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

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

Уровень сложности: Средний

Расчётное время изучения: 4-6 часов (теория + практика с runnable-примером)

Предварительные требования: Понимание ролей Верификатор/Имплементор/Safety/Координатор из части 3

Опыт работы с LLM-дуэлями из главы 4 (контрпримеры и минимальные контрпримеры)

Базовые навыки работы с командной строкой и Python-скриптами

Знакомство с форматом markdown и структурами YAML/JSON

Понимание принципов спецификации как источника истины (SDD, GitHub Spec Kit)

Цели обучения: Спроектировать схему файлового арбитража, в которой вердикт по спорному изменению фиксируется в judgment.md с обязательными полями verdict, reason, evidence_ref и next_step

Различать допустимые и недопустимые доказательства для Верификатора: различия (diff), логи хуков, JSON Schema, сценарии Given/When/Then — и отклонять пересказы в чате как недостаточные основания

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

Применить правило anti-Goodhart: блокировать вердикт PASS, если улучшение одной метрики (например, MTTR) нарушает стоп-пороги по ложным эскалациям, тихим провалам или дрожанию откатов

Формализовать повторяющийся конфликт в precedents.md с обязательными полями case_id, verdict, evidence_ref, applies_to, next_check для воспроизводимого разрешения будущих споров

Обзор: Файловый арбитраж спорного изменения — это процедурный механизм коллективной проверки одного изменения несколькими ролями (Верификатор, Имплементор, Safety, Координатор), где результат фиксируется в файлах проекта, а не в эфемерной переписке чата. В отличие от LLM-дуэли из главы 4, которая отвечает на вопрос «нашёлся ли минимальный контрпример и чем его закрыли», файловый арбитраж отвечает на другой вопрос: «какой официальный вердикт принимает команда ролей, какие доказательства признаны допустимыми и какой прецедент останется для будущих споров». Механизм строится вокруг двух ключевых артефактов: judgment.md (журнал решений по спорам текущей сессии) и precedents.md (база повторяющихся конфликтов). Координатор управляет процессом и ведёт протокол, но не голосует. Имплементор предлагает изменения только в контролируемых артефактах. Верификатор принимает или отклоняет по формальным критериям. Safety получает право вето при critical_risk. Все вердикты сверяются с фактами validation.md, а итоги пересматривают дорожную карту. Ротация ролей через разные ярусы моделей (дешёвые локальные vs. сильные облачные) превращается в инструмент проверки устойчивости спецификации: если вердикт меняется при смене пары, проблема в недостаточной переносимости доказательств, а не в «ошибке» конкретного агента. Правило anti-Goodhart завершает контур, запрещая принимать быстрые решения, улучшающие одну метрику ценой операционной устойчивости. Минимальный учебный сценарий использует кейс autoscale_200pct и собирается из трёх скриптов: run_duel.py, check_invariants.py, write_judgment.py.

Ключевые концепции: Judgment.md: Журнал решений по спорам текущей сессии арбитража. Содержит не просто PASS/FAIL, а полный процессуальный вердикт: какой раунд прошёл, какое различие (diff) рассмотрено, какие доказательства признаны достаточными, и что должен сделать Имплементор при повторном споре. Минимальные обязательные поля: verdict (APPROVE/DENY/DEFERRED), reason (формулировка основания), evidence_ref (ссылка на конкретный файл, а не пересказ), next_step (конкретное действие для разрешения). Без этих полей файловый арбитраж остаётся дуэлью из главы 4.

Precedents.md: База повторяющихся конфликтов для воспроизводимого разрешения будущих споров. Каждая запись содержит ровно пять полей: case_id (стабильный идентификатор), verdict (итог по правилу арбитража), evidence_ref (ссылка на различие, лог хука, схему или сценарий), applies_to (границы применимости: ярусы, режимы строгости, домены), next_check (условие пересмотра прецедента). Создаётся только для повторяемых конфликтов; уникальные споры остаются в judgment.md.

