Тема: Глоссарий прикладного тома: практическое руководство по production-SDD
Уровень сложности: Средний
Расчётное время изучения: 12-16 часов (2 недели при 1 часе в день)
Предварительные требования: Завершённый первый том учебника SDD (основные артефакты: QWEN.md, mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md)
Понимание навыков Qwen Code, MCP, ACP, EARS, Given/When/Then
Базовый опыт работы с Git, YAML/JSON, CI/CD
Знакомство с учебным проектом AgentClinic (TypeScript, Hono, SQLite, Vitest)
Цели обучения: Правильно переводить 40+ ключевых терминов прикладного тома из английской формы в русскую прозу, сохраняя технические имена в коде и YAML/JSON-ключах
Применять production-уточнения базовых артефактов SDD (validation.md, QWEN.md, конституция) в реальных сценариях с мультиагентным арбитражом и защитой от дрейфа
Проектировать парные метрики (anti-Goodhart) и шлюзы безопасности (spec gate, red button) для production-контура с LLM-агентами
Воспроизводить полный цикл файлового арбитража: от poisoned spec через мутационное тестирование до judgment.md и прецедентов
Самостоятельно заполнять обязательные артефакты первого прохода (capstone-досье) по конкретному инциденту
Обзор: Глоссарий прикладного тома — это не просто словарь терминов, а операционный справочник для production-SDD: системы разработки через спецификацию, где LLM-агенты работают под контролем человека в реальном production-контуре. Каждый термин здесь получает рабочее определение, runnable-сценарий и чёткие правила перевода: русская проза для объяснений, английские технические имена для кода, YAML и JSON. Главное правило чтения: не зубрить глоссарий целиком, а открывать термин тогда, когда он помогает заполнить конкретный файл или понять runnable-пример. Ключевые группы: роли агентов (Верификатор, Имплементор, Safety, Координатор), артефакты управления рисками (constitution.md, judgment.md, precedents.md, genealogy.md), метрики иммунитета и защиты от искажения показателей (anti-Goodhart), механизмы стресс-тестирования и мультиагентного арбитража. Учебный проект AgentClinic служит опорной точкой для всех production-сценариев.
Ключевые концепции: Тихий p0 (silent p0): Доля инцидентов уровня P0, прошедших через автоматизацию без человеческого подтверждения и без записи в audit trail. Anti-Goodhart-метрика: если MTTR падает, а silent_p0 растёт, авто-ремедиация ускоряется за счёт скрытых рисков. В коде: silent_p0, silent_p0_cap, silent_p0_ratio — технические имена, не переводятся.
Шлюз спецификации (spec ci): CI-проверка, блокирующая merge, если спецификация не покрыта планом, план — задачами, или задачи — фактами в validation.md. В прозе: «Spec CI» или «шлюз спецификации (Spec CI)»; в коде: spec_gate — только как имя задачи в .github/workflows/spec-ci.yml.
Файловый арбитраж (tribunal): Процедура коллегиального решения по спорной поправке: Верификатор, Имплементор и Safety голосуют по фиксированному протоколу, Координатор оформляет judgment.md. В прозе: «файловый арбитраж»; в коде: tribunal — только как имя каталога examples/tribunal/ и его скриптов.
Аварийный режим (red button): Формальный шлюз безопасности перед опасным действием: деплоем, откатом, миграцией или авто-ремедиацией. «Красная кнопка» — короткий разговорный ярлык. В коде: red_button, red_button_mttr_blindness — только как имена инвариантов в YAML.
Теневая спецификация (shadow spec): Спецификация для неформализуемых нюансов: интонации, негласных приоритетов, исторических решений. Хранится отдельно, побеждает в аукционе на основе журнала оценок (scorebook), не подменяет основную спецификацию. В заголовках допускаются оба написания.
Метрика иммунитета (immunity score): Вектор оценок валидатора из трёх компонент: strict_reject_rate (доля вырожденных кейсов, отклонённых строго на ожидаемом шаге), depth_of_diagnostics (полезная глубина объяснения до отказа), recovery_time_p95_ms (p95 времени возврата стабильного вердикта). Не одна итоговая цифра, а шлюз валидаторного контура.
Парная контр-метрика (guard metric): Метрика-антитело для защиты от искажения целевого показателя. Каждой целевой метрике (MTTR, edge_drift) сопоставляется guard-метрика (silent_p0, manual_review_floor, audit_trace_coverage), и CI-шлюз проходит только при одновременном выполнении обеих.
Конституция проекта (constitution.md): Расширение базовой конституции первого тома с явным разделом: immutable_principles (не отключаются автоматически, меняются только через референдум команды), mutable_rules (эволюционируют через накопление инцидентов с полями incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition), governance_protocol (роли и процедуры голосования).
Ядовитая спецификация (poisoned spec): Учебная спецификация с одним контролируемым дефектом: цикл эскалации, конфликт приоритетов или скрытый выход за границы. Используется для тренировки Верификатора и валидаторов через мутационное тестирование.
Оператор мутации (mutation operator): Функция, вносящая ровно один дефект известного класса в корректную спецификацию. Каждой мутации присваивается mutation_id, ожидаемый expected_failure и шаг halt_before. Примеры: Nullify, FutureTime, EscalationCycle, PriorityContradiction.
Решение по спору (judgment.md): Итоговый артефакт файлового арбитража: журнал голосов, decision_hash, ссылки на спецификацию, конституцию и инцидент, активные ttl и rollback_condition. Хранится в репозитории как неизменяемый след.
Прецедент (precedent): Запись в precedents.md о повторяющемся типе конфликта и принятом разрешении. Используется как tie-breaker latest_matching_precedent в governance_protocol и снижает стоимость следующего арбитража.
Генеалогия (genealogy.md): Провенанс восстановленной спецификации: для каждого требования — список источников, уровень уверенности (confirmed, inferred, hypothesis) и открытый вопрос. Создаётся при восстановлении из legacy-кода и логов.
Ярус модели (tier): Уровень модели в ярусной маршрутизации: local-coder (дешёвая локальная модель для генерации кода и черновиков), frontier-reviewer (дорогая frontier-модель для критических ревью и спорных вердиктов). В прозе: «низкий/средний/высокий ярус»; в YAML-ключах и именах ролей — без перевода.
Дрейф (drift): Расхождение между спецификацией, реализацией и реальным поведением агента в production. Три вида: spec_drift (спецификация устарела), code_drift (реализация ушла от плана), edge_drift (валидатор по-другому реагирует на пограничные случаи).
Реплей (replay): Повторное проигрывание исторических инцидентов через текущий валидатор и текущую конституцию. Шлюз в Goodhart-метриках: новая версия не должна ухудшать вердикты на уже разобранных кейсах.
Override-правило: Изменяемая норма в constitution.md, разрешающая обход стандартного поведения в узком контексте: для конкретного incident_type, на конкретной pipeline_phase, с ограниченным max_scope и обязательным ttl. Без ограничений конкурирует с инвариантами.
Цепочка доказательств (evidence chain): Структурированная цепочка артефактов, привязанная к решению агента: входной payload, версия спецификации, активные правила конституции, журнал голосов арбитража, diff изменения, проверки постусловий. Минимальное требование для production SDD.
Аукцион теневых спецификаций: Оценка и ранжирование неформальных эвристик перед включением в рабочий контекст. Победитель аукциона попадает в QWEN.md как few-shot с сроком пересмотра. Журнал оценок — scorebook (shadow-scorebook.json).
Антипаттерны процесса: ask_storm — цикл уточняющих вопросов вместо остановки; stage_regress — откат на предыдущую фазу SDD без причины; phase_context_loss — потеря контекста между фазами. Контрольные строки и защиты описаны в глоссарии.
Важные даты: Момент первого прохода: Не читать глоссарий целиком. Достаточно понимать capstone/ и десять обязательных артефактов первого прохода (полный список — в README)
Ввод терминов по частям: Роли (часть 4), Артефакты конституции (часть 3), Метрики иммунитета (часть 5), Теневые спецификации (часть 6), Spec CI (часть 7), Файловый арбитраж (часть 8), Ярусная маршрутизация (часть 9), Anti-Goodhart (часть 10), Развёртывание (часть 11), Антипаттерны и capstone (части 12-13)
Production-уточнения: Накладываются на базовые термины первого тома: validation.md дополняется failing case, anti-Goodhart-проверками, drift-полями; QWEN.md становится местом few-shot из аукциона; конституция расширяется immutable/mutable-разделом
Практические упражнения: Название: Перевод терминов: техническое имя vs проза
Проблема: Даны три контекста использования термина 'silent_p0'. Напишите правильную форму для каждого: (1) объяснение в документации для бизнеса, (2) YAML-ключ в конфигурации CI, (3) команда в CLI для проверки метрики. Проверьте себя по таблице перевода.
Решение: (1) Проза: «тихий P0» — доля инцидентов уровня P0, прошедших без человеческого подтверждения; (2) YAML-ключ: silent_p0, silent_p0_cap, silent_p0_ratio — техническое имя, не переводится; (3) CLI: silent_p0 — имя метрики в команде, например qwen -p metrics check silent_p0_ratio. Правило: английский ключ только в кодовых блоках и при первом упоминании в скобках.
Сложность: beginner
Название: Проектирование парных метрик для AgentClinic
Проблема: В системе записи к врачу внедряют метрику 'среднее время подтверждения записи' (MTTR-like). Какая guard-метрика защитит от искажения? Опишите: (1) целевую метрику, (2) guard-метрику, (3) условие шлюза, (4) сценарий, когда целевая метрика улучшается, а guard ухудшается.
Решение: (1) Целевая: booking_confirmation_time_ms — среднее время от запроса до подтверждения; (2) Guard: silent_override_rate — доля записей, подтверждённых автоматически без проверки конфликтов расписания врача; (3) Шлюз: обе метрики в зелёной зоне, иначе BLOCKED; (4) Сценарий: агент начинает подтверждать записи, игнорируя двойное бронирование — MTTR падает, silent_override_rate растёт, шлюз блокирует деплой. Anti-Goodhart-приём: никогда не оптимизировать одну метрику без проверки антитела.
Сложность: intermediate
Название: Восстановление genealogy.md для legacy-фичи
Проблема: В AgentClinic обнаружена фича 'автоматическое напоминание о приёме', реализованная 2 года назад, спецификации нет. Восстановите минимальную genealogy.md: опишите 3 источника информации, уровни уверенности и 2 открытых вопроса. Используйте формат из глоссария.
Решение: Источники: (1) Логи SMS-шлюза — confirmed (есть записи с шаблоном сообщения и триггером за 24ч); (2) Код в src/reminders/auto-sms.ts — inferred (логика есть, но нет комментариев о бизнес-правилах); (3) Отзывы пациентов в поддержке — hypothesis (некоторые жалуются на отсутствие напоминаний, возможен баг или opt-out). Открытые вопросы: (a) Какой порог 'достаточно близкого времени' срабатывает — 24ч, 2ч, или зависит от типа приёма? (b) Есть ли fallback-канал (email, push) при недоступности SMS? Формат genealogy.md: таблица с колонками requirement_id, sources[], confidence, open_questions[].
Сложность: intermediate
Название: Полный цикл файлового арбитража
Проблема: Спорное изменение в AgentClinic: агент предлагает добавить автоматическую отмену записи при 3х неявках, но это затрагивает SLA-политику возврата средств. Проведите файловый арбитраж: определите голоса Verifier, Implementor, Safety, роль Координатора, итоговый вердикт и содержимое judgment.md.
Решение: Verifier: reject — нарушение скрытого выхода за границы (спецификация про маршрутизацию алерта, агент правит SLA-политику); Implementor: abstain — поправка применима технически, но выходит за max_scope; Safety: veto (critical_risk) — blast radius включает финансовые обязательства, нет rollback_condition для возврата ошибочных отмен; Координатор: фиксирует verdict REJECTED, публикует judgment.md с decision_hash, ссылками на спецификацию маршрутизации и конституцию (mutable_rules для финансовых операций), активным ttl=0 (изменение не применяется), rollback_condition=N/A. Прецедент добавляется в precedents.md: 'auto-cancellation with financial impact requires explicit mutable_rule for billing, not just routing spec'.
Сложность: advanced
Название: Диагностика anti-паттерна ask_storm
Проблема: Агент в цикле задаёт 5 уточняющих вопросов о приоритете записи, не переходя к планированию. Проверьте контрольную строку: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. Опишите: (1) что указывает на ядовитую спецификацию, (2) какое правило конституции нарушено, (3) шаги ремедиации.
Решение: (1) ask_storm >= 4 при cycle_count > 0 — агент застрял в уточнениях вместо остановки или эскалации; escalation_path_resolved=false — нет разрешения конфликта; (2) Нарушение mutable_rule: при ask_storm >= 3 Координатор обязан прервать цикл и инициировать human-in-the-loop (если такое правило записано в constitution.md); если нет — gap в конституции; (3) Ремедиация: (a) зафиксировать инцидент, (b) обновить спецификацию с явным tie_breaker для конфликта приоритетов, (c) добавить guard-метрику max_ask_storm=2 в CI, (d) провести мутационное тестирование с оператором PriorityContradiction.
Сложность: advanced
Кейсы: Название: Внедрение ярусной маршрутизации в AgentClinic: от бюджетного кризиса к контролируемым затратам
Сценарий: Команда AgentClinic использовала единую frontier-модель (GPT-4-класс) для всех задач: написание кода, ревью, исправление багов, ответы в поддержку. При росте нагрузки затраты на API выросли на 340% за квартал, при этом 70% запросов были рутинными (генерация шаблонов SMS, обновление расписаний). Нужно было сохранить качество критических операций и сократить расходы.
Задача: (1) Нет разделения задач по критичности — frontier-модель использовалась для всего; (2) Нет механизма блокировки при превышении бюджета — расходы росли непрерывно; (3) Страх снижения качества: команда опасалась, что дешёвая модель 'сломает' сложную логику терапий; (4) Нет метрик для проверки, что downgrade задачи безопасен.
Решение: Внедрена ярусная маршрутизация по модели учебника: (1) Определены ярусы: local-coder (Qwen2.5-Coder 7B локально) для черновиков и рутины, frontier-reviewer (GPT-4) только для критических ревью, спорных вердиктов и проверки красной кнопки; (2) Введён хранитель бюджета — внешний скрипт с суточной квотой токенов по ярусам, блокирующий frontier при превышении; (3) Для каждой задачи создана guard-метрика: local_coder_acceptance_rate — доля задач, прошедших ревью frontier-модели без правок после генерации local-coder; (4) Пилот: 30% задач переведены на local-coder с автоматическим ревью frontier на выборке 10%.
Результат: Через 6 недель: снижение затрат на 62%, local_coder_acceptance_rate стабилизировалась на 78% (цель: 75%), среднее время выполнения рутинных задач снизилось с 4.2 мин до 1.1 мин (local-coder не требует сетевого вызова). Критические инциденты (конфликты терапий, жалобы) по-прежнему проходят frontier-reviewer. Хранитель бюджета сработал 3 раза, корректно отложив non-urgent frontier-задачи на следующие сутки без инцидентов.
Извлечённые уроки: Guard-метрика local_coder_acceptance_rate критична для доверия: без неё команда будет саботировать downgrade 'на всякий случай'
Хранитель бюджета должен быть внешним по отношению к агенту — Qwen Code сам бюджетом не управляет, это архитектурное ограничение
Пилот с выборочным ревью frontier даёт данные для обоснования масштабирования, а не слепого доверия к дешёвой модели
Ярусная маршрутизация требует обновления QWEN.md: few-shot примеры для local-coder и frontier-reviewer различаются по стилю и глубине
Связанные концепции: Ярус модели (tier, local-coder / frontier-reviewer)
Хранитель бюджета (budget keeper)
Парная контр-метрика (guard metric)
Аукцион теневых спецификаций (shadow specs)
Метрика иммунитета (immunity score)
Название: Spec Drift в контуре авто-ремедиации: как silent_p0 раскрыл скрытый кризис
Сценарий: В AgentClinic работал пайплайн авто-ремедиации: при отказе SMS-шлюза система автоматически переключалась на email-канал, фиксировала инцидент и уведомляла oncall. MTTR (среднее время восстановления) стабильно снижался: 12 мин → 8 мин → 5 мин. Казалось бы, успех.
Задача: При детальном аудите обнаружилось: 18% инцидентов P0 (полный отказ записи к критическим специалистам) проходили без человеческого подтверждения и без полной записи в audit trail. Агент 'исправлял' проблему переключением канала, но не эскалировал, когда email тоже был недоступен (редкий кейс, но критический). MTTR падал за счёт 'тихих' пропусков. Это классическое Goodhart-искажение: оптимизация одной метрики в ущерб системе.
Решение: Внедрён anti-Goodhart-контур: (1) К MTTR добавлена guard-метрика silent_p0 — доля P0 без human confirmation и полного audit trail; (2) Установлен manual_review_floor = 15% — минимум решений обязательно через человека; (3) Добавлена audit_trace_coverage — доля действий с полной цепочкой evidence; (4) Аварийный режим (red button) блокирует auto-deploy при silent_p0 > 10% или manual_review_rate < 15%; (5) Реплей (replay) исторических инцидентов через новый валидатор — шлюз: новая версия не ухудшает вердикты.
Результат: Первый прогон показал: silent_p0 = 18%, manual_review_rate = 12%, audit_trace_coverage = 73%. Red button = BLOCKED. Команда провела расследование, обновила mutable_rules в constitution.md: теперь при отказе обоих каналов (SMS+email) обязательна эскалация human-in-the-loop, не авто-ремедиация. Через 3 недели: silent_p0 = 4%, manual_review_rate = 22%, audit_trace_coverage = 97%, MTTR вырос до 9 мин (честное время, без тихих пропусков). Red button = UNLOCKED.
Извлечённые уроки: MTTR без guard-метрик — опасная 'метрика-приманка': легко оптимизировать в ущерб безопасности
silent_p0 раскрывает именно то, что MTTR скрывает — это его единственная и критичная функция
manual_review_floor — не бюрократия, а защита от вытеснения человека из контура
Реплей исторических кейсов — единственный способ доказать, что 'улучшение' не ухудшило старые сценарии
Аварийный режим должен быть формальным шлюзом с проверяемыми условиями, а не 'красной кнопкой' на словах
Связанные концепции: Тихий P0 (silent_p0)
Парная контр-метрика (guard metric, anti-Goodhart)
Аварийный режим (red button)
Реплей (replay)
Минимум ручной проверки (manual_review_floor)
Покрытие аудит-трейса (audit_trace_coverage)
Дрейф спецификации (spec_drift, edge_drift)
Название: Мутационное тестирование спецификации записи: от poisoned spec к вакцинированному валидатору
Сценарий: В AgentClinic обновили логику приоритета записи: раньше приоритет определялся только срочностью (urgent/elective), теперь добавился фактор 'хроничность заболевания' (chronic flag). Новая спецификация выглядела корректной, но при интеграционном тестировании возникли конфликты: хронический пациент с elective-записью получал приоритет выше, чем urgent-пациент без chronic flag, нарушая старый инвариант 'urgent всегда первый'.
Задача: (1) Ручное тестирование не выявило конфликт — тестировщики проверяли флаги по отдельности; (2) Старый валидатор пропускал кейс, потому что спецификация формально не нарушала Given/When/Then — конфликт был в неявном приоритете; (3) Нужно было 'вакцинировать' валидатор: научить его находять именно такие логические дефекты.
Решение: Применено мутационное тестирование по модели учебника: (1) Создана ядовитая спецификация (poisoned spec) — копия новой спецификации с внесённым оператором PriorityContradiction: одно правило понижает urgent до high при chronic=false, другое возвращает high в urgent при chronic=true без tie_breaker; (2) Ожидаемый отказ: PRIORITY_REVERSAL; (3) Валидатор прошёл через цикл мутаций: Nullify (поля chronic), FutureTime (временные метки записи), EscalationCycle (цикл эскалации приоритетов), PriorityContradiction; (4) Метрика иммунитета отслеживалась: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms; (5) Валидатор, не прошедший шлюз (recovery_time_p95_ms > 1200ms), отправлен на доработку.
Результат: После 3 итераций: strict_reject_rate = 94% (цель: 90%), depth_of_diagnostics = 4.2 шага (цель: 3+), recovery_time_p95_ms = 890ms (цель: <1200ms). Валидатор стабильно ловит PriorityContradiction на шаге 'When priority is calculated'. В production внедрена обновлённая спецификация с явным tie_breaker: urgent > chronic > elective, с таблицей разрешения конфликтов. Интеграционный конфликт устранён до деплоя.
Извлечённые уроки: Мутационное тестирование спецификаций — аналог unit-тестов для логики, но на уровне требований, не кода
Poisoned spec — не 'сломанный документ', а контролируемый учебный инструмент с известным дефектом
Метрика иммунитета — вектор, не скаляр: высокий strict_reject_rate при низком depth_of_diagnostics означает 'слепую строгость', бесполезную для диагностики
Операторы мутации должны быть классифицированы по типу дефекта, а не случайны — это позволяет целенаправленно усиливать валидатор
Вакцинация валидаторов — неразовая акция: при изменении спецификации нужен реплей старых мутантов
Связанные концепции: Ядовитая спецификация (poisoned spec)
Оператор мутации (mutation operator)
Метрика иммунитета (immunity score, strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms)
Контрпример (counterexample)
Стресс-спецификация (stress spec)
Реплей (replay)
Советы по изучению: Используйте глоссарий как справочник, не как учебник: открывайте термин, когда он встречается в конкретной главе или при заполнении файла. Правило чтения из README: 'имя файла или YAML/JSON-ключ можно оставить английским, но в объяснении выбирайте один русский смысл'
Создайте личную 'карту перевода': распечатайте таблицу перевода ключевых терминов и отмечайте те, которые вы уже использовали в своих артефактах. Цель: автоматизировать правильный выбор между прозой и техническим именем
Практикуйте 'прозовое объяснение' aloud: возьмите любой YAML-фрагмент из примеров и прочитайте его вслух, заменяя каждый ключ на русский эквивалент. Например, silent_p0_ratio: 0.18 → 'доля тихих P0: восемнадцать процентов'
Для визуального стиля: рисуйте схемы связей между артефактами. Например, цепочка: poisoned spec → mutation operator → immunity score → spec gate → judgment.md → precedents.md. Это помогает увидеть, как термины работают вместе, а не изолированно
Для кинестетического стиля: физически заполняйте шаблоны. Возьмите examples/templates/proposal.md и напишите реальный proposal для изменения в вашем проекте, затем проведите мысленный референдум
Используйте 'правило трёх контекстов': для каждого нового термина найдите его использование в (1) прозе объяснения, (2) YAML/JSON-ключе, (3) имени файла или CLI-команды. Это закрепляет двойное написание
Делайте 'аудит своих артефактов': раз в неделю проверяйте, не проскочил ли англицизм в прозу или не стали ли вы переводить техническое имя. Исправляйте — это тренирует дисциплину, критичную для командной работы
Для изучения anti-Goodhart: найдите в своём проекте 'метрику-приманку' — показатель, который легко оптимизировать в ущерб системе. Спроектируйте для неё guard-метрику по модели из части 10
Проходите capstone-досье поэтапно: не пытайтесь собрать все 13 частей сразу. Начните с одного реального инцидента в вашей практике и пройдите цикл: genealogy → spec → mutation → constitution → tribunal → metrics
Используйте учебный проект AgentClinic как 'ментальную песочницу': когда термин кажется абстрактным, спросите 'как это применилось бы в клинике записи?' — домен понятен, а маппинг на production-сценарии зафиксирован в приложении A
Дополнительные ресурсы: Исходный документ курса (глоссарий прикладного тома): Основной справочник, обновляется авторами; читать по мере прохождения частей, не целиком
Readme прикладного тома, раздел «обязательные артефакты первого прохода»: Минимальный набор для старта: capstone/ и 10 артефактов
Часть 1: spec archaeology (part-01-spec-archaeology.md): Ввод genealogy.md, восстановление спецификаций из legacy
Часть 2: poisoned specs (part-02-poisoned-specs.md): Ядовитые спецификации, антипаттерн ask_storm
Часть 3: project constitution (part-03-project-constitution.md): Immutable/mutable-разделы, governance_protocol, proposal.md
Часть 4: llm duel (part-04-llm-duel.md): Роли Verifier/Implementor, контрпримеры, repair.patch
Часть 5: stress specs (part-05-stress-specs.md): Мутационное тестирование, операторы мутации, метрики иммунитета
Часть 6: shadow specs (part-06-shadow-specs.md): Теневые спецификации, аукцион, scorebook, shadow-candidates.yaml
Часть 7: specification ci (part-07-specification-ci.md): Spec gate, шлюз спецификации, интеграция с GitHub
Часть 8: multi-agent tribunal (part-08-multiagent-tribunal.md): Файловый арбитраж, judgment.md, precedents.md, роль Coordinator
Часть 9: tier budgeting (part-09-tier-budgeting.md): Ярусная маршрутизация, local-coder/frontier-reviewer, budget keeper
Часть 10: goodhart metrics (part-10-goodhart-metrics.md): Anti-Goodhart, guard metrics, red button, silent_p0, replay
Часть 11: real api deployment (part-11-real-api-deployment.md): Readiness gate, dry run, evidence_ref, 25-балльная модель
Часть 12: production antipatterns (part-12-production-antipatterns.md): Связки между терминами, типичные ошибки внедрения
Часть 13: capstone (part-13-capstone.md): Итоговый пакет, полный production SDD-путь по инциденту
Приложение a: bridges to book (appendix-a-bridges-to-book.md): Соответствие учебного кода и production-инцидентов
Приложение b первого тома: agentclinic domain: Сущности домена для ментальных экспериментов
Глоссарий первого тома (../book/glossary.md): Базовые термины SDD, дополняемые production-уточнениями здесь
Шаблоны примеров (examples/templates/): proposal.md, judgment.md и другие — для практического заполнения
Runnable-примеры (examples/tribunal/, examples/stress-mutator/): Python stdlib-скрипты для локальных проверок, не стек основного приложения
Внешние фреймворки для сравнения: github spec kit, aws kiro: Референсные реализации SDD-цикла, сопоставление в приложении A первого тома
Резюме: Глоссарий прикладного тома — это операционная система production-SDD, где каждый термин имеет чёткое правило использования: русская проза для объяснений, английские технические имена для кода. Ключевые принципы: (1) Читайте по мере необходимости, не целиком; (2) Поддерживайте дисциплину двойного написания — она критична для командной коммуникации; (3) Все метрики — векторные и парные, guard-метрики защищают от Goodhart-искажения; (4) Арбитраж, конституция и прецеденты — не бюрократия, а формальная защита от непредсказуемого поведения агентов; (5) Мутационное тестирование и ядовитые спецификации — стандартный инструмент, не экзотика; (6) Capstone-досье связывает все части в воспроизводимый production-путь. Успешное освоение глоссария измеряется не знанием определений, а умением правильно заполнить judgment.md при спорном инциденте, спроектировать guard-метрику для новой фичи и провести арбитраж с понятными вердиктами для всех ролей.