MikrotikManager/docs/ux-ui-plan.md

План реализации UX/UI по пятичасовым окнам

Актуальное продолжение 2026-10-13: блок 212 завершён. GRE с PSK по умолчанию отключает FastPath; явный конфликт получает400. Форма и экспорт учитывают совместимость и недопустимый keepalive. SQL/API18, E2E10 и live GRE/Filters UI4 прошли; два собственных интерфейса удалены. Backend/frontend ux-gre212; source478/527 и compiled1048 совпали. Auth-исправление211 сохранено. Следующий213 — выбор IPv4/IPv6-команды в GRE экспорте. Этап12.5 открыт.

Общий план проекта MikrotikManager. Основан на согласованном плане из задачи; точка продолжения обновлена 2026-10-13. Источник фактического прогресса, проверок и ограничений — журнал реализации. Этот документ задаёт объём и критерии завершения, журнал фиксирует результат.

Актуальная точка продолжения — 2026-10-13

Этапы0–11 завершены в локальных границах журнала. История выполненных внешних блоков и доказательства сохранены в журнале и протоколе. Реальная Telegram доставка, Portal SSO, multi-instance и оставшиеся профильные сетевые ограничения открыты.

По поручению2026-10-09 работать укрупнёнными разделами, последовательно на текущей модели: карта возможностей → исправления → профильные тесты → build/deploy → собственные реальные сценарии → cleanup → один локальный коммит без push. Проверять квоту после завершённого раздела; незавершённые проверки явно переносить в журнал.

Цель и обязательные требования

Информативный, лаконичный и интуитивно понятный интерфейс с полноценной обработкой 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.34 — IPsec/GRE/VXLAN и переключение Firewall); этапы 10–12 не начаты. Этап 11 разделён: 11А — пользователи, контейнеры, сертификаты, резервирование; 11Б — оповещения, сбор данных, интеграции, релизы, настройки.

Подробные планы: этап 6, этап 7, этап 8 и итоговая матрица, этап 9.

Этап 8 завершён блоком 8.13: периоды и URL статистики, достоверность REST/SSE, защита от гонок, свежесть и разрывы графиков, месячный отчёт с каталогом неактивных серверов, адаптивность и профильная клавиатурная приёмка. Повреждённые ответы статистики показывают ошибку с повтором. Точный состав проверок и ограничений сохранён в журнале.

Ближайший оставшийся объём:

1. Этап 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 и защита повторов. В 9.21 исправлены подтверждение создания/сохранения GRE и защита формы. В 9.22 исправлены контейнер ответа, первоначальные KPI и сохранение данных при ошибке VXLAN. В 9.23 backend сообщает частичные сбои VXLAN, UI сохраняет данные неответивших устройств и показывает неизвестное состояние. В 9.24 добавлены схемы payload и тесты гонок VXLAN. В 9.25 подтверждены включение/отключение правил Firewall и защита повторов. В 9.26 подтверждены включение/отключение address-list с общим замком переключений. В 9.27 удаление правил/address-list перенесено в диалог с подтверждением API и защитой повторов. В 9.28 создание/редактирование правил и address-list требуют подтверждения API, сохраняют ввод/ошибку и блокируют повторы/закрытие. В 9.29 перемещение Firewall требует ok=true, откатывает порядок при ошибке и использует общий замок. В 9.30 восстановление истории подключено к общему замку, ручное обновление и открытие истории заблокированы во время записи. В 9.31 добавлены схемы ответа Firewall/серверов, сохранение последних данных при ошибке и поколение чтения с отменой применения при начале записи. В 9.32 backend сообщает частичные сбои по устройству/семейству/таблице, UI сохраняет недоступные срезы и блокирует изменения неполного среза. В 9.33 состояние изолировано по backend/режиму; поздние операции старого экрана не запускают чтение и не показывают уведомления в новом контексте. В 9.34 показано время получения срезов Firewall: успешные обновляются, недоступные сохраняют прежнее время или остаются неизвестными. В 9.35 сохранение Filters ожидает ok=true, сохраняет ввод при ошибке и блокирует повторную отправку/закрытие; live-список меняется после подтверждения. В 9.36 копирование Filters ждёт подтверждения, сохраняет цель/правила/режим при ошибке и блокирует повторы/закрытие. В 9.37 удаление Filters перенесено в диалог с сохранением ошибки, подтверждением API и защитой повторов. В 9.38 перемещение Filters подтверждается API; поиск использует полный порядок для приоритета и границ, действия таблицы блокируются на время операции. В 9.39 обновление/восстановление Filters используют общий замок до чтения правил/истории; ошибка чтения сохраняет подтверждение, чужой ruleset и stale отклоняются. В 9.40 добавлены схемы правил/ответов Filters, ошибка первоначальной загрузки с повтором без подмены моками и сохранение последних данных. В 9.41 запись выбранного устройства требует успешного чтения live=true, старые ответы отклоняются поколением запросов при переключении/применении. В 9.42 состояние Filters изолировано по backend/режиму, старые операции не уведомляют новый контекст. В 9.43 копирование Filters читает актуальный целевой набор под общим замком до PUT, ошибки чтения блокируют отправку. В 9.44 схемы/ошибки каталогов Filters сохраняют последние шлюзы, блокируют недостоверный route/маппинг; выборный GRE GET сообщает 503 при отказе. В 9.45 показано время получения правил/каталогов Filters и отдельное подтверждение записи, сбои сохраняют прежнее время. Далее — профильная клавиатурная/адаптивная приёмка Filters; ограничения счётчика, свежести и записи VXLAN остаются открытыми; загрузка данных IPsec и общая приёмка остаются открытыми.
2. Сохранять контекст устройства, введённые значения при ошибке и подтверждать результат операций по API; локальные моки проверяют клиентские сценарии, реальные сетевые операции требуют тестового окружения.
3. В этапе 12 выполнить полный аудит доступности (скринридер, контраст), производительности и сквозную регрессию. Ограничения этапа 8 — удалённые серверы месячного каталога, отсутствие экспорта и автоматического переподключения SSE — остаются явно зафиксированными, без заявления о реализации.

