Прикладная часть 12. Антипаттерны production SDD: диагностическая карта прикладного цикла

Статус: Рекомендация. Часть собирает антипаттерны, которые возникают именно в прикладном цикле: при дуэлях, файловом арбитраже, Spec CI, ярусных бюджетах, anti-Goodhart-метриках и авто-ремедиации. Они продолжают линию части 20 первого тома: артефакты есть, проверки есть, агент быстро работает, но контроль над системой постепенно уходит.

Эта часть нужна как диагностическая карта прикладного тома. Если production-контур стал шумным, противоречивым или защищает собственную скорость в ущерб пользователю, начните отсюда.

Перед чтением

• Опора из первого тома: часть 20 показывает базовые антипаттерны SDD.
• Локальный учебный кейс: любой уже созданный артефакт из глав 8–11.
• След для capstone/: три строки blocker / owner / next_check для выбранного high_memory_usage-пакета.
• Главный термин первого прохода: диагностический блокер. Названия отдельных антипаттернов — справочные, читать их подряд не нужно.
• Что отложить: превращение каждого антипаттерна в автоматическую CI-политику.

Цель

Цель главы — не выучить список названий, а провести короткий аудит уже собранного production SDD-пакета. После главы у вас должны быть три диагностические строки: что блокирует допуск, кто отвечает за исправление и когда это снова проверяется.

Для первого прохода читайте эту главу как чек-лист, а не как словарь всех возможных сбоев. Каталог ниже нужен, чтобы распознать найденную проблему; закрыть главу можно тремя строками blocker / owner / next_check.

Эскалации антипаттернов первого тома

Часть антипаттернов этого каталога — не новые, а production-варианты тех, что описаны в части 20 первого тома. Разница в масштабе: в учебном цикле базовый антипаттерн сжигает день работы, в прикладном — открывает класс инцидентов на живом сервисе.

| Теневая спецификация без срока пересмотра | «QWEN.md как свалка» — память без ttl и автора | | След без пометки-доказательства | «Факты на словах» — отсутствие evidence_ref |

Если вы прошли часть 20 первого тома, эти записи можно читать выборочно — здесь только то, что добавляет production-контекст. Остальные 12 антипаттернов этой главы появляются только в прикладном цикле (дуэли, арбитраж, бюджеты, anti-Goodhart, авто-ремедиация) и в томе 1 не разбираются.

Минимальный учебный сценарий

Учебный кейс

Перед итоговым зачётом нужно проверить один production SDD-контур на шум. Выберите любой пакет из глав 8–11: judgment.md, validation.md, budget_network.yaml или readiness-таблицу. Цель — найти не меньше трёх антипаттернов или явно доказать, что их нет.

Подготовка

• Диагностический чек-лист ниже.
• book2/examples/templates/retrospective.md — форма для короткой записи вывода.
• Один артефакт, который уже прошёл через runnable-пример или ручной учебный сценарий.

Шаги

1. Выберите один артефакт и не расширяйте область проверки. Ожидание: аудит занимает 15–30 минут, а не превращается в ревью всего проекта.

1. Ответьте на 12 вопросов чек-листа. *Ожидание: каждый ответ — yes, no или not_applicable с короткой ссылкой на файл.*
2. Для каждого no укажите антипаттерн, владельца и срок исправления.
3. Найдите хотя бы один [project script] в выбранной главе и проверьте, помечен ли он как runnable-аналог или интерфейс «реализуйте сами».
4. Запишите итог в antipattern-audit.md или в ретроспективу: что блокирует production-допуск, что можно оставить как улучшение.

Контрольный факт

Есть список из трёх пунктов: blocker, owner, next_check. Если отрицательные ответы превращены только в общие советы, диагностическая карта не выполнила свою функцию.

Как это попадает в capstone/

Перенесите в capstone/antipattern-audit.md три строки blocker / owner / next_check. Не исправляйте эти проблемы в том же файле без отдельной записи: для зачёта важно увидеть диагноз и следующий контроль, а не красивый итог без истории.

Минимальный фрагмент:

| blocker | owner | next_check |
|---|---|---|
| readiness без `evidence_ref` | platform | повторить dry-run с ссылкой на fixture |

| `[project script]` без runnable-аналога | devex | заменить на `examples/real-api` или реализовать скрипт |
| `manual_review_floor` не указан | sre | добавить guard-метрику до auto-mode |

