feat: harden OpenSpec agent resilience

openspec/changes/harden-openspec-sdd-agent-resilience/.openspec.yaml

@@ -0,0 +1,7 @@
+schema: wealth-ledger-sdd
+created: 2026-08-26
+goal: Повысить надёжность агентного SDD workflow без новых competing authorities
+  и процессного overhead.
+affected_areas:
+  - specs
+  - docs

openspec/changes/harden-openspec-sdd-agent-resilience/design.md

@@ -0,0 +1,185 @@
+## Context
+
+Project-local schema v2 уже владеет SDD semantics, а stage-aware verifier
+проверяет artifact graph, coverage и Delivery Map. При этом обязательные правила
+распределены внутри длинных instructions, единый Delta Spec template начинает с
+`ADDED Requirements`, а planning failures не имеют общего явного разделения на
+artifact, invocation и environment причины. OpenSpec CLI 1.10.0 остаётся
+project version contract; schema API имеет experimental status, поэтому решение
+должно сохранять native graph и не вводить новый workflow engine.
+
+Шесть second-round reports находятся как локальный неversioned corpus. Они
+содержат повторы прежних claims, предложения, противоречащие действующей policy,
+и неполный provenance. Existing remediation workflow уже определяет immutable
+snapshot и отдельный live triage, поэтому новый формат evidence не требуется.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- Сохранить project schema единственным владельцем artifact semantics, сделав
+  Critical Rules первыми и устранив повторяющийся explanation text.
+- Сохранить один native artifact graph и сделать Delta Spec scaffold нейтральным
+  к operation.
+- Дать planning verifier устойчивую taxonomy отказов и оставить semantic
+  качество `N/A` rationale на human review boundary.
+- Использовать уже разрешённый CLI context и существующую repository routing
+  policy без второго mapping authority.
+- Зафиксировать второй review corpus и его triage в существующей audit model.
+
+**Non-Goals:**
+
+- Универсализация topology за пределы WealthLedger.
+- Persistent approval state, дополнительные review/done/solution artifacts или
+  cross-change dependency graph.
+- CI, commit convention, task sizing, Success Metrics либо schema changelog.
+- Числовой quality threshold для instruction size, checksum или byte-count gate
+  для audit reports.
+- Изменение application runtime, данных или API contract.
+
+## Decisions
+
+### 1. Сохранить текущие authority boundaries и выпустить schema v3
+
+Schema продолжает владеть normative agent semantics; templates владеют исходной
+формой artifacts, project config содержит только устойчивый context, scripts
+реализуют детерминированные hard invariants, а durable docs описывает as-built
+process. Каждая artifact instruction начинается с компактного блока Critical
+Rules, после которого идут только stage-specific details. Пояснения приводятся
+по-русски, а exact OpenSpec tokens, headings, commands и SHALL/MUST сохраняются
+на английском.
+
+Material instruction, template и verifier contract change повышает schema
+version до 3. Исторический rationale остаётся в canonical change, archive,
+registry и Git history; отдельный changelog не создаётся.
+
+### 2. Сделать Delta Spec scaffold operation-neutral
+
+Единый template не может знать, новая capability или существующая и какая delta
+operation требуется. Поэтому он не создаёт активные operation headings, а через
+Markdown comments показывает выбор из `ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`
+и условный `Purpose`. Агент добавляет только применимые sections. Компактная
+shape guidance перемещается из длинной Specs instruction в template comments;
+semantic rules полного `MODIFIED`, полей `REMOVED` и формата `RENAMED` остаются
+в schema.
+
+### 3. Ввести три machine-distinguishable класса planning failure
+
+Verifier использует стабильные категории результата:
+
+- `artifact-validation` с exit 1 — artifact существует, но нарушает проверяемую
+  форму или ссылочную целостность; разрешено исправить только указанное
+  нарушение;
+- `invocation` с exit 2 — неверное число аргументов, имя или неразрешимый change;
+  исправляется вызов, а не artifact;
+- `environment` с exit 3 — отсутствует или несовместим runtime, CLI либо другой
+  prerequisite; сначала диагностируется окружение, artifact не меняется.
+
+Project instruction ссылается на эти категории и не вводит retry counter.
+Unexpected internal failure остаётся blocking result и не маскируется под
+artifact validation.
+
+### 4. Разделить structural и semantic качество `N/A`
+
+Hard guardrail отклоняет пустую причину, одиночный separator и неразрешённый
+template placeholder. Instruction и template требуют объяснить отсутствие
+самостоятельного observable behavior, техническую необходимость и связь с
+утверждённым Design или delivery. Смысл непустого rationale оценивают Change
+Owner и independent review; blacklist слов и эвристический natural-language
+checker не добавляются.
+
+### 5. Использовать CLI-resolved context
+
+Apply instruction прямо требует прочитать все paths из `contextFiles`,
+возвращённых native OpenSpec instructions, затем applicable local routing
+instructions affected areas. Он не вычисляет planning paths и не требует нового
+context map. Это сохраняет portable CLI state единственным владельцем resolved
+artifact context.
+
+### 6. Включить review corpus без дополнительной integrity ceremony
+
+Шесть reports переносятся в новый immutable audit snapshot set без изменения
+их текста. Короткий index перечисляет sources и известные provenance
+ограничения; checksum, byte-count manifest и отдельный validation framework не
+добавляются. Live registry дедуплицирует claims против существующих Audit IDs:
+повторы получают existing evidence/rationale, а действительно residual gaps —
+новые follow-up records, связанные с этим change.
+
+### 7. Проверять сохранение invariants, а не оптимизировать цифру
+
+Verification сопоставляет принятые lifecycle invariants с одним authoritative
+owner, проверяет compliant и controlled-invalid cases для новых hard guards и
+фиксирует наблюдаемое удаление duplication. Instruction length может быть
+сообщена как diagnostic, но не становится blocking threshold. Внешний model
+score не является completion evidence.
+
+## Delivery Map
+
+| Area | Status | Architectural outcome or N/A reason |
+| --- | --- | --- |
+| frontend | `N/A` | Client behavior, implementation и local gate не меняются. |
+| backend | `N/A` | API behavior, implementation и local gate не меняются. |
+| specs | `affected` | Schema v3, planning verifier, templates, fixtures и canonical Delta Specs поставляют новый workflow contract. |
+| docs | `affected` | Второй audit snapshot, live triage и as-built lifecycle documentation отражают поставленный process. |
+
+### Contract Gate Decision
+
+| Gate | Status | Reason |
+| --- | --- | --- |
+| runtime-openapi | `N/A` | Ни backend runtime contract, ни frontend committed client snapshot не меняются. |
+
+## Solution Assessment
+
+Change существенно меняет shared agent tooling, поэтому применён обязательный
+build-versus-buy review.
+
+| Option | Fit and maturity | Security / operating cost | Constraints / migration cost | Decision |
+| --- | --- | --- | --- | --- |
+| Native project OpenSpec schema, templates и existing verifier | Полностью сохраняет используемый OpenSpec 1.10.0 graph и уже поставленные project gates. | Не добавляет runtime или data surface; поддерживается текущими local gates. | Требует узкой правки project-owned contracts и controlled fixtures; active changes остаются совместимыми по artifact IDs. | Selected. |
+| Global agent prompt или внешний common-rules file | Может сократить schema text, но загрузка зависит от agent framework и не гарантируется native OpenSpec. | Создаёт competing authority и постоянную стоимость синхронизации. | Потребовал бы projection/versioning discipline и миграцию всех entrypoints. | Rejected. |
+| Дополнительный workflow framework или новые approval/context/done artifacts | Может хранить больше machine-readable state, но дублирует native graph и решает неподтверждённые risks. | Увеличивает process surface и число stale states без security benefit. | Высокая миграционная и эксплуатационная стоимость; конфликт с утверждённой governance. | Rejected. |
+
+Native project-local schema выбрана потому, что текущий OpenSpec 1.10.0 contract
+уже предоставляет используемую extension boundary для artifacts, templates и
+instructions, а external prompt и дополнительные state artifacts не выполняют
+утверждённые authority constraints. Review trigger: несовместимое изменение
+native schema API либо появление поддерживаемого OpenSpec mechanism для общих
+typed rules и failure classification.
+
+## Risks / Trade-offs
+
+- **При сокращении потеряется обязательное правило.** Mitigation: inventory
+  действующих invariants, authority fixtures и semantic comparison до/после.
+- **Neutral scaffold даст слишком мало shape guidance.** Mitigation: commented
+  operation menu и controlled deltas для всех четырёх operations.
+- **Failure будет отнесён не к той категории.** Mitigation: отдельные controlled
+  failures для artifact, invocation и environment paths; неожиданный failure
+  остаётся blocking.
+- **Непустой, но слабый `N/A` пройдёт structural gate.** Это осознанный trade-off:
+  semantic approval и independent review остаются владельцами смысла, чтобы
+  эвристика не выдавала false confidence.
+- **Schema v3 применяется к текущему active change.** Mitigation: artifact IDs и
+  dependency graph не меняются; current change повторно проходит planning и
+  strict schema/change validation после migration.
+
+## Migration Plan
+
+1. Сначала обновить normative schema contract и operation-neutral template,
+   сохранив artifact IDs и dependency graph.
+2. Затем обновить verifier taxonomy и controlled fixtures, после чего повторно
+   проверить active change новым contract.
+3. Перенести review corpus в immutable docs snapshot, выполнить deduplicated
+   triage и синхронизировать as-built lifecycle wording.
+4. Выполнить canonical gates affected areas, semantic verification и
+   independent read-only review до archive.
+
+### Rollback Contract
+
+| Field | Decision |
+| --- | --- |
+| Status | `N/A` |
+| Reason | Изменение обратимо в versioned tooling/docs, не меняет auth, данные, migration или public contract и не требует отдельного rollback contract. |
+| Trigger | N/A |
+| Actions | N/A |
+| Data safety | N/A; application data не затрагиваются. |
+| Verification | N/A |

