07. ADAPT — двусторонняя адаптация ТЗ¶

Часть RENAR Standard v1.0 · ← Оглавление

7.1 Что такое ADAPT и зачем он¶

Клиент присылает ТЗ на своём языке — языке бизнеса и договора. Оно подписано и больше не меняется: это контракт. Но превратить его в точные требования напрямую почти никогда не выходит. Где-то ТЗ молчит о важном («экспорт данных» — в каком формате? за какой срок?), где-то противоречит само себе, где-то один и тот же термин значит у клиента и у инженера разное. Редактировать ТЗ нельзя — договор. Молча додумать за клиента тоже нельзя: так в требования просачиваются чужие домыслы, а на приёмке всплывает «мы не это заказывали».

ADAPT — мост через этот разрыв. У него две стороны: прямая интерпретация («раздел §4.2 ТЗ мы поняли так-то») и обратные находки («§4.3 не задаёт срок — уточните»), которые выносятся клиенту и возвращаются его решениями.

Но документ, который читает клиент, и документ, которым живёт инженер, — разные документы. Решения, вынесенные клиенту и подписанные, — это обязательства, и они живут в отдельном артефакте: ACTZ, протоколе уточнения ТЗ (§7.13). ADAPT остаётся внутренней интерпретацией: его подписывает только архитектор, клиент его не видит. Граница проводится не по содержанию записи, а по аудитории — всё, что показано клиенту и утверждено, есть обязательство; всё, что не показано, есть интерпретация. Так исчезает неразрешимый спор «это толкование или уже изменение».

ADAPT не обязан предшествовать всей деривации. Типовой повод его создать — импорт ТЗ, но вопрос к клиенту с корнем в ТЗ может всплыть и позже — уже в ходе декомпозиции BR → SR → SPEC или при разработке тест-кейсов. Тогда возникает новый ADAPT, привязанный к той стадии, где находка обнаружена, а ранее выведенные артефакты остаются валидными. ADAPT создаётся не всегда: если конвертация соответствующего фрагмента ТЗ однозначна и вопросов нет, он не нужен (§7.4.1).

ADAPT — следствие Утверждения 2 из §2.4 (RENAR — waterfall-форма ≠ классический waterfall, потому что ADAPT обеспечивает двустороннюю адаптацию вместо «переброса спецификации через забор»).

7.2 Проблема, которую нормирует ADAPT¶

Без формализованного промежуточного артефакта между ТЗ и BR/SR возникает один из двух негативных исходов:

Исход	Что происходит
Дрейф ТЗ	ТЗ редактируется после подписания → нарушается договор
Скрытая интерпретация	Инженерные предположения молча просачиваются в BR/SR/SPEC → разрушается цепочка прослеживаемости и происхождение

ADAPT исключает оба исхода: ТЗ остаётся неизменяемым договорным документом, все интерпретации, уточнения и обратные находки регистрируются в ADAPT, который сам становится неизменяемым после подписи архитектора (§7.5), а решения клиента — в подписанных обеими сторонами ACTZ (§7.13).

7.3 Цикл двусторонней адаптации¶

        ┌───────────────────────────────┐
        │   ТЗ (immutable, договор)     │
        └───────────────┬───────────────┘
                        │ источник
                        ▼
┌──────────────────────────────────────────────┐
│              ADAPT-NNN                       │
│                                              │
│  Прямая интерпретация (инженер → клиент)     │
│  ─ по разделам ТЗ                             │
│  ─ сопоставление терминов                     │
│  ─ достроенные сценарии                      │
│  ─ уточнение границы работ                    │
│                                              │
│  Обратные находки (инженер → клиент)         │
│  ─ 7 категорий записей                       │
│  ─ жизненный цикл: open → asked → answered →  │
│              resolved → frozen               │
│                                              │
│  Status: draft → review → answered →         │
│         approved → frozen                    │
│  Approval: подпись архитектора (§7.5)        │
└────────────────────┬─────────────────────────┘
                     │ approved
                     ▼
        ┌───────────────────────────────┐
        │   BR / SR / SPEC              │
        │   ссылаются на ADAPT§         │
        │   через source.adapt          │
        └───────────────────────────────┘

ТЗ — первоисточник; ADAPT — канонический источник интерпретации; BR/SR/SPEC ссылаются на ADAPT, а не на ТЗ напрямую.

Показанный вход «ТЗ → ADAPT» — типовой (импорт ТЗ), но не единственный. Триггер цикла стадийно-независим: если вопрос к клиенту с корнем в ТЗ всплывает позже — на стадии декомпозиции BR → SR → SPEC или при разработке TC, — цикл запускается повторно и порождает новый ADAPT-NNN, привязанный к стадии, на которой находка обнаружена (§7.4.1.1). На одно ТЗ таких ADAPT может быть несколько (MVR-3, §0.5).

7.4 Нормативные требования к ADAPT¶

7.4.1 Реактивная обязательность¶

ADAPT — реактивный артефакт: создаётся тогда и только тогда, когда конвертация ТЗ → RENAR-описание порождает разрыв между языком клиента и языком требований (§7.12). Если конвертация однозначна — ADAPT не создаётся, BR / SR / SPEC выводятся напрямую из ТЗ через обязательное поле source.tz-section.

7.4.1.1 Условия обязательности ADAPT¶

ADAPT обязателен тогда и только тогда, когда хотя бы одно из условий выполнено:

