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

# 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 выполнен).