docs: review document for #485

Issue: #485
User-Visible: no

docs/reviews/CODE-REVIEW-485-r2.md

@@ -0,0 +1,319 @@
+# CODE-REVIEW-485-r2
+
+Issue: [#485](https://github.com/Matysh/houseplan-card/issues/485) — presence-radar
+Stage 1. Этап: code (PROCESS.md §2.7). Заход r2, блокирующих циклов израсходовано
+1 из 4 до этого раунда (r1 — красный, High 6/Medium 6).
+
+Материал: ветка `issue/485-radar-presence`, `git log --oneline origin/dev..HEAD` /
+`git diff origin/dev...HEAD`, HEAD = `1e6104100cc76195c3a05aa62e67af84793d9fd1`
+("fix: keep ordinary marker dialog close synchronous"). Диапазон коммитов после
+r1: `104e37b9` (lint), `cb513887`/`353a5dfa` (backend gate/tests), `c670b1bf`
+("fix: harden presence radar stage one" — основная правка H1–H6/M1–M6),
+`c6c94ebf` ("build: integrate radar after dev rebase"), `1e610410` (регрессия
+общего закрытия диалога маркера, найденная и исправленная в той же сессии).
+
+## Почему разбор полный, а не по дельте (PROCESS §2.10)
+
+r1 состоялся на коммите `f9acaa35`, который умер: ветку перебазировали на ушедший
+вперёд `dev` (`c6c94ebf`), и это прямо названный в процессе триггер полного
+разбора («ребейз на ушедший вперёд dev — после ребейза это другой код»).
+Проверено формально: `f9acaa35` не резолвится в этом дереве
+(`git cat-file -t f9acaa35` → `fatal: Not a valid object name`), дерево материала
+r1 `e85d8ed7d8c9…` тоже не встречается ни в одном коммите (`git log --all
+--format='%H %T' | grep e85d8ed7d8c9` → пусто) — это ожидаемо после ребейза
+(дерево описывает весь репозиторий, а не только диапазон задачи) и не является
+находкой само по себе, как и предупреждает §2.10. Текст `dist/`/
+`custom_components/houseplan/frontend/**` в `c6c94ebf` подтверждает: пересобранный
+бандл получил новые хэши чанков даже для несвязанных модулей (`de-*`, `fr-*`,
+`editor-*`, `houseplan-card-*`) — признак, что `dev` действительно продвинулся на
+другие слитые задачи, а не просто получил тривиальный ребилд. Поэтому ниже —
+полный повторный разбор backend+frontend+i18n+тесты, а не только диффа по
+находкам r1; раздел «Унаследовано из r1» в конце — не поэтому пустой, а потому
+что каждая находка r1 перепроверена заново с нуля.
+
+## Как проверялось
+
+Два параллельных фоновых агента (бэкенд: `radar.py`/`radar_validation.py`/
+`radar_websocket.py`/`radar_geometry.py`+тесты; фронтенд: `radar-*.ts`/
+`editors/radar-section.ts`/диффы `houseplan-editor-runtime.ts`/`houseplan-card.ts`
++тесты) прогнали весь набор findings r1 по одному, с явным «чем краснеет» на
+каждый, и отдельно перечитали код целиком в поисках нового. Самые весомые их
+утверждения (H3/H6/M4/новый `radar_stage1_api`/новый `bad_references`)
+перепроверены мной лично чтением исходников — цитаты ниже даны по коду, который
+я сам открыл, а не пересказ агента.
+
+**Прогнанные гейты:**
+
+| Гейт | Результат |
+|---|---|
+| `npx tsc --noEmit` (через `npm run bundle:sync`) | зелёный |
+| `node --test test/radar-editor.test.mjs test/radar-geometry.test.mjs test/radar-model.test.mjs test/radar-setup.test.mjs test/radar-render.test.mjs` | 27/27 pass |
+| `npm run build` + `cmp` трёх копий бандла | выполнено внутри `bundle:sync`, дерево синхронизировано без расхождений |
+| `node scripts/no-new-any.mjs --base origin/dev --head HEAD` | «Новых any нет» (2076 строк в 14 файлах) |
+| `node scripts/check-docs.mjs --screenshots=warn` | «Documentation checks passed» (strict красный по устаревшему отпечатку — ожидаемо, это гейт кандидата беты, не этого раунда, как и зафиксировал r1) |
+| `node scripts/smoke-select.mjs --base origin/dev --head HEAD` | 2 прямых совпадения на радар-символы (`smoke_radar_setup.mjs`, `smoke_radar_live.mjs`), плюс `_closeMarkerDialog`/`_markerDialog` как широкие символы из-за правки общего закрытия диалога |
+| `node demo/smoke_radar_setup.mjs` | OK, все поля отчёта `true` |
+| `node demo/smoke_radar_live.mjs` | OK, все поля отчёта `true` |
+| `node demo/smoke_marker_stay.mjs`, `smoke_dialog_zombie.mjs`, `smoke_new_device.mjs`, `smoke_toggle_entity.mjs` (выбраны вручную сверх авто-подсказки — правка `1e610410` меняет общий путь закрытия диалога маркера для *любого* устройства, не только радара) | все 4 — OK |
+| `node --test test/single-source-numbers.test.mjs` | 3/3 pass |
+| backend: `python -m pytest tests_backend/test_ha_radar.py tests_backend/test_ha_radar_websocket.py tests_backend/test_radar_geometry.py tests_backend/test_radar_validation.py -q` | **не выполнен лично** — см. «Чего не проверял». Опирался на анализ гейта бэкенд-агентом (пофайловое чтение + свидетельства «чем краснеет» по каждому найденному тесту) и на подтверждённый зелёный Validate на этом же SHA (https://github.com/Matysh/houseplan-card/actions/runs/34275082664) |
+| `npm run invariants` | не запускал — diff не трогает рёбра комнат/записи толщины/`layout`/`marker.space`/`open_spans` (проверено `grep` по всем изменённым backend/frontend radar-файлам, ноль совпадений); `radar.room_id` — только ссылка на существующую комнату, геометрия не меняется |
+
+## Находки
+
+### High — нет
+
+Все 6 High из r1 закрыты, с конкретной проверкой каждого — таблица «Закрытие
+раунда r1» ниже.
+
+### Medium (в скоупе задачи — чинится в этой же ветке)
+
+**M-1 (продолжение M6 из r1, закрыто частично). Три из четырёх числовых гардов
+калибровочного решателя на бэкенде по-прежнему не покрыты тестом; их можно
+снять незаметно.**
+`custom_components/houseplan/radar_geometry.py::solve_two_point` (170–211) несёт
+четыре защиты: расстояние от точки монтажа ≥50 см (177–178), допуск радиального
+рассогласования (196–197), потолок RMS ≤20 см и индивидуальной ошибки ≤30 см
+(199), порог неоднозначности зеркала <10 см (209–210). Из них
+`tests_backend/test_radar_geometry.py::test_two_point_fit_is_rigid_and_rejects_collinear_references`
+(73–82) проверяет только коллинеарность (угол 0°). Ни один backend-тест не
+строит референс ближе 50 см к монтажу, не создаёт измеримую RMS-ошибку и не
+создаёт двух близких по RMS зеркальных кандидатов — удаление любой из этих трёх
+защит (`radar_geometry.py:177-178`, `:199`, `:209-210`) не уронит ни один
+backend-тест. Симметричная TS-реализация (`src/radar-geometry.ts`,
+`test/radar-geometry.test.mjs:40-59`) все четыре гарда покрывает — но это
+отдельная реализация, не тот же код-путь, и не защищает Python-версию.
+Отличие от исходного M6: 2 из 8 отсутствовавших кодов ошибок
+(`unsupported_capability` — `radar_websocket.py:69-78`, тест
+`test_ha_radar_websocket.py:120-128`; `source_unavailable` —
+`radar_websocket.py:59-65`, тест `test_ha_radar_websocket.py:205-220`) теперь
+реализованы и протестированы полностью — эта часть M6 закрыта.
+*Проверка:* `python -m pytest tests_backend/test_radar_geometry.py -q -k solve_two_point` — единственный релевантный тест; сравнить с 4-кратным покрытием того же набора гардов в `test/radar-geometry.test.mjs`.
+
+**M-2 (новая). `settings.radar_stage1_api` объявляется константой `1` независимо
+от состояния координатора — вопреки явному тексту спецификации.**
+`custom_components/houseplan/websocket_api.py:1409` — `"radar_stage1_api": 1`
+жёстко закодировано в ответе `ws_config_get`, без проверки
+`rt.radar_coordinator`. Спецификация (`docs/specs/485-radar-presence-stage1.md:495-496`,
+§7): «`config/get` advertises `radar_stage1_api:1` **only after coordinator
+setup**. Absent capability disables radar operations with an update message;
+fields still survive.» Проверено чтением `custom_components/houseplan/__init__.py`:
+`data.radar_coordinator = RadarCoordinator(hass, data)` затем
+`await data.radar_coordinator.async_setup()` без `try/except` (61–88) — при
+ошибке `async_setup()` `async_setup_entry` целиком падает; при выгрузке записи
+(`__init__.py:299-301`) `radar_coordinator` становится `None`, но уже сохранённый
+`entry.runtime_data` может пережить это окно, если клиент успевает вызвать
+`config/get` между `teardown()` и повторной установкой при перезагрузке записи.
+В этом окне фронтенд получит `radar_stage1_api: 1`, попробует
+`houseplan/radar/subscribe` и получит непредсказанную ошибку вместо
+задокументированного «graceful degrade» с update-сообщением. Ни один backend
+или frontend тест не проверяет значение этого поля (`grep radar_stage1_api` по
+`tests_backend/` — пусто); фронтенд (`src/version-recovery-card.ts:66`) уже готов
+корректно обработать отсутствие капабилити (`=== 1 ? 1 : null`) — не хватает
+только серверной стороны условия.
+
+**M-3 (новая). `radar.bad_references` — объявленный и переведённый текст, на
+который код никогда не попадает; неоднозначная и «недалеко от монтажа»/
+коллинеарная ошибки выбора точек показывают общий, менее полезный текст.**
+`src/radar-geometry.ts:44-53`: и гард «референс ближе 50 см от монтажа», и гард
+«угол между референсами <20°/>160°» (буквально совпадающий с текстом
+`bad_references`: «Choose separated references in different directions from the
+sensor») бросают одно и то же `invalid_selection`; провал radial/RMS-подбора
+(строка 77, `if (!candidates.length) throw new Error('invalid_selection')`)
+бросает то же самое. `src/radar-setup.ts:333`:
+`state.error = message === 'ambiguous_sources' ? 'radar.ambiguous_sources' :
+'radar.bad_fit'` — то есть *всё*, что не «ambiguous», получает
+`radar.bad_fit` («Measurements do not match. Check units, mounting point and
+references»), а специально переведённый на 4 языка (`src/i18n/en.json:494`)
+`radar.bad_references` («Choose separated references in different directions
+from the sensor») не читается никаким `.ts`-файлом вообще (проверено `grep -r
+bad_references src/ test/` — только объявление в словарях). Сценарий: пользователь
+ставит обе контрольные точки почти на одной прямой от датчика (частая ошибка —
+обе точки у одной стены) и получает общее «проверьте единицы/установку», а не
+конкретную подсказку «выберите более разнесённые направления», которую именно
+для этого случая спроектировала и перевела спецификация. Функционально мастер
+работает (ошибка показывается, повторный ввод возможен), это не блокирует
+сценарий, но выданное указание вводит в заблуждение ровно как M4 из r1 (тот же
+класс дефекта, другая пара сообщений). Не поймано существующим гейтом
+`test/i18n-dead-keys.test.mjs`, потому что его паттерн для динамических ключей
+слишком широк (детали — issue #502 ниже, вне скоупа этой ветки).
+*Проверка:* `grep -n "bad_references" src/*.ts test/*.mjs` — совпадений в коде нет, только в `src/i18n/*.json`.
+
+### Low (на усмотрение автора, не блокируют)
+
+- Фикс H4 (комната без контура открывает мастер с предупреждением) корректен по
+  чтению (`src/editors/radar-section.ts:185-197`, ключ `radar.no_contour`
+  переведён отдельно и по-разному на все 4 языка), но не покрыт ни одним тестом:
+  ни `test/radar-editor.test.mjs`/`radar-setup.test.mjs`, ни
+  `demo/smoke_radar_setup.mjs` не строят комнату с `poly.length < 3` и не
+  проверяют, что мастер всё равно открывается (а не рефьюзится, как раньше).
+  Удаление этой ветки кода не уронит ни одного текущего теста.
+- Основной механизм M3 («Изменить установку» получает свежий UUID даже при
+  совпадающих итоговых координатах) верен по трассировке кода
+  (`src/editors/radar-section.ts:198-204` → `radarConfigFromDraft` →
+  `mount.installation_id`), но именно этот сценарий (совпадающие x/y, новый UUID)
+  не проверен тестом — единственная существующая проверка UUID
+  (`test/radar-editor.test.mjs:69`) доказывает лишь, что генератор не
+  детерминирован, а не то, что кнопка действительно его вызывает.
+- Планка 4 кадра/с (`custom_components/houseplan/radar.py:236-256`,
+  `_schedule_publish`/`_flush_pending`) — общая на весь координатор
+  (`_pending`/`_last_publish_monotonic` — поля координатора, не радара), тогда
+  как §4 спецификации формулирует её как «4 geometry frames/s/radar». При
+  нескольких одновременно активных радарах (до 32 по лимиту) их суммарная частота
+  делится на общий бюджет, а не даётся каждому независимо — это не превышение
+  потолка (не гонка/утечка), а более скромная деградация под нагрузкой, чем
+  буквально обещано текстом.
+- Ни для одного из AC S1-1/S1-5/S1-13/S1-16/S1-19 нет golden-сцены: `find demo/golden
+  -iname "*radar*"` — пусто, ровно то же наблюдение, что r1 сделал в разделе «Как
+  проверялось», не переросшее в Medium. За прошедший раунд это не изменилось.
+  Не поднимаю до Medium в этом раунде тоже: там, где AC называет golden
+  соевидетелем наряду с unit/smoke, конкретные защитные утверждения (частичное
+  здоровье, отрисовка зон, гейт допустимости, отказ неподдерживаемых команд) уже
+  доказаны прицельными негативными тестами с честным «чем краснеет» — см. таблицу
+  ниже. Рекомендую добавить радарную golden-сцену до кандидата беты, не как
+  условие зелёного вердикта этого раунда.
+
+## Закрытие раунда r1
+
+| Находка r1 | Чем закрыта | Где видно |
+|---|---|---|
+| H1 — «partial» не существует, смешанные/полностью устаревшие данные неотличимы | `radar.py:551-554` вычисляет `has_current_evidence`, различает `partial` (часть слотов свежая, часть нет) и `stale` (нет ни одной свежей) как разные ветки | `tests_backend/test_ha_radar.py::test_mixed_current_and_stale_coordinate_slots_report_partial` (108-129) строит 2-слотовый радар с 1 свежим+1 просроченным слотом, `occupancy=True`, и требует `health == "partial"`, `complete is False` — схлопывание в `stale` уронило бы тест |
+| H2 — гонка teardown/await воскрешает подписки | `async_refresh()` (121-148) берёт `self._lock` и перепроверяет `self.closed` сразу после единственного await; `teardown()` (150-172) выставляет `closed=True` синхронно до `async_track_*` cleanup | `test_teardown_during_config_load_cannot_resurrect_subscriptions` (307-324) — реальный неразрешённый `asyncio.Future` как результат `config_store.async_load`, `async_setup()` запущен как задача, `sleep(0)` даёт ей засеять на await под локом, `teardown()` вызывается пока задача приостановлена, затем future резолвится — тест требует `radars == {}`, `_unsub_config is None`, `_unsub_sources == []`; это настоящее чередование await, не последовательный вызов |
+| H3 — нет same-device проверки для LD2450 | `radar_validation.py:147-180` (`_validate_verified_adapter`) требует данные реестра, сверяет `device_id` всех источников (ровно одно устройство), `platform == "esphome"`, модель в `LD2450_MODELS`, и отдельно — совпадение с устройством самой привязки маркера | `test_radar_validation.py::test_ld2450_verified_adapter_requires_same_esphome_marker_device` (69-88) — 4 разных отказа (чужое устройство/чужая модель/чужое устройство привязки) с разными сообщениями; воспроизведено также в `test_ha_radar.py` через `_coordinator()` с реальными записями реестра |
+| H4 — отказ вместо предупреждения для комнаты без контура | `src/editors/radar-section.ts:185-197` теперь отдельно обрабатывает «нет комнаты вовсе» (отказ, `radar.invalid`) и «комната есть, контур короче 3 точек» (предупреждение `radar.no_contour`, мастер всё равно открывается — `setup.begin` не проверяет `room.poly`) | Прочитано и прослежено по коду `configureOnPlan`/`RadarSetupController.begin` (`src/radar-setup.ts:108-119`); ключ `radar.no_contour` переведён на 4 языка. **Автотеста нет** — см. Low выше |
+| H5 — известные зоны не рисуются | `src/radar-render.ts:18-24` рендерит `frame.zones`, фильтруя занятые, в `<polygon class="radar-zone">`; CSS `src/styles/plan.styles.ts:1448-1454` — `stroke-width: 2px`, `fill: color-mix(…8%, transparent)` | `test/radar-render.test.mjs:11-20` — рендерит занятую и пустую зону, проверяет класс/id/точки полигона и что пустая зона даёт `nothing` |
+| H6 — смена привязки может стереть сохранённую конфигурацию | `src/radar-editor.ts:65-75` (`radarAfterBindingChange`) различает черновик с `.original` (сохранённый — переживает смену привязки нетронутым) и без него (несохранённое Q5-объявление — стирается); оба места вызова в `houseplan-editor-runtime.ts` (13015, 13071) используют эту функцию вместо `radarRemove: d.radarRemove \|\| !!d.radar` | `test/radar-editor.test.mjs:60-70` — сохранённый черновик даёт `{radar:saved, radarRemove:false}`, несохранённый — `{radar:null, radarRemove:true}` |
+| M1 — Stage 2/3 валидация реализована преждевременно | `_validate_stage2` удалена полностью (её больше нет в файле); `_validate_settings` (358-363) проверяет только `version`/`show_live` | `test_future_stage_extensions_are_preserved_but_inert_in_stage1` (140-148) — блок `zones.local` с геометрически невалидным (вырожденным) полигоном проходит нетронутым; `test_future_fusion_and_output_settings_round_trip_without_stage1_validation` (227-248) — то же для `fusion_groups`/`room_outputs` |
+| M2 — распознавание по тексту manufacturer/model | `src/radar-editor.ts:55-127` требует структурное совпадение: `canonicalModel(...)` ∈ curated `LD2450_MODELS`, плюс суффиксное совпадение entity id (`target_1_x`/`target_1_y`); поле `manufacturer` объявлено в интерфейсе, но в логике сопоставления не читается | `test/radar-editor.test.mjs:49-58` — устройство с `model: 'Presence Radar FP2'` и координатными именами сущностей **не** признаётся допустимым (негативный тест) |
+| M3 — «Изменить установку» не реализовано; закрытие «грязного» мастера не спрашивает | `changeInstallation()` (`radar-section.ts:198-204`) генерирует свежий `installationId`, доступна только для `radar.original` (сохранённого); `RadarSetupController.discardIfAllowed()` (`radar-setup.ts:130-137`) спрашивает подтверждение через `host.confirmDiscard()`, `_closeMarkerDialog` маршрутизирует через guarded-путь при `isDirty()` | `test/radar-setup.test.mjs:46-80` — отмена на чистом/грязном+подтверждённом/грязном+отклонённом состоянии, все три ветки. Сценарий «одинаковые x/y → новый UUID» именно через кнопку — не тестирован, отмечено в Low |
+| M4 — неоднозначность маскируется под «плохие референсы» | `src/radar-setup.ts:331-336` — `ambiguous_sources` маппится в отдельный `radar.ambiguous_sources`, отличный от `radar.bad_fit` | `test/radar-geometry.test.mjs:54-59` — RMS двух зеркальных гипотез <10см даёт именно `ambiguous_sources`; словари 4 языков дают разный текст для двух ключей |
+| M5 — блок радара не в конце тела диалога | Основной (уже настроенный/распознанный) раздел остался на прежнем месте намеренно (спецификация требует «в конце» только для Q5-объявления неопознанного устройства); Q5-действие (`placement === 'additional'`, `radar-section.ts:76-86`) теперь рендерится в `<details class="radar-additional">` после Model/Link/Description/PDF и перед `footer` (`houseplan-editor-runtime.ts:13573`, до `:13575`) | Прочитано по месту вызова: секция вставлена между блоком PDF (13542-13572) и `<div class="row marker-footer" slot="footer">` (13575) |
+| M6 — 2/8 кодов ошибок отсутствуют; гварды решателя не тестированы | Коды `unsupported_capability`/`source_unavailable` реализованы и протестированы (см. M-1 выше). Гварды решателя закрыты **частично**: коллинеарность — тестирована, дистанция/RMS/неоднозначность на Python-стороне — нет | См. новую находку **M-1** выше — перенесено туда как незакрытый остаток, не задвоено в оба списка |
+| Low: USER-GUIDE цитирует несуществующий текст переключателя | `docs/USER-GUIDE.md:739`/`ru.md` теперь цитируют «Show live presence on the plan» / «Показывать текущее присутствие на плане», совпадает с `gs.radar_show_live` в `en.json:468`/`ru.json:468` дословно | `grep` подтверждает совпадение |
+| Low: `restricted`/`incomplete` схлопываются в `health_unknown` | `RADAR_HEALTH_KEYS` (`radar-model.ts:16-22`) получил отдельные `radar.health_restricted`/`radar.health_incomplete` | Прочитано по коду |
+| Low: `report_age` не показывается в Advanced | `radar-section.ts:461-464` вычисляет и показывает возраст отчёта | Прочитано по коду |
+| Low: `recognizeRadar` не в `radar-model.ts` | Не перенесено — предикат остался в `radar-editor.ts` | Архитектурная рекомендация, не обязательная; автор не обязан был чинить Low |
+
+## Что проверено и корректно (сверх таблицы закрытия r1)
+
+- **Права и лимиты не ослаблены при полном перечитывании**: `may_write` на
+  `setup/inspect`/установку, per-entity ACL на подписку/инспекцию, лимиты
+  10 инспекций/мин, 4 live-подписки/пользователь, 8 глобальных/1 на маркер
+  setup-подписок и `MAX_RADARS=32` — все на месте с тестами (подтверждено
+  фоновым агентом и выборочно перепроверено чтением `radar.py`/`radar_websocket.py`).
+- **Регрессия общего закрытия диалога маркера (`1e610410`) устранена корректно**:
+  до фикса `_closeMarkerDialog()` стал безусловно асинхронным
+  (`void this._closeMarkerDialogGuarded()`) из-за проверки радар-состояния,
+  затрагивая *все* маркеры, не только радарные. Сейчас — синхронное закрытие,
+  если `_radarSetup.isDirty() === false` (обычный случай), и guarded-путь только
+  при незавершённой калибровке. `test/radar-setup.test.mjs` получил прямые
+  проверки `isDirty()` на пустом/начатом состоянии; смоки `smoke_marker_stay`,
+  `smoke_dialog_zombie`, `smoke_new_device`, `smoke_toggle_entity` (выбраны вручную
+  как нерадарные потребители общего пути закрытия) — все зелёные.
+- **Один источник числа**: живая координата в «Advanced» диагностике и координата,
+  используемая для проекции/принадлежности зоне, идут из одного и того же
+  `RadarLiveFrame`/`radar-model.ts`; клиентская геометрия (`projectRadarLocal`)
+  используется только внутри эфемерного, сессионного мастера настройки, не в
+  принятом (post-Save) пути отображения. Регрессии класса #234/#233 не
+  просматривается.
+- **Новый `any` не добавлен** (`no-new-any.mjs`, 2076 строк/14 файлов — 0 совпадений).
+- **i18n-структура**: `en`/`ru`/`de`/`fr` синхронно получили одинаковый набор
+  новых ключей (`git diff --stat` — по 106 строк в каждом словаре); `test/i18n.test.mjs`
+  разрешает намеренные англо-идентичные `de`/`fr` значения (`radar.source_optional`,
+  `radar.heading`, `radar.radians`) явным списком, а не молчаливым допуском.
+- **Трейлеры и changelog**: оба `User-Visible: yes` коммита диапазона (`5e3adac4`,
+  `c670b1bf`) несут правки в `docs/CHANGELOG.md`+`docs/CHANGELOG.ru.md` в себе же;
+  `Issue: #485` — во всех коммитах диапазона.
+- **Инварианты геометрии не применимы**: radar-код не трогает рёбра/толщину/
+  `layout`/`open_spans` — проверено `grep` по всем изменённым файлам.
+
+## Чего не проверял
+
+- **`python -m pytest tests_backend/test_ha_radar*.py test_radar_geometry.py
+  test_radar_validation.py -q` лично не прогонял.** Песочница ревью не имеет
+  готового venv Python 3.14 с `pytest-homeassistant-custom-component`; попытка
+  создать venv (`/opt/az/bin/python3.14 -m venv` + `pip install -r
+  tests_backend/requirements.txt`) прошла успешно, но сам pytest упал на
+  `ModuleNotFoundError: No module named '_sqlite3'` — системный Python 3.14 в этом
+  окружении собран без `sqlite3` (нет `_sqlite3.so`), а
+  `pytest_homeassistant_custom_component.plugins` жёстко импортирует `sqlite3`.
+  Чинить это через пересборку Python или системный `apt` ради одного раунда
+  ревью — непропорциональные действия. Опираюсь на: (а) зелёный Validate на
+  точном SHA `1e610410` (backend job гоняет полный `tests_backend`,
+  https://github.com/Matysh/houseplan-card/actions/runs/34275082664); (б)
+  построчный разбор каждого нового/изменённого теста фоновым агентом с указанием
+  точной команды и того, что именно мутирует находка — эквивалент «прочитано, не
+  исполнено» для каждого конкретного теста, включая свежепостроенный
+  race-тест H2, который я прочитал лично и подтверждаю, что он действительно
+  чередует await, а не вызывает методы последовательно.
+- **`npm run golden:verify` не прогонял в этом раунде.** r1 уже установил (свой
+  контрольный прогон на чистом `origin/dev` тем же набором «different» сцен), что
+  расхождения полного матрикса — окруженческий шум этой песочницы, не регрессия
+  ветки; diff с r1 по golden-релевантным файлам — только уже принятый
+  `general-color-popover-desktop-en` baseline (не тронут дальше) и
+  `baselines-index.json`. Правок в рендер, задевающих существующие golden-сцены,
+  в дельте r1→r2 нет (единственная новая визуальная поверхность — `radar-render.ts`/
+  CSS, для которой golden-сцен не существует вовсе — см. Low).
+- **Полный `demo/smoke_*.mjs` матрикс (234 файла)** не гонял — `smoke-select.mjs`
+  вернул только 2 прямых совпадения (оба зелёные) плюс широкие символы
+  (`_closeMarkerDialog`/`_markerDialog`/`_editorRuntime`/`_mode`/`_cfgRev`),
+  закономерно задетые правкой общего диалога; вместо полного прогона выбрал 4
+  дополнительных нерадарных смока, реально использующих `_closeMarkerDialog`
+  (обоснование выбора — в таблице гейтов). Полный матрикс — предрелизная
+  обязанность (PROCESS §8), не обязанность этого раунда.
+- **`python -m pytest tests_backend -q` (весь набор, 799 тестов)** — не гонял по
+  той же причине окружения; полагаюсь на зелёный Validate тем же аргументом, что
+  и r1 использовал для этого пункта.
+- **Perf-профили** — не запускал: diff не трогает `src/iso-*`, `src/live-*`,
+  `src/render-*`, `houseplan-render-lifecycle.ts` управляющие профилями пути
+  напрямую помимо уже покрытых двумя всегда-идущими glow-профилями в Validate;
+  AC этой стадии не называют performance-профиль отдельным доказательством.
+
+## Итог
+
+0 High. 3 Medium в скоупе (M-1 продолжение M6, M-2 капабилити `radar_stage1_api`,
+M-3 мёртвый `radar.bad_references`) — все три доказаны конкретным чтением кода и
+названной командой/сценарием, все три чинятся в этой же ветке без переработки
+архитектуры. Отдельно заведён issue [#502](https://github.com/Matysh/houseplan-card/issues/502)
+на найденный вне скоупа этой ветки, но обнаруженный при её разборе, общий дефект
+теста `i18n-dead-keys` (широкий паттерн `^r.+$` маскирует мёртвые i18n-ключи по
+всему проекту, не только радарные) — это отдельная задача с меткой `tech-debt`,
+не правится внутри #485. 6 High и всё содержательное из 6 Medium r1 закрыто
+предметно, с воспроизводимой проверкой каждого (таблица выше); часть Low r1 тоже
+закрыта, не будучи обязательной. Вердикт — жёлтый: без High это возврат автору на
+доработку тех же трёх Medium в текущем issue, отдельный цикл не по архитектуре, а
+по трём точечным правкам (backend-тесты на 3 гварда, условие капабилити по
+`radar_coordinator`, маршрутизация `invalid_selection`→`bad_references` отдельно
+от radial/RMS-провала).
+
+---
+
+<!-- material-anchors: заполняется конвейером публикации -->
+
+---
+
+<!-- material-anchors: сгенерировано конвейером (#414) -->
+
+## Материал раунда
+
+- Ветка: `issue/485-radar-presence`, коммит `1e6104100cc7` — ребейз его осиротит, и это нормально: ниже якоря, которые ребейз не меняет.
+- Дерево материала: `da6ff25c3f681ed1584526e941b2dbc47e476705`
+  ```
+  git log --all --format='%H %T' | grep da6ff25c3f68
+  ```
+- ТЗ `docs/specs/485-radar-presence-stage1.md`, блоб `f6e7e122303a4c00192be58cdc387bbc4859c1e6`
+  ```
+  git log --all --find-object=f6e7e122303a4c00192be58cdc387bbc4859c1e6 -- docs/specs/485-radar-presence-stage1.md
+  ```
+- ТЗ `docs/specs/485-radar-presence-stage2.md`, блоб `b403e73fc26ba0ffb97be4ffa73be067d179880f`
+  ```
+  git log --all --find-object=b403e73fc26ba0ffb97be4ffa73be067d179880f -- docs/specs/485-radar-presence-stage2.md
+  ```
+- ТЗ `docs/specs/485-radar-presence-stage3.md`, блоб `c65e28389d762216c47f00249bdb751f3c9d5082`
+  ```
+  git log --all --find-object=c65e28389d762216c47f00249bdb751f3c9d5082 -- docs/specs/485-radar-presence-stage3.md
+  ```
+- ТЗ `docs/specs/485-radar-presence.md`, блоб `3297ed0140265ad86f2072a40cb9bf8097c0674d`
+  ```
+  git log --all --find-object=3297ed0140265ad86f2072a40cb9bf8097c0674d -- docs/specs/485-radar-presence.md
+  ```