Skip to content

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 records content priorities and parked formal transitions. The change log 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 <slug>.
  4. Validate offline with check <id> or check --all, including direct-state metadata, prerequisites, ordering, and terminal workflow-v1 transitions.
  5. Generate a scrubbed preview with prepare <id> and inspect it with show <id>.
  6. Bind approval to the exact payload digest and governed form revision.
  7. Run open <id> 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.