18 KiB
План реализации UX/UI по пятичасовым окнам
Общий план проекта MikrotikManager. Основан на согласованном плане из задачи; состояние на 2026-09-24. Источник фактического прогресса, проверок и ограничений — журнал реализации. Этот документ задаёт объём и критерии завершения, журнал фиксирует результат.
Цель и обязательные требования
Информативный, лаконичный и интуитивно понятный интерфейс с полноценной обработкой API, ошибок, прав и состояний данных. ReUI PRO, Frame и стиль base-nova; переиспользование установленных компонентов и общих композиций KpiStatGrid, ServerTileRail, CodeExportSheet. Основной сценарий — ПК с адаптацией для телефона; доступность обязательна.
Изменения выполняются как fullstack-работа: проверять контракт и поведение backend, а не только внешний вид. Не показывать успешную операцию до подтверждения API, не подменять неизвестные значения нулями. Локальные проверки используют реальные HTTP-пути с подменой ответов. Моки достаточны для локальной проверки UI и обработки ответов, но не доказывают применение конфигурации RouterOS, работу JWT в реальном окружении или точность IPFIX.
Распределение работы и лимиты
- Пятичасовое окно — квота использования, а не пять часов непрерывной разработки. Расход заранее неизвестен; этап ограничивается конкретным результатом и проверками.
- По умолчанию один крупный этап на окно. Небольшие блоки объединять после проверки доступной квоты. Учитывать и общий недельный лимит аккаунта.
- Проверять квоту в начале этапа и после законченного блока. Базовый резерв — 25% пятичасового окна: не начинать новый блок, завершать проверки и сохранять состояние.
- Последующие прямые указания пользователя «до конца лимитов» разрешают работать ниже базового резерва, сохраняя возможность завершить проверки, журнал и коммит. Не начинать блок, который нельзя безопасно закончить.
- Работать последовательно, без параллельных агентских задач. Не менять модель посреди этапа без необходимости.
- После каждого завершённого этапа или самостоятельного проверенного блока делать локальный коммит. Без push. Сообщение коммита — по AGENTS.md, с русским subject после префикса.
- Исторические проценты и даты сброса из первоначального плана не являются текущими: перед работой получать актуальные лимиты.
Этапы и критерии завершения
| Этап | Объём | Точка завершения | Распределение |
|---|---|---|---|
| 0. Подготовка | Зафиксировать состояние проекта, базовые проверки, таблицы и потребителей Filters, исходные экраны | Журнал, исходные ошибки, карта миграции | Первое окно |
| 1. Достоверность операций | Сохранение, удаление, опрос серверов; сохранение формы и данных при ошибках | Проверены успех, ошибка API, отсутствие доступа, повторное нажатие | Вместе с 0 при достаточном резерве |
| 2. Основа миграции | Связанная группа ReUI Data Grid/TanStack, общая оболочка, одна таблица серверов, подготовка Filters | Эталонная таблица, зависимости и образец миграции | Отдельное окно |
| 3. Основные таблицы | Обзор, серверы, мониторинг, трафик, статистика, справочники | Проверены таблицы группы, оставшиеся потребители перечислены | Отдельное окно |
| 4. Остальные таблицы | VPN, маршрутизация, управление, системные разделы; удаление старого API Filters | Нет смешения старого и нового API, общие проверки проходят | Отдельное окно |
| 5. Состояния данных | Частичные сбои дашборда, последние данные, свежесть, гонки запросов | Проверены первоначальная ошибка, частичный сбой, фоновое обновление | Отдельное окно |
| 6. Оболочка и дашборд | Навигация, контекст, подписи, сводка, очередь проблем, переходы к объектам | Проверены схемы и экраны ПК/телефона, переходы работают | Отдельное окно |
| 7. Серверы и мониторинг | Единый UX таблиц, деталей и форм; URL-контекст, права | Сценарий «проблема → сервер → действие → возврат» работает | Отдельное окно |
| 8. Трафик и статистика | Периоды, единицы, фильтры среза, связь графиков и таблиц, пустые состояния | Нет смешения live/истории и подмены неизвестных значений нулями | Отдельное окно; допускается несколько блоков |
| 9. VPN и сетевые операции | WireGuard, IPsec, GRE, VXLAN, Firewall, Filters; выбор устройства, формы | Контекст устройства сохраняется, результат операций подтверждён API | Отдельное окно |
| 10. Маршрутизация и диагностика | BGP, OSPF, рекурсивные маршруты, оптимизатор, диагностика, карта, терминал | Проверены профильные сценарии без изменения правил сетевых операций | Отдельное окно |
| 11. Администрирование | Пользователи, контейнеры, сертификаты, резервирование, оповещения, сбор данных, релизы, настройки | Общие шаблоны применены, ошибки операций и интеграций понятны | Разделено на 11А и 11Б |
| 12. Итоговая приёмка | Доступность, адаптивность, права, производительность, сквозная регрессия | Production build, тесты, ReUI checklist, список ограничений | Отдельное окно |
Это 13 контрольных этапов, а не обещание уложиться в 13 окон. Основная неопределённость — миграция компонентов и применение изменений в сетевых разделах.
Этапы 2–4 выполняются в отдельной ветке миграции (codex/reui-v9-migration). Промежуточные остановки допустимы с точным перечнем ошибок; выпуск до завершения этапа 4 не допускается. Само завершение этапа не является разрешением на push или deployment.
Референсы и схемы
Для каждой группы экранов сначала использовать одну схему как эталон, затем применять её последовательно. Не пересобирать весь визуальный план в каждом окне.
| Этапы | Референсы ReUI PRO | Схема доработки |
|---|---|---|
| 6 | App Shell 12, Stats 12 | Навигация → сводка → проблемы → измерения |
| 2–4, 7–8 | Data Grid Filtering 2 | Фильтры → таблица → детали → результат |
| 7, 9–10 | List 9, Sheet 8 | Сервер → объект → форма → подтверждение API |
| 11 | Settings 16 | Секция → состояние → действие → результат |
flowchart LR
A["0–1: подготовка и операции"] --> B["2–4: миграция ReUI"]
B --> C["5: достоверность данных"]
C --> D["6–8: основные экраны"]
D --> E["9–10: сетевые разделы"]
E --> F["11: администрирование"]
F --> G["12: приёмка"]
ПК: [Навигация] [Контекст и действия ]
[Период / фильтры ]
[Сводка ]
[Список объектов] [Детали / результат]
Телефон: [Навигация и контекст]
[Действия / фильтры ]
[Сводка ]
[Список объектов ]
[Детали / результат ]
Данные: контекст → загрузка → подтверждённые данные
↘ ошибка + повтор
новый контекст ≠ старые данные; неизвестное ≠ ноль
Текущая точка продолжения
По журналу этапы 0–8 завершены в границах локальной приёмки; внешние ограничения сохраняются. Этап 9 начат (блоки 9.1–9.20 — операции IPsec, удаление и переключение GRE); этапы 10–12 не начаты. Этап 11 разделён: 11А — пользователи, контейнеры, сертификаты, резервирование; 11Б — оповещения, сбор данных, интеграции, релизы, настройки.
Подробные планы: этап 6, этап 7, этап 8 и итоговая матрица, этап 9.
Этап 8 завершён блоком 8.13: периоды и URL статистики, достоверность REST/SSE, защита от гонок, свежесть и разрывы графиков, месячный отчёт с каталогом неактивных серверов, адаптивность и профильная клавиатурная приёмка. Повреждённые ответы статистики показывают ошибку с повтором. Точный состав проверок и ограничений сохранён в журнале.
Ближайший оставшийся объём:
- Этап 9: карта разделов и схема сохранены; удаление, импорт, создание, переключение, контекст экспорта и выбор пира WireGuard исправлены в 9.1–9.7; в 9.8 проверено подтверждение восстановления. В 9.9 исправлены разметка и сохранение подтверждения при ошибке у всех шести потребителей. В 9.10 исправлены ошибки и поздние ответы загрузки истории WireGuard. В 9.11 подтверждение восстановления проверено у остальных пяти потребителей. В 9.12 обработаны ошибка/повтор/поздние ответы истории IPsec. В 9.13 подключены ошибка/повтор/защита поздних ответов остальных четырёх разделов и общая валидация ревизий всех шести. В 9.14 исправлены подтверждение инициализации IPsec, сохранение формы и защита повторной отправки. В 9.15 проверены создание/редактирование пользователей IPsec и сохранение формы. В 9.16 проверены получение/повторный экспорт сертификатов, поздние ответы и соответствие отображаемого пароля архиву. В 9.17 подтверждены ответы удаления четырёх типов объектов IPsec и исправлен диалог повторов. В 9.18 исправлено подтверждение сохранения peer IPsec и поведение формы. В 9.19 исправлено подтверждение удаления GRE и сохранение диалога при ошибке. В 9.20 исправлено подтверждение включения/выключения GRE и защита повторов. Далее — создание/изменение GRE, затем VXLAN/Firewall/Filters; загрузка данных IPsec и общая приёмка остаются открытыми.
- Сохранять контекст устройства, введённые значения при ошибке и подтверждать результат операций по API; локальные моки проверяют клиентские сценарии, реальные сетевые операции требуют тестового окружения.
- В этапе 12 выполнить полный аудит доступности (скринридер, контраст), производительности и сквозную регрессию. Ограничения этапа 8 — удалённые серверы месячного каталога, отсутствие экспорта и автоматического переподключения SSE — остаются явно зафиксированными, без заявления о реализации.
Порядок продолжения и журналирования
Перед работой читать этот план, начало журнала, git status и последние коммиты; сохранять чужие изменения. Затем проверить квоту и выбрать завершённый по смыслу блок текущего этапа.
После блока записать в ux-ui-progress.md:
- результат и затронутые компоненты;
- выполненные проверки и известные ошибки;
- оставшийся объём и точный следующий шаг;
- решения по API и совместимости;
- границы локальной проверки и текущую квоту.
Профильные проверки выполнять после каждого блока. Полная регрессия — после миграции и при итоговой приёмке; между этапами расширять её при изменении общей основы. Не объявлять этап завершённым только по успешной сборке или тестам на моках.
Для новой задачи:
Продолжи UX/UI-план из docs/ux-ui-plan.md по журналу docs/ux-ui-progress.md. Сначала проверь состояние файлов и остаток лимита. Выполни следующий незавершённый блок, проверь результат, обнови журнал и сделай локальный коммит без push.