docs: review document for #316

Issue: #316
User-Visible: no

docs/reviews/SPEC-REVIEW-316-r3.md

@@ -0,0 +1,214 @@
+# SPEC-REVIEW-316-r3
+
+Issue: #316 · ТЗ: `docs/specs/316-opening-host-auto-resolution.md` ·
+заход: r3 · блокирующих циклов израсходовано 2 из 4 (входящее значение, до
+этого вердикта) · SHA материала ревью r3: `56ffbfac`
+(`docs: spec #316 revision 3 — correct compatibility reference, honest
+golden expectation`). Материал r2: SHA `6ca2ce8b`, документ
+`docs/reviews/SPEC-REVIEW-316-r2.md`. Материал r1: SHA `36f735ae`, документ
+`docs/reviews/SPEC-REVIEW-316-r1.md`.
+
+## Скоуп раунда
+
+Разбор — по дельте (PROCESS.md §2.9): `git diff 6ca2ce8b..HEAD --
+docs/specs/316-opening-host-auto-resolution.md`. Дельта — 13 добавленных /
+5 удалённых строк, целиком внутри §5.1 (ссылка на `docs/CONFIG-COMPATIBILITY.md`)
+и §5.3 (утверждение про golden-сцены) плюс однострочная правка статус-строки
+в шапке — это прямой точечный ответ на M3/M4 ревью r2, нормативные правила
+§3, AC и границы §2 не тронуты. Оснований для полного разбора нет — дельта
+меньше исходной задачи и локальна к двум абзацам.
+
+Комментарии issue #316 проверены полностью (`gh issue view 316 --json
+comments`): после вердикта r2 единственный новый комментарий — «Ревизия 3
+(56ffbfac)» автора, описывающий исключительно техническую правку по M3/M4;
+новых продуктовых директив владельца не появилось.
+
+## Как проверялось
+
+1. Найден вердикт r2 в комментариях issue (2026-08-26T18:01:35Z) и SHA
+   материала (`6ca2ce8b`, назван в документе r2).
+2. `git diff 6ca2ce8b..HEAD -- docs/specs/316-opening-host-auto-resolution.md`
+   — построчная сверка дельты с текстом находок M3/M4.
+3. **M3 (ссылка на `docs/CONFIG-COMPATIBILITY.md`).** Прочитан абзац
+   раздела «Canonical zero-thickness walls — model v9 (#306)»
+   (`docs/CONFIG-COMPATIBILITY.md:81-102`): цитата в новом тексте ТЗ
+   («…verifies that no opening would acquire a zero host… A conflict
+   rejects the complete candidate») сверена посимвольно со строками 93–95
+   файла — совпадает дословно. Раздел «Independent-wall opening host
+   (#132)» (строки 188+) явно назван вне скоупа отдельным предложением —
+   соответствует коду (`resolveRoomOpeningHost`/`hostRoomOpenings` в
+   `src/wall-segment-model.ts:591/620` пропускают `host.kind==='partition'`,
+   что и есть предмет раздела #132). M3 закрыта корректно.
+4. **M4 (claim про golden-сцены).** Новый текст §5.3 признаёт существующую
+   комбинацию span+проём в `coincident-partition-virtual-dark` (честно,
+   больше не выдаёт отсутствие за факт) и добавляет техническое
+   обоснование «ожидания без изменений»: «это независимая кладка вне
+   контурных атомов правила 3.1». Это обоснование проверено отдельно от
+   факта существования сцены — и оказалось неточным (см. находку M5 ниже).
+   Сам факт существования комбинации (закрытие исходной M4) подтверждён
+   повторно: `demo/golden/harness.mjs:99-112` — фикстура берётся из
+   `test/fixtures/276-coincident-partition.json`, `matrix.mjs:185-187` —
+   сцена в матрице с `mode: 'view'`, `baselines-index.json` — принята.
+5. Проверка обоснования M4 по коду и фикстуре (новая находка, см. ниже):
+   - `test/fixtures/276-coincident-partition.json` — `rooms: [left, right]`
+     делят контурную границу; `walls[0]` (`cm:15`, `key` в формате
+     `wall_segments`) — это контурная стена между комнатами; `partitions[0]`
+     (`id:"redundant"`, `cm:20`) — независимая кладка, дублирующая ту же
+     позицию; `openings[0].host` изначально `{kind:'partition',
+     id:'redundant', t:0.5}` — дверь хостится на партиции, не на контуре.
+   - `demo/golden/harness.mjs:99-112` (`state !== 'before'`): `delete
+     space.partitions` — независимая кладка удаляется целиком; `delete
+     opening.host` — хост очищается (не остаётся `'partition'`).
+   - `src/wall-segment-model.ts:617-625` (`hostRoomOpenings`): пропуск
+     `continue` срабатывает только при `opening.host?.kind === 'partition'`
+     (строка 620). После `delete opening.host` условие ложно — если бы
+     миграция когда-нибудь прошла по этому состоянию, проём обрабатывался
+     бы как контурный, тем же путём `resolveRoomOpeningHost`/`segments`,
+     что и правило 3.1 — то есть ровно **внутри** контурных атомов, а не
+     «вне» них, как формулирует ТЗ.
+   - Реальная причина, по которой сцена не меняется, — не это (ошибочное)
+     утверждение, а граница §2 ТЗ: «Правила §3 действуют только при
+     initial migration», а голден-сцена рендерится в `mode: 'view'` без
+     какого-либо структурного редактирования. Подтверждено чтением
+     `src/houseplan-card.ts:7394-7435` — `commitWallSegmentModel`
+     вызывается только из пути структурного редактора (геометрический
+     жест), не из `setConfig`/чистого рендера; `matrix.mjs:185-187` не
+     содержит `dialog`/`editorTray`/иного действия, запускающего запись.
+6. AC1–AC6, правила 3.1–3.4, §1, §2, §4, §6–§8 дельтой не задеты (текст не
+   менялся) — не перепроверялись повторно, унаследованы из r1/r2 (см.
+   раздел ниже).
+
+Гейты `typecheck`/`test`/`build`/`check-docs` не прогонялись: диапазон
+изменений — только `docs/specs/316-*.md`, продуктового кода нет, класс C.
+Как и в r1/r2, гейтов для класса C на стадии ТЗ не предусмотрено.
+
+## Закрытие раунда r2
+
+| Находка r2 | Чем закрыта | Где видно |
+|---|---|---|
+| M3 / неверный абзац `CONFIG-COMPATIBILITY.md` | Ссылка заменена на абзац раздела «Canonical zero-thickness walls — model v9 (#306)», раздел #132 явно исключён отдельной фразой | §5.1, строки 115–122; цитата сверена дословно с `docs/CONFIG-COMPATIBILITY.md:93-95` |
+| M4 / claim «в существующих сценах нет span+проём» — неточен | Формулировка заменена на признание факта: сцена существует, названа по имени, дано обоснование ожидания, назван арбитр (`golden:verify`) | §5.3, строки 136–143 — **но см. новую находку M5**: обоснование ожидания технически неточно |
+
+M3 закрыта по существу без оговорок. M4 закрыта в части исходной претензии
+(факт наличия сцены больше не отрицается), но правка внесла новое
+неточное техническое утверждение — это не пропуск в закрытии M4, а новый
+текст того же абзаца, добавленный при исправлении.
+
+## Унаследовано из r2 (через r1)
+
+Без повторной проверки приняты выводы `docs/reviews/SPEC-REVIEW-316-r2.md`
+(SHA `6ca2ce8b`) и транзитивно `docs/reviews/SPEC-REVIEW-316-r1.md`
+(SHA `36f735ae`) по частям документа, которые дельта r3 не затронула:
+
+- §1 «Сценарий», §2 «Границы» — не изменились; цепочка причин, сверка с
+  #306 §8.2, и правило «Правила §3 действуют только при initial migration»
+  приняты как проверенные в r1 (и переиспользованы в r3 п.5 «Как
+  проверялось» для новой находки M5, но не переоткрывались).
+- §3 Правила 3.1–3.4 — текст не менялся; заимствование критерия
+  `eligible()`, обоснование физического смысла 3.1, рендер по x/y для
+  безхостовых проёмов (3.3) — приняты из r1/r2 без повторного чтения кода.
+- AC1–AC6 — текст не менялся, приняты как «сформулированы однозначно, со
+  способом доказательства» из r1, включая переписанную в r2 и подтверждённую
+  тогда фикстуру AC3 (стык двух контурных атомов на границе толщины).
+- §5.2 (i18n), §5.4 (perf/touch), §6 «Принято предположительно», §7
+  «Риски», §8 «Откат» — не менялись, приняты из r2.
+- Термин «непривязанный (unhosted)» — не менялся, коллизия с
+  `docs/UX-MODES.md` закрыта в r1/r2, повторно не проверялась.
+- §5.1 — раздел не менялся целиком, кроме абзаца про
+  `docs/CONFIG-COMPATIBILITY.md` (перепроверен, см. выше); остальные шесть
+  пунктов списка файлов (закрытие M1 из r1/r2) приняты без повторного чтения.
+
+## Находки
+
+### M5 (Medium, в скоупе) — §5.3 обосновывает «без изменений» неточным утверждением о контурных/независимых атомах
+
+ТЗ (строки 138–141): «`coincident-partition-virtual-dark` строит
+`open_spans` поверх позиции проёма с удалённым host — но это независимая
+кладка вне контурных атомов правила 3.1, поэтому ожидание — «без
+изменений»».
+
+Проверено по фикстуре и коду (детали — «Как проверялось» п.5): в состоянии
+`virtual` независимая кладка (`space.partitions`, `id:"redundant"`) как раз
+**удаляется** харнессом (`delete space.partitions`,
+`demo/golden/harness.mjs:100`), вместе с ней очищается `opening.host`
+(`delete opening.host`, строка 103). Единственная оставшаяся стена в этой
+позиции — `space.walls[0]`, контурная граница между комнатами `left` и
+`right` фикстуры `276-coincident-partition.json`. `hostRoomOpenings`
+(`src/wall-segment-model.ts:620`) пропускает проём только при
+`opening.host?.kind === 'partition'`; после очистки host это условие
+ложно, значит, если бы по этому состоянию когда-нибудь прошла миграция,
+проём обрабатывался бы как **контурный**, тем же путём
+`resolveRoomOpeningHost`, что и правило 3.1, — то есть ровно внутри
+контурных атомов, а не «вне» них, как формулирует ТЗ. Формулировка
+переворачивает факт.
+
+Практический вывод («без изменений») остаётся верным — но по другой,
+уже названной в самом ТЗ причине: §2 ограничивает действие §3 initial
+migration, а сцена рендерится в `mode: 'view'` (`matrix.mjs:185-187`) без
+структурного редактирования — `commitWallSegmentModel` вызывается только
+из пути геометрического редактора (`src/houseplan-card.ts:7394-7435`), не
+из `setConfig`/чистого рендера. Значит правила §3 в этой сцене вообще не
+выполняются, независимо от того, контурный это атом или нет.
+
+**Чем грозит, если не поправить:** ошибочная формулировка учит следующего
+читателя (в первую очередь код-ревью #316) неверному инварианту —
+«независимая кладка защищена от правила 3.1 по природе», хотя защищена
+на самом деле только *презентация без структурной записи* (§2). Если
+код-ревью или реализация опираются на эту фразу как на общее правило (а
+не на частный случай границы §2), это способно замаскировать реальный
+случай, где такая же комбинация span+проём попадёт под структурную
+запись (например, тот же конфиг после «Оптимизировать планы» или первой
+структурной правки) — там рассуждение «независимая кладка» уже не
+работает, потому что кладки к этому моменту в конфиге не остаётся.
+
+**Почему Medium, а не Low:** это тот же класс ошибки, что и закрытая в
+этом же раунде M3 (неверная техническая ссылка/обоснование выдана за
+факт) — процесс требует помечать непроверенные технические утверждения
+как предположения, а не факты; правится одной фразой без пересмотра §3
+или AC.
+
+**Как починить (без пересмотра §3):** заменить обоснование на то, что
+уже верно установлено ТЗ: «сцена рендерится в `mode: 'view'` без
+структурного редактирования — §3 применяется только к initial migration
+(§2), а презентационный рендер её не запускает; расхождение — если оно
+всё же возникнет — обязан поймать `golden:verify`».
+
+## Что проверено и корректно
+
+- M3 закрыта полностью и точно: цитата и номер раздела `docs/
+  CONFIG-COMPATIBILITY.md` теперь указывают на реально устаревающий абзац
+  (строки 93–95, «Canonical zero-thickness walls — model v9 (#306)»),
+  раздел #132 корректно исключён отдельным предложением.
+- M4 закрыта в своей исходной части: ТЗ больше не отрицает существование
+  комбинации span+проём в golden-матрице — сцена названа явно, `golden:
+  verify` назван арбитром, путь приёмки при расхождении описан (не
+  «молчаливая переснятие»).
+- Статус-строка в шапке документа корректно отражает историю раундов
+  («r1: M1/M2/Low; r2: M3/M4»).
+- Дельта r3 не затронула AC, §3 и границы §2 — соответствует характеру
+  находок r2 (обе были про формулировки в §5, не про нормативную часть).
+
+## Чего не проверял
+
+- Не перепроверял AC1–AC6 и правила 3.1–3.4 по коду заново — текст не
+  менялся дельтой r3, наследуется из r1/r2 (см. «Унаследовано из r2»).
+- Не прогонял гейты typecheck/test/build/check-docs/смоки/golden — класс
+  C, продуктового кода ещё нет, как и в r1/r2.
+- Не проверял #319 — вне скоупа, как и в предыдущих раундах.
+- Не проверял остальные golden-сцены на предмет иных неточностей в §5.3
+  сверх найденной в M5 — одного контрпримера достаточно для находки;
+  исчерпывающая проверка — задача `golden:verify` на стадии кода.
+- Не проверял, действительно ли `space.walls[0]` в фикстуре `276-
+  coincident-partition.json` при реальном прогоне миграции (а не
+  гипотетически) резолвится в `resolveRoomOpeningHost` без конфликта —
+  это не требуется для M5: находка о неточности формулировки «вне
+  контурных атомов», а не о существовании конфликта при миграции этой
+  конкретной фикстуры (которая при `mode:'view'` миграции не проходит
+  вовсе).
+
+## Вывод
+
+High-находок нет. M5 — новая находка этого раунда (текст, добавленный при
+закрытии M4, а не пропуск в закрытии M3/M4 как таковом), в скоупе задачи,
+чинится точечной заменой одного предложения без пересмотра §3 и AC.
+Вердикт — жёлтый, документ возвращается автору на ревизию 4.