houseplan-card/docs/reviews/SPEC-REVIEW-264-r2.md

SPEC-REVIEW-264-r2 — контроллер Resize и commit-инвариант кладки

• Issue: https://github.com/Matysh/houseplan-card/issues/264
• Этап: ТЗ (S4-spec-review), заход r2, блокирующих циклов израсходовано 1 из 4 (лимит полного трека, зелёный вердикт цикла не тратит — §227)
• Ревьюер: независимая сессия, без контекста автора правки
• Материал: docs/specs/264-resize-controller.md на SHA 536b750d (HEAD); правка вносится коммитом 536b750d «docs: address resize controller spec review» поверх r1
• Вердикт: зелёный · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 0

Скоуп проверки — по дельте (PROCESS.md §2.10)

Раунд не первый, поэтому разбор ограничен дельтой и тем, до чего она дотягивается, а не задачей целиком.

1. Вердикт и SHA предыдущего раунда. Найден в docs/reviews/SPEC-REVIEW-264-r1.md (коммит c46c714c): «Вердикт: жёлтый · заход r1 · блокирующих циклов 1/4 · High: 0 · Medium: 2 → в задаче». В отличие от типового риска этого пункта, SHA материала r1 назван прямо в самом документе — «на SHA 6e1aea3a» — так что находки «SHA не назван» в этом раунде нет.
2. Дельта. git diff 6e1aea3a..536b750d -- docs/specs/264-resize-controller.md — 25 добавленных / 12 удалённых строк в одном файле, всё внутри docs/specs/264-resize-controller.md (§2 п.7, §4 п.1/5, §6 таблица переходов, §9, §10, §12 edge cases, §15 список файлов, §19 риски). Продуктовый код не менялся (diff origin/dev...HEAD содержит только этот один файл спецификации — этап ТЗ, не код-ревью).
3. Локальность дельты (проверка условия «разбор остаётся полным»). Рёбейза не было: git merge-base HEAD origin/dev = 78850a87 = текущий tip origin/dev, ветка не отставала. Контракт поведения не меняется — правка как раз восстанавливает точное соответствие описанного и фактического поведения. Новая подсистема не затронута — оба Medium из r1 лежали внутри уже разбираемого в r1 состояния Resize/Escape и списка тестовых файлов. Объём дельты (37 строк) многократно меньше исходного ТЗ (442 строки). Все четыре условия §2.10 для полного разбора отсутствуют — разбор по дельте оправдан.
4. Дополнительно прочитан фрагмент docs/RESIZE.md (канон Resize) на упоминание Escape/latent selection — единственное совпадение (строка 218) касается Escape во время активного drag, идло-ветки с _rszSel канон не описывает; значит нюанс действительно техническая территория автора, а не пропущенный продуктовый контракт.

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

Находка r1	Чем закрыта	Где это видно
M1 (Medium, в скоупе) — §2 п.7 и §19 утверждали, что «Escape в idle Resize сразу возвращает Draw», хотя код (houseplan-card.ts:2701-2710) делает это только вторым Escape при выбранной кликом комнате (_rszSel)	§2 п.7 переписан: _rszSel не удаляется, а переезжает в controller как selectedRoomId; первый Escape очищает selection и остаётся в Resize, второй — выходит в Draw. §4 п.1/5 добавляют состояние selectedRoomId и переходы select/clearSelection. §6 (таблица переходов) получает три новые строки: idle/selectRoom, idle/escape (selection есть → очистить, остаться в Resize), idle/escape (selection нет → exit-tool, root включает Draw) — это дословно воспроизводит найденный в коде код-путь. §9 фиксирует, что WarmViewport.rszSel продолжает нести это session-state значение через controller API. §12 добавляет edge case №17 «room-area click в idle Resize + Escape + Escape сохраняет … последовательность». §19 риск переформулирован с «it has no render consumer and idle Escape ends at Draw» (ложное) на «Controller сохраняет latent selection, warm getter/restore и двухшаговый Escape; dedicated unit/browser assertion»	docs/specs/264-resize-controller.md §2 п.7 (строки 71-77), §4 п.1/5 (104-112), §6 (194-196), §9 (278-280), §12 п.17 (332-333), §19 (453). Доказательство в AC не потеряно: AC2 «Controller реализует таблицу §6: … дают ровно один детерминированный outcome» — таблица §6 теперь включает новые строки, значит их обязан покрыть unit-тест того же AC; §17 «План тестирования» отдельно требует «for each row of the automat §6 and edge cases §12»
M2 (Medium, в скоупе) — §15 называл среди существующих тестов несуществующий demo/smoke_safe_resize.mjs	§15 заменяет несуществующее имя на demo/smoke_room_resize.mjs и добавляет demo/smoke_resize_pointer_real_plan.mjs рядом с уже верными demo/smoke_resize_wall_thickness.mjs/demo/smoke_resize_inner_dimensions.mjs — ровно рекомендация r1	docs/specs/264-resize-controller.md §15 (строки 374-378). Существование всех четырёх файлов перепроверено заново командой ls в этом раунде: demo/smoke_room_resize.mjs, demo/smoke_resize_pointer_real_plan.mjs, demo/smoke_resize_wall_thickness.mjs, demo/smoke_resize_inner_dimensions.mjs — все существуют

