MikrotikManager/docs/ux-ui-stage-11a.md

Этап 11А: пользователи и администрирование устройств

Статус: подготовка 2026-10-01. ReUI PRO/base-nova, существующие Frame, KpiStatGrid, Data Grid v9 и Sheet. Изменения последовательно, локальные коммиты без push.

Референсы и схемы

Область	Референс	Схема
Обзор раздела	Settings 16 / Stats 12	Источник → подтверждённая сводка → проблемы → действие
Таблицы	Data Grid Filtering 2	Фильтры → объект → детали → результат API
Формы	Sheet 8	Контекст → форма → проверка → подтверждённый результат / сохранённый черновик

[Источник и права]
         ↓
[Каталоги + свежесть] → [Ошибка: последние данные, явный повтор]
         ↓
[Объект / детали] → [Форма с черновиком]
                             ↓
                [Подтверждение API / частичное выполнение]
                             ↓
                [Повторное чтение / восстановление контекста]

Карта реализации

Порядок	Раздел / API	Исходная проблема	Точка завершения
1	Пользователи: /users, /servers	Live начинает с INIT_USERS; Promise.all связывает независимые отказы; нет свежести и защиты смены источника	Пустой/unknown/ошибка различаются, последний снимок и read-only права
2	Профиль и привязки: /users/:id, /bindings	Многошаговое сохранение, нет lock удаления, refresh ошибка проглатывается; Sheet эффект может сбросить форму	Частичное выполнение явно показано, повтор без дублей, успешный API отдельно от refresh
3	Interface catalog	Ошибка превращается в []; каталог может сохранять прежнее устройство; peer ошибки требуют проверки	Контекст и доступность, точный выбор, сохранение формы
4	Пользователи UI	«Пригласить» фактически создаёт профиль; icon actions без имён, raw colors, доступность формы	ПК/390/320, клавиатура, понятные подписи/токены
5	Контейнеры	Отказ очищает прошлые объекты, Promise.all и операции требуют защиты/валидации	Состояния снимка, реальные подтверждения действий, контекст/права
6	Сертификаты	Сводка, доступность экспорта/операций и конкретный сервер требуют аудита	Неизвестные статусы, действительный экспорт и ошибки API
7	Резервирование	Общий Promise.all четырёх источников, polling задач/интеграций и сохранение требуют аудита	Частичные сбои и состояние job без ложного завершения, форма сохранена
8	Приёмка 11А	Сквозные действия и общие компоненты	Профильная регрессия, production build, снимки, внешние ограничения

Границы

• Права пользователя в профиле и Portal JWT авторизация приложения — разные существующие контракты; не менять правила выдачи доступа в UX исправлениях.
• Сохранение профиля и привязок сейчас несколько HTTP запросов. Не обещать атомарность и не повторять подтверждённое создание после частичного отказа.
• Серверный каталог — зависимость формы прав/привязок; отсутствие доступа или отказ не должен обнулять сохранённые разрешения.
• Backend/моки не подтверждают реальный Portal, PostgreSQL, RouterOS, выдачу сертификатов, восстановление backup или доступность S3. Реальную приёмку перечислять отдельно.
• Оповещения, сбор данных, интеграции, релизы, настройки и расписание диагностики — 11Б.

Блок 11А.2 — достоверная загрузка пользователей (2026-10-01)

• Live не содержит INIT_USERS/демо серверов до API. Пользователи и серверы читаются независимо: быстрый список появляется до медленного каталога; отказ одной зависимости сохраняет другую и последние подтверждённые данные. Unknown KPI — —, подтверждённый пустой список — отдельное состояние.
• Получение пользователей имеет время браузерного чтения и ручной повтор. Смена backend/mode размонтирует прежний контекст, читатели отменяются и поздние ответы не меняют новый экран. Схемы обязательны; дубли ID отклоняются.
• Права users read/write и server read проверены перед запросами/действиями. Без подтверждённых актуальных каталогов редактирование приостановлено; неизвестный общий серверный каталог не показывается числом 0. Icon действия получили имена; «Пригласить» заменено фактическим «Добавить пользователя».
• 12 data E2E + 4 context E2E, профильный lint и TypeScript прошли. Production frontend прошёл в приёмочной сборке после подготовки нового контекста; дальнейшие операции ещё не приняты. Mock ветка подписана как локальное демо.
• Далее 11А.3: lock удаления/сохранения, сохранение диалога/черновика при ошибке, поздние мутации и отдельное подтверждение API от refresh. Затем частичное сохранение привязок без дублей и interface catalog. Реальные Portal/БД ещё не проверены.

Блок 11А.3 — подтверждённое удаление пользователя (2026-10-01)

• DELETE имеет single-flight lock, AbortSignal/30s срок и защиту позднего ответа после размонтирования. Ожидание блокирует повтор/отмену диалога; ошибка остаётся в диалоге с возможностью повторить, target не теряется.
• Удаление требует существующий backend контракт HTTP 204; успешный 200 с произвольным телом не принимается. Подтверждённая строка удаляется сразу, а отказ последующего refresh не называется отказом удаления: API результат и необходимость повторного чтения показаны отдельно.
• 17 data/operations E2E + 6 context E2E, TypeScript и профильный lint прошли. Проверены 403/503/неверный ответ, двойной click, Escape, refresh error, поздний success/error прежнего backend. Созданы общие HTTP-фикстуры пользователей.
• Далее 11А.4: безопасное сохранение профиля/черновика и частичных привязок, без повторного создания при подтверждённом первом шаге. Сохранение ещё не принято; interface catalog и визуальная приёмка далее. Реальный Portal/БД не проверен.

Блок 11А.4 — многошаговое сохранение профиля и привязок (2026-10-01)

• Общий mutation lock, отмена/30s срок каждого запроса, защита прежнего источника; Sheet не сбрасывает черновик при изменении каталога/подтверждённом промежуточном шаге. Во время отправки поля/кнопки и закрытие блокируются.
• UserSaveCheckpoint сохраняет подтверждённый id профиля и каждую привязку. После частичного отказа повтор читает профиль/привязки, обновляет профиль по этому id и продолжает diff без второго POST пользователя/повторной подтверждённой привязки. Потерянный ответ DELETE/POST привязки сверяется чтением. Это несколько HTTP запросов, не атомарная транзакция.
• При неизвестном исходе POST профиля повтор заблокирован; доступно чтение списка, черновик сохранён. 4xx создания допускает исправление/повтор. UI не присваивает найденный по login чужой профиль автоматически. Подтверждённый профиль/привязки отделены от отказа refresh.
• Ответы проверяют userId/login, отправленные поля/права и контекст привязки. Wrong role/sections/servers не подтверждают сохранение. IDs в URL кодируются. Техническая многострочная ошибка схемы заменена понятной краткой ошибкой — иначе footer выходил за экран; обнаружено E2E, исправлено и повторено без ослабления теста.
• 5 fault-injection unit, 27 различных data/operations E2E и 8 context E2E прошли; TypeScript, профильный lint и production frontend прошли. В UserSheet остаётся одна исходная catalog set-state-in-effect ошибка; она входит в следующий блок, suppressions нет.
• Далее 11А.5: строгий interface catalog, loading/error/empty, точный сервер и поздние ответы/peer сбои; затем форма/таблица, клавиатура и ПК/телефон. Реальная БД/Portal не проверены.

Блок 11А.5 — каталог интерфейсов формы (2026-10-01)

