feat: harden OpenSpec SDD workflow

2026-08-26 00:42:35 +03:00
parent 039b72eed3
commit a8b2c4eed9
42 changed files with 4024 additions and 181 deletions
@@ -0,0 +1,7 @@
+schema: wealth-ledger-sdd
+created: 2026-08-25
+goal: Make WealthLedger SDD changes reliably traceable, reproducible, and
+  maintainable across future OpenSpec upgrades.
+affected_areas:
+  - specs
+  - docs
@@ -0,0 +1,276 @@
+## Context
+
+WealthLedger использует project-local OpenSpec schema поверх CLI 1.10.0,
+canonical store в отдельном specs-репозитории и project-owned OpenCode
+entrypoints в unversioned workspace root. Schema уже задаёт последовательный
+artifact graph, а repository scripts защищают store authority, Delivery Map и
+terminal verification. Однако planning quality до Apply проверяется
+неравномерно, Tasks не имеют машиночитаемой связи с requirements и delivery
+areas, а root agent projection проверяется только как локально существующее
+состояние и не восстанавливается из четырёх Git-репозиториев.
+
+Custom schema API остаётся experimental, поэтому совместимость нельзя безопасно
+выводить только из SemVer. Root workspace не является Git-репозиторием;
+versioned authority для новых guardrails и projection recovery должен
+принадлежать `specs`, а as-built policy, audit snapshots и dispositions —
+`docs`. Других active OpenSpec changes нет. Этот change создан по schema version
+1, поэтому его собственные Tasks должны вручную соответствовать утверждённому
+v2 contract до того, как Apply сделает этот contract default для будущих
+changes.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- сделать planning structure, task ownership и requirement coverage
+  детерминированно проверяемыми до Apply;
+- восстановить project-owned agent workflow из versioned inputs и обнаруживать
+  drift derived projection;
+- сохранить один exact supported CLI contract, пригодный для контролируемого
+  будущего upgrade;
+- распределить guidance между schema, config, durable policy и verifiers без
+  конкурирующих источников;
+- сохранить все source assessments и нормализовать их claims с доказательными
+  dispositions;
+- сохранить пропорциональность workflow и существующие human approval gates.
+
+**Non-Goals:**
+
+- обновление OpenSpec CLI в этом change;
+- изменение frontend, backend, runtime API или deployment behavior;
+- универсальная схема для других проектов, Fast Track или второй lifecycle;
+- собственный workflow engine, identity/signature system для approvals или
+  общий dependency scheduler для changes;
+- автоматическое доказательство смысловой полноты Proposal, Specs или Design;
+- новые review, completion, blocker, revision либо traceability artifacts.
+
+## Decisions
+
+### 1. Native schema v2 остаётся workflow engine
+
+`wealth-ledger-sdd` повышается до version 2, сохраняя граф
+`Proposal → Delta Specs → Design → Tasks → Apply`. Изменяется contract
+существующих artifacts, а не их число. Schema и templates задают обязательную
+форму Tasks, условный rollback contract, stage validation guidance, полный
+feedback path и компактные примеры сложных delta operations. Minimal spec
+template остаётся ориентированным на `ADDED`; неиспользуемые delta sections не
+генерируются как пустые placeholders.
+
+Artifact approval остаётся человеческим фактом разговора. File existence и
+CLI status продолжают означать только structural state. Форматное исправление,
+не меняющее approved semantics, повторяет structural checks без каскадного
+reapproval; любое изменение intent, behavior, architecture или task scope
+возвращает workflow к самому раннему затронутому artifact и инвалидирует его
+downstream approvals.
+
+### 2. Guidance имеет явных владельцев
+
+Ответственность разделяется так:
+
+| Surface | Authority |
+| --- | --- |
+| schema instructions | artifact semantics, native syntax и workflow behavior |
+| templates | только форма создаваемого Markdown |
+| config context | стабильные факты workspace и язык project artifacts |
+| config rules | только краткие additive project constraints, отсутствующие в schema |
+| governance и ADR | durable rationale, ownership и upgrade policy |
+| non-mutating verifiers | Enforceable Engineering Invariants |
+
+Текущие config rules, дословно повторяющие schema, удаляются или сокращаются;
+произвольный `_rules.md` не вводится. Project explanations пишутся по-русски,
+а OpenSpec tokens, headings, commands и normative keywords сохраняются в их
+точной английской форме.
+
+### 3. Planning verifier отделён от full delivery dispatcher
+
+`specs` получает один stage-aware non-mutating planning verifier. Он разрешает
+change через canonical store и применяет только доступные на текущем этапе
+checks:
+
+- Proposal — metadata, обязательную структуру и разрешимость declared existing
+  capability paths;
+- Delta Specs — strict change validation и соответствие capability set
+  Proposal;
+- Design — Delivery Map, Contract Gate Decision и rollback decision;
+- Tasks — checkbox shape, area ownership, canonical gate coverage и точные
+  requirement references, включая explicit `N/A` rationale.
+
+Verifier не пытается машинно оценивать качество мотивации, архитектурного
+rationale или semantic correctness. Full workspace dispatcher вызывает его
+перед affected-area gates, а artifact entrypoints запускают доступный stage до
+запроса approval. Проверяемая логика получает compliant fixtures и
+representative failures для uncovered requirement, invalid area, malformed
+rollback decision и projection/version drift. Существующие parsers Delivery Map
+переиспользуются либо извлекаются, а не дублируются вторым несовместимым
+разбором.
+
+### 4. Tasks используют area owner и встроенную coverage metadata
+
+Каждый checkbox использует формат `X.Y [area] action`, где `area` — ровно одна
+из `frontend`, `backend`, `specs`, `docs`, `workspace`. Следующие indented
+metadata lines содержат:
+
+- `Covers`: одна или несколько пар `capability path — exact Requirement
+  heading` либо `N/A — concrete reason`;
+- `Verification`: planned command, observable check или delivered artifact.
+
+OpenSpec продолжает отслеживать progress по checkbox line, а planning verifier
+связывает последующие metadata lines с ближайшим checkbox. Cross-repository
+implementation разбивается по repository owners; `workspace` используется
+только для orchestration и verification. Requirement heading остаётся native
+identity OpenSpec; дополнительный ID namespace не создаётся.
+
+### 5. Root agent projection получает versioned canonical source
+
+Текущие project-owned `commands` и `skills` импортируются как canonical source
+tree под `specs/agent-projection/opencode`. Package manifests, installed
+dependencies и machine-local runtime state не входят в source. Явная sync
+команда атомарно обновляет соответствующие каталоги root `.opencode`, а
+отдельный non-mutating verifier сравнивает required file set и contents с
+canonical source.
+
+На upgrade новая upstream projection сначала создаётся в isolated staging.
+Upstream delta и минимальные WealthLedger overlays — fixed store,
+one-artifact-at-a-time approvals, feedback path и hard archive blockers —
+переносятся в canonical source, после чего sync обновляет root derived output.
+Authority verifier получает expected version из единственного version contract
+и проверяет совпадение каждого required generated marker. Concrete CLI version
+не закрепляется в verifier logic или fixtures независимо от contract.
+
+Canonical source tree выбран вместо:
+
+- patch set: меньше committed content, но patches хрупки к upstream text churn;
+- custom generator: устраняет дублирование, но создаёт новый transformation
+  engine и повышает maintenance cost;
+- symlink: устраняет copy drift, но связывает agent discovery с filesystem и
+  tool-specific symlink behavior;
+- manual staging only: сохраняет текущую простоту, но не обеспечивает recovery
+  из clean checkouts.
+
+### 6. Rollback contract является условной частью Design
+
+Design template получает внутри Migration Plan структурированный rollback
+decision. Для auth/security, data integrity или migration, public contract и
+других труднообратимых решений status `required` раскрывает trigger, actions,
+data safety и verification. Для остальных changes status `N/A` требует
+конкретной причины. Отдельный rollback artifact не создаётся.
+
+У этого change rollback contract имеет status `N/A`: application data,
+security behavior и public contracts не меняются, а committed specs/docs
+обратимы через Git. Initial projection cutover выполняется атомарно и сохраняет
+предыдущее local derived state до успешного verification, чтобы failed sync не
+оставил частично обновлённый workspace.
+
+### 7. Multi-source assessment хранит raw evidence и отдельный triage
+
+Пять исходных model reports переносятся byte-for-byte в один dated audit
+snapshot set под `docs/audits`; index обозначает их как external, non-authority
+claims и фиксирует checksums. После проверки совпадения исходная unversioned
+папка удаляется, чтобы не оставить competing copy.
+
+Live registry получает нормализованные Audit IDs. Повторяющиеся claims имеют
+одну запись со ссылками на все sources. Triage disposition
+`confirmed | already-covered | rejected | deferred` хранится отдельно от
+remediation status. Confirmed findings этого scope связываются с текущим active
+change; already-covered получают existing evidence; rejected — rationale;
+deferred — review trigger. Следующим planned remediation после завершения этого
+change снова становится ранее выбранная auth platform assessment.
+
+### 8. Version contract фиксирует совместимость, а не вечную версию
+
+Текущая exact version остаётся неизменной. Появление новой stable версии не
+блокирует delivery и не меняет contract автоматически. Future upgrade является
+отдельным SDD change и проходит staged projection comparison, schema/status/
+instructions compatibility, canonical-store checks, disposable lifecycle и
+positive/negative authority fixtures. Historical archives и Completion Evidence
+сохраняют фактические версии своих запусков.
+
+## Delivery Map
+
+| Area | Status | Architectural outcome or N/A reason |
+| --- | --- | --- |
+| frontend | `N/A` | Change не меняет frontend behavior, source, contract или canonical gate. |
+| backend | `N/A` | Change не меняет backend behavior, source, contract или canonical gate. |
+| specs | `affected` | Schema v2, planning/projection guardrails, canonical agent source и нормативные lifecycle requirements образуют единый проверяемый SDD contract. |
+| docs | `affected` | Immutable multi-source audit, dispositions, governance, lifecycle documentation и ADR отражают поставленную SDD-систему. |
+
+### Contract Gate Decision
+
+| Gate | Status | Reason |
+| --- | --- | --- |
+| runtime-openapi | `N/A` | Change не затрагивает backend runtime API, frontend generated client или committed OpenAPI snapshot. |
+
+## Solution Assessment
+
+Change существенно меняет общую project tooling infrastructure, поэтому
+сравнение alternatives обязательно.
+
+### Workflow enforcement
+
+| Option | Fit и maturity | Security / operating cost | Constraints / migration cost | Decision |
+| --- | --- | --- | --- | --- |
+| Native OpenSpec schema/config + thin project verifiers | Полностью сохраняет canonical artifact graph; используемые extension points уже работают в 1.10, хотя schema API experimental | Local-only, без новых secrets/services; низкая стоимость поверх существующих gates | Требует exact compatibility contract и fixtures при upgrade; incremental migration | Selected |
+| Prompt/docs-only conventions | Markdown mature и дёшев, но не отклоняет нарушения | Низкая стоимость, высокий риск silent drift | Не выполняет требования machine validation и reproducibility | Rejected |
+| Собственный workflow engine | Максимальный theoretical fit, но custom maturity отсутствует | Новый privileged control surface и высокая постоянная стоимость | Дублирует OpenSpec lifecycle, требует migration всех entrypoints и state | Rejected |
+| Общая monorepo/CI platform | Зрелые продукты существуют, но workspace не имеет общего build/dependency graph и CI | Существенная installation и operating cost | Не решает approval semantics или audit traceability сама по себе | Rejected |
+
+### Projection recovery
+
+| Option | Fit и maturity | Operating cost | Main constraint | Decision |
+| --- | --- | --- | --- | --- |
+| Versioned canonical source tree + sync/check | Простая file projection с детерминированным сравнением | Низкая; около 115 KB source Markdown | Source и derived copy должны проверяться на drift | Selected |
+| Versioned overlay patches | Компактно | Средняя/высокая при каждом upstream text change | Patch fragility | Rejected |
+| Programmatic overlay generator | Гибко | Высокая; собственная transformation logic | Риск второго workflow engine | Rejected |
+| Symlink в specs-owned tree | Минимум duplication | Низкая локально | Tool/filesystem portability и смешение machine-local package state | Rejected |
+
+Выбранный вариант не реализует OpenSpec behavior самостоятельно: native CLI
+остаётся engine, а project scripts только синхронизируют derived files и
+проверяют детерминированные инварианты.
+
+## Risks / Trade-offs
+
+- **Canonical source и derived projection дублируют Markdown.** Drift блокирует
+  verifier; изменения вносятся только в source и распространяются explicit
+  sync-командой.
+- **Markdown parser может стать хрупким.** Машиночитаемые prefixes и metadata
+  намеренно узкие, fixture suite покрывает compliant и representative invalid
+  inputs, а semantic review остаётся отдельным gate.
+- **Traceability создаёт ложное ощущение semantic coverage.** Verifier
+  подтверждает наличие ссылок, но semantic verification и independent review
+  продолжают проверять полноту реализации.
+- **Форматное исключение может скрыть semantic edit.** Оно ограничено ошибками,
+  не меняющими intent, behavior, decisions или tasks; сомнение возвращает
+  artifact на обычный reapproval path.
+- **Schema instructions могут разрастись.** Duplicate config rules удаляются,
+  examples остаются короткими, а final instruction size сравнивается с
+  baseline без жёсткого token threshold.
+- **Raw model reports могут выглядеть authoritative.** Snapshot index и registry
+  явно разделяют source claims, triage evidence и project authority.
+- **Initial source-tree bootstrap не имеет прежней versioned baseline.** Sync
+  сохраняет local pre-cutover state до успешного gate; после поставки все
+  дальнейшие projection versions становятся восстановимыми через Git history.
+- **Future OpenSpec release может изменить experimental interfaces.** Exact
+  contract блокирует silent adoption, а отдельный upgrade change выполняет
+  staged compatibility assessment.
+
+## Migration Plan
+
+1. Ввести canonical projection source и non-mutating planning/projection checks,
+   подтвердив compliant и controlled-invalid fixtures до переключения schema.
+2. Обновить schema, templates, config и canonical agent source до v2 contract;
+   собственные Tasks этого change оформить уже в новом формате.
+3. Атомарно синхронизировать root derived projection и отклонить delivery при
+   любом content/version drift.
+4. Перенести raw assessments в immutable indexed snapshot, проверить
+   byte-for-byte equality, удалить unversioned copy и обновить live registry.
+5. Обновить governance, lifecycle docs и ADR до фактической архитектуры, затем
+   выполнить specs/docs gates, semantic verification и independent review.
+
+### Rollback Contract
+
+| Field | Decision |
+| --- | --- |
+| Status | `N/A` |
+| Reason | Change не меняет application data, security behavior или public contracts; committed state обратим через Git, а projection является derived output с atomic cutover. |
+| Failed cutover handling | Sync восстанавливает сохранённое pre-cutover local state и не объявляет source/projection согласованными. |
+| Verification | Planning, projection, authority, strict OpenSpec и docs gates должны снова подтвердить выбранное состояние. |
@@ -0,0 +1,58 @@
+## Why
+
+WealthLedger уже использует строгий SDD lifecycle, но его качество сейчас
+зависит от нескольких разрозненных соглашений и ручной семантической проверки.
+Собранные независимые оценки выявили повторяющиеся риски: требования могут быть
+недостаточно явно связаны с работой по их поставке, ответственность задач в
+multi-repository workspace может читаться неоднозначно, а восстановление и
+эволюция workflow требуют слишком много неявного знания. Эти риски стоит
+устранить до следующих remediation changes, чтобы последующая разработка
+опиралась на воспроизводимый и проверяемый процесс.
+
+## What Changes
+
+- Установить единый проверяемый контракт качества SDD, связывающий изменяемые
+  требования, запланированную delivery-работу и ответственность каждой области.
+- Сделать возврат к upstream artifact, повторное утверждение и риск-обусловленный
+  rollback явными частями lifecycle, не создавая параллельных planning artifacts.
+- Обеспечить воспроизводимость project-owned agent workflow и управляемую
+  совместимость при будущей смене поддерживаемой версии инструмента.
+- Сохранить исходные multi-source audit assessments неизменными и дать каждому
+  нормализованному замечанию проверяемый итог: исправление, подтверждённое
+  существующее покрытие, осознанное отклонение либо отложенный trigger.
+- Разделить устойчивую policy, artifact-specific guidance и автоматические
+  guardrails так, чтобы обязательное правило имело одного владельца и не
+  зависело от необязательного чтения дополнительного контекста.
+
+Не входят в change: изменение поведения приложений или публичных контрактов,
+создание универсального SDD framework для других проектов, отдельный ускоренный
+lifecycle, новая модель identity для owner approval, дополнительные planning
+artifacts и общий механизм зависимостей между changes без наблюдаемой
+потребности.
+
+## Capabilities
+
+### New Capabilities
+
+Нет.
+
+### Modified Capabilities
+
+- `openspec-authority-and-lifecycle`: усилить воспроизводимость workflow,
+  совместимость поддерживаемой версии, проверки planning artifacts и
+  контролируемый возврат к изменённому upstream artifact.
+- `multi-repository-delivery`: сделать ownership задач и покрытие изменяемых
+  требований явными и проверяемыми для каждой delivery area.
+- `engineering-change-governance`: дополнить risk-based planning обязательной
+  rollback discipline для труднообратимых изменений и проверяемыми SDD
+  guardrails.
+- `audit-remediation-workflow`: поддержать неизменяемое multi-source audit
+  evidence и нормализованные dispositions без превращения внешних оценок в
+  authority проекта.
+
+## Impact
+
+Изменение затрагивает Change Owner и AI-агентов, которые создают, утверждают,
+реализуют и проверяют WealthLedger changes. Оно изменяет нормативный SDD
+workflow и его as-built process documentation, но не меняет frontend, backend,
+пользовательское поведение или runtime API contracts.
@@ -0,0 +1,46 @@
+## MODIFIED Requirements
+
+### Requirement: Реестр remediation отделён от снимка аудита
+
+Система SHALL создавать отдельный неизменяемый versioned audit snapshot в `docs/audits` для каждого завершённого аудита и SHALL поддерживать один актуальный durable remediation registry в `docs/development`, охватывающий findings всех audit snapshots. Для завершённого multi-source audit система SHALL сохранять каждый source file byte-for-byte и объединять их одним snapshot index. Каждый snapshot SHALL оставаться source of claims своего аудита и MUST NOT редактироваться для отражения последующей remediation. Внешняя модельная оценка MUST быть обозначена как неавторитетный источник claims и MUST NOT подменять requirements, governance или проверенное состояние проекта. Registry SHALL хранить текущее состояние, связанный canonical change, следующее действие и completion evidence каждой записи, MUST ссылаться на однозначный Audit ID и каждый относящийся source snapshot и MUST NOT дублировать полный текст finding, если он уже содержится в snapshot.
+
+#### Scenario: Агент открывает работу по аудиту в новой сессии
+
+- **WHEN** агент получает задачу устранить или продолжить finding из любого завершённого аудита
+- **THEN** он находит в едином registry исходный snapshot и Audit ID, текущий статус, связанный OpenSpec change, evidence и следующее действие без повторной интерпретации всех аудитов
+
+#### Scenario: Проводится повторный аудит
+
+- **WHEN** новый аудит завершён после предыдущего audit snapshot
+- **THEN** система добавляет новый immutable snapshot и обновляет тот же live registry, не переписывая предыдущий snapshot и не создавая конкурирующий registry
+
+#### Scenario: Обновляется прогресс remediation
+
+- **WHEN** работа по finding меняет статус
+- **THEN** versioned audit snapshots не редактируются, а изменение фиксируется только в live registry с датой и необходимым evidence
+
+#### Scenario: Один аудит содержит несколько внешних оценок
+
+- **WHEN** завершённая assessment использовала несколько независимых source reports
+- **THEN** snapshot index связывает byte-for-byte сохранённые reports в один audit и явно отделяет их claims от project authority
+
+## ADDED Requirements
+
+### Requirement: Каждое audit claim получает доказательный disposition
+
+Каждое уникальное claim завершённого multi-source audit MUST входить ровно в один нормализованный Audit ID и иметь triage disposition `confirmed`, `already-covered`, `rejected` или `deferred`. Нормализованная запись MUST ссылаться на каждый source report, содержащий claim. `confirmed` MUST связываться с remediation status и change либо terminal evidence; `already-covered` MUST приводить проверяемое существующее evidence; `rejected` MUST содержать конкретное rationale; `deferred` MUST содержать review trigger. Triage disposition MUST оставаться отдельным от remediation status `planned`, `active`, `done`, `deferred` или `accepted`, чтобы внешняя рекомендация не становилась принятой policy без проверки.
+
+#### Scenario: Несколько моделей повторяют одно замечание
+
+- **WHEN** два или более source reports описывают один и тот же underlying gap
+- **THEN** registry содержит один нормализованный Audit ID со ссылками на все источники и одним доказательным disposition
+
+#### Scenario: Рекомендация уже реализована
+
+- **WHEN** проверяемое состояние проекта полностью покрывает external claim
+- **THEN** disposition `already-covered` ссылается на существующий requirement, guardrail или completion evidence без создания фиктивной remediation work
+
+#### Scenario: Внешняя рекомендация противоречит authority
+
+- **WHEN** source report предлагает неподдерживаемый либо ухудшающий действующий invariant подход
+- **THEN** disposition `rejected` фиксирует конкретное противоречие и не превращает recommendation в requirement
@@ -0,0 +1,20 @@
+## ADDED Requirements
+
+### Requirement: Труднообратимое изменение имеет rollback contract
+
+Design MUST определять rollback trigger, rollback actions, data safety и rollback verification, когда change затрагивает auth или security behavior, data integrity или migration, public contract либо другое существенно труднообратимое решение. Rollback contract MUST учитывать данные и совместимость, созданные после поставки change, и MUST быть выполним без нового неутверждённого архитектурного решения. Когда указанные риски неприменимы, Design SHALL фиксировать конкретную проверяемую причину `N/A` и MUST NOT создавать отдельный artifact или формальный rollback plan ради процесса.
+
+#### Scenario: Change мигрирует данные
+
+- **WHEN** Design изменяет хранимые данные способом, который может потребовать возврата
+- **THEN** он определяет trigger, безопасные действия отката, судьбу новых данных и проверку восстановленного состояния до утверждения Tasks
+
+#### Scenario: Change меняет публичный контракт
+
+- **WHEN** Design вводит несовместимое изменение публичного контракта
+- **THEN** rollback contract объясняет восстановление совместимости и проверяемое условие успешного отката
+
+#### Scenario: Rollback risk отсутствует
+
+- **WHEN** change не затрагивает auth, security, данные, публичный контракт или другое труднообратимое решение
+- **THEN** Design указывает конкретную причину `N/A` без создания дополнительного rollback artifact
@@ -0,0 +1,39 @@
+## ADDED Requirements
+
+### Requirement: Каждая задача объявляет единственную delivery area
+
+Каждый checkbox Tasks MUST объявлять ровно одного owner из `frontend`, `backend`, `specs`, `docs` или `workspace`. Implementation work, изменяющая несколько Git-репозиториев, MUST быть разделена на repository-owned tasks; `workspace` SHALL использоваться только для cross-area orchestration или verification без владения repository implementation. Для каждой `affected` area Tasks MUST содержать её implementation work и canonical local gate, а task ownership MUST соответствовать утверждённому Delivery Map.
+
+#### Scenario: Change затрагивает frontend и backend
+
+- **WHEN** одна delivery intent требует изменения клиента и API
+- **THEN** Tasks содержит отдельные frontend-owned и backend-owned checkbox items вместо одной общей implementation task
+
+#### Scenario: Выполняется общий verification gate
+
+- **WHEN** задача только оркестрирует проверку нескольких affected areas и не изменяет их implementation
+- **THEN** task использует owner `workspace` и не подменяет repository-owned implementation или canonical gates
+
+#### Scenario: Task ссылается на N/A area
+
+- **WHEN** checkbox объявляет owner области, которая имеет статус `N/A` в Delivery Map
+- **THEN** planning validation завершается ошибкой и указывает несогласованную delivery area
+
+### Requirement: Tasks трассируются к утверждённым требованиям
+
+Каждый checkbox Tasks MUST содержать coverage reference: одну или несколько пар из точного capability path и точного Requirement heading либо `N/A` с конкретной причиной для работы, которая не реализует spec-level behavior. Каждый Requirement из Delta Specs MUST быть покрыт хотя бы одной task. Planning validation MUST отклонять отсутствующее покрытие, ссылку на несуществующий capability или Requirement и пустую причину `N/A`. Traceability SHALL использовать нативную идентичность requirement и MUST NOT вводить параллельный namespace собственных requirement IDs.
+
+#### Scenario: Delta requirement покрыт реализацией
+
+- **WHEN** Tasks планирует поставку изменённого requirement
+- **THEN** хотя бы один checkbox ссылается на точный capability path и Requirement heading этого delta
+
+#### Scenario: Задача не меняет spec-level behavior
+
+- **WHEN** task обновляет infrastructure, documentation или verification без самостоятельного requirement
+- **THEN** coverage reference содержит `N/A` и конкретно объясняет отсутствие spec-level связи
+
+#### Scenario: Requirement остался без задачи
+
+- **WHEN** хотя бы один Requirement из Delta Specs не указан ни в одной coverage reference
+- **THEN** planning validation блокирует approval Tasks и перечисляет uncovered Requirement
@@ -0,0 +1,79 @@
+## MODIFIED Requirements
+
+### 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.
+
+#### 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
+
+### 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 и project-owned projection
+
+## ADDED Requirements
+
+### Requirement: Project-owned agent workflow воспроизводим из versioned authority
+
+Project-owned agent workflow SHALL восстанавливаться в новом workspace из committed authority inputs и текущей поддерживаемой версии инструмента без использования прежнего локального generated state. Workspace-level projection SHALL оставаться derived output и MUST NOT становиться конкурирующим SDD authority. Non-mutating verifier MUST обнаруживать отсутствие required projection, расхождение с versioned inputs и несовместимый generated version marker; установленные зависимости и machine-local runtime state MUST NOT считаться authority inputs.
+
+#### Scenario: Workspace собирается заново
+
+- **WHEN** участник получает чистые checkout всех project repositories и поддерживаемый инструмент
+- **THEN** documented workflow воспроизводит project-owned agent projection из versioned inputs без копирования файлов с прежней машины
+
+#### Scenario: Derived projection изменена вручную
+
+- **WHEN** локальная project-owned projection больше не соответствует versioned authority inputs
+- **THEN** non-mutating verifier завершает проверку ошибкой и указывает на projection drift
+
+### Requirement: Planning artifact проверяется до запроса approval
+
+Каждый создаваемый planning artifact SHALL пройти все применимые на его текущем этапе non-mutating structural checks до запроса approval Change Owner. Если полный change validation ещё заблокирован отсутствующими downstream artifacts, workflow MUST выполнить доступные проверки текущего artifact и явно оставить недоступную проверку незавершённой, а не заявлять общий успех. Техническая ошибка проверяемого формата SHALL исправляться и проверяться повторно без передачи ручного исправления Change Owner; structural success MUST NOT подменять semantic approval.
+
+#### Scenario: Текущий artifact имеет проверяемое нарушение
+
+- **WHEN** сгенерированный planning artifact нарушает обязательный формат или ссылочную целостность, доступные для проверки на текущем этапе
+- **THEN** workflow исправляет нарушение и повторяет structural checks до запроса owner approval
+
+#### Scenario: Downstream artifacts ещё отсутствуют
+
+- **WHEN** Proposal создан, а Delta Specs, Design и Tasks ещё не существуют
+- **THEN** workflow сообщает результат доступных Proposal checks и не представляет отсутствующую full-change validation как успешную
@@ -0,0 +1,65 @@
+## 1. Planning guardrails
+
+- [x] 1.1 [specs] Реализовать выбранный в Solution Assessment вариант native OpenSpec + thin project verifiers: извлечь или переиспользовать существующий разбор Delivery Map и добавить stage-aware `verify-openspec-planning.sh` без собственного workflow state
+  - **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
+  - **Verification:** Запустить verifier последовательно на fixtures стадий Proposal, Delta Specs, Design и Tasks и подтвердить, что он применяет только доступные на каждой стадии checks.
+- [x] 1.2 [specs] Добавить positive и controlled-negative fixtures для proposal structure и capability set, malformed rollback decision, invalid или `N/A` delivery area, отсутствующей task metadata, неверной requirement reference и uncovered Requirement
+  - **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`; `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`; `engineering-change-governance` — `Труднообратимое изменение имеет rollback contract`
+  - **Verification:** Запустить fixture suite и проверить успешный compliant case, ожидаемые non-zero exits и actionable сообщения для каждого representative failure.
+- [x] 1.3 [specs] Подключить planning verifier к workspace dispatcher до affected-area gates, сохранив явное различие между stage success, full-change validation и semantic approval
+  - **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
+  - **Verification:** На incomplete disposable change проверить stage-only результат, а на полном change запустить dispatcher и подтвердить, что planning gate выполняется раньше repository gates.
+
+## 2. Versioned agent projection
+
+- [x] 2.1 [specs] Импортировать project-owned `commands` и `skills` в canonical source tree `specs/agent-projection/opencode`, документировав границы projection и исключив package manifests, dependencies и machine-local state
+  - **Covers:** `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`
+  - **Verification:** Сравнить перечень canonical files с текущей project-owned root projection и подтвердить отсутствие package/runtime files в committed source tree.
+- [x] 2.2 [specs] Добавить explicit atomic sync для root `.opencode` с восстановлением pre-cutover state при ошибке и отдельный non-mutating exact-content verifier required file set
+  - **Covers:** `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`
+  - **Verification:** В disposable workspace проверить успешное восстановление projection из canonical source, обнаружение missing/content drift и отсутствие частично обновлённого output после искусственно сорванного sync.
+- [x] 2.3 [specs] Расширить authority fixtures проверками projection drift и generated version markers, получая expected version только из `openspec/.cli-version`
+  - **Covers:** `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`; `openspec-authority-and-lifecycle` — `OpenSpec tooling имеет проверяемый version contract`
+  - **Verification:** Запустить authority fixture suite для current contract, mismatched CLI/marker, missing projection и content drift; проверить отсутствие независимого literal `1.10.0` в normative scripts и fixtures.
+
+## 3. Schema v2 and entrypoints
+
+- [x] 3.1 [specs] Повысить `wealth-ledger-sdd` до version 2 и перераспределить guidance по утверждённой owner matrix между schema instructions, templates и additive config без `_rules.md`, добавив stage validation, полный feedback path и компактные примеры сложных delta operations
+  - **Covers:** `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
+  - **Verification:** Выполнить `openspec schema validate wealth-ledger-sdd --verbose` из `specs`, получить instructions всех четырёх artifacts и проверить graph, русские explanations, exact English OpenSpec syntax и отсутствие дублирующих config rules.
+- [x] 3.2 [specs] Обновить Design template условным Rollback Contract, а Tasks template — checkbox owner `[area]` и обязательными `Covers`/`Verification`, сохранив minimal ADDED-first Spec template
+  - **Covers:** `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`; `engineering-change-governance` — `Труднообратимое изменение имеет rollback contract`
+  - **Verification:** Сгенерировать disposable lifecycle по schema v2 и проверить template shape, `required`/`N/A` rollback cases, точные requirement references и отсутствие пустых delta sections.
+- [x] 3.3 [specs] Обновить canonical agent commands и skills: запускать version и доступные planning checks до approval, возвращать Apply feedback к раннему затронутому artifact и использовать canonical store; затем атомарно синхронизировать root projection
+  - **Covers:** `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `OpenSpec tooling имеет проверяемый version contract`; `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
+  - **Verification:** Выполнить sync и non-mutating projection check, затем просмотреть instructions/entrypoints для Proposal, Specs, Design, Tasks и Apply и подтвердить fixed store, stage gate и feedback routing.
+- [x] 3.4 [specs] Проверить собственный `tasks.md` этого change новым v2 verifier и исправить только технические нарушения формата без изменения утверждённого scope
+  - **Covers:** `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`
+  - **Verification:** Запустить planning verifier для `harden-openspec-sdd-quality` и подтвердить owners только affected areas, валидность всех references и покрытие каждого Delta Requirement.
+
+## 4. Audit evidence and durable documentation
+
+- [x] 4.1 [docs] Перенести пять исходных model reports byte-for-byte в один dated snapshot set под `docs/audits`, добавить index с source list, checksums и external non-authority warning, обновить audits index и удалить unversioned `sdd-audit` только после проверки равенства
+  - **Covers:** `audit-remediation-workflow` — `Реестр remediation отделён от снимка аудита`
+  - **Verification:** Сверить для всех пяти файлов byte count и checksum source/destination до удаления source, затем проверить index links и ровно один versioned snapshot set.
+- [x] 4.2 [docs] Нормализовать все уникальные audit claims в live remediation registry с Audit IDs, всеми source references, доказательными dispositions и отдельными remediation statuses; связать confirmed scope с текущим active change и сохранить auth platform assessment следующим planned item без будущего terminal evidence
+  - **Covers:** `audit-remediation-workflow` — `Каждое audit claim получает доказательный disposition`; `audit-remediation-workflow` — `Реестр remediation отделён от снимка аудита`
+  - **Verification:** Сопоставить каждое claim пяти reports ровно одному Audit ID и проверить обязательные evidence/rationale/review trigger для соответствующего disposition и отсутствие дублирующего registry.
+- [x] 4.3 [docs] Обновить engineering governance, OpenSpec lifecycle guide, ADR 010 и связанные indexes до фактического v2 ownership, projection recovery, traceability, feedback, rollback и controlled-upgrade contract
+  - **Covers:** `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `OpenSpec tooling имеет проверяемый version contract`; `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`; `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`; `engineering-change-governance` — `Труднообратимое изменение имеет rollback contract`
+  - **Verification:** Выполнить scoped review updated docs против поставленных scripts/schema и проверить local links и indexes без копирования planning artifacts в docs.
+
+## 5. Delivery verification
+
+- [x] 5.1 [specs] Выполнить canonical specs gates и controlled-invalid fixture suites после интеграции schema, planning, projection и authority checks
+  - **Covers:** `N/A` — задача агрегирует verification уже покрытых требований и не вводит самостоятельное spec-level behavior.
+  - **Verification:** Запустить version preflight, planning/projection/authority fixture suites, schema validation, strict change validation, strict main-spec validation, authority verifier и `git diff --check` в `specs`.
+- [x] 5.2 [docs] Выполнить canonical docs gate и scoped проверку audit snapshot, checksums, registry completeness, indexes и local links
+  - **Covers:** `N/A` — задача проверяет docs delivery уже покрытых audit requirements и не добавляет новое поведение.
+  - **Verification:** Запустить `npm run verify` в `docs` и отдельно подтвердить affected local links, snapshot checksums и claim-to-Audit-ID coverage.
+- [x] 5.3 [workspace] Выполнить cross-area dispatcher для полного change без frontend/backend и runtime-openapi gates
+  - **Covers:** `N/A` — workspace task оркестрирует canonical gates affected repositories и не заменяет repository-owned implementation.
+  - **Verification:** Запустить `bash specs/scripts/verify-workspace-change.sh harden-openspec-sdd-quality` и подтвердить Delivery Map `specs/docs=affected`, `frontend/backend=N/A` и `runtime-openapi=N/A`.
+- [x] 5.4 [workspace] Провести semantic verification реализации против Proposal, всех 9 Delta Requirements и 28 Scenarios, Design и Tasks, затем independent read-only review без Critical или Important findings
+  - **Covers:** `N/A` — terminal semantic и independent reviews проверяют change целиком, но не реализуют отдельный Requirement.
+  - **Verification:** Сохранить наблюдаемое review evidence только после фактических запусков и устранить блокирующие findings до archive eligibility.
@@ -5,14 +5,5 @@ context: |
  Canonical OpenSpec authority — зарегистрированный store wealth-ledger-specs в specs/openspec.
  Docs описывает только фактическое as-built состояние; устойчивые process policies находятся в docs/development.
  Локальная разработка и verification выполняются под Node 22 без CI.
-
-rules:
-  proposal:
-    - Формулировать owner-утверждаемое намерение без технологий, API, файлов и зависимостей.
-  specs:
-    - Описывать только изменение наблюдаемого поведения и инвариантов, не изменение кода.
-  design:
-    - Всегда включать Delivery Map для frontend, backend, specs и docs.
-    - Добавлять Solution Assessment только при build-vs-buy trigger из schema instructions.
-  tasks:
-    - Включать planned verification каждой affected области, но не observed results, commit IDs или post-archive bookkeeping.
+  Project artifacts объясняют решения по-русски; exact OpenSpec headings, tokens,
+  commands и normative keywords SHALL/MUST сохраняются на английском.
@@ -1,6 +1,6 @@
 name: wealth-ledger-sdd
-version: 1
-description: WealthLedger SDD workflow - proposal → specs → design → tasks
+version: 2
+description: WealthLedger SDD workflow - proposal → specs → design → tasks → apply
 artifacts:
  - id: proposal
    generates: proposal.md
@@ -33,11 +33,22 @@ artifacts:
      behavior, so if behavior does not change, no spec should change either.
      Do not invent a requirement just to satisfy validation.

-      MUST NOT включать технологии, библиотеки, API signatures, имена файлов,
-      зависимости, классы или пошаговую реализацию. Эти решения появляются
-      только после Delta Specs в Design.
+      Artifact boundary — MUST NOT include:
+      - технологии, библиотеки, зависимости или выбранную архитектуру: эти
+        решения появляются только после Delta Specs в Design;
+      - API signatures, database structures, имена файлов, классов или
+        функций: это implementation detail для Design;
+      - implementation steps, task decomposition или verification commands:
+        это конкретизируется в Tasks после утверждения Design.

      This is the foundation - specs, design, and tasks all build on this.
+
+      До сохранения исследуй canonical main specs и remediation registry для
+      audit-derived change. После записи выполни
+      `bash specs/scripts/verify-openspec-planning.sh <change>`: на этой стадии
+      verifier проверяет Proposal и явно оставляет downstream validation
+      pending. Исправь технический формат и повтори check до запроса approval;
+      structural success не означает approval Change Owner.
    requires: []

  - id: specs
@@ -55,11 +66,17 @@ artifacts:
      - External constraints (security, privacy, reliability, compatibility)
      - Scenarios that can be tested or explicitly validated

-      Не включай в specs:
-      - Internal class/function names
-      - Library or framework choices
-      - Step-by-step implementation details
-      - Detailed execution plans (those belong in design.md or tasks.md)
+      Artifact boundary — MUST NOT include:
+      - intent или scope за пределами утверждённого Proposal: сначала верни
+        изменение в Proposal;
+      - internal components, class/function names, files или database
+        structures: implementation structure определяется в Design;
+      - library, framework или infrastructure choices: alternatives и решение
+        принадлежат Design;
+      - step-by-step implementation, delivery sequencing или verification
+        commands: это принадлежит Tasks;
+      - test procedure вместо behavior scenario: scenario фиксирует
+        наблюдаемые WHEN/THEN, а способ проверки выбирается позднее.

      Quick test: if the implementation can change without changing externally
      visible behavior, it likely does not belong in the spec.
@@ -113,8 +130,9 @@ artifacts:
      Common pitfall: Using MODIFIED with partial content loses detail at archive time.
      If adding new concerns without changing existing behavior, use ADDED instead.

-      Example (a new capability, so it opens with `## Purpose`):
+      Compact operation examples:
      ```
+      # ADDED in a new capability: include Purpose.
      ## Purpose

      Lets users take their data out of the product in a portable format.
@@ -128,15 +146,39 @@ artifacts:
      - **WHEN** user clicks "Export" button
      - **THEN** system downloads a CSV file with all user data

+      # MODIFIED: copy the complete old requirement, then edit it.
+      ## MODIFIED Requirements
+
+      ### Requirement: Session expiration
+      The system MUST reject an expired session and preserve every surviving
+      scenario from the main spec.
+
+      #### Scenario: Expired session
+      - **WHEN** a request uses an expired session
+      - **THEN** the system rejects the request
+
+      # REMOVED requires both fields.
      ## REMOVED Requirements

      ### Requirement: Legacy export
      **Reason**: Replaced by new export system
      **Migration**: Use new export endpoint at /api/v2/export
+
+      # RENAMED changes only the heading.
+      ## RENAMED Requirements
+
+      - FROM: `### Requirement: Old name`
+      - TO: `### Requirement: New name`
      ```

      Specs должны быть проверяемыми, но scenario не означает автоматический
      unit test: уровень проверки выбирается по риску поведения.
+
+      Перед записью установи явный approval Proposal из разговора. После
+      записи выполни `bash specs/scripts/verify-openspec-planning.sh <change>`
+      и исправь технические ошибки до запроса approval Delta Specs. Если
+      обнаружено изменение intent, вернись к Proposal и инвалидируй downstream
+      approvals вместо скрытого расширения Specs.
    requires:
      - proposal

@@ -146,7 +188,17 @@ artifacts:
    template: design.md
    instruction: |
      Создай Design, объясняющий, КАК архитектурно выполнить утверждённые
-      Delta Specs. Не превращай его в построчную инструкцию или список правок.
+      Delta Specs.
+
+      Artifact boundary — MUST NOT include:
+      - новое observable behavior или invariant, отсутствующие в утверждённых
+        Delta Specs: сначала верни изменение в Specs;
+      - пересказ Proposal или Specs вместо архитектурных constraints и
+        решений, необходимых для выбранного подхода;
+      - file-by-file implementation checklist, verification commands или
+        пошаговый список правок: это принадлежит Tasks;
+      - будущие delivery results, commit identifiers или Completion Evidence:
+        они фиксируются только после наблюдаемого выполнения.

      Обязательные разделы:
      - **Context**: только текущее состояние и ограничения подхода.
@@ -160,6 +212,12 @@ artifacts:
      - **Risks / Trade-offs**: риск и mitigation.
      - **Migration Plan**: порядок поставки и rollback, если применимо.

+      Внутри Migration Plan добавь `### Rollback Contract` с table fields.
+      Status `required` обязателен для auth/security, data integrity/migration,
+      public contract и другого существенно труднообратимого решения и требует
+      Trigger, Actions, Data safety и Verification. В остальных случаях Status
+      `N/A` требует конкретный Reason. Отдельный rollback artifact не создавай.
+
      Добавь **Solution Assessment**, если изменение вводит или существенно
      заменяет auth, security, storage, external integration, observability,
      caching, concurrency или общую infrastructure/tooling либо содержит
