10. Lifecycle и Quality Gates

10.1 Назначение главы

Глава нормирует:

  • Понятие Quality Gate — нормативное определение, pre/post-conditions, кто и когда обязан проверять.
  • Канонический закрытый список gates RENAR: QG-0 (Approval), QG-1 (Implementation), QG-2 (Verification) — обязательные для conformance; QG-3 (Architecture) и QG-4 (Acceptance) — опциональные расширения.
  • Lifecycle всех артефактов RENAR: BR / SR / TR (требования, глава 06), SPEC (глава 08), ADAPT (глава 07), TC (глава 09) — консолидированные state machines с привязкой gate-id к каждому переходу.
  • Substrate-agnostic enforcement — нормативные требования к hook-механизмам через capabilities V1–V6 (глава 11). Конкретные имплементации (substrate-native реализация hooks) выносятся в guide/ и conformance manifest.
  • Closed list policy: добавление нового типа Quality Gate производится только через formal change procedure стандарта RENAR (глава 14); project-local расширения списка gate-типов запрещены.

Глава не определяет frontmatter артефактов (это делают главы 06–09). Глава фиксирует только lifecycle states, переходы между ними и gates, контролирующие переходы.

10.2 Нормативное определение Quality Gate

10.2.1 Quality Gate

Quality Gate (gate) — нормативное условие, проверка которого обязана быть выполнена для разрешённого перехода артефакта из одного lifecycle-состояния в другое. Каждый gate состоит из:

  1. Идентификатор — QG-N или QG-<artifact>-<state> (закрытый список §10.3, §10.4).
  2. Pre-condition — набор проверяемых утверждений об артефакте и связанных артефактах, которые обязаны быть истинны на момент запуска gate.
  3. Post-condition — состояние, в которое переходит артефакт после успешного прохождения gate, и наблюдаемые эффекты (например, появление записи в лог переходов §10.13).
  4. Триггер — кто или что инициирует проверку gate (актор: AI-агент / архитектор / автоматический runner; событие: одобрение / завершение прогона / поступление delta-ТЗ).
  5. Enforcement-точка — место в substrate, где проверка обязана быть автоматизирована (§10.11).

Gate не является событием успеха — это условие, которое обязано быть проверено. Прохождение gate может быть отрицательным (pre-condition не выполнен) — в этом случае переход запрещён и артефакт остаётся в текущем состоянии.

10.2.2 Кто обязан проверять gate

Тип gateОбязательный actorSubstrate enforcement
Approval (QG-0)Архитектор или авторизованный role-holderАтомарная фиксация авторства и времени (V6, §11.3.6)
Implementation (QG-1)Автоматический runner (CI, eval-runner)Атомарная фиксация результата прогона привязанного к версии артефакта (V5, §11.3.5)
Verification (QG-2)Автоматический runner с подтверждением version-pinV5 + V6
Architecture (QG-3, опционально)Двойная подпись (клиент + архитектор)V3 + V6
Acceptance (QG-4, опционально)Stakeholder с полномочиямиV6

10.2.3 Связь с SENAR

SENAR §8 описывает Quality Gates как абстрактную концепцию для AI-управляемой разработки. RENAR расширяет SENAR в области requirements engineering:

  • Сохраняет идентификаторы QG-0 / QG-1 / QG-2 как обязательные.
  • Нормирует формальные state machines для каждого типа артефакта (SENAR этого не делает).
  • Привязывает каждый переход в state machine к конкретному gate с pre/post-conditions.
  • Добавляет опциональные QG-3 / QG-4 для отраслей с расширенными требованиями к аудиту.

RENAR не противоречит SENAR; имплементация SENAR-совместима с RENAR если выполнены требования §10.3 + §10.11.

10.3 Канонические RENAR gates (обязательные)

Закрытый список из трёх обязательных gates. Расширения вне этого списка — только опциональные §10.4 или через formal change procedure стандарта §10.10.

10.3.1 QG-0 — Approval Gate

Назначение: разрешает переход артефакта из черновика в утверждённое для разработки состояние.

