Files
specs/openspec/changes/archive/2026-10-17-quiet-user-feedback/tasks.md
T
ksv741 c5ec117328
Conventional commits / commits (pull_request) Successful in 11s
Specs security / security (pull_request) Successful in 8s
Specs verify / verify (pull_request) Successful in 10s
spec: archive quiet-user-feedback and sync canonical specs (#50)
Native archive применил 9 added и 12 modified требований без удалений.
Все 10 сценариев, которые удалили бы исходные MODIFIED-блоки, сохранены.
Новый canonical spec frontend-user-feedback внесён в AI_INDEX.

Completion Evidence фиксирует расхождение отметок задач 8.1-8.4 с фактом
и его устранение в WealthLedger/docs#51.
2026-10-17 22:16:29 +03:00

34 KiB
Raw Blame History

Implementation tasks

Основание: согласованные Delta Specs и Design, включая inline UI/UX package quiet-user-feedback-ui-v1 и Solution Assessment.

Задачи выполняются по порядку групп и пунктов. Каждая задача имеет одного владельца репозитория; технические проверки выполняет implementer. Проверки сети используют synthetic fixtures и существующий MSW, а не реальный T-Bank. Перед Node-командами в каждом репозитории выполняется nvm use --silent. Указанные ниже проверки — план, а не свидетельство выполненной реализации.

Перед изменениями сохраняются чужие staged/unstaged/new files, в частности перенос PortfolioStructure. База требований сверяется по Migration Plan Design: изменение порядка интеграции persist-tbank-data требует согласования затронутых artifacts, а не молчаливого перезаписывания active change. Recovery и удаление ручных controls поставляются вместе. Backend и workspace не получают implementation tasks: они не входят в affected Delivery Map.

1. Принятые решения и зависимости

  • 1.1 [frontend] Применить Solution Assessment: оставить TanStack Query и существующих resource/screen owners, добавить exact @mantine/notifications@9.6.1 с согласованным lockfile без второго query runtime или toast framework.
    • Covers: N/A — dependency preparation не вводит отдельного пользовательского поведения; реализует выбранные средства из Design §1 и §6 до custom recovery work.
    • Verification: npm ci; npm ls @mantine/core @mantine/hooks @mantine/notifications react react-dom; сверить exact versions, peer compatibility и отсутствие посторонних dependency changes.

2. Ограниченное восстановление чтения

  • 2.1 [frontend] В существующем shared/api реализовать классификацию временных GET failures, 15-секундный deadline с отменой чтения тела и до двух повторов с паузами 1/2 секунды; исключить auth endpoints, mutations, access/domain errors и отмену.

    • Covers: frontend-data-resilience — Временные сбои чтения восстанавливаются автоматически; frontend-user-feedback — Ошибки действий и препятствия доступа остаются понятными.
    • Verification: MSW-проверки через public client/query interface: recovery после network/timeout/503, конечное число запросов, прерванное чтение тела, отсутствие retries для 401/403/404/409 и malformed result, поведение 429 и серверной отсрочки по Design; npm run test:run -- src/shared/api.
  • 2.2 [frontend] Подключить read policy к authenticated query hooks и useResourceQuery, сохранив одну generated cache identity, независимые ordinary/observe режимы и существующие session/access fences; убрать локальные запреты retry только там, где они заменяются принятой политикой.

    • Covers: frontend-data-resilience — Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio; frontend-data-resilience — Временные сбои чтения восстанавливаются автоматически.
    • Verification: Расширить resource lifecycle MSW-сценарии: cached snapshot при ошибке, data: null при HTTP success, ordinary GET после observe, unmount/cancel и late response после logout/connection replacement; npm run test:run -- src/shared/api src/features/tbank-connection/model/connection-boundary.
  • 2.3 [frontend] Перевести useScreenSync на ограниченное восстановление failed/cancelled missing/stale источников обычным GET: две дополнительные source attempts с паузами 5/15 секунд, бюджет на текущую выборку и отсутствие автоматического force POST.

    • Covers: frontend-data-resilience — Временные сбои чтения восстанавливаются автоматически; frontend-data-resilience — Неполный результат не выдаётся за окончательный.
    • Verification: MSW + управляемое время: failed source при HTTP 200, новая work ID без сброса бюджета, исчерпание серии, fresh complete после неудачного force, permanent unavailableReason; проверить число ordinary GET и отсутствие POST /api/v1/tbank-sync; npm run test:run -- src/features/tbank-connection/model.
  • 2.4 [frontend] Согласовать status observation и заключительное observe-чтение с in-flight запросами, сохранив интервал 1 секунда только для running work; различить status ID not found и подтверждённый отказ доступа к ресурсу.

    • Covers: frontend-data-resilience — Временные сбои чтения восстанавливаются автоматически; frontend-data-resilience — Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio.
    • Verification: MSW-сценарии: медленное observe не отменяется каждым tick, terminal status не теряет заключительное чтение, HTTP/status failure не запускает force sync, 404 work ID перечитывает ресурс, access loss очищает личный snapshot; npm run test:run -- src/features/tbank-connection/model/screen-sync.test.tsx src/shared/api/resource-query.test.tsx.
  • 2.5 [frontend] Подключить единый lifecycle recovery на focus/reconnect и смену выборки: обычные reads используют штатную Query policy, инвестиционные — screen owner; отменять неактуальные timers и не дублировать восстановление при совпадении событий.

    • Covers: frontend-data-resilience — Временные сбои чтения восстанавливаются автоматически; frontend-data-resilience — Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio.
    • Verification: Через Query focus/online managers и MSW проверить fresh/stale/missing results, offline/hidden pause, одновременный reconnect/focus, повторное открытие, переход на другой счёт/период и уход последнего consumer; npm run test:run -- src/shared/api src/features/tbank-connection/model.

3. Состояния ожидания и доступного результата

  • 3.1 [frontend] Реализовать общую presentation-only модель ограниченного первичного ожидания в shared/lib: 10-секундный budget, устойчивый unavailable latch для identity области и автоматический переход к результату; применить её к существующим loading/state presentation без второго кэша.

    • Covers: frontend-loading-presentation — Первичное ожидание не становится бесконечной загрузкой; frontend-loading-presentation — Контекстная индикация действий и фонового обновления.
    • Verification: Минимальная runnable проверка собственного state transition: skeleton → timeout/error unavailable → loaded, отсутствие мигания при retry, сброс только при новой выборке, cleanup и доступное busy-состояние; npm run test:run -- src/shared/lib и npm run typecheck.
  • 3.2 [frontend] В общих investment section models разделить readiness, полноту и access failure: успешные пустые данные не теряются, missing/partial не становятся нулевым итогом, а технические metadata остаются у владельца данных.

    • Covers: frontend-data-resilience — Неполный результат не выдаётся за окончательный; frontend-ui-resilience — Ожидаемые finance states не становятся route failures.
    • Verification: Проверки через потребляющие views: null против полного [], partial rows против полного empty, недоступный total/comparison, independent ready section и access failure при cached content; npm run test:run -- src/features/instrument-details src/pages/account-income.

4. Инвестиционные экраны без технических controls

  • 4.1 [frontend] Перевести Accounts и AccountPage, включая «Все счета», на новые состояния: убрать даты получения, refresh/retry и технические предупреждения, сохранить валютные итоги, доступные snapshots, контекст и предметную навигацию.

    • Covers: brokerage-accounts — Экран списка брокерских счетов; brokerage-accounts — Клиентские состояния ошибки списка счетов; portfolio-view — Состояния и ошибки Portfolio на клиенте; frontend-data-resilience — Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio; frontend-ui-resilience — Ожидаемые finance states не становятся route failures.
    • Verification: RTL/MSW: initial/loaded/empty/partial/unavailable, quiet refetch failure, сохранение раскрытий и focus, отсутствие вымышленных нулей, 404 и invalid token скрывают снимок; npm run test:run -- src/pages/accounts src/pages/account src/app/routes/AppRoutes/AllAccounts.test.tsx.
  • 4.2 [frontend] Перевести полный журнал и recent operations на локальное тихое восстановление; сохранить применённые фильтры, cursor navigation, даты и смысл строк, не подменять новую страницу прежней.

    • Covers: brokerage-account-ledger — Account overview includes recent ledger events; brokerage-account-ledger — Журнал восстанавливает чтение без ручного обновления.
    • Verification: RTL/MSW: background failure с прежними записями, missing новой страницы, отсутствие false empty и retry, локальный сбой preview не скрывает Portfolio; npm run test:run -- src/pages/account-operations src/pages/account.
  • 4.3 [frontend] Перевести страницу будущих событий и preview на сохранение доступного результата и нейтральную локальную недоступность; убрать технические статусы, сохранив даты и ограничения финансового прогноза.

    • Covers: brokerage-account-upcoming-events — Account page presents an upcoming events list; brokerage-account-upcoming-events — Account overview includes upcoming events.
    • Verification: RTL/MSW: cached events при временной ошибке, неизвестный результат против полного empty, offer без суммы, потеря доступа и независимость preview; npm run test:run -- src/pages/account-events src/entities/brokerage-event src/pages/account.
  • 4.4 [frontend] Перевести доход и current-month summary на тихое обновление; оставить независимые готовые результаты, недоступные comparisons без нулевой базы и неизменный пользовательский черновик периода.

    • Covers: brokerage-account-income-analytics — Realized analytics never presents an incomplete result as complete; brokerage-account-income-analytics — Account overview has an independent current-month income summary; brokerage-account-income-analytics — Доход обновляется без технических сообщений; frontend-data-resilience — Неполный результат не выдаётся за окончательный.
    • Verification: RTL/MSW: полный старый результат при временном сбое, missing/partial текущего периода, готовый доход с недоступным сравнением, смена периода без переименования прежних сумм, сохранение черновика; npm run test:run -- src/pages/account-income src/pages/account.
  • 4.5 [frontend] Убрать refresh/retry из поиска акций и облигаций, связав VM с автоматическим recovery и ожиданием текущего debounced query; сохранить фильтры и отсутствие подмены результата прежним запросом.

    • Covers: frontend-user-feedback — Чтение данных не требует внимания к техническим состояниям; frontend-loading-presentation — Первичное ожидание не становится бесконечной загрузкой.
    • Verification: RTL/MSW: смена query во время запроса, delayed/failed поиск с последующим восстановлением, отсутствие false no-results и технических controls; npm run test:run -- src/features/instrument-search src/pages/stocks src/pages/bonds.
  • 4.6 [frontend] Перевести детали акции/облигации и их секции на readiness текущей выборки: график, личные позиции, история, сведения и выплаты сохраняют доступное содержимое без технических дат и действий.

    • Covers: frontend-user-feedback — Чтение данных не требует внимания к техническим состояниям; frontend-data-resilience — Неполный результат не выдаётся за окончательный; frontend-ui-resilience — Ожидаемые finance states не становятся route failures.
    • Verification: RTL/MSW: independent sections, новый диапазон свечей и instrument ID не показывают прежний результат как новый, partial history не является полной; npm run test:run -- src/features/instrument-details src/pages/stock src/pages/bond.

5. Карты, формы и настройки подключения

  • 5.1 [frontend] Перевести CardsPage, CardPage и BankSummary на тихое чтение, ограниченное ожидание и сохранение текущей выборки; удалить placeholder прежней страницы при переходе к другой странице банковских операций.

    • Covers: frontend-user-feedback — Чтение данных не требует внимания к техническим состояниям; frontend-data-resilience — Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio; frontend-loading-presentation — Первичное ожидание не становится бесконечной загрузкой.
    • Verification: RTL/MSW: карты/summary/history при refetch failure, page и период меняются без подмены данных, полный empty отличается от missing, формы не размонтируются из-за фоновой ошибки; npm run test:run -- src/pages/cards src/pages/card/ui/CardPage src/entities/bank-card/api.
  • 5.2 [frontend] Сохранить ввод и предметные действия BankCardForm и CategoryManager, заменив техническое перечитывание автоматической загрузкой; актуальную версию после конфликта принимать только явно, не повторяя запись.

    • Covers: frontend-user-feedback — Ошибки действий и препятствия доступа остаются понятными; frontend-loading-presentation — Контекстная индикация действий и фонового обновления.
    • Verification: RTL/MSW: field errors, сохранённый ввод при network failure, version conflict → автоматическое чтение → явное принятие версии, доступная отмена при unavailable, отсутствие второго mutation request; npm run test:run -- src/entities/bank-card/ui.
  • 5.3 [frontend] Перевести чтение категорий, исходной покупки и версий OperationForm/DeleteOperation на автоматическое восстановление; сохранить intent ID, refund constraints, явное подтверждение версии и недопущение повторной финансовой записи.

    • Covers: frontend-user-feedback — Ошибки действий и препятствия доступа остаются понятными; frontend-loading-presentation — Контекстная индикация действий и фонового обновления.
    • Verification: RTL/MSW: сбой зависимого GET без потери ввода, отсутствие ложного empty для расходов, конфликт удаления/правки, network loss после submit без auto-resubmit, сохранность version/intent при ручной повторной отправке; npm run test:run -- src/pages/card/ui/OperationForm src/pages/card/ui/DeleteOperation src/entities/bank-card/api/banking.test.tsx.
  • 5.4 [frontend] Перевести чтение T-Bank connection status на тихое восстановление: не показывать форму до первого известного статуса, сохранять уже открытую секцию и token при временном GET failure, оставить явные локальные ошибки mutations.

    • Covers: tbank-connection — Управление подключением в настройках; frontend-user-feedback — Ошибки действий и препятствия доступа остаются понятными; frontend-ui-resilience — Ожидаемые finance states не становятся route failures.
    • Verification: RTL/MSW: initial unavailable → loaded, сохранность ввода при фоновом сбое, single mutation на submit/delete, ошибки token и удаления, новая cache boundary только после успешной mutation; npm run test:run -- src/features/tbank-connection.

6. Редкие подтверждения действий

  • 6.1 [frontend] Подключить один Mantine Notifications host с общей темой, styles и i18n: limit 2, autoClose 4000 ms, desktop/mobile positions, доступное закрытие, reduced motion и очистка очереди при смене/завершении сессии.

    • Covers: frontend-user-feedback — Уведомления не мешают работе и не дублируются.
    • Verification: Проверить application-owned cleanup при logout/смене сессии через RTL; выполнить npm run typecheck; конфигурацию third-party limit/timer не дублировать unit-тестами библиотеки, доступность и размещение проверить в задаче 7.3.
  • 6.2 [frontend] В action VMs карт, операций и категорий отделить успех записи от последующего чтения и реализовать однократное подтверждение по таблице Design: видимый результат без toast, неочевидный — краткое сообщение с action ID и ограниченным ожиданием подтверждения.

    • Covers: frontend-user-feedback — Краткое уведомление подтверждает неочевидный результат действия; frontend-user-feedback — Уведомления не мешают работе и не дублируются; frontend-user-feedback — Ошибки действий и препятствия доступа остаются понятными.
    • Verification: RTL/MSW: сохранённая запись внутри/вне видимой выборки, удаление видимой/невидимой записи, успешная запись с неуспешным GET, 10-секундный предел подтверждения, повторный callback того же action ID и отдельное следующее действие; npm run test:run -- src/entities/bank-card/ui src/pages/card src/pages/cards.
  • 6.3 [frontend] В VM подключения добавить одно подтверждение успешной замены token при неизменном видимом статусе; создание/удаление с очевидным изменением статуса и все фоновые чтения оставить без toast.

    • Covers: tbank-connection — Управление подключением в настройках; frontend-user-feedback — Краткое уведомление подтверждает неочевидный результат действия; frontend-user-feedback — Чтение данных не требует внимания к техническим состояниям.
    • Verification: RTL/MSW: create/delete без дублирующего подтверждения, replace с единственным toast, failure без success, background recovery без notifications, сообщение без token; npm run test:run -- src/features/tbank-connection/ui.

7. Завершение frontend и UI-проверки

  • 7.1 [frontend] После миграции consumers удалить InvestmentRefreshState, SourceSyncStatus, неиспользуемые props/exports/строки и их устаревшие stories; проверить оставшиеся технические actions во всём scope без удаления предметных form/access controls.

    • Covers: frontend-user-feedback — Чтение данных не требует внимания к техническим состояниям; frontend-loading-presentation — Контекстная индикация действий и фонового обновления.
    • Verification: Проверить callers и i18n keys, отсутствие видимых/иконных/tooltip/live-region замен удалённых статусов; npm run knip; npm run deps; npm run test:run -- src/test/storybook.test.tsx; убедиться, что внутренние metadata и серверный контракт не удалены.
  • 7.2 [frontend] Обновить UI/data/testing conventions и значимые presentation stories под UI package v1: тихий loaded, нейтральный unavailable, partial без ложного итога и редкое подтверждение; сохранить изоляцию Storybook от application API/auth/query.

    • Covers: N/A — conventions и каталог закрепляют уже утверждённую архитектуру и UI-пакет, не вводя отдельного поведения; необходимы для согласованной frontend delivery из Design.
    • Verification: Сверить локальные инструкции с новыми retry/focus policies, примеры и ссылки; npm run deps:storybook; npm run build:catalog; проверить достижимость stories и отсутствие устаревшего обещания ручного retry.
  • 7.3 [frontend] Выполнить implementation-owned browser review состояний и interactions UI package v1 на 320, 768 и 1440 px: страницы чтения, partial/unavailable, формы, notification host и восстановление контекста.

    • Covers: frontend-user-feedback — Уведомления не мешают работе и не дублируются; frontend-user-feedback — Чтение данных не требует внимания к техническим состояниям; frontend-loading-presentation — Первичное ожидание не становится бесконечной загрузкой; frontend-data-resilience — Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio.
    • Verification: В браузере проверить Tab/focus, modal trap и доступное закрытие, busy/live announcements, reduced motion, длинный текст, safe area, отсутствие перекрытых controls/горизонтального скролла, сохранение scroll и раскрытий; presentation states воспроизвести synthetic stories, runtime lifecycle — приложением и RTL/MSW, без browser MSW worker.
  • 7.4 [frontend] Завершить Boy Scout review затронутого diff и выполнить полный canonical frontend gate после всех production, test, dependency и convention изменений.

    • Covers: N/A — финальная проверка frontend delivery по Design, без нового observable behavior; targeted tests не заменяют canonical gate.
    • Verification: npm ci и npm run verify; отдельно сверить сохранность чужого PortfolioStructure diff, отсутствие generated/OpenAPI drift, дублированных query owners и global toast interception; записать фактические результаты и ограничения.

8. As-built документация

  • 8.1 [docs] После frontend delivery оформить принятое решение о тихом чтении и редких уведомлениях в существующем журнале ADR, с причинами, альтернативами, последствиями и связью с предыдущим решением о background sync.

    • Covers: N/A — ADR фиксирует rationale уже утверждённого Design и выполненной delivery, а не создаёт новую behavioral spec; docs отмечен affected в Delivery Map.
    • Verification: Проверить номер по актуальному adr/README.md, самостоятельность текста, связь с ADR 017 и сохранность его исторического содержания; новый ADR описывает реализованный механизм и не обещает непоставленное поведение.
  • 8.2 [docs] Обновить объяснения UI resilience, data freshness и visual states, убрав описание обязательных предупреждений/ручного обновления и объяснив ограниченное автоматическое восстановление, первичную недоступность и сохранение ошибок действий.

    • Covers: N/A — as-built тематические страницы объясняют согласованные требования и технические решения; это documentation outcome Design, без самостоятельного нового поведения.
    • Verification: Сверить architecture/cross-cutting/ui-resilience.md, architecture/cross-cutting/data-freshness.md и design/overview.md с реализованным flow, исключить противоречия между freshness, completeness и UI; проверить локальные ссылки и предметные даты.
  • 8.3 [docs] Согласовать затронутые предметные описания счетов, портфеля, операций, дохода, событий, инструментов и карт с тихим UI; обновить только фрагменты, описывающие изменённые состояния и recovery.

    • Covers: N/A — предметная документация устраняет устаревшие инструкции пользователю после frontend delivery; область и поведение уже заданы Design и Delta Specs.
    • Verification: Пройти маршруты README к затронутым domains; сверить упоминания refresh/retry, времени получения и ошибок с приложением, сохранив полезные финансовые пояснения, ограничения прогнозов и входящие ссылки.
  • 8.4 [docs] Выполнить semantic/link review обновлённой документации и canonical docs gate с учётом новых файлов.

    • Covers: N/A — проверка документационной delivery из Design; не является новой пользовательской capability.
    • Verification: npm ci при отсутствии установленных dependencies, затем npm run verify; проверить ADR index, новые локальные anchors и пользовательские маршруты чтения; если затронуты диаграммы, отдельно проверить их рендер доступным средством.

9. Canonical specifications и итоговые gates

  • 9.1 [specs] После подтверждения реализации перенести согласованные quiet Delta Requirements в canonical specs через OpenSpec sync workflow и добавить frontend-user-feedback в AI_INDEX; учесть порядок пересечения с persist по Design, сохраняя несвязанные требования.

    • Covers: N/A — canonical publication не вводит поведения сверх утверждённых Delta Specs; реализует обязательный specs outcome Delivery Map и сохраняет единственный источник требований.
    • Verification: Сравнить перенесённые Requirement blocks со всеми десятью delta paths, проверить отсутствие восстановления старых UI/retry obligations и потери несвязанных scenarios; проверить новый target в AI_INDEX; при изменившейся базе вернуть затронутые artifacts на согласование до переноса.
  • 9.2 [specs] Выполнить canonical specs gate, native schema/change/spec validation и итоговую сверку трассировки с реально выполненными задачами.

    • Covers: N/A — проверка полноты и согласованности specs delivery, обязательная по Design и местным правилам; нового observable behavior нет.
    • Verification: npm run verify; openspec schema validate wealth-ledger-sdd --verbose; openspec validate quiet-user-feedback --type change --strict --store wealth-ledger-specs; openspec validate --specs --strict --store wealth-ledger-specs; проверить новые файлы и их diff отдельно, а checklist отмечать только по наблюдённым результатам.