| 1 | # ADR statuses: lifecycle (for humans) |
| 2 | |
| 3 | **Purpose:** a single agreement on **how to read and update** the “Status” field in ADRs — without listing individual record numbers (full index — [README.md](README.md)). |
| 4 | |
| 5 | **On the documentation site:** status-grouped navigator (auto-generated from ADR headers) — [../site/adr-nav/index.md](../site/adr-nav/index.md) · public: [ai-guiders.github.io/cascade-ide/en/site/adr-nav/](https://ai-guiders.github.io/cascade-ide/en/site/adr-nav/). |
| 6 | |
| 7 | --- |
| 8 | |
| 9 | ## Why two levels |
| 10 | |
| 11 | - **First tag** answers: *is the decision adopted or replaced?* |
| 12 | - **Second tag** (optional) answers: *are code/delivery obligations for this ADR already met in the product?* |
| 13 | |
| 14 | This separates **architectural decision** from **implementation fact**. |
| 15 | |
| 16 | --- |
| 17 | |
| 18 | ## First tag (required) |
| 19 | |
| 20 | | Value | Meaning | |
| 21 | |--------|---------| |
| 22 | | **Proposed** | Draft for discussion: not yet adopted as direction; may change or be rejected. | |
| 23 | | **Accepted** | Decision adopted: norm for code and review until **Superseded** / **Deprecated**. | |
| 24 | | **Superseded** | Replaced by another ADR; text must link explicitly (“instead use …”). | |
| 25 | | **Deprecated** | Obsolete; do not use for new work (historical reference). | |
| 26 | |
| 27 | Clarifications in parentheses are allowed: **Accepted (direction)**, **Accepted (strangler)** — when it matters not to confuse with “everything is already in code”. |
| 28 | |
| 29 | --- |
| 30 | |
| 31 | ## Second tag: **Implemented** |
| 32 | |
| 33 | Written after **Accepted** with **` · `** (space, middle dot, space): |
| 34 | |
| 35 | **`Accepted · Implemented`** |
| 36 | |
| 37 | **When to use:** main delivery for the ADR is **merged in code** (and contract tests/docs if needed); behavior is **current canon**. In the ADR header, briefly state *what* was done (one line), without duplicating the whole diff. |
| 38 | |
| 39 | **When not to use:** decision is adopted but implementation is intentionally phased / strangler / partial scope — keep **Accepted** with a note in parentheses (**partial**, **by plan**, **MCP implemented**, etc.) until “done” criteria are agreed. |
| 40 | |
| 41 | **Partial implementation** without the `Implemented` second tag: e.g. **`Accepted (partial)`** or a dedicated “Implementation state” subsection in the body. |
| 42 | |
| 43 | --- |
| 44 | |
| 45 | ## What to update when status changes |
| 46 | |
| 47 | 1. ADR file header (`**Status:**`). |
| 48 | 2. Row in [README.md](README.md) table. |
| 49 | 3. If needed — matching row in [architecture-policy.md](../../architecture-policy.md) (topic navigator). |
| 50 | 4. Short line in the “Versioning this navigator” section of `architecture-policy.md` when policy or a large index changes. |
| 51 | |
| 52 | One logical change — **one logical commit** (as usual in the repo). |
| 53 | |
| 54 | --- |
| 55 | |
| 56 | ## Relation to agents and CI |
| 57 | |
| 58 | ADR statuses are **not** a substitute for tracker tasks; they record **norm**. CI checks and MCP/CLI contracts are described in the ADRs themselves or linked docs (e.g. [MCP-PROTOCOL.md](../../MCP-PROTOCOL.md)). |
| 59 | |
| 60 | --- |
| 61 | |
| 62 | ## Brief for assistants (IDE / Cursor) |
| 63 | |
| 64 | - First tag: **Proposed** / **Accepted** / **Superseded** / **Deprecated** — see table above. |
| 65 | - Mark code delivery with **`Accepted · Implemented`** (via ` · `); in the ADR header — briefly *what* was done. |
| 66 | - Do not add **`Implemented`** when scope is intentionally partial — keep **Accepted** with a note (“partial”, strangler, separate implementation subsection). |
| 67 | - On status change, sync: ADR header, [README.md](README.md) row, and [architecture-policy.md](../../architecture-policy.md) if needed. |
| 68 | |
| 69 | The repository ignores **`.cursor/`**; you may duplicate these points in a **local** Cursor rule on your machine if you want. |
| 70 | |