# Template — Documentation maintenance section
Copy the block below into the project's root author-instructions file. It tells an agent what to load, what to update, and what never to touch. State local exceptions inline rather than restating this framework. The specs own the rules and this section points at them.
```markdown
## Documentation
- Load the specs of the domains you touch before acting: `<root>/specs/SPEC-<domain>.md`.
- Do not load the decision log unless someone asks why a rule exists.
- When a spec and a decision record disagree, follow the spec and leave the record alone.
- When you change current behavior, update the owning spec in the same change.
- Cite a rule by its ID, `<domain-slug>:<rule-slug>`, in commits, reviews, and comments.
- Add a decision record only when the choice is cross-cutting, expensive to reverse, constraining, or rejects an alternative someone will propose again.
- Never rename or delete a merged decision record, and never edit one to describe the present.
- Keep exploratory material in `.draft/`; promotion is a rewrite into the owning zone.
- Write step-by-step guides to the guides spec: every step carries its check, a manual step enumerates its fields and values, and upstream facts carry dated citations in the reference zone.
- Report documentation changes by ownership: which spec changed, which rule IDs, which hooks passed.
- Stay inside the budget for the artifact class: `<root>` author instructions 100 lines, a subtree's 150, a spec 300, a record 350 words, a chapter 200, a catalog 300. Every one of these is gated; a document that wants more room splits.
```
Two habits keep this section short. Write each rule once and link rather than restate it, and push anything that binds only one subtree into that subtree's own author-instructions file.