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

# CODE-REVIEW-82-r2

- **Issue:** #82 «Плавное масштабирование плана: анимация zoom/fit/reset»
- **Этап:** code (PROCESS.md §2.7)
- **Заход:** r2 · блокирующих циклов израсходовано 0 из 4 (r1 был зелёным, бюджет не тратил, #227)
- **Материал:** `origin/dev...HEAD`, HEAD = `cc73252aa73007db3bd636b02eec3dd8ece871b2`
- **origin/dev на момент ревью:** `e39cd3dfa1453be140ab809cd4344f9474bd0b2c`
- **Диапазон:** 13 коммитов, `8a18e812`…`cc73252a`
- **Вердикт:** зелёный · High: 0 · Medium: 0

## Почему разбор полный, а не по дельте

После зелёного r1 (вердикт на SHA `779382af`, комментарий 2026-08-30T15:51:14Z)
ветка была ребейзнута на ушедший вперёд `dev` (`e39cd3df`), а после этого
довешено ещё 6 коммитов, которых r1 не видел (`a945ca47`…`b5324ce4`, см. ниже).
Ребейз на ушедший вперёд dev — один из явных случаев, для которых инструкция
требует полный разбор, а не разбор по дельте (§7.2: после ребейза это другой
код). Поэтому весь диапазон `origin/dev...HEAD` перечитан и перепроверен
заново, включая часть, которую r1 уже одобрил, а не только новые 6 коммитов.

Отдельное наблюдение по процессу (не находка к коду, Low): комментарий
владельца «Финальный rebase… Единственный конфликт был в
docs/images/screenshots.json… исходный код и поведение камеры не
конфликтовали» описывает состояние ДО того, как в ветку попали ещё 6 коммитов
(`a945ca47`…`b5324ce4`), один из которых (`64f54fd4`) меняет реальное поведение
`src/houseplan-card.ts` (см. AC1/AC5 ниже), а не только тесты и скриншоты.
Ни один из этих 6 коммитов не описан в отдельном комментарии issue. Это не
блокирует ревью — полный разбор ниже покрывает эти коммиты по существу — но
статус-комментарии в этом раунде не отражали фактический diff на момент
возврата задачи в S7.

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

### Дешёвые гейты

Validate на точном HEAD `cc73252a` зелёный
(https://github.com/Matysh/houseplan-card/actions/runs/33320914612), поэтому
`tsc --noEmit`, `npm test` (1642, см. предыдущий зелёный прогон) и
`npm run build` со сверкой копий бандла не перегонялись как отдельная
проверка. Тем не менее `npm run bundle:sync` (= `tsc --noEmit && rollup -c` +
раскладка) выполнен локально по ходу подготовки к golden — прошёл чисто,
`dist`/`custom_components/.../frontend`/`demo/srv/assets` идентичны после
сборки, `git status` остался чистым (значит закоммиченные бандлы уже
соответствуют исходникам этого HEAD).

`node scripts/check-docs.mjs` — выполнен (diff трогает `src/**`):
`Documentation checks passed (7 files, 10 external links)`.

### Golden (не покрывается перечнем «дешёвых» гейтов из шапки этого раунда)

Diff меняет рендер (camera-контроллер, 8 «унаследованных из dev» golden-baseline
и 4 doc-скриншота, включая правку `screenshots.json`). Запущен
`npm run golden:verify` — **147/147 passed**, включая все 8 файлов из коммита
«test: accept inherited dev golden updates» (`device-dialog-desktop-de`,
`device-dialog-mobile-ru`, `toggle-entity-dialog-mobile-ru`,
`device-ripple-color-popover-mobile-ru`, `tray-medium-group-en` и т.д. — все
`passed` в выводе). Это подтверждает утверждение коммита не как заявление
автора, а как воспроизведённый прогон: текущий код рендерит ровно то, что
принято в качестве эталона, независимо от того, что сами PNG побайтово
отличаются от версии в `origin/dev` (шумовая перекодировка/иной прогон
захвата — не дефект).

### Browser smoke — выбор по диффу

`node scripts/smoke-select.mjs --base origin/dev --head HEAD`: 49 прямых
совпадений, 33 слабые связи (общий символ вроде `_modeTransitionBusy`,
`stopPropagation`). Прогнаны:

- все смок-файлы, которые сам diff **редактирует** (значит, r1 их в этом виде
  не видел): `smoke_canvas_frame`, `smoke_infinite_canvas`, `smoke_kiosk`,
  `smoke_kiosk_pan_lock` — все правки только добавляют `await` на
  устаканивание камеры перед проверкой существующих инвариантов, поведение не
  меняют;
- главный доказатель AC — `smoke_smooth_zoom` (250 строк, покрывает
  AC1–AC12, AC14 согласно ТЗ §18);
- обязательный минимум регрессий из ТЗ §18 и уже проверенный r1 набор:
  `smoke_zoom_out`, `smoke_editor_gestures`, `smoke_furniture`,
  `smoke_opening_preview`, `smoke_visual_continuity` (#73),
  `smoke_warm_remount`, `smoke_mode_transition` (#101),
  `smoke_isometric_contract`, `smoke_glow`, `smoke_glow_geometry_resilience`.

Все 15 — **зелёные** (полный вывод каждого — все ключи `true`/`OK`).

Остальные 34 «прямых» совпадения из смок-select не прогнаны: они привязаны к
`_baseVb`/`_viewOr`/`_cursorPt`/`_modeTransitionBusy` — символам, которые
внутри строки почти не меняли поведение (только сигнатуры точек входа и
уборка opening-курсора при старте команды камеры, без изменения самой логики
черчения/декора/wall-thickness). Слабые связи (33) не прогонялись — общее имя
без прямого попадания в изменённый символ.

### Что не прогонялось и почему

- `python -m pytest tests_backend` — diff не трогает `custom_components/**/*.py`
  (только сгенерированный JS-бандл внутри `custom_components/.../frontend`).
- `npm run invariants` — diff не трогает геометрию (нет правок рёбер комнат,
  записей толщины, `layout`, `marker.space`, `open_spans`); камера работает
  только с `viewBox`/`zoom`.
- Performance-профиль/screencast для AC13 — не прогонялся. ТЗ §21 и матрица
  AC13 сами относят это к предрелизному Full Performance гейту, не к
  автотесту в цикле ревью; то же решение уже дважды принято (r1 spec-review и
  r1 code-review). Косвенно AC13-риск (Glow/geometry rebuild на кадре)
  проверен `glowAndStructuralFrameStayStable` в `smoke_smooth_zoom` и
  `smoke_glow_geometry_resilience` — оба зелёные.
- `test/single-source-numbers.test.mjs` — механически входит в `npm test`
  (уже зелёный по Validate). Смысловая проверка сделана вручную: zoom badge
  (`src/houseplan-card.ts:11517`, `Math.round(this._zoom * 100)}%`) — единственное
  место, где процент зума выводится пользователю; он читает `this._zoom`
  напрямую, то же поле, которое `_applyCameraTransitionFrame` обновляет на
  каждом кадре. Второго источника числа не найдено.

## AC1–AC14: доказательства

| AC | Статус | Доказательство |
| --- | --- | --- |
| AC1 | Выполнен | `smoke_smooth_zoom`: `buttonHasIntermediateFrame`, `fitHomeAndDoubleTapAnimate`, `farFitUsesTheSameTransition` — все `true`; код `_stepZoom`/`_resetZoom`/`_fitAll`/`_fitFar` в `src/houseplan-card.ts:6270-6345` строят target существующей `fitView`/`_clampView` и передают его в `CameraTransitionController` |
| AC2 | Выполнен | `smoke_smooth_zoom.pinchIsDirectWithoutPostAnimation`, `smoke_editor_gestures` (pinch/pan в редакторе) — зелёные; `_zoomAt()` (immediate-путь) не создаёт transition |
| AC3 | Выполнен | Прочитано кодом: единственные reactive `_zoom`/`_view` пишутся только в `_applyCameraTransitionFrame`/`_settleCameraTransition`/`_zoomAt`, все SVG/HTML/hit-слои читают их через общий рендер-путь; `smoke_smooth_zoom.pointerdownFreezesPresentedFrame` подтверждает, что pointerdown видит реально представленный кадр, а не устаревший target |
| AC4 | Выполнен | `smoke_smooth_zoom.wheelRetargetsRunningTween` (разные token, `reverseFrom≈presentedBeforeReverse`), `wheelReversalKeepsAnchor` (≤0.5px) |
| AC5 | Выполнен | `smoke_smooth_zoom.exactLimitsAndFitAreNoops` (`active=false`, `saves=0` на fit/max/min); код `_startCameraTransition` (houseplan-card.ts:1207-1223) возвращает `false` без RAF/`_saveZoom`, если target совпадает с текущим или с уже бегущим target |
| AC6 | Выполнен | `pointerdownFreezesPresentedFrame`, `projectionCancelsAndIsoSettlesExactly`, `hiddenCommitsTargetOnce` — все `true`; код: `_cancelCameraTransition` вызван в `_stagePointerDown`, `_commitSpace`, `_setProjection`-пути (через `_cancelModeTransition`/adoption), `_refitView`, `_pageVisibility('hidden')`, config/layout adoption (`b3abfc67`) |
| AC7 | Выполнен | `smoke_warm_remount`, `smoke_visual_continuity` (#73) — зелёные без изменений поведения |
| AC8 | Выполнен | `reducedMotionIsImmediate` (`true`); `_onMotionChange` вызывает `_cancelCameraTransition(true)` при включении reduced motion, `_startCameraTransition` передаёт `duration=0` при `_reducedMotion` |
| AC9 | Выполнен | `buttonPersistsOnce`/`wheelStreamPersistsOnce` (`saves===1`); `_saveZoom()` вызывается только из `_settleCameraTransition`, один раз на settle |
| AC10 | Выполнен | `projectionCancelsAndIsoSettlesExactly` — итоговый `viewBox`/`zoom` точно совпадает с независимо вычисленным `_cameraTargetAt` |
| AC11 | Выполнен | `glowAndStructuralFrameStayStable` (`JSON.stringify` до/после равны); `smoke_glow`, `smoke_glow_geometry_resilience` зелёные |
| AC12 | Выполнен | `disconnectedCallback` вызывает `this._cameraTransition.dispose()` (houseplan-card.ts:2745); unit `viewport-transition.test.mjs` — `dispose()`→`cancel(false)` не оставляет RAF (`fake.callbacks.size===0` в тесте «cancel policies») |
| AC13 | Deferred (не автотест здесь) | То же решение, что в r1 spec- и code-review: закрывается предрелизным Full Performance/screencast гейтом, не циклом ревью. Косвенно риск закрыт `glowAndStructuralFrameStayStable` |
| AC14 | Выполнен | `coldViewDoesNotLoadEditorRuntime` (`true`, проверка через `performance.getEntriesByType('resource')`); `src/houseplan-editor-runtime.ts` не тронут диапазоном |

## Дельта сверх того, что видел r1

Сверх `c465eae8`/`54403704`/`b3abfc67` (уже одобрены r1 под именами
`895b120e…779382af`) в диапазон добавлено:

- `a945ca47` — `demo/docs/capture.mjs`: ждёт `card._cameraTransition?.active`
  перед снимком, иначе бросает. Тестовая инфраструктура, поведение продукта
  не меняет.
- `64f54fd4` — **единственный коммит с правкой продуктового кода** сверх
  того, что видел r1: `_fitFar()`/`_fitAll()` получили безусловный
  `this.requestUpdate()` перед `_resetZoom(...)` (houseplan-card.ts:5975,
  5985). Причина: `_showFar` — обычное приватное поле, не Lit `@state()`
  (houseplan-card.ts:5755), поэтому раньше рендер после клика по far-hint
  зависел от того, что `_resetZoom()` синхронно меняла `_zoom`/`_view` и тем
  самым просила update. С #82 `_startCameraTransition` может вернуть `false`
  без единого вызова хуков (когда camera-target уже совпадает с текущим) —
  и тогда без явного `requestUpdate()` смена `_showFar` не попала бы в
  рендер. Остальные правки того же коммита — `await` на устаканивание камеры
  в `demo/golden/harness.mjs`, `smoke_canvas_frame`, `smoke_infinite_canvas`,
  `smoke_kiosk` — тестовая инфраструктура.
  **Low, не блокирует:** конкретно этот no-op-путь (far-hint нажат, когда
  camera-target уже равен текущему — например повторный клик до истечения
  предыдущего fit-far) не покрыт отдельной smoke-проверкой; существующие
  тесты far-hint (`smoke_infinite_canvas.hintGoneAfterShow`) всегда бьют по
  сценарию с реальным движением камеры. Правка защитная и дешёвая
  (лишний `requestUpdate()` не создаёт видимых артефактов), риск регрессии
  низкий, поэтому не блокирует зелёный вердикт.
- `4c4399a7`, `4e24e266`, `9171644f` — три последовательных пересъёма
  doc-скриншотов (`08-room-card.png`, `09-device-info.png`,
  `06-device-editor.png`) с обновлением `screenshots.json`; `check-docs.mjs`
  зелёный на финальном состоянии.
- `b5324ce4` — 8 golden-baseline из `origin/dev`, подтверждены прогоном
  golden:verify выше (не только заявлением коммита).

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

| Находка r1 | Чем закрыта | Где это видно |
| --- | --- | --- |
| `55cf36d6`/`b3abfc67 fix: preserve structural adoption guard` — по факту перестановка двух независимых операторов без наблюдаемой разницы поведения, замечание только к формулировке сообщения коммита | Не блокировала r1, не блокирует и сейчас; независимо перечитан diff коммита `b3abfc67` в этом раунде — подтверждаю: переставлен только порядок `this._cancelCameraTransition(false)` относительно очистки `_geometryHistory`/`_devicePositionHistory`/`_pendingPhysicalWrites`, эти операции не пересекаются по состоянию | `git show b3abfc67 -- src/houseplan-card.ts` |
| AC13 закрыт только предрелizным Full Performance гейтом, не автотестом в цикле | Тот же прецедент подтверждён и на этом SHA — решение не изменилось | Раздел AC13 выше |

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

Поскольку ребейз на ушедший вперёд `dev` требует полного разбора (§7.2), из
r1 ничего не принято «на слово» без собственной перепроверки в этом
раунде — весь диапазон, включая уже одобренные r1 коммиты, перечитан заново
и его гейты (golden, smoke, check-docs, build) перезапущены в этом раунде.
Без повторной проверки принято только решение уровня продукта/процесса,
которое не является предметом код-ревью:

- продуктовая корректность ТЗ (структура §7.1, формулировки AC, отсутствие
  недекларированных догадок) — из `SPEC-REVIEW-82-r1.md`
  (`docs/reviews/SPEC-REVIEW-82-r1.md`, ТЗ на SHA `141d79a9`); код-ревью не
  переоценивает качество ТЗ, только соответствие ему;
- прецедент «AC13 закрывается предрелизным Full Performance гейтом» — принят
  ещё в `SPEC-REVIEW-82-r1.md` и переподтверждён `CODE-REVIEW-82-r1.md`; в
  этом раунде не пересматривается заново, только сверено, что новых
  Glow/geometry-путей в дельте нет (см. выше).

## Итог

High: 0. Medium: 0. Low: 3 (2 унаследованы и переподтверждены, 1 новая —
непокрытый smoke-тестом no-op-путь `_fitFar()`/`_fitAll()`, не блокирует).
Все AC1–AC12, AC14 подтверждены исполненным автотестом или разобраны по коду
с указанием строк; AC13 корректно отложен на предрелизный гейт по уже
принятому прецеденту. Вердикт: зелёный.