Глоссарий прикладного тома

Сводный список терминов второго тома учебника. Определения дублируются здесь, чтобы в главах не возникало разночтений. Если термин уже введён в первом томе, здесь даётся production-уточнение и ссылка на главу второго тома, где он работает.

Не читайте глоссарий целиком перед началом второго тома. Для первого прохода достаточно понимать capstone/ и десять обязательных артефактов первого прохода (полный список — в README, раздел «Обязательные артефакты первого прохода»). Остальные термины открывайте тогда, когда они помогают заполнить конкретный файл или понять runnable-пример.

Правило чтения простое: имя файла или YAML/JSON-ключ можно оставить английским, но в объяснении выбирайте один русский смысл. Например, judgment.md — это файл решения по спору; tribunal — файловый арбитраж, а не отдельный продукт или встроенная команда Qwen Code.

Основные формы в прозе, которые рекомендуется использовать по умолчанию (английский ключ — только в кодовых блоках и при первом упоминании в скобках):

• «тихий P0» — в прозе; silent_p0, silent_p0_cap, silent_p0_ratio — везде в коде, YAML/JSON-ключах, командах и подписях метрик;
• «Spec CI» или «шлюз спецификации (Spec CI)» — в прозе; spec_gate — только как имя задачи в .github/workflows/spec-ci.yml;
• «файловый арбитраж» — в прозе; tribunal — только как имя каталога examples/tribunal/ и его скриптов;
• «аварийный режим» — в прозе; «красная кнопка» — как короткий ярлык; red_button, red_button_mttr_blindness — только как имена инвариантов в YAML.

Таблица перевода ключевых терминов

В прозе второго тома мы по умолчанию используем русский эквивалент термина и при первом упоминании в главе даём английский ключ в скобках, например: «пометка-доказательство (evidence_ref)». Эта таблица — рабочий справочник: какие термины переводятся, какие остаются на английском как технические имена, какие живут как составной русско-английский термин. Если глава использует только русский вариант, можно вернуться сюда и сверить, что за ним стоит.

Класс «техническое имя» означает идентификатор в YAML/JSON, имя CLI/скрипта, имя статуса или ключ конфигурации — его не трогаем. Класс «термин с двойным написанием» — англицизм используется как составной маркер процесса; в прозе вводим русский эквивалент, но допускаем оба написания. Класс «прозовый термин» — англицизм русифицируется целиком, в основном тексте остаётся только русская форма.

| judgment, judgment.md | решение по спору; имя файла не трогаем | термин с двойным написанием | | precedent, precedents.md | прецедент; имя файла не трогаем | термин с двойным написанием | | audit_trace_coverage | покрытие аудит-трейса (метрика, имя ключа сохраняем) | техническое имя | | shadow specs, shadow spec | теневые спецификации; в заголовках допускаем оба написания | термин с двойным написанием | | stress spec, stress-spec | стресс-спецификация | прозовый термин | | guard metric, guard-метрика | парная контр-метрика, guard-метрика | термин с двойным написанием | | kill switch | стоп-кран, kill switch | термин с двойным написанием | | playbook | плейбук | прозовый термин (заимствование) | | runbook | ранбук | прозовый термин (заимствование) | | readiness gate, readiness | шлюз готовности, готовность; имя пункта модели сохраняем | термин с двойным написанием | | rollback, rollback_condition | откат; ключ rollback_condition сохраняем | термин с двойным написанием | | dry run, dry-run | пробный прогон | прозовый термин | | webhook | вебхук | прозовый термин (заимствование) | | auction | аукцион | прозовый термин (заимствование) |

| tribunal | файловый арбитраж спорного изменения; техническое имя каталога и скриптов примера | техническое имя | | Verifier, Implementor, Safety, Coordinator | Верификатор, Имплементор, Safety (голосуют), Координатор (non-voting protocolist) — в прозе; имена ролей в YAML и в коде остаются английскими | термин с двойным написанием | | immunity score | метрика иммунитета (вектор) | прозовый термин | | tier (low/mid/high, local-coder, frontier-reviewer) | ярус (низкий/средний/высокий) в прозе; ключи и имена ролей в YAML — без перевода | термин с двойным написанием | | mutation, mutation testing | мутация, мутационное тестирование | прозовый термин (заимствование) | | coverage, coverage-check | покрытие, проверка покрытия | прозовый термин | | scope, scope-check, out-of-scope | область охвата, проверка области, выход за границы | прозовый термин | | failover | переключение при отказе, failover | термин с двойным написанием | | blast radius | радиус последствий, blast radius | термин с двойным написанием | | gate, spec gate | шлюз, шлюз спецификации (gate) | термин с двойным написанием |

