04. Roles
Часть RENAR Standard v1.0-draft · ← Оглавление
4.1 Назначение главы
Глава нормирует роли в RENAR-проекте. RENAR не переопределяет базовый список ролей SENAR §4 и не вводит параллельную ролевую таксономию — он ссылается на SENAR и задаёт специализации для управления требованиями. Глава фиксирует:
- Closed list 5 базовых ролей SENAR (§4.2) с нормативной semantic-summary; полное определение ролей и их обязанностей — в SENAR §4.
- RENAR-specific специализации (§4.3) — кто нормативно является owner для каждого типа артефакта стандарта (ADAPT, BR, SR, SPEC-*, TR, TC) и за каждый Quality Gate, нормированный в главе 10.
- Authorized role-holder (§4.4) — нормативное определение делегирования architect-полномочий для целей одобрения и self-assessment (§14.5).
- Двойная подпись ADAPT (§4.5) — нормативное правило обязательной двойной подписи (client + architect) для перехода ADAPT в
approved; согласованно с §7.5 и §10.8. - RACI-матрица (§4.6) — закрытая матрица ответственности по типам артефактов RENAR и каноническим gates.
- Closed list policy (§4.7) — список ролей-owners закрыт на v1; project-local расширения запрещены.
Глава не нормирует substrate-нативные механизмы реализации ролевых проверок (substrate-native ACL, V6 author identifiers, substrate-native signature events) — это область главы 11 (capabilities) и guide/03-tool-guide-*.md (substrate-specific tooling). Substrate-зависимая терминология (имена конкретных review-механизмов, authorship-идентификаторов и task-routing систем) в этой главе не используется.
4.2 Базовые роли (SENAR §4)
4.2.1 Closed list
RENAR ссылается на пять базовых ролей SENAR §4 как на источник истины. Список закрыт на стороне SENAR; RENAR не добавляет и не удаляет роли.
| Роль | Краткая семантика (для RENAR-контекста) |
|---|---|
| Supervisor | Лицо, инициирующее и контролирующее работу AI-агента; в RENAR — типичный заказчик задачи elicitation, draft generation, ADAPT review. |
| AI-агент | Программный actor, выполняющий генерацию артефактов требований (forward интерпретация ADAPT, draft BR/SR/SPEC/TC) и review-операции; включает primary-генератора и adversarial-критика. |
| Architect / Tech Lead | Лицо, нормативно ответственное за технические решения и одобрение артефактов требований (QG-0 §10.3.1); подписывающая сторона двойной подписи ADAPT (§4.5). |
| Reviewer | Лицо или AI-агент, выполняющий adversarial review артефактов; в RENAR — обязательная роль для QG-0 (§10.3.1). |
| Stakeholder | Внешнее заинтересованное лицо — клиент, представитель клиента с полномочиями, product owner, end-user representative; источник ТЗ и сторона signature на стороне клиента (§7.5) и QG-4 (§10.4.2). |
Полное определение semantics каждой роли — обязанности, ограничения, взаимодействия — изложено в SENAR §4 и применяется к RENAR без изменений.
4.2.2 Запрет переопределения
Имплементация не имеет права:
- Переименовывать базовые роли SENAR в нормативной части conformance manifest (§14.4).
- Объединять две базовые роли в одну так, чтобы исчезала возможность независимого подписания (например, объединение Architect и Stakeholder делает невозможной двойную подпись §4.5 и не допускается).
- Добавлять новые базовые роли вне SENAR §4 без formal change procedure стандарта SENAR.
Project-local псевдонимы (например, локальное название «Lead Engineer» как синоним SENAR Architect / Tech Lead) допустимы в коммуникации, но conformance manifest (§14.4) обязан использовать нормативные имена ролей SENAR §4.
4.3 RENAR-specific специализации: ownership артефактов
Каждый тип артефакта RENAR имеет нормативно зафиксированного owner-а — роль, ответственную за инициирование артефакта, его содержательную целостность и one-click promote через QG-0 (§10.3.1).
4.3.1 Owner ADAPT
| Параметр | Нормативное значение |
|---|---|
| Owner | Architect (со стороны исполнителя) и Client representative (Stakeholder с полномочиями) |
| Тип ownership | Совместный (joint); обе роли обязаны для approval |
| QG-0 actor | Architect |
| QG-3 actor (опционально) | Двойная подпись (§4.5): Client + Architect |
ADAPT — единственный артефакт RENAR с обязательным joint ownership: одна сторона не может довести ADAPT до approved без участия другой (§7.5). Это нормативная защита от односторонней интерпретации ТЗ.
4.3.2 Owner BR / SR
| Параметр | Нормативное значение |
|---|---|
| Owner | Architect |
| QG-0 actor | Architect или authorized role-holder (§4.4) |
| QG-2 actor | Автоматический runner (без участия role-holder) |
| QG-4 actor (опционально) | Stakeholder (Client + Product Owner) §10.4.2 |
Architect нормативно ответственен за декомпозицию ADAPT → BR → SR и за согласованность дерева требований. AI-агент допустим как primary-генератор draft BR/SR, но не является owner-ом — owner всегда человек или явно делегированная authorized role-holder (§4.4).
4.3.3 Owner SPEC-*
| Параметр | Нормативное значение |
|---|---|
| Owner | Architect и domain tech lead |
| Тип ownership | Joint по типу SPEC: Architect — общая ответственность; domain tech lead — содержательная экспертиза для конкретного типа SPEC |
| QG-0 actor | Architect или authorized role-holder (§4.4) |
Domain tech lead — нормативный термин для лица с экспертизой по конкретному типу SPEC из закрытого списка (§8.X): SPEC-ARCH (системный архитектор), SPEC-API (API designer), SPEC-DATA (data architect), SPEC-INT (integration lead), SPEC-PROC (process owner), SPEC-UI (UX lead), SPEC-AI (ML lead), SPEC-SEC (security lead), SPEC-OPS (operations lead).
В малых проектах одно лицо может совмещать domain tech lead роли для нескольких типов SPEC; объединение Architect и всех domain tech leads в одно лицо допустимо при условии явной декларации в conformance manifest (§14.4).
4.3.4 Owner TR
| Параметр | Нормативное значение |
|---|---|
| Owner approval | Architect или authorized role-holder (§4.4) |
| Owner execution | Engineer (исполнитель TR) |
QG-0 actor (draft → approved) | Architect или authorized role-holder |
QG-2 actor (approved → done) | Engineer (с подтверждением автоматического runner) |
TR имеет разделённое ownership: одобрение задачи — у architect / role-holder, выполнение — у engineer. Engineer не может одобрить собственный TR (нарушение §10.2.2).
4.3.5 Owner TC
| Параметр | Нормативное значение |
|---|---|
| Owner | Engineer и QA |
| Тип ownership | Joint; engineer — авторство, QA — pos/neg парность и достаточность (§9.7) |
QG-1 actor (draft → ready) | Одобряющий actor (engineer или QA) + автоматический runner (dry-run pass) |
| QG-2 actor | Автоматический runner с version-pin (V5) |
AI-агент допустим как primary-генератор TC, но обязан проходить QA-проверку перед ready (§10.3.2). В проектах без явной QA-роли — обязательным QA-actor становится engineer, отличный от автора TC.
4.3.6 Owner accepted gate (QG-4)
| Параметр | Нормативное значение |
|---|---|
| Actor QG-4 | Stakeholder с полномочиями: Client + Product Owner |
| Применимость | Только если имплементация объявила QG-4 в conformance manifest (§10.4.2) |
QG-4 — единственный gate, для которого Architect не является достаточным actor. Подтверждение post-release бизнес-результата требует Stakeholder-а с полномочиями. При отсутствии QG-4 в manifest этот gate не применяется, и роль Client/Product Owner на этом этапе lifecycle артефакта не нормируется.
4.3.7 Closed list policy для owners
Список owner-распределений §4.3.1–§4.3.6 — закрыт на v1. Project-local расширения (новый owner для нового типа артефакта; перераспределение owner-полномочий между ролями SENAR §4) не допускаются без formal change procedure стандарта (§14.9).
Negative scenario: попытка имплементации объявить, что owner ADAPT — только Architect (без Client representative) — нарушение §4.3.1 и §14.3; manifest с таким объявлением не conformant.
4.4 Authorized role-holder
4.4.1 Нормативное определение
Authorized role-holder — лицо с явно делегированными architect-полномочиями для конкретного scope (один артефакт, один тип артефактов, или весь проект). Делегирование фиксируется substrate-нативно (V6 author identifier + ACL §11.3.6); конкретный механизм делегирования — substrate-specific и не нормируется в стандарте.
Authorized role-holder — нормативный термин, идентичный по применению в §10.2.2, §10.3.1 и §14.5.
4.4.2 Допустимые scenarios
Authorized role-holder допустим как actor для:
- QG-0 Approval (§10.2.2) — для BR / SR / SPEC / TR / ADAPT (на стороне architect) / TC.
- Self-assessment (§14.5) — как assessor с ролью
authorized-role-holderв conformance manifest.
4.4.3 Недопустимые scenarios
Authorized role-holder не заменяет:
- Client signature в ADAPT (§4.5) — двойная подпись ADAPT нормативно требует client-signature от Stakeholder-а, не от authorized role-holder со стороны исполнителя.
- Stakeholder в QG-4 (§10.4.2) — accepted gate требует Stakeholder с полномочиями на стороне клиента.
- External assessor в third-party assessment (§14.6) — внешняя оценка conformance требует независимости от проекта.
4.4.4 Substrate-нативная авторизация
Делегирование authorized role-holder обязано фиксироваться substrate-нативно через V6 (author + timestamp §11.3.6). Конкретный механизм — substrate-specific:
- Substrate с ACL-моделью — через role-based access list.
- Substrate с capability-токенами — через выпуск делегирующего токена.
- Substrate без явной авторизации — через декларацию делегирования в substrate-native артефакте проекта (например, отдельный файл с подписью architect).
Substrate-specific детали реализации делегирования — в guide/03-tool-guide-*.md для соответствующих substrate-семейств.
4.5 Двойная подпись ADAPT
4.5.1 Нормативное правило
ADAPT переходит в approved (QG-3 §10.4.1, §10.8.2) только при наличии обеих подписей:
client-signature— со стороны Client representative (Stakeholder с полномочиями подписания от клиента).architect-signature— со стороны Architect исполнителя.
Структура полей подписей фиксирована в §7.5; каждая подпись содержит signed-by, role, signed-at, signature-ref (substrate-native pointer на signature event).
4.5.2 Семантика каждой подписи
| Подпись | Подтверждает |
|---|---|
client-signature | Forward интерпретация совпадает с намерением клиента; все backward findings отвечены и ответы — финальные; ADAPT представляет согласованное с клиентом понимание ТЗ. |
architect-signature | Forward интерпретация технически реализуема; все backward findings в состоянии resolved (§7.4.5); декомпозиция в BR / SR / SPEC безопасна для запуска. |
Подписи не взаимозаменяемы. Architect не подтверждает client-side семантику; Client не подтверждает technical feasibility. Оба подтверждения нормативно обязательны.
4.5.3 Negative scenarios
- Одна подпись отсутствует: ADAPT с заполненной только
client-signatureили толькоarchitect-signatureнормативно не переходит вapproved. QG-3 запрещён (§10.8.2); попытка принудительного перехода — нарушение §14.3. - Одно лицо в обеих подписях: имплементация, в которой
client-signature.signed-by == architect-signature.signed-by, нарушает §4.5.1 (две роли требуют двух независимых лиц). Случайcoreminimal-mode, гдеclient-signatureопционален (см.core/renar-core.md), — вне scope conformance к полному RENAR (§14.3). - Authorized role-holder вместо Architect: допустимо (§4.4.2); подпись фиксируется с
role: authorized-role-holderиsignature-refуказывает на substrate-нативное доказательство делегирования. - Authorized role-holder вместо Client: не допустимо (§4.4.3); client-signature обязана быть от Stakeholder-а на стороне клиента.
4.5.4 Связь с другими gates
Двойная подпись ADAPT — единственный нормативный случай dual signature в RENAR. Остальные gates (§10.3) выполняются одним actor-ом (architect, runner, stakeholder). Это сознательное архитектурное решение: ADAPT — точка согласования с клиентом, остальные gates — внутренние проверки имплементации.
4.6 RACI-матрица
Матрица фиксирует Responsible / Accountable / Consulted / Informed по типам артефактов RENAR и каноническим gates. Сокращения: R = Responsible (исполняет), A = Accountable (одобряет / отвечает за результат), C = Consulted (обязан быть проинформирован до решения), I = Informed (уведомляется после решения).
4.6.1 Матрица артефактов
| Активность | AI-агент | Architect | Domain TL | Engineer | QA | Reviewer | Client | PO |
|---|---|---|---|---|---|---|---|---|
| Импорт ТЗ | R | A | — | — | — | C (adversarial) | C | I |
| Создание ADAPT (forward + backward) | R | A | C | — | — | C (adversarial) | C | I |
| Approval ADAPT (двойная подпись) | — | A (architect-signature) | — | — | — | C (adversarial) | A (client-signature) | I |
| Декомпозиция ADAPT → BR | R | A | C | — | — | C | I | C |
| Декомпозиция BR → SR | R | A | C | — | — | C | I | C |
| Создание SPEC-* | R | A | R/A (per type) | — | — | C | I | I |
| Создание TR | R | A | C | C | — | — | I | I |
| Реализация TR (execution) | — | C | C | R | — | — | I | I |
| Создание TC | R | C | C | R/A | A | — | I | I |
| Adversarial review артефакта | R (AI-критик) | A | — | — | — | R | — | I |
4.6.2 Матрица Quality Gates
Соответствие нормативно фиксированной таблице actor-ов §10.2.2.
| Gate | Артефакты | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|---|
| QG-0 Approval | BR, SR, TR, SPEC, TC, ADAPT (architect-side) | Architect или authorized role-holder | Architect | AI-критик (Reviewer) | Команда |
| QG-1 Implementation | TC (draft → ready) | Engineer / QA | Engineer | Автоматический runner | Команда |
| QG-2 Verification | BR, SR, TR, SPEC, TC | Автоматический runner (V5 + V6) | Architect | — | Команда |
| QG-3 Architecture (опционально, ADAPT) | ADAPT (answered → approved) | Двойная подпись (Client + Architect) | Architect | AI-критик | Команда |
| QG-4 Acceptance (опционально, BR) | BR (verified → accepted) | Stakeholder (Client + PO) | PO | Architect | Команда |
4.6.3 Closed list ролей в RACI
Список ролей-колонок матрицы §4.6.1 / §4.6.2 — закрыт на v1 RENAR:
AI-агент, Architect, Domain tech lead (per SPEC-type), Engineer, QA, Reviewer (adversarial), Client (Stakeholder с полномочиями), Product Owner.
Project-local роли (например, «Release Manager», «Compliance Officer») допустимы как Informed или Consulted в локальной practical-RACI имплементации, но не появляются как Responsible или Accountable в нормативной матрице conformance — иначе manifest не conformant (§14.3).
4.7 Closed list policy
4.7.1 Что зафиксировано на v1
- Список базовых ролей SENAR §4 (§4.2.1) — closed на стороне SENAR; RENAR не расширяет.
- Owner-распределение по типам артефактов (§4.3.1–§4.3.6) — closed.
- Authorized role-holder как нормативный термин (§4.4) — closed; semantics и scope изменяются только через formal change procedure стандарта.
- Правило двойной подписи ADAPT (§4.5.1) — closed; не подменяется и не отменяется project-local.
- Список ролей-колонок RACI (§4.6.3) — closed.
4.7.2 Declared-stricter (допустимо)
Имплементация может ужесточить требования относительно нормативного минимума, явно декларируя это в conformance manifest (§14.4) с указателем declared-stricter (§10.10.2):
- Требовать двойную подпись для BR/SR (не только для ADAPT).
- Требовать external adversarial reviewer на QG-0 для SPEC-SEC и SPEC-AI.
- Запретить совмещение Architect и domain tech lead в одном лице.
Declared-stricter — допустимая локальная политика; conformance к нормативному уровню сохраняется.
4.7.3 Declared-weaker (запрещено)
Имплементация не имеет права declared-weaker относительно §4 (одностороннее ослабление):
- Объявить, что ADAPT approve возможен с одной подписью.
- Объявить, что engineer-author TC может самостоятельно одобрить TC без QA-actor.
- Объявить, что QG-4 actor может быть исполнитель проекта вместо Stakeholder-а.
Manifest с любым declared-weaker относительно §4 — non-conformant (§14.8 loss-of-conformance).
4.7.4 Path для расширений
Добавление новой роли в нормативный список (§4.2, §4.3, §4.6.3) или новой owner-комбинации (§4.3.7) производится только через formal change procedure стандарта RENAR (§14.9): research draft → public review → minor-version bump. Project-local extensions остаются за пределами conformance.
4.8 Cross-references
| Источник | Применение |
|---|---|
| SENAR §4 | Closed list 5 базовых ролей; semantics и обязанности (нормативный источник) |
| §7.5 ADAPT approval schema | Структура полей client-signature и architect-signature |
| §10.2.2 QG actor table | Нормативное соответствие gate → actor; согласовано с §4.6.2 |
| §10.3.1 QG-0 Approval | Architect или authorized role-holder как actor §4.4 |
| §10.4.1 QG-3 Architecture | Dual signature requirement (§4.5) для ADAPT |
| §10.4.2 QG-4 Acceptance | Stakeholder (Client + PO) — §4.3.6 |
| §11.3.6 V6 Author + timestamp | Substrate-нативная фиксация authorship для делегирования role-holder §4.4.4 |
| §14.4 Conformance manifest | Использование нормативных имён ролей §4.2.2 |
| §14.5 Self-assessment | Assessor role enum (architect / authorized-role-holder / external-assessor) — §4.4 anchor |
core/renar-core.md | Minimal-mode: client-signature optional для ADAPT (вне scope полного conformance §4.5.3) |
guide/03-tool-guide-*.md | Substrate-specific механизмы делегирования (§4.4.4) и signature implementations |
← Предыдущая: 03. Terms · Оглавление · Следующая: 05. Methodology Positioning →