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

SPEC-REVIEW-244-r2

• Issue: #244 — «Маркеры остаются привязанными к удалённому id пространства и пропадают с плана; Optimize такую ссылку не лечит»
• Этап: ТЗ на ревью (PROCESS.md §2.4)
• Заход: r2 · блокирующих циклов израсходовано 1 из 4
• ТЗ: docs/specs/244-orphan-space-references.md (453 строки), коммит a18dd19ce4fb3ed54fc810e00b92e145a8f72922
• Ветка: issue/244-orphan-space-references, HEAD на момент ревью = a18dd19
• r1: жёлтый, docs/reviews/SPEC-REVIEW-244-r1.md, ТЗ рецензировалось на 9c3c7e1b378b9bef9bcb02b9a8c4ef725c99a041

Скоуп ревью

Разбор по дельте, не заново. Дельта локальна и мала: docs-only правка одного файла ТЗ, закрывающая единственную находку r1 (M1 — не назван touch/kiosk пункт DoR §2.5). Это не ребейз, не смена контракта поведения, не новая подсистема, объём (10 добавленных строк, 4 удалённых) несопоставим с исходной задачей — полный повторный разбор не требуется.

Дельта установлена как 9c3c7e1..a18dd19 — то есть SHA r1-обзора, а не SHA коммита, добавившего сам документ ревью (6ea2b04, «docs: review document for #244», который меняет только docs/reviews/** и не относится к предмету ревизии). Уточнение по процессу: комментарий-вердикт r1 в issue сам SHA не называет (Вердикт: жёлтый · заход r1 ... без ссылки на коммит) — SHA пришлось восстановить из шапки полного документа SPEC-REVIEW-244-r1.md (docs/specs/244-orphan-space-references.md, коммит 9c3c7e1b3...). Это не блокирует текущий раунд (документ есть, восстановление однозначно), но стоит включать SHA прямо в текст комментария-вердикта на будущее, чтобы не зависеть от того, попадёт ли полный файл в репозиторий раньше, чем на него понадобится сослаться.

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

Находка	Чем закрыта	Где это видно
M1 (Medium, DoR §2.5): ТЗ не называет влияние на touch/kiosk	Добавлен docs/TOUCH-SUPPORT.md в список канонических документов; в §13 добавлен абзац о touch/kiosk-паритете View/Static-рендера и о том, что Optimize/редактор пространства/редактор карточки остаются desktop-first best effort; AC1 расширен требованием доказательства на desktop/touch/static viewport	docs/specs/244-orphan-space-references.md:9-12 (канонические документы), :329-334 (§13, новый абзац), :340 (AC1, доказательство production-bundle smoke с desktop/touch/static viewport)

Формулировка проверена по существу, а не на слово автора: docs/TOUCH-SUPPORT.md делит поверхности на «touch-first View/kiosk» и «desktop-first best-effort editors» (таблица в начале документа). Утверждение ТЗ «восстановленный маркер использует тот же поддерживаемый View/Static render и тот же tap-контракт» соответствует контракту — Optimize сам по себе не меняет ни рендер, ни tap, он лишь чинит marker.space/layout, после чего маркер проходит тот же путь отрисовки, что и любой другой видимый маркер. Утверждение «Optimize, редактор пространства и редактор карточки остаются desktop-first best effort» соответствует таблице docs/TOUCH-SUPPORT.md (Plan/Device/Background editor — «Best effort»); в ТЗ не появляется новый интерактивный путь на touch, только inline-текст (delete blocker, default_floor ошибка), поэтому классификация верна.

Один нюанс, не поднимающий находку до Medium: раздел «Documentation rule» docs/TOUCH-SUPPORT.md требует, чтобы новые спецификации editor-функций называли один из трёх буквальных ярлыков — Touch editor: supported / best effort / intentionally degraded / not exposed. Добавленный абзац §13 передаёт это по смыслу («desktop-first best effort на touch»), но не использует ни один ярлык дословно. PROCESS.md §2.5 требует лишь «влияние на touch по docs/TOUCH-SUPPORT.md названо» — не конкретную форму слов, и смысл однозначен и проверяем. Low, снимается без правки: буквы правила TOUCH-SUPPORT.md рассчитаны на code review реализации, где ярлык — это машинно грепаемый чек-лист; на этапе ТЗ содержательное описание важнее точной формы, а оно есть.

Как проверялось (дельта)

1. git diff 9c3c7e1..a18dd19 -- docs/specs/244-orphan-space-references.md — единственный файл, 10 добавлений / 4 удаления: список канонических документов, абзац §13, строка AC1.
2. Прочитан целиком docs/TOUCH-SUPPORT.md — сверена формулировка нового абзаца §13 с политикой (таблица поверхностей, «What "fully supported View" means», «What "best-effort editors" means», «Documentation rule»).
3. Перечитан AC1 целиком в новой редакции — критерий остаётся однозначным, способ доказательства (production-bundle smoke с desktop/touch/static viewport) реализуем: в demo/ уже есть смоки, управляющие viewport/touch эмуляцией (smoke_touch_tips.mjs, smoke_isometric_live_touch.mjs и другие), то есть это не выдуманная методика, а расширение существующей.
4. Перепроверено, что правка не задевает диагноз §3, решения владельца §4, контракты §8–§11, инварианты §7, AC2–AC14, риски §16 и release-артефакты §17 — git diff подтверждает, что вне §0(canonical docs)/§13/AC1 файл не менялся ни строкой.
5. git diff --check 9c3c7e1..a18dd19 -- docs/specs/244-orphan-space-references.md — green (нет висячих пробелов/конфликтов).
6. node scripts/check-docs.mjs — green (диапазон не трогает src/**, гейт не обязателен, прогнан для очистки совести — 7 файлов, 10 внешних ссылок).
7. Класс изменения — C (docs/specs/**); typecheck/test/build/смоки к ревью ТЗ не относятся и не запускались, как и в r1.

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

Без повторной проверки приняты выводы docs/reviews/SPEC-REVIEW-244-r1.md (ТЗ на SHA 9c3c7e1b378b9bef9bcb02b9a8c4ef725c99a041), поскольку дельта r2 их не затрагивает:

• диагноз §3 (все шесть пунктов сверены построчно с кодом: resolveExplicitMarkerPlacement, virtual-маркер, View/kiosk фильтр рендера, _deleteSpace(), build_space_merge(), resolveInitialSpace());
• продуктовые решения владельца Q1/Q2/Q3, отражённые в §4/§10/§11 дословно;
• приоритет правил §8.2 (signature → effective Area → detach) и согласованность с resolveExplicitMarkerPlacement, включая manualRoomWithoutArea и порядок virtual-маркера;
• термины и инварианты §7 (1–5);
• контракт §8.3 (позиции и вложенные ссылки), §9 (импорт одного пространства), §10 (безопасное удаление), §11 (default_floor в редакторе карточки);
• §12 compatibility/миграция;
• §18 «Принятые предположения» — все шесть пунктов технические, не подменяют продуктовое решение;
• AC2–AC14 — однозначны, доказательства названы, не изменены дельтой r2;
• §16 риски и §17 release-артефакты;
• продуктовая рамка: задача закрывает J6 «Keep the plan true as the home evolves» из docs/SCOPE.md, скоуп не расширен, «Не входит» (§6) не изменился.

Находки

Новых находок нет. Единственная находка r1 (M1) закрыта по существу (см. «Закрытие раунда r1»); отмеченный нюанс формы ярлыка — Low, снимается без правки автору (обоснование выше).

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

• M1 закрыта содержательно, а не формальной отпиской: связь между сценарием (восстановленный маркер) и touch-контрактом (docs/TOUCH-SUPPORT.md) прослежена, а не постулирована.
• AC1 после правки остаётся однозначным критерием с реализуемым способом доказательства.
• Правка не затронула ни один из AC2–AC14, диагноз, контракты или решения владельца — унаследованные выводы r1 остаются в силе.
• git diff --check и check-docs.mjs green на текущем HEAD.

Чего не проверял

• Не проверялась реализация — стадия по-прежнему чисто ТЗ.
• Не прогонялись typecheck/test/build/смоки — класс изменения C (docs-only), гейты код-ревью к этому этапу не относятся, как и в r1.
• Не проводился повторный полный разбор диагноза §3, продуктовых решений, инвариантов §7, контрактов §8–§12, AC2–AC14, рисков §16 и release- артефактов §17 — дельта их не касается, выводы унаследованы из r1 (раздел выше) без повторного чтения кода.

Вердикт

M1 закрыта по существу проверяемой формулировкой, привязанной к docs/TOUCH-SUPPORT.md, а не общей фразой. Новых находок дельта не принесла; единственный отмеченный нюанс (буквальный ярлык из «Documentation rule») — Low и не требует правки на этапе ТЗ. High нет, Medium в скоупе нет.

Зелёный. ТЗ готово к передаче в реализацию (DoR §2.5 выполнен).