Статусы ADR: жизненный цикл (для людей)¶

Назначение: единая договорённость, как читать и как обновлять поле «Статус» в ADR — без перечисления конкретных номеров записей (полный индекс — в README.md).

На сайте документации: сгруппированный навигатор по статусам (автогенерация из шапок ADR) — ../site/adr-nav/index.md · публично: ai-guiders.github.io/cascade-ide/site/adr-nav/.

Зачем два уровня¶

Первый тег отвечает на вопрос: решение принято или отменено в пользу другого?
Второй тег (опционально) отвечает на вопрос: обязательства по коду/поставке для этого ADR уже выполнены в продукте?

Так отделяется архитектурное решение от факта внедрения.

Первый тег (обязательный)¶

Значение	Смысл
Proposed	Черновик на обсуждение: ещё не принято как направление; может меняться или быть отклонено.
Accepted	Решение принято: это норма для кода и ревью, пока не появится Superseded / Deprecated.
Superseded	Заменено другим ADR; в тексте должна быть явная ссылка «вместо этого — …».
Deprecated	Устарело; не использовать для новых изменений (историческая справка).

Уточнения в скобках допустимы: Accepted (направление), Accepted (strangler) — если важно не смешивать с «всё уже в коде».

Второй тег: Implemented¶

Пишется через · (пробел, средняя точка, пробел) после Accepted:

Accepted · Implemented

Когда ставить: основная поставка по ADR влита в код (и при необходимости тесты/доки контракта), поведение можно считать текущим каноном. В шапке ADR кратко уточняют что именно (одна строка), без дублирования всего diff.

Когда не ставить: решение принято, но реализация намеренно растянута / strangler / только часть scope — остаётся Accepted с пояснением в скобках (частично, по плану, MCP implemented и т.д.), пока не договоритесь о критерии «готово».

Частичная реализация без второго тега Implemented: например Accepted (частично) или в тексте отдельный подраздел «Состояние реализации».

Что обновлять при смене статуса¶

Шапка файла ADR (**Статус:**).
Строка в таблице README.md.
При необходимости — соответствующая строка в architecture-policy.md (навигатор по темам).
Краткая строка в разделе «Версионирование этого навигатора» в architecture-policy.md, если меняется политика или крупный индекс.

Один смысл изменения — логичный коммит (как принято в репозитории).

Связь с агентами и CI¶

Статусы ADR — не замена задач в трекере; они фиксируют норму. Проверки в CI и контракты MCP/CLI описываются в самих ADR или в ссылочных документах (например MCP-PROTOCOL.md).

Кратко для ассистентов (IDE / Cursor)¶

Первый тег: Proposed / Accepted / Superseded / Deprecated — см. таблицу выше.
Внедрение в код отмечать Accepted · Implemented (через ·); в шапке ADR — коротко что сделано.
Не ставить Implemented, если scope намеренно частичный — оставить Accepted с пояснением («частично», strangler, отдельный подпункт реализации).
При смене статуса синхронизировать: шапку ADR, строку в README.md, при необходимости architecture-policy.md.

Репозиторий игнорирует каталог .cursor/; при желании те же пункты можно продублировать в локальном правиле Cursor у себя на машине.