Backward finding обнаружена. Состязательный рецензент (§7.10.2) на любой стадии жизненного цикла требований (импорт ТЗ либо декомпозиция BR → SR → SPEC → TC) выявил ≥ 1 запись хотя бы по одной из 7 категорий §7.4.4 (contradiction, gap, hidden-assumption, feasibility, regulatory, terminology, scope) с корнем в языке или намерении ТЗ.
Требуется сопоставление терминов (term mapping). ТЗ использует термин, не имеющий однозначной инженерной интерпретации (требует сопоставления «клиент → инженер»).
Требуется уточнение границы работ. Граница работ из ТЗ неоднозначна и требует фиксации «входит / не входит».

Если ни одно условие не выполнено (состязательный рецензент выдал вердикт «no findings, no clarifications») — ADAPT не создаётся. BR / SR / SPEC ссылаются на ТЗ напрямую через source.tz-section (§6.5.2, §6.6.2, §8.5).

7.4.1.2 Состязательный рецензент как обязательный гейт¶

Состязательный обзор ТЗ (§7.10.2) — обязательный шаг для каждого ТЗ при импорте, независимо от того, создаётся ADAPT или нет. Вердикт при импорте — однократный, но не финальный: на стадиях деривации (BR → SR → SPEC → TC) состязательный рецензент выносит вердикт повторно, по мере того как декомпозиция вскрывает новые вопросы к ТЗ. Вердикт «no findings» при импорте не блокирует появление ADAPT позже, если на стадии декомпозиции обнаружится находка с корнем в ТЗ (§7.7.3). Состязательный рецензент выносит формальный вердикт в одной из двух форм:

Вердикт	Что фиксируется	Следствие
«findings present»	Список конкретных findings по 7 категориям + указание разделов ТЗ	ADAPT обязателен; жизненный цикл §7.4.5 запускается
«no findings, no clarifications»	Подтверждение состязательного рецензента (другая модель, §9.4) что ТЗ конвертируется в RENAR однозначно	ADAPT можно не создавать; вердикт остаётся зафиксированным свидетельством

В обоих исходах вердикт обязан быть зафиксирован в записи состязательного обзора (AR, §7.4.6) — неизменяемой после выпуска записи-свидетельстве с собственным идентификатором, автором и отметкой времени (V6). AR — единственный носитель вердикта: при исходе «findings present» она указывает на порождённый ADAPT, при исходе «no findings» она сама является тем свидетельством, на которое ссылается поле source.adversarial-review-ref (§6.5.2).

Hook (§10.11.1 adapt-applicability validation) при создании BR / SR / SPEC без source.adapt проверяет наличие AR со статусом issued и валидным вердиктом для соответствующего ТЗ. Отсутствие такой записи — fatal: создание блокируется до прохождения состязательного обзора.

7.4.1.3 Запрет молчаливого пропуска¶

Создание BR / SR / SPEC из ТЗ без состязательного обзора (пропуск ADAPT без вердикта) — нарушение стандарта. Это сохраняет инверсию источника истины (§2.3): «no findings» — это зафиксированное утверждение состязательного рецензента, не молчаливое допущение архитектора. Вердикт обязан быть выпущен как AR (§7.4.6) с автором и отметкой времени (V6) и доступен по запросу аудитора (§13.5).

При наличии delta-ТЗ — то же правило: delta-ADAPT создаётся реактивно, по факту находок при состязательном обзоре delta-ТЗ (§7.6).

7.4.1.4 Множественность ADAPT на одно ТЗ¶

Поскольку триггер стадийно-независим (§7.4.1.1), на одно немодифицированное ТЗ может приходиться ноль или более корневых ADAPT (cardinality 0..N — переформулировка MVR-3, §0.5):

ноль — состязательный обзор на всех стадиях вынес «no findings»;
один — находка обнаружена однократно (как правило при импорте);
несколько — находки с корнем в ТЗ возникали на разных стадиях деривации (импорт, затем декомпозиция BR → SR и т. д.).

Каждый ADAPT сохраняет стабильный сквозной ADAPT-NNN и фиксирует поле trigger-stage — стадию, на которой он порождён (§7.8.1). Множественность — штатный случай, а не исключение, и не ослабляет провенанс: каждый BR / SR / SPEC по-прежнему ссылается ровно на один ADAPT (через source.adapt) либо напрямую на ТЗ (через source.tz-section), из которого выведен.

7.4.2 Неизменяемость ТЗ¶

ТЗ — договорной документ. После регистрации ТЗ в носителе его содержимое не редактируется. Если в ходе работы выясняется, что в ТЗ ошибка / пропуск / противоречие — это регистрируется как обратная находка в ADAPT (§7.4.4), клиент даёт ответ, ответ становится частью ADAPT. ТЗ остаётся неизменяемым.

При большом количестве правок или при изменении границы работ — клиент подписывает delta-ТЗ как новый неизменяемый документ (§7.6).

7.4.3 Прямая адаптация ТЗ¶

Раздел прямой интерпретации ADAPT для каждого раздела ТЗ обязан содержать:

Элемент	Обязательность	Цель
Точная ссылка на ТЗ§N.N	обязательно	происхождение
Цитата из ТЗ (или пересказ с явной пометкой)	обязательно	Контекст
Инженерная интерпретация раздела	обязательно	Перевод языка клиента → язык требований
Сопоставление терминов (клиент → инженер)	обязательно если применимо	Дезамбигуация терминов
Достроенные сценарии	обязательно если ТЗ их подразумевает	Явная фиксация неявных случаев
Уточнение границы работ (входит / не входит)	обязательно	Граница работ
Ссылки из прямой интерпретации на BR/SR/SPEC	auto-derived	Цепочка прослеживаемости (§7.7)

7.4.4 Обратные находки и их категории¶

Раздел обратных находок ADAPT фиксирует обнаруженные проблемы по семи нормативным категориям. Список категорий закрыт на v1.0; добавление новых категорий — через формальную процедуру изменения стандарта (см. глава 13). Общая политика закрытого списка и master-индекс — §1.7.5.

