# Приложение C. Чек-листы прикладного SDD

Это приложение можно использовать как быстрый справочник во время прикладного цикла. Оно надстраивается над [приложением C первого тома](../book/appendix-c-checklists.md): базовые чек-листы перед спецификацией, реализацией и слиянием там не дублируются. Шаблоны процесса (запрос на слияние, ретроспектива, минимальные запросы для `/clear` и перепланирования) перенесены в [`examples/templates/`](examples/templates/): `pr-template.md`, `retrospective.md`, `clear-prompt.md`, `replan-prompt.md`.

## Перед началом прикладного тома

- [ ] Прочитана [часть 0](part-00-production-lab.md), выбран один учебный incident-case.
- [ ] Понятно, какие команды в главах имеют статус `[runnable]`, а какие помечены как `[project script]`.
- [ ] Создан или запланирован каталог `capstone/` для итогового пакета.
- [ ] Из первого тома понятны `requirements.md`, `plan.md`, `validation.md`, `QWEN.md` и пакет доказательств.
- [ ] Выбран режим чтения: учебный минимум или полный production-трек.

## Перед восстановлением спецификации из унаследованной системы

- [ ] Все источники перечислены с владельцем и ссылкой.
- [ ] Время событий нормализовано.
- [ ] Требования отделены от фонового контекста.
- [ ] Каждое утверждение имеет доказательство или помечено как гипотеза.
- [ ] Спорные пункты не попали в утверждённый контракт.

## Перед запуском ядовитой спецификации

- [ ] Внесён ровно один дефект.
- [ ] Описан ожидаемый симптом сбоя.
- [ ] Есть критерий восстановления.
- [ ] Исправление должно менять spec/plan/validation, а не только объяснение.

## Перед включением шлюза спецификации (Spec CI)

- [ ] У требований есть стабильные `REQ-*` идентификаторы.
- [ ] Пункты плана ссылаются на требования.
- [ ] Проверка области охвата опирается на доменную модель или API-контракт.
- [ ] JSON-примеры из `validation.md` валидируются схемой.
- [ ] CI-ошибка содержит файл, строку, правило, причину и действие.

## Перед файловым арбитражем спорного изменения

- [ ] Роли Координатор, Имплементор и Верификатор описаны заранее.
- [ ] Верификатор принимает только проверяемые доказательства.
- [ ] Спор разрешается различиями (diff) в файлах, а не аргументами в чате.
- [ ] Повторяющиеся решения попадают в `precedents.md`.
- [ ] Есть стоп-условие для ручного ревью.

## Перед оптимизацией production-метрик

- [ ] Целевая метрика отделена от инвариантов качества.
- [ ] Есть правило красной кнопки для сценария Гудхарта.
- [ ] Реплей проверяет не только агрегаты, но и дрейф поведения.
- [ ] След содержит источник решения, версию политики, хэш подсказки или иной воспроизводимый идентификатор.
- [ ] Изменение порога проходит как изменение риска, а не косметическая правка YAML.

## Перед авто-ремедиацией

- [ ] Известен радиус последствий.
- [ ] Есть пробный прогон (dry-run) или безопасная предварительная проверка.
- [ ] Условие отката записано до исполнения.
- [ ] Ручное подтверждение включается при неопределённости, повторном провале или расширении радиуса последствий.
- [ ] Инцидент не закрывается до двух независимых подтверждений восстановления, если риск высокий.

## Перед аудитом антипаттернов прикладного цикла

Полный разбор симптомов и причин — в [части 12](part-12-production-antipatterns.md). Здесь — 12 вопросов как быстрый чек-лист.

- [ ] `constitution.md` срабатывает как шлюз до выполнения, а не только как ревью после.
- [ ] В `mutable_rules` нет правил без `ttl` или с `ttl` больше 90 дней.
- [ ] После провала ядовитой спецификации меняется хотя бы один артефакт (`requirements.md`, `plan.md`, `validation.md`), а не только объяснение.
- [ ] Верификатор использует контрпример, лог hook'а или JSON Schema — не свободный текст.
- [ ] В `governance_protocol` есть veto от Safety и детерминированный tie-breaker.
- [ ] Запускаемые команды (`[runnable]`) явно отделены от `[project script]`-интерфейсов.
- [ ] Каждой целевой метрике сопоставлена парная anti-Goodhart-метрика.
- [ ] Когда CI падает, чинят код, а не ослабляют `validation.md`.
- [ ] У переключения между ярусами есть бюджетный потолок и аварийный режим.
- [ ] Каждая запись в `QWEN.md` имеет автора, доказательство и `ttl`.
- [ ] `manual_review_floor` сохраняется независимо от значения KPI.
- [ ] Поле `evidence_ref` заполнено в каждой записи следа.

Если на три и больше пунктов ответ отрицательный — не добавляйте новые слои автоматизации; сначала закройте провалы в текущем контуре.

## Перед итоговым production-зачётом

- [ ] `capstone/README.md` объясняет кейс без истории чата.
- [ ] `genealogy.md` содержит требование, источники, уровень уверенности и открытый вопрос.
- [ ] Poisoned/fixed-пара содержит один дефект и одно проверяемое исправление.
- [ ] `validation.md` ссылается минимум на один реально запущенный runnable-пример или его проектный аналог.
- [ ] `judgment.md` содержит вердикт, причину, `evidence_ref` и следующий шаг.
- [ ] Бюджетный и anti-Goodhart-слои имеют хотя бы по одному блокирующему инварианту.
- [ ] Readiness-вывод отделяет блокеры от улучшений.
- [ ] Диагностический чек-лист части 12 пройден, отрицательные ответы имеют владельца и следующий контроль.