houseplan-card/docs/reviews/SPEC-REVIEW-33-r2.md

SPEC-REVIEW #33 — r2

• Issue: https://github.com/Matysh/houseplan-card/issues/33
• Этап: ревью ТЗ (PROCESS.md §2.4)
• ТЗ: docs/specs/033-config-schema-lifecycle.md, ревизия 3
• SHA материала: 1c1f9d8ea4a3e2f32c5cd6150dde5e08bdfc280b
• Заход: r2 · блокирующих циклов израсходовано 1 из 4 (r1 — жёлтый, потратил цикл; зелёный вердикт этого раунда цикла не образует, #227)
• Вердикт: зелёный

Скоуп

Ревизия 3 — точечный ответ на три Medium-находки и два Low прошлого раунда (SPEC-REVIEW-33-r1, SHA 8335191b), ничего сверх этого. Продуктовая рамка, класс задачи (A, schema-потребители), трек (полный) и оценка аналитики не пересматриваются — они не были предметом находок r1 и делта их не задевает.

Дельта — ровно один файл, docs/specs/033-config-schema-lifecycle.md, 53 изменённые строки (34 добавлено / 19 удалено), подтверждено git diff 8335191b..1c1f9d8e --stat. Рядом в дереве src/** и custom_components/** не менялись с базового SHA r1 (git diff --stat 8335191b..HEAD -- src/ custom_components/ package.json пуст) — значит, ничего из подтверждённого чтением кода в r1 не могло протухнуть за это время. Делта локальна по критерию §2.10: не ребейз (HEAD ровно на один docs-коммит впереди материала r1), не смена контракта поведения (контракт поведения — «ничего в рантайме не меняется» — не тронут), не задета новая подсистема, объём сопоставим с тремя находками, которые он закрывает. Полный повторный разбор не требуется; ниже — разбор по дельте плюс целевая перепроверка того, до чего дельта дотягивается.

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

1. Найден вердикт r1 и SHA материала — оба названы в шапке docs/reviews/SPEC-REVIEW-33-r1.md (8335191b), спорить не пришлось.
2. Объявлена дельта: git diff 8335191b..1c1f9d8e -- docs/specs/033-config-schema-lifecycle.md (полный текст сверен построчно).
3. По каждой находке r1 (M1, M2, M3, L1, L2) — отдельная проверка чтением текущего дерева, что предложенное в ревизии 3 решение не просто иначе сформулировано, а технически состоятельно (не только «текст ТЗ звучит иначе», а «то, что он теперь обещает, совместимо с кодом, которого касается»):
   • scripts/config-field-registry.mjs — прочитан целиком; подтверждено, что поля enforcedBy и schema: 'allow-extra' в текущей форме записей нет (свободны для добавления), что CONFIG_FIELD_STATUSES остался тем же перечислением из 6 значений (ревизия 3 их не трогает — точно то, что требовало M1), что записей сейчас 27 (node --input-type=module импорт и .length), и что ни одна из четырёх «новых» ID-записей (decor_default_style, furniture, host=partition) ещё не существует в registry — делта не дублирует;
   • src/logic.ts:898-919 — SPACE_FILL_MODES/ROOM_FILL_MODES/ DISPLAY_MODES/TAP_ACTIONS существуют и экспортируются, как и утверждает исправленный текст (только 3 из 7 пар);
   • src/types.ts:212, src/plan-optimizer.ts:285, src/zero-walls.ts/houseplan-editor-runtime.ts/ houseplan-onboarding-runtime.ts (литералы 'dashed'/'solid'), custom_components/houseplan/validation.py:1254 (_BG_MODE) — подтверждено, что для opening.type, vacuum.trail_mode, zero_wall_style, bg_mode сегодня нет ни одной именованной экспортируемой frontend-константы (ровно то, что M2 требовал признать явно) и что предложенные имена OPENING_TYPES, VACUUM_TRAIL_MODES, ZERO_WALL_STYLES, BG_MODES не заняты (grep по src/*.ts — пусто), то есть план не столкнётся с коллизией имён при реализации;
   • scripts/config-audit.mjs (всё, 103 строки) — подтверждено, что process.exitCode сегодня выставляется только на ветках ошибок разбора (74/79/102), никогда от найденных полей; что код 1 нигде не занят и не проверяется ни одним потребителем (grep по package.json и .github/workflows/*.yml на audit:config/config-audit — только объявление npm-скрипта, никакого CI-потребления exit-кода), то есть новый контракт 0/3/2 ревизии 3 не конфликтует с существующим поведением или скрытым потребителем; заодно перечитан сам факт: 2 сегодня — единственный ненулевой код, значит выбор 3 для нового смысла действительно не сталкивается с ним, как и заявляет текст;
   • package.json:19 — "audit:config": "node scripts/config-audit.mjs", текст ТЗ теперь везде цитирует именно эту команду (L1 закрыт);
   • весь файл ТЗ ревизии 3 — построчный поиск «24» не находит ни одного оставшегося упоминания старого числа, все вхождения — «27» (L2 закрыт полностью, не только в шапке).
4. Перечитаны критерии приёмки AC1–AC7 целиком — ни один не ссылается на статус implemented или на старый контракт exit-кода: правка текста Блока 2/3 синхронизирована с разделом AC, который сам по себе делту не зафиксировал (он и не должен был — AC6 уже был сформулирован достаточно абстрактно, «различает exit-codes», и лишь уточнён числами 0/3/2).
5. Перечитан документ ревью r1 целиком (не только раздел «Находки») — сверено, что раздел «Что проверено и корректно» r1 не полагался ни на один факт, который ревизия 3 меняет (архитектура манифеста, docs/SCOPE.md, §7.1-разделы, «уже реализовано жизнью» для show_all/weather_entity/ aspect/segments — ревизия 3 их не трогает, только меняет способ их фиксации в registry с несуществующего статуса на поле enforcedBy).
6. Дешёвые гейты: npx tsc --noEmit на HEAD (1c1f9d8e) — чисто, 0 ошибок.

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

Находка r1	Чем закрыта	Где видно
M1 — статус implemented не существует ни в перечислении, ни в CONFIG_COMPATIBILITY.md	Статусная модель не меняется; вместо нового статуса — опциональное поле enforcedBy (ссылка на кодовую точку/тест), новые паспорта получают существующий статус current	docs/specs/033-config-schema-lifecycle.md:80-90 (Блок 2, абзац «Актуализация registry как данных»); подтверждено чтением, что CONFIG_FIELD_STATUSES (scripts/config-field-registry.mjs:362-369) и поле enforcedBy совместимы (поля с таким именем в записях сегодня нет)
M2 — 4 из 7 frontend-констант для parity-теста не существуют	Текст явно называет 3 готовые пары отдельно от 4 отсутствующих и описывает их как новую работу этого issue: экспортируемые as const-массивы OPENING_TYPES/VACUUM_TRAIL_MODES/ZERO_WALL_STYLES/BG_MODES, из которых выводятся существующие union-типы	docs/specs/033-config-schema-lifecycle.md:59-68 (Блок 2, первый абзац); подтверждено, что ни одно из четырёх имён не занято в src/*.ts
M3 — AC6/Блок 3 описывали несуществующее поведение config-audit.mjs как «расширение теста»	Явно зафиксирован новый контракт exit-кодов: 0 clean, 3 migration available, 2 invalid (без изменений), с обоснованием выбора 3, чтобы не конфликтовать с текущим 2; AC6 переформулирован под тот же контракт	docs/specs/033-config-schema-lifecycle.md:101-107 (Блок 3, последний абзац) и :147-148 (AC6); подтверждено чтением scripts/config-audit.mjs, что код 1 сегодня свободен и не потребляется CI
L1 — команда в «Что человек увидит» названа неверно (config:audit вместо audit:config)	Текст исправлен на точное имя npm-скрипта	docs/specs/033-config-schema-lifecycle.md:22; сверено с package.json:19
L2 — «registry = 24 записи» разошлось с фактическим размером массива (27)	Все вхождения числа в шапке и в разделе «Проблема» заменены на 27	docs/specs/033-config-schema-lifecycle.md:8,27; сверено подсчётом CONFIG_FIELD_REGISTRY.length на HEAD — 27; поиском по файлу подтверждено отсутствие оставшихся «24»

Все пять находок закрыты правкой текста в пределах ревизии 3, без изменения архитектуры Блока 1 и без обращения к владельцу — как и предполагал вердикт r1.

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

Следующее принято без повторной проверки — делта его не задевает, и ничего в дереве (src/, custom_components/) с SHA 8335191b не изменилось:

• соответствие docs/SCOPE.md (задача — защитная инфраструктура под J6, не претендует на пользовательскую ценность) — SPEC-REVIEW-33-r1.md, раздел «Скоуп», SHA 8335191b;
• присутствие и полнота всех обязательных разделов §7.1 (сценарий, что человек увидит, проблема, скоуп/не-скоуп, контракт, UX/i18n, модель данных, AC, план тестов, риски, откат, release-артефакты, принятые предположения) — SPEC-REVIEW-33-r1.md, раздел «Что проверено и корректно», SHA 8335191b; ревизия 3 не удалила и не переименовала ни один раздел (структура файла сверена при чтении ревизии 3 целиком в этом раунде, см. «Как проверялось» п.4–5, поэтому это скорее переподтверждено, чем чисто унаследовано);
• архитектурное решение Блока 1 (манифест схемы генерируется из Voluptuous, а не пишется руками на 212 путей) — не тронуто делтой, корректность подтверждена в r1 чтением scripts/config-field-registry.mjs и custom_components/houseplan/validation.py на SHA 8335191b;
• факты «show_all/weather_entity/aspect/segments уже реализованы кодом» — подтверждены в r1 чтением houseplan-card.ts:3895, houseplan-editor-runtime.ts:9618, validation.py:1590,1670 на SHA 8335191b; ревизия 3 меняет только способ их фиксации в данных (enforcedBy вместо статуса), не сам факт;
• необходимость заглушек родительских пакетов для импорта validation.py без homeassistant — воспроизведено в r1 (ModuleNotFoundError), делта этого блока не касается;
• формулировка не-скоупа (group_lights/exclude_integrations → #44) — не менялась.

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

• Все пять находок r1 закрыты по существу, а не только по формулировке: каждое новое обещание текста (поле enforcedBy, четыре новых экспорта, контракт exit-кодов 0/3/2, точное имя npm-скрипта, число 27) сверено с текущим деревом и не встречает коллизии имён, полей или уже занятого значения.
• AC1–AC7 остаются согласованными с телом ТЗ после правки: ни один AC не ссылается на отменённый статус implemented или на прежний недоопределённый контракт exit-кода; AC6 обновлён в паре с текстом Блока 3.
• Числа в шапке (212, 2, 27) внутренне согласованы по всему файлу — расхождений вида «одно число, два значения» не осталось (единственная такая находка прошлого раунда, L2, закрыта полностью).
• Делта не расширяет скоуп: три новых абзаца — это уточнение уже анонсированных в ревизии 2 блоков, а не новая работа сверх исходного ТЗ.

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

• Не проверял по существу архитектурные решения, не затронутые находками r1 (Блок 1 целиком, фикстуры Блока 3 кроме контракта exit-кода, раздел «Риски») — они не входят в дельту и не изменились со SHA 8335191b; доверие — по разделу «Унаследовано из r1» выше, не молчаливое.
• Не гонял npm test, npm run build, node scripts/check-docs.mjs — diff раунда docs-only (подтверждено git diff --stat), src/** не тронут, эти гейты не сказали бы ничего нового о ревизии ТЗ (то же основание, что в r1).
• Не гонял смоки, golden, инварианты модели, performance — этап ТЗ, кода ещё нет, ни один из этих гейтов не применим.
• Не проверял заново оценки сложности/риска и продуктовую ценность из комментариев аналитики — не предмет ревью ТЗ, не изменились в этом раунде.

Гейты — сводка

Гейт	Прогнан	Результат
npx tsc --noEmit	да, на SHA 1c1f9d8e	чисто, 0 ошибок
npm test	нет	diff docs-only, src/** не тронут
npm run build	нет	то же
node scripts/check-docs.mjs	нет	diff не касается src/**
смоки / golden / инварианты / perf	нет	этап ТЗ, продукт не меняется

Итог

0 High, 0 Medium, 0 Low. Все пять находок r1 закрыты состоятельно — проверено не только чтение нового текста, но и совместимость каждого нового обещания (поле enforcedBy, четыре новых frontend-константы, контракт exit-кодов, точные имена команды и числа) с текущим деревом. Новых находок делта не создала. Вердикт зелёный, ТЗ готово к разработке.