RENAR Core

Minimum Viable RENAR (MVR)

5 правил, 1 обязательный артефакт (ADAPT), 2 шлюза качества и минимальный walkthrough — всё, что нужно, чтобы вести требования как Source of Truth (SoT) и не дать AI-ассистентам «дрейфовать» в свободные интерпретации. Никакого специального инструментария не требуется. Текстовый редактор и любая система контроля версий (substrate) — достаточно для старта. Когда зрелость практики растёт, автоматизация помогает удерживать дисциплину при масштабировании. Время чтения: 20 минут.

Для кого это

Вы пишете требования к ПО или работаете с AI-агентами, которые пишут код по этим требованиям. Вы заметили: AI красиво формулирует требования и красиво пишет тесты, но реализация всё равно «не то». Клиент при приёмке говорит: «мы это так не имели в виду». Тесты зелёные, продукт неверный.

RENAR Core — это лёгкая дисциплина инженерии требований для AI-нативной разработки. Она ловит расхождение между договорным ТЗ, инженерной интерпретацией и реализацией — до того, как разойтись стало дорого. Работает с любым substrate (git, Raven, любая БД с версионностью), любым AI-инструментом, любым процессом разработки.

Для команд, которым нужны полная трассировка, audit trail и compliance, есть полный RENAR Standard — 15 нормативных глав.

Ключевые термины

ТЗ — техническое задание, договорной документ с клиентом. Подписано → immutable. Если в ТЗ ошибка/гэп/противоречие — ТЗ не редактируется; правки идут через ADAPT.

ADAPT — артефакт двусторонней адаптации ТЗ. Forward: инженерная интерпретация каждого раздела ТЗ. Backward: список вопросов/противоречий/гэпов, на которые клиент должен дать ответ перед началом реализации. Подписывается дважды: клиентом и архитектором.

SR (Software Requirement) — инженерное требование, выводимое из approved ADAPT. SR — единица, которая верифицируется тест-кейсом.

TC (Test Case) — тест-кейс, проверяющий что делает система, а не как. Позитивный + негативный сценарий парно.

Substrate — система хранения и версионирования артефактов (git, Raven, БД с историей). RENAR не привязан к конкретному substrate — требуются только capabilities (immutable history, atomic change, links).

Source of Truth (SoT) — при расхождении кода и требования побеждает требование. Код — следствие, не источник.

5 правил MVR

Правило 1. ADAPT перед SR

Каждое ТЗ получает ADAPT — артефакт, в котором инженер фиксирует:

Forward — как поняли каждый раздел ТЗ (цитата → инженерная интерпретация → достроенные сценарии → scope: входит/не входит).
Backward — что неясно, противоречиво или отсутствует в ТЗ. Список вопросов клиенту.
Term mapping — таблица «термин клиента → инженерное понимание».

SR не выводятся напрямую из ТЗ. SR ссылаются на разделы approved ADAPT.

Зачем это нужно. Без ADAPT инженерные интерпретации идут «молчком» в SR и код. Клиент при приёмке говорит «мы это не имели в виду» — и начинается переоткрытие ТЗ либо тихий компромисс со сдвигом сроков. ADAPT делает интерпретацию явной и подписанной — расхождение ловится до написания кода, не после.

Правило 2. Код не SoT

При расхождении между кодом и требованием побеждает требование. Если код делает X, а ADAPT/SR говорит Y — это дефект кода, а не «фактическое требование изменилось».

Если требование действительно нужно изменить — изменение идёт через delta-ADAPT с подписью клиента, а не через «переписали код, потом подгоним требование».

Зачем это нужно. «Код — это документация» работает только до первой переуступки команды или до первого судебного спора с клиентом. ТЗ — это контракт; ADAPT/SR — формальная интерпретация контракта; код — её реализация. Перевернуть иерархию = потерять провенанс.

Правило 3. Версионирование на substrate

Все артефакты (ТЗ, ADAPT, SR, TC) хранятся на substrate с capabilities:

Capability	Минимум
Immutable history	После approval запись не редактируется
Atomic change	Создание/обновление — одной транзакцией
Stable identifier	ID артефакта переживает rename
Cross-link	Артефакт ссылается на другой по ID
Version pin	SR может сослаться на конкретную ревизию ADAPT
Audit query	«Кто и когда подписал ADAPT-001» — отвечается одной командой

Конкретный substrate — на выбор: git с PR-ревью; Raven (документная БД с подписями); любая БД с историей и подписями. RENAR Core не требует git — только перечисленные capabilities.