openspec/changes/harden-openspec-sdd-agent-resilience/proposal.md

@@ -0,0 +1,44 @@
+## Why
+
+Вторая независимая оценка подтвердила зрелость текущего SDD workflow, но
+выявила несколько остающихся рисков для работы AI-агента: критические правила
+теряются внутри плотных инструкций, исходная форма Delta Specs подталкивает к
+одному виду изменения, а разные причины planning failure и задачи без прямого
+поведенческого покрытия могут интерпретироваться неоднозначно. Эти риски нужно
+снизить сейчас, пока workflow остаётся компактным и его принятые границы можно
+сохранить без нового процессного слоя.
+
+## What Changes
+
+- Сделать критические правила SDD короче и заметнее, сохранив их единственный
+  authoritative источник и принятые границы артефактов.
+- Сделать исходную форму Delta Specs нейтральной к виду изменения, чтобы она не
+  склоняла агента к неверной операции и не создавала пустых разделов.
+- Различать исправимые нарушения planning artifact, ошибки вызова workflow и
+  проблемы окружения, чтобы агент изменял artifact только по относящейся к нему
+  диагностике.
+- Требовать содержательного объяснения технической необходимости для задач без
+  прямого покрытия Requirement и направлять Apply к явно объявленному контексту
+  затронутых областей.
+- Включить выводы второго аудита в существующий remediation workflow, сохранив
+  внешние рекомендации как evidence для triage, а не как project authority.
+- Не вводить persistent approval markers, дополнительные planning или
+  completion artifacts, универсальную repository topology, отдельный context
+  mapping, Success Metrics, sizing, commit conventions, schema changelog,
+  cross-change dependency graph, CI либо числовой лимит размера инструкций.
+
+## Capabilities
+
+### New Capabilities
+
+### Modified Capabilities
+
+- `openspec-authority-and-lifecycle`: уточнить наблюдаемое поведение planning workflow для компактной передачи критических правил, нейтрального формирования Delta Specs, явного чтения разрешённого контекста и раздельной обработки artifact, invocation и environment failures.
+- `multi-repository-delivery`: уточнить contract задач без прямого Requirement coverage, сохранив детерминированную structural validation отдельно от semantic оценки их необходимости.
+
+## Impact
+
+Изменение затрагивает Engineering Owner и AI-агентов, которые планируют и
+проверяют WealthLedger changes, а также specification и as-built process
+documentation. Пользовательское поведение приложения, frontend/backend runtime
+и публичный API contract не меняются.

