# Standard proposals Potentially reusable improvements remain owned by `Thirlwall Inquiry: Implications for Defence Healthcare`. Each proposal has one canonical, schema-valid JSON record under `standard-proposals/`. Generated previews under `output/standard-proposals/` are ignored and disposable. ## Appearance proposal `configurable-appearance-family` records the verified consumer implementation and its immutable origin in `standard-proposals/configurable-appearance-family.json`. It separates corrections to existing requirements from a proposed reusable colour generator and configurable appearance defaults. A local candidate for the Standard now implements the reusable mechanism. It retains the exact brand accent and derives related colours for readable text and controls. The consumer example uses `#e1efdd` with dark sage `#505c4d`, light appearance and wide desktop layout. These remain project choices. Native saved appearance preferences and explicit reader width choices take precedence. The candidate is committed as `3ec5e3c545d3d6bc423d42983910217cff4abee8`. Its build, 182 unit and contract tests, full browser checks and nine appearance cases passed. A separate full-content pale-green/Dark/Wide browser check and maintainer provenance check passed. It has no managed preview service, so its distribution report retains that explicit limit. The exact proposal payload still needs approval before the governed form may be opened. No issue has been submitted. Standard acceptance, immutable release and consumer adoption remain pending; the wiki's Standard pin is unchanged. ### Completed technical handoff The Standard project reviewed and integrated this candidate in commit `dc14307508a24b170c7401f9469a1ee83115ec1f`. Its committed verification record reports 183 passing tests, 13 appearance cases and complete maintainer verification. The review fixed saved-appearance reversal during adoption. The technical handoff is complete and must not be proposed again from the older consumer status alone. Formal intake, acceptance, release and consumer adoption retain the separate states recorded above. The original exact proposal payload remains unchanged. The later blue and purple article-link roles in Thirlwall commit `12114d3acb71a5ed44836f3de40d0e8f366ee51a` were not part of that integration. The [project status](https://thirlwall-wiki.pages.dev/project/status/index.md) records content priorities and parked formal transitions. The [change log](https://thirlwall-wiki.pages.dev/log/index.md) records the implementation history. ## Content-development proposal `content-first-development-next-steps` records the user-confirmed response pattern in `standard-proposals/content-first-development-next-steps.json`. Its verified consumer origin is commit `ad966d4e43b56931ea22db804c4fde10704d043b`. After every development cycle, assess the wiki's continuing purpose, evidence and content maturity. Offer up to three numbered priorities. Each states **Proposed update**, **Why it matters** and **Done when**. Failed or unrun required checks take precedence. Do not repeat completed work or reopen blocked research without its recorded trigger. If none is grounded, state: “No further grounded content update is available.” Recommendations do not authorise execution. The local standing instruction applies now. The reusable Standard change also updates shared instructions, starter templates, the bootstrap prompt and response checks. A captured-response check can verify the format; it cannot judge the value of a recommendation or intercept output that the host does not expose. Formal intake, acceptance, release and consumer adoption remain separate from local implementation. The reusable implementation is recorded in candidate commit `b1d2de08fa8b5383dd50878e3bbec314097c9cf8`, based on `31ee99b4c9c2da71e60c006d93a03f0e8ccff724`. Its complete distribution run passed 189 tests, runtime/browser checks, 13 appearance cases and the canonical mutation guard. A separate maintainer provenance check passed. The isolated candidate's report leaves managed-service verification not checked. The implementation has also been integrated into the local Standard checkout, which uses its own maintainer verification. The tracked proposal preserves the exact candidate origin and bounded evidence; no issue has been submitted and the consumer pin is unchanged. ## Local workflow 1. Complete, verify, and commit the implementation in its own JJ phase. 2. Record the full Git commit, optional JJ change ID, and immutable pinned Standard revision. 3. Create and complete a proposal with `npm run standard:proposal -- new `. 4. Validate offline with `check ` or `check --all`, including direct-state metadata, prerequisites, ordering, and terminal workflow-v1 transitions. 5. Generate a scrubbed preview with `prepare ` and inspect it with `show `. 6. Bind approval to the exact payload digest and governed form revision. 7. Run `open ` only when requested. It may check and open the form, but the user performs the final Submit action. Do not include consumer files, secrets, private absolute paths, personal or confidential data, restricted evidence, public vulnerability detail, or material the project lacks authority to share. ## Separate authority The tracked workflow distinguishes local verification, payload approval/submission, explicit Standard classification and decision, immutable release inclusion, and optional adoption back into this project. Record each transition in its own JJ phase. Directly edited records must satisfy the same invariants as command-produced records, and issue linkage, decision, release inclusion, and adoption are terminal workflow-v1 transitions. Issue closure is not acceptance; acceptance is not release; and release does not change `.wiki-standard.yaml`, conformance status, deviations, or the pinned revision automatically. Release evidence requires the registry bytes at the exact full recorded revision, proof that it strictly descends from the release revision, a matching public release with the exact tag, `draft: false`, and `immutable: true`, and tag resolution to the recorded release revision. Never use `pre-registry-local-history`: workflow v1 reserves it for one exact existing UK Digital Health `DKBWS-LINK-002` Standard-registry entry, not consumer work. If the form, required label, marker search, provenance, exact digest, or remote result is missing, changed, duplicated, or ambiguous, stop with the durable local record. Never substitute an automated issue write or attachment upload.