This reverts commit b7a6d1aaac.

@@ -52,3 +52,3 @@
 Before planning or designing on top of an existing codebase:
 
-1. Check the repo root. If `CONTEXT-MAP.md` exists, read it, identify which contexts the task touches, and read their `CONTEXT.md` files. Otherwise read the root `CONTEXT.md` if present.
+1. Check the repo root. If `CONTEXT-MAP.md` exists, read it, list every tracked `CONTEXT.md`, the root one included (`git ls-files ':(glob)**/CONTEXT.md'`), identify which contexts the task touches, and read their `CONTEXT.md` files. Otherwise read the root `CONTEXT.md` if present.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted, and one marked `proposed` is decided but not yet built; a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.

@@ -146,2 +143,3 @@
 
-- **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
+- **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you suggest is not a decision until the user accepts it.
+- **Accept an ADR with its implementation.** Record a decision that is not yet built as `proposed`. The change that builds it, and no earlier one, sets the ADR to `accepted` before it merges and marks each older record the ADR supersedes or amends; an amended record keeps its status and gains a note naming the amending ADR.

@@ -52,3 +52,3 @@
 Before planning or designing on top of an existing codebase:
 
-1. Check the repo root. If `CONTEXT-MAP.md` exists, read it, identify which contexts the task touches, and read their `CONTEXT.md` files. Otherwise read the root `CONTEXT.md` if present.
+1. Check the repo root. If `CONTEXT-MAP.md` exists, read it, list every tracked `CONTEXT.md`, the root one included (`git ls-files ':(glob)**/CONTEXT.md'`), identify which contexts the task touches, and read their `CONTEXT.md` files. Otherwise read the root `CONTEXT.md` if present.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted, and one marked `proposed` is decided but not yet built; a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.

@@ -46,3 +46,1 @@
-- **Open (`status: proposed`):** state the situation and current behavior. Status-less ADRs count as proposed and stay unchanged until answered. Superseded or deprecated ADRs do not settle promises still in code.
-- **Keep (`status: accepted`):** state the situation, obligation, stakeholder goal, or risk and the chosen promise. A deferred keep names the owner who must decide.
-- **Drop (`status: accepted`):** state the negative promise and reason, such as "We do not support concurrent writers because each deployment has one writer." For "don't care, take the smallest," record only the negative promise. Record drops even when `project-docs`' ADR test excludes them.
+- **Open (`status: open`):** state the situation and current behavior. Superseded or deprecated ADRs do not settle promises still in code.

@@ -49,0 +47,4 @@
+- **Keep:** state the situation, obligation, stakeholder goal, or risk and the chosen promise. A deferred keep names the owner who must decide.
+- **Drop:** state the negative promise and reason, such as "We do not support concurrent writers because each deployment has one writer." For "don't care, take the smallest," record only the negative promise. Record drops even when `project-docs`' ADR test excludes them.
+
+Mark a keep or drop `accepted` when the code already reflects it; otherwise mark it `proposed` until the change that builds it merges. Both are decided ADRs.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted, and one marked `proposed` is decided but not yet built; a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.

@@ -121,3 +121,3 @@
 That's it. An ADR can be a single paragraph — the value is in recording _that_ a decision was made and _why_, not in filling out sections. Add optional sections only when they earn their place:
 
-- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — when decisions get revisited
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — when a decision is not yet built or gets revisited

@@ -146,2 +146,3 @@
 
-- **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
+- **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you suggest is not a decision until the user accepts it.
+- **Accept an ADR with its implementation.** Record a decision that is not yet built as `proposed`. The change that builds it, and no earlier one, sets the ADR to `accepted` before it merges and marks each older record the ADR supersedes or amends; an amended record keeps its status and gains a note naming the amending ADR.

@@ -145,6 +145,7 @@ What qualifies:
 ## Maintenance rules
 
 - **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
+- **Ship an ADR accepted with the change that builds it.** That change sets the ADR to `accepted` before it merges and marks each older record it supersedes or amends; an amended record keeps its status and gains a note naming the amending ADR.

@@ -145,6 +145,7 @@ What qualifies:
 ## Maintenance rules
 
 - **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
+- **Ship an ADR accepted with the change that builds it.** That change sets the ADR to `accepted` before it merges and marks each older record it supersedes or amends; an amended record keeps its status and gains a note naming the amending ADR.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open. An ADR with any other status, such as `superseded` or `deprecated`, is outdated and does not bind: delete it per the maintenance rules. If the plan contradicts an accepted ADR, name it ("this conflicts with ADR-0007"), then either adjust the plan or, on the user's decision, change the ADR per the maintenance rules — never silently override a recorded decision.