Ревьюируемый след

Сохраняйте antipattern-audit.md, если аудит относится к учебному пакету или capstone/. Не исправляйте найденные проблемы в том же изменении без отдельной записи: сначала должен быть виден диагноз, потом лечение.

Ключевые идеи

Каждый антипаттерн ниже разбирается по одной схеме из трёх полей: Симптом — что наблюдается в артефактах и логах, Почему плохо — как это меняет поведение команды или агента, Как исправить — минимальные шаги до состояния, в котором симптом ловится автоматически.

Каталог можно читать в любом порядке: каждая запись самостоятельна и держится тех же трёх полей. Записи не альтернативные — это разные классы шума, которые часто встречаются вместе. Если в одном production-пакете нашлись три и больше антипаттернов, читайте их как сцеплённую сеть проблем с общим корнем в потерянном контракте риска.

Примеры и применение

Конституция как косметика

> Эскалация антипаттерна из тома 1. Базовая версия — «конституция, которую никто не открывает» из части 20 первого тома. В прикладном цикле та же ошибка ведёт не к плохому коду, а к выполненной опасной операции.

Симптом: в репозитории есть constitution.md с immutable_principles и mutable_rules, но шлюз перед опасными действиями не запускается. В judgment.md есть ссылка на правило forbid_unscoped_delete, в логах команды (logs/auto-remediation.jsonl) нет ни одного вызова scripts/constitution/check.py. За последние 30 дней — ноль срабатываний шлюза.

Почему плохо: правила формально есть, но не ограничивают агента в момент давления. Через несколько инцидентов команда начинает считать конституцию декорацией. На разборе следующего инцидента всплывёт характерная фраза: «правило-то было, просто никто не проверял» — это сигнал, что конституция работала как комментарий, а не как контракт.

Как исправить:

• подключать constitution.md к проверкам шлюза до выполнения плейбука (см. часть 3);
• любую опасную операцию пропускать через scripts/constitution/check.py или эквивалент в CI;

• в judgment.md фиксировать ссылку на версию конституции и decision_hash;
• если правило не проверяется автоматически, переносить его из immutable_principles в плейбук и явно помечать как «инструкция, не шлюз»;
• проверять, что за последние 30 дней есть хотя бы один лог, где шлюз сработал и заблокировал действие. Ноль срабатываний за квартал — либо конституция не подключена, либо описывает несуществующие риски.

Mutable-правило с ttl: ∞

Симптом: в mutable_rules есть правило без ttl, или ttl стоит сразу на годы. rollback_condition отсутствует или сформулирован как «по решению команды».

Почему плохо: правило живёт бессрочно и со временем превращается в скрытую часть инварианта. Через год участники не помнят, зачем оно появилось, и боятся его трогать. Поправка применяется по аналогии к ситуациям, для которых не задумывалась.

Как исправить:

• задавать ttl в днях, а не годах; первый пересмотр — 30–90 дней (см. эталонный ответ в INSTRUCTOR.md);
• rollback_condition формулировать как проверяемый предикат: repeat_incidents_same_node>=2, silent_p0_ratio>0.05, safety_veto=true;

• по истечении ttl блокировать применение правила до явного продления через референдум;
• удалять правила, которые не сработали ни разу за период жизни.

Ядовитая спецификация без diff в артефактах

> Эскалация антипаттерна из тома 1. Базовая версия — «спецификация после кода» из части 20 первого тома: объяснение меняется, а артефакт — нет. Здесь та же ошибка проявляется в обратной задаче (восстановление спецификации) — патч лечит комментарий, а не первопричину.

Симптом: команда тренирует восстановление спецификации на ядовитых спецификациях (см. часть 2), но патч меняет только текст объяснения или комментарий. requirements.md, plan.md, validation.md остаются прежними.

Почему плохо: упражнение перестаёт учить локализации причины. Через неделю тот же класс ядовитой спецификации проходит снова — патч не закрыл первопричину.

Как исправить:

• в done-criteria урока требовать diff минимум в одном артефакте (requirements.md, plan.md, validation.md, constitution.md) — не только в объяснении;
• проводить полный обратный прогон Specify → Plan → Tasks → Implement после исправления;

• если патч меняет только текст объяснения, отправлять на пересдачу;
• регистрировать класс контролируемо дефектной спецификации в precedents.md, чтобы следующий аналогичный дефект ловился автоматически.

