Archive verified session-oriented SDD v2 delivery

This commit is contained in:
2026-09-07 22:28:34 +03:00
parent 04a07b390f
commit a342e9d63f
9 changed files with 909 additions and 74 deletions
@@ -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"
}
```
+185 -55
View File
@@ -9,12 +9,13 @@
### Requirement: Каждая agent-сессия имеет одну SDD-роль
Session-oriented SDD workflow SHALL направлять каждую новую agent-сессию ровно
в одну роль: Discovery, Specification, Implementation, Validation или
Finalization. Сессия MUST завершаться после результата своей роли и MUST NOT
самостоятельно выполнять следующую роль. Когда роль Specification готовит
planning artifact, она MUST соблюдать canonical OpenSpec artifact graph и
explicit approval boundary.
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
@@ -22,104 +23,233 @@ explicit approval boundary.
- **THEN** workflow направляет сессию только в Discovery и не начинает
Specification, Implementation, Validation или Finalization в той же сессии
#### Scenario: Завершилась реализация
- **WHEN** Implementation завершает разрешённый scope работы
- **THEN** workflow фиксирует результат Implementation как вход для следующей
сессии, направляет продолжение в Validation и не выполняет Validation в
завершившейся Implementation-сессии
#### Scenario: Specification подготавливает planning artifact
- **WHEN** Specification готовит следующий OpenSpec planning artifact
- **THEN** workflow создаёт только artifact, разрешённый текущей approval
boundary, и останавливается до явного решения Change Owner
- **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 определять следующую роль из сохранённого состояния change и
минимального handoff предыдущей роли. Он MUST загружать phase-specific canonical
authority, а не полную историю предыдущих сессий или все прежние handoff-данные.
После появления OpenSpec change его approved artifacts MUST быть источником
требований для последующих ролей; handoff MAY передавать только навигационные
факты, результаты и нерешённые блокеры.
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 этой
роли
- **THEN** workflow определяет ровно одну текущую роль, читает только актуальный
handoff и применимую canonical authority этой роли
#### Scenario: Есть история нескольких попыток
- **WHEN** change содержит предыдущие handoff-данные или результаты ранних
попыток
- **THEN** workflow не загружает их по умолчанию и обращается к ним только при
необходимости расследовать проблему текущей роли
- **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 сохранять только состояние перехода между ролями,
краткий результат, известные блокеры и один следующий допустимый outcome. Handoff
MUST NOT становиться альтернативным хранилищем Requirements, Delta Specs,
Design, Tasks, acceptance scenarios или approval decisions.
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** она использует OpenSpec artifacts для требований и технических
решений, а handoff использует только для маршрутизации и известных ограничений
- **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 или реализации
- **THEN** workflow возвращает работу к самой ранней затронутой canonical
planning boundary и не изменяет требование только в handoff или реализации
### Requirement: Validation остаётся независимой и без побочных исправлений
Validation SHALL независимо сопоставлять canonical OpenSpec artifacts с
состоянием репозитория, релевантными проверками и наблюдаемым поведением. Она
MUST NOT изменять production implementation или спецификацию. Validation MUST
возвращать PASS, FAIL либо SPEC_ISSUE и направлять следующую сессию к
Finalization, Implementation либо соответствующей planning boundary.
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 подтверждает requirements, relevant checks и границы
scope без blocking findings
- **WHEN** Validation подтверждает approved requirements, affected gates,
acceptance behavior и отсутствие blocking review findings
- **THEN** она возвращает PASS и разрешает следующую сессию Finalization
#### Scenario: Найдена проблема реализации
- **WHEN** Validation находит несоответствие реализации утверждённому OpenSpec
- **THEN** она возвращает FAIL с наблюдаемым finding и направляет следующую
- **THEN** она возвращает FAIL с точным observed finding и направляет следующую
сессию к Implementation без самостоятельного исправления
#### Scenario: Найдена проблема спецификации
- **WHEN** Validation находит противоречие или пробел в canonical planning
- **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. Если Finalization обнаруживает failure обязательной
проверки или проблему корректности, она MUST сообщить блокировку и направить
работу к ответственной предыдущей роли, не исправляя реализацию самостоятельно.
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 Validation
- **THEN** она выполняет только допустимые действия завершения canonical
lifecycle и фиксирует результат завершения
- **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 обнаруживает failed check или проблему корректности
- **THEN** она возвращает блокировку с наблюдаемой причиной и не закрывает
lifecycle change до работы ответственной роли
- **WHEN** Finalization обнаруживает любой blocker завершения
- **THEN** она не закрывает lifecycle change, сохраняет observed cause и
направляет продолжение к точной ответственной роли
### 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
+90 -19
View File
@@ -8,17 +8,34 @@
### Requirement: Completion Evidence сохраняет фактическое завершение change
Durable development documentation SHALL хранить для завершённого change ссылку на canonical OpenSpec archive, Delivery Map, commit identifiers изменённых репозиториев, точные выполненные verification commands, их наблюдённые результаты и итог independent read-only review. Completion Evidence MUST создаваться из фактов после выполнения работы, MUST быть доступно из устойчивого index или registry и MUST NOT дублироваться как unchecked task либо планируемый результат внутри archived 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** участник открывает evidence завершённого change в новой сессии
- **THEN** он может проследить связь от change и Delivery Map к фактическим commits, локальным gates и independent review без восстановления контекста из чата
- **WHEN** участник открывает canonical archive завершённого change в новой
сессии
- **THEN** он может проследить связь от Delivery Map к фактическим commits,
affected local gates и independent review без восстановления контекста из
чата или параллельного evidence store
#### Scenario: Реализация ещё продолжается
- **WHEN** часть commands, commits или review ещё не существует
- **THEN** documentation не представляет ожидаемые значения как Completion Evidence и change остаётся незавершённым
- **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: Важные архитектурные решения фиксируются в ADR
Репозиторий docs SHALL содержать ADR для выбора локального хранилища, API-контракта, gRPC-интеграции T-Bank, хранения T-Bank токенов, устойчивости upstream-вызовов, auth-сессий и frontend-кэша. Каждый ADR MUST описывать контекст, решение и последствия.
@@ -35,37 +52,91 @@ Durable development documentation SHALL хранить для завершённ
- **THEN** ее feature-документ существует и отражает фактическое поведение
### Requirement: OpenSpec change закрывается только после полной верификации
Функциональный OpenSpec change MUST содержать все требуемые артефакты, реализацию, критические тесты, успешную проверку `opsx-verify` и связанную документацию до архивирования.
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** для изменения отсутствует реализация, верификация или feature-документ
- **THEN** изменение не считается готовым к архивированию
- **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, следующую рекомендуемую задачу и evidence завершённых remediation changes.
Репозиторий `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
- **THEN** он может найти audit snapshot и registry через documentation indexes
и определить, какие findings planned, active, done, deferred или accepted
#### Scenario: Завершён audit-derived change
- **WHEN** связанный OpenSpec change архивирован после успешной проверки
- **THEN** registry обновляется с archive path, commits затронутых репозиториев и результатами exact verification commands
- **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 вместе с completion evidence. Документация MUST описывать фактическое текущее состояние поставленной системы и MUST NOT представлять планируемое или частично реализованное поведение как доступное. Change-specific requirements, proposals, designs, delta specifications и tasks MUST храниться только в canonical OpenSpec store и MUST NOT пересказываться в `docs` как параллельная спецификация в другом формате. Docs SHALL обновляться после реализации и проверки соответствующей области; она MAY ссылаться на canonical OpenSpec change, но MUST сохранять собственную as-built задачу и не копировать его нормативный текст.
Репозиторий `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 должен оставить устойчивое объяснение решения или evidence
- **THEN** documentation фиксирует реализованное состояние или completion evidence и ссылается на canonical OpenSpec change без дублирования его requirements, design или tasks
- **WHEN** завершённый change меняет поставленное поведение, архитектурную
границу, устойчивое решение или другой as-built subject docs
- **THEN** documentation фиксирует реализованное состояние и MAY ссылаться на
canonical OpenSpec change без дублирования его planning artifacts или
Completion Evidence
#### Scenario: Agent планирует незавершённый change
- **WHEN** агент создаёт requirements, design или tasks для незавершённого изменения
- **THEN** он сохраняет их под `specs/openspec` и не создаёт framework-specific planning document или описание будущего поведения в `docs`
- **WHEN** агент создаёт requirements, design или tasks для незавершённого
изменения
- **THEN** он сохраняет их в canonical OpenSpec store и не создаёт
framework-specific planning document или описание будущего поведения в docs
#### Scenario: Реализация расходится с прежней документацией
- **WHEN** проверенный change изменяет поставленное поведение, архитектурную границу или устойчивое решение
- **THEN** affected docs обновляется до фактического текущего состояния до terminal status и не сохраняет прежнее утверждение как действующее
- **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
### Requirement: Устойчивая документация имеет доступные фактические точки входа
Репозиторий `docs` SHALL содержать indexes архитектуры, разработки и фич,