Проверенные экраны Filters — блок 9.46

Референс плана	ПК	Телефон
Data Grid Filtering 2: устройство → свежесть → таблица	Экран	Экран
Sheet 8: Community → действие → подтверждение API	Форма	Форма

Снимки HTTP-фикстур просмотрены; в блоке 9.47 прошли общая регрессия Filters (33 E2E) и production build frontend (34 страницы). Этап 9 остаётся в работе; следующие блоки — ограничения IPsec/VXLAN и общего GRE-каталога по журналу.

В блоках 9.48–9.52 исправлены чтение, readiness, свежесть и контекст IPsec; прошли профильные операции, ПК/телефон и frontend build. Этап 9 открыт; далее VXLAN/GRE.

IPsec — проверенные экраны	ПК	Телефон
Устройство → свежесть → клиенты	Экран	Экран
Клиент → форма → подтверждение API	Форма	Форма
Устройство → peer/сертификаты → действия	Серверы	Сервер

Порядок продолжения и журналирования

Перед работой читать этот план, начало журнала, git status и последние коммиты; сохранять чужие изменения. Затем проверить квоту и выбрать завершённый по смыслу блок текущего этапа.

После блока записать в ux-ui-progress.md:

• результат и затронутые компоненты;
• выполненные проверки и известные ошибки;
• оставшийся объём и точный следующий шаг;
• решения по API и совместимости;
• границы локальной проверки и текущую квоту.

Профильные проверки выполнять после каждого блока. Полная регрессия — после миграции и при итоговой приёмке; между этапами расширять её при изменении общей основы. Не объявлять этап завершённым только по успешной сборке или тестам на моках.

Для новой задачи:

Продолжи UX/UI-план из docs/ux-ui-plan.md по журналу docs/ux-ui-progress.md. Сначала проверь состояние файлов и остаток лимита. Выполни следующий незавершённый блок, проверь результат, обнови журнал и сделай локальный коммит без push.

GRE/VXLAN — локальная визуальная приёмка 2026-09-30

Экран / референс	ПК	Телефон	Схема
GRE · List 9 / Stats 12	Снимок	Снимок	Устройство → сводка среза → туннели
GRE · Sheet 8	Форма	Форма	Контекст → поддерживаемые поля → подтверждение API
VXLAN · Data Grid Filtering 2	Снимок	Снимок	Устройство → подтверждённый срез → просмотр
VXLAN · Sheet 8	Экспорт	Экспорт	Снимок → актуальность → код → копирование/файл

HTTP-фикстуры; layout/клавиатура проверены. Production frontend build и 183 E2E прошли в 9.63. RouterOS/JWT остаются отдельной приёмкой; актуальная точка продолжения — в журнале.

Этап 9 завершён 2026-09-30 в границах локальной приёмки (209 E2E, frontend/backend build). Внешние ограничения — журнал 9.64. Следующий этап — маршрутизация/диагностика (10); схема и референсы сохраняются, сетевые правила применения не меняются.

