How Requirement Changes Update User Docs

theHive treats documentation as part of the delivery system, not as a side artifact.

Trigger points

The docs pipeline checks for updates when any of the following change:

• BRM or PRD files
• rules, traceability, or drift documents
• mapped code paths referenced by help docs

What happens in CI

1. docs:validate checks metadata, ownership, and requirement links.
2. docs:impact compares changed requirement IDs and code references against linked help docs.
3. docs:prepare-sites stages each public docs site from declared source repos before build and manifest generation.
4. docs:manifest generates the HelpAI chunk manifest and docs bundle artifacts.

Source staging rule

Shared documents must be declared in scripts/docs/site-config.ts.

Do not rely on symlinks inside a product docs/ tree to pull external content into a public docs site. CI stages markdown from explicit source entries only, which keeps builds reproducible and prevents one repo from depending on an undeclared sibling checkout.

Some declared shared sources are optional supplements. If CI cannot resolve or clone an optional source, staging skips it with a warning instead of failing the site build. Use this only for cross-repo reference material that should enrich a public docs site, not for the product docs required to operate that site.

When a required source repo is not present in the checkout, CI first tries the docs source token path before falling back to CI_JOB_TOKEN. This keeps public docs staging independent from GitLab job-token allowlists between sibling projects.

Why this matters

If requirements change but user help does not, HelpAI starts answering from stale guidance. The drift gate prevents that by failing the pipeline when linked help pages were not reviewed.