@@ -176,7 +234,11 @@ artifacts:
      skipped. If a question would change the specs, the chosen approach, or
      the task breakdown, resolve it now - ask the user instead of guessing.

-      Design формируется только после явного owner approval Delta Specs.
+      Design формируется только после явного owner approval Delta Specs. После
+      записи выполни `bash specs/scripts/verify-openspec-planning.sh <change>`
+      и исправь технические ошибки до запроса approval. Если Design показывает
+      несовместимость с intent или behavior, остановись, вернись к самому
+      раннему затронутому artifact и инвалидируй downstream approvals.
    requires:
      - specs

@@ -197,8 +259,18 @@ artifacts:

      Правила:
      - Группируй задачи под numbered `##` headings и располагай по dependencies.
-      - Каждая задача MUST иметь формат `- [ ] X.Y ...` и быть выполнимой за
-        одну рабочую сессию.
+      - Каждая задача MUST иметь формат `- [ ] X.Y [area] action`, быть
+        выполнимой за одну рабочую сессию и иметь ровно одного owner из
+        `frontend`, `backend`, `specs`, `docs`, `workspace`.
+      - Сразу после checkbox добавляй ровно по одной indented metadata line:
+        `- **Covers:**` и `- **Verification:**`.
+      - `Covers` содержит одну или несколько пар
+        `` `capability-path` — `exact Requirement heading` `` либо
+        `` `N/A` — concrete reason ``. Каждый Delta Requirement должен быть
+        покрыт хотя бы одной task; собственные requirement IDs не вводятся.
+      - Owner repository не может иметь статус `N/A` в Delivery Map.
+        Cross-repository implementation разделяй; `workspace` используй только
+        для orchestration/verification и с конкретным `N/A` Covers rationale.
      - Для каждой `affected` области Delivery Map должна существовать задача
        реализации и её canonical local gate; пустые commits запрещены.
      - Каждая задача MUST указывать planned verification action: команду,
