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

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

Не читайте глоссарий целиком перед началом второго тома. Для первого прохода достаточно понимать `capstone/` и десять обязательных артефактов первого прохода (полный список — в [README, раздел «Обязательные артефакты первого прохода»](README.md#обязательные-артефакты-первого-прохода)). Остальные термины открывайте тогда, когда они помогают заполнить конкретный файл или понять 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/скрипта, имя статуса или ключ конфигурации — его не трогаем. Класс «термин с двойным написанием» — англицизм используется как составной маркер процесса; в прозе вводим русский эквивалент, но допускаем оба написания. Класс «прозовый термин» — англицизм русифицируется целиком, в основном тексте остаётся только русская форма.

| Английская форма | Русский эквивалент | Класс |
|---|---|---|
| `evidence_ref` | пометка-доказательство, ссылка на доказательство | прозовый термин |
| `evidence`, `evidence chain` | доказательства, цепочка доказательств | прозовый термин |
| `counterexample` | контрпример | прозовый термин |
| `silent_p0` | тихий P0 (инцидент) | техническое имя |
| `red button` | аварийный режим; «красная кнопка» как короткий ярлык | термин с двойным написанием |
| `provenance` | провенанс, происхождение, источник происхождения | прозовый термин |
| `drift`, `edge_drift`, `spec_drift`, `code_drift` | дрейф (поведения, спецификации, кода); ключи метрик не трогаем | термин с двойным написанием |
| `escalation` | эскалация (заимствование закреплено в русском) | прозовый термин |
| `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`) разнесены отдельно: метрики измеряют систему, ключи памяти хранят её историю.

| Группа | Термин | Вводится в части |
|---|---|---|
| роли | Верификатор, Имплементор (голосуют) | [4](part-04-llm-duel.md) |
| роли | Safety (голосует), Координатор (non-voting), `governance_protocol` | [3](part-03-project-constitution.md), [8](part-08-multiagent-tribunal.md) |
| артефакт | `genealogy.md` | [1](part-01-spec-archaeology.md) |
| артефакт | poisoned/fixed-пара | [2](part-02-poisoned-specs.md) |
| артефакт | `constitution.md`, immutable/mutable, `ttl`, `rollback_condition` | [3](part-03-project-constitution.md) |
| артефакт | контрпример, `repair.patch`, `schema_delta` | [4](part-04-llm-duel.md) |
| артефакт | `judgment.md`, `precedents.md`, `decision_hash` | [8](part-08-multiagent-tribunal.md) |
| артефакт | `readiness.md`, 25-балльная модель | [11](part-11-real-api-deployment.md) |
| метрика | `strict_reject_rate`, `depth_of_diagnostics`, `recovery_time_p95_ms` | [5](part-05-stress-specs.md) |
| метрика | `mttr_gain`, `early_signal`, `coverage`, `false_escalation` | [6](part-06-shadow-specs.md) |
| метрика | `token_health_min`, `failover_to_frontier`, `degraded_queue` | [9](part-09-tier-budgeting.md) |
| метрика | `silent_p0`, `manual_review_floor`, `audit_trace_coverage` | [10](part-10-goodhart-metrics.md) |
| ключ памяти | `.specify/memory/shadow-candidates.yaml`, `.specify/memory/shadow-scorebook.json` | [6](part-06-shadow-specs.md) |
| ключ памяти | `precedents.md`, `change_log` | [3](part-03-project-constitution.md), [8](part-08-multiagent-tribunal.md) |
| механизм | стресс-спецификация, мутационное тестирование | [5](part-05-stress-specs.md) |
| механизм | теневая спецификация, аукцион, scorebook | [6](part-06-shadow-specs.md) |
| механизм | шлюз спецификации (Spec CI) | [7](part-07-specification-ci.md) |
| механизм | ярусная маршрутизация, `local-coder`, `frontier-reviewer`, бюджетный хранитель | [9](part-09-tier-budgeting.md) |
| механизм | парная контр-метрика, anti-Goodhart, аварийный режим | [10](part-10-goodhart-metrics.md) |
| механизм | dry-run, readiness gate, `evidence_ref` | [11](part-11-real-api-deployment.md) |

Если термин встречается в нескольких частях, в столбце указана та, где он получает рабочее определение и runnable-сценарий. Production-уточнения и связки между терминами разобраны в [части 12](part-12-production-antipatterns.md) и [части 13](part-13-capstone.md).

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

Этот глоссарий **дополняет**, а не заменяет [глоссарий первого тома](../book/GLOSSARY.md). Базовые термины 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 первого тома](../book/appendix-b-agentclinic-domain.md). Соответствие между учебным кодом и production-инцидентами зафиксировано в таблице [приложения A прикладного тома](appendix-a-bridges-to-book.md).

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

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

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

## Роли агентов

**Верификатор (Verifier)** — агент или сессия, чья единственная задача — искать нарушения инвариантов, контракта и фактов. Не имеет права писать код или менять артефакты, только выносит вердикт `approve / reject / abstain` с обоснованием. Подробнее — в [части 4](part-04-llm-duel.md) и [части 8](part-08-multiagent-tribunal.md).

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

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

**Safety** — отдельная роль в `governance_protocol`, которая проверяет blast radius, приватность, защиту резервных копий и условия отката. Имеет veto при `critical_risk`: даже при двух `approve` от Verifier и Implementor поправка отклоняется. Подробнее — в [части 3](part-03-project-constitution.md).

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

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

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

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

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

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

**Скрытый выход за границы (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](part-03-project-constitution.md).

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

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

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

**Итоговый пакет (capstone dossier)** — набор файлов из [части 13](part-13-capstone.md), который показывает полный 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](part-10-goodhart-metrics.md).

**`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](part-05-stress-specs.md).

**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](part-10-goodhart-metrics.md) — `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](part-10-goodhart-metrics.md).

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

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

**`ask_storm`** — состояние, когда агент в цикле задаёт уточняющие вопросы вместо остановки. Контрольная строка из [части 2](part-02-poisoned-specs.md): `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 первого тома](../book/appendix-a-sdd-dialects.md).