# SPEC-REVIEW-316-r2 Issue: #316 · ТЗ: `docs/specs/316-opening-host-auto-resolution.md` · заход: r2 · блокирующих циклов израсходовано 1 из 4 (входящее значение, до этого вердикта) · SHA материала ревью r2: `6ca2ce8b` (`docs: spec #316 revision 2 — registry/compatibility/goldens sections, reachable AC3 fixture`). Материал r1: SHA `36f735ae`, документ `docs/reviews/SPEC-REVIEW-316-r1.md`. ## Скоуп раунда Разбор — по дельте (PROCESS.md §2.9): `git diff 36f735ae..HEAD -- docs/specs/316-opening-host-auto-resolution.md`. Дельта локальна — это прямой ответ автора на M1/M2/L1 ревью r1 (новые §5 «Затронутые поверхности и артефакты», §6 «Принято предположительно», перенумерация §5→§7 «Риски» и §6→§8 «Откат», замена термина и фикстуры AC3), нормативные правила §3 и AC не переписаны. Оснований для полного разбора (ребейз, смена контракта, новая подсистема, объём дельты сопоставим с исходной задачей) нет — дельта это ровно правка по находкам r1, и по объёму (67 добавленных / 9 удалённых строк из ТЗ на 109 строк) меньше исходной задачи. Комментарии issue #316 проверены полностью (`gh issue view 316 --json comments`): после S4-решения владельца и вердикта r1 новых продуктовых директив нет — комментарий автора «Ревизия 2 ТЗ (6ca2ce8b)» описывает исключительно техническую правку по находкам r1, открытых продуктовых вопросов не появилось. ## Как проверялось 1. Найден вердикт r1 в комментариях issue (2026-08-26T15:09:36Z) и SHA материала (`36f735ae`, назван в документе r1 — не пришлось его реконструировать). 2. `git diff 36f735ae..HEAD -- docs/specs/316-opening-host-auto-resolution.md` — построчная сверка дельты с текстом находок M1/M2/L1. 3. По каждой находке r1 — проверка не заявления автора, а конкретной строки документа, которая её закрывает (таблица ниже), и, где утверждение опирается на код или другой документ, — сверка с реальным состоянием репозитория на HEAD: - `src/wall-segment-model.ts:588–615` (`resolveRoomOpeningHost`, `eligible`) и `src/wall-thickness.ts:1718–1771` (`atomicPolyForRoom`) — проверка, что новая фикстура AC3 (стык двух контурных атомов одной стены на границе смены толщины) действительно достижима: `wallBreaks`/`space.walls` с разными `cm` вносят точку разрыва в `atomicPolyForRoom` (строки 1743–1746), значит два атома одной стены с общей вершиной на границе толщины — реальный код-путь; `demo/smoke_wall_thickness_transition.mjs` подтверждает, что такой разрыв уже используется в тестах (для другого сценария, но тем же механизмом). Короткий проём в центре стыка попадает в допуск `t` обоих атомов (`t >= -EPS && t <= 1+EPS` при `half` в пределах `GRID_STEP_N*0.02`) — `eligible` истинен для обоих. Фикстура реальна. - `scripts/config-field-registry.mjs:291–303` (запись `spaces[].openings[].host=wall`) — текст `default`/`migration`, процитированный в §5.1 ТЗ, совпадает с файлом дословно. - `docs/CONFIG-COMPATIBILITY.md` — прочитан целиком (`§Stable wall identity`, `§Canonical zero-thickness walls — model v9 (#306)`, `§Independent-wall opening host (#132)`) для проверки, на какой именно абзац ссылается новый пункт §5.1 ТЗ — см. находку M3 ниже. - `demo/golden/harness.mjs` (`coincidentPartition` фикстура, строки ~85–112) и `demo/golden/matrix.mjs:169–186` (`coincident-partition-virtual-dark`) и `demo/golden/baselines/baselines-index.json:13` — проверка claim'а §5.3 «существующие сцены... в них нет комбинации span+проём» — см. находку M4 ниже. - `docs/specs/316-opening-host-auto-resolution.md` §5.2 (i18n) — сверено с r1 «Как проверялось» п.7 (ключи `toast.zero_wall_migration_blocked`, `wall_model.reason.opening-host` в `src/i18n/{ru,en}.json` не тронуты) — наследуется, дельта i18n-ключей не касается. 4. AC1, AC2, AC4–AC6 дельтой не задеты (текст не менялся) — не перепроверялись повторно, унаследованы из r1 (см. раздел ниже). AC3 изменился текстуально — перепроверен полностью (см. п.3 выше). 5. `grep -n "инертн" docs/specs/316-opening-host-auto-resolution.md` — пусто, термин заменён везде, коллизии с `docs/UX-MODES.md`/`smoke_inert_openings.mjs` больше нет. Гейты `typecheck`/`test`/`build`/`check-docs` не прогонялись: диапазон изменений — `docs/specs/316-*.md` (плюс сам документ ревью r1, тоже документация), продуктового кода нет, класс C. Это не пропуск гейта — как и в r1, гейтов для класса C на стадии ТЗ не предусмотрено. ## Закрытие раунда r1 | Находка r1 | Чем закрыта | Где видно | |---|---|---| | M1 / i18n не назван | Явный раздел «Без изменений», с именами обоих ключей и обоснованием (fail-closed путь §2 остаётся) | §5.2, строки 123–127 | | M1 / release-артефакты не названы | Раздел с CHANGELOG RU+EN, требованием новой golden-сцены и обязательством `golden:verify`, явный «без правок» для USER-GUIDE | §5.3, строки 129–137 | | M1 / затронутые файлы/модули не перечислены | Список из 7 файлов/поверхностей с указанием, что именно меняется в каждом | §5.1, строки 100–121 | | M1 / perf и touch не названы | Явные абзацы «нет» с обоснованием (одна доп. проходка O(atoms×openings) вне рендера; миграция — не жест) | §5.4, строки 139–144 | | M1 / `docs/CONFIG-COMPATIBILITY.md` не упомянут | Пункт с планом правки реестра и документа | §5.1, строки 109–118 — **но см. новую находку M3**: указан не тот абзац `docs/CONFIG-COMPATIBILITY.md` | | M1 / нет раздела «принято предположительно» | Новый раздел с 3 пунктами (tie-break, семантика деградации 3.3, имя состояния) | §6, строки 146–153 | | M2 / AC3 недостижимая фикстура | Фикстура заменена на стык двух контурных атомов одной стены на границе толщины — проверено реальным код-путём (см. «Как проверялось» п.3) | AC3, строки 84–88 | | L1 / коллизия термина «инертный» | Термин заменён на «непривязанный (unhosted)» везде, включая §3.3 и §7 «Риски» | grep по документу — 0 совпадений | Все находки r1 закрыты по существу, не декларативно. Дополнительно к закрытию M1 автор сам заметил и исправил нумерацию разделов (5→7 «Риски», 6→8 «Откат») — корректно, ссылок на старые номера в остальном тексте нет. ## Унаследовано из r1 Без повторной проверки приняты выводы `docs/reviews/SPEC-REVIEW-316-r1.md` (SHA `36f735ae`) по частям документа, которые дельта r2 не затронула: - §1 «Сценарий» и §2 «Границы» — не изменились; цепочка причин и сверка с #306 §8.2 приняты как проверенные в r1. - Правило 3.1 (проём удерживает стену) — текст не менялся; заимствование критерия `eligible()` и обоснование physического смысла приняты из r1. - Правило 3.3 нормативная часть (кроме переименования термина) — рендер по x/y для безхостовых проёмов, подтверждённый в r1 чтением `space-render.ts:285` и `plan-geometry-preflight.ts:224/276`, принят без повторного чтения кода. - AC1, AC2, AC4, AC5, AC6 — текст не менялся, приняты как «сформулированы однозначно, со способом доказательства» из вывода r1. - Откат (текст §8, бывший §6) — не менялся, принят как «конкретен и проверяем» из r1. ## Находки Обе находки этого раунда — новые: они возникли из текста, добавленного в r2 при закрытии M1, а не из чего-то, что r1 пропустил. ### M3 (Medium, в скоупе) — §5.1 указывает не тот абзац `docs/CONFIG-COMPATIBILITY.md` ТЗ (строки 115–118): «`docs/CONFIG-COMPATIBILITY.md` — новый подраздел о непривязанном контурном проёме... прежний абзац «missing/invalid host … fail dark» уточняется ссылкой». Проверено чтением `docs/CONFIG-COMPATIBILITY.md` целиком: фраза «A missing/invalid host is not re-associated automatically: current renderers fail dark» (строки 201–202) находится в разделе **«Independent-wall opening host (#132)»** (строки 188–222) — этот раздел целиком про `host.kind === 'partition'` (независимая кладка/партиции), код-путь, который #316 прямо не затрагивает: `resolveRoomOpeningHost` (строка 591) и `hostRoomOpenings` (строка 620) явно пропускают `opening.host?.kind === 'partition'` — это тот же факт, которым сам автор обосновал замену фикстуры AC3 (M2 r1). Абзац, который #316 действительно делает неточным, — в разделе **«Canonical zero-thickness walls — model v9 (#306)»** (строки 81–100), конкретно строка 94: «...verifies that no opening would acquire a zero host, and then removes both legacy fields in one transaction. A conflict rejects the complete candidate» — это прямое описание текущего fail-closed поведения, которое §3.1–3.4 заменяют на детерминированное авто-разрешение. Именно этот абзац перестаёт быть верным после реализации #316, и именно его, а не абзац про партиции, нужно уточнить в том же коммите, что и код (правило 11 PROCESS.md). **Чем грозит, если не поправить:** автор реализации, следуя ТЗ буквально, отредактирует раздел #132 (независимые стены — не тот код-путь) и оставит нетронутым реально устаревающий абзац раздела #306/v9 — формальное соответствие «документация в том же коммите» будет выполнено, а по факту контракт-документ останется противоречить новому поведению. **Почему Medium, а не High:** ошибка ссылки, а не решения — нормативные правила §3 не затронуты, откат/AC не сломаны, правится одной строкой (замена цитаты и номера раздела) без пересмотра §3. ### M4 (Medium, в скоупе) — §5.3 неточно утверждает отсутствие span+проём в существующих golden-сценах ТЗ (строки 132–135): «существующие сцены не должны измениться (в них нет комбинации span+проём) — verify обязан подтвердить». Проверено чтением `demo/golden/harness.mjs` (ветка `coincidentPartition`, `state === 'virtual'`) и `demo/golden/matrix.mjs:186` (`coincident-partition-virtual-dark`): фикстура явно строит `open_spans` поверх позиции, где стоит `space.openings[0]` (с удалённым `host`, `x:0.504166667, y:0.5`, `open_spans[0].a/b` — тот же `x`). Сцена присутствует в принятой матрице (`baselines-index.json:13`, `demo/golden/baselines/coincident-partition-virtual-dark.png`) — то есть комбинация «open_span + проём в той же позиции» в текущих golden-сценах **есть**, вопреки формулировке ТЗ. Не берусь утверждать, что рендер этой сцены изменится: `coincidentPartition` тестирует независимую кладку (партиции), а не контурные атомы комнаты — не исключено, что правило 3.1 (единственное, что меняет видимую геометрию) на эту сцену не влияет ровно по той же причине, что и в M2/M3 (независимая кладка вне `resolveRoomOpeningHost`/`buildAtoms` контурных атомов). Находка не в этом: **ТЗ формулирует как факт то, что не проверено и, как минимум по одному конкретному контрпримеру, неточно** — это ровно то, что процесс требует помечать как предположение, а не утверждение (см. вводный промпт: «утверждение о поведении, которого нет ни в одном документе... и не помечено как предположение — замечание»). **Практическое смягчение:** тот же абзац уже требует `golden:verify` на стадии кода, так что расхождение будет поймано автоматически независимо от точности claim'а — риска тихой регрессии нет. Находка — про точность ТЗ как источника для код-ревью следующего этапа (код-ревью #316 будет читать именно эту фразу, чтобы решить, какие сцены смотреть предметно, а не только доверять `golden:verify`). **Почему Medium, а не Low:** ТЗ прямо ссылается на конкретный (неверный) факт, а не на общую оценку риска; чинится заменой формулировки на честную («есть минимум одна существующая сцена с похожей комбинацией — `coincident-partition-virtual-dark`; ожидание — без изменений, т.к. это независимая кладка вне контурных атомов §3.1; `golden:verify` обязателен и для неё»), без пересмотра §3. ## Что проверено и корректно - Все восемь пунктов M1 (i18n, release-артефакты, затронутые файлы, perf/touch, ссылка на `docs/CONFIG-COMPATIBILITY.md` по факту наличия, раздел «принято предположительно») закрыты по существу — см. таблицу «Закрытие раунда r1». - Новая фикстура AC3 — реально достижима внутри `resolveRoomOpeningHost`, подтверждено чтением `atomicPolyForRoom` и существующего смока `smoke_wall_thickness_transition.mjs`, использующего тот же механизм разрыва атома на границе толщины (M2 закрыта корректно). - Термин «инертный» полностью заменён на «непривязанный (unhosted)» — новых коллизий с `docs/UX-MODES.md` не создано (L1 закрыта). - Текст `scripts/config-field-registry.mjs`, процитированный в §5.1, дословно совпадает с файлом на HEAD. - Раздел «Принято предположительно» (§6) корректно отделяет непродуктовые технические решения автора от нормативных правил §3 — не создаёт новых открытых продуктовых вопросов владельцу. - Перенумерация разделов (5→7, 6→8) внутренне согласована, висячих ссылок на старые номера не осталось. ## Чего не проверял - Не перепроверял AC1, AC2, AC4–AC6 и правила 3.1/3.3 (нормативная часть) по коду заново — текст не менялся дельтой r2, наследуется из r1 (см. «Унаследовано из r1»). - Не прогонял гейты typecheck/test/build/check-docs/смоки/golden — класс C, продуктового кода ещё нет, как и в r1. - Не проверял #319 — вне скоупа, как и в r1. - Не проверял осуществимость `atomicPolyForRoom`-механизма для реализации правил 3.1–3.3 в целом (только для новой фикстуры AC3, точечно) — общая реализуемость остаётся задачей код-ревью, не ТЗ-ревью. - Не проверял остальные golden-сцены на предмет других возможных span+проём комбинаций сверх найденной `coincident-partition-virtual-dark` — одного контрпримера достаточно, чтобы находка M4 была обоснована; исчерпывающий список сцен для реальной проверки — задача `golden:verify` на стадии кода, не ТЗ-ревью. ## Вывод High-находок нет. M3 и M4 — в скоупе задачи, новые в этом раунде (не пропуски r1), чинятся точечной правкой формулировок в §5.1/§5.3 без пересмотра нормативных правил §3 и без изменения AC. Вердикт — жёлтый, документ возвращается автору на ревизию 3.