openspec/changes/harden-openspec-sdd-agent-resilience/specs/multi-repository-delivery/spec.md

@@ -0,0 +1,30 @@
+## MODIFIED Requirements
+
+### Requirement: Tasks трассируются к утверждённым требованиям
+
+Каждый checkbox Tasks MUST содержать coverage reference: одну или несколько пар из точного capability path и точного Requirement heading либо `N/A` с конкретной причиной для работы, которая не реализует spec-level behavior. Причина `N/A` MUST объяснять отсутствие самостоятельного observable behavior, техническую необходимость задачи и её связь с утверждённым Design или delivery; однословная категория или неразрешённый placeholder не являются достаточной причиной. Каждый Requirement из Delta Specs MUST быть покрыт хотя бы одной task. Planning validation MUST отклонять отсутствующее покрытие, ссылку на несуществующий capability или Requirement, пустую причину `N/A` и неразрешённый placeholder. Содержательная достаточность непустой причины SHALL оцениваться semantic approval и independent review и MUST NOT выдаваться за детерминированный hard guardrail. 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` и конкретно объясняет техническую необходимость задачи и её связь с утверждённым Design или delivery
+
+#### Scenario: N/A содержит placeholder
+
+- **WHEN** coverage reference оставляет template placeholder вместо фактической причины
+- **THEN** planning validation блокирует approval Tasks и указывает незавершённую metadata
+
+#### Scenario: N/A содержит непустую слабую причину
+
+- **WHEN** coverage reference формально заполнена, но не объясняет необходимость задачи или её связь с утверждённым change
+- **THEN** semantic review запрашивает уточнение без представления эвристической текстовой оценки как hard guardrail
+
+#### Scenario: Requirement остался без задачи
+
+- **WHEN** хотя бы один Requirement из Delta Specs не указан ни в одной coverage reference
+- **THEN** planning validation блокирует approval Tasks и перечисляет uncovered Requirement

openspec/changes/harden-openspec-sdd-agent-resilience/specs/openspec-authority-and-lifecycle/spec.md

@@ -0,0 +1,113 @@
+## ADDED Requirements
+
+### 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
+
+## 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. Исправление Markdown heading, опечатки без изменения нормативного смысла или выравнивания таблицы MAY считаться механическим; изменение формулировки Requirement, добавление или удаление Scenario, изменение выбранного архитектурного решения либо planned Verification задачи MUST NOT считаться механическим.
+
+#### Scenario: После Design изменилось намерение
+
+- **WHEN** владелец меняет scope или ожидаемый эффект Proposal
+- **THEN** зависимые Delta Specs, Design и Tasks теряют прежнее подтверждение до повторной согласованной проверки
+
+#### Scenario: Task вводит новое поведение
+
+- **WHEN** implementation checklist требует поведение, которого нет в утверждённых Delta Specs
+- **THEN** агент не расширяет scope через Tasks и возвращает change к Delta Specs
+
+#### Scenario: Apply выявляет архитектурное расхождение
+
+- **WHEN** во время реализации обнаружено, что утверждённый Design не позволяет выполнить Specs без другого архитектурного решения
+- **THEN** Apply останавливается, Tasks теряет прежнее подтверждение, а change возвращается к Design с наблюдаемым основанием и вариантами решения
+
+#### Scenario: Исправляется только структурный формат
+
+- **WHEN** утверждённый artifact содержит исправимую синтаксическую или formatting-ошибку без изменения его смысла
+- **THEN** workflow исправляет ошибку, повторяет structural validation и сохраняет действующие approvals
+
+#### Scenario: Меняется planned Verification
+
+- **WHEN** исправление Tasks меняет способ, которым должна подтверждаться поставка
+- **THEN** workflow рассматривает изменение как semantic task-scope change и повторно запрашивает approval Tasks
+
+### Requirement: Planning artifact проверяется до запроса approval
+
+Каждый создаваемый planning artifact SHALL пройти все применимые на его текущем этапе non-mutating structural checks до запроса approval Change Owner. Если полный change validation ещё заблокирован отсутствующими downstream artifacts, workflow MUST выполнить доступные проверки текущего artifact и явно оставить недоступную проверку незавершённой, а не заявлять общий успех. Planning verifier MUST выдавать различимые результаты для нарушения artifact validation, некорректного invocation и environment failure. Только диагностированная техническая ошибка проверяемого artifact SHALL исправляться в artifact и проверяться повторно без передачи ручного исправления Change Owner; invocation или environment failure MUST NOT приводить к изменению planning artifact. Structural success MUST NOT подменять semantic approval.
+
+#### Scenario: Текущий artifact имеет проверяемое нарушение
+
+- **WHEN** сгенерированный planning artifact нарушает обязательный формат или ссылочную целостность, доступные для проверки на текущем этапе
+- **THEN** workflow сообщает artifact validation failure, исправляет указанное нарушение и повторяет structural checks до запроса owner approval
+
+#### Scenario: Verifier вызван некорректно
+
+- **WHEN** planning verifier получает отсутствующий или недопустимый input
+- **THEN** он сообщает invocation failure, а агент исправляет вызов без изменения planning artifact
+
+#### Scenario: Проверка блокируется окружением
+
+- **WHEN** verifier не может выполнить проверку из-за отсутствующего runtime, command или иного environment prerequisite
+- **THEN** он сообщает environment failure, агент сохраняет planning artifact неизменным и диагностирует prerequisite либо передаёт точную блокирующую ошибку Change Owner
+
+#### Scenario: Downstream artifacts ещё отсутствуют
+
+- **WHEN** Proposal создан, а Delta Specs, Design и Tasks ещё не существуют
+- **THEN** workflow сообщает результат доступных Proposal checks и не представляет отсутствующую full-change validation как успешную

openspec/changes/harden-openspec-sdd-agent-resilience/tasks.md

@@ -0,0 +1,44 @@
+## 1. Specs workflow delivery
+
+- [x] 1.1 [specs] Restructure project schema instructions as compact Critical Rules and bump the schema contract to v3
+  - **Covers:** `openspec-authority-and-lifecycle` — `Project schema сохраняет заметные самодостаточные правила`; `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`
+  - **Verification:** Inspect every generated artifact instruction for rule ownership and run `openspec schema validate wealth-ledger-sdd --verbose`.
+- [x] 1.2 [specs] Replace the ADDED-first Delta Spec scaffold with the approved operation-neutral commented shape
+  - **Covers:** `openspec-authority-and-lifecycle` — `Delta Spec template не предрешает операцию`
+  - **Verification:** Generate or inspect the Specs instruction/template output and validate controlled ADDED, MODIFIED, REMOVED and RENAMED deltas without empty operation sections.
+- [x] 1.3 [specs] Implement distinct artifact-validation, invocation and environment failure results in planning verification
+  - **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
+  - **Verification:** Run controlled planning-verifier cases and observe the specified result category and exit status for each failure class.
+- [x] 1.4 [specs] Reject unresolved N/A placeholders while keeping substantive rationale review semantic
+  - **Covers:** `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`
+  - **Verification:** Run one compliant N/A fixture and controlled failures for empty, separator-only and unresolved-placeholder rationales.
+- [x] 1.5 [specs] Route Apply through CLI-resolved contextFiles and affected-area local instructions
+  - **Covers:** `openspec-authority-and-lifecycle` — `Apply читает только разрешённый planning context`
+  - **Verification:** Inspect native Apply instructions for the active change and confirm they require every CLI-resolved context path without a second context map.
+- [x] 1.6 [specs] Extend controlled fixtures to preserve every changed lifecycle invariant
+  - **Covers:** `openspec-authority-and-lifecycle` — `Project schema сохраняет заметные самодостаточные правила`; `openspec-authority-and-lifecycle` — `Delta Spec template не предрешает операцию`; `openspec-authority-and-lifecycle` — `Apply читает только разрешённый planning context`; `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`
+  - **Verification:** Run the planning and authority fixture suites and confirm compliant cases pass while each representative violation fails for the intended reason.
+- [x] 1.7 [specs] Run the canonical specs validation set against schema v3 and the active change
+  - **Covers:** `N/A` — repository gate verification confirms the approved workflow but introduces no independent spec-level behavior.
+  - **Verification:** Run strict change validation with `openspec validate harden-openspec-sdd-agent-resilience --type change --strict --store wealth-ledger-specs`, strict main-spec validation, schema validation, planning fixtures and authority verification.
+
+## 2. Durable audit and process documentation
+
+- [x] 2.1 [docs] Move the six second-round reports into one immutable audit snapshot with a concise source index
+  - **Covers:** `N/A` — evidence preservation applies the existing audit-remediation contract and introduces no new delta behavior.
+  - **Verification:** Confirm the snapshot index links all six reports and records the known provenance limitations without checksum or byte-count gates.
+- [x] 2.2 [docs] Triage the second-round claims and align as-built SDD lifecycle documentation with the delivered v3 contract
+  - **Covers:** `openspec-authority-and-lifecycle` — `Project schema сохраняет заметные самодостаточные правила`; `openspec-authority-and-lifecycle` — `Delta Spec template не предрешает операцию`; `openspec-authority-and-lifecycle` — `Apply читает только разрешённый planning context`; `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`
+  - **Verification:** Review every normalized claim against its source and existing Audit IDs, then check affected local links and current-state wording.
+- [x] 2.3 [docs] Run the docs canonical gate after snapshot and lifecycle updates
+  - **Covers:** `N/A` — repository gate verification checks delivered documentation and does not define separate observable workflow behavior.
+  - **Verification:** Run `npm run verify` in docs under Node 22 and inspect the observed Markdown and diff-check result.
+
+## 3. Cross-area verification
+
+- [x] 3.1 [workspace] Run the affected-area workspace dispatcher
+  - **Covers:** `N/A` — orchestration only; specs and docs retain ownership of their implementation and canonical gates.
+  - **Verification:** Run `bash specs/scripts/verify-workspace-change.sh harden-openspec-sdd-agent-resilience` from the workspace root under Node 22 and observe both affected-area results.
+- [x] 3.2 [workspace] Perform semantic verification and independent read-only review
+  - **Covers:** `N/A` — terminal verification compares delivery with approved artifacts and introduces no independent behavior.
+  - **Verification:** Compare implementation with every Proposal outcome, all six Requirements, all twenty Scenarios, Design decisions and completed tasks; require an independent review with no Critical or Important findings.

openspec/schemas/wealth-ledger-sdd/schema.yaml

@@ -1,5 +1,5 @@
 name: wealth-ledger-sdd
-version: 2
+version: 3
 description: WealthLedger SDD workflow - proposal → specs → design → tasks → apply
 artifacts:
   - id: proposal
@@ -7,48 +7,34 @@ artifacts:
     description: Owner-approved intent without implementation details
     template: proposal.md
     instruction: |
-      Создай Proposal, который формулирует намерение и объясняет, ПОЧЕМУ
-      изменение нужно. Его должен понимать и утверждать владелец продукта или
-      процесса без знания структуры кода.
+      Critical Rules:
+      - Создай только Proposal: причина, намерение, scope, ожидаемый результат и
+        явные non-goals языком Change Owner.
+      - Сначала исследуй canonical main specs; для audit-derived change также
+        прочитай remediation registry.
+      - Capabilities перечисляет каждую новую или изменяемую behavior spec точным
+        path. Если spec-level behavior не меняется, не выдумывай Requirement:
+        оставь capabilities пустыми и установи `skip_specs: true`.
+      - Оставь технологии, зависимости, архитектуру, API, database/code/file
+        structure для Design, а implementation steps и verification — для Tasks.
+      - После записи запусти
+        `bash specs/scripts/verify-openspec-planning.sh <change>`. Исправляй
+        artifact только при `artifact-validation`; при `invocation` исправь вызов,
+        при `environment` — prerequisite. Structural success не является approval.
 
-      Sections:
-      Разделы:
+      Required Shape:
       - **Why**: проблема или возможность и причина заняться ею сейчас.
-      - **What Changes**: намерение, ожидаемый результат и явные non-goals.
-      - **Capabilities**: какие поведенческие specs появятся или изменятся:
-        - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<capability-path>/spec.md`. Use kebab-case for path segments you introduce (e.g., `user-auth` or `identity/user-auth`) and follow the project's existing spec organization.
-        - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Use the exact existing path under `openspec/specs/`. Leave empty if no requirement changes.
-      - **Impact**: затронутые пользователи, процессы или части системы только
-        на уровне scope.
+      - **What Changes**: намерение, ожидаемый результат и non-goals.
+      - **Capabilities**:
+        - **New Capabilities**: exact `specs/<capability-path>/spec.md`; новые path
+          segments используют kebab-case и существующую organization.
+        - **Modified Capabilities**: exact existing path под `openspec/specs/`
+          только при изменении Requirements.
+      - **Impact**: затронутые пользователи, процессы или части системы на уровне
+        scope, без implementation topology.
 
