Specs security / security (pull_request) Successful in 7s
Specs verify / verify (pull_request) Successful in 11s
Conventional commits / commits (pull_request) Successful in 11s
Specs security / security (push) Successful in 7s
Specs verify / verify (push) Successful in 9s
OpenSpec change: evolve-frontend-stack
70 lines
5.8 KiB
Markdown
70 lines
5.8 KiB
Markdown
## Why
|
||
|
||
У WealthLedger уже есть общий визуальный фундамент, каталог компонентов и
|
||
типизированное взаимодействие с сервером. Следующий шаг — сделать границы
|
||
переиспользования и поставки этого фундамента явными: участник должен быстро
|
||
находить подходящее решение, а приложение — получать проверенную совместимую
|
||
версию без копирования реализаций.
|
||
|
||
Исследование текущего frontend выявило конкретные незавершённые границы:
|
||
повторяющиеся рисунки иконок, обход существующих цветовых ролей, продуктовую
|
||
навигацию в общем UI и неполную автоматизацию архитектурных ограничений.
|
||
|
||
## What Changes
|
||
|
||
**Статус: локальная реализация и итоговая проверка завершены.**
|
||
Локальные границы приложения и private workspace-пакеты реализованы;
|
||
проверенные пункты и оставшиеся ограничения перечислены в [tasks](tasks.md).
|
||
Независимое версионирование и публикация через Nexus отложены до оценки пользы
|
||
пилота и не входят в требования этого перехода.
|
||
|
||
Первоначальный комплект плановых Markdown-файлов был подготовлен по запросу
|
||
пользователя в одной сессии. Последующие разрешения касались ограниченных
|
||
этапов; они не разрешают публикацию, deployment или archive.
|
||
|
||
- Выделить используемый общий визуальный фундамент в приватные workspace-пакеты,
|
||
сохранив внешний вид и работоспособность приложения между небольшими этапами.
|
||
- Установить единый порядок выбора компонентов и понятную границу между
|
||
общим представлением, предметным UI и сценариями приложения.
|
||
- Сделать повторно используемые собственные иконки доступными с единым
|
||
визуальным и доступным контрактом.
|
||
- Подтвердить переход существующим небольшим продуктовым срезом и проверкой
|
||
потребления собранных артефактов, а не только локальных исходников.
|
||
- Уточнить применимые инженерные правила после соответствующих изменений,
|
||
сохранить существующие проверки и поэтапно закрыть найденные пробелы.
|
||
|
||
Сохраняются денежная точность, обработка неизвестных значений, поведение
|
||
авторизации, запросов, форм, восстановления после ошибок и существующих страниц.
|
||
Предметные расчёты и серверные контракты не становятся частью общего UI.
|
||
|
||
Не входят редизайн, тёмная тема, мобильный адаптер, календарь обязательных
|
||
платежей, смена работающего стека, переустройство всех репозиториев и массовое
|
||
перемещение компонентов. Публикация, deployment, commit, push, PR и archive не разрешены.
|
||
Локальная реализация ограничена отдельно согласованными этапами.
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
|
||
Нет: новая capability на каждый пакет или каталог не требуется.
|
||
|
||
### Modified Capabilities
|
||
|
||
- `specs/frontend-design-system/spec.md`: добавить требования к потреблению
|
||
локальных пакетов общего фундамента и доступному контракту собственных
|
||
общих иконок. Существующие требования к единой теме и предметной независимости
|
||
сохраняются. [Delta](specs/frontend-design-system/spec.md).
|
||
|
||
## Impact
|
||
|
||
- Frontend: поставка общей основы, выбор источников компонентов, ограниченная
|
||
миграция потребителей и развитие существующих проверок.
|
||
- Backend: производственный контракт и поведение не меняются; отдельное
|
||
замечание к описанию ошибок остаётся отложенным исследованием владельца API.
|
||
- Specs: этот change и delta; основные as-built требования пока не изменяются.
|
||
- Docs: описание текущего локального устройства обновлено в 7.2;
|
||
независимая registry-поставка не заявляется.
|
||
|
||
Решения, альтернативы и каталог источников — в [design](design.md), единственная
|
||
очередь работ и текущее состояние — в [tasks](tasks.md).
|