specs/openspec/specs/openspec-authority-and-lifecycle/spec.md

# openspec-authority-and-lifecycle Specification

## Purpose
Определяет единственный источник полномочий для OpenSpec и проверяемый жизненный цикл SDD-изменений независимо от текущей директории, глобальной конфигурации или agent framework.

## Requirements

### Requirement: SDD-артефакты имеют непересекающиеся полномочия

Proposal SHALL выражать причину, намерение, границы и ожидаемый эффект change языком владельца и MUST NOT содержать решения по технологиям, структуре кода, файлам, API или зависимостям. Delta Specs SHALL определять только добавленное, изменённое или удалённое наблюдаемое поведение и инварианты системы без описания изменений кода. Design SHALL объяснять архитектурный способ выполнения утверждённых Specs, существенные решения, риски и альтернативы крупными частями и MUST NOT становиться построчной инструкцией реализации. Применимые UI/UX-решения и визуальные материалы SHALL входить в единый canonical Design и MUST NOT образовывать отдельный planning authority или отдельный UI/UX approval. Tasks SHALL быть implementation checklist, достаточным для выполнения Design и Specs, и MUST NOT содержать ещё не наблюдённые completion results, commit identifiers или post-archive bookkeeping. Completion Evidence SHALL фиксироваться только после фактической реализации и верификации и MUST NOT подменять planning artifact. Концептуальные материалы и Discovery SHALL оставаться входным контекстом и MUST NOT считаться утверждёнными OpenSpec artifacts.

#### Scenario: Product Owner формулирует Proposal

- **WHEN** владелец описывает требуемое изменение, не зная структуры кода и файлов
- **THEN** Proposal остаётся полноценным утверждаемым намерением без необходимости принимать архитектурные решения

#### Scenario: Агент подготавливает Tasks

- **WHEN** Proposal, Delta Specs и Design уже утверждены
- **THEN** Tasks перечисляет конкретные действия реализации и проверки, но не заявляет будущие результаты уже выполненными

#### Scenario: Владелец согласует визуальный результат

- **WHEN** Change Owner явно утверждает Design с применимыми визуальными материалами
- **THEN** решение распространяется на обозначенную версию всего пакета Design
  в существующем approval gate без новой SDD-роли или отдельного UI/UX approval

#### Scenario: Концепт доступен до Design

- **WHEN** обсуждение или Discovery содержит визуальный концепт
- **THEN** его наличие не разрешает downstream planning или реализацию и не
  заменяет явное утверждение соответствующего OpenSpec artifact

### Requirement: Artifact graph применяет последовательные approval gates

Versioned SDD change SHALL проходить последовательность `Proposal → Delta Specs → Design → Tasks → Apply`. AI-агент MAY подготовить черновик текущего разрешённого артефакта, но MUST NOT считать его утверждённым самостоятельно или создавать downstream artifact до явного решения Change Owner. Для change, определяющего продуктовое поведение, Change Owner SHALL быть Product Owner; для технического или процессного change — Engineering Owner. Каждый из четырёх planning artifacts MUST существовать и быть утверждён до Apply.

#### Scenario: Proposal ещё не утверждён

- **WHEN** AI-агент завершил черновик Proposal, но Change Owner не дал явного согласия
- **THEN** Delta Specs, Design и Tasks остаются недоступны для создания

#### Scenario: Delta Specs утверждены

- **WHEN** Change Owner явно подтверждает Delta Specs после утверждённого Proposal
- **THEN** Design становится следующим разрешённым planning artifact, а Tasks и Apply остаются заблокированы

### Requirement: Изменение upstream artifact требует каскадной проверки

