02. Переход на RENAR¶

Команды редко начинают с чистого листа. Эта глава — про то, как перевести существующий проект с ручного цикла «ТЗ → код» на RENAR постепенно, шаг за шагом, без остановки разработки. Каждый уровень даёт осязаемую пользу; команда выбирает, какого из RENAR-N достигать исходя из реальной ценности, а не из гонки за «полным соответствием» объявлениям на бумаге.

Предпосылки: RENAR Core, standard/11-maturity-model (закрытый список уровней RENAR-1..RENAR-5), guide/07-failure-modes. Уже на раннем RENAR с legacy типами (INT-TC, AIC, …) — см. 10-migration-v1.

1. Оценка: где команда сейчас¶

Прежде чем мигрировать, оцените текущее состояние. Чек-лист «pre-RENAR»:

Признак	Pre-RENAR	RENAR-1 минимум
ТЗ существует как артефакт	В чате / Google Doc / Notion	Зафиксировано в носителе как файл
Кто-то ведёт требования	Только в трекере (Jira / Linear)	В носителе как BR / SR / ADAPT
Откуда взялось требование	По памяти / переспрашиваем	Любой может найти источник в носителе
Изменения требований	Устно на дейли	Через явный change-set (delta-ТЗ)
Тесты	В коде, привязки к требованиям нет	TC как артефакты или хотя бы в коде с упоминанием SR-ID

Если 3+ строк в колонке «Pre-RENAR» — команда до RENAR-1. Это нормальная стартовая точка для большинства проектов.

1.1 Сигналы готовности¶

Команда готова к миграции, если:

Болит, что требования теряются между чатами / тикетами / документами.
Disputed acceptances случаются регулярно — «мы не это просили».
При onboarding нового инженера месяцы уходят на восстановление контекста.
Используется AI для генерации требований / кода, но нет систематической проверки.

Если ничего из этого не болит — RENAR может быть преждевременной оптимизацией. См. §8 «когда не нужен».

2. Этап 1 — войти в RENAR-1 (Стихийный, Ad-hoc)¶

Цель уровня: требования живут в носителе, не в чате; для каждого ТЗ есть ADAPT.

Типичная длительность: 1-2 недели.

2.1 Что добавляется¶

Выбирается и заводится носитель артефактов (substrate): каталог <project>.req/ в репозитории, рабочая область document store или иной носитель — RENAR к конкретной реализации не привязан; см. возможности V1–V6 (глоссарий §2.7).
Существующее ТЗ переносится в эту среду как не подлежащий произвольным правкам артефакт (с датой и подписями).
Для каждого ТЗ создаётся ADAPT — артефакт-мост: раздел Forward («как мы поняли») и backward (вопросы заказчику).
Новые требования заносятся как BR / SR файлы в носителе, не только в трекер.

2.2 Что НЕ требуется на этом этапе¶

Стандартизированный frontmatter (минимум — id + title).
Lifecycle статусы (draft/approved/...) — артефакты могут жить без явных переходов.
TC как отдельные артефакты.
Hooks носителя.
Нативный для носителя COVERAGE.

2.3 Типичные блокеры¶

«У нас уже есть тикеты в Jira» — оставьте. RENAR-1 не требует миграции; tracker и носитель могут сосуществовать. Главное — носитель теперь источник истины для новых требований.
«ADAPT — лишняя работа» — на одно ТЗ ADAPT занимает 1-2 часа. Это окупается на первом же спорном acceptance.
«Где хранить?» — любой носитель, удовлетворяющий V1–V6. См. guide/03-tool-guide-git или guide/04-document-store-substrate.

2.4 Когда переходить на RENAR-2¶

Когда новые требования перестали уходить в чаты и начали стабильно появляться в носителе. Это занимает 4-6 спринтов привычки.

3. Этап 2 — перейти на RENAR-2 (Зафиксированный, Documented)¶

Цель уровня: структура и frontmatter; delta-ТЗ как явный change-set.

Типичная длительность: 2-4 недели после RENAR-1.

3.1 Что добавляется¶

Каждый BR / SR получает frontmatter с обязательными полями (см. reference/02-schemas).
Папки структурируются: br/, sr/, adapt/, dpia/, ...
Изменения требований — только через delta-ТЗ (новый неизменяемый артефакт), не через прямое редактирование.
ТЗ зафиксировано как неизменяемое (изменения только через delta-ТЗ).

3.2 Шаблон: легализация существующих требований¶