Pre-condition (общая часть, дополняется per-artifact в §10.5–§10.9):

  • Frontmatter артефакта валиден по schema своей главы.
  • Идентификатор артефакта уникален в substrate (V1, §11.3.1).
  • Adversarial review произведён; или явно зафиксировано отсутствие применимости — допустимо только для тривиальных артефактов (по критериям, объявленным в conformance manifest, §14) с записью причины в лог переходов (§10.13).
  • Если артефакт ссылается на источник (source.adapt для BR/SR/SPEC, verifies[] для TC) — referenced артефакт существует в substrate в состоянии не ниже approved.

Post-condition:

  • Артефакт переходит в approved (для requirements / SPEC) или ready (для TC) или approved ADAPT (§10.8).
  • Запись в лог переходов (§10.13).
  • Для requirements / SPEC: разрешается декомпозиция в дочерние артефакты (для BR — SR; для SR — TR + SPEC через constrained-by / implements-spec).

Триггер: явное одобрение архитектором / role-holder в substrate-native механизме (V3 diff & review, §11.3.3).

Применимые артефакты: BR, SR, TR, SPEC, ADAPT, TC.

10.3.2 QG-1 — Implementation Gate

Назначение: подтверждает, что для артефакта существует валидная реализация — код, конфигурация, инфраструктурный артефакт — пригодная для верификации.

Pre-condition:

  • Реализация привязана к версии артефакта через version-pin (V5, §11.3.5).
  • automation.status: automated (с валидным automation.location) или automation.status: manual-pending (с указанным manual-pending-until и manual-pending-reason).
  • Все статические проверки имплементации substrate-агента (типы, lint, схема) — пройдены.
  • Pos/neg парность для покрываемых утверждений артефакта обеспечена (глава 09 §9.7).
  • Все обязательные секции body TC (глава 09 §9.4) заполнены.

Post-condition:

  • TC переходит в ready.
  • Запись в лог переходов.

Триггер: одобряющий actor (one-click promote draft → ready) при подтверждении автоматического runner о прохождении dry-run.

Применимые артефакты: TC (draft → ready).

Примечание: TR не имеет самостоятельной gate-passage QG-1. Условия валидности реализации (impl scope, version-pin, статические проверки) для TR фиксируются как pre-conditions QG-2 (§10.6.2). QG-1 — отдельный gate только для TC. Для BR / SR / SPEC аналогично — переход approved → verified управляется единым QG-2; промежуточного «QG-1 implementation» для requirements / SPEC не существует.

10.3.3 QG-2 — Verification Gate

Назначение: подтверждает, что наблюдаемое поведение системы соответствует артефакту: все TC из verified-by артефакта в состоянии passing на текущей версии артефакта.

Pre-condition:

  • Для BR / SR / SPEC: все TC из verified-by имеют last-run.result = pass и last-run.requirement-version (или эквивалент spec-version / version) совпадает с текущей version верифицируемого артефакта.
  • Pos/neg парность по нормативным утверждениям артефакта — выполнена.
  • Все обязательные spec-specific виды TC для типа артефакта присутствуют (глава 09 §9.8).
  • Для TR: все его AC верифицированы привязанными TC (last-run.result = pass).
  • Spec-specific дополнительные предусловия:
    • SPEC-UI / SPEC-AI: TC в состоянии passing с judge-isolation соблюдённой (глава 09 §9.13.4).
    • SPEC-SEC: TC tc-type: security присутствует и passing.

Post-condition:

  • Артефакт переходит в verified.
  • Запись в лог переходов с evidence-refs (список ID прогонов).
  • Substrate обязан фиксировать version верифицируемого артефакта в evidence-записи (V5).

Триггер: автоматический runner подтверждает passing TC и инициирует promote-transition по запросу автора (one-click promote approved → verified).

Применимые артефакты: BR, SR, SPEC, TR.

10.4 Опциональные gates

QG-3 и QG-4 — нормативно описаны, но не обязательны для conformance (глава 14). Имплементация может объявить в conformance manifest либо поддержку QG-3 / QG-4, либо их отсутствие. Conformance без QG-3 / QG-4 остаётся валидной.

10.4.1 QG-3 — Architecture Gate (опционально)