-      IMPORTANT: The Capabilities section is critical. It creates the contract between
-      proposal and specs phases. Research existing specs before filling this in.
-      Each capability listed here will need a corresponding spec file.
-
-      Every change must either declare at least one capability (new or
-      modified) or explicitly opt out of specs: `openspec validate` rejects a
-      change with zero deltas unless the change's `.openspec.yaml` sets
-      `skip_specs: true`. Use `skip_specs: true` only when no spec-level
-      behavior changes (pure refactor, tooling, docs) - specs describe
-      behavior, so if behavior does not change, no spec should change either.
-      Do not invent a requirement just to satisfy validation.
-
-      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.
+      Один Proposal формирует contract для downstream artifacts. Покажи его
+      Change Owner и остановись до explicit approval.
     requires: []
 
   - id: specs
@@ -56,129 +42,47 @@ artifacts:
     description: Observable behavior and invariants changed by the proposal
     template: spec.md
     instruction: |
-      Создай Delta Specs, определяющие, ЧТО наблюдаемо изменяется в системе.
+      Critical Rules:
+      - Создай behavior contract только для capabilities утверждённого Proposal:
+        observable inputs, outputs, errors и security/privacy/reliability/
+        compatibility constraints.
+      - Не добавляй intent вне Proposal, code/database/file structure, technology
+        choices, delivery steps или test procedure. Scenario задаёт WHEN/THEN
+        behavior; способ проверки выбирается позже.
+      - Создай один `specs/<capability-path>/spec.md` на каждый Proposal path.
+        New path следует Proposal; modified path точно совпадает с существующим
+        path под `<planningHome.root>/openspec/specs/` и не переименовывается.
+      - Используй только применимые `## ADDED Requirements`,
+        `## MODIFIED Requirements`, `## REMOVED Requirements` и
+        `## RENAMED Requirements`; не оставляй пустые operation sections.
+      - Каждый `### Requirement:` содержит SHALL/MUST и хотя бы один
+        `#### Scenario:` с `- **WHEN**` и `- **THEN**`.
+      - После explicit Proposal approval и записи запусти planning verifier.
+        Исправляй artifact только при `artifact-validation`; `invocation` и
+        `environment` не разрешают менять Delta Specs.
 