• Каталог привязан к serverId/host; ожидание, error и подтверждённое empty различаются. Поздний ответ другого устройства отменяется. При повторе сохраняются прошлые строки/время получения, выбор блокируется до успешного чтения; черновик формы не сбрасывается.
• API схемы отклоняют дубли интерфейсов/пиров, отсутствующий peer snapshot и пустые ключи. Ошибка peers показана явно, не выдаётся за пустой список; выбор неподтверждённого пира блокируется. Перед привязкой выбранные объекты сверяются с текущим каталогом.
• IPsec теперь выбирает конкретного клиента/CN как требует backend; раньше весь ipsec-vpn отправлялся с пустым ключом. WireGuard остаётся выбором public-key. Время handshake/активности не называется текущим подключением.
• Frame scroll имеет высоту родителя и min-h-0 flex цепочку. Демо каталог вычисляется при рендере; последняя исходная UserSheet set-state-in-effect ошибка устранена без suppressions.
• 25 catalog/operations E2E, TypeScript и профильный lint прошли. Проверены API/malformed/дубли/неполные peer данные, empty/loading, поздний success/error другого сервера, WG failure/retry, IPsec CN payload и прежние операции.
• Далее 11А.6: backend достоверность interface catalog (сейчас snapshot/история без метаданных, неизвестные флаги и скрытый IPsec failure); затем UI/доступность и локальная приёмка пользователей. Реальные RouterOS/DB/Portal не проверены.

Блок 11А.6 — backend метаданные каталога интерфейсов (2026-10-01)

• Добавлен /users/interface-catalog-state с serverId/source/sampledAt/inventoryComplete/failures и nullable running/disabled. Старый /interface-catalog и форма interfaces/boolean сохранены для совместимости; новый frontend будет подключён в следующем блоке.
• Явный пустой raw snapshot не заменяется трафиком; malformed snapshot возвращает 502. Missing snapshot допускает явно подписанный fallback только к одной последней дате traffic_samples: SQL ограничен sampledAt, старые интерфейсы/peer/loopback исключены. Unknown флаги не превращаются в false.
• WireGuard/IPsec failure не скрывается за пустыми пирами; каталог IPsec клиентов отдельно от физического состояния интерфейса, running/disabled неизвестны. Неподтверждённые клиенты raw IPsec интерфейса показаны peersError; нет дубля ipsec-vpn.
• Строгий новый контракт и factory DI проверяют serverId, источник/полноту, время, peer keys/дубли и точный контекст ответа. GET остаётся в существующем mm:users:read; правила сетевых действий/авторизации не изменены.
• Backend build, профильный lint, inventory parser и Fastify HTTP тесты прошли. test:users включён в общий test; прежние binding unique/cascade тесты явно skipped из-за отсутствия PostgreSQL. SQL/реальный RouterOS ещё требуют внешней приёмки.
• Далее 11А.7: подключить frontend к state контракту, показать источник/дату/частичные отказы и неизвестное состояние; обновить HTTP-фикстуры и проверить регрессию. Затем визуальная приёмка пользователей.

Блок 11А.7 — frontend state каталог (2026-10-01)

• UserSheet использует /interface-catalog-state, строго проверяет новый контракт и точный serverId. Legacy reader экспортирован для совместимости, новый экран к неоднозначному envelope не возвращается.
• UI отдельно показывает браузерное получение и время/источник среза. Snapshot и частичная traffic history подписаны; unknown не становится пустым каталогом. Nullable running отображается неизвестным состоянием, а исторические флаги не называются текущими.
• Частичные failures интерфейсов/WG/IPsec видны сразу с повтором, включая пустой IPsec failure. IPsec-vpn подписан как каталог клиентов, а не физический интерфейс. Демо и live состояния сохраняют прежнюю композицию Frame/Stepper.
• 44 различных data/operations/catalog E2E + 8 context E2E, TypeScript, профильный lint и production frontend прошли. Фикстуры перенесены на новый state envelope; отдельные negative тесты не дополняют отсутствующие метаданные автоматически.
• Далее 11А.8: семантические токены таблицы/формы, доступные имена, права/клавиатура, ПК/390/320 и снимки. После приёмки пользователей — контейнеры. Реальная БД/RouterOS/Portal остаётся внешней приёмкой.

Блок 11А.8 — доступность и локальная приёмка пользователей (2026-10-01)

• Существующие ReUI Stepper/Data Grid/Frame сохранены. Семантические токены, явные имена действий/прав, aria-pressed/expanded, клавиатурное раскрытие строки, подпись текущего шага. Vendor компоненты и тема не изменены; checklist ReUI проверен.
• Sheet занимает ширину телефона; min-w-0 fieldset удерживает шаги в 320 px, выбор роли переносится вертикально без разрыва слов. Ошибка сохранения внутри области прокрутки, footer остаётся доступен; обязательные поля имеют aria-invalid/describedby и получают фокус.
• Закрытие формы возвращает фокус к актуальной кнопке строки после её замены Data Grid. Найден и исправлен исходный no-op прав: отсутствующие section/server разрешения добавляются при явном выборе; «выбрать всё» охватывает показанные разделы/серверы.
• 48 уникальных data/operations/catalog/layout E2E, 8 context E2E, TypeScript, профильный lint и production frontend прошли. HTTP payload проверен для отсутствующих разрешений. 12 снимков ПК/390/320 сохранены; просмотрены обзор/профиль/каталог/ошибка, горизонтальная прокрутка ограничена таблицей.
• Пользователи приняты в границах локальных HTTP-подмен. Реальные Portal/PostgreSQL/RouterOS остаются внешней приёмкой; прежние DB binding тесты skipped.
• Далее 11А.9: достоверный state API контейнеров. Аудит выявил превращение отказов устройств/envs/mounts в пустые списки, неизвестного статуса в stopped и недостоверное общее empty. Затем подключение frontend, операции и UX; сертификаты/backup ещё не приняты.

Блок 11А.9 — достоверный backend каталог контейнеров (2026-10-01)

• Добавлен GET /api/containers/state с общим collectedAt и состояниями каждого enabled сервера. available + [] означает подтверждённую пустую загрузку, unsupported — отсутствие /container, error — отказ чтения. Сбой одного устройства сохраняет остальные.
• Загрузка envs/mounts независима, partial failures явно включены в контракт. Неизвестные status/startOnBoot не становятся stopped/false; отсутствующий образ не подменяется именем контейнера; нулевые CPU/RAM сохранены.
• Runtime контракт отклоняет отсутствующие/дубли RouterOS ID, чужой serverId, неверные состояния/даты и дубли устройств/ошибок. Новый reader не выдаёт синтетический rosId для сетевого действия.
• Старые /containers и /servers/:id/containers, mapper и сетевые операции сохранены для совместимости. RBAC соответствует существующим правилам: каталог dashboard read, команды server write; новых разрешений не введено.
• Backend build, профильный lint, новые service/HTTP tests и старый mapper test прошли. test:containers включён в общий test. Тесты без PostgreSQL/RouterOS; реальные чтения ещё требуют внешней приёмки.
• Далее 11А.10: frontend state reader, независимые серверы/контейнеры, последний снимок, unknown KPI, свежесть и защита смены источника. Затем подтверждённые команды, доступность/ПК/телефон.

Блок 11А.10 — frontend состояния контейнеров (2026-10-01)