Изменение утверждённого Proposal MUST инициировать повторную проверку Delta Specs, Design и Tasks; изменение утверждённых Delta Specs MUST инициировать повторную проверку Design и Tasks; изменение утверждённого Design MUST инициировать повторную проверку Tasks. Изменение Tasks MUST NOT неявно менять scope, наблюдаемое поведение или архитектурные решения upstream artifacts; при таком обнаружении workflow SHALL вернуть работу к самому раннему затронутому upstream artifact и его approval gate. Если несоответствие обнаружено во время Design или Apply, downstream-работа MUST остановиться, а Change Owner MUST получить наблюдаемое основание возврата и решения, требуемые на выбранном уровне. Механическое исправление синтаксиса или формата, которое не меняет утверждённые намерение, поведение, архитектурные решения или состав задач, MUST пройти повторную structural validation и MUST NOT само по себе инвалидировать approvals. Исправление Markdown heading, опечатки без изменения нормативного смысла или выравнивания таблицы MAY считаться механическим; изменение формулировки Requirement, добавление или удаление Scenario, изменение выбранного архитектурного решения либо planned Verification задачи MUST NOT считаться механическим.

#### Scenario: После Design изменилось намерение

- **WHEN** владелец меняет scope или ожидаемый эффект Proposal
- **THEN** зависимые Delta Specs, Design и Tasks теряют прежнее подтверждение до повторной согласованной проверки

#### Scenario: Task вводит новое поведение

- **WHEN** implementation checklist требует поведение, которого нет в утверждённых Delta Specs
- **THEN** агент не расширяет scope через Tasks и возвращает change к Delta Specs

#### Scenario: Apply выявляет архитектурное расхождение

- **WHEN** во время реализации обнаружено, что утверждённый Design не позволяет выполнить Specs без другого архитектурного решения
- **THEN** Apply останавливается, Tasks теряет прежнее подтверждение, а change возвращается к Design с наблюдаемым основанием и вариантами решения

#### Scenario: Исправляется только структурный формат

- **WHEN** утверждённый artifact содержит исправимую синтаксическую или formatting-ошибку без изменения его смысла
- **THEN** workflow исправляет ошибку, повторяет structural validation и сохраняет действующие approvals

#### Scenario: Меняется planned Verification

- **WHEN** исправление Tasks меняет способ, которым должна подтверждаться поставка
- **THEN** workflow рассматривает изменение как semantic task-scope change и повторно запрашивает approval Tasks

### Requirement: Канонический authority OpenSpec задан явно
WealthLedger SHALL использовать зарегистрированный store `wealth-ledger-specs` с физическим OpenSpec root `specs/openspec` как единственный поддерживаемый authority для versioned SDD artifacts. Каждый project-owned OpenSpec entrypoint и documented OpenSpec command MUST явно выбирать `--store wealth-ledger-specs`; он MUST NOT выбирать store из ближайшего root, текущей директории или глобального значения по умолчанию машины.

#### Scenario: Агент начинает SDD-работу из репозитория приложения
- **WHEN** агент начинает, продолжает, проверяет, синхронизирует или архивирует OpenSpec change из `frontend`, `backend`, `docs` или workspace root
- **THEN** documented workflow явно выбирает `wealth-ledger-specs` и разрешает artifacts под `specs/openspec`

#### Scenario: В окружении есть другой OpenSpec store или значение по умолчанию
- **WHEN** машина имеет другой зарегистрированный OpenSpec store или другое глобальное значение по умолчанию
- **THEN** project-owned entrypoints всё равно используют `wealth-ledger-specs` и не выполняют fallback к другому root

### Requirement: Versioned planning artifacts имеют единственное допустимое расположение
Система SHALL хранить committed OpenSpec specifications, changes, designs, delta specifications, tasks и archives только под `specs/openspec`. Она MUST NOT создавать или коммитить framework-specific planning, specification, task или design artifacts вне этого расположения, включая `superpowers/plans`. Это ограничение MUST NOT изменять или удалять read-only material под `references/**`.