| manual_review_floor, manual_review_rate | минимум ручной проверки, доля ручной проверки; ключи сохраняем | техническое имя | | genealogy, genealogy.md | генеалогия; имя файла не трогаем | термин с двойным написанием | | ttl, time to live | срок жизни (ttl); ключ сохраняем | техническое имя | | few-shot | образец-подсказка, few-shot | термин с двойным написанием | | scorebook | журнал оценок (scorebook); имя файла не трогаем | термин с двойным написанием | | pre-approved actions | заранее согласованные действия | прозовый термин | | quarantine | карантин | прозовый термин | | ask_storm, stage_regress, phase_context_loss | названия антипаттернов сохраняем как есть; в первом упоминании в главе даём короткий русский комментарий | техническое имя | | capstone, dossier | итоговый зачётный пакет, пакет доказательств | термин с двойным написанием |

Технические имена, которые остаются как есть и не переводятся ни в прозе, ни в таблицах: YAML/JSON-ключи (immutable_principles, mutable_rules, governance_protocol, incident_type, pipeline_phase, permitted_actions, max_scope, rollback_condition, decision_hash, parent_version, change_log, audit_trace, prompt_hash, decision_source, next_guard и подобные), имена файлов (QWEN.md, requirements.md, plan.md, validation.md, mission.md, tech-stack.md, roadmap.md, constitution.md, judgment.md, precedents.md, genealogy.md), имена CLI-команд и скриптов (qwen -p, python3 scripts/..., git, npm, rg), имена custom commands (/sdd:specify, /plan, /review), статусы (Стандарт / Рекомендация / Фронтир), маркеры блоков ([runnable], [project script]), аббревиатуры (MCP, CI, LLM, API, KPI, MTTR, SLO, SLA, SRE).

Где термин вводится впервые

Карта помогает быстро открыть главу, в которой термин впервые получает рабочее определение и сценарий применения. Метрики (silent_p0, audit_trace_coverage, manual_review_floor) и ключи памяти (shadow-scorebook.json, shadow-candidates.yaml, precedents.md, judgment.md) разнесены отдельно: метрики измеряют систему, ключи памяти хранят её историю.

| метрика | strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms | 5 | | метрика | mttr_gain, early_signal, coverage, false_escalation | 6 | | метрика | token_health_min, failover_to_frontier, degraded_queue | 9 | | метрика | silent_p0, manual_review_floor, audit_trace_coverage | 10 | | ключ памяти | .specify/memory/shadow-candidates.yaml, .specify/memory/shadow-scorebook.json | 6 | | ключ памяти | precedents.md, change_log | 3, 8 | | механизм | стресс-спецификация, мутационное тестирование | 5 | | механизм | теневая спецификация, аукцион, scorebook | 6 | | механизм | шлюз спецификации (Spec CI) | 7 | | механизм | ярусная маршрутизация, local-coder, frontier-reviewer, бюджетный хранитель | 9 | | механизм | парная контр-метрика, anti-Goodhart, аварийный режим | 10 |

| механизм | dry-run, readiness gate, evidence_ref | 11 |

Если термин встречается в нескольких частях, в столбце указана та, где он получает рабочее определение и runnable-сценарий. Production-уточнения и связки между терминами разобраны в части 12 и части 13.

Связь с глоссарием первого тома

Этот глоссарий дополняет, а не заменяет глоссарий первого тома. Базовые термины SDD — QWEN.md, mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md, навыки Qwen Code, MCP, ACP, EARS, Given/When/Then — определены там и здесь не повторяются.

Production-уточнения накладываются на эти базовые термины:

• validation.md первого тома содержит факты допуска к слиянию; во втором томе он же дополняется failing case дуэли, anti-Goodhart-проверками, drift-полями и trace-записями.
• QWEN.md первого тома хранит постоянный контекст агента; во втором томе он же становится местом размещения few-shot из аукциона shadow specs со сроком пересмотра.

• Конституция первого тома фиксирует mission.md + tech-stack.md + roadmap.md; во втором томе она расширяется явным разделом constitution.md с immutable_principles, mutable_rules и governance_protocol.

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

Учебный проект AgentClinic

Production-сценарии прикладного тома мысленно разворачиваются на учебном проекте AgentClinic из первого тома: TypeScript, Hono, серверный JSX, SQLite, Vitest. Python относится к runnable-примерам второго тома: это маленькие stdlib-скрипты для локальных проверок, а не стек основного приложения. Сущности домена — агенты-пациенты, недуги, терапии, записи на приём, отзывы, обратная связь — описаны в приложении B первого тома. Соответствие между учебным кодом и production-инцидентами зафиксировано в таблице приложения A прикладного тома.

