houseplan-card/docs/reviews/SPEC-REVIEW-406-r4.md

SPEC-REVIEW-406-r4

• Issue: #406
• ТЗ: docs/specs/406-beta2-polish.md, ветка issue/406-beta2-polish, ревизия 4, SHA 7a3dcfd7 (тот же коммит, что назвал автор в передаче на ревью: «Head: 7a3dcfd7»; git rev-parse HEAD подтверждает)
• Этап: spec (PROCESS.md §2.4)
• Заход: r4 · блокирующих циклов израсходовано 3 из 4
• Вердикт: зелёный

Почему разбор по дельте, а не заново

Предыдущий вердикт (SPEC-REVIEW-406-r3) получен на SHA c43051ac. origin/dev = b04387ce — тот же коммит, что был актуален и на момент r2/r3 (git merge-base c43051ac origin/dev = b04387ce = сам origin/dev, git merge-base --is-ancestor c43051ac origin/dev → false, т.е. ветка задачи не сливалась и не ребейзилась поверх ушедшего вперёд dev). Не §2.10-случай «ребейз на ушедший вперёд dev».

Дельта объявлена как git diff c43051ac..7a3dcfd7:

docs/reviews/SPEC-REVIEW-406-r3.md | 235 +++++++++++++ (новый файл — документ прошлого раунда)
docs/specs/406-beta2-polish.md     |  26 +++++++------

В самом ТЗ дельта — три места: (1) ревизия 3→4 в шапке, (2) одно предложение в разделе «Что человек увидит… После», (3) полностью переписанные разделы «UX» и «Release-артефакты». Контракты (а), (б), (в), (г), AC1–AC12, план автотестов, риски, откат, скоуп/не-скоуп дельтой не задеты ни строкой — инвариант проверен git diff c43051ac..7a3dcfd7 -- docs/specs/406-beta2-polish.md построчно. Диапазон origin/dev...HEAD по-прежнему состоит только из doc-файлов (три ревью-документа + сам ТЗ) — продуктового кода нет, гейты tsc/test/build неприменимы, тот же факт, что в r1–r3.

Дельта локальна и закрывает единственную Medium-находку r3 — это ровно случай, для которого §2.10 предписывает разбор по дельте, а не заново.

Скоуп

