Процесс ADR

Когда нужен ADR

• Выбор технологии (БД, брокер, фреймворк).
• Принципиальное архитектурное решение, влияющее на несколько модулей.
• Отказ от ранее принятого решения (с superseded by).
• Неочевидный trade-off.

Когда НЕ нужен ADR

• Реализационные детали в одном модуле.
• Простые технические выборы (имя функции, структура файлов).
• Временные решения (помечаются TODO в коде + issue).

Процесс

1. Скопировать ../20-architecture/adr/TEMPLATE.md с новым номером (следующий после последнего).
2. Заполнить секции: Context, Decision, Consequences, Alternatives considered.
3. Выставить Status: proposed.
4. Создать PR, @-упомянуть заинтересованных.
5. Обсудить. При необходимости — итерировать.
6. После достижения согласия — Status: accepted, Date: <сегодня>, merge.

После merge

ADR иммутабелен. Правки только:

• исправления опечаток;
• смена статуса на deprecated или superseded by ADR-NNNN.

Нумерация

Сквозная от 0001. Не переиспользовать.

Связи

• В других документах ссылаться на ADR: [ADR-0002](../20-architecture/adr/0002-kafka-as-event-bus.md).
• В principles.md и data-storage-decisions.md — ссылка в “References” каждого принципа.