Dokumentationsplan

Documentation Blueprint

Give every fact one home, so an agent finds what to build, how it works now and which rules hold. When the project already has a documentation layout, keep it and map these roles onto its files.

1. Where each fact lives

• Create a file when it has verified content. A young project starts with README.md, AGENTS.md and its first feature documents.
• A fact whose owner file exists is linked from other documents, never copied into them.
• Until the owner file exists, the feature document holds the fact and notes where it moves (Moves to docs/api.md); move it when that file is created.
• Reference the code can produce (OpenAPI schema, schema dump, CLI help) comes from its generator: link the output and the command. Hand-written text explains meaning, rules and reasons.

2. Feature document

# <Feature>
Status: implemented | partly implemented | planned
Last verified: YYYY-MM-DD against <commit or branch>

## What it does
## Business rules
## States and transitions
## Edge cases and limits
## Acceptance criteria
## Planned changes
## Open questions
## Related
- API: [api.md#<anchor>](../api.md#<anchor>)
- Data model: [data-model.md#<anchor>](../data-model.md#<anchor>)
- UI components: `path/to/component`
- Code and tests: `path/to/file`, `path/to/test`

• Status, Last verified and Related are required.
• Each section ends with a Sources: line of repository paths it was checked against.
• Acceptance criteria are observable checks taken from tests or the accepted spec, each with its source. A criterion no test covers ends with (not covered by a test).
• States and transitions lists each transition with its trigger. An unknown trigger is Unknown, needs <role>, not a guess.
• Planned changes holds accepted specs and roadmap items the code does not run yet, linked. An accepted spec is not proof the feature works.

3. Verification dates

• Last verified changes only after re-checking the content against the code, never for wording edits.
• Write the date of the check and the commit or branch you checked. A claim you could not check is marked Unverified.

4. The documentation section of AGENTS.md

Add one ## Documentation section or update the existing one; leave the file's other rules as they are. Name only files that exist and commands from the manifests:

## Documentation
| Before you | Read |
|---|---|
| Plan or change a feature | `docs/features/<feature>.md`, `docs/product.md` |
| Add a module or dependency | `docs/architecture.md` |
| Change endpoints, data or permissions | `docs/api.md`, `docs/data-model.md`, `docs/security.md` |

- Checks: `<test command>`, `<lint command>`, `<docs generator command>`.
- Current and planned stay apart: specs in `<spec folder>` describe work the code does not run yet.
- A task is done when the documents its change touches are updated in the same change, with a new Last verified line.

Before you finish

• Every fact has one owner file; others link to it.
• Each feature document has Status, Last verified, Related and per-section Sources.
• Acceptance criteria and transitions name their source or are marked unknown.
• Planned work sits under Planned changes, not under What it does.
• AGENTS.md has one Documentation section: read-before table, checks, done rule.