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

# SPEC-REVIEW-234-r2

- Issue: [#234](https://github.com/Matysh/houseplan-card/issues/234) — «Толщина отрезка цепочки молча сбрасывается на 15 см, хотя превью показывает нарисованную»
- ТЗ: `docs/specs/234-chain-segment-thickness.md`
- Ветка: `issue/234-chain-segment-thickness`, вершина на момент ревью: `b9dc870`
- Этап: spec-review, заход **r2**, блокирующих циклов израсходовано **1 из 4** (жёлтый r1 потратил цикл; этот заход, если зелёный, цикла не тратит — §7.2, #227)
- Предыдущий раунд: r1, вердикт жёлтый, SHA `88d8cfc`, документ `docs/reviews/SPEC-REVIEW-234-r1.md`

## Скоуп ревью (по дельте, PROCESS.md §2.10)

Раунд r1 дал ровно одну блокирующую находку (M1, Medium — отсутствие обязательного
раздела i18n) и одну снятую с записью Low (L1 — граница `> 0` не названа явно в
примере AC1). Автор ответил комментарием и коммитом `b9dc870`.

Дельта объявлена как `git diff 88d8cfc..b9dc870`:

```
docs/reviews/SPEC-REVIEW-234-r1.md        | 72 +++++++++++++++++++++++++++++
docs/specs/234-chain-segment-thickness.md | 14 ++++--
```

Первый файл — публикация документа r1 предыдущим шагом конвейера, не предмет
разбора. Второй — весь предмет этого раунда, и это три локальных правки текста:

1. заголовок §9 переименован «Изменяемые файлы» → «Изменяемые файлы и i18n»
   (без сдвига нумерации — проверено: §10…§17 в файле после правки идут в том же
   порядке, что до неё);
2. в §9 добавлен абзац «**i18n: не затронут.**…» и уточнён абзац про миграции;
3. в таблице §10 строка AC1 дополнена явным упоминанием `0` как невалидного
   значения.

Контракт (§6), инвариант (§7), границы (§5), AC2…AC9, mutation guards (§11) и
продуктовая рамка не менялись. Дельта строго локальна: не ребейз (`dev` не
сдвигался под веткой — родитель `fd43a25` тот же, что был на момент r1), не
смена контракта, не новая подсистема, объём — 14 строк текста. Полный повторный
разбор всей задачи не требуется; проверяются закрытие находок r1 и то, до чего
дотягивается сама дельта (раздел i18n как обязательный §7.1-раздел и
формулировка AC1).

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

| Находка r1 | Чем закрыта | Где видно |
|---|---|---|
| **M1** (Medium) — раздел `i18n` из обязательного списка §7.1 отсутствовал целиком | §9 переименован в «Изменяемые файлы и i18n», добавлен абзац «i18n: не затронут — задача не добавляет и не меняет строк интерфейса», плюс явное утверждение, что `src/i18n/en.json` и `src/i18n/ru.json` не появятся в диффе кода | `docs/specs/234-chain-segment-thickness.md`, §9, коммит `b9dc870` |
| **L1** (Low, была снята с записью, но автор закрыл добровольно) — граница `> 0` vs текущее `>= 0` не названа явно в примере AC1 | Строка AC1 в §10 дополнена: «…и **явный `0`**» с объяснением, что прежняя `wallChainSegments` считала ноль валидным, а контракт §6 сдвигает границу | `docs/specs/234-chain-segment-thickness.md`, §10, таблица AC, строка AC1, коммит `b9dc870` |

Обе закрыты текстом, а не заявлением: правки видны в самом диффе выше, не только
в комментарии автора.

## Проверка дельты

- **i18n-абзац.** `src/i18n/en.json` и `src/i18n/ru.json` существуют в дереве
  (`ls src/i18n/`) и не входят в диапазон `88d8cfc..b9dc870` — утверждение
  документа «файлы в диффе отсутствуют» на момент спеки корректно относится к
  будущей реализации, а не к этому текстовому коммиту, и это ожидаемо для этапа
  spec.
- **Абзац про миграции.** Ссылка «§4.3» адресует пункт 3 списка §4 («Формат
  конфигурации не меняется: `partitions[].cm` и `room_drafts[].segments[].cm`
  остаются как есть») — такая адресация к пункту списка уже использовалась в
  документе r1 (например, «§15.3»), это существующая конвенция документа, не
  новая двусмысленность.
- **Нумерация после переименования §9.** Сверено построчно: заголовки §10–§17
  не сдвинулись, ссылки на «§15», «§16» в тексте документа и в этом
  обсуждении остаются валидными.
- **AC1 после правки.** Новая формулировка («явный `0`… контракт §6 сдвигает
  границу на `> 0`») согласована с правилом §6 п.1 (`recorded[i]` — число и
  `> 0` → берётся оно) и не создаёт противоречия с AC2 или с mutation guard
  `chain-thickness-falls-back-to-default` (§11) — тот проверяет правило §6 п.2
  целиком, `0` — один из входов, покрытых той же таблицей, отдельного гварда не
  требует.
- Оба добавленных абзаца и правка AC1 не вводят новых утверждений о поведении,
  не зафиксированных ни в одном каноне (WALL-THICKNESS.md, CONFIG-COMPATIBILITY.md) —
  формулировки описывают то же решение §6/§15.3, что уже было проверено в r1,
  просто делают его явным в нужных разделах.

Новых находок дельта не создала.

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

Принято без повторной проверки в этом раунде, основание — документ
`docs/reviews/SPEC-REVIEW-234-r1.md` на SHA `88d8cfc`:

- продуктовая рамка: задача закрывает J6 «Keep the plan true as the home
  evolves» из `docs/SCOPE.md`, второстепенно J4; согласуется с
  `docs/WALL-THICKNESS.md` §6 и `docs/USER-GUIDE.ru.md:355` — расхождений с
  каноном нет;
- диагноз §3 ТЗ сверен построчно с `src/houseplan-card.ts` и
  `src/wall-face-graph.ts` на `88d8cfc`: пять формул, три fallback-паттерна,
  неатомарная запись точки, слепое копирование `_draftSegmentCms` при
  восстановлении — подтверждены кодом; дельта этих файлов не касалась;
  смещение номеров строк в ТЗ на 1–3 признано шумом;
- контракт `chainSegmentCms` (§6) однозначен, правило разрешения толщины
  проверено на согласованность с §15.3;
- AC1…AC9 однозначны, у каждого указан способ доказательства; AC3/AC4
  воспроизводят диагностированный симптом (`30, 30, 15` → `30, 30, 30`);
  дельта изменила только текст строки AC1, остальные AC не трогала —
  переподтверждать AC2…AC9 не требуется;
  регрессные смоки `demo/smoke_draw_wall_thickness.mjs` и
  `demo/smoke_wall_thickness_transition.mjs` существуют;
- mutation guards (§11) реалистичны, формат совпадает с существующими
  записями `scripts/mutation-gate.mjs`;
- touch-классификация (§8, `Touch editor: not exposed`) верна по
  `docs/TOUCH-SUPPORT.md`;
- продуктовый вопрос владельцу («чем заполнять отсутствующую запись») закрыт
  корректно по §2.2, отделён от технических предположений (§17);
- откат (§14) реалистичен, формат данных не меняется.

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

- Реализацию — её всё ещё не существует, стадия — spec.
- Точное значение `DRAW_WALL_DEFAULT_CM` (буквально `15`) — не открывал файл
  определения повторно; в r1 это уже было заявлено как непроверенное, дельта
  этой константы не касалась.
- Golden/скриншоты — не затронуты по тем же причинам, что в r1: задача не
  меняет формулы рендера.
- Регистрацию `docs/specs/README.md` — не входит в дельту `88d8cfc..b9dc870`,
  не проверялась ни в r1, ни здесь.

## Вердикт

Обе находки r1 закрыты текстом, а не заявлением: i18n-раздел присутствует и
содержателен, граница `> 0` названа явно в AC1. Дельта строго локальна,
контракт и AC2…AC9 не менялись, новых находок нет. High: 0, Medium: 0.

**Вердикт: зелёный · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 0 · Документ: docs/reviews/SPEC-REVIEW-234-r2.md**