Координатор (coordinator): Роль, открывающая сессию арбитража, задающая порядок раундов, ведущая очередь споров и отвечающая за официальный протокол в judgment.md. Ключевое отличие от Верификатора и Safety: Координатор не голосует. Его функция — процессуальная, а не решательная. Он запрещает переход к следующему этапу без записи результата предыдущего, предотвращая «забытые» споры в чате.

Верификатор (verifier): Роль, принимающая или отклоняющая изменения Имплементора по формальным критериям. Действует только при наличии допустимых доказательств из файлов: различия (diff) в requirements.md/hooks.md/validation.md, логи PreToolUse/PostToolUse, JSON Schema, сценарии Given/When/Then. Не принимает пересказы в чате, «убедительные» рассуждения без ссылок, впечатления агента. При DENY требует конкретное evidence_ref и next_step.

Имплементор (implementor): Роль, предлагающая изменения только в контролируемых артефактах проекта. При отклонении вердикта не переписывает объяснение в свободной форме, а добавляет проверяемое изменение: уточняет требование, усиливает хук или расширяет валидационный сценарий. Работает с patch_plan и хуками, фиксирует результаты в evidence/.

Safety: Роль с правом вето при обнаружении critical_risk. Голосует наряду с Верификатором и Имплементором, но её голос имеет блокирующий характер для критичных рисков. Полный устав с весами голосования (vote_weight), кворумом и veto-условиями — в части 3.

Допустимые доказательства (evidence ref): Строго ограниченный набор форм, которые Верификатор имеет право принимать: (1) различия (diff) в спецификационных файлах, (2) логи PreToolUse (блок опасных действий до исполнения) и PostToolUse (фактический результат, код выхода, хэш diff), (3) JSON Schema (проверка контракта данных), (4) сценарии Given/When/Then (причинная проверка условий-действий-результатов). Всё, что не попадает в эти категории, исключается из доказательной базы.

Ротация ярусов (tier rotation): Запуск одной и той же спецификации через разные пары Имплементор/Верификатор (локальный vs. сильный агент в каждой позиции). Четыре стандартные конфигурации: C1 (дешёвый Имплементор + сильный Верификатор), C2 (сильный Имплементор + дешёвый Верификатор), C3 (симметричная локальная пара), C4 (симметричная дорогая пара). Если вердикт меняется при смене пары — это сигнал tier_dependent_spec, требующий усиления доказательств в validation.md, а не замены модели.

Anti-goodhart-инвариант: Правило, запрещающее улучшать одну метрику за счёт деградации системы. Жёсткие стоп-условия в validation.md: false_escalation_rate <= 0.05, rollback_flapping < 3/ч, silent_p0_ratio == 0. Превышение любого порога переводит вердикт в FAIL независимо от выигрыша по времени (например, MTTR). Превращает защиту от Гудхарта из морального предупреждения в исполняемое правило арбитража.

Формы доказательств (minimal form vs. extended form): Учебный сигнал в матрице ярусов. local-coder отдаёт короткий diagnostic_code (minimal_form), frontier-reviewer — структуру evidence_by_invariant (extended_form). Если слабый Верификатор распознаёт только minimal_form, а сильный Имплементор выдаёт extended_form, пара C2 стабильно падает. Это демонстрирует, что форма доказательства должна соответствовать способности принимающей роли.

Спор через diff: Фундаментальное правило: конфликт разрешается только через различия в requirements.md, hooks.md, validation.md. Любые скрытые правки в диалоге чата исключаются из доказательной базы. Координатор принимает повторный раунд только после того, как различие связано с исходной спецификацией и конкретным событием-доказательством.

Практические упражнения: Название: Упражнение 1: Сборка минимального judgment.md

Проблема: Вы находитесь в каталоге book2/examples/tribunal. У вас есть спецификация specs/autoscale_spec.yaml, кейсы в cases/ и метрики в metrics/validation_metrics.json. Нужно получить итоговый out/judgment.md с полным вердиктом. Однако после первого запуска write_judgment.py вы обнаруживаете, что файл содержит только verdict: FAIL без полей reason, evidence_ref и next_step. Исправьте цепочку скриптов или их выходные данные так, чтобы финальный judgment.md удовлетворял критериям файлового арбитража.