• Live читает строгий /containers/state и отдельно /servers; slow/error одной зависимости не скрывает другую. Duplicate server IDs отклоняются. До подтверждения нет демо/ложного empty, неизвестные KPI и rail counts — —.
• Последний успешный снимок сохраняется при общем отказе и отдельно по устройству при частичной ошибке. Неизвестный status виден явно; envs/mounts partial, unsupported и known empty различаются. Браузерное получение каждого каталога подписано.
• Ключ backend/mode и prefsHydrated изолируют контекст; AbortController/revision/30s защищают чтение. Исчезнувший выбранный сервер не заменяется «всеми». Права соответствуют существующим dashboard read/server read/write; без свежих необходимых каталогов команды блокируются.
• Неподключённая кнопка создания disabled. Существующая композиция Frame/KpiStatGrid/ServerRail сохранена; семантическая и мобильная приёмка впереди.
• 14 data E2E, 4 source-context E2E, TypeScript, профильный lint и production frontend прошли.
• Далее 11А.11: single-flight команд, строгий ok:true, подтверждение API отдельно от фактического состояния/refresh, диалог удаления и поздние мутации. Затем экспорт/доступность/ПК/390/320. Реальный RouterOS/БД остаётся внешней приёмкой.

Блок 11А.11 — подтверждённые команды контейнеров (2026-10-01)

• POST start/stop/restart/remove проходит через typed reader со строгим ok:true, проверкой serverId/rosId и 30s сроком. Single-flight ref блокирует все карточки; поздние ответы после ухода/смены backend не меняют UI.
• Текст результата подтверждает команду API, фактический статус определяется повторным чтением. Ошибка refresh не отменяет подтверждение; подтверждённо удалённая карточка убирается до чтения.
• Удаление использует устойчивый AlertDialog с target/ошибкой/повтором. Ожидание блокирует Escape/отмену. 4xx — отклонение, malformed/network/5xx — неподтверждённый или частичный результат; новое действие требует явного чтения каталога. Исчезнувший target повторно не отправляется.
• 26 data/operations E2E, 8 context E2E, TypeScript, профильный lint и production frontend прошли. Модель сетевых команд/авторизации backend не менялась; реальные операции RouterOS требуют внешней приёмки.
• Далее 11А.12: доступность, семантические токены, ПК/390/320 и достоверность экспорта/метрик. Аудит экспорта выявил шаблонные veth IP и команды, которые не являются экспортом реального устройства; это нельзя выдавать за резервную конфигурацию.

Блок 11А.12 — достоверный снимок и интерфейс контейнеров (2026-10-01)

• Недостоверный генератор RSC (шаблонные IP veth, неподтверждённые настройки и некорректные env команды) заменён JSON-снимком каталога в существующем CodeExportSheet. Файл содержит наблюдаемые поля, collectedAt, source и partial failures; явно подписан как снимок, не конфигурация/backup.
• memory-high — лимит памяти по MikroTik Container, расход RAM теперь только memory-current (МиБ); отсутствие метрики не становится 0. Новые RouterOS list/mountlists и несколько envlist обрабатываются; неполные env/mount ответы становятся partial error.
• Семантические токены, русские статусы, aria имена/pressed, поиск/переносы и 44px меню на телефоне. Sheet на всю ширину, footer переносится на 320 px через props; vendor/theme и композиция Frame/ServerRail/KpiStatGrid не изменены. Неизвестный статус не предлагает запуск/перезапуск; KPI по статусам — —.
• 30 уникальных data/operations/layout E2E суммарно прошли (последний полный прогон 29/30, оставшийся narrow исправлен и все 4 layout повторно прошли); 8 context E2E, backend tests/build, TypeScript, профильный lint и production frontend прошли. Скачанный JSON проверен; 6 снимков сохранены и просмотрены.
• ReUI checklist проверен в границах адаптации. Далее 11А.13: URL-контекст и clipboard отказ/фокус, затем локальная приёмка контейнеров и аудит сертификатов. Общие ошибки Clipboard в CodeExportSheet требуют обработки; реальный RouterOS/БД ещё не проверен.

Блок 11А.13 — контекст и локальная приёмка контейнеров (2026-10-01)

• URL восстанавливает server/status/q, поддерживает Back/reload, сохраняет чужие параметры/hash. Дубли, неверные ID/status и слишком длинный поиск показывают ошибку со сбросом. Использован существующий preserveSelection ServerRail; исчезнувшее устройство не заменяет контекст.
• Устранены Clipboard rejection/отсутствие API в общей CodeExportSheet: сообщение с повтором/скачиванием вместо ложного «Скопировано». Бейдж относится к конкретному скопированному тексту; прежний каскадный effect заменён контролируемым сбросом при открытии/изменении начального формата. Дизайн/vendor/theme сохранены.
• Закрытие снимка и отмена удаления возвращают фокус к актуальной кнопке карточки; после исчезновения карточки предусмотрен fallback на обновление.
• 40 контейнерных E2E, 8 source-context, 10 профильных проверок экспорта, URL unit, TypeScript, профильный lint (включая общую оболочку) и production frontend прошли. Backend state тесты/сборка приняты в 11А.12. Контейнеры приняты локально; создание/логи/редактирование явно disabled, реальный RouterOS/БД требует внешней проверки.
• Далее 11А.14: observed state API сертификатов. Исходный mapper делает отсутствующий срок daysLeft=0, status=valid, keySize=0/trusted=false; это нельзя выдавать за наблюдаемые значения. Legacy API/renew/issue должны сохранять совместимость до отдельной миграции; frontend, ACME jobs, настройки и экспорт сертификатов ещё не приняты.

Блок 11А.14 — observed state API сертификатов (2026-10-01)

• Добавлен совместимый GET /certificates/state: collectedAt, отдельные enabled устройства, подтверждённые строки или error. Новое чтение /certificate не использует tolerant getCertificates, скрывавший неверный ответ как [].
• Новый CertificateObserved не подменяет отсутствующие срок/keySize/trusted/rosId. daysLeft nullable, status unknown; даты без часового пояса/некорректного календаря остаются raw полями и не используются для вычисления срока. Известные UTC/offset даты нормализованы; valid требует известных сроков и сведений об отзыве. Неизвестный будущий/неполный сертификат не становится valid.
• Контракт отклоняет дубли/чужой контекст, несогласованные срок/статус и error со строками. Частичный отказ одного устройства сохраняет остальные; общий DB отказ — HTTP 500, неверный envelope — 502.
• Legacy DTO/API, parser ролей, ACME issue/renew и сетевые операции сохранены для совместимости. Frontend ещё читает legacy; эти сценарии не приняты и требуют последующей миграции.
• Backend build, профильный lint, observed service/HTTP tests и прежний certificate-parse test прошли. test:certificates включён в общий test. PostgreSQL/RouterOS/ACME не использованы в тестах; локальные bare-time даты требуют отдельной проверки часового пояса устройства.
• Далее 11А.15: typed frontend reader и immutable merge последних снимков; затем 11А.16 — таблица/детали/unknown KPI, partial сбои, freshness, контекст/права. ACME settings/jobs/экспорт — последующие блоки. Резервирование, 11Б и итоговый 12 ещё не приняты.

Блок 11А.15 — typed reader и последние снимки сертификатов (2026-10-01)

