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

SPEC-REVIEW-272-r2

• Issue: #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-находок нет и не было. Готово к разработке.