Решение: Шаг 1: Проверьте выход run_duel.py (out/duel.json). Убедитесь, что каждый кейс содержит не только pass/fail, но и case_id, tested_invariant, failure_reason. Если нет — добавьте в cases/ JSON-файлы с этими полями или модифицируйте run_duel.py для их извлечения из спецификации.

Шаг 2: Проверьте выход check_invariants.py (out/invariants.json). Убедитесь, что каждый нарушенный инвариант содержит invariant_name, threshold, actual_value, metrics_source. Пример: {"invariant": "silent_p0", "threshold": 0, "actual": 3, "source": "metrics/validation_metrics.json"}.

Шаг 3: Модифицируйте write_judgment.py так, чтобы он собирал из обоих входов структуру с обязательными полями. Минимальный шаблон:

verdict: DENY
reason: "violates_invariant:silent_p0 — 3 P0-инцидента закрыты без эскалации"
evidence_ref: "metrics/validation_metrics.json#silent_p0"
next_step: "Имплементор добавляет проверку severity перед автоэскалацией в hooks.md"

Шаг 4: Перезапустите цепочку и проверьте, что out/judgment.md содержит все четыре поля. Если evidence_ref указывает на несуществующий файл — исправьте путь на относительный от корня проекта.

Сложность: beginner

Название: Упражнение 2: Различение допустимых и недопустимых доказательств

Проблема: Вам предоставлены пять «доказательств» от Имплементора после отклонения его патча. Какие из них Верификатор имеет право принять, а какие должны быть отклонены с требованием переделать?

1. «Я проверил локально, всё работает» (сообщение в Slack)
2. diff в hooks.md, добавляющий PreToolUse блокировку для глобального лимита
3. Скриншот логов из личного терминала разработчика
4. JSON Schema с обязательными полями tenant_id, limit_reason, expires_at
5. Сценарий Gherkin: Given tenant A exceeds burst limit / When rate-limit hook applies / Then tenant B quota remains unchanged

Решение: Допустимые доказательства: 2, 4, 5.

Недопустимые и почему:

• 1: Пересказ в чате, нет evidence_ref на конкретный файл. Вердикт не может опираться на «убеждённость» агента. Требование: превратить в diff в validation.md или лог хука.
• 3: Скриншот — невоспроизводимый артефакт. Нет хэша, нет машиночитаемой структуры. Требование: заменить на PostToolUse лог с контрольной суммой или JSON-выгрузку.

Для допустимых доказательств проверьте полноту:

• 2: PreToolUse лог должен содержать правило, код выхода, ссылку на событие. Если только текст «блокировано» — недостаточно.
• 4: JSON Schema должна быть применена к конкретному endpoint/структуре, а не в абстрактном виде.
• 5: Сценарий должен иметь привязку к конкретному кейсу в cases/ с воспроизводимым входом.

Сложность: intermediate

Название: Упражнение 3: Интерпретация расхождения в матрице ярусов

Проблема: Вы запустили scripts/matrix.py для спецификации rate_limit_spec.md и получили результат:

• C1 (local-coder Имплементор + frontier-reviewer Верификатор): PASS
• C2 (frontier-reviewer Имплементор + local-coder Верификатор): FAIL
• C3 (local-coder + local-coder): PASS
• C4 (frontier-reviewer + frontier-reviewer): PASS

Сигнал summary.signal = tier_dependent_spec. Ваша задача: не меняя модели, объяснить расхождение в validation.md и подготовить запись для precedents.md.

Решение: Шаг 1: Диагностика формы доказательств. Сравните выходы Имплементора в C1 и C2. Скорее всего, frontier-reviewer Имплементор выдаёт extended_form (evidence_by_invariant со структурированными рассуждениями), а local-coder Верификатор понимает только minimal_form (diagnostic_code как короткий код). Пара C2 падает из-за несовпадения форм, а не из-за ошибки спецификации.