ID	Категория	Что регистрируется
`contradiction`	Противоречие	Внутренние противоречия в ТЗ (§A vs §B)
`gap`	Пропуск	ТЗ молчит о том, без чего невозможна реализация
`hidden-assumption`	Скрытое предположение	Предположение инженера, которое может быть неверно
`feasibility`	Реализуемость	Технически нереализуемое или непропорционально дорогое требование
`regulatory`	Регуляторика	Требование, затрагивающее законодательство / compliance
`terminology`	Терминология	Неясный термин ТЗ с несколькими возможными значениями
`scope`	Скоп	Неясная граница работ

Каждая запись об обратной находке имеет стабильный ID (B-NNN), неизменяемый после создания. ID не переиспользуется даже для отозванных записей (журнал аудита).

7.4.5 Жизненный цикл одной записи об обратной находке¶

open → asked-to-client → answered → resolved → frozen
              ↑                          │
              └────── revised ───────────┘  (если ответ требует уточнения)

Статус	Что значит
`open`	Инженер записал; не вынесено клиенту
`asked-to-client`	Вопрос вынесен клиенту в составе ACTZ (§7.13); ожидается подписание; зафиксирована дата
`answered`	Клиент принял решение; решение зафиксировано пунктом подписанного ACTZ
`resolved`	Инженер интегрировал решение в прямую интерпретацию; запись несёт `decided-in: ACTZ-NNN §M`
`revised`	Решение клиента расплывчатое; повторный вопрос — новым ACTZ. Переход обратно в `asked-to-client`
`frozen`	После approval ADAPT — изменения невозможны

Связь с ACTZ обязательна. Каждая запись, требующая решения клиента, обязана нести поле decided-in: ACTZ-NNN §M — ссылку на пункт подписанного ACTZ, в котором решение зафиксировано (§7.13). Ссылка на неподписанный ACTZ, а равно висячая ссылка на несуществующий ACTZ — fatal (§10.11.1).

Approval ADAPT (§7.5) запрещён при наличии хотя бы одной записи об обратной находке в статусе open / asked-to-client / answered / revised. Все такие записи обязаны быть в resolved перед approval — то есть каждая обязана иметь подписанное решение клиента.

Обратное направление тоже обязано быть выражено: решение, принятое клиентом по его собственной инициативе (ACTZ без родительской находки, §7.13.2), обязано быть отражено в интерпретации — ADAPT реагирует на ACTZ. Подписанное решение, не отражённое ни в одном ADAPT, — fatal: это обязательство, которого нет в требованиях.

7.4.6 AR — запись состязательного обзора¶

AR (Adversarial-Review Record, запись состязательного обзора) — неизменяемая после выпуска запись-свидетельство, фиксирующая факт и исход обязательного состязательного обзора (§7.4.1.2).

AR принадлежит классу свидетельств, а не узлов графа требований: у неё нет родителей и потомков, она не декомпозируется, не верифицируется тест-кейсами и не является ни требованием, ни спецификацией. Поэтому AR не расширяет ни один закрытый список стандарта (§1.7.5): она доопределяет уже существующее свидетельство, на которое ссылается поле source.adversarial-review-ref, а не вводит новый тип артефакта требований.

7.4.6.1 Идентичность и множественность¶

Идентификатор — AR-NNN, сквозной в рамках родительского ТЗ и неизменяемый после создания (зеркально ADAPT-NNN, §7.4.1.4). Год несёт родительское ТЗ (TZ-YYYY-NNN); для delta-ТЗ нумерация ведётся в области действия соответствующего delta-ТЗ (§7.11).

Кардинальность — ноль или более AR на одно ТЗ, как и у ADAPT. Обзор при импорте ТЗ обязателен всегда и даёт первую AR; на стадиях деривации AR выпускается по факту проведения обзора. Единицей гранулярности является событие обзора: несколько артефактов, выведенных из одного обзорного события без новых вопросов, ссылаются на одну AR.

Полнота обеспечивается не мандатом «AR на каждом узле», а инвариантом провенанса узла:

Каждый BR / SR / SPEC ссылается ровно на один источник адаптации — source.adapt либо source.adversarial-review-ref. Состязательный обзор обязателен при импорте ТЗ; на стадиях деривации его исход фиксируется как AR по факту проведения.

7.4.6.2 Обязательные поля¶

Поле	Обязательность	Значение
`id`	обязательно	`AR-NNN`; неизменяем
`tz-ref`	обязательно	Обозреваемое (delta-)ТЗ
`trigger-stage`	обязательно	Стадия обзора: `import-tz` / `decompose-br` / `decompose-sr` / `spec` / `tc` (перечень согласован с `trigger-stage` ADAPT, §7.8.1)
`reviewer.vendor` + `reviewer.model`	обязательно	Модель состязательного рецензента; обязана отличаться от модели основного агента (§7.10.2)
`verdict`	обязательно	`findings-present` либо `no-findings`
`produces-adapt[]`	условно	Обязательно непустой при `verdict: findings-present`; отсутствует либо пуст при `no-findings`
`status`	обязательно	`draft` / `issued` / `superseded`
`superseded-by`	условно	Обязательно при `status: superseded`
`signature.author` + `signature.timestamp`	обязательно для `issued`	Возможность носителя V6

При исходе findings-present тело AR содержит только указатели на разделы ТЗ и на порождённые записи B-NNN; сами находки живут в ADAPT и в AR не дублируются. При исходе no-findings тело содержит краткое обоснование однозначности конвертации.

7.4.6.3 Жизненный цикл¶

draft → issued → superseded

