houseplan-card/docs/reviews/SPEC-REVIEW-313-r1.md

# SPEC-REVIEW-313-r1

Issue: #313 · этап: ТЗ (spec) · трек: `small` (лёгкий) · заход: r1 · лимит циклов ТЗ: 2 · израсходовано: 0

## Скоуп

Инструмент «Толщина» (`_wallThickHit`/`_wallThickHover`/`_wallThickClick`/`_wallThickApply`,
`src/houseplan-card.ts`) сейчас видит только атомарные интервалы контуров комнат
(`wallIntervals(space.rooms, …)`) и не видит независимую кладку — перегородки
(`space.partitions`) и сегменты сохранённых черновиков (`space.room_drafts[].points`).
ТЗ расширяет резолвер, hover, диалог и запись на все три источника, с приоритетом
независимой кладки при наложении и без кнопки «на всю комнату» для неё. Модуль один,
файл один — критерии `small` (сложность/риск ≤3, одна поверхность, без миграции,
без нового UX-контракта, без влияния на перф/touch) соответствуют содержанию задачи.

Первый вопрос по `docs/SCOPE.md`: чью работу закрывает правка. Инструмент правки
геометрии Plan-редактора — часть J6 («Keep the plan true as the home evolves»,
два редактора, drag/resize/merge/split). Конфликта со SCOPE нет: это устранение
дыры в уже существующем, одобренном инструменте, а не новая функциональность.

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

Ревью ТЗ этапа `S4-spec-review`, r1 — полный разбор (первый заход, дельты нет).
Читал: `docs/SCOPE.md`, `AGENTS.md`, `PROCESS.md` (§1–§12), тело issue #313 и
единственный комментарий (аналитика + решения владельца от 2026-08-26), канонический
документ подсистемы `docs/WALL-THICKNESS.md`, срез `docs/USER-GUIDE.ru.md` по
инструменту «Толщина», связанные issues #308 (закрыт), #306 (open, S3-spec),
#229 (закрыт), #303 (закрыт).

Код читался в дереве `dev @ a78deb7c` (текущий HEAD), не исполнялся — это ревью ТЗ,
не код-ревью, автотестов ещё нет. Каждое фактическое утверждение ТЗ (сигнатуры,
существование функций/полей, номера строк, тексты тостов, содержимое смоков)
проверено чтением исходников и `docs/WALL-THICKNESS.md`, а не принято на слово:

- `_wallThickHit` (:11915) действительно перебирает только `wallIntervals(space.rooms, …)` —
  подтверждено чтением, совпадает с описанием «Причина (код)».
- `_wallThickApply` (:11978) действительно пишет только через `sp.walls` /
  `setWallThicknessForRoom` — writer для `partition.cm`/`draft.segments[i].cm`
  отсутствует, подтверждено.
- `wallThickHoverHalfUnits(hit.cm, …)` уже принимает `cm` (:11946, импорт :312) —
  подтверждено, hover-контракт из #303 переиспользуется без изменений.
- `PartitionCfg` (`src/types.ts:64`) и `RoomDraftCfg.segments[i]` (`src/types.ts:56-61`)
  уже содержат обязательное числовое поле `cm` — модель не меняется, миграция не нужна.
- `docs/WALL-THICKNESS.md` §9 УЖЕ фиксирует инвариант «1–100 см для перегородок и
  сегментов драфта, ноль не существует» и «Invalid input blocks the commit and
  reports the valid range» — решение владельца №2 (запретить 0/пусто для независимой
  кладки) не догадка, а совпадение с задокументированным контрактом модели.
  Это же объясняет, почему у комнатных стен 0 легитимен (§6 канона: «empty/0 clears»),
  а у независимой кладки — нет: два разных, уже описанных контракта, ТЗ их не путает.
- `toast.wallthick_pick` / `toast.wallthick_open` / `toast.physical_range` (`src/i18n/ru.json:533-537`)
  существуют и достаточно общие для переиспользования на перегородках/драфтах —
  новых ключей i18n действительно не требуется, как заявлено в аналитике.
- `_commitPhysicalGeometry` + `history.wall_thickness` (:12017) — существующая
  физическая транзакция с одним Undo, переиспользуется корректно.
- Правило приоритета независимой кладки над контуром комнаты уже реализовано и
  используется в смежном коде — `_boundaryBlocked` (:11285-11309, комментарий
  «Independent masonry owns its hit zone…») перебирает `wall_columns`, `partitions`
  и `room_drafts` именно в этом порядке приоритета для операций границы/select.
  Формулировка ТЗ «согласуется с select-инструментом» подтверждена, а не голословна.
- `_activeDraftId` (:1548) переживает переключение инструмента/пространства
  (:1291, :2188) — «активный драфт инструменту не виден» описывает реальную
  достижимую ситуацию (недорисованная цепочка, отложенная переключением тула),
  а не искусственный кейс; исключение активного драфта уже так работает у snap-геометрии
  (`excludeDraftId`, :6746; комментарий :20349) — переиспользование обосновано.
- Три смока, названные в AC4, существуют: `demo/smoke_wall_thickness.mjs`,
  `demo/smoke_wallthick_hover_width.mjs`, `demo/smoke_resize_wall_thickness.mjs`.