Шаг 2: Усиление validation.md. Добавьте требование: «Все доказательства безопасности изоляции tenant должны содержать diagnostic_code из фиксированного перечня, независимо от яруса Имплементора». Это заставляет сильного Имплементора адаптировать выход под способность слабого Верификатора.

Шаг 3: Запись в precedents.md:

- case_id: PREC-RL-001
  verdict: DEFERRED
  evidence_ref: "matrix/tiers.json#C2_signal"
  applies_to: "rate-limit с изоляцией tenant, все ярусы, форма доказательства не стандартизирована"
  next_check: "validation.md обновлён требованием diagnostic_code или появился универсальный парсер evidence"

Шаг 4: Проверка. Перезапустите C2 после обновления validation.md. Ожидаемый результат: либо PASS (если форма стандартизирована), либо осмысленный FAIL с конкретным нарушением схемы, а не «непонятно».

Сложность: intermediate

Название: Упражнение 4: Применение anti-Goodhart правила

Проблема: Имплементор предлагает патч для autoscale_200pct, который снижает MTTR с 6 до 2 минут путём агрессивной автоматической эскалации при первом тревожном событии. Дуэль показывает PASS по скорости. Однако метрики показывают: false_escalation_rate = 0.12, rollback_flapping = 5/ч, silent_p0_ratio = 0. Какой вердикт и артефакт фиксирует Координатор?

Решение: Шаг 1: Проверка стоп-порогов из validation.md. Сравните с порогами: false_escalation_rate <= 0.05 (0.12 > 0.05, нарушение), rollback_flapping < 3/ч (5 > 3, нарушение), silent_p0_ratio == 0 (0 = 0, OK).

Шаг 2: Вердикт. Независимо от PASS по MTTR, Координатор фиксирует FAIL по anti-Goodhart:

verdict: DENY
reason: "metric corruption — false_escalation_rate 0.12 exceeds threshold 0.05; rollback_flapping 5/h exceeds threshold 3/h"
evidence_ref: "metrics/validation_metrics.json#post_patch"
next_step: "Имплементор добавляет cooldown_window_sec и manual_review_floor в hooks.md, обновляет validation.md порогами"

Шаг 3: Требование к Имплементору. Не косметическое объяснение («мы поправим»), а конкретное изменение: добавить окно остывания (cooldown) между эскалациями, порог ручного подтверждения для первичных событий, счётчик откатов с гистерезисом.

Шаг 4: Повторная проверка. Новый раунд дуэли + инвариантов должен показать false_escalation_rate <= 0.05 и rollback_flapping < 3/ч до возможного APPROVE.

Сложность: intermediate

Название: Упражнение 5: Полный арбитражный цикл с переносом в capstone

Проблема: Проведите полный цикл файлового арбитража для кейса high_memory_usage в учебном проекте. Начальное состояние: readiness проходит по score, но stateful_blocker не имеет backup_verified evidence. Имплементор настаивает на APPROVE, Верификатор требует DENY, Safety не активирован (нет critical_risk). Три раунда не приводят к согласию. Очередь инцидентов растёт. Какой стоп-условие применить и какой минимальный фрагмент перенести в capstone/judgment.md?

Решение: Шаг 1: Применение стоп-условия. По правилам арбитража, при трёх раундах без решения Координатор фиксирует DEFERRED — вердикт, откладывающий решение до получения недостающих доказательств или передачи человеку. Не APPROVE под давлением очереди, не DENY без полного основания.

Шаг 2: Фиксация в judgment.md:

verdict: DEFERRED
reason: "readiness passes by score, but stateful blocker has no backup evidence after 3 rounds"
evidence_ref: "fixtures/readiness_block_stateful.json"
next_step: "add backup_verified evidence or keep remediation manual"
rounds_conducted: 3
escalation_to_human: "pending — auto-escalate if not resolved in 24h or queue exceeds 10"