#### Scenario: Агент фиксирует функциональное изменение
- **WHEN** агенту нужно зафиксировать requirements, design decisions или implementation tasks для функционального change
- **THEN** он создаёт versioned SDD artifacts в canonical OpenSpec store и не создаёт parallel framework artifact вне него

#### Scenario: Агент изучает reference material
- **WHEN** агент встречает framework artifacts под `references/**`
- **THEN** он рассматривает их как read-only reference content и не классифицирует их как нарушение policy

### Requirement: Authority policy имеет read-only verifier
Canonical store и policy расположения artifacts SHALL иметь documented read-only verifier. Verifier MUST возвращать ненулевой результат, когда project-owned OpenSpec entrypoint не выбирает canonical store, когда запрещённый project-owned planning artifact существует вне `specs/openspec`, или когда существует дополнительный project-owned `openspec/` root; он MUST исключать `references/**` из проверок расположения artifacts.

#### Scenario: Canonical authority остаётся целостным
- **WHEN** verifier запускается в compliant workspace
- **THEN** он завершается без изменения tracked files и сообщает об успехе

#### Scenario: Entry point вновь допускает неявный выбор store
- **WHEN** project-owned OpenSpec entrypoint допускает выбор nearest-root или global-default
- **THEN** verifier завершается ошибкой и указывает non-compliant entrypoint

### Requirement: OpenSpec tooling имеет проверяемый version contract

SDD workflow MUST объявлять одну текущую поддерживаемую версию OpenSpec CLI в canonical version contract и проверять фактическую версию до команд, читающих или изменяющих canonical change. Normative checks и проверяемые generated markers MUST получать ожидаемую версию из этого контракта и MUST NOT независимо закреплять конкретный version literal. Несовместимая либо неопределённая версия MUST давать actionable blocking result и MUST NOT приводить к молчаливому изменению artifact graph, templates или project-owned entrypoints. Публикация новой stable версии MUST NOT автоматически менять поддерживаемую версию проекта. Upgrade SHALL изменять version contract только после изолированной проверки совместимости schema, agent workflow, canonical store и hard blockers и SHALL сохранять историческое evidence с фактически использованными ранее версиями.

#### Scenario: Версия CLI соответствует контракту

- **WHEN** агент начинает работу с canonical change поддерживаемой версией OpenSpec
- **THEN** workflow продолжает работу с объявленной схемой и canonical store

#### Scenario: Версия CLI не соответствует контракту

- **WHEN** доступная версия OpenSpec не совпадает с объявленным совместимым контрактом
- **THEN** локальная preflight-проверка блокирует SDD-операцию и сообщает ожидаемую и фактическую версии

#### Scenario: Опубликована новая stable версия

- **WHEN** upstream публикует новую stable версию, которая ещё не прошла project compatibility assessment
- **THEN** текущий version contract остаётся действующим и новая версия не становится неявным требованием для разработки

#### Scenario: Подготовлен upgrade candidate

- **WHEN** Engineering Owner рассматривает смену поддерживаемой версии
- **THEN** изолированная проверка подтверждает schema, agent workflow, store selection и hard blockers до изменения version contract

### Requirement: Structural и semantic verification являются разными gates

OpenSpec structural validation SHALL проверять schema, artifact graph и формальную корректность specs, но MUST NOT считаться доказательством соответствия реализации. До terminal status change MUST пройти semantic verification реализации против Proposal, Delta Specs, Design и Tasks, а затем независимый read-only review. Если основной agent entrypoint semantic verification недоступен, workflow SHALL использовать versioned эквивалентную процедуру с теми же входными артефактами, категориями проверки и наблюдаемым evidence.

#### Scenario: Structural validation прошла без ошибок

- **WHEN** все planning artifacts формально валидны, но реализация ещё не сопоставлена с ними
- **THEN** change не получает terminal status только на основании structural validation

#### Scenario: Slash workflow недоступен агенту