Обе находки r1 были Medium в скоупе задачи, без High — по §2.4/§4 PROCESS.md это корректно закрывается в том же issue повторным циклом ревью ТЗ, что и происходит.

Проверка дельты по существу (не за слово автора)

• Внутренняя согласованность. grep -n "_rszSel\|selectedRoomId\|rszSel" по всему файлу после правки показывает 9 упоминаний, и все они говорят одно и то же: поле не удаляется, а переезжает в controller под именем selectedRoomId, а WarmViewport.rszSel остаётся его module/session-хранилищем. Нет ни одного оставшегося места, которое всё ещё утверждало бы «поле удаляется как мёртвое» или «Escape всегда сразу Draw» — прежняя формулировка полностью заменена, а не задублирована.
• §1 («жесты не меняются») — единственное место, которое могло бы конфликтовать с исправленным §2 п.7, если бы правка не была полной. Прочитан отдельно: формулировка не изменилась и теперь соответствует факту, потому что фикс сохраняет наблюдаемую двухшаговую Escape-последовательность «как есть», а не убирает её.
• AC1 (§16) утверждает «в root нет mutable … _rszSel; состояние и cache принадлежат одному ResizeController» — это не противоречит фиксу: AC1 про root, а поле по фиксу уезжает именно из root в controller, само утверждение AC1 не меняло смысла и не требовало правки.
• Список файлов §15 (M2) сверен исполнением ls в этом раунде (не унаследовано с доверием к r1, так как это прямой предмет правки): все четыре смока на диске.
• Свежесть risk-таблицы §19: строка про _rszSel переформулирована так, что явно требует «dedicated unit/browser assertion» — то есть риск не просто закрыт текстом, а оставляет след для код-ревью (какой тест обязан существовать).

Открытых продуктовых вопросов правка не создаёт и не решает — обе находки были техническими (автор решает сам, §7.1 PROCESS.md), в соответствии с вердиктом r1.

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

Без повторной проверки в этом раунде принято из docs/reviews/SPEC-REVIEW-264-r1.md (материал на SHA 6e1aea3a), поскольку дельта их не задевает:

• структура ТЗ покрывает все обязательные разделы §7.1 PROCESS.md (сценарий, персона, что человек увидит, проблема, скоуп/не-скоуп, контракт поведения, UX/touch, данные/миграция, i18n, AC с доказательством, план автотестов, риски, откат, release-артефакты);
• продуктовый вопрос из тела issue закрыт ссылкой на выпущенный #277 (fail-closed, ноль записи при нарушении инварианта);
• фактические ссылки на существующий код (_rsz*-поля, _rszApplyPreview, checkWallRecordsPreserved в scripts/model-invariants.mjs:301, паттерн test-build/tsconfig.test.json в package.json, геометрические функции resize.ts/wall-thickness.ts/open-spans.ts, docs/TESTING.md / docs/ARCHITECTURE.md / docs/STATUS.md, WarmViewport.rszSel как module-state) — верны, кроме уже закрытого M2;
• performance-бюджеты §13 совпадают с канонизированными в docs/RESIZE.md;
• класс изменения A+B+C и User-Visible: no — корректны для содержания после фикса M1 (документ больше не противоречит себе по этому пункту);
• соответствие docs/SCOPE.md (J6), честная низкая продуктовая ценность (2/10) при высокой инженерной (9/10), решение владельца по порядку относительно #34 (взято в работу 2026-08-27);
• гейты typecheck/test/build/check-docs/invariants не запускались и в этом раунде — на этапе ТЗ нет продуктового кода, diff затрагивает только markdown; они станут обязательны на код-ревью (S7-code-review).

Чего не проверял в этом раунде

• Генерики/типизацию ResizeControllerOutcome<...> — не предмет дельты, §5 сама называет это уточняемым при реализации.
• Полную построчную сверку всех 19 пунктов матрицы edge cases (§12) с кодом — вне дельты сверялись выборочно в r1 (пп. 5, 6, 12, 14); новый п.17 сверен по коду отдельно в этом раунде (см. таблицу закрытия r1).
• Browser/unit-тесты — их ещё нет, поведение не реализовано; это предмет код-ревью, не ТЗ.
• Полный повторный обход docs/SCOPE.md, AGENTS.md, PROCESS.md, тела issue #264 и всех его комментариев — они не изменились со времени r1 и не затронуты дельтой; их разбор унаследован из r1 без повторного чтения по существу (кроме точечной сверки docs/RESIZE.md на Escape/_rszSel, сделанной в этом раунде).

Итог

Оба Medium из r1 закрыты в коде документа, а не только заявлением автора: проверено построчным сравнением дельты с найденным в r1 кодом (_rszSel/Escape) и исполнением ls для списка смоков. Новых находок дельта не порождает. High-находок нет и не было. Вердикт зелёный, документ переводит issue в S5-ready.