feat: harden OpenSpec SDD workflow

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

@@ -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.

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

@@ -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

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

@@ -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 -->