Этап 10 начат 2026-09-30. Карта API, референсы, схема и совместимость: ux-ui-stage-10.md. Точная точка продолжения — в журнале.

BGP — локальная визуальная приёмка 2026-09-30

Экран / референс	ПК	Телефон	Схема
BGP · List 9 / Data Grid Filtering 2	Снимок	Снимок	Устройство → свежесть → сводка → фильтры/сессии
BGP · Data Grid детали	Детали	Детали	URL сессии → подтверждённые поля / неизвестные значения
BGP · Stats 12 / Frame	Аналитика	Аналитика	Точный срез → достоверные суммы → сравнение

27 E2E/сборки прошли; реальные RouterOS/JWT/БД не проверены. Далее — OSPF, точное продолжение в журнале.

OSPF — локальная визуальная приёмка 2026-09-30

Экран / референс	ПК	Телефон	Схема
Интерфейсы · List 9 / Stats 12	Снимок	Снимок	Устройство → свежесть → интерфейсы → подтверждённая операция
Соседи · Data Grid Filtering 2	Снимок	Снимок	Поиск → один срез графа/таблицы → фактическое состояние
Детали · Frame	Снимок	Снимок	URL узла → Router ID → соседи/интерфейсы → возврат фокуса
BFD · Data Grid / Stats 12	Снимок	Снимок	Срез → состояния → наблюдаемые таймеры/счётчики

HTTP-фикстуры; локальная приёмка: 43 основных + 8 source E2E, 9 unit, production frontend. Реальный RouterOS/JWT/БД не проверен. Далее рекурсивные маршруты; точное продолжение в журнале.

Рекурсивные маршруты — локальная визуальная приёмка 2026-09-30

Экран / референс	ПК	Телефон	Схема
Data Grid Filtering 2 / List 9	Детали	390 px, 320 px	Устройство → свежесть → группа/таблица → endpoints
Sheet 8	Форма	390 px, 320 px	Полный снимок → параметры → подтверждение API → возврат фокуса

48 основных + 8 source E2E, backend recursive regression и production frontend прошли. HTTP-фикстуры; RouterOS/DB/JWT остаются внешней приёмкой. Далее оптимизатор по журналу.

Оптимизатор — локальная визуальная приёмка 2026-10-01

Экран / референс	ПК	Телефон	Схема
Сводка · Stats 12 / Frame	Снимок	390 px, 320 px	Источник → объяснение модели → сводка → OSPF
Настройки · Settings 16	Снимок	390 px, 320 px	Пороги → вес → локальный пересчёт
Community · Data Grid Filtering 2	Снимок	390 px, 320 px	Устройство → базовый расчёт → модельная рекомендация → закрепление

47 основных + 8 source E2E, backend optimizer/live-maps, production frontend/backend прошли. Исходные значения отдельно от модели; Community apply недоступен, демо только симуляция. HTTP/DI фикстуры; реальный RouterOS/JWT/БД остаётся внешней приёмкой. Далее карта/терминал; ограничения и точное продолжение — в журнале.

Карта сети — промежуточные экраны 2026-10-01

Экран / референс	ПК	Телефон	Схема
Оболочка · Frame / API	Обзор	390 px, 320 px	Источник → свежесть → слои/фильтры → карта
Детали · Frame / List 9	Детали	390 px, 320 px	Устройство → фактические поля → действия → возврат

Оболочка и клавиатурные действия проверены (35 + 12 E2E). Камера и читаемость малой топологии доработаны в 10.53 (16 E2E + 2 unit). Pointer/touch и пустые состояния приняты в 10.54: 39 основных + 12 source E2E, 10 unit и production frontend build. Реальные RouterOS/JWT/БД остаются внешней приёмкой; далее терминал.

Терминал: локальная приёмка 10.57

REST запрос → ожидание → подтверждённый output / ошибка с сохранением команды. Выбор устройства и поле команды остаются доступными на ПК и телефоне. Референс — существующий ReUI Frame и List 9; детали проверок в журнале.

Экран	ПК	Телефон
Готовность	PNG	390 px, 320 px
Вывод	PNG	390 px, 320 px

Диагностика: экраны 10.69

Референс — существующий ReUI Frame/FramePanel и List 9. Устройство → параметры → подтверждённый ответ API/ошибка → копирование или удаление. Расписание относится к 11Б.

Экран	ПК	Телефон
Готовность	PNG	390 px, 320 px
Вывод	PNG	390 px, 320 px

Актуальное продолжение 2026-10-01