- **WHEN** среда не предоставляет установленный semantic verification entrypoint
- **THEN** агент выполняет документированную эквивалентную read-only проверку и сохраняет её результат вместо пропуска gate

### Requirement: Archive блокируется незавершёнными tasks
Project-owned archive workflow MUST отклонять archive, если отсутствует требуемый planning artifact, любой обязательный artifact не утверждён, `tasks.md` отсутствует или содержит unchecked task, semantic verification либо независимый read-only review не завершены успешно, или любая affected delivery area не реализована и не прошла обязательные pre-archive gates. Workflow MUST NOT предлагать confirmation override для этих blocking conditions. Post-archive bookkeeping MUST NOT появляться как unchecked task; он SHALL фиксироваться через детерминированное Completion Evidence после успешного archive, после чего связанная delivery может получить terminal status.

#### Scenario: Change имеет unchecked task
- **WHEN** implementer запрашивает archive и остаётся хотя бы один unchecked task
- **THEN** workflow не архивирует change и сообщает incomplete tasks как blocking condition без возможности confirmation override

#### Scenario: Change не прошёл required verification
- **WHEN** planning artifacts и tasks завершены, но semantic verification, independent review, implementation или pre-archive gate affected area отсутствуют либо неуспешны
- **THEN** workflow не архивирует change и перечисляет недостающие blocking conditions

#### Scenario: Change завершил все tasks
- **WHEN** каждый planning artifact утверждён, каждый task отмечен, required verification, implementation и pre-archive gates всех affected areas успешно завершены
- **THEN** workflow допускает archive и фиксирует его результат через определённый completion-evidence path без создания post-archive task

### Requirement: Planning artifact проверяется до запроса approval

Каждый создаваемый planning artifact SHALL пройти все применимые на его текущем этапе non-mutating structural checks до запроса approval Change Owner. Если полный change validation ещё заблокирован отсутствующими downstream artifacts, workflow MUST выполнить доступные проверки текущего artifact и явно оставить недоступную проверку незавершённой, а не заявлять общий успех. Planning verifier MUST выдавать различимые результаты для нарушения artifact validation, некорректного invocation и environment failure. Только диагностированная техническая ошибка проверяемого artifact SHALL исправляться в artifact и проверяться повторно без передачи ручного исправления Change Owner; invocation или environment failure MUST NOT приводить к изменению planning artifact. Structural success MUST NOT подменять semantic approval.

#### Scenario: Текущий artifact имеет проверяемое нарушение

- **WHEN** сгенерированный planning artifact нарушает обязательный формат или ссылочную целостность, доступные для проверки на текущем этапе
- **THEN** workflow сообщает artifact validation failure, исправляет указанное нарушение и повторяет structural checks до запроса owner approval

#### Scenario: Verifier вызван некорректно

- **WHEN** planning verifier получает отсутствующий или недопустимый input
- **THEN** он сообщает invocation failure, а агент исправляет вызов без изменения planning artifact

#### Scenario: Проверка блокируется окружением

- **WHEN** verifier не может выполнить проверку из-за отсутствующего runtime, command или иного environment prerequisite
- **THEN** он сообщает environment failure, агент сохраняет planning artifact неизменным и диагностирует prerequisite либо передаёт точную блокирующую ошибку Change Owner

#### Scenario: Downstream artifacts ещё отсутствуют

- **WHEN** Proposal создан, а Delta Specs, Design и Tasks ещё не существуют
- **THEN** workflow сообщает результат доступных Proposal checks и не представляет отсутствующую full-change validation как успешную

### Requirement: Project schema сохраняет заметные самодостаточные правила

Project schema SHALL показывать обязательные правила текущей стадии до
поддерживающих пояснений и SHALL сохранять нормативную семантику artifact graph,
artifact boundaries и feedback routing внутри schema. Она MUST NOT зависеть от
global agent prompt или параллельного файла правил для корректного выполнения
workflow. Поясняющий текст SHALL использовать основной язык project artifacts,
сохраняя exact OpenSpec headings, tokens, commands и normative keywords без
перевода. Сокращение или перегруппировка instructions MUST NOT удалять
действующий lifecycle invariant.

