docs: review document for #244

Issue: #244
User-Visible: no

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

@@ -0,0 +1,145 @@
+# 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 выполнен).