Зачем это нужно. AI-агент через 3 месяца спросит «откуда это требование». Если substrate не помнит истории — ответа нет. Если substrate забывает кто подписал — спор с клиентом невозможен. Versioning — не «git-привычка», а инженерное требование к самой системе хранения требований.

Правило 4. TC pos/neg парность

Каждый SR имеет минимум:

1 позитивный TC — счастливый путь, удовлетворяет SR.
1 негативный TC — граничное условие, ошибочный ввод, отказ внешней системы, недостаток прав.

TC проверяет что делает система (наблюдаемое поведение), а не как (детали реализации). Тест, который ломается при рефакторинге без изменения поведения — это тест реализации, его переписать.

Зачем это нужно. AI-агенты охотно пишут позитивные тесты и обходят негативные («счастливый путь покрыт, всё ок»). 80% инцидентов в продакшене — это именно негативные сценарии: пустой ввод, конкуренция, отказ внешнего сервиса. Без принудительной парности негативный путь остаётся непроверенным до первого инцидента.

Правило 5. Spot-check ручной верификации

Раз в спринт (или раз в N задач, если нет спринтов) инженер вручную проверяет 5 случайных passing TC:

Запускает TC сам.
Сверяет фактический результат с тем, что заявлено в SR.
Проверяет, что TC действительно проверяет SR, а не подделан под код.

Если хотя бы один из 5 spot-check провалился — расследовать причину (Правило 7 SENAR Core: устраняй причину, не симптом).

Зачем это нужно. AI-агенты способны написать TC, который формально зелёный, но семантически не проверяет SR (например, assert True, мок возвращает ожидаемое значение независимо от поведения). Автоматизация не ловит такие подделки — ловит только человек глазами. Spot-check — дешёвый санитарный фильтр.

1 обязательный артефакт — ADAPT

Назначение

ADAPT (Adaptive Document for Articulating Project’s TZ) — формализованная двусторонняя интерпретация ТЗ. Один ADAPT на одно ТЗ (плюс delta-ADAPT на каждое delta-ТЗ).

Минимальная схема

Frontmatter

---
id: ADAPT-NNN                       # immutable; NNN — порядковый номер в проекте
title: "Адаптация ТЗ <name>"
type: ADAPT

source-tz:
  id: TZ-YYYY-NNN
  signed-date: "<ISO-date>"
  signed-by-client: "<name-role>"
  document-ref: "<substrate-native-ref>"   # ссылка на pinned ревизию ТЗ

status: draft | review | approved | frozen

approval:
  client-signature:
    signed-by: "<name>"
    organization: "<client-org>"
    signed-at: "<ISO-datetime>"
    signature-ref: "<substrate-native-ref>"
  architect-signature:
    signed-by: "<name>"
    signed-at: "<ISO-datetime>"

open-questions-count: integer        # для approved обязательно 0
resolved-questions-count: integer

ai-provenance:
  generated-by: "<vendor>-<model>@<date>"
  human-edits: true                  # обязательно true для approved
---

Body — обязательные разделы

## Краткое содержание
<3-5 параграфов: о чём ТЗ, scope, основные acceptance критерии>

## Term mapping (клиент → инженер)
| Термин клиента | Инженерное понимание | Раздел ТЗ |
|---|---|---|

## Forward: интерпретация по разделам ТЗ

### ТЗ §N. <название>
<Цитата>
**Интерпретация**: <инженерное понимание>
**Достроенные сценарии**: <список>
**Scope**: входит/не входит
**Forward links** (после approval): SR-NN, SPEC-NN

## Backward: обнаруженные проблемы

### B-001: <короткое описание>
- **Категория**: contradiction | gap | hidden-assumption | feasibility | regulatory | terminology | scope
- **Статус**: open → asked-to-client → answered → resolved → frozen
- **Описание проблемы**: <...>
- **Вопрос к клиенту**: <...>
- **Ответ клиента** (после answered): <кто, когда, что ответил>
- **Resolution** (после resolved): <как интегрирован ответ в Forward>

## Резюме backward findings
| Категория | Open | Asked | Answered | Resolved |
|---|---|---|---|---|

Lifecycle backward записи

open → asked-to-client → answered → resolved → frozen
                ↑                       │
                └────── revised ────────┘  (если ответ клиента расплывчатый)