• readCertificatesState использует строгий новый контракт, GET, caller AbortSignal + 30s срок. Unknown поля сохраняются; malformed/duplicate/чужой контекст, 204 и ошибки HTTP не становятся успешным пустым каталогом.
• mergeCertificateSnapshots хранит latest отдельно от confirmed: отказ устройства сохраняет последний успешный снимок с его временем, первоначальный отказ имеет confirmed=null. Подтверждённое empty очищает строки; исчезнувшие enabled устройства удаляются; восстановление заменяет свой снимок без мутации прежнего состояния.
• 5 fault/HTTP unit, TypeScript, профильный lint и production frontend прошли. Reader/merge готовы к подключению; текущая страница ещё использует legacy DTO. Приёмка сертификатов не завершена.
• Далее узкая проверка setup ошибки клиента устройства (11А.16), затем миграция страницы/таблицы/деталей на observed nullable поля и независимые состояния. Не заменять null числом 0/false, не терять partial rows и выбранный сервер; ACME settings/jobs/экспорт проверять отдельными блоками.

Блок 11А.16 — изоляция setup ошибок устройств (2026-10-01)

• В обоих новых state каталогах создание клиента/reader перенесено внутрь защищённого чтения устройства. Setup исключение одного клиента становится его error/partial, остальные строки остаются доступны; общий каталог не срывается.
• Container reader создаётся один раз и используется для /container/envs/mounts. Certificate reader остаётся отдельным для каждого устройства; сетевые команды, Legacy API и авторизация не изменены.
• Fault тесты setup для обоих каталогов, test:containers, test:certificates, backend build, профильный lint и diff check прошли. Frontend production/TypeScript проверены в 11А.15; новых frontend изменений в этом блоке нет.
• Последняя квота: 96% пятичасового и 77% недельного использовано. Новый большой блок не начинать при этом остатке; продолжить после проверки актуальной квоты.
• Точный следующий шаг — 11А.17: подключить readCertificatesState + mergeCertificateSnapshots в app/(main)/certificates/page.tsx. Мигрировать CertificatesDataGrid и CertificateExpandedDetail на CertificateObserved/совместимый view type без nullable→0/false; обновить фильтры/KPI, independent server read, error/partial/freshness, prefsHydrated/key backend-mode и отмену/revision чтения. Проверить live HTTP failures/unknown/empty/partial/recovery/права/смену источника, TypeScript/lint/build, обновить журнал и сделать локальный коммит без push.
• Далее отдельными блоками ACME settings и renew, issue job polling/частичное выполнение, реальный экспорт/импорт сертификатов, UX/ПК/390/320. Резервные копии, 11Б и общий 12 ещё не приняты; реальные RouterOS/Portal/PostgreSQL/ACME/S3 проверки остаются внешними.

Подключение observed сертификатов: следующий блок 11А.17

Референсы: существующий Data Grid Filtering 2 / Sheet 8. Сохранить композицию DataGrid v9/Frame/ServerRail и семантические токены.

Данные	Сейчас в legacy UI	Требование observed UI
Срок отсутствует / дата без timezone	daysLeft=0, возможный valid	—, raw дата с пояснением, unknown; не включать в подтверждённо действительные/истекающие
keySize/trusted отсутствуют	0 / false	Размер/доверие неизвестны, действия определяются API/правами
Отказ одного устройства	Общий error или краткий toast	latest.error постоянно виден, confirmed строки/время сохранены
Начальный отказ	Пустая таблица/нули	Список и KPI неизвестны, явный повтор
Подтверждённое empty	Пустая таблица	Известный пустой каталог и нули; очищает предыдущий снимок
Смена источника	Общий эффект старого контекста	Изолированный key + отмена/revision; поздний ответ не меняет новый экран

[Источник и права] → [Независимые state + servers]
                           ↓
                  [latest ошибка / confirmed снимок]
                           ↓
             [KPI известных данных → таблица → детали]
                           ↓
               [ACME/экспорт: последующие блоки]

Проверенные заготовки: shared/api/certificates.ts (readCertificatesState), lib/certificate-snapshots.ts, новый contracts CertificateObserved. Legacy API/renew/issue ещё используются, их миграцию не считать завершённой.

Блок 11А.17.2 — state каталог на странице сертификатов (2026-10-01)

• Страница читает readCertificatesState и независимо строгий каталог серверов. Снимки сохраняются при общем/частичном отказе; подтверждённое empty очищает прежние строки. Отображаются время каталога и время последнего успешного чтения каждого устройства.
• useCertificateCatalog отменяет чтения при unmount/смене источника, использует revision и общий срок 30s. Результат одного источника не ждёт другой; источники разделены key mode/backend после prefsHydrated.
• Неизвестная/частичная сводка показывает — с объяснением, фильтр неизвестных статусов доступен. Выбор сервера сохраняется при отказе каталога; неизвестный статус сервера не превращается в offline на rail.
• Refresh теперь повторяет строгий GET state, не подмешивает legacy DTO и не объявляет частичный результат полным успехом. Write-действия требуют права сертификатов, выпуск также требует доступного каталога серверов. Неподключённый импорт отключён вместо ложного сообщения об успехе.
• 12 профильных HTTP E2E, TypeScript, ESLint и production frontend прошли. API контракт/сетевые правила не менялись.
• Следующий блок 11А.17.3: URL server/status/q и проверки позднего ответа при смене mode/backend. Затем отдельные блоки ACME/renew, issue polling, UI/экспорт и приёмка. Сертификаты в целом, резервные копии, 11Б/12 не приняты; реальные RouterOS/ACME/Portal проверки остаются внешними.

Блок 11А.17.3 — URL и изоляция источника сертификатов (2026-10-01)

• server/status/q читаются из URL: reload/Back сохраняют контекст, чужие параметры и hash не теряются. Дубликаты, неизвестные статусы, некорректные ID и слишком длинный поиск явно отклоняются; сброс не удаляет чужой контекст. Mock srv ID поддержан отдельно.
• Недоступный сервер не заменяется всеми устройствами; ошибка ссылки скрывает строки. Нет совпадений отличается от подтверждённого пустого каталога. Моковые данные подписаны явно.
• 3 URL unit, 6 URL E2E и 4 E2E смены backend/mode с поздним успехом/ошибкой прошли. ESLint/TypeScript прошли; production сборка URL/Suspense прошла до финального добавления подписи моков, после него повторены TypeScript и E2E.
• Далее 11А.18: строгие ответы/отмена API ACME/renew/issue, затем достоверные формы настроек и issue checkpoint/polling. Настройки, выпуск и общая приёмка сертификатов пока не приняты.

Блок 11А.18 — строгие API настроек и выпуска сертификатов (2026-10-01)

• ACME/renew settings и issue request/ответы проверяются существующими contracts схемами. Malformed/204 не считаются успешным сохранением; пустой jobId и чужая задача в polling отклоняются. Legacy list/refresh тоже валидируют DTO.
• Все certificate API принимают caller AbortSignal вместе со сроком 30s. Ошибка Cloudflare с backend message сохраняет понятную причину вместо HTTP Bad Request. Payload проверяется до mutation запроса.
• 5 новых API fault тестов + 5 snapshot/reader тестов, TypeScript и профильный ESLint прошли. Следующий блок 11А.19 — достоверное чтение и сохранение renew настроек, затем ACME и issue polling. Реальные ACME/RouterOS операции пока не приняты.

Блок 11А.19 — достоверные настройки автообновления (2026-10-01)