Назначение: разрешает переход ADAPT из answered в approved (§10.8). Также применим к декомпозиционным решениям SPEC-ARCH в проектах с регулируемой архитектурной приёмкой.

Pre-condition:

  • Все backward findings в ADAPT в статусе resolved (глава 07 §7.4.5).
  • Двойная подпись готова: client signature + architect signature (глава 07 §7.5).
  • Для SPEC-ARCH (если QG-3 применяется): декомпозиционное решение зафиксировано в substrate как ADR-like артефакт со ссылкой из SPEC-ARCH (форма ADR substrate-specific — fits в guide/).

Post-condition:

  • ADAPT переходит в approved (immutable наравне с ТЗ).
  • Запись в лог переходов с обеими подписями (V6 author + timestamp фиксирует обоих акторов).

Триггер: явный двойной approval; substrate обязан атомарно фиксировать обе подписи (V2 atomic change unit, §11.3.2).

Когда применять:

  • ADAPT — всегда (но имплементация может объявить QG-3 как локальный псевдоним для approval ADAPT, не выделяя его в отдельный gate).
  • SPEC-ARCH — в проектах с регуляторными требованиями к архитектурной приёмке.

10.4.2 QG-4 — Acceptance Gate (опционально)

Назначение: фиксирует приёмку клиентом бизнес-результата после релиза. Переход BR из verified в accepted.

Pre-condition:

  • BR в verified (QG-2 пройден).
  • Измеримый бизнес-результат (business-outcome в frontmatter BR) — измерен; current-value зафиксирован.
  • achievement ≥ project-configurable порога (по умолчанию 80 %, фиксируется в conformance manifest).
  • Формальная подпись stakeholder’а.

Post-condition:

  • BR переходит в accepted (терминальный недеградируемый статус — обратный переход требует delta-ТЗ).
  • Запись в лог переходов с подписью stakeholder’а.

Триггер: формальная приёмка stakeholder’ом по факту релиза.

Когда применять:

  • Проекты с явной фиксацией post-release outcomes (продуктовые SaaS, регулируемые отрасли).
  • При отсутствии QG-4 — статус accepted не используется; BR остаётся в verified до deprecated.

10.4.3 Conformance с/без опциональных gates

Conformance manifest (глава 14) обязан явно объявлять:

quality-gates:
  qg-0: required          # всегда required
  qg-1: required
  qg-2: required
  qg-3: declared          # required | declared | absent
  qg-4: declared

declared означает: имплементация поддерживает gate; артефакты могут проходить его, но conformance не требует прохождения для всех артефактов. absent — gate не применяется в имплементации; терминальное состояние артефакта — verified (без accepted).

10.5 State machine BR / SR

10.5.1 Состояния и переходы

draft  ──[QG-0]──▶  approved  ──[QG-2]──▶  verified  ──[QG-4 (опционально)]──▶  accepted
  │                     │                      │                                    │
  │                     │                      │                                    │
  └──────────┬──────────┴──────────────────────┴──────────[deprecation]─────────────┘
             ▼
        deprecated  (terminal; с `replaced-by` если есть замена)
СтатусСемантикаGate перехода
draftСоздан AI-агентом или архитектором; ещё не утверждён— (создание)
approvedУтверждён к декомпозиции / реализацииQG-0 (§10.3.1)
verifiedВсе производные TC passing на текущей версииQG-2 (§10.3.3)
acceptedPost-release бизнес-результат подтверждёнQG-4 (§10.4.2, опционально)
deprecatedТерминальный; не удаляется (V1 immutable history)Deprecation transition (§10.5.3)

Frontmatter BR / SR (включая обязательные поля статуса) определяется в главе 06 §6.5.2 / §6.6.2. Этот раздел нормирует только переходы между состояниями и привязку к gates.

10.5.2 Pre-conditions per transition

ПереходGateДополнительные pre-conditions (поверх §10.3)
draft → approvedQG-0BR: business-outcome заполнен. SR: parent BR в состоянии не ниже approved. Если SR ссылается на SPEC через constrained-by[] — все SPEC в approved или выше.
approved → verifiedQG-2Хотя бы один TC с negative: true в verified-by. Все last-run.requirement-version совпадают с текущей version.
verified → acceptedQG-4Только если имплементация объявила QG-4.
* → deprecatedDeprecation transition (§10.5.3)См. §10.5.3

