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

SPEC-REVIEW-234-r2

• Issue: #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