@@ -145,6 +145,7 @@ What qualifies:
 ## Maintenance rules
 
 - **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
+- **Ship an ADR accepted with the change that builds it.** That change sets the ADR to `accepted` before it merges and marks each older record it supersedes or amends; an amended record keeps its status and gains a note naming the amending ADR.

@@ -146,3 +146,3 @@
 
 - **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
-- **Supersede living decisions; delete dead ones.** When a decision is reversed but the area it governs still exists, write a new ADR and mark the old one `superseded by ADR-NNNN` — the old rationale still explains why the code looked the way it did. But when a refactor removes the subject of a decision entirely, edit or delete the ADR: a record about code that no longer exists only misleads, and version control remembers. Leave numbering gaps as-is after a deletion — renumbering breaks `superseded by` references.
+- **Ship an ADR accepted with the change that builds it.** That change sets a `proposed` ADR to `accepted` before it merges and edits or deletes each older ADR whose decision it changes, per the next rule.

@@ -147,2 +147,3 @@
 - **Update inline, don't batch.** When the user settles a term or a decision mid-session, write it down right then. Deferred documentation doesn't happen. A plan you propose is not a decision until the user accepts it.
-- **Supersede living decisions; delete dead ones.** When a decision is reversed but the area it governs still exists, write a new ADR and mark the old one `superseded by ADR-NNNN` — the old rationale still explains why the code looked the way it did. But when a refactor removes the subject of a decision entirely, edit or delete the ADR: a record about code that no longer exists only misleads, and version control remembers. Leave numbering gaps as-is after a deletion — renumbering breaks `superseded by` references.
+- **Ship an ADR accepted with the change that builds it.** That change sets a `proposed` ADR to `accepted` before it merges and edits or deletes each older ADR whose decision it changes, per the next rule.
+- **Keep only current decisions.** When a decision changes, edit its ADR to state the new decision. When a new decision replaces it outright, delete the old ADR and add a new one. Delete an ADR whose decision no longer applies. After deleting an ADR, update or remove every link to it. Never keep an outdated ADR marked superseded or deprecated, or annotated with a note pointing to another ADR, and never write "amends ADR-X" or "supersedes ADR-X" in the newer one: each ADR states its own decision, and version control keeps the history. When the reason the old approach was dropped is worth keeping, record it under the current ADR's Considered Options.

@@ -57,3 +57,3 @@
 Replace proposed text with the accepted decision when answered. Delete proposed ADRs only when they duplicate another root; retain accepted negatives after their code disappears. Use the same format for design choices, implementation gaps, and review findings. ADRs plus git carry resume state; execution history belongs in commits.
 
-Accepted ADRs remain settled across sessions. Supersede one when a fact undermines its reason, a witness appears for a don't-care drop, or a deferred keep's owner answers. Proposed and status-less ADRs are the decision backlog.
+Accepted ADRs remain settled across sessions. When a fact undermines one's reason or a witness appears for a don't-care drop, put it to the user; when the user or a deferred keep's owner answers, edit or replace the ADR per `project-docs`. Proposed ADRs are the decision backlog; status-less ADRs count as accepted.

@@ -28,3 +28,3 @@
 **Cross-reference with code.** When the user states how something works, check whether the code agrees, and surface any contradiction: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
 
-**Name ADR conflicts.** When the plan contradicts a recorded ADR, say so explicitly — "this conflicts with ADR-0007" — and force the choice: adjust the plan, or supersede the ADR per the `project-docs` skill. Never let a plan silently override a recorded decision.
+**Name ADR conflicts.** When the plan contradicts an accepted ADR, say so explicitly — "this conflicts with ADR-0007" — and force the choice: adjust the plan, or change the ADR per the `project-docs` skill. Never let a plan silently override a recorded decision.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** An ADR marked `accepted`, or without a status, is decided and binding; `proposed` means the decision is still open. Other statuses, including `superseded` and `deprecated`, are outdated and do not bind: flag them and use the maintenance rules when that cleanup is authorized. If the plan contradicts an accepted ADR, name it ("this conflicts with ADR-0007"), then either adjust the plan or, on the user's decision, change the ADR per the maintenance rules — never silently override a recorded decision.

@@ -31,3 +31,3 @@
 Have a fresh-context sub-agent attack the result from both directions: find situations the old code handles that the rebuild omits without an accepted decision, and promises the rebuild makes that no accepted decision covers. Mechanism-only differences and replacements chosen by an accepted ADR are not findings.
 
