Skip to content

LLM Wiki entry point

Read first

  1. Repository AGENTS.md.
  2. .wiki-standard.yaml.
  3. knowledge/index.md.
  4. Context map.
  5. docs/project/status.md.
  6. The manifest's roles.authoring_policy path, or AUTHORING.md when no path is mapped, before writing new original English prose.
  7. DESIGN.md for rendered changes.
  8. Knowledge graph query results when Graphify is selected.

Operating model

  • Ingest: register a target source, preserve its identity, add its stable exact-row anchor, update the relevant concept and evidence state, add links, and record the change.
  • Query: select the smallest authoritative target context, expose uncertainty, and cite registered evidence through individual internal source-row links.
  • Lint: find contradictions, stale claims, unsupported authority, ungoverned exact repetitions of the declared canonical question, bare or misdirected source identities, unregistered named-authority URLs, missing links, and generated-output drift.
  • Propose: after a user-authored reusable improvement is implemented, verified, and committed locally, preserve it in a tracked Standard proposal. Validate direct states and terminal transitions offline, prepare a disposable scrubbed payload, and bind approval to the exact digest and governed form revision. The user submits; intake, Standard decision, exact registry/release evidence, and optional adoption remain separate authorities. Never reuse the Standard's sole historical bridge.

Never treat an LLM answer, rendered page, or graph edge as new evidence.

Apply the DenchCo ASD-STE100-inspired 80% house style in the mapped authoring policy (AUTHORING.md when no path is mapped) to all new original English Wiki prose. 80% is a pragmatic aim, not a computed score or a claim of ASD-STE100 compliance. Review meaning and source fidelity before style, preserve protected text and necessary technical terms, and record material exceptions with their scope and reason. Follow explicit user instructions and stricter applicable local policy. Do not bulk-rewrite existing prose or change consumer pins to apply the default.

In a Standard Production maintenance workspace, a file-changing development turn remains incomplete until its persistent changes are recorded in the required end-of-turn JJ commit under DKBWS-PROV-001.

Use the tracked proposal workflow for a governed upstream handoff. If the form, label, marker search, provenance, or digest evidence is unavailable or ambiguous, preserve the record and stop; filing does not amend the pinned Standard or authorize migration.

Development responses route Human or LLM Wiki destinations through the configured live canonical HTTP(S) origin under DKBWS-PROMPT-002. File, editor, absolute-path, and repository-relative Markdown links do not substitute for Wiki navigation; plain repository paths identify only implementation artifacts with no rendered route. Captured drafts check Markdown, HTML links, and plain GFM-autolinked URLs. Managed local drafts add --managed-live to require exact service identity, canonical URL equality, and HTTP 200 for every displayed route; STD-VAL-007 remains the host boundary for uncaptured output.

Persistent preview handoff uses npm run service:preview only after all twelve registry fields, the exact installed/loaded job, canonical URL, and marker identity pass. Live service evidence belongs to maintainer verification; distribution/CI leaves DKBWS-RUNTIME-002 not checked.

Use project status for zero to three current priorities and the validation queue for parked work. Apply the AGENTS.md completion and cycle guard before recommending any follow-up; a completed answer does not need a Next Steps section.