Статус	Что значит
`draft`	Обзор проведён, вердикт оформляется; ссылаться на AR из `source.adversarial-review-ref` запрещено
`issued`	Вердикт выпущен и подписан рецензентом (V6); запись неизменяема
`superseded`	Более поздний обзор на той же стадии заместил ранний вердикт; терминальное состояние, запись сохраняется для аудита (V1)

Выпущенная (issued) AR не редактируется. Единственный выход — superseded, когда повторный обзор на той же стадии выносит новый вердикт: тогда выпускается новая AR, а прежняя получает status: superseded и superseded-by. Модель замещения — та же, что для ADAPT (§7.6.4); отдельного контрольного гейта для AR не вводится (§10.11.1).

Висячая ссылка source.adversarial-review-ref на несуществующую AR либо на AR в статусе draft или superseded — fatal: гейт блокирует изменение (§10.11.1).

7.5 Утверждение ADAPT — подпись архитектора¶

ADAPT — внутренний артефакт интерпретации. Его аудитория — инженер, AI-агент, состязательный рецензент и верификатор; клиент его не видит и не подписывает. Обязательства перед клиентом живут в ACTZ (§7.13).

ADAPT переходит из статуса answered в approved после подписи архитектора (атомарная единица изменения, возможности носителя V2 + V3 из §3.3):

Подпись	Кто	Что подтверждает
Подпись архитектора	Архитектор со стороны исполнителя	Все обратные находки отработаны (каждая — в статусе `resolved` и несёт `decided-in` на пункт подписанного ACTZ, §7.4.5); прямая интерпретация технически реализуема и соответствует принятым решениям

Нативная для носителя реализация подписи — комбинация V3 (diff & review) + V6 (author + timestamp). Конкретный механизм (digital signature / процесс утверждения / двойная review-аттестация) выбирается реализацией и фиксируется в манифесте соответствия (§3.7).

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

После утверждения ADAPT неизменяем наравне с ТЗ. Дальнейшие изменения — только добавлением нового артефакта с типизированной связью, по одному из трёх непересекающихся механизмов: delta-ADAPT при delta-ТЗ (§7.6.1), errata при ошибке интерпретации (§7.6.3) или дезавуирование ранее верного решения (§7.6.4). Сам frozen ADAPT не редактируется ни в одном из них.

Errata, не затрагивающая ни одного решения из подписанного ACTZ (исправление ошибки толкования, не влияющей на обязательства перед клиентом), клиента не касается и подписывается только архитектором (§7.6.3).

7.6 Delta-ТЗ и delta-ADAPT¶

7.6.1 Рабочий процесс¶

Delta-ADAPT следует тому же реактивному правилу §7.4.1, что и корневой ADAPT: создаётся по факту находок при состязательном обзоре delta-ТЗ.

При появлении delta-ТЗ от клиента:

Клиент регистрирует delta-ТЗ в носителе как новый неизменяемый документ (TZ-YYYY-NNN-delta-N).
Клиент подписывает delta-ТЗ (V6 author + timestamp).
Состязательный рецензент (§7.10.2) проводит обзор delta-ТЗ и выносит вердикт.
Если вердикт «findings present» — Архитектор / AI-агент создаёт delta-ADAPT (ADAPT-NNN-delta-N) с frontmatter полем parent-adapt: ADAPT-NNN и source-tz: TZ-YYYY-NNN-delta-N. Forward интерпретация покрывает только разделы delta-ТЗ. Backward findings фиксируются по delta-ТЗ. Approval — подпись архитектора §7.5; решения клиента по находкам delta-ТЗ фиксируются подписанными ACTZ (§7.13).
Если вердикт «no findings, no clarifications» — delta-ADAPT не создаётся. Вердикт фиксируется в носителе с V6 author + timestamp. BR / SR / SPEC, изменяемые в результате delta-ТЗ, ссылаются на source.tz-section: TZ-YYYY-NNN-delta-N напрямую.

В обоих случаях свидетельство состязательного обзора (вердикт) обязано быть машинно-доступно для аудита (hook §10.11.1 reference-validation).

7.6.1bis Пример: тривиальный delta-ТЗ¶

Delta-ТЗ: «переименовать поле "username" на форме регистрации в "email"».

Клиент подписывает TZ-YYYY-NNN-delta-1.
Состязательный рецензент проверяет: термин однозначен (email — стандартный инженерный термин), scope чёткий (одно поле на одной форме), вопросов к клиенту нет.
Вердикт: «no findings, no clarifications»; зафиксирован в носителе.
delta-ADAPT не создаётся.
SR-NN с поведением «POST /auth/sign-up принимает email» получает обновление: source.tz-section: TZ-YYYY-NNN-delta-1 §1. SR parent BR-NN не меняется.

7.6.2 Цепочка delta-ADAPT¶

ADAPT-001 (от TZ-YYYY-NNN main)
  └─ ADAPT-001-delta-1 (от TZ-YYYY-NNN-delta-1)
        └─ ADAPT-001-delta-2 (от TZ-YYYY-NNN-delta-2)
              └─ ADAPT-001-delta-3 (от TZ-YYYY-NNN-delta-3)

Цепочка строго последовательна: применение delta-ADAPT обязано идти по порядку (см. сквозную фиксацию версии V5 в §3.3.5). Перенумеровать или переставлять delta-ADAPT в цепочке запрещено.

7.6.3 Errata для уже approved ADAPT¶

Если через продолжительное время после утверждения обнаруживается, что в ADAPT-NNN неверна прямая интерпретация ТЗ или некорректно зафиксировано разрешение обратной находки — два допустимых исхода:

Исход	Артефакт
ТЗ содержит неоднозначность, обнаруженную поздно	delta-ADAPT с новой записью об обратной находке и ответом клиента
Неверная интерпретация (ошибка инженера)	errata-ADAPT-NNN-M как отдельный артефакт. Если правка затрагивает решение из подписанного ACTZ (меняет обязательство) — требуется новый ACTZ с двусторонней подписью; если не затрагивает — достаточно подписи архитектора

В обоих исходах frozen ADAPT не редактируется. Только добавление новых артефактов с явной типизированной связью.

7.6.4 Дезавуирование approved ADAPT¶

Delta и errata не покрывают один случай: ранее принятое решение было верным, но позже сформированные требования ему противоречат по новому пониманию. Это не ошибка инженера (errata) и не новый контракт от клиента (delta) — это отмена ранее корректного решения. Для него вводится третий механизм — дезавуирование (supersession).

Механизм	Когда	Природа
delta-ADAPT (§7.6.1)	пришло delta-ТЗ от клиента	новый источник: изменился контракт
errata-ADAPT (§7.6.3)	прежняя интерпретация была ошибочной	исправление того, что всегда было неверно
дезавуирующий ADAPT (§7.6.4)	прежнее решение было верным, но позже сформированные требования ему противоречат	отмена ранее корректного решения по новому пониманию

Правила дезавуирования:

Дезавуирующий артефакт. Создаётся новый ADAPT-NNN с frontmatter-полем supersedes: ADAPT-MMM и обязательным supersession-rationale, ссылающимся на конкретное противоречащее требование (BR / SR / SPEC ID) и его источник. Дезавуируемый ADAPT получает автоматически выводимую обратную ссылку superseded-by: ADAPT-NNN (§7.8.1).
Подпись. Если дезавуируемое решение имело контрактный итог (было зафиксировано пунктом подписанного ACTZ) — дезавуирование требует нового ACTZ с двусторонней подписью: согласованное с клиентом решение нельзя отменить в одностороннем порядке, и отменяющий протокол проставляет superseded-by на прежнем (§7.13.4). Если правка не затрагивает ни одного решения из подписанного ACTZ, достаточно подписи архитектора (по аналогии с правилом errata, §7.6.3). Отдельный QG не вводится — дезавуирование проходит через тот же QG-3 (§7.5, §10.8.5).
Состояние. Дезавуируемый ADAPT-MMM переходит в выделенное терминальное состояние superseded — отдельное от frozen и от obsolete, которым устаревают TR / SPEC / TC (у ADAPT состояния obsolete нет, §10.8.1). superseded immutable и сохраняется для аудита (immutable history, возможность носителя V1); не удаляется. Переход нормирован в §10.8.5.
Перенаправление производных. Все BR / SR / SPEC с source.adapt: ADAPT-MMM обязаны быть либо перенаправлены на дезавуирующий ADAPT, либо пере-выведены. Висячая ссылка source.adapt на ADAPT в статусе superseded — fatal: гейт check-adapt-supersession.js блокирует (§10.11.1), по аналогии с reference-validation.
Аддитивность. Как delta и errata — дезавуируемый ADAPT не редактируется; вводится только новый артефакт и типизированная связь supersedes / superseded-by.

Дезавуирование — расширяющая возможность: одиночный ADAPT без дезавуирований остаётся валидным частным случаем, миграция существующих проектов не требуется.

7.7 Связь ADAPT с другими артефактами¶

7.7.1 BR / SR / SPEC ссылаются на ADAPT через `source.adapt`¶

# Frontmatter SR (пример)
source:
  adapt: ADAPT-001
  adapt-section: "Forward §3"   # прямая интерпретация; канонический идентификатор секции — Forward §*
  tz-section: "§3.4"            # для traceability; первоисточник остаётся ТЗ

Поле source.adapt — условное: присутствует, когда конвертация ТЗ → RENAR потребовала ADAPT; опускается, когда состязательный рецензент вынес вердикт «no findings» — тогда обязательно поле source.adversarial-review-ref (§7.4.1). Поле source.tz-section — обязательное всегда (двойная цепочка прослеживаемости).

7.7.2 Полная цепочка прослеживаемости¶

TC-NN  →  verifies SR-12  →  выведено из ADAPT-001 §4 (прямая интерпретация)
                                  │     │
                                  │     └─ resolves B-007 (was: contradiction,
                                  │            answered by client 2026-03-15)
                                  │
                                  └─ interprets TZ-YYYY-NNN §3.4

При проверке от тест-кейса можно дойти до: (a) исходного раздела ТЗ, (b) прямой интерпретации этого раздела, © вопросов исполнителя по обратным находкам, (d) ответов клиента, (e) производных BR / SR / SPEC.

7.7.3 TR не ссылается на ADAPT напрямую¶

TR (задача) ссылается на SR / SPEC, а они уже ссылаются на ADAPT. Исполнитель задачи не обращается к ADAPT напрямую — все нужные интерпретации уже содержатся в SR / SPEC. Если исполнитель обнаружил неясность в SR — корень определяет исход (§7.4.1.1):

корень в декомпозиции (а не в ТЗ — например, неточная формулировка SR, упущенная связь constrained-by[]) — решается уточнением SR / SPEC без ADAPT;
корень в языке или намерении ТЗ — регистрируется обратная находка в ADAPT. Если ADAPT для этого ТЗ уже существует — добавляется новая запись; если ADAPT ещё не создавался (вердикт при импорте был «no findings») — на текущей стадии создаётся новый ADAPT (§7.4.1.1). Это штатный, а не исключительный случай.

7.8 ADAPT schema¶

7.8.1 frontmatter (обязательные поля)¶