-      Spec является behavior contract, а не планом изменения кода.
+      Delta Operations:
+      - `ADDED`: новый Requirement.
+      - `MODIFIED`: скопируй из main spec полный existing Requirement block со
+        всеми Scenarios, затем измени behavior; heading совпадает точно.
+      - `REMOVED`: добавь **Reason** и **Migration**.
+      - `RENAMED`: только heading rename в формате `FROM:` / `TO:`.
 
-      Good spec content:
-      - Observable behavior users or downstream systems rely on
-      - Inputs, outputs, and error conditions
-      - External constraints (security, privacy, reliability, compatibility)
-      - Scenarios that can be tested or explicitly validated
+      New Capability:
+      Добавь `## Purpose` из 1–2 предложений (не менее 50 characters). Archive
+      переносит его в новую main spec; без него появляется ручной `TBD`. Для
+      existing capability `Purpose` в delta не добавляй. Existing Purpose меняй
+      прямо в main spec под `planningHome.root` отдельным явно разрешённым
+      изменением. `planningHome.root` уже разрешает store-backed или local root;
+      не вычисляй path самостоятельно.
 
-      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, а способ проверки выбирается позднее.
+      `skip_specs: true` допустим только при отсутствии Proposal capabilities и
+      delta files. Specs должны быть проверяемыми, но Scenario не означает
+      обязательный unit test: уровень проверки определяется риском.
 