@@ -213,24 +285,38 @@ artifacts:
        branching, transformation, invariant или regression.
      - Перед custom implementation в обязательных областях включи действие по
        утверждённому Solution Assessment из Design.
-      - MUST NOT записывать ещё не наблюдённые результаты как выполненные,
-        предполагаемые commit identifiers, archive path или post-archive
-        Completion Evidence. Такое evidence создаётся только после факта.
+
+      Artifact boundary — MUST NOT include:
+      - новое observable behavior или Requirement: сначала верни изменение в
+        Specs;
+      - новое архитектурное решение или отклонение от утверждённого Design:
+        сначала обнови Design;
+      - одну задачу с несколькими owner repositories: раздели её по delivery
+        areas;
+      - vague action без проверяемого результата: сформулируй конкретное DO и
+        planned Verification;
+      - ещё не наблюдённые результаты как выполненные, предполагаемые commit
+        identifiers, archive path или post-archive Completion Evidence: такое
+        evidence создаётся только после факта.

      Example:
      ```
-      ## 1. Setup
+      ## 1. Delivery

-      - [ ] 1.1 Create new module structure and verify expected files are present
-      - [ ] 1.2 Add dependencies to package.json and verify package installation succeeds
-
-      ## 2. Core Implementation
-
-      - [ ] 2.1 Implement data export function and verify the export test passes
-      - [ ] 2.2 Add CSV formatting utilities and verify unit tests cover quoting and delimiters
+      - [ ] 1.1 [backend] Implement session rejection
+        - **Covers:** `user-authentication` — `Expired session is rejected`
+        - **Verification:** Run the backend canonical gate and the expiry contract test.
+      - [ ] 1.2 [workspace] Run cross-area semantic review
+        - **Covers:** `N/A` — verification only; no independent spec behavior.
+        - **Verification:** Compare delivery against every approved Requirement and Scenario.
      ```

      Reference specs for what needs to be built, design for how to build it.