10.5.3 Deprecation transition

Pre-condition:

  • Артефакт находится в любом не-deprecated состоянии.
  • replaced-by (если указан) существует в substrate и находится в состоянии не ниже approved.
  • Нет активных дочерних TR в состоянии approved или активных задач исполнителя по этому артефакту (атомарная переадресация задач на replacement — обязательное условие, V2 atomic change unit).

Post-condition:

  • status: deprecated.
  • deprecated-date записан (V6).
  • replaced-by указан, если есть замена.

Триггер: архитектор или Product Owner.

10.5.4 Reverse-эволюция верификации

Если артефакт уже verified, но version инкрементировался (например, после применения delta-ADAPT, глава 07 §7.6) — статус обязан вернуться в approved до повторного прохождения QG-2 на новой версии. Этот переход обязателен и автоматический: substrate обязан инвалидировать verified при изменении version (глава 06 §6.5.4 reverse-эволюция).

10.6 State machine TR

10.6.1 Состояния и переходы

draft  ──[QG-0]──▶  approved  ──[QG-2 (per TR)]──▶  done
  │                     │                            │
  │                     │                            │
  └─────────────────────┴───[обесценивание]─────────▶ obsolete
СтатусСемантикаGate
draftTR создан; AC ещё не финализированы—
approvedAC утверждены; разрешён старт работы исполнителяQG-0 (§10.3.1) с TR-specific pre-conditions §10.6.2
doneAC верифицированы; все привязанные TC passingQG-2 (§10.3.3) с TR-specific pre-conditions §10.6.2
obsoleteTR утратил актуальность до завершения (родительский SR изменился)Обесценивание (архитектор)

10.6.2 TR-specific pre-conditions

QG-0 для TR (draft → approved) — дополнительно к общей части:

  • Цель сформулирована (goal).
  • AC верифицируемы и независимы (каждый AC — отдельная проверка).
  • Хотя бы один негативный сценарий присутствует.
  • Установлена ссылка на parent SR (или BR для простых конфигураций) через implements.
  • Если TR реализует SPEC — обязательное поле implements-spec[] (глава 08 §8.6.2).
  • Если задача затрагивает безопасность — threat-surface задекларирован (глава 08 §8.5.8).

QG-2 для TR (approved → done):

  • Все AC TR подтверждены прохождением соответствующих TC (last-run.result = pass).
  • Pos/neg парность по каждому AC.
  • Для TR реализующего SPEC: TC соответствующего spec-specific вида существует и passing (глава 09 §9.8).

10.6.3 Обесценивание TR

Если родительский SR переходит в deprecated или его version изменилась так, что AC TR более не актуальны — TR переходит в obsolete. Это не деградация — это альтернативный терминальный путь. TR в obsolete не удаляется.

10.7 State machine SPEC

10.7.1 Состояния и переходы

draft  ──[review-transition]──▶  review  ──[QG-0]──▶  approved  ──[QG-2]──▶  verified
                                                          │                       │
                                                          └───[обесценивание]──▶ obsolete  (terminal)
СтатусСемантикаGate
draftSPEC создан; обязательные frontmatter-поля заполняются—
reviewОбязательные body-разделы (§8.4.1) и type-specific (§8.5) присутствуют; готов к ревьюReview-transition (§10.7.2)
approvedАрхитектор подтвердил; depends-on[] консистентенQG-0
verifiedВсе обязательные spec-specific TC passingQG-2
obsoleteЗаменён или больше не актуален; replaced-by обязателенDeprecation (§10.5.3 mutatis mutandis)

10.7.2 Review-transition (draft → review)

Review-transition не является полноценным gate в смысле §10.2.1 — это автоматическая проверка структурной полноты. Pre-condition:

  • Все обязательные frontmatter-поля §8.4 заполнены.
  • Все обязательные body-разделы §8.4.1 присутствуют.
  • Type-specific разделы §8.5 присутствуют для соответствующего spec-type.

Post-condition: status: review; артефакт виден архитектору для ревью.

