Тема: Приложение C. Чек-листы прикладного SDD
Уровень сложности: Средний
Расчётное время изучения: 8-12 часов (теория + практика)
Предварительные требования: Завершённое изучение первого тома курса SDD (базовые чек-листы перед спецификацией, реализацией и слиянием)
Понимание структуры артефактов: requirements.md, plan.md, validation.md, QWEN.md
Опыт работы с CI/CD и базовое понимание Git-воркфлоу
Знакомство с концепциями: доменная модель, API-контракт, JSON Schema
Прочитана часть 0 прикладного тома (выбор учебного incident-case)
Цели обучения: Применять чек-листы приложения C как операционный справочник на каждом этапе прикладного цикла SDD, от подготовки до итогового production-зачёта
Внедрять механизмы контроля качества: шлюзы спецификации (Spec CI), файловый арбитраж, ядовитые спецификации и автоматическую ремедиацию с чёткими условиями отката
Выявлять и устранять антипаттерны прикладного цикла по 12-пунктовой диагностике, принимая решение об остановке автоматизации при ≥3 провалах
Формировать завершённый пакет артефактов capstone с traceability: genealogy.md, poisoned/fixed-пары, judgment.md и доказательной базой
Обзор: Приложение C прикладного тома представляет собой операционный справочник — надстройку над базовыми чек-листами первого тома. Оно охватывает восемь критических контрольных точек прикладного цикла: подготовка к работе, восстановление спецификации из унаследованных систем, внедрение ядовитых спецификаций для валидации процесса, включение Spec CI, файловый арбитраж спорных изменений, оптимизация production-метрик с защитой от эффекта Гудхарта, автоматическая ремедиация инцидентов, аудит антипаттернов и итоговый production-зачёт. Каждый чек-лист спроектирован как шлюз: прохождение проверок обязательно для перехода на следующий этап. Шаблоны процесса (запрос на слияние, ретроспектива, запросы для /clear и перепланирования) вынесены в каталог examples/templates/. Особенность прикладного уровня — в переходе от «наличия артефактов» к «доказательной работе артефактов в production-условиях»: каждое требование отслеживается, каждое изменение обосновано, каждый риск контролируется инвариантом.
Ключевые концепции: Шлюз спецификации (spec ci): Автоматизированная проверка, блокирующая продвижение изменений при нарушении структурных правил. Требования: стабильные REQ-* идентификаторы, обратная трассировка плана на требования, валидация JSON-примеров схемой, информативные сообщения об ошибках (файл, строка, правило, причина, действие). Spec CI работает как «ворота до выполнения», а не как ревью после.
Ядовитая спецификация (poisoned spec): Метод валидации процесса: вносится ровно один контролируемый дефект, описывается ожидаемый симптом, фиксируется критерий восстановления. Исправление должно затрагивать spec/plan/validation, а не только текстовое объяснение. Проверяет, что система контроля качества способна обнаружить и локализовать ошибку.
Файловый арбитраж: Механизм разрешения споров через diff в файлах, а не дискуссии в чате. Роли: Координатор (процесс), Имплементор (код), Верификатор (проверяемые доказательства). Повторяющиеся решения фиксируются в precedents.md. Есть стоп-условие для перехода на ручное ревью.
Эффект гудхарта и anti-goodhart-метрики: Принцип: когда метрика становится целью, она перестаёт быть хорошей метрикой. Защита: каждой целевой метрике сопоставлена парная метрика-инвариант, есть правило «красной кнопки» для остановки при искажении поведения. Изменение порога — это изменение риска, требующее следования процедуре.
Радиус последствий (blast radius): Граница затронутых систем при автоматической ремедиации. Контрольные вопросы: известен ли радиус, есть ли dry-run, записано ли условие отката до исполнения, требуется ли ручное подтверждение при расширении радиуса или повторном провале. Высокорисковые инциденты требуют двух независимых подтверждений восстановления.
След (trace) и evidence ref: Воспроизводимый идентификатор решения: источник, версия политики, хэш подсказки. Каждая запись в QWEN.md содержит автора, доказательство и TTL. Поле evidence_ref обязательно для всех записей следа. Обеспечивает аудируемость и отладку дрейфа системы.
Mutable rules и ttl: Правила с ограниченным сроком действия. Запрет: правила без TTL или с TTL > 90 дней. Принудительное пересмотр предотвращает застывание неактуальных ограничений и накопление технического долга в governance.
Budget ceiling и ярусы (tiers): Финансовый и операционный контроль при переключении между уровнями системы. Каждое переключение имеет бюджетный потолок и аварийный режим. Предотвращает неконтролируемый рост затрат при масштабировании.
Manual review floor: Незыблемый минимум ручной проверки, не зависящий от значения KPI. Защита от полной автоматизации критических решений. Сохраняется даже при достижении высоких показателей автоматизации.
Genealogy.md: Артефакт итогового пакета: требование, источники, уровень уверенности, открытый вопрос. Обеспечивает прозрачность происхождения каждого элемента спецификации и честность о неопределённости.
Практические упражнения: Название: Аудит готовности к прикладному циклу
Проблема: Вы получили репозиторий команды, которая утверждает, что готова начать прикладной том. Проверьте следующие факты: (1) каталог capstone/ отсутствует, (2) в README нет различения [runnable] и [project script], (3) requirements.md есть, но plan.md ссылается на него неявно через текст, а не через REQ-* идентификаторы, (4) validation.md содержит JSON-примеры без схемы. Составьте список блокеров и план устранения с приоритетами.
Решение: Шаг 1: Блокер — отсутствие capstone/. Действие: создать структуру каталогов, запланировать итоговый пакет. Шаг 2: Блокер — неразличение типов команд. Действие: пройтись по всем главам, промаркировать явно, обновить README. Шаг 3: Блокер — отсутствие стабильных идентификаторов. Действие: внедрить REQ-* нумерацию, обновить plan.md с прямыми ссылками. Шаг 4: Блокер — невалидируемые примеры. Действие: создать JSON Schema, добавить валидацию в CI. Приоритет: 3 и 4 — критичные для Spec CI, 1 и 2 — критичные для итогового зачёта. Срок: 2 рабочих дня.
Сложность: intermediate
Название: Проектирование ядовитой спецификации
Проблема: Ваша система обработки платежей имеет требование REQ-PAY-07: «Таймаут операции — 30 секунд». Создайте ядовитую спецификацию: внесите ровно один дефект, опишите ожидаемый симптом, задайте критерий восстановления. Убедитесь, что исправление затронет минимум два артефакта из spec/plan/validation.
Решение: Шаг 1: Дефект — изменить таймаут на 300 секунд в plan.md (в разделе конфигурации сервиса), оставив requirements.md неизменным. Шаг 2: Симптом — метрика p99 latency вырастет выше 45 секунд, пользователи получат timeout на клиенте раньше, чем сервер завершит операцию, что приведёт к дублированию платежей. Шаг 3: Критерий восстановления — p99 latency < 10 секунд, отсутствие дублей в validation.md (проверка по trace_id). Шаг 4: Исправление затрагивает: plan.md (возврат к 30 секунд), validation.md (добавление проверки консистентности trace_id + таймаута). requirements.md не требует изменения, что демонстрирует разделение ответственности.
Сложность: intermediate
Название: Разбор инцидента по anti-Goodhart-протоколу
Проблема: Команда оптимизировала метрику «количество закрытых тикетов в день». Через месяц: тикеты закрываются за 2 минуты, но реинцидентность выросла на 400%, клиентская удовлетворённость упала. Метрика достигла цели 150%. Команда хочет «поднять планку до 200%». Примените чек-лист перед оптимизацией метрик.
Решение: Шаг 1: Остановка — применить правило красной кнопки: рост реинцидентности > 50% — стоп-условие. Шаг 2: Разделение: целевая метрика (тикеты/день) отделена от инварианта (реинцидентность < 10%, NPS > 30). Шаг 3: Реплей: проверить не только агрегаты (среднее), но и дрейф поведения — распределение времени решения, корреляция «быстрое закрытие → повторное открытие». Шаг 4: След: зафиксировать версию политики, хэш промпта, принявшего решение о 150%. Шаг 5: Изменение порога — оформить как изменение риска: требуется анализ anti-Goodhart-метрики, согласование Safety, обновление governance_protocol. Вывод: повышение до 200% — отклонено, возврат к 100% с добавлением инварианта реинцидентности.
Сложность: advanced
Название: Симуляция файлового арбитража
Проблема: Спор: Имплементор добавил в plan.md шаг «кэшировать ответы API на 24 часа», Верификатор отклоняет — требование REQ-DATA-03 требует «актуальность данных в течение 1 часа». Координатор получил 15 сообщений в чате с аргументами. Примените протокол файлового арбитража.
Решение: Шаг 1: Остановить дискуссию в чате, объявить переход к файловому арбитражу. Шаг 2: Имплементор создаёт ветку с двумя вариантами plan.md: (A) исходный с кэшем 24ч, (B) модифицированный с кэшем 1ч + fallback на stale-данные. Шаг 3: Верификатор предоставляет проверяемое доказательство: diff между (A) и (B), JSON-тест с time-travel проверкой актуальности, логи CI для обоих вариантов. Шаг 4: Решение: принять (B), зафиксировать в precedents.md: «При конфликте кэша и актуальности — fallback на stale с TTL=требуемая актуальность». Шаг 5: Стоп-условие: если спор затрагивает архитектуру хранилища — эскалация на архитектурный комитет. Время разрешения: 2 часа вместо 2 дней чат-переписки.
Сложность: intermediate
Название: Аудит антипаттернов: принятие решения
Проблема: Проведите аудит гипотетической команды по 12-пунктовому чек-листу. Факты: (1) constitution.md проверяется только в конце спринта, (2) 3 правила в mutable_rules без TTL, (3) после провала ядовитой спецификации изменили только объяснение в README, (4) CI падает — ослабили validation.md, (5) у метрики «деплои/день» нет anti-Goodhart-пары. Остальные пункты — положительные. Какое решение требует приложение C?
Решение: Шаг 1: Подсчёт отрицательных ответов: 5 пунктов (1, 2, 3, 4, 5). Шаг 2: Применение правила: ≥3 отрицательных ответов → запрет на добавление новых слоёв автоматизации. Шаг 3: Приоритизация: пункт 4 (ослабление validation при падении CI) — критичный, требует немедленного реверта и root-cause анализа. Пункт 3 — второй по критичности, требует повторного прохождения цикла ядовитой спецификации с изменением артефактов. Пункт 2 — операционный, назначить владельца, установить TTL 90 дней. Пункты 1 и 5 — структурные, включить в план спринта. Шаг 4: Контроль: через 2 недели повторный аудит, цель — ≤2 отрицательных ответа.
Сложность: advanced
Кейсы: Название: Внедрение Spec CI в платёжной платформе fintech-стартапа
Сценарий: Стартап с 50 микросервисами, 8 командами, ежедневно 200+ PR. Проблема: 40% откатов в production вызваны несоответствием реализации требованиям, при этом requirements.md существовал, но не был связан с кодом. Решение руководства: «внедрить автоматизацию за месяц».
Задача: Команды восприняли требование как «ещё один CI». Внедрили проверку наличия файла requirements.md, но не структуры. Через 2 месяца: файлы есть, но REQ-* идентификаторы дублируются, plan.md ссылается на несуществующие требования, JSON-примеры в validation.md не валидируются. Откаты не снизились. Руководство требовало «усилить автоматизацию» — добавить ML-проверку семантики.
Решение: Применён чек-лист «Перед включением шлюза спецификации» из приложения C. Остановка: обнаружено 7 нарушений из 5 пунктов чек-листа. Решение — не добавлять ML, а закрыть базовые провалы. Действия: (1) стандартизация REQ-* с префиксом домена (PAY-, AUTH-, LED-), (2) внедрение обратной трассировки: каждый пункт plan.md начинается с [REQ-...], (3) JSON Schema для всех API-примеров, (4) структурированные сообщения CI: файл, строка, правило, причина, действие. Ключевое: Spec CI настроен как обязательный статус check — PR блокируется при провале.
Результат: Через 6 недель: откаты из-за несоответствия требованиям снизились с 40% до 8%. Время на ревью сократилось на 30%, так как Верификаторы получили машинно-проверяемые артефакты. Через 4 месяца: добавлена anti-Goodhart-метрика «время от обнаружения несоответствия до исправления» — предотвращено искажение в сторону «красивых, но бесполезных» requirements.md.
Извлечённые уроки: Автоматизация без базовых шлюзов усиливает хаос, а не порядок — правило ≥3 провалов работает
CI-сообщения должны быть actionable: разработчик тратит < 2 минут на понимание причины провала
Обратная трассировка plan→requirements позволяет при изменении требования автоматически находить затронутые задачи
Связанные концепции: Шлюз спецификации (Spec CI)
Обратная трассировка требований
Правило остановки автоматизации при ≥3 провалах
Название: Авто-ремедиация инцидента с контролируемым радиусом последствий
Сценарий: Облачный провайдер, система автоматического масштабирования кластеров Kubernetes. Ночной пиковый инцидент: latency API выросла на 300%, триггер сработал, система начала масштабирование — создала 500 новых подов вместо 50, исчерпав бюджет кластера и вызвав каскадный отказ соседних сервисов.
Задача: Исходная система авто-ремедиации не имела: (1) ограничения радиуса последствий, (2) dry-run для масштабирования, (3) записанного условия отката, (4) ручного подтверждения при расширении. «Интеллектуальная» система приняла решение на основе агрегатов без проверки дрейфа поведения.
Решение: Применены чек-листы «Перед оптимизацией production-метрик» и «Перед авто-ремедиацией». Введены: (1) радиус последствий — максимум 2x текущих реплик для одного сервиса, каскадное масштабирование запрещено без ручного подтверждения; (2) dry-run: симуляция планировщика Kubernetes с оценкой ресурсов; (3) условие отката: если latency не снижается через 5 минут после масштабирования — откат к исходному состоянию; (4) двойное подтверждение восстановления для инцидентов с радиусом > 1 сервиса.
Результат: Следующий аналогичный пик: система создала 45 подов (в пределе 2x), latency нормализовалась. Dry-run предсказал исчерпание CPU в кластере — триггер переключился на аварийный режим с перенаправлением трафика в резервный регион. Время восстановления сократилось с 47 минут до 8. Стоимость инцидента: с $120K (штрафы SLA + перерасход ресурсов) до $3K (переключение трафика).
Извлечённые уроки: Радиус последствий без ограничения — это не авто-ремедиация, а авто-катастрофа
Dry-run в распределённых системах должен учитывать глобальные ресурсы, а не только локальные метрики целевого сервиса
Условие отката, записанное до исполнения, предотвращает «забывание» в панике инцидента
Связанные концепции: Радиус последствий (Blast Radius)
Dry-run и безопасная предварительная проверка
Правило красной кнопки для эффекта Гудхарта
Двойное подтверждение восстановления
Название: Итоговый production-зачёт: от чата к доказательной базе
Сценарий: Команда из 4 человек завершила 6-месячный проект миграции биллинговой системы. При подготовке к зачёту обнаружилось: capstone/README.md содержит копию истории чата с заказчиком, genealogy.md отсутствует, judgment.md — одно предложение «всё работает», нет poisoned/fixed-пары.
Задача: Команда воспринимала прикладной цикл как «написать код и объяснить в чате». Артефакты создавались ретроспективно, без traceability. Заказчик требовал аудируемую базу для регуляторной проверки (PCI DSS).
Решение: Применён чек-лист «Перед итоговым production-зачётом» как рамка восстановления. Действия: (1) README.md переписан: кейс описан через доменную модель, без упоминания чата; (2) genealogy.md создан для каждого критичного требования (хранение PAN, шифрование, аудит) — с источником (PCI DSS пункт), уровнем уверенности (высокий/средний/низкий), открытым вопросом; (3) poisoned/fixed-пара восстановлена: внесён дефект в валидацию PAN-номеров, зафиксировано исправление в validation.md; (4) judgment.md: вердикт «условно пригодно», причина — 2 средних уровня уверенности в genealogy, evidence_ref на тесты, следующий шаг — повторная оценка через квартал; (5) добавлены бюджетный и anti-Goodhart-слои с блокирующими инвариантами.
Результат: Зачёт пройден с отметкой «требует доработки уверенности». Регуляторная проверка: genealogy.md принят как доказательство происхождения требований. Через квартал: 2 открытых вопроса закрыты, уровень уверенности повышен, judgment.md обновлён до «пригодно». Команда внедрила создание genealogy параллельно с разработкой, а не ретроспективно.
Извлечённые уроки: Genealogy.md, созданный в процессе, требует 10% времени; восстановленный ретроспективно — 300%
Открытые вопросы в genealogy — не признак слабости, а признак честности; их отсутствие вызывает подозрение
Judgment.md с вердиктом «условно пригодно» и планом — ценнее, чем «пригодно» без обоснования
Связанные концепции: Genealogy.md и уровень уверенности
Poisoned/fixed-пара как доказательство процесса
Judgment.md с вердиктом и следующим шагом
Readiness-вывод: разделение блокеров и улучшений
Советы по изучению: Проходите чек-листы не как формальность, а как шлюз: при отрицательном ответе — остановка и устранение, а не галочка «потом исправим»
Создайте физический или цифровой «паспорт проекта» — таблицу с 8 контрольными точками приложения C, где фиксируете дату прохождения, владельца, ссылку на evidence
Для визуальных учеников: постройте диаграмму потока — от «Перед началом» до «Итоговый зачёт» — и отметьте, какие шаблоны из examples/templates/ используются на каждом этапе
Для практиков: возьмите свой текущий проект и проведите аудит по 12-пунктовому чек-листу антипаттернов; реальный счёт отрицательных ответов даст сильнее, чем теоретическое чтение
Для аудиальных учеников: обсуждайте кейсы в парах — роли Координатора, Имплементора, Верификатора при файловом арбитраже лучше понимаются через игру
Фиксируйте «прецеденты» (precedents.md) с первого спора — экономия времени на повторных ситуациях превышает затраты на ведение
Используйте TTL как «напоминание о смерти» для правил: установите календарные напоминания за неделю до истечения
Дополнительные ресурсы: Шаблоны процесса (examples/templates/): pr-template.md — структура запроса на слияние с обязательными ссылками на требования; retrospective.md — формат ретроспективы с фокусом на evidence; clear-prompt.md и replan-prompt.md — минимальные запросы для /clear и перепланирования
Часть 0 — production lab: Выбор и подготовка учебного incident-case, различение [runnable] и [project script], создание capstone/
Часть 12 — production antipatterns: Полный разбор 12 антипаттернов, на которые нацелен быстрый чек-лист приложения C
Приложение c первого тома: Базовые чек-листы: перед спецификацией, реализацией, слиянием — фундамент, на который надстраивается прикладной уровень
Json schema specification: Документация для создания валидационных схем validation.md (json-schema.org)
Чек-лист pci dss requirements: Пример внешнего источника требований для практики создания genealogy.md с регуляторной трассировкой
Резюме: Приложение C прикладного тома превращает SDD из методологии в операционную систему: восемь контрольных точек с чёткими шлюзами, 12-пунктовый аудит антипаттернов как датчик здоровья процесса, итоговый зачёт с доказательной базой. Ключевые принципы: шлюзы до выполнения (а не ревью после), файловый арбитраж вместо чат-дискуссий, anti-Goodhart-защита метрик, контролируемый радиус авто-ремедиации, остановка автоматизации при ≥3 провалах. Успешное применение требует не зазубривания пунктов, а внутреннего принятия культуры: «отрицательный ответ — это не провал, а предотвращённый провал в production».