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

SPEC-REVIEW — Issue #278 · заход r2

• Issue: https://github.com/Matysh/houseplan-card/issues/278
• ТЗ: docs/specs/278-wall-union-isolation.md
  • SHA r1 (на котором проведено первое ревью): d906e5d8
  • SHA r2 (правки по замечанию, текущий HEAD): 53c96219
• Трек: обычный, файл ТЗ обязателен и присутствует.
• Заход: r2 · блокирующих циклов израсходовано 1 из 4 (жёлтый r1 потратил один цикл; этот заход, если зелёный, бюджет не тратит — §4/#227).

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

Единственная находка r1 — M1: отсутствовал обязательный раздел «Риски» (PROCESS.md §7.1). Дельта между d906e5d8 и 53c96219:

git diff d906e5d8..53c96219 -- docs/specs/278-wall-union-isolation.md

даёт ровно один добавленный блок — новый раздел ## 12.1. Риски и меры (15 строк, таблица «Риск | Мера» из 10 строк), вставленный между §12 «Архитектурный контракт» и §13 «Производительность». Ничего другого в ТЗ не менялось: ни один AC (§15), ни один раздел §1–§11, §13–§18 не тронут байт в байт.

Дельта локальна в терминах §2.10 (не ребейз, не смена контракта поведения, не новая подсистема, объём — один раздел из документа в 318 строк), поэтому разбор сужен: заново проверено только закрытие M1 и то, что новый раздел не вступает в противоречие с остальным текстом ТЗ (§3, §7, §18), которое он расширяет. Полная переоценка технического контракта (§3–§12, §15–§18), уже признанного обоснованным в r1, не производилась — см. «Унаследовано из r1».

Продуктовый код по-прежнему не менялся:

git diff --stat origin/dev...HEAD -- . ':!docs/reviews'
 docs/specs/278-wall-union-isolation.md | 318 +++++++++++++++++++++++
 docs/specs/README.md                   |   1 +

— как и в r1, гейты tsc/test/build/check-docs неприменимы: дерево кода идентично dev, изменился только документ ТЗ.

Как проверялось

1. Найден вердикт r1 (комментарий issue от claude, 2026-08-24T02:00:03Z) и SHA, на котором он получен, — d906e5d8; сам документ docs/reviews/SPEC-REVIEW-278-r1.md прочитан полностью.
2. Найден SHA правок r2 — не в основном хендофф-комментарии автора (там буквальный незаполненный плейсхолдер Коммит дельты: $sha), а в следующем комментарии-уточнении «Техническое уточнение хендоффа: фактический SHA правок r1 — 53c96219» — это совпадает с текущим HEAD (git log --oneline -1 → 53c96219 docs: address wall union spec review).
3. git show 53c96219 -- docs/specs/278-wall-union-isolation.md — единственная правка это новый раздел §12.1.
4. По каждому из трёх пунктов, перечисленных в M1 r1, проверено буквальное текстовое закрытие в добавленной таблице (см. таблицу ниже).
5. Прочитан раздел §18 «Принятые технические предположения» и §7 «Strict commit barrier» — на предмет противоречия с новым §12.1 (совпадение по порядку merge #276→#277→#278 и по судьбе временного adapter). Противоречий нет, новый раздел ссылается на те же решения, не переопределяя их.
6. Проверен текущий статус #276/#277 (gh issue view 276/277 --json labels): #277 — S4-spec-review (как и на момент r1), #276 — S3-spec (откатился с S4-spec-review, замечено дополнительно). Это не расходится с формулировкой риска в §12.1 («параллельны только ТЗ/review, код последователен») — риск сформулирован достаточно широко, чтобы покрывать и этот случай; отдельной находки не заводится.
7. Проверено, что новый раздел не вводит скрытую догадку, выданную за факт: каждая строка таблицы либо ссылается на существующий AC/раздел (AC4, AC5, AC7–AC9, AC11, §7, §13, §18.4), либо формулирует процессное обязательство («#278 не переходит в S6, пока #276 и #277 не merged») — это решение авторов о порядке работы, а не заявление о поведении продукта, которого нет в документах.

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

Находка r1	Чем закрыта	Где это видно
M1 — отсутствует обязательный раздел «Риски» (PROCESS.md §7.1)	Добавлен раздел ## 12.1. Риски и меры с таблицей из 10 пунктов	docs/specs/278-wall-union-isolation.md:225-236 (коммит 53c96219)
M1, подпункт: не разобран риск параллельного review #276/#277 при последовательном §18.4-порядке merge	Строка 1 таблицы: «#276/#277 ещё проходят ревью… Код строго последователен: #278 не переходит в S6, пока #276 и #277 не merged; ветка пересоздаётся/rebase от актуального dev»	Строка 1 таблицы §12.1
M1, подпункт: не оценён риск для legacy-планов, навсегда остающихся degraded-extra без ремонта #276	Строка 2 таблицы: «Render сохраняет стены, но strict geometry edits остаются заблокированы; user guide предлагает Optimize, затем export/bug report, без скрытого удаления данных»	Строка 2 таблицы §12.1
M1, подпункт: не оценён риск того, что временный adapter #277 переживёт merge и создаст дублирующую проверку	Строка 3 таблицы: «#278 удаляет adapter в том же implementation commit; source guard/call-site inventory и mutant writer-bypass требуют один exported barrier»	Строка 3 таблицы §12.1

Все три подпункта единственной находки закрыты текстом, а не заявлением автора о том, что «сделано» — правка проверена построчным чтением дельты, не хендофф-комментарием.

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

Без повторной проверки принято всё, чего дельта не касается — техническая часть контракта, признанная обоснованной в docs/reviews/SPEC-REVIEW-278-r1.md на SHA d906e5d8:

• центральное техническое утверждение §2/§12 (цикл extraBodies в wallBodiesGeometry() не имеет per-piece try/catch в отличие от roomRings/ wallEdgeBodies) — подтверждено построчным чтением src/wall-thickness.ts в r1, код с тех пор не менялся;
• roomGeom исключает extras (AC5) — тот же файл, та же проверка;
• границы с #197/#199 (не дубликат) — объяснение из issue и ТЗ не менялось;
• типизированный контракт ok/degraded-extra/failed-core/not-applicable (§4) и режимы strict/render-safe;
• canonical-consumers claim (§6), подтверждённый в r1 построчной сверкой с houseplan-card.ts/space-render.ts/plan-geometry-preflight.ts;
• AC1–AC15 (§15) и привязка каждого к способу доказательства;
• §11 «Не входит» — границы с #276/#277 не переопределены;
• §18 «Принятые технические предположения» — текст не менялся, включая §18.4 (порядок merge), на который новая находка ссылается без изменения смысла.

Источник: docs/reviews/SPEC-REVIEW-278-r1.md, SHA ТЗ d906e5d8.

Находки

Нет. High: 0, Medium: 0, Low: 0.

Что проверено и корректно

• Единственная находка r1 закрыта по существу, а не текстом «исправлено»: каждый из трёх названных в r1 подпунктов имеет собственную строку в новой таблице рисков с конкретной мерой, а не общей фразой.
• Новый раздел не противоречит §7/§18.4: порядок merge #276→#277→#278 и судьба временного adapter описаны одинаково в обоих местах документа.
• Новый раздел не содержит догадки, выданной за факт: каждая строка либо ссылается на существующий AC, либо формулирует процессное решение авторов (не наблюдаемое поведение продукта).
• SHA раунда r1 назван (в отличие от изначального незаполненного $sha в первом хендоффе, что само по себе было бы находкой, если бы не было исправлено следующим комментарием того же автора).
• Диапазон diff подтверждён git, а не заявлением: продуктовый код по-прежнему не тронут, гейты spec-этапа неприменимы, как и в r1.

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

• Полная переоценка технического контракта §3–§12, §15–§18 не выполнялась повторно — эти разделы не входят в дельту d906e5d8..53c96219 и приняты по выводу r1 (см. «Унаследовано из r1»).
• Реализуемость union()/polyclip-ts для per-extra изоляции — как и в r1, на этапе spec не проверяется экспериментально.
• Golden/perf/smoke наборы не запускались — код не менялся, гейты §8 к spec-этапу неприменимы.
• Не проверялось, действительно ли #276 откатился с S4-spec-review в S3-spec по существу (это факт другого issue) — учтён только как наблюдение, не влияющее на формулировку риска в §12.1.

Вердикт

Зелёный. Единственная находка r1 (M1) закрыта по всем трём составляющим, новый раздел не вводит противоречий и не расширяет скоуп. Готово к «Готово к разработке».