docs: record second OpenSpec schema review

development/openspec-authority-and-lifecycle.md

@@ -26,14 +26,24 @@ agent workflow, store resolution и hard blockers; historical archives
 
 ## Project-local schema
 
-Новые changes по умолчанию используют schema `wealth-ledger-sdd` version 2 из
+Новые changes по умолчанию используют schema `wealth-ledger-sdd` version 3 из
 `specs/openspec/schemas/wealth-ledger-sdd`. Её граф:
 
 ```text
 proposal → specs → design → tasks → apply
 ```
 
-OpenSpec обеспечивает structural order, а явное решение Change Owner — переход между артефактами. Agent создаёт один текущий artifact и останавливается для approval. Роли артефактов и cascade rules определены в governance policy; исполняемые templates и instructions принадлежат schema.
+OpenSpec обеспечивает structural order, а явное решение Change Owner — переход
+между артефактами. Agent создаёт один текущий artifact и останавливается для
+approval. Роли артефактов и cascade rules определены в governance policy;
+исполняемые templates и instructions принадлежат schema. Каждая instruction
+начинается компактным блоком `Critical Rules`; основной explanatory prose
+написан по-русски, а exact OpenSpec headings, tokens и normative keywords
+сохраняются на английском.
+
+Delta Spec template является operation-neutral comment guide. Он перечисляет
+`ADDED`, `MODIFIED`, `REMOVED` и `RENAMED`, но не создаёт активную operation
+section. Автор добавляет только применимые sections и не оставляет пустых.
 
 До запроса approval выполняется доступная stage-aware проверка:
 
@@ -43,9 +53,11 @@ bash specs/scripts/verify-openspec-planning.sh <change>
 
 Proposal проверяется без ложного объявления полного change success; по мере
 появления Specs, Design и Tasks добавляются strict validation, Delivery Map,
-rollback, area ownership и exact Requirement coverage. Технический format
-failure исправляется и проверяется повторно; structural success не означает
-approval.
+rollback, area ownership и exact Requirement coverage. Planning result имеет
+три категории: `artifact-validation` (exit 1), `invocation` (exit 2) и
+`environment` (exit 3). Только первая разрешает менять проверяемый planning
+artifact; две остальные требуют исправить invocation или prerequisite.
+Structural success не означает approval.
 
 Project-local schema проверяется из `specs`:
 
@@ -83,7 +95,16 @@ bash specs/scripts/verify-workspace-change.sh <change>
 Перед affected-area gates dispatcher повторяет planning verifier. Tasks имеют
 формат `X.Y [area] action` и indented `Covers`/`Verification`; каждый Delta
 Requirement покрывается точной ссылкой хотя бы один раз, а `workspace` остаётся
-только owner orchestration/verification.
+только owner orchestration/verification. Для `N/A` verifier отклоняет пустой,
+separator-only или unresolved placeholder, а содержательность rationale
+подтверждается semantic review.
+
+Apply читает planning artifacts только из `contextFiles`, возвращённых native
+`openspec instructions apply --json`, затем repository-local `AGENTS.md`
+affected areas. Второй context mapping не поддерживается. Без reapproval можно
+исправить только Markdown heading, typo без изменения нормативного смысла или
+table alignment; Requirement, Scenario, architecture и planned Verification
+являются semantic changes.
 
 Перед archive отдельно подтверждаются structural и semantic gates: