# SPEC-REVIEW-293-r2

- **Issue:** https://github.com/Matysh/houseplan-card/issues/293
- **Этап:** spec (PROCESS.md §2.4)
- **Заход:** r2 · блокирующих циклов израсходовано 1 из 4 (r1 — жёлтый, потратил
  1 цикл; зелёный вердикт цикла не образует, §227)
- **Ветка/SHA:** `issue/293-resize-pointer-noop` @ `9e9fd0298587ef0d4a1f7a32c6bcc2c61e603729`
- **Предыдущий раунд:** SPEC-REVIEW-293-r1, вердикт жёлтый, получен на SHA
  `c514b534` (SHA был явно назван в тексте вердикта r1 и в комментарии автора —
  не находка на этот раз)
- **Дельта r1→r2:** `git diff c514b534..HEAD` — три файла:
  - `docs/specs/293-resize-pointer-noop.md` (+25/−3: новые разделы 9 и 10,
    сдвиг нумерации 9→11, 10→12, 11→13)
  - `docs/specs/README.md` (+1: строка индекса)
  - `docs/reviews/SPEC-REVIEW-293-r1.md` (+165: коммит документа r1 в дерево,
    не предмет этого раунда)
  - Продуктового кода в дельте нет (`git diff --stat c514b534..HEAD -- src/
    custom_components/` — пусто), новая подсистема не затронута, контракт
    поведения не менялся. Дельта чисто аддитивная и локальная — полный разбор
    по §2.10 не требуется.

## Скоуп ревью

Предмет раунда — только дельта: закрытие M1 и L1 из r1. AC1–AC10, контракт
раздела 1–8, `docs/RESIZE.md`/`docs/TOUCH-SUPPORT.md`/`docs/USER-GUIDE.ru.md`
согласованность, соответствие `docs/SCOPE.md` — уже разобраны в r1 полностью,
дельта их не касается (ни один AC, ни один пункт контракта не переписан,
только приписаны разделы «Риски» и «Откат» плюс строка индекса). Эти пункты
наследуются без повторной проверки — см. раздел ниже.

## Как проверялось

1. `gh issue view 293 --json ... --comments` — подтверждён вердикт r1 (жёлтый,
   заход r1, 0/4 при входе) и его SHA `c514b534`, названный автором явно в
   тексте комментария-вердикта.
2. `git diff c514b534..HEAD --stat` и полный текстовый diff — три файла,
   перечислены выше; `git log --oneline c514b534..HEAD` — два коммита
   (`9e9fd029` добавляет разделы, `b0696880` коммитит документ r1), оба несут
   `Issue: #293` / `User-Visible: no` — корректно для чисто документационной
   правки.
3. Прочитан файл `docs/specs/293-resize-pointer-noop.md` целиком (231 строка) —
   не только добавленный фрагмент, чтобы проверить согласованность новых
   разделов с остальным текстом и отсутствие сломанных перекрёстных ссылок
   после сдвига номеров разделов. Перекрёстных ссылок по номеру раздела
   (`## 9`, «раздел 9» и т.п.) в файле не оказалось — все ссылки на AC даны по
   имени (`AC1`, `AC7`…), поэтому renumbering 9→11/10→12/11→13 безопасен.
4. Проверено предметное содержание новых разделов против текста находки M1
   r1 — см. таблицу закрытия ниже.
5. `grep -n "## P1" -A3 docs/specs/README.md` — новая строка `#293` попала в
   таблицу `## P1`, что соответствует фактическому приоритету issue (метка
   `P1`), не в `P2`/`P3`.
6. Гейты `typecheck`/`test`/`build` не запускались — продуктовый код не
   менялся ни в r1, ни в этой дельте (см. п.2); эти гейты относятся к
   код-ревью (§2.7), не к ревью ТЗ. Смоки/golden/invariants не применимы по
   той же причине.

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

| Находка r1 | Чем закрыта | Где это видно |
|---|---|---|
| **M1** (Medium, в скоупе) — отсутствуют обязательные разделы §7.1 «риски» и «откат» | Добавлены раздел `## 9. Риски и меры` (3 пункта, каждый привязан к конкретным AC — AC1/AC6/AC8 для риска неопределённой root cause, AC2/AC5/AC9 для риска touch safety floor, AC7 для риска ослабления safe Resize) и раздел `## 10. Откат` (revert implementation-коммита, схема/миграция/данные не трогаются) | `docs/specs/293-resize-pointer-noop.md:188-205`, коммит `9e9fd029` |
| **L1** (Low, на решение автора) — спек не индексирован в `docs/specs/README.md` | Строка `#293` добавлена в таблицу `## P1` | `docs/specs/README.md` diff в `9e9fd029`, видно в `## P1` рядом с #277/#280/#281 |

