Archive verified UI design workflow and Storybook delivery
Native archive synchronized 8 added and 3 modified requirements. All 24 main specs pass strict validation. Independent completion-output review confirms all 8 archived files preserve their bytes and all unrelated main specs remain unchanged. Product pilot remains a separate future change.
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: wealth-ledger-sdd
|
||||
created: 2026-09-06
|
||||
+658
@@ -0,0 +1,658 @@
|
||||
# Completion Evidence — integrate-ui-ux-design-workflow
|
||||
|
||||
Delivery facts observed on 2026-09-07 before native archive. Independent
|
||||
Validation: **PASS**, no unresolved Critical/Important findings. All **20**
|
||||
implementation-owned Tasks are complete; independent Validation is separate.
|
||||
The Change Owner explicitly authorized Storybook with real application components,
|
||||
all necessary canonical specification/implementation corrections, completion of
|
||||
the prerequisite and remaining work directly in the coordinating conversation.
|
||||
Optional SDD-session routing was not invoked; legacy state is not approval evidence.
|
||||
|
||||
## Delivery Map and existing commits
|
||||
|
||||
| Area | Delivered scope | Existing commit |
|
||||
| --- | --- | --- |
|
||||
| frontend | Storybook 10.6.0, six real WealthLedger component groups, 21 colocated stories, shared application visuals, isolated runtime graph and static build in the canonical gate | Storybook delivery `e63fd89a3922cd4dd7f194e33b320b4178985a5f`; reviewed delivery HEAD `36698322b7273b3a9eae1d078bcc9cddf2c8295b` includes the subsequent verified routing/formatting correction |
|
||||
| backend | N/A: no runtime, endpoints, DTOs, data, auth or API contract changes in this change | No new backend commit or gate claimed |
|
||||
| specs | Approved canonical artifacts/checklist, reconciled deltas, schema v5 and Design template with portable visual-package rules | `c6dc20b153d2d6b480c53bf5c4e780c17a177476` |
|
||||
| docs | As-built catalog/workflow, visual-package governance, lifecycle/context rules and navigation | `ac6c1ecc60f1cc72523e33052e50e7dc976611e7` |
|
||||
|
||||
Runtime-openapi is N/A because neither side of the API contract changes.
|
||||
Workspace-owned optional protocol/phase-adapter edits are local unversioned
|
||||
instructions included in the reviewed inventory; workspace root is not a Git
|
||||
repository and has no delivery commit. Existing change states/records and
|
||||
unrelated changes/historical archives were not migrated or rewritten.
|
||||
|
||||
## Completed prerequisite and semantic reconciliation
|
||||
|
||||
`optimize-session-oriented-sdd-v2` is actually completed and archived at store
|
||||
`wealth-ledger-specs`, path
|
||||
`changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/` from canonical
|
||||
OpenSpec root. Its completion evidence and checked Tasks are present in specs
|
||||
commit `a342e9d63f31dd7e79db26f207e1e8162a639d5a`; that commit synchronized
|
||||
2 ADDED and 9 MODIFIED Requirements and passed strict validation of 23 main specs.
|
||||
This observed delivery/archive evidence, not native planning completeness,
|
||||
unblocked the current process implementation. The full immutable dependency
|
||||
bundle is included in the current reviewed input inventory.
|
||||
|
||||
Both overlapping session requirements preserve the delivered v2 introductory
|
||||
clauses and all four existing scenarios each. The visual additions retain
|
||||
bounded checkpoints, content bindings, independent read-only Validation,
|
||||
canonical evidence ownership and approval boundaries. The stable source locator
|
||||
uses store ID and a path from canonical OpenSpec root so the caller's archive
|
||||
move cannot break dependency identity.
|
||||
|
||||
Expected current native semantic sync: **8 ADDED + 3 MODIFIED** Requirements,
|
||||
no removals or renames: frontend-ui-catalog adds 3 with its approved Purpose;
|
||||
agent-sdd-session-workflow modifies 2; openspec-authority-and-lifecycle modifies
|
||||
1 and adds 5. Unaffected requirements/scenarios and existing Purpose are retained.
|
||||
The current Design **UI/UX package revision 2 is fully inline**. There are no
|
||||
current attachments to invent, copy from an external editor or hash separately.
|
||||
This record describes prearchive facts; native archive/sync outputs are checked
|
||||
separately before the archive/evidence commit, whose own ID is not self-referenced.
|
||||
|
||||
## Observed verification commands and results
|
||||
|
||||
All Node commands used Node 22 selected with repository `nvm use --silent`;
|
||||
specs uses frontend runtime before changing into specs. Successful lockfile
|
||||
installation and environment prerequisites were retained for unchanged inputs.
|
||||
Commit/staging operations preserved the independently reviewed 325-file content
|
||||
fingerprint. No unchanged full gate was repeated merely for completion mechanics.
|
||||
|
||||
| Working directory | Exact command | Observed result |
|
||||
| --- | --- | --- |
|
||||
| frontend | `npm ci` | Exit 0 on the delivered unchanged lockfile |
|
||||
| frontend | `npm run verify` | Exit 0; 24 test files / 110 tests; TypeScript, Biome, OpenAPI snapshot, coverage, Knip, FSD and Storybook runtime boundaries; application and Storybook builds PASS |
|
||||
| docs | `npm ci` | Exit 0 on the delivered unchanged lockfile |
|
||||
| docs | `npm run verify` | Exit 0 after final locator clarification; 43 Markdown files, 0 issues, whitespace check PASS |
|
||||
| specs | `openspec schema validate wealth-ledger-sdd --verbose` | Exit 0; project-local schema v5 valid |
|
||||
| specs | `openspec validate integrate-ui-ux-design-workflow --type change --strict --store wealth-ledger-specs` | Exit 0 after final planning/checklist edits |
|
||||
| specs | `openspec validate --specs --strict --store wealth-ledger-specs` | Exit 0; all 23 main specs PASS before current semantic sync |
|
||||
| specs | `openspec instructions apply --change integrate-ui-ux-design-workflow --json --store wealth-ledger-specs` | Returned Proposal, three Delta Specs, Design and Tasks; every context file read |
|
||||
| workspace | `python3 /tmp/ui-workflow-visual-proof.py` | Exit 0; 10 temporary visual-package transfer/hash positive and negative checks below |
|
||||
| workspace | `python3 /tmp/wealthledger-fingerprint.py /tmp/ui-workflow-input-scope.json /tmp/ui-workflow-prearchive.json --previous /tmp/ui-workflow-ready-review.json` | Exit 0; exact 325-file reviewed inventory/fingerprint retained after delivery commits |
|
||||
| workspace | `cmp /tmp/ui-workflow-ready-review.json /tmp/ui-workflow-prearchive.json` | Exit 0; manifests identical |
|
||||
|
||||
Supporting observed evidence: 63 story/viewport cases (21 stories at
|
||||
320/768/1280 CSS px), 21 dev/static comparisons, Docs/Controls/reset/remount,
|
||||
Actions/retry and keyboard interactions passed, without horizontal overflow or
|
||||
application API/external data requests. The runtime boundary's controlled
|
||||
negative shared API import was rejected with seven dependency violations;
|
||||
restored valid code passes the canonical gate. Scoped documentation review
|
||||
resolved 27 local links. Fifteen optional-adapter routing cases and a fresh
|
||||
isolated reader passed within their explicit controlled-proof scope.
|
||||
|
||||
The existing Storybook static build has a nonblocking large-chunk warning.
|
||||
Backend gate results belong to the completed dependency, not current UI delivery.
|
||||
Temporary logs/fixtures are supporting evidence: durable verdict, outcomes and
|
||||
reviewed membership are embedded below. No test of a third-party platform,
|
||||
synthetic callback or file-transfer fixture is claimed as a complete product
|
||||
journey. **This delivery establishes readiness for a separately approved product
|
||||
pilot; no product pilot was performed.**
|
||||
|
||||
## Independent read-only Validation report
|
||||
|
||||
Verdict: **PASS** on the frozen inputs below. No unresolved Critical or Important findings.
|
||||
|
||||
The Change Owner authorized the Storybook/content correction, necessary canonical planning updates, completion of the prerequisite, and the remaining implementation/completion work in the coordinating conversation. This independent reviewer used the canonical workflow directly; the optional session router was not invoked. Stale legacy navigation was not treated as approval evidence. No production, policy, specification, checklist, state or historical archive was edited by this reviewer. This temporary report is evidence for canonical Completion Evidence, not another versioned planning store.
|
||||
|
||||
## Reviewed input binding
|
||||
|
||||
- Change: `integrate-ui-ux-design-workflow`.
|
||||
- Inventory: `/tmp/ui-workflow-ready-review.json`; independently re-expanded final snapshot: `/tmp/ui-workflow-independent-after.json`.
|
||||
- Raw planning/delivery fingerprint: `sha256:1c5877f10f41fc5ddbf1092efa51f4d8a7e6dc389a5a5056e44227d271d5ab38`.
|
||||
- Files: **325**. The reviewer independently reconstructed the documented byte stream and SHA-256, checked exact inventory membership, then re-expanded and matched the fingerprint again after review.
|
||||
- Scope: complete tracked/nonignored frontend and docs gate inputs; all 23 main specs; current canonical change and schema/templates; specs config/CLI version; the actual archived predecessor bundle including its Completion Evidence; root/repository routing and relevant local SDD/OpenCode instructions. Workspace-owned instructions are explicitly included even outside Git.
|
||||
- Exclusions: this change's own future Completion Evidence and irrelevant `.DS_Store`; unrelated active planning and historical archives other than the required predecessor. Backend runtime is N/A; its routing instruction is included explicitly. There is no API contract change requiring runtime-openapi.
|
||||
- Canonical Tasks: **20 implementation-owned checkboxes checked, 0 unchecked**. Independent Validation is a separate narrative responsibility, not an implementation checkbox. Raw checklist bytes are included in this verdict; approval normalization is a separate concern.
|
||||
- Current Design: **UI/UX package revision 2**, fully inline. No current change attachment needs an external account, live editor or invented screenshot identity.
|
||||
|
||||
## Authority, dependency and reconciliation
|
||||
|
||||
Read all six files returned by native Apply: Proposal, three Delta Specs, Design and Tasks. Reviewed affected frontend/specs/docs AGENTS, delivered lifecycle/governance/context authority, schema v5 and Design template, five changed local adapter/protocol surfaces, and applicable delivered main baselines. Earlier detailed Storybook source/config/test review remains applicable after verifying unchanged inputs.
|
||||
|
||||
The prerequisite is actually completed: `wealth-ledger-specs`, `changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/`, contains its actual Completion Evidence and completed Tasks; specs commit `a342e9d` archives it and synchronizes its approved main requirements. This is archive/delivery evidence, not merely native planning completeness. The bundle and its evidence are included in this review's input inventory.
|
||||
|
||||
The reviewer independently checked the two overlapping session requirements against the **delivered main baseline**. Both retain the exact baseline introductory text and all four existing scenarios each; the UI-only additions do not replace v2 batching, gate reuse, canonical authority, validation ownership or read-only safeguards. There are no pending edits to unrelated main specs or historical archive contents in the reviewed tree.
|
||||
|
||||
The replacement of the former independent-review checkbox with a separate Validation section preserves v2 ownership. Design's docs Delivery Map now points to canonical archive/Completion Evidence rather than a docs evidence store. These corrections remain within the authorized upstream revisions.
|
||||
|
||||
## Requirement and acceptance coverage
|
||||
|
||||
The three deltas contain **11 Requirements / 39 Scenarios**. All were semantically reviewed against implementation, declared Design and available verification evidence.
|
||||
|
||||
| Requirement | Reviewed implementation and acceptance evidence |
|
||||
| --- | --- |
|
||||
| Каталог предоставляет определённый набор реальных компонентов | Storybook 10.6.0 replaces the custom Vite shell. Six groups import real WealthLedger presentation components/compositions, use the existing app theme/CSS/i18n, and document purpose, variants and limits. The primary content is application components, not default Mantine demos or newly invented wrappers. Missing catalog coverage is explicitly not a prohibition on using a component. |
|
||||
| Примеры воспроизводят состояния и взаимодействия изолированно | Twenty-one stories cover declared states across BrokerageAccountList, PositionCard, RecentEvents, PortfolioRefreshState/PortfolioTotals, StateView and AccountPageLoading. Native Controls/reset/remount, local actions/retry, MemoryRouter links and existing accessibility/loading semantics remain in use. Browser evidence covers all stories at 320/768/1280px and dev/static equivalence; story tests preserve totals during refetch and invoke real callbacks without application data access. |
|
||||
| Каталог сохраняет достоверность и границы демонстрации | Synthetic typed props, null remote logos, memory routing and local callbacks avoid auth/API/VM execution and real user data. The additional runtime dependency check rejects reachable application data while retaining the baseline FSD check. Descriptions distinguish local retry, display-only cached totals and memory navigation from actual API recovery or complete product journeys. Changes to included components must be reviewed with their stories. |
|
||||
| SDD-артефакты имеют непересекающиеся полномочия | Canonical schema/template and governance place applicable visual materials in the existing Design and its single approval. Proposal/spec/task responsibilities remain distinct; concepts, screenshots and live Storybook do not grant approval. No new SDD role, visual approval slot, planning root or evidence store was introduced. |
|
||||
| UI/UX-проработка Design соразмерна изменению | Native Design instructions/template and governance define new/changed, exact reuse and reasoned N/A. Applicable screens, states, interactions and responsive behavior are described; reuse states its source, portion and differences. Unchanged areas and N/A do not require a formal new mockup. Current revision 2 uses the existing Storybook shell and inline description of actual app previews. |
|
||||
| Визуальный пакет Design имеет однозначную сохраняемую версию | Design revision/material identity, relative local PNG/SVG paths and raw-byte SHA-256 are defined without a self-referential Design hash. Exports are local and self-contained; exact archived reuse has store ID plus a path relative to canonical OpenSpec root, so moving the consuming change does not change source resolution. Approval/PASS bindings include declared material and reuse inputs. Controlled producer and independent reader evidence confirm restoration and identity for inline/export/reuse/N/A cases and explicit failure evidence for unavailable sources. |
|
||||
| Соответствие визуальному Design входит в semantic verification | Native Apply, lifecycle and adapters require following/reading the approved package. Validation compares screens, states, interactions and responsive behavior, returns implementation FAIL for an unambiguous visual deviation and SPEC_ISSUE for contradictory/ambiguous planning. It does not repair implementation or the package; screenshots/build success alone do not provide PASS. |
|
||||
| Внедрение UI/UX workflow сохраняет действующие approval boundaries | Process delivery waited for actual prerequisite completion, then reconciled the delivered v2 baseline. Governance/protocol preserve existing approved changes unless the owner explicitly requests migration at the appropriate boundary. No automatic retrofit/reapproval/PASS or historical rewrite occurs. |
|
||||
| Готовность к пилоту отделена от доказанной успешности workflow | As-built catalog/frontend workflow documents explain how to select a real component, retain a canonical Design package and hand it to Implementation/review. A later small UI change must be selected by its owner and obtain its own approvals. The delivered result is readiness for such a pilot; no product pilot is claimed or implicitly assigned. |
|
||||
| Продолжение workflow восстанавливает только нужный контекст | The complete v2 requirement and four scenarios are preserved. Native context routes to Design, which resolves its exact visual package; state/handoff carry only canonical pointers and observed integrity results. Missing/ambiguous materials block dependent work, not a guess from prior chat or a mutable external canvas. |
|
||||
| Validation остаётся независимой и без побочных исправлений | The complete delivered v2 requirement and four scenarios are preserved, including affected gates, acceptance/edge/review ownership and prohibition on changing Tasks. Added visual obligations use the same PASS/FAIL/SPEC_ISSUE outcomes and read-only boundary. |
|
||||
|
||||
## Verification and evidence reuse
|
||||
|
||||
- Frontend canonical gate: the last successful `npm run verify` under frontend Node 22 is retained in `/tmp/sdd-v2-frontend-verify-final.log`: **24 test files / 110 tests**, type/lint/OpenAPI/coverage/Knip/FSD/runtime-story checks, application build and Storybook static build pass. The earlier lockfile installation succeeded on the same lockfile. The reviewer verified `git diff 3669832` is empty and frontend inventory membership equals the previously reviewed full-gate set, so repeating this unchanged gate was unnecessary.
|
||||
- Storybook-specific prior source review covered all six CSF modules, common preview, configuration, runtime boundary rule and `composeStories` tests. The standard direct CSF exports and narrowly scoped Biome exceptions preserve indexing/story names. Flat `onAction: fn()` arguments connect StateView's real action slot to native Actions; retry remains a local function.
|
||||
- Coordinator's browser implementation evidence: **63 story/viewport cases** (21 states at 320/768/1280 CSS px), **21 dev/static comparisons**, Docs/Controls/reset/remount, Actions onAction/retry, keyboard links/actions, no horizontal overflow or application API/external data requests. These results belong to unchanged Storybook inputs; this reviewer did not rerun the browser or present its earlier custom Vite catalog checks as Storybook proof.
|
||||
- Runtime boundary negative evidence: `/tmp/storybook-boundary-negative.log` directly inspected; a controlled runtime shared API import is rejected by the reachable-dependency rule, including API client/query dependencies. Type-only props references remain allowed and are erased at runtime.
|
||||
- Specs: coordinator observed successful `openspec schema validate wealth-ledger-sdd --verbose`, `openspec validate integrate-ui-ux-design-workflow --type change --strict --store wealth-ledger-specs`, and `openspec validate --specs --strict --store wealth-ledger-specs` (**23 main specs**). Schema/current checks were rerun after the final locator clarification; unchanged main-spec inputs are included in this full inventory. Native Design/Tasks/Apply JSON snapshots were read: Design has the visual package rules; Tasks receives Design and Delta Specs; Apply resolves all six canonical context files. A native ready/completeness state is not used as this independent verdict.
|
||||
- Docs: `/tmp/ui-workflow-docs-verify-final.log` directly inspected: canonical `npm run verify` succeeds, **43 Markdown files, 0 issues**, plus coordinator's scoped **27 local-link** check. The final stable reuse locator clarification was included in this gate. Prior as-built claims of a blocked process were replaced with the actually delivered workflow and the explicit no-pilot limitation.
|
||||
- Portable visual package producer: retained `/tmp/ui-workflow-visual-proof.py` inspected. Ten observed positive/negative fixture checks cover inline-only, listed SVG hash and self-containment, copied relative package, archive-like move, exact dated reuse, N/A, missing material, changed bytes and unavailable external-only source. Fixtures are temporary and not a new versioned parser/checker or product feature. The reuse fixture is a standalone package root supplied by readme.json, not a registered canonical store; it proves dated exact-path/revision/material identity as an analogue. Actual current dependency identity uses the verified canonical store/root-relative path.
|
||||
- Fresh isolated reader: `/tmp/ui-workflow-isolated-reader.md` inspected. A reader without inherited package discussion resolves the entry pointer and actual package/material files; byte equality/hash/XML observations confirm readability and identity. It explicitly distinguishes observed recovery facts from assessed FAIL/SPEC_ISSUE routes, owner approval, actual native archive execution, whole-change Validation and product pilot success. This avoids overstating the controlled fixture proof.
|
||||
- Current package is fully inline; the generic export/reuse contract was exercised with controlled files. No extra attachment or formal mockup is required for this implementation's declared scope.
|
||||
- Backend and runtime-openapi remain **N/A**, with concrete Design reasons: no backend runtime, data, auth, public API or contract behavior changes.
|
||||
|
||||
## Resolved durability note
|
||||
|
||||
During review, the initial relative predecessor link in current Design (`../archive/...`) was identified as breaking after the consuming change moves under archive. Before the final freeze, the executor replaced it with stable canonical store/path identity and clarified the same locator rule in governance, native Design instructions and the template. The reviewer inspected the final form and fresh gate evidence. This preserves the source meaning and revision 2 visual package; there is no remaining unresolved finding.
|
||||
|
||||
## Completion limits
|
||||
|
||||
This independent PASS proves the reviewed implementation and readiness to use the catalog with the updated workflow. It does **not** claim a successful product pilot, execution of native archive for the current change, creation of current Completion Evidence, or terminal completion.
|
||||
|
||||
Finalization must consume this exact input-bound result, verify existing delivery commits and the expected semantic sync, create canonical Completion Evidence from observed facts, perform native archive and verify its outputs. For the current inline package, Design content must remain intact; any future declared exports/reuse sources must retain their relative structure, identity and availability. Expected archive/sync/evidence changes are handled as completion outputs; other relevant input changes invalidate this PASS.
|
||||
|
||||
## Controlled visual-package producer outcomes
|
||||
|
||||
```text
|
||||
PASS inline-only material restores without attachments or self-hash
|
||||
PASS local SVG export SHA-256 matches listed material
|
||||
PASS fixture SVG is self-contained without executable handlers or external assets
|
||||
PASS copied Design and relative materials readable by isolated reader
|
||||
PASS archive move preserves relative structure and material identity
|
||||
PASS exact dated immutable reuse resolves full original package
|
||||
PASS reasoned N/A needs no formal visual export
|
||||
PASS missing listed file produces concrete missing-material evidence
|
||||
PASS changed bytes produce digest mismatch; revision alone cannot approve them
|
||||
PASS external-only source has no retained local material; package remains unavailable
|
||||
```
|
||||
|
||||
## Independent isolated-reader evidence
|
||||
|
||||
# Independent bounded UI Design recovery proof
|
||||
|
||||
Verdict: **PASS for this controlled recovery/routing proof only**. This is not
|
||||
product UI Validation, a change-wide verdict, proof of owner approval, or proof
|
||||
that native OpenSpec archive was executed.
|
||||
|
||||
Reader: independent subagent with no inherited package discussion. Read root and
|
||||
docs instructions, canonical lifecycle, governance UI/UX policy, and context
|
||||
fingerprint rules. No SDD skill was invoked. Package entry point was
|
||||
`/tmp/ui-workflow-visual-proof-path.txt`, then `readme.json` and only its referenced
|
||||
Design/material files. The explicitly requested producer script was inspected
|
||||
separately. No repository, package, state or archive was mutated by this reader.
|
||||
|
||||
Fixture root:
|
||||
`/var/folders/j_/h2ft23gd3qq35ps3v5bcftfm0000gn/T/ui-workflow-visual-proof-2cy_zt20`.
|
||||
|
||||
## Observed recovery cases
|
||||
|
||||
| Case | Independent observation |
|
||||
| --- | --- |
|
||||
| Inline-only | `inline.md` contains applicability `new/changed`, revision 1, empty-card screen/state, no interaction, responsive widths 320/768/1280px, and explicitly inline material. No attachment or self-hash is needed. |
|
||||
| Local export | Archived `design.md` names material `sample`, relative path `visuals/state.svg`, empty-card purpose, revision 1 and a raw-byte SHA-256. The file exists, resolves inside its package, and has the listed hash. |
|
||||
| Isolated restoration | `isolated-reader/design.md` and its SVG are byte-identical to `archive/2026-09-07-visual-example/design.md` and its SVG. The same relative material path works in both directories. No URL/account/runtime was needed. |
|
||||
| Exact reuse | `reuse.md` identifies the dated archived Design, revision 1, material digest, empty-card-only scope and no differences. Following that source resolves its complete one-material package; no `latest` lookup is used. This is a fixture of exact archived reuse, not an independently proven repository archive transaction. |
|
||||
| Reasoned N/A | `not-applicable.md` states repository-instructions-only scope with no user interface. The reason is recoverable without requiring a formal visual export. |
|
||||
| External-only | `external-only.md` contains only `https://example.invalid/mutable-canvas`; there is no retained package material or exact source revision in that Design. It is intentionally unavailable for dependent implementation/review. No network fetch was attempted. |
|
||||
|
||||
Both actual SVGs have SHA-256:
|
||||
`5ec34c3212849508f77ed17e5bc88bb08b1e706a72e1e706384f517c1f6f4c0d`.
|
||||
Their XML is one 80x30 grey rectangle, without scripts, executable handlers or
|
||||
external assets; source parsing confirms the fixture is self-contained.
|
||||
|
||||
Independent read-only negative observations:
|
||||
|
||||
- Hashing the actual SVG bytes plus one in-memory space yields
|
||||
`f4eadd01a25087e1d6a07f98e0da25ab0f22c2692208465d6d58cf394fd8301f`, detecting a
|
||||
byte change without altering the package or its stated revision.
|
||||
- Reading the former `active/visual-example/visuals/state.svg` raises
|
||||
`FileNotFoundError`. This is the old location after the controlled move, not a
|
||||
missing material in the currently restored archive or isolated copy.
|
||||
- `/tmp/ui-workflow-visual-proof.py` explicitly deletes the isolated SVG, handles
|
||||
`FileNotFoundError`, writes changed bytes and asserts a digest mismatch, then
|
||||
restores the original bytes. Those historical mutation cases were inspected in
|
||||
retained source, not rerun or independently observed at their original time.
|
||||
|
||||
The independent Python read/compare/XML/hash checks exited 0. Current package
|
||||
files are intact; no missing material or digest mismatch was found in the valid
|
||||
archive and isolated packages.
|
||||
|
||||
## Expected routes, distinguished from executed product review
|
||||
|
||||
- Missing listed material, digest mismatch, ambiguous material identity or
|
||||
external-only source blocks dependent work. Restore the exact agreed bytes or
|
||||
return to the responsible planning boundary; do not reconstruct a design from
|
||||
chat memory or fetch a mutable current design as a substitute.
|
||||
- An implementation visibly inconsistent with an unambiguous package yields
|
||||
`FAIL`, owned by Implementation. For example, an implemented button contradicts
|
||||
this fixture's explicit no-interaction decision. No product implementation was
|
||||
provided here, so this routing rule was assessed, not executed as a UI verdict.
|
||||
- Contradictory or ambiguous package/planning yields `SPEC_ISSUE`. Resolve a
|
||||
design choice at Design; affected requirements return to Delta Specs and
|
||||
changed intent to Proposal, with the ordinary downstream approval cascade.
|
||||
- A material change cannot be authorized by retaining or silently incrementing
|
||||
revision, or by merely replacing its listed digest. Revision/digest detect
|
||||
identity/content changes; neither proves the owner's decision. Bindings include
|
||||
Design Markdown, listed attachments and exact reuse inputs. A changed planning
|
||||
fingerprint invalidates that approval and downstream approvals; relevant input
|
||||
changes invalidate PASS. A semantic replacement needs the responsible planning
|
||||
decision. Exact byte restoration can recover an unchanged approved binding.
|
||||
- The archive/copy byte equality proves portability of this fixture's relative
|
||||
structure. Their differently located inventory paths would produce different
|
||||
full set fingerprints; this check does not misrepresent them as the same
|
||||
workspace-relative binding. Expected archive moves require separate completion
|
||||
output checks under the existing lifecycle.
|
||||
|
||||
No unresolved issue was found within the bounded proof. Human design quality,
|
||||
real product screens/responsiveness, owner approval, repository gates and final
|
||||
change Validation remain outside this result.
|
||||
|
||||
## Optional adapter walkthrough evidence
|
||||
|
||||
# UI workflow adapter task 4.4 — scoped role walkthrough
|
||||
|
||||
These are manual applied scenarios against the edited optional adapters and
|
||||
canonical Design decisions 4/5. No production session skill was invoked, no
|
||||
state/record was migrated, and no product pilot was performed. File-transfer and
|
||||
SHA-256 experiments belong to the separate task 4.5 probe.
|
||||
|
||||
| Input | Applied adapter instruction and observed routing |
|
||||
| --- | --- |
|
||||
| Inline-only applicable Design | Specification reads native Design UI/UX contract; ordinary Design identity binds inline material. Existing protocol fingerprint authority is reused; no visual state or self-hash is added. |
|
||||
| Design lists local visual exports | Protocol resolves them through canonical Design, verifies declared availability/digests, and extends the existing Design approval/verification inventory. No parallel attachment registry is introduced. |
|
||||
| Design references exact immutable reuse | Protocol retains reused materials as bound inputs; context authority includes exact source Design/materials. Handoff retains pointers/results, not a copied package. |
|
||||
| Design has justified N/A | Conditional visual instructions do not invent a package; normal Design and Tasks approval boundaries remain. |
|
||||
| New Design package lacks a required material or has ambiguous scope | Specification blocks dependent planning before approval and returns the conflict to the earliest affected boundary. No standalone UI/UX approval exists. |
|
||||
| Material bytes mismatch declared digest during Implementation | Implementation stops dependent work, retaining exact observed cause until known bytes are restored or the responsible planning boundary is resolved; it never draws missing material from memory. |
|
||||
| Material missing or digest mismatch during Validation | Dependent checks stop and PASS is unavailable. Validation preserves evidence for existing recovery/verdict routing and performs no side-effect repair. |
|
||||
| App visibly contradicts an unambiguous approved Design state | Implementation corrects it within Tasks; independent Validation reports FAIL and routes to Implementation. |
|
||||
| Visual package conflicts with observable behavior in Specs | Implementation/Validation report SPEC_ISSUE at Delta Specs, cascading Design/Tasks approvals through existing protocol. A deeper intent conflict routes to Proposal. |
|
||||
| Visual package itself is ambiguous | SPEC_ISSUE returns to the earliest responsible planning boundary; Validation does not rewrite the package to match implementation. |
|
||||
| Material digest/revision updated | Protocol explicitly states that revision/digests grant no approval; existing whole-Design binding/cascade is applied. |
|
||||
| Current input-bound PASS reaches Finalization | Existing PASS inventory comparison includes Design materials, without repeating independent Validation. Native archive mechanics preserve Design/material structure and exact reuse identity. |
|
||||
| Material disappears or changes during archive transfer | Finalization blocks completion and follows existing blocker routing. External URL substitution cannot satisfy the missing canonical export. |
|
||||
| Already-approved legacy Design or unrelated active change | Protocol uses authority migration boundary instead of automatic retrofit or another change's state mutation. |
|
||||
| A handoff continues the work | It carries canonical pointers and observed integrity results only. Existing one-role/bounded-outcome rules remain unchanged. |
|
||||
|
||||
Observed local verification: six adapter files passed frontmatter/newline/
|
||||
whitespace checks; eight local links and the fingerprint anchor resolve.
|
||||
Production edits were limited to protocol plus Specification, Implementation,
|
||||
Validation and Finalization additions. Router, envelope version/fields,
|
||||
transitions, records, change state and historical archives were untouched.
|
||||
|
||||
## Reviewed input inventory
|
||||
|
||||
The following retained JSON defines membership, scope, exclusions and the
|
||||
independent raw PASS fingerprint. Its algorithm is the delivered context
|
||||
authority. Own Completion Evidence is excluded from self-hash; expected archive
|
||||
moves and approved main-spec sync are verified as separate completion outputs.
|
||||
|
||||
```json
|
||||
{
|
||||
"roots": [
|
||||
"frontend",
|
||||
"docs",
|
||||
"specs/openspec/schemas/wealth-ledger-sdd",
|
||||
"specs/openspec/specs",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2"
|
||||
],
|
||||
"paths": [
|
||||
"AGENTS.md",
|
||||
"specs/AGENTS.md",
|
||||
"specs/openspec/config.yaml",
|
||||
"specs/openspec/.cli-version",
|
||||
"backend/AGENTS.md"
|
||||
],
|
||||
"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": [
|
||||
".agents/skills/sdd-session/.DS_Store",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/completion-evidence.md"
|
||||
],
|
||||
"purpose": "Independent validation of integrate-ui-ux-design-workflow: full frontend/docs gate inputs, all main specs for native gate, schema, current canonical planning, completed dependency bundle and relevant local instructions. Backend runtime/API N/A; other active changes and historical archives outside dependency excluded.",
|
||||
"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/AGENTS.md",
|
||||
"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/archive/2026-09-07-optimize-session-oriented-sdd-v2/.openspec.yaml",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/completion-evidence.md",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/design.md",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/proposal.md",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/specs/agent-sdd-session-workflow/spec.md",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/specs/project-documentation/spec.md",
|
||||
"specs/openspec/changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/tasks.md",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/.openspec.yaml",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/design.md",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/proposal.md",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/specs/agent-sdd-session-workflow/spec.md",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/specs/frontend-ui-catalog/spec.md",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/specs/openspec-authority-and-lifecycle/spec.md",
|
||||
"specs/openspec/changes/integrate-ui-ux-design-workflow/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:1c5877f10f41fc5ddbf1092efa51f4d8a7e6dc389a5a5056e44227d271d5ab38"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,271 @@
|
||||
## Context
|
||||
|
||||
Frontend использует React 19, Vite 8, Mantine 9, общую app-owned theme, светлую
|
||||
схему и русскую i18n. Продуктовые presentation components уже отделены от VM и
|
||||
API. Каталог использует Storybook и покрывает реальные компоненты и композиции
|
||||
приложения; прежняя Vite-витрина удаляется. Продуктовые экраны не меняются.
|
||||
|
||||
Поставленная baseline — schema v4 и canonical authority после завершённого
|
||||
`optimize-session-oriented-sdd-v2`; его immutable bundle расположен в
|
||||
`wealth-ledger-specs`, `changes/archive/2026-09-07-optimize-session-oriented-sdd-v2/`
|
||||
относительно canonical OpenSpec root.
|
||||
Его canonical archive содержит Completion Evidence. Процессное расширение
|
||||
сохраняет поставленные bounded outcomes, approval/input binding, независимую
|
||||
Validation и canonical completion ownership. Два пересекающихся MODIFIED
|
||||
requirements дополнены визуальными обязанностями поверх этой baseline со всеми
|
||||
её существующими scenarios. UI/UX package revision 2 ниже сохраняется.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
|
||||
- Использовать специализированную инфраструктуру витрины с готовыми stories,
|
||||
controls, docs, navigation и изолированным preview.
|
||||
- Показывать реальные решения WealthLedger, применимые состояния и правила
|
||||
использования на общей визуальной основе приложения.
|
||||
- Сохранить изоляцию демонстраций от application API, auth и пользовательских
|
||||
данных, действующие FSD boundaries и canonical verification.
|
||||
- Включить переносимый визуальный пакет в существующий Design после завершения
|
||||
процессной зависимости, без нового lifecycle.
|
||||
|
||||
**Non-Goals:**
|
||||
|
||||
- Собственная navigation/controls система, каталог стандартных Mantine demos,
|
||||
wrappers над примитивами ради нового имени, массовый UI refactor или редизайн.
|
||||
- Полная каталогизация, отдельный publishing service, CI, browser mock mode,
|
||||
автоматическая visual regression либо продуктовая фича в роли пилота.
|
||||
|
||||
## Decisions
|
||||
|
||||
### 1. Каталог использует Storybook на существующем Vite stack
|
||||
|
||||
Выбран Storybook 10.6.0 с React/Vite framework и Docs addon той же версии.
|
||||
Published peer ranges React/Vite framework включают React 19 и Vite 8.
|
||||
Dependencies фиксируются точными versions в общем frontend lockfile. Другие
|
||||
addons не добавляются без конкретной потребности. Storybook владеет navigation,
|
||||
Controls, Docs, Actions и remount preview; собственный catalog shell удаляется.
|
||||
|
||||
Локальный Storybook и static build существуют отдельно от app entrypoint и
|
||||
продуктовых маршрутов. Сохраняются понятные scripts dev:catalog и build:catalog;
|
||||
static output — storybook-static. Продуктовая сборка не включает stories.
|
||||
Telemetry Storybook выключена. Manager может хранить собственные настройки
|
||||
витрины; это не разрешает stories читать application storage, cookies или secrets.
|
||||
|
||||
Общий preview decorator использует экспортируемую app theme, Mantine CSS,
|
||||
application styles, русскую i18n и светлую схему без чтения сохранённой темы.
|
||||
Stories находятся рядом с принадлежащими slice presentation modules и используют
|
||||
относительные imports внутри slice; cross-slice imports сохраняют public API.
|
||||
Storybook configuration — tooling composition, а не новый application слой.
|
||||
|
||||
Примеры получают синтетические typed props. MemoryRouter используется только
|
||||
для реальных components со ссылками; он не меняет URL приложения и не подключает
|
||||
product routes. AuthProvider, QueryClient, API clients, page containers и runtime
|
||||
VM hooks не входят в preview graph. Type-only ссылки на VM/API-derived props
|
||||
допустимы: они стираются и не запускают запросы. Проверка FSD сохраняет эти связи,
|
||||
а отдельный runtime pass того же dependency-cruiser проверяет именно выполняемый
|
||||
graph stories/preview без ослабления основной boundary проверки.
|
||||
|
||||
Внешние logos не загружаются: synthetic props используют null и реальный
|
||||
fallback компонента. Retry/actions используют локальный Storybook callback.
|
||||
Пример не выполняет денежные расчёты и не доказывает API recovery. Существующие
|
||||
pure presentation helpers допустимы для подготовки synthetic props.
|
||||
|
||||
### 2. Начальный набор представляет шесть групп решений WealthLedger
|
||||
|
||||
| Группа / реальные components | Состояния и конфигурации | Применение и ограничения |
|
||||
| --- | --- | --- |
|
||||
| BrokerageAccountList | summary available, unavailable, empty; длинное имя и несколько валют | Выбор счёта, сводка и их реальные ограничения; synthetic account IDs и MemoryRouter, без auth/API. |
|
||||
| PositionCard | stocks gain, bonds loss, other, missing valuation/identifiers | Карточка позиции с готовыми display props, null logo и реальным fallback; вычисления VM и котировки не воспроизводятся. |
|
||||
| RecentEvents | loaded, loading, error, empty, missing amount | Реальная секция ближайших событий; fixed synthetic items и локальная ссылка, без запроса календаря. |
|
||||
| PortfolioRefreshState вместе с PortfolioTotals | idle, refreshing, refresh error; локальный retry | Отображение сохранённых сумм при refetch/ошибке, без скрытия данных. Это presentation Client Cached Snapshot, не исполнение query lifecycle. |
|
||||
| StateView | empty/error, с действием и без него | Общий компонент пустого состояния/ошибки с alert semantics и локальным callback. |
|
||||
| AccountPageLoading через LoadingSkeleton | существующая структура заголовка, сводки и строк | Реальный page-owned structural loading; busy-region и декоративные shapes без фокуса. |
|
||||
|
||||
Названия, назначение и ограничения находятся в Storybook Docs для каждой группы;
|
||||
каждая история представляет определённое состояние. Controls изменяют только
|
||||
допустимые props; synthetic объекты и callbacks не становятся URL/API inputs.
|
||||
Истории с ссылками явно описывают, что полный переход на продуктовую страницу не
|
||||
демонстрируется. Storybook Actions показывает локальный callback.
|
||||
|
||||
Отдельный раздел стандартных Button/TextInput/Select/Checkbox/Alert/Paper не
|
||||
создаётся: в текущем scope нет отличающегося contract, который оправдывает копию
|
||||
Mantine docs. Эти primitives видны внутри настоящих compositions. Если появится
|
||||
реальная принятая конфигурация или app-owned abstraction, она рассматривается
|
||||
вместе с соответствующим изменением, без предварительных wrappers.
|
||||
|
||||
### 3. UI/UX package revision 2 — существующий Storybook shell и app preview
|
||||
|
||||
Применимость: **reuse** стандартного Storybook 10.6.0 manager/Docs/Controls и
|
||||
**new/changed** composition начальных stories на существующей теме WealthLedger.
|
||||
Процессная часть имеет UI/UX N/A, поскольку не вводит пользовательский экран.
|
||||
Пакет revision 2 полностью встроен в Design: таблица групп выше и правила ниже;
|
||||
отдельных attachments или изменяемых внешних макетов нет.
|
||||
|
||||
- Широкая витрина использует штатное дерево историй Storybook, Canvas/Docs и
|
||||
панель Controls/Actions. Выбор истории открывает её определённые synthetic args.
|
||||
- Узкая витрина использует штатную адаптивную navigation Storybook. Для проверки
|
||||
UI самого приложения доступен изолированный iframe preview; его область
|
||||
проверяется на 320, 768 и 1280 CSS px без горизонтальной прокрутки.
|
||||
- Цвета, typography, поверхности и responsive поведение внутри Canvas принадлежат
|
||||
существующим компонентам и app theme. Manager не стилизуется под продукт.
|
||||
- Controls отражают supported props; reset args и remount используют штатные
|
||||
действия Storybook. Изменение размера preview не сбрасывает args. Собственный
|
||||
сброс/счётчик и кастомный breakpoint navigation из revision 1 удаляются.
|
||||
- Ошибка/loading относятся к выбранной истории. Семантика alert/busy, доступные
|
||||
labels, keyboard/focus и сохранение данных при refetch остаются реальными.
|
||||
- Docs объясняет назначение, состояние, synthetic-data boundary и ограничения.
|
||||
Наличие истории не подтверждает полный journey или сквозной пилот процесса.
|
||||
|
||||
### 4. Визуальные материалы принадлежат одному canonical Design
|
||||
|
||||
Design получает компактный раздел UI/UX Applicability: `new/changed`, `reuse`
|
||||
либо `N/A` с причиной. Для применимого scope он определяет экраны, состояния,
|
||||
interactions и responsive rules; при reuse называет конкретную версию, часть
|
||||
решения и отличия. Новый формальный макет для неизменяемой области не нужен.
|
||||
|
||||
Основное переносимое представление — Markdown внутри Design. Если изображение
|
||||
необходимо для однозначного результата, используются локальные PNG/SVG exports
|
||||
в `visuals/` того же canonical change. Design содержит состав пакета: revision,
|
||||
идентификатор каждого материала, относительный путь, назначение/экран/состояние
|
||||
и SHA-256 для внешних по отношению к Markdown файлов. Содержимое самого Design
|
||||
входит в его обычную identity; self-referential hash не вводится. SVG exports
|
||||
самодостаточны, без scripts, внешних fonts/assets и исполняемых обработчиков.
|
||||
|
||||
Внешний редактор или preview может быть вспомогательным источником, но approved
|
||||
результат должен открываться из canonical пакета без аккаунта в этом сервисе.
|
||||
Ссылка на изменяемый каталог также не заменяет сохранённое решение: Design
|
||||
фиксирует выбранную конфигурацию и идентичность переиспользуемого источника.
|
||||
Reuse из другого archive ссылается на его точный immutable пакет, а не `latest`.
|
||||
|
||||
Revision описывает комплект, digest обнаруживает замену файла; ни то ни другое
|
||||
не доказывает owner approval. Approval относится ко всему представленному
|
||||
Design с его составом. Семантическая замена изображения, responsive rule или
|
||||
interaction меняет Design и возвращает его к обычному approval boundary.
|
||||
При несовместимости со Specs возврат начинается со Specs, при изменении intent —
|
||||
с Proposal. Форматное исправление не маскирует визуальное изменение.
|
||||
|
||||
При archive относительная структура Design/visuals переносится вместе с change.
|
||||
Проверяется доступность каждого материала и совпадение его identity после
|
||||
переноса; утрата файла блокирует завершение, а не компенсируется внешним URL.
|
||||
Historical archives не дополняются новыми пакетами задним числом.
|
||||
|
||||
### 5. Процесс расширяется в существующих владельцах
|
||||
|
||||
Project-local OpenSpec schema владеет формой Design и phase instructions;
|
||||
governance/lifecycle — единым правилом approval, переносимости и feedback.
|
||||
Runtime-neutral authority описывает поведение без обязательного конкретного
|
||||
skill, browser или design service. Локальные session skills/entrypoints только
|
||||
направляют к ней и читают выбранный пакет из Design; отдельный visual handoff,
|
||||
новая роль или отдельный UI/UX gate не возникают.
|
||||
|
||||
Implementation и Validation получают Design штатным native context routing,
|
||||
а из него — применимые материалы. Недоступность, отсутствующий материал или
|
||||
несовпадение digest блокирует зависимую работу до восстановления точного пакета
|
||||
либо owner decision на нужной boundary. Восстановление известных байтов не
|
||||
разрешает дорисовать отсутствующее решение по памяти.
|
||||
|
||||
Semantic verification сравнивает область изменения с согласованными экранами,
|
||||
состояниями, interactions и responsive behavior. Однозначный visual mismatch
|
||||
даёт исправление реализации; противоречие или неоднозначность самого пакета —
|
||||
возврат в Specification. Validation остаётся read-only. Native structural
|
||||
success, наличие screenshots и наличие каталога не дают semantic PASS.
|
||||
|
||||
Проверка комплектности использует обычные файловые операции, относительные
|
||||
ссылки и стандартный SHA-256; отдельный parser/registry или approval engine не
|
||||
создаётся. Native structural validation не заявляется автоматической проверкой
|
||||
качества макета или произвольных attachments. Содержательность applicability,
|
||||
полнота пакета и визуальное соответствие остаются явными обязанностями review.
|
||||
После завершения зависимости существующий approval/input binding расширяется
|
||||
на перечисленные attachments, не создавая параллельной модели state.
|
||||
|
||||
## Delivery Map
|
||||
|
||||
| Area | Status | Architectural outcome or N/A reason |
|
||||
| --- | --- | --- |
|
||||
| frontend | `affected` | Storybook с шестью группами реальных компонентов/композиций, общей theme, безопасными stories, Docs и отдельной static build в canonical gate. |
|
||||
| backend | `N/A` | Каталог не использует API/auth clients и реальные финансовые данные; endpoints, DTO, хранение, денежные вычисления и backend gate не меняются. |
|
||||
| specs | `affected` | Новая capability каталога, расширение lifecycle/session requirements и существующей schema для полного Design package после dependency reconciliation; planning остаётся только в canonical store. |
|
||||
| docs | `affected` | As-built описание доступного каталога, его границ, визуальной основы и фактически внедрённого UI/UX workflow; обновлённые routing links к canonical archive/Completion Evidence без отдельного evidence store в docs. |
|
||||
|
||||
### Contract Gate Decision
|
||||
|
||||
| Gate | Status | Reason |
|
||||
| --- | --- | --- |
|
||||
| runtime-openapi | `N/A` | Ни одна сторона API contract не изменяется; каталог изолирован от application API. |
|
||||
|
||||
Workspace entrypoints — локальная non-authority orchestration. Они следуют
|
||||
versioned specs/docs contract; их адаптация не подменяет repository-owned
|
||||
реализацию, Delivery Map или canonical gates.
|
||||
|
||||
## Solution Assessment
|
||||
|
||||
| Вариант | Fit и зрелость | Стоимость и ограничения | Решение |
|
||||
| --- | --- | --- | --- |
|
||||
| Storybook 10.6.0 + React/Vite + Docs | Специализированная поддерживаемая витрина; готовые navigation, args/controls, docs, actions и static build. Peer ranges включают React 19 и Vite 8. | Новые devDependencies и их обновления; конфигурация и stories остаются project-owned. Совместимость build и gate проверяется при интеграции. | Выбран: снижает объём собственного catalog tooling. |
|
||||
| Собственная Vite composition | Использует уже установленный stack | Требует сопровождать navigation, controls, reset, descriptions и responsive shell; малое число stories не устраняет эту стоимость. | Удаляется, конкретного gap Storybook не установлено. |
|
||||
| Ladle | Готовая React-витрина | Нет потребности во втором runner при выбранном Storybook; отдельная интеграция и lifecycle. | Не выбран. |
|
||||
| Mantine docs / screenshots | Полезный reference библиотеки | Не показывают реальные WealthLedger compositions и их состояния. | Вспомогательный reference, не каталог проекта. |
|
||||
|
||||
Для переносимого visual package сохраняются OpenSpec, Git, Markdown и при
|
||||
необходимости самодостаточные exports; Storybook показывает текущее состояние
|
||||
реализации и не заменяет сохраняемую согласованную версию Design.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Dependency может изменить main specs и approval model. Текущая проверка
|
||||
authority не даёт права применить сегодняшние MODIFIED blocks после неё без
|
||||
повторного сопоставления и нужного reapproval.
|
||||
- Общая theme предотвращает drift tokens; изменение descriptions или
|
||||
демонстрируемой конфигурации всё равно требует review вместе с компонентом.
|
||||
- Локальные synthetic examples доказывают UI interaction, но не API, денежную
|
||||
семантику или полный investment journey. Ограничение видно рядом с примером.
|
||||
- Переносимые exports увеличивают размер specs repository и нуждаются в ручном
|
||||
review. Используются только материалы, необходимые для конкретного Design;
|
||||
временные captures не становятся частью approved пакета автоматически.
|
||||
- Storybook в этом scope не предоставляет автоматическую visual regression.
|
||||
Проверка клавиатуры и responsive behavior выполняется browser review;
|
||||
отдельный browser test framework или числовой visual threshold не вводится скрыто.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Продолжить planning только по явным approvals текущего change. Этот Design
|
||||
фиксирует решения, но не включает новые process rules сейчас. Каталог может
|
||||
реализовываться после утверждения всех его planning artifacts; внедрение
|
||||
процессной части дополнительно зависит от завершения predecessor change.
|
||||
2. Перед process implementation подтвердить фактическое завершение
|
||||
`optimize-session-oriented-sdd-v2` по canonical archive и completion evidence,
|
||||
затем заново прочитать поставленную authority, schema и session routing.
|
||||
Наличие всех planning files или native `isComplete` недостаточно.
|
||||
3. Сопоставить пересекающиеся MODIFIED requirements с новыми main specs,
|
||||
сохранив поставленные predecessor invariants и scenarios. Если их текущая
|
||||
редакция требует изменения Requirement/Scenario, остановиться на Delta Specs
|
||||
approval boundary; после approval повторно согласовать зависимые Design и
|
||||
Tasks. Перенос future predecessor текста сейчас и автоматический merge при
|
||||
archive не заменяют этот шаг. При более раннем изменении intent возврат —
|
||||
к Proposal. До разрешения расхождения process implementation заблокирована.
|
||||
4. Поставить Storybook и истории, удалив прежний custom catalog, а после dependency
|
||||
reconciliation — согласованное расширение существующих schema,
|
||||
policy и локальных adapters. Не дублировать новые predecessor rules о роли
|
||||
Validation, evidence и bounded outcomes; добавить только visual package
|
||||
responsibilities. Docs описывают фактически проверенное состояние.
|
||||
5. Применять обновление к новым changes и к ещё не утверждённому Design активного
|
||||
change. Для уже утверждённого Design сохранить его исходную approval boundary:
|
||||
миграция пакета требует явного решения владельца; добавление или изменение
|
||||
содержательного UI/UX решения возвращает к Design и инвалидирует Tasks,
|
||||
затронутые Specs — к Specs. Для changes уже в Implementation/Validation нет
|
||||
автоматического retrofit или нового PASS: owner-requested migration проходит
|
||||
ту же boundary. Неизменяемые legacy changes продолжают по своему согласованному
|
||||
scope; исторические archives остаются неизменными. Не мигрировать чужие state
|
||||
в рамках этой поставки.
|
||||
6. Завершить текущую поставку с affected gates и независимым semantic review,
|
||||
сохранив Design package при archive. Готовность означает доступность каталога
|
||||
и работающего процесса. Отдельный последующий небольшой UI change выбирается
|
||||
владельцем, получает собственные approvals и использует оба результата;
|
||||
только его наблюдённый проход позволяет заявить успешность совместного пилота.
|
||||
|
||||
### Rollback Contract
|
||||
|
||||
| Field | Decision |
|
||||
| --- | --- |
|
||||
| Status | `N/A` |
|
||||
| Reason | Локальный tooling и versioned process artifacts обратимы; auth/security behavior, реальные данные, API и необратимая инфраструктура не меняются. Каталог имеет отдельный entrypoint. Возврат frontend/process редакции не удаляет canonical visual packages или archive и не восстанавливает approval автоматически. |
|
||||
@@ -0,0 +1,89 @@
|
||||
## Why
|
||||
|
||||
WealthLedger уже имеет общую основу интерфейса, но участникам разработки
|
||||
недоступен единый воспроизводимый каталог её возможностей и состояний.
|
||||
Существующий Design объясняет технические решения, однако не определяет,
|
||||
какой визуальный результат согласован, как передать его следующей изолированной
|
||||
сессии и как установить соответствие реализации этому результату.
|
||||
|
||||
Нужно связать доступную UI-основу и UI/UX-проектирование с действующим SDD,
|
||||
чтобы владелец видел ожидаемый интерфейс до реализации, а исполнители
|
||||
использовали одну согласованную основу и однозначный Design. Planning можно
|
||||
вести сейчас; внедрение процессной части начнётся после завершения
|
||||
`optimize-session-oriented-sdd-v2`.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Развить существующую UI-основу и предоставить один доступный участникам
|
||||
каталог ограниченного набора реальных компонентов и UI-композиций
|
||||
WealthLedger, их вариантов, применимых состояний и правил использования.
|
||||
Основное содержание показывает решения приложения; библиотечные примитивы
|
||||
допустимы только как вспомогательная основа с принятыми конфигурациями. Каталог отражает реальное поведение компонентов
|
||||
и общие визуальные правила приложения, позволяя выбирать готовые решения
|
||||
без запуска полного пользовательского сценария.
|
||||
- Включить UI/UX-проектирование в существующий Design. Объём визуальной
|
||||
проработки соразмерен изменению: новый или существенно изменённый интерфейс,
|
||||
переиспользование согласованного решения либо обоснованная неприменимость
|
||||
UI/UX. Отсутствие влияния на интерфейс не требует формального макета.
|
||||
- Сделать визуальные материалы частью единого согласуемого Design: они
|
||||
объясняют затронутые экраны, состояния, взаимодействия и адаптивное поведение
|
||||
в объёме конкретного change. Следующая изолированная сессия получает
|
||||
однозначную версию полного пакета, а материалы остаются доступны после
|
||||
архивирования change.
|
||||
- Передавать согласованный визуальный результат в реализацию и независимую
|
||||
проверку через существующий SDD. Существенное расхождение возвращает работу
|
||||
к соответствующей planning boundary; наличие макета или каталога само по
|
||||
себе не означает approval либо подтверждённое соответствие реализации.
|
||||
- Подготовить основу для совместного пилота каталога и обновлённого процесса
|
||||
на последующем небольшом UI change с собственными planning approvals.
|
||||
Текущая поставка даёт готовность к такому пилоту; успешность сквозного
|
||||
workflow можно заявить только после его фактического прохождения.
|
||||
- Перед Design повторно сверить действующую canonical authority. Согласование
|
||||
процесса с результатом `optimize-session-oriented-sdd-v2` не даёт права
|
||||
автоматически переутверждать активные changes или переписывать archives.
|
||||
|
||||
Вне scope: полный редизайн приложения, каталогизация всех компонентов,
|
||||
новая продуктовая фича в роли неявного пилота, замена существующей UI-основы,
|
||||
отдельная поставка дизайн-системы как самостоятельного продукта, автоматическое
|
||||
преобразование макетов в реализацию и двусторонняя синхронизация. Новый lifecycle,
|
||||
дополнительная SDD-роль и отдельный UI/UX approval не вводятся. Концептуальные
|
||||
материалы и Discovery остаются входным контекстом, а не утверждёнными
|
||||
OpenSpec-артефактами.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `frontend-ui-catalog` — `specs/frontend-ui-catalog/spec.md`: участники
|
||||
разработки могут воспроизводимо просматривать ограниченный набор реальных
|
||||
UI-компонентов, их варианты и состояния на общей визуальной основе приложения.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `openspec-authority-and-lifecycle` —
|
||||
`specs/openspec-authority-and-lifecycle/spec.md`: полномочия Design охватывают
|
||||
применимый визуальный пакет; единые approval, передача, semantic verification,
|
||||
feedback routing и сохранность при archive распространяются на весь пакет.
|
||||
- `agent-sdd-session-workflow` — `specs/agent-sdd-session-workflow/spec.md`:
|
||||
Specification, Implementation и независимая Validation используют применимые
|
||||
визуальные материалы из canonical Design при продолжении между сессиями,
|
||||
сохраняя единственную роль сессии и non-authority характер handoff.
|
||||
|
||||
## Impact
|
||||
|
||||
Основные пользователи изменения — Change Owner, участники UI/UX-проектирования,
|
||||
frontend-разработчики и AI-агенты, выполняющие planning, implementation и review.
|
||||
Для пользователей приложения этот change не вводит новых инвестиционных
|
||||
сценариев и не разрешает массовую смену интерфейса.
|
||||
|
||||
Затрагиваются frontend как владелец общей UI-основы и каталога, specs как
|
||||
владелец canonical SDD contract и docs как описание фактически поставленного
|
||||
процесса и правил использования основы. Локальные agent entrypoints следуют
|
||||
этому contract. Backend, денежные расчёты и публичный API не меняются.
|
||||
|
||||
Точные границы поставки по всем четырём репозиториям определит Delivery Map
|
||||
в Design. Действующие правила доступности, UI-состояний, границ frontend и
|
||||
обязательной проверки сохраняются; каталог не вводит конкурирующую модель
|
||||
пользовательского поведения. Совместимость инструментов, переносимость
|
||||
визуальных материалов и применимость обновлённого процесса к активным changes
|
||||
остаются вопросами последующего Design до разрешения внедрения.
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### 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.
|
||||
|
||||
Specification при подготовке Design SHALL определять применимый визуальный
|
||||
пакет в canonical Design. При продолжении после его approval Implementation и
|
||||
Validation SHALL получать применимые визуальные материалы именно согласованной
|
||||
версии из canonical Design, сохраняя одну роль сессии и не создавая копию Design
|
||||
в handoff. Недоступность или неоднозначность согласованного пакета MUST быть
|
||||
сообщена как блокер зависимой работы и MUST NOT компенсироваться догадкой по
|
||||
истории обсуждения или текущему внешнему макету.
|
||||
|
||||
#### 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
|
||||
без причины
|
||||
|
||||
#### Scenario: Specification готовит Design с визуальными материалами
|
||||
|
||||
- **WHEN** Specification получила разрешение подготовить Design с применимым
|
||||
UI/UX scope
|
||||
- **THEN** она представляет визуальные материалы как часть одного canonical
|
||||
Design и останавливается до его единого approval, не начиная другую роль
|
||||
|
||||
#### Scenario: Implementation получает утверждённый визуальный Design
|
||||
|
||||
- **WHEN** Implementation начинает разрешённую реализацию UI change
|
||||
- **THEN** она использует применимый пакет согласованной версии из canonical
|
||||
Design, а навигационный handoff не заменяет его содержимое или owner approval
|
||||
|
||||
#### Scenario: Пакет невозможно однозначно восстановить
|
||||
|
||||
- **WHEN** следующая роль не может получить применимые материалы или установить
|
||||
согласованную версию
|
||||
- **THEN** зависимая работа останавливается с конкретным блокером до
|
||||
восстановления пакета либо разрешения вопроса на соответствующей planning boundary
|
||||
|
||||
### 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.
|
||||
|
||||
Для применимого UI/UX scope независимое сопоставление SHALL включать визуальные
|
||||
материалы согласованной версии canonical Design и соответствующие экраны,
|
||||
состояния, взаимодействия и адаптивное поведение реализации. Read-only boundary
|
||||
Validation SHALL распространяться на весь визуальный пакет Design.
|
||||
|
||||
#### 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
|
||||
|
||||
#### Scenario: Найдено визуальное несоответствие
|
||||
|
||||
- **WHEN** наблюдаемая реализация расходится с однозначным применимым решением
|
||||
согласованного визуального пакета
|
||||
- **THEN** Validation возвращает FAIL с конкретным несоответствием и не
|
||||
исправляет интерфейс или визуальный пакет в этой сессии
|
||||
|
||||
#### Scenario: Визуальный пакет противоречит другим planning artifacts
|
||||
|
||||
- **WHEN** Validation обнаруживает противоречие согласованного визуального
|
||||
результата требованиям либо неоднозначность самого Design
|
||||
- **THEN** она возвращает SPEC_ISSUE с основанием возврата к самой ранней
|
||||
затронутой planning boundary, не выбирая новую трактовку самостоятельно
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
## Purpose
|
||||
|
||||
Предоставляет участникам разработки воспроизводимый обзор ограниченного набора
|
||||
реальных UI-компонентов и композиций WealthLedger для выбора решений на
|
||||
общей визуальной основе приложения.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Каталог предоставляет определённый набор реальных компонентов
|
||||
|
||||
Участники разработки SHALL иметь один доступный каталог с явно определённым
|
||||
ограниченным набором реальных компонентов и UI-композиций WealthLedger, их
|
||||
назначением, поддерживаемыми вариантами, применимыми состояниями и правилами
|
||||
использования. Основное содержание SHALL показывать решения, используемые
|
||||
приложением. Библиотечные примитивы MAY быть вспомогательными примерами принятых
|
||||
конфигураций, но MUST NOT подменять продуктовые компоненты и композиции. Каталог MUST демонстрировать реальное
|
||||
поведение компонентов на общей визуальной основе приложения, а не независимые
|
||||
имитации. Отсутствие компонента в каталоге MUST NOT означать его отсутствие в
|
||||
приложении или запрет использования.
|
||||
|
||||
#### Scenario: Участник выбирает готовое решение
|
||||
|
||||
- **WHEN** участник просматривает включённый в каталог компонент
|
||||
- **THEN** он видит его назначение, доступные варианты и состояния и может
|
||||
сопоставить их с потребностью интерфейса на визуальной основе WealthLedger
|
||||
|
||||
#### Scenario: Участник изучает принятый UI-паттерн
|
||||
|
||||
- **WHEN** участник выбирает композицию или компонент из основного набора
|
||||
- **THEN** он видит реальное решение WealthLedger, его назначение, состояния и
|
||||
ограничения применения, а не только стандартный пример UI-библиотеки
|
||||
|
||||
#### Scenario: Компонент не входит в начальный набор
|
||||
|
||||
- **WHEN** участник ищет компонент за пределами объявленного набора
|
||||
- **THEN** граница покрытия каталога остаётся явной, без заявления о полноте
|
||||
каталогизации приложения
|
||||
|
||||
### Requirement: Примеры воспроизводят состояния и взаимодействия изолированно
|
||||
|
||||
Каталог SHALL позволять воспроизводимо просматривать объявленные варианты и
|
||||
состояния без прохождения полного пользовательского сценария приложения.
|
||||
Интерактивные примеры SHALL позволять наблюдать поддерживаемые взаимодействия.
|
||||
Примеры MUST сохранять применимые правила доступности и UI-состояний приложения
|
||||
и MUST NOT вводить конкурирующую модель их поведения. Состояния, неприменимые к
|
||||
компоненту, MUST NOT требоваться только ради заполнения каталога.
|
||||
|
||||
#### Scenario: Участник повторно открывает пример
|
||||
|
||||
- **WHEN** участник повторно выбирает тот же объявленный вариант и состояние
|
||||
- **THEN** каталог воспроизводит соответствующий пример без предварительного
|
||||
прохождения инвестиционного сценария
|
||||
|
||||
#### Scenario: Участник взаимодействует с компонентом
|
||||
|
||||
- **WHEN** участник использует поддерживаемое взаимодействие интерактивного
|
||||
примера, включая клавиатурное управление там, где оно применимо
|
||||
- **THEN** доступное поведение, focus и ограничения состояния соответствуют
|
||||
реальному компоненту приложения
|
||||
|
||||
#### Scenario: Представлено запросное состояние
|
||||
|
||||
- **WHEN** пример показывает применимое loading, error, empty или loaded
|
||||
состояние либо отображение ранее полученных данных при refetch
|
||||
- **THEN** пример сохраняет действующую семантику соответствующего состояния
|
||||
приложения и не подменяет её новой каталоговой договорённостью
|
||||
|
||||
### Requirement: Каталог сохраняет достоверность и границы демонстрации
|
||||
|
||||
Каталог SHALL отражать фактические поддерживаемые возможности включённых
|
||||
компонентов и общие визуальные правила приложения. Демонстрационные данные
|
||||
MUST NOT требовать доступа к реальным финансовым данным или секретам пользователя;
|
||||
действия в примерах MUST NOT изменять реальные пользовательские данные. Известное
|
||||
ограничение воспроизведения MUST быть явно обозначено и MUST NOT представляться
|
||||
как подтверждённое продуктовое поведение.
|
||||
|
||||
#### Scenario: Возможность компонента изменилась
|
||||
|
||||
- **WHEN** изменённая возможность включённого компонента поставляется
|
||||
- **THEN** каталог показывает соответствующее фактическое поведение и не
|
||||
представляет устаревший вариант как поддерживаемый
|
||||
|
||||
#### Scenario: Участник выполняет демонстрационное действие
|
||||
|
||||
- **WHEN** участник открывает пример или выполняет в нём действие
|
||||
- **THEN** для демонстрации не требуются реальные пользовательские финансовые
|
||||
данные или секреты и реальные пользовательские данные остаются неизменными
|
||||
|
||||
#### Scenario: Изолированный пример имеет ограничение
|
||||
|
||||
- **WHEN** пример не воспроизводит некоторый аспект полного пользовательского
|
||||
сценария
|
||||
- **THEN** участник видит это ограничение и не получает заявления о проверке
|
||||
полного сценария на основании примера
|
||||
+160
@@ -0,0 +1,160 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: SDD-артефакты имеют непересекающиеся полномочия
|
||||
|
||||
Proposal SHALL выражать причину, намерение, границы и ожидаемый эффект change языком владельца и MUST NOT содержать решения по технологиям, структуре кода, файлам, API или зависимостям. Delta Specs SHALL определять только добавленное, изменённое или удалённое наблюдаемое поведение и инварианты системы без описания изменений кода. Design SHALL объяснять архитектурный способ выполнения утверждённых Specs, существенные решения, риски и альтернативы крупными частями и MUST NOT становиться построчной инструкцией реализации. Применимые UI/UX-решения и визуальные материалы SHALL входить в единый canonical Design и MUST NOT образовывать отдельный planning authority или отдельный UI/UX approval. Tasks SHALL быть implementation checklist, достаточным для выполнения Design и Specs, и MUST NOT содержать ещё не наблюдённые completion results, commit identifiers или post-archive bookkeeping. Completion Evidence SHALL фиксироваться только после фактической реализации и верификации и MUST NOT подменять planning artifact. Концептуальные материалы и Discovery SHALL оставаться входным контекстом и MUST NOT считаться утверждёнными OpenSpec artifacts.
|
||||
|
||||
#### Scenario: Product Owner формулирует Proposal
|
||||
|
||||
- **WHEN** владелец описывает требуемое изменение, не зная структуры кода и файлов
|
||||
- **THEN** Proposal остаётся полноценным утверждаемым намерением без необходимости принимать архитектурные решения
|
||||
|
||||
#### Scenario: Агент подготавливает Tasks
|
||||
|
||||
- **WHEN** Proposal, Delta Specs и Design уже утверждены
|
||||
- **THEN** Tasks перечисляет конкретные действия реализации и проверки, но не заявляет будущие результаты уже выполненными
|
||||
|
||||
#### Scenario: Владелец согласует визуальный результат
|
||||
|
||||
- **WHEN** Change Owner явно утверждает Design с применимыми визуальными материалами
|
||||
- **THEN** решение распространяется на обозначенную версию всего пакета Design
|
||||
в существующем approval gate без новой SDD-роли или отдельного UI/UX approval
|
||||
|
||||
#### Scenario: Концепт доступен до Design
|
||||
|
||||
- **WHEN** обсуждение или Discovery содержит визуальный концепт
|
||||
- **THEN** его наличие не разрешает downstream planning или реализацию и не
|
||||
заменяет явное утверждение соответствующего OpenSpec artifact
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: UI/UX-проработка Design соразмерна изменению
|
||||
|
||||
Design SHALL явно определять применимость UI/UX: новый или существенно
|
||||
изменённый интерфейс, переиспользование согласованного решения либо N/A с
|
||||
конкретной причиной отсутствия влияния на интерфейс. Для применимого scope
|
||||
Design SHALL давать Change Owner однозначное представление ожидаемого результата:
|
||||
затронутые экраны, применимые состояния, взаимодействия и адаптивное поведение.
|
||||
Ссылки на переиспользуемое решение SHALL указывать, какая его часть применима
|
||||
к change и какие различия остаются. Неизменяемые части интерфейса и N/A MUST NOT
|
||||
требовать формальных новых макетов.
|
||||
|
||||
#### Scenario: Change существенно меняет интерфейс
|
||||
|
||||
- **WHEN** Design описывает новый или существенно изменённый пользовательский
|
||||
интерфейс
|
||||
- **THEN** владелец может оценить затронутые экраны, применимые состояния,
|
||||
взаимодействия и поведение при изменении доступного пространства до реализации
|
||||
|
||||
#### Scenario: Используется согласованное решение
|
||||
|
||||
- **WHEN** change переиспользует ранее согласованное UI/UX-решение
|
||||
- **THEN** Design однозначно указывает применимое решение, область
|
||||
переиспользования и различия без обязательного повторного рисования
|
||||
|
||||
#### Scenario: Change не влияет на интерфейс
|
||||
|
||||
- **WHEN** UI/UX неприменим по конкретной причине, приведённой в Design
|
||||
- **THEN** пакет Design допускается без формального макета и дополнительных
|
||||
UI/UX approvals
|
||||
|
||||
### Requirement: Визуальный пакет Design имеет однозначную сохраняемую версию
|
||||
|
||||
Canonical Design SHALL однозначно определять состав и версию своих применимых
|
||||
визуальных материалов. Материалы SHALL оставаться доступны Change Owner,
|
||||
исполнителю и независимому reviewer при передаче между изолированными сессиями
|
||||
и после archive, без зависимости от временного контекста предыдущей сессии.
|
||||
Ссылка, содержимое которой может молча измениться, MUST NOT быть единственным
|
||||
свидетельством согласованной версии. Визуальные материалы MUST NOT создавать
|
||||
конкурирующий versioned planning root вне canonical OpenSpec authority.
|
||||
|
||||
#### Scenario: Design передаётся другому исполнителю
|
||||
|
||||
- **WHEN** новая изолированная сессия получает canonical Design
|
||||
- **THEN** она может однозначно найти полный применимый визуальный пакет и
|
||||
определить именно ту версию, на которую распространяется approval
|
||||
|
||||
#### Scenario: Визуальный источник изменился или недоступен
|
||||
|
||||
- **WHEN** текущий внешний или временный источник отличается от согласованной
|
||||
версии либо перестал открываться
|
||||
- **THEN** согласованная версия остаётся доступна из сохраняемого пакета Design
|
||||
и не заменяется молча новым содержимым
|
||||
|
||||
#### Scenario: Change архивирован
|
||||
|
||||
- **WHEN** участник обращается к Design после archive
|
||||
- **THEN** применимые визуальные материалы согласованной версии доступны вместе
|
||||
с архивным Design и сохраняют однозначную связь с ним
|
||||
|
||||
### Requirement: Соответствие визуальному Design входит в semantic verification
|
||||
|
||||
Реализация SHALL следовать утверждённому Design, включая его применимые
|
||||
визуальные материалы. Semantic verification и независимый read-only review
|
||||
SHALL сопоставлять реализованные экраны, состояния, взаимодействия и адаптивное
|
||||
поведение с этим пакетом в границах change. Наличие каталога или макета MUST NOT
|
||||
считаться approval или доказательством соответствия реализации. Несоответствие
|
||||
реализации SHALL направляться на исправление реализации; необходимость
|
||||
существенно изменить согласованный результат SHALL возвращать работу к самой
|
||||
ранней затронутой planning boundary с действующими cascade approval rules.
|
||||
|
||||
#### Scenario: Реализация расходится с согласованным интерфейсом
|
||||
|
||||
- **WHEN** реализация не соответствует однозначному применимому решению Design
|
||||
- **THEN** проверка сообщает наблюдаемое несоответствие для исправления
|
||||
реализации и не объявляет соответствие только из-за наличия макета или каталога
|
||||
|
||||
#### Scenario: Согласованное решение требует пересмотра
|
||||
|
||||
- **WHEN** выполнить UI/UX-решение без существенного изменения утверждённого
|
||||
результата невозможно либо planning artifacts противоречат друг другу
|
||||
- **THEN** workflow возвращает работу к самой ранней затронутой planning
|
||||
boundary, применяет cascade approval rules и не подгоняет Design под реализацию
|
||||
|
||||
### Requirement: Внедрение UI/UX workflow сохраняет действующие approval boundaries
|
||||
|
||||
Planning `integrate-ui-ux-design-workflow` MAY продолжаться до завершения
|
||||
`optimize-session-oriented-sdd-v2`, но внедрение процессной части MUST ожидать его
|
||||
завершения. Перед Design этого change workflow SHALL повторно сверить действующую
|
||||
canonical authority и определить применимость обновлённого процесса к активным
|
||||
changes. Обновление MUST NOT автоматически переутверждать их artifacts или
|
||||
переписывать historical archives.
|
||||
|
||||
#### Scenario: Предшествующий процессный change ещё не завершён
|
||||
|
||||
- **WHEN** `optimize-session-oriented-sdd-v2` остаётся незавершённым
|
||||
- **THEN** planning текущего change допускается в рамках явных approvals,
|
||||
а внедрение его процессной части остаётся недоступным
|
||||
|
||||
#### Scenario: Начинается Design интеграции
|
||||
|
||||
- **WHEN** Delta Specs этого change явно утверждены и начинается Design
|
||||
- **THEN** Design опирается на повторно сверенную текущую canonical authority
|
||||
и явно определяет применимость процесса к активным changes
|
||||
|
||||
#### Scenario: Обновлённый процесс поставляется
|
||||
|
||||
- **WHEN** процессные изменения становятся доступными участникам
|
||||
- **THEN** прежние approvals активных changes не считаются автоматически
|
||||
обновлёнными, а historical archives сохраняются без переписывания
|
||||
|
||||
### Requirement: Готовность к пилоту отделена от доказанной успешности workflow
|
||||
|
||||
Поставка каталога и обновлённого процесса SHALL позволять использовать их
|
||||
совместно в последующем небольшом UI change с собственными planning approvals.
|
||||
Текущий change MUST NOT включать неявную продуктовую фичу в качестве пилота или
|
||||
заявлять успешность сквозного workflow до его фактического прохождения.
|
||||
|
||||
#### Scenario: Текущая поставка завершена
|
||||
|
||||
- **WHEN** каталог и обновлённый процесс готовы к совместному использованию,
|
||||
но последующий UI change ещё не прошёл workflow
|
||||
- **THEN** результат описывается как готовность к пилоту без заявления об
|
||||
успешном сквозном пилоте
|
||||
|
||||
#### Scenario: Начинается пилотный UI change
|
||||
|
||||
- **WHEN** владелец выбирает небольшой UI change для совместного использования
|
||||
каталога и процесса
|
||||
- **THEN** этот change проходит собственные planning approvals, а вывод о
|
||||
сквозной успешности опирается только на его фактически наблюдаемый результат
|
||||
@@ -0,0 +1,106 @@
|
||||
## 1. Подготовка в границах Design
|
||||
|
||||
- [x] 1.1 [workspace] Проверить совместимость выбранного Storybook с текущими React/Vite/Node и существующими владельцами UI перед заменой catalog tooling.
|
||||
- **Covers:** `N/A` — проверка Solution Assessment и архитектурных предпосылок для разрешённой замены tooling и состава витрины.
|
||||
- **Verification:** Сверить published peer ranges, installed versions и ответственные presentation components; выполнить интеграционную сборку на текущем stack, сохраняя OpenSpec/Git/Markdown для процессной части.
|
||||
|
||||
## 2. Storybook реальных компонентов WealthLedger
|
||||
|
||||
Группа независима от завершения процессной зависимости. Реализация следует
|
||||
UI/UX package revision 2; прежние checkbox не переносятся на изменённые действия.
|
||||
|
||||
- [x] 2.1 [frontend] Установить Storybook React/Vite и Docs с точными версиями, общим preview decorator и отдельными dev/static entrypoints; удалить custom catalog shell и его ненужную конфигурацию.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** Проверить общий lockfile, app theme/CSS/i18n/light scheme, выключенную telemetry, штатные Controls/Docs/Actions и отсутствие старого HTML/shell/demo-кода и stories в продуктовой сборке.
|
||||
- [x] 2.2 [frontend] Добавить colocated stories BrokerageAccountList и PositionCard с состояниями и synthetic props из Design revision 2.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** Сверить available/unavailable/empty summary и длинное имя счёта; stocks gain/bonds loss/other/missing valuation позиции. Использовать реальные view без VM/API, MemoryRouter при необходимости и null logos.
|
||||
- [x] 2.3 [frontend] Добавить stories RecentEvents и композиции PortfolioRefreshState с PortfolioTotals.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** Сверить loaded/loading/error/empty/missing amount событий, idle/refetch/error сохранённых сумм, локальный retry и отсутствие исчезновения данных при обновлении; не заявлять выполнение query lifecycle.
|
||||
- [x] 2.4 [frontend] Добавить stories StateView и реального AccountPageLoading, описания назначения и ограничений всех шести групп.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** Проверить empty/error с действием и без него, реальную page-owned skeleton structure, alert/busy semantics, доступность и отсутствие обязательных Mantine primitive demos или wrappers ради каталога.
|
||||
- [x] 2.5 [frontend] Проверить безопасные story props/callbacks и адаптировать dependency-cruiser к runtime graph Storybook без ослабления FSD.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** На существующем test stack проверить реальные stories/их callbacks без application network и доступа к данным пользователя; controlled runtime API import должен отклоняться, type-only references допускаются. Не тестировать собственным кодом внутренности Storybook/Mantine.
|
||||
- [x] 2.6 [frontend] Включить Storybook config и stories в TypeScript, lint, Knip, dependency checks и static build canonical verify.
|
||||
- **Covers:** `N/A` — интеграция tooling в существующий frontend gate по Delivery Map без нового продуктового поведения.
|
||||
- **Verification:** Проверить entry discovery и обе сборки; ограничить export exceptions требуемыми Storybook default meta/config exports и прямыми CSF exports историй. Declarative CSF/config не требуют искусственного unit coverage; production coverage floors и полный type/lint/dependency scope сохраняются.
|
||||
- [x] 2.7 [frontend] Проверить Storybook dev и static build в браузере по таблице и UI/UX package revision 2.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** Просмотреть все stories и Docs, Controls/reset/remount, actions и keyboard; проверить preview на 320/768/1280 CSS px без overflow и сохранение args при resize. Проверить отсутствие application API/external data requests, корректные локальные ссылки и эквивалентность dev/static preview.
|
||||
|
||||
## 3. Обязательная граница перед процессной частью
|
||||
|
||||
Группы 4 и процессная часть группы 5 недоступны до выполнения 3.1 и 3.2.
|
||||
Если prerequisite не выполнен, зависимая работа остаётся заблокированной;
|
||||
наличие checklist не разрешает изменение upstream artifacts или чужих state.
|
||||
|
||||
- [x] 3.1 [workspace] Подтвердить фактическое завершение optimize-session-oriented-sdd-v2 и перечитать поставленные canonical authority, schema и session routing перед процессной реализацией.
|
||||
- **Covers:** `N/A` — это orchestration зависимости из Migration Plan Design, а не реализация repository-owned поведения; без неё нельзя определить действующую baseline процессного расширения.
|
||||
- **Verification:** Найти canonical archive и фактическое completion evidence зависимости с подтверждением поставки; native planning complete/isComplete и наличие planning files не считать завершением. При отсутствии подтверждения оставить процессную часть заблокированной и не менять dependency artifacts/state.
|
||||
- [x] 3.2 [workspace] Сопоставить текущие Delta Specs и Design с поставленной authority зависимости, особенно два пересекающихся MODIFIED requirements, и определить допустимость продолжения.
|
||||
- **Covers:** `N/A` — reconciliation проверяет совместимость уже утверждённого scope с baseline перед delivery, не создавая новое поведение или самостоятельный planning authority.
|
||||
- **Verification:** Сопоставить `Продолжение workflow восстанавливает только нужный контекст` и `Validation остаётся независимой и без побочных исправлений` со всеми поставленными invariants/scenarios и проверить остальные затронутые rules. Не применять MODIFIED blocks как безусловную замену: изменение Requirement/Scenario возвращает к Delta Specs и reapproval зависимых Design/Tasks; изменение intent — к Proposal, архитектуры — к Design. До разрешения несовместимости процессная реализация закрыта; автоматический merge при archive не заменяет reconciliation.
|
||||
|
||||
## 4. Расширение существующего процессного contract
|
||||
|
||||
После успешного reconciliation использовать поставленных владельцев и их
|
||||
approval/input binding. Не переносить заранее planned predecessor rules и
|
||||
не дублировать его bounded outcomes, verification ownership или evidence model.
|
||||
|
||||
- [x] 4.1 [specs] Расширить существующие Design template и instructions project-local schema применимостью UI/UX и составом единого переносимого визуального пакета.
|
||||
- **Covers:** `openspec-authority-and-lifecycle` — `SDD-артефакты имеют непересекающиеся полномочия`; `openspec-authority-and-lifecycle` — `UI/UX-проработка Design соразмерна изменению`; `openspec-authority-and-lifecycle` — `Визуальный пакет Design имеет однозначную сохраняемую версию`; `agent-sdd-session-workflow` — `Продолжение workflow восстанавливает только нужный контекст`
|
||||
- **Verification:** Получить native Design instructions из canonical store и проверить new/changed, reuse и обоснованный N/A, экраны/состояния/interactions/responsive scope, идентичность и отличия reuse, revision и перечень материалов. Для необходимых PNG/SVG exports проверить относительные пути внутри change `visuals/` и SHA-256, самодостаточность SVG; для встроенного Markdown не вводить self-hash, отдельный authority, роль или UI/UX approval.
|
||||
- [x] 4.2 [specs] Расширить применимые native phase instructions существующей schema чтением согласованного Design package, feedback routing, semantic verification и сохранностью материалов при archive.
|
||||
- **Covers:** `openspec-authority-and-lifecycle` — `Визуальный пакет Design имеет однозначную сохраняемую версию`; `openspec-authority-and-lifecycle` — `Соответствие визуальному Design входит в semantic verification`; `agent-sdd-session-workflow` — `Продолжение workflow восстанавливает только нужный контекст`; `agent-sdd-session-workflow` — `Validation остаётся независимой и без побочных исправлений`
|
||||
- **Verification:** Проверить native context routing к Design и от него к перечисленным материалам, блокировку зависимой работы при missing/ambiguous package или digest mismatch, feedback для implementation mismatch и SPEC_ISSUE без редактирования пакета Validation; проверить инструкции сохранения относительной структуры и identity при archive. Использовать штатные файловые операции и SHA-256 без нового parser/registry или заявления, что native structural validation проверяет произвольные attachments и визуальное качество.
|
||||
- [x] 4.3 [docs] Обновить governance и lifecycle фактически внедрённым единым UI/UX contract, правилами переносимости и применимости процесса к активным changes.
|
||||
- **Covers:** `openspec-authority-and-lifecycle` — `SDD-артефакты имеют непересекающиеся полномочия`; `openspec-authority-and-lifecycle` — `UI/UX-проработка Design соразмерна изменению`; `openspec-authority-and-lifecycle` — `Визуальный пакет Design имеет однозначную сохраняемую версию`; `openspec-authority-and-lifecycle` — `Соответствие визуальному Design входит в semantic verification`; `openspec-authority-and-lifecycle` — `Внедрение UI/UX workflow сохраняет действующие approval boundaries`
|
||||
- **Verification:** Сверить as-built policy с поставленной schema: approval всего Design, сохранённые переносимые материалы вместо external-only URL, cascade при смысловом изменении, независимый read-only review и проверка сохранности при archive. Проверить применение к новым changes и неутверждённому Design; уже утверждённый Design и changes в Implementation/Validation не получают автоматический retrofit/PASS, owner-requested migration возвращается к нужной boundary; legacy scope, чужие state и historical archives не переписываются.
|
||||
- [x] 4.4 [workspace] Адаптировать локальные session skills/entrypoints как non-authority orchestration к поставленному contract визуального пакета.
|
||||
- **Covers:** `N/A` — локальные adapters маршрутизируют чтение и verification versioned specs/docs authority; их адаптация предусмотрена Design и не подменяет repository-owned процессную реализацию или canonical gate.
|
||||
- **Verification:** Проверить Specification, Implementation, Validation и archive routing: применимые материалы читаются через canonical Design, существующий approval/input binding охватывает перечисленные attachments без параллельной state model, handoff не копирует пакет, одна роль сессии сохраняется. Missing material/digest mismatch блокирует зависимую работу; visual mismatch даёт исправление реализации, противоречие пакета — возврат к самой ранней planning boundary; не мигрировать state чужих changes.
|
||||
- [x] 4.5 [workspace] Проверить передачу, целостность и routing визуального пакета на временных невёрсионируемых примерах без изменения активных changes или archives.
|
||||
- **Covers:** `N/A` — межобластная проверка обеспечивает согласованность schema, policy и локальных adapters по Design; она не реализует новое поведение и не заменяет их canonical gates.
|
||||
- **Verification:** Проверить inline-only пакет, пакет с локальными exports, точный immutable reuse и обоснованный N/A; воспроизвести чтение из новой изолированной сессии и перенос структуры Design/visuals, сверить доступность и SHA-256 после переноса. Контролируемые missing file, изменённые bytes и external-only source должны приводить к конкретному блокеру; visual mismatch и противоречие Specs — к разным предусмотренным outcomes без side edits. Изменение revision/digest само по себе не подтверждает approval; существенная смена материала требует соответствующей boundary. Не объявлять эти проверки продуктовым пилотом или новым hard guardrail.
|
||||
|
||||
## 5. As-built документация и готовность к последующему пилоту
|
||||
|
||||
- [x] 5.1 [docs] Описать фактически доступные запуск и сборку каталога, начальный набор, общую визуальную основу, доступность, ограничения и сопровождение примеров; добавить применимые routing/index links.
|
||||
- **Covers:** `frontend-ui-catalog` — `Каталог предоставляет определённый набор реальных компонентов`; `frontend-ui-catalog` — `Примеры воспроизводят состояния и взаимодействия изолированно`; `frontend-ui-catalog` — `Каталог сохраняет достоверность и границы демонстрации`
|
||||
- **Verification:** После группы 2 сверить команды с поставленными frontend scripts и шесть групп Storybook с реальными view и их историями; явно описать, что отсутствие компонента не запрещает его использование, synthetic interactions не доказывают полный journey, а изменения включённых компонентов проверяются вместе с их примерами. Scoped review проверяет локальные ссылки и направление к действующему UI Pattern для query/refetch/loading semantics без копирования canonical planning artifacts.
|
||||
- [x] 5.2 [docs] Описать совместное использование поставленных каталога и UI/UX workflow как готовность к отдельному небольшому UI change с собственными approvals.
|
||||
- **Covers:** `openspec-authority-and-lifecycle` — `Готовность к пилоту отделена от доказанной успешности workflow`
|
||||
- **Verification:** После групп 2–4 проверить доступный участнику путь от просмотра компонента к применимому Design package и отдельным planning approvals; текст не включает неявную продуктовую фичу, не назначает пилот без владельца и не заявляет сквозную успешность до фактического прохождения последующего change.
|
||||
|
||||
## 6. Проверки завершённой реализации по affected areas
|
||||
|
||||
Выполнять после соответствующей реализации и исправлений под Node 22,
|
||||
активируя repository `.nvmrc` через `nvm use --silent`; если у specs нет
|
||||
`.nvmrc`, выбрать Node через существующую frontend `.nvmrc` до перехода в specs.
|
||||
Каждый canonical gate выполнить один раз на готовом состоянии; повторять
|
||||
только после новых изменений, failure или нерешённой проблемы. Эта группа
|
||||
планирует проверки и не утверждает их результаты или approval.
|
||||
|
||||
- [x] 6.1 [frontend] Выполнить canonical frontend gate с каталогом, тестами и обеими сборками в его scope.
|
||||
- **Covers:** `N/A` — gate подтверждает frontend Delivery Map после реализации каталога и не добавляет отдельное observable behavior.
|
||||
- **Verification:** Из `frontend` после `nvm use --silent` выполнить `npm ci`, затем `npm run verify`; сохранить фактические команды, exit status и relevant diagnostics, не подменять gate отдельной успешной сборкой каталога.
|
||||
- [x] 6.2 [specs] Выполнить native structural checks project-local schema, completed change и main specs из canonical store.
|
||||
- **Covers:** `N/A` — обязательный specs gate проверяет форму versioned SDD delivery после reconciliation и процессного расширения; он не доказывает semantic соответствие или owner approval.
|
||||
- **Verification:** Под выбранным Node 22 из `specs` выполнить `openspec schema validate wealth-ledger-sdd --verbose`, `openspec validate integrate-ui-ux-design-workflow --type change --strict --store wealth-ledger-specs` и `openspec validate --specs --strict --store wealth-ledger-specs`; сопоставить наблюдённые результаты с фактически поставленной authority, не синхронизировать пересекающиеся deltas в обход 3.2.
|
||||
- [x] 6.3 [docs] Выполнить canonical docs gate для фактической документации каталога и процесса.
|
||||
- **Covers:** `N/A` — docs gate подтверждает качество as-built delivery из групп 4–5; это verification существующего документационного результата, а не самостоятельное поведение.
|
||||
- **Verification:** Из `docs` после `nvm use --silent` выполнить `npm ci`, затем `npm run verify`; дополнить результат scoped review локальных ссылок изменённых документов по docs AGENTS.md.
|
||||
## 7. Независимая Validation
|
||||
|
||||
После implementation-owned Tasks отдельный read-only reviewer сопоставляет все
|
||||
Delta Requirements/Scenarios с реализацией, UI/UX package revision 2 и текущей
|
||||
поставленной baseline. Проверка охватывает состояния, interactions, responsive
|
||||
поведение, dependency reconciliation, сохранность пакета, approval boundaries
|
||||
и границу готовности к пилоту. Актуальные gate outcomes используются с input
|
||||
binding. Результат PASS/FAIL/SPEC_ISSUE не является implementation checkbox;
|
||||
reviewer не меняет production code, specifications или Tasks. Critical/Important
|
||||
finding, failed gate либо недоказанное соответствие блокируют завершение.
|
||||
Backend и runtime-openapi остаются N/A по причинам Design.
|
||||
Reference in New Issue
Block a user