docs: specify isometric toggle performance

Issue: #124
User-Visible: no

docs/reviews/SPEC-REVIEW-154-r1.md

@@ -1,295 +0,0 @@
-# Ревью ТЗ — issue #154, цикл r1
-
-- **Issue:** https://github.com/Matysh/houseplan-card/issues/154
-- **ТЗ:** `docs/specs/154-touch-hover-reset.md`, коммит `cd3c7752a8846c11508a7a6b4c46b6d990624408`
-- **Этап:** spec (PROCESS.md §2.4)
-- **Вердикт:** жёлтый · цикл r1/4 · High: 3 · Medium: 1
-
-## Скоуп ревью
-
-Прочитаны в указанном порядке: `docs/SCOPE.md`, `AGENTS.md`, `PROCESS.md`
-(§1–§4, §7, §12), тело issue #154 и оба комментария владельца (аналитика
-2026-08-15: P1/bug/polish, обычный трек, «trivial запрещён из-за touch
-impact», «вопросов нет»; публикация ТЗ), `docs/USER-GUIDE.ru.md` (термины
-«hover», раздел ограничений «Комнатные подсказки основаны на hover»),
-`docs/TOUCH-SUPPORT.md` (input classification, deliberate degradation),
-`docs/UX-MODES.md` (contract View: «room hover highlight, hover tooltips»),
-`docs/CANVAS.md` (проверка, действительно ли это канонический документ для
-hover-контракта — нет, см. Medium-1) и `docs/TESTING.md` (существующий
-контракт «No hover tooltips on touch», v1.43.3/v1.42.2).
-
-Issue не помечен `small`/`trivial`; ТЗ корректно лежит файлом в
-`docs/specs/154-touch-hover-reset.md`, а не в теле issue. Формат ревью —
-полный документ, не комментарий.
-
-Для калибровки того, что этот репозиторий уже считает обязательным
-оформлением §7.1, сверился с `docs/specs/138-adjacent-room-autoclose.md`
-(разделы «1. Сценарий и продуктовый контекст» / «2. Что человек увидит до и
-после») и его ревью `docs/reviews/SPEC-REVIEW-138-r1.md` — оно отдельной
-строкой подтверждает наличие обоих разделов как условие «обязательные
-разделы §7.1 на месте».
-
-## Как проверялось
-
-Ревью также читало код, на который ТЗ опирается как на текущее поведение —
-чтобы отличить обоснованное утверждение от догадки, выданной за факт:
-
-- `src/houseplan-card.ts:5442–5470` (`_notePointer`) — подтверждает
-  формулировку issue и ТЗ: touch/pen действительно закрывает `_tip`
-  (`5446`), но не трогает `_hoverRoom`. Совпадает.
-- `src/houseplan-card.ts:659,662,1759–1760` — `_tip`/`_hoverRoom` как
-  реактивный state; `14619–14646` — room hover действительно навешан через
-  `@mouseenter`/`@mouseleave` на path/polygon/rect комнаты, без
-  `pointerenter`/`pointerleave`. Совпадает с §6 ТЗ.
-- `src/houseplan-card.ts:1285,5443,9494,11167` — уже существует
-  `_boundaryPointerType`, session-local поле «последний реальный
-  pointerType», используемое для decor-snap радиуса (`_decorSnap`) и
-  touch-детекции (`9494`). ТЗ §5 говорит «Houseplan вводит один
-  session-local источник фактической modality», не упоминая, что подобное
-  поле уже есть. Это не продуктовая двусмысленность (реализация — дело
-  автора, PROCESS §7.1), но реальный риск дублирования authority; отмечено
-  ниже как **Low**, без отдельного issue.
-- `grep ':hover'` по `src/` — 32 вхождения в 6 файлах
-  (`houseplan-card.ts`, `styles.ts`, `space-card.ts`, `hp-dialog.ts`,
-  `hp-device-preview.ts`, `hp-color-opacity.ts`, `hp-help.ts`). Ни один не
-  назван в ТЗ — см. **High-3**.
-- `docs/CANVAS.md` — единственное вхождение слова «hover» (строка 563,
-  «hover is only a preview and never authoritative») относится к preview
-  hit-резолвера архитектурного connection overlay в редакторе Плана
-  (endpoint/line snapping), а не к View-контракту room/device hover,
-  который меняет issue #154. `docs/UX-MODES.md:69–70` прямо перечисляет
-  «room hover highlight, hover tooltips» как часть допустимых
-  взаимодействий View — см. **Medium-1**.
-- `docs/TESTING.md:175–176,750–752` — существующий, уже протестированный
-  контракт «a hover tooltip never appears after ANY touch/pen pointer
-  event, even if the browser claims hover: hover» — ТЗ корректно описывает
-  его как частично реализованный и подлежащий расширению.
-- issue #152 (`gh issue view 152`) — действительно ещё `S4-spec-review`, не
-  реализован; ссылка ТЗ на «будущий #152» и решение не читать `_hoverRoom`
-  из его hit-резолвера корректны и не создают ложной зависимости.
-
-## Находки
-
-### High-1 — нет обязательных разделов «Сценарий» и «Что человек увидит до/после» (§7.1)
-
-**Где:** `docs/specs/154-touch-hover-reset.md`, весь документ; ближе всего
-раздел «1. Проблема и требуемый результат» (строки 9–19).
-
-PROCESS.md §7.1 требует ТЗ начинать с двух продуктовых разделов: «какая
-персона (`docs/SCOPE.md`), на какой поверхности, в какой момент это
-встретит» и «что человек увидит до и после, одной фразой без терминов
-реализации» — и подчёркивает, что «два первых раздела — продуктовые, и они
-идут первыми не случайно». Это не стилистическая рекомендация: сам
-репозиторий уже применяет это буквально в `docs/specs/138-...md`
-(разделы «1. Сценарий и продуктовый контекст» / «2. Что человек увидит до и
-после»), и предыдущее ревью того ТЗ отдельно проверяло их наличие как
-условие «обязательные разделы §7.1 на месте».
-
-В ТЗ #154 такого раздела нет вообще. Раздел 1 сразу входит в техническое
-описание бага (`_notePointer()`, CSS `:hover`, `mouseenter`/`mouseleave`), а
-второй абзац, который мог бы быть «что человек увидит», написан в терминах
-реализации: «показывает только краткий pressed feedback», «настоящие mouse и
-trackpad», «на гибридном устройстве последующий mouse input восстанавливает
-его» — это не «одна фраза без терминов реализации», а пересказ технического
-контракта.
-
-Персона и поверхность из `docs/SCOPE.md` — не абстракция: J1–J3 явно относят
-View к household members/guests на wall tablet и companion-приложении
-(«View mode is the product for two of the three personas»), а issue
-явно называет ещё и «мобильный браузер / HA Companion». Отсутствие
-явного раздела означает, что читатель ТЗ вынужден реконструировать это
-сам, а вопрос «какая персона важнее при конфликте» (например, «жертвуем ли
-чем-то ради гибридного admin-устройства ради гарантии touch у household
-member») в тексте не решён явно — только подразумевается порядком risk-строк
-§16.
-
-**Почему High:** это единственная площадка процесса, где владелец мог бы
-опротестовать выбор персоны/поверхности/степени деградации ДО написания
-кода (PROCESS §7.1: «Владелец отвечает на продуктовые вопросы… их место —
-этап ТЗ»); без явного раздела с этим согласиться (или оспорить) нечего —
-ревьюер не может подтвердить, что «что человек увидит» действительно решено,
-а не растворено в технической формулировке.
-
-**Что нужно поправить:** добавить два раздела по образцу #138 — «Сценарий»
-(персона/поверхность/момент, со ссылкой на J1–J3 `docs/SCOPE.md`) и «Что
-человек увидит до/после» одной фразой без «modality», «pointerType»,
-«hybrid», «pressed feedback» (например: «раньше подсветка комнаты/маркера
-после тапа могла остаться до следующего действия; теперь она гаснет сразу
-после отпускания пальца, а мышь на компьютере работает как раньше»).
-
-### High-2 — критерии приёмки не указывают способ доказательства (DoR §2.5)
-
-**Где:** `docs/specs/154-touch-hover-reset.md` §12 «Acceptance criteria»
-(строки 197–212), сверено с §13 «План тестирования» (214–252).
-
-PROCESS.md §2.5 (вход в «Готово к разработке») требует буквально: «AC1…ACn —
-пронумерованные проверяемые критерии приёмки; **у каждого указано, чем он
-доказывается**: `unit` / `backend` / `smoke` / `golden` / «ревью кода»» — и
-«если хоть один пункт не выполнен — статус не «Готово к разработке»».
-
-Все 12 пунктов §12 сформулированы как утверждения о поведении (хорошо,
-проверяемо и однозначно сформулированы — отдельная претензия к ним
-отсутствует), но ни один не помечен способом доказательства. §13 группирует
-тесты по категориям (Unit/source contract, Browser smoke, Golden,
-Performance), но не сопоставляет их с номерами AC — например, неясно из
-текста, доказывается ли AC7 («desktop mouse hover не изменён») smoke-тестом,
-golden-скриншотом, или обоими одновременно, и то же для AC9 (keyboard focus)
-и AC12 (naked hover selector — очевидно «ревью кода» по source-inventory,
-но это нигде не написано явно).
-
-**Почему High:** это не редакторская придирка, а буквальный пункт входного
-чек-листа перед `S5-ready`. Без явной привязки разработчик и код-ревьюер
-(другая модель, без контекста этой сессии — AGENTS.md «Two-agent workflow»)
-должны будут заново реконструировать, каким тестом каждый AC закрыт, что
-именно и должен исключать этот пункт DoR.
-
-**Что нужно поправить:** добавить к каждому из 12 пунктов §12 тег
-доказательства, например `[unit]`, `[smoke]`, `[golden]`, `[unit+smoke]`,
-`[ревью кода]` — материал для этого уже есть в §13, требуется только явное
-сопоставление 1:1.
-
-### High-3 — не перечислены затронутые файлы и модули (DoR §2.5)
-
-**Где:** весь документ; ближайший к теме раздел — «14. План реализации»
-(строки 254–262).
-
-Тот же пункт DoR §2.5 требует отдельно: «перечислены затронутые файлы и
-модули». В ТЗ этого списка нет — §14 ограничивается общими шагами
-(«провести inventory JS state и View/shared CSS hover selectors», «ввести
-component-local pointer modality authority»), не называя ни одного
-конкретного файла.
-
-Это не тривиальный однофайловый фикс: `grep ':hover' src/` даёт 32
-вхождения в 6 файлах — `houseplan-card.ts`, `styles.ts`, `space-card.ts`,
-`hp-dialog.ts`, `hp-device-preview.ts`, `hp-color-opacity.ts` (плюс
-`hp-help.ts`, у которого есть top-level `mouseenter`/`_notePointer`-подобная
-логика — исключён по контракту §4, но это тоже стоило бы явно назвать).
-Раз §3 ТЗ прямо говорит, что «общие компоненты редакторов получают
-исправление, если используют тот же pointer-modality gate», а этот gate
-должен быть «единым» и «передан в обязательные shadow child components»
-(§5), явно неясно без списка файлов, какие из этих 6+ компонентов входят в
-обязательный охват, а какие — только в «если не требуют отдельной сложной
-адаптации» (§3, необязательная часть).
-
-**Почему High:** без списка файлов нельзя проверить полноту заявленного
-«обязательного охвата» View (issue, раздел «Обязательный охват») — то же
-самое, что нельзя проверить AC без способа доказательства.
-
-**Что нужно поправить:** добавить раздел «Затронутые файлы» с явным списком
-(минимум все 6 файлов с `:hover`, плюс модуль(и), где будет жить pointer
-modality authority), и отметить для каждого — «обязательный охват» или
-«если дёшево, без специальной адаптации» (§3).
-
-### Medium-1 — план документации (§15) называет неверный канонический документ для hover-контракта
-
-**Где:** `docs/specs/154-touch-hover-reset.md` §15 (строки 264–276), пункт
-«`docs/CANVAS.md` — hover/pressed/semantic ownership».
-
-`docs/CANVAS.md` — канонический документ infinite canvas (координаты,
-content frame, zoom/pan, grid, drag limits, snap contract, wall geometry).
-Слово «hover» встречается там ровно один раз (строка 563) и относится к
-preview hit-резолверу architectural connection overlay в редакторе Плана
-(«the same resolver runs again on click, so hover is only a preview and
-never authoritative») — это про предпросмотр примыкания к стене при
-рисовании, а не про View-контракт room/device/opening hover, который меняет
-эта задача.
-
-Настоящий канонический источник контракта — `docs/UX-MODES.md`, раздел
-«View — display and device interaction only» (строки 63–70): «room hover
-highlight, hover tooltips (name, clean-floor area, temperature, signal)» —
-именно эта строка перечисляет ровно то поведение, которое ТЗ #154 меняет
-(добавляет pointer-modality gate и запрещает sticky/synthetic hover). ТЗ
-§15 не включает `docs/UX-MODES.md` в список документов на обновление
-вообще.
-
-**Последствие, если не исправить:** implementer, следуя §15 буквально,
-допишет в `docs/CANVAS.md` абзац не по адресу (документ и так не про
-интеракции), а `docs/UX-MODES.md` продолжит говорить просто «room hover
-highlight, hover tooltips» без указания на pointer-modality/no-sticky-hover
-контракт — расхождение документации с реальным поведением ровно там, где
-его будут искать в первую очередь (`UX-MODES.md` явно значится и в
-AGENTS.md как канонический документ подсистемы).
-
-**Что нужно поправить:** заменить `docs/CANVAS.md` на `docs/UX-MODES.md` в
-списке §15 (либо добавить `UX-MODES.md` к списку и явно решить, нужен ли
-`CANVAS.md` вообще — по факту нет, там нет ownership hover).
-
-Заведён отдельный issue: см. итог ниже.
-
-## Что проверено и корректно
-
-- **Проблема описана по реальному коду, не по догадке.** `_notePointer()`
-  (`houseplan-card.ts:5442`) действительно закрывает только `_tip`, room
-  hover действительно висит на `mouseenter`/`mouseleave`
-  (`14619–14646`) — оба факта, на которых строится вся мотивация ТЗ,
-  подтверждены чтением, не голословны.
-- **Границы transient hover (§2) чёткие и без скрытого расширения скоупа.**
-  Working/alarm/unavailable/Glow/pulse, `hp-help`, selected/checked,
-  keyboard focus прямо исключены из очистки — совпадает с исключениями,
-  которые перечислил сам владелец в теле issue («Исключения»).
-- **Synthetic-mouse policy (§6) корректно закрывает главный технический
-  риск бага** («мобильный браузер может синтезировать mouse-события») —
-  явно требует trusted `PointerEvent` с реальным `pointerType`, запрещает
-  произвольный wall-clock timeout как основной механизм. Это прямое,
-  проверяемое техническое решение, а не «наверное сработает».
-- **Не создаёт ложной зависимости от нереализованного #152.** Проверено:
-  #152 (`click-to-fit`) сам ещё в `S4-spec-review`; §9 ТЗ прямо пишет, что
-  #152 должен использовать canonical hit resolver независимо от
-  `_hoverRoom`, не читая его как заменитель выбора — корректно, не
-  предвосхищает нерешённый ТЗ #152.
-- **«Принятые предположения» (§17) — действительно технические или уже
-  решённые владельцем, не спрятанные продуктовые вопросы.** Пункт «touch и
-  pen следуют одинаковой no-hover policy» дословно совпадает с «Pen tap
-  следует touch-политике» из тела issue (владелец уже решил это), а не
-  является домыслом автора ТЗ; «media query — только второй gate»,
-  «mouse modality — только trusted PointerEvent» — реализационные решения,
-  которые PROCESS §7.1 явно отдаёт на усмотрение автора.
-- **Accessibility (§11) не оставляет открытых вопросов**: DOM focus,
-  `:focus-visible`, `aria-*`, dialog focus trap явно выведены из-под
-  touch-cleanup — совпадает с «Keyboard focus и `:focus-visible` сохраняют
-  штатное поведение» из тела issue.
-- **i18n и модель данных закрыты корректно и коротко, а не отпиской.** §15
-  прямо говорит: новых строк не ожидается, если появятся — обе локали и
-  parity test обязательны; §16 — «Config, storage и backend data не
-  меняются; миграция и data rollback не нужны» — соответствует тому, что
-  задача чисто presentation/pointer-lifecycle, backend не тронут.
-- **Откат (§16) реалистичен**: «возвращает прежние JS/CSS hover paths» —
-  для чисто клиентской, не мигрирующей данные задачи это адекватный и
-  проверяемый уровень детализации отката.
-- **Трек и трейлеры соответствуют аналитике.** Комментарий 2026-08-15
-  корректно исключил `trivial` (touch impact) и `small` (несколько
-  поверхностей: room/device/opening/controls/dialogs); полный трек и файл
-  в `docs/specs/` — правильный выбор, подтверждён `S4-spec-review` без
-  `small`.
-
-## Чего не проверял
-
-- Реализацию — её нет, это ревью ТЗ, а не кода (PROCESS.md §2.4).
-- Golden/browser smoke живьём — на этапе ТЗ не запускаются; план в §13
-  выглядит технически осмысленным (real touch context, CDP touch input,
-  `(any-hover: hover)` контекст), но существование конкретных сценариев не
-  верифицировалось запуском.
-- Производительность — утверждения §13 «Performance» (pointermove не
-  вызывает full Lit update и т.п.) не профилировались; на этапе ТЗ это не
-  требуется, оценка отложена до реализации/пре-релизного гейта.
-- Полный список всех `:hover`-селекторов в `styles.ts` построчно (нужен ли
-  каждому modality gate) — за пределами ревью ТЗ; сосчитано только число
-  файлов/вхождений, чтобы обосновать High-3.
-- Реализуемость unit-теста «compatibility MouseEvent не включает mouse
-  modality» в текущем test harness (`test/**`) — не проверялась: на этапе
-  спецификации это заявление о контракте, а не код.
-
-## Вывод
-
-Технический контракт (§5–11, §16–17) продуман, обоснован кодом и не
-содержит выданных за факт догадок — это сильная сторона документа. Но три
-independent High-находки — отсутствие обязательных продуктовых разделов
-§7.1, отсутствие способа доказательства у каждого AC и отсутствие списка
-затронутых файлов — это три отдельных, буквальных пункта DoR §2.5,
-неотвеченных полностью. Ни один из них не требует пересмотра решения, все
-три чинятся добавлением текста в это же ТЗ без изменения контракта.
-
-Возврат в «ТЗ в работе» (`S3-spec`), цикл r1/4.
-
-Medium-1 заведён отдельным issue со ссылкой на #154 (не блокирует переход
-сам по себе, но должен быть закрыт до релиза документации).