Образные названия

В главах иногда используются образные названия. Они нужны как вспомогательные ярлыки, а не как основные названия процесса. Инженерные эквиваленты такие:

• Восстановление спецификаций — восстановление требований из legacy-кода, логов, инцидентов и истории решений; «Spec-некромантия» допустима только как вспомогательный ярлык.
• Ядовитая спецификация — намеренно сломанная учебная спецификация с одним контролируемым дефектом.
• Вакцинация валидаторов — мутационное тестирование (mutation testing) для спецификаций и проверок.
• Аукцион теневых спецификаций (shadow specs) — оценка и ранжирование неформальных эвристик перед включением в рабочий контекст.
• Файловый арбитраж спорного изменения — см. ниже раздел «Файловый арбитраж»; tribunal в именах файлов и каталогов остаётся техническим ярлыком примера.
• Ярусная маршрутизация моделей — распределение задач между моделями разной стоимости и качества.
• Метрики-приманки — KPI, которые легко оптимизировать в ущерб системе; инженерная защита — парные контр-метрики (guard metrics).
• Аварийный режим (red button) — формальный шлюз безопасности перед опасным действием: деплоем, откатом, миграцией или авто-ремедиацией; «красная кнопка» — разговорный ярлык.

Роли агентов

Верификатор (Verifier) — агент или сессия, чья единственная задача — искать нарушения инвариантов, контракта и фактов. Не имеет права писать код или менять артефакты, только выносит вердикт approve / reject / abstain с обоснованием. Подробнее — в части 4 и части 8.

Имплементор (Implementor) — агент, который выполняет план в auto-edit режиме после утверждённой спецификации. В файловом арбитраже голосует за применимость поправки в плейбуке, но не имеет права обходить вердикт Верификатора или роли Safety.

Координатор (Coordinator) — роль (человек, CI job или внешний оркестратор), которая принимает финальное решение по результатам файлового арбитража, фиксирует прецедент и публикует judgment.md. Не голосует наравне с Верификатором, Имплементором и Safety; отвечает за процедуру, а не за содержание.

Safety — отдельная роль в governance_protocol, которая проверяет blast radius, приватность, защиту резервных копий и условия отката. Имеет veto при critical_risk: даже при двух approve от Verifier и Implementor поправка отклоняется. Подробнее — в части 3.

**Ярус модели (tier, local-coder / frontier-reviewer)** — уровень модели в ярусной маршрутизации. local-coder — дешёвая локальная модель для генерации кода и черновиков; frontier-reviewer — дорогая frontier-модель, которая используется только на критических ревью, спорных вердиктах и проверках красной кнопки. Подробнее — в части 9.

Хранитель бюджета (budget keeper) — внешний сервис или скрипт, который следит за суточной квотой токенов по ярусам и блокирует обращения к frontier-моделям при превышении лимита. Qwen Code сам бюджетом не управляет.

Спецификации и артефакты

Теневая спецификация (shadow spec) — спецификация для неформализуемых нюансов: интонации, негласных приоритетов, исторических решений, которые не попали в основной requirements.md. Хранится отдельно, побеждает в аукционе на основе журнала оценок (scorebook), не подменяет основную спецификацию. Подробнее — в части 6.

Журнал оценок (scorebook) — журнал оценок теневых спецификаций: формула, веса, бюджет, пороги и компоненты mttr_gain, early_signal, coverage, false_escalation для каждого кандидата. Файл вида .specify/memory/shadow-scorebook.json; создаётся или обновляется прогоном аукциона.

Ядовитая спецификация (poisoned spec) — учебная спецификация, в которую сознательно внесён один дефект: цикл эскалации, конфликт приоритетов или скрытый выход за границы (hidden out-of-scope). Используется для тренировки Верификатора и валидаторов. Подробнее — в части 2.

Скрытый выход за границы (hidden out-of-scope) — действие, которое спецификация формально не запрещает, но и не описывает, и которое агент склонен выполнить «по дороге». Пример: спецификация просит изменить маршрутизацию алерта, агент дополнительно правит SLA-политику. Защита — явный раздел «За границами» и шлюз Spec CI.

Override-правило — изменяемая норма в constitution.md, которая разрешает агенту обойти стандартное поведение в узком контексте: для конкретного incident_type, на конкретной pipeline_phase, с ограниченным max_scope и обязательным ttl. Без этих ограничений правило начинает конкурировать с инвариантами.