Шаг 3: Проверка на повторяемость. Если этот конфликт возникает регулярно (например, при каждом обновлении autoscale_200pct), добавьте в capstone/precedents.md:

- case_id: PREC-HMU-001
  verdict: DEFERRED
  evidence_ref: "fixtures/readiness_block_stateful.json"
  applies_to: "high_memory_usage с readiness score pass и отсутствием backup_verified, все ярусы"
  next_check: "появление backup_verified evidence или изменение readiness scoring algorithm"

Шаг 4: Перенос в capstone. Не копируйте весь out/duel.json — он воспроизводится командой. Сохраните только judgment.md или его выдержку, если они стали частью учебного пакета доказательств. Локальные out/duel.json и out/invariants.json оставьте вне репозитория.

Сложность: advanced

Кейсы: Название: Кейс: Rate-limit с изоляцией tenant и tier-dependent спецификация

Сценарий: Команда разрабатывает API-шлюз с автоматическим ограничением частоты (rate limiting). Спецификация требует: при всплеске запросов ограничивать конкретного клиента (tenant), не блокировать весь сервис, не эскалировать каждый всплеск как P0. Имплементор предлагает патч: добавить tenant_id в ключ дедупликации, ввести окно burst_window_sec=60, писать событие в evidence/rate_limit.ndjson.

Задача: При ротации ролей через матрицу ярусов обнаружилось расхождение: конфигурация C1 (дешёвый Имплементор + сильный Верификатор) даёт PASS, C2 (сильный Имплементор + дешёвый Верификатор) стабильно FAIL. Команда изначально интерпретировала это как «слабый Верификатор ошибается» и собиралась заменить модель. При этом сильный Имплементор выдавал структурированные рассуждения (extended_form), а слабый Верификатор понимал только короткие diagnostic_code (minimal_form).

Решение: Вместо замены модели Координатор потребовал усилить validation.md требованием универсальной формы доказательств. Имплементор адаптировал выход: все доказательства безопасности изоляции tenant теперь содержат обязательный diagnostic_code из фиксированного перечня, независимо от яруса. Верификатор получил три проверяемых доказательства: JSON Schema с tenant_id/limit_reason/expires_at, PreToolUse блокировку глобального лимита без области действия, Given/When/Then сценарий изоляции соседних клиентов.

Результат: После стандартизации формы все четыре конфигурации матрицы дали согласованный PASS. Время разрешения споров снизилось с 2-3 дней переписки до одного раунда арбитража. Запись PREC-RL-001 в precedents.md позволила автоматически разрешать аналогичные конфликты в трёх последующих спринтах без повторных раундов.

Извлечённые уроки: Расхождение вердиктов при смене ярусов — это сигнал о недостаточной переносимости спецификации, а не ошибка конкретной модели

Форма доказательства должна соответствовать способности принимающей роли; универсальность достигается стандартизацией в validation.md, а не подбором моделей

Каждый повторяющийся конфликт стоит формализовать в precedents.md — это инвестиция в сокращение будущих раундов арбитража

Связанные концепции: Ротация ярусов (tier rotation)

Формы доказательств (minimal_form vs. extended_form)

Допустимые доказательства (evidence_ref)

precedents.md

Название: Кейс: Anti-Goodhart в автоэскалации и блокировка быстрого, но вредного патча

Сценарий: Операционная команда ставит цель снизить MTTR (среднее время восстановления) с 6 до 2 минут для сервиса autoscale_200pct. Имплементор предлагает агрессивную автоматическую эскалацию при первом тревожном событии без окон остывания и без ручного подтверждения. Дуэль показывает PASS по скорости: MTTR действительно падает до 1.8 минут.

Задача: Верификатор обнаружил побочные эффекты: false_escalation_rate вырос до 0.12 (порог 0.05), rollback_flapping достиг 5/ч (порог 3/ч). Имплементор настаивал, что цель по MTTR достигнута и это «операционная деталь». Координатор столкнулся с давлением: очередь инцидентов растёт, бизнес хочет быстрый результат.