Старые требования (которые уже были в носителе с RENAR-1) — пройти рецензирование и проставить frontmatter «как есть» без пересмотра содержания. Это legalization, не rewrite:

---
id: BR-12
title: "Регистрация сотрудника через корпоративный email"
status: approved          # уже работает в проде
created-at: "2025-12-01"  # ретроактивно
priority: must            # ретроактивная оценка
legacy: true              # маркер: требование не проходило ADAPT с нуля
---

Поле legacy: true опционально, но рекомендовано — отличает «исторические» требования от новых, которые с самого начала прошли весь RENAR-пайплайн.

3.3 Типичные блокеры¶

«frontmatter на 100 требований — это месяц» — да. Делайте в фоне, по 10-15 требований / неделю; новые требования сразу с frontmatter.
«Delta-ТЗ замедляет» — на первых неделях да. После 2-3 итераций обычно становится быстрее, чем «давай просто поменяем».
«Не понимаем, какой priority ставить ретроактивно» — оставьте priority: should для всего legacy; явно must ставится только при подтверждении со stakeholder.

3.4 Когда переходить на RENAR-3¶

Когда frontmatter валиден для 80%+ артефактов и команда привыкла к delta-ТЗ.

4. Этап 3 — перейти на RENAR-3 (Учитываемый, Tracked)¶

Цель уровня: автоматическая валидация + lifecycle enforcement + TC покрытие для priority=must.

Типичная длительность: 4-8 недель после RENAR-2.

4.1 Что добавляется¶

Hooks носителя валидируют frontmatter по schema на каждое изменение. Невалидные — блок integration.
Lifecycle статусы используются реально: каждый артефакт в одном из закрытых состояний (draft / approved / verified / deprecated / obsolete).
TC создаются для всех priority=must BR / SR / SPEC.
Нативный для носителя COVERAGE report auto-generated на каждый promote-transition.
Reference-validation hook: создание BR / SR с ссылкой на ADAPT в статусе ниже approved — блок.
Реализация ссылается на BR / SR / SPEC с pinned verifies[].version.

4.2 Шаблон: backfill TC¶

Для всех priority=must требований без TC:

Отсортировать по «частоте упоминания в incident reports» — где TC даст максимум value.
Покрывать по 3-5 требований / спринт, не пытаясь backfill сразу всё.
TC создаются как артефакты в вашем носителе со связью verified-by.

4.3 Типичные блокеры¶

«Старые требования упрямо не приводятся к schema» — оставьте их в legacy-папке; новые сразу schema-valid. Hook носителя применяется только к новым / изменяемым артефактам.
«Hooks замедляют PR cycle» — измерьте: если > 30s — оптимизируйте hooks (parallelization, caching); не «отключить».
«Команда обходит hooks через --no-verify» — это organizational failure pattern; root cause — hooks слишком медленные / шумные. Чините, не запрещайте.

4.4 Когда переходить на RENAR-4¶

Когда COVERAGE для priority=must = 100%, frontmatter валиден везде, lifecycle действительно работает.

5. Этап 4 — перейти на RENAR-4 (Верифицируемый, Verified)¶

Цель уровня: для всех утверждённых артефактов есть успешно пройденные контрольные примеры (TC); переход под контрольной точкой QG-2 (Verification Gate) обеспечивается носителем; соблюдена парность позитивных / негативных проверок; для материала от ИИ задан блок ai-provenance.

Типичная длительность: 6-12 недель после RENAR-3.

5.1 Что добавляется¶

100% approved артефактов имеют verified-by ссылку на ≥ 1 TC.
Pos/neg парность для каждого нормативного утверждения.
Контрольная точка QG-2 (Verification Gate) блокируется встроенными в носитель проверками: перевод в verified только при всех успешных TC для текущей requirement-version.
Все TC автоматизированы или явно manual-pending с deadline.
Для tc-type: ux — VLM-judge isolation.
Для tc-type: eval — judge-модель ≠ модель реализации.
ai-provenance для AI-сгенерированных артефактов: минимум generated-by + generated-at.
Source citation — каждое нормативное утверждение имеет pointer на источник в ТЗ или ADAPT.
Привязка согласования (reconciliation) запускается носителем не реже одного раза в неделю.
Spot-check 5 случайных passing TC раз в спринт.

5.2 Шаблон: поэтапное покрытие¶

Достижение 100% verified-by покрытия — не одним PR. Подход:

Сначала pos-only TC для всех priority=must (бенефит — быстрая обратная связь).
Затем neg-TC pairs (бенефит — отлов test-fitting drift).
Затем tc-type extensions (ux / eval / contract / security) по мере необходимости.

5.3 Типичные блокеры¶

«Изоляция judge-модели дорого» — это правда. Но это структурный rate limit на AIR-06 test-fitting drift — нельзя обойти без потери verification integrity.
«Source citation замедляет авторов» — автоматизируйте: AI-генератор должен сразу выдавать citation; ручная авторизация — только для legacy backfill.
«Находки reconciliation заваливают команду» — tunable thresholds; начинайте с conservative defaults, постепенно ослабляйте.

5.4 Когда переходить на RENAR-5¶

Когда RENAR-4 стабильно работает 2-3 квартала, метрики стабильны, команда не «горит» от reconciliation noise.

6. Этап 5 — перейти на RENAR-5 (Оптимизирующий, Optimized)¶

Цель уровня: adversarial review как gate; multi-model agreement для priority=must; cost/latency budgets; knowledge graph как primary search; continuous evaluation для AI-критических компонентов.

Типичная длительность: 12+ недель после стабильного RENAR-4.

6.1 Что добавляется¶

Adversarial critic — обязательный gate для draft → approved. Critic — модель, отличная от модели генерации.
Multi-model agreement для priority=must: артефакт генерируется ≥ 2 моделями; расхождения помечены и обязательны к разбору.
Cost / latency budget per artifact; превышение → автоматическая декомпозиция.
Knowledge graph как primary search для AI-агентов.
Continuous evaluation для SPEC-AI.
Метрика Hallucination Rate < 1%.
Метрика Multi-model Disagreement Rate отслеживается.
Возврат улучшений шаблонов в requirements-library — стандартная практика.

6.2 Когда RENAR-5 нужен¶

Регулируемые отрасли (финтех, healthcare, AI-системы high-risk per AI Act).
Когда продукт критически зависит от качества AI-генерации (генеративные продукты).
Когда есть бюджет на continuous evaluation infrastructure.

Многие проекты могут остановиться на RENAR-4 — этого достаточно для соответствия заявленному профилю RENAR (conformance). RENAR-5 не обязательно «лучше», зато почти всегда дороже и строже. Выбирайте по потребности, а не по моде.

7. Миграция legacy-требований¶

Существующие тысячи требований в Jira / Confluence — как втягивать?

7.1 Стратегия не-миграции¶

Если legacy требования не активно меняются — не мигрируйте. RENAR применяется только к новым требованиям и активно изменяемым. Legacy остаётся в исходном месте как read-only «исторический контекст».

7.2 Стратегия выборочной миграции¶

Для legacy, которые активно меняются:

На момент первого change — затянуть в носитель как BR/SR с legacy: true маркером и минимальным frontmatter.
Применить change как delta-ТЗ.
Через 1-2 итерации требование «созревает» — становится full-RENAR (без legacy маркера, с полным frontmatter и TC).

7.3 Стратегия bulk-import¶

Когда нужно мигрировать сразу > 100 требований (например, при organizational reorganization):

Скриптовая выгрузка из tracker → frontmatter скелет (id, title, минимум).
Все импортированные требования — legacy: true + status: approved (как есть в проде).
Backfill TC и full frontmatter — спринт за спринтом, не блокируя current work.

8. Когда RENAR НЕ нужен¶

RENAR — overhead. Не применяйте к:

One-off скриптам и прототипам — не доходят до production, или становятся production только через rewrite.
Очень маленьким командам (1-2 человека) — overhead управления носителем может превышать benefit.
Проектам без AI-генерации требований / тестов — главная ценность RENAR (защита от AI-specific failure modes) теряется.
Краткосрочным экспериментам (≤ 1 спринт) — не успеете окупить ADAPT-setup.

Минимальный порог окупаемости: проект с ≥ 3 итерациями требований, ≥ 2 разработчиков, использует AI где-либо в pipeline (генерация требований / кода / тестов / документации).

9. Антипаттерны миграции¶

Чего избегать:

9.1 Миграция «big-bang»¶

Симптом: Команда останавливает разработку на 2 спринта чтобы «перейти на RENAR». Через 2 спринта получают burnout и брошенную миграцию.

Вместо: Гибридный режим. Новые требования сразу в RENAR, старые — по мере касания. Долго, но устойчиво.

9.2 Пропуск уровней¶

Симптом: «Давайте сразу на RENAR-4». Команда пропускает RENAR-⅔, ставит full hooks + ai-provenance + adversarial critic, но frontmatter не валиден и lifecycle хаотичен.

