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

SPEC-REVIEW-316-r4

Issue: #316 · ТЗ: docs/specs/316-opening-host-auto-resolution.md · заход: r4 · блокирующих циклов израсходовано 3 из 4 (входящее значение, до этого вердикта) · SHA материала ревью r4: bb051741 (docs: spec #316 revision 4 — the golden expectation rests on the render/write boundary, not on masonry kind). Материал r3: SHA 56ffbfac, документ docs/reviews/SPEC-REVIEW-316-r3.md. Материал r2: SHA 6ca2ce8b, документ docs/reviews/SPEC-REVIEW-316-r2.md. Материал r1: SHA 36f735ae, документ docs/reviews/SPEC-REVIEW-316-r1.md.

Скоуп раунда

Разбор — по дельте (PROCESS.md §2.9/§2.10): git diff 56ffbfac..bb051741 -- docs/specs/316-opening-host-auto-resolution.md. Дельта — 10 строк (5 добавлено / 3 удалено по факту, с учётом переноса), целиком внутри §5.3 (обоснование ожидания «без изменений» для golden-сцены coincident-partition-virtual-dark) плюс однострочная правка статус-строки в шапке. Это прямой точечный ответ на M5 ревью r3 — единственную находку предыдущего раунда. Нормативные правила §3, AC1–AC6, границы §2, §5.1 (compatibility), §5.2 (i18n), §5.4 (perf/touch), §6–§8 не тронуты.

Полный diff между r3 и r4 (git diff 56ffbfac..bb051741 --stat) состоит из двух файлов: правки ТЗ (10 строк) и появления в дереве документа docs/reviews/SPEC-REVIEW-316-r3.md (публикация предыдущего ревью) — второй файл к предмету этого раунда не относится.

Оснований для полного разбора (ребейз, смена контракта, новая подсистема, объём дельты сопоставим с задачей) нет: дельта меньше исходной задачи и локальна к одному абзацу.

Комментарии issue #316 проверены полностью (gh issue view 316 --comments): после вердикта r3 (2026-08-26T18:13:20Z) единственный новый комментарий — «Ревизия 4 (bb051741)» автора, описывающий исключительно правку M5. Новых продуктовых директив владельца не появилось.

Как проверялось

1. Найден вердикт r3 в комментариях issue (2026-08-26T18:13:20Z) и SHA материала (56ffbfac, назван в документе r3).
2. git diff 56ffbfac..bb051741 -- docs/specs/316-opening-host-auto-resolution.md — построчная сверка дельты с текстом находки M5 и с предложенной в r3 формулировкой «как починить».
3. M5 (обоснование ожидания «без изменений» в §5.3). Новый текст: «Ожидание «без изменений» держится не на природе кладки (после очистки host проём обрабатывался бы миграцией как контурный — тем же путём, что правило 3.1), а на границе §2: сцена рендерится в mode: 'view' без структурной записи, commitWallSegmentModel из чистого рендера не вызывается — правила §3 в ней не выполняются вовсе». Проверено заново по коду (не по заявлению автора):
   • src/houseplan-card.ts:197-200 — commitWallSegmentModel импортируется из wall-segment-model; вызовы — строки 7408, 7432, 7435, 7568, все внутри методов, обрабатывающих геометрический жест редактора (сохранение после _restoreGeometryStateInConfig/_geometrySnapshotFromConfig, ветки успеха/ошибки с _showWallModelMigrationBlocked). Пути от setConfig/чистого рендера, вызывающего commitWallSegmentModel, не найдено — подтверждает «из чистого рендера не вызывается».
   • demo/golden/matrix.mjs:185-187 — сцена coincident-partition-virtual-dark задана с mode: 'view', без dialog/editorTray/иного действия, запускающего структурную запись — подтверждает «сцена рендерится в mode: 'view' без структурной записи».
   • Ранее проверенный (r3, не переоткрывается) факт «после delete opening.host проём обрабатывался бы как контурный» сохранён в новом тексте как параллельное обоснование в скобках, само по себе оно теперь явно не несёт вес вывода «без изменений» — вес несёт граница §2. Формулировка больше не переворачивает факт (в отличие от текста r3), и не отрицает его: обе стороны утверждения теперь совместимы.
4. Правка соответствует ровно тому, что r3 назвал в разделе «Как починить» (docs/reviews/SPEC-REVIEW-316-r3.md, строки 170–174): «сцена рендерится в mode: 'view' без структурного редактирования — §3 применяется только к initial migration (§2), а презентационный рендер её не запускает» — совпадает по существу; автор сохранил также верное техническое уточнение из своей же r3-формулировки (контурная обработка после очистки host), переведя его из основания вывода в параллельное замечание — это усиливает точность, не ослабляет её.
5. AC1–AC6, правила 3.1–3.4, §1, §2, §4, §5.1, §5.2, §5.4, §6–§8 дельтой не задеты (текст не менялся) — не перепроверялись повторно, унаследованы из r1/r2/r3 (см. раздел ниже).

Гейты typecheck/test/build/check-docs не прогонялись: диапазон изменений — только docs/specs/316-*.md, продуктового кода нет, класс C. Как и в r1–r3, гейтов для класса C на стадии ТЗ не предусмотрено.

Закрытие раунда r3