• Renew форма начинает с unknown, а не enabled/default расписания. Ошибка чтения оставляет операции заблокированными до подтверждённого GET; есть явный повтор и отдельные read/write права. Read-only не выдаётся за недоступный backend.
• Числа проверяются без parseInt/default/clamping: целый интервал от 300 и срок 1–90. Ошибка/204/malformed PUT сохраняет подтверждённое состояние и dirty черновик. Переключатель меняется только после подтверждения, toggle/schedule имеют общий синхронный lock.
• Фоновый GET не стирает dirty черновик; запросы отменяются при unmount, поздний ответ не меняет другой источник и не показывает старый toast. Disabled MM не объявляется доказательством включённого RouterOS ACME.
• 10 renew E2E, повторные 12 data E2E, 2 context E2E позднего PUT, TypeScript/ESLint и production frontend прошли. HTTP fixtures приведены к реальному renewBeforeDays контракту.
• Следующий блок 11А.20: выделить достоверную форму ACME, неизвестное чтение, сохранение черновика/токена, общий lock save/test и отмена; затем issue checkpoint/polling и приёмка сертификатов.

Блок 11А.20 — достоверная форма ACME (2026-10-01)

• ACME форма выделена в собственный компонент с прежней OpsPanel/ReUI композицией. До подтверждённого GET настройки и состояние токена неизвестны; read-only читает фактические значения, сохранение/тест требуют write права.
• Dirty URL/zone/token сохраняются при фоновом чтении и отказе PUT. Токен очищается только после валидного подтверждения; tokenConfigured=false при отправленном токене не считается успехом. Пустое поле сохраняет прежний секрет на backend.
• Save/test имеют общий синхронный lock и блокируют поля на время операции; test не объявляется сохранением. Ошибка Cloudflare видна с причиной. При unmount запросы отменяются, старые ответы/toast не попадают в другой источник.
• 10 ACME E2E, 2 поздних PUT context E2E, 2 read-only E2E, TypeScript/ESLint и production frontend прошли.
• Следующий блок 11А.21: совместимость реального issue DTO (backend serverId сейчас числом, failed step не включён в контракт), затем сохранение job checkpoint и отмена polling без повторного POST. Выпуск/общая приёмка сертификатов, backups/11Б/12 остаются незавершёнными.

Блок 11А.21.1 — совместимость issue DTO (2026-10-01)

• Реальный backend issue DTO теперь преобразует числовой PostgreSQL serverId в строковый ID контракта; результат проверяется схемой вместо приведения step через as. JSON/JSONB имена доменов поддержаны, malformed значения отклоняются.
• В enum шага добавлен failed, который уже записывает runner. Ошибка задачи и finishedAt сохраняются, а не теряются при frontend strict parse. Сетевой runner/порядок операций и правила прав не менялись.
• 4 DTO unit, backend test:certificates/build, профильный ESLint, повторные 10 frontend API/snapshot unit и frontend TypeScript прошли.
• Далее 11А.21.2: poll helper с отменой и проверкой ожидаемого server/name/domains, затем сохранённый checkpoint на странице и live HTTP fault тесты повторного нажатия/ошибки/смены источника.

Блок 11А.21.2 — отменяемое наблюдение issue задачи (2026-10-01)

• pollCertificateIssue проверяет jobId, сервер, имя и домены перед наблюдением результата. queued/running не считаются успехом; done требует шага done. failed возвращает реальную ошибку задачи.
• Caller abort отменяет задержку и блокирует позднее наблюдение; polling ограничен 120 чтениями и сроком 5 минут, каждое HTTP чтение имеет свой срок. Ошибка GET/истечение наблюдения не объявляются failed задачей и не запускают новый POST.
• 5 fault unit и TypeScript/ESLint прошли. Helper пока не подключён к форме.
• Следующий блок 11А.21.3: повторяемое создание issue с устойчивым requestId на backend, затем frontend checkpoint и возобновление наблюдения. Это необходимо, чтобы потеря POST ответа не провоцировала второй выпуск.

Блок 11А.21.3 — устойчивое создание issue задачи (2026-10-01)

• В запрос выпуска добавлен необязательный UUID requestId. Backend использует существующий primary key задачи и INSERT ON CONFLICT DO NOTHING: повтор идентичной цели возвращает тот же jobId без повторной очереди, другая цель/source с тем же ID получает 409. Старые клиенты без requestId продолжают получать независимые UUID. Миграция БД не нужна.
• Request ID сохраняется и проверяется frontend API; чужое подтверждение отклоняется. Server ID должен быть безопасным положительным целым, имя/домены не могут быть пустыми после trim. Контракт нормализует поля перед созданием.
• 4 request helper unit (включая конкурентный повтор), HTTP handler fault проверки, backend test:certificates/build, 6 frontend API unit, polling unit, frontend TypeScript и профильный lint прошли. Проверки helper/HTTP используют тестовый repository; реальный PostgreSQL INSERT и RouterOS выпуск остаются внешней приёмкой. Runner и сетевой порядок операций не менялись.
• Следующий блок 11А.21.4: frontend checkpoint с заранее созданным requestId и неизменной целью, resume GET/poll без нового ID, сохранение в пределах источника, отмена и HTTP fault/context проверки.

Блок 11А.21.4 — сохраняемая задача выпуска на странице (2026-10-01)

• До POST создаётся requestId и immutable цель, записывается checkpoint sessionStorage по backend URL. Невозможность первоначальной записи не отправляет выпуск. Reload восстанавливает ту же задачу; моковый режим не показывает live checkpoint. Повреждённая запись блокирует новый выпуск.
• Принятый job повторно наблюдается GET/poll без POST. Неподтверждённый запрос сначала проверяет известный ID; при 404 повторяет тот же POST/requestId, защищённый backend от дублей. Read/write права разделены. Ошибка GET/чужая цель не считаются успешным или failed выпуском.
• Sheet/Stepper сохраняют цель и блокируют её изменение после принятия; реальный failed и частичное выполнение показаны явно. Новый выпуск после terminal требует отдельного действия и начинается с пустого имени/доменов. Закрытие формы не объявляется отменой server job. После done ошибка перечитывания каталога не меняет результат задачи. Неподключённый FileImportDialog с ложным callback удалён.
• При unmount отменяются POST/poll/задержки; поздние успех/ошибка не меняют другой backend/mode и не показывают старый toast.
• 3 checkpoint + 5 poll unit, 7 issue E2E, 8 source/context E2E, TypeScript/ESLint и production frontend прошли. Реальный PostgreSQL/ACME/RouterOS выпуск не проверен; pending job восстановление после перезапуска backend требует отдельной инфраструктурной приёмки.
• Следующий блок 11А.22: семантические токены, клавиатура/ПК/390/320, снимки и профильная регрессия сертификатов. Импорт/экспорт приватного ключа остаются явно недоступны; безопасный JSON снимок каталога можно добавить отдельно. Затем резервные копии и 11Б/12.

Блок 11А.22 — визуальная и профильная приёмка UI сертификатов (2026-10-01)