Этап 10 принят локально (10.71): 235 основных + 52 source E2E, 42 unit, frontend/backend build. Реальный RouterOS/Portal/PostgreSQL остаётся внешней приёмкой. Далее 11А — пользователи, контейнеры, сертификаты, резервирование; затем 11Б и 12. История прежних контрольных точек выше не заменяет актуальный журнал.

Карта этапа 11А: API, референсы и схемы. Точный следующий блок и ограничения — журнал.

Администрирование: экраны 11А

Пользователи и контейнеры приняты локально (11А.8/11А.13); референсы Settings 16 / Stats 12 / Sheet 8 и схемы — карта 11А. Далее сертификаты и резервирование.

Экран	ПК	Телефон
Пользователи	Профиль, ошибка	390, 320
Контейнеры	Обзор, снимок	390, 320

Каталог Evolution защищён от неполного HTTP-ответа в 11Б.3.3.4.1; Подтверждение testConnection исправлено в 11Б.3.3.4.2; состояния интеграции остаются в объёме 11Б. Актуальная точка продолжения: 11Б.3.4.4 — строгие NetFlow API и backend эффекты, затем форма. GeoIP принят локально в 11Б.3.4.3 (13 основных + 6 source E2E, ПК/390/320); реальные интеграции не проверены. GeoIP known/dirty/partial/unknown guard приняты в 11Б.3.4.2. GeoIP RBAC исправлен в 11Б.3.4.1 (traffic read/write вместо catch-all dashboard read). Scheduler принят локально в 11Б.3.3.7 (46 основных + 6 backend source E2E, ПК/390/320); внешние интеграции не доказаны. Параллельных агентов не использовать. Ручные run-now/refresh, общий lock/права и сообщения skipped/partial/event/status приняты в 11Б.3.3.6.3. Точечные операции настроек, ввод и подтверждённый сброс dirty приняты в 11Б.3.3.6.2. Независимые strict settings readers и защита черновиков подключены в 11Б.3.3.5; реальные интеграции остаются внешней приёмкой. Независимые scheduler status/runs и достоверные KPI приняты в 11Б.3.3.3. Strict history/unknown/свежесть приняты в 11Б.3.3.2. Контекст/abort/revision и исходный lint исправлены в 11Б.3.3.1; далее независимые readers/dirty states и операции. GeoIP API принят в 11Б.3.2. Scheduler API основа проверена в 11Б.3.1, пока не подключена к странице. Совместимость JSONB/legacy snapshot и foreign guard проверены в 11Б.2; исходные lint/context ограничения страницы описаны в журнале. Общий runner исправлен в 11Б.1; карта оставшегося этапа — 11Б. Этап 11А принят локально в 11А.33: backups 71 основных + 28 source E2E, 27 frontend unit, backend профиль и production build. Backup scheduler cleanup проверен в 11А.32; общий dispatcher/journal status исправлен в 11Б.1, реальные интеграции остаются внешней приёмкой. S3/partial job/initial errors приняты в 11А.31.2.2. Диалоги ошибок приняты в 11А.31.2.1. Frame/первые 9 экранов приняты в 11А.31.1. URL/Filters контекст принят в 11А.30. Клиентский checkpoint restore принят в 11А.29.5. Backend outcome неизвестного импорта принят в 11А.29.4. Идентичность receipt принята в 11А.29.3. Backend cleanup удаления принят в 11А.29.2. Frontend delete/restore/download принят в 11А.29.1, затем URL/Frame/визуальная приёмка и scheduler cleanup. Frontend checkpoint/создание/serial polling приняты локально в 11А.28.2. API/основа наблюдения реализованы в 11А.28.1. Настройки расписания/S3 реализованы в 11А.27.1–11А.27.2. Каталоги/source/права реализованы в 11А.25, backend результат ручных операций исправлен в 11А.26. Сертификаты приняты локально в 11А.24, backups API стал строгим. State API, reader, snapshot merge и nullable представление подключены в 11А.14–11А.17.3; таблица требований — этап 11А. Резервные копии и весь 11А приняты локально в 11А.33; внешние ограничения — журнал.

Экран	ПК	Телефон
История	PNG	390, 320
Настройки	PNG	390, 320
Создание	PNG	390, 320

Референсы: Settings 16, Data Grid Filtering 2, Sheet 8. Схема: источник → сводка → история/настройки → immutable цель → подтверждение API/неизвестный результат.

Экран	ПК	Телефон
Ошибка удаления	PNG	390, 320
Неизвестный импорт	PNG	390, 320

Экран	ПК	Телефон
S3 ошибка	PNG	390, 320
Partial job	PNG	390, 320
Initial error	PNG	390, 320

