Саморевью по указанию владельца, с оговоркой о независимости. Одна находка
Low на себя: утверждение «эмит тот же» в сообщении cbf5cc1b неверно —
побайтовая сверка нормализованных сборок показала расхождение в одном месте.
Поведение при этом тождественно, разбор в документе.
Отдельно разобрано, почему восемь разошедшихся golden-сцен не из этого
коммита.
Issue: #390
User-Visible: no
The same eight changes are present on origin/dev and are unrelated to the smooth camera implementation. Review confirmed the catalog actions, toolbar undo/redo controls and dialog help/status icons are the intended current dev UI. Accept only those named Linux candidates; keep 139 existing scenarios unchanged.
Issue: #82
User-Visible: no
Release: v1.70.0-beta.1
Baseline-Reviewed: https://github.com/Matysh/houseplan-card/actions/runs/33319326145
Wait for camera transitions in legacy smoke and golden scenarios, and render the far-object hint state even when fitting is a camera no-op.
Issue: #82
User-Visible: no
Живой прогон #2157 показал огрех формулировки: база диапазона (#388)
представилась заголовком «База классификации (#387)». Текст верный, ссылка
чужая — читатель уходит не в тот issue разбираться, почему диапазон такой.
Заголовок теперь следует режиму, а не общей ветке кода. Закреплено тестом на
оба режима и обе формулировки.
Issue: #388
User-Visible: no
Правка типов в #390 пересобрала бандл, а в него вшит отпечаток исходников —
скриншот-индекс стал формально протухшим, хотя ни один пиксель измениться не
мог: аннотации типов стираются, эмит тот же.
Это не рассуждение, а измерение. Канонический прогон «Скриншоты
документации» #130 (workflow_dispatch, ref=dev) снял кадры пином и вынес
вердикт:
--- изменившихся PNG: 0
--- Chromium: было «151.0.7922.34», стало «151.0.7922.34»
--- oxipng: было «oxipng 10.2.0», стало «oxipng 10.2.0»
ВЕРДИКТ: ничего не изменилось, принимать нечего.
Единственное, что изменилось в артефакте, — screenshots.json. Здесь ровно
он и обновлён: sourceFingerprint и десять sourceSha256 сцен. Хеши картинок,
версия браузера и версия упаковщика не тронуты — проверено полем за полем.
Issue: #390
User-Visible: no
Красный backend на dev — это два независимых дефекта, и ни один не был виден
в диффе.
Первый, 85 падений. scripts/dump-config-schema.py подменяет
custom_components и custom_components.houseplan пустышками, чтобы прочитать
схему без Home Assistant, и оставляет их в sys.modules навсегда. Вызывает его
в том числе pytest: tests_backend/test_config_schema_manifest.py идёт первым
по алфавиту. Дальше HA просил у загрузчика custom_components.houseplan,
получал пустышку без async_setup и отказывался поднимать интеграцию — «No
setup or config entry setup function defined». Каждый тест харнесса падал на
_setup с «assert False», и ни один не намекал на причину: подмена работает
для подмодулей, потому что __path__ у пустышки настоящий.
Подмена не убрана — без неё скрипт не выполнит свою задачу. Она стала
обратимой: sys.modules снимается до и возвращается после, включая отсутствие
ключа. Обратимость закреплена тестом.
Второй, 1 падение. test_furniture_flip_flags_survive_coordinate_
canonicalization_unchanged требовал CONFIG_SCHEMA(result) == result, но схема
на минимальном конфиге достраивает markers и settings и приводит целые к
float — тождества там нет и не было. Проверяется теперь неподвижная точка:
повторная валидация не меняет канонический вид, а флаги её переживают.
Диагностика шла через CI: в песочнице HA-харнесс не поднять, поэтому
временная ветка experiment/389-diag печатала, что именно видит загрузчик.
Она показала модуль без __file__ и без единого атрибута — namespace-подобную
пустышку, — и это вывело на подмену.
Issue: #389
User-Visible: no
Пять мест, найденных при разборе #388: они проехали мимо гейта #342, пока
диапазоны были узкими, и он их больше не покажет.
Кэш климата (houseplan-card.ts) сравнивается только по ссылке, значение не
читается ни разу — поэтому hass стал `unknown`: он и запрещает случайно
воспользоваться содержимым, и не врёт про форму объекта, которую HA нам не
обещает. Правила и маркеры типизированы по-настоящему, их типы известны.
Реестр HA (houseplan-editor-runtime.ts) описан минимальной структурной
формой: код читает ровно два поля и оба защищённо, так что форма честнее
`any` — она говорит, на что код опирается.
Ключ i18n `device_inbox.reason_excluded_integration` не нуждался в приведении
вовсе: он есть в словаре. Шаблонный ключ приведён к `I18nKey`, как уже
сделано в этом файле строкой 8013 — это утверждение о пространстве ключей, а
не отключение проверок; `as any` заодно снимал контроль и со второго
аргумента.
Поведение не меняется: аннотации типов стираются, эмит тот же. Бандл
пересобран, потому что в него вшит отпечаток исходников.
Issue: #390
User-Visible: no
Правка #388 уронила dev, и виновата подмена предиката. Я взял доказательством
`conclusion=success`, то есть оправдательный вердикт. Гейтам диапазона нужен
другой факт: судили ли этот коммит вообще. Упавший прогон коммит судил —
вердикт вынесен, автор его видел; переоткрывать такой коммит диапазоном не
надо. Не судил только отменённый.
Цена ошибки была наглядной. Backend на dev красный несколько дней по своей
причине (test_ha_import_export), успешных прогонов нет вовсе, поэтому база
уезжала на десятки коммитов назад. На 83d646c — docs-коммите — гейт
«новый код не добавляет any» предъявил 5 чужих находок из e4e1e370 и
8d431d6d и уронил frontend. Ровно тот сценарий обвинения невиновного, ради
которого делался #386, только устроенный мной.
Теперь `judgedShas` считает судимыми завершённые прогоны с любым вердиктом,
кроме cancelled, а `greenShas` остаётся для классификации (#387): там вопрос
другой — доказано ли, что тяжёлые гейты на этом дереве ПРОШЛИ. Два вопроса,
два предиката, и путать их дорого.
Запрос к API стал `status=completed` — надмножество, нужный предикат
применяет скрипт.
Issue: #388
User-Visible: no
#387 закрыл классификацию — какие job запускать. Здесь остаток того же
дефекта: гейты, которые судят сам диапазон коммитов. Провенанс, процессный
гейт и «новый код не добавляет any» брали диапазон от головы предыдущего
пуша, а concurrency отменяет прогон предыдущего пуша штатно. Тогда его
коммиты не судит никто: свой прогон отменён, а следующий пуш сравнивает уже
с ними. Окно не закрывается никогда.
Уязвим был прямой пуш в dev — основной режим конвейера. На ветках дефекта
нет: no-new-any там всегда считает от merge-base, а resolveValidationRange
подменяет осиротевший before на origin/dev (#315).
База стала последним предком с успешно завершённым Validate. Фолбэк, когда
такого нет, сознательно оставлен прежним — before, но с пометкой в summary
«диапазон недоказуем». Расширять диапазон здесь нельзя: гейт, который сам
красит прогон, лишил бы следующий пуш зелёного предка и запер dev в
красноте навсегда. Фолбэк обязан не зависеть от собственного успеха гейта.
Дыра сужается с «всегда, когда прогон предыдущего пуша отменён» до «когда
во всём окне обхода нет ни одного успешного прогона».
Находки no-new-any теперь называют коммит, добавивший строку: диапазон стал
шире, и без имени источника сообщение обвиняло бы того, кто пушнул
следующим, — ровно то, что чинили в #386 для golden.
Issue: #388
User-Visible: no
Диапазон классификации брался от `github.event.before` — головы предыдущего
пуша. Это допущение «до этого уже проверено», и оно неверно ровно тогда,
когда прогон предыдущего пуша не завершился. А не завершается он штатно:
concurrency отменяет его следующим пушем.
На #86 (r5) это дало ложный зелёный: push 04da7eb1 тронул dist/** и
frontend/**, его прогон отменили через три минуты; следующий push fa146fb1
тронул только docs/images/**, классификация сравнила эти два коммита и
выставила frontend=false. Job «Фронтенд», а за ней golden, smoke и backend
оказались skipped — прогон при этом success. Маркеры переиспользования эти
гейты тоже не подтверждали: `Cache not found` по всем четырём.
Теперь база — самый новый предок HEAD, для которого Validate ДЕЙСТВИТЕЛЬНО
завершился успешно; если такого нет, диапазон расширяется до merge-base с
dev, то есть до всего вклада ветки. Работает по индукции: цепочка узких
диффов покрывает всё изменённое с последней настоящей проверки, а одно
незавершённое звено теперь расширяет диапазон, а не сужает.
Недоступность API не роняет job: пустой ответ опускает базу до merge-base,
то есть в сторону большего объёма проверок.
Защита от force-push (#347) сохранена: механизм, из-за которого merge-base
врал на переписанной истории, до конца не разобран, и снимать защиту, не
объяснив её, — способ получить #347 второй раз.
Issue: #387
User-Visible: no
Refresh the canonical documentation frames after rebasing #86 onto the
current dev branch and visually reviewing all ten scenarios.
Issue: #86
User-Visible: no
claude[bot]