---
id: ADAPT-NNN                       # immutable; NNN sequential per project
title: "Адаптация ТЗ <name>"
type: ADAPT
trigger-stage: import-tz            # стадия, породившая ADAPT (§7.4.1.4):
                                    # import-tz | decompose-br | decompose-sr | spec | tc

source-tz:
  id: TZ-YYYY-NNN
  signed-date: "<ISO-date>"
  signed-by-client: "<name + role>"
  document-version-ref: "<нативный для носителя идентификатор версии>"   # V5 pin (см. §3.3.5)

parent-adapt:                       # для delta-ADAPT
  id: ADAPT-NNN
  delta-tz: TZ-YYYY-NNN-delta-N

supersedes: ADAPT-MMM               # только для дезавуирующего ADAPT (§7.6.4); опускается иначе
superseded-by: ADAPT-NNN            # auto-derived; проставляется на дезавуируемом ADAPT
supersession-rationale: >           # mandatory если присутствует supersedes:
  "<ссылка на противоречащее BR/SR/SPEC ID + его источник; обоснование отмены>"

status: draft | review | asked | answered | approved | frozen | superseded
created: "<ISO-date>"
last-updated: "<ISO-date>"

approval:                            # обязательно для approved
  # client-signature ОТСУТСТВУЕТ: ADAPT — внутренняя интерпретация (§7.5).
  # Клиентские обязательства несёт ACTZ (§7.13) с двусторонней подписью.
  architect-signature:               # mandatory для approved
    signed-by: "<name>"
    role: architect
    signed-at: "<ISO-datetime>"

generates-requirements: []           # auto-derived; BR/SR из этого ADAPT
generates-specs: []                  # auto-derived; SPEC-* из этого ADAPT
open-questions-count: integer        # auto-derived; обязательно 0 для approved
resolved-questions-count: integer

ai-provenance:                       # обязательно если ADAPT draft был AI-сгенерирован
  generated-by: "<vendor>-<model>@<date>"
  prompt-template: "<template-path>@<version>"
  context-tokens: integer
  output-tokens: integer
  human-edits: boolean               # обязательно true для approved — архитектор вычитал текст (§7.5)
---

Примечание: ADAPT существует только в одном режиме (подпись архитектора, полный жизненный цикл §7.4.5). Реактивность (§7.4.1) выражается на уровне создания: если состязательный рецензент вынес вердикт «no findings, no clarifications», ADAPT не создаётся вовсе, а не создаётся в упрощённой форме.

7.8.2 Body structure (обязательные разделы)¶

Обязательные разделы тела ADAPT:

Краткое содержание — 3–5 параграфов для одностраничного чтения архитектором и состязательным рецензентом (§7.5).
Сопоставление терминов (Term mapping) — таблица «клиент → инженер».
Прямая интерпретация (раздел Forward) — раздел на каждый раздел ТЗ с обязательными элементами из §7.4.3.
Обратные находки — все записи с жизненным циклом из §7.4.5.
Резюме по обратным находкам — статистическая таблица по категориям и статусам.
Таблица производных артефактов — auto-derived список BR / SR / SPEC.
История изменений ADAPT — нативно для носителя, auto-generated.

Опциональные разделы — на усмотрение реализации, не нормированы.

7.9 Контрольные точки качества для ADAPT¶

ADAPT имеет выделенную машину состояний. Детали в главе 10 §10.8. Краткая сводка:

Gate	Предусловие	Постусловие
QG-ADAPT-draft	ADAPT создан; присутствует frontmatter	Прямая интерпретация охватывает все разделы ТЗ
QG-ADAPT-review	Прямая интерпретация заполнена; первичные обратные находки в `open`	Все обратные находки в `open` или `asked-to-client`
QG-ADAPT-asked	Все обратные находки в `asked-to-client`; вопросы вынесены клиенту в составе ACTZ (`status: sent`)	Ожидание подписания протокола
QG-ADAPT-answered	Все обратные находки в `answered`; начато разрешение	Готов к финализации
QG-ADAPT-approve	Все обратные находки в `resolved` и несут `decided-in` на подписанный ACTZ; подпись архитектора готова	ADAPT неизменяем; разрешена генерация BR / SR / SPEC
QG-ADAPT-frozen	`approved`	Дальнейшие изменения — только через delta-ADAPT или errata

Hooks носителя (§3.3.3 V3, §3.3.5 V5) обязаны:

Блокировать переход в approved при open-questions-count > 0.
Блокировать создание BR / SR / SPEC с source.adapt на ADAPT в статусе ниже approved.
Пересчитывать open-questions-count / resolved-questions-count после каждого изменения.

7.10 ADAPT и AI-генерация¶

7.10.1 AI-агент создаёт draft ADAPT¶

При вердикте состязательного рецензента «findings present» (§7.4.1) AI-агент создаёт draft ADAPT: прямая интерпретация по разделам, попытка обнаружить contradictions / gaps / terminology ambiguities, первая версия сопоставления терминов. Этот draft — стартовая точка для архитектора, не финальный артефакт.

7.10.2 Состязательный рецензент¶

Применение принципа состязательного обзора (отдельный AI-агент-критик с другой моделью; процедура — guide/07 §3.5): ищет, что primary агент пропустил — недостающие обратные находки. Если состязательный рецензент находит не менее трёх серьёзных новых находок — primary draft возвращается на доработку.

7.10.3 Клиент не общается с AI напрямую¶

Вопросы по обратным находкам агрегируются архитектором в человеческий формат перед отправкой клиенту. Архитектор может убрать дубликаты, переформулировать на язык клиента, объединить связанные. Клиент видит подготовленный список вопросов, не raw output AI-агента. Ответ клиента (в любой форме: текст, видеозвонок, письмо) транскрибируется архитектором в ADAPT с указанием канала и аутентификации.

