00. Введение¶
Часть RENAR Standard v1.0-draft · ← Оглавление
Новичкам. Эта глава — нормативная и плотная (RFC-2119, закрытые списки, обязательные положения). Если ты человек и впервые встречаешь RENAR — начни с концептуального обзора
core/renar-core.md(≤ 10 мин), затемguide/00-quickstart(≈ 30 мин), затем возвращайся сюда. Если ты AI-агент — переходи напрямую к нормативным главам.
0.1 Зачем эта глава¶
Клиент написал в ТЗ: «пользователь выгружает отчёт». Инженер прочитал это как выгрузку в PDF, спецификация назвала CSV, а тест в итоге проверяет Excel. Злого умысла нет — требование просто живёт сразу в пяти местах (договорное ТЗ клиента, инженерная декомпозиция, спецификации, тест-кейсы, код), и на каждом стыке смысл чуть смещается. Когда артефакты пишут вперемешку человек и AI-агент, стыков больше, а смещение быстрее. Поэтому узкое место разработки — уже не скорость кода, а корректность требований. RENAR существует, чтобы на этих стыках смысл не утекал: он задаёт явные контракты между артефактами.
Эта глава отвечает на четыре вопроса: что такое RENAR (§0.2), зачем он нужен (§0.3), как соотносится с SENAR (§0.4) и каков минимум, ниже которого о соответствии говорить нельзя — Minimum Viable RENAR (далее MVR; §0.5). Закрытые списки и язык RU-корпуса — §0.6, §0.7.
Глава не вводит новых нормативных требований. Каждое из семи утверждений MVR — ссылка на главу §1–§13, где оно превращается в точную норму; здесь дано связное целое.
Конвенция модальных глаголов. Нормативная сила выражается русскими модальными словами: «обязан» / «должен» — обязательный уровень (RFC-2119 shall / must); «следует» / «рекомендуется» — recommended (should); «может» / «допустимо» — permitted (may); «запрещён» / «не должен» — shall not. Соответствие — RFC-2119 + ISO/IEC/IEEE 29148:2018 §5.2.1. Действует во всех нормативных главах.
0.2 Что такое RENAR¶
RENAR (Requirements Engineering & Normative Adaptive Regulation) — нормативный стандарт управления требованиями для разработки с AI-агентами. Стандарт нормирует:
- Модель данных артефактов требований (BR / SR / TR), ADAPT, девяти типов SPEC, TC.
- Жизненный цикл артефактов через закрытый список Quality Gates (QG-0 / QG-1 / QG-2 обязательные; QG-3 / QG-4 опциональные).
- Возможности носителя V1–V6.
- Соответствие — уровни RENAR-1..RENAR-5, обязательные положения, манифест, процедуры оценки.
RENAR — специализация SENAR (§1.6) в области инженерии требований. Реализация, соответствующая RENAR, всегда совместима с SENAR; обратное — неверно (§1.6.2).
RENAR не привязан к конкретному носителю (VCS, документная БД, wiki): нормативные главы используют язык, независимый от носителя, нормируют возможности V1–V6 (§3.1). RENAR — стандарт, а не реализация.
0.2.1 AI-агент как штатный исполнитель¶
RENAR-артефакты штатно создаются и поддерживаются AI-агентом по заданию инженера. Человек выполняет роль проверяющего и утверждающего. Это нормативное позиционирование, а не методологическая рекомендация.
Следствия:
- Полнота — требования к полноте артефактов: AI-агент исполняет «код на естественном языке», без полноты разрушается происхождение (§0.3).
- Плотность frontmatter — десятки полей следствие машинной природы основного читателя. В многоязычном UI поля могут отображаться человекочитаемо (§4.13.3).
- Компенсирующие механизмы — двойная подпись ADAPT (§7.5), выборочная проверка инженера (§9.14), состязательный обзор (§9.4), Quality Gates (§10.3) — обеспечивают то, что человек остаётся источником решений по договорным результатам.
Что не утверждает §0.2.1: RENAR не требует AI-агента для соответствия — стандарт реализуем вручную, но процессные издержки делают это непрактичным (§1.4.1 признак 5). AI-агент не заменяет утверждение человеком — все нормативные подписи выполняются человеком. AI-агент действует как responsible (R в RACI §5.6), не как accountable (A).
0.3 Зачем существует RENAR¶
В разработке с AI-агентами требования живут одновременно в нескольких артефактах, создаваемых и поддерживаемых смесью авторов-людей и AI-агентов. Без нормативных контрактов между ними возникает дрейф требований — расхождение между тем, что зафиксировано, верифицируется и реализовано.
RENAR закрывает восемь нормированных классов дрейфа (полный список с точками контроля — §4.11; концептуальное описание — core/renar-core.md). Все восемь — структурные: возникают из самого факта совместного владения артефактом несколькими авторами, не из ошибок дисциплины. Закрыть их можно только нормативно — фиксацией контракта связей, авторства полей и предусловий переходов (§13.3 обязательные положения).
Контракт обеспечивается машинно только при условии полноты артефактов (§0.2.1). Артефакт с умолчаниями — контракт с дырами, через которые проходит дрейф независимо от наличия hooks: hook видит только то, что записано. То же относится к каноническим именам и закрытым спискам (§4.2): hook сравнивает строки, не интерпретирует синонимы.
0.4 Связь с SENAR¶
RENAR нормирует только те аспекты инженерии требований, которые SENAR оставляет на усмотрение доменного стандарта: модель данных артефактов, жизненный цикл артефактов требований, манифест соответствия для инженерии требований. RENAR не дублирует и не переопределяет SENAR-конструкции (5 ценностей, 14 правил, общие Quality Gates, 5 базовых ролей).
Манифест соответствия проекта (§13.4) обязан декларировать одновременно senar-version и renar-version. Заявление о соответствии RENAR без указания совместимой SENAR-version — несоответствующее (§13.8).
Если нормативное утверждение RENAR оказывается несовместимым с нормой SENAR — это баг стандарта RENAR. Разрешение — через формальную процедуру изменения стандарта SENAR с согласующей правкой в RENAR (§13.9), а не через локальное переопределение на уровне проекта.
| Аспект | SENAR (база) | RENAR (специализация инженерии требований) |
|---|---|---|
| 5 ценностей + 14 правил + 5 ролей | нормирует | наследует |
| Общие Quality Gates | общий фреймворк | закрытый список канонических QG-0..QG-4 (§10.3) |
| Модель данных артефактов | — (вне области) | BR / SR / TR / ADAPT / 9 SPEC types / TC (§6–§9) |
| Жизненный цикл артефактов требований | — | канонические машины состояний (§10) |
| Возможности носителя | — | V1–V6 (§3) |
| Манифест соответствия | типовой SENAR | RENAR-CONFORMANCE.yaml + обязательные положения (§13) |
Оригинальный вклад RENAR (не унаследовано из SENAR): модель данных требований; ADAPT с двусторонней адаптацией и двойной подписью; независимые от носителя V1–V6; канонический жизненный цикл и QG для оси требований; pos/neg-парность и judge ≠ production как блокирующие положения; уровни соответствия RENAR-1..RENAR-5.
0.5 Minimum Viable RENAR (MVR)¶
Minimum Viable RENAR — закрытый список из семи нормативных утверждений, обязательных для любой RENAR-соответствующей реализации независимо от объявленного уровня (включая RENAR-1). MVR эквивалентен обязательным положениям §13.3.
| # | Утверждение[¹] | Нормативный источник |
|---|---|---|
| MVR-1 | Инверсия источника истины: иерархия артефактов требований обязана быть источником истины о поведении системы; код — производный артефакт. Обратная разработка (reverse-engineering) поведения из кода в SR без обоснования bug-fix запрещена. | §2.3, §13.3.1 |
| 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.3, §13.3.2 |
| MVR-3 | Reactive, stage-agnostic ADAPT (0..N на ТЗ): ADAPT — реактивный артефакт, создаётся тогда и только тогда, когда конвертация ТЗ → RENAR-описание на любой стадии деривации порождает gap между языком клиента и языком требований. На одно ТЗ приходится ноль или более ADAPT; каждый привязан к своему триггеру (импорт ТЗ либо конкретная стадия декомпозиции) через trigger-stage, множественность — штатный случай. При наличии gap ADAPT обязателен в статусе approved с двойной подписью. При отсутствии gap (состязательный рецензент вынес вердикт «no findings») ADAPT не создаётся; BR/SR/SPEC ссылаются на ТЗ напрямую через обязательные source.tz-section + source.adversarial-review-ref. Delta-ТЗ следует тому же правилу. |
§7, §13.3.3 |
| MVR-4 | Закрытый список 9 типов SPEC: тип SPEC обязан принадлежать закрытому списку SPEC-ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS. Проект не имеет права создавать новые типы локально. |
§8.3, §13.3.4 |
| MVR-5 | TC pos/neg парность: каждое нормативное утверждение верифицируемого артефакта, охватываемое хотя бы одним TC, обязано иметь парный negative TC. Исключение — утверждение само описывает negative invariant. | §9.7, §13.3.5 |
| MVR-6 | Закрытый список Quality Gates: реализация обязана поддерживать QG-0 (Approval), QG-1 (Implementation), QG-2 (Verification) как required. QG-3 / QG-4 — declared или absent. Новые gate-типы локально создавать запрещено. |
§10.3, §13.3.6 |
| MVR-7 | Манифест соответствия: проект обязан содержать манифест с одновременным renar-version + senar-version + level (RENAR-1..RENAR-5) + подтверждением обязательных положений §13.3. Манифест immutable (V1). |
§13.4 |
[¹] Каждая строка задаёт обязательный уровень требования (RFC-2119 «shall» в русских формулировках — «обязан» или «должен» по контексту) в трактовке ISO/IEC/IEEE 29148:2018 §5.2.1.
Реализация, удовлетворяющая всем семи MVR, соответствует минимум уровню RENAR-1 (§13.2.1). Реализация, нарушающая хотя бы одно MVR, не имеет соответствия RENAR независимо от заявленного уровня (§13.8).
0.6 Политика закрытого списка¶
Список из семи MVR — закрытый на v1.0. Проект не имеет права расширять MVR локально или сокращать список.
Реализация может ужесточить требования сверх MVR через маркер declared-stricter (§10.10.2, §13.4): требовать QG-3/QG-4 как required, требовать состязательный обзор TC на всех типах SPEC, декларировать RENAR-3+ как минимум.
Реализация не имеет права declared-weaker: выдать заявление о соответствии RENAR без поддержки одного из MVR-1..MVR-7; объявить ADAPT опциональным; допустить single-TC-coverage для нормативного утверждения без negative-invariant исключения; опустить senar-version или level в манифесте.
Изменение MVR — только через формальную процедуру изменения стандарта RENAR (§13.9): исследовательский черновик → публичное обсуждение → повышение minor-версии → руководство по миграции.
0.7 Язык RU-корпуса¶
RU нормативный корпус RENAR — гибрид: канонические идентификаторы (латиница и аббревиатуры закрытого списка) + русская связующая проза. Политика — reference/06 §1 и §4.2. Артефакты и ID, статусы жизненного цикла, VCS domain terms, accepted technical loanwords остаются латиницей; организационная терминология и rewrite-кальки — переводятся; editorial rule «≤ 1 latin token на нормативное предложение» вне канонических идентификаторов.
Носитель, не substrate. Концепт хранилища по-русски — «носитель» (склоняется). Латиницей substrate остаётся только в именах полей (substrate-capabilities), коде/YAML и именах файлов; в связующей прозе — всегда «носитель».