- Кнопка «на всю комнату» (`wallthick.apply_room`, :12558-12560) сейчас рендерится
  безусловно — условный рендер по «есть ли `roomId`/kind `room`» технически
  тривиален, контракт (п.3) реализуем как описано.
- #308 (пример наложения перегородки на ребро комнаты, фикстура-экспорт в
  приложении к отчёту) — issue **закрыт** без комментария к закрытию и без метки
  `rejected`, при этом сохраняет статусную метку `S1-new` (в нарушение §2.9/§9
  PROCESS.md — закрытый issue не должен нести `S*`). Это не блокирует #313: своя
  AC3 (приоритет при наложении) самодостаточна и не зависит от того, будет ли
  когда-нибудь сделана «согласованная правка обоих источников» из решения
  владельца №3. Но пункт «остаётся скоупом #308» из решения владельца сейчас
  ссылается в никуда — фиксирую это как наблюдение, не как находку против #313.

Гейты кода не гонялись — на этапе ТЗ кода ещё нет, тестировать нечего
(`typecheck`/`test`/`build`/`check-docs` относятся к код-ревью, §2.7/§8).

## Находки

Ни одной High/Medium. Одна Low, снимаю с записью (не блокирует, автору можно
поправить попутно при написании ТЗ AC/PR, отдельного цикла не требует):

- **Low — неверный номер строки в цитате.** В разделе «Что нужно» (п.1) и в
  разделе «Причина» issue правило «Independent masonry owns its hit zone»
  указано по адресу `:11104`. На `dev @ a78deb7c` по этому адресу лежит фрагмент
  диалога decor-текста (цветовой пикер), правило по факту находится в
  `_boundaryBlocked`, `src/houseplan-card.ts:11285`. Раздел «Контракт» (та часть
  ТЗ, что реально нормативна) этот номер не повторяет — там же цитата дана без
  строки, поэтому имплементация не пострадает. Правлю с записью: верный адрес —
  `src/houseplan-card.ts:11285`.

## Что проверено и корректно

- Трек `small` выбран обоснованно, все пять критериев §5 выполнены (одна
  поверхность/один файл, риск/сложность ≤3, без миграции, без нового
  UX-контракта — кнопка `apply_room` просто скрывается там, где нет комнаты,
  остальной диалог тот же, — без влияния на touch/perf).
- Обязательные для light-трека разделы (проблема · контракт · AC · откат)
  присутствуют, ни один не пуст.
- Три продуктовых решения владельца (комментарий 2026-08-26) корректно перенесены
  в «Контракт» и не переизобретены заново.
- Все 4 AC пронумерованы, каждый называет способ доказательства (`smoke`/`unit`),
  AC1/AC2 явно фиксируют текущее красное состояние («падает на текущем dev —
  hit = null»), AC3 задаёт конкретную регрессионную фикстуру (#308), AC4 защищает
  от регрессии по существующим гейтам — тест на «AC умеет упасть» проходит на
  уровне формулировки (для AC1/AC2 это прямо написано).
- Ни одного продуктового вопроса не осталось открытым: три развилки, требовавшие
  решения владельца (кнопка диалога, ноль/пусто, приоритет при наложении), закрыты
  явными решениями в комментарии аналитики, а не угаданы автором.
- Утверждений о поведении, не подтверждённых документом/кодом и не помеченных как
  предположение, не найдено — единственная фактическая неточность (строка :11104)
  разобрана выше как Low.
- Откат («один revert, без миграций и новых полей конфига») соответствует факту:
  модель данных не меняется, меняется только резолвер/writer инструмента.
- Конфликта со `docs/SCOPE.md` и `docs/TOUCH-SUPPORT.md` не нашёл: правка
  редактора Plan (десктоп-первый инструмент), в View не протекает.

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

- Не проверял по коду, что hit-резолвер после правки не даст обратной регрессии
  для контуров комнат при наличии рядом коллинеарной перегородки НЕ на кейсе
  #308 (общий случай «рядом, но не точно на ребре») — в ТЗ такой AC не заявлен
  явно за пределами AC3/AC4, это забота код-ревью и, при необходимости, находка
  для отдельного цикла на этапе кода, а не пробел ТЗ (AC4 достаточно узко и
  корректно защищает именно регрессию контуров).
- Не проверял столбы (`space.wall_columns`) на предмет того, должен ли инструмент
  «Толщина» также брать их — симптом, аналитика и AC ни разу их не упоминают,
  а в `docs/USER-GUIDE.ru.md` у колонны уже отдельный диалог размера через select
  (не через «Толщина»); границу считаю намеренной и не отношу к находкам.
- Не прогонял никаких автотестов/смоков — на этапе ТЗ кода нет, гонять нечего;
  сами тексты AC1/AC2 содержат обязательство, что новый смок «падает на текущем
  dev», это будет предметом код-ревью, а не этого документа.
- Не проверял `#306` (замена виртуальных стен стенами cm=0) по существу — он
  открыт, в `S3-spec`, `blocked`, и в контракт #313 входит только требованием
  «точка записи не должна требовать переписывания под будущую ветку 0», что
  является технической, а не продуктовой договорённостью и не подлежит проверке
  на этом этапе.

## Вердикт

Готово к разработке. Both AC-доказательства и продуктовые развилки закрыты
решениями владельца; единственная находка — Low, снята с запиской в этом
документе, отдельного цикла не требует.