Продолжение 2026-10-03: завершён 11Б.3.4.4.1 (строгие NetFlow API, 5 unit и 3 collector/probes E2E, typecheck/ESLint). Следующий блок — 11Б.3.4.4.2: backend экспорт/права и подтверждение сохранения отдельно от запуска listener. Purge и форма ещё требуют доработки.

Завершён 11Б.3.4.4.2: private export требует traffic write, GET не создаёт ключи, PUT отделяет сохранение от ошибки запуска listener. HTTP/JWT, backend build, lint и permissions прошли. Далее 11Б.3.4.4.3: конкурентное создание ключей/выборочные patch; purge и UI ещё не приняты.

Завершён 11Б.3.4.4.3: выборочная запись NetFlow patch и условная установка host keys, свежая подтверждённая пара; DI гонка/HTTP/JWT/build/lint прошли. Реальная PG гонка не проверена. Далее 11Б.3.4.4.4 — атомарность purge и частичные результаты.

Завершён 11Б.3.4.4.4: 6 таблиц/counters purge в общей транзакции, отдельные partition/listener/event warnings и nullable размер файлов. DI/HTTP/API/typecheck/build/lint прошли; реальный PG purge не запускался. Следующий шаг 11Б.3.4.4.5 — форма NetFlow и подтверждённые/частичные/неизвестные операции.

Завершён 11Б.3.4.4.5: форма NetFlow known/dirty/rights/lock, selective PUT, partial outcomes и review после unknown POST; 12 E2E/form unit/typecheck/lint/production build прошли. Далее 11Б.3.4.4.6 — source/adaptive приёмка, затем общий контракт IP/CIDR/DNS.

Завершён 11Б.3.4.4.6: 10 NetFlow backend source E2E, 3 responsive, 6 снимков (320 и ПК просмотрены), регрессия GeoIP/collector прошли. Далее 11Б.3.4.4.7: общий IP/CIDR/DNS ввод/фактический порт и отказ конкурентному purge вместо очереди. Затем приёмка NetFlow и Evolution.

Завершён 11Б.3.4.4.7.1: конкурентный purge получает 409 до удаления, неподтверждённый session lock соединения исключается из пула; DI/backend/build/lint/conflict E2E прошли. Реальный PG overlap не проверен. Далее 11Б.3.4.4.7.2 — общий IP/CIDR/DNS контракт и фактические порты.

Завершён 11Б.3.4.4.7.2: общий NetFlow IP/CIDR/DNS/ports patch, draft и backend проверяют его; инструкция использует фактический порт. 14 E2E, unit/HTTP/JWT, lint и оба builds прошли. Далее 11Б.3.4.4.7.3 — согласованный host export/маска, затем приёмка NetFlow и Evolution.

Завершён 11Б.3.4.4.7.3: host export из одного снимка, фактические mask/WG/IPFIX ports, strict keys/peers и безопасные однострочные комментарии. Builder/key/HTTP/JWT/build/lint прошли без запуска host/RouterOS. Далее 11Б.3.4.4.8 — приёмка NetFlow; затем 11Б.3.5 Evolution. Нестандартные prefix allocator не приняты.

Локальная приёмка NetFlow 11Б.3.4.4.8: 19 основных и 10 source E2E, backend JWT с purge, backend/frontend builds и API tests прошли в описанных блоках. Дублирующий purge Settings заменён переходом к единой панели (link E2E/typecheck). Исходные lint ошибки Settings остаются до его блока. Внешние PG/WG/RouterOS/Portal/нестандартный IPv4 prefix не приняты. Далее 11Б.3.5.1 — строгие Evolution settings/save/test API и затем provider/форма.

Завершён 11Б.3.5.1 — contracts/Evolution strict settings/save/test API: 3 unit, contracts build/typecheck/lint прошли. Новый PUT helper пока не подключён (backend старый receipt). Далее 11Б.3.5.2 backend selective save/подтверждение, затем provider и форма.

Завершён 11Б.3.5.2: Evolution backend selective RETURNING save/public receipt и проверка items upstream/test; DI HTTP/JWT, backend build/lint прошли. Старый provider совместим с публичными полями, ещё не мигрирован. Далее 11Б.3.5.3 — provider known/error/time/source; затем форма и upstream catalog validation.

Завершён 11Б.3.5.3.1: Evolution provider known/error/time/readers/source/strict receipts, статус Settings; 8 provider (один selector повторён), 2 прежних и 6 source E2E, lint/typecheck/production build прошли. Форма/consumer mocks ещё не приняты. Далее 11Б.3.5.3.2 — upstream catalog strict/unknown counts; затем 11Б.3.5.4 форма/consumers.