-Put each uncovered situation to the user and record the answer in an added or superseding ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.
+Put each uncovered situation to the user and record the answer in a new or edited ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.

@@ -35,3 +35,3 @@
 ## Fix direction and missing features
 
-Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` ADR is the source of truth for the decision it records: code contradicting it is `code-drift`, and changing the decision means superseding the ADR per `project-docs`, never editing it to match the code.
+Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` or status-less ADR is the source of truth for the decision it records: code contradicting it is `code-drift`. Changing the decision is the user's call, after which the ADR is edited, replaced, or deleted per `project-docs`; never edit an ADR just to match the code.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** An ADR marked `accepted`, or without a status, is decided and binding; `proposed` means the decision is still open. Other statuses, including `superseded` and `deprecated`, are outdated and do not bind: flag them and use the maintenance rules when that cleanup is authorized. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007"), then either adjust the plan or, on the user's decision, change the ADR per the maintenance rules — never silently override a recorded decision.

@@ -31,3 +31,3 @@
 Have a fresh-context sub-agent attack the result from both directions: find situations the old code handles that the rebuild omits without an accepted decision, and promises the rebuild makes that no accepted decision covers. Mechanism-only differences and replacements chosen by an accepted ADR are not findings.
 
-Put each uncovered situation to the user and record the answer in an added or superseding ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.
+Put each uncovered situation to the user and record the answer in a new or edited ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.

@@ -35,3 +35,3 @@
 ## Fix direction and missing features
 
-Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` ADR is the source of truth for the decision it records: code contradicting it is `code-drift`, and changing the decision means superseding the ADR per `project-docs`, never editing it to match the code.
+Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` or status-less ADR is the source of truth for the decision it records: code contradicting it is `code-drift`. Changing the decision is the user's call, after which the ADR is edited, replaced, or deleted per `project-docs`; never edit an ADR just to match the code.

@@ -57,3 +57,3 @@
 Replace proposed text with the accepted decision when answered. Delete proposed ADRs only when they duplicate another root; retain accepted negatives after their code disappears. Use the same format for design choices, implementation gaps, and review findings. ADRs plus git carry resume state; execution history belongs in commits.
 
-Accepted ADRs remain settled across sessions. Supersede one when a fact undermines its reason, a witness appears for a don't-care drop, or a deferred keep's owner answers. Proposed and status-less ADRs are the decision backlog.
+Binding ADRs remain settled across sessions. When a fact undermines one's reason or a witness appears for a don't-care drop, put it to the user; when the user or a deferred keep's owner answers, edit or replace the ADR per `project-docs`. Proposed ADRs are the decision backlog.

@@ -32,2 +31,3 @@
+Have a fresh-context sub-agent attack the result from both directions: find situations the old code handles that the rebuild omits without an accepted decision, and promises the rebuild makes that no accepted decision covers. Mechanism-only differences and replacements chosen by a binding ADR are not findings.
 
-Put each uncovered situation to the user and record the answer in an added or superseding ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.
+Put each uncovered situation to the user and record the answer in a new or edited ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.

@@ -35,3 +35,3 @@
 ## Fix direction and missing features
 
-Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` ADR is the source of truth for the decision it records: code contradicting it is `code-drift`, and changing the decision means superseding the ADR per `project-docs`, never editing it to match the code.
+Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` or status-less ADR is the source of truth for the decision it records: code contradicting it is `code-drift`. Changing the decision is the user's call, after which the ADR is edited, replaced, or deleted per `project-docs`; never edit an ADR just to match the code.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** An ADR marked `accepted`, or without a status, is decided and binding; `proposed` means the decision is still open. Other statuses, including `superseded` and `deprecated`, are outdated and do not bind: flag them and use the maintenance rules when that cleanup is authorized. Read any current ADR an outdated record points to and apply these status rules. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007"), then either adjust the plan or, on the user's decision, change the ADR per the maintenance rules — never silently override a recorded decision.

@@ -58,2 +57,3 @@
+Replace proposed text with the accepted decision when answered. Delete proposed ADRs only when they duplicate another root; retain binding negative ADRs after their code disappears. Use the same format for design choices, implementation gaps, and review findings. ADRs plus git carry resume state; execution history belongs in commits.
 