Immutable principle — правило в immutable_principles раздела constitution.md, которое не может быть отключено автоматически: запрет на restart production-БД без бэкапа, на удаление резервных копий, на bypass в security-critical namespace. Меняется только через явный референдум команды, не через голосование агентов.

Mutable rule — правило в mutable_rules раздела constitution.md с обязательными полями incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition. Эволюционирует через референдум при накоплении непредсказанных инцидентов.

**proposal.md** — отдельный файл поправки к constitution.md, который проходит как изменение контракта риска. Содержит version, parent_version, обоснование, изменения в mutable_rules, ожидаемый эффект и rollback_condition. Шаблон — [examples/templates/proposal.md](examples/templates/proposal.md); процедура референдума — в части 3.

**precedents.md** — журнал прецедентов файлового арбитража: каждое разрешённое разногласие фиксируется как запись case_ref, нарушенное правило, итоговый вердикт и ссылка на judgment.md. Используется как кратчайший путь к решению повторяющихся споров; формат — в части 8.

**genealogy.md** — провенанс восстановленной спецификации: для каждого требования — список источников, уровень уверенности (confirmed, inferred, hypothesis) и открытый вопрос. Создаётся при восстановлении спецификации из унаследованного контекста; подробнее — в части 1.

Шлюз спецификации (spec gate) — CI-проверка, блокирующая merge, если спецификация не покрыта планом, план — задачами, или задачи — фактами в validation.md. Конкретный пример — spec_gate в части 7.

Итоговый пакет (capstone dossier) — набор файлов из части 13, который показывает полный production SDD-путь по одному инциденту: происхождение требования, ядовитый дефект, исправление, конституцию, проверку, вердикт, бюджет, anti-Goodhart-ограничители, readiness и аудит антипаттернов.

Метрики иммунитета и Goodhart-защита

Метрика иммунитета (immunity score) — вектор оценок валидатора, а не одна итоговая цифра. Состоит из трёх компонент: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms. Используется как шлюз валидаторного контура при мутационном тестировании спецификаций.

**strict_reject_rate** — доля вырожденных кейсов (мутантов), которые отклонены строго на ожидаемом шаге Given/When/Then. Рост этой метрики при падении depth_of_diagnostics означает, что валидатор стал строже, но «слепее».

**depth_of_diagnostics** — полезная глубина объяснения до отказа: сколько шагов трассировки валидатор прошёл, прежде чем вернуть verdict. Глубина 1 — это «отказано», глубина 3+ — «отказано, потому что поле X в шаге Y нарушает правило Z».

**recovery_time_p95_ms** — p95 времени (в миллисекундах), за которое валидатор возвращает стабильный verdict и диагностический маршрут после изменения спецификации. Превышение порога (например, 1200ms) провоцирует обходные практики и тормозит CI.

**silent_p0** — доля инцидентов уровня P0, которые прошли через автоматизацию без человеческого подтверждения и без записи в audit trail. Anti-Goodhart-метрика: если MTTR падает, а silent_p0 растёт, авто-ремедиация ускоряется за счёт скрытых рисков. Подробнее — в части 10.

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

**audit_trace_coverage** — доля действий агента, для которых сохранена полная цепочка evidence: входной payload, версия спецификации, версия конституции, vote-лог, decision_hash. Целевое значение — 100%; падение блокирует merge и red button.

Anti-Goodhart (анти-Гудхарт) — общий приём проектирования метрик в паре с антителами. Каждой целевой метрике (MTTR, edge_drift) сопоставляется метрика-страж (silent_p0, manual_review_floor, audit_trace_coverage), и CI-шлюз проходит только при одновременном выполнении обеих.

Мутации и стресс-тестирование

Оператор мутации (mutation operator) — функция, которая берёт корректную спецификацию и вносит ровно один дефект известного класса. Каждой мутации присваивается mutation_id, ожидаемый expected_failure и шаг halt_before. Подробнее — в части 5.

Nullify — оператор, который обнуляет обязательное поле (service_id, owner, timestamp). Ожидаемый отказ — EMPTY_REQUIRED_FIELD до расчёта SLA.

FutureTime — оператор, ставящий response_timestamp в будущее или создающий отрицательную задержку реакции. Ожидаемые коды — INVALID_TIME_ANCHOR, NEGATIVE_RESPONSE_LAG, STALE_INCIDENT_WINDOW.

EscalationCycle — оператор, который добавляет в граф маршрутов эскалации обратное ребро (traffic_sre → edge_oncall при уже существующем edge_oncall → traffic_sre). Ожидаемый отказ — CYCLE_ESCALATION с минимальным циклом в диагностике.