open — инженер записал, клиента ещё не спрашивали.
asked-to-client — вопрос передан клиенту (с датой и каналом).
answered — клиент ответил; ответ зафиксирован в ADAPT с автором и датой.
resolved — ответ интегрирован в Forward; обновлён term mapping и/или достроенные сценарии.
frozen — после approval ADAPT все backward записи immutable.

Категории backward (закрытый список)

Только 7 категорий, новые добавляются только через изменение полного RENAR Standard:

Двойная подпись

ADAPT переходит в approved только когда:

Все backward записи в статусе resolved (open-questions-count == 0).
Подписал клиент (или представитель с полномочиями) — что forward совпадает с тем что хотели, и ответы на backward финальные.
Подписал архитектор — что backward отработаны полностью, forward технически реализуем.

Substrate-нативный механизм: на git — PR с двумя required reviewers; на Raven — endpoint approval с двумя signature-полями. Конкретика — на substrate.

2 Шлюза качества

Два шлюза, через которые проходит каждое требование. Метод обеспечения — на выбор (вручную, автоматически, на ревью); важно, чтобы проверка состоялась.

Шлюз качества QG-ADAPT-approve

Применяется при попытке перевести ADAPT в статус approved.

#	Проверка	Правило
1	Forward охватывает все разделы ТЗ (нет пропущенных §)	Правило 1
2	Term mapping заполнен; нет неопределённых терминов клиента	Правило 1
3	Все backward записи в статусе `resolved` (`open-questions-count == 0`)	Правило 1
4	Подпись клиента присутствует, дата ≥ даты последнего `answered`	Правило 1
5	Подпись архитектора присутствует	Правило 1
6	`ai-provenance.human-edits == true` (текст видел человек)	Правило 1

Если хотя бы один пункт не выполнен — ADAPT остаётся в review, approval блокируется.

Шлюз качества QG-2 verified-by-TC

Применяется при попытке перевести SR в статус verified.

#	Проверка	Правило
1	SR ссылается на approved ADAPT (раздел Forward)	Правила 1, 2
2	Для SR существует ≥ 1 позитивный TC, и он зелёный	Правила 3, 4
3	Для SR существует ≥ 1 негативный TC, и он зелёный	Правило 4
4	TC проверяют поведение из SR, а не детали реализации	Правило 4
5	В текущем спринте spot-check 5 случайных passing TC пройден	Правило 5
6	Версия substrate, к которой привязан TC, pinned к ревизии SR	Правило 3

Если что-то не выполнено — SR остаётся в review. Зелёные тесты без spot-check (пункт 5) не основание для verified.

Когда переходить на RENAR Standard

RENAR Core достаточен, пока:

Один договорной клиент или работа без внешнего клиента (внутренний продукт).
Команда ≤ 5 человек.
Нет жёстких compliance-требований (ФЗ-152, GDPR, AI Act, отраслевая регуляторика).
Один substrate, без multi-project координации.

Триггеры перехода на полный RENAR Standard (15 глав):

Триггер	Что добавляет Standard
Появился договорной клиент с подписанным ТЗ → ADAPT нужен с юридически весомой двойной подписью	Глава 5 ADAPT — полная схема, signature requirements, errata workflow
Команда > 5 человек, нужны выделенные роли	Глава 4 Roles — Architect, Requirements Engineer, Reviewer, QA
Compliance (ФЗ-152, GDPR, AI Act)	Глава 11 Compliance mapping; reference appendix `03-ai-risk-register`
Multi-project / multi-team координация	Глава 9 Lifecycle + delta-ADAPT chains
Нужен audit trail для регулятора	Глава 12 Provenance, KG schema
Внедряется AI-агент в роли requirements engineer	Глава 13 AI Generation; reference `04-ai-style-guide`
Появились SPEC-* (API, DATA, ARCH, SEC, UI)	Глава 6 Specifications-as-parallel-axis

Переход не «всё или ничего» — Standard внедряется главами по мере роста зрелости.

Минимальный walkthrough

Один сквозной пример: ТЗ → ADAPT → SR → TC. Демонстрирует Правила 1, 2, 4.

Шаг 1. ТЗ (фрагмент)

TZ-2026-001 §3.1 Регистрация пользователя
Система должна позволять клиенту зарегистрироваться через email.
После регистрации клиент получает доступ к личному кабинету.

Шаг 2. ADAPT-001 — Forward (фрагмент)

### ТЗ §3.1 Регистрация пользователя

**Цитата**: «Система должна позволять клиенту зарегистрироваться через email. После регистрации клиент получает доступ к личному кабинету.»