docs/specs/124-isometric-view-toggle-performance.md

@@ -0,0 +1,254 @@
+# Issue #124 — isometric view toggle выполняет Stage 1 performance budget
+
+- **Issue:** https://github.com/Matysh/houseplan-card/issues/124
+- **Статус документа:** готово к будущей реализации; issue остаётся на `S3-spec`
+- **Приоритет:** P2
+- **Тип:** bug/performance, обычный трек
+- **Пользовательское изменение:** нет; скрытый Labs UI и pixels сохраняются
+
+## 1. Симптом и доказательство
+
+В exact-SHA Full Performance для `v1.63.0-beta.1` (`3270e039…`) профиль
+`large-house-isometric-v1` измерил:
+
+- `viewToggleMs.median`: 192.8 ms;
+- pre-#89 baseline: 31.7 ms;
+- limit: 131.7 ms (`base + 20% + 100 ms`);
+- все семь candidate samples: 189.2–213.4 ms.
+
+Одно переиспользование wall union в экспериментальном `2576d9d` дало около
+10 ms и не закрыло долг. Точная доминирующая причина не доказана. Полная
+Lit/DOM смена структурных шаблонов — гипотеза, а не готовое решение.
+
+#156 не является дублем: его regression run имел зелёный `viewToggleMs` на
+другой сравнительной линии и прямо исключил #124.
+
+## 2. Цели
+
+1. Профилированием установить стоимость Flat → Iso и Iso → Flat.
+2. Уложить canonical profile в неизменённый budget.
+3. Сохранить Flat/Iso geometry, live layers, actions, fallback и viewport.
+4. Не увеличить cache/heap и не перенести стоимость в соседнюю метрику.
+5. Получить воспроизводимое exact-SHA доказательство закрытия исходного долга.
+
+## 3. Не входит в задачу
+
+- ослабление budget/noise/minimum samples;
+- публичное включение изометрии;
+- новая Stage 3 геометрия/материалы/камера;
+- изменение Flat pixels или editors/static card;
+- скрытие live layers на время toggle;
+- async loading/network request;
+- замена renderer architecture без измеренной причины;
+- переоткрытие #89 или поглощение #156.
+
+## 4. Канонический benchmark
+
+`demo/benchmark_large_house.mjs --profile=large-house-isometric-v1` остаётся
+authority. `viewToggleMs` включает полный user-observable цикл:
+
+1. `_setProjection('flat')`;
+2. `updateComplete`;
+3. `_setProjection('iso')`;
+4. `updateComplete`.
+
+Нельзя завершить metric до painted DOM либо заменить его pure geometry timing.
+Minimum — 7 samples на Linux CI с обычной environment/provenance проверкой.
+
+Для закрытия нужны два сравнения:
+
+- **debt closure:** candidate против pre-#89 SHA
+  `316ee76a2913066f8ccd86d27fdf7b17dabaff48`, который использовался как
+  историческая граница до merge #89;
+- **current regression:** тот же exact candidate против актуального `main`/stable
+  обычным workflow, чтобы оптимизация не ухудшила v1.64 соседние paths.
+
+Если automation не умеет сохранить pinned comparison artifact, допускается
+manual workflow input с exact SHA и ссылка на run в review. Один зелёный push
+candidate-vs-parent, где product code одинаков, не закрывает #124.
+
+## 5. Обязательное профилирование до изменения продукта
+
+До выбора реализации author публикует в issue/review:
+
+- отдельные Flat commit и Iso commit timings;
+- main-thread flame/trace либо эквивалентные измеренные call stacks;
+- Lit `performUpdate`/template commit долю;
+- geometry/cache hit/miss и `_isoScene()` build count;
+- DOM node add/remove count по классам слоёв;
+- layout/style/paint долю;
+- минимум три главных cost centres с абсолютным временем.
+
+Профилирование выполняется на production bundle и той же fixture. Dev build,
+один sample или ручное ощущение не являются доказательством.
+
+Diagnostic instrumentation:
+
+- живёт в benchmark/harness либо за test-only hook;
+- не создаёт production console noise;
+- не меняет timing path в финальном closure run;
+- удаляется либо остаётся как дешёвый выключенный counter с documented owner.
+
+## 6. Допустимые направления оптимизации
+
+Конкретное направление выбирается только по §5. Допустимы:
+
+- стабилизация shared DOM subtree и переключение минимального structural layer;
+- reuse уже вычисленной scene/union/index geometry;
+- разделение structural и live templates, чтобы HA layers не пересоздавались;
+- memoization чистых template inputs с bounded identity;
+- уменьшение синхронного layout/measurement после projection commit;
+- использование части `2576d9d`, если trace подтверждает её вклад.
+
+Запрещено:
+
+- держать два полноценных интерактивных дерева, если это дублирует tab order,
+  actions, ids или нарушает heap budget;
+- CSS screenshot/bitmap вместо живого плана;
+- пропуск `updateComplete`/paint в benchmark;
+- debounce, который делает UI быстрым только до позднего тяжёлого commit;
+- global cache без лимита;
+- UA-specific fast path.
+
+## 7. Render и DOM invariants
+
+- Labs off/expired: iso DOM, geometry work, storage/network path отсутствуют;
+- Flat остаётся reference и не получает Stage 2 DOM/classes/filters;
+- editors и `houseplan-space-card` всегда Flat;
+- Iso использует одну canonical scene/projection snapshot;
+- room fills/hover, Glow/spill, sun, decor/backdrop, vacuum, devices, labels и
+  opening live panels сохраняются;
+- DOM/tab order и actions совпадают по semantic targets;
+- no duplicate ids, focus targets или pointer consumers;
+- toggle сохраняет logical center и zoom по #89;
+- failure latch и explicit retry остаются работоспособными.
+
+Если shared subtree остаётся смонтированным между projections, его inertness,
+ARIA и pointer policy должны быть доказаны, а не основаны только на opacity.
+
+## 8. Cache и lifecycle
+
+- `_isoGeometryCache` cap остаётся 8;
+- `cacheGrowth.isoGeometry` после profile — 0;
+- repeated Flat ↔ Iso не добавляет новые entries при том же fingerprint;
+- HA-only state update не rebuild-ит structural geometry;
+- theme/locale/live state не меняют geometry key;
+- config geometry change инвалидирует правильную scene;
+- Labs expiry/removal немедленно делает effective Flat и не удерживает active
+  iso DOM вне bounded cache;
+- warm remount не усыновляет viewport другой projection.
+
+## 9. Соседние performance budgets
+
+Оптимизация не считается успешной, если `viewToggleMs` зелёный, но ухудшены:
+
+- model ready / first stable render;
+- space switch;
+- HA state update;
+- pan/zoom и resize preview;
+- switch cycle;
+- long-task count/max/total;
+- heap growth;
+- Flat `large-house-v1`.
+
+Все лимиты читаются из текущих versioned budget files; hardcoded threshold в
+production/test не добавляется.
+
+## 10. Touch, accessibility и actions
+
+- projection toggle остаётся hidden Labs control;
+- touch/kiosk gestures имеют прежний safety contract;
+- активный dialog/tooltip/focus не дублируется между trees;
+- tap/long press на room/device/opening вызывает тот же outcome в Flat/Iso;
+- locks/security и service target не меняются;
+- keyboard tab order не получает скрытых duplicate nodes;
+- reduced motion не относится к мгновенному projection toggle и не меняет
+  benchmark semantics.
+
+## 11. Acceptance criteria
+
+1. Profiling evidence на production fixture публикует измеренную root cause.
+2. Pinned pre-#89 exact comparison зелёный по неизменённому `viewToggleMs` budget
+   с ≥7 samples.
+3. Current-main exact comparison также зелёный.
+4. Все остальные timing/long-task/heap/cache checks профиля зелёные.
+5. Flat profile остаётся в budget.
+6. `isoGeometry` cap/growth равны 8/0, repeated toggle — cache hit.
+7. Flat/Iso golden и live/touch/action smokes зелёные без несвязанной
+   переакцептации.
+8. Labs off не создаёт iso work/DOM.
+9. HA state update не rebuild-ит geometry и не переносит cost из toggle.
+10. Viewport/fallback/warm-remount contract #89/#122 не регрессирует.
+
+## 12. План тестирования
+
+### Unit/source contract
+
+- cache key/cap/hit/invalidation;
+- effective projection/fallback;
+- shared DOM ownership и отсутствие duplicate consumers;
+- Labs-off source contract;
+- logical center conversion unchanged.
+
+### Browser smoke
+
+- repeated Flat ↔ Iso с layer/action parity;
+- room/device/opening/vacuum interactions;
+- Glow/sun/room fills remain mounted and state-stable;
+- theme/state update during/after toggle;
+- editor round-trip always Flat;
+- kiosk/touch and warm remount;
+- injected geometry exception and explicit retry.
+
+### Golden
+
+- все existing Flat и Iso baselines verify;
+- никакой baseline не принимается только ради performance fix;
+- если measured solution намеренно меняет DOM без pixels, expected diff = 0.
+
+### Performance
+
+- local 1-sample diagnostic допустим только для итерации;
+- closure evidence — два Linux exact-SHA runs по §4, ≥7 samples;
+- artifacts содержат raw samples, summaries, provenance и cache counters.
+
+## 13. План реализации
+
+1. Добавить/выполнить profiling instrumentation и опубликовать вывод.
+2. Выбрать минимальный measured optimization.
+3. Зафиксировать structural/live DOM и cache invariants тестами.
+4. Реализовать без visual/action diff.
+5. Прогнать typecheck, unit и build в цикле.
+6. Перед beta прогнать targeted smoke/golden и оба performance comparison.
+
+## 14. Документация и release-артефакты
+
+- changelog не нужен при чистой performance-починке скрытой функции
+  (`User-Visible: no`);
+- `docs/ISOMETRIC.md` обновляется measured architecture/root cause;
+- ADR меняется, только если renderer ownership действительно изменён;
+- `docs/TESTING.md`/performance README фиксируют pinned closure evidence;
+- user guide и i18n не меняются;
+- performance artifacts и review links обязательны;
+- golden обновлять запрещено без отдельного visual rationale.
+
+## 15. Риски и откат
+
+| Риск | Мера |
+| --- | --- |
+| Cost просто отложен после metric | painted completion + trace |
+| Два дерева дублируют actions | DOM/ARIA/pointer contract smoke |
+| Cache растёт | cap/growth exact assertions |
+| Flat подорожал | отдельный flat profile |
+| Решение основано на гипотезе | profiling до product diff |
+
+Откат возвращает прежний render path. Cache/storage schema не меняются. Если
+оптимизация ломает Flat/actions, Labs kill switch немедленно даёт effective Flat,
+но это mitigation, а не критерий принятия красного кода.
+
+## 16. Принятые технические предположения
+
+- историческая debt-граница — exact pre-#89 SHA `316ee76…`;
+- benchmark продолжает измерять полный Flat → Iso → Flat/Iso user cycle;
+- measured solution может не использовать `2576d9d`;
+- public activation изометрии остаётся отдельной будущей задачей.

