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

openspec-authority-and-lifecycle Specification

Purpose

Определяет единственный источник полномочий для OpenSpec и проверяемый жизненный цикл SDD-изменений независимо от текущей директории, глобальной конфигурации или agent framework. Применяется только к работе, которую Change Owner явно начал как OpenSpec/SDD; обычная разработка идёт по задаче без planning artifacts.

Requirements

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

Proposal SHALL выражать причину, намерение, границы и ожидаемый эффект change языком владельца и MUST NOT содержать решения по технологиям, структуре кода, файлам, API или зависимостям. Delta Specs SHALL определять только добавленное, изменённое или удалённое наблюдаемое поведение и инварианты системы без описания изменений кода. В wealth-ledger-sdd-v2 System Analysis SHALL определять межсистемные потоки, contracts и semantics до Design; Design SHALL объяснять внутреннюю реализацию approved behavior/contracts, риски и альтернативы, не становясь построчной инструкцией. QA Analysis SHALL определять независимую system verification, не предписывая разработчикам internal tests. Docs Impact SHALL планировать только durable AS-IS knowledge для docs/. Применимые UI/UX-решения и визуальные материалы SHALL входить в единый canonical Design и MUST NOT образовывать отдельный planning authority или отдельный UI/UX approval. Tasks SHALL быть implementation checklist из утверждённых upstream artifacts и 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 upstream artifacts выбранной schema утверждены
• 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

Каждый change SHALL следовать schema из своего .openspec.yaml: существующие active wealth-ledger-sdd сохраняют Proposal → Delta Specs → Design → Tasks → Apply, а новые wealth-ledger-sdd-v2 используют Proposal → Delta Specs → System Analysis → (Design + QA Analysis) → Docs Impact → Tasks → Apply. В v2 Design и QA Analysis MAY подготавливаться параллельно после approval System Analysis; Docs Impact требует approvals обоих. skip_specs: true явно обозначает отсутствие behavior delta, а не фиктивный spec. AI-агент MAY подготовить черновик текущего разрешённого артефакта, но MUST NOT считать его утверждённым самостоятельно или создавать downstream artifact до явного решения Change Owner. Для change, определяющего продуктовое поведение, Change Owner SHALL быть Product Owner; для технического или процессного change — Engineering Owner. Каждый применимый planning artifact выбранной schema MUST существовать и быть явно утверждён до Apply; существующие approvals legacy changes MUST NOT инвалидироваться только из-за смены default schema.

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

• WHEN AI-агент завершил черновик Proposal, но Change Owner не дал явного согласия
• THEN downstream artifacts выбранной schema остаются недоступны для создания

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

• WHEN Change Owner явно подтверждает Delta Specs после утверждённого Proposal
• THEN для legacy разрешён Design, для v2 — System Analysis; Tasks и Apply остаются заблокированы

Scenario: Active change переживает смену default schema

• WHEN active change закреплён за wealth-ledger-sdd и default меняется на wealth-ledger-sdd-v2
• THEN он сохраняет прежний artifact graph и approvals без создания фиктивных v2 artifacts

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

Семантическое изменение утверждённого artifact MUST возвращаться к самой ранней затронутой planning boundary и инициировать повторную проверку и approval только её зависимых downstream artifacts согласно выбранной schema. Для legacy Proposal → Delta Specs → Design → Tasks; для v2 intent/scope → Proposal, observable behavior → Specs, systems/sequences/contracts/mappings/inter-system errors/semantic observability → System Analysis, internal implementation/storage/technical observability/developer tests → Design, system verification/test data/automation → QA Analysis, durable AS-IS/ADR → Docs Impact, decomposition/ownership/dependencies → Tasks. Изменение Tasks MUST NOT неявно менять upstream semantics. Если несоответствие обнаружено во время Design или Apply, downstream-работа MUST остановиться, а Change Owner MUST получить наблюдаемое основание возврата. Механическое исправление синтаксиса или формата без изменения смысла MUST пройти повторную structural validation и MUST NOT само по себе инвалидировать approvals. Исправление Markdown heading, опечатки без изменения нормативного смысла или выравнивания таблицы MAY считаться механическим; изменение Requirement/Scenario, contract, sequence, архитектурного решения, QA expected result, docs target либо planned Verification задачи MUST NOT считаться механическим.

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

• WHEN владелец меняет scope или ожидаемый эффект Proposal
• THEN зависимые artifacts выбранной schema теряют прежнее подтверждение до повторной согласованной проверки

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

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

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

• WHEN во время реализации обнаружено, что утверждённый Design не позволяет выполнить Specs без другого архитектурного решения
• THEN Apply останавливается, затронутые downstream approvals теряют силу, а 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 проверяется по совместимости

SDD workflow MUST проверять доступный OpenSpec CLI на совместимость с выбранной schema и canonical store без закрепления одной версии CLI. Перед изменением workflow или обновлением CLI SHALL выполняться native validation обеих project-local schemas, затронутых changes и canonical specs; artifact graph, agent workflow, store selection и blocking gates MUST сохранять согласованную семантику. Несовместимый CLI MUST давать actionable blocking result и MUST NOT приводить к молчаливому изменению artifacts или project-owned entrypoints. Фактически использованная версия CLI SHALL сохраняться в observed verification evidence, а не в отдельном version contract.

Scenario: Доступный CLI совместим

• WHEN проверки выбранной schema и canonical store проходят на установленном OpenSpec CLI
• THEN workflow продолжает работу без требования совпадения с закреплённым номером версии

Scenario: CLI нарушает совместимость

• WHEN после обновления CLI schema validation, разрешение store или blocking gates перестают работать
• THEN зависимая SDD-операция останавливается с диагностикой нарушения до исправления несовместимости

Scenario: CLI обновлён

• WHEN Engineering Owner обновляет OpenSpec CLI
• THEN проверяются обе project-local schemas, затронутые changes, canonical specs и workflow, а фактическая версия и результаты сохраняются в verification evidence

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

OpenSpec structural validation SHALL проверять schema, artifact graph и формальную корректность specs, но MUST NOT считаться доказательством соответствия реализации или approval. До terminal status change MUST пройти semantic verification реализации против применимых approved artifacts выбранной schema, включая v2 System Analysis, QA Analysis и Docs Impact, а затем независимый 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, если отсутствует требуемый выбранной schema planning artifact, любой обязательный artifact не утверждён, tasks.md отсутствует или содержит unchecked task, semantic verification либо независимый read-only review не завершены успешно, или любая affected delivery area не реализована и не прошла обязательные pre-archive gates. Для v2 также MUST быть подтверждены developer checks, независимая QA/system verification, semantic compatibility backend-generated OpenAPI/runtime interface с approved target contract при изменении API и применение Docs Impact так, чтобы canonical docs/ отражали resulting AS-IS. Native OpenSpec sync/archive SHALL обновлять canonical behavior specs, не переписывая их implementation details; System Analysis и target contracts остаются в архивном change, а не становятся второй вечной копией current OpenAPI. 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 создан, а downstream artifacts выбранной schema ещё не существуют
• 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, а вывод о сквозной успешности опирается только на его фактически наблюдаемый результат