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

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

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

• [ ] Прочитана часть 0, выбран один учебный 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. Здесь — 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 пройден, отрицательные ответы имеют владельца и следующий контроль.