feat: harden OpenSpec SDD workflow
This commit is contained in:
@@ -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.
|
||||
+46
@@ -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
|
||||
+20
@@ -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
|
||||
+39
@@ -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
|
||||
+79
@@ -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.
|
||||
Reference in New Issue
Block a user