Перейти к содержанию

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

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

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

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

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

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).

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

        ┌───────────────────────────────┐
        │   ТЗ (immutable, договор)     │
        └───────────────┬───────────────┘
                        │ источник
                        ▼
┌──────────────────────────────────────────────┐
│              ADAPT-NNN                       │
│                                              │
│  Прямая интерпретация (инженер → клиент)     │
│  ─ по разделам ТЗ                             │
│  ─ сопоставление терминов                     │
│  ─ достроенные сценарии                      │
│  ─ уточнение границы работ                    │
│                                              │
│  Обратные находки (инженер → клиент)         │
│  ─ 7 категорий записей                       │
│  ─ жизненный цикл: open → asked → answered →  │
│              resolved → frozen               │
│                                              │
│  Status: draft → review → client-ready →     │
│         answered → approved → frozen         │
│  Approval: двойная подпись клиент+архитектор │
└────────────────────┬─────────────────────────┘
                     │ 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 обязателен тогда и только тогда, когда хотя бы одно из условий выполнено:

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

Если ни одно условие не выполнено (состязательный рецензент выдал вердикт «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 можно не создавать; вердикт фиксируется в свидетельствах носителя (V6 author + timestamp), доступен для аудита

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

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

Создание BR / SR / SPEC из ТЗ без состязательного обзора (пропуск ADAPT без вердикта) — нарушение стандарта. Это сохраняет инверсию источника истины (§2.3): «no findings» — это зафиксированное утверждение состязательного рецензента, не молчаливое допущение архитектора. Вердикт обязан быть фиксирован нативным для носителя механизмом V6 (author + timestamp) и доступен по запросу аудитора (§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 Вопрос отправлен клиенту, ожидается ответ; зафиксирована дата
answered Клиент ответил; ответ записан в документ с author + timestamp (возможность носителя V6)
resolved Инженер интегрировал ответ в прямую интерпретацию
revised Ответ клиента расплывчатый; повторный вопрос. Переход обратно в asked-to-client
frozen После approval ADAPT — изменения невозможны

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

7.5 Утверждение ADAPT — двойная подпись

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

Подпись Кто Что подтверждает
Подпись клиента Клиент или представитель клиента с полномочиями Прямая интерпретация ТЗ совпадает с тем, что заказчик имел в виду; ответы на вопросы по обратным находкам — финальные
Подпись архитектора Архитектор со стороны исполнителя Все обратные находки отработаны (нет нерешённых); прямая интерпретация технически реализуема

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

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

7.6 Delta-ТЗ и delta-ADAPT

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

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

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

  1. Клиент регистрирует delta-ТЗ в носителе как новый неизменяемый документ (TZ-YYYY-NNN-delta-N).
  2. Клиент подписывает delta-ТЗ (V6 author + timestamp).
  3. Состязательный рецензент (§7.10.2) проводит обзор delta-ТЗ и выносит вердикт.
  4. Если вердикт «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.
  5. Если вердикт «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"».

  1. Клиент подписывает TZ-YYYY-NNN-delta-1.
  2. Состязательный рецензент проверяет: термин однозначен (email — стандартный inженерный термин), scope чёткий (одно поле на одной форме), вопросов к клиенту нет.
  3. Вердикт: «no findings, no clarifications»; зафиксирован в носителе.
  4. delta-ADAPT не создаётся.
  5. 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 как отдельный артефакт с подписью клиента (если меняет контрактный итог) или только архитектора (если правка косметическая)

В обоих исходах 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) прежнее решение было верным, но позже сформированные требования ему противоречат отмена ранее корректного решения по новому пониманию

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

  1. Дезавуирующий артефакт. Создаётся новый ADAPT-NNN с frontmatter-полем supersedes: ADAPT-MMM и обязательным supersession-rationale, ссылающимся на конкретное противоречащее требование (BR / SR / SPEC ID) и его источник. Дезавуируемый ADAPT получает автоматически выводимую обратную ссылку superseded-by: ADAPT-NNN (§7.8.1).
  2. Подпись. Если дезавуируемое решение имело контрактный итог (было подписано клиентом — типовой случай для approved ADAPT) — дезавуирование требует новой подписи клиента: согласованное с клиентом решение нельзя отменить в одностороннем порядке. Если же правка строго косметическая и не затрагивает контрактный итог, допустима подпись только архитектора, без клиента (по аналогии с правилом errata, §7.6.3). Отдельный QG не вводится — дезавуирование проходит через тот же QG-3 (двойная подпись, §7.5, §10.8.5).
  3. Состояние. Дезавуируемый ADAPT-MMM переходит в выделенное терминальное состояние superseded — отдельное от obsolete (устаревание) и от frozen. superseded immutable и сохраняется для аудита (immutable history, возможность носителя V1); не удаляется. Переход нормирован в §10.8.5.
  4. Перенаправление производных. Все BR / SR / SPEC с source.adapt: ADAPT-MMM обязаны быть либо перенаправлены на дезавуирующий ADAPT, либо пере-выведены. Висячая ссылка source.adapt на ADAPT в статусе superseded — fatal: гейт check-adapt-supersession.js блокирует (§10.11.1), по аналогии с reference-validation.
  5. Аддитивность. Как 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 — корень определяет исход (Q1, §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 | client-ready | answered | approved | frozen | superseded | obsolete
created: "<ISO-date>"
last-updated: "<ISO-date>"

approval:                            # обязательно для approved
  client-signature:                  # mandatory для approved
    signed-by: "<name>"
    role: "<role>"
    organization: "<client-org>"
    signed-at: "<ISO-datetime>"      # V6 timestamp
    signature-ref: "<нативная для носителя ссылка>"
  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 — клиент видел текст
---

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

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

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

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

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

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

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

Gate Предусловие Постусловие
QG-ADAPT-draft ADAPT создан; присутствует frontmatter Прямая интерпретация охватывает все разделы ТЗ
QG-ADAPT-review Прямая интерпретация заполнена; первичные обратные находки в open Все обратные находки в open или asked-to-client
QG-ADAPT-client-ready Все обратные находки в asked-to-client; пакет вопросов сформирован Готов к отправке клиенту
QG-ADAPT-answered Все обратные находки в answered; начато разрешение Готов к финализации
QG-ADAPT-approve Все обратные находки в resolved; двойная подпись готова 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

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

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

Применение принципа состязательного обзора (отдельный AI-агент-критик с другой моделью; процедура — guide/07 §4.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
  tz/
    TZ-YYYY-NNN.md
    TZ-YYYY-NNN-delta-1.md

Конкретная файловая структура на конкретном носителе специфична для носителя (см. 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) — формализация того, что при переводе обнаружились пробелы, неоднозначности или противоречия, требующие согласования с клиентом.

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

  1. ADAPT — реактивный артефакт по дизайну. Существование разрыва между языками — необходимое условие создания (§7.4.1.1); формальный ADAPT без содержания утрачивает смысл для аудита и обесценивает остальные ADAPT.
  2. Состязательный рецензент — единственный, кто декларирует отсутствие разрыва. «ADAPT не нужен» — зафиксированный вердикт другой модели (§7.10.2, §7.4.1.3), а не молчаливое допущение архитектора.
  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 Связь с другими главами

Глава Связь
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 Версионирование носителя Двойная подпись (V6) + atomic approval (V2 + V3); immutability после approved (V1); delta-ADAPT через V4
13 Соответствие ADAPT для каждого ТЗ — обязательное положение