• Состояния таблицы/предупреждений используют semantic success/warning/destructive. Раскрытие деталей имеет native кнопку с именем, aria-expanded и клавиатурой; исходные нераспознанные даты RouterOS показываются явно без подмены нормализованной датой.
• Общее количество остаётся известным при неизвестных статусах/сроках, отдельные классификации показывают —. Мобильный фильтр сохраняет подписи в горизонтальном контейнере; Sheet использует full width через data-side вариант, footer переносится. Vendor/theme не изменены.
• 9 PNG (обзор/детали/форма × ПК/390/320) сохранены и просмотрены. Layout проверки включают отсутствие горизонтального overflow страницы/формы, клавиатурное раскрытие, поиск и возврат фокуса после Escape.
• Профильная регрессия: 48 main E2E + 16 context E2E, 26 frontend unit, backend test:certificates, frontend/backend production build, TypeScript/профильный ESLint и ReUI checklist прошли. Реальные PostgreSQL/ACME/RouterOS/S3 не проверялись.
• UI сертификатов принят в этих локальных границах. При сверке runner найден отдельный дефект: ошибка appendEvent после успешного выпуска попадает в общий catch и записывает failed; fire-and-forget onStep может перезаписать terminal шаг.
• Следующий блок 11А.23: отделить события/ошибки метаданных runner от результата реальной операции, упорядочить onStep записи, защитить terminal от повторного запуска и cleanup lock при setup ошибке; fault unit/backend checks. Затем метаданные JSON snapshot/окончательная приёмка сертификатов и резервные копии.

Экраны сертификатов

Область	Проверенные изображения	Схема
Обзор	ПК, 390, 320	Свежесть → известный итог / неизвестные классификации → настройки → таблица
Детали	ПК, 390, 320	Фильтр → native раскрытие → поля и unknown → исходные даты
Выпуск	ПК, 390, 320	Цель → проверка → requestId → та же задача → подтверждение API

Блок 11А.23 — достоверный результат backend issue runner (2026-10-01)

• События и ошибки записи прогресса отделены от результата ACME/RouterOS. Ошибка appendEvent после успеха не записывает failed; ошибка итоговой записи остаётся ошибкой наблюдения, без повторного импорта. Очередь перехватывает setup rejection, process lock освобождается при любой ошибке.
• onStep записи выполняются последовательно и завершаются перед terminal. Done/failed/running записи не запускают сетевую операцию заново; восстановление running после перезапуска требует отдельной инфраструктурной сверки, автоматический replay не добавлен.
• Реальная фаза dns_a_sync добавлена в контракт. Диагностические callback строки Cloudflare сохраняются отдельными событиями, старые DB строки читаются как dns_a_sync. Порядок ACME/DNS/RouterOS не изменён.
• 10 fault unit runner, 5 DTO unit, полный backend test:certificates/build, 14 frontend API/poll/checkpoint unit, TypeScript и профильный ESLint прошли. PostgreSQL/ACME/RouterOS остаются внешней приёмкой; lock действует в одном процессе, распределённый lease не реализован.
• Следующий блок 11А.24: закрыть локальную приёмку сертификатов с явными ограничениями и начать строгие API-контракты резервных копий. JSON metadata snapshot необязателен; PEM/private key import/export остаётся недоступным.

Блок 11А.24 — локальная приёмка сертификатов и API резервных копий (2026-10-01)

• Сертификаты приняты локально по 11А.14–11А.23: state/unknown/частичные сбои, URL, права, renew/ACME формы, checkpoint выпуска и runner, 48 main + 16 context E2E и ПК/390/320 снимки. После runner исправления backend профиль/10 fault unit/5 DTO unit, frontend API/poll/checkpoint и production сборки прошли. Реальный PostgreSQL, ACME, RouterOS, восстановление running после рестарта и распределённая блокировка остаются внешней приёмкой. PEM/private key import/export не реализованы; JSON metadata snapshot не обязателен для принятого объёма.
• Backups API использует общие Zod-контракты: список без дублей, обязательное storage, корректные даты/размеры; job counters и результаты согласованы, terminal имеет время окончания, чужой ID не принимается. Partial done с failures остаётся частичным результатом. Удалён неиспользуемый createBackups, ожидавший синхронные created вместо фактического job ack.
• Настройки и ответы restore/test/sync проверяются, запросы принимают AbortSignal и 30s срок. DELETE требует фактический HTTP 204, IDs кодируются. Некорректный запрос создания/расписания отклоняется до HTTP; известные false/0/empty не подменяются.
• 6 API fault unit, frontend TypeScript/профильный ESLint, backend и frontend production build прошли. Backups UI/операции ещё не приняты: Promise.all, отсутствие source/mode/RBAC guard, сброс черновика, повтор POST, интервал polling и ошибки событий требуют следующих блоков. Реальные PostgreSQL/RouterOS/S3 не проверялись.
• Следующий блок 11А.25: независимые подтверждённые каталоги backups/servers/schedule/storage, source guard и read/write права, initial/empty/stale/partial состояния. Далее формы настроек, создание/опрос, restore/delete/download и визуальная приёмка.

Блок 11А.24.1 — актуальная E2E-фикстура резервных копий (2026-10-01)

• Полный TypeScript после строгого BackupItem обнаружил старую admin-tables фикстуру без обязательного storage. Добавлено фактическое local; API-схема не ослаблена.
• Повторный полный TypeScript и 2 существующих E2E резервных копий (сортировка/подтверждение удаления, Filters) прошли. Production frontend/backend и API unit выполнены в 11А.24.
• Далее 11А.25: независимые каталоги, права и источник страницы.

Блок 11А.25 — независимые каталоги резервных копий (2026-10-01)

• После hydration страница привязана к mode/backend. Live не начинает с демонстрационных строк; mock использует локальный каталог с явной подписью и отключёнными операциями. Запросы отменяются при unmount/новом чтении, revision подавляет поздние ответы.
• История, серверы, расписание и хранилище читаются независимо с отдельными known/error/receivedAt. Отказ/медленный ответ зависимости не скрывает историю. Initial unknown, loading, подтверждённый empty и старый подтверждённый список различаются; ручной повтор и время чтения показаны. 0 байт остаётся 0 Б.
• Read/write/server read права проверены перед запросами/действиями. Создание требует актуальный каталог серверов и хранилища; удаление/restore отключены для reader, download требует read. Restore для удалённого serverId недоступен.
• Фоновое чтение не сбрасывает dirty черновики. Сводка расписания/назначения берётся из подтверждённых DTO; draft не называется сохранённым. UI настроек пока ожидает оба DTO, отдельные формы/валидация/частичное сохранение входят в следующий блок.
• 12 data E2E + 2 существующих table/Filters E2E + 4 context E2E, полный TypeScript, профильный ESLint и production frontend прошли. Реальные PostgreSQL/RouterOS/S3 не проверены.
• Следующий блок 11А.26: backend достоверность резервного копирования/restore при сбоях журнала событий. Затем 11А.27 формы настроек, dirty/секреты/проверка S3/общий lock, создание и polling, delete/restore/download, URL и визуальная приёмка. Весь backups ещё не принят.

Блок 11А.26 — результат операций отделён от событий (2026-10-01)

• Ручной job и restore используют безопасную запись событий: отказ журнала не прерывает запуск, не превращает созданные файлы в failed и не возвращает ошибку после подтверждённого импорта RouterOS. Process job вынесен в тестируемую функцию; map задач локален экземпляру routes.
• Создание использует общий строгий request контракт, поддерживает прежние numeric IDs. Дубли/невалидные/отсутствующие выбранные серверы отклоняются до создания задачи; молчаливое выполнение только части запроса удалено. Frontend ack проверяет total всех выбранных целей.
• Персональные ошибки остаются partial done с created/failures. Ошибка S3 загрузки сохраняет локальную копию и uploadError; итоговое событие имеет warning и число ошибок загрузки. Frontend polling пока требует отдельной доработки, чтобы не называть такой done полным успехом.
• 3 fault unit job, HTTP handler проверки create/restore при отказах событий, invalid target/no side effect/partial/RBAC, test:backups (включая S3 client), backend production build, 6 frontend API unit, TypeScript/профильный lint прошли. Реальный PostgreSQL/RouterOS/S3 не проверен; jobs in-memory теряются после рестарта, requestId/idempotency ещё не реализованы.
• Следующий блок 11А.27: достоверные формы расписания/хранилища, independent known состояния, dirty/секреты/partial save/общий mutation lock и S3 test без скрытого сохранения. Далее 11А.28 создание/checkpoint/polling; scheduler event/setup cleanup дополнительно проверить в 11А.26.1 или 11Б.

