schema: wealth-ledger-sdd-v2

context: |
  WealthLedger — multi-repository workspace. The `main` repository is the workspace
  root and contains sibling repositories `frontend/`, `backend/`, `docs/` and `specs/`.
  OpenSpec configuration, schemas, changes and canonical behavior specs live only in
  `specs/openspec/` and are accessed as store `wealth-ledger-specs`. There is no
  `openspec/` directory or `config.yaml` in `main`, `frontend`, `backend` or `docs`.
  When an OpenSpec command is invoked from the workspace root, target the canonical
  store explicitly when that command supports store selection.
  New changes use `wealth-ledger-sdd-v2`; active changes explicitly pinned to
  `wealth-ledger-sdd` keep their original proposal → specs → design → tasks → apply
  lifecycle and existing approvals until completion. Never infer approval from
  the existence of an artifact. Schema selection comes from each change's
  `.openspec.yaml`, not from the current default. The Change Owner is the Product
  Owner for product behavior and the Engineering Owner for technical/process changes.
  A session handoff never stores requirements, design or tasks and never proves an
  approval; a new session without an explicitly confirmed approval does not start
  downstream work. Versioned planning, spec, task and design artifacts live only in
  `specs/openspec`, never in framework-specific folders elsewhere.
  Canonical specs are grouped by domain as `specs/<domain>/<capability>/spec.md`;
  a delta uses the same path. Process rules belong to workspace conventions, this
  config and schemas, not to canonical specs.

  Repository responsibilities and sources of truth:
  - `main` (`./`): workspace instructions, shared configuration, development Compose
    and release/workspace orchestration. It MUST NOT contain product feature code.
  - `frontend/`: React/Vite product implementation.
  - `backend/`: NestJS product API, Prisma data model and SQLite persistence.
  - `docs/`: canonical AS-IS product and architecture knowledge. Current architecture,
    integrations and durable diagrams describe the system as it exists now; historical
    architectural rationale is preserved in ADRs and archived changes.
  - `specs/`: OpenSpec changes plus canonical behavior specs. Canonical specs contain
    normative observable behavior only, not durable implementation documentation.
  - Future `qa/`: Playwright/E2E automation when the repository actually exists.

  Contract authority:
  - For v2 changes, new or changed cross-system contracts are planned contract-first
    in the change's `system-analysis/contracts/` before implementation.
  - After implementation, backend-generated OpenAPI is the executable/current HTTP API
    contract and MUST remain semantically compatible with the approved target contract.
  - Do not create a second permanent machine-readable API source of truth in canonical
    OpenSpec specs or docs.

  Documentation authority:
  - `docs/architecture/`, `docs/domains/`, `docs/integrations/` and related pages hold
    durable AS-IS explanations.
  - V2 changes select durable knowledge through approved `docs-impact`; legacy
    changes continue their approved delivery map. Change-specific reasoning,
    migration history and rejected options remain in the archived OpenSpec change
    unless an ADR is explicitly required.

  Language and normative terminology:
  - Human-facing project artifacts are written in Russian, while exact OpenSpec headings,
    tokens, commands, identifiers and machine-readable contract syntax remain unchanged.
  - Normative keywords follow BCP 14 (RFC 2119 + RFC 8174). `MUST`, `MUST NOT`,
    `REQUIRED`, `SHALL`, `SHALL NOT`, `SHOULD`, `SHOULD NOT`, `RECOMMENDED`,
    `NOT RECOMMENDED`, `MAY` and `OPTIONAL` have normative meaning only when written
    in uppercase. Lowercase forms have their ordinary-language meaning.
  - Do not use uppercase BCP 14 keywords merely for emphasis. Use them only when the
    statement intentionally imposes a normative obligation or permitted variation.

  A downstream artifact cannot silently change upstream semantics: route changes
  to the earliest affected artifact and reapprove only its affected dependents.
  Native OpenSpec sync/archive owns behavior delta → canonical specs; docs updates
  follow approved delivery tasks, not an automatic copy of system analysis.

  Repository-local `AGENTS.md` files remain authoritative for implementation conventions
  inside their repositories. Load only the affected repository instructions and relevant
  code/docs; do not scan the entire workspace without need.

operations:
  archive:
    guidance:
      - Keep the change's selected schema and explicit approvals; do not impose v2-only artifacts on legacy changes.
      - Complete implementation, developer checks, independent verification and canonical documentation before archive. For v2 changes, also check applicable QA Analysis, docs-impact and target contract compatibility with backend-generated OpenAPI.
      - Native OpenSpec sync/archive updates canonical behavior specs, not implementation documentation.
      - Independent verification is read-only (no edits to code, specs or tasks) and returns PASS, FAIL or SPEC_ISSUE routed to the earliest affected artifact. For UI changes it compares implemented screens, states, interactions and responsive behavior with the approved visual package.
      - Archive only after the latest PASS with no Critical or Important findings and no relevant input changes since; archive routes blockers instead of fixing them.
      - Completion evidence is written after the work and records, per affected repo, the commit, exact commands with observed results, N/A reasons and the review outcome. Never create empty commits to mark an unaffected repo.