ask_storm под видом аккуратности

Симптом: агент в цикле задаёт уточняющие вопросы и не переходит к решению. Контрольная строка: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false (ask_storm — счётчик повторных уточнений без новых данных).

Почему плохо: вопросы выглядят как осторожность, но это сигнал внутреннего противоречия в спецификации. Каждый ответ человека на ходу добавляет новую формулировку, которая нигде не закрепляется и при следующем /clear исчезает.

Как исправить:

• останавливать сессию после третьего подряд уточнения и проверять requirements.md на противоречия;
• разбирать спецификацию как ядовитую (часть 2) — один дефект, поиск первопричины;
• ответы фиксировать не в чате, а в requirements.md или clarifications.md;
• не превращать вопросы агента в продолжающийся диалог: каждое уточнение должно либо закрыть пункт спецификации, либо вернуться в её правку.

stage_regress без явной причины

Симптом: фаза implement возвращается в plan, фаза plan — в specify без записи о причине. На следующий день никто не помнит, почему план переписан. (stage_regress — откат на предыдущую фазу SDD-цикла без явной причины.)

Почему плохо: SDD-цикл превращается в дрейф. Каждый шаг назад теряет контекст предыдущего, и через неделю проект имеет три полу-черновика плана, ни один из которых не закрыт фактом в validation.md.

Как исправить:

• фиксировать переход между фазами явно: ревьюируемая запись изменения, запись в genealogy.md, причина;
• запрещать откат на предыдущую фазу без обновления хотя бы одного факта в validation.md;
• использовать project skill, который при git status показывает, какая фаза текущая и какие факты ещё не закрыты;
• если откат повторяется чаще раза в день — это сигнал, что спецификация мала, а не процесс шумит.

phase_context_loss между фазами

Симптом: specify зафиксировал решение, plan его не унаследовал, implement начал с черновика, который никогда не проходил validation.md. (phase_context_loss — потеря контекста между фазами.)

Почему плохо: каждый шаг работает с собственной картиной мира. Через два-три перехода они расходятся настолько, что артефакты противоречат друг другу, и любая проверка тривиально проходит — она проверяет не то.

Как исправить:

• между фазами передавать только ссылки на файлы (@specs/...), а не пересказ из чата;
• ввести проектный навык check_phase_handoff, который проверяет, что план ссылается на действующий requirements.md, а реализация — на действующий план;
• после /clear начинать новую фазу с прочтения QWEN.md, актуального requirements.md и текущего plan.md;
• если фаза не может объяснить, какой пункт предыдущей фазы она реализует — возвращаться к ней до правки кода.

Верификатор превращается в обычный code review

Симптом: Верификатор пишет комментарии вида «стиль не очень», «лучше переименовать», «давайте обсудим». Конкретного контрпримера, ссылки на правило или нарушения JSON Schema нет.

Почему плохо: дуэль теряет процедурный характер. Верификатор перестаёт быть формальным контуром и становится ещё одним мнением. Имплементор отвечает свободным текстом, и спор уходит в чат, где его невозможно воспроизвести.

Как исправить:

• запрещать Верификатору любые суждения без конкретного артефакта: контрпример с минимальностью, лог hook'а, JSON Schema, Given/When/Then;
• репликация вердикта должна быть локальной: другой человек по тому же cases/ и metrics/ получает тот же judgment.md;
• если Верификатор не нашёл контрпример — фиксировать verdict=APPROVE и переходить дальше, а не продолжать обсуждение в общих формулировках;
• стилистические замечания выносить в отдельный канал ревью, не смешивая с дуэлью.

Файловый арбитраж, в котором голосует только большинство

Симптом: governance_protocol описан как «2 approve из 3», без veto от Safety и tie-breaker. При равном счёте система зависает или принимает решение по дате созыва.

Почему плохо: роль Safety теряет смысл. Решения принимаются голосами Верификатора и Имплементора, которые оптимизируют скорость; критичные риски проходят как «приемлемые».

Как исправить:

• ввести safety_veto: critical_risk для роли Safety;
• задать tie_breaker: safety_first_then_latest_matching_precedent;
• проверять governance_protocol шлюзом Spec CI: отсутствие tie-breaker и veto блокирует merge;

• каждое отклонение по veto от Safety фиксировать в precedents.md со ссылкой на immutable-правило, чтобы повторный аналогичный спор закрылся быстрее.