+      После записи выполни
+      `bash specs/scripts/verify-openspec-planning.sh <change>` и исправь
+      технические нарушения до запроса approval. Если Tasks требует новое
+      behavior или architecture, не расширяй scope: вернись к Specs или Design
+      и инвалидируй Tasks approval.
    requires:
      - design

@@ -240,5 +326,23 @@ apply:
  instruction: |
    Сначала проверь exact OpenSpec version contract. Работай только с change в
    canonical store `wealth-ledger-specs` и не создавай parallel planning root.
-    Read context files, work through pending tasks, mark complete as you go.
+    Apply допустим только после явных approvals Proposal, Delta Specs, Design и
+    Tasks из разговора. До реализации выполни
+    `bash specs/scripts/verify-openspec-planning.sh <change>`.
+
+    Read context files, work through pending tasks, run each planned
+    Verification and mark a checkbox complete only after observed success.
    Pause if you hit blockers or need clarification.
+
+    Feedback routing:
+    - intent/scope mismatch → Proposal;
+    - observable behavior mismatch → Delta Specs;
+    - architecture/rollback mismatch → Design;
+    - decomposition/ownership/coverage mismatch → Tasks.
+
+    Останови downstream work, сообщи наблюдаемое основание и инвалидируй
+    approvals начиная с самого раннего затронутого artifact. Только
+    механическое syntax/format исправление без изменения intent, behavior,
+    decisions или task scope можно исправить и повторно структурно проверить
+    без reapproval. Structural validation не заменяет semantic verification и
+    independent read-only review.
@@ -42,6 +42,17 @@

 <!-- Delivery order and rollback, when applicable -->

