Docs Update

Wiki maintenance after implementation turns proven changes into durable routed knowledge.

The closeout question is whether the implementation changed behavior, architecture, setup, contracts, decisions, operator workflow, troubleshooting knowledge, source knowledge, Fumadocs navigation, or routed page structure. When it did, docs-ingest-phase decides where that knowledge should land and what evidence supports it.

• Use this when: proven work changed behavior, architecture, setup, contracts, operator workflow, troubleshooting knowledge, or routed docs structure.
• It gives you: routed wiki/project docs aligned with implemented reality.
• It ends with: updated pages and metadata, root docs updates when needed, or an explicit docs no-op reason.
• Wrapped phase/skills: $docs-ingest-phase, routed flow-writing, routed concept-writing, writing-fragments, writing-beats, writing-shape, route/navigation bookkeeping.

Runtime Graph

Docs ingest is not a writing afterthought. The graph shows the closeout path from proven change to routed knowledge, project docs, navigation metadata, or an explicit no-op.

Reading The Ingest Path

• Start from proof: changed behavior, contracts, setup, operator workflow, troubleshooting knowledge, or routed docs structure.
• $docs-ingest-phase reads sources before writing. Session memory is not enough.
• Routed public-facing pages carry reader-facing product, usage, or domain knowledge. Private docs carry specs, decisions, runbooks, maintenance, internal operations, and durable writer artifacts.
• Substantial public-facing docs work runs writing-fragments, then writing-beats, then writing-shape before final page writing.
• Metadata is part of the work. A page that is correct but hard to find is not durable.
• Closeout reports paths, metadata changes, root docs updates, or the no-op reason.

Entrypoint

Use $docs-ingest-phase after Implementation, AFK Implementation, or Debugging when proven work changed durable knowledge.

The skill decides whether to update routed wiki pages, routed project pages, root docs, runbooks, or nothing. A no-op still needs a reason.

Flow

Ingest only after proof:

1. Read the relevant scoped AGENTS.md.
2. Invoke $docs-ingest-phase.
3. Read the implemented spec, implementation notes, runbook, source docs, and existing routed pages.
4. Write flow pages before concept pages when ingesting a spec.
5. For substantial public-facing docs creation or material updates, run writing-fragments, writing-beats, and writing-shape, then persist those artifacts in the private docs surface.
6. Update routed MDX pages under the repo's correct public or private docs surface.
7. Preserve surface and permission frontmatter.
8. Update nearest meta.json and section index pages.
9. Update root docs/README.md and runbooks only when setup, workflow, contracts, hooks, troubleshooting, or operator behavior changed.
10. Record no-op reasons when no routed or root docs update is required.

Routing Rule

Use /docs/harness as this repo's Harness domain entry point. CLI mechanics route under /docs/cli.

Use /docs/project for this repo's internal operations: specs, plans, implementation notes, maintenance logs, decisions, repo guidance, runbooks, durable public-doc writer artifacts, and management context.

Other repos should follow their own docs architecture instead of copying these route names.

Current Harness Rule

For the Harness wiki refactor, routed MDX is the canonical human-facing documentation. Existing specs, logs, raw notes, and current routed pages are the input material. New or expanded canonical pages should land in routed MDX.

No-Op Rule

A docs no-op must explain why no routed or root docs update is needed. Good reasons name the unchanged knowledge surface: no behavior change, no operator workflow change, no setup or contract change, no durable troubleshooting knowledge, or no routed page/navigation impact.

Terminal Outcome

Future humans and agents can find the implemented reality through routed pages and navigation metadata, with source paths listed in frontmatter.

Validation

Check meta.json, section cards, frontmatter, route file names, and wording constraints. Run the relevant docs or wiki checks when available.