-Accepted ADRs remain settled across sessions. Supersede one when a fact undermines its reason, a witness appears for a don't-care drop, or a deferred keep's owner answers. Proposed and status-less ADRs are the decision backlog.
+Binding ADRs remain settled across sessions. When a fact undermines one's reason or a witness appears for a don't-care drop, put it to the user; when the user or a deferred keep's owner answers, edit or replace the ADR per `project-docs`. Proposed ADRs are the decision backlog.

@@ -32,2 +31,3 @@
+Have a fresh-context sub-agent attack the result from both directions: find situations the old code handles that the rebuild omits without a binding ADR, and promises the rebuild makes that no binding ADR covers. Mechanism-only differences and replacements chosen by a binding ADR are not findings.
 
-Put each uncovered situation to the user and record the answer in an added or superseding ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.
+Put each uncovered situation to the user and record the answer in a new or edited ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.

@@ -35,3 +35,3 @@
 ## Fix direction and missing features
 
-Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` ADR is the source of truth for the decision it records: code contradicting it is `code-drift`, and changing the decision means superseding the ADR per `project-docs`, never editing it to match the code.
+Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` or status-less ADR is the source of truth for the decision it records: code contradicting it is `code-drift`. Changing the decision is the user's call, after which the ADR is edited, replaced, or deleted per `project-docs`; never edit an ADR just to match the code.

@@ -58,3 +58,3 @@
 
 - **Use the glossary's canonical terms** in everything you produce — plans, code, commit messages. When the user's wording conflicts with a defined term, flag the mismatch instead of silently adopting either side.
-- **Don't re-litigate recorded ADRs.** A status-less ADR counts as accepted; only an ADR marked `proposed` is still open, and a `deprecated` or `superseded` one no longer binds — its successor, where one exists, governs instead. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007") and either adjust the plan or supersede the ADR — never silently override a recorded decision.
+- **Don't re-litigate recorded ADRs.** An ADR marked `accepted`, or without a status, is decided and binding; `proposed` means the decision is still open. Other statuses, including `superseded` and `deprecated`, are outdated and do not bind: flag them and use the maintenance rules when that cleanup is authorized. Read any current ADR an outdated record points to and apply these status rules. If the plan contradicts a binding ADR, name it ("this conflicts with ADR-0007"), then either adjust the plan or, on the user's decision, change the ADR per the maintenance rules — never silently override a recorded decision.

@@ -3,3 +3,3 @@
 Apply the shared reengineering skill's required design-abstractions reading before preparing the briefs.
 
-Have three fresh-context sub-agents independently design the scope. Give all three the loaded modeling guidance and `CONTEXT.md`, the boundary ADR, and accepted ADRs as the sole sources of requirements. For a narrower-than-program scope, include exact boundary signatures. Keep the repository outside their reading scope. Give each a different constraint:
+Have three fresh-context sub-agents independently design the scope. Give all three the loaded modeling guidance and `CONTEXT.md`, the boundary ADR, and binding ADRs as the sole sources of requirements. For a narrower-than-program scope, include exact boundary signatures. Keep the repository outside their reading scope. Give each a different constraint:

@@ -34,2 +33,3 @@
+Have a fresh-context sub-agent attack the result from both directions: find situations the old code handles that the rebuild omits without a binding ADR, and promises the rebuild makes that no binding ADR covers. Mechanism-only differences and replacements chosen by a binding ADR are not findings.
 
-Put each uncovered situation to the user and record the answer in an added or superseding ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.
+Put each uncovered situation to the user and record the answer in a new or edited ADR before adding, removing, or keeping its promise. Completion requires the implementation to satisfy the confirmed design, all three checks to pass, and every review finding to be resolved.

@@ -35,3 +35,3 @@
 ## Fix direction and missing features
 
-Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` ADR is the source of truth for the decision it records: code contradicting it is `code-drift`, and changing the decision means superseding the ADR per `project-docs`, never editing it to match the code.
+Fix docs to match code by default. Change code only for a confirmed **code-drift** where the doc is the intended source of truth. A third case hides inside "incorrect": the doc describes a capability that _should_ exist but doesn't (an endpoint, a flag). Removing the claim and _implementing_ the feature are both valid — surface the fork to the user, and if the claim is removed, flag the missing feature as separate work rather than silently dropping it. ADRs are decision records, not behaviour docs. A `proposed` ADR is an open question: correct its statement of current behaviour if the code contradicts it, never delete it as stale. An `accepted` or status-less ADR is the source of truth for the decision it records: code contradicting it is `code-drift`. Changing the decision is the user's call, after which the ADR is edited, replaced, or deleted per `project-docs`; never edit an ADR just to match the code.