Тема: Прикладная часть 8. Файловый арбитраж спорного изменения: роли, вердикты и прецеденты
Уровень сложности: Средний
Расчётное время изучения: 2-3 часа
Предварительные требования: Знание принципов командного ревью (Часть 16 первого тома)
Понимание механизмов LLM-дуэлей и работы с контрпримерами
Базовые навыки работы с CLI (запуск Python-скриптов)
Понимание структур данных YAML и JSON
Цели обучения: Понимать различие между LLM-дуэлью и файловым арбитражем (вопросы поиска дефектов vs. вынесения официального вердикта).
Настроить и запустить минимальный учебный сценарий арбитража с использованием скриптов run_duel.py, check_invariants.py и write_judgment.py.
Формировать корректные записи в judgment.md с использованием строгих доказательств (evidence_ref).
Создавать записи в precedents.md для документирования повторяющихся спорных ситуаций.
Применять правило anti-Goodhart для защиты системы от оптимизации метрик за счет скрытых рисков (silent failures, rollback-flapping).
Обзор: Файловый арбитраж превращает разрешение споров по изменениям кода из субъективного обмена мнениями в чате в формализованную, воспроизводимую цепочку доказательств. В этой системе работают четкие роли: Координатор управляет процессом, Имплементор предлагает изменения, Верификатор проверяет их по формальным критериям, а Safety налагает вето при критических рисках. Итогом арбитража становятся артефакты проекта: judgment.md (журнал решений с доказательствами) и precedents.md (база знаний повторяющихся споров). Подход спроектирован так, чтобы вердикт не зависел от конкретной модели ИИ (что проверяется через ротацию ярусов), а спецификация оставалась главным источником истины.
Ключевые концепции: Файловый арбитраж: Коллективная проверка спорного изменения несколькими ролями, где результат фиксируется в виде файлов (артефактов), а не в истории чата.
Роли арбитража: Координатор (ведет протокол, не голосует), Имплементор (предлагает изменения), Верификатор (проверяет формальные критерии), Safety (блокирует критические риски через вето).
Judgment.md: Журнал решений по спорам. Должен содержать вердикт (APPROVE/DENY/DEFERRED), причину и evidence_ref — доказательство из файла, а не пересказ из чата.
Precedents.md: Журнал прецедентов для повторяющихся споров. Содержит стабильный идентификатор, вердикт, доказательство, границы применимости и условие для пересмотра (next_check).
Evidence ref: Строгая ссылка на доказательство (лог хука, различие в diff, JSON Schema, сценарий Given/When/Then). Верификатор не принимает аргументы без evidence_ref.
Ротация ярусов (tier rotation): Тестирование одной и той же спецификации на разных парах агентов (например, дешевая локальная модель + дорогая облачная). Выявляет зависимость вердикта от конкретного ИИ.
Anti-goodhart инварианты: Защитный механизм арбитража, запрещающий улучшать одну метрику (например, MTTR) за счет деградации других (рост false_escalation_rate, rollback-flapping, silent_p0).
Decision trace: Воспроизводимый фазовый протокол решения, описывающий извлеченные факты, проверки красных флагов, примененную политику и итоговый вердикт.
Практические упражнения: Название: Запуск учебного runnable-кейса autoscale_200pct
Проблема: Необходимо провести файловый арбитраж для спецификации autoscale_spec.yaml. Требуется запустить дуэль, проверить anti-Goodhart инварианты и сгенерировать итоговый журнал решений.
Решение: 1. Перейдите в каталог примера: cd book2/examples/tribunal. 2. Запустите скрипт дуэли: python3 scripts/run_duel.py --spec specs/autoscale_spec.yaml --cases cases/ --out out/duel.json. 3. Запустите проверку инвариантов: python3 scripts/check_invariants.py --metrics metrics/validation_metrics.json --out out/invariants.json. 4. Сгенерируйте вердикт: python3 scripts/write_judgment.py --duel-out out/duel.json --invariants-out out/invariants.json --to out/judgment.md.
Сложность: beginner
Название: Перенос конфликта в базу прецедентов
Проблема: В ходе разбора autoscale_200pct выявлен повторяющийся конфликт: автоматический режим требует audit_trace_coverage=1.0, но текущее значение 0.7. Нужно задокументировать этот прецедент.
Решение: Откройте файл precedents.md и добавьте YAML-структуру: case_id: PREC-001, verdict: DENY, evidence_ref: tests/regression_001.json, applies_to: auto-remediation без полного audit_trace, next_check: повторить дуэль при изменении manual_review_floor. В следующем споре сошлитесь на PREC-001.
Сложность: intermediate
Название: Верификация защиты от ловушки Гудхарта
Проблема: Имплементор предложил план снижения MTTR с 6 до 2 минут за счет агрессивной автоэскалации. Вам, как Верификатору, нужно отвергнуть план, если он нарушает инварианты.
Решение: Проверьте логику на соответствие жестким стоп-условиям в validation.md. Убедитесь, что false_escalation_rate <= 0.05, rollback_flapping < 3/ч, и silent_p0_ratio == 0. Если план нарушает хотя бы одно условие, Координатор фиксирует FAIL(reason=metric corruption) в judgment.md.
Сложность: advanced
Кейсы: Название: Арбитраж спора по ограничению частоты запросов (Rate Limiting) в API-шлюзе
Сценарий: Спецификация требует при всплеске запросов временно ограничивать конкретного клиента (tenant), но не блокировать весь сервис. Имплементор предлагает патч, добавляющий tenant_id в ключ дедупликации и окно burst_window_sec=60.
Задача: Необходимо убедиться, что патч действительно изолирует клиентов и не приведет к глобальной блокировке. Важно проверить не только техническую правдоподобность текста, но и наличие строгих доказательств.
Решение: Верификатор требует три доказательства (evidence_ref): 1) JSON Schema, требующую tenant_id, limit_reason, expires_at; 2) Лог PreToolUse, запрещающий изменение глобального лимита; 3) Сценарий Given/When/Then, доказывающий, что всплеск от tenant A не снижает квоту tenant B.
Результат: При A/B-тестировании выяснилось, что при паре «сильный Имплементор + слабый Верификатор» патч отклоняется, так как доказательства спрятаны в длинном тексте, а не вынесены в формализованный diff. В спецификацию был добавлен явный сценарий изоляции tenant-а на языке Gherkin.
Извлечённые уроки: Вердикт должен опираться на формализованные доказательства, а не на авторитет модели или убедительность текста.
Расхождение вердиктов при ротации ярусов означает, что требования спецификации недостаточно переносимы и требуют усиления через diff в validation.md.
Связанные концепции: Ротация ярусов
evidence_ref
JSON Schema
Сценарии Given/When/Then
Советы по изучению: Уделите особое внимание разнице форматов доказательств: слабые модели (local-coder) понимают только minimal_form (короткий diagnostic_code), в то время как сильные (frontier-reviewer) могут работать с extended_form (структура evidence_by_invariant).
Запомните золотое правило арбитража: спор разрешается только через различия (diff) в requirements.md, hooks.md или validation.md. Переписка в чате доказательством не является.
При самостоятельном изучении используйте скрипт matrix.py для проверки того, как меняется вердикт при смене пар ИИ-агентов (C1-C4).
Изучите формат decision_trace — он помогает отделить факты от оценок и делает протокол решения воспроизводимым для других верификаторов.
Дополнительные ресурсы: Пример файлового арбитража (runnable): book2/examples/tribunal/ и book2/examples/tribunal/matrix/
Проектный устав и веса голосования: Часть 3 (part-03-project-constitution.md#ключевые-идеи)
Артефакт проверки фич: Часть 9 (part-09-feature-validation.md) — здесь описан validation.md
Совместимость с qwen code cli: appendix-b-qwen-code-compatibility.md
Резюме: Файловый арбитраж превращает процесс проверки кода из хаотичного обсуждения в строгий процессуальный протокол. Основными инструментами здесь выступают журналы judgment.md и precedents.md, а опорой для принятия решений — формальные доказательства (evidence_ref), такие как логи хуков, схемы JSON и тестовые сценарии Given/When/Then. Подход защищен от искажения метрик с помощью anti-Goodhart инвариантов и от предвзятости конкретных ИИ-моделей с помощью ротации ярусов. Главное правило: если доказательства нет в файле, Координатор не должен превращать впечатление агента в официальный вердикт.