Вместо: Уровни идут по порядку. RENAR-4 без RENAR-3 базы — не работает.

9.3 Паралич «идеального frontmatter»¶

Симптом: Команда тратит недели на полирование одного frontmatter — «а правильно ли я выбрал priority?» Реальная работа стоит.

Вместо: frontmatter — «достаточно хорошо». Ошибки правятся в delta-ТЗ. Главное — что-то быть в носителе, а не вылизанность.

9.4 Частичное принятие носителя¶

Симптом: Половина требований в носителе, половина — всё ещё в Jira. Никто не знает, где источник истины.

Вместо: Single source of truth должен быть сразу. Если нельзя перенести всё — перенесите только новые, явно объявите носитель владельцем «всего нового».

9.5 Подход «сначала tooling»¶

Симптом: Команда полгода пишет внутренние tooling вокруг RENAR (свой validator / своя CI / своя UI), не используя сам стандарт.

Вместо: Сначала практика на минимальном носителе (даже плоская папка с markdown). Tooling — когда становится больно вручную.

Стоимость и выгода внедрения (иллюстративно)¶

Секция иллюстративная и ненормативная — помогает прикинуть порядок величин. Конкретные числа зависят от проекта; реальную модель калибруйте по своим данным.

Стоимость внедрения (что вкладывается):

Обучение команды Core (5 правил + ADAPT) — порядка полдня-дня на инженера.
Дисциплина ADAPT на каждое ТЗ — дополнительные часы на elicitation / backward до старта кода (окупаются отсутствием переоткрытия ТЗ позднее).
Носитель уже есть (git) — отдельных лицензий не требуется; tooling-автоматизация опциональна и вводится постепенно.

Выгода (что возвращается):

Сокращение времени декомпозиции ТЗ с AI-ускорением (порядок величин — standard/12 §12.5.1: 5–10× на RENAR-4, иллюстративно).
Меньше споров на приёмке: ADAPT с двойной подписью фиксирует интерпретацию до кода.
Меньше инцидентов из негативных сценариев — за счёт обязательной pos/neg-парности TC.
Журнал аудита «что сдавали по контракту» — бесплатно из носителя (V1 / V6).

Когда не окупается: короткоживущие прототипы, чистый продуктовый дискавери без договора, команды без compliance-давления и без внешнего клиента (см. §8 «когда RENAR не нужен»). Для них достаточно RENAR Core или ничего.

Количественная ROI-модель (порядок экономии на проект и т.п.) пока живёт в research-материалах; перенос откалиброванной версии в этот раздел запланирован в бэклоге фазы 8 для v1.1.

10. Связанные документы¶

standard/11-maturity-model — нормативные определения RENAR-1..RENAR-5 уровней (closed list).
00-quickstart — 30-минутный sample для маленького проекта.
01-walkthrough — полный example на одном проекте.
07-failure-modes — что может пойти не так при миграции; organizational failure patterns §5.
reference/02-schemas — frontmatter schemas, обязательные для RENAR-2+.
03-tool-guide-git — специфичный для носителя guide для git.
04-document-store-substrate — informative обзор носителя document-oriented store.

11. Зафиксированные решения для v1.0¶

Legacy backfill bulk-import — bypass запрещён. На initial import артефакты вносятся со статусом imported-legacy (специфичный для носителя marker, не входит в нормативный closed list lifecycle §10.5–§10.8) и не участвуют в conformance assessment до промотирования через нормальный QG-0 flow. Это сохраняет §1.7.3 declared-weaker запрет: validation не обходится, а лишь отложена до момента, когда артефакт начнёт claim conformance.
Откат с уровня RENAR-3 → RENAR-2 допустим через formal downgrade per §13.8.2: выпускается новая версия manifest с пониженным level. План восстановления не обязателен (downgrade — намеренный, не потеря соответствия), но рекомендуется зафиксировать причину downgrade в журнале аудита.
Cross-org migration: каждая подсистема — свой manifest с собственным level (§13.4). Organization-aggregate "RENAR-N" неформально определяется минимумом уровней подсистем; организационный manifest не нормируется RENAR v1.0.

11.1 Отложено на v1.1 (бэклог фазы 8)¶

Шаблоны миграции для команд 50+ инженеров. Гайд ориентирован на группы 5–15 человек; для большего масштаба нужны полевые наблюдения. Ответственные: сопровождение стандарта RENAR и ранние внедренцы.