**Интерпретация**: User с ролью customer создаёт аккаунт через POST /auth/sign-up
с email + password. Email верифицируется отдельным шагом перед первым входом.

**Достроенные сценарии**:
- sign-up: email + password → создание User в статусе `unverified`
- email verification: клик по ссылке из email → перевод User в `verified`
- первый вход: только для `verified` → редирект в личный кабинет

**Scope**:
- Входит: email/password, email verification, личный кабинет (профиль).
- НЕ входит: OAuth-провайдеры (Google/Apple), SMS-верификация, 2FA.

**Forward links** (после approval): SR-03, SR-04, SR-05.

Шаг 3. ADAPT-001 — Backward (1 запись)

### B-007: gap — что происходит при попытке входа неверифицированного пользователя

- **Категория**: gap
- **Статус**: resolved
- **Ссылка на ТЗ**: §3.1
- **Описание**: ТЗ не описывает поведение системы, если пользователь
  пытается войти до email-верификации.
- **Вопрос к клиенту**: показывать сообщение «подтвердите email» и предложить
  отправить письмо повторно — или блокировать молча с 401?
- **Asked-to-client**: 2026-05-10
- **Ответ клиента**: 2026-05-12, Иванов И.И. (PM): «Показать сообщение
  + кнопку повторной отправки. 401 без объяснения — плохой UX.»
- **Resolution**: добавлен сценарий в Forward §3.1; создан SR-05.

Шаг 4. SR-03 (derived from ADAPT-001 §3.1 Forward)

---
id: SR-03
title: "Sign-up через email/password"
source:
  adapt: ADAPT-001
  adapt-section: "Forward §3.1"
  tz-section: "§3.1"
status: verified
verified-by: [TC-15, TC-16]
---

Описание: POST /auth/sign-up принимает {email, password}.
При валидных данных создаёт User в статусе `unverified`, возвращает 201.
При невалидном email возвращает 422 с указанием поля.

Шаг 5. TC pos/neg парность

TC-15 (позитивный):
  given: новый email, валидный password (≥ 8 символов)
  when: POST /auth/sign-up {email, password}
  then: status 201; User создан в статусе unverified; email с verification link отправлен

TC-16 (негативный):
  given: невалидный email "not-an-email"
  when: POST /auth/sign-up {email, password}
  then: status 422; body содержит {"field": "email", "error": "invalid format"}

Trace chain полностью: TC-16 → SR-03 → ADAPT-001 §3.1 Forward → TZ-2026-001 §3.1.

При аудите через год: «откуда взялось требование возвращать 422» — ответ из B-007 не возникает (B-007 о другом), но trace от TC к ТЗ восстанавливается без догадок.

Что дальше

RENAR Core — отправная точка. Когда команда растёт, объём ТЗ/SR увеличивается или появляются compliance-требования, переходите на полный RENAR Standard поэтапно (см. таблицу триггеров выше).

Соответствие Core: если вы соблюдаете 5 правил, ведёте ADAPT на каждое ТЗ и стабильно проходите оба шлюза — вы практикуете RENAR Core. Никакого официального подтверждения не требуется; самооценка.

Соответствие правил Core правилам Standard:

Правило Core	Эквивалент в Standard
1. ADAPT перед SR	Глава 5 (ADAPT) + Глава 9 §9.2 (lifecycle)
2. Код не SoT	Глава 1 §1.1 (SoT principle) + Глава 14 §14.1
3. Versioning на substrate	Глава 3 (Substrate capabilities V1-V6)
4. TC pos/neg парность	Глава 10 §10.1 (test discipline) + QG-2
5. Spot-check ручной	Глава 10 §10.3 (manual sampling) + Rule 9.5 audit

Краткая справочная карта

Перед началом проекта:

Создайте ADAPT-001 на ТЗ. Forward по каждому §. Backward — всё что неясно.
Спросите клиента по backward. Зафиксируйте ответы с датой и автором.
Подпишите ADAPT дважды (клиент + архитектор). До approval не пишите SR.

При написании SR:

SR ссылается на approved ADAPT §, не на ТЗ напрямую.
Каждый SR — минимум 1 позитивный + 1 негативный TC. Парно.

Перед закрытием SR (QG-2 verified-by-TC):

Оба TC зелёные.
TC проверяют поведение, не реализацию.
В текущем спринте spot-check 5 случайных passing TC прошёл.

При изменении требований:

ТЗ не редактируете. Клиент даёт delta-ТЗ → создаёте delta-ADAPT с новой подписью.
SR/TC обновляются после approval delta-ADAPT, не до.