#### Scenario: Агент получает instruction текущего artifact

- **WHEN** OpenSpec возвращает agent instruction для разрешённой стадии
- **THEN** обязательные правила этой стадии доступны до подробностей и достаточны без внешнего prompt с дублирующей policy

#### Scenario: Instructions сокращаются

- **WHEN** повторяющийся или поясняющий текст удаляется либо переносится внутри project schema
- **THEN** каждый ранее действующий artifact boundary, approval gate и feedback route остаётся представлен ровно одним authoritative правилом

### Requirement: Delta Spec template не предрешает операцию

Исходная форма Delta Spec SHALL быть применима к `ADDED`, `MODIFIED`, `REMOVED`
и `RENAMED` requirements и MUST NOT создавать активный пустой раздел или
предварительно выбирать одну delta operation. Она SHALL сообщать допустимые
формы operations и отдельное правило `Purpose` для новой capability, не
заставляя существующую capability начинать с `ADDED Requirements`.

#### Scenario: Изменяется существующий requirement

- **WHEN** агент получает исходную форму Delta Spec для существующей capability
- **THEN** форма позволяет выбрать `MODIFIED Requirements` без удаления заранее созданного активного `ADDED Requirements`

#### Scenario: Delta использует одну операцию

- **WHEN** change требует только одну из поддерживаемых delta operations
- **THEN** сохранённый artifact содержит только применимую operation и не содержит пустых sections остальных видов

### Requirement: Apply читает только разрешённый planning context

Apply SHALL прочитать каждый artifact path из `contextFiles`, возвращённых
OpenSpec для текущего change, а затем применимые локальные routing instructions
каждой affected delivery area. Агент MUST NOT вычислять planning context paths
самостоятельно или требовать отдельный project context mapping, дублирующий
CLI-resolved state.

#### Scenario: OpenSpec возвращает contextFiles

- **WHEN** агент начинает Apply утверждённого change
- **THEN** он читает все объявленные CLI paths и локальные instructions affected areas до выполнения pending tasks

#### Scenario: У change нет отдельного context map

- **WHEN** CLI уже разрешил planning artifacts и affected areas имеют локальные routing instructions
- **THEN** Apply использует эти authorities и не блокируется отсутствием второго context mapping artifact

### Requirement: Agent context следует текущей SDD-фазе

Project-owned agent workflow SHALL начинать каждую работу с определения текущей
SDD-фазы и affected delivery areas, а затем SHALL загружать canonical artifacts,
локальные routing instructions и supporting authority, применимые к этой фазе и
этим areas. Переход в новую agent-сессию после утверждения planning artifact
SHALL использовать canonical artifact и явное решение Change Owner как основание
продолжения. Workflow MUST NOT требовать полную историю предыдущей сессии или
отдельный handoff/context artifact, дублирующий OpenSpec authority. Supporting
material, не влияющий на текущую фазу, затронутую область, доменную семантику или
обязательный gate, SHALL загружаться только при появлении наблюдаемой
необходимости.

#### Scenario: Утверждённый artifact передаётся в новую сессию

- **WHEN** Change Owner явно утверждает текущий planning artifact и следующая agent-сессия продолжает change на разрешённой downstream-фазе
- **THEN** workflow восстанавливает работу из canonical change artifacts, owner approval и применимых routing instructions без обязательной передачи полной истории обсуждения или создания второго handoff artifact

#### Scenario: Работа ограничена одной delivery area

- **WHEN** текущая фаза затрагивает одну определённую delivery area и не требует cross-system или доменной оценки
- **THEN** workflow загружает authority и локальные instructions этой area, а нерелевантные architecture, domain и repository materials остаются lazy context

