WealthLedger/docs
5
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record AI governance audit

Browse Source
This commit is contained in:
ksv741
2026-08-24 19:55:28 +03:00
parent eb69300ebe
commit 1944f2fc97
21 changed files with 1764 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files
development/README.md
+1
View File
@@ -7,5 +7,6 @@
- [Backend workflow](backend-workflow.md) — bootstrap backend, локальные
non-mutating gates и границы e2e.
- [Audit remediation registry](audit-remediation.md) — текущий статус findings, следующий OpenSpec change и evidence завершённых улучшений.
- [Engineering governance](engineering-governance.md) — Change Owner, SDD approvals, Delivery Map, risk-based testing, build-versus-buy и hard guardrails.
- [OpenSpec authority и lifecycle](openspec-authority-and-lifecycle.md) — единственный SDD store, границы постоянной документации и условия archive.
- [Проверка runtime OpenAPI](runtime-openapi-verification.md) — отдельный read-only contract gate и его границы.
development/audit-remediation.md
+47 -7
View File
@@ -2,12 +2,12 @@
## Назначение
Это versioned реестр текущего состояния remediation для findings из [технического аудита 20.08.2026](../audits/audit-20-08-2026.md). Аудит — неизменяемый source of facts; этот документ хранит только приоритет, статус, путь продолжения и evidence последующих решений.
Это единый versioned реестр текущего состояния remediation для findings из всех [технических audit snapshots](../audits/README.md). Каждый аудит — неизменяемый source of facts; этот документ хранит только текущий статус, путь продолжения и evidence последующих решений, не копируя полный текст finding.
## Правила работы
- Каждая audit-derived запись имеет один статус: `planned`, `active`, `done`, `deferred` или `accepted`.
- Одновременно допускается не более одного `active` remediation change. При отсутствии active change раздел «Следующая задача» содержит ровно один рекомендуемый change.
- Одновременно допускается не более одного `active` remediation change. Пока он существует, продолжается только он. При наличии `planned` ровно одна запись отмечается следующей рекомендуемой задачей, но она не запускается параллельно active change.
- `done` требует даты, archive path OpenSpec change, commit для каждого затронутого Git-репозитория и точных non-mutating verification commands с observed results.
- `deferred` и `accepted` требуют даты, rationale и review trigger либо ссылки на явное решение владельца.
- При смене статуса обновляется только этот реестр; versioned audit snapshot не редактируется.
@@ -16,15 +16,55 @@
- Bootstrap change: [`2026-08-23-establish-audit-remediation-workflow`](../../specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow/) — `archived`; это process foundation и не закрывает ни одного Audit ID.
- Последний завершённый audit remediation change: [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) — `archived`; WL-P3-02, WL-P3-03, WL-P3-05 и WL-P3-06 закрыты.
- Активных audit remediation changes нет.
- Единственный active change: [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) — AUD24-01 и AUD24-03–AUD24-09, а также A-14–A-16 и A-18.
## Следующая задача
## Текущая задача
`tighten-backend-request-feedback`: выбрать policy для unknown request fields и
зафиксировать её в новом OpenSpec change для WL-P3-01.
Завершить `harden-agent-sdd-governance`. Пока change active, новый remediation change не создаётся.
## Следующая рекомендуемая задача
`assess-auth-platform-options` для AUD24-02. Она начинается только после archive текущего active change, применяет Solution Assessment к существующей реализации и зрелым auth platforms, включая Better Auth, и не предрешает миграцию.
## Реестр findings
### Аудит 13.08.2026
| Audit ID | Текущий статус | Связь и следующее действие | Terminal evidence или trigger |
| --- | --- | --- | --- |
| A-01 | done | См. WL-P2-03. | CAS rotation и regression test, 2026-08-23. |
| A-02 | accepted | Ограниченная revocation model закреплена в ADR 006; access token живёт 15 минут. | Пересмотреть, если продукт потребует немедленный отзыв access token. |
| A-03 | deferred | Production transport исключён из local MVP scope. | Пересмотреть перед hosted deployment или reverse-proxy contract. |
| A-04 | done | `docs/features/tbank-connection.md` описывает поставленные Accounts, Portfolio, Ledger и Future Events. | Current-state docs проверены 2026-08-24. |
| A-05 | done | См. WL-P1-03 и WL-P1-04. | Canonical root и hard archive lifecycle, 2026-08-23. |
| A-06 | done | См. WL-P2-10. | Architecture/development onboarding и link review, 2026-08-24. |
| A-07 | done | См. WL-P2-02. | P2002 mapping и concurrent registration regression, 2026-08-23. |
| A-08 | planned | Объединить validation payload review с `tighten-backend-request-feedback`. | Готово к выбору после active change. |
| A-09 | planned | Operations cache закрыт WL-P2-01; отдельно оценить session retention/index. | Создать scoped change после решения приоритета. |
| A-10 | deferred | Текущая operational mitigation описана в T-Bank feature doc. | Пересмотреть при наблюдаемой потере metadata или новом large-portfolio SLA. |
| A-11 | done | Исправлено и подтверждено самим snapshot 13.08.2026. | Transport tests и единый Bearer owner. |
| A-12 | done | Исправлено в snapshot; дополнительно защищено WL-P3-03. | Dependency boundary fixture passed, 2026-08-24. |
| A-13 | deferred | Frontend behavior закрыт; backend e2e зависит от WL-P2-05. | Тот же stable Prisma trigger, что у WL-P2-05. |
| A-14 | active | `harden-agent-sdd-governance`. | Completion Evidence только после archive. |
| A-15 | active | `harden-agent-sdd-governance`. | Обновить current-state ADR и links. |
| A-16 | active | `harden-agent-sdd-governance`. | Слоистые AGENTS и onboarding. |
| A-17 | deferred | Совпадает с accessibility scope WL-P3-04. | Пересмотреть при включении accessibility/second locale в MVP scope. |
| A-18 | active | `harden-agent-sdd-governance`. | Нормализовать H1 main spec и пройти strict validation. |
### Аудит 24.08.2026
| Audit ID | Цель | Статус | Связанный change | Следующее действие / evidence |
| --- | --- | --- | --- | --- |
| AUD24-01 | Ввести risk-based testing без тестов ради файла или coverage. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-02 | Оценивать mature solutions и ретроспективно проверить auth platform. | planned | `assess-auth-platform-options` | Начать только после active governance change; миграция не предрешена. |
| AUD24-03 | Закрепить строгий artifact graph и роли OpenSpec. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-04 | Синхронизировать agent projection и hard archive blockers. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-05 | Добавить canonical repo gates и workspace dispatcher. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-06 | Ввести docs-as-code gate и authoritative process policy. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-07 | Сделать AGENTS компактными routing/enforcement layers. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-08 | Охватить одним registry все audit snapshots и исправить stale status. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
| AUD24-09 | Исправить current-state ADR/spec contradictions. | active | [`harden-agent-sdd-governance`](../../specs/openspec/changes/harden-agent-sdd-governance/) | Завершить gates и archive. |
### P1
| Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
@@ -60,7 +100,7 @@
| WL-P3-01 | Сделать unknown request fields явной ошибкой или документированной policy. | backend | planned | `tighten-backend-request-feedback` (ещё не создан) | Выбрать validation policy. | — |
| WL-P3-02 | Устранить shared i18n import cycle. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; Node 22 `npm run verify` — passed. |
| WL-P3-03 | Восстановить FSD public API boundary. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; dependency fixture gate — passed. |
| WL-P3-04 | Исправить базовые language/loading accessibility semantics. | frontend | planned | — | Пересмотреть при включении accessibility в MVP scope. | — |
| WL-P3-04 | Исправить базовые language/loading accessibility semantics. | frontend | deferred | — | Пересмотреть при включении accessibility в MVP scope. | 2026-08-24; текущий local MVP scope не включает accessibility remediation. |
| WL-P3-05 | Ввести пропорциональный bundle regression budget. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; initial JS payload 509,165 B ≤ 512,000 B. |
| WL-P3-06 | Добавить coverage ratchet только как regression signal. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; coverage 82.57/76.08/77.35/83.48% — passed. |
| WL-P3-07 | Защитить рабочий `.env` от случайного commit. | frontend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; frontend `826936c`, specs `8897bd9`, docs `60a1c33`; hygiene check passed. |
development/backend-workflow.md
+6 -7
View File
@@ -14,17 +14,16 @@ npm ci
## Локальная проверка
Следующие команды не изменяют versioned-файлы:
Canonical gate не изменяет versioned-файлы:
```bash
npm run lint
npm run typecheck:app
npm run typecheck:test
npm test -- --runInBand
npm run verify
```
`npm run lint:fix` — явная записывающая команда. Runtime OpenAPI сверяется с
frontend snapshot из workspace:
Он проверяет Node 22 до application stages и последовательно запускает hygiene,
lint, application/test TypeScript, Jest и build. `npm run lint:fix` — явная
записывающая команда, а `npm run test:cov` — отдельная диагностика без общего
числового threshold. Runtime OpenAPI сверяется с frontend snapshot из workspace:
```bash
bash specs/scripts/verify-runtime-openapi.sh
development/engineering-governance.md
+116
View File
@@ -0,0 +1,116 @@
# Engineering governance
## Назначение
Этот документ — единственный источник устойчивой инженерной policy WealthLedger. Он определяет, как планировать и проверять изменения, но не хранит требования, design или tasks конкретного change. Нормативные change-specific артефакты находятся только в canonical OpenSpec store `wealth-ledger-specs` (`specs/openspec`).
## Термины
**Change Owner** — человек, который принимает текущий planning artifact и разрешает переход к следующему. Для продуктового поведения это Product Owner, для технического или процессного изменения — Engineering Owner.
**Delivery Map** — решение по каждой области `frontend`, `backend`, `specs` и `docs`: `affected` с ожидаемым результатом либо `N/A` с конкретной проверяемой причиной.
**Completion Evidence** — созданная после реализации и archive запись о фактической поставке: Delivery Map, archive path, commits изменённых репозиториев, точные verification commands с наблюдёнными результатами и итог independent read-only review.
**Enforceable Engineering Invariant** — обязательное правило с детерминированной non-mutating локальной проверкой, нарушение которой блокирует завершение change. Непроверяемое предпочтение является guidance, а не hard guardrail.
## Последовательность SDD
Каждый versioned change проходит один граф:
```text
Proposal → Delta Specs → Design → Tasks → Apply → Verify → Archive
```
- Proposal формулирует намерение, границы и ожидаемый результат без технологий, API, файлов и зависимостей.
- Delta Specs описывают изменение наблюдаемого поведения и инвариантов без изменений кода.
- Design объясняет архитектурный способ реализации крупными частями, риски и альтернативы; он не является построчной инструкцией.
- Tasks — implementation checklist, достаточный для выполнения Design и Specs. Он содержит планируемые проверки, но не будущие результаты, commits или post-archive bookkeeping.
AI-агент готовит только текущий разрешённый артефакт, показывает его Change Owner и останавливается. Downstream artifact создаётся только после явного approval. Если новая сессия не может подтвердить approval из доступного контекста, агент запрашивает его повторно.
Изменение принятого upstream artifact инвалидирует approval зависимых артефактов: Proposal — Specs, Design и Tasks; Specs — Design и Tasks; Design — Tasks. Tasks не могут неявно расширять scope или менять поведение и архитектуру: работа возвращается к соответствующему upstream artifact.
## Delivery Map и multi-repository delivery
Design каждого change оценивает все четыре области:
- `specs` всегда `affected` для versioned SDD change;
- `docs` всегда `affected` для поставленной пользовательской фичи; для технического изменения допустимо `N/A`, только если as-built документация действительно не меняется;
- `frontend` и `backend` являются `affected`, когда меняются их поведение, контракт, реализация или обязательный local gate;
- `N/A` требует конкретной причины; пустой commit не имитирует участие репозитория.
Change остаётся active, пока каждая affected область не реализована и не прошла свой canonical gate. Design содержит Contract Gate Decision: `runtime-openapi` имеет статус `required`, когда изменение затрагивает frontend и backend стороны API contract, иначе `N/A` с конкретной причиной. Успех одного репозитория не компенсирует отсутствие или failure другого.
## Risk-based testing
Автоматизированный тест обязателен, когда изменение затрагивает хотя бы один существенный риск:
- security- или privacy-sensitive поведение;
- денежные вычисления;
- целостность или миграцию данных;
- конкурентный доступ;
- публичный контракт;
- критический пользовательский journey;
- подтверждённую регрессию.
Уровень теста выбирается по наблюдаемому поведению и наиболее дешёвой надёжной границе. Тест не создаётся только потому, что появился или изменился файл. DTO без собственной логики, декларативная конфигурация, тонкий адаптер, прямолинейная оркестрация, hygiene script и поведение сторонней библиотеки проверяются существующим contract или integration gate без отдельного unit test, пока в проектном коде нет самостоятельного ветвления, преобразования, инварианта либо регрессии.
Frontend coverage gate — anti-regression constraint. Он не является причиной писать малоценные тесты декларативных файлов. Для backend нет общего числового coverage threshold; новый threshold допустим только через отдельное утверждённое обоснование защищаемого риска.
Проверка самого нового hard guardrail должна показать успешный compliant case и отказ на одном контролируемом репрезентативном нарушении. Это не превращает каждый вспомогательный script в объект unit testing.
## Build versus buy
До утверждения Design обязательна оценка зрелых поддерживаемых решений, если change вводит или существенно заменяет:
- авторизацию или иной security-механизм;
- хранение данных;
- внешнюю интеграцию;
- observability;
- caching или concurrency control;
- общую инфраструктуру или tooling.
Solution Assessment сравнивает применимые варианты по соответствию требованиям, зрелости, безопасности, эксплуатационной стоимости, ограничениям и стоимости миграции. Поддерживаемое совместимое решение используется либо Design конкретно объясняет, почему его совокупная стоимость или риск выше выбранной альтернативы.
Собственная реализация допустима, только если подходящего решения нет или доказана существенная несовместимость. Тогда Design фиксирует проверенные варианты, конкретные gaps, принятые риски и trigger повторного рассмотрения. Для обратимого изменения вне перечисленных областей отдельная формальная оценка не создаётся ради процесса.
## Single Source of Truth
| Вид знания | Authoritative location |
| --- | --- |
| Намерение, требования, Design, Tasks, changes и archives | `specs/openspec` |
| Исполняемое поведение | `frontend` и `backend` code и risk-based tests |
| Публичный API contract | backend runtime OpenAPI и committed frontend snapshot |
| Текущее устройство и поставленные возможности | `docs/architecture` и `docs/features` |
| Устойчивые архитектурные решения и причины | `docs/adr` |
| Инженерная policy и completion evidence | `docs/development` |
| Компактная маршрутизация AI-агентов | root и repository-local `AGENTS.md` |
`docs` описывает только фактическое текущее состояние и не пересказывает Proposal, Delta Specs, Design или Tasks другим форматом. `AGENTS.md` не копирует архитектуру или feature documentation: он направляет к authority и перечисляет только применимые hard constraints и canonical commands.
## Guardrails и local gates
CI пока отсутствует, поэтому обязательные gates выполняются локально одним и тем же способом человеком, AI-агентом и workspace verifier:
| Область | Canonical gate |
| --- | --- |
| frontend | `npm run verify` в `frontend` |
| backend | `npm run verify` в `backend` |
| specs | `bash specs/scripts/verify-workspace-change.sh <change>` из workspace root |
| docs | `npm run verify` в `docs` |
Каждый gate non-mutating и fail-fast. Auto-fix commands выполняются отдельно и не служат доказательством корректности. Runtime preflight отклоняет неподдерживаемый Node до application checks; OpenSpec preflight аналогично отклоняет несовместимую CLI version до операций со store.
Hard guardrail должен иметь исполняемую локальную проверку. Правило без надёжной проверки помечается как guidance и учитывается в review, но не выдаётся за автоматический запрет. Новые frameworks, checkers и thresholds добавляются только после оценки поддерживаемого решения, maintenance cost и реально защищаемого риска.
## Verify, archive и Completion Evidence
Structural validation OpenSpec проверяет schema и форму артефактов, но не соответствие реализации. До archive обязательны:
1. успешные canonical gates всех affected areas;
2. semantic verification реализации против Proposal, Delta Specs, Design и Tasks;
3. independent read-only review без Critical и Important findings;
4. завершённый checklist без unchecked tasks.
Archive не имеет confirmation override для этих blockers. После успешного archive применяется двухфазная фиксация: сначала commits поставленных изменений и archive/sync, затем Completion Evidence с уже существующими delivery commit IDs, после чего отдельный final docs commit сохраняет evidence. Evidence ссылается на предшествующий as-built docs commit, если docs affected; при `N/A` сохраняет причину и не выдумывает implementation commit. Собственный final evidence commit не может ссылаться сам на себя и сообщается итогом archive workflow. Только фактические commits, выполненные команды и наблюдённые результаты могут быть evidence; planned значения и предположения не считаются завершением.
development/frontend-workflow.md
+5 -1
View File
@@ -7,7 +7,11 @@ npm ci
npm run verify
```
`verify` проверяет OpenAPI drift, TypeScript, Biome, unit tests и coverage, Knip, FSD dependency rules и production build. Он работает без backend.
`verify` сначала отклоняет runtime вне Node 22, затем проверяет OpenAPI drift,
repository hygiene, TypeScript, Biome, один coverage-backed запуск Vitest,
Knip, FSD dependency rules, production build и bundle budget. Он работает без
backend. Coverage остаётся anti-regression constraint; правила выбора тестов
зафиксированы в [engineering governance](engineering-governance.md).
Backend остаётся источником OpenAPI. После изменения опубликованного backend-контракта разработчик запускает в `frontend/`:
development/openspec-authority-and-lifecycle.md
+50 -12
View File
@@ -2,29 +2,67 @@
## Назначение
Этот документ фиксирует постоянные границы SDD-процесса WealthLedger. Он не содержит requirements, design, delta-specs или tasks конкретного change: они живут только в canonical OpenSpec store.
Этот документ описывает фактически настроенный OpenSpec workflow WealthLedger. Общие определения, approval policy, risk-based testing и build-versus-buy находятся в [Engineering governance](engineering-governance.md).
## Единственный SDD store
- Canonical OpenSpec store: `wealth-ledger-specs`.
- Canonical store: `wealth-ledger-specs`.
- Физический root: `specs/openspec` относительно workspace.
- Requirements, design, delta-specs, tasks, changes и archives создаются и коммитятся только в этом store.
- Любая OpenSpec command, читающая или изменяющая change, явно использует `--store wealth-ledger-specs`; cwd, ближайший root и глобальная конфигурация машины не выбирают store проекта.
- Requirements, Delta Specs, Design, Tasks, changes и archives хранятся только в этом store.
- Команда, читающая или изменяющая change, всегда получает `--store wealth-ledger-specs`; cwd и nearest-root discovery не выбирают authority проекта.
- Versioned framework-specific planning artifacts вне `specs/openspec`, включая `superpowers/plans`, запрещены. `references/**` остаётся read-only исключением.
## Границы артефактов
Exact поддерживаемая OpenSpec CLI version хранится в `specs/openspec/.cli-version`. Перед project-owned операциями выполняется:
- `docs` хранит только долговечную architecture, development, feature, audit и remediation documentation, включая completion evidence после archive.
- `frontend` и `backend` хранят runtime code и tests, но не framework-specific planning artifacts.
- Framework-specific requirements, plans, specs, design и task artifacts вне `specs/openspec` не создаются и не коммитятся; это включает `superpowers/plans`.
- `references/**` — read-only reference content. Его framework artifacts не являются нарушением и не подлежат переносу или очистке без отдельной задачи.
```bash
bash specs/scripts/verify-openspec-version.sh
```
## Завершение change
Несовпадение version блокирует операцию до чтения или изменения store.
Archive разрешён только после завершения всех planning artifacts и всех tasks. Post-archive bookkeeping не может быть незакрытым task: после успешного archive durable registry/history фиксирует фактический archive path, commits затронутых репозиториев, команды проверки и observed results.
## Project-local schema
Перед завершением change выполните из workspace:
Новые changes по умолчанию используют schema `wealth-ledger-sdd` из `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.
Project-local schema проверяется из `specs`:
```bash
openspec schema validate wealth-ledger-sdd --verbose
openspec schema which wealth-ledger-sdd --json
```
`schema which` должен указывать project-local source. `specs/openspec/config.yaml` хранит default schema и компактный routing context, а не копию полной policy.
## Agent entrypoints и обновление OpenSpec
Root `.opencode` — generated local projection OpenSpec 1.10 с минимальными WealthLedger overlays: fixed store, one-artifact-at-a-time и hard archive blockers. Она не является SSOT, потому что workspace root не versioned.
`openspec update` не запускается напрямую из workspace root. Новую upstream version сначала генерируют в isolated staging, сравнивают с projection, переносят upstream delta и повторно накладывают project overlays. После этого обязательно выполняют authority fixtures; permissive archive, conditional store selection и второй `openspec` root считаются failures.
## Реализация и проверка change
Design содержит Delivery Map для `frontend`, `backend`, `specs` и `docs`. Из workspace один non-mutating dispatcher проверяет карту и запускает canonical gates affected areas:
```bash
bash specs/scripts/verify-workspace-change.sh <change>
```
`specs` проверяется всегда. Dispatcher читает явный Contract Gate Decision из Design и сравнивает backend runtime OpenAPI с committed frontend snapshot только при `runtime-openapi: required`; этот status допустим лишь при affected frontend и backend. Child failure блокирует общий результат; fallback и auto-fix отсутствуют.
Перед archive отдельно подтверждаются structural и semantic gates:
```bash
bash specs/scripts/verify-openspec-authority.sh
openspec validate <change> --type change --strict --store wealth-ledger-specs
openspec validate --specs --strict --store wealth-ledger-specs
```
Structural success не доказывает соответствие реализации. Project-owned verify workflow сопоставляет реализацию с Proposal, Delta Specs, Design и Tasks, затем требует independent read-only review без Critical и Important findings.
Archive отклоняется при незавершённом artifact approval, unchecked task, failed affected-area gate, отсутствующей semantic verification или independent review. Confirmation override для этих условий отсутствует. Completion Evidence создаётся только после archive и delivery commits по двухфазному протоколу [Engineering governance](engineering-governance.md); final evidence commit не подменяется незакрытым task.