+### Rollback Contract
+
+| Field | Decision |
+| --- | --- |
+| Status | `required` or `N/A` |
+| Reason | <!-- concrete reason when N/A --> |
+| Trigger | <!-- required when Status is required --> |
+| Actions | <!-- required when Status is required --> |
+| Data safety | <!-- required when Status is required --> |
+| Verification | <!-- required when Status is required --> |
+
 ## Open Questions

 <!-- Only questions that cannot change Specs, approach or Tasks; otherwise
@@ -1,9 +1,17 @@
-## 1. <!-- Task Group Name -->
+## 1. <!-- Dependency-ordered task group -->

- [ ] 1.1 <!-- Concrete implementation action and its planned verification -->
- [ ] 1.2 <!-- Concrete implementation action and its planned verification -->
+- [ ] 1.1 [area] <!-- Concrete implementation action -->
+  - **Covers:** `<capability-path>` — `<exact Requirement heading>`
+  - **Verification:** <!-- Planned command, observable check or delivered artifact -->
+- [ ] 1.2 [area] <!-- Concrete implementation action -->
+  - **Covers:** `N/A` — <!-- Concrete reason this task has no spec-level behavior -->
+  - **Verification:** <!-- Planned command, observable check or delivered artifact -->

-## 2. <!-- Task Group Name -->
+## 2. <!-- Affected repository delivery and gates -->

