05. Роли¶
Часть RENAR Standard v1.0 · ← Оглавление
5.1 Кто за что отвечает¶
RENAR не заводит свою иерархию ролей — он наследует пять базовых ролей из SENAR §4 и добавляет к ним специализации для работы с требованиями: кто владеет каждым артефактом (ADAPT, BR, SR, SPEC, TR, TC) и кто отвечает за каждый Quality Gate. Здесь же — правило, ради которого глава во многом существует: двусторонняя подпись ACTZ (клиент + исполнитель), без которой решение клиента не является обязательством. ADAPT при этом подписывает только Архитектор — это внутренняя интерпретация.
Глава не нормирует нативные для носителя механизмы реализации ролевых проверок (нативный для носителя 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 (§7.5) и исполнительская сторона двусторонней подписи ACTZ (§5.5). Источник истины — роль SENAR §4 «Architect / Tech Lead»; в русскоязычном корпусе именуется «Архитектор». |
| Рецензент | Лицо или AI-агент, выполняющий состязательный обзор артефактов; в RENAR — обязательная роль для QG-0 (§10.3.1). |
| Заинтересованная сторона (Stakeholder) | Внешнее заинтересованное лицо — клиент, представитель клиента с полномочиями, владелец продукта, end-user representative; источник ТЗ и сторона подписи на стороне клиента: ACTZ (§7.13) и 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).
- Объединять две базовые роли в одну так, чтобы исчезала возможность независимого подписания (например, объединение Архитектора и Заинтересованной стороны делает невозможной двустороннюю подпись ACTZ §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 | Архитектор (исполнитель) | Единоличная — внутренняя интерпретация | QG-0: Архитектор; QG-3 (опц.): подпись архитектора (§7.5) |
| 5.3.1bis | ACTZ | Архитектор (исполнитель) + представитель клиента | Совместная — обе подписи обязательны | Подписание (§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.5bis | AT | Архитектор (исполнитель) | Разделённая: авторство изолировано (§9.19.2) — генерирует изолированный AI-агент на другой модели; привязку к стенду (environment-ref) и прогон ведёт сторона исполнителя |
Релизный гейт приёмки AT (§10.4.3): автоматический runner |
| 5.3.6 | QG-4 accepted | Заинтересованная сторона (Клиент + ВП) | Одиночная — Архитектор недостаточен | Только если QG-4 в манифесте (§10.4.2) |
5.3.1 Owner ADAPT¶
ACTZ — единственный артефакт RENAR с обязательной совместной ответственностью: решение не становится обязательством без подписи обеих сторон (§7.13) — нормативная защита от односторонней фиксации обязательств.
ADAPT — артефакт единоличной ответственности Архитектора (§7.5): это внутренняя интерпретация, и клиент не подтверждает то, чего не читает. Защита от односторонней интерпретации ТЗ обеспечивается не подписью клиента под ADAPT, а тем, что каждая находка обязана быть закрыта подписанным ACTZ (§7.4.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), TEST (test-environment lead), DOC (documentation 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).
Негативный сценарий: попытка объявить, что ACTZ подписывается односторонне (без представителя клиента) — нарушение §5.3.1 и §13.3; манифест несоответствующий. Обратно: требование клиентской подписи под ADAPT избыточно и базовым соответствием не является — это declared-stricter расширение (§1.7.2).
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 в ACTZ (двусторонняя подпись требует заинтересованной стороны на стороне клиента, не уполномоченного лица со стороны исполнителя); не заменяет заинтересованную сторону в 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 Двойная подпись ACTZ¶
5.5.1 Нормативное правило¶
Двусторонняя подпись стоит на ACTZ — протоколе уточнения ТЗ (§7.13), а не на ADAPT. ACTZ переходит в signed только при наличии обеих подписей:
client-signature— со стороны представителя клиента (заинтересованная сторона с полномочиями подписания от клиента).vendor-signature— со стороны исполнителя.
ADAPT подписывает только Архитектор (§7.5): это внутренний артефакт интерпретации, клиент его не видит.
Граница проводится по аудитории: всё, что вынесено клиенту и утверждено, — обязательство (ACTZ, двусторонняя подпись); всё, что не вынесено, — интерпретация (ADAPT, подпись архитектора). Клиентская подпись под ADAPT была бы фикцией — клиент подписывал бы инженерный документ, который не читает и не может оценить.
Структура полей подписей фиксирована в §7.13.3; каждая подпись содержит signed-by, role, signed-at, signature-ref (нативный для носителя указатель на событие подписания).
5.5.2 Семантика каждой подписи¶
| Подпись | Подтверждает |
|---|---|
client-signature (на ACTZ) |
Решения, вынесенные на утверждение, приняты; формулировки обязательств («будет сделано так-то») соответствуют намерению клиента; решения финальные. |
vendor-signature (на ACTZ) |
Исполнитель принимает решения как обязательства и берётся их реализовать. |
architect-signature (на ADAPT) |
Прямая интерпретация технически реализуема; все обратные находки в состоянии resolved и несут decided-in на пункт подписанного ACTZ (§7.4.5); декомпозиция в BR / SR / SPEC безопасна для запуска. |
Подписи не взаимозаменяемы. Архитектор не подтверждает клиентскую семантику; клиент не подтверждает техническую реализуемость и не берёт на себя ответственность за интерпретацию.
5.5.3 Негативные сценарии¶
- Одна подпись отсутствует на ACTZ: протокол не переходит в
signed; решения, которые он несёт, обязательствами не являются; находки, ссылающиеся на него черезdecided-in, не могут бытьresolved, и ADAPT не переходит вapproved(§7.4.5). - Одно лицо в обеих подписях ACTZ: реализация, в которой
client-signature.signed-by == vendor-signature.signed-by, нарушает §5.5.1 (две стороны требуют двух независимых лиц). Сценарий внутреннего продукта без независимого представителя клиента — вне основной области применения (§1.5.4). - Подпись клиента на ADAPT: избыточна и нормативно не требуется. Реализация, требующая её, —
declared-stricterрасширение (§1.7.2), а не соответствие базовому уровню. - Уполномоченное лицо вместо Архитектора: допустимо (§5.4.2); подпись фиксируется с
role: authorized-role-holder. - Уполномоченное лицо вместо Клиента: не допустимо (§5.4.3);
client-signatureобязана быть от заинтересованной стороны на стороне клиента. - Подписанное решение без отражения в интерпретации: ACTZ подписан, но ни один ADAPT его решения не несёт — обязательство существует вне требований; fatal (§7.4.5).
5.5.4 Связь с другими gates¶
Двусторонняя подпись ACTZ — единственный нормативный случай двойной подписи в RENAR. Остальные gates (§10.3) выполняются одним участником (архитектор, runner, заинтересованная сторона). Это сознательное решение: ACTZ — точка согласования с клиентом, остальные 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 (состязательный) | I | I |
| Подписание ACTZ (двусторонняя подпись) | — | A (vendor-signature) |
— | — | — | — | 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 |
| Генерация AT из итогового ТЗ | R (изолированный агент, другая модель) | A | — | — | — | — | I | I |
Привязка AT к стенду (environment-ref) |
— | A | — | R | — | — | 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) |
Подпись Архитектора; все находки закрыты подписанными ACTZ | Архитектор | AI-критик | Команда |
| QG-4 Acceptance Gate (опционально, BR) | BR (verified → accepted) |
Заинтересованная сторона (Клиент + ВП) | ВП | Архитектор | Команда |
| Релизный гейт приёмки AT (обязателен, не QG — §10.4.3) | AT (все в passing); продукт |
Автоматический runner | Архитектор | — | Команда, Клиент |
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) закрыто; правило двусторонней подписи ACTZ (§5.5.1) закрыто; ролевые колонки RACI (§5.6.3) закрыты.
5.7.2 Declared-stricter допустимо¶
Реализация может ужесточить требования, явно декларируя в манифесте (§13.4) с маркером declared-stricter (§10.10.2): требовать двустороннюю подпись для BR/SR (не только для ACTZ); требовать подпись клиента под ADAPT; требовать внешний состязательный рецензент на QG-0 для SPEC-SEC и SPEC-AI; запретить совмещение Архитектора и технического лидера домена.
5.7.3 Declared-weaker запрещено¶
Реализация не имеет права объявлять ACTZ подписанным одной подписью; инженера-автора 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 | Структура поля architect-signature; client-signature и vendor-signature — на ACTZ (§7.13.3) |
| §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 | Подпись Архитектора на ADAPT (§7.5); двусторонняя подпись (§5.5) — на ACTZ |
| §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. Иерархия требований →