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

CODE-REVIEW-211-r2 — коррекция compatibility-смока после полного Linux CI

• Issue: https://github.com/Matysh/houseplan-card/issues/211
• ТЗ: docs/specs/211-device-icons-visual-parity.md (принято SPEC-REVIEW-211-r2, зелёный)
• Предыдущий цикл: docs/reviews/CODE-REVIEW-211-r1.md — зелёный, реализация (4e82976, 270cf63) уже слита в dev до того, как полный Linux smoke вскрыл устаревшую проверку; поэтому временный S8-merged был гонкой двух событий, а не итоговым статусом (см. комментарии владельца в issue).
• Диапазон этого цикла: origin/dev..HEAD = один коммит 4d1b62b — test: align locked marker smoke with design package · Issue: #211 · User-Visible: no
• Цикл: r2/4

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

Весь диапазон git diff origin/dev...HEAD — это 11 строк в одном файле, demo/smoke_cover_no_plate.mjs (7 добавлено, 4 удалено). Ничего в src/**, custom_components/**, конфиге, i18n или changelog не тронуто — класс B (гейт/тест), трейлер User-Visible: no соответствует. Изменение правит один устаревший compatibility-факт (lockedLockIsNeutral → lockedLockKeepsPackageFace) внутри смока, который сам по себе не входит в диапазон реализации #211, но проверяет побочный контракт («у замка есть рамка, замок не становится нейтральным»), задетый переходом на дизайн-пакет #179/#211.

Продуктовый код в этом цикле не проверяется повторно — он уже был предметом CODE-REVIEW-211-r1 (зелёный) и в этом диапазоне не менялся.

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

Гейты — прогнаны

npx tsc --noEmit                                            → чисто
npm test                                                     → 939 pass, 0 fail, 0 skipped
npm run build                                                → OK
cmp dist/houseplan-card.js custom_components/.../houseplan-card.js → идентичны
cmp dist/houseplan-card.js demo/srv/assets/houseplan-card.js        → идентичны
node demo/smoke_cover_no_plate.mjs                            → все факты true, OK
node demo/smoke_device_icon_design.mjs                        → все факты true, OK (доп. проверка
    основного AC3-смока лежащей рядом поверхности; продукт не менялся с r1, но
    это самый дешёвый способ убедиться, что коррекция теста не разошлась с
    уже принятым CSS)

Проверка «тест умеет падать» (обязательная дисциплина, применена к

единственному изменённому предикату)

Правило .dev.lock-locked в src/styles.ts вернул временно к состоянию до основного фикса 4e82976 (background: var(--device-core-bg); color: #000, без theme-light/theme-dark расщепления — то есть ровно то поведение, которое проверял старый lockedLockIsNeutral), пересобрал dist и синхронизировал demo/srv/assets/houseplan-card.js (демо-сервер отдаёт именно эту копию, не dist/ напрямую — без этого шага мутация не была бы видна смоку). Результат:

"lockedLockKeepsPackageFace": false
FAILED (1): lockedLockKeepsPackageFace: expected true, got false

Все остальные факты смока остались зелёными — падение точечное, как и должно быть для правки одного предиката. После проверки src/styles.ts восстановлен из копии, npm run build прогнан повторно, dist синхронизирован обратно в demo/srv/assets и в custom_components/houseplan/frontend; git status — чистое дерево, диффа не осталось.

Дополнительно проверено чтением: новые ожидаемые значения (rgb(0, 0, 0)/rgb(255, 255, 255) для Light, rgb(37, 37, 37)/ rgb(255, 255, 255) для Dark) — это буквальный computed-style результат правил .dev.lock-locked, .dev.theme-light.lock-locked, .dev.theme-dark.lock-locked (src/styles.ts:2035-2048), которые сами уже были зафиксированы и приняты в CODE-REVIEW-211-r1 как соответствующие §7.3 ТЗ (Lock Light: core black / glyph white, Lock Dark: core #252525 / glyph white). --device-face-bg/--device-face-fg транслируются в background/color .device-core напрямую (src/styles.ts:1988-1989), так что тест меряет ровно то, что видит пользователь, а не побочный токен.

Оценка ветвления по теме в самом тесте

Смок не переключает hass.themes.darkMode, а демо-фикстура (demo/srv/demo.html) не задаёт его вовсе, поэтому device-face.ts:24 (hass.themes.darkMode ? 'theme-dark' : 'theme-light') в этом прогоне детерминированно даёт theme-light — веткой rgb(37, 37, 37) тест здесь фактически не исполняется. Это не дефект: тёмная ветка того же контракта (darkLockUsesWhiteGlyphAndDarkShell) уже отдельно и явно проверяется вычисляемым фактом в demo/smoke_device_icon_design.mjs и была подтверждена в r1 независимым before/after прогоном. Тернарное выражение здесь написано корректно и симметрично на случай, если смок когда-нибудь начнёт переключать тему, но не создаёт для этого дублирующего покрытия — фиксирую как наблюдение, не как находку.

Коммит и трейлеры

4d1b62b: Issue: #211, User-Visible: no — верно, диапазон не содержит изменений продукта, изменений в changelog не требуется.

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

• Правка ограничена одним файлом гейта (demo/smoke_cover_no_plate.mjs), относится к предмету #211 (AC3, Lock state parity) и устраняет расхождение между устаревшим pre-#179 предположением теста («заблокированный замок — нейтральный, глиф всегда чёрный») и принятым дизайн-пакетом («core черный/ #252525, глиф всегда белый»).
• Новый предикат lockedLockKeepsPackageFace измеряет именно тот CSS, который производит видимый пиксель (background/color на .device-core через --device-face-bg/--device-face-fg), не побочный токен.
• Предикат доказанно умеет падать: воспроизведена красная линия на до-фиксовом правиле, падение точечное (1 из ~60 фактов файла), после восстановления кода все факты снова зелёные.
• Остальные факты того же файла (cover plate/morph/valve/window/unlocked-lock) не задеты диапазоном и остались зелёными — регрессии в соседних, не относящихся к #211 проверках нет.
• tsc, unit-suite и build чистые; три копии бандла идентичны после восстановления дерева.
• Коммит несёт корректный Issue:/User-Visible: трейлер для class B.

Находки

Нет находок уровня High, Medium или Low. Единственное отмеченное выше наблюдение (тернарная dark-ветка предиката не исполняется в этом конкретном прогоне) не поднимаю как находку: поведение для Dark уже покрыто отдельным, явно исполняемым фактом в другом смоке, а сам тернар написан правильно и не вводит риск регрессии.

Чего не проверял и почему

• Полный набор из 127 browser smokes — не запускал; диапазон правит один предикат в одном уже существующем файле, не относящийся к нему smoke не может быть задет текстовой правкой ассерта.
• npm run golden:verify — не запускал; диапазон не меняет ни один файл, влияющий на рендер (только тестовый ассерт), видимый результат не может измениться.
• python -m pytest tests_backend -q — не запускал; custom_components/**/*.py не тронут.
• Performance-профили — не запускал; диапазон не касается DOM/CSS/JS продукта.
• Полный Linux CI-прогон — не запускал локально; это гейт CI на выходе из код-ревью, а не задача рецензента. (Именно такой прогон и обнаружил устаревший факт, который правит этот коммит — второй такой же прогон на этом SHA пройдёт штатно через пайплайн после зелёного вердикта.)

Вердикт

Единственное изменение цикла — точечная и доказанная (падает на старом поведении, зелёное на новом) коррекция стороннего compatibility-теста, приводящая его в соответствие с уже принятым в r1 дизайн-контрактом #211/#179. Продуктовый код не менялся, регрессий нет, трейлеры корректны.

Зелёный.