- [ ] 2.1 <!-- Affected repository action and canonical local gate -->
- [ ] 2.2 <!-- Cross-area verification when required -->
+- [ ] 2.1 [area] <!-- Affected repository action -->
+  - **Covers:** `<capability-path>` — `<exact Requirement heading>`
+  - **Verification:** <!-- Canonical local gate -->
+- [ ] 2.2 [workspace] <!-- Cross-area orchestration or verification only -->
+  - **Covers:** `N/A` — <!-- Concrete orchestration/verification reason -->
+  - **Verification:** <!-- Cross-area gate or semantic review -->
@@ -7,20 +7,29 @@
 ## Requirements

 ### Requirement: Реестр remediation отделён от снимка аудита
-Система SHALL создавать отдельный неизменяемый versioned audit snapshot в `docs/audits` для каждого завершённого аудита и SHALL поддерживать один актуальный durable remediation registry в `docs/development`, охватывающий findings всех audit snapshots. Каждый snapshot SHALL оставаться source of facts своего аудита и MUST NOT редактироваться для отражения последующей remediation. Registry SHALL хранить текущее состояние, связанный canonical change, следующее действие и completion evidence каждой записи, MUST ссылаться на однозначный Audit ID и исходный snapshot и MUST NOT дублировать полный текст finding, если он уже содержится в snapshot.
+
+Система SHALL создавать отдельный неизменяемый versioned audit snapshot в `docs/audits` для каждого завершённого аудита и SHALL поддерживать один актуальный durable remediation registry в `docs/development`, охватывающий findings всех audit snapshots. Для завершённого multi-source audit система SHALL сохранять каждый source file byte-for-byte и объединять их одним snapshot index. Каждый snapshot SHALL оставаться source of claims своего аудита и MUST NOT редактироваться для отражения последующей remediation. Внешняя модельная оценка MUST быть обозначена как неавторитетный источник claims и MUST NOT подменять requirements, governance или проверенное состояние проекта. Registry SHALL хранить текущее состояние, связанный canonical change, следующее действие и completion evidence каждой записи, MUST ссылаться на однозначный Audit ID и каждый относящийся source snapshot и MUST NOT дублировать полный текст finding, если он уже содержится в snapshot.

 #### Scenario: Агент открывает работу по аудиту в новой сессии