7.11 Схема хранения¶

ADAPT-документы хранятся в подпапке adapt/ носителя требований:

[project]/
  adapt/
    ADAPT-001-main.md
    ADAPT-001-delta-1.md
    ADAPT-001-delta-2.md
    ADAPT-002-main.md
    errata/
      errata-ADAPT-001-1.md
  ar/
    AR-001.md
    AR-002.md
  tz/
    TZ-YYYY-NNN.md
    TZ-YYYY-NNN-delta-1.md

Записи состязательного обзора (§7.4.6) хранятся в подпапке ar/. Они существуют и тогда, когда ADAPT не создан (вердикт no-findings), — поэтому подпапка независима от adapt/.

Конкретная файловая структура на конкретном носителе специфична для носителя (см. guide/03 для distributed VCS; guide/04 для document-oriented store).

7.12 Соотношение ТЗ и RENAR-описания¶

7.12.1 Два языка с переменным расстоянием¶

ТЗ и RENAR-описание — два разных артефакта с разной природой:

Параметр	ТЗ	RENAR-описание
Целевой читатель	Клиент (человек)	AI-агент (§0.2.1) и человек-verifier
Язык	Язык клиента (бизнес-домен, контрактная лексика)	Язык требований (канонические IDs, закрытые списки, формальные frontmatter и графовые связи)
Полнота	Допускает умолчания, неполноту, неоднозначность формулировок	Не допускает умолчаний; полнота — нижняя граница machine-enforceability (§0.3)
Эволюция	Инкрементная: первое ТЗ описывает систему полностью, последующие — только delta (§7.6)	Не инкрементная: перед изменением системы создаётся новая полная версия RENAR-описания, и только затем AI-агент производит изменения в реализации
Статус после подписания	Неизменяемый договорной документ (§7.4.2)	Эволюционирует через approved delta-ADAPT или (когда ADAPT не создаётся, §7.4.1) через source.tz-section напрямую

Расстояние между двумя языками переменное. Иногда разделы ТЗ формулированы достаточно однозначно, чтобы AI-агент конвертировал их в BR/SR/SPEC без потерь смысла. Иногда — наоборот: ТЗ содержит контрактную фразу, имеющую несколько инженерных трактовок, или пропускает поведение, без которого реализация невозможна.

7.12.2 ADAPT — реактивный мост между языками¶

ADAPT существует только когда между языками возникает разрыв. Его прямая интерпретация (forward, §7.4.3) — перевод конкретных разделов ТЗ с языка клиента на язык требований. Обратные находки (backward, §7.4.4) — формализация того, что при переводе обнаружились пробелы, неоднозначности или противоречия, требующие согласования с клиентом.

Из этой природы следуют три следствия:

ADAPT — реактивный артефакт по дизайну. Существование разрыва между языками — необходимое условие создания (§7.4.1.1); формальный ADAPT без содержания утрачивает смысл для аудита и обесценивает остальные ADAPT.
Состязательный рецензент — единственный, кто декларирует отсутствие разрыва. «ADAPT не нужен» — зафиксированный вердикт другой модели (§7.10.2, §7.4.1.3), а не молчаливое допущение архитектора.
Форма ADAPT — единственная. Создаётся в полной форме (подпись архитектора §7.5, все разделы body §7.8.2, полный жизненный цикл §7.4.5); промежуточных «light»-форм не существует.

7.12.3 Почему RENAR-описание всегда полное¶

RENAR-описание не инкрементное по дизайну: AI-агент (§0.2.1) не способен надёжно «достроить» изменения, опираясь только на delta. Полная новая версия RENAR-описания — единственная форма, гарантирующая что:

machine-enforceable инварианты (полнота, graph consistency, состояния жизненного цикла) применимы к описанию в целом, а не к diff;
состязательный рецензент работает на полном артефакте, не на дельте;
последующие шаги (декомпозиция, генерация TC, реализация — guide/00-quickstart §«Два штатных сценария») выполняются на актуальной полной картине системы.

Delta-ТЗ — инкрементное на уровне источника (контрактная сторона); полная новая версия RENAR-описания собирается AI-агентом из родительского RENAR + либо delta-ADAPT (если он создавался), либо напрямую с учётом delta-ТЗ через source.tz-section.

7.12.4 Связь с инверсией источника истины¶

ТЗ — договорной артефакт, но не источник истины о поведении системы (§2.3). Источник истины — RENAR-описание (BR / SR / SPEC / TR / TC). ТЗ — источник, из которого RENAR-описание выводится либо через ADAPT (когда есть разрыв), либо напрямую через source.tz-section (когда разрыв отсутствует); код — производный артефакт реализации RENAR-описания. ADAPT и §7.12 фиксируют двойную инверсию: контрактный источник (ТЗ) → источник истины (RENAR-описание) → код. ADAPT встраивается в цепочку реактивно, когда мост между языками нужен.

7.13 ACTZ — протокол уточнения ТЗ¶

7.13.1 Назначение и граница с ADAPT¶

ACTZ (ACTZ-NNN, Agreed Clarification of TZ, в договорном обороте — «Протокол уточнения ТЗ № N») — артефакт контрактного контура: порция вопросов, предложений и решений, вынесенная клиенту и подписанная обеими сторонами.

Граница между ACTZ и ADAPT проводится по аудитории, а не по содержанию записи:

Всё, что показано клиенту и утверждено, — обязательство. Всё, что не показано, — интерпретация.

	ADAPT — интерпретация	ACTZ — утверждение
