houseplan-card/docs/reviews/SPEC-REVIEW-306-r2.md

SPEC-REVIEW-306-r4

• Issue: #306 — Редактор плана: заменить виртуальные стены обычными стенами толщиной 0
• Этап: ревью ТЗ (PROCESS.md §2.4, повторный раунд — §2.10)
• Заход: r4 · блокирующих циклов израсходовано (до этого вердикта) 2 из 4
• ТЗ: docs/specs/306-zero-thickness-walls.md, HEAD ветки issue/306-zero-thickness-walls = 3d7395abc354b072d4ed8ae48809972509dde41 («docs: align zero-wall spec limits»)
• Метка issue: S4-spec-review (полный трек, не small/trivial)

Расхождение метаданных запуска с фактическим состоянием issue (процессная находка, не по ТЗ)

Входные метаданные этого запуска указывали «Заход: r2 · блокирующих циклов израсходовано 1 из 4». Это не совпадает с состоянием GitHub — тот же класс расхождения, который уже фиксировали SPEC-REVIEW-306-r2.md и SPEC-REVIEW-306-r3.md для своих запусков:

• r1 (904c47e4) — жёлтый, High 0, Medium 3 (2026-08-25T16:49:42Z) — 1 цикл;
• r2 (2c801bf5) — зелёный, High 0, Medium 0 (2026-08-25T16:57:24Z) — цикл не тратит;
• r3 (SHA на момент ревью не разрешается локально: документ r3 называет abbd4904, этот коммит недостижим в текущей истории — по датам и содержимому (то же сообщение «docs: adapt zero-wall spec to model v8», 2026-08-26T07:21:56+03:00) это переписанный при rebase-на-dev эквивалент коммита 9283d2ee; между r2 и r3 в лог влиты посторонние коммиты dev, например 93054823, что и есть след rebase) — жёлтый, High 0, Medium 1 (M1: устаревший лимит 500 вместо MAX_WALL_SEGMENTS=200000), 2026-08-26T07:31:54Z — 2-й цикл;
• автор исправил M1 в 3d7395ab («docs: align zero-wall spec limits», 2026-08-26T07:33:20+03:00) и передал «на финальный spec-review r4/4» (2026-08-26T07:33:36Z).

Провожу разбор как r4 по фактическому состоянию GitHub, а не как r2. Это находка процесса запуска ревью, а не находка по содержанию ТЗ #306 — отдельный issue не заводится (параметр одного прогона, не продуктовый дефект, прецедент — сам этот issue в r2/r3).

Скоуп этого раунда

Дельта между содержимым, разобранным в r3 (эквивалент 9283d2ee), и текущим HEAD (3d7395ab):

git diff 9283d2ee..3d7395ab -- docs/specs/306-zero-thickness-walls.md

даёт 11 изменённых строк в трёх местах документа (§10 шаг 10, §13, §17 AC13) — ровно та правка, которую предписал вердикт r3 для закрытия M1. Правка не меняет ни одного контракта поведения, не задевает новую подсистему и не сопоставима по объёму с исходной задачей — это учебный пример локальной дельты по критерию §2.10. Разбор по дельте: заново проверено только M1 и AC13/§10/§13, чьё доказательство эта правка задевает; остальное — раздел «Унаследовано».

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

• git diff 9283d2ee..3d7395ab -- docs/specs/306-zero-thickness-walls.md — единственный источник дельты, прочитан целиком построчно;
• grep -n '\b500\b' docs/specs/306-zero-thickness-walls.md — пусто: устаревшая цифра из трёх мест M1 (§10 п.10, §13, §17 AC13) удалена полностью, замена на `MAX_WALL_SEGMENTS` (сейчас 200 000) / «любого другого актуального backend-лимита»;
• custom_components/houseplan/validation.py:1047-1048 — MAX_WALLS = MAX_WALL_SEGMENTS = 200_000 подтверждено текущим кодом (та же строка, что и в r3, повторно проверена — правка ссылается на реальную константу, не на новую догадку); :1056 MAX_OPEN_SPANS = 500 — как и в r3, это предел удаляемого поля, не итогового каталога, ТЗ его не использует;
• §20 «Риски и защита» (строка «Atomization превысит лимит» → «atomic failure, no truncation») уже была сформулирована без конкретной цифры — делта её не касалась, четвёртое место M1 не требовало правки;
• node --test test/docs-accept.test.mjs test/process-gate.test.mjs — 41 passed, 0 failed, 0 skipped (Linux; автор указывал 40 passed + 1 ожидаемый Windows-skip — расхождение по площадке, не по существу);
• секции 1 «Сценарий» и 2 «Что человек увидит до и после» (закрытие M1 r1) и ссылка на docs/SCOPE.md J4/J6 перечитаны на текущем HEAD (строки 9-26) — дельта их не касалась, текст не откатился;
• docs/SCOPE.md — J4/J6 существуют в документе (grep -n "J4\|J6"), утверждение §1 не голословно.

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