RecursiveDependency — оператор, создающий косвенную рекурсию между вычисляемыми полями: owner зависит от priority, priority — от blast_radius, blast_radius — снова от owner. Ожидаемый отказ — RECURSION_LIMIT с цепочкой полей. В runnable-примере examples/stress-mutator/ не реализован — описан как будущее расширение в части 5.

PriorityContradiction — оператор, при котором одно правило понижает P1 до P2, а другое возвращает P2 в P1 без tie_breaker. Ожидаемый отказ — PRIORITY_REVERSAL; защита — политика разрешения конфликтов, а не граф маршрутов.

Файловый арбитраж

**Файловый арбитраж спорного изменения (tribunal в именах примеров)** — процедура коллегиального решения по спорной поправке или инциденту: Верификатор, Имплементор и Safety голосуют по фиксированному протоколу, Координатор оформляет judgment.md. Не встроенная команда Qwen Code; реализуется как комбинация /review, скриптов и правил.

Прецедент (precedent) — запись в precedents.md о повторяющемся типе конфликта и принятом разрешении. Используется как tie-breaker latest_matching_precedent в governance_protocol и снижает стоимость следующего арбитража.

**Решение по спору (judgment.md)** — итоговый артефакт файлового арбитража: журнал голосов, decision_hash, ссылки на спецификацию, конституцию и инцидент, активные ttl и rollback_condition. Хранится в репозитории как неизменяемый след.

Генеалогия (genealogy) — цепочка parent_version → version в change_log конституции и в журнале решений. Позволяет восстановить, почему агент в момент инцидента имел право на конкретное действие, и пересчитать решение постфактум.

Контроль исполнения

Аварийный режим (red button) — формальный шлюз перед потенциально опасным действием в production: откат, миграция, массовое обновление конфигурации. В разговорном тексте может называться «красной кнопкой», но в артефактах фиксируйте условия включения режима. Срабатывает только при выполнении всех anti-Goodhart-метрик; пример из части 10 — red_button = BLOCKED (MTTR=4:50, silent_p0=18%, manual_review_rate=12%).

Радиус последствий (blast radius) — максимально возможная зона воздействия одного действия агента: количество узлов, namespace'ов, пользователей, объём данных. Указывается в mutable_rules как max_scope и проверяется шлюзом до выполнения.

Срок жизни (TTL) — срок жизни mutable-правила или временного исключения (override). Без ttl поправка становится бессрочной и превращается в скрытую часть инварианта.

Условие отката (rollback condition) — условие отмены mutable-правила: рост повторных инцидентов, veto от Safety, превышение порога silent_p0. Должно быть проверяемым автоматически, а не оставаться текстовой формулировкой.

Доказательная база

Цепочка доказательств (evidence chain) — структурированная цепочка артефактов, привязанная к решению агента: входной payload, версия спецификации, активные правила конституции, журнал голосов арбитража, diff применённого изменения, проверки постусловий. Минимальное требование для production SDD.

Провенанс (provenance) — происхождение спорного требования или правила: автор, источник (тикет, инцидент, регуляторный документ), дата, уровень неопределённости. Позволяет отделить «команда так договорилась» от «требование пришло из аудита».

Реплей (replay) — повторное проигрывание исторических инцидентов через текущий валидатор и текущую конституцию. Используется как шлюз в Goodhart-метриках: новая версия не должна ухудшать вердикты на уже разобранных кейсах. Подробнее — в части 10.

Дрейф (drift) — расхождение между спецификацией, реализацией и тем, что реально делает агент в production. В прикладном томе различают три вида: spec_drift (спецификация устарела), code_drift (реализация ушла от плана), edge_drift (валидатор начал по-другому реагировать на пограничные случаи).

Антипаттерны процесса

**ask_storm** — состояние, когда агент в цикле задаёт уточняющие вопросы вместо остановки. Контрольная строка из части 2: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. Признак ядовитой или внутренне противоречивой спецификации.

**stage_regress** — откат на предыдущую фазу SDD-цикла без явной причины: implement возвращается в plan, plan — в specify. Лечится привязкой каждой фазы к фактам в validation.md и фиксированным критериям перехода.

**phase_context_loss** — потеря контекста между фазами: specify зафиксировал решение, plan его не унаследовал, implement действует по черновику. Защита — явные ссылки @specs/... и project skill, который проверяет наследование между фазами.

Внешние SDD-фреймворки

GitHub Spec Kit — открытый фреймворк со стандартным циклом /constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement. Используется во втором томе как референс для Spec CI и spec gate.

AWS Kiro — IDE с собственной моделью SDD: spec'и (requirements.md + design.md + tasks.md), steering-файлы, агентные хуки. Сопоставление с учебником — в Приложении A первого тома.