Documentation Governance

documentation-governance_en.html

This document defines how the documentation package itself must evolve. It exists because the project depends on durable knowledge transfer rather than fragile memory.

Core governance rules

• Non-destructive update rule: start from the latest doc_updates_YYYY-MM-DD_HHMMSS/_docs/en/ package, not from the older baseline zip and not from memory.
• Growth rule: every existing documentation file must become larger or materially richer after an integration pass unless a human explicitly authorizes a deletion.
• No-loss rule: never summarize away detail. Expand, cross-link, clarify, and duplicate critical rules where they matter.
• Conversation capture rule: if a feature, behavior, command, argument, warning, or acceptance expectation was discussed in a session, it belongs in the docs. Conversation is temporary; docs are authoritative.
• AI usefulness rule: prefer explicitness over elegance. Repetition is acceptable when it prevents ambiguity for future humans, future models, scripts, or test harnesses.
• File naming rule: documentation filenames must remain lowercase, hyphen-separated, and language-suffixed, for example commands-and-functions_en.html.

Governance checks for every doc update

• Every existing file should grow or become materially richer.
• Every newly useful document should be added to index_en.html.
• All links should use lowercase canonical filenames.
• New behaviors, commands, and acceptance criteria should be documented in the same work cycle that introduces them.
• The package should keep a files/ directory with durable context artifacts used during the update.

Why this document exists

Future sessions must not repeat the mistake of replacing rich docs with shorter summaries. The docs are intended to become more complete over time, not more elegant and less informative.