#### Scenario: Supporting material становится необходимым

- **WHEN** во время работы возникает вопрос, влияющий на domain semantics, cross-area architecture, audit disposition или обязательный gate
- **THEN** workflow загружает соответствующий authoritative material до принятия решения и не использует token-efficiency guidance как основание пропустить требуемый контекст

### Requirement: Session handoff сохраняет approval boundary

Разделение agent-сессий SHALL происходить только на наблюдаемой границе, где
завершённый результат представлен canonical artifact, применённым изменением или
verification outcome. Handoff SHALL сохранять change identity, последний явно
утверждённый artifact, текущую фазу, affected areas, unresolved blockers и
следующий разрешённый outcome. Если новая сессия не имеет явного подтверждения
approval, workflow MUST повторно запросить решение Change Owner и MUST NOT
выводить approval только из наличия artifact.

#### Scenario: Planning-фаза завершилась approval

- **WHEN** Change Owner утвердил Proposal, Delta Specs или Design и работа продолжается в новой сессии
- **THEN** handoff указывает change identity, утверждённую границу и единственный следующий разрешённый artifact, не перенося нерелевантную историю инструментов и обсуждений

#### Scenario: Approval невозможно подтвердить

- **WHEN** canonical artifact существует, но доступный контекст новой сессии не содержит явного решения Change Owner
- **THEN** workflow останавливается перед downstream artifact и повторно запрашивает approval

#### Scenario: Реализация переходит к независимой проверке

- **WHEN** Apply завершил заявленную работу и change передаётся в свежий verification/review context
- **THEN** handoff сохраняет approved artifacts, affected areas, фактический implementation scope и unresolved blockers, а reviewer получает необходимый diff и evidence без полной implementation history

### Requirement: UI/UX-проработка Design соразмерна изменению

Design SHALL явно определять применимость UI/UX: новый или существенно
изменённый интерфейс, переиспользование согласованного решения либо N/A с
конкретной причиной отсутствия влияния на интерфейс. Для применимого scope
Design SHALL давать Change Owner однозначное представление ожидаемого результата:
затронутые экраны, применимые состояния, взаимодействия и адаптивное поведение.
Ссылки на переиспользуемое решение SHALL указывать, какая его часть применима
к change и какие различия остаются. Неизменяемые части интерфейса и N/A MUST NOT
требовать формальных новых макетов.

#### Scenario: Change существенно меняет интерфейс

- **WHEN** Design описывает новый или существенно изменённый пользовательский
  интерфейс
- **THEN** владелец может оценить затронутые экраны, применимые состояния,
  взаимодействия и поведение при изменении доступного пространства до реализации

#### Scenario: Используется согласованное решение

- **WHEN** change переиспользует ранее согласованное UI/UX-решение
- **THEN** Design однозначно указывает применимое решение, область
  переиспользования и различия без обязательного повторного рисования

#### Scenario: Change не влияет на интерфейс

- **WHEN** UI/UX неприменим по конкретной причине, приведённой в Design
- **THEN** пакет Design допускается без формального макета и дополнительных
  UI/UX approvals

### Requirement: Визуальный пакет Design имеет однозначную сохраняемую версию

Canonical Design SHALL однозначно определять состав и версию своих применимых
визуальных материалов. Материалы SHALL оставаться доступны Change Owner,
исполнителю и независимому reviewer при передаче между изолированными сессиями
и после archive, без зависимости от временного контекста предыдущей сессии.
Ссылка, содержимое которой может молча измениться, MUST NOT быть единственным
свидетельством согласованной версии. Визуальные материалы MUST NOT создавать
конкурирующий versioned planning root вне canonical OpenSpec authority.

#### Scenario: Design передаётся другому исполнителю

- **WHEN** новая изолированная сессия получает canonical Design
- **THEN** она может однозначно найти полный применимый визуальный пакет и
  определить именно ту версию, на которую распространяется approval