Находка r3	Чем закрыта	Где видно
M5 / §5.3 обосновывает «без изменений» неточным «независимая кладка вне контурных атомов»	Обоснование заменено на границу §2 (mode: 'view', commitWallSegmentModel не вызывается из чистого рендера); неверный переворот факта устранён, техническое уточнение про контурную обработку после очистки host сохранено как параллельное замечание, не как основание вывода	docs/specs/316-opening-host-auto-resolution.md, §5.3, строки 138–147; подтверждено чтением src/houseplan-card.ts:197-200,7405-7568 и demo/golden/matrix.mjs:185-187 (см. «Как проверялось» п.3)

M5 закрыта полностью, без оговорок: новый текст верен и по факту (проверено кодом заново), и по логике вывода (граница §2, а не природа кладки, несёт обоснование ожидания).

Унаследовано из r3 (через r2, r1)

Без повторной проверки приняты выводы docs/reviews/SPEC-REVIEW-316-r3.md (SHA 56ffbfac) и транзитивно docs/reviews/SPEC-REVIEW-316-r2.md (SHA 6ca2ce8b), docs/reviews/SPEC-REVIEW-316-r1.md (SHA 36f735ae) по частям документа, которые дельта r4 не затронула:

• §1 «Сценарий», §2 «Границы» — не изменились с r1; цепочка причин, сверка с #306 §8.2, правило «Правила §3 действуют только при initial migration» приняты как проверенные в r1.
• §3 Правила 3.1–3.4 — текст не менялся с r1; заимствование критерия eligible(), обоснование физического смысла 3.1, tie-break 3.2, рендер по x/y для безхостовых проёмов 3.3 — приняты из r1/r2 без повторного чтения кода.
• AC1–AC6 — текст не менялся с r1 (кроме фикстуры AC3, переписанной и подтверждённой в r2) — приняты как «сформулированы однозначно, со способом доказательства».
• §5.1 — весь раздел, включая перечень файлов (закрытие M1 r1) и ссылку на docs/CONFIG-COMPATIBILITY.md (закрытие M3 r2, проверено дословной сверкой цитаты в r3) — не менялся дельтой r4, принят без повторного чтения.
• §5.2 (i18n), §5.4 (perf/touch), §6 «Принято предположительно», §7 «Риски», §8 «Откат» — не менялись с r2, приняты без повторной проверки.
• §5.3 — факт существования сцены coincident-partition-virtual-dark с комбинацией span+проём (закрытие исходной M4 r2) — не переоткрывался в этом раунде; проверялось только обоснование ожидания «без изменений» (M5), см. выше.
• Термин «непривязанный (unhosted)» — не менялся с r1, коллизия с docs/UX-MODES.md закрыта в r1/r2, повторно не проверялась.

Находки

Нет. Дельта r4 — точечная и корректная правка единственной находки предыдущего раунда; новых утверждений, выходящих за рамки предложенного в r3 исправления, текст не вводит.

Что проверено и корректно

• M5 закрыта полностью и точно: обоснование ожидания «без изменений» для coincident-partition-virtual-dark теперь опирается на верный факт (граница §2 — mode: 'view', commitWallSegmentModel не вызывается из презентационного рендера), а не на неверное обобщение о природе независимой кладки. Подтверждено чтением кода заново (не по заявлению автора): src/houseplan-card.ts (импорт и все вызовы commitWallSegmentModel), demo/golden/matrix.mjs (параметры сцены).
• Статус-строка в шапке документа корректно отражает историю раундов («r1: M1/M2/Low; r2: M3/M4; r3: M5»).
• Все находки r1 (M1, M2, Low «инертный»), r2 (M3, M4) и r3 (M5) закрыты по существу, каждая — со ссылкой на конкретную строку кода или текста, не на заявление автора.
• Открытых Medium/High-находок по ТЗ #316 не осталось. Обязательные разделы §7.1/DoR §2.5 присутствуют: сценарий, что человек увидит, проблема, скоуп и не-скоуп, контракт поведения, i18n, AC1–AC6 с доказательством, план автотестов (в AC), риски, откат, release-артефакты, блок «принято предположительно».

Чего не проверял

• Не перепроверял AC1–AC6 и правила 3.1–3.4 по коду заново — текст не менялся дельтой r4, наследуется из r1/r2/r3.
• Не прогонял гейты typecheck/test/build/check-docs/смоки/golden — класс C, продуктового кода ещё нет, как и в r1–r3. Это гейт этапа кода, не ТЗ.
• Не проверял #319 — вне скоупа, как и в предыдущих раундах.
• Не проверял остальные golden-сцены на предмет иных неточностей в §5.3 — не требуется: единственная находка предыдущего раунда была именно про эту сцену и именно про формулировку обоснования, она закрыта; полная проверка golden-матрицы — задача golden:verify на стадии кода.

Вывод

High-находок нет. Medium-находок нет: единственная находка r3 (M5) закрыта по существу и подтверждена повторным чтением кода. Зелёного вердикта требует и содержание (все обязательные разделы ТЗ на месте, AC однозначны и снабжены способом доказательства, технические решения автора помечены как предположения в §6), и процесс (§2.10 — дельта проверена, находка закрыта, унаследованные части перечислены). Вердикт — зелёный, ТЗ уходит в S5-ready.