From d5a0e942a39441998e7815bcc5b81525d49b4422 Mon Sep 17 00:00:00 2001
From: Sergey Krylov <ksv741@mail.ru>
Date: Fri, 30 Oct 2026 08:57:45 +0300
Subject: [PATCH 1/3] refactor: drop check.cjs and translate
 wealth-ledger-sdd-lab schema (WealthLedger/specs#66)

Readiness rules move to a manual checklist with fixed gate semantics.
Analysis artifacts live under analysis/; templates and instructions are in Russian.
---
 .../schemas/wealth-ledger-sdd-lab/check.cjs   | 294 ------
 .../schemas/wealth-ledger-sdd-lab/schema.yaml | 911 ++++++++++--------
 .../templates/data-mapping.md                 |  18 +-
 .../wealth-ledger-sdd-lab/templates/design.md |  30 +-
 .../templates/docs-impact.md                  |   4 +-
 .../templates/failure-model.md                |   9 +-
 .../wealth-ledger-sdd-lab/templates/nfr.md    |   9 +-
 .../templates/observability.md                |   9 +-
 .../templates/process-record.md               |  54 +-
 .../templates/proposal.md                     |  13 +-
 .../templates/qa-analysis.md                  |  20 +-
 .../templates/research.md                     |  10 +-
 .../templates/security-analysis.md            |  10 +-
 .../wealth-ledger-sdd-lab/templates/spec.md   |  40 +-
 .../templates/system-analysis.md              |  27 +-
 .../wealth-ledger-sdd-lab/templates/tasks.md  |  28 +-
 .../templates/test-cases.md                   |  12 +-
 .../templates/ux-design.md                    |  17 +-
 18 files changed, 668 insertions(+), 847 deletions(-)
 delete mode 100644 openspec/schemas/wealth-ledger-sdd-lab/check.cjs

diff --git a/openspec/schemas/wealth-ledger-sdd-lab/check.cjs b/openspec/schemas/wealth-ledger-sdd-lab/check.cjs
deleted file mode 100644
index 834874a..0000000
--- a/openspec/schemas/wealth-ledger-sdd-lab/check.cjs
+++ /dev/null
@@ -1,294 +0,0 @@
-#!/usr/bin/env node
-// Deterministic checks for wealth-ledger-sdd-lab changes. OpenSpec CLI 1.13.1 has no conditional
-// artifacts, gate records or archive policy, so this file covers only what the CLI cannot.
-// It is the single source for profile, ordering, gate and readiness rules; schema.yaml points here.
-// Semantic quality (contradictions, invented facts, design fit) stays with reviewers.
-//
-// Usage: node check.cjs <plan|apply|archive> <change-name> [--root <openspec-root>]
-//   plan    — artifact consistency while planning; missing gates are notes, not errors.
-//   apply   — plan + every apply blocker is an error.
-//   archive — apply + all tasks done, G4 approved, lab retrospective.
-// Exit: 0 ok, 1 violations, 2 invocation/environment error.
-"use strict";
-const fs = require("node:fs");
-const path = require("node:path");
-
-const SA_MODULES = ["data-mapping", "failure-model", "nfr", "observability"];
-// Primary file of each conditional artifact, relative to the change directory.
-const PRIMARY = {
-  research: "research.md",
-  "ux-design": "ux-design.md",
-  "system-analysis": "system-analysis/system-analysis.md",
-  "data-mapping": "system-analysis/data-mapping.md",
-  "failure-model": "system-analysis/failure-model.md",
-  nfr: "system-analysis/nfr.md",
-  observability: "system-analysis/observability.md",
-  "security-analysis": "security-analysis.md",
-  "test-cases": "test-cases",
-  "docs-impact": "docs-impact.md",
-};
-const CONDITIONAL = Object.keys(PRIMARY);
-// A selected conditional input must exist before any of these files is written.
-const BEFORE_SOLUTION = ["design.md", "qa-analysis.md", "tasks.md"];
-const DOWNSTREAM = {
-  research: ["specs", ...BEFORE_SOLUTION],
-  "ux-design": BEFORE_SOLUTION,
-  "system-analysis": BEFORE_SOLUTION,
-  ...Object.fromEntries(SA_MODULES.map((id) => [id, BEFORE_SOLUTION])),
-  "security-analysis": BEFORE_SOLUTION,
-  "test-cases": ["tasks.md"],
-  "docs-impact": ["tasks.md"],
-};
-// Gate that may approve each artifact. Complex changes approve system analysis at G2 (contract-first).
-const SA_IDS = ["system-analysis", ...SA_MODULES];
-const allowedGates = (id, complex, hasG2) => {
-  if (id === "proposal") return ["G1"];
-  if (id === "change-profile") return ["G1", "G2", "G3"]; // later profile changes need a recorded decision
-  if (id === "specs") return hasG2 ? ["G2"] : ["G3"];
-  if (SA_IDS.includes(id)) return complex ? ["G2"] : hasG2 ? ["G2", "G3"] : ["G3"];
-  return ["G3"];
-};
-const NOT_APPROVED = new Set(["research", "process-record"]); // input context / the log itself
-const REF = /`([a-z0-9][a-z0-9/-]*)`\s*[—–-]\s*`([^`]+)`/g;
-
-const fail = (msg) => { console.error(msg); process.exit(2); };
-const args = process.argv.slice(2);
-const [mode, changeName] = args;
-if (!["plan", "apply", "archive"].includes(mode) || !changeName) {
-  fail("Usage: node check.cjs <plan|apply|archive> <change-name> [--root <openspec-root>]");
-}
-const rootIdx = args.indexOf("--root");
-if (rootIdx > 0 && !args[rootIdx + 1]) fail("--root needs a path");
-const root = path.resolve(rootIdx > 0 ? args[rootIdx + 1] : path.join(__dirname, "..", ".."));
-const changeDir = path.join(root, "changes", changeName);
-if (!fs.existsSync(changeDir)) fail(`Change directory not found: ${changeDir}`);
-
-const errors = [];
-const warnings = [];
-const notes = [];
-const rel = (p) => path.relative(changeDir, p);
-const read = (p) => fs.readFileSync(p, "utf8");
-const at = (p) => path.join(changeDir, p);
-const walk = (dir) => fs.existsSync(dir)
-  ? fs.readdirSync(dir, { withFileTypes: true }).flatMap((e) =>
-    e.isDirectory() ? walk(path.join(dir, e.name)) : [path.join(dir, e.name)])
-  : [];
-const present = (p) => p === "test-cases" || p === "specs"
-  ? walk(at(p)).some((f) => f.endsWith(".md"))
-  : fs.existsSync(at(p));
-const mdFiles = walk(changeDir).filter((f) => f.endsWith(".md"));
-const strip = (s) => (s ?? "").replace(/`/g, "").trim();
-// Columns: fixed count, the last cell keeps any `|` it contains.
-const tableRows = (text, heading, columns) => {
-  const section = text.split(/^## /m).find((s) => s.startsWith(heading));
-  if (!section) return null;
-  return section.split("\n").filter((l) => /^\|/.test(l)).slice(2).map((l) => {
-    const parts = l.replace(/^\|/, "").replace(/\|\s*$/, "").split("|");
-    return [...parts.slice(0, columns - 1), parts.slice(columns - 1).join("|")].map((c) => c.trim());
-  });
-};
-
-finishIfMissing();
-const record = read(at("process-record.md"));
-
-// 1. Unfilled templates.
-for (const f of mdFiles) {
-  if (read(f).includes("<!-- guide:")) errors.push(`${rel(f)}: unfilled template guide comment remains`);
-}
-
-// 2. Mode, class, Change Profile.
-const labMode = (record.match(/\*\*Mode:\*\*\s*(lab|delivery)\b/i) || [])[1]?.toLowerCase();
-if (!labMode) errors.push("process-record.md: **Mode:** must be `lab` or `delivery`");
-const klass = (record.match(/\*\*Class:\*\*\s*(standard|complex)\b/i) || [])[1]?.toLowerCase();
-if (!klass) errors.push("process-record.md: **Class:** must be `standard` or `complex`");
-const complex = klass === "complex";
-const hasG2 = labMode === "lab" || complex;
-
-const profile = new Map();
-for (const [rawId, selected, reason] of tableRows(record, "Change Profile", 3) ?? []) {
-  const id = strip(rawId);
-  if (!CONDITIONAL.includes(id)) { errors.push(`Change Profile: unknown artifact '${id}'`); continue; }
-  if (!/^(yes|no)$/i.test(strip(selected))) errors.push(`Change Profile: '${id}' Selected must be yes|no`);
-  if (!reason) errors.push(`Change Profile: '${id}' needs a trigger or reason`);
-  profile.set(id, /^yes$/i.test(strip(selected)));
-}
-const pending = [];
-for (const id of CONDITIONAL) {
-  if (!profile.has(id)) { errors.push(`Change Profile: no decision for '${id}'`); continue; }
-  const has = present(PRIMARY[id]);
-  if (profile.get(id) && !has) {
-    const consumer = DOWNSTREAM[id].find(present);
-    if (consumer) errors.push(`'${id}' is selected but ${PRIMARY[id]} does not exist while ${consumer} was already written`);
-    else pending.push(id);
-  }
-  if (!profile.get(id) && has) errors.push(`'${id}' is not selected but ${PRIMARY[id]} exists; select it through a gate decision or remove the file`);
-}
-for (const id of SA_MODULES) {
-  if (profile.get(id) && !profile.get("system-analysis")) errors.push(`'${id}' requires system-analysis to be selected`);
-}
-if (fs.existsSync(at("system-analysis")) && !present(PRIMARY["system-analysis"])) {
-  errors.push("system-analysis/ exists without system-analysis/system-analysis.md");
-}
-
-// 3. Requirement references resolve; delta requirements are covered.
-const skipSpecs = present(".openspec.yaml") && /^skip_specs:\s*true/m.test(read(at(".openspec.yaml")));
-if (skipSpecs && present("specs")) errors.push("skip_specs: true but specs/ contains delta files");
-const deltaReqs = [];
-const known = new Map();
-const removed = new Set();
-const addKnown = (cap, h) => (known.get(cap) ?? known.set(cap, new Set()).get(cap)).add(h);
-const key = (cap, req) => `${cap}\u0000${req}`;
-for (const f of walk(at("specs")).filter((x) => x.endsWith("spec.md"))) {
-  const cap = path.relative(at("specs"), path.dirname(f)).split(path.sep).join("/");
-  let op = null;
-  const seen = new Set();
-  for (const line of read(f).split("\n")) {
-    op = (line.match(/^## (ADDED|MODIFIED|REMOVED|RENAMED) Requirements/) || [])[1] ?? op;
-    const req = (line.match(/^### Requirement:\s*(.+?)\s*$/) || [])[1];
-    if (req) {
-      if (seen.has(req)) errors.push(`specs/${cap}/spec.md: duplicate Requirement '${req}'`);
-      seen.add(req);
-      if (op === "REMOVED") removed.add(key(cap, req));
-      else addKnown(cap, req);
-      if (op === "ADDED" || op === "MODIFIED") deltaReqs.push(key(cap, req));
-    }
-    const to = (line.match(/^-?\s*TO:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/) || [])[1];
-    if (to) addKnown(cap, to);
-  }
-}
-for (const f of walk(path.join(root, "specs")).filter((x) => x.endsWith("spec.md"))) {
-  const cap = path.relative(path.join(root, "specs"), path.dirname(f)).split(path.sep).join("/");
-  for (const m of read(f).matchAll(/^### Requirement:\s*(.+?)\s*$/gm)) {
-    if (!removed.has(key(cap, m[1]))) addKnown(cap, m[1]);
-  }
-}
-const refs = (text) => [...text.matchAll(REF)].map((m) => ({ cap: m[1], req: m[2] }));
-for (const f of mdFiles.filter((x) => !rel(x).startsWith(`specs${path.sep}`))) {
-  for (const { cap, req } of refs(read(f))) {
-    if (!known.get(cap)?.has(req)) errors.push(`${rel(f)}: unknown requirement reference \`${cap}\` — \`${req}\``);
-  }
-}
-const tasksPath = at("tasks.md");
-const tasksText = fs.existsSync(tasksPath) ? read(tasksPath) : "";
-const coversLines = tasksText.split("\n").filter((l) => /\*\*Covers:\*\*/.test(l)).join("\n");
-const taskCover = new Set(refs(coversLines).map((r) => key(r.cap, r.req)));
-const qaText = [at("qa-analysis.md"), ...walk(at("test-cases"))].filter(fs.existsSync).map(read).join("\n");
-const qaCover = new Set(refs(qaText).map((r) => key(r.cap, r.req)));
-for (const k of deltaReqs) {
-  const label = k.replace("\u0000", "` — `");
-  if (tasksText && !taskCover.has(k)) errors.push(`tasks.md: delta requirement \`${label}\` has no task Covers`);
-  if (present("qa-analysis.md") && !qaCover.has(k)) warnings.push(`qa-analysis: delta requirement \`${label}\` has no verification reference (allowed only with a stated risk reason)`);
-}
-if (!skipSpecs && present("specs") && deltaReqs.length === 0) warnings.push("no ADDED/MODIFIED requirements found in delta specs");
-
-// 4. Test case identity and traceability.
-const tcIds = new Set();
-for (const f of walk(at("test-cases")).filter((x) => x.endsWith(".md"))) {
-  for (const block of read(f).split(/^###\s+(?=TC-)/m).slice(1)) {
-    const id = block.split(/\s/)[0];
-    if (tcIds.has(id)) errors.push(`${rel(f)}: duplicate test case id ${id}`);
-    tcIds.add(id);
-    if (!refs(block).length) errors.push(`${rel(f)}: test case ${id} has no requirement reference`);
-  }
-}
-
-// 5. Contracts and diagrams are referenced, JSON parses, required task kinds exist.
-const saText = walk(at("system-analysis")).filter((f) => f.endsWith(".md")).map(read).join("\n");
-const contracts = walk(at("system-analysis/contracts"));
-for (const f of [...contracts, ...walk(at("system-analysis/diagrams"))]) {
-  if (!saText.includes(path.basename(f))) errors.push(`${rel(f)}: not referenced from any system-analysis/*.md`);
-  if (f.endsWith(".json")) {
-    try { JSON.parse(read(f)); } catch (e) { errors.push(`${rel(f)}: invalid JSON (${e.message})`); }
-  }
-}
-const taskLines = tasksText.split("\n").filter((l) => /^\s*[-*+]\s*\[.?\]/.test(l));
-if (tasksText) {
-  if (!taskLines.some((l) => /Independent Review:/.test(l))) errors.push("tasks.md: no `Independent Review:` task");
-  if (contracts.length && !taskLines.some((l) => /Contract Parity:/.test(l))) errors.push("tasks.md: contracts exist but no `Contract Parity:` task");
-  if (profile.get("docs-impact") === false && !/^## Docs Impact/m.test(tasksText)) {
-    errors.push("tasks.md: docs-impact not selected, so a `## Docs Impact` section (changes or no-change reason) is required");
-  }
-}
-
-// 6. Gate Log: chronological; invalidating Gn withdraws Gn and every later gate.
-const gates = new Map();
-const order = [];
-for (const [rawGate, , scope, validation, , decision] of tableRows(record, "Gate Log", 6) ?? []) {
-  const id = (strip(rawGate).match(/^G[1-4]\b/) || [])[0];
-  if (!id) continue;
-  if (/^invalidated\b/i.test(decision)) {
-    for (const g of [...gates.keys()]) if (g >= id) gates.delete(g);
-    continue;
-  }
-  if (!/^approved\b/i.test(decision)) continue;
-  if (!/"[^"]+"|«[^»]+»/.test(decision)) errors.push(`Gate ${id}: approval must quote the Change Owner decision`);
-  if (!validation) errors.push(`Gate ${id}: approval has no validation evidence`);
-  const prior = ["G1", "G2", "G3", "G4"].filter((g) => g < id && (g !== "G2" || hasG2));
-  if (prior.some((g) => !gates.has(g))) errors.push(`Gate ${id}: approved before ${prior.filter((g) => !gates.has(g)).join(", ")}`);
-  const ids = strip(scope).split(/[,\s]+/).filter(Boolean);
-  for (const a of ids) {
-    if (id !== "G4" && !allowedGates(a, complex, hasG2).includes(id)) errors.push(`Gate ${id}: '${a}' must be approved at ${allowedGates(a, complex, hasG2).join(" or ")}`);
-  }
-  gates.set(id, ids);
-  order.push(id);
-}
-if (gates.has("G1") && !gates.get("G1").includes("change-profile")) errors.push("Gate G1: scope must include change-profile");
-
-// 7. Readiness.
-const artifactPaths = [
-  ["proposal", "proposal.md"], ["specs", "specs"], ["design", "design.md"],
-  ["qa-analysis", "qa-analysis.md"], ["tasks", "tasks.md"],
-  ...CONDITIONAL.map((id) => [id, PRIMARY[id]]),
-];
-const approvedScope = new Set([...gates.values()].flat());
-const required = hasG2 ? ["G1", "G2", "G3"] : ["G1", "G3"];
-const missingGates = required.filter((g) => !gates.has(g));
-const unapproved = artifactPaths.filter(([id, p]) => !NOT_APPROVED.has(id) && present(p) && !approvedScope.has(id)).map(([id]) => id);
-const blockers = [
-  ...(tasksText ? [] : ["tasks.md missing"]),
-  ...(missingGates.length ? [`missing gates: ${missingGates.join(", ")}`] : []),
-  ...(unapproved.length ? [`not in any approved gate scope: ${unapproved.join(", ")}`] : []),
-  ...(pending.length ? [`selected but missing: ${pending.join(", ")}`] : []),
-];
-notes.push(`apply-ready: ${blockers.length || errors.length ? `no (${[...blockers, ...(errors.length ? ["errors"] : [])].join("; ")})` : "yes"}`);
-if (mode !== "plan") blockers.forEach((b) => errors.push(`apply blocker: ${b}`));
-
-const sequence = ["proposal", "process-record", "research", "specs", "ux-design", "system-analysis",
-  ...SA_MODULES, "security-analysis", "design", "qa-analysis", "test-cases", "docs-impact", "tasks"];
-const pathOf = Object.fromEntries([...artifactPaths, ["process-record", "process-record.md"]]);
-const next = sequence.find((id) => {
-  if (CONDITIONAL.includes(id) && !profile.get(id)) return false;
-  if (id === "specs" && skipSpecs) return false;
-  return !present(pathOf[id]);
-});
-notes.push(`next artifact: ${next ?? "none (planning complete for this profile)"}`);
-
-// 8. Archive readiness. Native archive treats any non-[x] marker as open, so descoped work is
-// removed from tasks.md by a gate decision and recorded in "Descoped Work".
-if (mode === "archive") {
-  for (const l of taskLines) if (!/\[x\]/i.test(l)) errors.push(`tasks.md: open task: ${l.trim()}`);
-  for (const [task, reason, gate] of tableRows(record, "Descoped Work", 3) ?? []) {
-    if (task && (!reason || !/^G[1-4]$/.test(strip(gate)))) errors.push(`Descoped Work '${task}': needs reason and approving gate`);
-  }
-  if (!gates.has("G4")) errors.push("Gate G4 Delivery Acceptance is not approved");
-  if (labMode === "lab") {
-    const retro = record.split(/^## /m).find((s) => s.startsWith("Retrospective")) ?? "";
-    if (!retro.replace(/^Retrospective.*\n/, "").trim()) errors.push("process-record.md: Retrospective is empty (lab mode)");
-    if ((tableRows(record, "Lab Journal", 9) ?? []).length < gates.size) warnings.push("Lab Journal has fewer rows than approved gates");
-  }
-}
-finish();
-
-function finishIfMissing() {
-  if (fs.existsSync(at("process-record.md"))) return;
-  errors.push("process-record.md is missing: Change Profile and Gate Log are required");
-  finish();
-}
-
-function finish() {
-  for (const n of notes) console.log(`note: ${n}`);
-  for (const w of warnings) console.log(`warning: ${w}`);
-  for (const e of errors) console.log(`error: ${e}`);
-  console.log(errors.length ? `FAIL ${mode} ${changeName}: ${errors.length} error(s)` : `OK ${mode} ${changeName}`);
-  process.exit(errors.length ? 1 : 0);
-}
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml b/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml
index 136b52a..b632641 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml
+++ b/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml
@@ -1,177 +1,241 @@
 name: wealth-ledger-sdd-lab
 version: 1
-description: Experimental Engineering Lab workflow - proposal + change profile → specs → selected analysis modules → design ∥ qa-analysis → tasks → apply, with 4 decision gates
+description: Экспериментальный Engineering Lab workflow — proposal + Change Profile → specs → выбранные analysis-артефакты → design ∥ qa-analysis → tasks → apply, 4 decision gates
 
-# CLI contract (OpenSpec 1.13.1): an artifact is complete when its `generates` path exists;
-# `requires` is a hard edge; there is no conditional artifact. Conditional artifacts below are
-# therefore never required by a mandatory artifact or by apply. Selection, ordering of selected
-# artifacts, gates and archive readiness are checked by `check.cjs` in this schema directory.
+# Контракт OpenSpec CLI: артефакт завершён, когда существует путь `generates`; `requires` — жёсткое ребро;
+# условных артефактов в CLI нет. Поэтому условные артефакты ниже не требуются ни обязательными
+# артефактами, ни apply. Выбор, порядок, gates и готовность — ручной Readiness Checklist в
+# instruction `process-record`. Исполняемых проверок у schema нет: gates рекомендательные, их
+# соблюдение обеспечивают основной агент и independent reviewer, а не CLI.
+# Раскладка change: в корне — proposal, process-record, specs/, design, tasks;
+# вся аналитика — в `analysis/`.
 
 artifacts:
   - id: proposal
     generates: proposal.md
-    description: Change Owner intent, scope, capabilities, evidence and open decisions
+    description: Намерение Change Owner — зачем, результат, scope, capabilities, evidence, открытые решения
     template: proposal.md
     instruction: |
-      Owner: Change Owner; draft — product-analyst. Gate: G1 Product Decision.
+      Владелец: Change Owner; черновик — product-analyst. Gate: G1 Product Decision.
 
-      Purpose:
-      Proposal фиксирует, зачем нужно изменение, какой результат ожидается, где
-      проходит scope и какие решения ещё не приняты. Это не requirements, не system
-      analysis и не design.
+      Назначение:
+      Proposal фиксирует, зачем нужно изменение, какой результат ожидается, где проходит
+      scope и какие решения ещё не приняты. Это не requirements, не system analysis и
+      не design.
 
-      Start of the lab lifecycle (обязательно до записи):
+      Старт lab lifecycle (до первой записи):
       - Change создаётся явно: `openspec new change <name> --schema wealth-ledger-sdd-lab
         --store wealth-ledger-specs`. Schema не становится default и не применяется к
         существующим changes.
-      - Small (локальный fix, известное behavior) не идёт в OpenSpec: правка canonical spec
-        в том же Issue. Lab schema принимает только Standard и Complex.
-      - Если существует research (`research.md` в change, Issue, внешний отчёт), прочитай
-        его выводы; Proposal ссылается на research в **Evidence**, а не копирует его.
-        Research может закончиться решением не делать change — тогда change не создаётся.
-      - Общий протокол (Change Profile, gates, делегирование сабагентам, `check.cjs`) —
-        instruction artifact `process-record`; он действует на каждой стадии.
+      - Small не идёт в OpenSpec: fix восстанавливает поведение, уже описанное canonical
+        spec (spec не меняется или уточняется без изменения смысла), — правка в том же
+        Issue. Fix, меняющий canonical behavior, — минимум `delivery` `standard`.
+        Lab schema принимает только Standard и Complex.
+      - Если есть research (`analysis/research.md`, Issue, внешний отчёт), прочитай его
+        выводы; Proposal ссылается на него в **Evidence**, а не копирует. Research может
+        закончиться решением не делать change — тогда change не создаётся.
+      - Общий протокол (Change Profile, gates, Readiness Checklist, делегирование) —
+        instruction `process-record`; он действует на каждой стадии. Прочитай его до
+        первой записи: `openspec instructions process-record`.
 
-      Read First:
-      - Релевантные canonical specs из `specs/openspec/specs/` и AS-IS pages `docs/`
+      Прочитай сначала:
+      - Релевантные canonical specs из `specs/openspec/specs/` и AS-IS страницы `docs/`
         (`overview.md`, `architecture/`, `domains/`, `integrations/`, `adr/`, `design/`).
-      - Code-level реализацию не исследуй глубже, чем нужно для scope/impact.
+      - Код изучай не глубже, чем нужно для scope и impact.
 
-      Critical Rules:
+      Правила:
       - Один Proposal = одно связное намерение; независимо поставляемое разделяй.
-      - Capabilities перечисляют каждую новую/изменяемую behavior spec точным path.
+      - Capabilities перечисляют каждую новую или изменяемую behavior spec точным path.
         Если observable behavior не меняется — `.openspec.yaml: skip_specs: true`.
-      - Breaking observable behavior помечай **BREAKING**.
+      - Ломающее observable behavior помечай **BREAKING**.
       - Evidence разделяет факты (с источником) и гипотезы.
       - Open Decisions: вопрос, кто решает, что блокирует. Вопрос, меняющий scope или
         capabilities, решается до G1.
 
-      MUST NOT Include:
-      - files/classes/functions/tables/ORM entities; libraries/frameworks/transport;
-        endpoint/payload/error-code contracts; diagrams; test plans; tasks/PR plan;
-        пиксельные UI-детали.
+      Не включай: файлы/классы/функции/таблицы/ORM-сущности; библиотеки/фреймворки/
+      транспорт; контракты endpoint/payload/error-code; диаграммы; тест-планы; tasks/
+      план PR; пиксельные детали UI.
 
-      Feedback Routing: research gap → research; всё остальное возвращается сюда.
+      Обратная связь: пробел в research → research; остальное возвращается сюда.
 
-      Validation:
+      Проверка:
       - `openspec validate <change> --store wealth-ledger-specs` (Why/What Changes);
-        structural success не является approval.
-      - Затем создай `process-record.md` (Change Profile) и предъяви G1 оба файла вместе.
+        структурный успех не является approval.
+      - Затем создай `process-record.md` (Change Profile) и предъяви на G1 оба файла.
     requires: []
 
   - id: research
-    generates: research.md
-    description: Optional product research used as input context; never approved as a requirement source
+    generates: analysis/research.md
+    description: Необязательное продуктовое исследование — входной контекст, не источник требований
     template: research.md
     instruction: |
-      Owner: product-researcher. Conditional: создавай только если Change Profile выбрал
-      `research`. Не требуется ни одним artifact и не блокирует apply. Не входит в gates:
-      это входной контекст, не утверждаемый artifact.
+      Владелец: product-researcher. Условный, пишется до proposal: research — вход
+      Proposal, поэтому создаётся раньше `proposal.md`, а не по Change Profile (Profile
+      появляется позже и лишь фиксирует факт: `yes` — `analysis/research.md` есть в
+      change, `no` — ссылка на внешний источник или причина). Не требуется ни одним
+      артефактом и не блокирует apply. В gates не входит: это контекст, не утверждаемый
+      артефакт.
 
       Trigger: новый продуктовый функционал, незнакомая предметная область, конкуренты и
       альтернативы, проверка гипотезы, высокая продуктовая неопределённость.
-      Если исследование уже существует вне change (Issue, `audit-results/`, отчёт),
-      не копируй его: Proposal ссылается на источник, Change Profile ставит `no` + ссылку.
-      Исследование, начатое до решения о change, живёт вне OpenSpec до G1.
+      Исследование уже есть вне change (Issue, `audit-results/`, отчёт) — не копируй,
+      Proposal ссылается на источник.
+      Research понадобился после G1 (новая неопределённость) — это Open Decision в
+      Proposal: research дописывается, Proposal обновляется, G1 инвалидируется.
 
-      Critical Rules:
-      - Каждое утверждение: [F] факт с источником, [I] интерпретация или [H] гипотеза.
+      Правила:
+      - Каждое утверждение помечено: [F] факт с источником, [I] интерпретация, [H] гипотеза.
       - Не выдумывай источники, цифры и пользователей; нет данных — так и напиши.
-      - Recommendation допускает «не делать» и «сузить scope».
+      - Рекомендация допускает «не делать» и «сузить scope».
 
-      MUST NOT Include: окончательные requirements, обязательные архитектурные решения,
-      contracts, tasks.
+      Не включай: окончательные requirements, обязательные архитектурные решения,
+      контракты, tasks.
 
-      Feedback Routing: выводы потребляет Proposal (Evidence, Scope, Open Decisions).
+      Обратная связь: выводы потребляет Proposal (Evidence, Scope, Open Decisions).
     requires: []
 
   - id: process-record
     generates: process-record.md
-    description: Change Profile, gate decisions, descoped work and lab journal for the change
+    description: Change Profile, решения gates, снятая работа и lab-журнал change
     template: process-record.md
     instruction: |
-      Owner: основной агент (оркестратор). Change Profile утверждает Change Owner на G1.
-      Это журнал процесса, а не planning authority: он не содержит requirements,
-      contracts или design.
+      Владелец: основной агент (оркестратор). Change Profile утверждает Change Owner на
+      G1. Это журнал процесса, а не planning authority: requirements, контрактов и
+      design здесь нет.
 
       ## Общий протокол lab schema (действует на каждой стадии)
 
-      Modes and Classes:
-      - **Mode** `lab` — целенаправленная практика: G2 обязателен, независимая проверка
-        на каждом gate, Lab Journal после каждой стадии, Retrospective перед archive,
-        условные artifacts можно выбирать ради названной практики.
-      - **Mode** `delivery` — минимально достаточный процесс: artifacts только по
-        risk-триггеру, qa-analysis компактный, Lab Journal необязателен.
+      Режимы и классы:
+      - **Mode** `lab` — целенаправленная практика: G2 обязателен, independent review на
+        каждом gate, Lab Journal после каждой стадии, Retrospective перед archive;
+        условные артефакты можно выбирать ради названной практики.
+      - **Mode** `delivery` — минимально достаточный процесс: артефакты только по
+        risk-trigger, qa-analysis компактный, Lab Journal необязателен.
       - **Class** `standard` | `complex`. Complex: межсистемно, деньги/синхронизация/
         данные, необратимые миграции или высокая неопределённость. Mode и Class
         независимы.
 
+      Шаблоны: HTML-комментарии в шаблонах — подсказки для автора. В готовом артефакте их
+      нет; удаляй до gate этого артефакта.
+
       Change Profile (обязательная таблица, все 10 строк):
-      - `yes` только при конкретном trigger из instruction artifact; в lab допустим
-        `yes` с названной практикой («lab: data mapping practice»).
-      - `no` с конкретной причиной. Пустой документ с «N/A» вместо `no` запрещён.
-      - Profile меняется только решением Change Owner, записанным строкой Gate Log
-        со scope `change-profile`; уже утверждённые gates при этом инвалидируются.
-      - Выбранный условный input пишется до artifact, который его потребляет
-        (research, ux-design, system-analysis и modules, security-analysis — до design,
-        qa-analysis и tasks; test-cases, docs-impact — до tasks).
+      - `yes` — только при конкретном trigger из instruction артефакта; в lab допустим
+        `yes` с названной практикой («lab: практика data mapping»).
+      - `no` — с конкретной причиной. Пустой документ с «N/A» вместо `no` запрещён.
+      - Profile меняется только решением Change Owner: строка текущего gate (G1–G3) со
+        Scope `change-profile`; все последующие gates при этом инвалидируются.
+      - Выбранный условный вход пишется раньше потребителя: research — до proposal;
+        ux-design, system-analysis, data-mapping, failure-model, nfr, observability,
+        security-analysis — до design, qa-analysis и tasks; test-cases, docs-impact —
+        до tasks.
 
-      Deterministic checks — `check.cjs` (из `specs/`):
-      `node openspec/schemas/wealth-ledger-sdd-lab/check.cjs <plan|apply|archive> <change>`.
-      Он единственный владелец правил profile/порядка/gates/readiness; не дублируй их
-      проверку вручную, а читай его вывод. `plan` — после каждого artifact; `apply` —
-      перед apply; `archive` — перед native archive. Exit 1 = нарушение artifact,
-      exit 2 = ошибка вызова/окружения (не исправляй artifact из-за неё).
+      Граница контроля:
+      - CLI проверяет только существование файлов и структуру delta specs. Profile,
+        порядок, gates и готовность — Readiness Checklist ниже: его проходит основной
+        агент, independent reviewer gate перепроверяет. Скриптов у schema нет.
+      - Checklist — не approval и не замена review: он ловит форму, смысл — reviewer.
+      - Результат checklist пишется в колонку Validation Gate Log
+        (`readiness: plan OK` | `readiness: apply OK` | список нарушений).
 
-      Next artifact:
-      - `openspec status` показывает невыбранные условные artifacts как `ready`, а
+      Следующий артефакт:
+      - `openspec status` показывает невыбранные условные артефакты как `ready`, а
         `isPlanningComplete` остаётся `false`, пока они не созданы. Это ограничение CLI:
-        не создавай artifact только потому, что он `ready`.
-      - Следующий artifact = `note: next artifact` из `check.cjs plan`.
+        не создавай артефакт только потому, что он `ready`.
+      - Следующий артефакт — первый ещё не созданный и разрешённый последним approved
+        gate в порядке: proposal → process-record → specs → выбранные ux-design /
+        system-analysis и модули / security-analysis → design ∥ qa-analysis → выбранные
+        test-cases / docs-impact → tasks.
 
-      Decision Gates (Gate Log, append-only):
+      Decision Gates (Gate Log, только дописывание):
       | Gate | Scope | Когда |
       | --- | --- | --- |
       | G1 Product Decision | proposal, change-profile | всегда |
       | G2 Requirements Baseline | specs (+ system-analysis и модули для complex) | lab или complex |
-      | G3 Solution Approval | всё остальное planning, включая tasks | всегда |
+      | G3 Solution Approval | остальное planning, включая tasks | всегда |
       | G4 Delivery Acceptance | implementation, review, QA, parity, docs | перед archive |
-      - Без G2 (delivery standard) specs входят в scope G3.
-      - Complex: system-analysis и выбранные модули входят в G2, чтобы системные
-        обязательства были согласованы до design (contract-first).
-      - Решение gate явно разрешает draft следующего пакета artifacts. Approval
-        перечисляет каждый artifact id в Scope и дословно цитирует слова Change Owner
-        из текущей сессии или комментария Issue (укажи ссылку). Никогда не записывай
-        решение, которого владелец не давал; существование файла или строки Gate Log
-        не является approval — `check.cjs` проверяет только форму записи.
-      - Каждый gate различает: Artifact Validation (CLI + `check.cjs`), Independent
-        Review (findings) и Decision Approval (владелец). Validation и Findings
-        заполняются до запроса решения.
-      - Семантическое изменение утверждённого artifact: строка `invalidated: <reason>`
-        для gate, покрывающего самый ранний затронутый artifact (это снимает и все
-        последующие gates), затем повторное approval по порядку. Механические правки
-        (опечатка, формат) не инвалидируют.
-      - Release Approval находится вне OpenSpec (release-it, Gitea); G4 его не заменяет.
+      - Без G2 (delivery standard) specs входят в Scope G3.
+      - Complex: выбранные system-analysis, data-mapping, failure-model, nfr,
+        observability входят в G2, чтобы системные обязательства были согласованы до
+        design (contract-first). Hub не обязателен: утверждается только выбранное.
+      - Каждый артефакт утверждается только на своём gate: proposal — G1; change-profile
+        — G1 (позднее изменение — G2/G3); specs — G2 (без G2 — G3); system-analysis и
+        модули — G2 для complex, иначе G3 (или G2, если он есть); остальное planning —
+        G3. Approval на чужом gate не засчитывается. Scope G1–G3 содержит только эти ids;
+        неизвестный id — ошибка записи. Scope G4 — implementation, review, QA, parity,
+        docs.
+      - Решение gate явно разрешает черновик следующего пакета артефактов. Approval
+        перечисляет каждый id в Scope и дословно цитирует слова Change Owner из текущей
+        сессии или комментария Issue (со ссылкой). Никогда не записывай решение, которого
+        владелец не давал; существование файла или строки Gate Log — не approval.
+      - Состояние gate = его ПОСЛЕДНЯЯ строка в Gate Log. `rejected`,
+        `changes requested` и `invalidated: <причина>` снимают approval этого gate и всех
+        последующих; новое approval — по порядку. Прежний approved выше в журнале не
+        действует.
+      - Каждый gate разделяет: Artifact Validation (CLI + Readiness Checklist),
+        Independent Review (findings) и Decision Approval (владелец). Validation и
+        Findings заполняются до запроса решения.
+      - Смысловое изменение утверждённого артефакта: строка `invalidated: <причина>` для
+        gate, покрывающего самый ранний затронутый артефакт (снимает и все последующие),
+        затем повторное approval по порядку. Механические правки (опечатка, формат) не
+        инвалидируют.
+      - Release Approval — вне OpenSpec (release-it, Gitea); G4 его не заменяет.
+
+      Readiness Checklist (проходи целиком; любой пункт «нет» — нарушение):
+      plan — после каждого артефакта:
+      - [ ] `**Mode:**` = lab|delivery, `**Class:**` = standard|complex, Issue указан.
+      - [ ] Change Profile: ровно 10 строк, Selected = yes|no, Reason непустой; `yes` в
+        delivery называет trigger, в lab — trigger или практику.
+      - [ ] Нет файлов невыбранных условных артефактов; `skip_specs: true` ⇔ нет `specs/`.
+      - [ ] Каждый выбранный условный вход существует раньше потребителя (см. Change
+        Profile).
+      - [ ] В артефактах, предъявляемых на gate, нет HTML-комментариев шаблона.
+      - [ ] Каждая ссылка `` `capability` — `Requirement` `` указывает на heading из delta
+        или canonical spec; после RENAMED — только на новое имя.
+      - [ ] Gate Log: артефакт засчитан только на своём gate; в Scope нет неизвестных ids;
+        Scope G1 включает `change-profile`; состояние gate — по последней строке; каждое
+        approved содержит дословную цитату и непустую Validation.
+      - [ ] Specs: нет дублей `### Requirement:` в одном файле; MODIFIED/REMOVED/RENAMED
+        FROM ссылаются на существующий canonical heading.
+      - [ ] test-cases: ids `TC-` уникальны, у каждого case есть Verifies в формате ссылки.
+      - [ ] Каждый файл `analysis/contracts/` и `analysis/diagrams/` упомянут в
+        `analysis/*.md`; JSON/YAML-контракты синтаксически валидны.
+      apply — plan плюс:
+      - [ ] Существуют proposal, process-record, specs (или `skip_specs: true`), design,
+        qa-analysis, tasks и все выбранные условные артефакты.
+      - [ ] Текущее состояние approved: G1; G2 (lab или complex); G3. Каждый существующий
+        артефакт (кроме research и process-record) входит в approved Scope.
+      - [ ] С момента approval нет смысловых правок утверждённых артефактов без
+        `invalidated`.
+      - [ ] Каждый ADDED/MODIFIED/REMOVED Requirement имеет строку в Coverage Matrix
+        qa-analysis и хотя бы одну task с ним в Covers. Упоминание вне матрицы и Covers —
+        не покрытие. REMOVED покрывается проверкой миграции/регрессии.
+      - [ ] В tasks есть Independent Review; Contract Parity при наличии
+        `analysis/contracts/`; раздел `## Docs Impact` в tasks.md, если docs-impact `no`.
+      - [ ] Descoped Work: каждая строка с причиной и gate G3/G4.
+      archive — apply плюс:
+      - [ ] Все tasks `[x]` или перенесены в Descoped Work.
+      - [ ] Состояние G4 — approved; Validation G4 содержит verify, review, QA, parity
+        (если есть контракты), docs.
+      - [ ] Lab: Retrospective заполнена.
 
       Independent Review (lab — на каждом gate; delivery — минимум G4):
-      - G1: product-analyst проверяет проблему/scope на противоречия и скрытые решения.
-      - G2: qa-engineer — testability; independent-reviewer — противоречия с canonical
-        specs и пропущенные error/boundary cases.
-      - G3: independent-reviewer — согласованность specs ↔ system-analysis ↔ design ↔
+      - G1: product-analyst ищет в проблеме и scope противоречия и скрытые решения.
+      - G2: qa-engineer — тестируемость; independent-reviewer — противоречия с canonical
+        specs и пропущенные error/boundary случаи.
+      - G3: independent-reviewer — согласованность specs ↔ analysis ↔ design ↔
         qa-analysis ↔ tasks; security-reviewer, если выбран security-analysis.
-      - G4: independent-reviewer — код против approved artifacts; qa-engineer — system
-        verification по qa-analysis.
-      - Reviewer не исправляет artifact; findings маршрутизируются по Feedback Routing.
+      - G4: independent-reviewer — код против утверждённых артефактов; qa-engineer —
+        системная проверка по qa-analysis.
+      - Reviewer не исправляет артефакт; findings идут по правилам обратной связи.
 
-      Delegation to subagents:
+      Делегирование сабагентам:
       - Сабагент — самостоятельный профессионал: не знает OpenSpec, gates и других
         сабагентов. Основной агент выбирает роль, пишет Task Brief, получает результат,
-        размещает его в artifact, проверяет согласованность и выносит вопросы человеку.
+        размещает его в артефакте, проверяет согласованность и выносит вопросы человеку.
       - Task Brief: профессиональная цель («спроектируй межсистемные взаимодействия
-        для …», не «создай artifact system-analysis»); точные входные файлы/разделы;
-        ограничения из MUST NOT Include artifact, сформулированные профессионально;
-        ожидаемые разделы ответа; правило «неизвестное — вернуть вопросом, не
-        выдумывать».
+        для …», а не «создай artifact system-analysis»); точные входные файлы и разделы;
+        ограничения из «Не включай» артефакта, сформулированные профессионально;
+        ожидаемые разделы ответа; правило «неизвестное — вернуть вопросом, не выдумывать».
       - Сабагент не принимает решений за другие роли; конфликт с upstream возвращается
         как finding.
 
@@ -184,439 +248,456 @@ artifacts:
 
   - id: specs
     generates: "specs/**/*.md"
-    description: Normative black-box behavioral deltas, business rules and invariants
+    description: Нормативные black-box дельты поведения, бизнес-правила и инварианты
     template: spec.md
     instruction: |
-      Owner: product-analyst (requirements engineering). Gate: G2 (lab/complex) или G3.
-      Reviewers: qa-engineer (testability), independent-reviewer (consistency).
+      Владелец: product-analyst (requirements engineering). Gate: G2 (lab/complex) или G3.
+      Reviewers: qa-engineer (тестируемость), independent-reviewer (согласованность).
 
-      Purpose:
-      Delta Specs — нормативный black-box contract: что система обязана делать для
+      Назначение:
+      Delta Specs — нормативный black-box контракт: что система обязана делать для
       пользователя или внешнего наблюдателя. После archive становятся canonical specs.
 
-      Preconditions:
+      Предусловия:
       - G1 approved; используются только capabilities из Proposal.
-      - Для existing capability прочитай canonical spec целиком.
-      - `skip_specs: true` — spec files не создаются.
+      - Для существующей capability прочитай canonical spec целиком.
+      - `skip_specs: true` — spec-файлы не создаются.
 
-      Critical Rules:
-      - Один Requirement = одно устойчивое observable behavior/invariant.
-      - BCP 14 по policy `config.yaml`: uppercase SHALL/MUST только для обязательств.
-      - Каждый Requirement имеет ≥1 `#### Scenario:` с конкретными WHEN/THEN.
-      - Бизнес-правила, инварианты (например, сохранение суммы, однократный учёт денег,
-        знак и точка округления) и граничные случаи — явные Requirements/Scenarios.
-      - Допущение не оформляется как факт: неизвестное правило → вопрос в Proposal
-        Open Decisions, а не выдуманный Requirement.
-      - Не дели Requirements по repositories; system names/transport/endpoints —
-        System Analysis, если сама их identity не является внешним обязательством.
+      Правила:
+      - Один Requirement = одно устойчивое observable behavior или инвариант.
+      - BCP 14 по политике `config.yaml`: uppercase SHALL/MUST — только для обязательств.
+      - У каждого Requirement ≥1 `#### Scenario:` с конкретными WHEN/THEN.
+      - Бизнес-правила, инварианты (сохранение суммы, однократный учёт денег, знак и
+        точка округления) и граничные случаи — явные Requirements/Scenarios.
+      - Допущение не оформляется как факт: неизвестное правило → вопрос в Open
+        Decisions Proposal, а не выдуманный Requirement.
+      - Не дели Requirements по repositories; имена систем/транспорт/endpoints —
+        в system-analysis, если сама их identity не внешнее обязательство.
 
-      Delta Operations:
-      - `ADDED`; `MODIFIED` — ПОЛНЫЙ existing block со всеми scenarios, heading точно;
-        `REMOVED` — **Reason** и **Migration**; `RENAMED` — `FROM:`/`TO:`.
+      Delta-операции:
+      - `ADDED`; `MODIFIED` — ПОЛНЫЙ существующий блок со всеми scenarios, heading
+        точно; `REMOVED` — **Reason** и **Migration**; `RENAMED` — `FROM:`/`TO:`.
       - Новая capability: `## Purpose` 1–2 предложения (≥50 символов).
-      - Не оставляй пустые operation sections.
+      - Не оставляй пустые разделы операций.
 
-      Reference Format (используется всеми downstream artifacts и `check.cjs`):
-      `` `capability-path` — `Requirement heading` `` — точный heading.
+      Формат ссылки (для всех downstream артефактов и Readiness Checklist):
+      `` `capability-path` — `Requirement heading` `` — heading точно. Пример:
+      `` `portfolio/holdings` — `Итог портфеля не учитывает дубли операций` ``.
+      Переименование heading после G2 — это RENAMED + invalidation; ссылки обновляются.
 
-      MUST NOT Include: implementation details, поведение вне Proposal, «корректно»/
-      «быстро»/«удобно» без критерия, противоречия canonical specs.
+      Не включай: детали реализации, поведение вне Proposal, «корректно»/«быстро»/
+      «удобно» без критерия, противоречия canonical specs.
 
-      Feedback Routing: intent/scope/capabilities → Proposal; systems/contracts/
-      mappings → позже System Analysis; interaction details → UX Design.
+      Обратная связь: намерение/scope/capabilities → Proposal; системы/контракты/
+      mappings → system-analysis; детали взаимодействия → ux-design.
 
-      Validation: `openspec validate <change> --strict --store wealth-ledger-specs`.
+      Проверка: `openspec validate <change> --strict --store wealth-ledger-specs`.
     requires:
       - process-record
 
   - id: ux-design
-    generates: ux-design.md
-    description: Optional interaction design of approved behavior; part of the Design package
+    generates: analysis/ux-design.md
+    description: Необязательный interaction design утверждённого поведения; часть Design package
     template: ux-design.md
     instruction: |
-      Owner: ux-designer. Conditional: только если Change Profile выбрал `ux-design`.
+      Владелец: ux-designer. Условный: только если Change Profile выбрал `ux-design`.
       Gate: G3 вместе с design (единый Design package, отдельного UX approval нет).
 
-      Trigger: новые экраны, существенное изменение пользовательского сценария,
-      редизайн, сложные формы, многосостоянийный интерфейс. Иначе UI описывается в
-      разделе UI Implementation `design.md` (reuse или N/A с причиной).
+      Trigger: новые экраны, существенное изменение пользовательского сценария, редизайн,
+      сложные формы, многосостоянийный интерфейс. Иначе UI описывается в разделе
+      UI Implementation `design.md` (reuse или N/A с причиной).
 
-      Authority:
-      - ux-design.md — UX-часть единого Design package (не отдельный planning
-        authority и не отдельный approval): внутри пакета он один владеет flows, IA,
-        состояниями, feedback, responsive и a11y. design.md ссылается на него и
-        фиксирует только инженерную реализацию UI.
-      - Observable behavior остаётся в Specs; UX не вводит новое behavior. Состояние или
+      Полномочия:
+      - ux-design — UX-часть единого Design package (не отдельный approval): внутри
+        пакета он один владеет flows, IA, состояниями, feedback, responsive и a11y.
+        design.md ссылается на него и фиксирует только инженерную реализацию UI.
+      - Observable behavior остаётся в Specs; UX не вводит новое поведение. Состояние или
         ошибка, которых нет в Specs, — finding → Specs.
 
-      Critical Rules:
+      Правила:
       - Ссылайся на Requirements, не пересказывай их.
-      - UI States покрывает loading/empty/error/success/partial только там, где они
-        реально возможны.
-      - Visual materials следуют правилу Visual Package из instruction `design`.
-      - Используй существующую design system (`docs/design/`, `frontend` UI kit) прежде
+      - UI States — loading/empty/error/success/partial только там, где они реально
+        возможны.
+      - Визуальные материалы — по правилу Visual Package из instruction `design`.
+      - Используй существующую design system (`docs/design/`, UI kit `frontend`) прежде
         нового паттерна; отклонение обоснуй.
 
-      MUST NOT Include: серверная архитектура, contracts, component tree, state
+      Не включай: серверную архитектуру, контракты, дерево компонентов, state
       management, data fetching.
 
-      Feedback Routing: behavior → Specs; реализуемость → Design; данные/ошибки
-      интеграции → System Analysis.
+      Обратная связь: поведение → Specs; реализуемость → design; данные/ошибки
+      интеграции → system-analysis.
     requires:
       - specs
 
   - id: system-analysis
-    generates: system-analysis/system-analysis.md
-    description: Optional hub of cross-system context, boundaries, flows, data ownership and contracts
+    generates: analysis/system-analysis.md
+    description: Необязательный hub межсистемного контекста — границы, flows, владение данными, контракты
     template: system-analysis.md
     instruction: |
-      Owner: system-analyst. Conditional: только если Change Profile выбрал
+      Владелец: system-analyst. Условный: только если Change Profile выбрал
       `system-analysis`. Gate: G2 для complex, иначе G3.
 
-      Trigger: новый/изменённый межсистемный contract (HTTP API, внешняя интеграция,
-      event), изменение data ownership, несколько систем в одном flow, сложная
-      миграция/coexistence. Изменение внутри одного repo без contract — не trigger.
+      Trigger: новый или изменённый межсистемный контракт (HTTP API, внешняя интеграция,
+      event), изменение владения данными, несколько систем в одном flow, сложная
+      миграция/coexistence. Изменение внутри одного repo без контракта — не trigger.
 
-      Structure (hub + modules; каждый module — отдельный выбор Change Profile):
-      - `system-analysis/system-analysis.md` — context, boundaries, As-Is/To-Be, impact,
-        responsibilities, data ownership, flows overview, contract semantics, error
-        semantics на границах, compatibility, ссылки на modules.
-      - `system-analysis/contracts/` — machine-readable target contracts
-        (OpenAPI/AsyncAPI/JSON Schema/Proto). Не отдельный artifact: принадлежит hub.
-      - `system-analysis/diagrams/*.mmd` — Mermaid sequence/state/data-flow, только
-        если помогают понять поведение. Каждый файл упоминается в hub или module.
-      - Modules: `data-mapping.md`, `failure-model.md`, `nfr.md`, `observability.md`.
-      - Расширения (audit, fraud, feature toggles, CMS, внешние системы) добавляются
-        новым module только при реальном requirement; schema их не предопределяет.
+      Структура (hub + модули; каждый модуль — отдельный выбор Change Profile, hub для
+      модуля не обязателен):
+      - `analysis/system-analysis.md` — контекст, границы, As-Is/To-Be, impact,
+        ответственности, владение данными, обзор flows, семантика контрактов и ошибок на
+        границах, совместимость, ссылки на модули.
+      - `analysis/contracts/` — машиночитаемые target-контракты (OpenAPI/AsyncAPI/
+        JSON Schema/Proto). Не отдельный артефакт: принадлежит hub.
+      - `analysis/diagrams/*.mmd` — Mermaid sequence/state/data-flow, только если
+        помогают понять поведение. Каждый файл упомянут в hub или модуле.
+      - Модули: `data-mapping.md`, `failure-model.md`, `nfr.md`, `observability.md`.
+      - Расширения (audit, fraud, feature toggles, CMS, внешние системы) — новым
+        модулем только при реальном requirement; schema их не предопределяет.
 
-      Contract Authority (сохранено из v2):
-      - Новый/изменённый contract определяется в `contracts/` до implementation.
-      - Backend-generated OpenAPI остаётся executable/runtime source после реализации
-        и MUST быть semantic-compatible с approved target contract до G4.
-      - Не создавай второй вечный canonical OpenAPI в `specs/`; target contract остаётся
-        в archived change. Mismatch generated ↔ target возвращает change сюда.
-      - Для existing HTTP API прочитай текущий backend-generated OpenAPI
+      Полномочия контракта (из v2):
+      - Новый или изменённый контракт определяется в `analysis/contracts/` до
+        реализации.
+      - Backend-generated OpenAPI остаётся исполняемым runtime-источником после
+        реализации и MUST быть семантически совместим с утверждённым target-контрактом
+        до G4.
+      - Не создавай второй вечный canonical OpenAPI в `specs/`; target-контракт остаётся
+        в архивном change. Расхождение generated ↔ target возвращает change сюда.
+      - Для существующего HTTP API прочитай текущий backend-generated OpenAPI
         (`frontend/src/shared/api/spec/openapi.json` — опубликованный snapshot).
-      - Каждый contract помечает compatibility: additive | breaking (+ migration).
+      - Каждый контракт помечает совместимость: additive | breaking (+ migration).
 
-      Critical Rules:
-      - Не вводи observable behavior молча: gap → Specs и повторный G2/G3.
-      - Hub не копирует содержимое modules; module не копирует hub.
-      - Нет internal classes/modules/DB tables/developer tests.
+      Правила:
+      - Не вводи observable behavior молча: пробел → Specs и повторный G2/G3.
+      - Hub не копирует модули; модуль не копирует hub.
+      - Нет внутренних классов/модулей/таблиц БД/developer tests.
 
-      Feedback Routing: behavior → Specs; internal implementation → Design;
-      verification → QA Analysis.
+      Обратная связь: поведение → Specs; внутренняя реализация → design; проверка →
+      qa-analysis.
     requires:
       - specs
 
   - id: data-mapping
-    generates: system-analysis/data-mapping.md
-    description: Optional field-level mapping, transformations and conservation invariants between systems
+    generates: analysis/data-mapping.md
+    description: Необязательный поле-в-поле mapping, преобразования и инварианты сохранения между системами
     template: data-mapping.md
     instruction: |
-      Owner: system-analyst; reviewer — database-specialist при изменении хранения.
-      Conditional: только если выбран `data-mapping` (требует `system-analysis`).
+      Владелец: system-analyst; reviewer — database-specialist при изменении хранения.
+      Условный: только если выбран `data-mapping`; hub не обязателен.
 
       Trigger: преобразование данных между системами или моделями (внешний API →
-      domain, domain → API, агрегаты), денежные суммы, валюты, знаки, агрегаты,
-      классификация записей по группам.
+      domain, domain → API, агрегаты), денежные суммы, валюты, знаки, классификация
+      записей по группам.
 
-      Critical Rules:
-      - Каждое target-поле: source, transformation, unit/currency/scale, nullability,
-        default, validation, поведение при ошибке.
-      - Invariants: правила сохранения (сумма частей = итог, каждая денежная единица
-        учитывается ровно в одном агрегате), знаковые соглашения, точка округления —
-        со ссылкой на защищаемый Requirement. Нет Requirement — finding → Specs.
-      - Double-counting: каждый тип исходной записи, который может попасть в два
-        агрегата, и правило, относящее его ровно к одному.
-      - Большой mapping — machine-checkable файл в `contracts/` со ссылкой отсюда.
+      Правила:
+      - Каждое target-поле: источник, преобразование, unit/валюта/scale, nullability,
+        default, валидация, поведение при ошибке.
+      - Инварианты: правила сохранения (сумма частей = итог, каждая денежная единица
+        учтена ровно в одном агрегате), знаки, точка округления — со ссылкой на
+        защищаемый Requirement. Нет Requirement — finding → Specs.
+      - Двойной учёт: каждый тип исходной записи, который может попасть в два агрегата,
+        и правило, относящее его ровно к одному.
+      - Большой mapping — машиночитаемый файл в `analysis/contracts/` со ссылкой отсюда.
 
-      MUST NOT Include: ORM/SQL/код mappers, retry/idempotency (failure-model).
+      Не включай: ORM/SQL/код mappers, retry/idempotency (failure-model).
 
-      Feedback Routing: инвариант без Requirement → Specs; ownership → hub;
-      реализация → Design.
+      Обратная связь: инвариант без Requirement → Specs; владение данными → hub;
+      реализация → design.
     requires:
-      - system-analysis
+      - specs
 
   - id: failure-model
-    generates: system-analysis/failure-model.md
-    description: Optional boundary failure semantics - timeouts, retries, idempotency, partial failure and recovery
+    generates: analysis/failure-model.md
+    description: Необязательная семантика отказов на границах — таймауты, повторы, идемпотентность, частичный отказ, восстановление
     template: failure-model.md
     instruction: |
-      Owner: system-analyst; reviewer — reliability-specialist.
-      Conditional: только если выбран `failure-model` (требует `system-analysis`).
+      Владелец: system-analyst; reviewer — reliability-specialist.
+      Условный: только если выбран `failure-model`; hub не обязателен.
 
       Trigger: внешняя интеграция, фоновая синхронизация, повторяемые операции,
-      многошаговая запись, возможны дубликаты/out-of-order/частичный отказ.
+      многошаговая запись, возможны дубли/out-of-order/частичный отказ.
 
-      Critical Rules:
-      - Каждый failure scenario: граница, отказ, обнаружение, требуемое поведение
-        системы, observable результат, Requirement.
-      - Idempotency: ключ, scope, срок хранения, результат повторного запроса/события.
-      - Partial failure: что остаётся согласованным, compensation или recovery.
-      - Обязательства формулируются на границе систем; механизм (lock, queue,
-        transaction) — Design.
+      Правила:
+      - Каждый сценарий отказа: граница, отказ, обнаружение, требуемое поведение системы,
+        observable результат, Requirement.
+      - Идемпотентность: ключ, scope, срок хранения, результат повторного запроса/события.
+      - Частичный отказ: что остаётся согласованным, компенсация или восстановление.
+      - Обязательства формулируются на границе систем; механизм (lock, очередь,
+        транзакция) — design.
 
-      MUST NOT Include: численные SLO (nfr), выбор библиотек, код.
+      Не включай: численные SLO (nfr), выбор библиотек, код.
 
-      Feedback Routing: новое user-visible поведение при отказе → Specs; механизм →
-      Design; проверка → QA Analysis.
+      Обратная связь: новое видимое пользователю поведение при отказе → Specs;
+      механизм → design; проверка → qa-analysis.
     requires:
-      - system-analysis
+      - specs
 
   - id: nfr
-    generates: system-analysis/nfr.md
-    description: Optional measurable non-functional requirements with thresholds and evidence
+    generates: analysis/nfr.md
+    description: Необязательные измеримые нефункциональные требования с порогами и способом измерения
     template: nfr.md
     instruction: |
-      Owner: system-analyst; reviewer — reliability-specialist.
-      Conditional: только если выбран `nfr` (требует `system-analysis`).
+      Владелец: system-analyst; reviewer — reliability-specialist.
+      Условный: только если выбран `nfr`; hub не обязателен.
 
-      Trigger: значимые performance/availability/capacity/retention/security
-      constraints, которые меняют design или verification.
+      Trigger: значимые ограничения performance/availability/capacity/retention/security,
+      которые меняют design или проверку.
 
-      Critical Rules:
-      - Каждый NFR: id, threshold, способ измерения, rationale/источник.
-      - Без threshold — раздел Constraints Without Thresholds с владельцем решения;
-        не выдумывай числа.
+      Правила:
+      - Каждый NFR: id, порог, способ измерения, обоснование/источник.
+      - Нет порога — раздел Constraints Without Thresholds с владельцем решения; числа
+        не выдумывай.
       - Security-NFR живут здесь; security-analysis ссылается на них по id.
 
-      MUST NOT Include: механизмы достижения (Design), failure semantics
-      (failure-model), события наблюдаемости (observability).
+      Не включай: механизмы достижения (design), семантику отказов (failure-model),
+      события наблюдаемости (observability).
     requires:
-      - system-analysis
+      - specs
 
   - id: observability
-    generates: system-analysis/observability.md
-    description: Optional semantic observability obligations - events, signals, correlation, SLI and alerts
+    generates: analysis/observability.md
+    description: Необязательные обязательства наблюдаемости — события, сигналы, корреляция, SLI и алерты
     template: observability.md
     instruction: |
-      Owner: system-analyst; reviewer — reliability-specialist.
-      Conditional: только если выбран `observability` (требует `system-analysis`).
+      Владелец: system-analyst; reviewer — reliability-specialist.
+      Условный: только если выбран `observability`; hub не обязателен.
 
-      Trigger: фоновые/асинхронные процессы, финансовые расчёты или синхронизация,
-      где оператор должен отличать успех, частичный успех и отказ; новые SLI.
+      Trigger: фоновые/асинхронные процессы, финансовые расчёты или синхронизация, где
+      оператор должен различать успех, частичный успех и отказ; новые SLI.
 
-      Critical Rules:
-      - Semantic events с trigger и обязательными атрибутами (например,
-        `code=1 → NO_MONEY`); correlation через границы систем.
-      - Diagnostic scenarios: «когда X, оператор определяет Y по Z».
-      - SLI/alerts — только с определением и целевым значением; цель из nfr — ссылкой.
+      Правила:
+      - Семантические события с trigger и обязательными атрибутами (например,
+        `code=1 → NO_MONEY`); корреляция через границы систем.
+      - Диагностические сценарии: «когда X, оператор определяет Y по Z».
+      - SLI/алерты — только с определением и целевым значением; цель из nfr — ссылкой.
 
-      MUST NOT Include: SDK/exporter/logger/инфраструктура (Design), секреты и
-      персональные данные в атрибутах.
+      Не включай: SDK/exporter/logger/инфраструктуру (design), секреты и персональные
+      данные в атрибутах.
     requires:
-      - system-analysis
+      - specs
 
   - id: security-analysis
-    generates: security-analysis.md
-    description: Optional change-scoped threat model with mitigations and residual risks
+    generates: analysis/security-analysis.md
+    description: Необязательная threat model этого change — mitigations и остаточные риски
     template: security-analysis.md
     instruction: |
-      Owner: security-reviewer. Conditional: только если выбран `security-analysis`.
-      Gate: G3; validation requirements проверяются на G4.
+      Владелец: security-reviewer. Условный: только если выбран `security-analysis`.
+      Gate: G3; требования к проверке исполняются на G4.
 
       Trigger: authentication/authorization, токены и секреты, новая trust boundary,
-      sensitive/financial personal data, внешняя интеграция, изменение модели доступа.
-      Не создавай для изменений без этих признаков.
+      чувствительные/финансовые персональные данные, внешняя интеграция, изменение
+      модели доступа. Без этих признаков не создавай.
 
-      Inputs: Specs; system-analysis (hub, nfr) если выбран; существующие ADR и
+      Входы: Specs; system-analysis и nfr, если выбраны; существующие ADR и
       `docs/architecture/cross-cutting/`.
 
-      Critical Rules:
-      - Threat model только этого change (STRIDE как способ поиска, не как чек-лист).
-      - Каждая mitigation назначена artifact-владельцу: observable требование → Specs,
-        межсистемное обязательство → System Analysis, механизм → Design.
+      Правила:
+      - Threat model только этого change (STRIDE — способ поиска, не чек-лист).
+      - Каждая mitigation назначена владельцу: observable требование → Specs,
+        межсистемное обязательство → system-analysis, механизм → design.
       - Security-NFR не дублируй: ссылайся на id из `nfr.md`.
-      - Residual risks явно принимает Change Owner на G3.
+      - Остаточные риски явно принимает Change Owner на G3.
 
-      MUST NOT Include: универсальный security checklist, эксплуатация внешних систем,
-      секреты.
+      Не включай: универсальный security checklist, эксплуатацию внешних систем, секреты.
     requires:
       - specs
 
   - id: design
     generates: design.md
-    description: Engineering design of how affected repositories implement approved behavior and system obligations
+    description: Инженерный design — как affected repositories реализуют утверждённое поведение и системные обязательства
     template: design.md
     instruction: |
-      Owner: solution-architect; reviewers — affected frontend/backend engineers,
+      Владелец: solution-architect; reviewers — affected frontend/backend engineers,
       database-specialist при миграциях. Gate: G3.
 
-      Purpose:
-      Как affected repositories реализуют свою сторону approved Specs и выбранных
-      system-analysis/ux-design/security-analysis. Не повторный system analysis.
+      Назначение:
+      Как affected repositories реализуют свою сторону утверждённых Specs и выбранных
+      analysis-артефактов. Это не повторный system analysis.
 
-      Preconditions:
-      - Все выбранные research, ux-design, system-analysis и modules,
-        security-analysis уже существуют (`check.cjs plan` без errors). Complex:
-        system-analysis утверждён на G2.
-      - Upstream contracts/sequences/mappings — входные ограничения.
+      Предусловия:
+      - Все выбранные условные входы из `analysis/` уже существуют (Readiness Checklist
+        `plan` без нарушений). Complex: выбранные system-analysis и модули утверждены
+        на G2.
+      - Протокол (gates, checklist, обратная связь) — instruction `process-record`;
+        Change Profile в `process-record.md` определяет, какие входы читать.
+      - Upstream контракты/sequences/mappings — входные ограничения.
 
-      Critical Rules:
-      - Не добавляй observable behavior; не меняй system contracts. Нереализуемый
-        contract → System Analysis, а не private contract здесь.
-      - Каждое существенное решение ссылается на driver: Requirement, NFR id, failure
-        id, threat id или constraint. Новая технология/компонент без driver запрещены.
-      - UI: при ux-design.md — только инженерная реализация (composition, state, data
-        fetching, производство каждого UI state); без ux-design.md — раздел UI
-        Implementation даёт new/changed/reuse/N/A с причиной и нужные экраны/состояния.
-        Неизменяемый UI и N/A не требуют макетов.
-      - Visual Package (единые правила для ux-design.md и UI Implementation): версия
-        пакета; для reuse — immutable locator (store ID + path от OpenSpec root),
-        применимая часть и отличия; локальные PNG/SVG под `visuals/` с relative path,
-        purpose и SHA-256; SVG самодостаточен (без scripts, handlers, внешних
-        fonts/assets); mutable внешняя ссылка не является утверждённой версией.
-        ux-design.md и design.md — один Design package с одним approval на G3.
-      - Solution Assessment обязателен для нового auth, security, storage, external
-        integration, observability, caching, concurrency, shared tooling или иного
-        дорогого необратимого решения; иначе N/A + reason.
-      - Rollback contract обязателен для security, destructive migration, public
-        contract и труднообратимых решений.
-      - Developer verification определяют implementation owners; QA matrix не копируй.
-      - ADR Candidates: только долгоживущие архитектурные решения с alternatives.
+      Глубина:
+      - Delivery standard: Inputs, Implementation Impact Map, Decisions и
+        Risks / Trade-offs обязательны; остальные разделы — только при наличии
+        содержания (Solution Assessment и Rollback — по их trigger ниже); пустые удаляй,
+        не пиши N/A.
+      - Lab или complex: все разделы шаблона; N/A — с причиной в одну строку.
 
-      MUST NOT Include: approved sequences/contracts/mappings (ссылки, не копии);
-      UX flows/states при наличии ux-design.md; QA coverage; docs plan; tasks/PR plan;
-      длинный production code.
+      Правила:
+      - Не добавляй observable behavior и не меняй системные контракты. Нереализуемый
+        контракт → system-analysis, а не private-контракт здесь.
+      - Каждое существенное решение ссылается на driver: Requirement, id NFR, failure,
+        threat или ограничение. Новая технология/компонент без driver запрещены.
+      - UI: при ux-design — только инженерная реализация (композиция, state, data
+        fetching, как получается каждое UI-состояние); без ux-design — раздел
+        UI Implementation: new/changed/reuse/N/A с причиной и нужные экраны/состояния.
+        Неизменяемый UI и N/A макетов не требуют.
+      - Visual Package (единое правило для ux-design и UI Implementation): версия
+        пакета; для reuse — неизменяемый locator (store ID + path от OpenSpec root),
+        применимая часть и отличия; локальные PNG/SVG в `visuals/` с относительным путём,
+        назначением и SHA-256; SVG самодостаточен (без scripts, handlers, внешних
+        шрифтов/ресурсов); изменяемая внешняя ссылка не является утверждённой версией.
+        ux-design и design — один Design package с одним approval на G3.
+      - Solution Assessment обязателен для нового auth, security, storage, внешней
+        интеграции, observability, кеширования, конкурентности, общего tooling или иного
+        дорогого необратимого решения; иначе N/A + причина.
+      - Rollback обязателен для security, разрушающей миграции, публичного контракта и
+        труднообратимых решений.
+      - Developer verification определяют implementation owners; QA-матрицу не копируй.
+      - ADR Candidates: только долгоживущие архитектурные решения с альтернативами.
 
-      Feedback Routing: intent → Proposal; behavior → Specs; interaction → UX Design;
-      contracts/mappings/failure semantics/semantic observability → System Analysis;
-      threats → Security Analysis.
+      Не включай: утверждённые sequences/контракты/mappings (ссылки, не копии); UX flows/
+      состояния при наличии ux-design; QA-покрытие; план docs; tasks/план PR; длинный
+      production-код.
+
+      Обратная связь: намерение → Proposal; поведение → Specs; взаимодействие →
+      ux-design; контракты/mappings/отказы/наблюдаемость → system-analysis и модули;
+      угрозы → security-analysis.
     requires:
       - specs
 
   - id: qa-analysis
-    generates: qa-analysis.md
-    description: Risk-based system verification strategy independent from developer-owned tests
+    generates: analysis/qa-analysis.md
+    description: Risk-based стратегия системной проверки, независимая от developer tests
     template: qa-analysis.md
     instruction: |
-      Owner: qa-engineer. Gate: G3. Может выполняться параллельно с design.
+      Владелец: qa-engineer. Gate: G3. Может выполняться параллельно с design.
 
-      Purpose:
-      Что нужно проверить на уровне системы, чтобы доказать соответствие Specs и
-      выбранным system-analysis modules, и с какой глубиной — по риску.
+      Назначение:
+      Что проверить на уровне системы, чтобы доказать соответствие Specs и выбранным
+      analysis-модулям, и с какой глубиной — по риску.
 
-      Depth (условные секции внутри обязательного artifact):
+      Глубина (условные разделы внутри обязательного артефакта):
       - Всегда: Risk Assessment, Coverage Matrix (строка на каждый delta Requirement),
         Gaps / Blockers.
-      - Delivery standard: остальные разделы только при наличии содержания; удаляй
-        пустые разделы, не пиши N/A.
-      - Lab или complex: все разделы; Cross-system Verification обязателен при
-        выбранном system-analysis, failure-model или data-mapping (каждый failure id
-        и invariant имеет проверку или обоснованный risk-based отказ).
+      - Delivery standard: остальные разделы — только при наличии содержания; пустые
+        удаляй, не пиши N/A.
+      - Lab или complex: все разделы; Cross-system Verification обязателен при выбранных
+        system-analysis, failure-model или data-mapping (каждый failure id и инвариант
+        имеет проверку или обоснованный risk-based отказ).
 
-      Critical Rules:
-      - QA проверяет system behavior, не устройство кода; не предписывай unit/component
-        tests, mocks, coverage percentage.
-      - Не создавай behavior: неопределённый expected result → gap в Specs;
-        неопределённый flow/error/contract → gap в System Analysis.
+      Правила:
+      - QA проверяет поведение системы, не устройство кода; не предписывай unit/component
+        tests, mocks, процент покрытия.
+      - Не создавай поведение: неопределённый ожидаемый результат → пробел в Specs;
+        неопределённый flow/ошибка/контракт → пробел в system-analysis.
       - Ссылайся на Scenarios, не переписывай их. Отдельные test cases — только через
-        artifact `test-cases`.
-      - Планы проверок отделены от результатов: результаты фиксируются на G4, не здесь.
-      - Automation: black-box API/E2E кандидаты; QA repo пока нет — `deferred until QA
+        артефакт `test-cases`.
+      - Планы проверок отделены от результатов: результаты фиксируются на G4.
+      - Automation: black-box кандидаты API/E2E; QA repo пока нет — `deferred until QA
         repo exists`.
 
-      Feedback Routing: behavior → Specs; contracts/failures → System Analysis;
-      testability hooks → Design (как need, без проектирования).
+      Обратная связь: поведение → Specs; контракты/отказы → system-analysis;
+      testability hooks → design (как потребность, без проектирования).
     requires:
       - specs
 
   - id: test-cases
-    generates: "test-cases/*.md"
-    description: Optional explicit test design for high-risk scenarios that need concrete data, steps or oracles
+    generates: "analysis/test-cases/*.md"
+    description: Необязательный явный test design для рискованных сценариев, которым нужны конкретные данные, шаги или oracle
     template: test-cases.md
     instruction: |
-      Owner: qa-engineer. Conditional: только если выбран `test-cases`. Gate: G3.
+      Владелец: qa-engineer. Условный: только если выбран `test-cases`. Gate: G3.
 
-      Trigger: финансовые расчёты, сложные бизнес-сценарии, значимые интеграции,
-      много ошибок и граничных случаев, критичное пользовательское поведение — когда
-      проверка требует конкретных данных, шагов или oracle, которых нет в Scenario.
+      Trigger: финансовые расчёты, сложные бизнес-сценарии, значимые интеграции, много
+      ошибок и граничных случаев, критичное пользовательское поведение — когда проверке
+      нужны конкретные данные, шаги или oracle, которых нет в Scenario.
 
-      Critical Rules:
-      - Один файл на область: `test-cases/<area>.md`; id `TC-<AREA>-<NNN>` уникален.
-      - Каждый case: Verifies (reference format), Risk/Priority, Preconditions, Test
-        Data, Steps, Expected Results, Automation Candidate.
+      Правила:
+      - Один файл на область: `analysis/test-cases/<area>.md`; id `TC-<AREA>-<NNN>`
+        уникален.
+      - Каждый case: Verifies (формат ссылки), риск/приоритет, предусловия, тестовые
+        данные, шаги, ожидаемый результат, кандидат в автоматизацию.
       - Case добавляет информацию сверх Scenario (числа, комбинации, порядок событий,
-        расчётный oracle). Если не добавляет — не пиши case; coverage matrix ссылается
-        на Scenario.
-      - Не копируй acceptance criteria дословно; expected result выводится из
-        Requirement, а не придумывается. Неопределённость → gap в Specs.
-      - qa-analysis Coverage Matrix ссылается на TC ids.
+        расчётный oracle). Не добавляет — не пиши case; Coverage Matrix ссылается на
+        Scenario.
+      - Не копируй acceptance criteria дословно; ожидаемый результат выводится из
+        Requirement, а не придумывается. Неопределённость → пробел в Specs.
+      - Coverage Matrix qa-analysis ссылается на TC ids.
     requires:
       - qa-analysis
 
   - id: docs-impact
-    generates: docs-impact.md
-    description: Optional promotion plan from change knowledge to canonical AS-IS documentation
+    generates: analysis/docs-impact.md
+    description: Необязательный план переноса знаний change в canonical AS-IS документацию
     template: docs-impact.md
     instruction: |
-      Owner: documentation-engineer. Conditional: только если выбран `docs-impact`.
+      Владелец: documentation-engineer. Условный: только если выбран `docs-impact`.
       Gate: G3.
 
-      Trigger: несколько docs targets, новый ADR, перенос diagrams, изменение
-      architecture/integration pages, lab-практика Documentation Impact Analysis.
-      Иначе — раздел `## Docs Impact` в tasks.md (targets или конкретная no-change
-      причина).
+      Trigger: несколько docs targets, новый ADR, перенос диаграмм, изменение страниц
+      architecture/integration, lab-практика Documentation Impact Analysis. Иначе —
+      раздел `## Docs Impact` в tasks.md (targets или конкретная причина без изменений).
 
-      Canonical Documentation Model: `docs/` — AS-IS (`overview.md`, `glossary.md`,
+      Модель документации: `docs/` — AS-IS (`overview.md`, `glossary.md`,
       `architecture/`, `architecture/cross-cutting/`, `domains/`, `integrations/`,
-      `adr/`, `design/`). Accepted ADR не переписывается.
+      `adr/`, `design/`). Принятый ADR не переписывается.
 
-      Critical Rules:
-      - Promote только знание, полезное после завершения change; без migration diary.
-      - Не копируй machine-readable contract в docs как второй source of truth.
-      - Каждая entry: Action, exact Target (существующий path проверен), Category,
-        Resulting AS-IS, Source, Verification.
-      - Diagram promotion по умолчанию — нет.
-      - docs-impact не редактирует `docs/`; Tasks создаёт `[docs]` items.
+      Правила:
+      - Переносится только знание, полезное после завершения change; без дневника
+        миграции.
+      - Не копируй машиночитаемый контракт в docs вторым источником истины.
+      - Каждая запись: Action, точный Target (существующий path проверен), Category,
+        итоговое AS-IS, Source, Verification.
+      - Перенос диаграмм по умолчанию — нет.
+      - docs-impact не редактирует `docs/`; tasks создают пункты `[docs]`.
     requires:
       - design
 
   - id: tasks
     generates: tasks.md
-    description: Dependency-ordered, repository-owned delivery checklist with verification, review and parity tasks
+    description: Упорядоченный по зависимостям delivery checklist по repositories с проверками, review и parity
     template: tasks.md
     instruction: |
-      Owner: основной агент (delivery coordination); reviewers — affected engineers.
+      Владелец: основной агент (координация delivery); reviewers — affected engineers.
       Gate: G3.
 
-      Preconditions:
-      - design и qa-analysis существуют; все выбранные условные artifacts существуют
-        (`check.cjs plan` без errors).
+      Предусловия:
+      - design и qa-analysis существуют; все выбранные условные артефакты существуют
+        (Readiness Checklist `plan` без нарушений).
       - Для complex/lab: G2 approved до записи tasks.
+      - Протокол (gates, checklist, Descoped Work) — instruction `process-record`.
 
-      Task Format:
-      `- [ ] X.Y [main|frontend|backend|docs|specs] <Kind>: <action + outcome>`
+      Формат task:
+      `- [ ] X.Y [main|frontend|backend|docs|specs] <Kind>: <действие + результат>`
       с полями **Covers**, **Source**, **Verification**, **Depends on**.
       Kinds: Implementation, Migration, Automated Testing, Contract Parity, Docs,
       Independent Review, QA Verification, Verification.
 
-      Required Tasks (только релевантные; `check.cjs` проверяет отмеченные *):
-      - Implementation/Automated Testing per repository по Design.
+      Обязательные tasks (только релевантные; отмеченные * проверяет Readiness Checklist):
+      - Implementation/Automated Testing по каждому repository согласно design.
       - Migration: при изменении хранения — backup/rollback и проверка на копии данных.
-      - * Contract Parity: при наличии `system-analysis/contracts/` — сравнение
-        backend-generated OpenAPI/runtime с target contract.
+      - * Contract Parity: при наличии `analysis/contracts/` — сравнение backend-generated
+        OpenAPI/runtime с target-контрактом.
       - Docs: из docs-impact или раздела `## Docs Impact`.
-      - * Independent Review: read-only review реализации против approved artifacts.
-      - QA Verification: system checks по qa-analysis (и test-cases).
-      - Security: проверки из security-analysis Validation Requirements, если выбран.
-      - Native sync/archive не является task; canonical specs не правятся task'ом.
+      - * Independent Review: read-only review реализации против утверждённых артефактов.
+      - QA Verification: системные проверки по qa-analysis (и test-cases).
+      - Security: проверки из Validation Requirements security-analysis, если выбран.
+      - Native sync/archive — не task; canonical specs задачами не правятся.
 
-      Critical Rules:
-      - Одна task = один repository + один independently reviewable outcome.
-      - * Каждый ADDED/MODIFIED Requirement появляется в Covers хотя бы одной task.
-      - Covers использует reference format; неизвестный heading — ошибка `check.cjs`.
+      Правила:
+      - Одна task = один repository + один независимо проверяемый результат.
+      - * Каждый ADDED/MODIFIED/REMOVED Requirement есть в Covers хотя бы одной task
+        (REMOVED — task миграции/регрессии).
+      - Covers в формате ссылки; неизвестный heading — нарушение checklist.
+      - У каждой task все четыре поля; Verification — наблюдаемая команда или результат,
+        а не «проверить, что работает».
       - `[qa]` запрещён, пока QA repo не существует.
-      - Не создавай ceremonial tasks; нерелевантная Kind не нужна.
-      - Descope после G3: удали task из tasks.md и запиши в process-record
-        `Descoped Work` с причиной и gate решения владельца.
+      - Не создавай церемониальные tasks; нерелевантный Kind не нужен.
+      - Снятие после G3: удали task из tasks.md и запиши в `Descoped Work`
+        process-record с причиной и gate решения владельца.
 
-      MUST NOT Include: новое behavior/contract/design/QA/docs decision (→ upstream
-      artifact), commits/branches, будущие результаты.
+      Не включай: новое поведение/контракт/design/QA/docs-решение (→ upstream артефакт),
+      commits/branches, будущие результаты.
 
-      Feedback Routing: semantic change → самый ранний затронутый artifact,
-      инвалидируя его gate и последующие.
+      Обратная связь: смысловое изменение → самый ранний затронутый артефакт с
+      инвалидацией его gate и последующих.
     requires:
       - design
       - qa-analysis
@@ -626,46 +707,52 @@ apply:
     - tasks
   tracks: tasks.md
   instruction: |
-    Apply реализует approved plan и не переоткрывает upstream decisions без feedback cycle.
+    Apply реализует утверждённый план и не переоткрывает upstream-решения без цикла
+    обратной связи.
 
-    Preconditions (CLI проверяет только наличие tasks.md, остальное — `check.cjs`):
-    - `check.cjs apply <change>` = OK (G1, G2 для lab/complex, G3; каждый
-      существующий artifact утверждён на своём gate; выбранные artifacts существуют).
+    Предусловия (CLI проверяет только наличие tasks.md, остальное — вручную):
+    - Readiness Checklist `apply` (instruction `process-record`) пройден целиком и
+      записан в Validation последней строки G3; любое нарушение блокирует apply.
+      Главное: все обязательные и выбранные артефакты существуют; текущее состояние
+      G1, G2 (lab/complex), G3 — approved по последней строке.
     - Перед зависимой UI-работой проверь наличие и SHA-256 материалов из таблицы
-      Materials (ux-design.md или UI Implementation design.md).
-    - Store `wealth-ledger-specs`; protocol — instruction `process-record`.
+      Materials (ux-design или UI Implementation в design).
+    - Store `wealth-ledger-specs`; протокол — instruction `process-record`.
 
-    Context Loading: `contextFiles` из apply instructions, затем `AGENTS.md` только
-    affected repositories, затем relevant upstream sections для каждой task.
+    Загрузка контекста: `contextFiles` из apply instructions, затем `AGENTS.md` только
+    affected repositories, затем нужные upstream-разделы для каждой task.
 
-    Execution:
-    - Pending tasks по dependency order; один repository на task; delegate по роли
-      (frontend-engineer, backend-engineer, database-specialist) с Task Brief.
-    - Checkbox отмечается только после observed success Verification.
-    - Contract Parity: backend-generated OpenAPI semantic-compatible с target contract.
+    Выполнение:
+    - Незакрытые tasks — в порядке зависимостей; один repository на task; делегируй по
+      роли (frontend-engineer, backend-engineer, database-specialist) с Task Brief.
+    - Checkbox отмечается только после наблюдаемого успеха Verification.
+    - Contract Parity: backend-generated OpenAPI семантически совместим с
+      target-контрактом.
     - Independent Review выполняет independent-reviewer (read-only) по полному diff
-      против approved artifacts; Major findings исправляются или возвращаются в gate.
+      против утверждённых артефактов; Major findings исправляются или возвращаются в gate.
     - QA Verification выполняет qa-engineer по qa-analysis; результаты — в Gate Log G4.
     - Lab: строка Lab Journal после implementation, review и QA.
+    - Снятие task — только решением владельца с записью в Descoped Work.
 
-    Before archive (G4 Delivery Acceptance):
-    - Все tasks `[x]`; descoped — только через `Descoped Work`.
-    - Validation G4: developer checks, parity, review verdict, QA results, docs.
-    - Lab: Retrospective заполнен.
-    - `check.cjs archive <change>` = OK (включает все apply-проверки), затем `openspec archive <change>
-      --store wealth-ledger-specs`. Никогда `--no-validate`. `--yes` подавляет и
-      подтверждение spec updates, и предупреждение о незакрытых tasks, поэтому
-      допустим только сразу после успешного `check.cjs archive` (в non-TTY агентской
-      среде без него archive не выполняется).
+    Перед archive (G4 Delivery Acceptance):
+    - Все tasks `[x]`; снятые — только через `Descoped Work`.
+    - Validation G4: developer checks, parity, вердикт review, результаты QA, docs.
+    - Lab: Retrospective заполнена.
+    - Readiness Checklist `archive` пройден и записан в Validation G4, затем
+      `openspec archive <change> --store wealth-ledger-specs`. Никогда
+      `--no-validate`. `--yes` подавляет и подтверждение обновления specs, и
+      предупреждение о незакрытых tasks, поэтому допустим только сразу после
+      пройденного checklist `archive` (в non-TTY агентской среде без него archive не
+      выполняется).
 
-    Sync / Archive Semantics: native archive обновляет canonical specs;
-    system-analysis, contracts и process-record остаются в archived change; `docs/`
-    меняются только `[docs]` tasks; значимые решения — immutable ADR.
+    Семантика sync/archive: native archive обновляет canonical specs; `analysis/`,
+    контракты и process-record остаются в архивном change; `docs/` меняются только
+    tasks `[docs]`; значимые решения — неизменяемый ADR.
 
-    Feedback Routing:
-    - intent/scope → Proposal; behavior/invariants → Specs; interaction → UX Design;
-      systems/contracts/mappings/failures/NFR/semantic observability → System Analysis
-      и modules; threats → Security Analysis; internal implementation → Design;
-      verification → QA Analysis/Test Cases; docs → Docs Impact; decomposition → Tasks.
-    - При semantic conflict останови downstream work, сообщи evidence, инвалидируй
-      gates от самого раннего затронутого artifact.
+    Обратная связь:
+    - намерение/scope → Proposal; поведение/инварианты → Specs; взаимодействие →
+      ux-design; системы/контракты/mappings/отказы/NFR/наблюдаемость → system-analysis
+      и модули; угрозы → security-analysis; внутренняя реализация → design; проверка →
+      qa-analysis/test-cases; docs → docs-impact; декомпозиция → tasks.
+    - При смысловом конфликте останови downstream-работу, приложи evidence,
+      инвалидируй gates начиная с самого раннего затронутого артефакта.
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/data-mapping.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/data-mapping.md
index 9668ebb..01ce807 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/data-mapping.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/data-mapping.md
@@ -1,28 +1,28 @@
 # Data Mapping
 
-<!-- guide: Field-level transformation between systems. Large mappings go to a
-     machine-checkable file in contracts/ and are referenced here. Remove guides. -->
+<!-- Преобразование данных между системами по полям. Большой mapping — машиночитаемый
+     файл в contracts/ со ссылкой отсюда. -->
 
 ## Source and Target
 
-| Mapping | Source (owner) | Target (owner) | Direction | Trigger |
+| Mapping | Источник (владелец) | Цель (владелец) | Направление | Trigger |
 | --- | --- | --- | --- | --- |
 
 ## Field Mapping
 
-| Target field | Source field(s) | Transformation | Unit / currency / scale | Nullability | Default | Validation | On failure |
+| Поле цели | Поля источника | Преобразование | Единица / валюта / scale | Nullability | Default | Валидация | При ошибке |
 | --- | --- | --- | --- | --- | --- | --- | --- |
 
 ## Invariants
 
-<!-- guide: Conservation rules that must hold after mapping, e.g. "total = sum of
-     positions + cash; each money unit counted once", sign conventions, rounding
-     point. Each invariant references the spec requirement it protects. -->
+<!-- Правила сохранения после mapping, например «итог = сумма позиций + кэш; каждая
+     денежная единица учтена один раз», знаки, точка округления. Каждый инвариант
+     ссылается на защищаемый Requirement. -->
 
 ## Double-counting and Classification Risks
 
-<!-- guide: Every source record type that could fall into two target aggregates,
-     and the rule that assigns it to exactly one. -->
+<!-- Каждый тип исходной записи, который может попасть в два агрегата, и правило,
+     относящее его ровно к одному. -->
 
 ## Transformation Errors
 
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/design.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/design.md
index 0ba5533..091adbf 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/design.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/design.md
@@ -1,22 +1,22 @@
 # Engineering Design
 
-<!-- guide: How affected repositories implement approved specs and system
-     obligations. Reference upstream ids; do not restate them. Remove guides. -->
+<!-- Как affected repositories реализуют утверждённые specs и системные обязательства.
+     Ссылайся на upstream ids, не пересказывай. -->
 
 ## Inputs
 
-<!-- guide: Exact upstream artifacts this design implements (specs, selected
-     system-analysis modules, ux-design, security-analysis). -->
+<!-- Точные upstream-артефакты, которые реализует этот design (specs, выбранные
+     модули analysis/, ux-design, security-analysis). -->
 
 ## Architecture Drivers
 
-<!-- guide: Requirements, NFR ids, constraints and risks that force decisions. -->
+<!-- Requirements, ids NFR, ограничения и риски, которые вынуждают решения. -->
 
 ## Technical Goals / Non-Goals
 
 ## Implementation Impact Map
 
-| Area | Affected | Outcome or N/A reason |
+| Область | Затронута | Результат или причина N/A |
 | --- | --- | --- |
 | main | | |
 | frontend | | |
@@ -24,8 +24,8 @@
 
 ## Decisions
 
-<!-- guide: Per decision: context, chosen option, rejected alternatives, driver it
-     satisfies. Group by repository when that helps. -->
+<!-- На каждое решение: контекст, выбранный вариант, отвергнутые альтернативы, driver.
+     Группируй по repository, если это помогает. -->
 
 ## Components and Responsibilities
 
@@ -33,16 +33,16 @@
 
 ## Contract Implementation
 
-<!-- guide: How each contract is produced/consumed and how published OpenAPI is
-     compared with the target contract. N/A when no contracts changed. -->
+<!-- Как каждый контракт производится/потребляется и как опубликованный OpenAPI
+     сравнивается с target-контрактом. N/A, если контракты не менялись. -->
 
 ## Cross-cutting Implementation
 
 ## UI Implementation
 
-<!-- guide: With ux-design.md: component composition, state, data fetching, how
-     each UI state is produced — no restated UX. Without ux-design.md: state
-     new/changed, reuse or N/A with reason, plus the needed screen/state detail. -->
+<!-- С ux-design: композиция компонентов, state, data fetching, как получается каждое
+     UI-состояние — без пересказа UX. Без ux-design: new/changed/reuse или N/A с
+     причиной и нужные детали экранов/состояний. -->
 
 ## Developer Verification Strategy
 
@@ -50,8 +50,8 @@
 
 ## Solution Assessment
 
-<!-- guide: Required for new auth, security, storage, integration, observability,
-     caching, concurrency or shared tooling; otherwise N/A with reason. -->
+<!-- Обязателен для нового auth, security, storage, интеграции, observability,
+     кеширования, конкурентности или общего tooling; иначе N/A с причиной. -->
 
 ## Risks / Trade-offs
 
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/docs-impact.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/docs-impact.md
index 715218d..eeeca15 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/docs-impact.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/docs-impact.md
@@ -1,12 +1,12 @@
 # Documentation Impact
 
-<!-- guide: Plan only; docs/ is edited by [docs] tasks. Remove guides. -->
+<!-- Только план; docs/ правят tasks `[docs]`. -->
 
 ## Summary
 
 ## Documentation Changes
 
-| Action | Target | Category | Resulting AS-IS | Source | Verification |
+| Action | Target | Category | Итоговое AS-IS | Source | Verification |
 | --- | --- | --- | --- | --- | --- |
 
 ## Diagram Promotion
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/failure-model.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/failure-model.md
index fb0e81e..3992ace 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/failure-model.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/failure-model.md
@@ -1,19 +1,18 @@
 # Failure Model
 
-<!-- guide: Boundary-level failure semantics. Implementation of mechanisms (queues,
-     locks, libraries) belongs to design.md. Remove guides before G3. -->
+<!-- Семантика отказов на границах. Реализация механизмов (очереди, locks,
+     библиотеки) — в design.md. -->
 
 ## Failure Scenarios
 
-| ID | Boundary / step | Failure | Detection | Required system behavior | Observable result | Requirement |
+| ID | Граница / шаг | Отказ | Обнаружение | Требуемое поведение системы | Наблюдаемый результат | Requirement |
 | --- | --- | --- | --- | --- | --- | --- |
 
 ## Timeouts and Retries
 
 ## Idempotency and Duplicate Handling
 
-<!-- guide: Idempotency key, scope, retention; what a duplicate request/event
-     yields. -->
+<!-- Ключ идемпотентности, scope, срок хранения; что даёт повторный запрос/событие. -->
 
 ## Ordering and Concurrency
 
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md
index 586c35b..6d37f60 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md
@@ -1,14 +1,13 @@
 # Non-Functional Requirements
 
-<!-- guide: Only measurable constraints that change design or verification.
-     Each row needs a threshold and a way to measure it. Remove guides. -->
+<!-- Только измеримые ограничения, которые меняют design или проверку. У каждой
+     строки есть порог и способ измерения. -->
 
-| ID | Category | Requirement | Threshold | Measurement / evidence | Rationale / source |
+| ID | Категория | Требование | Порог | Измерение / evidence | Обоснование / источник |
 | --- | --- | --- | --- | --- | --- |
 
 ## Constraints Without Thresholds
 
-<!-- guide: Constraints that are real but not measurable yet; state why and who
-     decides the threshold. -->
+<!-- Реальные, но пока неизмеримые ограничения: почему нет порога и кто его решит. -->
 
 ## Open Questions
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/observability.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/observability.md
index e328a2f..40ea561 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/observability.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/observability.md
@@ -1,11 +1,10 @@
 # Observability
 
-<!-- guide: What must be observable and why; not which SDK, exporter or logger
-     (design.md). Remove guides before G3. -->
+<!-- Что должно быть наблюдаемо и зачем; не какой SDK, exporter или logger (design.md). -->
 
 ## Semantic Events
 
-| Event | Trigger | Required attributes | Consumer / purpose |
+| Событие | Trigger | Обязательные атрибуты | Потребитель / назначение |
 | --- | --- | --- | --- |
 
 ## Logs, Metrics and Traces
@@ -14,11 +13,11 @@
 
 ## SLI and Alert Conditions
 
-| SLI | Definition | Target | Alert condition |
+| SLI | Определение | Цель | Условие алерта |
 | --- | --- | --- | --- |
 
 ## Diagnostic Scenarios
 
-<!-- guide: "When X happens, an operator can determine Y from Z." -->
+<!-- «Когда X, оператор определяет Y по Z». -->
 
 ## Open Questions
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md
index 28617c4..138a5fb 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md
@@ -1,17 +1,21 @@
 # Process Record
 
-**Mode:** <!-- guide: lab | delivery -->
-**Class:** <!-- guide: standard | complex -->
-**Issue:** <!-- guide: Gitea Issue link -->
+**Mode:** <!-- lab | delivery -->
+**Class:** <!-- standard | complex -->
+**Issue:** <!-- ссылка на Gitea Issue -->
 
 ## Change Profile
 
-<!-- guide: One row per conditional artifact, all ten rows required. Selected =
-     yes|no. Reason cites the concrete trigger from the instruction table or why
-     it does not apply; "lab practice" is a valid reason only in lab mode and
-     must name the practice. -->
+<!-- Строка на каждый условный артефакт, все десять обязательны. Выбран = yes|no.
+     Причина называет конкретный trigger из instruction артефакта или объясняет, почему
+     он не применим; «lab: практика …» допустима только в lab и называет практику.
+     Пример:
+     | failure-model | yes | синхронизация брокера повторяет неидемпотентную запись |
+     | nfr | no | нет новых обязательств по задержке, объёму или хранению |
+     | data-mapping | yes | lab: практика data mapping |
+     Плохо: `| nfr | no | N/A |` — причина должна объяснять, почему не нужно. -->
 
-| Artifact | Selected | Reason |
+| Артефакт | Выбран | Причина |
 | --- | --- | --- |
 | research | | |
 | ux-design | | |
@@ -26,32 +30,38 @@
 
 ## Gate Log
 
-<!-- guide: Append-only, chronological. Scope = artifact ids covered by the
-     decision. Validation = commands run and their results, review verdicts.
-     Decision = `approved "<quoted owner words>"`, `rejected`, `changes requested`
-     or `invalidated: <reason>`. Never write a decision the owner did not give. -->
+<!-- Только дописывание, по хронологии. Scope — ids артефактов в решении.
+     Validation — выполненные команды и результаты, вердикты review.
+     Decision — `approved "<дословные слова владельца>"`, `rejected`,
+     `changes requested` или `invalidated: <причина>`. Никогда не записывай решение,
+     которого владелец не давал. ПОСЛЕДНЯЯ строка gate — его состояние; более поздняя
+     rejected / changes requested / invalidated снимает этот gate и все последующие.
+     Пример:
+     | G1 | 2026-10-29 | proposal, change-profile | `openspec validate` OK; readiness: plan OK | product-analyst: 1 major — закрыт в Open Decisions | approved "ок, идём дальше" (сессия) |
+     | G2 | 2026-10-30 | specs | `openspec validate --strict` OK; readiness: plan OK | qa-engineer: в Scenario нет значения THEN | changes requested |
+     Плохо: `approved` без цитаты владельца; строка G4 со Scope `design`. -->
 
-| Gate | Date | Scope | Validation | Findings | Decision |
+| Gate | Дата | Scope | Validation | Findings | Decision |
 | --- | --- | --- | --- | --- | --- |
 
 ## Descoped Work
 
-<!-- guide: Tasks removed from tasks.md after G3. Reason and approving gate are
-     required. Leave the header row only when nothing was descoped. -->
+<!-- Tasks, удалённые из tasks.md после G3. Причина и gate решения обязательны.
+     Если ничего не снято — только строка заголовка. -->
 
-| Task | Reason | Gate |
+| Task | Причина | Gate |
 | --- | --- | --- |
 
 ## Lab Journal
 
-<!-- guide: lab mode: one row per completed stage, written right after it.
-     Unique findings = what this stage found that no other stage did.
-     Cost = subagent calls, approximate tokens or time. delivery mode: optional. -->
+<!-- lab: строка на каждую завершённую стадию, сразу после неё. Уникальные находки —
+     то, что нашла только эта стадия. Стоимость — вызовы сабагентов, примерно токены
+     или время. delivery: необязательно. -->
 
-| Stage | Role / subagent | Unique findings | Decisions | Risks found / excluded | Handoff issues | Skills | Cost | Transferable |
+| Стадия | Роль / сабагент | Уникальные находки | Решения | Риски найдены / исключены | Проблемы передачи | Skills | Стоимость | Переносимо |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- |
 
 ## Retrospective
 
-<!-- guide: Written after G4. Which stages paid off, which were redundant for this
-     class of change, what to change in the schema. Facts first, then opinion. -->
+<!-- После G4. Какие стадии окупились, какие были лишними для этого класса change,
+     что поменять в schema. Сначала факты, потом мнение. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md
index 8dc2c74..099715e 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md
@@ -1,7 +1,6 @@
 # Proposal
 
-<!-- guide: Language of the Change Owner. No files, APIs, tables, libraries,
-     diagrams or test plans. Remove every guide comment before G1. -->
+<!-- Язык Change Owner. Без файлов, API, таблиц, библиотек, диаграмм и тест-планов. -->
 
 ## Why
 
@@ -23,14 +22,16 @@
 
 ## Success Criteria
 
+<!-- Каждый критерий измерим или наблюдаем: что увидит пользователь или владелец. -->
+
 ## Evidence
 
-<!-- guide: Facts that justify the change, each with a source: Issue, research
-     (link or `research.md`), incident, measurement. Mark hypotheses as such. -->
+<!-- Факты, обосновывающие change, каждый с источником: Issue, research (ссылка или
+     `analysis/research.md`), инцидент, измерение. Гипотезы помечай явно. -->
 
 ## Assumptions / Dependencies
 
 ## Open Decisions
 
-<!-- guide: Decisions not yet taken that may change scope. Each item: question,
-     who decides, what blocks until it is answered. Empty only if none exist. -->
+<!-- Ещё не принятые решения, способные изменить scope. Каждое: вопрос, кто решает,
+     что блокируется до ответа. Пусто, только если таких нет. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md
index 3ef55db..32bf794 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md
@@ -1,20 +1,24 @@
 # QA Analysis
 
-<!-- guide: Risk-based system verification strategy. Reference scenarios; do not
-     restate them. No developer unit/component test plans. Remove guides. -->
+<!-- Risk-based стратегия системной проверки. Ссылайся на Scenarios, не пересказывай.
+     Без планов developer unit/component tests. -->
 
 ## Risk Assessment
 
-| Risk | Affected requirements | Likelihood | Impact | Verification depth |
+| Риск | Затронутые требования | Вероятность | Ущерб | Глубина проверки |
 | --- | --- | --- | --- | --- |
 
 ## Coverage Matrix
 
-<!-- guide: One row per delta requirement. Check = system-level way of proving
-     it; test case ids when test-cases is selected; or "not verified: <risk
-     reason>". -->
+<!-- Строка на каждый delta Requirement. Проверка — системный способ доказать его;
+     ids test cases, если выбран test-cases; либо «not verified: <риск-причина>».
+     Покрытие — только строки этой таблицы; упоминание требования в другом месте
+     файла покрытием не считается. REMOVED требует проверки миграции/регрессии.
+     Пример:
+     | `portfolio/holdings` — `Итог портфеля не учитывает дубли операций` | повторный импорт того же файла брокера, итог не меняется | API | TC-HOLD-001 |
+     | `portfolio/holdings` — `Портфель показывает валюту` | not verified: только отображение, проверено ревью Scenario; риск низкий | — | — | -->
 
-| Requirement | Check | Level | Test cases |
+| Requirement | Проверка | Уровень | Test cases |
 | --- | --- | --- | --- |
 
 ## Negative and Boundary Focus
@@ -30,5 +34,3 @@
 ## Regression Impact
 
 ## Gaps / Blockers
-
-<!-- guide: Each gap names its routing destination artifact. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/research.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/research.md
index 0bd7c2d..8e0b3ed 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/research.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/research.md
@@ -1,7 +1,7 @@
 # Product Research
 
-<!-- guide: Input context, not a requirement source. Every claim is marked
-     [F] fact with source, [I] interpretation or [H] hypothesis. Remove guides. -->
+<!-- Входной контекст, не источник требований. Каждое утверждение помечено:
+     [F] факт с источником, [I] интерпретация, [H] гипотеза. -->
 
 ## Problem Statement
 
@@ -11,7 +11,7 @@
 
 ## Existing Solutions and Alternatives
 
-| Option | What it does | Strengths | Weaknesses | Source |
+| Вариант | Что делает | Сильные стороны | Слабые стороны | Источник |
 | --- | --- | --- | --- | --- |
 
 ## Evidence & Sources
@@ -24,5 +24,5 @@
 
 ## Recommendation
 
-<!-- guide: build / do not build / narrow scope / research more, with reasons.
-     "Do not build" is a valid outcome. -->
+<!-- делать / не делать / сузить scope / исследовать дальше — с причинами.
+     «Не делать» — допустимый итог. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/security-analysis.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/security-analysis.md
index 6c39a93..fe789de 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/security-analysis.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/security-analysis.md
@@ -1,7 +1,7 @@
 # Security Analysis
 
-<!-- guide: Threat model of this change only. Reference security NFR rows by id;
-     do not restate them. No generic checklist. Remove guides before G3. -->
+<!-- Threat model только этого change. На security-NFR ссылайся по id, не
+     пересказывай. Без универсального чек-листа. -->
 
 ## Scope
 
@@ -11,16 +11,16 @@
 
 ## Threats
 
-| ID | Threat (STRIDE) | Attack scenario | Asset / boundary | Existing control | Likelihood / impact |
+| ID | Угроза (STRIDE) | Сценарий атаки | Актив / граница | Существующий контроль | Вероятность / ущерб |
 | --- | --- | --- | --- | --- | --- |
 
 ## Recommended Mitigations
 
-| Threat | Mitigation | Owner artifact (specs / system-analysis / design) |
+| Угроза | Mitigation | Артефакт-владелец (specs / system-analysis / design) |
 | --- | --- | --- |
 
 ## Residual Risks
 
 ## Validation Requirements
 
-<!-- guide: Evidence needed before G4: review focus, negative tests, tooling. -->
+<!-- Evidence, нужные до G4: фокус review, негативные тесты, инструменты. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
index b838743..ecaad36 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
@@ -1,18 +1,32 @@
 <!--
-Choose only the sections this delta needs; delete this guide before approval.
+Оставь только нужные этой дельте разделы; комментарий удали до approval.
 
-New capability only: add `## Purpose` with 1–2 sentences (50+ characters).
-Existing capability: do not add Purpose.
+Только новая capability: `## Purpose` в 1–2 предложения (от 50 символов).
+Существующая capability: Purpose не добавляй.
 
-Supported operations:
-- `## ADDED Requirements`: new complete Requirement blocks.
-- `## MODIFIED Requirements`: full existing Requirement blocks with every
-  surviving Scenario, then edited behavior; heading matches exactly.
-- `## REMOVED Requirements`: Requirement heading plus **Reason** and **Migration**.
-- `## RENAMED Requirements`: `FROM:` and `TO:` heading pairs only.
+Операции:
+- `## ADDED Requirements` — новые полные блоки Requirement.
+- `## MODIFIED Requirements` — полный существующий блок со всеми сохраняемыми
+  Scenario, затем изменённое поведение; heading совпадает точно.
+- `## REMOVED Requirements` — heading Requirement плюс **Reason** и **Migration**.
+- `## RENAMED Requirements` — только пары `FROM:` и `TO:`.
 
-Every normative Requirement uses BCP 14 (RFC 2119 + RFC 8174) uppercase
-SHALL/MUST deliberately, and at least one `#### Scenario:` with `- **WHEN**`
-and `- **THEN**`. Lowercase must/should/may are ordinary language.
-Do not leave empty operation sections or a sample Requirement.
+Каждый нормативный Requirement осознанно использует BCP 14 (RFC 2119 + RFC 8174)
+uppercase SHALL/MUST и минимум один `#### Scenario:` с `- **WHEN**` и
+`- **THEN**`. Строчные «must/should/may» — обычный язык.
+Не оставляй пустые разделы операций и образцы.
+
+Пример:
+## ADDED Requirements
+### Requirement: Итог портфеля не учитывает дубли операций
+Система SHALL учитывать каждый идентификатор операции брокера в итоге портфеля
+не более одного раза.
+
+#### Scenario: Одна операция импортирована дважды
+- **WHEN** операция `op-1` на 100.00 RUB импортирована дважды
+- **THEN** итог портфеля увеличивается ровно на 100.00 RUB
+
+Плохо: «Система SHALL корректно обрабатывать дубли» — нет наблюдаемого критерия;
+«THEN итог правильный» — нет ожидаемого значения; один Requirement на импорт,
+отображение и экспорт сразу — раздели по поведению.
 -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/system-analysis.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/system-analysis.md
index 0467d0c..5680f63 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/system-analysis.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/system-analysis.md
@@ -1,12 +1,11 @@
 # System Analysis
 
-<!-- guide: Hub document. Owns context, boundaries, flows overview and contract
-     semantics; details live in selected modules and are referenced, not copied.
-     Remove guides before G3. -->
+<!-- Hub. Владеет контекстом, границами, обзором flows и семантикой контрактов;
+     детали — в выбранных модулях, на них ссылаются, а не копируют. -->
 
 ## Requirement Coverage
 
-| Requirement | Flow / contract | Module |
+| Requirement | Flow / контракт | Модуль |
 | --- | --- | --- |
 
 ## System Context and Boundaries
@@ -19,32 +18,32 @@
 
 ## Data Ownership
 
-| Data | Source of truth | Writers | Readers |
+| Данные | Источник истины | Пишут | Читают |
 | --- | --- | --- | --- |
 
 ## Interaction Flows
 
-<!-- guide: Reference diagrams/*.mmd; text only for what a diagram cannot carry. -->
+<!-- Ссылки на diagrams/*.mmd; текст — только для того, что диаграмма не передаёт. -->
 
 ## Contracts
 
-<!-- guide: Per contract: producer/consumer, operation/event, version, file in
-     contracts/, compatibility class (additive / breaking), published source it
-     must match after implementation. -->
+<!-- На каждый контракт: producer/consumer, операция/событие, версия, файл в
+     contracts/, класс совместимости (additive / breaking), опубликованный источник,
+     с которым он обязан совпасть после реализации. -->
 
-| Contract | Producer → Consumer | File | Compatibility | Published source |
+| Контракт | Producer → Consumer | Файл | Совместимость | Опубликованный источник |
 | --- | --- | --- | --- | --- |
 
 ## Error Semantics
 
-<!-- guide: Business vs technical failures at boundaries. Detailed retry/
-     idempotency/recovery belongs to failure-model.md when selected. -->
+<!-- Бизнес- и технические отказы на границах. Подробные retry/идемпотентность/
+     восстановление — в failure-model.md, если выбран. -->
 
 ## Compatibility / Migration
 
 ## Detailed Modules
 
-<!-- guide: Link each selected module (data-mapping, failure-model, nfr,
-     observability) with one line on what it decides. -->
+<!-- Ссылка на каждый выбранный модуль (data-mapping, failure-model, nfr,
+     observability) и одна строка о том, что он решает. -->
 
 ## Open Questions
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/tasks.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/tasks.md
index 9402737..708b685 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/tasks.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/tasks.md
@@ -1,18 +1,24 @@
 # Tasks
 
-<!-- guide: Task line format:
-- [ ] X.Y [main|frontend|backend|docs|specs] <Kind>: <action + outcome>
-  - **Covers:** `capability` — `Requirement heading` pairs, or `N/A` — <reason>
-  - **Source:** exact upstream artifact section / contract / docs-impact entry
-  - **Verification:** owner-controlled command, observable check or artifact
-  - **Depends on:** task ids or none
+<!-- Формат task:
+- [ ] X.Y [main|frontend|backend|docs|specs] <Kind>: <действие + результат>
+  - **Covers:** пары `capability` — `Requirement heading` или `N/A` — <причина>
+  - **Source:** точный раздел upstream-артефакта / контракт / запись docs-impact
+  - **Verification:** команда владельца, наблюдаемая проверка или артефакт
+  - **Depends on:** ids tasks или none
 Kinds: Implementation, Migration, Automated Testing, Contract Parity, Docs,
-Independent Review, QA Verification, Verification. Remove guides before G3. -->
+Independent Review, QA Verification, Verification.
+Пример:
+- [ ] 2.1 [backend] Implementation: пропускать операции, чей внешний id уже сохранён
+  - **Covers:** `portfolio/holdings` — `Итог портфеля не учитывает дубли операций`
+  - **Source:** design.md Decisions D2; analysis/failure-model.md F3
+  - **Verification:** `npm run verify` в backend; повторный импорт fixture оставляет итог 100.00
+  - **Depends on:** 1.1
+Плохо: «Verification: проверить, что работает»; Covers с heading, которого нет в specs. -->
 
-## 1. <!-- guide: delivery phase -->
+## 1. <!-- этап delivery -->
 
 ## Docs Impact
 
-<!-- guide: Only when docs-impact is not selected: list docs/ targets with
-     resulting AS-IS, or one concrete no-change reason. Delete when docs-impact.md
-     exists. -->
+<!-- Только если docs-impact не выбран: targets в docs/ с итоговым AS-IS или одна
+     конкретная причина без изменений. Удали раздел, если есть analysis/docs-impact.md. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/test-cases.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/test-cases.md
index 4e8b8ae..e679190 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/test-cases.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/test-cases.md
@@ -1,10 +1,10 @@
-# Test Cases — <!-- guide: area -->
+# Test Cases — <!-- область -->
 
-<!-- guide: One file per area under test-cases/. A case adds concrete data, steps
-     or an oracle that the scenario does not already state; otherwise reference the
-     scenario from qa-analysis instead of writing a case. Remove guides. -->
+<!-- Один файл на область в analysis/test-cases/. Case добавляет конкретные данные,
+     шаги или oracle, которых нет в Scenario; иначе qa-analysis ссылается на Scenario,
+     а case не пишется. -->
 
-### TC-<!-- guide: AREA-NNN --> <!-- guide: title -->
+### TC-<!-- AREA-NNN --> <!-- название -->
 
 - **Verifies:** `capability` — `Requirement heading` / Scenario
 - **Risk / Priority:**
@@ -13,4 +13,4 @@
 - **Steps:**
   1.
 - **Expected Results:**
-- **Automation Candidate:** <!-- guide: yes (level) | no (reason) -->
+- **Automation Candidate:** <!-- yes (уровень) | no (причина) -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/ux-design.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/ux-design.md
index 8dc07de..7142f18 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/ux-design.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/ux-design.md
@@ -1,15 +1,14 @@
 # UX Design
 
-<!-- guide: Interaction design of observable behavior from Delta Specs. Reference
-     requirements as `capability` — `Requirement heading`; do not restate them.
-     No server architecture, contracts or component/state-management choices.
-     Remove guides before G3. -->
+<!-- Interaction design observable behavior из Delta Specs. Ссылайся на требования
+     как `capability` — `Requirement heading`, не пересказывай. Без серверной
+     архитектуры, контрактов и выбора компонентов/state management. -->
 
 ## User Goals
 
 ## User Flows
 
-<!-- guide: Mermaid flowchart or numbered steps per flow, with entry and exit points. -->
+<!-- Mermaid flowchart или нумерованные шаги на каждый flow, с точками входа и выхода. -->
 
 ## Information Architecture and Screen Structure
 
@@ -17,7 +16,7 @@
 
 ## UI States
 
-| Screen / region | Loading | Empty | Error | Success | Partial / stale |
+| Экран / область | Loading | Empty | Error | Success | Partial / stale |
 | --- | --- | --- | --- | --- | --- |
 
 ## Validation Feedback
@@ -26,15 +25,15 @@
 
 ## Accessibility
 
-<!-- guide: Keyboard path, focus order, names/roles, contrast, non-color cues. -->
+<!-- Путь с клавиатуры, порядок фокуса, имена/роли, контраст, признаки не только цветом. -->
 
 ## Design System Reuse
 
 ## Materials
 
-<!-- guide: Inline Markdown by default; local files follow the Visual Package rule. -->
+<!-- По умолчанию inline Markdown; локальные файлы — по правилу Visual Package. -->
 
-| Material ID | Relative path / reference | Screen/state and purpose | SHA-256 |
+| ID материала | Относительный путь / ссылка | Экран/состояние и назначение | SHA-256 |
 | --- | --- | --- | --- |
 
 ## Open UX Questions
-- 
2.54.0


From 4c13b1863fefbdae083432be5cd1d02c5d1da552 Mon Sep 17 00:00:00 2001
From: Sergey Krylov <ksv741@mail.ru>
Date: Fri, 30 Oct 2026 10:50:19 +0300
Subject: [PATCH 2/3] spec: add requirement-writing profile to sdd-lab
 (WealthLedger/specs#66)

---
 .../schemas/wealth-ledger-sdd-lab/schema.yaml |  60 ++++-
 .../wealth-ledger-sdd-lab/spec-writing.md     | 220 ++++++++++++++++++
 .../wealth-ledger-sdd-lab/templates/nfr.md    |  11 +-
 .../templates/process-record.md               |   2 +
 .../templates/proposal.md                     |   4 +-
 .../templates/qa-analysis.md                  |  21 +-
 .../wealth-ledger-sdd-lab/templates/spec.md   |  40 ++--
 7 files changed, 320 insertions(+), 38 deletions(-)
 create mode 100644 openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md

diff --git a/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml b/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml
index b632641..bf2c772 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml
+++ b/openspec/schemas/wealth-ledger-sdd-lab/schema.yaml
@@ -118,6 +118,13 @@ artifacts:
       Шаблоны: HTML-комментарии в шаблонах — подсказки для автора. В готовом артефакте их
       нет; удаляй до gate этого артефакта.
 
+      Качество требований: единый профиль для автора и reviewer —
+      `openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md`. До утверждения Specs
+      автор проходит нормоконтроль и смысловую проверку набора из раздела Review;
+      назначенный по режиму reviewer перепроверяет их на существующем G2/G3.
+      Результат — в Validation и Findings Gate Log. Вопрос, меняющий норму или ожидаемый
+      результат, блокирует gate; предпочтение стиля само по себе не блокирует.
+
       Change Profile (обязательная таблица, все 10 строк):
       - `yes` — только при конкретном trigger из instruction артефакта; в lab допустим
         `yes` с названной практикой («lab: практика data mapping»).
@@ -196,6 +203,9 @@ artifacts:
         approved содержит дословную цитату и непустую Validation.
       - [ ] Specs: нет дублей `### Requirement:` в одном файле; MODIFIED/REMOVED/RENAMED
         FROM ссылаются на существующий canonical heading.
+      - [ ] Для предъявляемых на gate Specs пройдены оба прохода Review из
+        spec-writing.md: качество требований и полнота/согласованность итогового набора;
+        нет нерешённых вопросов о нормативном поведении.
       - [ ] test-cases: ids `TC-` уникальны, у каждого case есть Verifies в формате ссылки.
       - [ ] Каждый файл `analysis/contracts/` и `analysis/diagrams/` упомянут в
         `analysis/*.md`; JSON/YAML-контракты синтаксически валидны.
@@ -220,10 +230,11 @@ artifacts:
 
       Independent Review (lab — на каждом gate; delivery — минимум G4):
       - G1: product-analyst ищет в проблеме и scope противоречия и скрытые решения.
-      - G2: qa-engineer — тестируемость; independent-reviewer — противоречия с canonical
-        specs и пропущенные error/boundary случаи.
+      - G2: qa-engineer — тестируемость; independent-reviewer — оба прохода Review из
+        spec-writing.md для delta и итогового набора с canonical specs.
       - G3: independent-reviewer — согласованность specs ↔ analysis ↔ design ↔
-        qa-analysis ↔ tasks; security-reviewer, если выбран security-analysis.
+        qa-analysis ↔ tasks; без G2 также профиль Specs; security-reviewer, если выбран
+        security-analysis.
       - G4: independent-reviewer — код против утверждённых артефактов; qa-engineer —
         системная проверка по qa-analysis.
       - Reviewer не исправляет артефакт; findings идут по правилам обратной связи.
@@ -262,15 +273,27 @@ artifacts:
       - G1 approved; используются только capabilities из Proposal.
       - Для существующей capability прочитай canonical spec целиком.
       - `skip_specs: true` — spec-файлы не создаются.
+      - Прочитай `openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md`: это единый
+        профиль написания и ревью, включая эталоны, а не необязательные советы.
 
       Правила:
-      - Один Requirement = одно устойчивое observable behavior или инвариант.
-      - BCP 14 по политике `config.yaml`: uppercase SHALL/MUST — только для обязательств.
-      - У каждого Requirement ≥1 `#### Scenario:` с конкретными WHEN/THEN.
+      - Путь дельты — `specs/<capability-path>/spec.md`, capability-path точно из Proposal.
+      - Один Requirement = одно независимо принимаемое наблюдаемое обязательство или
+        инвариант. Единый атомарный результат не дроби по числу SHALL.
+      - Новая норма: субъект + SHALL / SHALL NOT + результат с явным условием, если оно
+        нужно. MUST / MUST NOT равнозначны; BCP 14 — по политике `config.yaml`.
+      - Общая норма, нужные определения/таблицы, затем ≥1 `#### Scenario:` для
+        ADDED/MODIFIED: GIVEN по необходимости, конкретные WHEN/THEN. Scenario не
+        создаёт новую норму. Существующие headings и сохраняемые Scenarios не теряй.
+      - Термины бери из затронутых specs и предоставленного глоссария; новое определение
+        размещай внутри владеющего Requirement, а не только в исследовании или примере.
       - Бизнес-правила, инварианты (сохранение суммы, однократный учёт денег, знак и
-        точка округления) и граничные случаи — явные Requirements/Scenarios.
+        точка округления), единицы и существенные границы — явные нормы и Scenarios.
+        Для ветвлений/жизненного цикла используй таблицы по профилю, без дублирования
+        правил прозой. Неизвестные пороги и политики не выдумывай.
       - Допущение не оформляется как факт: неизвестное правило → вопрос в Open
-        Decisions Proposal, а не выдуманный Requirement.
+        Decisions Proposal с владельцем и зависимым требованием; зависимый gate ждёт
+        решения. Наблюдение в коде не подменяет согласованное намерение.
       - Не дели Requirements по repositories; имена систем/транспорт/endpoints —
         в system-analysis, если сама их identity не внешнее обязательство.
 
@@ -291,7 +314,9 @@ artifacts:
       Обратная связь: намерение/scope/capabilities → Proposal; системы/контракты/
       mappings → system-analysis; детали взаимодействия → ux-design.
 
-      Проверка: `openspec validate <change> --strict --store wealth-ledger-specs`.
+      Проверка: `openspec validate <change> --strict --store wealth-ledger-specs`, затем
+      оба прохода Review из spec-writing.md. Успех CLI не доказывает полноту смысла;
+      проверяй delta вместе с получающимся canonical набором.
     requires:
       - process-record
 
@@ -445,8 +470,12 @@ artifacts:
 
       Правила:
       - Каждый NFR: id, порог, способ измерения, обоснование/источник.
+      - Для численного порога определи единицы, условия/нагрузку, точки начала и конца
+        измерения, окно или агрегат по необходимости. Контекст измерения нужен,
+        чтобы разные авторы и QA проверяли одно обязательство.
       - Нет порога — раздел Constraints Without Thresholds с владельцем решения; числа
-        не выдумывай.
+        не выдумывай. Если от порога зависит design или приёмка, вопрос блокирует
+        соответствующий gate до решения.
       - Security-NFR живут здесь; security-analysis ссылается на них по id.
 
       Не включай: механизмы достижения (design), семантику отказов (failure-model),
@@ -572,10 +601,14 @@ artifacts:
       Назначение:
       Что проверить на уровне системы, чтобы доказать соответствие Specs и выбранным
       analysis-модулям, и с какой глубиной — по риску.
+      Прочитай `openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md`: ожидаемый исход
+      берётся из нормы, а не из догадки QA или фактического поведения реализации.
 
       Глубина (условные разделы внутри обязательного артефакта):
-      - Всегда: Risk Assessment, Coverage Matrix (строка на каждый delta Requirement),
-        Gaps / Blockers.
+      - Всегда: Risk Assessment, Coverage Matrix (строка на каждый ADDED/MODIFIED/REMOVED
+        Requirement с указанием Scenarios/ветвей правила и способа проверки), Gaps /
+        Blockers. При `skip_specs: true` матрица фиксирует существующее поведение или
+        согласованное ограничение для регрессии и его источник, без выдуманных дельт.
       - Delivery standard: остальные разделы — только при наличии содержания; пустые
         удаляй, не пиши N/A.
       - Lab или complex: все разделы; Cross-system Verification обязателен при выбранных
@@ -589,6 +622,9 @@ artifacts:
         неопределённый flow/ошибка/контракт → пробел в system-analysis.
       - Ссылайся на Scenarios, не переписывай их. Отдельные test cases — только через
         артефакт `test-cases`.
+      - По риску проверь существенные границы, строки таблиц, переходы, повторы,
+        конкуренцию и отсутствие запрещённых побочных эффектов. Пропуск проверки —
+        явное `not verified: <риск-причина>` для названного случая в матрице, не молчание.
       - Планы проверок отделены от результатов: результаты фиксируются на G4.
       - Automation: black-box кандидаты API/E2E; QA repo пока нет — `deferred until QA
         repo exists`.
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md b/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md
new file mode 100644
index 0000000..ccfbad5
--- /dev/null
+++ b/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md
@@ -0,0 +1,220 @@
+# Spec Writing Profile
+
+Профиль написания и ревью требований `wealth-ledger-sdd-lab`. Цель — одинаковое
+понимание поведения разными авторами, разработчиками и QA, а не дословно одинаковые
+документы. Это адаптация инженерных практик, не заявление о соответствии стандартам.
+
+## Scope
+
+Автор и reviewer читают профиль перед подготовкой или согласованием Specs. Правила
+применяются к новым и изменяемым требованиям; весь canonical store ради стиля не
+переписывается. Пути, delta-операции и gates задаёт `schema.yaml`.
+
+Specs определяют наблюдаемое поведение. Обоснования и открытые решения — в Proposal,
+межсистемные детали — в `analysis/`, механизмы — в design, способы доказательства —
+в QA. Ни один downstream-артефакт не вводит новое поведение молча.
+
+## Writing Rules
+
+1. **Основание.** Каждое обязательство следует из согласованного намерения или
+   существующего контракта. Наблюдение в коде, гипотеза и пример — не решение
+   владельца. Неизвестное запиши в Open Decisions: вопрос, кто решает, зависимое
+   требование и что блокируется. Несогласованные числа и варианты не становятся нормой.
+2. **Термины.** Используй названия из затронутых canonical specs и предоставленного
+   проектного глоссария. Один термин — одно значение в названном контексте. «Счёт»,
+   «брокерский счёт» и «учётная запись» не взаимозаменяемы. Новый или спорный термин
+   определи в теле владеющего им Requirement; остальные требования ссылаются на него.
+   Определение должно различать случаи, а не заменять слово синонимом. Общие термины
+   передаются в глоссарий через Docs Impact; новый файл словаря на каждый change не нужен.
+3. **Атомарность.** Один Requirement — одно независимо принимаемое обязательство.
+   Если одну часть можно принять, а другую отклонить — раздели. Связанные условия,
+   сохранность данных при отказе и единый атомарный результат остаются вместе.
+   Число союзов или SHALL не определяет атомарность.
+4. **Явная норма.** Назови субъект, условие применимости и наблюдаемый результат.
+   Для нового обязательства предпочитай SHALL / SHALL NOT; существующие MUST /
+   MUST NOT равнозначны и сохраняются. SHOULD / MAY не заменяют неопределённый исход:
+   допустимая вариативность и исключения должны быть согласованы и описаны.
+   «Корректно», «быстро», «при необходимости», «и/или», «и т. д.» без определения —
+   повод уточнить правило. Краткость не оправдывает потерю условий.
+5. **Величины и границы.** Для расчёта задай входы, формулу, знак, валюту, точность
+   и момент округления, если они влияют на результат. Для периода — включительность
+   границ, дату/время учёта и часовой пояс; для порога — сравнение и точку отсчёта.
+   Различай ноль, отсутствие значения и неизвестный результат. Не добавляй допуск,
+   таймаут или округление без источника только ради измеримости.
+6. **Свобода реализации.** Описывай «что», а не внутренние классы, библиотеки или
+   алгоритм. Если внутренний механизм можно заменить без изменения внешнего
+   обязательства, это design. Внешний формат или протокол допустим в Specs, когда
+   именно он является согласованным обязательством, а не удобством реализации.
+
+## Requirement and Scenario
+
+Порядок блока: `### Requirement:` с устойчивым именем → общая норма → нужные
+определения/таблица → `#### Scenario:`. Для новых требований используй короткое имя
+на русском; существующие headings сохраняй для native delta-сопоставления.
+
+Выбирай форму по смыслу (адаптация EARS, не дополнительный синтаксис OpenSpec):
+
+| Смысл | Каркас нормы |
+| --- | --- |
+| Постоянное свойство | Система SHALL … |
+| Реакция на событие | При … система SHALL … |
+| Зависимость от состояния | Пока … система SHALL … |
+| Ошибка или исключение | Если … система SHALL … |
+
+У ADDED/MODIFIED Requirement минимум один Scenario. GIVEN нужен, когда исходное
+состояние влияет на результат; WHEN задаёт событие; THEN — наблюдаемый исход с
+определённым ожидаемым значением или составом, не «работает правильно». AND уточняет
+тот же исход. Шаги не описывают внутренние вызовы и селекторы UI.
+
+Сначала общее правило, затем различающие примеры: основной путь, существенная
+граница, иной исход, отказ, повтор или конкуренция — по применимости. Каждый сценарий
+добавляет новый класс поведения. Не вводи правило только в Scenario и не переписывай
+правило целиком для каждой комбинации данных. Сценарии показывают следствия нормы,
+но несколько примеров не доказывают универсальный инвариант.
+
+## Representation
+
+| Когда прозы недостаточно | Представление и обязательные уточнения |
+| --- | --- |
+| Взаимодействуют несколько условий | Таблица решений: область входов, смысл «любое», политика совпадений (одна строка / первая / все), результат отсутствия совпадений или объяснение полноты |
+| Результат зависит от истории | Переходы: исходное состояние, событие/условие, новое состояние, видимый эффект; существенные повторы и недопустимые переходы |
+| Должно сохраняться свойство | Инвариант/формула с областью действия и единицами; примеры нуля, знака и округления по применимости |
+
+Нормативная таблица находится внутри Requirement до первого Scenario и вводится
+фразой с SHALL. Она — единственное определение правила, а не копия соседней прозы.
+Неоднозначные пересечения строк — дефект, если явно не задан приоритет или сбор
+результатов. Таблица безусловно не нужна каждому требованию. Внутренние состояния
+реализации и межсистемные схемы остаются в analysis/design.
+
+## Examples
+
+Учебные примеры формы, не продуктовые решения WealthLedger. В реальном change
+периоды, состояния и исходы берутся из его согласованных входов.
+
+### Condition and Boundary
+
+```markdown
+## ADDED Requirements
+
+### Requirement: Отбор операций за календарный период
+При формировании отчёта система SHALL включать все и только операции выбранного
+счёта, дата учёта которых входит в выбранный период включительно по Europe/Moscow.
+
+#### Scenario: Последний день периода и следующий день
+- **GIVEN** выбран период 01.10.2026–31.10.2026 и счёт A
+- **AND** на счёте A есть операции X с датой учёта 31.10.2026 и Y с датой 01.11.2026
+- **WHEN** формируется отчёт
+- **THEN** отчёт включает X и не включает Y
+```
+
+Плохо: «Система SHALL корректно отбирать операции до конца месяца» — не определены
+месяц, границы, дата отбора и счёт. «THEN список корректен» не позволяет проверить исход.
+
+### Decision Table
+
+```markdown
+## ADDED Requirements
+
+### Requirement: Различимость неполного и пустого итога
+Система SHALL представлять итог расчёта по таблице. «Полнота» означает получение
+всех данных выбранной выборки; «есть записи» — наличие хотя бы одной записи.
+Оба условия логические. Совпадает ровно одна строка; «любое» означает оба значения.
+Покрыты все комбинации.
+
+| Полнота подтверждена | Есть записи | Видимый итог |
+| --- | --- | --- |
+| Нет | Любое | Недоступен, без числового итога |
+| Да | Нет | Ноль и пояснение пустого результата |
+| Да | Да | Рассчитанный итог |
+
+#### Scenario: Известная часть не становится окончательной суммой
+- **GIVEN** известна одна запись на 100 RUB, но полнота выборки не подтверждена
+- **WHEN** пользователь просматривает результат
+- **THEN** итог обозначен как недоступный, не показан ни как 100 RUB, ни как ноль
+```
+
+Плохо: строки «нет данных → 0» и «данные не полны → недоступно» без определения
+«нет данных» — одному входу могут соответствовать два разных результата.
+
+### State Transition
+
+```markdown
+## ADDED Requirements
+
+### Requirement: Отмена формирования отчёта
+При запросе отмены система SHALL изменять состояние формирования отчёта по таблице.
+Область правила — состояния «Ожидает», «Отменён», «Готов»; начальное — «Ожидает».
+Совпадает ровно одна строка. Таблица определяет только событие отмены.
+
+| До | После | Результат отмены |
+| --- | --- | --- |
+| Ожидает | Отменён | Отмена подтверждена, отчёт не будет сформирован |
+| Отменён | Отменён | Отмена подтверждена без повторного эффекта |
+| Готов | Готов | Отмена отклонена, готовый отчёт сохранён |
+
+#### Scenario: Повтор отмены
+- **GIVEN** формирование отчёта уже отменено
+- **WHEN** пользователь снова запрашивает отмену
+- **THEN** отмена подтверждена, состояние остаётся «Отменён»
+```
+
+Плохо: «повтор ничего не делает» — не определён результат для пользователя.
+
+## Review
+
+Используй два прохода на существующем gate Specs (G2 или G3), не новый gate.
+Автор выполняет самопроверку; назначенный по режиму reviewer перепроверяет независимо.
+
+| Проход | Что проверить |
+| --- | --- |
+| Нормоконтроль | Native headings/операции; термины и единицы; явные субъект/условие/исход; атомарность; корректные ссылки; Scenario с проверяемым THEN |
+| Смысл и набор | Необходимость и происхождение норм; основной путь, альтернативы, отказы и границы; повторы/конкуренция/сохранность по риску; непротиворечивость таблиц и итогового baseline; отсутствие выдуманных решений |
+
+Проверь не только delta, но и получающийся набор вместе с canonical specs:
+сохранились ли действующие ограничения, исключения, инварианты и сценарии? MODIFIED
+заменяет полный блок; редакторское улучшение не разрешает удалить прежний сценарий
+или незаметно переименовать Requirement.
+
+Профиль не отменяет ограничений установленного CLI. При предупреждении о длине
+сократи повторения или раздели действительно независимые обязательства; не убирай
+условия и не прячь норму в комментарий/код ради успешного `--strict`.
+
+Контрольный вопрос: «Назови существенную ошибочную реализацию и наблюдение, которым
+это требование отличит её от соответствующей». Если ответ зависит от догадки,
+укажи точную неопределённость. Это эвристика ревью, не доказательство полноты.
+
+Finding: **файл/heading + цитата → нарушенное правило → два возможных толкования
+или недостающий исход → вопрос владельцу/адресат исправления**. Reviewer возвращает
+находки, не переписывает текст по вкусу. Пример: «до конца месяца» → неясна правая
+граница → операция в последний день включается или исключается → уточнить в Specs.
+Нерешённый вопрос, меняющий требование или ожидаемый результат, блокирует его gate;
+косметическое предпочтение не блокирует. Validation и Findings — в существующем
+Gate Log, без нового отчёта на каждый Requirement.
+
+### Trial
+
+Для проверки эффекта дай одним и тем же авторам/моделям одинаковые входы: простое
+правило, ветвление, повтор/состояние и MODIFIED. До сравнения зафиксируй согласованные
+исходы и намеренно оставленные неизвестные. Сравни ответы независимых читателей на
+контрольные вопросы, пропуски и выдуманные нормы, время уточнения и ревью. Совпадение
+формулировок и успешный CLI не считаются доказательством одинакового понимания.
+
+## Sources and Adaptation
+
+Из девяти исследований `sdd-spec-quality/*.md` и трёх сводок `result/*.pdf` выбраны
+правила с понятной пользой для ручного Markdown-процесса. Первоисточники проверены
+30.10.2026; критерии адаптированы, а не перенесены как обязательная сертификация.
+
+| Источник | Что взято и где предел |
+| --- | --- |
+| [NASA SE Handbook, Appendix C, C.2–C.4](https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/) | Необходимость, одна мысль, «что, а не как», проверяемость и согласованность; не сертификационный комплект документов |
+| [INCOSE GtWR v4 Summary, с. 2–3](https://www.incose.org/wp-content/uploads/legacy/working-groups/requirements-wg/guidetowritingrequirements/incose_rwg_gtwr_v4_summary_sheet.pdf) | C1/C3/C5/C7 для отдельного требования, C10–C14 для набора; R4/R7/R33–R36 — термины, величины, время. Полный платный Guide не заявлен как проверенный |
+| [EARS, автор методики](https://alistairmavin.com/ears/) | Каркасы условия/события/состояния/ошибки; русский язык — адаптация, не буквальная английская грамматика |
+| [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html), [8174 §2](https://www.rfc-editor.org/rfc/rfc8174.html#section-2) | Значения uppercase SHALL/MUST и запретов; наличие ключевого слова само по себе не гарантирует качество |
+| [Cucumber, Given/When/Then](https://cucumber.io/docs/gherkin/reference/) | Исходное состояние, событие, наблюдаемый исход; Markdown Scenario не становится исполняемым Gherkin-тестом |
+
+Из предложений не приняты: жёсткие лимиты слов/сценариев, подсчёт SHALL вместо
+атомарности, обязательные REQ-ID и скрытые атрибуты, JSON-first, новые линтеры и gates.
+Из нормоконтроля конструкторской документации заимствовано разделение проверки формы
+и смысла; соответствие ГОСТ, DO-178C или ISO/IEC/IEEE 29148 не заявляется. Таблицы и
+инварианты используются по риску; обязательная формальная модель каждому change не нужна.
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md
index 6d37f60..6fafc56 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/nfr.md
@@ -1,13 +1,16 @@
 # Non-Functional Requirements
 
 <!-- Только измеримые ограничения, которые меняют design или проверку. У каждой
-     строки есть порог и способ измерения. -->
+     строки есть согласованный порог с единицами, условия/нагрузка и способ измерения.
+     Для времени укажи точки начала/конца, для статистики — окно и агрегат.
+     Не превращай пример числа из исследования в утверждённую цель. -->
 
-| ID | Категория | Требование | Порог | Измерение / evidence | Обоснование / источник |
-| --- | --- | --- | --- | --- | --- |
+| ID | Категория | Требование | Порог и единицы | Условия измерения | Измерение / evidence | Обоснование / источник |
+| --- | --- | --- | --- | --- | --- | --- |
 
 ## Constraints Without Thresholds
 
-<!-- Реальные, но пока неизмеримые ограничения: почему нет порога и кто его решит. -->
+<!-- Реальные, но пока неизмеримые ограничения: почему нет порога, кто решит и какое
+     решение/проверку это блокирует. Не выдавай неизвестное за согласованный NFR. -->
 
 ## Open Questions
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md
index 138a5fb..7808107 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/process-record.md
@@ -36,6 +36,8 @@
      `changes requested` или `invalidated: <причина>`. Никогда не записывай решение,
      которого владелец не давал. ПОСЛЕДНЯЯ строка gate — его состояние; более поздняя
      rejected / changes requested / invalidated снимает этот gate и все последующие.
+     Для Specs: Validation отмечает нормоконтроль и смысловую проверку набора по
+     spec-writing.md; Findings — конкретные неясности/пропуски и их разрешение.
      Пример:
      | G1 | 2026-10-29 | proposal, change-profile | `openspec validate` OK; readiness: plan OK | product-analyst: 1 major — закрыт в Open Decisions | approved "ок, идём дальше" (сессия) |
      | G2 | 2026-10-30 | specs | `openspec validate --strict` OK; readiness: plan OK | qa-engineer: в Scenario нет значения THEN | changes requested |
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md
index 099715e..d45abe7 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/proposal.md
@@ -34,4 +34,6 @@
 ## Open Decisions
 
 <!-- Ещё не принятые решения, способные изменить scope. Каждое: вопрос, кто решает,
-     что блокируется до ответа. Пусто, только если таких нет. -->
+     зависимое требование/артефакт и что блокируется до ответа. Несогласованное
+     правило, термин, порог или вариант поведения не заменяй допущением в Specs.
+     Пусто, только если таких вопросов нет. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md
index 32bf794..a7e472b 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/qa-analysis.md
@@ -10,19 +10,25 @@
 
 ## Coverage Matrix
 
-<!-- Строка на каждый delta Requirement. Проверка — системный способ доказать его;
-     ids test cases, если выбран test-cases; либо «not verified: <риск-причина>».
+<!-- Строка на каждый ADDED/MODIFIED/REMOVED Requirement. Назови покрытые Scenarios
+     точными headings и ветви таблицы/переходы, если они есть. Проверка даёт наблюдение,
+     отличающее исполнение нормы от нарушения; test cases — ссылками, не копиями.
+     Пропуск случая — «not verified: <риск-причина>» с названием случая.
      Покрытие — только строки этой таблицы; упоминание требования в другом месте
      файла покрытием не считается. REMOVED требует проверки миграции/регрессии.
+     При skip_specs: true вместо дельт укажи существующее поведение/ограничение,
+     которое сохраняем, точный источник и регрессионную проверку.
      Пример:
-     | `portfolio/holdings` — `Итог портфеля не учитывает дубли операций` | повторный импорт того же файла брокера, итог не меняется | API | TC-HOLD-001 |
-     | `portfolio/holdings` — `Портфель показывает валюту` | not verified: только отображение, проверено ревью Scenario; риск низкий | — | — | -->
+     | `example-report` — `Отбор операций за календарный период` | Последний день периода и следующий день | Отчёт за октябрь включает X за 31.10 и исключает Y за 01.11 | API | ссылка на Scenario | -->
 
-| Requirement | Проверка | Уровень | Test cases |
-| --- | --- | --- | --- |
+| Requirement / регрессионный baseline | Сценарии / ветви правила | Проверка / ожидаемое наблюдение | Уровень | Test cases |
+| --- | --- | --- | --- | --- |
 
 ## Negative and Boundary Focus
 
+<!-- Границы до/на/после порога, отказ, повтор, конкуренция, сохранность данных —
+     только применимое. Ссылайся на нормы, не придумывай исходы. -->
+
 ## Cross-system Verification
 
 ## Test Data and Environment Needs
@@ -34,3 +40,6 @@
 ## Regression Impact
 
 ## Gaps / Blockers
+
+<!-- Цитата/heading → неоднозначность или непокрытый исход → владелец решения и
+     upstream-артефакт. Вопрос о значении expected result блокирует согласование. -->
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
index ecaad36..c850685 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
@@ -1,5 +1,8 @@
 <!--
-Оставь только нужные этой дельте разделы; комментарий удали до approval.
+Перед заполнением прочитай единый профиль:
+openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md.
+Оставь только нужные этой дельте разделы; подсказки и образец не входят в результат.
+Файл — specs/<capability-path>/spec.md с точным путём из Proposal.
 
 Только новая capability: `## Purpose` в 1–2 предложения (от 50 символов).
 Существующая capability: Purpose не добавляй.
@@ -11,22 +14,29 @@
 - `## REMOVED Requirements` — heading Requirement плюс **Reason** и **Migration**.
 - `## RENAMED Requirements` — только пары `FROM:` и `TO:`.
 
-Каждый нормативный Requirement осознанно использует BCP 14 (RFC 2119 + RFC 8174)
-uppercase SHALL/MUST и минимум один `#### Scenario:` с `- **WHEN**` и
-`- **THEN**`. Строчные «must/should/may» — обычный язык.
-Не оставляй пустые разделы операций и образцы.
+Каркас ADDED/MODIFIED: устойчивое имя → субъект SHALL <наблюдаемый результат>
+с явным условием, если оно нужно → определения/таблица → Scenarios.
+SHALL NOT — запрет; существующие MUST/MUST NOT равнозначны. Один Requirement —
+одно независимо принимаемое обязательство, не подсчёт предложений или SHALL.
+Сценарий: GIVEN — существенное исходное состояние, WHEN — событие,
+THEN — конкретный наблюдаемый исход. Минимум один Scenario; границы/отказы/повторы
+добавляй по смыслу. Новое правило в одном лишь сценарии недопустимо.
+Термины определены, величины имеют единицы и границы. Неизвестное — вопрос в
+Open Decisions с владельцем и зависимым требованием, не придуманный ответ.
 
-Пример:
+Учебный образец формы, не продуктовая политика:
 ## ADDED Requirements
-### Requirement: Итог портфеля не учитывает дубли операций
-Система SHALL учитывать каждый идентификатор операции брокера в итоге портфеля
-не более одного раза.
+### Requirement: Отбор операций за календарный период
+При формировании отчёта система SHALL включать все и только операции выбранного
+счёта, дата учёта которых входит в выбранный период включительно по Europe/Moscow.
 
-#### Scenario: Одна операция импортирована дважды
-- **WHEN** операция `op-1` на 100.00 RUB импортирована дважды
-- **THEN** итог портфеля увеличивается ровно на 100.00 RUB
+#### Scenario: Последний день периода и следующий день
+- **GIVEN** выбран период 01.10.2026–31.10.2026 и счёт A
+- **AND** на счёте A есть операции X с датой учёта 31.10.2026 и Y с датой 01.11.2026
+- **WHEN** формируется отчёт
+- **THEN** отчёт включает X и не включает Y
 
-Плохо: «Система SHALL корректно обрабатывать дубли» — нет наблюдаемого критерия;
-«THEN итог правильный» — нет ожидаемого значения; один Requirement на импорт,
-отображение и экспорт сразу — раздели по поведению.
+Плохо: «корректно отбирать операции до конца месяца» — не определены месяц,
+границы, дата отбора и счёт; «THEN список корректен» — нет проверяемого исхода.
+Для таблиц решений и переходов используй эталоны из профиля.
 -->
-- 
2.54.0


From a8047ed0600bd803a2ebc2bb4d63392a4cb6ff4b Mon Sep 17 00:00:00 2001
From: Sergey Krylov <ksv741@mail.ru>
Date: Fri, 30 Oct 2026 13:34:08 +0300
Subject: [PATCH 3/3] spec: clarify sdd-lab requirement guidance
 (WealthLedger/specs#66)

---
 .../wealth-ledger-sdd-lab/spec-writing.md     | 38 +++++++++++++++----
 .../wealth-ledger-sdd-lab/templates/spec.md   |  6 +++
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md b/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md
index ccfbad5..1a6aa71 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md
@@ -20,6 +20,12 @@ Specs определяют наблюдаемое поведение. Обосн
    существующего контракта. Наблюдение в коде, гипотеза и пример — не решение
    владельца. Неизвестное запиши в Open Decisions: вопрос, кто решает, зависимое
    требование и что блокируется. Несогласованные числа и варианты не становятся нормой.
+   Для спорного или выведенного при анализе Requirement перед первым Scenario добавь
+   `**Источник (ненормативно):**` — ссылку на конкретное решение Change Owner в Issue
+   или пункт согласованной редакции контракта. Ссылка должна оставаться пригодной из
+   canonical spec после archive; относительной ссылки на активный Proposal недостаточно.
+   Источник объясняет происхождение, но не заменяет полную норму или approval;
+   обоснование остаётся в Proposal.
 2. **Термины.** Используй названия из затронутых canonical specs и предоставленного
    проектного глоссария. Один термин — одно значение в названном контексте. «Счёт»,
    «брокерский счёт» и «учётная запись» не взаимозаменяемы. Новый или спорный термин
@@ -63,8 +69,9 @@ Specs определяют наблюдаемое поведение. Обосн
 
 У ADDED/MODIFIED Requirement минимум один Scenario. GIVEN нужен, когда исходное
 состояние влияет на результат; WHEN задаёт событие; THEN — наблюдаемый исход с
-определённым ожидаемым значением или составом, не «работает правильно». AND уточняет
-тот же исход. Шаги не описывают внутренние вызовы и селекторы UI.
+определённым ожидаемым значением или составом, не «работает правильно». AND продолжает
+предыдущий тип шага: дополняет исходный контекст, событие или ожидаемый исход.
+Шаги не описывают внутренние вызовы и селекторы UI.
 
 Сначала общее правило, затем различающие примеры: основной путь, существенная
 граница, иной исход, отказ, повтор или конкуренция — по применимости. Каждый сценарий
@@ -168,7 +175,7 @@ Specs определяют наблюдаемое поведение. Обосн
 | Проход | Что проверить |
 | --- | --- |
 | Нормоконтроль | Native headings/операции; термины и единицы; явные субъект/условие/исход; атомарность; корректные ссылки; Scenario с проверяемым THEN |
-| Смысл и набор | Необходимость и происхождение норм; основной путь, альтернативы, отказы и границы; повторы/конкуренция/сохранность по риску; непротиворечивость таблиц и итогового baseline; отсутствие выдуманных решений |
+| Смысл и набор | Необходимость и происхождение норм (у спорных/выведенных — источник действительно подтверждает норму, ссылка пригодна после archive); основной путь, альтернативы, отказы и границы; повторы/конкуренция/сохранность по риску; непротиворечивость таблиц и итогового baseline; отсутствие выдуманных решений |
 
 Проверь не только delta, но и получающийся набор вместе с canonical specs:
 сохранились ли действующие ограничения, исключения, инварианты и сценарии? MODIFIED
@@ -193,11 +200,26 @@ Gate Log, без нового отчёта на каждый Requirement.
 
 ### Trial
 
-Для проверки эффекта дай одним и тем же авторам/моделям одинаковые входы: простое
-правило, ветвление, повтор/состояние и MODIFIED. До сравнения зафиксируй согласованные
-исходы и намеренно оставленные неизвестные. Сравни ответы независимых читателей на
-контрольные вопросы, пропуски и выдуманные нормы, время уточнения и ревью. Совпадение
-формулировок и успешный CLI не считаются доказательством одинакового понимания.
+Эффект профиля проверяется сравнительным пилотом; до результатов он не подтверждён.
+
+1. До запуска зафиксируй четыре одинаковых для обеих версий задания: простое правило,
+   ветвление, повтор/состояние и MODIFIED с исходной canonical spec. Для оценки отдельно
+   запиши согласованные исходы, намеренно оставленные неизвестные и контрольные вопросы.
+2. Сравни прежнюю и изменённую инструкции минимум на двух авторах/моделях, каждый
+   выполняет обе версии. Сохрани входы, prompts, версии инструкций и моделей, доступные
+   настройки и результаты. Для LLM используй отдельные сессии без ответов другой версии;
+   для людей чередуй порядок версий, чтобы уменьшить эффект обучения.
+3. Независимые читатели отвечают на одинаковые контрольные вопросы по полученным
+   спецификациям, не зная автора и версии инструкции. Ответы для оценки из шага 1
+   раскрываются после чтения; согласие читателей само по себе не означает правильность.
+4. По каждому заданию сравни расхождения трактовок, ошибки относительно согласованных
+   исходов, пропущенные случаи, выдуманные нормы и время уточнения/ревью. Сохрани
+   конкретные примеры ошибок вместе с результатами в Issue пилота.
+5. Критерий улучшения согласуй до запуска: меньше смысловых расхождений без роста
+   ошибок, пропусков и выдуманных норм; допустимое изменение времени определяет владелец.
+   Если различий нет или данных недостаточно, эффект не подтверждён. Вывод ограничен
+   проверенными заданиями и авторами/моделями. Совпадение формулировок и успешный CLI
+   не считаются доказательством одинакового понимания.
 
 ## Sources and Adaptation
 
diff --git a/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md b/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
index c850685..e675091 100644
--- a/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
+++ b/openspec/schemas/wealth-ledger-sdd-lab/templates/spec.md
@@ -21,9 +21,15 @@ SHALL NOT — запрет; существующие MUST/MUST NOT равноз
 Сценарий: GIVEN — существенное исходное состояние, WHEN — событие,
 THEN — конкретный наблюдаемый исход. Минимум один Scenario; границы/отказы/повторы
 добавляй по смыслу. Новое правило в одном лишь сценарии недопустимо.
+AND дополняет предыдущий тип шага GIVEN/WHEN/THEN.
 Термины определены, величины имеют единицы и границы. Неизвестное — вопрос в
 Open Decisions с владельцем и зависимым требованием, не придуманный ответ.
 
+Для спорного/выведенного Requirement укажи источник перед первым Scenario по профилю.
+Пример формата (подставь реальное согласованное решение):
+**Источник (ненормативно):** [решение владельца](<URL-комментария-Issue>), пункт «Границы периода».
+Ссылка остаётся пригодной после archive; норму полностью сформулируй в Requirement.
+
 Учебный образец формы, не продуктовая политика:
 ## ADDED Requirements
 ### Requirement: Отбор операций за календарный период
-- 
2.54.0