docs(specs): archive OpenSpec resilience change

openspec/changes/archive/2026-08-26-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/archive/2026-08-26-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/archive/2026-08-26-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/archive/2026-08-26-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/archive/2026-08-26-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/archive/2026-08-26-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.