Если review-transition не пройден — артефакт остаётся в draft; substrate обязан вернуть список отсутствующих секций (V3 diff & review поддерживает структурный фидбек).

10.7.3 SPEC-specific pre-conditions

QG-0 для SPEC (review → approved) — дополнительно к общей части §10.3.1:

  • depends-on[] граф ацикличен (глава 08 §8.6.3).
  • Все SPEC из depends-on[] в состоянии не ниже approved.
  • Если SPEC ссылается на ADAPT через source.adapt — ADAPT в состоянии approved.

QG-2 для SPEC (approved → verified):

  • Все обязательные spec-specific виды TC для spec-type присутствуют и passing (глава 09 §9.8).
  • Для SPEC-AI: pos/neg pair coverage по evaluation-criteria = 100 %; judge-isolation соблюдена.
  • Для SPEC-SEC: tc-type: security присутствует.
  • Для SPEC-DATA: tc-type: contract присутствует для опубликованных interface-полей.

10.8 State machine ADAPT

10.8.1 Macro-состояния

draft  ──[review-transition]──▶  review  ──[backward-ready]──▶  client-ready
                                                                       │
                                                                       │ [client returns answers]
                                                                       ▼
                                                                  answered
                                                                       │
                                                                       │ [QG-3]
                                                                       ▼
                                                                  approved
                                                                       │
                                                                       │ [immutable; только delta-ADAPT или errata]
                                                                       ▼
                                                                  frozen

Состояния ADAPT (draft → review → client-ready → answered → approved → frozen) определены в главе 07 §7.4. Этот раздел нормирует gates.

ПереходGatePre-condition
draft → reviewReview-transitionForward охватывает все разделы ТЗ; первичные backward findings зафиксированы в open
review → client-readyBackward-readyВсе backward findings переведены в asked-to-client; пакет вопросов сформирован
client-ready → answeredClient-returnВсе backward findings в answered с author + timestamp ответа клиента (V6)
answered → approvedQG-3 (§10.4.1)Все backward findings в resolved; двойная подпись готова
approved → frozenFreeze-transitionАвтоматический после approve; ADAPT immutable; разрешается генерация BR / SR / SPEC с source.adapt = approved

10.8.2 Sub-state machine для backward-записи

Каждая backward-запись внутри ADAPT имеет собственную sub-state machine (глава 07 §7.4.5):

open  ──▶  asked-to-client  ──▶  answered  ──▶  resolved  ──[approve ADAPT]──▶  frozen
                  ▲                  │
                  └──── revised ─────┘  (если ответ требует уточнения)
Sub-stateСемантика
openЗаписан инженером; не отправлено клиенту
asked-to-clientОтправлен клиенту; зафиксирована дата вопроса
answeredКлиент ответил; ответ записан (V6 author + timestamp)
resolvedИнженер интегрировал ответ в forward интерпретацию
revisedОтвет расплывчатый; повторный вопрос (возврат к asked-to-client)
frozenПосле approval ADAPT; изменения невозможны

Нормативное правило: QG-3 (approve ADAPT) запрещён, если хотя бы одна backward-запись в open / asked-to-client / answered / revised. Все backward-записи обязаны быть в resolved (глава 07 §7.4.5).

10.8.3 QG-3 для ADAPT — детализация

Pre-condition (полная):

  • Все forward разделы покрыты (forward complete).
  • Все backward-записи в resolved.
  • Client signature получен и зафиксирован substrate-нативным механизмом (V3 + V6).
  • Architect signature получен и зафиксирован.
  • Если ADAPT — delta-ADAPT: parent-ADAPT в frozen (глава 07 §7.6).

Post-condition:

  • ADAPT переходит в approved.
  • Запись в лог переходов с обеими подписями.
  • Substrate обязан атомарно (V2) зафиксировать обе подписи: частичная подпись (только клиент / только архитектор) не переводит ADAPT в approved.

Триггер: явное одобрение обоими акторами.

10.8.4 Errata для frozen ADAPT