Находка r3	Чем закрыта	Где видно
M1 (Medium, в скоупе) — лимит wall_segments[] в ТЗ назван устаревшим числом 500 в трёх местах (§10 п.10, §13, §17 AC13), противоречит уже слитому #282 (MAX_WALL_SEGMENTS=200_000)	Все три места переписаны на именованную константу/обобщённую формулировку без хардкода цифры	docs/specs/306-zero-thickness-walls.md:351-353 («При превышении MAX_WALL_SEGMENTS (сейчас 200 000) или любого другого актуального backend-лимита отказать целиком»), :423-424 («Лимит authoritative-каталога остаётся равен backend-константе MAX_WALL_SEGMENTS (сейчас 200 000)»), :605-606 AC13 («Превышение любого актуального backend-лимита… отклоняет весь candidate без truncation/partial apply») — коммит 3d7395ab
Low, снято с записью r1/r3 (нет единого консолидированного блока предположений)	Не переоткрывается — r1 и r3 уже признали формат достаточным при отсутствии открытых продуктовых вопросов	без изменений в этом раунде

Других находок r3 не было (High 0, Medium 1 — только M1).

Унаследовано из r1/r2/r3

Без повторной проверки по существу в этом раунде — дельта 9283d2ee..3d7395ab их не касается ни текстуально, ни по содержанию:

• продуктовые решения владельца по световому режиму (таблица dashed/solid, запрет фиктивной толщины, единый resolver для Glow и солнца, инвалидация кэшей при переключении, RU/EN copy под селектором) — проверены в SPEC-REVIEW-306-r1.md/r2.md/r3.md на SHA 904c47e4/2c801bf5/ эквиваленте 9283d2ee; §4 п.4-7, §9.1, §15 текущего файла не менялись;
• соответствие docs/SCOPE.md (J4/J6) и отсутствие конфликта с out-of-scope — §1, §21 не в дельте;
• присутствие docs/USER-GUIDE.ru.md в §16/§19 (закрытие M2 r1) — строки 484, 683 текущей ревизии, не в дельте;
• статусы compatibility-реестра deprecated-read/migrate-on-write (закрытие M3 r1) — §6.2, строки ~172-175, проверены в r3 прямым обращением к scripts/config-field-registry.mjs/docs/CONFIG-COMPATIBILITY.md, не в дельте r3→r4;
• целевая модель v8→v9 на authoritative wall_segments[], stable ID/lineage #282, backend-диапазоны cm для wall_segments/room_drafts/partitions/ wall_columns — проверены в r3 по коду (validation.py), эта дельта их не меняет;
• AC1, AC2, AC3, AC4, AC5, AC6, AC7, AC8, AC9, AC10, AC11, AC12, AC14, AC15, AC16, AC18 — не в дельте, наследуются из r3 без повторного разбора;
• i18n-таблица §15, touch/accessibility §14 — не в дельте;
• release-артефакты §19 (оба changelog, оба user-guide, канонические документы подсистем) — не в дельте.

AC13 и связанный текст §10 п.10, §13 — единственные места, разобранные заново в этом раунде (см. «Как проверялось» и таблицу закрытия выше); AC17 (перф-бюджеты) перечитан целиком заново, так как его формулировка находится в §13, но сам перф-контракт (fingerprint, отсутствие rebuild на HA tick, benchmark-пороги) не изменился словом — дельта тронула только соседнюю строку про лимит записей.

Находки

Нет. High: 0, Medium: 0.

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

• M1 закрыт по существу, не декларативно: три из трёх мест исправлены идентичной по смыслу формулировкой, привязанной к реальной именованной константе, а не к новому хардкоду; четвёртое упомянутое в r3 место (§20) не требовало правки, так как не содержало числа;
• исправление не создало нового технического долга: вместо конкретной цифры документ теперь ссылается на «текущий backend-лимит» — формулировка переживёт будущее изменение константы без повторного устаревания;
• docs/process gate зелёный (node --test test/docs-accept.test.mjs test/process-gate.test.mjs — 41/41);
• секции 1-2 (§7.1), ссылка на docs/SCOPE.md, i18n, touch, release-артефакты не откатились и не пострадали от точечной правки — дельта минимальна и не затронула соседний текст.

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

• Не перепроверял AC1-AC12, AC14-AC18 по существу заново — они не в дельте r3→r4 и не зависят от лимита wall_segments[]; их закрытие наследуется из r3 (см. раздел «Унаследовано»);
• не прогонялись npm run typecheck/npm test/npm run build, browser-смоки, golden, python -m pytest tests_backend — на этапе ревью ТЗ src не менялся ни в этой дельте, ни в дельте r3→r4; это гейты код-ревью (PROCESS.md §2.7, §8), здесь неприменимы;
• не проверял заново реестр docs/CONFIG-COMPATIBILITY.md/ scripts/config-field-registry.mjs — сделано в r3, дельта их не касается;
• не восстанавливал точную историю rebase (abbd4904 → 9283d2ee) коммит-за-коммитом — установил только, что это тот же контент по времени, сообщению коммита и последующему diff; для целей этого ревью достаточно, что дельта М1 считается от контента, который r3 реально видел.

Вердикт

M1 закрыт по существу на всех трёх упомянутых местах, новых находок дельта не создала. High: 0, Medium: 0 — зелёный.

Вердикт: зелёный · заход r4 · блокирующих циклов 2/4 · High: 0 · Medium: 0 → в задаче