Фиктивный [project script]

Симптом: в спецификации, чек-листе или главе обучения используется команда вида python3 scripts/spec_ci/check_scope.py, но самого скрипта в репозитории нет. Никто его не запускал, факт «проверка прошла» подразумевается, а не наблюдается.

Почему плохо: появляется ложное чувство контроля. CI выглядит строгим, но проверка не выполняется. Через несколько недель команда забывает, какие скрипты реальные, а какие — интерфейс.

Как исправить:

• рядом с каждым [project script]-блоком явно говорить, есть ли запускаемый аналог в examples/ или это интерфейс «реализуйте сами»;
• в Spec CI отдельный шаг проверяет, что упомянутые в validation.md команды действительно существуют (test -x path/to/script);
• учебные главы помечают [runnable] только для команд, которые проходят локальный python3 scripts/...;
• если скрипт нужен, но его нет — заводить тикет с фиксированной датой реализации, а не оставлять как «потом».

Голый KPI без парной контр-метрики

Симптом: в validation.md есть целевая метрика (MTTR<=5m, coverage>=80%, auto_close_rate>=0.9), но нет парных контр-метрик (guard-метрик). Шлюз CI проходит, когда KPI выполнен.

Почему плохо: классический Гудхарт. Агент или команда учится выполнять метрику любой ценой: закрывать сложные инциденты как лёгкие, маркировать P0 как P2, обходить ручное ревью. Метрика растёт, реальное качество падает.

Как исправить:

• каждой целевой метрике ставить в пару anti-Goodhart-метрику (см. часть 10): к MTTR — silent_p0_ratio и manual_review_floor; к coverage — mutation_kill_rate;
• шлюз проходит только при одновременном выполнении пары;
• любое изменение порога — событие риска, а не косметическая правка YAML; фиксируется с обоснованием;
• регулярно прогонять реплей по историческим инцидентам: новая версия не должна ухудшать вердикты на разобранных кейсах.

Дрейф validation.md после красного CI

Симптом: CI упал, после чего автор пулл-реквеста меняет порог или удаляет факт в validation.md вместо правки кода. Описание изменения — «уточнили валидацию».

Почему плохо: процесс начинает защищать реализацию, а не контракт пользователя. Это та же ошибка, что и «ослабление фактов после ошибки» из части 20 первого тома, но в прикладном масштабе: ослабление порога silent_p0 с дефолтного 0.05 (AgentClinic baseline, см. Приложение D.4) до 0.10 за один пулл-реквест сдвигает целый класс рисков.

Как исправить:

• любую правку validation.md, которая ослабляет проверку, ревьюить отдельно как изменение контракта риска;
• в описании изменения фиксировать причину: идентификатор инцидента, ссылку на пост-мортем, ожидаемый эффект;
• запрещать удаление обязательных фактов без записи в precedents.md;
• если порог менялся за последний квартал больше двух раз — это сигнал, что цель и проверка живут раздельно.

Переключение между ярусами без бюджета

Симптом: при падении local-coder весь трафик автоматически уходит в frontier-reviewer. budget_keeper (хранитель бюджета) не настроен или не блокирует превышение.

Почему плохо: дорогой ярус за минуты съедает дневную квоту и теряет способность обслуживать настоящие P0/P1, когда они придут. Переключение при отказе (failover) превращается в источник вторичного инцидента.

Как исправить:

• описывать переключение как ранжированное, а не тотальное (см. часть 9);
• в frontier-reviewer отправлять только задачи с severity in [P0, P1] и age > N;
• остальное — в очередь деградации, после тайм-аута — в ручной канал;
• аварийный режим срабатывает по token_health и переводит систему в защищённый режим до восстановления local-coder.

Теневая спецификация без срока пересмотра

> Эскалация антипаттерна из тома 1. Базовая версия — «QWEN.md как свалка» из части 20 первого тома. В учебном цикле проблема — растущий контекст; в прикладном — эвристика без автора получает силу контракта.

Симптом: QWEN.md содержит образец-подсказку (few-shot) или эвристику, которая попала туда «как-то само собой». Автор не помнит, кто и когда её добавил. У записи нет ttl, доказательств или ссылки на оценку.

Почему плохо: эвристика приобретает силу контракта без процедуры пересмотра. Её нельзя оспорить (никто не помнит автора) и нельзя точно проверить (нет источника). Через полгода правило применяется по аналогии к случаям, для которых не задумывалось.

