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

SPEC-REVIEW-288-r2

• Issue: https://github.com/Matysh/houseplan-card/issues/288
• Этап: spec (PROCESS.md §2.4)
• Заход: r2 · блокирующих циклов израсходовано 1 из 4 (r1 был жёлтым и потратил 1 цикл; зелёный вердикт цикла не образует, #227)
• Документ ТЗ: docs/specs/288-bounded-multiwall-corridor.md
• SHA r1 (найден в документе r1, не в комментарии-вердикте): cb0f9e7351e919701666dfd05b53f0e218e672a5
• SHA r2 (текущий HEAD, дельта этого раунда): fba615e9f6ec8841c6e6e0f9a7cc5fe0d1fc7c25
• Разбор — по дельте (PROCESS.md §2.10): единственный коммит между SHA r1 и HEAD — fba615e9 docs: add risks and rollback to junction spec (docs/specs/288-bounded-multiwall-corridor.md, +21/-4 строк). Дельта локальна: только текст, только два новых раздела плюс одна строка в шапке; не задета ни одна формулировка сценария, контракта, scope или AC. Условия «разбор остаётся полным» (ребейз на ушедший вперёд dev, смена контракта поведения, новая подсистема, объём дельты сопоставим с исходной задачей) не выполнено ни одно — исходное ТЗ 208 строк, дельта 25 строк правки двух разделов. Полный повторный разбор не требуется.

Дельта (что менялось)

git diff cb0f9e73..fba615e9 -- docs/specs/288-bounded-multiwall-corridor.md

• добавлен раздел «7. Риски и меры» (3 пункта: регрессия семи прежних junction-контрактов → мера AC4/оба плана/golden; над-/недосечение соседней стены → мера AC3/AC5/AC7; расхождение polygon между Plan/View/Static/Iso → мера AC5 + запрет consumer-specific post-fix);
• добавлен раздел «8. Откат» (один абзац: чистый revert, флаг/миграция не нужны, т.к. persisted model не меняется);
• последующие разделы («Ожидаемые файлы», «Release…», «Принятые технические предположения») перенумерованы 7→9, 8→10, 9→11 без потери и без дублей (проверено grep -n "^## " по всему файлу — последовательность 1…11 без пропусков);
• в шапку «Связано» добавлен #279.

Коммит несёт корректные трейлеры: Issue: #288, User-Visible: no (класс C, поведение не меняется).

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

Находка r1	Чем закрыта	Где это видно
M1 (Medium, в скоупе) — отсутствуют обязательные разделы «Риски» и «Откат» (§7.1, DoR §2.5)	Добавлены разделы «7. Риски и меры» (3 пункта с мерами, привязанными к AC3/AC4/AC5/AC7) и «8. Откат» (чистый revert, без флага/миграции)	docs/specs/288-bounded-multiwall-corridor.md:170-185, коммит fba615e9
L1 (Low) — «Связано» не включает #279, хотя AC4 на него ссылается	#279 добавлен в строку «Связано»	docs/specs/288-bounded-multiwall-corridor.md:11, коммит fba615e9

Оба пункта закрыты содержательно, а не формальным упоминанием слова: риск 1 прямо называет затронутый общий код (bevelMultiWallBody) и все семь прежних контрактов по номерам, риск 2 и 3 — конкретные меры отказа (перекрытие, недосечение, рассинхронизация consumers) с привязкой к конкретным AC, а не общими словами. Формулировки рисков корректно хеджированы («может вернуть», «может разойтись») — это анализ риска, а не факт о поведении, выданный без основания. Откат сформулирован как утверждение и совпадает с уже зафиксированным в шапке фактом «persisted model не меняется» — не новое недоказанное утверждение, а следствие уже принятого в r1 факта.

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

Всё, что не затронуто дельтой, принимается без повторной проверки по документу docs/reviews/SPEC-REVIEW-288-r1.md (SHA cb0f9e7351e919701666dfd05b53f0e218e672a5):

• диагноз причины (узел 577,299, лучи 349/120/5 шагов, толщины 30/30/30 см, соседняя стена 20 см, радиус 4×15=60, вырез 60−15=45) — сверен ревьюером r1 с телом issue буквально;
• существование и корректность использования идентификаторов контракта (MITRE_LIMIT, MultiWallNodeRay.supports/halfDepth) в src/wall-thickness.ts — проверено чтением кода в r1, дельта этого файла не касается;
• привязка AC1/AC2 к существующему demo/smoke_real_plan_masonry.mjs и корректность его логики подсчёта разрывов — не менялась;
• table-driven конструкция AC3 как независимая от AC1 unit-гарантия — текст AC3 не тронут дельтой;
• список регрессионных контрактов AC4 (#249/#261/#271/#272/#275/#278/#279), сверенный с docs/WALL-THICKNESS.md, — текст AC4 не тронут; #279 добавлен только в шапку «Связано», в самом AC4 он уже присутствовал в r1; сверено git diff cb0f9e73..HEAD -- docs/specs/288-bounded-multiwall-corridor.md — раздел AC (строки 98–156 текущего файла) в дельте не участвует; мутационное требование AC7 — не менялось;
• корректность Scope/«Не входит» (исключение #289/#290 и глобальных констант) — не менялось; «Принятые технические предположения» — не менялись по содержанию, только перенумерованы (9→11);
• отсутствие продуктовых вопросов, требующих участия владельца, — не менялось; новый текст рисков и отката тоже не содержит продуктовой развилки, ниже проверено отдельно.
• совместимость/touch/performance (раздел 6) — не менялась.

Что проверено заново в этом раунде

• Полный просмотр итогового файла (docs/specs/288-bounded-multiwall-corridor.md, 226 строк) для проверки целостности нумерации разделов и отсутствия висячих перекрёстных ссылок на старые номера — ссылок по номеру раздела в тексте документа нет вообще (grep -n "раздел\|§[0-9]" — 0 совпадений), поэтому перенумерация 7→9/8→10/9→11 безопасна.
• Содержательность нового раздела «Риски и меры»: каждый из трёх пунктов называет конкретный failure mode и конкретную меру, привязанную к проверяемому AC, а не общую фразу «будем осторожны». Прецедентная сверка формы с docs/specs/275-multiwall-strip-containment.md и docs/specs/278-wall-union-isolation.md (использовались как эталон в r1) показывает сопоставимую структуру: конкретный риск → конкретная мера.
• Раздел «Откат»: соответствует требованию DoR §2.5 «откат: как выключить или вернуть назад» — здесь ответ «чистый revert» обоснован отсутствием изменений модели данных, что само по себе уже было зафиксировано в шапке ТЗ («Модель данных: schema, config, layout и Optimize не меняются») и в r1 это не оспаривалось.
• Продуктовая рамка не пересматривалась целиком (не требуется по §2.10, дельта не продуктовая), но точечно проверено: новые два раздела не вводят решения, которое следовало бы адресовать владельцу (нет пограничного случая, нет конфликта персон, нет вопроса об объёме видимых изменений) — оба раздела чисто технические, что соответствует их месту в документе (после AC, до release-раздела).
• Трейлеры коммита fba615e9: Issue: #288, User-Visible: no — корректно для документации класса C без изменения поведения.

Гейты

Этап — spec, продуктовый код не менялся (diff ограничен docs/specs/288-*.md, класс C). Как и в r1, гейты §8 (typecheck/test/build/check-docs/ smoke/invariants/golden) к этапу spec-review не относятся и не запускались — это гейты этапа code-review (§2.7), где эта задача окажется позже. Дельта этого раунда тем более не продуктовая (только текст ТЗ), так что необходимость их прогона не возникла и по факту дельты.

Находки

Нет. High: 0, Medium: 0, Low: 0. Обе находки r1 закрыты содержательно (см. таблицу выше), новых находок дельта не порождает.

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

• Повторно не проверял идентичность кода src/wall-thickness.ts контракту §3.1 — код не менялся с r1, наследуется.
• Не запускал demo/smoke_real_plan_masonry.mjs и npm run invariants — реализации ещё нет, как и в r1; вопрос сохраняется до code-review.
• Не проверял golden baseline — как и в r1, AC6 описывает будущую работу.

Вердикт

Вердикт: зелёный · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 0
Документ: docs/reviews/SPEC-REVIEW-288-r2.md