houseplan-card/docs/analysis/800-spec-preflight.md

Локальная предварительная проверка ТЗ #800 (до канонического r1)

Итог второго предварительного прохода: зелёный. High: 0 · Medium: 0 · Low: 0.

Это preflight, не канонический раунд SPEC-REVIEW-800-rN и не отчёт CI. Штатный S4-ревьюер самостоятельно проверяет тело issue и выносит вердикт.

Первый проход — жёлтый

High: 0 · Medium: 2 · Low: 0.

Дата: 2026-10-05. Ревьюер — отдельный агент, не автор ТЗ. Материал: тело issue #800, редакция с updatedAt: 2026-10-05T16:05:13Z. SHA-256 нормализованного тела: c2723dc2993ba025df0e0f584936a8acf999b6373ca43f45436c408b29d71f39. База репозитория: 1faed2af7d89f768e7fd15a55489c5f8317f7032.

Это локальное предварительное ревью, а не отчёт CI или вердикт штатного конвейера. На момент проверки владелец ещё не разрешил запрошенную замену штатной модели ревью. Документ не разрешает смену статуса, начало разработки, слияние или выпуск и не объявляет израсходованный цикл штатного конвейера. Issue, метки, продуктовые файлы и удалённые ветки ревьюер не менял.

Скоуп и способ проверки

Прочитаны маршрут SCOPE → AGENTS → REVIEWER и применимые разделы PROCESS §2.3–2.5, §6, §7.1. Проверены обязательные разделы ТЗ, выполнимость AC1–AC6, backend lifecycle, start/cancel/result races, приватность и совместимость. Для существующего контракта прочитаны Zigbee-разделы ARCHITECTURE, CONFIG-COMPATIBILITY, USER-GUIDE.ru и действующий transport runtime базы. Черновик реализации не читался; продуктового diff задачи на базе нет.

Проверка выполнена чтением. Установка зависимостей, тесты, браузерные гейты и мутанты не запускались: это ревью ТЗ, не доказательство готовой реализации.

Находки первого прохода

M1 — не определён исход коррелированной ошибки Zigbee2MQTT

Medium, в скоупе. §4.8–4.9 и AC5 запрещают заменять last-good невалидным ответом, но не требуют завершать задание при ответе своей transaction с status: error. После удаления общего таймаута реализация может отбрасывать такой ответ как неподходящую карту и бесконечно показывать ожидание, хотя провайдер уже сообщил окончательный отказ.

Сценарий: запрос опубликован; Z2M возвращает коррелированную ошибку, в том числе непосредственно во время публикации. Сохранённая карта не меняется, но для фазы задания и освобождения подписок однозначного oracle нет. Z2M 2.14.2 действительно публикует ответ при ошибке сканирования.

Требуемое уточнение: terminal error, локализованная ошибка без сырого payload, stale last-good, очистка подписок и backend-проба с немедленным ответом. Коррелированная успешная оболочка с невалидной картой также не должна оставлять бесконечное ожидание.

M2 — не задан lifecycle при потере MQTT после публикации

Medium, в скоупе. §4.7 определяет frontend disconnect, §4.9 ограничивает подготовку транспорта. Фраза §4.3 «между переподключениями» не определяет исход разрыва HA ↔ MQTT после отправки запроса: terminal error или продолжение ожидания после переподписки. При единственном неретейненном ответе варианты имеют разный наблюдаемый результат и разное время удержания ресурсов.

Сценарий: публикация завершена, затем MQTT отключается и подключается снова. ТЗ не определяет фазу задания и требуемый UI в этот момент. Отдельно нельзя допустить, чтобы восстановление соединения повторно запустило радио-скан.

Требуемое уточнение: явный выбранный исход, last-good и cleanup, плюс AC на disconnect/reconnect без повторной публикации. Предложенный технический вариант — terminal transport error; следующий запрос только явно.

Что проверено и корректно

• Сценарий служит J7 из SCOPE: существующая необязательная диагностика Zigbee, без нового сетевого анализатора или фоновых автоматических сканов.
• Отмена адресует точный job id; старый id не отменяет новое задание; успех/отмена имеют один итог. Дедупликация задана по нормализованному topic.
• AC1–AC4 предусматривают управляемые часы, поздний результат, восстановление клиента и очистку UI без отмены серверного задания.
• §4.10/AC5 сохраняют реальный HA-admin-only доступ независимо от права редактирования House Plan. §6/AC6 исключают карту из постоянной модели, export, support и diagnostics; cache и число topics ограничены.
• Старый backend, отсутствие MQTT, неизменность ZHA и маршрутов/LQI, локализации, rollback и release-артефакты описаны.

