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.
2026-09-07 22:53:02 +03:00
parent c6dc20b153
commit 0e4c491765
11 changed files with 944 additions and 1 deletions
@@ -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"
 }
 ```
@@ -65,6 +65,14 @@ 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
@@ -91,6 +99,26 @@ artifacts MUST быть источником intent, requirements, design и tas
 - **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: Handoff не заменяет canonical OpenSpec authority
 Workflow handoff SHALL сохранять только состояние перехода, краткий observed
@@ -137,6 +165,11 @@ PASS, FAIL либо SPEC_ISSUE с маршрутизацией к Finalization,
 самой ранней затронутой 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,
@@ -163,6 +196,20 @@ review MUST NOT оставаться unchecked implementation Tasks.
 - **THEN** завершение Implementation не зависит от checkbox, который может
  закрыть только Validation
 #### Scenario: Найдено визуальное несоответствие
 - **WHEN** наблюдаемая реализация расходится с однозначным применимым решением
  согласованного визуального пакета
 - **THEN** Validation возвращает FAIL с конкретным несоответствием и не
  исправляет интерфейс или визуальный пакет в этой сессии
 #### Scenario: Визуальный пакет противоречит другим planning artifacts
 - **WHEN** Validation обнаруживает противоречие согласованного визуального
  результата требованиям либо неоднозначность самого Design
 - **THEN** она возвращает SPEC_ISSUE с основанием возврата к самой ранней
  затронутой planning boundary, не выбирая новую трактовку самостоятельно
 ### Requirement: Finalization требует успешной независимой Validation
 Workflow SHALL разрешать Finalization только после последней независимой
@@ -0,0 +1,95 @@
 # frontend-ui-catalog Specification
 ## Purpose
 Предоставляет участникам разработки воспроизводимый обзор ограниченного набора
 реальных UI-компонентов и композиций WealthLedger для выбора решений на
 общей визуальной основе приложения.
 ## 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** участник видит это ограничение и не получает заявления о проверке
  полного сценария на основании примера
@@ -7,7 +7,7 @@
 ### Requirement: SDD-артефакты имеют непересекающиеся полномочия
-Proposal SHALL выражать причину, намерение, границы и ожидаемый эффект change языком владельца и MUST NOT содержать решения по технологиям, структуре кода, файлам, API или зависимостям. Delta Specs SHALL определять только добавленное, изменённое или удалённое наблюдаемое поведение и инварианты системы без описания изменений кода. Design SHALL объяснять архитектурный способ выполнения утверждённых Specs, существенные решения, риски и альтернативы крупными частями и MUST NOT становиться построчной инструкцией реализации. Tasks SHALL быть implementation checklist, достаточным для выполнения Design и Specs, и MUST NOT содержать ещё не наблюдённые completion results, commit identifiers или post-archive bookkeeping. Completion Evidence SHALL фиксироваться только после фактической реализации и верификации и MUST NOT подменять planning artifact.
+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
@@ -19,6 +19,18 @@ Proposal SHALL выражать причину, намерение, границ
 - **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
 ### Requirement: Artifact graph применяет последовательные approval gates
 Versioned SDD change SHALL проходить последовательность `Proposal → Delta Specs → Design → Tasks → Apply`. AI-агент MAY подготовить черновик текущего разрешённого артефакта, но MUST NOT считать его утверждённым самостоятельно или создавать downstream artifact до явного решения Change Owner. Для change, определяющего продуктовое поведение, Change Owner SHALL быть Product Owner; для технического или процессного change — Engineering Owner. Каждый из четырёх planning artifacts MUST существовать и быть утверждён до Apply.
@@ -281,3 +293,134 @@ approval, workflow MUST повторно запросить решение Chang
 - **WHEN** Apply завершил заявленную работу и change передаётся в свежий verification/review context
 - **THEN** handoff сохраняет approved artifacts, affected areas, фактический implementation scope и unresolved blockers, а reviewer получает необходимый diff и evidence без полной implementation history
 ### 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, а вывод о
  сквозной успешности опирается только на его фактически наблюдаемый результат