05. Роли¶
Часть RENAR Standard v1.0-draft · ← Оглавление
5.1 Кто за что отвечает¶
RENAR не заводит свою иерархию ролей — он наследует пять базовых ролей из SENAR §4 и добавляет к ним специализации для работы с требованиями: кто владеет каждым артефактом (ADAPT, BR, SR, SPEC, TR, TC) и кто отвечает за каждый Quality Gate. Здесь же — правило, ради которого глава во многом существует: двойная подпись ADAPT (клиент + архитектор), без которой ADAPT не переходит в approved.
Глава не нормирует нативные для носителя механизмы реализации ролевых проверок (нативный для носителя ACL, V6-идентификаторы автора, нативные для носителя события подписания) — это область главы 3 (возможности носителя) и guide/03-tool-guide-*.md (специфичный для носителя инструментарий).
5.2 Базовые роли (SENAR §4)¶
5.2.1 Закрытый список¶
RENAR ссылается на пять базовых ролей SENAR §4 как на источник истины. Список закрыт на стороне SENAR; RENAR не добавляет и не удаляет роли.
| Роль | Краткая семантика (для RENAR-контекста) |
|---|---|
| Супервизор | Лицо, инициирующее и контролирующее работу AI-агента; в RENAR — типичный заказчик задач выявления требований, генерации черновиков, рецензирования ADAPT. |
| AI-агент | Программный участник, выполняющий генерацию и сопровождение артефактов требований (forward интерпретация ADAPT, BR/SR/TR/SPEC/TC, обновление графовых связей при изменениях). В RENAR — штатный primary author артефактов (§0.2.1); включает primary-генератора и adversarial-критика. AI-агент не является owner (§5.3) и не ставит подписей (§5.5). |
| Архитектор / Tech Lead | Лицо, нормативно ответственное за технические решения и одобрение артефактов требований (QG-0 §10.3.1); подписывающая сторона двойной подписи ADAPT (§5.5). Источник истины — роль SENAR §4 «Architect / Tech Lead»; в русскоязычном корпусе именуется «Архитектор». |
| Рецензент | Лицо или AI-агент, выполняющий состязательный обзор артефактов; в RENAR — обязательная роль для QG-0 (§10.3.1). |
| Заинтересованная сторона (Stakeholder) | Внешнее заинтересованное лицо — клиент, представитель клиента с полномочиями, владелец продукта, end-user representative; источник ТЗ и сторона подписи на стороне клиента (§7.5) и QG-4 (§10.4.2). |
Полное определение семантики каждой роли — обязанности, ограничения, взаимодействия — изложено в SENAR §4 и применяется к RENAR без изменений.
Именование роли Архитектора. Везде далее в стандарте, руководстве и приложениях роль SENAR «Architect / Tech Lead» обозначается русским каноническим именем «Архитектор» (например, «Архитектор подтвердил» в §8.3, двойная подпись в §5.5). Это синоним, а не отдельная роль: манифест соответствия обязан использовать нормативное имя SENAR (§5.2.2).
Именование роли заинтересованной стороны. Везде далее в стандарте, руководстве и приложениях роль SENAR «Stakeholder» обозначается русским каноническим именем «Заинтересованная сторона» (например, «заинтересованная сторона с полномочиями» в §5.3.6, сторона подписи на стороне клиента в §5.5). Это синоним, а не отдельная роль: манифест соответствия обязан использовать нормативное имя SENAR (§5.2.2).
5.2.2 Запрет переопределения¶
Реализация не имеет права:
- Переименовывать базовые роли SENAR в нормативной части манифеста соответствия (§13.4).
- Объединять две базовые роли в одну так, чтобы исчезала возможность независимого подписания (например, объединение Архитектора и Заинтересованной стороны делает невозможной двойную подпись §5.5 и не допускается).
- Добавлять новые базовые роли вне SENAR §4 без формальной процедуры изменения стандарта SENAR.
Локальные для проекта псевдонимы (например, локальное название «Lead Engineer» как синоним SENAR Architect / Tech Lead) допустимы в коммуникации, но манифест соответствия (§13.4) обязан использовать нормативные имена ролей SENAR §4.
5.3 Специализации RENAR: ответственность за артефакты¶
Каждый тип артефакта имеет нормативно зафиксированного owner-а — роль, ответственную за инициирование артефакта, содержательную целостность и one-click promote через QG-0 (§10.3.1).
| § | Артефакт | Owner | Тип отв. | Участники QG |
|---|---|---|---|---|
| 5.3.1 | ADAPT | Архитектор (исполнитель) + Client representative | Совместная — обе роли обязаны для утверждения | QG-0: Архитектор; QG-3 (опц.): двойная подпись (§5.5) |
| 5.3.2 | BR / SR | Архитектор | Одиночная (Accountable); AI-агент = Responsible primary-генератор | QG-0: Архитектор или authorized role-holder (§5.4); QG-2: автоматический runner; QG-4 (опц.): Заинтересованная сторона |
| 5.3.3 | SPEC-* | Архитектор + технический лидер домена | Совместная по типу SPEC: Архитектор — общая; ТЛ домена — экспертиза | QG-0: Архитектор или authorized role-holder |
| 5.3.4 | TR | Архитектор (утверждение) + Инженер (execution) | Разделённая | QG-0: Архитектор; QG-2: Инженер + runner |
| 5.3.5 | TC | Инженер + QA | Совместная — авторство Инженера, QA pos/neg парность (§9.7) | QG-1: Инженер/QA + runner; QG-2: runner с V5 pin |
| 5.3.6 | QG-4 accepted | Заинтересованная сторона (Клиент + ВП) | Одиночная — Архитектор недостаточен | Только если QG-4 в манифесте (§10.4.2) |
5.3.1 Owner ADAPT¶
ADAPT — единственный артефакт RENAR с обязательной совместной ответственностью: одна сторона не может довести ADAPT до approved без участия другой (§7.5) — нормативная защита от односторонней интерпретации ТЗ.
5.3.2 Owner BR / SR¶
Архитектор нормативно ответственен за декомпозицию ADAPT → BR → SR и за согласованность дерева требований. AI-агент — штатный primary-генератор draft BR/SR (§0.2.1, §5.2.1), но не owner: owner всегда человек или уполномоченное лицо (§5.4). В RACI: AI-агент — Responsible (исполняет), Архитектор — Accountable (отвечает за результат). Попытка манифеста объявить AI-агента как Accountable — несоответствующий (§13.3).
5.3.3 Owner SPEC-*¶
Технический лидер домена — нормативный термин для экспертизы по конкретному типу SPEC (§8.3): ARCH (системный архитектор), API (API designer), DATA (data architect), INT (integration lead), PROC (process owner), UI (UX lead), AI (ML lead), SEC (security lead), OPS (operations lead). В малых проектах одно лицо может совмещать роли ТЛ домена; объединение Архитектора + всех ТЛ домена в одно лицо допустимо при декларации в манифесте (§13.4).
5.3.4 Owner TR¶
TR имеет разделённую ответственность: одобрение задачи — у Архитектора/уполномоченного лица, выполнение — у Инженера. Инженер не может одобрить собственный TR (нарушение §10.2.2).
5.3.5 Owner TC¶
AI-агент допустим как primary-генератор TC, но обязан проходить QA-проверку перед ready (§10.3.2). В проектах без явной QA-роли QA-участником становится инженер, отличный от автора TC.
5.3.6 Owner accepted gate (QG-4)¶
QG-4 — единственный gate, для которого Архитектор не является достаточным участником. Подтверждение post-release бизнес-результата требует заинтересованной стороны с полномочиями (Клиент + ВП). При отсутствии QG-4 в манифесте gate не применяется, и роль Клиент/ВП на этом этапе жизненного цикла не нормируется.
5.3.7 Политика закрытого списка для owner-распределений¶
Список §5.3.1-§5.3.6 — закрытый на v1. Локальные для проекта расширения (новый owner для нового типа; перераспределение owner-полномочий между ролями SENAR §4) не допускаются без формальной процедуры изменения стандарта (§13.9).
Негативный сценарий: попытка объявить, что owner ADAPT — только Архитектор (без Client representative) — нарушение §5.3.1 и §13.3; манифест несоответствующий.
5.4 Уполномоченное лицо¶
5.4.1 Нормативное определение¶
Уполномоченное лицо (authorized role-holder) — лицо с явно делегированными архитекторскими полномочиями для конкретного охвата (один артефакт, один тип артефактов или весь проект). Делегирование фиксируется нативно для носителя (V6 author identifier + ACL §3.3.6); конкретный механизм специфичен для носителя. Уполномоченное лицо — нормативный термин, идентичный по применению в §10.2.2, §10.3.1, §13.5.
5.4.2 Допустимые сценарии¶
Участник для QG-0 Approval Gate (§10.2.2) — BR/SR/SPEC/TR/ADAPT (со стороны архитектора)/TC; self-assessment (§13.5) — assessor с ролью authorized-role-holder в манифесте.
5.4.3 Недопустимые сценарии¶
Уполномоченное лицо не заменяет client-signature в ADAPT (двойная подпись требует заинтересованной стороны на стороне клиента, не уполномоченного лица со стороны исполнителя); не заменяет заинтересованную сторону в QG-4 (§10.4.2); не заменяет внешнего оценщика в независимой оценке (третьей стороной) (§13.6).
5.4.4 Авторизация на стороне носителя¶
Делегирование обязано фиксироваться нативно через V6 (§3.3.6): носитель с ACL — через role-based access list; носитель с capability-токенами — через выпуск делегирующего токена; носитель без явной авторизации — через декларацию делегирования в нативном артефакте проекта (отдельный файл с подписью архитектора). Специфичные для носителя детали — guide/03-tool-guide-*.md.
5.5 Двойная подпись ADAPT¶
5.5.1 Нормативное правило¶
ADAPT переходит в approved (QG-3 §10.4.1, §10.8.2) только при наличии обеих подписей:
client-signature— со стороны Client representative (заинтересованная сторона с полномочиями подписания от клиента).architect-signature— со стороны Архитектора исполнителя.
Структура полей подписей фиксирована в §7.5; каждая подпись содержит signed-by, role, signed-at, signature-ref (нативный для носителя указатель на событие подписания).
5.5.2 Семантика каждой подписи¶
| Подпись | Подтверждает |
|---|---|
client-signature |
Forward интерпретация совпадает с намерением клиента; все backward findings отвечены и ответы — финальные; ADAPT представляет согласованное с клиентом понимание ТЗ. |
architect-signature |
Forward интерпретация технически реализуема; все backward findings в состоянии resolved (§7.4.5); декомпозиция в BR / SR / SPEC безопасна для запуска. |
Подписи не взаимозаменяемы. Архитектор не подтверждает клиентскую семантику; Клиент не подтверждает техническую реализуемость. Оба подтверждения нормативно обязательны.
5.5.3 Негативные сценарии¶
- Одна подпись отсутствует: ADAPT с заполненной только
client-signatureили толькоarchitect-signatureнормативно не переходит вapproved. QG-3 запрещён (§10.8.2); попытка принудительного перехода — нарушение §13.3. - Одно лицо в обеих подписях: реализация, в которой
client-signature.signed-by == architect-signature.signed-by, нарушает §5.5.1 (две роли требуют двух независимых лиц). Сценарий внутреннего продукта без независимого представителя клиента — вне основной области применения (§1.5.4); манифест такого проекта не заявляет соответствие RENAR-N. - Уполномоченное лицо вместо Архитектора: допустимо (§5.4.2); подпись фиксируется с
role: authorized-role-holderиsignature-refуказывает на нативное для носителя доказательство делегирования. - Уполномоченное лицо вместо Клиента: не допустимо (§5.4.3);
client-signatureобязана быть от заинтересованной стороны на стороне клиента.
5.5.4 Связь с другими gates¶
Двойная подпись ADAPT — единственный нормативный случай двойной подписи в RENAR. Остальные gates (§10.3) выполняются одним участником (архитектор, runner, заинтересованная сторона). Это сознательное архитектурное решение: ADAPT — точка согласования с клиентом, остальные gates — внутренние проверки реализации.
5.6 RACI-матрица¶
Матрица фиксирует Responsible / Accountable / Consulted / Informed по типам артефактов RENAR и каноническим gates. Сокращения: R = Responsible (исполняет), A = Accountable (одобряет / отвечает за результат), C = Consulted (обязан быть проинформирован до решения), I = Informed (уведомляется после решения).
5.6.1 Матрица артефактов¶
| Активность | AI-агент | Архитектор | Технический лидер домена | Инженер | QA | Рецензент | Клиент | ВП |
|---|---|---|---|---|---|---|---|---|
| Импорт ТЗ | R | A | — | — | — | C (состязательный) | C | I |
| Создание ADAPT (forward + backward) | R | A | C | — | — | C (состязательный) | C | I |
| Утверждение ADAPT (двойная подпись) | — | A (architect-signature) |
— | — | — | C (состязательный) | 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 |
| Состязательный обзор артефакта | R (AI-критик) | A | — | — | — | R | — | I |
5.6.2 Матрица Quality Gates¶
Соответствие нормативно фиксированной таблице участников §10.2.2.
| Gate | Артефакты | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|---|
| QG-0 Approval Gate | BR, SR, TR, SPEC, TC, ADAPT (со стороны архитектора) | Архитектор или authorized role-holder | Архитектор | AI-критик (Рецензент) | Команда |
| QG-1 Implementation Gate | TC (draft → ready) |
Инженер / QA | Инженер | Автоматический runner | Команда |
| QG-2 Verification Gate | BR, SR, TR, SPEC, TC | Автоматический runner (V5 + V6) | Архитектор | — | Команда |
| QG-3 Architecture Gate (опционально, ADAPT) | ADAPT (answered → approved) |
Двойная подпись (Клиент + Архитектор) | Архитектор | AI-критик | Команда |
| QG-4 Acceptance Gate (опционально, BR) | BR (verified → accepted) |
Заинтересованная сторона (Клиент + ВП) | ВП | Архитектор | Команда |
5.6.3 Закрытый список ролей в RACI¶
Список ролей-колонок матрицы §5.6.1 / §5.6.2 — закрыт на v1 RENAR:
AI-агент, Архитектор, Технический лидер домена (per SPEC-type), Инженер, QA, Рецензент (состязательный), Клиент (Заинтересованная сторона с полномочиями), Владелец продукта.
Локальные для проекта роли (например, «release Manager», «Compliance Officer») допустимы как Informed или Consulted в локальной practical-RACI реализации, но не появляются как Responsible или Accountable в нормативной матрице соответствия — иначе манифест не соответствующий (§13.3).
5.7 Политика закрытого списка (закрытый список)¶
5.7.1 Что зафиксировано на v1¶
Базовые роли SENAR §4 (§5.2.1) закрыты на стороне SENAR; owner-распределение §5.3.1-§5.3.6 закрыто; уполномоченное лицо (§5.4) закрыто; правило двойной подписи ADAPT (§5.5.1) закрыто; ролевые колонки RACI (§5.6.3) закрыты.
5.7.2 Declared-stricter допустимо¶
Реализация может ужесточить требования, явно декларируя в манифесте (§13.4) с маркером declared-stricter (§10.10.2): требовать двойную подпись для BR/SR (не только ADAPT); требовать внешний состязательный рецензент на QG-0 для SPEC-SEC и SPEC-AI; запретить совмещение Архитектора и технического лидера домена.
5.7.3 Declared-weaker запрещено¶
Реализация не имеет права объявлять ADAPT утверждённым с одной подписью; инженера-автора TC одобряющим без участника-QA; исполнителя в роли участника QG-4 вместо Заинтересованной стороны. Манифест с declared-weaker относительно §5 — несоответствующий (§13.8 потеря соответствия).
5.7.4 Путь для расширений¶
Добавление новой роли (§5.2, §5.3, §5.6.3) или owner-комбинации (§5.3.7) — только через формальную процедуру изменения стандарта (§13.9): исследовательский черновик → публичное обсуждение → повышение minor-версии.
5.8 Перекрёстные ссылки¶
| Источник | Применение |
|---|---|
| SENAR §4 | Закрытый список 5 базовых ролей; semantics и обязанности (нормативный источник) |
| §7.5 ADAPT approval schema | Структура полей client-signature и architect-signature |
| §10.2.2 QG actor table | Нормативное соответствие gate → участник; согласовано с §5.6.2 |
| §10.3.1 QG-0 Approval Gate | Архитектор или authorized role-holder как участник §5.4 |
| §10.4.1 QG-3 Architecture Gate | Требование двойной подписи (§5.5) для ADAPT |
| §10.4.2 QG-4 Acceptance Gate | Заинтересованная сторона (Клиент + ВП) — §5.3.6 |
| §3.3.6 V6 Author + timestamp | нативная для носителя фиксация авторства для делегирования role-holder §5.4.4 |
| §13.4 Манифест соответствия | Использование нормативных имён ролей §5.2.2 |
| §13.5 Self-assessment | Assessor role enum (architect / authorized-role-holder / external-assessor) — §5.4 anchor |
core/renar-core.md |
Концептуальный обзор стандарта для человека-читателя (ненормативный); roles и signatures полностью нормируются здесь, §5 |
guide/03-tool-guide-*.md |
специфичные для носителя механизмы делегирования (§5.4.4) и signature implementations |
← Предыдущая: 04. Термины и определения · Оглавление · Следующая: 06. Иерархия требований →