docs/specs/154-touch-hover-reset.md

@@ -1,299 +0,0 @@
-# Issue #154 — transient hover не залипает после touch
-
-- **Issue:** https://github.com/Matysh/houseplan-card/issues/154
-- **Статус документа:** готово к будущей реализации; issue остаётся на `S3-spec`
-- **Приоритет:** P1
-- **Тип:** bug/polish, обычный трек
-- **Пользовательское изменение:** да
-
-## 1. Проблема и требуемый результат
-
-Мобильный браузер после tap может синтезировать mouse-события и сохранять CSS
-`:hover`. Одновременно room hover в View управляется `mouseenter`/`mouseleave`,
-а touch sequence не гарантирует `mouseleave`. Текущий `_notePointer()` закрывает
-`_tip`, но не очищает `_hoverRoom` и не нейтрализует CSS hover.
-
-После исправления touch/pen показывает только краткий pressed feedback на время
-жеста. После его завершения transient hover отсутствует. Настоящие mouse и
-trackpad сохраняют обычный hover, а на гибридном устройстве последующий mouse
-input восстанавливает его после touch без reload.
-
-## 2. Термины и границы состояния
-
-**Transient hover** существует только из-за текущего hover-capable pointer:
-
-- `_hoverRoom`, room fill/outline и room tooltip;
-- device marker lift/shadow/brightness;
-- opening, room label и control hover styles;
-- dialog close/control hover;
-- аналогичные чисто визуальные CSS `:hover` состояния общих View-компонентов.
-
-Не являются transient hover и не очищаются этой задачей:
-
-- `active`, `pressed` во время незавершённого pointer sequence;
-- selected/checked/current состояния редакторов;
-- working, unavailable, alarm, warning, Glow/pulse и иное HA-derived состояние;
-- keyboard focus и `:focus-visible`;
-- открытый по click/tap toggle-popover `hp-help`;
-- открытый dialog либо выполненное action.
-
-## 3. Scope
-
-Обязательный охват основного View:
-
-- room floor/fill/outline/label/tooltip;
-- device marker, opening и vacuum marker;
-- controls поверх плана и close/action controls диалога;
-- tap комнаты из будущей #152;
-- long press, pinch, multi-touch и pointer capture cancellation;
-- touch → mouse/trackpad на гибридном устройстве;
-- смена режима, visibility и lifecycle компонента.
-
-Общие компоненты редакторов получают исправление, если используют тот же
-pointer-modality gate без специальной адаптации. Полная поддержка touch-editing
-остаётся вне scope согласно `docs/TOUCH-SUPPORT.md`.
-
-## 4. Не входит в задачу
-
-- изменение semantic device/room state;
-- новый visual design hover/pressed/focus;
-- изменение действий tap, long press или click;
-- превращение `hp-help` в transient tooltip;
-- исправление touch settings из #149;
-- полная переработка gesture arbiter #152;
-- глобальный `blur()`, снятие DOM focus либо synthetic click suppression,
-  способный отменить пользовательское action.
-
-## 5. Единый pointer-modality authority
-
-Houseplan вводит один session-local источник фактической modality:
-
-```text
-unknown | mouse | touch | pen
-```
-
-Начальное значение — `unknown`; pointer-only hover при нём выключен. Переходы:
-
-- trusted `PointerEvent` с `pointerType === 'mouse'` включает `mouse`;
-- trusted `touch` включает `touch` и немедленно очищает transient hover;
-- trusted `pen` включает `pen` и следует touch policy;
-- следующий настоящий mouse/trackpad pointer event переводит touch/pen → mouse;
-- смена mode/space, `visibilitychange` в hidden и disconnect очищают transient
-  hover, не подменяя semantic state.
-
-Media queries не являются authority: браузер может ошибочно сообщать
-`(hover: hover)` после touch. Для включения CSS hover одновременно нужны:
-
-1. последняя фактическая modality `mouse`;
-2. hover/fine-pointer capability среды.
-
-Компонент применяет единый class/data-attribute gate к View tree; дочерние
-shadow components получают ту же modality явным property/attribute contract.
-Независимые локальные детекторы и глобальный mutable singleton запрещены.
-
-Modality не сохраняется в localStorage/config и не синхронизируется между
-карточками. Она не обязана быть reactive product state, если один безопасный
-DOM gate и явная очистка обновляются без лишнего full render.
-
-## 6. Synthetic mouse policy
-
-Touch-generated compatibility `MouseEvent` не может включить mouse modality.
-Authority дают только Pointer Events с фактическим `pointerType`; существующие
-`mouseenter`/`mouseleave` не меняют modality.
-
-JS room hover переводится на `pointerenter`/`pointerleave` либо общий delegated
-pointer path и устанавливается только для разрешённого mouse modality. Touch и
-pen никогда не записывают `_hoverRoom`/`_tip` через hover path.
-
-Не использовать произвольный таймаут «после touch игнорировать mouse N ms» как
-основной механизм: он ломает быстрый touch → mouse сценарий и зависит от
-браузера. Если конкретный браузер отправляет compatibility event как
-`PointerEvent(pointerType='mouse')`, допускается только детерминированная
-проверка provenance/capabilities этого же input sequence с unit/browser
-доказательством; wall-clock suppression без идентичности sequence запрещён.
-
-## 7. Очистка transient hover
-
-Единый idempotent helper очищает только transient hover state. Он вызывается:
-
-- в начале каждого touch/pen `pointerdown`;
-- на соответствующих `pointerup` и `pointercancel`;
-- при `lostpointercapture`;
-- после terminal click/action path до следующего painted frame;
-- при начале multi-touch/pinch и после его завершения/cancel;
-- при mode/space change;
-- при `document.visibilityState === 'hidden'`;
-- при disconnect/remount boundary.
-
-Повторный вызов — no-op и не должен создавать render loop. Pointer capture
-снимается только владельцем gesture по текущему contract; hover cleanup не
-отменяет service call, dialog open или room fit.
-
-После touch terminal event pressed feedback очищается обычным gesture owner.
-Transient hover не остаётся дольше одного animation frame и не используется для
-имитации pressed.
-
-## 8. CSS contract
-
-Все пользовательски заметные View `:hover` selectors получают общий modality
-gate. Как минимум это:
-
-- room overlay/yard/styled fill;
-- device normal/alarm lift, shadow и brightness;
-- opening outline;
-- room-label controls;
-- stage controls/options;
-- dialog close/action controls и общие card controls, видимые в View.
-
-Один selector не должен случайно смешивать hover с semantic state. Если текущая
-rule объединяет `:hover` и `:focus-visible`, её разделяют: mouse hover получает
-modality gate, focus-visible остаётся без него. `:active`/explicit pressed styles
-также остаются независимы.
-
-Selectors редакторских handles можно оставить вне обязательного охвата, если
-они не используются в View/shared component; решение фиксируется inventory в
-review. Naked View `:hover` после изменения считается source-contract ошибкой.
-
-## 9. JS hover и tooltip contract
-
-- `_hoverRoom` и `_tip` не устанавливаются touch/pen событиями.
-- `pointerleave` реальной мыши очищает принадлежащее target состояние.
-- touch `pointerdown` очищает старый mouse hover до выполнения tap action.
-- открытие/закрытие dialog не восстанавливает старый hover snapshot.
-- tooltip, открытый keyboard focus либо explicit click contract, не должен
-  ошибочно классифицироваться как hover; owner хранится явно.
-- следующий mouse enter/move заново вычисляет current hit и показывает hover,
-  а не восстанавливает устаревший room/device id.
-
-Room fit #152 использует canonical hit resolver непосредственно из gesture
-sequence и не зависит от `_hoverRoom`; очистка hover не должна терять room tap.
-
-## 10. Touch, gestures и lifecycle
-
-- Второй pointer немедленно исключает single-tap activation по действующему
-  gesture contract и очищает hover.
-- Pinch/long press могут выполнить своё существующее действие, но после terminal
-  event не оставляют hover.
-- `pointercancel`/lost capture всегда безопасны, даже если target удалён renderом.
-- Tap → dialog → close не возвращает marker lift/shadow из пред-dialog frame.
-- Pen tap следует touch policy; hover stylus не входит в обязательный контракт.
-- Kiosk, light/dark theme, Flat/Isometric используют одинаковую modality policy.
-
-Listener `visibilitychange` регистрируется/удаляется симметрично lifecycle и не
-создаёт утечку при повторных mount/unmount.
-
-## 11. Accessibility
-
-- DOM focus не снимается touch cleanup helper.
-- `:focus-visible` и keyboard tooltip/action продолжают работать независимо от
-  последней pointer modality.
-- Touch cleanup не меняет `aria-expanded`, `aria-pressed`, selection либо dialog
-  focus trap.
-- Mouse hover не является единственным способом получить обязательную
-  информацию или действие.
-- Reduced motion не влияет на state machine; pressed feedback #22 остаётся
-  кратким и не превращается в hover.
-
-## 12. Acceptance criteria
-
-1. После touch tap на каждом обязательном View target transient hover исчезает
-   не позднее следующего frame после завершения pressed feedback.
-2. `_hoverRoom`/hover-owned `_tip` равны null после touch terminal event.
-3. Device lift/shadow и CSS hover controls отсутствуют после tap/dialog close.
-4. Working/alarm/unavailable/Glow/pulse/selected state не изменяется.
-5. Pinch, long press, multi-touch, cancel и lost capture не оставляют hover.
-6. Браузер с touch и ложным `(hover: hover)` не показывает sticky hover.
-7. Настоящий desktop mouse hover визуально и функционально не изменён.
-8. На hybrid device touch → mouse восстанавливает hover первым настоящим mouse
-   pointer event без reload и без произвольной задержки.
-9. Keyboard focus и `:focus-visible` сохраняются.
-10. Cleanup не отменяет click action, dialog, #152 room fit или help popover.
-11. Mode/space/visibility/disconnect очищают transient hover без listener leak.
-12. В View/shared CSS не остаётся naked hover selector из inventory.
-
-## 13. План тестирования
-
-### Unit/source contract
-
-- transitions `unknown → mouse/touch/pen → mouse`;
-- compatibility MouseEvent не включает mouse modality;
-- touch/pen down/up/cancel и lost capture вызывают idempotent cleanup;
-- mode/space/visibility/disconnect lifecycle;
-- cleanup очищает только hover-owned state;
-- room hover gate и #152 hit независимы;
-- CSS inventory: View hover selectors требуют modality gate, focus-visible — нет.
-
-### Browser smoke
-
-- реальный touch context/CDP touch input: room, device, opening, label, control;
-- tap → dialog → close и tap при активном semantic device state;
-- browser context с touch и `(any-hover: hover)`;
-- two-finger pinch, long press, pointercancel и lost capture;
-- touch room click-to-fit #152 без sticky room highlight;
-- touch → hardware/simulated mouse pointer: hover снова появляется;
-- desktop mouse enter/leave и keyboard Tab/Enter regression;
-- Flat/Isometric, kiosk, light/dark и visibility round-trip.
-
-Тест проверяет computed styles и JS state после painted frame, а не только
-отсутствие class. `dispatchEvent(new MouseEvent(...))` не заменяет настоящий
-touch browser scenario.
-
-### Golden
-
-- touch post-tap screenshot без hover, но с прежним semantic state;
-- desktop mouse-hover и keyboard-focus screenshots;
-- visual diff не переакцептует unrelated colors/shadows.
-
-### Performance
-
-- pointermove не вызывает full Lit update на каждый пиксель;
-- modality gate не добавляет unbounded listeners/observers;
-- canonical pan/pinch smoke сохраняет frame responsiveness;
-- performance profile перед beta подтверждает отсутствие новых long tasks.
-
-## 14. План реализации
-
-1. Провести inventory JS state и View/shared CSS hover selectors.
-2. Ввести component-local pointer modality authority и lifecycle cleanup.
-3. Перевести room hover на pointer events с mouse gate.
-4. Ввести общий CSS modality gate, разделив hover/focus/semantic rules.
-5. Передать modality в обязательные shadow child components.
-6. Добавить unit/source-contract и real-touch/hybrid browser tests.
-7. Прогнать typecheck, unit и build; перед beta — smoke, golden, performance.
-
-## 15. Документация и release-артефакты
-
-Поскольку bug виден пользователю, implementation commit обязан иметь
-`User-Visible: yes` и в том же коммите обновить:
-
-- `docs/CHANGELOG.md` и `docs/CHANGELOG.ru.md`;
-- `docs/TOUCH-SUPPORT.md` — pointer modality и отсутствие sticky hover;
-- `docs/CANVAS.md` — hover/pressed/semantic ownership;
-- `docs/TESTING.md` — real-touch и hybrid smoke contract.
-
-Нужны reviewed touch post-tap, desktop-hover и keyboard-focus golden artifacts,
-а также browser smoke report. Новых пользовательских строк не ожидается; если
-появятся, обе локали и parity test обязательны.
-
-## 16. Риски и откат
-
-| Риск | Мера |
-| --- | --- |
-| Touch cleanup отменяет action | state-only helper, gesture smoke |
-| Mouse hover пропадает на hybrid | event-derived transition back to mouse |
-| Focus styling попадает под gate | отдельные selectors/source contract |
-| Semantic state очищается как hover | явный inventory и state ownership tests |
-| Pointermove вызывает rerender storm | DOM gate без full render per move |
-| Lifecycle listener течёт | symmetric connect/disconnect test |
-
-Откат возвращает прежние JS/CSS hover paths. Config, storage и backend data не
-меняются; миграция и data rollback не нужны.
-
-## 17. Принятые предположения
-
-- `touch` и `pen` следуют одинаковой no-hover policy;
-- initial `unknown` не включает pointer-only hover до фактической мыши;
-- mouse modality определяется trusted PointerEvent, не compatibility MouseEvent;
-- media query используется только вторым gate, а не источником modality;
-- #152 room activation не должна читать `_hoverRoom` как selected hit;
-- `hp-help`, focus-visible и semantic states не относятся к transient hover.