frozen — терминальное недеградируемое состояние. Изменения возможны только через:

  1. Delta-ADAPT (если ТЗ содержит ambiguity, обнаруженную поздно) — новый артефакт с явной связью parent-adapt.
  2. Errata-ADAPT (если ошибка интерпретации инженера) — отдельный артефакт с подписью клиента (если меняется contractual outcome) или только архитектора (если cosmetic).

В обоих случаях frozen ADAPT не редактируется. Это требование V1 (immutable history) для контрактных артефактов (глава 07 §7.6.3).

10.9 State machine TC

10.9.1 Состояния и переходы

draft  ──[QG-0]──▶  ready  ──[runner pass]──▶  passing
                      │                            │
                      │   [runner fail]            │ [criteria change |
                      └─────────────────────▶ failing      delta invalidation]
                                                   │            │
                                                   ▼            ▼
                                                obsolete  ◀─────┘  (terminal)
СтатусСемантикаGate / триггер
draftTC создан; реализация в работе—
readydry-run runner прошёл; pos/neg парность подтвержденаQG-0 (§10.3.1) с TC-specific pre-conditions §10.9.2
passinglast-run.result = pass на текущей requirement-versionRunner pass; bot-managed
failinglast-run.result = failRunner fail; bot-managed
obsoleteПокрываемое поведение более не существуетDeprecation (§10.9.4)

Frontmatter TC и pos/neg pairing определяются в главе 09.

10.9.2 TC-specific pre-conditions

QG-0 для TC (draft → ready) — дополнительно к общей части:

  • automation.status: automated (с валидным automation.location) ИЛИ automation.status: manual-pending (с manual-pending-until ≤ +1 sprint и заполненным manual-pending-reason).
  • Pos/neg парность по покрываемым утверждениям подтверждена (§9.7).
  • Dry-run runner прошёл (только структурная валидность; не путать с production-прогоном).
  • Все обязательные секции body TC (§9.4) заполнены.
  • Citation на verifies[] — артефакт существует в substrate в состоянии не ниже approved.

Post-condition:

  • status: ready.
  • Runner разрешён к production-прогону.

10.9.3 Runner-managed переходы (не Quality Gates)

ready → passing, ready → failing, passing → failing, failing → passing — переходы, происходящие только по факту прогона runner’а (глава 09 §9.12 last-run bot-managed). Эти переходы не являются Quality Gates в смысле §10.2.1: они — нормативные следствия результатов прогона, а не gate-passage с pre/post-conditions. В частности, проверка совпадения last-run.requirement-version с текущей версией верифицируемого артефакта (см. §9.10) — это runner-managed consistency check, а не отдельный gate.

Post-condition каждого runner-перехода:

  • last-run обновлён: result, timestamp, requirement-version, evidence-refs.
  • Substrate обязан запретить ручную модификацию last-run (только runner-actor).

10.9.4 Обесценивание TC

TC переходит в obsolete если:

  1. Артефакт из verifies[] переходит в deprecated / obsolete.
  2. Delta-ТЗ инвалидирует тестовое поведение (глава 09 §9.16).

Post-condition: status: obsolete. TC не удаляется (V1 immutable history).

10.9.5 Change-of-criteria — отдельный нормативный путь

Изменение ## Критерий успеха или ## Критерий неуспеха в TC — не обычный transition; это специальный путь, требующий отдельного approval workflow (глава 09 §9.13). Подробности enforcement — §10.11.3.

10.10 Closed list policy

10.10.1 Нормативное правило

Закрытый список Quality Gates RENAR — обязательные {QG-0, QG-1, QG-2} и опциональные {QG-3, QG-4}. Изменение списка возможно только через formal change procedure стандарта RENAR (глава 14).

10.10.2 Что запрещено

ДействиеЗапрещено?Почему
Project-local создание нового gate-типа QG-NЗапрещеноНарушает закрытый список; делает conformance не-портируемой
Локальное переопределение pre-conditions canonical gateЗапрещеноДелает conformance несравнимой между имплементациями
Дополнительное ужесточение pre-conditions локального gateРазрешеноConformance manifest может объявить более строгие пороги (например, qg-2.required-negative-tc: true)
Локальное ослабление pre-conditions canonical gateЗапрещеноНарушает контракт стандарта
Объявление QG-3 / QG-4 как absent в conformance manifestРазрешеноОпциональные gates — §10.4
Объявление QG-0 / QG-1 / QG-2 как absentЗапрещеноНарушает conformance §10.4.3