+
 - **WHEN** агент получает задачу устранить или продолжить finding из любого завершённого аудита
 - **THEN** он находит в едином registry исходный snapshot и Audit ID, текущий статус, связанный OpenSpec change, evidence и следующее действие без повторной интерпретации всех аудитов

 #### Scenario: Проводится повторный аудит
+
 - **WHEN** новый аудит завершён после предыдущего audit snapshot
 - **THEN** система добавляет новый immutable snapshot и обновляет тот же live registry, не переписывая предыдущий snapshot и не создавая конкурирующий registry

 #### Scenario: Обновляется прогресс remediation
+
 - **WHEN** работа по finding меняет статус
 - **THEN** versioned audit snapshots не редактируются, а изменение фиксируется только в live registry с датой и необходимым evidence

+#### Scenario: Один аудит содержит несколько внешних оценок
+
+- **WHEN** завершённая assessment использовала несколько независимых source reports
+- **THEN** snapshot index связывает byte-for-byte сохранённые reports в один audit и явно отделяет их claims от project authority
+
 ### Requirement: Registry задаёт однозначный статус и следующий change
 Каждая audit-derived запись SHALL иметь ровно один статус из `planned`, `active`, `done`, `deferred` или `accepted`. `planned` MUST означать согласованную работу, которую можно начать без внешнего review trigger; запись, ожидающая версии зависимости, внешнего события или отдельного решения владельца, MUST иметь статус `deferred` с условием пересмотра. Registry MUST содержать не более одного `active` remediation change и ровно одну следующую рекомендуемую задачу, пока существуют findings со статусом `planned`.

@@ -46,3 +55,22 @@ Registry SHALL NOT представлять finding как `done` без дат
 #### Scenario: Риск сознательно не исправляется сейчас
 - **WHEN** владелец переносит finding или принимает риск
 - **THEN** registry сохраняет причину решения и условия, при которых оно должно быть пересмотрено
+
+### Requirement: Каждое audit claim получает доказательный disposition
+
+Каждое уникальное claim завершённого multi-source audit MUST входить ровно в один нормализованный Audit ID и иметь triage disposition `confirmed`, `already-covered`, `rejected` или `deferred`. Нормализованная запись MUST ссылаться на каждый source report, содержащий claim. `confirmed` MUST связываться с remediation status и change либо terminal evidence; `already-covered` MUST приводить проверяемое существующее evidence; `rejected` MUST содержать конкретное rationale; `deferred` MUST содержать review trigger. Triage disposition MUST оставаться отдельным от remediation status `planned`, `active`, `done`, `deferred` или `accepted`, чтобы внешняя рекомендация не становилась принятой policy без проверки.
+
+#### Scenario: Несколько моделей повторяют одно замечание
+
+- **WHEN** два или более source reports описывают один и тот же underlying gap
+- **THEN** registry содержит один нормализованный Audit ID со ссылками на все источники и одним доказательным disposition
+
+#### Scenario: Рекомендация уже реализована
+
+- **WHEN** проверяемое состояние проекта полностью покрывает external claim
+- **THEN** disposition `already-covered` ссылается на существующий requirement, guardrail или completion evidence без создания фиктивной remediation work
+
+#### Scenario: Внешняя рекомендация противоречит authority
+
+- **WHEN** source report предлагает неподдерживаемый либо ухудшающий действующий invariant подход
+- **THEN** disposition `rejected` фиксирует конкретное противоречие и не превращает recommendation в requirement
@@ -67,3 +67,22 @@

 - **WHEN** change объявляет новое правило блокирующим
 - **THEN** completion evidence подтверждает как успешный compliant case, так и обнаружение контролируемого representative violation
