244 lines
17 KiB
YAML
244 lines
17 KiB
YAML
name: wealth-ledger-sdd
|
||
version: 5
|
||
description: WealthLedger SDD workflow - proposal → specs → design → tasks → apply
|
||
artifacts:
|
||
- id: proposal
|
||
generates: proposal.md
|
||
description: Owner-approved intent without implementation details
|
||
template: proposal.md
|
||
instruction: |
|
||
Critical Rules:
|
||
- Создай только Proposal: причина, намерение, scope, ожидаемый результат и
|
||
явные non-goals языком Change Owner.
|
||
- Сначала исследуй canonical main specs; для audit-derived change также
|
||
прочитай remediation registry.
|
||
- Capabilities перечисляет каждую новую или изменяемую behavior spec точным
|
||
path. Если spec-level behavior не меняется, не выдумывай Requirement:
|
||
оставь capabilities пустыми и установи `skip_specs: true`.
|
||
- Оставь технологии, зависимости, архитектуру, API, database/code/file
|
||
structure для Design, а implementation steps и verification — для Tasks.
|
||
- После записи используй native OpenSpec instructions и validation с
|
||
`--store wealth-ledger-specs`. Structural success не является approval.
|
||
|
||
Required Shape:
|
||
- **Why**: проблема или возможность и причина заняться ею сейчас.
|
||
- **What Changes**: намерение, ожидаемый результат и non-goals.
|
||
- **Capabilities**:
|
||
- **New Capabilities**: exact `specs/<capability-path>/spec.md`; новые path
|
||
segments используют kebab-case и существующую organization.
|
||
- **Modified Capabilities**: exact existing path под `openspec/specs/`
|
||
только при изменении Requirements.
|
||
- **Impact**: затронутые пользователи, процессы или части системы на уровне
|
||
scope, без implementation topology.
|
||
|
||
Один Proposal формирует contract для downstream artifacts. Покажи его
|
||
Change Owner и остановись до explicit approval.
|
||
requires: []
|
||
|
||
- id: specs
|
||
generates: "specs/**/*.md"
|
||
description: Observable behavior and invariants changed by the proposal
|
||
template: spec.md
|
||
instruction: |
|
||
Critical Rules:
|
||
- Создай behavior contract только для capabilities утверждённого Proposal:
|
||
observable inputs, outputs, errors и security/privacy/reliability/
|
||
compatibility constraints.
|
||
- Не добавляй intent вне Proposal, code/database/file structure, technology
|
||
choices, delivery steps или test procedure. Scenario задаёт WHEN/THEN
|
||
behavior; способ проверки выбирается позже.
|
||
- Создай один `specs/<capability-path>/spec.md` на каждый Proposal path.
|
||
New path следует Proposal; modified path точно совпадает с существующим
|
||
path под `<planningHome.root>/openspec/specs/` и не переименовывается.
|
||
- Используй только применимые `## ADDED Requirements`,
|
||
`## MODIFIED Requirements`, `## REMOVED Requirements` и
|
||
`## RENAMED Requirements`; не оставляй пустые operation sections.
|
||
- Каждый `### Requirement:` содержит SHALL/MUST и хотя бы один
|
||
`#### Scenario:` с `- **WHEN**` и `- **THEN**`.
|
||
- После explicit Proposal approval и записи используй native OpenSpec
|
||
validation с `--store wealth-ledger-specs`.
|
||
|
||
Delta Operations:
|
||
- `ADDED`: новый Requirement.
|
||
- `MODIFIED`: скопируй из main spec полный existing Requirement block со
|
||
всеми Scenarios, затем измени behavior; heading совпадает точно.
|
||
- `REMOVED`: добавь **Reason** и **Migration**.
|
||
- `RENAMED`: только heading rename в формате `FROM:` / `TO:`.
|
||
|
||
New Capability:
|
||
Добавь `## Purpose` из 1–2 предложений (не менее 50 characters). Archive
|
||
переносит его в новую main spec; без него появляется ручной `TBD`. Для
|
||
existing capability `Purpose` в delta не добавляй. Existing Purpose меняй
|
||
прямо в main spec под `planningHome.root` отдельным явно разрешённым
|
||
изменением. `planningHome.root` уже разрешает store-backed или local root;
|
||
не вычисляй path самостоятельно.
|
||
|
||
`skip_specs: true` допустим только при отсутствии Proposal capabilities и
|
||
delta files. Specs должны быть проверяемыми, но Scenario не означает
|
||
обязательный unit test: уровень проверки определяется риском.
|
||
|
||
Покажи Delta Specs Change Owner и остановись до explicit approval. Если
|
||
обнаружилось изменение intent, вернись к Proposal и инвалидируй downstream
|
||
approvals.
|
||
requires:
|
||
- proposal
|
||
|
||
- id: design
|
||
generates: design.md
|
||
description: Architectural implementation approach and delivery decisions
|
||
template: design.md
|
||
instruction: |
|
||
Critical Rules:
|
||
- Создай архитектурный способ выполнить утверждённые Delta Specs крупными
|
||
решениями, rationale, alternatives, risks и migration order.
|
||
- Не добавляй observable behavior вне Specs, не пересказывай upstream
|
||
artifacts и не пиши file-by-file checklist, verification commands,
|
||
будущие results, commits или Completion Evidence.
|
||
- Разреши до сохранения любой вопрос, который меняет Specs, approach или
|
||
Tasks. `Open Questions` оставляет только genuinely deferrable unknowns.
|
||
- После explicit Delta Specs approval и записи используй native OpenSpec
|
||
validation с `--store wealth-ledger-specs`.
|
||
|
||
Required Shape:
|
||
- **Context**: current state и constraints подхода.
|
||
- **Goals / Non-Goals**: технические границы.
|
||
- **Decisions**: ключевые решения, rationale и alternatives.
|
||
- **Delivery Map**: ровно `frontend`, `backend`, `specs`, `docs`; каждая
|
||
area имеет `affected` outcome или конкретный `N/A` reason. `specs` всегда
|
||
`affected`.
|
||
- **Risks / Trade-offs** и **Migration Plan**.
|
||
- В Migration Plan — `### Rollback Contract`: `required` с Trigger,
|
||
Actions, Data safety, Verification для auth/security, data integrity/
|
||
migration, public contract или другого труднообратимого решения; иначе
|
||
`N/A` с конкретным Reason.
|
||
|
||
UI/UX Package:
|
||
- Определи применимость `new/changed`, `reuse` или `N/A` с конкретной
|
||
причиной. Для применимого scope покажи экраны, состояния, interactions
|
||
и responsive поведение; для reuse назови точную immutable версию,
|
||
используемую часть и отличия. Неизменяемой области не нужен новый макет.
|
||
Immutable reuse locator содержит store ID и путь от OpenSpec root,
|
||
чтобы archive вызывающего change не менял разрешение источника.
|
||
- Пакет входит в единый Design approval: revision, inline Markdown и
|
||
перечень необходимых локальных PNG/SVG в `visuals/` этого change с
|
||
относительным path, назначением и SHA-256 каждого файла. SVG должен быть
|
||
самодостаточным, без scripts, handlers, external fonts/assets. Для
|
||
inline Design self-hash не вводится; external-only URL не заменяет пакет.
|
||
- Сохраняй применимые материалы и exact archived reuse доступными без
|
||
временного чата или внешнего аккаунта. General package/approval rules
|
||
задаёт canonical governance, input binding — context authority.
|
||
|
||
Solution Assessment:
|
||
Включи section внутри Design, если change вводит или существенно заменяет
|
||
auth, security, storage, external integration, observability, caching,
|
||
concurrency, shared infrastructure/tooling либо другое дорогостоящее
|
||
необратимое решение. Сравни mature options по fit, maturity, security,
|
||
operating cost, constraints и migration cost. Custom implementation
|
||
допустима только после конкретной несовместимости alternatives. Не создавай
|
||
отдельный assessment artifact.
|
||
|
||
Покажи Design Change Owner и остановись до explicit approval. Если approach
|
||
несовместим с intent или behavior, вернись к самому раннему затронутому
|
||
artifact и инвалидируй downstream approvals.
|
||
requires:
|
||
- specs
|
||
|
||
- id: tasks
|
||
generates: tasks.md
|
||
description: Implementation checklist with trackable tasks
|
||
template: tasks.md
|
||
instruction: |
|
||
Critical Rules:
|
||
- Создай dependency-ordered implementation checklist только после explicit
|
||
Design approval. Формат каждого item:
|
||
`- [ ] X.Y [frontend|backend|specs|docs|workspace] action`.
|
||
- Каждый checkbox имеет ровно одну indented `- **Covers:**` и одну
|
||
`- **Verification:**` line, одного owner и помещается в одну рабочую
|
||
сессию.
|
||
- `Covers` содержит exact
|
||
`` `capability-path` — `Requirement heading` `` pairs либо
|
||
`` `N/A` — reason ``. Каждый Delta Requirement покрыт хотя бы одной task;
|
||
parallel requirement IDs не вводятся.
|
||
- `N/A` reason объясняет отсутствие самостоятельного observable behavior,
|
||
техническую необходимость и связь с утверждённым Design или delivery.
|
||
Не оставляй template placeholder. Смысл проверяется owner review, а не
|
||
text heuristic.
|
||
- Owner repository обязан быть `affected` в Delivery Map. Cross-repository
|
||
implementation разделяй. `workspace` владеет только orchestration или
|
||
verification и всегда использует содержательный `N/A`.
|
||
- Для каждой affected area добавь owned implementation и canonical gate.
|
||
Не создавай empty commit. Planned Verification задаёт command,
|
||
observable check или delivered artifact, но не будущий result.
|
||
- Новое behavior возвращает change в Specs; новое architecture — в Design;
|
||
multi-owner или vague task исправляется в Tasks. Не добавляй commits,
|
||
archive path или post-archive Completion Evidence.
|
||
- После записи используй native OpenSpec validation с
|
||
`--store wealth-ledger-specs`.
|
||
|
||
Design Input:
|
||
- Прочитай применимый UI/UX пакет согласованной revision из Design,
|
||
включая перечисленные материалы; отсутствие или неоднозначность пакета
|
||
блокирует зависимую decomposition до восстановления или Design boundary.
|
||
- Планируй implementation-owned проверки состояний, interactions и
|
||
responsive scope. Независимую Validation не превращай в checkbox,
|
||
который может закрыть только reviewer.
|
||
|
||
Testing:
|
||
Автоматические tests обязательны для security/privacy, денежных расчётов,
|
||
data integrity/migration, concurrency, public contracts, critical journeys
|
||
и подтверждённых regressions. DTO без логики, declarative structure, thin
|
||
adapter, прямолинейная orchestration, hygiene script и third-party behavior
|
||
используют существующий integration/contract gate, если нет собственного
|
||
branching, transformation, invariant или regression. Перед custom work в
|
||
mandatory assessment area включи утверждённый Solution Assessment action.
|
||
|
||
Group tasks под numbered `##` headings. Покажи Tasks Change Owner и
|
||
остановись до explicit approval. Если checklist требует новое behavior или
|
||
architecture, вернись к Specs или Design и инвалидируй Tasks approval.
|
||
requires:
|
||
- design
|
||
- specs
|
||
|
||
apply:
|
||
requires: [ tasks ]
|
||
tracks: tasks.md
|
||
instruction: |
|
||
Critical Rules:
|
||
- Apply допустим только после explicit approvals Proposal, Delta Specs,
|
||
Design и Tasks. Используй canonical store `wealth-ledger-specs` для всех
|
||
OpenSpec commands, читающих или изменяющих change.
|
||
- Прочитай каждый path из `contextFiles`, возвращённых native OpenSpec apply
|
||
instructions, затем applicable repository-local `AGENTS.md` affected areas.
|
||
Не вычисляй planning paths и не создавай второй context map.
|
||
- Выбирай связный ограниченный batch pending implementation-owned Tasks по
|
||
dependencies. Запускай relevant planned Verification и отмечай checkbox
|
||
только после observed success.
|
||
- Если implementation-owned работа остаётся, сохрани checkpoint с completed
|
||
и remaining Tasks, observed checks и одним следующим Implementation outcome.
|
||
Remaining work сама по себе не blocker. READY_FOR_VALIDATION допустим
|
||
только после всех implementation-owned Tasks и успешных relevant checks.
|
||
Независимая Validation и Finalization выполняются в своих ролях по
|
||
canonical lifecycle authority; Apply их не запускает.
|
||
- При recovery соблюдай artifact approval binding и повторно используй
|
||
актуальные результаты checks по canonical context authority; state или
|
||
planning completeness сами по себе approval не подтверждают.
|
||
- Из canonical Design прочитай применимый визуальный пакет: revision,
|
||
перечисленные материалы и exact immutable reuse. Проверь доступность,
|
||
SHA-256 и согласованный input binding до зависимой работы; missing file,
|
||
ambiguous package, digest mismatch или external-only source дают blocker,
|
||
а не разрешение восстановить решение по догадке.
|
||
- Следуй согласованным экранам, состояниям, interactions и responsive scope.
|
||
Несоответствие реализации исправляй в Implementation; изменение самого
|
||
решения возвращай к самой ранней затронутой planning boundary. Передача
|
||
и archive package следуют canonical lifecycle без копии пакета в handoff.
|
||
- Feedback routing: intent/scope → Proposal; observable behavior → Delta
|
||
Specs; architecture/rollback → Design; decomposition/ownership/coverage →
|
||
Tasks. Останови downstream work, сообщи evidence и инвалидируй approvals от
|
||
самого раннего затронутого artifact.
|
||
- Механическая правка ограничена Markdown heading, typo без изменения
|
||
нормативного смысла или table alignment. Requirement wording, Scenario,
|
||
architecture и planned Verification являются semantic changes и требуют
|
||
соответствующего reapproval.
|
||
- Structural validation не заменяет semantic verification и independent
|
||
read-only review.
|