01. Scope
Часть RENAR Standard v1.0-draft · ← Оглавление
1.1 Назначение главы
Глава нормирует формальные границы стандарта RENAR: какие предметные области покрывает (closed list, §1.2), какие — явно не покрывает (closed list, §1.3), в каких контекстах разработки применим (§1.4) и в каких не применим (§1.5). Глава фиксирует:
- Closed list нормативных областей (§1.2) — артефакты, lifecycle-механизмы, мета-возможности, которые RENAR нормирует. Список закрыт на v1; расширения — только через formal change procedure (§14.9).
- Closed list исключений (§1.3) — области, которые RENAR явно не нормирует и оставляет за пределами conformance; имплементация свободна в выборе.
- Primary применимость (§1.4) — контракт-ориентированная разработка как нормативный target-контекст стандарта.
- Negative scope (§1.5) — контексты, в которых RENAR-conformance структурно невозможен (отсутствуют обязательные предусловия — immutable ТЗ, двусторонняя client-side validation).
- Связь с SENAR (§1.6) — RENAR как специализация SENAR в области requirements engineering; нормативная совместимость, не альтернатива.
- Closed list policy (§1.7) — нерасширяемость §1.2 / §1.3 / §1.4 / §1.5 project-local; путь добавления через formal change procedure.
Глава не определяет содержательные нормы артефактов и lifecycle — это область глав 06–14. Глава не определяет substrate-нативные механизмы реализации — это область главы 11 и guide/03-tool-guide-*.md.
1.2 Что нормирует RENAR (closed list)
Закрытый список нормативных областей RENAR на версии v1.0. Каждая область рассматривается в указанной главе:
| # | Область | Глава |
|---|---|---|
| 1 | Иерархия требований (BR / SR / TR) | 06 |
| 2 | ADAPT (двусторонняя адаптация ТЗ): forward интерпретация + backward findings + двойная подпись | 07 |
| 3 | Closed list 9 типов спецификаций (SPEC-ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS) | 08 |
| 4 | Test Cases как first-class артефакт; pos/neg парность; spec-specific TC-обязательства | 09 |
| 5 | Lifecycle states + Quality Gates (QG-0 / QG-1 / QG-2 обязательные; QG-3 / QG-4 опциональные) | 10 |
| 6 | Substrate-agnostic versioning capabilities V1–V6 | 11 |
| 7 | Maturity model (RENAR-1..RENAR-5) | 12 |
| 8 | Метрики requirements engineering (RDLT, Hallucination Rate, DRA, ACR и др.) | 13 |
| 9 | Conformance (mandatory clauses, manifest, self-assessment, third-party assessment) | 14 |
| 10 | Роли и ownership артефактов (specializations над SENAR §4) | 04 |
Все перечисленные области имеют нормативное содержание (MUST / SHALL / запрет project-local расширений по соответствующим closed lists).
1.2.1 Что относится к нормативной области
К нормативной области RENAR относятся:
- Data model артефактов — обязательные frontmatter поля, типы, enum-значения, инварианты согласованности.
- Lifecycle states + переходы — state machines per артефакт-тип; pre/post-conditions; gate-id для каждого перехода.
- Identity и provenance — immutable identifiers; substrate-нативная фиксация authorship и timestamp (V6); version pin между артефактами (V5).
- Cross-artifact constraints —
verifies[],constrained-by[],parent,delta-of,verified-by,implements-spec— нормативная семантика связей и правила консистентности. - AI-provenance — обязательная фиксация модели-генератора, prompt-template, объёма tokens; правила human-edits для approval.
- Conformance procedures — mandatory clauses, manifest schema, assessment cadence, loss-of-conformance handling.
1.3 Что RENAR явно НЕ нормирует (closed list)
Закрытый список областей, которые намеренно оставлены за пределами стандарта. Имплементация в этих областях — свободный выбор и не влияет на conformance.
| # | Область | Что вне scope |
|---|---|---|
| 1 | SENAR-методология в целом | 5 ценностей, 14 правил, общие Quality Gates, agent instrumentation — нормируются SENAR; RENAR не дублирует и не переопределяет. |
| 2 | Конкретный substrate / VCS | Выбор конкретного version-control / document-database / wiki-platform — на усмотрение имплементации; RENAR нормирует только capabilities V1–V6 (§11). |
| 3 | Tech stack реализации | Языки программирования, фреймворки, базы данных, инфраструктурные компоненты — вне scope; RENAR нормирует требования, не реализацию. |
| 4 | Конкретный UI / IDE / редактор артефактов | Web-интерфейсы, IDE-расширения, CLI-инструменты — вне scope; нормируется только формат хранения артефактов в substrate. |
| 5 | Конкретные test runners | pytest, jest, playwright, ragas, и др. — substrate-specific; RENAR нормирует только обязательность automation.location и last-run фиксации (V5+V6). |
| 6 | Бизнес-процессы продаж / договоров | Pre-sale, формулировка договорной стоимости, юридическая структура контрактов — вне scope; RENAR работает с ТЗ как с входом и не нормирует процесс его создания на стороне клиента. |
| 7 | Project management practices | Agile-ceremonies, sprint planning, kanban-boards, story-points estimation — вне scope; RENAR нормирует workflow артефактов требований, не management-overhead. |
| 8 | AI model selection и prompt engineering | Выбор LLM-провайдера, prompt-templates, fine-tuning стратегии — вне scope; RENAR нормирует только обязательную фиксацию ai-provenance.generated-by и adversarial review pattern (§9.4). |
| 9 | Конкретные substrate-нативные команды и hooks | substrate-specific CLI-команды (например, конкретные имена команд VCS), реализация hooks (§10.11) — substrate-specific и относятся к guide/03-tool-guide-*.md. |
| 10 | Юридическая интерпретация artifact-подписей | Электронная подпись, юридическая значимость, GDPR-обработка персональных данных в ТЗ — вне scope стандарта; нормируется применимым законодательством. |
1.3.1 Принцип substrate-agnostic языка
Нормативные главы стандарта RENAR используют substrate-agnostic терминологию (§11.1). Substrate-зависимые имена (конкретные продукты, протоколы, команды) не появляются в нормативном тексте; они присутствуют только в guide/ (substrate-specific tooling) и reference/ (примеры).
1.4 Область применимости (primary scope)
1.4.1 Контракт-ориентированная разработка
Нормативный primary-контекст RENAR — контракт-ориентированная разработка: проект, в котором:
- Существует ТЗ (явно сформулированное требование со стороны заказчика), которое после подписания становится immutable (§7.4.1 ADAPT-source).
- Имеется идентифицируемая сторона клиента (Stakeholder с полномочиями подписания, §4.3.6) — способная подтвердить acceptance (§10.4.2) и подписать ADAPT (§4.5).
- Двусторонняя client-side validation обязательна — forward интерпретация ТЗ обсуждается с клиентом до начала декомпозиции (§7.3).
- Delta-ТЗ workflow возможен — изменения scope формализуются через delta-ADAPT (§7.6), а не через silent reinterpretation.
1.4.2 Типичные представители контракт-ориентированной разработки
| Контекст | Характеристики |
|---|---|
| Заказная разработка по ТЗ | Independent vendor + identifiable client; формальный договор; acceptance criteria. |
| Regulated industries | Compliance audit обязателен (медицина, финансы, госсектор); traceability requirements → tests → код требуется по нормативу. |
| Enterprise консалтинг | Third-party реализует по ТЗ клиента-корпорации; multi-stakeholder approval; audit trail. |
| Long-lived product с явным product owner-ом | Product Owner играет роль Client representative для внутренних feature-ТЗ; внутренние SLA + audit обязательны. |
| Public-sector / government IT | Тендерные ТЗ; формальная приёмка; multi-year contracts. |
1.4.3 Spec-Driven Development (SDD) — современное имя
Контракт-ориентированная разработка с AI-ускорением — это форма Spec-Driven Development (§5.X). RENAR — нормативный стандарт для AI-native SDD; не альтернатива SDD, а его специализация в области управления требованиями.
1.5 Где RENAR неприменим (negative scope)
RENAR нормативно неприменим в контекстах, где структурно отсутствуют предусловия §1.4.1. Заявление RENAR-conformance (§14.4) для проектов в этих контекстах — non-conformant (§14.8).
1.5.1 Lean startup / pure discovery
Контекст: продуктовая команда строит MVP в условиях неопределённости рынка; «требования» — гипотезы, валидируемые на пользователях, а не immutable договорённости.
Почему вне scope:
- Отсутствует immutable ТЗ — гипотезы перепроверяются после каждого pivot.
- Client representative структурно отсутствует (внутренний продакт = author + sole assessor — нарушение §4.5.3 о двух независимых лицах в подписи).
- Delta-ТЗ workflow не применим: pivot — это смена scope целиком, не дельта.
Альтернатива: lean startup команды могут заимствовать отдельные практики RENAR (например, AI-провенанс артефактов, adversarial review TC) без объявления RENAR-conformance — это допустимо как inspiration, но не conformance claim.
1.5.2 Pure R&D / исследовательские проекты
Контекст: научно-исследовательский проект без определённого результирующего scope (например, exploratory ML research, novel-algorithm prototyping без заказчика).
Почему вне scope:
- ТЗ как immutable артефакт отсутствует.
- Acceptance criteria (QG-4 §10.4.2) не формализуемы — критерий «успеха» научного исследования не подписывается заранее.
- Двойная подпись ADAPT неприменима.
1.5.3 Exploratory hackathon / proof-of-concept
Контекст: time-boxed exploratory работа без обязательной приёмки клиентом.
Почему вне scope: те же причины, что в §1.5.1 + явный отказ от формальной приёмки.
1.5.4 Internal product без external client (core-mode boundary)
Контекст: внутренний инструмент команды; «клиент» совпадает с автором; нет independent Stakeholder для двойной подписи ADAPT.
Boundary case: для таких проектов существует core-mode (core/renar-core.md) — минимальное подмножество практик RENAR (immutable identifiers, lifecycle states, V1–V6, ADAPT с опциональной client-signature). Core-mode не является полным RENAR-conformance — manifest для core-mode проекта объявляет mode: core и не заявляет RENAR-N (§14.2.1).
Negative scenario: попытка объявить RENAR-N (с полным conformance) для проекта без independent Client representative — non-conformant (§14.8), нарушение §4.5.3.
1.5.5 Negative scenarios — конкретизация
| Сценарий | Почему non-conformant |
|---|---|
| Проект без письменного ТЗ; требования — устные обсуждения | Нарушение §1.4.1 (1): ТЗ как immutable артефакт отсутствует; ADAPT не имеет source (§7.4.1). |
| Проект с author == client (одно лицо подписывает обе стороны) | Нарушение §4.5.3 о двух независимых лицах в подписях ADAPT. |
| Проект, в котором scope пересматривается без формальной фиксации delta-ТЗ | Нарушение §7.6 delta-ADAPT workflow; нарушение §14.3 mandatory clause «ADAPT для каждого ТЗ». |
| Manifest объявляет tech-stack-specific требования (например, «обязательно использовать Python») | Нарушение §1.3 (3): tech stack вне scope стандарта; manifest non-conformant. |
1.6 Связь с SENAR
1.6.1 RENAR как специализация SENAR
SENAR — методологическая база: 5 ценностей AI-native разработки, 14 правил, агенты-инструкции, общие Quality Gates (§10.2.3), 5 базовых ролей (§4.2).
RENAR — специализация SENAR в области requirements engineering: нормирует только те аспекты, которые SENAR оставляет на усмотрение domain-стандарта (data model артефактов, lifecycle, conformance manifest). RENAR не дублирует SENAR и не переопределяет SENAR-конструкции.
1.6.2 Совместимость
RENAR-conformant имплементация всегда является SENAR-совместимой. Обратное — не обязательно: SENAR-совместимый проект может не заявлять RENAR-conformance, если работает вне primary scope §1.4.
Несовместимость RENAR с SENAR в любой нормативной точке — баг стандарта RENAR; разрешается через formal change procedure стандарта SENAR + corresponding alignment в RENAR.
1.6.3 RENAR не альтернатива SENAR
Имплементация не имеет права заявить «следуем RENAR вместо SENAR» — это нарушение §1.6.1. RENAR используется поверх SENAR; conformance manifest проекта объявляет одновременно SENAR-version и RENAR-version (§14.4).
1.7 Closed list policy
1.7.1 Что закрыто на v1
- Список нормативных областей §1.2 — closed; project-local расширения нормативной области запрещены.
- Список исключений §1.3 — closed; project-local попытки нормировать через manifest исключённые области (§1.3 (3) tech stack, §1.3 (7) PM practices) — non-conformant.
- Primary scope §1.4 — closed; добавление новых primary-контекстов — только через formal change procedure стандарта.
- Negative scope §1.5 — closed; перевод сценария из §1.5 в §1.4 — только через formal change procedure (с обоснованием в research draft).
1.7.2 Declared-stricter допустимо
Имплементация может ужесточить scope относительно нормативного минимума, явно декларируя в conformance manifest (§14.4) с маркером declared-stricter (§10.10.2):
- Применять RENAR только к подмножеству требований проекта (например, только к security-critical SR).
- Требовать дополнительные artifact-типы (например, threat-models) сверх нормативных §1.2.
- Запретить core-mode для всех проектов организации.
Declared-stricter — допустимая локальная политика; conformance к нормативному уровню сохраняется.
1.7.3 Declared-weaker запрещено
Имплементация не имеет права declared-weaker относительно §1.2 / §1.3 / §1.4:
- Объявить RENAR-conformance для проекта в §1.5 negative scope.
- Применять RENAR без ADAPT (нарушение §14.3.3 mandatory clause).
- Нормировать через project-local manifest исключённые области §1.3.
1.7.4 Путь расширения
Изменение §1.2 / §1.3 / §1.4 / §1.5 — только через formal change procedure стандарта RENAR (§14.9):
- Research draft — обоснование изменения scope с практическими кейсами.
- Public review — открытое обсуждение.
- Minor-version bump — изменение включается в
v1.Xилиv2.0. - Migration guidance — для существующих conformant проектов.
1.8 Cross-references
| Источник | Применение |
|---|---|
| SENAR (полная методология) | Методологическая база RENAR (§1.6.1); RENAR не дублирует SENAR-нормы. |
| §4 Roles | Ownership артефактов и роли — specializations над SENAR §4 (§1.2 (10), §1.6.1). |
| §5 Methodology positioning | Три фундаментальных утверждения (SoT inversion, waterfall-form ≠ classical waterfall, substrate-agnostic versioning) — обоснование scope §1.4. |
| §7 ADAPT | ADAPT как нормативное требование §1.4.1 (3) двусторонней client-side validation. |
| §10 Lifecycle и QG | Lifecycle + Quality Gates — нормативная область §1.2 (5). |
| §11 Substrate versioning | V1–V6 capabilities — нормативная область §1.2 (6); substrate-agnostic принцип §1.3.1. |
| §14 Conformance | Mandatory clauses, manifest, loss-of-conformance — нормативная область §1.2 (9); negative scenarios §1.5.5. |
core/renar-core.md | Core-mode boundary case для §1.5.4 (internal product без external client). |
research/00-architecture-vision.md §4 | Источник §1.2 + §1.3 (architecture vision). |
research/19-methodology-positioning.md §2 | Источник §1.4 + §1.5 (применимость и неприменимость). |
guide/02-transition-guide.md | Practical guidance для проектов, переходящих с lean-стиля на контракт-ориентированную разработку (substrate-specific). |
← Предыдущая: 00. Introduction · Оглавление · Следующая: 02. Normative references →