+
+### Requirement: Труднообратимое изменение имеет rollback contract
+
+Design MUST определять rollback trigger, rollback actions, data safety и rollback verification, когда change затрагивает auth или security behavior, data integrity или migration, public contract либо другое существенно труднообратимое решение. Rollback contract MUST учитывать данные и совместимость, созданные после поставки change, и MUST быть выполним без нового неутверждённого архитектурного решения. Когда указанные риски неприменимы, Design SHALL фиксировать конкретную проверяемую причину `N/A` и MUST NOT создавать отдельный artifact или формальный rollback plan ради процесса.
+
+#### Scenario: Change мигрирует данные
+
+- **WHEN** Design изменяет хранимые данные способом, который может потребовать возврата
+- **THEN** он определяет trigger, безопасные действия отката, судьбу новых данных и проверку восстановленного состояния до утверждения Tasks
+
+#### Scenario: Change меняет публичный контракт
+
+- **WHEN** Design вводит несовместимое изменение публичного контракта
+- **THEN** rollback contract объясняет восстановление совместимости и проверяемое условие успешного отката
+
+#### Scenario: Rollback risk отсутствует
+
+- **WHEN** change не затрагивает auth, security, данные, публичный контракт или другое труднообратимое решение
+- **THEN** Design указывает конкретную причину `N/A` без создания дополнительного rollback artifact
@@ -61,3 +61,41 @@ Workspace SHALL предоставлять один non-mutating локальн

 - **WHEN** общий verifier проверяет несколько affected областей и канонический gate одной из них не проходит
 - **THEN** общий результат является неуспешным и явно указывает failing area без обхода её локального gate
+
+### Requirement: Каждая задача объявляет единственную delivery area
+
+Каждый checkbox Tasks MUST объявлять ровно одного owner из `frontend`, `backend`, `specs`, `docs` или `workspace`. Implementation work, изменяющая несколько Git-репозиториев, MUST быть разделена на repository-owned tasks; `workspace` SHALL использоваться только для cross-area orchestration или verification без владения repository implementation. Для каждой `affected` area Tasks MUST содержать её implementation work и canonical local gate, а task ownership MUST соответствовать утверждённому Delivery Map.
+
+#### Scenario: Change затрагивает frontend и backend
+
+- **WHEN** одна delivery intent требует изменения клиента и API
+- **THEN** Tasks содержит отдельные frontend-owned и backend-owned checkbox items вместо одной общей implementation task
+
+#### Scenario: Выполняется общий verification gate
+
+- **WHEN** задача только оркестрирует проверку нескольких affected areas и не изменяет их implementation
+- **THEN** task использует owner `workspace` и не подменяет repository-owned implementation или canonical gates
+
+#### Scenario: Task ссылается на N/A area
+
+- **WHEN** checkbox объявляет owner области, которая имеет статус `N/A` в Delivery Map
+- **THEN** planning validation завершается ошибкой и указывает несогласованную delivery area
+
+### Requirement: Tasks трассируются к утверждённым требованиям
+
+Каждый checkbox Tasks MUST содержать coverage reference: одну или несколько пар из точного capability path и точного Requirement heading либо `N/A` с конкретной причиной для работы, которая не реализует spec-level behavior. Каждый Requirement из Delta Specs MUST быть покрыт хотя бы одной task. Planning validation MUST отклонять отсутствующее покрытие, ссылку на несуществующий capability или Requirement и пустую причину `N/A`. Traceability SHALL использовать нативную идентичность requirement и MUST NOT вводить параллельный namespace собственных requirement IDs.
+
+#### Scenario: Delta requirement покрыт реализацией
+
+- **WHEN** Tasks планирует поставку изменённого requirement
+- **THEN** хотя бы один checkbox ссылается на точный capability path и Requirement heading этого delta
+
+#### Scenario: Задача не меняет spec-level behavior
+
+- **WHEN** task обновляет infrastructure, documentation или verification без самостоятельного requirement
+- **THEN** coverage reference содержит `N/A` и конкретно объясняет отсутствие spec-level связи
+
+#### Scenario: Requirement остался без задачи
+
+- **WHEN** хотя бы один Requirement из Delta Specs не указан ни в одной coverage reference
+- **THEN** planning validation блокирует approval Tasks и перечисляет uncovered Requirement
@@ -35,7 +35,7 @@ Versioned SDD change SHALL проходить последовательност

 ### 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.
+Изменение утверждённого 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.

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

@@ -47,6 +47,16 @@ Versioned SDD change SHALL проходить последовательност
 - **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
+
 ### 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, текущей директории или глобального значения по умолчанию машины.

@@ -82,7 +92,7 @@ Canonical store и policy расположения artifacts SHALL иметь do

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

-SDD workflow MUST объявлять поддерживаемую версию OpenSpec CLI и проверять фактическую версию до команд, читающих или изменяющих canonical change. Несовместимая либо неопределённая версия MUST давать actionable blocking result и MUST NOT приводить к молчаливому изменению artifact graph, templates или project-owned entrypoints.
+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 соответствует контракту

@@ -94,6 +104,16 @@ SDD workflow MUST объявлять поддерживаемую версию O
 - **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 и project-owned projection
+
 ### 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.
@@ -122,3 +142,31 @@ Project-owned archive workflow MUST отклонять archive, если отс
 #### 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: Project-owned agent workflow воспроизводим из versioned authority
+
+Project-owned agent workflow SHALL восстанавливаться в новом workspace из committed authority inputs и текущей поддерживаемой версии инструмента без использования прежнего локального generated state. Workspace-level projection SHALL оставаться derived output и MUST NOT становиться конкурирующим SDD authority. Non-mutating verifier MUST обнаруживать отсутствие required projection, расхождение с versioned inputs и несовместимый generated version marker; установленные зависимости и machine-local runtime state MUST NOT считаться authority inputs.
+
+#### Scenario: Workspace собирается заново
+
+- **WHEN** участник получает чистые checkout всех project repositories и поддерживаемый инструмент
+- **THEN** documented workflow воспроизводит project-owned agent projection из versioned inputs без копирования файлов с прежней машины
+
+#### Scenario: Derived projection изменена вручную
+
+- **WHEN** локальная project-owned projection больше не соответствует versioned authority inputs
+- **THEN** non-mutating verifier завершает проверку ошибкой и указывает на projection drift
+
+### Requirement: Planning artifact проверяется до запроса approval
+
+Каждый создаваемый planning artifact SHALL пройти все применимые на его текущем этапе non-mutating structural checks до запроса approval Change Owner. Если полный change validation ещё заблокирован отсутствующими downstream artifacts, workflow MUST выполнить доступные проверки текущего artifact и явно оставить недоступную проверку незавершённой, а не заявлять общий успех. Техническая ошибка проверяемого формата SHALL исправляться и проверяться повторно без передачи ручного исправления Change Owner; structural success MUST NOT подменять semantic approval.
+
+#### Scenario: Текущий artifact имеет проверяемое нарушение
+
+- **WHEN** сгенерированный planning artifact нарушает обязательный формат или ссылочную целостность, доступные для проверки на текущем этапе
+- **THEN** workflow исправляет нарушение и повторяет structural checks до запроса owner approval
+
+#### Scenario: Downstream artifacts ещё отсутствуют
+
+- **WHEN** Proposal создан, а Delta Specs, Design и Tasks ещё не существуют
+- **THEN** workflow сообщает результат доступных Proposal checks и не представляет отсутствующую full-change validation как успешную