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

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.