# 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) закрыта по всем трём составляющим, новый
раздел не вводит противоречий и не расширяет скоуп. Готово к «Готово к
разработке».