# 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.