docs/specs/README.md

@@ -48,7 +48,6 @@ GitHub Issues и GitHub Projects (v2) остаются единственным
 | [#131](https://github.com/Matysh/houseplan-card/issues/131) Полный первый кадр View у read-only-пользователя | [131-readonly-cold-start.md](131-readonly-cold-start.md) |
 | [#138](https://github.com/Matysh/houseplan-card/issues/138) Автозамыкание комнаты по существующей стене | [138-adjacent-room-autoclose.md](138-adjacent-room-autoclose.md) |
 | [#146](https://github.com/Matysh/houseplan-card/issues/146) Четырёхфазный фон «Следует за Солнцем» | [146-four-phase-sun-background.md](146-four-phase-sun-background.md) |
-| [#154](https://github.com/Matysh/houseplan-card/issues/154) Touch: hover-состояние залипает после tap | [154-touch-hover-reset.md](154-touch-hover-reset.md) |
 | [#156](https://github.com/Matysh/houseplan-card/issues/156) Регрессии Full Performance перед v1.64.0 stable | [156-full-performance-regressions.md](156-full-performance-regressions.md) |
 
 ## P2
@@ -85,6 +84,7 @@ GitHub Issues и GitHub Projects (v2) остаются единственным
 | [#107](https://github.com/Matysh/houseplan-card/issues/107) Переключение виртуального источника света «Всегда» | [107-virtual-light-toggle.md](107-virtual-light-toggle.md) |
 | [#122](https://github.com/Matysh/houseplan-card/issues/122) Изометрический режим Stage 2: скрытый режим и визуальная полировка | [122-isometric-stage2.md](122-isometric-stage2.md) |
 | [#123](https://github.com/Matysh/houseplan-card/issues/123) Split из вершины не меняет наружную геометрию стен | [123-corner-split-wall.md](123-corner-split-wall.md) |
+| [#124](https://github.com/Matysh/houseplan-card/issues/124) Performance переключения Flat/Iso | [124-isometric-view-toggle-performance.md](124-isometric-view-toggle-performance.md) |
 | [#137](https://github.com/Matysh/houseplan-card/issues/137) Узлы и линии привязки в редакторе Плана | [137-plan-snap-overlay.md](137-plan-snap-overlay.md) |
 | [#141](https://github.com/Matysh/houseplan-card/issues/141) Бесшовные стыки перегородок и открытых контуров | [141-wall-junctions.md](141-wall-junctions.md) |