Forge
markdowndeeb25a2
1# Статусы ADR: жизненный цикл (для людей)
2
3**Назначение:** единая договорённость, **как читать и как обновлять** поле «Статус» в ADR — без перечисления конкретных номеров записей (полный индекс — в [README.md](README.md)).
4
5**На сайте документации:** сгруппированный навигатор по статусам (автогенерация из шапок ADR) — [../site/adr-nav/index.md](../site/adr-nav/index.md) · публично: [ai-guiders.github.io/cascade-ide/site/adr-nav/](https://ai-guiders.github.io/cascade-ide/site/adr-nav/).
6
7---
8
9## Зачем два уровня
10
11- **Первый тег** отвечает на вопрос: *решение принято или отменено в пользу другого?*
12- **Второй тег** (опционально) отвечает на вопрос: *обязательства по коду/поставке для этого ADR уже выполнены в продукте?*
13
14Так отделяется **архитектурное решение** от **факта внедрения**.
15
16---
17
18## Первый тег (обязательный)
19
20| Значение | Смысл |
21|----------|--------|
22| **Proposed** | Черновик на обсуждение: ещё не принято как направление; может меняться или быть отклонено. |
23| **Accepted** | Решение принято: это норма для кода и ревью, пока не появится **Superseded** / **Deprecated**. |
24| **Superseded** | Заменено другим ADR; в тексте должна быть явная ссылка «вместо этого — …». |
25| **Deprecated** | Устарело; не использовать для новых изменений (историческая справка). |
26
27Уточнения в скобках допустимы: **Accepted (направление)**, **Accepted (strangler)** — если важно не смешивать с «всё уже в коде».
28
29---
30
31## Второй тег: **Implemented**
32
33Пишется через **` · `** (пробел, средняя точка, пробел) после **Accepted**:
34
35**`Accepted · Implemented`**
36
37**Когда ставить:** основная поставка по ADR **влита в код** (и при необходимости тесты/доки контракта), поведение можно считать **текущим каноном**. В шапке ADR кратко уточняют *что* именно (одна строка), без дублирования всего diff.
38
39**Когда не ставить:** решение принято, но реализация намеренно растянута / strangler / только часть scope — остаётся **Accepted** с пояснением в скобках (**частично**, **по плану**, **MCP implemented** и т.д.), пока не договоритесь о критерии «готово».
40
41**Частичная реализация** без второго тега `Implemented`: например **`Accepted (частично)`** или в тексте отдельный подраздел «Состояние реализации».
42
43---
44
45## Что обновлять при смене статуса
46
471. Шапка файла ADR (`**Статус:**`).
482. Строка в таблице [README.md](README.md).
493. При необходимости — соответствующая строка в [architecture-policy.md](../architecture-policy.md) (навигатор по темам).
504. Краткая строка в разделе «Версионирование этого навигатора» в `architecture-policy.md`, если меняется политика или крупный индекс.
51
52Один смысл изменения — **логичный коммит** (как принято в репозитории).
53
54---
55
56## Связь с агентами и CI
57
58Статусы ADR — **не** замена задач в трекере; они фиксируют **норму**. Проверки в CI и контракты MCP/CLI описываются в самих ADR или в ссылочных документах (например [MCP-PROTOCOL.md](../MCP-PROTOCOL.md)).
59
60---
61
62## Кратко для ассистентов (IDE / Cursor)
63
64- Первый тег: **Proposed** / **Accepted** / **Superseded** / **Deprecated** — см. таблицу выше.
65- Внедрение в код отмечать **`Accepted · Implemented`** (через ` · `); в шапке ADR — коротко *что* сделано.
66- Не ставить **`Implemented`**, если scope намеренно частичный — оставить **Accepted** с пояснением («частично», strangler, отдельный подпункт реализации).
67- При смене статуса синхронизировать: шапку ADR, строку в [README.md](README.md), при необходимости [architecture-policy.md](../architecture-policy.md).
68
69Репозиторий игнорирует каталог **`.cursor/`**; при желании те же пункты можно продублировать в **локальном** правиле Cursor у себя на машине.
70
View only · write via MCP/CIDE