Чего не проверял

Реализацию и её исполнение, фактическую совместимость будущего Python-кода с минимальной версией HA, скорость/успешность сканирования реальной Zigbee-сети. Этот документ не подтверждает прохождение каких-либо продуктовых гейтов.

Второй проход — зелёный

High: 0 · Medium: 0 · Low: 0.

Дата: 2026-10-05. Ревьюер — тот же независимый от автора ТЗ агент. Материал: тело issue #800, редакция с updatedAt: 2026-10-05T16:08:53Z. SHA-256 нормализованного тела: de6f7a8816ce796cb3f53713838505a66a5b098d986cf39d56f9e8ec74a55d09. База репозитория: 1faed2af7d89f768e7fd15a55489c5f8317f7032.

Зелёный предварительный результат сам по себе не разрешает смену статуса, начало разработки, слияние или выпуск. Разрешения владельца на замену штатного ревью на момент проверки нет. Документ не объявляет израсходованные циклы штатного конвейера. Коммитов, push и изменений issue/меток ревьюер не выполнял.

Дельта и способ проверки

Повторный разбор по принципу PROCESS §2.10: тело issue с хешем c2723dc2993ba025df0e0f584936a8acf999b6373ca43f45436c408b29d71f39 из первого прохода сопоставлено с текущим телом указанного выше хеша. Изменены §4.3, §4.8–4.9, добавлен §4.12, уточнён §5 и расширен AC5. Продуктовый сценарий и состав подсистем не расширены: дельта локальна.

Проверено чтением точного текста дельты и затронутых AC2, AC4, AC5. Тесты, браузерные гейты и мутанты не запускались; реализация этим выводом не оценивается. Хеш тела вычислен штатным issueBodyDigest из scripts/review-doc-guard.mjs.

Закрытие находок первого прохода

Находка	Закрывающий текст	Результат
M1: коррелированная ошибка провайдера могла оставить бесконечное ожидание	§4.8: собственная transaction с status: error или иным явно неуспешным статусом немедленно завершает job ошибкой, включая ответ во время publish. Собственная успешная оболочка с невалидной картой также даёт error. Last-good не заменяется, конечный исход освобождает подписки; некоррелируемый мусор игнорируется. AC5 отдельно требует пробу немедленного status:error.	Закрыта
M2: не определена потеря HA ↔ MQTT после публикации	§4.12: terminal transport error, stale last-good, освобождение подписок, понятное сообщение UI и отсутствие повторной публикации при reconnect. AC5 содержит проверку disconnect после publish и reconnect. §4.3 теперь явно говорит только о переподключениях frontend к HA.	Закрыта

Дополнительные изменения дельты

• §4.9 различает локальную установку callback, ограниченное ожидание обработки подписок через доступный публичный HA API и фактический запуск радио-скана. Нет обещания неподтверждаемого прогресса. Сохраняются порядок callback-before-publish, защита немедленного ответа и транспортные лимиты; запрещён безусловный импорт отсутствующего на минимальной HA API.
• §5 сохраняет строки активных topics при редактировании списка, поэтому запущенное задание не теряет видимые таймер и отмену. Удалённые темы не возвращаются в сохранённые настройки. Disable скрывает UI, не отменяя job; повторное включение восстанавливает наблюдение. Это согласуется с AC2/AC4.
• Новых High/Medium/Low в дельте не обнаружено.

Унаследовано из первого прохода

Без повторной полной проверки приняты выводы первого прохода этого документа на материале c2723dc2993ba025df0e0f584936a8acf999b6373ca43f45436c408b29d71f39:

• соответствие J7/SCOPE и отсутствие автоматических сканов;
• доказуемость долгого ожидания, дедупликации, точной отмены и гонки успех/отмена (AC1–AC3), кроме явно разобранного расширения ошибок;
• admin-only и непостоянная ограниченная runtime-карта, исключение из config/export/support/diagnostics;
• совместимость старого backend, отсутствие MQTT, неизменность ZHA и существующих маршрутов/LQI;
• i18n, риски, rollback, release-артефакты и общий план доказательств.

Чего не проверял во втором проходе

Продуктового кода задачи нет в материале. Реальное HA/MQTT исполнение, утечки, гонки, минимальная HA и frontend/backend/smoke результаты подлежат проверке при реализации и независимом код-ревью. Скорость радио-сканирования сети владельца остаётся вне возможностей локальных fixture-тестов.