specs/openspec/changes/integrate-ui-ux-design-workflow/tasks.md

1. Подготовка в границах Design

• 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 не переносятся на изменённые действия.

• 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 в продуктовой сборке.
• 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.
• 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.
• 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 ради каталога.
• 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.
• 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 сохраняются.
• 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.

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

• 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.
• 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 и визуальное качество.
• 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 не переписываются.
• 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.
• 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 документация и готовность к последующему пилоту

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

• 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 отдельной успешной сборкой каталога.
• 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.
• 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.