30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
# Documentation Policy
|
|
|
|
## Purpose
|
|
|
|
This policy defines how architectural knowledge is captured and maintained.
|
|
|
|
## Mandatory Rules
|
|
|
|
- Record every architecture decision in the Bible before or together with implementation.
|
|
- Use English for all architecture documentation.
|
|
- Keep only current architecture in active sections.
|
|
- When a solution is replaced, update or remove obsolete guidance in the same change.
|
|
- Keep architecture details centralized in `bible/`; top-level docs should only reference it.
|
|
|
|
## Change Workflow
|
|
|
|
1. Update the relevant file(s) in `bible/architecture/` or `bible/synthesis/`.
|
|
2. If behavior changed, add or update a decision note in `bible/decisions/10-decisions.md`.
|
|
3. Update `CHANGELOG.md` when public bundle/tooling contracts change.
|
|
4. Remove duplicated or outdated statements from `README.md`, `CLAUDE.md`, and `AGENTS.md`.
|
|
|
|
## Scope Expansion Guardrail
|
|
|
|
- Do not expand the design-code scope beyond the currently approved work area by default.
|
|
- Expansion into new domains (for example API contracts, data/model architecture, observability,
|
|
security, or backend service patterns) requires an explicit user request.
|
|
- If the request is ambiguous, keep focus on the current scope and ask for confirmation before
|
|
broadening the repository mission.
|
|
- Prefer depth and consistency in the current approved scope over breadth.
|