10.10.3 Расширение списка

Добавление нового gate-типа возможно через:

  1. Запрос на изменение стандарта (formal change request) с обоснованием — research-draft с типологией и сравнением с canonical gates.
  2. Public review (срок и форум фиксируется политикой стандарта, глава 14).
  3. Включение в следующую minor-версию стандарта (v1.X или v2.0).

Project-local расширения остаются за пределами conformance — они допустимы как internal-практики, но не влияют на conformance manifest.

10.11 Substrate-agnostic enforcement

10.11.1 Нормативные требования

Substrate, реализующий RENAR, обязан обеспечить автоматическую проверку pre-conditions gates на следующих точках:

Точка enforcementЧто обязано быть провереноОпирается на capabilities
Promote-transition (любой переход в более высокий статус)Pre-conditions соответствующего gate (§10.3, §10.4, §10.5–§10.9)V3 (diff & review) для блокировки перехода до approve; V4 (branching) для отделения WIP от утверждённой правды
Approve-transition (any approval action)Authorship зафиксирован (actor) и временная меткаV6 (author + timestamp)
Reference-validation (любое создание/изменение артефакта с ссылкой на другой)Referenced артефакт существует и в требуемом состоянииV1 (immutable history) для stable identifier; V5 (version pin) для cross-substrate ссылок
Change-of-criteria для TC (§10.11.3)Применён отдельный approval workflowV3 + V6
Runner-transitions для TC (ready → passing/failing)Только runner-actor может писать last-runV6 (authorship); substrate-native ACL или role-based restrictions
Lifecycle invalidation (артефакт verified, версия инкрементировалась)Артефакт автоматически переведён в approvedV5 (version pin) для детекции

10.11.2 Substrate без V3 / V4 / V6 — не conformant

Substrate, не обеспечивающий V3 (diff & review), не может реализовать gates: нет способа отделить «предложенное изменение» от «утверждённой правды» (глава 11 §11.3.3). Аналогично V4 (branching, §11.3.4) и V6 (author + timestamp, §11.3.6) — без них approval-механика невозможна. Substrate, не удовлетворяющий V3 / V4 / V6, не реализует RENAR независимо от других свойств.

10.11.3 Change-of-criteria для TC — особый enforcement

Изменение Pass / Fail критерия TC — высокорисковая операция (защита от test-fitting, глава 09 §9.13). Substrate обязан:

  1. Детектировать: любое изменение секций ## Критерий успеха / ## Критерий неуспеха в TC-артефакте.
  2. Принудительно изолировать: change-of-criteria обязано быть отдельным change-set (V4 atomic change unit), помеченным признаком, отличающим его от обычных правок (substrate-native механизм — частный случай V3 diff & review; форма признака — substrate-specific, выносится в guide/).
  3. Запретить совмещение: одно и то же лицо не имеет права одобрить change-of-criteria и одобрение fix кода, который тестируется этим же TC. Substrate обязан проверять это правило при approve-transition.
  4. Регистрировать: change-of-criteria записывается в audit-trail (§10.13) с явной типизацией события.

10.11.4 Forms of substrate-native реализации

Конкретные substrate-native механизмы (как именно реализуется hook в данном substrate) — выносятся в guide/ и conformance manifest. Стандарт не нормирует форму hook (это substrate-specific решение). Стандарт нормирует что hook обязан проверять и в какой точке.

Раздел guide/ обязан содержать для каждого поддерживаемого substrate:

  • Mapping enforcement-точек §10.11.1 на substrate-native механизмы.
  • Примеры реализаций.
  • Известные ограничения substrate относительно автоматизации каждой проверки.

10.12 Запрещённые переходы

Закрытый список переходов, нарушающих lifecycle. Substrate обязан их блокировать.