Как исправить:

• любую эвристику в QWEN.md оформлять с минимальной шапкой: автор, дата, доказательство, ttl, ссылка на аукцион (см. часть 6);
• по истечении ttl — либо обновлять, либо отправлять в карантин с записью причины;
• образцы-подсказки, которые не сработали в последних 50 инцидентах, считать кандидатами на удаление;
• теневая спецификация не заменяет approved-требование — она только направляет prompt в неоднозначных случаях.

Авто-ремедиация без минимума ручной проверки

Симптом: агент автоматически закрывает инциденты на основании метрик. manual_review_floor не задан или равен нулю.

Почему плохо: даже если метрики выглядят чисто, агент постепенно вытесняет человека из контура. При появлении класса инцидентов, который модель не видела, нет резервного механизма заметить отклонение. Через несколько недель тихие сбои накапливаются, потому что их некому ловить.

Как исправить:

• задавать manual_review_floor явно: например, «не менее 15% инцидентов проходят через человека независимо от метрик»;
• ротация выбирается случайно, а не по принципу «оставим людям самое сложное» — иначе ручное ревью не видит базового уровня;
• результаты ручного ревью попадают в реплей-набор для следующего прогона валидатора;
• любое снижение manual_review_floor проходит как изменение контракта риска, а не как оптимизация.

Готовность 25/25 как цель, а не как описание

Симптом: команда подтягивает все 25 пунктов модели готовности до зелёного, потому что «надо выпустить». Часть пунктов выставлена авансом, без реальной пометки-доказательства.

Почему плохо: готовность теряет смысл как ранний сигнал. На следующем релизе всё снова «25/25», но инциденты возвращаются. Шкала превращается в ритуал.

Как исправить:

• проверять готовность через evidence_ref, а не через текстовое утверждение;
• 23/25 с реальными доказательствами — это допуск; 25/25 без доказательств по двум пунктам — не допуск;
• при невыполнении пункта явно фиксировать риск и условие отката, а не «закрашивать в зелёный»;

• регулярно прогонять готовность в обратную сторону: какой пункт сработал и поймал реальную проблему, какой за квартал не сработал ни разу — кандидат на пересмотр.

Генеалогия без актуализации

Симптом: genealogy.md или change_log конституции существует, но последняя запись датирована тремя месяцами раньше. Между тем правил изменилось пять.

Почему плохо: провенанс перестаёт работать как доказательная цепочка. Через полгода восстановить «почему агент имел право выполнить это действие» невозможно, и спор после инцидента уходит в общую дискуссию.

Как исправить:

• запись в change_log — обязательная часть каждой поправки конституции, без неё шлюз не пропускает merge;
• parent_version обязателен; пропуск версии — повод для отдельного ревью;
• decision_hash рассчитывается автоматически из содержимого решения, чтобы подмена не прошла молча;
• ежемесячно — короткий аудит: сверка change_log с реальными правками файла. Расхождение фиксируется как инцидент процесса.

След без пометки-доказательства

> Эскалация антипаттерна из тома 1. Базовая версия — «факты на словах» из части 20 первого тома. В учебном цикле след не нужен, потому что фича маленькая. В прикладном без evidence_ref нельзя восстановить, на каком основании выполнено действие.

Симптом: агент сохраняет логи действий, но в записях нет ссылок на исходные артефакты: какая версия спецификации применялась, какие правила конституции, какой prompt. После инцидента восстановить контекст решения невозможно.

Почему плохо: audit_trace_coverage (покрытие аудит-трейса) формально близок к 100%, но след бесполезен. Это та же ошибка, что и validation.md, который никто не запускал, но на уровне аудита.

Как исправить:

• в каждой записи следа обязательны spec_version, constitution_version, prompt_hash, decision_source, evidence_ref;
• Spec CI проверяет полноту полей и блокирует merge, если хотя бы один из них пустой;
• evidence_ref — это путь и идентификатор внутри артефакта (logs/node-2026-05-12.parquet#row_4123), не общая ссылка на каталог;
• любая запись с evidence_ref=null считается недействительной для аудита.

Диагностический чек-лист

Если прикладной SDD-контур стал шумным или перестал ловить регрессии, ответьте:

1. Срабатывает ли constitution.md как шлюз до выполнения, а не только как ревью после?
2. Есть ли в mutable_rules правила без ttl или с ttl больше 90 дней?
3. После провала ядовитой спецификации меняется ли хотя бы один артефакт (requirements.md, plan.md, validation.md)?
4. Использует ли Верификатор контрпример, лог hook'а или JSON Schema — или только свободный текст?
5. Есть ли в governance_protocol veto от Safety и детерминированный tie-breaker?
6. Помечены ли в репозитории запускаемые команды отдельно от [project script]-интерфейсов?
7. Сопровождает ли каждую целевую метрику парная anti-Goodhart-метрика?
8. Когда CI падает, чинят код или ослабляют validation.md?
9. Есть ли у переключения между ярусами бюджетный потолок и аварийный режим?
10. Каждая запись в QWEN.md имеет автора, доказательство и ttl?
11. Сохраняется ли manual_review_floor независимо от значения KPI?
12. Заполнен ли evidence_ref в каждой записи следа?

Если на три и больше вопросов ответ отрицательный — не добавляйте новые слои автоматизации: файловый арбитраж, ярусную маршрутизацию, новые правила аварийного режима. Сначала уберите шум и закройте провалы в текущем контуре.

Итог

Антипаттерны прикладного цикла не катастрофичны по отдельности. Опасно их накопление: через несколько релизов команда не видит контракта риска за «зелёным CI». Диагностическая карта — это первый шаг к ремонту. Каждый отрицательный ответ превращается в проектный навык, шлюз Spec CI или правило конституции с проверяемым rollback_condition. Возвращайтесь к этой главе после каждого крупного инцидента: тот же артефакт через три месяца показывает уже другие три блокера.

Связанные части первого тома

• Часть 20 первого тома — базовые антипаттерны SDD: спецификация после кода, гигантский requirements.md, ритуальный /clear, QWEN.md как свалка.
• Часть 18 первого тома — антипаттерны, которые одновременно являются угрозами безопасности.
• Часть 2 — ядовитые спецификации как тренировочный инструмент против большинства антипаттернов этой главы.

• Часть 10 — anti-Goodhart как защита от голого KPI.

Артефакты и критерии готовности

Полный трек добавляет обновлённый диагностический чек-лист в [appendix-c-checklists.md](appendix-c-checklists.md), записи в precedents.md для каждого встречавшегося антипаттерна, дополнения в QWEN.md для повторяющихся и проверку Spec CI хотя бы для одного из них. Считайте его готовым, если в Spec CI есть хотя бы одна проверка, ловящая антипаттерн автоматически (например, mutable_rules без ttl), а повторяющиеся антипаттерны попадают в precedents.md или QWEN.md только с доказательством и сроком пересмотра.

Практика

1. Откройте текущий constitution.md команды и проверьте mutable_rules на наличие ttl и rollback_condition. Найдите минимум одно правило, которое нужно либо обновить, либо отправить в карантин. *Ожидание: в antipattern-audit.md появилась одна строка blocker / owner / next_check для конкретного правила; срок ttl задан в днях, не годах.*
2. Возьмите последний пулл-реквест с правкой validation.md. Определите, что менялось — порог или содержание факта. Если порог, проверьте, есть ли в описании изменения ссылка на пост-мортем или идентификатор инцидента. *Ожидание: для пулл-реквеста зафиксирован один из двух исходов — либо обоснованное изменение контракта риска со ссылкой на инцидент, либо антипаттерн «дрейф validation.md после красного CI» с владельцем и сроком отката.*
3. Пройдите по списку [project script]-блоков в одной выбранной главе и сверьте, какие команды реальны, а какие — интерфейс. Дополните README главы пометками. *Ожидание: для каждого [project script] явно указано «есть runnable-аналог в examples/...» или «реализуйте сами»; нет блоков без пометки.*

Контрольные вопросы

1. Почему mutable-правило с ttl: ∞ опаснее, чем правило без формулировки вообще?
2. Чем ask_storm отличается от добросовестных уточнений и как отличить одно от другого?
3. Какие три поля делают запись следа пригодной для аудита, и почему audit_trace_coverage=100% без них — Гудхарт-метрика?
4. На ревью пулл-реквеста вы видите, что автор изменил порог silent_p0 с 0.05 до 0.10 и добавил комментарий «временно, до стабилизации». Что вы сделаете с этим пулл-реквестом и какие три условия должны быть выполнены, прежде чем такое изменение можно слить?