Решение: Координатор применил правило anti-Goodhart как исполняемое стоп-условие: превышение любого порога в validation.md переводит вердикт в FAIL независимо от выигрыша по времени. Вердикт был зафиксирован: DENY(reason=metric corruption). Имплементору было предписано не косметическое объяснение, а конкретное изменение: добавить cooldown_window_sec, manual_review_floor для первичных событий, гистерезис счётчика откатов. Все изменения — как diff в hooks.md и validation.md.

Результат: После доработки патч прошёл повторный арбитраж: MTTR = 2.3 минут (в пределах цели), false_escalation_rate = 0.03, rollback_flapping = 1/ч. Команда осознала, что «быстрый» первоначальный вариант привёл бы к операционному коллапсу: ложные эскалации перегрузили бы on-call инженеров, дрожание откатов destabilизировало бы production. Правило anti-Goodhart стало обязательной частью всех последующих арбитражей автоэскалации.

Извлечённые уроки: Улучшение одной метрики ценой деградации системы — не улучшение, а метрическая коррупция; anti-Goodhart правило должно быть исполняемым, не моральным

Давление «быстрее, очередь растёт» не отменяет процедурных стоп-условий; Координатор защищает процесс от экспедитивных решений

Конкретный next_step в judgment.md (какие файлы изменить, какие пороги добавить) эффективнее любого «мы разберёмся» в чате

Связанные концепции: Anti-Goodhart-инвариант

Стоп-условия в validation.md

Координатор как защитник процесса

judgment.md

Название: Кейс: Трёхраундовый тупик и вердикт DEFERRED для stateful blocker

Сценарий: В учебном проекте capstone возник спор по кейсу high_memory_usage. readiness проходил по score, но stateful_blocker не имел backup_verified evidence — критичное требование для stateful-сервисов. Имплементор настаивал на APPROVE, ссылаясь на высокий readiness score. Верификатор требовал DENY, ссылаясь на отсутствие доказательства резервирования. Safety не был активирован (риск не достиг critical_risk).

Задача: Три раунда арбитража не привели к согласию. Имплементор добавлял всё более убедительные текстовые объяснения, но не создавал проверяемых изменений. Верификатор отклонял текстовые аргументы, но не мог предложить альтернативу, кроме полного запрета. Очередь инцидентов росла, возникло давление на «принять как есть» или «отклонить окончательно».

Решение: Координатор применил процедурное стоп-условие: при трёх раундах без решения фиксируется DEFERRED — вердикт, откладывающий решение до получения недостающих доказательств или передачи человеку. В judgment.md было записано: verdict: DEFERRED, конкретное reason, evidence_ref на текущее состояние, next_step с двумя альтернативами (add backup_verified evidence или keep remediation manual), условие автоэскалации к человеку. Ни APPROVE под давлением, ни DENY без полного основания.

Результат: Человек-архитектор принял решение за 4 часа: для учебного сервиса допустимо ручное remediation, но production-треку требуется обязательное backup_verified. Это решение было формализовано в precedents.md как PREC-HMU-001. В последующих спринтах аналогичные конфликты разрешались автоматически по прецеденту без участия человека. Команда осознала, что DEFERRED — не «поражение арбитража», а корректное процессуальное состояние, предотвращающее принятие решений под давлением.

Извлечённые уроки: DEFERRED — валидный и важный вердикт; он предотвращает принятие решений под давлением при неполных доказательствах

Текстовые убедительные объяснения без проверяемых изменений — это повторение одного и того же раунда, а не прогресс в арбитраже

Чёткое условие эскалации к человеку в judgment.md (время, порог очереди) предотвращает бесконечное откладывание

Связанные концепции: Вердикт DEFERRED

Стоп-условия арбитража

Координатор как протоколист без голоса

precedents.md

Советы по изучению: Начинайте с runnable-примера: физически запустите три скрипта (run_duel.py, check_invariants.py, write_judgment.py) и откройте полученные файлы. Теория арбитража становится очевидной только после работы с реальными артефактами.