Завершён 11Б.3.5.3.2: strict upstream catalog, nullable ASN/community counts, unknown «—» вместо 0. Parser/aggregation/HTTP/JWT/build/typecheck/lint и provider/counts E2E прошли; locator inline details исправлен. Реальный Evolution/PG не принят. Далее 11Б.3.5.4.1 — форма Evolution dirty/rights/lock/key clear/source.

Завершён 11Б.3.5.4.1: отдельная форма Evolution dirty/rights/lock/clear confirmation/source; 17 основных, 8 source и 3 responsive E2E, typecheck/lint/build прошли. 6 снимков, 320/ПК/clear просмотрены. Общие Settings и live consumer mocks ещё не приняты. Далее 11Б.3.5.4.2 — consumers/sidebar unknown/disabled/no fallback.

Завершён 11Б.3.5.4.2: live catalog consumers/sidebar/Filters без demo fallback, unknown/disabled/last snapshot и current details; 25 E2E, typecheck/профильный lint/build прошли. 3 community screenshots, 320/ПК просмотрены. Sidebar sync-effect baseline error и Filters unused warnings описаны в журнале. Далее 11Б.3.5.5 — HTTP/JWT catalog и приёмка Evolution.

Завершён 11Б.3.5.5: Evolution catalog DI HTTP/JWT, один settings snapshot, backend test/build/lint прошли. Evolution принят локально в границах предыдущих form/provider/source/consumer/adaptive проверок; реальный upstream/PG/Portal/RouterOS не принят. Далее 11Б.3.6.1 — достоверные общие Settings без фиктивных сохранений/API keys/MFA; затем system DB, Alerts/Releases/probes.

Завершён 11Б.3.6.1: общие Settings без фиктивных сохранений/demo keys/MFA, реальная тема/source URL, переходы к инструментам; 32 E2E с одним исправленным locator, 3 source с исправленным alert locator, 8 Evolution source, typecheck/lint/build прошли. 6 screenshots, 320 просмотрены. System DB ещё не принят. Далее 11Б.3.6.1.2 health/source guards; затем 11Б.3.6.2 DB operations.

Завершён 11Б.3.6.1.2: DataSource health token/revision/abort/ABA, explicit checking и validated health body. 2 unit, 10 source/health, 16 Settings/Evo provider и 8 Evo source E2E, typecheck/lint/build прошли; два test setup уточнены. System monitor остаётся отдельным reader. Далее 11Б.3.6.2.1 — system DB API/credentials in events; затем backend outcomes и UI.

Завершён 11Б.3.6.2.1: system DB export PGDMP/leaf filename и restore strict receipt/limits/abort без повтора; DATABASE_URL удалён из новых event payload. 3 unit группы/typecheck/lint/backend и frontend builds прошли. UI/backend partial/restore transaction не приняты. Далее 11Б.3.6.2.2 — backend transaction/outcomes/DI HTTP/JWT, затем 11Б.3.6.2.3 форма.

Завершён 11Б.3.6.2.2.1: DI restore executor/--single-transaction/cleanup warning, file choose без фиктивного success, confirmation до receipt. 4 DI/3 API/2 browser tests, backend/frontend builds/typecheck/lint прошли; реальный PG restore не запускался. System DB не принят полностью. Следующий точный шаг 11Б.3.6.2.2.2 — backend core/restart/event partial outcomes + DI HTTP/JWT/concurrency; затем 11Б.3.6.2.3 source/lock/unknown UI.

2026-10-03: завершён 11Б.3.6.2.2.2, подтверждённый backup/restore отделён от restart/audit warnings; nonqueued concurrency, HTTP/JWT/API/UI проверки прошли локально. Далее DB форма 11Б.3.6.2.3.

2026-10-03: завершён 11Б.3.6.2.3.1, отдельная DB форма/lock/checkpoint/адаптивность; 10 E2E, API/proxy tests и build прошли. Далее source/ABA/unmount и приёмка DB.

2026-10-03: 11Б.3.6.2.3.2 — 6 source и 18 соседних E2E прошли; база принята в локальных границах. Далее 11Б.4.1 Alerts contracts/API.

2026-10-03: 11Б.4.1 — строгие Alerts output schemas/API и сверка save receipts; 5 unit/builds/typecheck/lint прошли. Module пока не подключён. Далее 11Б.4.2.1 backend Telegram.

2026-10-03: 11Б.4.2.1.1 — selective Telegram UPDATE RETURNING, strict send receipt; 7 DI/send tests/build/lint прошли. confirm-stability пропущен без PG. Далее HTTP/JWT 11Б.4.2.1.2.

