Archive verified session-oriented SDD v2 delivery
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: wealth-ledger-sdd
|
||||
created: 2026-08-28
|
||||
+634
@@ -0,0 +1,634 @@
|
||||
# Completion Evidence — optimize-session-oriented-sdd-v2
|
||||
|
||||
Delivery facts observed on 2026-09-07 before native archive. Independent
|
||||
Validation: **PASS**, no unresolved Critical/Important findings. All 20
|
||||
implementation Tasks are complete. The Change Owner explicitly authorized this
|
||||
dependency and its current Tasks in the coordinating conversation ("да, давай"),
|
||||
following the concrete request to include and complete this dependency directly.
|
||||
Optional session routing was not invoked; legacy state was not used as approval.
|
||||
|
||||
## Delivery Map and existing commits
|
||||
|
||||
| Area | Delivered scope | Existing commit |
|
||||
| --- | --- | --- |
|
||||
| frontend | Canonical routing and the necessary ignored-file formatting fix; earlier approved Storybook delivery is also present | `36698322b7273b3a9eae1d078bcc9cddf2c8295b` |
|
||||
| backend | Canonical routing; runtime/API unchanged | `de1dab0d476d10a28b101d9cf6f25e5ace1368d2` |
|
||||
| specs | Schema v4, native Tasks dependencies and bounded Apply; completed checklist | `04a07b390f73412a5d376c0051253da25481f1a3` |
|
||||
| docs | Portable lifecycle/context authority, registry/index routing and previously verified Storybook as-built docs | `024e240303ec977ece40ab0e75a234267834ea7c` |
|
||||
|
||||
Workspace-owned root routing and optional adapters are local unversioned
|
||||
instructions, bound by the inventory below; workspace root is not a Git repository.
|
||||
No fictional workspace commit is claimed. Runtime-openapi: N/A because no API
|
||||
contract changed. Historical archives, audits and legacy completion evidence
|
||||
were preserved. No product pilot was performed.
|
||||
|
||||
## Verification and independent review
|
||||
|
||||
All Node commands used Node 22 selected through repository `.nvmrc`; specs used
|
||||
frontend runtime. Frontend lockfile install was already successful on the same
|
||||
lockfile; backend `npm ci` succeeded. Canonical frontend/backend/docs gates and
|
||||
native schema/current/main-spec checks have successful observed results below.
|
||||
The first backend build failed on sandbox Prisma cache `utime`; the sanctioned
|
||||
rerun completed. Frontend commit hooks exposed an ignored-AGENTS formatting bug;
|
||||
the scoped native formatter option fixed it without bypassing hooks, followed
|
||||
by a new frontend gate and superseding independent PASS. Commit/staging left
|
||||
reviewed bytes and the final fingerprint unchanged.
|
||||
|
||||
# Independent Validation — optimize-session-oriented-sdd-v2
|
||||
|
||||
Verdict: **PASS** on the frozen inputs below. No unresolved Critical or Important findings.
|
||||
|
||||
This is an independent read-only review performed by the delegated reviewer after explicit Change Owner authorization of the dependency and its Tasks, as reported in the current coordinating conversation. The optional session router was not invoked. Legacy session state was not treated as approval evidence. The reviewer did not modify production code, repository policy, canonical specifications, Tasks, historical records, or other changes. This temporary report is evidence for the canonical Completion Evidence, not a new versioned planning or verdict store.
|
||||
|
||||
## Reviewed input binding
|
||||
|
||||
- Change: `optimize-session-oriented-sdd-v2`.
|
||||
- Inventory: `/tmp/sdd-v2-ready-review-final.json`; independently re-expanded final snapshot: `/tmp/sdd-v2-independent-after-final.json`.
|
||||
- Raw planning/delivery fingerprint: `sha256:42e412e4ee45f765bad83639561db8fb5cf8aadeef3283b6543a5ca7152d724d`.
|
||||
- Files: **420**. The reviewer independently reconstructed the byte stream and SHA-256 using the delivered context contract, verified exact inventory membership, and matched the coordinating snapshot. A final re-expansion and fingerprint after review matched again.
|
||||
- Scope: full tracked/nonignored frontend, backend and docs repository candidates; the predecessor canonical change; all canonical main specs; project-local `wealth-ledger-sdd` schema; specs configuration, CLI version and AGENTS; root AGENTS; all 16 OpenCode entrypoints and the six SDD phase skills/shared protocol. Workspace-owned ignored instructions are explicitly enumerated through their roots.
|
||||
- Exclusions: this change's own future `completion-evidence.md` and irrelevant `.DS_Store`; other active change planning and historical archives are outside this change's process review scope. Existing Storybook delivery is inside the full frontend/docs gate inventory and had its own earlier scoped review. It is not represented as new predecessor product behavior.
|
||||
- Canonical Tasks: **20 checked, 0 unchecked** after observed implementation outcomes. Task contents remained approved; checkbox progress is raw in this PASS fingerprint and separately normalized only for approval binding.
|
||||
- Runtime: Node 22 selected using repository `.nvmrc` through `nvm use --silent`; specs uses frontend runtime. Runtime/gate metadata must remain attached to this fingerprint when consumed.
|
||||
|
||||
## Authority and implementation review
|
||||
|
||||
Read the full approved Proposal, both Delta Specs, Design and Tasks, applicable main baselines, root/all four repository AGENTS, delivered governance/lifecycle/context documentation, registry/index changes, project-local schema, all 16 `.opencode` entrypoints, and all SDD phase skills/shared protocol.
|
||||
|
||||
The two deltas contain **11 Requirements / 39 Scenarios**. Semantic and acceptance review covered each:
|
||||
|
||||
| Requirement | Implementation and scenario evidence |
|
||||
| --- | --- |
|
||||
| Implementation сохраняет ограниченные checkpoints | Schema Apply and Implementation adapter distinguish a verified partial batch as CHECKPOINT from completion of all implementation-owned tasks as READY_FOR_VALIDATION. Actual obstacles remain BLOCKED; independent Validation is not executed by Apply. |
|
||||
| Активные инструкции согласованы и независимы от agent runtime | Root/repository instructions and 16 optional command/skill entrypoints point to the same vendor-neutral governance/lifecycle/context authorities. Local gates/boundaries remain available without an optional runtime. Clean-shell native routing succeeded for all five native planning/apply instructions. |
|
||||
| Каждая agent-сессия имеет одну SDD-роль | Governance approval table, shared protocol and Specification adapter preserve Discovery, individual artifact decisions, bounded Proposal+Specs and Design+Tasks pairs, same-role continuation after permitted approval, and independent context at pair/role boundaries. Tasks approval does not run Implementation inside Specification; completed Implementation does not run Validation. |
|
||||
| Продолжение workflow восстанавливает только нужный контекст | Context authority and protocol define one current self-contained envelope, phase-specific canonical context, old records only for concrete investigation, bounded independent reads and reuse only for unchanged relevant gate inputs. Native Tasks resolves Design plus both Delta Specs; Apply resolves all five canonical files. |
|
||||
| Handoff не заменяет canonical OpenSpec authority | Envelope contains navigation/results/task IDs, never copied requirements or design. Four approval slots require explicit decision source, artifact identity and content fingerprint; missing legacy binding requires owner decision; mismatch invalidates the affected boundary and downstream slots. Approved Tasks progress normalization does not conceal semantic edits or raw PASS changes. |
|
||||
| Validation остаётся независимой и без побочных исправлений | Governance, lifecycle and Validation adapter require gates, semantic/acceptance behavior, edge cases and independent review; prohibit production/planning/Tasks edits; preserve PASS/FAIL/SPEC_ISSUE routing. Validation-owned work is not an implementation checkbox. |
|
||||
| Finalization требует успешной независимой Validation | Finalization consumes current input-bound PASS, re-expands inventory and handles unchecked implementation work, stale/missing PASS, planning gaps and retryable completion failures at their responsible roles. It does not repair implementation/planning or rerun unchanged Validation. |
|
||||
| Completion Evidence сохраняет фактическое завершение change | Governance/lifecycle and Finalization adapter create evidence inside the active canonical change only from existing Delivery Map, commits, exact observed gates and independent result, then archive it together. Missing facts block completion; docs N/A does not require an evidence-only docs mutation. |
|
||||
| OpenSpec change закрывается только после полной верификации | Completion requires all implementation-owned tasks, required artifacts, affected gates, semantic/acceptance verification, no blocking findings, as-built documentation and current independent PASS. No confirmation override is permitted. |
|
||||
| Документация процесса содержит remediation registry | Updated registry/index preserve sources/status/next task and use a canonical archive/evidence link for future done entries. Historical dated records and prior evidence links remain unchanged. |
|
||||
| Durable documentation is not a parallel SDD store | Docs AGENTS/governance/lifecycle/index distinguish as-built documentation from canonical planning/evidence, retain documentation only for actual affected subjects and avoid a parallel evidence store. Existing historical docs evidence is preserved under the explicit no-rewrite constraint. |
|
||||
|
||||
## Verification evidence
|
||||
|
||||
Existing successful affected gates were assessed with the supplied command results/logs and the frozen delivery inventory; full application gates were not needlessly repeated by this reviewer.
|
||||
|
||||
- Frontend: `npm run verify`, supplied successful exit; `/tmp/sdd-v2-frontend-verify-final.log` directly inspected: 24 test files / 110 tests pass, production build and Storybook static build succeed. Existing large Storybook bundle warning is nonblocking and introduces no predecessor runtime behavior.
|
||||
- Backend: `npm ci`, then `npm run verify`, supplied successful exits; `/tmp/sdd-v2-backend-verify-final.log` directly inspected: 25 suites / 106 tests, type/lint checks, Prisma generation and Nest build pass. Earlier sandbox EPERM was resolved by the sanctioned rerun, not treated as a successful result.
|
||||
- Specs: coordinating evidence reports successful `openspec schema validate wealth-ledger-sdd --verbose` and strict current-change validation after marking Tasks. Reviewer independently observed schema resolution as project-local and all native context instructions under Node 22. `openspec validate --specs --strict --store wealth-ledger-specs` was rerun after the input-scope correction; `/tmp/sdd-v2-main-specs-gate.log` directly inspected: 23 passed, 0 failed.
|
||||
- Docs: writer/coordinator supplied successful canonical `npm run verify` for 43 Markdown files and scoped verification of 125 local links. Scoped diff review found no rewritten historical completion-evidence entries or dated audit snapshots.
|
||||
- Native read-only clean-shell check: with `/bin/zsh`, `login: false`, frontend `.nvmrc` activated, invoked `openspec instructions <stage> --change optimize-session-oriented-sdd-v2 --json --store wealth-ledger-specs` for proposal/specs/design/tasks/apply. Every stage resolves `wealth-ledger-sdd`; dependencies are proposal→specs→design and tasks→design+specs; Apply observes all_done after 20/20 Tasks. This does not mistake native completeness for independent PASS or archive completion.
|
||||
- Adapter mechanics: directly inspected `/tmp/sdd-v2-adapter-probe.py` and the 15 observed positive/negative checks in `/tmp/sdd-v2-adapter-proof-1vg2e8yo/proof.txt` (coordinator also reran to `/tmp/sdd-v2-adapter-proof-tyvq9ut4/proof.txt`). Assertions cover matching approval, checkbox-only normalization versus raw PASS, semantic edit invalidation, added/deleted membership, executable mode, symlink identity, exclusive lock refusal, concurrent-state detection/preservation, exclusive immutable record creation, interrupted write and atomic pointer replacement.
|
||||
- The disposable fingerprint helper and this review report are not new versioned runtime tooling. Current real inventory uses valid workspace-relative paths and regular files/symlinks covered by the documented algorithm.
|
||||
|
||||
## Superseding review after the completion blocker
|
||||
|
||||
This PASS supersedes `/tmp/sdd-v2-independent-review.md`. The earlier raw PASS was correctly invalidated when completion exposed an actual frontend AGENTS-only commit failure and Implementation changed `frontend/package.json`. The only change adds `--no-errors-on-unmatched` to the existing `lint-staged` Biome formatting command. It permits a batch containing only intentionally ignored files without suppressing parser errors, weakening lint rules, bypassing the hook, or changing application runtime/dependencies.
|
||||
|
||||
Independent scoped review found no Critical/Important issue. The executor observed the ignored-AGENTS positive command exit 0; `/tmp/sdd-v2-format-negative.log` was inspected and shows malformed TypeScript still rejected with formatting aborted due to parsing errors. The affected frontend canonical `npm run verify` was rerun successfully (coordinator observed exit 0); the final log was directly inspected: 24 files / 110 tests pass and both production/Storybook builds succeed. Other gates and semantic review are reused for verified unchanged inputs.
|
||||
|
||||
The reviewer reconstructed the current 420-file fingerprint independently. Reversing only this formatter flag **in memory**, without any repository write, reconstructed the exact previous fingerprint `sha256:9f89383792f5373e626b0608bb3d4a7d7a3244f36e40a6b19a249dc0e4c676de`. This proves the rest of the formerly reviewed content/modes/membership remained unchanged. A final inventory re-expansion matches `sha256:42e412e4ee45f765bad83639561db8fb5cf8aadeef3283b6543a5ca7152d724d`.
|
||||
|
||||
## Resolved finding and completion limits
|
||||
|
||||
One evidence-binding gap was found before PASS: the initial inventory covered only two main capabilities while the reused native main-specs gate covered all 23. The executor expanded the scope to all main specs plus the CLI version and reran the affected main-specs strict gate. The reviewer independently verified the corrected 420-file membership and final fingerprint. No unresolved finding remains.
|
||||
|
||||
The expected future semantic sync is 2 ADDED and 5 MODIFIED session Requirements and 4 MODIFIED documentation Requirements. Existing identities match the approved deltas; untouched Requirements and Purpose must be preserved. Finalization still has to review the exact resulting semantic diff, create evidence from existing delivery commits, execute archive, and verify its outputs. This PASS does not claim archive, completion evidence creation, terminal status, or completion of `integrate-ui-ux-design-workflow`.
|
||||
|
||||
Any new relevant planning/delivery content or inventory change invalidates this PASS. Staging/committing unchanged bytes does not. Expected archive/sync/evidence outputs follow the separately reviewed completion procedure and cannot hide implementation changes.
|
||||
|
||||
## Controlled adapter evidence
|
||||
|
||||
```text
|
||||
PASS unchanged content yields matching approval binding
|
||||
PASS canonical checklist-only progress retains Tasks approval
|
||||
PASS canonical checklist-only progress changes PASS raw binding
|
||||
PASS semantic task edit invalidates approval binding
|
||||
PASS re-expanded directory detects added input
|
||||
PASS prior missing entry plus re-expanded inventory detects deletion
|
||||
PASS executable mode mutation changes binding
|
||||
PASS symlink target identity mutation changes binding
|
||||
PASS exclusive lock refuses second writer
|
||||
PASS state byte comparison detects concurrent replacement
|
||||
PASS conflict path preserves other writer state
|
||||
PASS exclusive record creation preserves immutable record
|
||||
PASS interruption after record leaves old pointer intact
|
||||
PASS state still matches writer snapshot under lock
|
||||
PASS atomic pointer replacement occurs after existing record
|
||||
```
|
||||
|
||||
# SDD v2 adapter controlled walkthrough
|
||||
|
||||
Scope: predecessor Tasks 4.1–4.5, optional adapter instructions only. These are
|
||||
manual role walkthroughs against the edited instruction text, supplemented by
|
||||
actual temporary filesystem/fingerprint experiments in
|
||||
`/tmp/sdd-v2-adapter-proof-1vg2e8yo/proof.txt`. No production role was invoked,
|
||||
no actual change state/record was mutated, and this is not a product pilot or
|
||||
independent whole-change Validation.
|
||||
|
||||
| Task | Controlled input | Observed instruction result |
|
||||
| --- | --- | --- |
|
||||
| 4.1 | Approved Proposal with matching canonical identity, fingerprint and explicit decision source | Recovery step 2 carries the binding without repeating approval; router loads only Specification for Delta Specs. |
|
||||
| 4.1 | Approved label with missing fingerprint or source | Recovery step 3 requires the earliest missing owner decision; downstream file existence grants no approval. |
|
||||
| 4.1 | Legacy version 1 state pointing to Implementation | Recovery step 5 uses phase only as a hint and recovers prerequisite bindings from explicit available decisions; missing decisions require owner recovery, never automatic promotion. |
|
||||
| 4.1 | Proposal payload changes | Recovery step 3 invalidates Proposal and all downstream approvals and selects Specification/proposal. |
|
||||
| 4.1 | Delta Specs member added or removed | Fresh full membership fingerprint changes; recovery invalidates Specs, Design and Tasks and selects Specification/specs. Temporary addition/deletion experiments detected both mutations. |
|
||||
| 4.1 | Canonical Tasks checkbox alone changes | Approval fingerprint remains equal while raw PASS fingerprint changes; temporary experiment demonstrated both. |
|
||||
| 4.1 | Current record missing or envelope fields conflict | Recovery step 5 blocks routing until the selected change is reconciled; no history-wide migration. |
|
||||
| 4.1 | Concurrent state writer or existing immutable record | Lock/byte compare/exclusive creation prevents overwrite. Temporary experiments detected concurrent replacement, refused second lock/record creation, preserved old pointer after interrupted write, then completed record-before-pointer update. |
|
||||
| 4.2 | Structurally valid Proposal awaiting owner decision | Specification step 2 records AWAITING_APPROVAL; Delta Specs remains unavailable. |
|
||||
| 4.2 | Owner explicitly approves unchanged Proposal | Step 3 records ARTIFACT_APPROVED and permits Delta Specs in the same Specification task after native context reads. |
|
||||
| 4.2 | Owner explicitly approves Delta Specs | Step 4 ends first pair and selects Design in a new Specification task. |
|
||||
| 4.2 | Owner explicitly approves unchanged Design | Step 3 permits Tasks within the same Specification task. |
|
||||
| 4.2 | Tasks drafted but not approved | Step 2 keeps AWAITING_APPROVAL; Implementation unavailable. |
|
||||
| 4.2 | Owner explicitly approves Tasks | Step 4 selects Implementation in a new task and ends Specification. |
|
||||
| 4.3 | Coherent checked batch complete with pending implementation-owned Tasks | Step 4 chooses CHECKPOINT and next Implementation outcome; remaining work alone is not BLOCKED. |
|
||||
| 4.3 | All implementation-owned Tasks complete and relevant checks successful | Step 4 chooses READY_FOR_VALIDATION; role stops before independent verification. |
|
||||
| 4.3 | Actual obstacle prevents next batch | Step 4 chooses BLOCKED, retains Implementation and names obstacle. |
|
||||
| 4.3 | Architecture inconsistency discovered | Step 4 chooses SPEC_ISSUE at Design, invalidating dependent Tasks approval. |
|
||||
| 4.4 | Independent affected gates, acceptance/semantic evidence and review satisfy current approved inputs | PASS is bound to reviewed inventory and exact evidence; next role Finalization. |
|
||||
| 4.4 | Observed implementation violation | FAIL includes requirement, evidence and expected result; next role Implementation; read-only rule prohibits repairing code, tests or Tasks. |
|
||||
| 4.4 | Observed planning contradiction | SPEC_ISSUE selects earliest responsible Specification boundary; planning and Tasks remain read-only. |
|
||||
| 4.4 | Input changes while verification runs | Step 4 re-expands inventory and repeats affected verification before verdict; old evidence cannot bind new content. |
|
||||
| 4.5 | Current independent PASS with unchanged inputs and existing completion facts | Steps 1–4 consume PASS without rerunning Validation, create active canonical completion-evidence.md, then archive together via native lifecycle. |
|
||||
| 4.5 | Missing or stale PASS | Step 2 routes FINALIZATION_BLOCKED to Validation; no archive. |
|
||||
| 4.5 | Unchecked implementation-owned Task or implementation finding | Step 2 routes blocker to Implementation; no self-repair or archive. |
|
||||
| 4.5 | Planning gap/conflict | Step 2 routes blocker to earliest Specification boundary; no rewrite under Finalization. |
|
||||
| 4.5 | Missing delivery commit/gate/review fact | Step 3 blocks completion and disallows placeholders; terminal status unavailable. |
|
||||
| 4.5 | Retryable archive/evidence/environment failure with unchanged valid inputs | Step 2 retains Finalization; current record carries PASS source/input binding for retry without reconstructing history. |
|
||||
|
||||
Edited sources: `.agents/skills/sdd-session/SKILL.md`,
|
||||
`.agents/skills/sdd-session/references/workflow-protocol.md`, and
|
||||
`sdd-specification`, `sdd-implementation`, `sdd-validation`, `sdd-finalization`
|
||||
`SKILL.md` files. General policy and exact fingerprint algorithm remain owned by
|
||||
vendor-neutral engineering/context documents; adapters link to them.
|
||||
|
||||
Additional observed check: all six edited files passed frontmatter/newline/
|
||||
whitespace checks; all eight local links and the fingerprint anchor resolve.
|
||||
|
||||
## Reviewed input inventory
|
||||
|
||||
This embeds the reviewed inventory so temporary log/manifest locations above
|
||||
are supporting evidence, not a prerequisite for recovering the verdict.
|
||||
Fingerprint procedure is the delivered context authority. Completion Evidence
|
||||
excludes itself; native archive/sync outputs are checked separately against the
|
||||
approved deltas. No future archive commit is claimed here.
|
||||
|
||||
```json
|
||||
{
|
||||
"roots": [
|
||||
"frontend",
|
||||
"backend",
|
||||
"docs",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2",
|
||||
"specs/openspec/specs"
|
||||
],
|
||||
"paths": [
|
||||
"AGENTS.md",
|
||||
"specs/AGENTS.md",
|
||||
"specs/openspec/config.yaml",
|
||||
"specs/openspec/.cli-version"
|
||||
],
|
||||
"workspace_roots": [
|
||||
".opencode/commands",
|
||||
".opencode/skills",
|
||||
".agents/skills/sdd-session",
|
||||
".agents/skills/sdd-discovery",
|
||||
".agents/skills/sdd-specification",
|
||||
".agents/skills/sdd-implementation",
|
||||
".agents/skills/sdd-validation",
|
||||
".agents/skills/sdd-finalization"
|
||||
],
|
||||
"exclude": [
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/completion-evidence.md",
|
||||
".agents/skills/sdd-session/.DS_Store"
|
||||
],
|
||||
"purpose": "Independent validation of optimize-session-oriented-sdd-v2; full affected repository gate inputs plus reviewed process delivery and canonical planning/baseline. Other active changes and immutable archives excluded from process scope.",
|
||||
"files": [
|
||||
".agents/skills/sdd-discovery/SKILL.md",
|
||||
".agents/skills/sdd-finalization/SKILL.md",
|
||||
".agents/skills/sdd-implementation/SKILL.md",
|
||||
".agents/skills/sdd-session/SKILL.md",
|
||||
".agents/skills/sdd-session/references/workflow-protocol.md",
|
||||
".agents/skills/sdd-specification/SKILL.md",
|
||||
".agents/skills/sdd-validation/SKILL.md",
|
||||
".opencode/commands/opsx-apply.md",
|
||||
".opencode/commands/opsx-archive.md",
|
||||
".opencode/commands/opsx-continue.md",
|
||||
".opencode/commands/opsx-explore.md",
|
||||
".opencode/commands/opsx-new.md",
|
||||
".opencode/commands/opsx-propose.md",
|
||||
".opencode/commands/opsx-sync.md",
|
||||
".opencode/commands/opsx-verify.md",
|
||||
".opencode/skills/openspec-apply-change/SKILL.md",
|
||||
".opencode/skills/openspec-archive-change/SKILL.md",
|
||||
".opencode/skills/openspec-continue-change/SKILL.md",
|
||||
".opencode/skills/openspec-explore/SKILL.md",
|
||||
".opencode/skills/openspec-new-change/SKILL.md",
|
||||
".opencode/skills/openspec-propose/SKILL.md",
|
||||
".opencode/skills/openspec-sync-specs/SKILL.md",
|
||||
".opencode/skills/openspec-verify-change/SKILL.md",
|
||||
"AGENTS.md",
|
||||
"backend/.env.example",
|
||||
"backend/.gitignore",
|
||||
"backend/.nvmrc",
|
||||
"backend/.prettierrc",
|
||||
"backend/AGENTS.md",
|
||||
"backend/README.md",
|
||||
"backend/certs/russian-trusted-root-ca.pem",
|
||||
"backend/eslint.config.mjs",
|
||||
"backend/nest-cli.json",
|
||||
"backend/package-lock.json",
|
||||
"backend/package.json",
|
||||
"backend/prisma.config.ts",
|
||||
"backend/prisma/migrations/20260813063823_add_authentication/migration.sql",
|
||||
"backend/prisma/migrations/20260813145440_add_tbank_connection/migration.sql",
|
||||
"backend/prisma/migrations/migration_lock.toml",
|
||||
"backend/prisma/schema.prisma",
|
||||
"backend/src/app.module.ts",
|
||||
"backend/src/auth/auth.controller.spec.ts",
|
||||
"backend/src/auth/auth.controller.ts",
|
||||
"backend/src/auth/auth.dto.ts",
|
||||
"backend/src/auth/auth.module.ts",
|
||||
"backend/src/auth/auth.service.spec.ts",
|
||||
"backend/src/auth/auth.service.ts",
|
||||
"backend/src/auth/auth.types.ts",
|
||||
"backend/src/auth/jwt-auth.guard.ts",
|
||||
"backend/src/auth/jwt.strategy.ts",
|
||||
"backend/src/common/decorators/api-safe-error-response.decorator.ts",
|
||||
"backend/src/common/filters/http-exception.filter.spec.ts",
|
||||
"backend/src/common/filters/http-exception.filter.ts",
|
||||
"backend/src/common/logging/logging.module.ts",
|
||||
"backend/src/common/logging/request-context.service.ts",
|
||||
"backend/src/common/logging/request-logging.middleware.spec.ts",
|
||||
"backend/src/common/logging/request-logging.middleware.ts",
|
||||
"backend/src/common/logging/structured-logger.service.spec.ts",
|
||||
"backend/src/common/logging/structured-logger.service.ts",
|
||||
"backend/src/config/env.validation.spec.ts",
|
||||
"backend/src/config/env.validation.ts",
|
||||
"backend/src/config/swagger.config.ts",
|
||||
"backend/src/main.spec.ts",
|
||||
"backend/src/main.ts",
|
||||
"backend/src/prisma/prisma.module.ts",
|
||||
"backend/src/prisma/prisma.service.ts",
|
||||
"backend/src/tbank/brokerage-account.dto.ts",
|
||||
"backend/src/tbank/brokerage-accounts.controller.ts",
|
||||
"backend/src/tbank/brokerage-accounts.service.spec.ts",
|
||||
"backend/src/tbank/brokerage-accounts.service.ts",
|
||||
"backend/src/tbank/brokerage-operation.dto.ts",
|
||||
"backend/src/tbank/brokerage-operation.mapper.spec.ts",
|
||||
"backend/src/tbank/brokerage-operation.mapper.ts",
|
||||
"backend/src/tbank/brokerage-operations.controller.spec.ts",
|
||||
"backend/src/tbank/brokerage-operations.controller.ts",
|
||||
"backend/src/tbank/brokerage-operations.service.spec.ts",
|
||||
"backend/src/tbank/brokerage-operations.service.ts",
|
||||
"backend/src/tbank/decimal.spec.ts",
|
||||
"backend/src/tbank/decimal.ts",
|
||||
"backend/src/tbank/income-analytics.controller.ts",
|
||||
"backend/src/tbank/income-analytics.dto.ts",
|
||||
"backend/src/tbank/income-analytics.service.spec.ts",
|
||||
"backend/src/tbank/income-analytics.service.ts",
|
||||
"backend/src/tbank/income-period.spec.ts",
|
||||
"backend/src/tbank/income-period.ts",
|
||||
"backend/src/tbank/instrument-metadata.service.spec.ts",
|
||||
"backend/src/tbank/instrument-metadata.service.ts",
|
||||
"backend/src/tbank/moex.client.spec.ts",
|
||||
"backend/src/tbank/moex.client.ts",
|
||||
"backend/src/tbank/portfolio-totals.ts",
|
||||
"backend/src/tbank/portfolio.controller.ts",
|
||||
"backend/src/tbank/portfolio.dto.ts",
|
||||
"backend/src/tbank/portfolio.service.spec.ts",
|
||||
"backend/src/tbank/portfolio.service.ts",
|
||||
"backend/src/tbank/proto/contracts/common.proto",
|
||||
"backend/src/tbank/proto/contracts/google/api/field_behavior.proto",
|
||||
"backend/src/tbank/proto/contracts/instruments.proto",
|
||||
"backend/src/tbank/proto/contracts/operations.proto",
|
||||
"backend/src/tbank/proto/contracts/users.proto",
|
||||
"backend/src/tbank/tbank-access.service.spec.ts",
|
||||
"backend/src/tbank/tbank-access.service.ts",
|
||||
"backend/src/tbank/tbank-account-policy.spec.ts",
|
||||
"backend/src/tbank/tbank-account-policy.ts",
|
||||
"backend/src/tbank/tbank-connection.controller.ts",
|
||||
"backend/src/tbank/tbank-connection.dto.ts",
|
||||
"backend/src/tbank/tbank-connection.module.ts",
|
||||
"backend/src/tbank/tbank-connection.service.spec.ts",
|
||||
"backend/src/tbank/tbank-connection.service.ts",
|
||||
"backend/src/tbank/tbank-token.service.spec.ts",
|
||||
"backend/src/tbank/tbank-token.service.ts",
|
||||
"backend/src/tbank/tbank.client.spec.ts",
|
||||
"backend/src/tbank/tbank.client.ts",
|
||||
"backend/src/tbank/tbank.crypto.spec.ts",
|
||||
"backend/src/tbank/tbank.crypto.ts",
|
||||
"backend/src/tbank/upcoming-events.controller.spec.ts",
|
||||
"backend/src/tbank/upcoming-events.controller.ts",
|
||||
"backend/src/tbank/upcoming-events.dto.ts",
|
||||
"backend/src/tbank/upcoming-events.service.spec.ts",
|
||||
"backend/src/tbank/upcoming-events.service.ts",
|
||||
"backend/test/app.e2e-spec.ts",
|
||||
"backend/test/e2e-env.cjs",
|
||||
"backend/test/jest-e2e.json",
|
||||
"backend/test/openapi-contract.e2e-spec.ts",
|
||||
"backend/test/runtime-check.cjs",
|
||||
"backend/tsconfig.build.json",
|
||||
"backend/tsconfig.json",
|
||||
"backend/tsconfig.typecheck.app.json",
|
||||
"backend/tsconfig.typecheck.test.json",
|
||||
"docs/.gitignore",
|
||||
"docs/.markdownlint-cli2.jsonc",
|
||||
"docs/.nvmrc",
|
||||
"docs/AGENTS.md",
|
||||
"docs/adr/001-prisma-sqlite-local-mvp.md",
|
||||
"docs/adr/002-nest-generated-openapi-contract.md",
|
||||
"docs/adr/003-tbank-server-side-grpc-boundary.md",
|
||||
"docs/adr/004-encrypted-per-user-tbank-token.md",
|
||||
"docs/adr/005-tbank-upstream-resilience.md",
|
||||
"docs/adr/006-auth-session-policy.md",
|
||||
"docs/adr/007-react-query-fetch-policy.md",
|
||||
"docs/adr/008-pino-backend-logging.md",
|
||||
"docs/adr/009-concurrent-refresh-rotation-policy.md",
|
||||
"docs/adr/010-native-openspec-sdd-and-local-orchestration.md",
|
||||
"docs/adr/README.md",
|
||||
"docs/architecture/README.md",
|
||||
"docs/architecture/domain-glossary.md",
|
||||
"docs/architecture/system-overview.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/README.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/deepseek-audit.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/gemini-audit.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/grok-audit.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/kimi-audit.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/qwen-audit.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd-v2-review/zai-audit.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd/README.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd/deepseek-result.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd/gemini-result.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd/kimi-result.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd/qwen-result.md",
|
||||
"docs/audits/2026-08-26-wealth-ledger-sdd/zai-result.md",
|
||||
"docs/audits/2026-08-frontend-repository-audits/README.md",
|
||||
"docs/audits/2026-08-frontend-repository-audits/frontend-repository-audit-2026-08-28.md",
|
||||
"docs/audits/2026-08-frontend-repository-audits/frontend-repository-audit.md",
|
||||
"docs/audits/2026-08-frontend-repository-audits/frontend-structural-maintainability-audit.md",
|
||||
"docs/audits/README.md",
|
||||
"docs/audits/audit-13-08-2026.md",
|
||||
"docs/audits/audit-20-08-2026.md",
|
||||
"docs/audits/audit-24-08-2026.md",
|
||||
"docs/audits/codex-sessions-token-audit-2026-08-26.md",
|
||||
"docs/development/README.md",
|
||||
"docs/development/agent-token-efficiency.md",
|
||||
"docs/development/audit-remediation.md",
|
||||
"docs/development/backend-workflow.md",
|
||||
"docs/development/completion-evidence.md",
|
||||
"docs/development/engineering-governance.md",
|
||||
"docs/development/frontend-workflow.md",
|
||||
"docs/development/openspec-authority-and-lifecycle.md",
|
||||
"docs/development/runtime-openapi-verification.md",
|
||||
"docs/development/ui-catalog.md",
|
||||
"docs/features/README.md",
|
||||
"docs/features/authentication.md",
|
||||
"docs/features/brokerage-account-income-analytics.md",
|
||||
"docs/features/brokerage-account-ledger.md",
|
||||
"docs/features/brokerage-account-upcoming-events.md",
|
||||
"docs/features/brokerage-accounts.md",
|
||||
"docs/features/frontend-ui-resilience.md",
|
||||
"docs/features/portfolio-view.md",
|
||||
"docs/features/tbank-connection.md",
|
||||
"docs/package-lock.json",
|
||||
"docs/package.json",
|
||||
"frontend/.env.example",
|
||||
"frontend/.gitignore",
|
||||
"frontend/.husky/commit-msg",
|
||||
"frontend/.husky/pre-commit",
|
||||
"frontend/.nvmrc",
|
||||
"frontend/.storybook/dependency-cruiser.cjs",
|
||||
"frontend/.storybook/main.ts",
|
||||
"frontend/.storybook/preview.tsx",
|
||||
"frontend/AGENTS.md",
|
||||
"frontend/README.md",
|
||||
"frontend/biome.json",
|
||||
"frontend/commitlint.config.cjs",
|
||||
"frontend/dependency-cruiser.cjs",
|
||||
"frontend/docs/API-LAYER.md",
|
||||
"frontend/docs/CONVENTIONS.md",
|
||||
"frontend/docs/README.md",
|
||||
"frontend/docs/STRUCTURE.md",
|
||||
"frontend/docs/TESTING.md",
|
||||
"frontend/docs/UI-PATTERN.md",
|
||||
"frontend/index.html",
|
||||
"frontend/knip.json",
|
||||
"frontend/package-lock.json",
|
||||
"frontend/package.json",
|
||||
"frontend/public/favicon.svg",
|
||||
"frontend/public/icons.svg",
|
||||
"frontend/scripts/check-openapi.mjs",
|
||||
"frontend/src/app/index.ts",
|
||||
"frontend/src/app/routes/AppRoutes.test.tsx",
|
||||
"frontend/src/app/routes/AppRoutes.tsx",
|
||||
"frontend/src/app/routes/ProtectedLayout.tsx",
|
||||
"frontend/src/app/routes/RouteErrorBoundary.test.tsx",
|
||||
"frontend/src/app/routes/RouteErrorBoundary.tsx",
|
||||
"frontend/src/app/routes/RouteFallback.tsx",
|
||||
"frontend/src/app/routes/RouteGuards.tsx",
|
||||
"frontend/src/app/routes/index.ts",
|
||||
"frontend/src/app/styles.css",
|
||||
"frontend/src/app/theme.ts",
|
||||
"frontend/src/app/ui/AccountBreadcrumbs.tsx",
|
||||
"frontend/src/app/ui/App.tsx",
|
||||
"frontend/src/app/ui/AppBreadcrumbs.module.css",
|
||||
"frontend/src/app/ui/AppBreadcrumbs.test.tsx",
|
||||
"frontend/src/app/ui/AppBreadcrumbs.tsx",
|
||||
"frontend/src/app/ui/BreadcrumbTrail.tsx",
|
||||
"frontend/src/app/ui/index.ts",
|
||||
"frontend/src/assets/hero.png",
|
||||
"frontend/src/assets/react.svg",
|
||||
"frontend/src/assets/vite.svg",
|
||||
"frontend/src/entities/broker-operation/api/useBrokerageOperations.test.tsx",
|
||||
"frontend/src/entities/broker-operation/api/useBrokerageOperations.ts",
|
||||
"frontend/src/entities/broker-operation/index.ts",
|
||||
"frontend/src/entities/broker-operation/model/display.ts",
|
||||
"frontend/src/entities/broker-operation/ui/LedgerEntryRow.module.css",
|
||||
"frontend/src/entities/broker-operation/ui/LedgerEntryRow.tsx",
|
||||
"frontend/src/entities/brokerage-account/api/useBrokerageAccounts.test.tsx",
|
||||
"frontend/src/entities/brokerage-account/api/useBrokerageAccounts.ts",
|
||||
"frontend/src/entities/brokerage-account/index.ts",
|
||||
"frontend/src/entities/brokerage-account/model/display.ts",
|
||||
"frontend/src/entities/brokerage-account/ui/BrokerageAccountList.module.css",
|
||||
"frontend/src/entities/brokerage-account/ui/BrokerageAccountList.stories.tsx",
|
||||
"frontend/src/entities/brokerage-account/ui/BrokerageAccountList.test.tsx",
|
||||
"frontend/src/entities/brokerage-account/ui/BrokerageAccountList.tsx",
|
||||
"frontend/src/entities/brokerage-event/api/useBrokerageEvents.test.tsx",
|
||||
"frontend/src/entities/brokerage-event/api/useBrokerageEvents.ts",
|
||||
"frontend/src/entities/brokerage-event/index.ts",
|
||||
"frontend/src/entities/income/api/useIncome.ts",
|
||||
"frontend/src/entities/income/index.ts",
|
||||
"frontend/src/entities/portfolio/api/usePortfolio.test.tsx",
|
||||
"frontend/src/entities/portfolio/api/usePortfolio.ts",
|
||||
"frontend/src/entities/portfolio/index.ts",
|
||||
"frontend/src/entities/portfolio/model/display.test.ts",
|
||||
"frontend/src/entities/portfolio/model/display.ts",
|
||||
"frontend/src/features/auth/index.ts",
|
||||
"frontend/src/features/auth/model/auth.test.tsx",
|
||||
"frontend/src/features/auth/model/auth.tsx",
|
||||
"frontend/src/features/auth/model/validation.ts",
|
||||
"frontend/src/features/auth/ui/AuthForm.module.css",
|
||||
"frontend/src/features/auth/ui/AuthForm.test.tsx",
|
||||
"frontend/src/features/auth/ui/AuthForm.tsx",
|
||||
"frontend/src/features/auth/ui/AuthPageLayout.module.css",
|
||||
"frontend/src/features/auth/ui/AuthPageLayout.tsx",
|
||||
"frontend/src/features/auth/ui/LoginForm.tsx",
|
||||
"frontend/src/features/auth/ui/RegisterForm.tsx",
|
||||
"frontend/src/features/tbank-connection/index.ts",
|
||||
"frontend/src/features/tbank-connection/model/connection-boundary.ts",
|
||||
"frontend/src/features/tbank-connection/ui/TbankConnectionSection.test.tsx",
|
||||
"frontend/src/features/tbank-connection/ui/TbankConnectionSection.tsx",
|
||||
"frontend/src/features/tbank-connection/ui/TbankConnectionSection.view.test.tsx",
|
||||
"frontend/src/features/tbank-connection/ui/TbankConnectionSection.view.tsx",
|
||||
"frontend/src/features/tbank-connection/ui/TbankConnectionSection.vm.ts",
|
||||
"frontend/src/features/tbank-connection/ui/TbankConnectionSectionLoaded.tsx",
|
||||
"frontend/src/main.tsx",
|
||||
"frontend/src/pages/account-events/index.ts",
|
||||
"frontend/src/pages/account-events/ui/AccountEventsPage.test.tsx",
|
||||
"frontend/src/pages/account-events/ui/AccountEventsPage.tsx",
|
||||
"frontend/src/pages/account-events/ui/AccountEventsPage.vm.ts",
|
||||
"frontend/src/pages/account-events/ui/components/AccountEventRow.view.tsx",
|
||||
"frontend/src/pages/account-events/ui/components/AccountEventsPageEmpty.view.tsx",
|
||||
"frontend/src/pages/account-events/ui/components/AccountEventsPageError.view.tsx",
|
||||
"frontend/src/pages/account-events/ui/components/AccountEventsPageLoaded.view.tsx",
|
||||
"frontend/src/pages/account-events/ui/components/AccountEventsPageLoading.view.tsx",
|
||||
"frontend/src/pages/account-income/index.ts",
|
||||
"frontend/src/pages/account-income/ui/AccountIncomePage.module.css",
|
||||
"frontend/src/pages/account-income/ui/AccountIncomePage.test.tsx",
|
||||
"frontend/src/pages/account-income/ui/AccountIncomePage.tsx",
|
||||
"frontend/src/pages/account-income/ui/AccountIncomePage.vm.ts",
|
||||
"frontend/src/pages/account-income/ui/components/AccountIncomePageError.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/AccountIncomePageLoaded.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/AccountIncomePageLoading.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/IncomeBreakdown.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/IncomeComparisons.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/IncomeForecast.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/IncomeSummary.view.tsx",
|
||||
"frontend/src/pages/account-income/ui/components/IncomeTrend.view.tsx",
|
||||
"frontend/src/pages/account-operations/index.ts",
|
||||
"frontend/src/pages/account-operations/ui/AccountOperationsPage.test.tsx",
|
||||
"frontend/src/pages/account-operations/ui/AccountOperationsPage.tsx",
|
||||
"frontend/src/pages/account-operations/ui/AccountOperationsPage.vm.ts",
|
||||
"frontend/src/pages/account-operations/ui/components/AccountOperationsPageError.view.tsx",
|
||||
"frontend/src/pages/account-operations/ui/components/AccountOperationsPageLoaded.view.tsx",
|
||||
"frontend/src/pages/account-operations/ui/components/AccountOperationsPageLoading.view.tsx",
|
||||
"frontend/src/pages/account/index.ts",
|
||||
"frontend/src/pages/account/ui/AccountPage.module.css",
|
||||
"frontend/src/pages/account/ui/AccountPage.test.tsx",
|
||||
"frontend/src/pages/account/ui/AccountPage.tsx",
|
||||
"frontend/src/pages/account/ui/AccountPage.vm.test.tsx",
|
||||
"frontend/src/pages/account/ui/AccountPage.vm.ts",
|
||||
"frontend/src/pages/account/ui/components/AccountHeading.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/AccountPageEmpty.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/AccountPageError.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/AccountPageLoaded.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/AccountPageLoading.stories.tsx",
|
||||
"frontend/src/pages/account/ui/components/AccountPageLoading.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/CashBalances.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/IncomeSummary.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/PortfolioRefreshState.stories.tsx",
|
||||
"frontend/src/pages/account/ui/components/PortfolioRefreshState.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/PortfolioTotals.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/PositionCard.stories.tsx",
|
||||
"frontend/src/pages/account/ui/components/PositionCard.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/PositionLogo.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/PositionSection.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/RecentEvents.stories.tsx",
|
||||
"frontend/src/pages/account/ui/components/RecentEvents.view.tsx",
|
||||
"frontend/src/pages/account/ui/components/RecentOperations.view.tsx",
|
||||
"frontend/src/pages/accounts/index.ts",
|
||||
"frontend/src/pages/accounts/ui/AccountsPage.test.tsx",
|
||||
"frontend/src/pages/accounts/ui/AccountsPage.tsx",
|
||||
"frontend/src/pages/accounts/ui/AccountsPage.vm.ts",
|
||||
"frontend/src/pages/accounts/ui/components/AccountsPageEmpty.view.tsx",
|
||||
"frontend/src/pages/accounts/ui/components/AccountsPageError.view.tsx",
|
||||
"frontend/src/pages/accounts/ui/components/AccountsPageLoaded.view.tsx",
|
||||
"frontend/src/pages/accounts/ui/components/AccountsPageLoading.view.tsx",
|
||||
"frontend/src/pages/accounts/ui/components/AccountsRefreshState.view.tsx",
|
||||
"frontend/src/pages/login/index.ts",
|
||||
"frontend/src/pages/login/ui/LoginPage.tsx",
|
||||
"frontend/src/pages/not-found/index.ts",
|
||||
"frontend/src/pages/not-found/ui/NotFoundPage.tsx",
|
||||
"frontend/src/pages/register/index.ts",
|
||||
"frontend/src/pages/register/ui/RegisterPage.tsx",
|
||||
"frontend/src/pages/settings/index.ts",
|
||||
"frontend/src/pages/settings/ui/SettingsPage.tsx",
|
||||
"frontend/src/shared/api/authenticated-query.test.tsx",
|
||||
"frontend/src/shared/api/authenticated-query.ts",
|
||||
"frontend/src/shared/api/client.test.ts",
|
||||
"frontend/src/shared/api/client.ts",
|
||||
"frontend/src/shared/api/generated/schema.d.ts",
|
||||
"frontend/src/shared/api/index.ts",
|
||||
"frontend/src/shared/api/problem-details.ts",
|
||||
"frontend/src/shared/api/spec/openapi.json",
|
||||
"frontend/src/shared/i18n/i18n.ts",
|
||||
"frontend/src/shared/i18n/index.ts",
|
||||
"frontend/src/shared/i18n/locales/ru.ts",
|
||||
"frontend/src/shared/i18n/zod.ts",
|
||||
"frontend/src/shared/lib/display.test.ts",
|
||||
"frontend/src/shared/lib/display.ts",
|
||||
"frontend/src/shared/lib/index.ts",
|
||||
"frontend/src/shared/ui/AppShell.module.css",
|
||||
"frontend/src/shared/ui/AppShell.tsx",
|
||||
"frontend/src/shared/ui/LoadingSkeleton.tsx",
|
||||
"frontend/src/shared/ui/StateView.stories.tsx",
|
||||
"frontend/src/shared/ui/StateView.test.tsx",
|
||||
"frontend/src/shared/ui/StateView.tsx",
|
||||
"frontend/src/shared/ui/index.ts",
|
||||
"frontend/src/test/handlers.ts",
|
||||
"frontend/src/test/query.tsx",
|
||||
"frontend/src/test/server.ts",
|
||||
"frontend/src/test/setup.ts",
|
||||
"frontend/src/test/storybook.test.tsx",
|
||||
"frontend/tsconfig.app.json",
|
||||
"frontend/tsconfig.json",
|
||||
"frontend/tsconfig.node.json",
|
||||
"frontend/vite.config.ts",
|
||||
"frontend/vitest.config.ts",
|
||||
"specs/AGENTS.md",
|
||||
"specs/openspec/.cli-version",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/.openspec.yaml",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/design.md",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/proposal.md",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/specs/agent-sdd-session-workflow/spec.md",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/specs/project-documentation/spec.md",
|
||||
"specs/openspec/changes/optimize-session-oriented-sdd-v2/tasks.md",
|
||||
"specs/openspec/config.yaml",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd/schema.yaml",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd/templates/design.md",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd/templates/proposal.md",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd/templates/spec.md",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd/templates/tasks.md",
|
||||
"specs/openspec/specs/.gitkeep",
|
||||
"specs/openspec/specs/agent-sdd-session-workflow/spec.md",
|
||||
"specs/openspec/specs/api-contract-generation/spec.md",
|
||||
"specs/openspec/specs/app-breadcrumb-navigation/spec.md",
|
||||
"specs/openspec/specs/audit-remediation-workflow/spec.md",
|
||||
"specs/openspec/specs/backend-structured-logging/spec.md",
|
||||
"specs/openspec/specs/brokerage-account-income-analytics/spec.md",
|
||||
"specs/openspec/specs/brokerage-account-ledger/spec.md",
|
||||
"specs/openspec/specs/brokerage-account-upcoming-events/spec.md",
|
||||
"specs/openspec/specs/brokerage-accounts/spec.md",
|
||||
"specs/openspec/specs/engineering-change-governance/spec.md",
|
||||
"specs/openspec/specs/frontend-data-resilience/spec.md",
|
||||
"specs/openspec/specs/frontend-loading-presentation/spec.md",
|
||||
"specs/openspec/specs/frontend-quality-guardrails/spec.md",
|
||||
"specs/openspec/specs/frontend-query-coherence/spec.md",
|
||||
"specs/openspec/specs/frontend-ui-resilience/spec.md",
|
||||
"specs/openspec/specs/multi-repository-delivery/spec.md",
|
||||
"specs/openspec/specs/openspec-authority-and-lifecycle/spec.md",
|
||||
"specs/openspec/specs/portfolio-view/spec.md",
|
||||
"specs/openspec/specs/project-documentation/spec.md",
|
||||
"specs/openspec/specs/project-foundation/spec.md",
|
||||
"specs/openspec/specs/tbank-connection/spec.md",
|
||||
"specs/openspec/specs/user-authentication/spec.md",
|
||||
"specs/openspec/specs/workspace-artifact-hygiene/spec.md"
|
||||
],
|
||||
"fingerprint": "sha256:42e412e4ee45f765bad83639561db8fb5cf8aadeef3283b6543a5ca7152d724d"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,230 @@
|
||||
## Context
|
||||
|
||||
SDD lifecycle уже опирается на canonical OpenSpec store, versioned engineering
|
||||
governance, repository-local routing и необязательные agent adapters. Сейчас эти
|
||||
слои частично повторяют lifecycle rules, а session state не связывает сохранённый
|
||||
approval с неизменностью одобренного artifact. Implementation ориентирована на
|
||||
полное завершение change за один outcome, Validation и Finalization местами
|
||||
повторяют evidence work, а Completion Evidence живёт вне canonical archive.
|
||||
|
||||
Подход должен сохранить OpenSpec единственной authority для change-specific
|
||||
знания, `docs/development` — authority для общей policy и context discipline, а
|
||||
active instructions — короткими routing entrypoints. Canonical workflow должен
|
||||
оставаться выполнимым без конкретного AI-agent runtime. Все репозитории
|
||||
независимы, CI отсутствует, а локальные gates выполняются под Node 22.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
|
||||
- Разделить vendor-neutral lifecycle core, repository-local boundaries и
|
||||
необязательные runtime adapters без дублирования общей policy.
|
||||
- Представить Specification как две ограниченные последовательности с отдельной
|
||||
approval boundary перед каждым downstream artifact.
|
||||
- Сделать persisted session navigation достаточной для точного продолжения, но
|
||||
не превращать её в альтернативу canonical artifacts или самостоятельное
|
||||
доказательство approval.
|
||||
- Разрешить Implementation завершаться проверенным checkpoint и направлять
|
||||
Validation и Finalization по точным, не пересекающимся обязанностям.
|
||||
- Хранить фактическое Completion Evidence вместе с canonical archive.
|
||||
|
||||
**Non-Goals:**
|
||||
|
||||
- Изменять пользовательское поведение WealthLedger, доменную модель или API.
|
||||
- Вводить новый workflow engine, CI service либо обязательный agent runtime.
|
||||
- Переносить Requirements, Design, Tasks или acceptance scenarios в session
|
||||
records, documentation или active instructions.
|
||||
- Автоматически считать сохранённое состояние approval решением Change Owner.
|
||||
|
||||
## Decisions
|
||||
|
||||
### 1. Canonical core и active entrypoints имеют разные обязанности
|
||||
|
||||
Общая lifecycle policy и context discipline остаются в двух versioned
|
||||
vendor-neutral authorities внутри `docs/development`: первая определяет стадии,
|
||||
ownership и completion safeguards, вторая — bounded reads, evidence batching и
|
||||
handoff discipline. OpenSpec schema задаёт форму и stage-specific native
|
||||
instructions для canonical artifacts. Root и repository-local active
|
||||
instructions содержат только ссылочную маршрутизацию, локальные boundaries и
|
||||
canonical gates.
|
||||
|
||||
Необязательные skills, commands и session records являются adapters поверх этой
|
||||
модели. Они могут автоматизировать routing и persistence, но canonical outcomes
|
||||
должны быть достижимы вручную через OpenSpec и repository gates. Общие правила не
|
||||
копируются в каждый adapter: adapter ссылается на authority и добавляет только
|
||||
runtime-specific mechanics.
|
||||
|
||||
Альтернатива — сделать agent skill tree источником полного workflow — отклонена:
|
||||
она привязывает completion safeguards к одному runtime и создаёт расходящиеся
|
||||
копии policy. Оставить дублирование во всех `AGENTS.md` также отклонено из-за
|
||||
непроверяемого semantic drift.
|
||||
|
||||
### 2. Specification использует две bounded progression с четырьмя approval boundaries
|
||||
|
||||
Specification сохраняет одну роль, но делится на пары `Proposal + Delta Specs`
|
||||
и `Design + Tasks`. После draft каждого artifact workflow ждёт explicit approval
|
||||
его неизменившегося содержимого. Approval Proposal разрешает только Delta Specs;
|
||||
approval Delta Specs завершает первую пару и направляет следующий Specification
|
||||
outcome к Design. Аналогично approval Design разрешает только Tasks, а approval
|
||||
Tasks — переход к Implementation.
|
||||
|
||||
Navigation state хранит для текущей границы наблюдённый approval status,
|
||||
identity artifact и стабильный fingerprint его содержимого. Первичное значение
|
||||
`approved` появляется только после явного решения Change Owner. При продолжении
|
||||
fingerprint сверяется с canonical artifact: совпадение позволяет использовать
|
||||
сохранённый observed status, отсутствие статуса требует повторного решения, а
|
||||
несовпадение сбрасывает approval изменённого artifact и всех downstream
|
||||
artifacts. Immutable record сообщает только наблюдённый переход и следующий
|
||||
outcome; canonical content в него не копируется.
|
||||
|
||||
Альтернатива — всегда повторно спрашивать approval в новой сессии — безопасна,
|
||||
но противоречит требуемому восстановлению контекста. Approval только по имени
|
||||
artifact без fingerprint отклонён, потому что не обнаруживает semantic edit.
|
||||
|
||||
### 3. Session recovery читает один актуальный envelope
|
||||
|
||||
Mutable state остаётся единственным navigation pointer, а immutable phase record
|
||||
— self-contained handoff текущего outcome. Recovery сначала выбирает одну роль и
|
||||
один разрешённый outcome, затем читает только текущий record, phase-specific
|
||||
authority и canonical artifacts этой роли. Старые records доступны лишь как
|
||||
evidence при расследовании конкретного расхождения.
|
||||
|
||||
Обновление выполняется в порядке `canonical outcome → immutable record → state
|
||||
pointer`. Незавершённая запись не продвигает pointer; конфликт конкурентных
|
||||
изменений остаётся видимым через filesystem/Git и не разрешается last-write-wins
|
||||
логикой. Records не содержат Requirements, decisions, Tasks или acceptance
|
||||
scenarios.
|
||||
|
||||
### 4. Implementation checkpoint является нормальным outcome той же роли
|
||||
|
||||
Implementation выбирает связный batch из ещё не выполненных approved Tasks.
|
||||
После реализации она отмечает только фактически завершённые canonical Tasks и
|
||||
сохраняет релевантные observed checks. Если implementation-owned Tasks остаются,
|
||||
outcome остаётся Implementation checkpoint с completed/remaining scope и одним
|
||||
следующим Implementation outcome; это не blocker и не готовность к Validation.
|
||||
|
||||
Только отсутствие remaining implementation-owned Tasks вместе с успешными
|
||||
релевантными проверками создаёт `READY_FOR_VALIDATION`. Размер batch не задаётся
|
||||
искусственным числом: граница определяется связностью изменения и возможностью
|
||||
дать проверяемый checkpoint без частично нарушенного инварианта.
|
||||
|
||||
Альтернатива — требовать реализацию всего change за одну сессию — отклонена из-за
|
||||
неограниченного контекста и потери проверяемых промежуточных результатов.
|
||||
|
||||
### 5. Validation производит независимый verdict, Finalization только потребляет его
|
||||
|
||||
Validation выполняется в отдельной read-only роли относительно production code,
|
||||
planning artifacts и Tasks. Она объединяет affected canonical gates, semantic и
|
||||
acceptance verification, применимые edge cases и independent review в один
|
||||
verdict: `PASS`, `FAIL` либо `SPEC_ISSUE`. Validation-owned проверки не
|
||||
представляются implementation checkboxes.
|
||||
|
||||
Record `PASS` связывается с identity проверенных planning и delivery inputs.
|
||||
Finalization проверяет, что эти inputs не изменились, но не повторяет актуальную
|
||||
Validation. Отсутствующий или устаревший `PASS` направляется в Validation;
|
||||
implementation finding — в Implementation; planning issue — к самой ранней
|
||||
затронутой Specification boundary; retryable completion failure остаётся в
|
||||
Finalization.
|
||||
|
||||
Альтернатива — разрешить Validation сразу исправлять findings — отклонена,
|
||||
поскольку смешивает независимый verdict с авторством изменений. Повторять все
|
||||
проверки в Finalization отклонено как дублирование уже привязанного к inputs
|
||||
evidence.
|
||||
|
||||
### 6. Completion Evidence формируется до archive только из существующих фактов
|
||||
|
||||
После успешной Validation delivery changes и их repository commits уже должны
|
||||
существовать. Finalization собирает фактическую Delivery Map, commit identifiers,
|
||||
точные observed gate outcomes и independent review result в Completion Evidence
|
||||
внутри active canonical change, затем архивирует change вместе с этой записью.
|
||||
После archive as-built remediation registry может ссылаться на canonical archive
|
||||
и не дублирует evidence.
|
||||
|
||||
Для `N/A` area сохраняется проверяемая причина без фиктивного commit или gate.
|
||||
Если любой факт отсутствует, Completion Evidence не создаёт placeholder и
|
||||
archive остаётся заблокирован. Тем самым archive является единственным
|
||||
долговечным evidence bundle, а docs сохраняет только as-built navigation.
|
||||
|
||||
Альтернатива — вести отдельный evidence store в docs — отклонена, поскольку он
|
||||
расходится с change authority и усложняет восстановление terminal status.
|
||||
|
||||
## Delivery Map
|
||||
|
||||
| Area | Status | Architectural outcome or N/A reason |
|
||||
| --- | --- | --- |
|
||||
| frontend | `affected` | Repository-local active instructions согласуются с vendor-neutral lifecycle authority и сохраняют только frontend boundaries и canonical gate. Product code и runtime behavior не меняются. |
|
||||
| backend | `affected` | Repository-local active instructions согласуются с vendor-neutral lifecycle authority и сохраняют только backend boundaries и canonical gate. API и runtime behavior не меняются. |
|
||||
| specs | `affected` | Canonical Delta Specs, OpenSpec schema instructions и completion/archive model закрепляют bounded Specification, Implementation checkpoints и разделение Validation/Finalization. |
|
||||
| docs | `affected` | Engineering governance, lifecycle/context documentation и remediation semantics становятся общей vendor-neutral authority и указывают на Completion Evidence в canonical archive. |
|
||||
|
||||
Workspace-owned root routing и optional runtime adapters меняются как
|
||||
orchestration surface, но не подменяют repository-owned outcomes из Delivery
|
||||
Map.
|
||||
|
||||
### Contract Gate Decision
|
||||
|
||||
| Gate | Status | Reason |
|
||||
| --- | --- | --- |
|
||||
| runtime-openapi | `N/A` | Change не меняет backend API contract, frontend contract consumer или runtime OpenAPI snapshot. |
|
||||
|
||||
## Solution Assessment
|
||||
|
||||
Change существенно меняет shared SDD tooling, поэтому оценены следующие
|
||||
варианты:
|
||||
|
||||
| Option | Fit and maturity | Security / operating cost | Constraints / migration cost |
|
||||
| --- | --- | --- | --- |
|
||||
| Расширить существующие OpenSpec schema, versioned Markdown authorities и малый navigation adapter | Высокое соответствие; OpenSpec уже является canonical store и поддерживает native artifact lifecycle | Не добавляет внешнего сервиса или credential surface; использует существующие local gates | Требует согласованно обновить active instructions и мигрировать текущий state envelope |
|
||||
| Сделать vendor-specific skills/commands обязательным workflow engine | Хорошая автоматизация только внутри одного runtime; portability низкая | Добавляет runtime lock-in и отдельную поверхность сопровождения safeguards | Нарушает достижимость canonical outcomes без optional framework и усложняет переход между agents |
|
||||
| Ввести отдельный general-purpose workflow/BPM/CI orchestrator | Зрелые продукты существуют, но их возможности существенно шире локального session routing | Добавляет сервис, конфигурацию, supply-chain и operational ownership | Непропорциональная миграция при отсутствии CI и серверной orchestration requirement |
|
||||
| Написать собственный orchestration engine | Можно точно подогнать под state machine, но зрелость начинается с нуля | Максимальная стоимость тестирования, совместимости и поддержки | Дублирует OpenSpec lifecycle и создаёт новую authority boundary |
|
||||
|
||||
Выбран первый вариант: он расширяет уже ответственную платформу и сохраняет
|
||||
малый custom surface только для локальной навигации. Повторная оценка нужна,
|
||||
если появятся multi-user concurrent execution, обязательный remote CI или
|
||||
невозможность выразить новый lifecycle invariant native OpenSpec validation.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Fingerprint защищает approval от незаметного изменения artifact, но не
|
||||
превращает navigation state в криптографическое доказательство личности
|
||||
Change Owner. Модель доверия остаётся repository-local и явной.
|
||||
- Разделение authorities снижает дублирование, но повышает важность корректных
|
||||
routing links. Canonical gates и scoped review должны обнаруживать broken
|
||||
links и противоречащие active instructions.
|
||||
- Миграция активного change может встретить legacy state без approval binding.
|
||||
Такой state не угадывается: текущая boundary запрашивает решение повторно.
|
||||
- Input-bound `PASS` требует точно определить relevant inputs. Слишком широкий
|
||||
набор вызывает лишнюю Validation, слишком узкий — риск stale verdict; binding
|
||||
включает все approved planning artifacts и affected delivery state.
|
||||
- Перенос Completion Evidence в archive меняет порядок Finalization. Archive
|
||||
остаётся заблокированным до существования delivery commits и всех observed
|
||||
verification facts.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Сначала изменить canonical schema и vendor-neutral lifecycle/context
|
||||
authorities так, чтобы новые state transitions, approval invalidation,
|
||||
checkpoint outcomes, verdict routing и archive evidence имели одно
|
||||
нормативное определение.
|
||||
2. Затем согласовать root и repository-local active instructions с новыми
|
||||
authorities, сохранив только routing, boundaries и local gates.
|
||||
3. После этого обновить optional runtime adapters и session envelope. Legacy
|
||||
state без artifact fingerprint остаётся читаемым для выбора change/phase, но
|
||||
не переносит approval автоматически.
|
||||
4. Перевести Implementation, Validation и Finalization adapters на новые
|
||||
outcomes и input bindings; удалить дублирующий evidence flow после появления
|
||||
canonical archive path.
|
||||
5. Завершить миграцию согласованной проверкой всех affected instruction
|
||||
surfaces и native OpenSpec lifecycle без зависимости от optional runtime.
|
||||
|
||||
### Rollback Contract
|
||||
|
||||
| Field | Decision |
|
||||
| --- | --- |
|
||||
| Status | `N/A` |
|
||||
| Reason | Изменение состоит из versioned process artifacts, local instructions и обратимого navigation state; оно не меняет auth/security, данные, public contract или необратимую runtime infrastructure. До завершения миграции прежние canonical artifacts сохраняются в Git, а legacy state без нового binding приводит к повторному approval, а не к потере данных. |
|
||||
| Trigger | N/A |
|
||||
| Actions | N/A |
|
||||
| Data safety | N/A |
|
||||
| Verification | N/A |
|
||||
@@ -0,0 +1,59 @@
|
||||
## Why
|
||||
|
||||
Текущий session-oriented SDD уже отделяет инженерные роли и сохраняет OpenSpec
|
||||
единственным источником требований, но продолжение change всё ещё требует
|
||||
лишних переключений между сессиями, повторного восстановления неизменившегося
|
||||
контекста и неоднозначной передачи ответственности за checkpoints,
|
||||
verification и завершение. Эти издержки затрудняют локальную разработку и
|
||||
создают повторную работу без дополнительной гарантии корректности. Workflow
|
||||
нужно сделать проще и предсказуемее сейчас, сохранив explicit approvals,
|
||||
независимую Validation и жёсткие blockers завершения.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Сгруппировать тесно связанные planning artifacts в ограниченные
|
||||
Specification-сессии, сохранив отдельное явное решение Change Owner перед
|
||||
каждым downstream artifact.
|
||||
- Сделать продолжение workflow однозначным и достаточным по минимальному
|
||||
актуальному состоянию, без обязательного перечитывания неизменившейся истории
|
||||
или повторного подтверждения уже принятого и не пересмотренного artifact.
|
||||
- Разрешить Implementation завершать связный ограниченный batch, сохранять
|
||||
оставшуюся работу и продолжаться в следующей Implementation-сессии без
|
||||
ложного blocker outcome.
|
||||
- Закрепить, что semantic verification, acceptance verification и independent
|
||||
review принадлежат Validation, а Finalization использует актуальный PASS и
|
||||
направляет проблему к точной ответственной роли без повторения неизменившейся
|
||||
проверки.
|
||||
- Устранить противоречия и дублирование в активных SDD и repository
|
||||
instructions, сделать операционный workflow независимым от конкретного
|
||||
AI-agent runtime и сохранить одну понятную authority для context discipline.
|
||||
- Перенести Completion Evidence к завершённому canonical change и сохранять в
|
||||
ней только уже существующие факты поставки, не вынуждая технический change
|
||||
создавать несвязанное as-built documentation.
|
||||
- Не вводить telemetry, числовые token budgets, автоматический multi-agent
|
||||
pipeline, отдельный workflow service или database и не менять поведение
|
||||
frontend/backend приложения либо публичный API.
|
||||
- Не ослаблять explicit approvals, canonical gates, risk-based testing,
|
||||
semantic verification, independent review или archive blockers; не
|
||||
переписывать historical changes, audits и иные датированные evidence.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `agent-sdd-session-workflow`: уточнить наблюдаемую модель bounded sessions,
|
||||
approvals, восстановления контекста, Implementation checkpoints, независимой
|
||||
Validation и точной маршрутизации Finalization.
|
||||
- `project-documentation`: изменить контракт Completion Evidence и terminal
|
||||
verification так, чтобы фактическое завершение сохранялось рядом с canonical
|
||||
archived change без обязательной параллельной docs-записи.
|
||||
|
||||
## Impact
|
||||
|
||||
Change затрагивает участников, которые планируют, реализуют, проверяют и
|
||||
завершают SDD changes в локальной multi-repository workspace. Он меняет
|
||||
ожидаемый процесс перехода между SDD-ролями, форму durable completion evidence и
|
||||
активные инженерные инструкции, но не пользовательские возможности WealthLedger,
|
||||
данные, публичные контракты или runtime-поведение приложения.
|
||||
+250
@@ -0,0 +1,250 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Implementation сохраняет ограниченные checkpoints
|
||||
|
||||
Implementation SHALL выбирать связный ограниченный batch из оставшихся
|
||||
утверждённых Tasks и MAY завершить сессию, оставаясь в роли Implementation,
|
||||
если весь change ещё не реализован. Такой checkpoint MUST фиксировать
|
||||
завершённые canonical Tasks, оставшуюся работу и достаточный результат
|
||||
релевантных проверок, не выдавая неполный change за готовый к Validation.
|
||||
|
||||
#### Scenario: Завершён один связный batch
|
||||
|
||||
- **WHEN** Implementation завершила и проверила ограниченный batch, но в
|
||||
canonical Tasks осталась implementation-owned работа
|
||||
- **THEN** workflow сохраняет завершённые и оставшиеся Tasks, направляет
|
||||
продолжение в новую Implementation-сессию и не сообщает blocker или
|
||||
готовность к Validation
|
||||
|
||||
#### Scenario: Завершена вся implementation-owned работа
|
||||
|
||||
- **WHEN** все утверждённые implementation-owned Tasks выполнены и релевантные
|
||||
проверки Implementation успешны
|
||||
- **THEN** workflow фиксирует готовность change к независимой Validation
|
||||
|
||||
### Requirement: Активные инструкции согласованы и независимы от agent runtime
|
||||
|
||||
Активные SDD и repository instructions SHALL направлять участника к одной
|
||||
authority для общей lifecycle policy и одной authority для операционной context
|
||||
discipline. Они MUST сохранять одинаковые approval и completion safeguards и
|
||||
MUST NOT требовать конкретный AI-agent runtime или его необязательные
|
||||
framework-specific entrypoints для выполнения canonical workflow.
|
||||
|
||||
#### Scenario: Участник начинает работу из любого active entrypoint
|
||||
|
||||
- **WHEN** участник открывает root или repository-local active instructions
|
||||
- **THEN** он получает согласованный canonical lifecycle, применимые локальные
|
||||
boundaries и ссылки на общую authority без противоречащей копии shared policy
|
||||
|
||||
#### Scenario: Необязательный agent runtime отсутствует
|
||||
|
||||
- **WHEN** участник выполняет workflow без vendor-specific commands, skills или
|
||||
instruction tree
|
||||
- **THEN** все canonical planning, implementation, validation и finalization
|
||||
outcomes остаются достижимыми без ослабления safeguards
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Каждая agent-сессия имеет одну SDD-роль
|
||||
|
||||
Session-oriented SDD workflow SHALL направлять каждую agent-сессию ровно в одну
|
||||
роль: Discovery, Specification, Implementation, Validation или Finalization.
|
||||
Сессия MUST NOT самостоятельно выполнять следующую роль, но создание immutable
|
||||
phase record или ожидание решения MUST NOT само по себе принуждать к новой
|
||||
сессии той же роли. Specification MUST поддерживать bounded progression
|
||||
`Proposal + Delta Specs` и `Design + Tasks`, сохраняя отдельную explicit
|
||||
approval boundary перед каждым downstream artifact.
|
||||
|
||||
#### Scenario: Начинается новый change
|
||||
|
||||
- **WHEN** пользователь начинает SDD-workflow для нового change
|
||||
- **THEN** workflow направляет сессию только в Discovery и не начинает
|
||||
Specification, Implementation, Validation или Finalization в той же сессии
|
||||
|
||||
#### Scenario: Specification подготавливает planning artifact
|
||||
|
||||
- **WHEN** Specification подготовила structurally valid Proposal
|
||||
- **THEN** workflow запрашивает явный approval Change Owner и не создаёт Delta
|
||||
Specs до получения решения
|
||||
|
||||
#### Scenario: Proposal явно одобрен
|
||||
|
||||
- **WHEN** Change Owner явно одобряет неизменившийся Proposal в bounded
|
||||
`Proposal + Delta Specs` progression
|
||||
- **THEN** Specification MAY продолжить в той же роли и создать Delta Specs без
|
||||
перехода к Design или другой SDD-роли
|
||||
|
||||
#### Scenario: Delta Specs явно одобрены
|
||||
|
||||
- **WHEN** Change Owner явно одобряет неизменившиеся Delta Specs
|
||||
- **THEN** workflow завершает bounded `Proposal + Delta Specs` progression и
|
||||
направляет следующий Specification outcome к Design
|
||||
|
||||
#### Scenario: Design явно одобрен
|
||||
|
||||
- **WHEN** Change Owner явно одобряет неизменившийся Design в bounded
|
||||
`Design + Tasks` progression
|
||||
- **THEN** Specification MAY продолжить в той же роли и создать Tasks без
|
||||
перехода к Implementation до отдельного approval Tasks
|
||||
|
||||
#### Scenario: Завершилась реализация
|
||||
|
||||
- **WHEN** Implementation завершает все утверждённые implementation-owned Tasks
|
||||
- **THEN** workflow фиксирует результат Implementation как вход для следующей
|
||||
Validation-сессии и не выполняет Validation в завершившейся
|
||||
Implementation-сессии
|
||||
|
||||
### Requirement: Продолжение workflow восстанавливает только нужный контекст
|
||||
|
||||
Workflow SHALL однозначно определять текущую роль и разрешённый outcome из
|
||||
сохранённого состояния change и одного актуального self-contained handoff. Он
|
||||
MUST загружать только phase-specific canonical authority и изменившийся
|
||||
relevant evidence, а не полную историю, прежние handoff-данные или уже
|
||||
прочитанные неизменившиеся inputs. После появления OpenSpec change его approved
|
||||
artifacts MUST быть источником intent, requirements, design и tasks.
|
||||
|
||||
#### Scenario: Пользователь продолжает change после другой сессии
|
||||
|
||||
- **WHEN** пользователь запрашивает продолжение известного change
|
||||
- **THEN** workflow определяет ровно одну текущую роль, читает только актуальный
|
||||
handoff и применимую canonical authority этой роли
|
||||
|
||||
#### Scenario: Есть история нескольких попыток
|
||||
|
||||
- **WHEN** change содержит более старые records или результаты прежних попыток
|
||||
- **THEN** workflow не загружает их по умолчанию и обращается к ним только для
|
||||
расследования конкретной проблемы текущей роли
|
||||
|
||||
#### Scenario: Независимые evidence доступны одновременно
|
||||
|
||||
- **WHEN** до следующего смыслового решения нужны несколько независимых
|
||||
read-only inputs
|
||||
- **THEN** workflow получает их одним bounded batch и сохраняет полный relevant
|
||||
scope для failure или review findings
|
||||
|
||||
#### Scenario: Успешный gate уже выполнен на неизменившихся inputs
|
||||
|
||||
- **WHEN** успешный gate был выполнен и его relevant inputs после этого не
|
||||
изменялись
|
||||
- **THEN** workflow использует сохранённый observed outcome и не повторяет gate
|
||||
без причины
|
||||
|
||||
### Requirement: Handoff не заменяет canonical OpenSpec authority
|
||||
|
||||
Workflow handoff SHALL сохранять только состояние перехода, краткий observed
|
||||
result, известные блокеры и один следующий допустимый outcome. Navigation state
|
||||
MAY сохранять approval status текущих planning artifacts для продолжения
|
||||
workflow, но handoff и state MUST NOT становиться альтернативным хранилищем
|
||||
Requirements, Delta Specs, Design, Tasks или acceptance scenarios и MUST NOT
|
||||
считаться самостоятельным доказательством решения Change Owner.
|
||||
|
||||
#### Scenario: Specification уже завершена
|
||||
|
||||
- **WHEN** следующая роль получает handoff после Specification
|
||||
- **THEN** она использует approved OpenSpec artifacts для требований и решений,
|
||||
а handoff — только для маршрутизации, observed results и известных
|
||||
ограничений
|
||||
|
||||
#### Scenario: Approval подтверждён для неизменившегося artifact
|
||||
|
||||
- **WHEN** новый Specification context содержит сохранённый approved status и
|
||||
workflow не изменял соответствующий planning artifact
|
||||
- **THEN** workflow продолжает к разрешённому downstream artifact без
|
||||
повторного запроса того же approval
|
||||
|
||||
#### Scenario: Workflow изменяет planning artifact
|
||||
|
||||
- **WHEN** workflow семантически изменяет planning artifact
|
||||
- **THEN** approval этого artifact и всех зависимых downstream artifacts
|
||||
сбрасывается до нового явного решения Change Owner
|
||||
|
||||
#### Scenario: Требование нужно изменить во время реализации
|
||||
|
||||
- **WHEN** Implementation обнаруживает, что requirement или архитектурное
|
||||
решение неполно либо противоречиво
|
||||
- **THEN** workflow возвращает работу к самой ранней затронутой canonical
|
||||
planning boundary и не изменяет требование только в handoff или реализации
|
||||
|
||||
### Requirement: Validation остаётся независимой и без побочных исправлений
|
||||
|
||||
Validation SHALL независимо выполнять affected canonical gates, semantic и
|
||||
acceptance verification, проверку применимых edge cases и independent read-only
|
||||
review относительно approved OpenSpec artifacts. Она MUST NOT изменять
|
||||
production implementation, specification или Tasks и MUST возвращать только
|
||||
PASS, FAIL либо SPEC_ISSUE с маршрутизацией к Finalization, Implementation либо
|
||||
самой ранней затронутой planning boundary. Validation-owned verification и
|
||||
review MUST NOT оставаться unchecked implementation Tasks.
|
||||
|
||||
#### Scenario: Реализация соответствует утверждённому change
|
||||
|
||||
- **WHEN** Validation подтверждает approved requirements, affected gates,
|
||||
acceptance behavior и отсутствие blocking review findings
|
||||
- **THEN** она возвращает PASS и разрешает следующую сессию Finalization
|
||||
|
||||
#### Scenario: Найдена проблема реализации
|
||||
|
||||
- **WHEN** Validation находит несоответствие реализации утверждённому OpenSpec
|
||||
- **THEN** она возвращает FAIL с точным observed finding и направляет следующую
|
||||
сессию к Implementation без самостоятельного исправления
|
||||
|
||||
#### Scenario: Найдена проблема спецификации
|
||||
|
||||
- **WHEN** Validation находит противоречие или пробел в approved planning
|
||||
artifacts
|
||||
- **THEN** она возвращает SPEC_ISSUE и направляет работу к самой ранней
|
||||
затронутой planning boundary без переписывания specification под реализацию
|
||||
|
||||
#### Scenario: Tasks планируют независимую проверку
|
||||
|
||||
- **WHEN** Tasks описывают ожидаемую semantic verification или independent
|
||||
review после реализации
|
||||
- **THEN** завершение Implementation не зависит от checkbox, который может
|
||||
закрыть только Validation
|
||||
|
||||
### Requirement: Finalization требует успешной независимой Validation
|
||||
|
||||
Workflow SHALL разрешать Finalization только после последней независимой
|
||||
Validation с PASS, если после неё не было relevant изменений planning или
|
||||
delivery inputs. Finalization MUST выполнять только archive и completion
|
||||
mechanics, MUST NOT повторять актуальную Validation и MUST направлять каждый
|
||||
blocker к точной ответственной роли без исправления production implementation
|
||||
или planning artifacts.
|
||||
|
||||
#### Scenario: Последняя Validation прошла
|
||||
|
||||
- **WHEN** Finalization получает change после PASS и relevant inputs с момента
|
||||
этой Validation не изменялись
|
||||
- **THEN** она использует observed PASS и выполняет completion mechanics без
|
||||
повторной independent Validation
|
||||
|
||||
#### Scenario: Implementation-owned Task не завершена
|
||||
|
||||
- **WHEN** Finalization обнаруживает незавершённую implementation-owned Task
|
||||
- **THEN** она возвращает blocker в Implementation и не архивирует change
|
||||
|
||||
#### Scenario: PASS отсутствует или устарел
|
||||
|
||||
- **WHEN** последняя Validation не завершилась PASS либо после PASS изменились
|
||||
relevant planning или delivery inputs
|
||||
- **THEN** Finalization возвращает blocker в Validation и не считает прежний
|
||||
outcome актуальным
|
||||
|
||||
#### Scenario: Обнаружена planning issue
|
||||
|
||||
- **WHEN** Finalization обнаруживает противоречие или пробел в approved planning
|
||||
artifacts
|
||||
- **THEN** она возвращает blocker к самой ранней затронутой Specification
|
||||
boundary без самостоятельного исправления
|
||||
|
||||
#### Scenario: Completion mechanics временно недоступны
|
||||
|
||||
- **WHEN** production и planning inputs корректны, но собственное retryable
|
||||
действие завершения не выполнено из-за environment или completion failure
|
||||
- **THEN** workflow остаётся в Finalization с observed blocker и не повторяет
|
||||
Implementation или Validation без изменения их inputs
|
||||
|
||||
#### Scenario: В Finalization обнаружена проблема
|
||||
|
||||
- **WHEN** Finalization обнаруживает любой blocker завершения
|
||||
- **THEN** она не закрывает lifecycle change, сохраняет observed cause и
|
||||
направляет продолжение к точной ответственной роли
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Completion Evidence сохраняет фактическое завершение change
|
||||
|
||||
Canonical archived OpenSpec change SHALL хранить Completion Evidence с
|
||||
фактической Delivery Map, commit identifiers изменённых delivery areas, точными
|
||||
выполненными verification commands и их observed results, а также итогом
|
||||
independent read-only review. Completion Evidence MUST создаваться только после
|
||||
существования этих фактов, MUST быть доступно вместе с canonical archive и MUST
|
||||
NOT представляться как unchecked Task, планируемый результат или обязательная
|
||||
docs-мутация для area со статусом `N/A`.
|
||||
|
||||
#### Scenario: Участник проверяет основание terminal status
|
||||
|
||||
- **WHEN** участник открывает canonical archive завершённого change в новой
|
||||
сессии
|
||||
- **THEN** он может проследить связь от Delivery Map к фактическим commits,
|
||||
affected local gates и independent review без восстановления контекста из
|
||||
чата или параллельного evidence store
|
||||
|
||||
#### Scenario: Реализация ещё продолжается
|
||||
|
||||
- **WHEN** часть delivery commits, commands, observed results или review ещё не
|
||||
существует
|
||||
- **THEN** change не представляет ожидаемые значения как Completion Evidence и
|
||||
не получает terminal status
|
||||
|
||||
#### Scenario: Технический change не меняет as-built documentation
|
||||
|
||||
- **WHEN** фактическая Delivery Map обоснованно устанавливает `docs: N/A`
|
||||
- **THEN** Completion Evidence сохраняет эту причину рядом с canonical archive
|
||||
и не требует несвязанного изменения docs repository
|
||||
|
||||
### Requirement: OpenSpec change закрывается только после полной верификации
|
||||
|
||||
OpenSpec change MUST содержать все обязательные planning artifacts и
|
||||
завершённые implementation-owned Tasks до архивирования. Archive MUST быть
|
||||
заблокирован, пока отсутствует успешный canonical gate любой affected area,
|
||||
semantic и acceptance verification реализации относительно approved artifacts
|
||||
либо independent read-only review без Critical и Important findings; для area
|
||||
со статусом `N/A` MUST существовать конкретная проверяемая причина.
|
||||
|
||||
#### Scenario: Команда пытается архивировать незавершенное изменение
|
||||
|
||||
- **WHEN** для change отсутствует обязательный artifact, implementation-owned
|
||||
результат, affected-area gate, semantic или acceptance verification,
|
||||
допустимый independent review либо требуемая as-built documentation
|
||||
- **THEN** change не архивируется и остаётся незавершённым без confirmation
|
||||
override
|
||||
|
||||
#### Scenario: Delivery area не затронута
|
||||
|
||||
- **WHEN** Delivery Map помечает area как `N/A`
|
||||
- **THEN** archive допускает отсутствие её commit и gate только при наличии
|
||||
конкретной проверяемой причины
|
||||
|
||||
### Requirement: Документация процесса содержит remediation registry
|
||||
|
||||
Репозиторий `docs` SHALL содержать immutable versioned audit snapshots в
|
||||
`docs/audits` и versioned remediation registry в development documentation.
|
||||
Registry MUST документировать source audit, допустимые статусы, связанные
|
||||
OpenSpec changes и следующую рекомендуемую задачу. Для завершённого
|
||||
audit-derived change registry MUST ссылаться на canonical archive и его
|
||||
Completion Evidence, а не дублировать commits и verification results как
|
||||
отдельный evidence store.
|
||||
|
||||
#### Scenario: Участник проекта ищет состояние технических улучшений
|
||||
|
||||
- **WHEN** участник открывает development documentation
|
||||
- **THEN** он может найти audit snapshot и registry через documentation indexes
|
||||
и определить, какие findings planned, active, done, deferred или accepted
|
||||
|
||||
#### Scenario: Завершён audit-derived change
|
||||
|
||||
- **WHEN** связанный OpenSpec change получил terminal status после успешной
|
||||
проверки
|
||||
- **THEN** registry содержит его итоговый статус и ссылку на canonical archive
|
||||
с Completion Evidence
|
||||
|
||||
### Requirement: Durable documentation is not a parallel SDD store
|
||||
|
||||
Репозиторий `docs` SHALL хранить только долговечную architecture, development,
|
||||
feature, audit и remediation documentation. Документация MUST описывать
|
||||
фактическое текущее состояние поставленной системы и MUST NOT представлять
|
||||
планируемое или частично реализованное поведение как доступное. Change-specific
|
||||
requirements, proposals, designs, delta specifications, tasks и Completion
|
||||
Evidence MUST храниться только в canonical OpenSpec store и MUST NOT
|
||||
пересказываться в `docs` как параллельная спецификация или evidence store. Docs
|
||||
SHALL обновляться после реализации и проверки только когда её as-built subject
|
||||
действительно affected.
|
||||
|
||||
#### Scenario: Change требует постоянной документации
|
||||
|
||||
- **WHEN** завершённый change меняет поставленное поведение, архитектурную
|
||||
границу, устойчивое решение или другой as-built subject docs
|
||||
- **THEN** documentation фиксирует реализованное состояние и MAY ссылаться на
|
||||
canonical OpenSpec change без дублирования его planning artifacts или
|
||||
Completion Evidence
|
||||
|
||||
#### Scenario: Agent планирует незавершённый change
|
||||
|
||||
- **WHEN** агент создаёт requirements, design или tasks для незавершённого
|
||||
изменения
|
||||
- **THEN** он сохраняет их в canonical OpenSpec store и не создаёт
|
||||
framework-specific planning document или описание будущего поведения в docs
|
||||
|
||||
#### Scenario: Реализация расходится с прежней документацией
|
||||
|
||||
- **WHEN** проверенный change изменяет поставленное поведение, архитектурную
|
||||
границу или устойчивое решение
|
||||
- **THEN** affected docs обновляется до фактического текущего состояния до
|
||||
terminal status и не сохраняет прежнее утверждение как действующее
|
||||
|
||||
#### Scenario: Docs не входит в Delivery Map
|
||||
|
||||
- **WHEN** технический change не меняет ни один as-built subject docs и Delivery
|
||||
Map устанавливает `docs: N/A` с проверяемой причиной
|
||||
- **THEN** terminal status не требует изменения docs только ради Completion
|
||||
Evidence
|
||||
@@ -0,0 +1,74 @@
|
||||
## 1. OpenSpec-native planning and Apply context
|
||||
|
||||
- [x] 1.1 [specs] Обновить project-local `wealth-ledger-sdd` schema metadata и зависимость Tasks с `design` на `design + specs`, чтобы native Tasks instructions возвращали утверждённый Design и все Delta Specs, необходимые для exact `Covers`
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Продолжение workflow восстанавливает только нужный контекст`; `agent-sdd-session-workflow` — `Handoff не заменяет canonical OpenSpec authority`
|
||||
- **Verification:** `openspec instructions tasks --change optimize-session-oriented-sdd-v2 --store wealth-ledger-specs` возвращает dependency paths Design и Delta Specs без дополнительных planning artifacts; `openspec schema validate wealth-ledger-sdd --verbose`
|
||||
- [x] 1.2 [specs] Дополнить только `apply.instruction` bounded Implementation semantics: выбирать связный batch pending Tasks, сохранять checkpoint при remaining work и выдавать `READY_FOR_VALIDATION` только после завершения всех implementation-owned Tasks и релевантных checks
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Implementation сохраняет ограниченные checkpoints`
|
||||
- **Verification:** `openspec instructions apply --change optimize-session-oriented-sdd-v2 --store wealth-ledger-specs` различает checkpoint и `READY_FOR_VALIDATION`, сохраняет чтение CLI-resolved `contextFiles` и не запускает Validation или Finalization
|
||||
|
||||
## 2. Vendor-neutral engineering authority
|
||||
|
||||
- [x] 2.1 [docs] Обновить engineering lifecycle authority: зафиксировать bounded Specification approvals, нормальный Implementation checkpoint, независимую Validation и Finalization, которая потребляет только актуальный input-bound `PASS`
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Каждая agent-сессия имеет одну SDD-роль`; `agent-sdd-session-workflow` — `Implementation сохраняет ограниченные checkpoints`; `agent-sdd-session-workflow` — `Validation остаётся независимой и без побочных исправлений`; `agent-sdd-session-workflow` — `Finalization требует успешной независимой Validation`
|
||||
- **Verification:** Scoped documentation review прослеживает каждую transition и blocker к одной ответственной роли без повторной Validation или side-effect repair
|
||||
- [x] 2.2 [docs] Обновить authority context discipline для recovery из одного актуального envelope, fingerprint-bound approval, bounded evidence reads и запрета копировать canonical artifacts в handoff
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Продолжение workflow восстанавливает только нужный контекст`; `agent-sdd-session-workflow` — `Handoff не заменяет canonical OpenSpec authority`
|
||||
- **Verification:** Scoped documentation review подтверждает порядок canonical outcome → immutable record → state pointer, invalidation при fingerprint mismatch и чтение старых records только для конкретного расследования
|
||||
- [x] 2.3 [docs] Перенести durable completion semantics к canonical archive и согласовать remediation registry и documentation indexes с ссылкой на archived Completion Evidence без отдельного evidence store
|
||||
- **Covers:** `project-documentation` — `Completion Evidence сохраняет фактическое завершение change`; `project-documentation` — `OpenSpec change закрывается только после полной верификации`; `project-documentation` — `Документация процесса содержит remediation registry`
|
||||
- **Verification:** Scoped link and ownership review подтверждает, что registry сохраняет source audit, status, related change и next task, а completed entry ссылается на canonical archive вместо дублирования commits и gate results
|
||||
|
||||
## 3. Active repository entrypoints
|
||||
|
||||
- [x] 3.1 [frontend] Свести frontend active instructions к ссылке на vendor-neutral lifecycle/context authorities, frontend boundaries и canonical local gate без копии shared SDD policy
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Активные инструкции согласованы и независимы от agent runtime`
|
||||
- **Verification:** Frontend entrypoint остаётся достаточным для выбора canonical workflow и local gate без обращения к optional skill или vendor-specific command
|
||||
- [x] 3.2 [backend] Свести backend active instructions к ссылке на vendor-neutral lifecycle/context authorities, backend boundaries и canonical local gate без копии shared SDD policy
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Активные инструкции согласованы и независимы от agent runtime`
|
||||
- **Verification:** Backend entrypoint остаётся достаточным для выбора canonical workflow и local gate без обращения к optional skill или vendor-specific command
|
||||
- [x] 3.3 [specs] Согласовать specs active instructions с canonical lifecycle authority, fixed store, one-artifact approvals, native stage routing и specs gate без дублирования общей policy
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Активные инструкции согласованы и независимы от agent runtime`
|
||||
- **Verification:** Specs entrypoint направляет к `wealth-ledger-specs`, native OpenSpec instructions и canonical validation без обязательного runtime adapter
|
||||
- [x] 3.4 [docs] Согласовать docs active instructions с canonical lifecycle authority, as-built ownership, remediation routing и docs gate без дублирования общей policy
|
||||
- **Covers:** `agent-sdd-session-workflow` — `Активные инструкции согласованы и независимы от agent runtime`; `project-documentation` — `Документация процесса содержит remediation registry`
|
||||
- **Verification:** Docs entrypoint однозначно различает canonical planning authority, as-built documentation и remediation registry и не требует optional runtime adapter
|
||||
- [x] 3.5 [workspace] Свести root routing и optional command entrypoints к vendor-neutral authorities, fixed canonical store и repository-local boundaries
|
||||
- **Covers:** `N/A` — workspace orchestration реализует утверждённое Design-разделение canonical core и optional adapters, но не добавляет самостоятельного observable requirement
|
||||
- **Verification:** Из root entrypoint можно определить SDD phase, canonical authority и affected repository gates без vendor-specific command tree
|
||||
|
||||
## 4. Optional session adapters
|
||||
|
||||
- [x] 4.1 [workspace] Обновить `.agents/skills/sdd-session/SKILL.md` и `.agents/skills/sdd-session/references/workflow-protocol.md`: добавить observed approval status, artifact identity и стабильный fingerprint в navigation envelope, downstream invalidation, безопасный recovery legacy state и точный phase routing
|
||||
- **Covers:** `N/A` — workspace navigation adapter технически реализует утверждённые Design decisions для approval recovery, тогда как normative behavior принадлежит canonical specs
|
||||
- **Verification:** Контролируемые `sdd-session` protocol scenarios показывают продолжение при совпадающем fingerprint, повторный запрос при отсутствии binding, invalidation при изменении artifact и маршрутизацию ровно в одну роль
|
||||
- [x] 4.2 [workspace] Обновить `.agents/skills/sdd-specification/SKILL.md` для пар `Proposal + Delta Specs` и `Design + Tasks`, сохранив отдельную explicit approval boundary перед каждым downstream artifact и запрет перехода к Implementation до approval Tasks
|
||||
- **Covers:** `N/A` — optional Specification orchestration проецирует approved canonical lifecycle и не создаёт отдельного requirement surface
|
||||
- **Verification:** `sdd-specification` scenarios проходят четыре approval boundaries, разрешают bounded продолжение внутри одной роли и останавливаются до Implementation без отдельного approval Tasks
|
||||
- [x] 4.3 [workspace] Обновить `.agents/skills/sdd-implementation/SKILL.md` для выбора связного batch, фиксации completed/remaining Tasks и checkpoint outcome без ложного blocker или преждевременного `READY_FOR_VALIDATION`
|
||||
- **Covers:** `N/A` — optional Implementation orchestration реализует approved checkpoint architecture, а observable invariant остаётся в canonical spec
|
||||
- **Verification:** `sdd-implementation` scenarios различают checkpoint с remaining implementation work и `READY_FOR_VALIDATION` только после завершения всех implementation-owned Tasks и релевантных checks
|
||||
- [x] 4.4 [workspace] Обновить `.agents/skills/sdd-validation/SKILL.md`: сохранить read-only boundary относительно production implementation, planning artifacts и Tasks и связать `PASS`, `FAIL`, `SPEC_ISSUE` с identity проверенных planning/delivery inputs
|
||||
- **Covers:** `N/A` — optional Validation orchestration реализует approved independent-verdict architecture без нового spec-level behavior
|
||||
- **Verification:** `sdd-validation` scenarios не выполняют repair mutations, сохраняют input binding и направляют каждый verdict к Finalization, Implementation либо самой ранней Specification boundary
|
||||
- [x] 4.5 [workspace] Обновить `.agents/skills/sdd-finalization/SKILL.md`: проверять свежесть `PASS`, точно маршрутизировать blockers и формировать Completion Evidence внутри active canonical change только из уже существующих фактов перед archive
|
||||
- **Covers:** `N/A` — optional Finalization orchestration реализует approved completion mechanics; normative archive safeguards принадлежат canonical specs
|
||||
- **Verification:** `sdd-finalization` scenarios блокируют missing/stale `PASS`, unchecked implementation task и incomplete evidence, не повторяют актуальную Validation, архивируют Completion Evidence вместе с change и оставляют retryable completion failure в Finalization
|
||||
|
||||
## 5. Affected-area gates and workflow consistency
|
||||
|
||||
- [x] 5.1 [frontend] Выполнить frontend canonical gate после изменения repository-local active instructions
|
||||
- **Covers:** `N/A` — это обязательная проверка affected frontend delivery, а не самостоятельное observable behavior
|
||||
- **Verification:** `npm run verify` под frontend `.nvmrc`
|
||||
- [x] 5.2 [backend] Выполнить backend canonical gate после изменения repository-local active instructions
|
||||
- **Covers:** `N/A` — это обязательная проверка affected backend delivery, а не самостоятельное observable behavior
|
||||
- **Verification:** `npm run verify` под backend `.nvmrc`
|
||||
- [x] 5.3 [specs] Выполнить native strict validation schema, active change и main specs в canonical store после реализации specs-owned work
|
||||
- **Covers:** `N/A` — это обязательный canonical gate affected specs delivery и structural proof, не новое requirement
|
||||
- **Verification:** `openspec schema validate wealth-ledger-sdd --verbose`; `openspec validate optimize-session-oriented-sdd-v2 --type change --strict --store wealth-ledger-specs`; `openspec validate --specs --strict --store wealth-ledger-specs`
|
||||
- [x] 5.4 [docs] Выполнить docs canonical gate и scoped local-link review после изменения governance, context authority и remediation navigation
|
||||
- **Covers:** `N/A` — это обязательная проверка affected docs delivery и ссылочной целостности, а не самостоятельное observable behavior
|
||||
- **Verification:** `npm run verify` под docs `.nvmrc`; scoped review изменённых local links
|
||||
- [x] 5.5 [workspace] Проверить согласованность всех active entrypoints и достижимость canonical planning, implementation, validation и finalization outcomes без optional runtime adapters
|
||||
- **Covers:** `N/A` — cross-area orchestration проверяет vendor-neutral delivery согласно Design, но не подменяет independent Validation и не создаёт новый requirement
|
||||
- **Verification:** Из clean shell пройти routing для каждой SDD-роли через canonical docs, native OpenSpec instructions и repository gates без вызова optional skills/commands; выполнить scoped semantic review против approved Delta Specs и Design
|
||||
Reference in New Issue
Block a user