Блок 11А.27.1 — независимое сохранение настроек и расписания (2026-10-01)

• Расписание и хранилище имеют отдельные кнопки/PUT/подтверждения. Отказ одного DTO не скрывает известную соседнюю форму. Общий settings lock защищает save/test/sync от повторов; поля заблокированы на время отправки, старый GET отменяется. Unmount отменяет мутацию и подавляет поздние toast/state.
• Числовой черновик сохраняет blank/дробный/выходящий за диапазон ввод: значения не clamp/parseInt. Валидация 0–23/0–59/1–28/1–365 до HTTP. Доступны произвольные минуты. Точный формат сохраняется; enabled binary backup требует явного выбора поддерживаемого .rsc. Недоступность .backup не заменяется обещанием «скоро».
• Пустой список serverIds обозначает явный режим всех включённых устройств, включая будущие; пустой ручной выбор не отправляется. Устаревшие выбранные IDs требуют изменения/обновления. Backend семантика расписания не изменена.
• API подтверждает отправленные поля и наличие нового секретного ключа. Ошибка остаётся в постоянном Alert/черновике; только подтверждённый save очищает secret. Test/sync S3 используют сохранённую конфигурацию и не делают скрытый PUT; dirty форма просит явно сохранить её.
• 10 helper/API unit, 12 data + 9 settings E2E (повтор после исправления a11y имени checkbox), 8 context E2E, полный TypeScript/профильный ESLint и production frontend прошли. Реальные PostgreSQL/RouterOS/S3 не проверены.
• Следующий блок 11А.27.2: валидация S3/доступные имена полей, корректная свежесть последнего теста при изменении конфигурации, секрет/невалидный ack/API error/test без PUT и профильная проверка. Затем создание/checkpoint/polling, остальные операции и визуальная приёмка.

Блок 11А.27.2 — достоверные настройки и последняя проверка S3 (2026-10-01)

• S3 форма валидирует обязательные Bucket/Access key/Secret key или наличие сохранённого секрета, HTTP(S) Endpoint. Пустое secret поле оставляет существующий ключ; пробельный новый ключ отклоняется. Поля и toggles имеют доступные имена. Dirty настройка имеет статус «Не сохранено», показ/скрытие секрета не считается изменением конфигурации.
• Backend сбрасывает lastTestAt/error при фактическом изменении S3-конфигурации/ключей. Test запись проверяет updatedAt через условный UPDATE; изменившаяся конфигурация требует повторной проверки. UI показывает «Проверено ранее» и дату, не Connected; API error с подтверждённым settings обновляет последний receipt. Реальный PostgreSQL optimistic UPDATE ещё требует внешней приёмки.
• Совместимость строгого backup API с PostgreSQL подтверждена mapper unit: raw timestamp преобразуется в ISO того же момента. Null server/0 byte/uploadError сохраняются; invalid дата/размер отклоняются. Сравнение timestamp receipt учитывает представление PostgreSQL, а не только строковое равенство.
• 28 data/settings/storage E2E, 11 frontend helper/API unit, 3 DTO + 3 storage update + 3 job fault unit и HTTP/S3 профиль, frontend/backend production build, TypeScript/профильный ESLint прошли. Реальные PostgreSQL/RouterOS/S3 и конкурентные внешние клиенты не проверены.
• Следующий блок 11А.28: single-flight создание, immutable цель/checkpoint, наблюдение без setInterval гонок и ложного полного успеха при failures/uploadError. Jobs сейчас in-memory: рестарт backend означает потерю наблюдения; автоматический повтор неизвестного POST недопустим. Затем delete/restore/download, URL, scheduler cleanup и визуальная приёмка.

Блок 11А.28.1 — идентичность задачи и основа наблюдения (2026-10-01)

• Create request принимает необязательный UUID requestId; job/ack содержат canonical serverIds, job содержит заметку. Повтор той же цели/заметки в том же backend процессе возвращает прежний job; конфликт ID возвращает 409. Конкурентный повтор после async catalog lookup резервируется одним Map insert, без второй очереди. Старые клиенты без ID получают отдельные UUID.
• Событие запуска записывается независимо от очереди/ack, чтобы медленный журнал не держал запуск. GET job контракт проверяет цель, число устройств и принадлежащие ей created/failures. API ack проверяет request ID/все serverIds, неизвестное тело не подтверждает операцию.
• Добавлены строгий checkpoint по backend URL и serial polling helper: immutable request до POST, cross-check наблюдения, AbortSignal/срок чтения/наблюдения, read failure/timeout не становятся failed server job. Outcome отличает полный успех от device failures и uploadError.
• 16 frontend API/checkpoint/poll unit, backend test:backups с HTTP concurrent retry/conflict/RBAC, backend production build, полный TypeScript/профильный ESLint прошли. UI пока использует старое создание/setInterval; подключение в следующем блоке.
• Jobs/idempotency Map существуют только в текущем процессе. После рестарта API может вернуть 404 для ранее принятой операции; автоматический повтор неизвестного POST не реализован и недопустим без durable repository. Реальные DB/RouterOS/S3/рестарт не проверены.
• Следующий блок 11А.28.2: frontend checkpoint до POST, общий lock формы, GET-only resume/после reload/неизвестного ответа, точный partial результат, поздние ответы источника и профильные E2E. Затем остальные операции/URL/визуальная приёмка.

Блок 11А.28.2 — сохраняемая задача создания резервных копий (2026-10-01)

• До POST сохраняется immutable requestId/serverIds/заметка в sessionStorage по backend URL. Первичная ошибка записи не отправляет запрос. Форма блокирует изменение цели после передачи; закрытие не объявляется отменой server job. При подтверждённом 4xx создания черновик остаётся доступным для исправления.
• Reload/неизвестный POST восстанавливает ту же задачу. Любой resume выполняет только GET/serial polling: 404 in-memory job означает неизвестный результат/возможный рестарт, не разрешение второго POST. Некорректный checkpoint/чужая цель не допускают новое создание. New task доступен только после известного terminal и отдельного действия.
• Done с device failures/uploadError показывает подтверждённый частичный результат и созданное количество; полный success требует всех файлов без ошибок. Неуспешное перечитывание истории отдельно сохраняет подтверждение job. Общий lock формы исключает двойной POST; settings при активном/неизвестном job недоступны.
• Late POST/poll/задержки отменяются при unmount и не меняют другой backend/mode, не показывают старый toast. Sheet адаптирован full width через data-side вариант; footer переносится, цель и job ID сохраняются.
• 9 job E2E + 28 data/settings/storage регрессии, 16 context E2E, TypeScript/профильный ESLint/production frontend прошли; helper/backend проверки выполнены в 11А.28.1. Реальные PostgreSQL/RouterOS/S3/рестарт не проверены; durable job repository отсутствует.
• Следующий блок 11А.29: delete/restore/download: synchronous locks, контекст/отмена, точное подтверждение цели и отделение API результата от refresh; backend partial cleanup и правила восстановления проверить. Затем URL, Frame/адаптивность, scheduler cleanup и приёмка backups.