2026-10-03: 11Б.4.2.1.2 — реальные Alerts HTTP/JWT gates и один Telegram stored snapshot, профильные tests/build/typecheck/lint прошли. Далее rules/groups 11Б.4.2.2.1.

2026-10-03: 11Б.4.2.2.1.1 — общая нормализация rules/groups и 400 до удаления; 8 unit и backend profile/builds/typecheck/lint прошли. Далее transaction receipt 11Б.4.2.2.1.2.

2026-10-03: 11Б.4.2.2.1.2 — transaction rules receipt/readback/lock, DI/API/JWT/build/typecheck/lint прошли. Реальный PG rollback/overlap и optimistic revision не приняты. Далее Alerts UI 11Б.4.3.1.

2026-10-03: 11Б.4.3.1.1 — live Alerts без первоначальных demo/0, strict primary reader/known/time, 3 E2E/lint/typecheck/build прошли. Далее independent secondary readers/source 11Б.4.3.1.2.

2026-10-03: 11Б.4.3.1.2.1 — strict secondary API (GRE partial failures/unknown status), 4 unit/typecheck/lint прошли. Module не подключён. Далее 11Б.4.3.1.2.2 independent UI/source.

12.5.51 — реальная GRE пара, связность и lifecycle (2026-10-08)

По прямому поручению пользователя VPN-приёмка продолжается с созданием реальных тестовых туннелей, особенно GRE. Lifecycle: production backend8782054, два CHR7.24.5, собственные имена mm-acceptance-gre-* и комментарий владения. Перед записью проверены локальные внешние адреса и отсутствие пересечения198.18.255.248/30 с существующей адресацией/недефолтными маршрутами. POST application API создал обе GRE стороны и /ip/address:201/201. Внешние endpoints194.226.121.150 ↔104.165.244.7, внутренние198.18.255.249/30 ↔198.18.255.250/30, MTU1400,keepalive2s/3. Дополнительных static/default routes и Firewall правил не создавалось.

После running=true независимый RouterOS Ping через указанный GRE интерфейс:3/3 в каждом направлении,0%loss,~54ms. Это реальная point-to-point связность, не benchmark и не шифрованный IPsec. PATCH MTU первого конца1360, disable и enable дали200 и подтверждены отдельным чтением RouterOS. Browser: настоящие созданные объекты, формы обоих устройств, local IP и server/tunnel URL-контекст/reload/320px, JS errors0; browser проход читает/отменяет формы, создание/изменение выполнял production API. ФормаCHR1 просмотрена, CHR2 сохранена.

Первый запуск Ping до готовности получил timeout; повтор после running подтвердил3/3. Первый harness остановил свою очистку на слишком строгом сравнении baseline, включавшем runtime IDs; причина конкретного несовпадения не была сохранена полностью. Независимая очистка удалила оставшуюся собственную сторону и подтвердила отсутствие интерфейсов/IP/connected route, исходные количества0GRE/1–2addresses/4–5routes. Harness исправлен: сначала очистить обе стороны, сравнивать конфигурационные поля без runtime IDs, сохранить evidence до assertion. Повторный полный lifecycle прошёл с exitCode0: DELETE200/200, все выбранные поля GRE/IP/route/IPv4 Firewall совпали с baseline. Прямое административное восстановление чужих объектов не выполнялось.

Обнаружен настоящий дефект: принятый remoteInnerIp возвращается пустым, затем теряется в форме редактирования. Связность обеспечивается настройкой обоих реальных /ip/address, но сохранение формы этим не считается исправленным. Следующий12.5.52 — исправить metadata persistence/restore peer IP и профильные тесты, затем развернуть и повторить настоящий GRE цикл. Ограничения ROS6 для остальных VPN/прав/частичных отказов остаются. Control main2servers/9speed/retention14 сохранён; application GRE revisions намеренно остаются журналом выполненных действий. Временный контейнер/туннель8018 удалены; RouterOS тестовые объекты очищены. Локальный коммит без push.

Официальная схема пары и keepalive: MikroTik GRE. Документация текущей версии проверена, реальные команды/ответы — RouterOS7.24.5.

12.5.76 — VXLAN: достоверность, экспорт и полная профильная приёмка (2026-10-09)

По поручению пользователя работа укрупнена по разделам. В одном блоке выполнены code/API/UI, профильные проверки, production Docker build обеих частей, deploy, реальная приёмка и очистка; один локальный коммит в конце, без push.

