Keeping this manual current

This manual is part of the product, not a separate document that drifts. Its source lives in the repository under docs/manual/, so a change is a normal pull request and its history is git.

Editing content

Each page is a Markdown file in docs/manual/. Edit the file, open a pull request, and the change ships with the app. The page order and the per-role mapping are defined in app/services/manual.py; add a page there to add it to the navigation and the printed document.

Regenerating screenshots

Screenshots are generated by automation from the seeded demo, so they cannot silently disagree with the current UI. Regenerate them with:

npm run manual:screenshots

This logs into the seeded Riverside demo, captures each screen, and writes the PNGs into docs/manual/img/. Commit the updated PNGs. The generator is defined in e2e/manual-screenshots.spec.ts and reuses the same Playwright setup as the end-to-end tests, so it starts the app the same way make verify does.

The stale-content check

tests/test_manual.py runs in make verify and fails loudly if the manual rots:

• every screenshot a page references must exist on disk,
• every user-facing role must have a page,
• every page must render,
• cross-links between manual pages must point at a page that exists.

So a screenshot deleted or renamed, or a page removed, breaks the build rather than leaving a broken manual in front of a clinic.

Exporting the single-document manual

Print / export as one document renders every page as one document. Use the browser’s Print to PDF to produce the single file suitable for upload as the DHA system_manual.