# SPEC-REVIEW-244-r2 - Issue: [#244](https://github.com/Matysh/houseplan-card/issues/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 выполнен).