00. Introduction
Часть RENAR Standard v1.0-draft · ← Оглавление
0.1 Назначение главы
Глава вводит RENAR как нормативный стандарт: что он нормирует, почему существует, как соотносится с SENAR, и каков минимальный набор утверждений, которым обязана удовлетворять любая RENAR-conformant имплементация (Minimum Viable RENAR, далее MVR). Глава фиксирует:
- Определение (§0.2) — RENAR через три тезиса: нормативный стандарт requirements engineering, специализация SENAR, substrate-agnostic data model + lifecycle.
- Обоснование (§0.3) — восемь классов дрифта требований и нормативные области, которые их закрывают.
- Связь с SENAR (§0.4) — RENAR как специализация, не альтернатива; нормативная совместимость.
- MVR (§0.5) — закрытый список из 7 MUST/SHALL утверждений, к каждому из которых сведена RENAR-conformance.
- Навигацию (§0.6) — таблица 15 нормативных глав и роль supporting directories.
- Closed list policy (§0.7) — нерасширяемость MVR project-local, declared-stricter / declared-weaker правила.
Глава не вводит новые нормативные требования: каждое утверждение MVR ссылается на нормирующую главу §1–§14, где оно детализируется. Дублирование §1.2 / §1.4 / §1.6 запрещено; ссылки — обязательны.
0.2 Что такое RENAR
0.2.1 Нормативный стандарт requirements engineering
RENAR (Requirements Engineering & Normative Adaptive Regulation) — нормативный стандарт управления требованиями для AI-native разработки. Стандарт нормирует:
- Data model артефактов требований (BR / SR / TR), ADAPT, девяти типов SPEC, TC.
- Lifecycle артефактов через закрытый список Quality Gates (QG-0 / QG-1 / QG-2 обязательные; QG-3 / QG-4 опциональные).
- Substrate-agnostic capabilities V1–V6, которые substrate проекта обязан удовлетворять.
- Conformance — уровни (RENAR-1..RENAR-5), mandatory clauses, manifest, assessment-процедуры.
0.2.2 Специализация SENAR
RENAR — специализация SENAR (§1.6) в области requirements engineering, не альтернатива SENAR и не самостоятельная методология. SENAR предоставляет методологическую базу (5 ценностей, 14 правил, общие Quality Gates, 5 базовых ролей); RENAR нормирует только те аспекты, которые SENAR оставляет на усмотрение domain-стандарта.
RENAR-conformant имплементация всегда SENAR-совместима; обратное — нет (§1.6.2).
0.2.3 Substrate-agnostic
RENAR не привязан к конкретному substrate (version-control system, document database, wiki-platform): нормативные главы используют substrate-agnostic язык (§11.1) и нормируют capabilities V1–V6, а не конкретные продукты или команды. Substrate-specific guidance вынесена в guide/03-tool-guide-*.md.
RENAR — стандарт, а не реализация: имплементации могут существовать на разных substrate (single-SSoT правило, §11.3) при условии удовлетворения V1–V6 и mandatory clauses (§14.3).
0.3 Зачем существует RENAR
0.3.1 Проблема: дрифт требований
В AI-native разработке требования живут одновременно в нескольких артефактах (ТЗ от клиента, decomposed BR/SR, SPEC, TC, описание задачи, реализация кода), создаваемых и поддерживаемых смесью human + AI authors. Без нормативных контрактов между артефактами возникает дрифт — расхождение между тем, что зафиксировано, тем, что верифицируется, и тем, что фактически реализовано.
RENAR закрывает восемь классов дрифта:
| # | Класс дрифта | Что происходит | Нормативное закрытие |
|---|---|---|---|
| 1 | Schema drift | Поля артефактов расходятся между projects / substrate | Closed list нормативных областей §1.2 + canonical schema (reference/02-schemas) |
| 2 | Lifecycle drift | Статусы (draft / approved / verified) значат разное у разных авторов | Canonical state machines + closed list QG (§10) |
| 3 | Source-of-truth drift | Одна сущность правится одновременно в нескольких местах | Single-SSoT designation per артефакт (§11.3 V3) |
| 4 | Implementation drift | Код реализует требование, которое уже удалено или переименовано | Immutable identifiers + V5 version-pin (§11.3); reference-validation hooks (§10.11.1) |
| 5 | Terminological drift | Термины (verified, implemented, approved) значат разное у разных людей | Canonical глоссарий (§3) — один термин = одно состояние lifecycle |
| 6 | Order / provenance drift | Delta-ТЗ применяется не в порядке, ссылается на несуществующее требование | Delta-ADAPT workflow + V6 author/timestamp (§7.6, §11.3) |
| 7 | TC ↔ requirement provenance drift | TC верифицирует устаревшее поведение (requirement-version отстаёт) | Pinned verifies[].version + QG-2 блок promote в verified (§9, §10.3.3) |
| 8 | Test-fitting drift | AI-агент ослабляет Pass/Fail-критерии TC вместо исправления реализации | Adversarial review pattern + separate approval критериев TC (§9.4, §10.3.3) |
0.3.2 Норма как контракт между AI-агентами
Восемь классов дрифта — структурные, не операционные: они возникают из самого факта совместного владения артефактом несколькими авторами (включая AI), а не из ошибок дисциплины. Закрыть их можно только нормативно — фиксацией контракта о том, как артефакты связаны, кто пишет какое поле, и какие предусловия обязаны быть выполнены при переходах (§14.3 mandatory clauses).
Без RENAR (или эквивалентного нормативного слоя над SENAR) дрифт неотвратим. С RENAR — substrate-нативные hooks (§10.11) обеспечивают enforcement, а conformance manifest (§14.4) фиксирует уровень формального соответствия.
0.4 Связь с SENAR
0.4.1 RENAR ⊂ SENAR
RENAR нормирует только аспекты requirements engineering, которые SENAR оставляет на усмотрение domain-стандарта: data model артефактов, lifecycle requirement-артефактов, conformance manifest для RE. RENAR не дублирует и не переопределяет SENAR-конструкции: 5 ценностей, 14 правил, общие Quality Gates (§10.2.3), 5 базовых ролей (§4.2) — нормируются SENAR.
0.4.2 Manifest объявляет обе версии
Conformance manifest проекта (§14.4) обязан декларировать одновременно senar-version и renar-version. Заявление RENAR-conformance без указания SENAR-version или с указанием несовместимой SENAR-version — non-conformant (§14.8).
0.4.3 Несовместимость = баг стандарта
Если нормативное утверждение RENAR оказывается несовместимым с нормой SENAR — это баг стандарта RENAR. Разрешение — через formal change procedure SENAR + corresponding alignment в RENAR (§14.9), не через project-local переопределение. Имплементация не имеет права заявить «следуем RENAR вместо SENAR» (§1.6.3).
0.4.4 Разделение ответственности
| Аспект | SENAR (база) | RENAR (специализация RE) |
|---|---|---|
| Методологические ценности | 5 ценностей AI-native разработки | — (наследует) |
| Общие правила | 14 правил агентской работы | — (наследует) |
| Общие Quality Gates | Generic gate framework | Closed list canonical gates QG-0..QG-4 (§10.3) |
| Базовые роли | 5 ролей: Author, Reviewer, Approver, Tester, Operator | RE-specializations поверх SENAR §4: Architect, Client representative, AI-author (§4) |
| Data model артефактов | — (вне scope) | BR / SR / TR / ADAPT / 9 SPEC types / TC (§6, §7, §8, §9) |
| Lifecycle requirement-артефактов | — (вне scope) | Canonical state machines (§10) |
| Substrate capabilities | — (вне scope) | V1–V6 (§11) |
| Conformance manifest | Generic SENAR-manifest | RENAR-CONFORMANCE.yaml + mandatory clauses (§14.3, §14.4) |
Пересечение строк «— (наследует)» означает, что RENAR использует SENAR-конструкцию как есть, не модифицирует. Пересечение строк «— (вне scope)» означает, что SENAR оставляет аспект на усмотрение domain-стандарта, и RENAR его нормирует.
0.5 Minimum Viable RENAR (MVR)
Minimum Viable RENAR — закрытый список из семи нормативных утверждений, которым обязана удовлетворять любая RENAR-conformant имплементация независимо от объявленного уровня (включая RENAR-1). MVR эквивалентен mandatory clauses §14.3; глава 00 представляет MVR как первичную сводку для читателя, §14.3 — как нормативную деталь для assessor-а.
0.5.1 Семь утверждений
| # | Утверждение | Нормативный источник |
|---|---|---|
| MVR-1 | SoT inversion: иерархия артефактов требований SHALL быть source of truth о поведении системы; код — derived артефакт реализации. Reverse-engineering поведения из кода в SR без обоснования bug-fix запрещён. | §5.3, §14.3.1 |
| MVR-2 | V1–V6 capabilities: substrate проекта SHALL удовлетворять всем шести capabilities — immutable history (V1), atomic change unit (V2), diff & review (V3), branching / change-set (V4), cross-substrate version pin (V5), author + timestamp (V6). | §11.3, §14.3.2 |
| MVR-3 | ADAPT per ТЗ: каждое ТЗ SHALL иметь ровно один корневой ADAPT в статусе approved с двусторонней client-side validation и двойной подписью (Architect + Client representative). Delta-ТЗ SHALL иметь свой delta-ADAPT. | §7, §14.3.3 |
| MVR-4 | Closed list 9 SPEC types: тип SPEC SHALL принадлежать закрытому списку SPEC-ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS. Project-local создание новых типов запрещено. | §8.3, §14.3.4 |
| MVR-5 | TC pos/neg парность: каждое нормативное утверждение верифицируемого артефакта (BR / SR / SPEC / TR), охватываемое хотя бы одним TC, SHALL иметь парный negative TC. Исключение — утверждение само описывает negative invariant. | §9.7, §14.3.5 |
| MVR-6 | Quality Gates closed list: имплементация SHALL поддерживать QG-0 (Approval), QG-1 (Implementation), QG-2 (Verification) как required. QG-3 (Architecture) и QG-4 (Acceptance) — declared или absent. Project-local создание новых gate-типов запрещено. | §10.3, §14.3.6 |
| MVR-7 | Conformance manifest: проект SHALL содержать conformance manifest, объявляющий одновременно renar-version + senar-version + level (RENAR-1..RENAR-5) + подтверждение всех mandatory clauses §14.3. Manifest immutable в смысле V1. | §14.4 |
0.5.2 MVR — необходимое и достаточное условие conformance
Имплементация, удовлетворяющая всем семи утверждениям MVR, соответствует минимум уровню RENAR-1 (§14.2.1). Уровни RENAR-2..RENAR-5 добавляют дополнительные обязательства поверх MVR (§12). Имплементация, нарушающая хотя бы одно утверждение MVR, не имеет conformance к стандарту RENAR в целом — независимо от заявленного уровня (§14.8).
0.6 Структура документа
0.6.1 Нормативные главы (standard/)
| # | Глава | Назначение |
|---|---|---|
| 00 | Introduction | Эта глава — определение RENAR, MVR, навигация |
| 01 | Scope | Closed list нормативных областей и исключений; primary + negative scope |
| 02 | Normative references | Mapping на ISO/IEC 29148, BABOK, SAFe, ISO/IEC 5338, NIST AI RMF, AI Act EU |
| 03 | Terms and definitions | Canonical глоссарий — закрытие terminological drift |
| 04 | Roles | Роли над SENAR §4; ownership артефактов; двойная подпись ADAPT |
| 05 | Methodology positioning | SoT inversion (SDD); waterfall-form ≠ classical waterfall; substrate-agnostic versioning |
| 06 | Requirements hierarchy | BR / SR / TR; декомпозиция система / подсистема / модуль |
| 07 | ADAPT | Двусторонняя адаптация ТЗ; forward + backward findings; двойная подпись |
| 08 | Specifications | Closed list 9 типов SPEC; общая схема + type-specific extensions; constrained-by[] |
| 09 | Test cases | TC как first-class артефакт; pos/neg парность; adversarial review; VLM-judge |
| 10 | Lifecycle и QG | State machines; QG-0..QG-4; hooks enforcement |
| 11 | Substrate versioning | Capabilities V1–V6; substrate-agnostic нормативный язык; single-SSoT правило |
| 12 | Maturity model | RENAR-1..RENAR-5; checklist по уровням |
| 13 | Metrics | REQ-специфичные метрики (RDLT, Hallucination Rate, DRA, ACR); business outcomes; ROI |
| 14 | Conformance | Mandatory clauses; manifest; self-assessment + third-party; loss-of-conformance |
0.6.2 Supporting directories
| Directory | Статус | Назначение |
|---|---|---|
core/ | non-normative | Gentle single-doc введение для read-первого знакомства + core-mode boundary case (§1.5.4) |
guide/ | non-normative | Practical guides: quickstart, walkthrough, transition guide, substrate-specific tool guides, compliance, failure modes |
reference/ | non-normative (informative) | Приложения: glossary, schemas, AI risk register, AI style guide, knowledge graph schema |
research/ | non-normative (frozen drafts) | Обоснования и историческое наследие; drafts со статусом frozen не редактируются |
Substrate-зависимая терминология (§1.3.1) присутствует только в guide/ и reference/ (примеры); нормативные главы — substrate-agnostic.
0.6.3 Рекомендованный порядок чтения
Первое знакомство: 00 → 01 → 03 → 05 → 06–08 → 09–11 → 12–14. Опытному читателю — начать с 05 (положение в типологии) и 11 (substrate versioning); это фундамент остальных глав.
0.7 Closed list policy
0.7.1 MVR закрыт на v1
Список из семи утверждений §0.5.1 — closed на v1.0. Project-local расширение MVR (добавление MVR-8 и далее) запрещено; уменьшение списка — также запрещено. Все семь утверждений обязательны для conformance к стандарту в целом (§14.3).
0.7.2 Declared-stricter допустимо
Имплементация может ужесточить требования сверх MVR, декларируя в conformance manifest (§14.4) с маркером declared-stricter (§10.10.2). Примеры:
- Требовать QG-3 + QG-4 как
required(вместо опциональных). - Требовать adversarial review TC (§9.4) на всех типах SPEC, не только
SPEC-SEC/SPEC-AI. - Декларировать
RENAR-3или выше как минимальный уровень для всех проектов организации.
Declared-stricter — допустимая локальная политика; conformance к нормативному минимуму сохраняется.
0.7.3 Declared-weaker запрещено
Имплементация не имеет права declared-weaker относительно MVR:
- Заявить RENAR-conformance без поддержки одного из MVR-1..MVR-7.
- Объявить ADAPT опциональным (нарушение MVR-3).
- Допустить single-TC-coverage для нормативного утверждения без negative-invariant исключения (нарушение MVR-5).
- Опустить
senar-versionилиlevelв manifest (нарушение MVR-7).
0.7.4 Путь расширения
Изменение MVR (добавление, удаление, переформулировка утверждения) — только через formal change procedure стандарта RENAR (§14.9):
- Research draft — обоснование с практическими кейсами.
- Public review — открытое обсуждение партнёрами и сообществом.
- Minor-version bump — изменение включается в
v1.Xилиv2.0. - Migration guidance — для существующих conformant проектов.
0.8 Cross-references
| Источник | Применение в этой главе |
|---|---|
| SENAR (полная методология) | Методологическая база RENAR (§0.4.1); RENAR ⊂ SENAR. |
| §1 Scope | Closed list нормативных областей и исключений; primary + negative scope; substrate-agnostic principle. |
| §3 Terms | Canonical глоссарий — закрытие terminological drift (§0.3.1 класс 5). |
| §4 Roles | Роли + двойная подпись ADAPT — основа MVR-3. |
| §5 Methodology positioning | SoT inversion — основа MVR-1. |
| §7 ADAPT | Forward + backward findings, двойная подпись, delta-ADAPT — основа MVR-3 и §0.3.1 класс 6. |
| §8 Specifications | Closed list 9 типов SPEC — основа MVR-4. |
| §9 Test cases | pos/neg парность, adversarial review — основа MVR-5 и §0.3.1 классы 7-8. |
| §10 Lifecycle и QG | Canonical state machines + closed list QG — основа MVR-6 и §0.3.1 классы 2, 7. |
| §11 Substrate versioning | Capabilities V1–V6 + single-SSoT правило — основа MVR-2 и §0.3.1 классы 1, 3, 4, 6. |
| §12 Maturity model | RENAR-1..RENAR-5 — уровни поверх MVR. |
| §14 Conformance | Mandatory clauses §14.3 ≡ MVR §0.5.1; manifest §14.4 — основа MVR-7. |
| core/renar-core.md | Core-mode boundary case (§1.5.4) для internal product без external client. |
| research/00-architecture-vision.md §7 | Источник восьми классов дрифта §0.3.1. |
| research/19-methodology-positioning.md | Источник трёх фундаментальных утверждений главы §5. |