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

# SPEC-REVIEW-272-r2

- Issue: [#272](https://github.com/Matysh/houseplan-card/issues/272) — «Multi-wall стыки beta.5 всё ещё оставляют белые треугольные отверстия вне probe #261»
- Этап: ТЗ на ревью (PROCESS.md §2.4)
- Заход: r2 · блокирующих циклов израсходовано 1 из 4
- Артефакт ТЗ: `docs/specs/272-no-multiwall-holes.md`, коммит `08dcd0000c92fa643d81275b8afc544a08b71e1b` (ветка `issue/272-no-multiwall-holes`)
- Предыдущий заход: r1, вердикт жёлтый, документ `docs/reviews/SPEC-REVIEW-272-r1.md` (коммит `2133be1faf75f6951578ae2c2e793fbebf024672`), получен на SHA документа ТЗ `9e4a9470b63718d75cb6e11b13717ccc24cbe4e6`
- Ревьюер: свежая сессия, без устных пояснений автора

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

r1 нашёл SHA `9e4a9470b63718d75cb6e11b13717ccc24cbe4e6` (комментарий r1 его не называл — это уже было отмечено находкой предыдущего раунда неявно через требование указывать SHA; в этом заходе SHA восстановлен из тела комментария «ТЗ готово к ревью», где автор явно назвал коммит). Автор ответил комментарием «ТЗ обновлено по ревью r1» с явным SHA `08dcd0000c92fa643d81275b8afc544a08b71e1b` — тем же, что сейчас HEAD ветки задачи.

Дельта объявлена командой:

```
git diff 9e4a9470b63718d75cb6e11b13717ccc24cbe4e6..08dcd0000c92fa643d81275b8afc544a08b71e1b
```

Результат — `git diff --stat` по обоим SHA:

```
docs/reviews/SPEC-REVIEW-272-r1.md   | 179 +++++++++++++++++++++++++++++++++++
docs/specs/272-no-multiwall-holes.md |  29 +++++-, 2 --
```

Первый файл — документ ревью r1, добавленный конвейером; не предмет разбора. Второй — ровно файл ТЗ, единственный предмет этого раунда. Дельта полностью локальна: правки текста не расширились ни на новый раздел, ни на другую подсистему, ребейза на `dev` не было (`git log` показывает прямую линию `9e4a947 → 2133be1 → 08dcd00`, без слияний). Основание для разбора по дельте, а не заново, выполнено — переопределения продуктовой рамки (§1) и AC, не затронутых правкой, не требуется.

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

| Находка r1 | Чем закрыта | Где это видно |
|---|---|---|
| Medium 1 — AC2–AC7 без явной строки «Доказательство» | К каждому из AC2, AC3, AC4, AC5, AC6, AC7 добавлена отдельная строка `**Доказательство:** …`, называющая конкретный тест-файл или тип гейта (unit/smoke/golden/mutation) | `docs/specs/272-no-multiwall-holes.md:215-216` (AC2 → `test/wall-thickness.test.mjs`, connected-component inventory), `:224-225` (AC3 → #197/#249/#261/#271 unit, mutation, targeted smoke), `:234-235` (AC4 → targeted production-bundle multiwall/junction smoke, `isPointInFill()`), `:251-252` (AC5 → `demo/golden/harness.mjs`, `test/golden-matrix.test.mjs`, targeted Linux semantic golden verify), `:260-261` (AC6 → `scripts/mutation-gate.mjs`), `:269-270` (AC7 → anonymous minimized table-driven units) |
| Medium 2 — «объявленный exterior sector» не определён алгоритмически (§6.3, п.3) | Пункт 3 переписан: критерий сведён к одному вычисляемому правилу связности (компонент пустоты достигает границы окна, не пересекая union конечных incident ray strips и node core), фраза «объявленный exterior sector» удалена целиком; добавлен абзац, прямо запрещающий fixture-аннотацию и привязывающий discarded wedge #249 к тому же вычисляемому пути | `docs/specs/272-no-multiwall-holes.md:153-163` (новый текст п.3 и абзац «Exterior здесь не назначается fixture-аннотацией…») |
| Low 1 — избыточная ссылка на J6 наряду с J1 (снята в r1 без правки, с записью) | Решение ревьюера r1 — снята без правки, повторной проверки не требует | `docs/reviews/SPEC-REVIEW-272-r1.md`, раздел «Находки», Low-1 |

Обе Medium-находки закрыты текстом, а не заявлением автора: сравнение диффа с формулировкой правки в r1 совпадает построчно — реализовано ровно то исправление, которое r1 предложил как один из вариантов («одна фраза… фиксирующая происхождение сектора как вычисляемой величины»).

## Что проверено в этом раунде (по дельте)

- **AC2–AC7, строки «Доказательство»**: каждая называет конкретный файл или тип гейта в терминах §2.5 PROCESS.md (`unit`/`smoke`/`golden`/`mutation`) — механически сверяемо, догадок нет. AC3 называет тип пруфов («unit, mutation и targeted smoke probes») без файла — это соответствует минимальной букве §2.5 («указано, чем доказывается»), и то же допущение (тип без файла) уже принято в AC4 текстом до правки; не считаю это новой находкой, так как речь о наборе существующих регресс-тестов (#197/#249/#261/#271), которые уже названы поимённо в тексте AC3 выше строки «Доказательство».
- **§6.3, п.3 — переформулированный критерий на внутреннюю согласованность**: новое правило («компонент связности достигает границы окна, не пересекая union конечных incident ray strips и node core») использует ровно те термины, что определены в §6.1 («required solid», «incident positive ray», «node core») и не вводит новых недоопределённых понятий. Критерий стал детерминированным полностью (снята развилка «граница окна ИЛИ объявленный сектор» → осталось только «граница окна без пересечения union»), что усиливает, а не ослабляет исходный контракт — обратной регрессии для AC1/AC5 не создаёт.
- **Содержание AC1, AC3 (кроме добавленной строки), AC4–AC7 не изменилось** — только добавлены строки доказательства, критерии приёмки остались текстуально идентичны r1 (сверено построчно по diff — исправление не переписывает уже верное содержание, как и требовал ревьюер r1).
- **Отсутствие новых догадок**: новый абзац §6.3 не вводит нового технического решения, требующего продуктового вопроса владельцу — он полностью технический (как алгоритм вычисляет связность), и решение уже помечено в §13 как разрешённое реализации («конкретный boolean algorithm выбирается реализацией»), что не изменилось.

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

Принято без повторной проверки — документ `docs/reviews/SPEC-REVIEW-272-r1.md`, вердикт получен на SHA `9e4a9470b63718d75cb6e11b13717ccc24cbe4e6`:

- соответствие обязательным разделам §7.1 PROCESS.md (сценарий, персона, «что человек увидит», проблема, scope/не-scope, UX/touch/i18n/данные, риски, откат, release-артефакты) — раздел ТЗ, дельта не касалась;
- построчная сверка §3/§6.1–6.2 контракта с `src/wall-thickness.ts` (`MITRE_LIMIT`, `MULTI_WALL_JOIN_LIMIT`, `multiWallBevelTrianglesAt`/`bevelMultiWallBody`/`bevelMultiWallPaper`) — код не менялся, эти строки ТЗ не менялись;
- корректность описания состояния связанных issue #249/#258/#261/#270/#271 (закрыты/открыты, что уже слито) — не менялось;
- отсутствие продуктовых вопросов владельцу — подтверждено в r1 и остаётся верным: правки r2 чисто технические (формат AC, формализация критерия), ни одна не требует решения «что видит пользователь»;
- корректность отсылки к `docs/SCOPE.md` (J1, за вычетом снятого Low по J6) — не менялось.

## Гейты этого раунда

Как и в r1: диапазон `origin/dev..HEAD` для этого issue содержит только документы (`docs/specs/272-no-multiwall-holes.md`, `docs/reviews/SPEC-REVIEW-272-r1.md`), продуктовый код не менялся. `typecheck`/`test`/`build` не прогонялись — ревью документа ТЗ этого не требует; прогон был бы гейтом без предмета проверки.

## Вердикт

Зелёный. Обе Medium-находки r1 закрыты текстом ТЗ, без потери и без ослабления содержания критериев; переформулированный критерий §6.3.3 детерминирован и не вводит новой неопределённости или продуктового вопроса. High-находок нет и не было. Готово к разработке.