Сравнивайте «плохие» и «хорошие» вердикты буквально: напечатайте рядом сообщение из чата («Верификатор отклонил») и запись из judgment.md с evidence_ref. Разница в воспроизводимости станет очевидной.

Практикуйте ротацию ярусов как диагностический инструмент, а не как способ «найти правильную модель». Запустите матрицу, получите tier_dependent_spec, и именно это — целевой учебный сигнал. Не пытайтесь его «исправить» заменой модели.

Создавайте собственные precedents.md вручную, а не копируя шаблон. Попробуйте описать конфликт из вашей практики в пяти обязательных полях — вы сразу увидите, какие части знаний не формализованы.

Используйте diff как единственный язык спора. При возникновении разногласия в учебной группе — не обсуждайте, а предложите конкретное изменение в requirements.md, hooks.md или validation.md. Это тренирует арбитражное мышление.

Проверяйте anti-Goodhart инварианты намеренно «ломая» метрики. Создайте тестовый патч, который улучшает MTTR ценой ложных эскалаций, и убедитесь, что check_invariants.py блокирует его. Это формирует интуицию исполняемых правил.

Ведите личный «протокол Координатора»: для каждого пройденного упражнения записывайте, какие раунды прошли, где возникли тупики, какие стоп-условия применили. Это развивает процессуальное мышление, а не только техническое.

Изучайте связь с предыдущими частями курса активно: возвращайтесь к части 16 (командное ревью человека) и сравнивайте, как те же роли работают «уровнем выше» с файловыми артефактами вместо комментариев в PR.

Дополнительные ресурсы: Book2/examples/tribunal/readme.md: Основной runnable-пример файлового арбитража с тремя скриптами и учебным кейсом autoscale_200pct

Book2/examples/tribunal/matrix/readme.md: Матрица ярусов для проверки tier_dependent_spec с четырьмя конфигурациями пар

Appendix-b-qwen-code-compatibility.md: Соответствие ролей арбитража и встроенных возможностей CLI Qwen Code (/review, headless qwen -p)

../book/part-16-team-code-review.md: Базовая схема командного ревью человеком — предшественник файлового арбитража ролей

../book/part-10-project-replanning.md: Перепланирование после фактов — как итоги арбитража влияют на дорожную карту

../book/part-09-feature-validation.md: validation.md как источник фактов для сверки вердиктов Верификатора

Github spec kit (https://github.com/github/spec-kit): Внешний референс по подходу SDD: спецификация как источник истины для поведения системы

Book2/examples/tribunal/scripts/run duel.py: Исходный код скрипта дуэли для изучения формата выходных данных

Book2/examples/tribunal/scripts/check invariants.py: Исходный код проверки anti-Goodhart инвариантов с порогами

Book2/examples/tribunal/scripts/write judgment.py: Исходный код сборки judgment.md для понимания логики агрегации доказательств

Резюме: Файловый арбитраж спорного изменения превращает разрешение конфликтов из эфемерной переписки в чате в воспроизводимую процедуру с фиксацией в артефактах проекта. Ключевые принципы: Координатор управляет процессом и протоколом, но не голосует; Верификатор принимает только проверяемые доказательства из файлов (diff, логи хуков, JSON Schema, Given/When/Then), отвергая пересказы; Имплементор предлагает изменения только в контролируемых артефактах; Safety обладает вето при critical_risk. Вердикты фиксируются в judgment.md с обязательными полями verdict, reason, evidence_ref, next_step. Ротация ролей через разные ярусы моделей выявляет tier_dependent_spec и требует усиления спецификации, а не замены модели. Правило anti-Goodhart блокирует метрическую коррупцию: улучшение одного показателя ценой ложных эскалаций, тихих провалов или дрожания откатов переводит вердикт в FAIL независимо от выигрыша по скорости. Повторяющиеся конфликты формализуются в precedents.md с пятью обязательными полями для автоматического разрешения будущих споров. Минимальный учебный сценарий использует кейс autoscale_200pct и собирается из трёх скриптов в book2/examples/tribunal/.