spec: add requirement-writing profile to sdd-lab (WealthLedger/specs#66)

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