adr-authorlisted

# Skill — ADR Author ## Когда подгружается Задачи, в которых обсуждается или фиксируется архитектурное решение. Триггер-keywords: `ADR`, `decision`, `supersede`, `rationale`, `trade-off`, `alternative`, «выбрать», «заменить», «отказаться от». ## Когда писать ADR (порог) Запиши ADR, если **хотя бы одно** из: - решение затрагивает ≥ 2 модуля (например, `domain` + `infra`); - меняется схема БД (таблица, колонка, индекс, миграция); - меняется контракт между слоями (тип в `domain/entities.py`, MCP-тул, Web-маршрут, формат CLI); - решение задаёт **политику**, которой все обязаны следовать («все мутации пишут revision», «все запросы идут через repository»); - решение **откатывает** предыдущее (`supersedes ADR-NNN`). **Не** пиши ADR для: - внутренней реализации одного модуля без внешнего эффекта; - мелких рефакторов / переименований; - багфиксов без архитектурных следствий; - выбора имени переменной / стиля кода (это standards, не ADR). ## Структура ADR ADR в COD-DOC — четыре markdown-поля плюс метаданные. Каждое поле имеет конкретное назначение; не путай их. ### 1. Context (что решаем) **Опиши проблему, не решение.** Что не работает в нынешнем состоянии? Какие ограничения / силы / зависимости заставляют принимать решение сейчас? > Шаблон-вопросы: > - Что было раньше? > - Что изменилось / что появилось нового? > - Какие альтернативные пути уже рассмотрены или отвергнуты? > - Какие constraints (perf, deadline, размер команды, существующий код)? Хороший Context — 2–6 а