Содержимое	Перевод языка ТЗ на инженерный, сопоставление терминов, достроенные сценарии, обратные находки, прямая интерпретация	Вопросы, предложения и решения, вынесенные клиенту. Формулируются на языке обязательств («кнопка называется X»), а не толкования
Аудитория	Инженер, AI-агент, состязательный рецензент, верификатор	Клиент и стороны договора
Подпись	Только архитектора (§7.5)	Двусторонняя: клиент + исполнитель
Вес	Внутренний контур	Контрактный

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

7.13.2 Происхождение и множественность¶

ACTZ порождается двумя способами, оба штатны:

Из обратной находки. Находка, требующая решения клиента (§7.4.4), выносится в ACTZ; после подписания запись получает decided-in: ACTZ-NNN §M (§7.4.5).
По инициативе клиента, без находки. Клиент сам предлагает решение («кнопку назовём иначе»). Такой ACTZ ссылается только на ТЗ; родительской находки у него нет. После подписания решение обязано быть отражено в ADAPT — интерпретация реагирует на протокол.

Кардинальность:

Отношение	Кардинальность	Пояснение
ТЗ : ACTZ	1 : 0..N	Ноль протоколов законен: конвертация без вопросов и без инициатив клиента не порождает документов
ADAPT : ACTZ	1 : 1..N	Находки одного ADAPT закрываются несколькими протоколами по мере раундов уточнений

Поздний ACTZ — штатный случай, а не исключение. Протокол возникает на любой стадии жизни заказа, в том числе из разбора замечаний заказчика после демонстрации. Норма стадийно-независима — симметрично реактивному ADAPT (§7.4.1).

7.13.3 Обязательные поля¶

Поле	Обязательность	Значение
`id`	обязательно	`ACTZ-NNN`; сквозной в рамках родительского ТЗ; неизменяем
`tz-ref`	обязательно	ТЗ, к которому относится протокол
`resolves[]`	условно	Записи `B-NNN` в ADAPT, которые закрывает протокол; отсутствует у ACTZ по инициативе клиента
`decisions[]`	обязательно	Пункты решений; каждый формулируется на языке обязательств и имеет стабильный номер `§M`
`annexes[]`	условно	Новые версии приложений к ТЗ, утверждаемые этим протоколом (§7.13.5)
`status`	обязательно	`draft` → `sent` → `signed` → `superseded`
`client-signature`	обязательно для `signed`	Клиент или его представитель с полномочиями (V6: author + timestamp)
`vendor-signature`	обязательно для `signed`	Исполнитель (V6)
`superseded-by`	условно	Обязательно при `status: superseded`

7.13.4 Жизненный цикл¶

draft → sent → signed → superseded

Статус	Что значит
`draft`	Протокол готовится; клиенту не вынесен. Ссылаться на него из `decided-in` запрещено
`sent`	Вынесен клиенту, ожидается подписание
`signed`	Подписан обеими сторонами; неизменяем, несёт контрактный вес
`superseded`	Более поздний подписанный ACTZ отменил решение; терминальное состояние, запись сохраняется для аудита (V1)

Подписанный ACTZ не редактируется. Исправление — только новым ACTZ, отменяющим прежнее решение (superseded-by); модель замещения — та же, что для ADAPT (§7.6.4).

Клиенту выносится подготовленный список решений, а не сырой вывод AI-агента (§7.10.3): вопросы агрегирует и переформулирует архитектор.

7.13.5 Приложения к ТЗ¶

Приложения (карты сопоставления, справочники, макеты) — неотъемлемая часть ТЗ, отдельной адресуемой сущностью они не являются. Уточнение приложения оформляется новой версией приложения, приложенной к ACTZ и утверждаемой той же двусторонней подписью (annexes[]).

Это закрывает случай, когда решением клиента является не текст, а новая версия таблицы: прежняя версия остаётся неизменяемой (V1), новая входит в итоговое ТЗ через подписавший её протокол.

7.14 Итоговое ТЗ — эталон сдачи-приёмки¶

Итоговое ТЗ (effective TZ) — эталон, против которого система сдаётся и принимается:

Итоговое ТЗ = начальное ТЗ (включая приложения) + все подписанные ACTZ. При расхождении между документами приоритет имеет более поздний подписанный документ.

Против итогового ТЗ выводятся приёмочные тесты AT (§9.19); из него же строится отчёт приёмки.

ADAPT в эталон приёмки не входит. Внутренняя интерпретация из контрактного контура выведена целиком — клиент отвечает только за то, что подписывал и понимал. Это и есть смысл расщепления: приёмка становится юридически чистой.

QG-4 (§10.4.2) — отдельный опциональный гейт бизнес-результата (achievement ≥ 80%). Он не подменяет приёмку соответствия итоговому ТЗ и с ней не смешивается: бизнес-цель может быть достигнута при несоответствии контракту, и наоборот.

7.15 Связь с другими главами¶

Глава	Связь
02 Methodology positioning	ADAPT — следствие Утверждения 2 (двусторонняя адаптация вместо «переброса спецификации через забор»)
06 Requirements hierarchy	BR / SR ссылаются на ADAPT через `source.adapt`
08 Specifications	SPEC-* также ссылаются на ADAPT через `source.adapt`
09 Test cases	TC через SR / SPEC возвращается в ADAPT для полной цепочки прослеживаемости
10 Жизненный цикл и QG	машина состояний ADAPT + QG-ADAPT-* gates
03 Версионирование носителя	Подпись архитектора на ADAPT и двусторонняя подпись ACTZ (V6) + atomic approval (V2 + V3); immutability после approved (V1); delta-ADAPT через V4
13 Соответствие	Состязательный обзор для каждого ТЗ — обязательное положение; ADAPT создаётся реактивно (§7.4.1)