diff --git a/docs/reviews/SPEC-REVIEW-244-r2.md b/docs/reviews/SPEC-REVIEW-244-r2.md new file mode 100644 index 00000000..2b5423e9 --- /dev/null +++ b/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 выполнен).