feat: harden OpenSpec SDD workflow

This commit is contained in:
2026-08-26 00:42:35 +03:00
parent 039b72eed3
commit a8b2c4eed9
42 changed files with 4024 additions and 181 deletions
@@ -0,0 +1,7 @@
schema: wealth-ledger-sdd
created: 2026-08-25
goal: Make WealthLedger SDD changes reliably traceable, reproducible, and
maintainable across future OpenSpec upgrades.
affected_areas:
- specs
- docs
@@ -0,0 +1,276 @@
## Context
WealthLedger использует project-local OpenSpec schema поверх CLI 1.10.0,
canonical store в отдельном specs-репозитории и project-owned OpenCode
entrypoints в unversioned workspace root. Schema уже задаёт последовательный
artifact graph, а repository scripts защищают store authority, Delivery Map и
terminal verification. Однако planning quality до Apply проверяется
неравномерно, Tasks не имеют машиночитаемой связи с requirements и delivery
areas, а root agent projection проверяется только как локально существующее
состояние и не восстанавливается из четырёх Git-репозиториев.
Custom schema API остаётся experimental, поэтому совместимость нельзя безопасно
выводить только из SemVer. Root workspace не является Git-репозиторием;
versioned authority для новых guardrails и projection recovery должен
принадлежать `specs`, а as-built policy, audit snapshots и dispositions —
`docs`. Других active OpenSpec changes нет. Этот change создан по schema version
1, поэтому его собственные Tasks должны вручную соответствовать утверждённому
v2 contract до того, как Apply сделает этот contract default для будущих
changes.
## Goals / Non-Goals
**Goals:**
- сделать planning structure, task ownership и requirement coverage
детерминированно проверяемыми до Apply;
- восстановить project-owned agent workflow из versioned inputs и обнаруживать
drift derived projection;
- сохранить один exact supported CLI contract, пригодный для контролируемого
будущего upgrade;
- распределить guidance между schema, config, durable policy и verifiers без
конкурирующих источников;
- сохранить все source assessments и нормализовать их claims с доказательными
dispositions;
- сохранить пропорциональность workflow и существующие human approval gates.
**Non-Goals:**
- обновление OpenSpec CLI в этом change;
- изменение frontend, backend, runtime API или deployment behavior;
- универсальная схема для других проектов, Fast Track или второй lifecycle;
- собственный workflow engine, identity/signature system для approvals или
общий dependency scheduler для changes;
- автоматическое доказательство смысловой полноты Proposal, Specs или Design;
- новые review, completion, blocker, revision либо traceability artifacts.
## Decisions
### 1. Native schema v2 остаётся workflow engine
`wealth-ledger-sdd` повышается до version 2, сохраняя граф
`Proposal → Delta Specs → Design → Tasks → Apply`. Изменяется contract
существующих artifacts, а не их число. Schema и templates задают обязательную
форму Tasks, условный rollback contract, stage validation guidance, полный
feedback path и компактные примеры сложных delta operations. Minimal spec
template остаётся ориентированным на `ADDED`; неиспользуемые delta sections не
генерируются как пустые placeholders.
Artifact approval остаётся человеческим фактом разговора. File existence и
CLI status продолжают означать только structural state. Форматное исправление,
не меняющее approved semantics, повторяет structural checks без каскадного
reapproval; любое изменение intent, behavior, architecture или task scope
возвращает workflow к самому раннему затронутому artifact и инвалидирует его
downstream approvals.
### 2. Guidance имеет явных владельцев
Ответственность разделяется так:
| Surface | Authority |
| --- | --- |
| schema instructions | artifact semantics, native syntax и workflow behavior |
| templates | только форма создаваемого Markdown |
| config context | стабильные факты workspace и язык project artifacts |
| config rules | только краткие additive project constraints, отсутствующие в schema |
| governance и ADR | durable rationale, ownership и upgrade policy |
| non-mutating verifiers | Enforceable Engineering Invariants |
Текущие config rules, дословно повторяющие schema, удаляются или сокращаются;
произвольный `_rules.md` не вводится. Project explanations пишутся по-русски,
а OpenSpec tokens, headings, commands и normative keywords сохраняются в их
точной английской форме.
### 3. Planning verifier отделён от full delivery dispatcher
`specs` получает один stage-aware non-mutating planning verifier. Он разрешает
change через canonical store и применяет только доступные на текущем этапе
checks:
- Proposal — metadata, обязательную структуру и разрешимость declared existing
capability paths;
- Delta Specs — strict change validation и соответствие capability set
Proposal;
- Design — Delivery Map, Contract Gate Decision и rollback decision;
- Tasks — checkbox shape, area ownership, canonical gate coverage и точные
requirement references, включая explicit `N/A` rationale.
Verifier не пытается машинно оценивать качество мотивации, архитектурного
rationale или semantic correctness. Full workspace dispatcher вызывает его
перед affected-area gates, а artifact entrypoints запускают доступный stage до
запроса approval. Проверяемая логика получает compliant fixtures и
representative failures для uncovered requirement, invalid area, malformed
rollback decision и projection/version drift. Существующие parsers Delivery Map
переиспользуются либо извлекаются, а не дублируются вторым несовместимым
разбором.
### 4. Tasks используют area owner и встроенную coverage metadata
Каждый checkbox использует формат `X.Y [area] action`, где `area` — ровно одна
из `frontend`, `backend`, `specs`, `docs`, `workspace`. Следующие indented
metadata lines содержат:
- `Covers`: одна или несколько пар `capability path — exact Requirement
heading` либо `N/A — concrete reason`;
- `Verification`: planned command, observable check или delivered artifact.
OpenSpec продолжает отслеживать progress по checkbox line, а planning verifier
связывает последующие metadata lines с ближайшим checkbox. Cross-repository
implementation разбивается по repository owners; `workspace` используется
только для orchestration и verification. Requirement heading остаётся native
identity OpenSpec; дополнительный ID namespace не создаётся.
### 5. Root agent projection получает versioned canonical source
Текущие project-owned `commands` и `skills` импортируются как canonical source
tree под `specs/agent-projection/opencode`. Package manifests, installed
dependencies и machine-local runtime state не входят в source. Явная sync
команда атомарно обновляет соответствующие каталоги root `.opencode`, а
отдельный non-mutating verifier сравнивает required file set и contents с
canonical source.
На upgrade новая upstream projection сначала создаётся в isolated staging.
Upstream delta и минимальные WealthLedger overlays — fixed store,
one-artifact-at-a-time approvals, feedback path и hard archive blockers —
переносятся в canonical source, после чего sync обновляет root derived output.
Authority verifier получает expected version из единственного version contract
и проверяет совпадение каждого required generated marker. Concrete CLI version
не закрепляется в verifier logic или fixtures независимо от contract.
Canonical source tree выбран вместо:
- patch set: меньше committed content, но patches хрупки к upstream text churn;
- custom generator: устраняет дублирование, но создаёт новый transformation
engine и повышает maintenance cost;
- symlink: устраняет copy drift, но связывает agent discovery с filesystem и
tool-specific symlink behavior;
- manual staging only: сохраняет текущую простоту, но не обеспечивает recovery
из clean checkouts.
### 6. Rollback contract является условной частью Design
Design template получает внутри Migration Plan структурированный rollback
decision. Для auth/security, data integrity или migration, public contract и
других труднообратимых решений status `required` раскрывает trigger, actions,
data safety и verification. Для остальных changes status `N/A` требует
конкретной причины. Отдельный rollback artifact не создаётся.
У этого change rollback contract имеет status `N/A`: application data,
security behavior и public contracts не меняются, а committed specs/docs
обратимы через Git. Initial projection cutover выполняется атомарно и сохраняет
предыдущее local derived state до успешного verification, чтобы failed sync не
оставил частично обновлённый workspace.
### 7. Multi-source assessment хранит raw evidence и отдельный triage
Пять исходных model reports переносятся byte-for-byte в один dated audit
snapshot set под `docs/audits`; index обозначает их как external, non-authority
claims и фиксирует checksums. После проверки совпадения исходная unversioned
папка удаляется, чтобы не оставить competing copy.
Live registry получает нормализованные Audit IDs. Повторяющиеся claims имеют
одну запись со ссылками на все sources. Triage disposition
`confirmed | already-covered | rejected | deferred` хранится отдельно от
remediation status. Confirmed findings этого scope связываются с текущим active
change; already-covered получают existing evidence; rejected — rationale;
deferred — review trigger. Следующим planned remediation после завершения этого
change снова становится ранее выбранная auth platform assessment.
### 8. Version contract фиксирует совместимость, а не вечную версию
Текущая exact version остаётся неизменной. Появление новой stable версии не
блокирует delivery и не меняет contract автоматически. Future upgrade является
отдельным SDD change и проходит staged projection comparison, schema/status/
instructions compatibility, canonical-store checks, disposable lifecycle и
positive/negative authority fixtures. Historical archives и Completion Evidence
сохраняют фактические версии своих запусков.
## Delivery Map
| Area | Status | Architectural outcome or N/A reason |
| --- | --- | --- |
| frontend | `N/A` | Change не меняет frontend behavior, source, contract или canonical gate. |
| backend | `N/A` | Change не меняет backend behavior, source, contract или canonical gate. |
| specs | `affected` | Schema v2, planning/projection guardrails, canonical agent source и нормативные lifecycle requirements образуют единый проверяемый SDD contract. |
| docs | `affected` | Immutable multi-source audit, dispositions, governance, lifecycle documentation и ADR отражают поставленную SDD-систему. |
### Contract Gate Decision
| Gate | Status | Reason |
| --- | --- | --- |
| runtime-openapi | `N/A` | Change не затрагивает backend runtime API, frontend generated client или committed OpenAPI snapshot. |
## Solution Assessment
Change существенно меняет общую project tooling infrastructure, поэтому
сравнение alternatives обязательно.
### Workflow enforcement
| Option | Fit и maturity | Security / operating cost | Constraints / migration cost | Decision |
| --- | --- | --- | --- | --- |
| Native OpenSpec schema/config + thin project verifiers | Полностью сохраняет canonical artifact graph; используемые extension points уже работают в 1.10, хотя schema API experimental | Local-only, без новых secrets/services; низкая стоимость поверх существующих gates | Требует exact compatibility contract и fixtures при upgrade; incremental migration | Selected |
| Prompt/docs-only conventions | Markdown mature и дёшев, но не отклоняет нарушения | Низкая стоимость, высокий риск silent drift | Не выполняет требования machine validation и reproducibility | Rejected |
| Собственный workflow engine | Максимальный theoretical fit, но custom maturity отсутствует | Новый privileged control surface и высокая постоянная стоимость | Дублирует OpenSpec lifecycle, требует migration всех entrypoints и state | Rejected |
| Общая monorepo/CI platform | Зрелые продукты существуют, но workspace не имеет общего build/dependency graph и CI | Существенная installation и operating cost | Не решает approval semantics или audit traceability сама по себе | Rejected |
### Projection recovery
| Option | Fit и maturity | Operating cost | Main constraint | Decision |
| --- | --- | --- | --- | --- |
| Versioned canonical source tree + sync/check | Простая file projection с детерминированным сравнением | Низкая; около 115 KB source Markdown | Source и derived copy должны проверяться на drift | Selected |
| Versioned overlay patches | Компактно | Средняя/высокая при каждом upstream text change | Patch fragility | Rejected |
| Programmatic overlay generator | Гибко | Высокая; собственная transformation logic | Риск второго workflow engine | Rejected |
| Symlink в specs-owned tree | Минимум duplication | Низкая локально | Tool/filesystem portability и смешение machine-local package state | Rejected |
Выбранный вариант не реализует OpenSpec behavior самостоятельно: native CLI
остаётся engine, а project scripts только синхронизируют derived files и
проверяют детерминированные инварианты.
## Risks / Trade-offs
- **Canonical source и derived projection дублируют Markdown.** Drift блокирует
verifier; изменения вносятся только в source и распространяются explicit
sync-командой.
- **Markdown parser может стать хрупким.** Машиночитаемые prefixes и metadata
намеренно узкие, fixture suite покрывает compliant и representative invalid
inputs, а semantic review остаётся отдельным gate.
- **Traceability создаёт ложное ощущение semantic coverage.** Verifier
подтверждает наличие ссылок, но semantic verification и independent review
продолжают проверять полноту реализации.
- **Форматное исключение может скрыть semantic edit.** Оно ограничено ошибками,
не меняющими intent, behavior, decisions или tasks; сомнение возвращает
artifact на обычный reapproval path.
- **Schema instructions могут разрастись.** Duplicate config rules удаляются,
examples остаются короткими, а final instruction size сравнивается с
baseline без жёсткого token threshold.
- **Raw model reports могут выглядеть authoritative.** Snapshot index и registry
явно разделяют source claims, triage evidence и project authority.
- **Initial source-tree bootstrap не имеет прежней versioned baseline.** Sync
сохраняет local pre-cutover state до успешного gate; после поставки все
дальнейшие projection versions становятся восстановимыми через Git history.
- **Future OpenSpec release может изменить experimental interfaces.** Exact
contract блокирует silent adoption, а отдельный upgrade change выполняет
staged compatibility assessment.
## Migration Plan
1. Ввести canonical projection source и non-mutating planning/projection checks,
подтвердив compliant и controlled-invalid fixtures до переключения schema.
2. Обновить schema, templates, config и canonical agent source до v2 contract;
собственные Tasks этого change оформить уже в новом формате.
3. Атомарно синхронизировать root derived projection и отклонить delivery при
любом content/version drift.
4. Перенести raw assessments в immutable indexed snapshot, проверить
byte-for-byte equality, удалить unversioned copy и обновить live registry.
5. Обновить governance, lifecycle docs и ADR до фактической архитектуры, затем
выполнить specs/docs gates, semantic verification и independent review.
### Rollback Contract
| Field | Decision |
| --- | --- |
| Status | `N/A` |
| Reason | Change не меняет application data, security behavior или public contracts; committed state обратим через Git, а projection является derived output с atomic cutover. |
| Failed cutover handling | Sync восстанавливает сохранённое pre-cutover local state и не объявляет source/projection согласованными. |
| Verification | Planning, projection, authority, strict OpenSpec и docs gates должны снова подтвердить выбранное состояние. |
@@ -0,0 +1,58 @@
## Why
WealthLedger уже использует строгий SDD lifecycle, но его качество сейчас
зависит от нескольких разрозненных соглашений и ручной семантической проверки.
Собранные независимые оценки выявили повторяющиеся риски: требования могут быть
недостаточно явно связаны с работой по их поставке, ответственность задач в
multi-repository workspace может читаться неоднозначно, а восстановление и
эволюция workflow требуют слишком много неявного знания. Эти риски стоит
устранить до следующих remediation changes, чтобы последующая разработка
опиралась на воспроизводимый и проверяемый процесс.
## What Changes
- Установить единый проверяемый контракт качества SDD, связывающий изменяемые
требования, запланированную delivery-работу и ответственность каждой области.
- Сделать возврат к upstream artifact, повторное утверждение и риск-обусловленный
rollback явными частями lifecycle, не создавая параллельных planning artifacts.
- Обеспечить воспроизводимость project-owned agent workflow и управляемую
совместимость при будущей смене поддерживаемой версии инструмента.
- Сохранить исходные multi-source audit assessments неизменными и дать каждому
нормализованному замечанию проверяемый итог: исправление, подтверждённое
существующее покрытие, осознанное отклонение либо отложенный trigger.
- Разделить устойчивую policy, artifact-specific guidance и автоматические
guardrails так, чтобы обязательное правило имело одного владельца и не
зависело от необязательного чтения дополнительного контекста.
Не входят в change: изменение поведения приложений или публичных контрактов,
создание универсального SDD framework для других проектов, отдельный ускоренный
lifecycle, новая модель identity для owner approval, дополнительные planning
artifacts и общий механизм зависимостей между changes без наблюдаемой
потребности.
## Capabilities
### New Capabilities
Нет.
### Modified Capabilities
- `openspec-authority-and-lifecycle`: усилить воспроизводимость workflow,
совместимость поддерживаемой версии, проверки planning artifacts и
контролируемый возврат к изменённому upstream artifact.
- `multi-repository-delivery`: сделать ownership задач и покрытие изменяемых
требований явными и проверяемыми для каждой delivery area.
- `engineering-change-governance`: дополнить risk-based planning обязательной
rollback discipline для труднообратимых изменений и проверяемыми SDD
guardrails.
- `audit-remediation-workflow`: поддержать неизменяемое multi-source audit
evidence и нормализованные dispositions без превращения внешних оценок в
authority проекта.
## Impact
Изменение затрагивает Change Owner и AI-агентов, которые создают, утверждают,
реализуют и проверяют WealthLedger changes. Оно изменяет нормативный SDD
workflow и его as-built process documentation, но не меняет frontend, backend,
пользовательское поведение или runtime API contracts.
@@ -0,0 +1,46 @@
## MODIFIED Requirements
### Requirement: Реестр remediation отделён от снимка аудита
Система SHALL создавать отдельный неизменяемый versioned audit snapshot в `docs/audits` для каждого завершённого аудита и SHALL поддерживать один актуальный durable remediation registry в `docs/development`, охватывающий findings всех audit snapshots. Для завершённого multi-source audit система SHALL сохранять каждый source file byte-for-byte и объединять их одним snapshot index. Каждый snapshot SHALL оставаться source of claims своего аудита и MUST NOT редактироваться для отражения последующей remediation. Внешняя модельная оценка MUST быть обозначена как неавторитетный источник claims и MUST NOT подменять requirements, governance или проверенное состояние проекта. Registry SHALL хранить текущее состояние, связанный canonical change, следующее действие и completion evidence каждой записи, MUST ссылаться на однозначный Audit ID и каждый относящийся source snapshot и MUST NOT дублировать полный текст finding, если он уже содержится в snapshot.
#### Scenario: Агент открывает работу по аудиту в новой сессии
- **WHEN** агент получает задачу устранить или продолжить finding из любого завершённого аудита
- **THEN** он находит в едином registry исходный snapshot и Audit ID, текущий статус, связанный OpenSpec change, evidence и следующее действие без повторной интерпретации всех аудитов
#### Scenario: Проводится повторный аудит
- **WHEN** новый аудит завершён после предыдущего audit snapshot
- **THEN** система добавляет новый immutable snapshot и обновляет тот же live registry, не переписывая предыдущий snapshot и не создавая конкурирующий registry
#### Scenario: Обновляется прогресс remediation
- **WHEN** работа по finding меняет статус
- **THEN** versioned audit snapshots не редактируются, а изменение фиксируется только в live registry с датой и необходимым evidence
#### Scenario: Один аудит содержит несколько внешних оценок
- **WHEN** завершённая assessment использовала несколько независимых source reports
- **THEN** snapshot index связывает byte-for-byte сохранённые reports в один audit и явно отделяет их claims от project authority
## ADDED Requirements
### Requirement: Каждое audit claim получает доказательный disposition
Каждое уникальное claim завершённого multi-source audit MUST входить ровно в один нормализованный Audit ID и иметь triage disposition `confirmed`, `already-covered`, `rejected` или `deferred`. Нормализованная запись MUST ссылаться на каждый source report, содержащий claim. `confirmed` MUST связываться с remediation status и change либо terminal evidence; `already-covered` MUST приводить проверяемое существующее evidence; `rejected` MUST содержать конкретное rationale; `deferred` MUST содержать review trigger. Triage disposition MUST оставаться отдельным от remediation status `planned`, `active`, `done`, `deferred` или `accepted`, чтобы внешняя рекомендация не становилась принятой policy без проверки.
#### Scenario: Несколько моделей повторяют одно замечание
- **WHEN** два или более source reports описывают один и тот же underlying gap
- **THEN** registry содержит один нормализованный Audit ID со ссылками на все источники и одним доказательным disposition
#### Scenario: Рекомендация уже реализована
- **WHEN** проверяемое состояние проекта полностью покрывает external claim
- **THEN** disposition `already-covered` ссылается на существующий requirement, guardrail или completion evidence без создания фиктивной remediation work
#### Scenario: Внешняя рекомендация противоречит authority
- **WHEN** source report предлагает неподдерживаемый либо ухудшающий действующий invariant подход
- **THEN** disposition `rejected` фиксирует конкретное противоречие и не превращает recommendation в requirement
@@ -0,0 +1,20 @@
## ADDED Requirements
### Requirement: Труднообратимое изменение имеет rollback contract
Design MUST определять rollback trigger, rollback actions, data safety и rollback verification, когда change затрагивает auth или security behavior, data integrity или migration, public contract либо другое существенно труднообратимое решение. Rollback contract MUST учитывать данные и совместимость, созданные после поставки change, и MUST быть выполним без нового неутверждённого архитектурного решения. Когда указанные риски неприменимы, Design SHALL фиксировать конкретную проверяемую причину `N/A` и MUST NOT создавать отдельный artifact или формальный rollback plan ради процесса.
#### Scenario: Change мигрирует данные
- **WHEN** Design изменяет хранимые данные способом, который может потребовать возврата
- **THEN** он определяет trigger, безопасные действия отката, судьбу новых данных и проверку восстановленного состояния до утверждения Tasks
#### Scenario: Change меняет публичный контракт
- **WHEN** Design вводит несовместимое изменение публичного контракта
- **THEN** rollback contract объясняет восстановление совместимости и проверяемое условие успешного отката
#### Scenario: Rollback risk отсутствует
- **WHEN** change не затрагивает auth, security, данные, публичный контракт или другое труднообратимое решение
- **THEN** Design указывает конкретную причину `N/A` без создания дополнительного rollback artifact
@@ -0,0 +1,39 @@
## ADDED Requirements
### Requirement: Каждая задача объявляет единственную delivery area
Каждый checkbox Tasks MUST объявлять ровно одного owner из `frontend`, `backend`, `specs`, `docs` или `workspace`. Implementation work, изменяющая несколько Git-репозиториев, MUST быть разделена на repository-owned tasks; `workspace` SHALL использоваться только для cross-area orchestration или verification без владения repository implementation. Для каждой `affected` area Tasks MUST содержать её implementation work и canonical local gate, а task ownership MUST соответствовать утверждённому Delivery Map.
#### Scenario: Change затрагивает frontend и backend
- **WHEN** одна delivery intent требует изменения клиента и API
- **THEN** Tasks содержит отдельные frontend-owned и backend-owned checkbox items вместо одной общей implementation task
#### Scenario: Выполняется общий verification gate
- **WHEN** задача только оркестрирует проверку нескольких affected areas и не изменяет их implementation
- **THEN** task использует owner `workspace` и не подменяет repository-owned implementation или canonical gates
#### Scenario: Task ссылается на N/A area
- **WHEN** checkbox объявляет owner области, которая имеет статус `N/A` в Delivery Map
- **THEN** planning validation завершается ошибкой и указывает несогласованную delivery area
### Requirement: Tasks трассируются к утверждённым требованиям
Каждый checkbox Tasks MUST содержать coverage reference: одну или несколько пар из точного capability path и точного Requirement heading либо `N/A` с конкретной причиной для работы, которая не реализует spec-level behavior. Каждый Requirement из Delta Specs MUST быть покрыт хотя бы одной task. Planning validation MUST отклонять отсутствующее покрытие, ссылку на несуществующий capability или Requirement и пустую причину `N/A`. Traceability SHALL использовать нативную идентичность requirement и MUST NOT вводить параллельный namespace собственных requirement IDs.
#### Scenario: Delta requirement покрыт реализацией
- **WHEN** Tasks планирует поставку изменённого requirement
- **THEN** хотя бы один checkbox ссылается на точный capability path и Requirement heading этого delta
#### Scenario: Задача не меняет spec-level behavior
- **WHEN** task обновляет infrastructure, documentation или verification без самостоятельного requirement
- **THEN** coverage reference содержит `N/A` и конкретно объясняет отсутствие spec-level связи
#### Scenario: Requirement остался без задачи
- **WHEN** хотя бы один Requirement из Delta Specs не указан ни в одной coverage reference
- **THEN** planning validation блокирует approval Tasks и перечисляет uncovered Requirement
@@ -0,0 +1,79 @@
## MODIFIED Requirements
### Requirement: Изменение upstream artifact требует каскадной проверки
Изменение утверждённого Proposal MUST инициировать повторную проверку Delta Specs, Design и Tasks; изменение утверждённых Delta Specs MUST инициировать повторную проверку Design и Tasks; изменение утверждённого Design MUST инициировать повторную проверку Tasks. Изменение Tasks MUST NOT неявно менять scope, наблюдаемое поведение или архитектурные решения upstream artifacts; при таком обнаружении workflow SHALL вернуть работу к самому раннему затронутому upstream artifact и его approval gate. Если несоответствие обнаружено во время Design или Apply, downstream-работа MUST остановиться, а Change Owner MUST получить наблюдаемое основание возврата и решения, требуемые на выбранном уровне. Механическое исправление синтаксиса или формата, которое не меняет утверждённые намерение, поведение, архитектурные решения или состав задач, MUST пройти повторную structural validation и MUST NOT само по себе инвалидировать approvals.
#### Scenario: После Design изменилось намерение
- **WHEN** владелец меняет scope или ожидаемый эффект Proposal
- **THEN** зависимые Delta Specs, Design и Tasks теряют прежнее подтверждение до повторной согласованной проверки
#### Scenario: Task вводит новое поведение
- **WHEN** implementation checklist требует поведение, которого нет в утверждённых Delta Specs
- **THEN** агент не расширяет scope через Tasks и возвращает change к Delta Specs
#### Scenario: Apply выявляет архитектурное расхождение
- **WHEN** во время реализации обнаружено, что утверждённый Design не позволяет выполнить Specs без другого архитектурного решения
- **THEN** Apply останавливается, Tasks теряет прежнее подтверждение, а change возвращается к Design с наблюдаемым основанием и вариантами решения
#### Scenario: Исправляется только структурный формат
- **WHEN** утверждённый artifact содержит исправимую синтаксическую или formatting-ошибку без изменения его смысла
- **THEN** workflow исправляет ошибку, повторяет structural validation и сохраняет действующие approvals
### Requirement: OpenSpec tooling имеет проверяемый version contract
SDD workflow MUST объявлять одну текущую поддерживаемую версию OpenSpec CLI в canonical version contract и проверять фактическую версию до команд, читающих или изменяющих canonical change. Normative checks и проверяемые generated markers MUST получать ожидаемую версию из этого контракта и MUST NOT независимо закреплять конкретный version literal. Несовместимая либо неопределённая версия MUST давать actionable blocking result и MUST NOT приводить к молчаливому изменению artifact graph, templates или project-owned entrypoints. Публикация новой stable версии MUST NOT автоматически менять поддерживаемую версию проекта. Upgrade SHALL изменять version contract только после изолированной проверки совместимости schema, agent workflow, canonical store и hard blockers и SHALL сохранять историческое evidence с фактически использованными ранее версиями.
#### Scenario: Версия CLI соответствует контракту
- **WHEN** агент начинает работу с canonical change поддерживаемой версией OpenSpec
- **THEN** workflow продолжает работу с объявленной схемой и canonical store
#### Scenario: Версия CLI не соответствует контракту
- **WHEN** доступная версия OpenSpec не совпадает с объявленным совместимым контрактом
- **THEN** локальная preflight-проверка блокирует SDD-операцию и сообщает ожидаемую и фактическую версии
#### Scenario: Опубликована новая stable версия
- **WHEN** upstream публикует новую stable версию, которая ещё не прошла project compatibility assessment
- **THEN** текущий version contract остаётся действующим и новая версия не становится неявным требованием для разработки
#### Scenario: Подготовлен upgrade candidate
- **WHEN** Engineering Owner рассматривает смену поддерживаемой версии
- **THEN** изолированная проверка подтверждает schema, agent workflow, store selection и hard blockers до изменения version contract и project-owned projection
## ADDED Requirements
### Requirement: Project-owned agent workflow воспроизводим из versioned authority
Project-owned agent workflow SHALL восстанавливаться в новом workspace из committed authority inputs и текущей поддерживаемой версии инструмента без использования прежнего локального generated state. Workspace-level projection SHALL оставаться derived output и MUST NOT становиться конкурирующим SDD authority. Non-mutating verifier MUST обнаруживать отсутствие required projection, расхождение с versioned inputs и несовместимый generated version marker; установленные зависимости и machine-local runtime state MUST NOT считаться authority inputs.
#### Scenario: Workspace собирается заново
- **WHEN** участник получает чистые checkout всех project repositories и поддерживаемый инструмент
- **THEN** documented workflow воспроизводит project-owned agent projection из versioned inputs без копирования файлов с прежней машины
#### Scenario: Derived projection изменена вручную
- **WHEN** локальная project-owned projection больше не соответствует versioned authority inputs
- **THEN** non-mutating verifier завершает проверку ошибкой и указывает на projection drift
### Requirement: Planning artifact проверяется до запроса approval
Каждый создаваемый planning artifact SHALL пройти все применимые на его текущем этапе non-mutating structural checks до запроса approval Change Owner. Если полный change validation ещё заблокирован отсутствующими downstream artifacts, workflow MUST выполнить доступные проверки текущего artifact и явно оставить недоступную проверку незавершённой, а не заявлять общий успех. Техническая ошибка проверяемого формата SHALL исправляться и проверяться повторно без передачи ручного исправления Change Owner; structural success MUST NOT подменять semantic approval.
#### Scenario: Текущий artifact имеет проверяемое нарушение
- **WHEN** сгенерированный planning artifact нарушает обязательный формат или ссылочную целостность, доступные для проверки на текущем этапе
- **THEN** workflow исправляет нарушение и повторяет structural checks до запроса owner approval
#### Scenario: Downstream artifacts ещё отсутствуют
- **WHEN** Proposal создан, а Delta Specs, Design и Tasks ещё не существуют
- **THEN** workflow сообщает результат доступных Proposal checks и не представляет отсутствующую full-change validation как успешную
@@ -0,0 +1,65 @@
## 1. Planning guardrails
- [x] 1.1 [specs] Реализовать выбранный в Solution Assessment вариант native OpenSpec + thin project verifiers: извлечь или переиспользовать существующий разбор Delivery Map и добавить stage-aware `verify-openspec-planning.sh` без собственного workflow state
- **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
- **Verification:** Запустить verifier последовательно на fixtures стадий Proposal, Delta Specs, Design и Tasks и подтвердить, что он применяет только доступные на каждой стадии checks.
- [x] 1.2 [specs] Добавить positive и controlled-negative fixtures для proposal structure и capability set, malformed rollback decision, invalid или `N/A` delivery area, отсутствующей task metadata, неверной requirement reference и uncovered Requirement
- **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`; `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`; `engineering-change-governance` — `Труднообратимое изменение имеет rollback contract`
- **Verification:** Запустить fixture suite и проверить успешный compliant case, ожидаемые non-zero exits и actionable сообщения для каждого representative failure.
- [x] 1.3 [specs] Подключить planning verifier к workspace dispatcher до affected-area gates, сохранив явное различие между stage success, full-change validation и semantic approval
- **Covers:** `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
- **Verification:** На incomplete disposable change проверить stage-only результат, а на полном change запустить dispatcher и подтвердить, что planning gate выполняется раньше repository gates.
## 2. Versioned agent projection
- [x] 2.1 [specs] Импортировать project-owned `commands` и `skills` в canonical source tree `specs/agent-projection/opencode`, документировав границы projection и исключив package manifests, dependencies и machine-local state
- **Covers:** `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`
- **Verification:** Сравнить перечень canonical files с текущей project-owned root projection и подтвердить отсутствие package/runtime files в committed source tree.
- [x] 2.2 [specs] Добавить explicit atomic sync для root `.opencode` с восстановлением pre-cutover state при ошибке и отдельный non-mutating exact-content verifier required file set
- **Covers:** `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`
- **Verification:** В disposable workspace проверить успешное восстановление projection из canonical source, обнаружение missing/content drift и отсутствие частично обновлённого output после искусственно сорванного sync.
- [x] 2.3 [specs] Расширить authority fixtures проверками projection drift и generated version markers, получая expected version только из `openspec/.cli-version`
- **Covers:** `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`; `openspec-authority-and-lifecycle` — `OpenSpec tooling имеет проверяемый version contract`
- **Verification:** Запустить authority fixture suite для current contract, mismatched CLI/marker, missing projection и content drift; проверить отсутствие независимого literal `1.10.0` в normative scripts и fixtures.
## 3. Schema v2 and entrypoints
- [x] 3.1 [specs] Повысить `wealth-ledger-sdd` до version 2 и перераспределить guidance по утверждённой owner matrix между schema instructions, templates и additive config без `_rules.md`, добавив stage validation, полный feedback path и компактные примеры сложных delta operations
- **Covers:** `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
- **Verification:** Выполнить `openspec schema validate wealth-ledger-sdd --verbose` из `specs`, получить instructions всех четырёх artifacts и проверить graph, русские explanations, exact English OpenSpec syntax и отсутствие дублирующих config rules.
- [x] 3.2 [specs] Обновить Design template условным Rollback Contract, а Tasks template — checkbox owner `[area]` и обязательными `Covers`/`Verification`, сохранив minimal ADDED-first Spec template
- **Covers:** `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`; `engineering-change-governance` — `Труднообратимое изменение имеет rollback contract`
- **Verification:** Сгенерировать disposable lifecycle по schema v2 и проверить template shape, `required`/`N/A` rollback cases, точные requirement references и отсутствие пустых delta sections.
- [x] 3.3 [specs] Обновить canonical agent commands и skills: запускать version и доступные planning checks до approval, возвращать Apply feedback к раннему затронутому artifact и использовать canonical store; затем атомарно синхронизировать root projection
- **Covers:** `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `OpenSpec tooling имеет проверяемый version contract`; `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`
- **Verification:** Выполнить sync и non-mutating projection check, затем просмотреть instructions/entrypoints для Proposal, Specs, Design, Tasks и Apply и подтвердить fixed store, stage gate и feedback routing.
- [x] 3.4 [specs] Проверить собственный `tasks.md` этого change новым v2 verifier и исправить только технические нарушения формата без изменения утверждённого scope
- **Covers:** `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`
- **Verification:** Запустить planning verifier для `harden-openspec-sdd-quality` и подтвердить owners только affected areas, валидность всех references и покрытие каждого Delta Requirement.
## 4. Audit evidence and durable documentation
- [x] 4.1 [docs] Перенести пять исходных model reports byte-for-byte в один dated snapshot set под `docs/audits`, добавить index с source list, checksums и external non-authority warning, обновить audits index и удалить unversioned `sdd-audit` только после проверки равенства
- **Covers:** `audit-remediation-workflow` — `Реестр remediation отделён от снимка аудита`
- **Verification:** Сверить для всех пяти файлов byte count и checksum source/destination до удаления source, затем проверить index links и ровно один versioned snapshot set.
- [x] 4.2 [docs] Нормализовать все уникальные audit claims в live remediation registry с Audit IDs, всеми source references, доказательными dispositions и отдельными remediation statuses; связать confirmed scope с текущим active change и сохранить auth platform assessment следующим planned item без будущего terminal evidence
- **Covers:** `audit-remediation-workflow` — `Каждое audit claim получает доказательный disposition`; `audit-remediation-workflow` — `Реестр remediation отделён от снимка аудита`
- **Verification:** Сопоставить каждое claim пяти reports ровно одному Audit ID и проверить обязательные evidence/rationale/review trigger для соответствующего disposition и отсутствие дублирующего registry.
- [x] 4.3 [docs] Обновить engineering governance, OpenSpec lifecycle guide, ADR 010 и связанные indexes до фактического v2 ownership, projection recovery, traceability, feedback, rollback и controlled-upgrade contract
- **Covers:** `openspec-authority-and-lifecycle` — `Изменение upstream artifact требует каскадной проверки`; `openspec-authority-and-lifecycle` — `OpenSpec tooling имеет проверяемый version contract`; `openspec-authority-and-lifecycle` — `Project-owned agent workflow воспроизводим из versioned authority`; `openspec-authority-and-lifecycle` — `Planning artifact проверяется до запроса approval`; `multi-repository-delivery` — `Каждая задача объявляет единственную delivery area`; `multi-repository-delivery` — `Tasks трассируются к утверждённым требованиям`; `engineering-change-governance` — `Труднообратимое изменение имеет rollback contract`
- **Verification:** Выполнить scoped review updated docs против поставленных scripts/schema и проверить local links и indexes без копирования planning artifacts в docs.
## 5. Delivery verification
- [x] 5.1 [specs] Выполнить canonical specs gates и controlled-invalid fixture suites после интеграции schema, planning, projection и authority checks
- **Covers:** `N/A` — задача агрегирует verification уже покрытых требований и не вводит самостоятельное spec-level behavior.
- **Verification:** Запустить version preflight, planning/projection/authority fixture suites, schema validation, strict change validation, strict main-spec validation, authority verifier и `git diff --check` в `specs`.
- [x] 5.2 [docs] Выполнить canonical docs gate и scoped проверку audit snapshot, checksums, registry completeness, indexes и local links
- **Covers:** `N/A` — задача проверяет docs delivery уже покрытых audit requirements и не добавляет новое поведение.
- **Verification:** Запустить `npm run verify` в `docs` и отдельно подтвердить affected local links, snapshot checksums и claim-to-Audit-ID coverage.
- [x] 5.3 [workspace] Выполнить cross-area dispatcher для полного change без frontend/backend и runtime-openapi gates
- **Covers:** `N/A` — workspace task оркестрирует canonical gates affected repositories и не заменяет repository-owned implementation.
- **Verification:** Запустить `bash specs/scripts/verify-workspace-change.sh harden-openspec-sdd-quality` и подтвердить Delivery Map `specs/docs=affected`, `frontend/backend=N/A` и `runtime-openapi=N/A`.
- [x] 5.4 [workspace] Провести semantic verification реализации против Proposal, всех 9 Delta Requirements и 28 Scenarios, Design и Tasks, затем independent read-only review без Critical или Important findings
- **Covers:** `N/A` — terminal semantic и independent reviews проверяют change целиком, но не реализуют отдельный Requirement.
- **Verification:** Сохранить наблюдаемое review evidence только после фактических запусков и устранить блокирующие findings до archive eligibility.