Прямой GET /api/servers/:id/vxlan теперь возвращает409 для выключенного сервера до обращения к RouterOS. Защита есть также в native reader и агрегаторе, для home-router и exit-node. Неполные/некорректные параметры интерфейса, повторные ID/имена и неизвестные/некорректные статические VTEP считаются ошибкой устройства вместо выдуманных VNI/port/L2MTU/флагов. Сохранение последних успешных данных и частичная ошибка остаются прежними. VTEP сопоставляется с именем или RouterOS ID интерфейса.

Реальный MTU передаётся в модель, виден в таблице и экспортируется; для старого снимка без MTU показывается «—», параметр не придумывается, экспорт просит проверить его отдельно. CodeExportSheet прямо описывает fragment: interface/известный MTU/static VTEP, без IP/bridge/FDB. Стабильная actions cell получает callback через контекст, поэтому открытое меню сохраняется при refresh и экспорт использует последние данные. Frame/base-nova и установленные ReUI primitives сохранены; registry migration не выполнялась.

Проверки: backend mapping/HTTP route/export tests, backend и scoped frontend TypeScript, ESLint изменённых файлов и diff check passed. Профильный browser набор23/23 (VXLAN и два связанных layout cases), context-race4/4. В тесте1000 строк отображаются50 строк; измерено2245 DOM nodes, payload227787 bytes и829ms до ready в данном локальном запуске — это наблюдение, не универсальный performance SLA. Общая регрессия проекта не повторялась.

На161.104.46.222 развёрнуты backend/frontend mmapp-test/*:ux-vxlan76, version1.0.0-test.vxlan76. Сборочный source — git archive базового HEAD6b068ac с явными13 working-file overrides, а не отдельный уже закоммиченный revision. SHA256 архива b69f8eb8b5830e85930aca0974cd83a94940e2e162101b8798208720ccf3e1ae; manifest позволяет сверить каждый изменённый файл. Production builds passed; Compose3 services running, backend/PostgreSQL healthy; frontend healthcheck отсутствует, HTTP/browser passed. Backup2441206 bytes/0600, pg_restore --list passed, .env сохранён приватно на сервере, прежние образы доступны для rollback.

Реальная собственная VXLAN пара на194.226.121.150 и104.165.244.7: VNI160075, UDP51880, MTU1400, публичные local/static remote VTEP, IP198.18.255.245/30↔198.18.255.246/30. Native параметры совпали с каталогом приложения; Ping3/3 в обе стороны. Browser4/4 подтвердил URL выбранного устройства/туннеля, экспорт и отсутствие page overflow на1280/320px. Экспорт каждой стороны заново применён через строго ограниченный native REST adapter к собственным интерфейсам: только interface/VTEP команды, IP добавлены отдельно; MTU1400 и Ping3/3 повторно подтверждены. Это проверка параметров fragment, не запуск произвольного .rsc скрипта в терминале.

Две временные выключенные записи home-router/exit-node указывали на отдельный HTTP probe. Прямые GET вернули409, nativeProbeCalls0; временные записи удалены. Native protocol: cleanup сравнил исходные VXLAN/VTEP/IP/routes/IPv4 firewall/bridge/bridge-port на обоих устройствах, все проверки true. DB controls после: servers2/speedHistory9/retention14/migrations9. Пароли не менялись, SSH и оба CHR доступны. Smoke шести страниц: HTTP200, mobile fits, JS errors0/API errors0.

Референс	Схема применённого решения
ReUI Data Grid / Filtering2	Контекст устройства → достоверная таблица/MTU → устойчивое меню
Sheet8	Актуальный снимок → границы fragment → код → независимая native проверка

flowchart LR
    A[Устройство] --> B{Включено?}
    B -->|Нет| C[409: без опроса]
    B -->|Да| D{Снимок достоверен?}
    D -->|Нет| E[Ошибка и последние данные]
    D -->|Да| F[Таблица с MTU]
    F --> G[Экспорт interface и VTEP]
    G --> H[Повторное применение и Ping]

Границы: app VXLAN API read-only, create/delete выполнены native REST только на собственных объектах. IPv6/bridge/FDB/throughput/RBAC/concurrency и произвольный терминальный .rsc import не приняты; динамический ARP/FDB baseline не сравнивался. Первый запуск Edge в sandbox завершился до страницы; повторный разрешённый запуск прошёл. Этап12.5 целиком не закрыт. Следующий раздел12.5.77 — IPsec; остаточные VXLAN/WireGuard ограничения остаются в протоколе.

12.5.77 — основной блок IPsec (2026-10-09)

Подробный объём, протоколы, схема и ограничения: 12.5.77 в журнале.