docs: review document for #234

Issue: #234
User-Visible: no
This commit is contained in:
claude[bot]
2026-08-21 19:41:37 +03:00
committed by Sergey Matyunin
parent b2024c6626
commit 67505f8343
+125
View File
@@ -0,0 +1,125 @@
# 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**