ИзВАртефактПочему запрещено
draftverifiedBR / SR / SPECПропускает QG-0; нет evidence approval
draftacceptedBRSame; и пропускает QG-2
draftdoneTRПропускает QG-0
draftpassingTCПропускает QG-0 (нет dry-run runner)
obsolete*ЛюбойТерминальный статус; «реанимация» запрещена — нужен новый артефакт с supersedes
deprecated*ЛюбойSame
frozen*ADAPTSame; изменения только через delta-ADAPT или errata (§10.8.4)
verifieddraftBR / SR / SPECДеградация через несколько ступеней — потенциальная потеря trace; если требуется доработка — verified → approved через delta или reverse-эволюция §10.5.4
acceptedverifiedBRДеградация после приёмки — недопустима без delta-ТЗ
acceptedapprovedBRSame
passingdraftTCДеградация теряет history runs; используется passing → failing → obsolete или change-of-criteria путь
readydraftTCДеградация теряет dry-run evidence (§10.9.2); ослабление TC через [test-spec-change] (глава 09 §9.13) — не путь возврата в draft
failingdraftTCДеградация теряет runner history; повторная диагностика — через новый прогон (failing → passing runner-managed) или obsolete

10.12.1 Реакция substrate

При попытке запрещённого перехода substrate обязан:

  1. Заблокировать transition (V3 diff & review).
  2. Вернуть actor’у код ошибки с указанием конкретного нарушенного правила (по идентификатору строки этой таблицы).
  3. Не создавать запись в лог переходов (§10.13).

10.13 Logging gate-passing events

10.13.1 Нормативное требование

Каждое успешное прохождение gate (любого типа: QG-0, QG-1, QG-2, QG-3, QG-4, runner-transition, deprecation, freeze-transition) обязано быть зафиксировано в substrate как immutable событие со следующими полями:

ПолеСемантикаОбязательность
timestampUTC ISO-8601 момент успешного прохожденияОбязательно
artifact-idИдентификатор артефакта (immutable, V1)Обязательно
artifact-typeBR / SR / TR / SPEC-<type> / ADAPT / TCОбязательно
artifact-versionВерсия артефакта на момент перехода (V5)Обязательно
from-statusИсходное состояниеОбязательно
to-statusЦелевое состояниеОбязательно
gate-idQG-0 / QG-1 / QG-2 / QG-3 / QG-4 / deprecation / freeze / runner-pass / runner-fail / change-of-criteriaОбязательно
actorИдентификатор инициатора (V6); для двойной подписи — список акторовОбязательно
evidence-refsСсылки на доказательства: ID прогонов runner, ID adversarial-review артефактов, ID подписейОбязательно для QG-2 / QG-3 / QG-4
notesСвободный текстОпционально

10.13.2 Substrate-agnostic format

Формат хранения событий — substrate-specific (отдельный лог-стрим / append-only collection / иные формы). Стандарт нормирует только обязательные поля §10.13.1, не их сериализацию.

Conformance manifest обязан указать механизм хранения событий и формат экспорта (для audit-аудита, глава 14).

10.13.3 Retention

События не удаляются в течение всего lifecycle артефакта и после его перехода в deprecated / obsolete / frozen. Этого требует V1 (immutable history) и нормативные положения compliance (глава 14).

10.14 Связь с другими главами

ГлаваСвязь
05SENAR QG-0..QG-2 — концептуальная основа; RENAR расширяет (§10.2.3)
06Frontmatter и body BR / SR / TR (§6.5–§6.7); state machines детализированы здесь (§10.5–§10.6)
07Frontmatter ADAPT (§7.8); backward sub-states (§7.4.5); двойная подпись (§7.5); delta-ADAPT (§7.6) — state machine здесь (§10.8)
08Frontmatter SPEC (§8.4); type-specific QG (§8.8); state machine здесь (§10.7)
09Frontmatter TC (§9.3); pos/neg pairing (§9.7); change-of-criteria (§9.13); state machine здесь (§10.9)
11V1–V6 — фундамент enforcement (§10.11); без V3 / V4 / V6 — нет реализации gates
12Уровни зрелости определяют объём применимых gates (например, RENAR-1 — QG-0 / QG-1 / QG-2 обязательны; на более высоких уровнях усиливаются pre-conditions QG-2: pos/neg парность, spec-specific TC)
14Conformance manifest объявляет gate support (§10.4.3); хранит retention policy событий (§10.13.3)