Requirements and acceptance

This document records measurable requirements for the static documentation publication in the standalone private devSatym/resilience-gate-docs repository. Runtime platform requirements are analyzed separately in the integrated system design. Acceptance refers to the identified documentation snapshot and pinned upstream implementation, rather than a public-production certification.

ID	Requirement	Acceptance evidence
RG-W01	Use Astro and Starlight with a custom identity	Locked dependencies; custom tokens and homepage; successful production build
RG-W02	Teach the whole release question	Six primary sections, source coverage table, six flagship narratives, application and platform designs
RG-W03	Publish explicit canonical sources only	Content-map validation; website/upstream source roots; unknown/private/traversal/symlink rejection tests; publication inventory
RG-W04	Preserve source and observation identity	Documentation HEAD separate from pinned upstream revision; input origin; reviewed revision per article; historical UTC windows; separate application/chart/render/Freight identities
RG-W05	Preserve reviewed evidence	Verify 34 original PNG hashes; distinct derivative hashes; separate website screenshots
RG-W06	Publish at the root custom-domain base	Default /; origin https://resilience-gate.devsatym.xyz; production links, metadata, assets, nested routes, search, and 404 checked; alternate local base remains separately testable
RG-W07	Search the actual static build	Pagefind index, six meaningful queries, result navigation and no-result interaction
RG-W08	Support mobile and keyboard interaction	Route overflow crawl; mobile menu, theme persistence, focus, gallery and search tests
RG-W09	Supply accessible system diagrams	Ten source-derived static SVGs with title/description; captions, direct enlargement, local source
RG-W10	Keep builds deterministic and development current	Repeatable preparation; clean output rebuild; canonical edit watcher check
RG-W11	Document both systems	Four platform designs and website requirements/design/maintenance/reports discoverable under Reference
RG-W12	Validate without lab access	Source bootstrap plus content/unit/type/build/browser checks; no paid/cloud/cluster operations
RG-W13	Isolate documentation CI privileges	Read-only GitHub PR/main/manual checks; no CI publishing secret/job; separate native Pages Git builds, paused initial setup, explicit source/ownership inspection, reviewed branch previews and continuous main publication
RG-W14	Record actual audits	Browser images, accessibility results, repeated mobile Lighthouse measurements and independent review
RG-W15	Preserve underlying project behavior	Standalone website repository; ignored pinned upstream checkout; no tracked platform code, infrastructure, tests, or release workflows
RG-W16	Keep deployment status honest	Cloudflare configured target separate from local checks, deployment, and HTTPS verification; actual outcomes in Cloudflare receipts; prior transfer receipt preserved
RG-W17	Keep Cloudflare Pages static and within the Free plan	Native Git source from the private docs repository; root site, native command DOCS_SITE=<reviewed stable origin> npm run build:cloudflare, dist, Node 22.20.0; explicit nonsecret shell input rather than dashboard-vars-only configuration; no SSR/Functions/Worker/storage; static limits; only the new owner-added exact-host CNAME after Pages association; existing DNS/nameservers and paid settings preserved

Completion interpretation

A successful build is one acceptance item. A source test does not replace a live observation; an automated accessibility scan is not full WCAG certification. Each audit result uses PASS, FAIL, BLOCKED, or NOT RUN, with a reason. Private raw evidence is excluded even when a public report summarizes its result.

Prior monorepo audit results are historical and retained under migration-evidence/monorepo-audit/. Repository-separation checks and transfer remain recorded under docs/website/audit/migration/. The superseded Workers campaign remains under docs/website/audit/cloudflare/. Current Pages local checks, native deployment and strict HTTPS verification belong to separate actual receipts under docs/website/audit/cloudflare-pages/. Results and counts must come from the corresponding receipt. Private source or a successful repository transfer does not establish private or deployed website hosting.

Reader tasks

A reviewer can understand the system and inspect evidence without credentials. A learner can trace a request, a release and a failure through source-backed explanations. An operator can identify prerequisites, execution scope, expected outcomes and cleanup before choosing an existing procedure. The website adds no platform capabilities, live telemetry, accounts, analytics or database.

See the audit report, coverage map, technical design, and Cloudflare publication runbook.