living-docs-governance

Topics in the source

• Living Docs Governance
• When to Activate
• How It Works
• 1. Inventory before creating anything
• 2. Assign four roles
• 3. Wire the active harness honestly
• 4. Treat documentation as evidence, not executable truth
• 5. Update only the role affected

Long-lived projects often rot at the documentation layer first: the README describes an old pipeline, architecture notes describe a refactor that never shipped, and every new session re-derives context that should already be available. Living Docs Governance assigns four non-overlapping roles to the project's existing documentation, links those roles from the active agent harness, and defines small update rules that keep the sources useful. The roles matter; the filenames do not. This is a maintain-phase practice. For one-time exploration of an unfamiliar repository, use codebase-onboarding first. Activate when any of these are true: The repository has grown past a few modules and its docs are drifting from the code. Agents or teammates repeatedly rediscover the same structure and decisions. Nobody can quickly answer what is healthy, blocked, intentionally removed, or currently authoritative. Deleted files or abandoned approaches are recreated because their disposition was not preserved. The project needs a durable governance layer without adopting a large documentation platform. Do not use this for a throwaway script or create a parallel documentation system when the repository al

This is an excerpt. Refer to the complete source and its current requirements.