Обе находки закрыты правкой текста, а не заявлением — проверено чтением диффа,
не пересказом автора.

Содержательная проверка новых разделов (не только факт присутствия):

- Риск 1 корректно называет то, что уже было открытым вопросом в разделе 1
  ТЗ («реализация обязана сначала зафиксировать точную причину… а затем
  исправить»), и не вводит новый факт под видом решения — риск сформулирован
  как риск, а не как скрытая догадка о причине.
- Риск 2 и риск 3 указывают на реальные AC (AC2/AC5/AC9 и AC7 существуют в
  разделе 7 в указанном виде — проверено построчно), формулировки не
  противоречат разделу 8 (Touch safety floor) и разделу 3 (Pointer contract).
- Раздел «Откат» согласован с шапкой документа («Модель данных: schema и
  model version не меняются») и с разделом 12 «Release» — противоречий нет.
- Оба новых раздела не содержат догадки, выданной за факт: формулировки
  риска — гипотезы о рисках, а не утверждения о поведении кода.

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

Без повторной проверки принято из **SPEC-REVIEW-293-r1** (документ в дереве —
`docs/reviews/SPEC-REVIEW-293-r1.md`, вердикт получен на SHA `c514b534`):

- соответствие `docs/SCOPE.md` (дефект в закрытом J6, регрессия безусловно в
  скоупе);
- фактическая точность раздела 1 (топология общей стены в
  `test/fixtures/real-plan-second-floor.json`, поведение
  `_rszDrag/_rszMove/_rszApplyPreview` в `src/houseplan-card.ts`) —
  проверено r1 численно и по коду, дельта эти утверждения не трогает;
- корректность и неразмытость раздела «Не входит» (#292/#289/#290,
  partial-shared/diagonal/>2-room, schema/storage вне скоупа);
- то, что контракт разделов 3–4 (Pointer contract, Live overlay contract)
  восстанавливает уже документированное в `docs/RESIZE.md`, а не изобретает
  новую продуктовую рамку;
- то, что новая часть контракта (toast при непредсказуемом reject) — не
  придуманный UX, а прямой запрос владельца через существующий механизм
  `toast.*`;
- проверяемость и способность падать AC1–AC10 (mutation-требования в
  AC1/AC2/AC5/AC8, отсутствие двойного источника числа);
- согласованность раздела 8 с `docs/TOUCH-SUPPORT.md` (safety floor);
- корректность условной формулировки i18n (раздел «Ожидаемые файлы»: en/ru
  ключи «если добавляется runtime reason»);
- корректность release-артефактов (раздел 12: трейлеры, оба changelog,
  закрытие только бетой).

Ни один из этих пунктов не мог измениться дельтой этого раунда: дельта не
касается разделов 1–8, 11–13, только добавляет 9–10 и одну строку индекса.

## Находки этого раунда

Нет. Дельта полностью закрывает M1 и L1, новых High/Medium/Low не внесено.

## Что проверено и признано корректным (в дельте)

- Оба новых раздела присутствуют, содержательны, не формальны (не «риск: не
  установлен» без конкретики) и ссылаются на реальные, существующие AC.
- Renumbering разделов 9→11, 10→12, 11→13 не сломал внутренних ссылок —
  ссылок по номеру раздела в документе нет вообще.
- Индекс `docs/specs/README.md` обновлён в правильной таблице (`P1`).
- Коммиты дельты несут корректные трейлеры (`Issue: #293`,
  `User-Visible: no` — доки, не продукт).
- Документ теперь формально закрывает все обязательные разделы §7.1: риски и
  откат добавлены, остальные были на месте с r1.

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

- Полный повторный разбор разделов 1–8, 11–13 — не требуется по §2.10, они не
  входят в дельту; их проверка наследуется из r1 (см. выше).
- `typecheck`/`test`/`build`/смоки/invariants/golden — неприменимо, продуктовый
  код не менялся ни в одном из двух раундов.
- Соответствие итоговой реализации разделам 9–10 — предмет код-ревью (§2.7),
  не этапа ТЗ.

## Итог

High: 0. Medium: 0. Low: 0. Обе находки r1 (M1 Medium в скоупе, L1 Low)
закрыты правкой текста, проверено построчно. Дельта чисто документационная,
локальная, не задевает AC, контракт или подсистему — полный разбор не
требовался и не проводился повторно там, где дельта не дотягивается. Вердикт:
зелёный. Issue переходит в «Готово к разработке» (S5-ready).