Блок 11А.29.1 — подтверждение операций и отмена старого контекста (2026-10-01)

• Delete/restore используют синхронный общий lock и immutable цель. Ошибка API сохраняет диалог/файл и показывается внутри него; Escape/отмена заблокированы во время запроса. Только DELETE 204 удаляет подтверждённую строку и закрывает диалог. Ошибка отдельного refresh не отменяет подтверждение удаления.
• Restore сверяет filename и говорит об API-подтверждении импорта, а не о проверенной рабочей конфигурации. Полная идентичность serverId/backupId и неизвестный результат импорта требуют следующего backend/API блока.
• Download имеет single-flight по файлу, caller AbortSignal/срок чтения и проверку MIME. HTML/JSON 200 не сохраняются как бэкап; object URL освобождается. Unmount/source отменяют все три операции и подавляют поздние toast/скачивание/state.
• Предупреждение restore вынесено из HTML-абзаца, устранена ошибка вложенности/hydration.
• 9 API unit, 6 operations E2E (повтор после исправления HTML), все 28 context E2E, TypeScript, профильный ESLint и production frontend прошли. Реальные RouterOS/PostgreSQL/S3 не проверены.
• Следующий блок 11А.29.2: backend cleanup удаления: не игнорировать S3 ошибки, удалять запись после файлов, сохранить возможность повторить частичную очистку. Исходные bucket/endpoint в записи не хранятся — историческое происхождение S3 остаётся ограничением. Затем restore identity/неизвестный результат, URL/Frame/адаптивность и scheduler/приёмка.

Блок 11А.29.2 — подтверждённая очистка перед удалением записи (2026-10-01)

• Backend удаляет S3 объект и локальный файл до записи каталога. Ошибка S3/диска/DB выходит наружу, не превращается в 204. Отсутствие рабочего S3 подключения при s3Key отклоняет удаление. Сохранившаяся запись позволяет повторить частичную очистку; local rm force и S3 DeleteObject допускают уже отсутствующий объект.
• Имя локального файла проверяется до любых side effects: разделители/traversal/absolute target отклоняются, путь остаётся внутри storage/backups. Проверки не удаляют реальные файлы.
• Диалог явно указывает текущее подключение S3. Записи исторически хранят только object key, исходные bucket/endpoint не сохранялись: отсутствие объекта в прежнем bucket, очистка версий S3 и внешние конкурентные изменения не подтверждены. Это ограничение не скрыто обещанием физического удаления всех исторических копий.
• 3 fault/order/path unit, полный backend test:backups (DTO/storage/job/HTTP/S3), HTTP DELETE 204/500/404 и RBAC, backend production build и профильный ESLint прошли. Frontend изменён только текстом пояснения. Реальные PostgreSQL/RouterOS/S3 не проверены.
• Следующий блок 11А.29.3: restore receipt backupId/serverId, неизвестный результат импорта и повтор; затем URL/Frame/адаптивность, scheduler cleanup и локальная приёмка резервных копий.

Блок 11А.29.3 — идентичность подтверждения импорта (2026-10-01)

• Restore receipt содержит backupId и numeric serverId наряду с filename/актуальным serverName. API проверяет обе цели, страница проверяет filename. UI serverId преобразуется из string в number согласно контракту. Ответ чужого сервера/бэкапа и старый неполный receipt не закрывают диалог и не подтверждают импорт. Переименование сервера не считается ошибкой.
• Backend/helper и тестовые HTTP ответы мигрированы вместе. 10 frontend API unit, backend test:backups, 7 operations E2E и 4 restore context E2E, frontend/backend production build, TypeScript и профильный ESLint прошли. Первый прогон выявил string/number ID mismatch; исправлено и проверки повторены.
• API receipt подтверждает ответ импорта, не работоспособность конечной конфигурации. Внешние RouterOS/PostgreSQL/S3 не проверены. Потеря ответа и blind fallback после ошибки импорта остаются следующим блоком.
• Следующий блок 11А.29.4: неизвестный результат restore, ограничение повторного импорта и его HTTP семантика; далее URL/Frame/адаптивность и scheduler/приёмка backups.

Блок 11А.29.4 — неизвестный результат импорта на backend (2026-10-01)

• Import fallback /execute разрешён только при RouterOS HTTP 404/405 для /import. Таймаут/обрыв, невалидный JSON, 400/401/500 не запускают второй импорт. После отправки команды любая ошибка маркируется BackupRestoreUnknownError; HTTP 502/outcome unknown не объявляет конфигурацию неизменённой. Ошибка подготовки до импорта остаётся 400/outcome not-applied.
• Событие успешного импорта пишется независимо от HTTP receipt: медленный/отказавший журнал не удерживает подтверждённый ответ. Успешный импорт не повторяется helper-функцией.
• 3 restore fault unit (сети в них нет), весь backend test:backups с HTTP outcome 502/400, backend production build прошли. Профильный lint новых/helper/service/routes файлов прошёл. В mikrotik.ts остались две исходные prefer-const ошибки (req/entry); наличие обеих подтверждено lint версии HEAD до изменения, новых lint ошибок нет.
• Реальный RouterOS не проверен; /execute receipt подтверждает ответ команды, не завершение всех изменений конфигурации. Backend durable restore/idempotency repository пока отсутствует; клиентский запрет слепого повтора нужен следующим блоком.
• Следующий блок 11А.29.5: checkpoint restore до POST, неизвестный результат/после reload и явная проверка роутера перед новым импортом; затем URL/Frame/адаптивность, scheduler и приёмка backups.

Блок 11А.29.5 — отметка неизвестного restore до POST (2026-10-01)

• До POST записывается immutable backupId/serverId/filename/имя/время в sessionStorage по backend URL. Отказ записи не отправляет импорт. Синхронный guard и общий operation lock защищают повтор; hydration/corrupt checkpoint не допускают начало.
• Обрыв, deadline, чужой receipt, backend unknown и legacy 400 без outcome сохраняют отметку. Reload/возврат не запускает POST и блокирует restore. Известный 400 not-applied/403/404/405 или подтверждённый receipt очищает отметку. Отказ очистки сохраняет блокировку, но не отменяет toast подтверждённого импорта.
• Новый импорт требует явного checkbox «Я проверил состояние роутера…» и отдельного действия «Разрешить новое восстановление». Оно только снимает отметку, не отправляет запрос и не объявляет конфигурацию проверенной приложением. Read-only/занятость запрещают снятие; после unknown диалог закрывается кнопкой «Закрыть», это не отмена server operation.
• 2 checkpoint/classification unit, 12 operations E2E, все 28 context E2E, TypeScript/профильный ESLint и production frontend прошли. Тесты уточнены: review выполняется после закрытия modal, checkpoint same-origin привязан к location.origin.
• Durable backend restore repository отсутствует: отметка действует в текущей вкладке/sessionStorage, не синхронизирует разные браузеры/вкладки и не доказывает результат RouterOS. Реальные RouterOS/PostgreSQL/S3 не проверены; ручная проверка устройства остаётся внешним действием.
• Следующий блок 11А.30: URL контекст истории/табов/Filters, затем Frame и визуальная адаптивная приёмка, unknown статус устройств, scheduler cleanup и локальная приёмка backups.