These rules apply to every agent working in this repository.
docs/adr/**.specs/<current-sprint>/<feature>/spec.md(the current active spec)docs/wiki/**- Existing code conventions
- Do not implement code directly from a raw user request.
- Do not implement code directly from a spec.
- Code may only be implemented from an accepted implementation contract.
- If the implementation contract is ambiguous, stop and escalate to the Orchestrator.
- Do not silently change architecture.
- Do not rewrite accepted ADR history.
- Do not update the wiki in a way that contradicts accepted ADRs.
- Wiki: current operational understanding and active conventions (source of truth for current state).
- ADRs: historical decisions and rationale.
- Specs: historical snapshots of feature intent at time of implementation (read-only after workflow completes).
- Implementation contracts: constrained implementation instructions (active during workflow, then archived).
Escalate to the Orchestrator when:
- The spec is ambiguous or not testable.
- The implementation contract does not constrain the work enough.
- A new architectural decision is required.
- A dependency, framework, service, or persistence strategy must change.
All agents have access to wiki search tools that query the operational wiki at docs/wiki/**:
wiki_wiki_search— hybrid (FTS5 + vector) search for fuzzy/conceptual querieswiki_wiki_search_exact— exact lexical/FTS search for specific terms, IDs, file nameswiki_wiki_read_section— read a specific section by path and heading
Before making decisions, writing documents, reviewing work, or implementing code, agents should proactively search the wiki for relevant operational context. The wiki captures current understanding of architecture, domain concepts, engineering practices, and decisions.
The wiki sits at authority order #3 — above existing code conventions — and should be consulted as a primary reference for operational knowledge.