## 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.