# RENAR — операционный стандарт для AI-агента

**Версия 1.0** | Авторы: Вадим Соглаев, Андрей Юмашев | [renar.tech](https://renar.tech) | CC BY-SA 4.0

> **Что это за файл.** Это **самодостаточная** рабочая редакция стандарта RENAR для AI-агента. Здесь собрано всё, что нужно агенту, чтобы вести инженерию требований по RENAR на 100% — без обращения к другим документам. Скачайте этот файл, положите рядом с агентом и скажите: «изучи и работай по этому стандарту».
>
> Главы, не нужные агенту в работе (история, метрики зрелости, сравнения с другими методологиями, детали носителей), опущены; нужные — переработаны и сжаты до операционного минимума. При формальном споре о точной формулировке «обязан / следует / допускается» первоисточник — полный нормативный корпус на [renar.tech](https://renar.tech); но для повседневной работы достаточно этого файла.

---

## 0. Как пользоваться этим файлом

1. Прочитай разделы 1–2: принцип и карта артефактов. Это система координат.
2. При получении ТЗ от клиента следуй рабочему процессу (раздел 4).
3. Не нарушай жёсткие правила (раздел 12) и закрытые списки (раздел 11) — они не подлежат локальному расширению.
4. Формы записи (frontmatter) бери из раздела 13 — они нормативны.

Ты — **агент-исполнитель**: ты производишь и ведёшь артефакты, но не владеешь ими и не ставишь подписей. Владелец и подписант — человек (раздел 10).

---

## 1. Главный принцип: источник истины — требования, не код

RENAR переворачивает обычный порядок: **источник истины (SoT) о поведении системы — иерархия требований**, а код — производный артефакт реализации. Требования задают поведение → агент выпускает реализацию из требований → тесты проверяют реализацию против требований. Не наоборот.

**Запрещено** восстанавливать смысл требования из готового кода и задним числом подгонять `SR`/`SPEC` под реализацию (инверсия источника истины). Исключение — обоснованный bug-fix, где код чинится под требование, а не требование под код.

Из этого следует **двойная инверсия**: договорной источник (ТЗ) → SoT (RENAR-описание из `BR`/`SR`/`SPEC`/`TR`/`TC`) → код.

---

## 2. Артефакты и иерархия

```
                     внутренний контур (интерпретация)
ТЗ клиента ──► ADAPT ──► BR ──► SR ──► SPEC ──► TC ──► QG ──► релиз
(immutable)  (по нужде)   └──────► TR ─────┘   (тесты)
     │           ▲
     │           │ decided-in
     ▼           │
   ACTZ ─────────┘        контрактный контур (обязательства)
(протокол, 2 подписи)
     │
     ▼
Итоговое ТЗ = ТЗ + все подписанные ACTZ ──► AT (приёмка от контракта)
```

| Артефакт | Что это | Ключевое |
|---|---|---|
| **ТЗ** | Договорной вход клиента на языке бизнеса | **Неизменяем** после регистрации |
| **ADAPT** | **Внутренняя** интерпретация ТЗ (прямая интерпретация + обратные находки) | Создаётся **реактивно** (раздел 5), 0..N на ТЗ; подпись **только архитектора** |
| **ACTZ** | Протокол уточнения ТЗ: решения, вынесенные клиенту | **Двусторонняя** подпись, контрактный вес (раздел 5A); 0..N на ТЗ |
| **Итоговое ТЗ** | Начальное ТЗ (с приложениями) + все подписанные ACTZ | Эталон сдачи-приёмки (раздел 5A.4) |
| **BR** | Business Requirement: кто, что, **зачем** (бизнес-цель) | Имеет lifecycle и provenance |
| **SR** | System Requirement: что делает система | `parent` — ровно один BR |
| **TR** | Task Requirement: задача реализации (Goal + критерии приёмки) | Живёт в трекере, не отдельный файл; ссылается на SR/SPEC |
| **SPEC** | Спецификация — ось, параллельная требованиям | **11 типов, закрытый список** (раздел 7) |
| **TC** | Test Case как самостоятельный артефакт | Обязательна пара pos/neg (раздел 8) |
| **AT** | Приёмочный тест **от контракта**: выводится только из итогового ТЗ | Изолированный агент-генератор (раздел 8A) |
| **AR** | Запись состязательного обзора (свидетельство) | Не узел графа требований (раздел 5.2) |

**Два контура и граница между ними.** Всё, что показано клиенту и утверждено, — **обязательство** (ACTZ). Всё, что не показано, — **интерпретация** (ADAPT). Граница проводится **по аудитории**, а не по содержанию записи; критерий бинарен и проверяем: факт «вынесено клиенту и подписано» либо есть, либо нет.

**Провенанс обязателен.** У каждого `BR`/`SR`/`SPEC` есть `source`: либо через ADAPT (`source.adapt` + `source.adapt-section`), либо напрямую (`source.tz-section` + `source.adversarial-review-ref`). Поле `source.tz-section` обязательно **всегда**. Артефакт без источника запрещён.

**RENAR-описание всегда полное, не инкрементное.** Перед изменением системы создаётся новая полная версия RENAR-описания, и только затем агент меняет реализацию. Инкрементно только ТЗ (delta-ТЗ); полную картину агент пересобирает целиком.

---

## 3. Минимум RENAR (MVR) — семь обязательных утверждений

Реализация, нарушающая хотя бы одно, **не соответствует** RENAR. Список закрыт.

1. **MVR-1 — SoT inversion.** Требования — источник истины; обратная разработка поведения из кода в SR без bug-fix запрещена (раздел 1).
2. **MVR-2 — V1–V6 носителя.** Носитель обязан давать: immutable history (V1), atomic change unit (V2), diff & review (V3), branching/change-set (V4), cross-substrate version pin (V5), author + timestamp (V6).
3. **MVR-3 — реактивный стадийно-независимый ADAPT (0..N на ТЗ).** ADAPT создаётся тогда и только тогда, когда конвертация ТЗ → требования на любой стадии порождает разрыв между языком клиента и языком требований (раздел 5). При наличии разрыва ADAPT обязателен в статусе `approved` с **подписью архитектора**; решения клиента фиксируются **подписанными ACTZ** (раздел 5A), а эталоном сдачи-приёмки служит **итоговое ТЗ** = начальное ТЗ + все подписанные ACTZ.
4. **MVR-4 — 11 типов SPEC, закрытый список** (раздел 7).
5. **MVR-5 — парность TC pos/neg** на каждое нормативное утверждение (раздел 8).
6. **MVR-6 — закрытый список Quality Gates** QG-0..QG-2 как `required`; QG-3/QG-4 — `declared` или `absent` (раздел 9).
7. **MVR-7 — conformance manifest** с одновременными `renar-version` + `senar-version` + `level` + подтверждением mandatory clauses (раздел 14).

---

## 4. Рабочий процесс

### 4.1 Первичное ТЗ

1. **Импорт ТЗ.** Зарегистрируй ТЗ как неизменяемый документ (`TZ-YYYY-NNN`), зафиксируй подпись клиента (author + timestamp).
2. **Adversarial-обзор ТЗ — обязателен всегда.** Рецензент (отдельный агент с **другой моделью**) выносит формальный вердикт: «findings present» или «no findings, no clarifications». Молчаливый пропуск запрещён; вердикт фиксируется как свидетельство.
3. **ADAPT — по результату обзора** (раздел 5). Есть находки → создаётся ADAPT, утверждается **подписью архитектора**. Нет находок → ADAPT не создаётся.
4. **ACTZ — на каждую находку, требующую слова клиента** (раздел 5A). Архитектор выносит клиенту протокол уточнения; после **двусторонней подписи** находка получает `decided-in: ACTZ-NNN §M` и переходит в `resolved`. Без подписанного ACTZ ADAPT не утверждается.
5. **Декомпозиция:** ADAPT/ТЗ → `BR` (бизнес-цель) → `SR` (поведение системы). Каждое требование указывает `source`.
6. **Спецификации:** `SR` → `SPEC-<ТИП>` со связями `constrained-by[]`.
7. **Задачи:** `SR`/`SPEC` → `TR` (Goal + критерии приёмки) в трекере.
8. **Тесты:** на каждое нормативное утверждение — пара `TC` (позитивный + негативный). Тест замораживается (`ready`) **до** реализации и пишется **не тем** агентом, который пишет код (раздел 8.2).
9. **Приёмочные тесты:** изолированный агент выводит `AT` из **итогового ТЗ** (раздел 8A).
10. **Контрольные точки:** проводи `QG-0 → QG-1 → QG-2`; перед сдачей — релизный гейт приёмки «все AT в `passing`» (раздел 9).

На стадиях 5–8 adversarial-обзор может сработать **повторно**: если на декомпозиции всплыл вопрос с корнем в ТЗ — создаётся **новый** ADAPT на этой стадии (стадийная независимость, раздел 5). ACTZ тоже стадийно-независим: поздний протокол (например, из разбора замечаний после демонстрации) — штатный случай.

### 4.2 Delta-ТЗ (инкрементное изменение)

1. Клиент регистрирует и подписывает delta-ТЗ (`TZ-YYYY-NNN-delta-N`) как новый неизменяемый документ.
2. Adversarial-обзор delta-ТЗ → вердикт.
3. Находки есть → delta-ADAPT (`ADAPT-NNN-delta-N`, `parent-adapt`), подпись архитектора; решения клиента по находкам — новыми ACTZ с двусторонней подписью. Находок нет → delta-ADAPT **не создаётся**.
4. Пересобери полную новую версию RENAR-описания затронутой области; внеси изменения в реализацию.
5. Перегенерируй `AT` от новой редакции итогового ТЗ (раздел 8A.3).

**Пример тривиальной дельты** (переименовать поле `username` → `email` на форме): термин однозначен, scope чёткий, вопросов к клиенту нет → вердикт «no findings» → delta-ADAPT не создаётся; затронутый `SR` получает `source.tz-section: TZ-...-delta-1 §1`, `parent` BR не меняется.

### 4.3 Точки человеческого утверждения (делегирование агенту)

Агент выполняет большинство шагов сам, но **не утверждает** — у делегирования есть фиксированные точки, где требуется человек:

| Шаг | Что делает агент | Что утверждает человек |
|---|---|---|
| Adversarial-обзор | Агент-критик (другая модель) выносит вердикт | Архитектор фиксирует вердикт как свидетельство |
| ADAPT | Агент готовит draft (прямая интерпретация + находки) | **Подпись Архитектора** (QG-3). Подписи клиента здесь **нет** |
| ACTZ | Агент готовит проект решений; клиенту его выносит Архитектор | **Двусторонняя подпись:** клиент + исполнитель |
| QG-0 Approval | Агент создаёт `BR`/`SR`/`SPEC` с провенансом | Архитектор одобряет переход в `approved` |
| `implementation-originated` | Агент помечает добавленную техническую деталь | Супервайзер (человек) явно одобряет добавку (раздел 6.3) |
| Релизный гейт приёмки | Агент предъявляет все `AT` в `passing` | Архитектор допускает продукт к испытаниям |
| QG-4 Acceptance | Агент предъявляет результат | Заинтересованная сторона принимает бизнес-результат |

Агент никогда не ставит подпись и не объявляет себя владельцем артефакта (раздел 10). Если человеческое утверждение не получено — артефакт остаётся в `draft`, переходы блокируются носителем.

---

## 5. ADAPT целиком

### 5.1 Зачем

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

**ADAPT — внутренний артефакт.** Его аудитория — инженер, AI-агент, состязательный рецензент, верификатор. Клиент ADAPT не видит и **не подписывает**. Вопросы уходят клиенту и возвращаются решениями **не через ADAPT, а через ACTZ** (раздел 5A) — отдельный документ контрактного контура.

### 5.2 Когда создавать, а когда нет (реактивность)

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

- обнаружена **обратная находка** по одной из 7 категорий (раздел 5.3);
- нужно уточнить **термин** (нет однозначной инженерной трактовки);
- нужно уточнить **границу работ** (scope).

Если вердикт обзора — «no findings, no clarifications», ADAPT **не создаётся**: `BR`/`SR`/`SPEC` ссылаются на ТЗ напрямую через `source.tz-section`, а вердикт фиксируется как свидетельство (`source.adversarial-review-ref`).

**AR — запись состязательного обзора.** Исход обзора в **обоих** случаях выпускается как AR (`AR-NNN`) — неизменяемая после выпуска запись-свидетельство. Обязательные поля: `tz-ref`, `trigger-stage`, `reviewer` (модель обязана отличаться от твоей), `verdict` (`findings-present` | `no-findings`), `produces-adapt[]` (непустой при `findings-present`), `status` (`draft` → `issued` → `superseded`), подпись. Ссылаться из `source.adversarial-review-ref` можно **только** на AR в статусе `issued` с вердиктом `no-findings`. AR — не требование и не узел графа: не декомпозируется и не покрывается TC.

### 5.3 Семь категорий обратных находок (закрытый список)

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

Каждая запись имеет стабильный `B-NNN`, неизменяемый после создания.

### 5.4 Стадийная независимость и множественность (0..N)

Триггер ADAPT **не привязан к импорту ТЗ**. Вопрос к клиенту с корнем в ТЗ может всплыть позже — при декомпозиции `BR → SR → SPEC` или разработке `TC`. Тогда создаётся **новый** ADAPT на этой стадии (поле `trigger-stage`). На одно ТЗ приходится **ноль или более** корневых ADAPT — это штатный случай.

Если неясность с корнем **в декомпозиции** (а не в ТЗ) — она решается уточнением `SR`/`SPEC` **без** ADAPT. ADAPT возникает только когда корень — в языке или намерении ТЗ.

### 5.5 Lifecycle записи и утверждение

Каждая обратная находка проходит: `open → asked-to-client → answered → resolved → frozen` (с возможным возвратом `revised → asked-to-client`). Смысл статусов привязан к ACTZ:

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

**`decided-in` обязателен.** Каждая находка, требующая решения клиента, обязана нести `decided-in: ACTZ-NNN §M` — ссылку на пункт **подписанного** ACTZ. Ссылка на неподписанный ACTZ (`draft`/`sent`) и висячая ссылка — **fatal**. Утверждение ADAPT (QG-3) запрещено, пока есть запись в `open`/`asked-to-client`/`answered`/`revised` — все обязаны быть `resolved`, то есть иметь подписанное решение клиента.

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

**Подпись ADAPT — только архитектора.** ADAPT переходит `answered → approved` по подписи Архитектора: все находки отработаны (каждая `resolved` и несёт `decided-in` на подписанный ACTZ), прямая интерпретация технически реализуема. **Подписи клиента под ADAPT нет** — клиентские обязательства несёт ACTZ. После утверждения ADAPT **неизменяем**.

### 5.6 Изменения утверждённого ADAPT — три механизма

Frozen ADAPT не редактируется. Изменения — только добавлением нового артефакта по одному из трёх путей:

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

**Дезавуирование (`supersession`).** Новый `ADAPT-NNN` с полем `supersedes: ADAPT-MMM` и обязательным `supersession-rationale` (ссылка на противоречащее `BR`/`SR`/`SPEC` и его источник). Дезавуируемый ADAPT переходит в терминальное состояние **`superseded`** (отдельное от `obsolete`), остаётся неизменяемым и сохраняется для аудита; получает `superseded-by: ADAPT-NNN`. Все производные с `source.adapt: ADAPT-MMM` обязаны быть перенаправлены на дезавуирующий ADAPT или пере-выведены — **висячая ссылка на `superseded` запрещена**. Отдельной контрольной точки нет — проходит через тот же QG-3.

### 5.7 AI и adversarial review

Агент создаёт **draft** ADAPT автоматически (прямая интерпретация по разделам, попытка найти противоречия/пропуски/неясные термины, первичный term mapping). Это стартовая точка, не финал. Отдельный агент-критик с **другой моделью** ищет, что упущено. Клиент **не общается с AI напрямую**: вопросы агрегирует и переформулирует Архитектор; клиенту выносится подготовленный список решений (ACTZ), а не сырой вывод агента.

---

## 5A. ACTZ — протокол уточнения ТЗ

### 5A.1 Что это и чем отличается от ADAPT

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

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

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

### 5A.2 Происхождение и множественность

Два штатных источника:

1. **Из обратной находки.** Находка, требующая решения клиента, выносится в ACTZ; после подписания получает `decided-in: ACTZ-NNN §M`.
2. **По инициативе клиента, без находки.** Клиент сам предлагает решение. Такой ACTZ ссылается только на ТЗ; родительской находки нет. После подписания решение **обязано** быть отражено в ADAPT.

Кардинальность: **ТЗ : ACTZ = 1 : 0..N** (ноль протоколов законен — конвертация без вопросов не порождает документов); **ADAPT : ACTZ = 1 : 1..N** (находки одного ADAPT закрываются несколькими протоколами по мере раундов).

ACTZ **стадийно-независим**: поздний протокол — из разбора замечаний после демонстрации — штатный случай, а не исключение.

### 5A.3 Жизненный цикл

```text
draft → sent → signed → superseded
```

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

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

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

### 5A.4 Итоговое ТЗ — эталон сдачи-приёмки

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

Против итогового ТЗ выводятся приёмочные тесты `AT` (раздел 8A) и строится отчёт приёмки.

**ADAPT в эталон приёмки не входит.** Клиент отвечает только за то, что подписывал и понимал; внутренняя интерпретация из контрактного контура выведена целиком.

---

## 6. Иерархия требований и провенанс

- **BR (Business Requirement)** — фиксирует бизнес-цель группы связанных SR: кто, что, **зачем**. При изменении SR видна привязка к бизнес-потребности.
- **SR (System Requirement)** — что система делает; `parent` — ровно один BR (множественные parent запрещены).
- **TR (Task Requirement)** — задача реализации в трекере: Goal + критерии приёмки. Ссылается на `SR`/`SPEC`, **не** на ADAPT напрямую — все интерпретации уже в SR/SPEC.

### 6.1 Уровни системы и ссылки на вышестоящие требования

Каждый артефакт несёт `scope` с уровнем. Уровней три:

| Уровень | Что это | Кто может быть на уровне |
|---|---|---|
| `system` | Информационная система целиком | `BR`, `SR`, `TR` |
| `subsystem` | Техническое деление: компонент, сервис, команда | `BR` (если подсистема — самостоятельный продукт), `SR`, `TR` |
| `module` | Часть подсистемы, пригодная для одной задачи | `SR`, `TR` (но **не** `BR` — бизнес-цель на уровне модуля не формулируется) |

Базовая декомпозиция `BR → SR → TR` работает внутри одного уровня. Для составных систем уровни связываются **вверх**:

- **Подсистема как техническое деление** (не отдельный продукт): своего `BR` не имеет — наследует бизнес-цель системы; `SR` подсистемы имеет `parent` = `BR` системы.
- **Подсистема как самостоятельный продукт** (свой бизнес-владелец): имеет собственный корневой `BR`. Этот `BR` **обязан** декларировать `implements[]` — ссылку на `BR` родительской системы, которые он раскрывает. Без неё связь дерева подсистемы с деревом системы теряется, и traceability «зачем эта подсистема» становится невосстановимой.

Обязанность ссылаться вверх лежит на `BR` подсистемы (через `implements[]`), а не на родителе: система не знает заранее, какие подсистемы её реализуют — это они декларируют свою принадлежность. Поле `implemented-by[]` на родительском `BR` собирается носителем автоматически из обратных ссылок.

**implements-edge (подсистема → система).** `implements[]` — массив `id + scope.system` на `BR` родительской системы. Это типизированное межуровневое ребро (**не** parent): cardinality 0..N, без циклов, target в статусе `approved`+. Один `BR` подсистемы может раскрывать несколько `BR` системы. Запрет множественных `parent` на это ребро **не** распространяется — оно отдельного типа.

### 6.2 Структура хранения артефактов (информативно, зависит от носителя)

> Раздел **информативный**: RENAR не нормирует раскладку файлов — носителем может быть файловая система, база, трекер или их сочетание. Ниже — **пример** раскладки на файловом носителе; организация вправе устроить хранение иначе, лишь бы сохранялись связи `parent` / `source` / `implements[]` / `constrained-by[]` и машиночитаемость графа.

Удобный для файлового носителя ориентир — раскладка по системам и уровням, с TC рядом с проверяемым артефактом:

```text
<корень-требований>/
├── tz/                          # неизменяемые ТЗ и delta-ТЗ
│   ├── TZ-2026-001.md
│   └── TZ-2026-001-delta-1.md
├── adapt/                       # ADAPT (0..N на ТЗ), неизменяемы после frozen
│   └── ADAPT-001.md
├── <система>/
│   ├── br/                      # BR уровня system
│   │   └── BR-01.md
│   ├── sr/
│   │   └── SR-01.md
│   ├── spec/                    # SPEC всех 11 типов
│   │   ├── SPEC-API-01.md
│   │   └── SPEC-DATA-01.md
│   ├── tc/                      # TC рядом со своим scope; пары pos/neg вместе
│   │   ├── TC-01.md
│   │   └── TC-01-neg.md
│   └── <подсистема>/            # самостоятельный продукт — своё дерево
│       ├── br/                  # BR подсистемы с implements[] на BR системы
│       │   └── BR-01.md
│       ├── sr/
│       └── tc/
└── RENAR-CONFORMANCE.yaml       # манифест соответствия (раздел 14)
```

TR здесь нет: TR живёт в трекере задач, не отдельным файлом (раздел 2). Имена файлов = `id` артефакта — это даёт стабильную ссылку, переживающую переименование заголовка.

**Trace chain** (read-side) имеет два валидных варианта: через ADAPT (`source.adapt`) либо напрямую из ТЗ (`source.tz-section` + `source.adversarial-review-ref`). Оба машиночитаемы. Висячая ссылка на `superseded` ADAPT делает chain невалидной.

### 6.3 Требование, порождённое реализацией (`source: implementation-originated`)

Реализуя задачу, ты штатно добавляешь **внутренние технические детали**, которых нет в требованиях: защитную проверку входа, обработку граничного случая, журналирование. Требовать на каждую такую деталь ACTZ с подписью клиента — абсурдная церемония, и именно она толкает к молчаливой подгонке требований задним числом. Поэтому есть **узкий** легальный класс `source: implementation-originated`.

| Что | Куда |
|---|---|
| **Наблюдаемое клиентом поведение** (экран, поле, сообщение, срок, формат, объём поставки) | **Только** через контрактный контур: ADAPT + ACTZ с подписями. Послаблений нет |
| **Внутренняя техническая деталь без наблюдаемого клиентом поведения** | Допустим `source: implementation-originated` |

Граница — **наблюдаемость для клиента**, не размер правки. Сомнение трактуется в пользу контрактного контура.

Обязательная обвязка такого требования (все пять пунктов):

1. **Провенанс**: ссылка на единицу изменения реализации, которая его породила, и обоснование нужности.
2. **Утверждение человека**: явное одобрение супервайзера. Агент не может легализовать собственную добавку.
3. **TC до слияния**: покрывающий тест существует и проходит до включения изменения.
4. **Убитый мутант**: у такого TC красной истории быть не может (тест написан после кода и рождён зелёным) — зубастость доказывается **мутационной проверкой** (`mutation-check.mutants-killed ≥ 1`). Без убитого мутанта TC доказательством не является (раздел 8.2).
5. **Счётчик в метриках дрейфа**: рост доли `implementation-originated` — сигнал протечки процесса требований, он обязан быть виден.

Запрещённым остаётся: молчаливая правка существующего `SR` под поведение кода (нарушение MVR-1) и использование класса для наблюдаемого клиентом поведения (несоответствие: обязательство перед клиентом не может возникнуть из кода).

---

## 7. Спецификации (SPEC) — одиннадцать типов, закрытый список

Тип SPEC обязан принадлежать списку из одиннадцати. Новые типы локально создавать запрещено.

| Тип | Назначение |
|---|---|
| `SPEC-ARCH` | Архитектура: компоненты, границы, решения |
| `SPEC-API` | Контракты интерфейсов (endpoints, методы, форматы) |
| `SPEC-DATA` | Модели данных, схемы, миграции, классификация |
| `SPEC-INT` | Интеграции с внешними системами |
| `SPEC-PROC` | Процессы, workflow, оркестрация |
| `SPEC-UI` | Интерфейс пользователя, экраны, поведение |
| `SPEC-AI` | AI-компоненты: модель, риск-класс, judge-изоляция |
| `SPEC-SEC` | Безопасность: угрозы, контроли, требования |
| `SPEC-OPS` | Эксплуатация: развёртывание, мониторинг, SLO |
| `SPEC-TEST` | Тестовые стенды и данные: топология, эмуляторы и sandbox внешних систем, конфигурация прогона, датасеты, анонимизация |
| `SPEC-DOC` | Поставляемая проектная документация: состав, структура документов, проверяемые требования к ним |

SPEC — ось, параллельная требованиям. Связь с требованием — типизированное ребро `constrained-by[]` (SR ограничен спецификациями). Граф `depends-on` между SPEC обязан быть ациклическим (DAG).

---

## 8. Тест-кейсы (TC)

TC — самостоятельный артефакт со своим жизненным циклом, а не строка в коде. На каждое нормативное утверждение верифицируемого артефакта, охваченное хотя бы одним TC, **обязан** существовать парный **негативный** TC. Исключение — утверждение само описывает negative invariant.

- `verifies[]` указывает на проверяемый артефакт и его версию; обратная связь `verified-by` симметрична.
- `requirement-version` фиксируется: при инкременте версии требования TC переходит в нужное состояние (детект устаревания).
- Автоматизированный TC (`automation.status: automated`) обязан иметь непустой `automation.location` и **обязательное** `automation.kind` (`dynamic` | `static`; `static` — когда runner является статическим анализатором).
- Для `SPEC-AI`: judge-модель обязана отличаться по вендору от production-модели (изоляция оценки, P7).
- Необязательная привязка к задаче: `verifies-tr` + `verifies-claims[]` — тест сужается до объёма TR (подмножество утверждений родительского SR). Покрытие по-прежнему считается от утверждений артефакта, не от задач.

Состояния TC: `draft → ready → passing | failing`. Только runner-actor пишет `last-run`.

### 8.1 Шесть типов TC (закрытый список)

```text
tc-type ∈ { business, ux, system, contract, eval, security }
```

| Тип | Что проверяет | Применяется к |
|---|---|---|
| `business` | Достигнута ли бизнес-цель | BR |
| `ux` | Соответствует ли UX заявленному опыту | SPEC-UI |
| `system` | Ведёт ли система себя как описано | SR, SPEC-PROC, SPEC-ARCH |
| `contract` | Соблюдён ли контракт интерфейса | SPEC-API, SPEC-INT, SPEC-DATA |
| `eval` | Достигнуто ли качество AI-компонент | SPEC-AI |
| `security` | Соблюдены ли security-инварианты | SPEC-SEC |

**Типа `acceptance` больше нет** — он переименован в `business`. Приёмок две, по разные стороны развязки контуров: `business`-TC проверяет бизнес-цель BR (внутренний контур), `AT` — соответствие контракту (раздел 8A). Одно имя на два предмета было источником путаницы.

### 8.2 Изоляция авторства (P8) и красная история (P9)

**P8 — изоляция авторства теста.** Тест, созданный в процессе написания кода, ты подстроишь **под код**, а не под требование: он честно проверит написанное, но не требуемое. Изоляция обязательна по трём осям:

| Ось | Требование |
|---|---|
| **Время** | TC заморожен (`ready`) **до** начала реализации, которую он проверяет. TR не уходит в работу, пока связанные TC не в `ready` |
| **Автор** | Агент, пишущий тест, **не совпадает** с агентом, пишущим реализацию (разные сессии или модели). Провенанс TC сверяется с провенансом единицы изменения реализации |
| **Изменение** | Правка `## Pass-критерий` / `## Fail-критерий` замороженного теста — только через `[test-spec-change]` с утверждением инженера |

**P9 — красная история.**

> **Тест, ни разу не наблюдавшийся красным, не является доказательством.**

- **Фиксирующий прогон** выполняется **до** реализации: тест обязан быть **красным** — проверяемого поведения ещё нет. Переход «красный → зелёный» записывается носителем и является условием засчёта TC при QG-2.
- Зелёный результат на фиксирующем прогоне — **сигнал разбора**, а не успех: либо тест ничего не проверяет, либо функциональность уже существует. Оба случая требуют разбора инженером.
- **Наследование**: у задач без изменения наблюдаемого поведения (рефакторинг, миграция без изменения контракта) красная история **наследуется** от TC того же утверждения (`red-history.inherited-from`).
- **Исключение — `implementation-originated`** (раздел 6.3): такой тест рождается зелёным, красной истории у него быть не может. Компенсация обязательна: **убитый мутант** (`mutation-check.mutants-killed ≥ 1`).

**Зачем P9, если есть P8.** Изоляция гарантирует, что тест написан до кода и не тем, кто пишет код. Но она не гарантирует, что тест **что-то проверяет**: пустой тест, честно написанный изолированным агентом, проходит все три оси P8 и зелен с рождения. Красную дыру закрывает только красная история.

**Машинный сигнал ослабления нормы.** Если после правки теста **падает ранее зелёная система** — норма изменилась по факту, как бы правку ни классифицировали. Срабатывание блокирующее: правка проводится как изменение нормы (`[test-spec-change]` + утверждение инженера) либо отменяется.

---

## 8A. AT — приёмочный тест контрактного контура

### 8A.1 Зачем

Прослеживаемость TC замкнута через **интерпретацию**: `TC → SR → ADAPT → ТЗ`. Отсюда класс дефектов, который уровень TC не ловит **в принципе**: если интерпретация ТЗ неверна, все TC могут быть `passing` — система идеально соответствует **неверной** интерпретации — и при этом провалит приёмку у заказчика.

**AT** (`AT-NN`) выводится **исключительно** из **итогового ТЗ** (раздел 5A.4) и проверяет соответствие **контракту**, а не интерпретации.

### 8A.2 Изоляция как механизм генерации

AT создаёт **изолированный агент**: на вход подаётся **только итоговое ТЗ**. Доступ к ADAPT, BR / SR / SPEC, TC и коду **запрещён**. Модель агента-генератора AT обязана отличаться от модели основного агента.

Изоляция здесь — не гигиена, а **суть механизма**: AT есть симуляция взгляда заказчика. Агент, видевший ADAPT или SR, воспроизведёт **ту же** интерпретацию — и AT начнёт подтверждать её вместо контракта. Уровень приёмки схлопнется в уровень верификации, а ошибка толкования получит **ложное подтверждение соответствия**. Нарушение изоляции — **fatal**.

### 8A.3 Перегенерация перед испытаниями

> **AT перегенерируются перед каждыми испытаниями** от **действующей** редакции итогового ТЗ.

Каждый подписанный ACTZ порождает новую редакцию итогового ТЗ. AT, выведенные при планировании, к моменту испытаний устаревают — без перегенерации система в конце длинного заказа проверяется против контракта годичной давности. Устаревшая программа испытаний к испытаниям **не допускается**: гейт сверяет `tz-version` каждого AT с действующей редакцией и блокирует расхождение. Перегенерация дёшева — её выполняет тот же изолированный агент.

### 8A.4 Маршрутизация провалов (диагностика)

| AT | TC | Диагноз | Что чинится |
|---|---|---|---|
| ✗ | ✓ | **Ошибка интерпретации**: система соответствует ADAPT, но не контракту | ADAPT / ACTZ, затем производные требования |
| ✗ | ✗ | Дефект реализации | Код |
| ✓ | ✗ | Требование строже контракта либо TC неверен | Разбор: избыточное требование или дефект TC |
| ✓ | ✓ | Норма | — |

Первая строка — то, ради чего AT вводится: этот дефект не обнаруживается никаким TC.

### 8A.5 Обязательные поля и тело

- `verifies[]` — **только** `TZ §N` и `ACTZ-NNN §M`. Ссылка на внутренний артефакт (BR / SR / SPEC / TC) — **fatal**.
- `tz-version` — редакция итогового ТЗ, из которой AT выведен.
- `generator` — провенанс изолированного агента: вендор, модель, подтверждение отсутствия доступа к внутреннему контуру.
- `negative` — парность pos/neg как у TC; `status` и `automation` (включая `automation.kind`) — как у TC; `last-run` ведёт runner.
- `environment-ref` — стенд и датасет приёмочных испытаний. Поле заполняет **не генератор**: изолированный агент внутренних артефактов не видит. Привязку проставляет архитектор или runner **после** генерации — испытания воспроизводимы, изоляция не нарушена.
- **`tz_text`** — дословная цитата проверяемого пункта итогового ТЗ рядом с шагами — **обязательный** раздел тела AT. Цитата снимает спор на приёмке: предъявляется не пересказ, а сам пункт контракта.

**Отчёт приёмки** `ACCEPTANCE.md` — автогенерируемый: покрытие AT по разделам итогового ТЗ и пунктам подписанных ACTZ. Продукт не предъявляется к сдаче, пока не все AT в `passing` (раздел 9).

---

## 9. Жизненный цикл и контрольные точки (QG)

Состояния требований: `draft → approved → verified → deprecated → obsolete`.
Состояния ADAPT: `draft → review → asked → answered → approved → frozen`, и терминальное `superseded` при дезавуировании. Состояние `client-ready` **изъято**: вынесение вопросов клиенту — предмет ACTZ, а не состояние ADAPT.
Состояния ACTZ: `draft → sent → signed → superseded`.

| Точка | Что проверяет | Кто проводит | Уровень |
|---|---|---|---|
| **QG-0** Approval | Схема валидна, есть связь с родителем, указан источник | Архитектор / уполномоченный | required |
| **QG-1** Implementation | `TR` связан со `SPEC`, носитель реализации зафиксирован; связанные TC заморожены в `ready` (P8) | Инженер + runner | required |
| **QG-2** Verification | Все `TC` проходят, пара pos/neg, версии совпадают, у каждого TC есть красная история либо убитый мутант (P9) | Автоматический runner | required |
| **QG-3** Architecture | **Подпись Архитектора** под ADAPT; каждая находка `resolved` и несёт `decided-in` на подписанный ACTZ; дезавуирование — тоже здесь | Архитектор | declared / absent |
| **QG-4** Acceptance | Бизнес-результат принят (`achievement ≥ 80%`) | Заинтересованная сторона | declared / absent |
| **Релизный гейт приёмки (AT)** | Все `AT` в `passing`; `tz-version` каждого AT = действующая редакция итогового ТЗ; провенанс генератора подтверждает изоляцию | Изолированный агент + runner | **обязателен** |

QG-0..QG-2 обязательны (`required`). QG-3/QG-4 — `declared` или `absent`. Новые типы гейтов локально создавать запрещено.

**Релизный гейт приёмки не смешивается с QG-4:** QG-4 опционален и меряет бизнес-результат, релизный гейт — соответствие контракту. Бизнес-цель может быть достигнута при несоответствии контракту, и наоборот.

**Независимый от носителя enforcement.** Носитель обязан автоматически блокировать переходы при невыполненных предусловиях: promote-transition (V3/V4), approve-transition (V6), reference-validation (V1/V5), `implements`-edge validation, `adapt-applicability` validation, `adapt-supersession` validation (висячий `source.adapt` на `superseded` — fatal), `decided-in` на неподписанный или несуществующий ACTZ — fatal, подписанный ACTZ без отражения в ADAPT — fatal, нарушение изоляции генератора AT — fatal.

---

## 10. Роли и подписи

**Агент (AI) — штатный исполнитель**: primary-генератор черновиков `BR`/`SR`/`SPEC`/`TC`/draft-ADAPT и adversarial-критик. Но агент **не владелец** артефакта и **не ставит подписей**.

**Человек** — владелец, verifier и approver. По RACI: `R` (Responsible) = AI, `A` (Accountable) = Архитектор (русское имя роли Architect / Tech Lead со стороны исполнителя). Попытка объявить AI-агента Accountable — non-conformant.

Карта подписей — закрытая:

| Артефакт | Кто подписывает |
|---|---|
| **ТЗ** и delta-ТЗ | Клиент |
| **ACTZ** | **Двусторонне**: клиент + исполнитель (`client-signature` + `vendor-signature`; одно и то же лицо с обеих сторон — нарушение) |
| **ADAPT** | **Только Архитектор** |
| **AR** | Состязательный рецензент |
| `implementation-originated` | Супервайзер-человек |

Клиент подписывает **только ТЗ и ACTZ**. Подписи клиента под ADAPT **нет**: клиент подписывал бы инженерный документ, который не читал и не может оценить.

Происхождение AI фиксируется в `ai-provenance` (модель, шаблон промпта, токены, факт человеческой правки). Разные роли агентов обязаны быть разными агентами: основной ≠ состязательный рецензент; автор теста ≠ автор реализации (P8); генератор AT ≠ основной агент (модель другая, доступ к внутреннему контуру отсутствует).

---

## 11. Закрытые списки (нельзя расширять локально)

- **11 типов SPEC:** `ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS / TEST / DOC`.
- **6 типов TC:** `business / ux / system / contract / eval / security` (типа `acceptance` **нет**).
- **7 категорий находок:** `contradiction / gap / hidden-assumption / feasibility / regulatory / terminology / scope`.
- **9 нормативных принципов TC:** P1 полноценный артефакт, P2 документ ≠ реализация, P3 AI-generated, P4 AI-executed, P5 pos/neg парность, P6 `last-run` bot-managed, P7 judge ≠ production, **P8 изоляция авторства**, **P9 красная история**.
- **Quality Gates:** `QG-0 / QG-1 / QG-2 / QG-3 / QG-4`.
- **V1–V6** возможностей носителя: immutable history, atomic change unit, diff & review, branching, version pin, author + timestamp.
- **Состояния ADAPT:** `draft / review / asked / answered / approved / frozen / superseded` (состояния `obsolete` у ADAPT нет).
- **Состояния ACTZ:** `draft / sent / signed / superseded`.

Расширение любого списка — только формальной поправкой стандарта (исследовательский черновик → обсуждение → повышение minor-версии → руководство по миграции).

---

## 12. Жёсткие правила (нарушать нельзя)

- **ТЗ, подписанный ACTZ и утверждённый ADAPT неизменяемы** — только добавление новых артефактов с явной типизированной связью.
- **Не реконструировать `SR`/`SPEC` из кода** без bug-fix обоснования (инверсия источника истины). Узкое исключение — `implementation-originated` для внутренней технической детали, с обвязкой из раздела 6.3.
- **Не подгонять тесты** под реализацию; изменение проверяемого поведения помечается тегом `[test-spec-change]`.
- **Не писать тест тем же агентом, что пишет реализацию** (P8), и не засчитывать тест, ни разу не бывший красным (P9) — исключение только `implementation-originated` с убитым мутантом.
- **Провенанс обязателен** у каждого `BR`/`SR`/`SPEC` (`source.tz-section` всегда; `source.adapt` либо `source.adversarial-review-ref`).
- **Пара TC** (позитивный + негативный) на каждое нормативное утверждение.
- **Adversarial-обзор ТЗ обязателен всегда**; «ADAPT не нужен» — это зафиксированный вердикт другой модели, не молчаливое допущение.
- **Не подписывать ADAPT у клиента.** Клиенту выносится ACTZ; ADAPT подписывает только Архитектор.
- **Каждая находка, требующая слова клиента, несёт `decided-in` на пункт ПОДПИСАННОГО ACTZ.** Ссылка на `draft`/`sent` ACTZ — fatal. Подписанный ACTZ, не отражённый ни в одном ADAPT, — fatal.
- **AT выводится только из итогового ТЗ** изолированным агентом на другой модели; доступ генератора к ADAPT / BR / SR / SPEC / TC / коду запрещён; `verifies[]` AT ссылается только на `TZ §N` и `ACTZ-NNN §M`.
- **AT перегенерируются перед каждыми испытаниями** от действующей редакции итогового ТЗ; продукт не предъявляется к сдаче, пока не все AT в `passing`.
- **Закрытые списки** не выдумывать (раздел 11).
- **Висячая ссылка на `superseded` ADAPT** запрещена — перенаправляй или пере-выводи производные.

---

## 13. Минимальные формы записи (frontmatter)

### ТЗ
```yaml
id: TZ-YYYY-NNN
type: TZ
status: registered            # immutable после регистрации
signed-by-client: "<имя + роль>"
signed-date: "<ISO-date>"
document-version-ref: "<идентификатор версии носителя>"
```

### ADAPT
```yaml
id: ADAPT-NNN
type: ADAPT
trigger-stage: import-tz       # import-tz | decompose-br | decompose-sr | spec | tc
source-tz: { id: TZ-YYYY-NNN, signed-date: "<ISO>", signed-by-client: "<имя+роль>" }
parent-adapt: { id: ADAPT-NNN, delta-tz: TZ-YYYY-NNN-delta-N }   # для delta-ADAPT
supersedes: ADAPT-MMM          # только для дезавуирующего ADAPT
superseded-by: ADAPT-NNN       # auto-derived на дезавуируемом
supersession-rationale: "<противоречащее BR/SR/SPEC + источник>"   # mandatory если supersedes
status: draft | review | asked | answered | approved | frozen | superseded
approval:
  architect-signature: { signed-by: "<имя>", role: architect, signed-at: "<ISO>" }   # единственная подпись ADAPT
open-questions-count: 0        # обязательно 0 для approved
```
Каждая обратная находка в теле ADAPT:
```yaml
- id: B-NNN
  category: gap                # один из 7 закрытых
  status: open | asked-to-client | answered | resolved | revised | frozen
  decided-in: "ACTZ-NNN §M"    # mandatory для resolved; ACTZ обязан быть signed
```

### ACTZ (протокол уточнения ТЗ)
```yaml
id: ACTZ-NNN
type: ACTZ
contract-name: "Протокол уточнения ТЗ № N"
tz-ref: TZ-YYYY-NNN
resolves: [B-001, B-004]       # записи ADAPT, которые закрывает; отсутствует у ACTZ по инициативе клиента
decisions:                     # обязательно; язык обязательств, стабильный номер §M
  - { section: "§1", text: "<решение клиента на языке обязательств>" }
annexes: ["<новая версия приложения к ТЗ>"]   # если решением является новая версия приложения
status: draft | sent | signed | superseded
client-signature: { signed-by: "<имя>", role: "<роль>", organization: "<орг>", signed-at: "<ISO>" }   # mandatory для signed
vendor-signature: { signed-by: "<имя>", role: "<роль>", signed-at: "<ISO>" }                          # mandatory для signed
superseded-by: ACTZ-MMM        # mandatory при status: superseded
```

### BR
```yaml
id: BR-NN
type: BR
status: draft                  # draft → approved → verified → deprecated → obsolete
level: system | subsystem
implements: [{ id: BR-MM, scope.system: "<система>" }]   # для подсистемы (0..N)
source:
  adapt: ADAPT-NNN             # если ADAPT есть
  tz-section: "§N.N"           # обязательно всегда
  adversarial-review-ref: AR-NNN        # если source.adapt опущен → AR (issued, no-findings)
```
Тело (обязательные разделы):
```markdown
## Потребность
Кто (роль), что (действие), зачем (бизнес-цель) — одно предложение.
## Критерии успеха
Измеримые результаты, 3–7 пунктов; каждый независимо проверяем.
## Контекст
Откуда требование (ссылка на раздел ADAPT при наличии); какие альтернативы.
## Ограничения
Опционально: бизнес-ограничения (бюджет, сроки, регуляторика). Технических — нет.
```

### SR
```yaml
id: SR-NN
type: SR
status: draft
parent: BR-NN                  # ровно один
source:
  adapt: ADAPT-NNN
  adapt-section: "Forward §3"
  tz-section: "§3.4"           # обязательно всегда
constrained-by: [SPEC-API-02, SPEC-UI-04]
verified-by: [TC-NN, TC-NN-neg]
```
Вариант провенанса для внутренней технической детали (раздел 6.3) — **только** при `observable-by-client: false`:
```yaml
source:
  tz-section: "§N.N"                   # обязательно всегда, в том числе здесь
  implementation-originated:
    change-unit-ref: "<единица изменения реализации, породившая требование>"
    rationale: "<почему функциональность признана нужной>"
    human-approval: { approved-by: "<супервайзер-человек>", role: "<роль>", approved-at: "<ISO>" }
    observable-by-client: false        # true → несоответствие
    covering-tc: TC-NN                 # существует и проходит до слияния
    mutation-check: { mutants-killed: 1, report-ref: "<отчёт мутационной проверки>" }   # ≥ 1
```
Тело (обязательные разделы):
```markdown
## Требование
Одно предложение нормативной формы: «Система должна …».
## Поведение
Детальное наблюдаемое поведение; функциональные сценарии.
## Ограничения
Если применимо: нефункциональные (производительность, безопасность). Полные — в SPEC.
## Связь с SPEC
Если есть constrained-by[]: какие аспекты поведения нормированы какими SPEC.
```

### SPEC
```yaml
id: SPEC-API-NN
type: SPEC-API                 # один из 11 закрытых типов
status: draft
source: { adapt: ADAPT-NNN, tz-section: "§N.N" }
depends-on: [SPEC-DATA-NN]     # DAG, без циклов
```

### TR (в трекере, не файл)
```yaml
id: TR-NNN
type: TR
goal: "<что сделать>"
acceptance-criteria: ["<критерий 1>", "<критерий 2>"]
implements-spec: SPEC-API-NN
parent-sr: SR-NN
```
Тело (обязательные разделы; имена `Goal`/`Acceptance Criteria`/`Scope` канонические):
```markdown
## Goal
Один параграф; результат, который TR делает наблюдаемым.
## Acceptance Criteria
Нумерованный список опровержимых критериев; покрывает положительные и отрицательные сценарии.
## Scope
Что входит и что **не** входит в TR.
## Ссылки
Если применимо: на SPEC из implements-spec[] и разделы родительского SR.
```

### TC
```yaml
id: TC-NN
type: TC
tc-type: business             # business | ux | system | contract | eval | security  (acceptance ИЗЪЯТ)
negative: false               # парный TC-NN-neg обязателен (negative: true)
verifies: [{ id: SR-NN, requirement-version: "1.4" }]
verifies-tr: TR-NN            # опционально: сужение до объёма задачи
verifies-claims: ["§2.1"]     # опционально: подмножество утверждений родительского SR
status: draft                 # draft → ready → passing | failing | obsolete
red-history:                  # обязательно для засчёта TC доказательством (P9)
  fixing-run: { date: "<ISO>", result: fail }     # фиксирующий прогон ДО реализации — обязан быть красным
  green-transition: "<ISO>"                        # ведёт runner
  inherited-from: TC-NN                            # conditional: рефакторинг без изменения поведения
  not-applicable-reason: implementation-originated # conditional: класс раздела 6.3
mutation-check: { mutants-killed: 1 }              # mandatory если not-applicable-reason задан (≥ 1)
environment-ref: SPEC-TEST-NN  # mandatory если automation.kind: dynamic — стенд и датасет, против которых TC валиден; для static не применяется
automation:
  status: automated           # automated | manual-pending
  kind: dynamic               # ОБЯЗАТЕЛЬНО: dynamic | static
  location: "<путь/идентификатор>"                 # mandatory если automated
judge: { vendor: "<провайдер>", model: "<модель>" }   # mandatory для ux | eval; вендор ≠ production (P7)
ai-provenance: { generated-by: "<вендор>-<модель>@<дата>", human-edits: false }   # автор теста ≠ автор реализации (P8)
```
Тело (обязательные разделы; `## Pass-критерий` и `## Fail-критерий` — фиксированные имена):
```markdown
## Контекст
На какой пункт верифицируемого артефакта ссылается TC; цитата или пересказ.
## Предусловия
Состояние системы и данных для прогона; seed-механизм.
## Шаги
Действия runner. Для tc-type: ux — намерения, не селекторы.
## Pass-критерий
Бинарный, наблюдаемый, воспроизводимый.
## Fail-критерий
Наблюдаемые признаки нарушения (не отрицание Pass): утечки, side-effects, гонки.
## Постусловия
Ожидаемое состояние после прогона; cleanup.
## Out of scope
Что намеренно не проверяется, с указанием парного TC.
```

### AT (приёмочный тест от контракта)
```yaml
id: AT-NN
type: AT
verifies:                     # ТОЛЬКО контрактный контур; ссылка на BR/SR/SPEC/TC — fatal
  - "TZ §3.4"
  - "ACTZ-001 §2"
tz-version: "<редакция итогового ТЗ>"    # обязана совпадать с действующей редакцией
generator:                    # изолированный агент
  vendor: "<провайдер>"
  model: "<модель>"           # обязана отличаться от модели основного агента
  internal-access: false      # доступа к ADAPT / BR / SR / SPEC / TC / коду не было; true → fatal
negative: false               # парность pos/neg как у TC
status: draft                 # draft → ready → passing | failing | obsolete
environment-ref: SPEC-TEST-NN            # обязательно: стенд и датасет приёмочных испытаний; проставляется НЕ генератором, а архитектором или runner'ом ПОСЛЕ генерации — изоляция не нарушается
automation: { status: automated, kind: dynamic, location: "<путь/идентификатор>" }
```
Тело AT — как у TC, плюс **обязательный** раздел с дословной цитатой пункта контракта:
```markdown
## tz_text
Дословная цитата проверяемого пункта итогового ТЗ (не пересказ).
```

---

## 14. Conformance-минимум

Проект декларирует соответствие через **manifest** (неизменяемый, V1) с обязательными полями:

```yaml
renar-version: 1.0
senar-version: "<версия>"
level: RENAR-1                 # RENAR-1 (ad-hoc) … RENAR-5 (оптимизирующий)
mandatory-clauses:
  sot-inversion: true
  substrate-v1-v6: { v1: true, v2: true, v3: true, v4: true, v5: true, v6: true }
  adapt-reactive: true
  spec-types-closed-list: true
  tc-pos-neg-pairing: true
  quality-gates-closed-list: true
  conformance-manifest: true
```

Реализация может **ужесточить** требования (`declared-stricter`: QG-3/QG-4 как `required` и т. п.), но не **ослабить**: нельзя объявить ADAPT опциональным, допустить single-TC для нормативного утверждения или опустить `senar-version`/`level`. Уровни `RENAR-1..RENAR-5` отражают зрелость процесса, не объём документации.

---

## 15. Глоссарий ключевых терминов

- **ТЗ** — техническое задание: договорной вход клиента, неизменяемый.
- **ADAPT** — **внутренняя** интерпретация ТЗ (прямая интерпретация + обратные находки); реактивный, 0..N на ТЗ; подпись только архитектора.
- **ACTZ** — протокол уточнения ТЗ («Протокол уточнения ТЗ № N»): решения, вынесенные клиенту; **двусторонняя** подпись, контрактный вес; `draft → sent → signed → superseded`.
- **Итоговое ТЗ** (effective TZ) — начальное ТЗ + все подписанные ACTZ; эталон сдачи-приёмки.
- **`decided-in`** — ссылка находки на пункт **подписанного** ACTZ, в котором зафиксировано решение клиента.
- **AT** — приёмочный тест от контракта: выводится изолированным агентом только из итогового ТЗ; перегенерируется перед каждыми испытаниями.
- **P8 (изоляция авторства)** — тест заморожен до реализации; автор теста ≠ автор реализации; правка критериев — через `[test-spec-change]`.
- **P9 (красная история)** — тест, ни разу не бывший красным, не является доказательством.
- **`implementation-originated`** — узкий класс провенанса для внутренней технической детали; обязателен убитый мутант.
- **Прямая интерпретация (Forward)** — перевод раздела ТЗ на язык требований.
- **Обратная находка (backward finding)** — зарегистрированный вопрос/проблема по 7 категориям.
- **Adversarial review** — обзор отдельным агентом с другой моделью; выносит вердикт; фиксируется как AR.
- **Provenance / source** — машиночитаемое происхождение артефакта.
- **implements-edge** — типизированное ребро «BR подсистемы реализует BR системы».
- **Дезавуирование** (`supersession`) — отмена ранее верного, но опровергнутого решения; состояние `superseded`.
- **QG (Quality Gate)** — контрольная точка перехода жизненного цикла.
- **SoT inversion** — требования (не код) суть источник истины о поведении.
- **MVR** — Minimum Viable RENAR: семь обязательных утверждений.
- **Архитектор** — русское имя роли Architect / Tech Lead; владелец и подписант со стороны исполнителя (в том числе единственный подписант ADAPT).

---

*RENAR 1.0 — операционная редакция для агента. Полный нормативный корпус: [renar.tech](https://renar.tech). © 2026 Вадим Соглаев, Андрей Юмашев. CC BY-SA 4.0.*