-      Quick test: if the implementation can change without changing externally
-      visible behavior, it likely does not belong in the spec.
-
-      Create one spec file per capability listed in the proposal's Capabilities section.
-      `<capability-path>` is the spec directory relative to `specs/` (for example,
-      `user-auth` or `identity/user-auth`). Preserve the full path:
-      - New capabilities: use the exact path from the proposal at `specs/<capability-path>/spec.md`. Any path segment newly introduced in the proposal must be kebab-case. Follow the project's existing organization; do not add a new domain level when the project uses a flat layout.
-      - Modified capabilities: use the exact existing path from `openspec/specs/<capability-path>/` when creating the delta at `specs/<capability-path>/spec.md`. Do not move or rename the capability.
-
-      There must be at least one spec file unless the change's `.openspec.yaml`
-      sets `skip_specs: true` (no spec-level behavior change) - `openspec validate`
-      rejects a zero-delta change without that marker. If the proposal lists no
-      capabilities and `skip_specs` is not set, revisit the proposal first.
-
-      Delta operations (use ## headers):
-      - **ADDED Requirements**: New capabilities
-      - **MODIFIED Requirements**: Changed behavior - MUST include full updated content
-      - **REMOVED Requirements**: Deprecated features - MUST include **Reason** and **Migration**
-      - **RENAMED Requirements**: Name changes only - use FROM:/TO: format
-
-      Format requirements:
-      - Each requirement: `### Requirement: <name>` followed by description
-      - Use SHALL/MUST for normative requirements (avoid should/may)
-      - Each scenario: `#### Scenario: <name>` with WHEN/THEN format
-      - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
-      - Every requirement MUST have at least one scenario.
-
-      New capabilities only: start the delta spec with a `## Purpose` section -
-      one or two sentences (50+ characters, or `openspec validate --strict`
-      reports it as too brief) describing what the capability is for. Archive
-      copies it into the main spec it creates; without it the new main spec is
-      left with a `TBD ... Update Purpose after archive` placeholder to fill in
-      by hand. Do NOT add `## Purpose` to a delta for an existing capability -
-      that spec already has one and the delta's is ignored. To change an
-      existing capability's Purpose - including a leftover `TBD` placeholder -
-      edit `<planningHome.root>/openspec/specs/<capability-path>/spec.md`
-      directly. `planningHome.root` comes from the `openspec instructions ...
-      --json` response. Always use it rather than a repo-relative path: it
-      resolves to the store whenever the change lives in one - whether that
-      came from `--store`, a project `store:` pointer, or a global default
-      store - and to the current repository otherwise. Do not try to work out
-      which case applies; the field already has.
-
-      MODIFIED requirements workflow:
-      1. Locate the existing requirement in `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (the same store-aware root as above)
-      2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios)
-      3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior
-      4. Ensure header text matches exactly (whitespace-insensitive)
-
-      Common pitfall: Using MODIFIED with partial content loses detail at archive time.
-      If adding new concerns without changing existing behavior, use ADDED instead.
-
-      Compact operation examples:
-      ```
-      # ADDED in a new capability: include Purpose.
-      ## Purpose
-
-      Lets users take their data out of the product in a portable format.
-
-      ## ADDED Requirements
-
-      ### Requirement: User can export data
-      The system SHALL allow users to export their data in CSV format.
-
-      #### Scenario: Successful export
-      - **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.
+      Покажи Delta Specs Change Owner и остановись до explicit approval. Если
+      обнаружилось изменение intent, вернись к Proposal и инвалидируй downstream
+      approvals.
     requires:
       - proposal
 
@@ -187,58 +91,45 @@ artifacts:
     description: Architectural implementation approach and delivery decisions
     template: design.md
     instruction: |
-      Создай Design, объясняющий, КАК архитектурно выполнить утверждённые
-      Delta Specs.
+      Critical Rules:
+      - Создай архитектурный способ выполнить утверждённые Delta Specs крупными
+        решениями, rationale, alternatives, risks и migration order.
+      - Не добавляй observable behavior вне Specs, не пересказывай upstream
+        artifacts и не пиши file-by-file checklist, verification commands,
+        будущие results, commits или Completion Evidence.
+      - Разреши до сохранения любой вопрос, который меняет Specs, approach или
+        Tasks. `Open Questions` оставляет только genuinely deferrable unknowns.
+      - После explicit Delta Specs approval и записи запусти planning verifier.
+        Исправляй Design только при `artifact-validation`; `invocation` и
+        `environment` требуют исправить вызов или prerequisite.
 
-      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:
-        они фиксируются только после наблюдаемого выполнения.
+      Required Shape:
+      - **Context**: current state и constraints подхода.
+      - **Goals / Non-Goals**: технические границы.
+      - **Decisions**: ключевые решения, rationale и alternatives.
+      - **Delivery Map**: ровно `frontend`, `backend`, `specs`, `docs`; каждая
+        area имеет `affected` outcome или конкретный `N/A` reason. `specs` всегда
+        `affected`.
+      - **Contract Gate Decision**: `runtime-openapi` = `required`, только когда
+        меняются обе стороны API contract; иначе конкретный `N/A`.
+      - **Risks / Trade-offs** и **Migration Plan**.
+      - В Migration Plan — `### Rollback Contract`: `required` с Trigger,
+        Actions, Data safety, Verification для auth/security, data integrity/
+        migration, public contract или другого труднообратимого решения; иначе
+        `N/A` с конкретным Reason.
 
-      Обязательные разделы:
-      - **Context**: только текущее состояние и ограничения подхода.
-      - **Goals / Non-Goals**: технические границы, не пересказ Proposal.
-      - **Decisions**: крупные решения, rationale и рассмотренные alternatives.
-      - **Delivery Map**: ровно frontend, backend, specs и docs; для каждой
-        области `affected` с ожидаемым архитектурным результатом либо `N/A` с
-        конкретной причиной. `specs` всегда affected. Здесь же зафиксируй
-        Contract Gate Decision для `runtime-openapi`: `required`, только когда
-        change затрагивает обе стороны API contract, либо `N/A` с причиной.
-      - **Risks / Trade-offs**: риск и mitigation.
-      - **Migration Plan**: порядок поставки и rollback, если применимо.
+      Solution Assessment:
+      Включи section внутри Design, если change вводит или существенно заменяет
+      auth, security, storage, external integration, observability, caching,
+      concurrency, shared infrastructure/tooling либо другое дорогостоящее
+      необратимое решение. Сравни mature options по fit, maturity, security,
+      operating cost, constraints и migration cost. Custom implementation
+      допустима только после конкретной несовместимости alternatives. Не создавай
+      отдельный assessment artifact.
 
-      Внутри 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 либо содержит
-      другое дорогостоящее необратимое решение. Сравни зрелые готовые решения
-      по fit, maturity, security, operating cost, constraints и migration cost.
-      Custom implementation допустима только после фиксации несовместимости
-      подходящих alternatives и принятых рисков. Не создавай отдельный artifact.
-
-      **Open Questions** допустим только для неизвестного, которое не меняет
-      Specs, выбранный подход или Tasks. Иначе остановись и запроси решение
-      владельца до сохранения Design.
-
-      Open questions are for genuinely deferrable unknowns, not decisions you
-      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. После
-      записи выполни `bash specs/scripts/verify-openspec-planning.sh <change>`
-      и исправь технические ошибки до запроса approval. Если Design показывает
-      несовместимость с intent или behavior, остановись, вернись к самому
-      раннему затронутому artifact и инвалидируй downstream approvals.
+      Покажи Design Change Owner и остановись до explicit approval. Если approach
+      несовместим с intent или behavior, вернись к самому раннему затронутому
+      artifact и инвалидируй downstream approvals.
     requires:
       - specs
 
@@ -247,76 +138,46 @@ artifacts:
     description: Implementation checklist with trackable tasks
     template: tasks.md
     instruction: |
-      Создай implementation checklist, достаточный для выполнения Design и
-      Delta Specs. Это конкретное DO, а не ещё один архитектурный документ.
+      Critical Rules:
+      - Создай dependency-ordered implementation checklist только после explicit
+        Design approval. Формат каждого item:
+        `- [ ] X.Y [frontend|backend|specs|docs|workspace] action`.
+      - Каждый checkbox имеет ровно одну indented `- **Covers:**` и одну
+        `- **Verification:**` line, одного owner и помещается в одну рабочую
+        сессию.
+      - `Covers` содержит exact
+        `` `capability-path` — `Requirement heading` `` pairs либо
+        `` `N/A` — reason ``. Каждый Delta Requirement покрыт хотя бы одной task;
+        parallel requirement IDs не вводятся.
+      - `N/A` reason объясняет отсутствие самостоятельного observable behavior,
+        техническую необходимость и связь с утверждённым Design или delivery.
+        Не оставляй template placeholder. Смысл проверяется owner review, а не
+        text heuristic.
+      - Owner repository обязан быть `affected` в Delivery Map. Cross-repository
+        implementation разделяй. `workspace` владеет только orchestration или
+        verification и всегда использует содержательный `N/A`.
+      - Для каждой affected area добавь owned implementation и canonical gate.
+        Не создавай empty commit. Planned Verification задаёт command,
+        observable check или delivered artifact, но не будущий result.
+      - Новое behavior возвращает change в Specs; новое architecture — в Design;
+        multi-owner или vague task исправляется в Tasks. Не добавляй commits,
+        archive path или post-archive Completion Evidence.
+      - После записи запусти planning verifier. Исправляй Tasks только при
+        `artifact-validation`; `invocation` и `environment` не разрешают менять
+        checklist.
 
-      Before writing tasks, check design.md for Open Questions. If any of them
-      would change what gets built, resolve them with the user first - do not
-      bake an unstated assumption into the task list.
+      Testing:
+      Автоматические tests обязательны для security/privacy, денежных расчётов,
+      data integrity/migration, concurrency, public contracts, critical journeys
+      и подтверждённых regressions. DTO без логики, declarative structure, thin
+      adapter, прямолинейная orchestration, hygiene script и third-party behavior
+      используют существующий integration/contract gate, если нет собственного
+      branching, transformation, invariant или regression. Перед custom work в
+      mandatory assessment area включи утверждённый Solution Assessment action.
 
-      **IMPORTANT: Follow the template below exactly.** The apply phase parses
-      checkbox format to track progress. Tasks not using `- [ ]` won't be tracked.
-
-      Правила:
-      - Группируй задачи под numbered `##` headings и располагай по dependencies.
-      - Каждая задача 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: команду,
-        проверку наблюдаемого поведения или delivered artifact.
-      - Автоматические тесты обязательны для security/privacy, денежных
-        расчётов, data integrity/migration, concurrency, public contracts,
-        critical journeys и подтверждённых regressions.
-      - Не требуй отдельный unit test только из-за изменения файла. DTO без
-        логики, declarative structures, thin adapters, прямолинейная
-        orchestration, hygiene scripts и third-party behavior проверяются
-        существующим integration/contract gate, если нет собственного
-        branching, transformation, invariant или regression.
-      - Перед custom implementation в обязательных областях включи действие по
-        утверждённому Solution Assessment из Design.
-
-      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. Delivery
-
-      - [ ] 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.
+      Group tasks под numbered `##` headings. Покажи Tasks Change Owner и
+      остановись до explicit approval. Если checklist требует новое behavior или
+      architecture, вернись к Specs или Design и инвалидируй Tasks approval.
     requires:
       - design
 
@@ -324,25 +185,25 @@ apply:
   requires: [ tasks ]
   tracks: tasks.md
   instruction: |
-    Сначала проверь exact OpenSpec version contract. Работай только с change в
-    canonical store `wealth-ledger-specs` и не создавай parallel planning root.
-    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.
+    Critical Rules:
+    - Apply допустим только после explicit approvals Proposal, Delta Specs,
+      Design и Tasks. Проверь exact OpenSpec version, canonical store
+      `wealth-ledger-specs` и planning verifier до implementation.
+    - Прочитай каждый path из `contextFiles`, возвращённых native OpenSpec apply
+      instructions, затем applicable repository-local `AGENTS.md` affected areas.
+      Не вычисляй planning paths и не создавай второй context map.
+    - Выполняй pending tasks по dependencies. Запускай planned Verification и
+      отмечай checkbox только после observed success.
+    - Feedback routing: intent/scope → Proposal; observable behavior → Delta
+      Specs; architecture/rollback → Design; decomposition/ownership/coverage →
+      Tasks. Останови downstream work, сообщи evidence и инвалидируй approvals от
+      самого раннего затронутого artifact.
+    - Механическая правка ограничена Markdown heading, typo без изменения
+      нормативного смысла или table alignment. Requirement wording, Scenario,
+      architecture и planned Verification являются semantic changes и требуют
+      соответствующего reapproval.
+    - `artifact-validation` разрешает исправить указанную planning form;
+      `invocation` требует исправить вызов; `environment` — prerequisite.
+      Последние два класса не разрешают менять planning artifact.
+    - Structural validation не заменяет semantic verification и independent
+      read-only review.

openspec/schemas/wealth-ledger-sdd/templates/spec.md

@@ -1,11 +1,17 @@
-## Purpose
-<!-- New capabilities only: one or two sentences (50+ characters) on what this capability is for. Delete this section for an existing capability. -->
+<!--
+Choose only the sections this delta needs; delete this guide before approval.
 
-## ADDED Requirements
+New capability only: add `## Purpose` with 1–2 sentences (50+ characters).
+Existing capability: do not add Purpose.
 
-### Requirement: <!-- requirement name -->
-<!-- requirement text -->
+Supported operations:
+- `## ADDED Requirements`: new complete Requirement blocks.
+- `## MODIFIED Requirements`: full existing Requirement blocks with every
+  surviving Scenario, then edited behavior.
+- `## REMOVED Requirements`: Requirement heading plus **Reason** and **Migration**.
+- `## RENAMED Requirements`: `FROM:` and `TO:` heading pairs only.
 
-#### Scenario: <!-- scenario name -->
-- **WHEN** <!-- condition -->
-- **THEN** <!-- expected outcome -->
+Every Requirement uses `### Requirement: <name>`, SHALL/MUST, and at least one
+`#### Scenario: <name>` with `- **WHEN**` and `- **THEN**`.
+Do not leave empty operation sections.
+-->