record

# Record Knowledge Record significant decisions for future work. Reconcile the affected requirements and system designs after the decision. ## Record a decision Create an ADR when all statements are true: - The choice creates a durable constraint, boundary, contract, ownership rule, operational invariant, or repository-wide convention. - Meaningful alternatives have different trade-offs. - Future work must follow or supersede the choice. - A requirement, system design, test, or work order does not preserve enough rationale. Do not create an ADR for a simple feature, local refactor, routine dependency change, plan sequence, or temporary migration step. ## ADR procedure 1. Choose an ID in the form `YYYY-MM-DD-short-title`. 2. Make sure that `docs/decisions/<id>.md` does not exist. 3. Create the ADR with the template below. 4. Add it to `docs/decisions/INDEX.md`. 5. Reconcile affected specifications. Existing numeric ADR IDs remain valid. Do not rename them. ```markdown # ADR-YYYY-MM-DD-short-title: Short title **Status:** accepted | superseded by <adr-id> | deprecated **Date:** YYYY-MM-DD **Area:** backend | frontend | infra | protocol | workflow ## Context Explain the situation and the need for a decision. ## Decision State the selected rule, boundary, or contract. ## Consequences State benefits, costs, and follow-up constraints. ## Alternatives Considered State each meaningful alternative and why it was not selected. ``` ## Reconcile specifications Rea...