ADR-0099: The User Manual is an In-App Topic Reference, Not a Document¶
- Status: accepted
- Date: 2026-07-27 (evening discussion; "Personally I would love to have an in-app help system as I do not expect anybody to actually read the document from start to finish")
- Deciders: Nicolas Burri
- Relates to: the registered LLM-help discussion (the manual is its Layer-2 corpus and its
Layer-1.5 foundation), the screenshot machinery (
npm run screens— the image source), the existing user guide/tutorial (absorbed as the narrative path), ADR-0074 (the PDF pipeline the print door stays open through).
Context¶
A proper user manual is becoming a real requirement. Three separately-raised discussions converged on the same principle in one day — evidence should DERIVE from the living system, not be hand-copied beside it (org chart: ADR-0098; LLM help: registered; manual: this ADR). The usage truth that decides the format: nobody arrives at a manual — they arrive at a QUESTION, standing on a specific screen. A linear document serves the writer's order; an in-app reference serves the reader's moment.
Decisions¶
- In-app, as TOPICS. The manual is a set of self-contained, linkable topic pages — each answers one question and is reachable from the surface it explains — rendered by the app's existing markdown renderer and SHIPPED WITH THE BUILD, so the help a user reads is always the help for the version they are running (also the auditor's expectation of user documentation). No static-site generator, no second deployment artifact.
- Screenshots are GENERATED, never pasted. Topics reference screenshot SCENES by name; the build resolves them to the current captures from the screenshot machinery. A UI change that alters a manual image surfaces as a visible diff (a review signal) instead of silent staleness — the same anti-drift principle as ADR-0098's derived views.
- Tutorial ↔ manual bidirectionality is a CHECKED invariant. The tutorial remains the narrative learning path; the manual is the topic reference; the links between them run BOTH ways and an oracle-style lint in the e2e gate fails when a tutorial lesson lacks its manual cross-reference or a manual topic covering a tutored subject fails to say so.
- Contextual entry points. Major surfaces carry a help affordance deep-linking to their topic — a DETERMINISTIC surface→topic mapping. This is the foundation of the registered context-sensitive help system (its no-LLM layer), and the topic corpus is the RAG source of its LLM layer: one body of content, three features.
- Not foreclosed, explicitly: a printable/PDF manual (the existing PDF pipeline can render the same topics if a customer or auditor ever wants one); localization beyond en (topics are ordinary content; de when warranted).
Consequences¶
- Topic content is markdown in-repo, versioned with the product; drafts are authored with intent marked for red-pen review (Nicolas: "drafts is fine").
- New app surface: a help route + topic renderer + per-surface "?" affordances (implementation sliced separately; content-first, since content survives every refinement).
- The bidirectionality lint joins the gate suite beside the seed-drift oracle.
- User documentation formally joins the release/validation story (versions with releases).