Без изменений: пять пунктов из тела issue → четыре после того, как (д) выведен из скоупа в r3 (дефект уже исправлен в #409 коммитом 8119c523). Четыре пункта на трёх поверхностях: словари i18n (а), роль/описание диалога подтверждения (б) вместе со смок-покрытием HA-ветки (в), уборка снапшотов area (г). Полный трек обоснован (три несвязанные поверхности, критерий «одна поверхность» для small не выполняется) — не пересматривался, дельта трек не касается.

Как проверялось

Прочитаны заново docs/SCOPE.md, PROCESS.md целиком (включая §2.10, §4, §7.1, §7.2), AGENTS.md. Прочитано тело issue #406 и все восемь комментариев (два S2-разбора, четыре передачи на ревью автором, два предыдущих вердикта). Прочитаны целиком docs/reviews/SPEC-REVIEW-406-r1.md (входит в SHA дерева как исторический контекст), -r2.md и -r3.md.

Само ТЗ (docs/specs/406-beta2-polish.md, 344 строки) прочитано целиком построчно на SHA 7a3dcfd7, не только дельта — чтобы убедиться, что переписанные разделы UX/Release-артефакты не противоречат ничему из разделов, которые дельта не тронула (сценарий, контракт (б), AC6–AC8).

Точечно перепроверена по коду цифра, впервые появившаяся в этой ревизии текста (раздел UX, строка 197: «восемь точек входа: семь destructive и одна warning») — это не пересказ старой находки r1, а новое количественное утверждение в новом месте документа, поэтому дельта его касается:

grep -n "kind: *'destructive'" src/*.ts   → 7 вхождений
  houseplan-onboarding-runtime.ts:224, 437
  houseplan-editor-runtime.ts:3127, 3153, 8418, 8658, 8884
grep -n "kind: *'warning'" src/*.ts       → 1 вхождение
  houseplan-card.ts:13044

7 + 1 = 8, число в тексте точное.

Проверена терминология «нативная оболочка House Plan» против docs/USER-GUIDE.ru.md: строки 730 и 1904 этого документа уже используют оборот «общий диалог House Plan» / «единый диалог House Plan» для того же подтверждения — новая формулировка ТЗ не изобретает термин, а совпадает с уже принятым в проекте словарём интерфейса.

Продуктового кода в диапазоне origin/dev...HEAD нет (git diff origin/dev...HEAD --stat — только четыре .md-файла), поэтому tsc/test/ build не гонялись — неприменимы, тот же факт, что в r1–r3.

Закрытие раунда r3

Находка r3	Чем закрыта	Где это видно
№1 (Medium, в скоупе) — раздел «UX» и «Release-артефакты» утверждали «оформление не меняется», хотя раздел (б) в r3 впервые ввёл видимый переход confirm-диалогов с HA-хрома на нативную оболочку hp-dialog	Раздел «UX» переписан: явно назван видимый переход для всех восьми точек входа («…в реальном Home Assistant переходят с оболочки ha-dialog на уже поддерживаемую нативную оболочку hp-dialog: возможны небольшие отличия заголовка и анимации»), явно перечислено, что не меняется (кнопки, цвет, защита от случайного закрытия, начальный фокус, Esc), явно названо, что это «осознанный видимый компромисс… а не обещание pixel parity». Раздел «Release-артефакты» требует пункт CHANGELOG именно про нативную оболочку и про alertdialog, User-Visible: yes	docs/specs/406-beta2-polish.md:193-206 (UX), :339-343 (Release-артефакты); в дифф c43051ac..7a3dcfd7 эти два раздела — единственные содержательно переписанные блоки

Находка закрыта по существу: числовое утверждение, добавленное в закрывающем тексте («восемь точек входа: семь + одна»), перепроверено независимо по коду (см. «Как проверялось») и совпадает; формулировка не противоречит ни одному месту ТЗ, которое дельта не трогала (AC6–AC8, контракт (б), раздел «Проверена ровно закреплённая проектом версия…»); терминология не изобретена, а совпадает с docs/USER-GUIDE.ru.md.

Унаследовано из r3

Разделы, дельтой c43051ac..7a3dcfd7 не задетые ни строкой, приняты без повторной построчной проверки контракта — из docs/reviews/SPEC-REVIEW-406-r3.md (и через него — из r2/r1), на SHA c43051ac:

• (а) Мёртвые строки в словарях — инвентарь 13 мёртвых ключей (7 confirm.* + 6 прочих семейств), правило извлечения производных *.help.aria из литеральных _help('*.help') для всех 19 пар, коллизия с test/unified-wall-tool-source.test.mjs и её разрешение как открытого вопроса реализации — вся фактура из r1/r2, подтверждена в r2 и не пересчитывалась в r3 и в этом раунде.
• (б) контракт роли/описания (без изменённого в этом раунде текста UX) — дихотомия destructive/warning → alertdialog, механизм .ariaDescribedBy/type в закреплённой версии home-assistant-frontend ==20260729.7, независимо подтверждённый в r3 построчным чтением реального ha-dialog.ts (560 строк). Эта часть контракта дельтой r3→r4 не менялась.
• (в) смок-покрытие HA-ветки — контракт «смок с зарегистрированным ha-dialog проверяет обе развилки», прецедент стаба smoke_free_walls.mjs, требование к стабу моделировать публичные свойства, а не внутренний shadow DOM — переписано и подтверждено в r3, дельтой r4 не тронуто.
• (г) снапшоты area — условие «уборка только при авторитетном реестре», связь с #403, порядок обрезки markerAreaSnapshotOf (сохранять последние, а не первые) — фактура из r1/r2, не пересчитывалась в r3 и в этом раунде.
• AC1–AC12, план автотестов, мутанты, риски, откат, модель данных/миграция, i18n — текст этих разделов не изменился ни на строку между c43051ac и 7a3dcfd7; их разбор в r3 («AC6-AC8 и обновлённый план автотестов внутренне непротиворечивы», «нет висячих ссылок на AC13/AC14», «§7.1 — все разделы присутствуют») принят как есть.
• Отсутствие продуктовых вопросов владельцу — подтверждено в r1/r2/r3, в этом раунде тоже не появилось: единственная правка (UX/Release-артефакты) технический вопрос не поднимает, она документирует уже принятое техническое решение (б).

Находки

Блокирующих (High) и находок Medium в скоупе, не закрытых этой ревизией, нет.

[Low, снято с записью] DoR-пункты «влияние на touch по docs/TOUCH-SUPPORT.md» и «влияние на производительность названо явно» не выделены в ТЗ отдельной строкой (ни в этой, ни в предыдущих трёх ревизиях — проверено по docs/reviews/SPEC-REVIEW-406-r{1,2,3}.md, ни один не поднимал этот пункт). Разбираю по существу, не откладываю: производительность покрыта явно — AC12 фиксирует бюджет initial (удаление ключей уменьшает его, роль/aria-describedby добавляют единицы байт), доказательство — bundle:budget до/после. Touch не упомянут вовсе, но по факту неприменим: все четыре пункта задачи — словари, диалог hp-confirm (используется исключительно в двух редакторах, SCOPE.md: View никогда не показывает destructive/warning-действий), снапшоты area (внутренняя уборка данных, не интерфейс) — не меняют ни один жест, ни один drag/resize/tap-путь TOUCH-SUPPORT.md; смена HA-хрома на нативный <dialog> — рендер-путь, одинаковый независимо от способа ввода. Снимаю без возврата автору: правка тривиальна (одна фраза «влияние на touch: нет, диалог не входит в touch-специфичные пути редакторов»), но её отсутствие не меняет ни одного AC и не создаёт риска — решение реализации от неё не зависит.

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

• Единственная Medium-находка r3 закрыта по существу, не косметически: новый текст UX/Release-артефактов называет ровно то видимое изменение, которое раздел (б) вводит, ничего не занижая и не расширяя сверх доказанного в r3.
• Новое количественное утверждение в закрывающем тексте («8 точек входа: 7 + 1») точное — перепроверено независимым grep по src/*.ts, не принято на слово автора.
• Терминология не изобретена — «нативная оболочка House Plan» совпадает с уже используемым в docs/USER-GUIDE.ru.md оборотом («общий диалог House Plan», «единый диалог House Plan»).
• Внутренняя согласованность документа после правки — раздел UX не противоречит AC6–AC8, контракту (б) и разделу «Практически» (строки 120-130); раздел Release-артефакты корректно относит к User-Visible ровно один пункт (б) и оставляет три остальных (а, в, г) внутренними.
• §7.1, обязательные разделы — все присутствуют и после правки: сценарий, что человек увидит до/после, проблема+контракт по каждому из четырёх пунктов, скоуп/не-скоуп, UX, модель данных и миграция, i18n, AC1-AC12 с доказательством, план автотестов, риски, откат, release-артефакты.
• Дельта c43051ac..7a3dcfd7 не задевает ни один AC — контракты и план автотестов текстуально не изменились, поэтому доказательства AC1-AC12 наследуются из r3 без пересчёта.
• origin/dev не продвинулся с r2/r3 (b04387ce) — основание для разбора по дельте, а не заново, сохраняется.
• Продуктовых технических вопросов владельцу не вынесено — как и в r1/r2/r3.
• Три проверки автора (check-docs.mjs, process-gate.mjs --issues, git diff --check), названные в передаче revision 4 неявно (те же, что называл автор в revision 3) — doc-only дерево, не относятся к предмету находок этого раунда.

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

• Гейты tsc/test/build — не гонял: git diff origin/dev...HEAD --stat показывает только четыре .md-файла, продуктового кода нет. То же основание, что в r1-r3.
• Не пересчитывал заново инвентарь мёртвых ключей (а), механику снапшотов (г), контракт (б)/(в) по существу — унаследовано из r3 (SHA c43051ac), дельта r3→r4 их не касается (см. раздел «Унаследовано из r3»).
• Не проверял поведение реального wa-dialog глубже, чем сделал r3 (та же граница: ha-dialog.ts не передаёт type/role внутрь — этого достаточно для контракта (б), глубже в сторонний пакет ТЗ сознательно не заходит).
• Не проверял scripts/mutation-gate.mjs на техническую реализуемость трёх заявленных мутантов — на этапе ТЗ это описание намерения, не код.
• Не запрашивал у владельца touch/perf-строку DoR — разобрал сам как Low и снял с записью (см. «Находки»); оба ответа выводятся из уже зафиксированного в SCOPE.md/TOUCH-SUPPORT.md факта («View никогда не показывает destructive-действий»), продуктовым вопросом не является.

Вердикт

Вердикт: зелёный · заход r4 · блокирующих циклов 3/4 · High: 0 · Medium: 0