houseplan-card/docs/reviews/CODE-REVIEW-117-r2.md

CODE-REVIEW-117-r2

• Issue: https://github.com/Matysh/houseplan-card/issues/117
• ТЗ: docs/specs/117-registryless-opening-entity.md, зелёное docs/reviews/SPEC-REVIEW-117-r1.md (High 0, Medium 0)
• Предыдущий цикл: docs/reviews/CODE-REVIEW-117-r1.md — зелёный, High 0, Medium 0. Слияние не удалось (конфликт с dev), задача вернулась в S6-in-progress не по правкам кода, а для ребейза (комментарий владельца от 2026-08-18). Ветка ребейзнута на актуальный origin/dev и опубликована --force-with-lease на c65cbcc96c644a2bfca3dbd6c62482dc16c092c3.
• Диапазон: git log --oneline origin/dev..HEAD — четыре коммита:
  • 563a850 docs: specify registryless opening entities (Issue: #117, User-Visible: no)
  • 9baf533 docs: review document for #117 (Issue: #117, User-Visible: no)
  • 01fe48d fix: support registryless opening entities (Issue: #117, User-Visible: yes)
  • c65cbcc docs: review document for #117 (Issue: #117, User-Visible: no)
• Роль: ревьюер кода (не автор), свежая сессия без контекста реализации, этап S7-code-review, цикл r2/4 (лимит считается по этапу — вердикт ТЗ бюджет код-ревью не расходует).

Скоуп ревью

git diff origin/dev...HEAD --stat — 18 файлов:

Класс	Файлы
A (продукт)	src/ha-binding-status.ts
B (гейты/инструменты)	demo/smoke_registryless_opening.mjs (новый), scripts/mutation-gate.mjs, test/ha-binding-status.test.mjs, test/render-device-snapshot.test.mjs
C (документация)	docs/ARCHITECTURE.md, docs/CHANGELOG.md, docs/CHANGELOG.ru.md, docs/TESTING.md, docs/USER-GUIDE.ru.md, docs/images/screenshots.json, docs/specs/117-registryless-opening-entity.md, docs/specs/README.md, docs/reviews/SPEC-REVIEW-117-r1.md, docs/reviews/CODE-REVIEW-117-r1.md
D (сгенерированное)	dist/houseplan-card.js, custom_components/houseplan/frontend/houseplan-card.js, demo/srv/assets/houseplan-card.js

Что изменилось между r1 и r2: сам продуктовый диф не изменился ни на строку — git show 01fe48d -- src/ha-binding-status.ts даёт байт-в-байт тот же патч, что был одобрен в r1 (единственная точка: renderOpeningEntityAvailable в src/ha-binding-status.ts:533-546 больше не требует одновременно projectedHass.entities[entityId] и projectedHass.states[entityId], только наличие state в замороженной проекции). Ребейз добавил только слияние трёх generated-бандлов с ушедшим вперёд dev (конфликт разрешён пересборкой) и docs/images/screenshots.json (изменился только sourceFingerprint/ sourceSha256 из-за нового содержимого бандла; все imageSha256 — то есть сам пиксельный результат существующих golden-сцен — не изменились). Это не формальность: я не полагался на констатацию «код тот же», а сверил патч построчно и независимо пересобрал бандл, см. ниже.

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

Я не ассистент автора — свежая сессия, ни один гейт не принят «со слов». Все команды ниже прогнаны лично на этом дереве (origin/issue/117-registryless-opening @ c65cbcc).

Гейт	Команда	Результат
Typecheck	npx tsc --noEmit	зелёный, без вывода
Unit	npm test	870/870 pass (совпадает с заявленным автором после ребейза; в r1 было 804/804 — рост за счёт коммитов dev, вошедших при ребейзе)
Build + сверка бандлов	npm run build, затем sha256sum трёх копий	зелёный; все три — 72f660c0c574574ab07d8d7dd96262c928f333dbe5747e8091c48fbb6f0094ca, совпадает с заявленным автором хешем и с уже закоммиченными файлами (git status --short после сборки — пусто)
Целевой smoke (AC1/2/3/7/8/9)	node demo/smoke_registryless_opening.mjs	OK, все 13 подпроверок true
Регрессия opening-биндинга	node demo/smoke_opening_binding.mjs	OK, все 15 подпроверок true
Регрессия lock action	node demo/smoke_lock_action.mjs	OK, все 8 подпроверок true
Регрессия lock invariant (SCOPE.md)	node demo/smoke_lock_invariant.mjs	OK, все 7 подпроверок true
Mutation-guard	node scripts/mutation-gate.mjs --id=registryless-opening-requires-registry-row	поймано 1 из 1 — возврат .entities[entityId] красит smoke, чистый прогон зелёный
Process-gate (офлайн + --issues)	node scripts/process-gate.mjs --range origin/dev..HEAD --target-ref refs/heads/issue/117-registryless-opening --issues	коммитов 4, гейт пройден, предупреждений 0

Что не прогонял и почему (соразмерность гейтов, PROCESS.md §8, диф не менялся относительно уже принятого r1):

• Полный набор из 127 browser-смоков — diff по-прежнему задевает ровно одну логическую точку и один класс потребителей (opening contact/lock). Целевой smoke плюс три регрессионных (opening-биндинг, lock action, lock invariant) покрывают contract, security-инвариант и frame-atomicity — этого достаточно для поверхности изменения; расширение до полного набора не добавило бы сигнала сверх r1.
• npm run golden:verify — не прогонял. Прочитал diff src/space-render.ts и геометрических модулей в origin/dev...HEAD — их там нет; единственная правка убирает один операнд &&, который для уже зарегистрированных сущностей (entities[eid] и states[eid] присутствуют или отсутствуют синхронно) не меняет результат вовсе. docs/images/screenshots.json в этом же коммите подтверждает то же самое замером: imageSha256 всех 10 сцен не изменился, изменился только sourceFingerprint (хеш нового бандла). Ни один golden-сценарий не использует YAML-only fixture без registry row.
• python -m pytest tests_backend -q — не прогонял, диф не касается custom_components/houseplan/**/*.py (таких файлов в изменениях нет).
• Performance-профили — не прогонял. ТЗ §14 явно заявляет «нет», правка не добавляет новый проход по кадру или структуру данных.
• Реальную установку Home Assistant с живой YAML-сущностью без unique_id — вне возможностей код-ревью; демо-стенд с фейковым hass/registry — канонический суррогат по AGENTS.md, и я прогнал его лично.
• Ребейз/историю ветки как таковую (корректность merge-base, что именно было в конфликте) — не переисполнял git rebase; вместо этого сверил итог: продуктовый патч побайтово идентичен r1, три бандла воспроизводимо собираются из текущего дерева с тем же хешем, что заявил автор, npm test зелёный на полном (после ребейза выросшем) наборе. Это доказывает результат ребейза, а не процесс его выполнения — для код-ревью этого достаточно.
• Локальный pre-push, обойдённый автором при публикации ребейзнутой ветки — не входит в скоуп код-ревью #117: это отдельный дефект инструмента (диапазон pre-push после --force-with-lease неверно берёт старый remote SHA), заведён владельцем отдельно как #190 (process, bug, P2, S1-new — проверено gh issue view 190, issue существует с ровно этими метками). Страховка CI (process-gate job в validate.yml) не обходится этим действием, и я независимо прогнал тот же скрипт офлайн — гейт чист.

Находки

Находок уровня High и Medium нет.

Low не завожу. Диф идентичен уже одобренному в r1, повторное построчное чтение не выявило ничего нового; единственное новое обстоятельство ребейза (docs/images/screenshots.json) — ожидаемое следствие смены хеша бандла, а не дефект.

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

Ревью выполнено заново, не как штамп поверх r1: каждый AC перепроверен чтением текущего кода на этом SHA и/или повторным исполнением, без опоры на текст предыдущего документа как на источник истины.

• AC1 (registry-less live contact меняет presentation). Прочитан _openingAmt() (src/houseplan-card.ts:17101-17107): amount берётся из this._renderPlanHass.states[o.contact] только когда _renderOpeningEntityAvailable(o.contact) истинно. Доказано smoke: closedContactControlsPresentation (closed) и stateTickSwapsOneAtomicFrame (open) на binary_sensor.hp117_yaml_contact, для которой smoke явно проверяет noRegistryRowsExist (нет строки в card.hass.entities).
• AC2 (registry-less live lock badge). _renderOpeningLocks() (src/houseplan-card.ts:17221-17224) фильтрует по тому же _renderOpeningEntityAvailable(o.lock). Доказано smoke: yamlLockBadgeRendersLocked, затем .oplock.unlocked после смены состояния, unknownKeepsExistingTypeSemantics — unknown не становится ни locked, ни unlocked, значок .oplock.unknown.
• AC3 (frame — только immutable projection, не raw hass). Прочитано: _renderOpeningEntityAvailable (src/houseplan-card.ts:17129-17131) — однострочная делегация в renderOpeningEntityAvailable(this._renderPlanHass, eid), this.hass не упоминается нигде в теле. Source-contract тест test/render-device-snapshot.test.mjs проверяет это регексом на тело именно этого метода (assert.doesNotMatch(openingRenderAvailability, /this\.hass\b/)) и через methodBody. Mutation-гейт подтверждает, что тест красится при регрессии (возврат .entities[entityId]), а не только выглядит проверкой.
• AC4 (active registry entity — прежнее поведение). Логическое обоснование подтверждено чтением activeRegistryHass() (src/ha-binding-status.ts:323-354): для зарегистрированной активной сущности entities[eid] и states[eid] присутствуют или отсутствуют синхронно — удаление одного операнда && не меняет результат. Исполнением подтверждено smoke_opening_binding.mjs (exactOpeningReferencesStayActive и вся регрессионная матрица, 15/15).
• AC5 (disabled/orphan/missing остаются unavailable). Прочитан activeRegistryHass() построчно: явный disabled_by на сущности или родительском устройстве, а также authoritative-orphan (device_id указывает на отсутствующее устройство) — все три ветки удаляют state из проекции до её передачи в render helper, поэтому renderOpeningEntityAvailable честно не может их оживить. Доказано unit (test/ha-binding-status.test.mjs, кейсы lock.disabled_entity, lock.disabled_parent, lock.orphan, lock.missing — все false) и smoke (explicitDisabledRowsRemoveStaleStates, с ожиданием debounce-паузы 220ms перед проверкой удаления state).
• AC6 (limited-registry live exact entity работает). Доказано unit — limitedFrame с authoritative: false и без registry rows, renderOpeningEntityAvailable(limitedFrame, 'binary_sensor.limited_yaml') → true.
• AC7 (marker tombstone не блокирует opening reference). Доказано unit (markerTombstoneIsNotAnInput — projection с removed: true маркером той же сущности всё равно даёт true) и smoke (markerTombstonesDoNotBlockOpening, который дополнительно контрастирует с !card._planEntityAvailable(...), то есть общий marker-путь по-прежнему блокируется, а opening-путь — нет; узкий скоуп из ТЗ §4 не создаёт разрыва).
• AC8 (lock security/unlock confirmation не меняются). Прочитан _lockAction() (src/houseplan-card.ts:17260-17273) — вне дифа, по-прежнему проверяет _openingEntityAvailable() (live path) перед callService, confirm() только для unlock. Значок .oplock по клику лишь открывает info-карточку (this._openingInfo = o), не вызывает сервис — прочитано на src/houseplan-card.ts:17246-17250. Подтверждено исполнением: smoke_lock_action.mjs, smoke_lock_invariant.mjs зелёные (SCOPE.md-инвариант «The lock invariant, stated precisely» не ослаблен), плюс новый smoke явно проверяет planOpeningAndBadgeNeverActuate (тап по проёму и badge не меняет число вызовов callService) и explicitInfoActionStillWorks (только явное действие в открытой info-карточке вызывает lock.unlock).
• AC9 (state update не пересобирает geometry/config). Доказано smoke: stateTickDoesNotRebuildGeometryOrConfig сравнивает _physicalBodiesCache, _cfgEpoch и сериализованный _serverCfg до/после тика состояния.
• AC10 (existing opening golden/interactions без регресса). Golden baseline в дифе не тронут; docs/images/screenshots.json показывает, что все 10 imageSha256 не изменились — то есть уже принятые пиксельные сцены идентичны и после ребейза. Поведенческая регрессия подтверждена отдельно исполнением smoke_opening_binding.mjs (зелёный).
• Трейлеры и changelog. Все четыре коммита несут терминальные Issue: #117 и User-Visible: yes|no (проверено git show -s --format по каждому). Коммит с User-Visible: yes (01fe48d) правит docs/CHANGELOG.md и docs/CHANGELOG.ru.md в себе же (git show 01fe48d --stat), обе записи под одним и тем же заголовком v1.65.0-beta.2, без дублирования с уже существующими записями.
• Соответствие ТЗ и SCOPE.md. Диф не расширяет скоуп (§4 ТЗ дословно соблюдён: picker, миграция, marker lifecycle, generic registry-less для прочих marker-биндингов, geometry не тронуты). Задача лежит внутри уже закрытых J1/J3/J6 (docs/SCOPE.md), lock-инвариант не ослаблен.
• Целостность ребейза. Продуктовый патч (src/ha-binding-status.ts) побайтово идентичен версии, одобренной в r1 (сверено git show diff-текста). Три копии бандла воспроизводимо пересобираются из текущего дерева с тем же SHA-256, что заявил автор в хендоффе. git status --short после сборки — пусто: закоммиченные бандлы уже соответствуют пересборке, конфликт разрешён корректно, а не «на глаз».

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

• Полный набор из 127 browser-smoke — предрелизный гейт, не гейт ревью; обоснование сужения дано выше и не изменилось относительно r1.
• npm run golden:verify — обоснование дано выше (imageSha256 неизменны, геометрические/стилевые модули вне дифа).
• python -m pytest tests_backend -q — Python не тронут этим дифом.
• Performance-профили — ТЗ §14 явно исключает влияние, изменение не меняет проход по кадру.
• Реальную установку Home Assistant с YAML-сущностью без unique_id — вне возможностей ревью; демо-стенд — канонический суррогат, прогнан лично.
• Сам процесс git rebase (порядок разрешения конфликтов, промежуточные состояния) — не переисполнялся; проверен итог (см. «Целостность ребейза» выше), что для код-ревью достаточно.
• Дефект pre-push при force-push после rebase — вне скоупа этого issue, отслеживается отдельно в #190; подтверждено, что issue заведён и что CI backstop (process-gate) при этом не обойден (перепрогнан лично, чист).

Вердикт

Зелёный. High: 0, Medium: 0. Ребейз не изменил продуктовый код ни на строку — проверено побайтовым сравнением диффа, а не заявлением автора; три копии бандла воспроизводимо пересобираются с тем же хешем; полный (выросший после ребейза) unit-набор 870/870, typecheck и целевые/регрессионные smoke зелёные, mutation-guard подтверждает, что покрытие умеет падать. Каждый AC1–AC10 либо доказан автотестом, который я лично прогнал, либо разобран чтением текущего кода на этом SHA с явной пометкой «проверено чтением, не исполнением». Трейлеры, changelog (RU+EN) и process-gate в порядке. Задача готова к слиянию.