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

**Версия 1.3-draft** | Авторы: Вадим Соглаев, Андрей Юмашев | [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 ─────┘   (тесты)
```

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

**Провенанс обязателен.** У каждого `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).
4. **MVR-4 — 9 типов 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. **Декомпозиция:** ADAPT/ТЗ → `BR` (бизнес-цель) → `SR` (поведение системы). Каждое требование указывает `source`.
5. **Спецификации:** `SR` → `SPEC-<ТИП>` со связями `constrained-by[]`.
6. **Задачи:** `SR`/`SPEC` → `TR` (Goal + критерии приёмки) в трекере.
7. **Тесты:** на каждое нормативное утверждение — пара `TC` (позитивный + негативный).
8. **Контрольные точки:** проводи `QG-0 → QG-1 → QG-2` (раздел 9).

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

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

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

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

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

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

| Шаг | Что делает агент | Что утверждает человек |
|---|---|---|
| Adversarial-обзор | Агент-критик (другая модель) выносит вердикт | Архитектор фиксирует вердикт как свидетельство |
| ADAPT | Агент готовит draft (прямая интерпретация + находки) | **Двойная подпись:** клиент + Архитектор (QG-3) |
| QG-0 Approval | Агент создаёт `BR`/`SR`/`SPEC` с провенансом | Архитектор одобряет переход в `approved` |
| QG-4 Acceptance | Агент предъявляет результат | Stakeholder принимает бизнес-результат |

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

---

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

### 5.1 Зачем

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

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

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

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

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

### 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`). Утверждение ADAPT (QG-3) запрещено, пока есть запись в `open`/`asked-to-client`/`answered`/`revised` — все обязаны быть `resolved`.

ADAPT утверждается **двойной подписью**: клиент (прямая интерпретация совпадает с замыслом; ответы финальны) + Архитектор (находки отработаны; интерпретация реализуема). После утверждения ADAPT **неизменяем**.

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

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

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

**Дезавуирование (`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 напрямую**: вопросы агрегирует и переформулирует Архитектор; ответ клиента он транскрибирует в 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 всех 9 типов
│   │   ├── 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 невалидной.

---

## 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 — ось, параллельная требованиям. Связь с требованием — типизированное ребро `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`.
- Для `SPEC-AI`: judge-модель обязана отличаться по вендору от production-модели (изоляция оценки).

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

---

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

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

| Точка | Что проверяет | Кто проводит | Уровень |
|---|---|---|---|
| **QG-0** Approval | Схема валидна, есть связь с родителем, указан источник | Архитектор / уполномоченный | required |
| **QG-1** Implementation | `TR` связан со `SPEC`, носитель реализации зафиксирован | Engineer + runner | required |
| **QG-2** Verification | Все `TC` проходят, пара pos/neg, версии совпадают | Автоматический runner | required |
| **QG-3** Architecture | Двойная подпись ADAPT (клиент + Архитектор); дезавуирование — тоже здесь | клиент + Архитектор | declared / absent |
| **QG-4** Acceptance | Бизнес-результат принят | Stakeholder | declared / absent |

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

**Независимый от носителя 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).

---

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

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

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

Происхождение AI фиксируется в `ai-provenance` (модель, шаблон промпта, токены, факт человеческой правки). Клиент подписывает только **ТЗ** и **ADAPT**.

---

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

- **9 типов SPEC:** `ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS`.
- **7 категорий находок:** `contradiction / gap / hidden-assumption / feasibility / regulatory / terminology / scope`.
- **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:** включая терминальное `superseded`.

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

---

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

- **ТЗ и утверждённый ADAPT неизменяемы** — только добавление новых артефактов с явной типизированной связью.
- **Не реконструировать `SR`/`SPEC` из кода** без bug-fix обоснования (инверсия источника истины).
- **Не подгонять тесты** под реализацию; изменение проверяемого поведения помечается тегом `[test-spec-change]`.
- **Провенанс обязателен** у каждого `BR`/`SR`/`SPEC` (`source.tz-section` всегда; `source.adapt` либо `source.adversarial-review-ref`).
- **Пара TC** (позитивный + негативный) на каждое нормативное утверждение.
- **Adversarial-обзор ТЗ обязателен всегда**; «ADAPT не нужен» — это зафиксированный вердикт другой модели, не молчаливое допущение.
- **Закрытые списки** не выдумывать (раздел 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 | client-ready | answered | approved | frozen | superseded | obsolete
approval:
  client-signature: { signed-by: "<имя>", role: "<роль>", organization: "<орг>", signed-at: "<ISO>" }
  architect-signature: { signed-by: "<имя>", role: architect, signed-at: "<ISO>" }
open-questions-count: 0        # обязательно 0 для approved
```

### 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: "<вердикт>"   # если source.adapt опущен
```
Тело (обязательные разделы):
```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]
```
Тело (обязательные разделы):
```markdown
## Требование
Одно предложение нормативной формы: «Система должна …».
## Поведение
Детальное наблюдаемое поведение; функциональные сценарии.
## Ограничения
Если применимо: нефункциональные (производительность, безопасность). Полные — в SPEC.
## Связь с SPEC
Если есть constrained-by[]: какие аспекты поведения нормированы какими SPEC.
```

### SPEC
```yaml
id: SPEC-API-NN
type: SPEC-API                 # один из 9 закрытых типов
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: acceptance           # acceptance | ux | system | contract | eval | security
negative: false               # парный TC-NN-neg обязателен (negative: true)
verifies: [{ id: SR-NN, requirement-version: "1.4" }]
status: draft                 # draft → ready → passing | failing
automation: { status: automated, location: "<путь/идентификатор>" }
```
Тело (обязательные разделы; `## Pass-критерий` и `## Fail-критерий` — фиксированные имена):
```markdown
## Контекст
На какой пункт верифицируемого артефакта ссылается TC; цитата или пересказ.
## Предусловия
Состояние системы и данных для прогона; seed-механизм.
## Шаги
Действия runner. Для tc-type: ux — намерения, не селекторы.
## Pass-критерий
Бинарный, наблюдаемый, воспроизводимый.
## Fail-критерий
Наблюдаемые признаки нарушения (не отрицание Pass): утечки, side-effects, гонки.
## Постусловия
Ожидаемое состояние после прогона; cleanup.
## Out of scope
Что намеренно не проверяется, с указанием парного TC.
```

---

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

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

```yaml
renar-version: 1.3-draft
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 на ТЗ.
- **Прямая интерпретация (Forward)** — перевод раздела ТЗ на язык требований.
- **Обратная находка (backward finding)** — зарегистрированный вопрос/проблема по 7 категориям.
- **Adversarial review** — обзор отдельным агентом с другой моделью; выносит вердикт.
- **Provenance / source** — машиночитаемое происхождение артефакта.
- **implements-edge** — типизированное ребро «BR подсистемы реализует BR системы».
- **Дезавуирование** (`supersession`) — отмена ранее верного, но опровергнутого ADAPT; состояние `superseded`.
- **QG (Quality Gate)** — контрольная точка перехода жизненного цикла.
- **SoT inversion** — требования (не код) суть источник истины о поведении.
- **MVR** — Minimum Viable RENAR: семь обязательных утверждений.
- **Архитектор** — русское имя роли Architect / Tech Lead; владелец и подписант со стороны исполнителя.

---

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