#### Scenario: Визуальный источник изменился или недоступен

- **WHEN** текущий внешний или временный источник отличается от согласованной
  версии либо перестал открываться
- **THEN** согласованная версия остаётся доступна из сохраняемого пакета Design
  и не заменяется молча новым содержимым

#### Scenario: Change архивирован

- **WHEN** участник обращается к Design после archive
- **THEN** применимые визуальные материалы согласованной версии доступны вместе
  с архивным Design и сохраняют однозначную связь с ним

### Requirement: Соответствие визуальному Design входит в semantic verification

Реализация SHALL следовать утверждённому Design, включая его применимые
визуальные материалы. Semantic verification и независимый read-only review
SHALL сопоставлять реализованные экраны, состояния, взаимодействия и адаптивное
поведение с этим пакетом в границах change. Наличие каталога или макета MUST NOT
считаться approval или доказательством соответствия реализации. Несоответствие
реализации SHALL направляться на исправление реализации; необходимость
существенно изменить согласованный результат SHALL возвращать работу к самой
ранней затронутой planning boundary с действующими cascade approval rules.

#### Scenario: Реализация расходится с согласованным интерфейсом

- **WHEN** реализация не соответствует однозначному применимому решению Design
- **THEN** проверка сообщает наблюдаемое несоответствие для исправления
  реализации и не объявляет соответствие только из-за наличия макета или каталога

#### Scenario: Согласованное решение требует пересмотра

- **WHEN** выполнить UI/UX-решение без существенного изменения утверждённого
  результата невозможно либо planning artifacts противоречат друг другу
- **THEN** workflow возвращает работу к самой ранней затронутой planning
  boundary, применяет cascade approval rules и не подгоняет Design под реализацию

### Requirement: Внедрение UI/UX workflow сохраняет действующие approval boundaries

Planning `integrate-ui-ux-design-workflow` MAY продолжаться до завершения
`optimize-session-oriented-sdd-v2`, но внедрение процессной части MUST ожидать его
завершения. Перед Design этого change workflow SHALL повторно сверить действующую
canonical authority и определить применимость обновлённого процесса к активным
changes. Обновление MUST NOT автоматически переутверждать их artifacts или
переписывать historical archives.

#### Scenario: Предшествующий процессный change ещё не завершён

- **WHEN** `optimize-session-oriented-sdd-v2` остаётся незавершённым
- **THEN** planning текущего change допускается в рамках явных approvals,
  а внедрение его процессной части остаётся недоступным

#### Scenario: Начинается Design интеграции

- **WHEN** Delta Specs этого change явно утверждены и начинается Design
- **THEN** Design опирается на повторно сверенную текущую canonical authority
  и явно определяет применимость процесса к активным changes

#### Scenario: Обновлённый процесс поставляется

- **WHEN** процессные изменения становятся доступными участникам
- **THEN** прежние approvals активных changes не считаются автоматически
  обновлёнными, а historical archives сохраняются без переписывания

### Requirement: Готовность к пилоту отделена от доказанной успешности workflow

Поставка каталога и обновлённого процесса SHALL позволять использовать их
совместно в последующем небольшом UI change с собственными planning approvals.
Текущий change MUST NOT включать неявную продуктовую фичу в качестве пилота или
заявлять успешность сквозного workflow до его фактического прохождения.

#### Scenario: Текущая поставка завершена

- **WHEN** каталог и обновлённый процесс готовы к совместному использованию,
  но последующий UI change ещё не прошёл workflow
- **THEN** результат описывается как готовность к пилоту без заявления об
  успешном сквозном пилоте

#### Scenario: Начинается пилотный UI change

- **WHEN** владелец выбирает небольшой UI change для совместного использования
  каталога и процесса
- **THEN** этот change проходит собственные planning approvals, а вывод о
  сквозной успешности опирается только на его фактически наблюдаемый результат