Тема: Прикладная часть 12. Антипаттерны production SDD: диагностическая карта прикладного цикла
Уровень сложности: Средний
Расчётное время изучения: 6-8 часов
Предварительные требования: Базовые знания SDD (Software Design Document)
Прохождение части 20 первого тома (базовые антипаттерны SDD)
Опыт работы с артефактами SDD (requirements.md, validation.md, plan.md)
Понимание концепций Spec CI и дуэлей
Знакомство с ярусным бюджетированием (часть 9)
Понимание Goodhart-метрик (часть 10)
Цели обучения: Провести диагностический аудит production SDD-пакета и выявить минимум 3 антипаттерна (или подтвердить их отсутствие) за 15-30 минут
Создать диагностическую карту с тремя полями: blocker, owner, next_check для каждого найденного антипаттерна
Применить 12-вопросный диагностический чек-лист к выбранному артефакту с фиксацией ответов yes/no/not_applicable
Отличитьproduction-варианты антипаттернов от их базовых версий первого тома и эскалировать понимание масштаба проблемы
Спроектировать минимум один Spec CI-шлюз, автоматически ловящий найденный антипаттерн
Обзор: Данная часть представляет собой диагностическую карту прикладного SDD-цикла, собирающую антипаттерны, которые возникают именно в production-контуре: при дуэлях, файловом арбитраже, Spec CI, ярусных бюджетах, anti-Goodhart-метриках и авто-ремедиации. Цель главы — не выучить список названий, а провести короткий аудит уже собранного production SDD-пакета и получить три диагностические строки: что блокирует допуск, кто отвечает за исправление и когда это снова проверяется. Каждый антипаттерн разбирается по схеме из трёх полей: Симптом (что наблюдается), Почему плохо (последствия для команды или агента), Как исправить (минимальные шаги до автоматизации). Каталог антипаттернов включает 17 позиций, из которых часть являются эскалациями базовых антипаттернов первого тома, а остальные появляются только в прикладном цикле.章节可以按任意顺序阅读，因为每条记录都独立且遵循相同的三字段结构。警告信号：一旦在同一production-пакете обнаружено три и более антипаттернов, их следует рассматривать как связанную сеть проблем с общим корнем в потерянном контракте риска.
Ключевые концепции: Диагностический блокер: Конкретное препятствие, которое не позволяет коду пройти в production. Определяется через ответы 'no' на вопросы диагностического чек-листа. Каждый блокер требует владельца и срока следующей проверки.
Антипаттерн 'конституция как косметика': Ситуация, когда правила конституции формально существуют, но не ограничивают агента в момент выполнения. Шлюз перед опасными действиями не запускается, scripts/constitution/check.py не вызывается.
Mutable-правило с ttl: ∞: Правило в mutable_rules без срока жизни или с чрезмерно длительным ttl. Со временем превращается в скрытую часть инварианта, которую боятся трогать, и применяется по аналогии к неподходящим ситуациям.
Ядовитая спецификация без diff в артефактах: После тренировки на ядовитых спецификациях патч исправляет только текст объяснения, не касаясь requirements.md, plan.md или validation.md.
Ask storm: Счётчик повторных уточняющих вопросов без получения новых данных. Агент не переходит к решению, создавая вид осторожности вместо реального продвижения.
Stage regress: Откат на предыдущую фазу SDD-цикла без явной причины и записи. Приводит к дрейфу, когда проект имеет несколько полу-черновиков, ни один из которых не закрыт фактом.
Phase context loss: Потеря контекста между фазами: specify зафиксировал решение, plan его не унаследовал, implement начал с черновика, который никогда не проходил validation.md.
Файловый арбитраж без veto и tie-breaker: governance_protocol описан только как '2 approve из 3' без критического veto от Safety и детерминированного tie-breaker. Решения принимаются голосованием без учёта критических рисков.
Фиктивный [project script]: В спецификации упоминается команда вида python3 scripts/spec_ci/check_scope.py, но самого скрипта в репозитории нет. Проверка 'выполнена' подразумевается, а не наблюдается.
Голый kpi без парной контр-метрики: Целевая метрика (MTTR, coverage, auto_close_rate) без anti-Goodhart-метрики. Агент учится выполнять метрику любой ценой, реальное качество падает.
Дрейф validation.md после красного ci: После падения CI автор пуlla меняет порог или удаляет факт вместо исправления кода. Описание изменения — 'уточнили валидацию'.
Переключение между ярусами без бюджета: При падении local-coder весь трафик уходит в frontier-reviewer без budget_keeper. Дорогой ярус съедает дневную квоту за минуты.
Теневая спецификация без ttl и автора: QWEN.md содержит эвристику без автора, даты и доказательства. Применяется по аналогии к случаям, для которых не задумывалась.
Авто-ремедиация без manual review floor: Агент автоматически закрывает инциденты, метрики выглядят чистыми, но ручной проверки нет. Тихие сбои накапливаются без резервного механизма.
Готовность 25/25 как цель: Команда подтягивает все пункты модели готовности до зелёного авансом, без реальных evidence_ref. Шкала превращается в ритуал.
Генеалогия без актуализации: change_log конституции устарел, между тем правил изменилось несколько. Провенанс перестаёт работать как доказательная цепочка.
След без evidence ref: Логи действий сохраняются, но без ссылок на spec_version, constitution_version, prompt_hash. audit_trace_coverage стремится к 100%, но след бесполезен.
Anti-goodhart-метрика: Парная метрика, защищающая целевую от манипуляции. К MTTR — silent_p0_ratio и manual_review_floor; к coverage — mutation_kill_rate.
Три поля диагностической карты: blocker, owner, next_check — минимальный фрагмент для зачёта. Если отрицательные ответы превращены только в общие советы, карта не выполнила свою функцию.
Бюджетный потолок яруса: Максимальный лимит токенов для яруса. При превышении — защищённый режим до восстановления базового яруса.
Важные даты: Квартальный аудит: Рекомендуемый срок для проверки, менялся ли порог метрики более двух раз
Пересмотр mutable-правила: Первый пересмотр — 30-90 дней с момента создания
Ttl теневая спецификация: Срок действия эвристики в QWEN.md до автоматического карантина
Практические упражнения: Название: Аудит готовности конституции
Проблема: Откройте текущий constitution.md вашей команды и проверьте mutable_rules на наличие ttl и rollback_condition. Найдите минимум одно правило, которое нужно либо обновить, либо отправить в карантин. Создайте запись в antipattern-audit.md с одной строкой blocker/owner/next_check для конкретного правила.
Решение: 1. Откройте constitution.md и найдите секцию mutable_rules. 2. Для каждого правила проверьте: есть ли ttl (в днях, не годах), есть ли rollback_condition (проверяемый предикат). 3. Если ttl отсутствует или ∞ — это blocker. 4. Определите owner (кто отвечает за это правило). 5. Установите next_check (когда проверить повторно, минимум 30 дней). 6. Запишите в antipattern-audit.md: | ready_without_ttl | platform | пересмотреть через 60 дней или отправить в карантин |. 7. Если правило не сработало ни разу за период жизни — кандидат на удаление.
Сложность: intermediate
Название: Анализ пулл-реквеста с validation.md
Проблема: Возьмите последний PR с правкой validation.md. Определите, что менялось — порог или содержание факта. Если порог, проверьте, есть ли в описании изменения ссылка на пост-мортем или идентификатор инцидента. Зафиксируйте исход: обоснованное изменение контракта риска или антипаттерн 'дрейф validation.md после красного CI'.
Решение: 1. Найдите последний PR, изменивший validation.md. 2. Определите тип изменения: (а) порог (threshold) — опасный сигнал, (б) содержание факта — может быть нормой. 3. Если менялся порог: (а) есть ссылка на инцидент/пост-мортем — обоснованное изменение, (б) нет ссылки или комментарий 'временно' — это антипаттерн. 4. Для антипаттерна: кто owner? кто должен был проверить? Когда следующий check? 5. Зафиксируйте в antipattern-audit.md. 6. Если изменение обосновано — убедитесь, что оно прошло отдельное ревью как изменение контракта риска.
Сложность: intermediate
Название: Верификация [project script]-блоков
Проблема: Пройдите по списку [project script]-блоков в одной выбранной главе (главы 8-11) и сверьте, какие команды реальны, а какие — интерфейс 'реализуйте сами'. Дополните README главы пометками.
Решение: 1. Выберите главу (например, главу 8). 2. Найдите все блоки [project script]. 3. Для каждого: (а) существует ли файл по указанному пути? (б) если существует — это runnable-аналог, (в) если нет — это интерфейс. 4. Определите runnable-команды: проверьте, что скрипт проходит python3 scripts/... или эквивалент. 5. Для фиктивных скриптов: (а) завести тикет с фиксированной датой реализации, (б) пометить в README 'реализуйте сами'. 6. Зафиксируйте результаты в antipattern-audit.md.
Сложность: intermediate
Название: Калибровка метрик
Проблема: Найдите в validation.md минимум две целевых метрики (KPI). Проверьте, есть ли для каждой парная anti-Goodhart-метрика. Если пары нет — добавьте рекомендацию в аудит.
Решение: 1. Откройте validation.md. 2. Найдите метрики: MTTR, coverage, auto_close_rate и подобные. 3. Для каждой проверьте наличие парной: (а) MTTR → silent_p0_ratio + manual_review_floor, (б) coverage → increase_in_incident_severity, (в) auto_close_rate → false_negative_rate. 4. Если пары нет — это антипаттерн 'голый KPI'. 5. Определите owner (кто добавит парную метрику). 6. Зафиксируйте: | KPI_without_counter_metric | devex | добавить anti-Goodhart к следующему спринту |.
Сложность: advanced
Название: Полный диагностический аудит
Проблема: Выберите один артефакт из глав 8-11 (judgment.md, validation.md, budget_network.yaml или readiness-таблицу). Проведите полный аудит по 12-вопросному диагностическому чек-листу. Зафиксируйте ответы (yes/no/not_applicable), для каждого 'no' — blocker, owner, next_check.
Решение: 1. Выберите артефакт и не расширяйте область проверки. 2. Подготовьте диагностический чек-лист. 3. Ответьте на 12 вопросов, каждый с короткой ссылкой на файл или evidence. 4. Для каждого 'no': (а) определите антипаттерн, (б) owner, (в) next_check. 5. Минимум три записи в итоговой таблице. 6. Запишите в antipattern-audit.md или retrospective.md. 7. Не исправляйте проблемы в этом же файле — сначала должен быть виден диагноз.
Сложность: advanced
Кейсы: Название: Аудит SDD-пакета маркетплейса: от хаоса к порядку
Сценарий: Команда разработки маркетплейса работает с SDD-процессом полгода. Production-контур стал шумным: CI иногда 'зелёный', но инциденты возвращаются. После каждого инцидента команда добавляет новые правила в constitution.md, но они не работают — агент продолжает выполнять опасные операции. При этом артефакты формально в порядке: есть requirements.md, validation.md со шлюзами, judgment.md с вердиктами.
Задача: Необходимо понять, почему формально правильная система не ловит регрессии. Первый поверхностный анализ показал: около 40 правил в mutable_rules, но ни одного с ttl. В validation.md прописаны MTTR<=5m и coverage>=80%, но парных метрик нет. Файловый арбитраж работает по принципу '2 approve из 3', но role Safety не имеет veto. Между фазами контекст теряется: plan наследует старую версию requirements.md, implement работает с черновиком, который никогда не проходил validation.md.
Решение: Проведён диагностический аудит по 12 вопросам. Обнаружено 7 антипаттернов:Конституция как косметика — правила есть, но scripts/constitution/check.py не подключен к шлюзу. Создан Spec CI-шаг, проверяющий наличие вызова check.py перед любым merge. Mutable-правила с ttl: ∞ — 12 правил без срока пересмотра. Для каждого установлен ttl 60 дней и первый пересмотр через 30 дней. Голый KPI — MTTR без silent_p0_ratio. Добавлена парная метрика. Файловый арбитраж без veto — добавлен safety_veto: critical_risk и tie-breaker. Фиктивные [project script] — 3 команды из документации не существуют. Заведены тикеты с дедлайнами. phase_context_loss — введён project skill check_phase_handoff, проверяющий ссылки между фазами.
Результат: Через месяц после аудита: количество инцидентов на production снизилось на 35%. Время на разбор каждого инцидента сократилось в два раза — теперь есть trace с evidence_ref. Spec CI автоматически ловит отсутствие check.py и missing evidence_ref. Новая команда on-бординга использует диагностический чек-лист как чек-лист входа. Команда понимает, что SDD — это не про красивые документы, а про контракт риска, который проверяется автоматически.
Извлечённые уроки: Формально правильные документы без автоматических проверок — это косметика, а не контракт. Правило должно либо проверяться автоматически, либо быть явно помечено как 'инструкция, не шлюз'
Аудит должен занимать 15-30 минут на один артефакт. Если аудит расширяется на весь проект — это уже не аудит, а ревью. Фокус критически важен
Три поля blocker/owner/next_check — это минимум, а не максимум. Каждый отрицательный ответ на чек-лист должен превращаться в конкретное действие с владельцем и сроком
Связанные концепции: Диагностический блокер
Антипаттерн 'Конституция как косметика'
Голый KPI без парной контр-метрики
Файловый арбитраж без veto
Название: Восстановление контекста после stage_regress
Сценарий: Проект по внедрению системы авто-ремедиации прошёл через несколько фазовых откатов. Изначальная спецификация определяла manual_review_floor=15%. Однако после серии инцидентов plan был переписан три раза, каждый раз без фиксации причин. Implement начал работу с финального черновика plan, который содержал manual_review_floor=0%. validation.md также обновилась, но ссылалась на старую requirements.md. Через месяц команда не могла восстановить, кто и почему принял решение об исключении ручной проверки.
Задача: После деплоя система автоматически закрыла 200+ инцидентов без единой ручной проверки. Метрики выглядели великолепно: auto_close_rate=0.95, MTTR=3m. Однако при аудите обнаружилось, что модель пропустила класс новых инцидентов, который не видела в обучающей выборке. Поскольку manual_review_floor=0%, никто не заметил накопления тихих сбоев. Пришлось проводить ручной разбор всех 200+ инцидентов post-factum.
Решение: Введён mandatory-процесс для stage_regress: любой откат требует записи в genealogy.md с указанием причины и ссылки на инцидент/обсуждение. Spec CI блокирует merge, если plan.md содержит ссылки на несуществующие requirements.md. Auto-remediation теперь требует manual_review_floor>=15% независимо от значения auto_close_rate. Создан project skill, который при обнаружении stage_regress триггерит сообщение в канал с напоминанием о процедуре.
Результат: За последние 90 дней не было ни одного stage_regress без записи. Auto_remediation теперь имеет реальный floor — ручные проверки распределяются случайно, а не 'по сложности'. Тихие сбои ловятся вовремя: в среднем 2-3 случая в неделю попадают на ручное ревью и добавляются в обучающую выборку.
Извлечённые уроки: SDD-цикл без записей о переходах между фазами — это дрейф, а не процесс. Каждый шаг назад теряет контекст предыдущего
Auto-remediation без manual_review_floor — это передача контроля агенту, который оптимизирует метрики, а не пользовательский контракт
Метрики выглядят великолепно, когда нет человека, который проверяет их смысл
Связанные концепции: stage_regress без явной причины
Авто-ремедиация без минимума ручной проверки
phase_context_loss между фазами
Название: Эскалация 'QWEN.md как свалка' в production
Сценарий: Команда платформы ведёт QWEN.md полтора года. За это время туда попали сотни эвристик, few-shot-образцов,临时ных правил. При возникновении спорных ситуаций участники цитируют 'правила из QWEN', но никто не помнит, кто их добавил, когда, и на основании чего. Эвристика 'если инцидент похож на P0, но метрики зелёные — это P0' цитируется регулярно, хотя в последних 50 инцидентах она не сработала ни разу.
Задача: После крупного инцидента (сбой платёжной системы на 3 часа) выяснилось, что один из участников принял решение об откате на основании эвристики из QWEN.md, которая была добавлена 'когда-то кем-то' и нигде не задокументирована. История решений невоспроизводима. При разборе невозможно установить, кто и на основании чего рекомендовал то или иное действие.
Решение: Проведён обязательный аудит QWEN.md: для каждой записи требовались автор, дата, доказательство (ссылка на эксперимент или инцидент), ttl. Записи без ttl отправлены в карантин. Эвристика, не сработавшая в последних 50 инцидентах, удалена. Введено правило: любая новая эвристика проходит через процедуру аукциона — минимум три участника должны подтвердить её ценность до добавления. Spec CI проверяет наличие ttl и автора для каждой записи.
Результат: QWEN.md сократился с 340 записей до 89. Каждая оставшаяся запись имеет автора, дату, доказательство и ttl. Время на поиск релевантной эвристики сократилось на 70%. При спорных решениях теперь можно проследить provenance — кто рекомендовал и на основании чего.
Извлечённые уроки: Теневая спецификация без автора и ttl со временем приобретает силу контракта, которую невозможно оспорить и невозможно проверить
Количество записей в QWEN — это technical debt, а не покрытие знаний. Регулярная чистка обязательна
Эвристика без доказательства — это мнение, которое не должно ограничивать поведение агента
Связанные концепции: Теневая спецификация без срока пересмотра
След без пометки-доказательства
Генеалогия без актуализации
Советы по изучению: Читайте каталог антипаттернов как чек-лист, а не как словарь. Для первого прохода достаточно найти три антипаттерна или убедиться, что их нет — закрыть главу можно тремя строками blocker/owner/next_check
Не пытайтесь изучить все 17 антипаттернов за один раз. Сфокусируйтесь на тех, которые наиболее релевантны для вашего текущего проекта или артефакта
При прохождении диагностического чек-листа работайте с одним артефактом (judgment.md, validation.md или бюджетом). Расширение области проверки превращает аудит в многочасовое ревью
Помните: ваша цель — не исправить найденные проблемы, а зафиксировать диагноз. Исправления — это отдельные задачи с отдельными владельцами
Связывайте каждый антипаттерн с уже знакомыми концепциями первого тома. Если вы помните 'конституцию, которую никто не открывает', легче понять эскалацию 'конституция как косметика' в production
Практикуйтесь в парах: один проводит аудит, другой задаёт уточняющие вопросы. Это помогает увидеть слепые пятна и тренирует способность объяснять антипаттерны вслух
После каждого крупного инцидента возвращайтесь к этой главе и проводите повторный аудит того же артефакта. Тот же artifact через три месяца показывает уже другие три блокера
Заведите привычку проверять evidence_ref в каждой записи следа. Это мелочь, но без неё любой аудит post-factum превращается в детективное расследование
Если на три и больше вопросов диагностического чек-листа ответ отрицательный — не добавляйте новые слои автоматизации. Сначала уберите шум и закройте провалы в текущем контуре
Дополнительные ресурсы: Часть 20 первого тома: Базовые антипаттерны SDD: спецификация после кода, гигантский requirements.md, ритуальный /clear, QWEN.md как свалка
Часть 18 первого тома: Антипаттерны, которые одновременно являются угрозами безопасности
Часть 2: ядовитые спецификации: Тренировочный инструмент против большинства антипаттернов этой главы
Часть 9: ярусное бюджетирование: Подробнее о бюджетном потолке и failover между ярусами
Часть 10: anti-goodhart метрики: Защита от голого KPI через парные контр-метрики
Book2/examples/templates/retrospective.md: Шаблон для короткой записи вывода диагностического аудита
Appendix-c-checklists.md: Обновлённый диагностический чек-лист
Приложение d.4: Защита метрик от Гудхарта — калибровка порогов
Резюме: Прикладная часть 12 представляет диагностическую карту для аудита production SDD-контура. Ключевая идея: артефакты есть, проверки есть, агент работает быстро, но контроль над системой постепенно уходит. Каталог из 17 антипаттернов (часть — эскалации из первого тома, часть — уникальны для прикладного цикла) разбирается по схеме Симптом → Почему плохо → Как исправить. Минимальный учебный сценарий: выбрать один артефакт, ответить на 12 вопросов диагностического чек-листа, для каждого 'no' зафиксировать blocker/owner/next_check. Цель — не выучить названия, а провести 15-30-минутный аудит и получить три діагностичні строки. Опасность — не антипаттерны по отдельности, а их накопление: через несколько релизов команда не видит контракта риска за 'зелёным CI'. Антипаттерны прикладного цикла не катастрофичны по отдельности. Опасно их накопление: через несколько релизов команда не видит контракта риска за «зелёным CI». Диагностическая карта — это первый шаг к ремонту. Возвращайтесь к этой главе после каждого крупного инцидента.