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

# SPEC-REVIEW-329-r2

Issue: #329 · Этап: spec (S4-spec-review) · Заход: r2 · Трек: обычный ·
Блокирующих циклов израсходовано до этого раунда: 1/4

ТЗ: `docs/specs/329-junction-limits.md`.
Ревизия под ревью — коммит `783c04d1813b0b201efb21b8bae1b0c497978cf1`
(«docs: spec #329 revision 2 — per-surface refusal channels, AC5 split,
absolute thresholds»), базовый SHA раунда r1 — `8dce8453975121a89263d44243e49059f7000da7`.
Класс C (`docs/specs/**`), продуктовый код не тронут — `git show --stat 783c04d1`
подтверждает единственный файл в диффе.

## Скоуп ревью (по дельте, PROCESS.md §2.9)

Раунд не первый. Предыдущий вердикт — жёлтый, r1, найден в комментарии issue
`claude[bot]` от 2026-08-27T16:37:06Z, зафиксирован на SHA `8dce8453` (назван
в шапке `docs/reviews/SPEC-REVIEW-329-r1.md`, committed at `9f7d1fd4`). Автор
объявил делту в комментарии от 2026-08-27T16:39:52Z: «Ревизия 2 (783c04d1):
M1 — ..., M2 — ..., L1 — ...».

Дельта — `git diff 8dce8453..783c04d1 -- docs/specs/329-junction-limits.md`:
38 строк (29 добавлено, 9 удалено) внутри одного файла, только в §2
(нормативные ограничения/канал отказа) и §8 (AC5 → AC5a/AC5b). Остальной
документ (§1, §3 body, §4, §5, §6, §7, AC1–AC4, AC6, AC8–AC10, §9, §10, §11)
байт-не тронут diff'ом.

Делта локальна: это не ребейз на ушедший вперёд dev, не смена контракта
поведения продукта (та же формулировка решений владельца, что и в r1), не
задета новая подсистема. Полный разбор документа не требуется — разбираю
делту плюс всё, до чего она дотягивается логически (это как раз и вскрыло
находку ниже: обновлённое §2 разошлось с AC7, который delta не тронула).

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

- Прочитан диф `git diff 8dce8453..783c04d1` построчно — оба заявленных
  изменения (M1, M2) сверены с текстом находок r1 дословно; L1 тоже
  проверен, хотя автор не был обязан его чинить.
- Перечитан `docs/USER-GUIDE.ru.md`, раздел «Resize» (строки 473–493,
  таблица 477–484) и «Толщина стены» (515–528) — сверка новой формулировки
  канала §2 с уже задокументированным поведением инструментов.
- `git log --all --oneline | grep 313` + `git show 5e5dad27 --stat` —
  проверен прецедент #313, на который ссылается §2 для канала «Толщины»
  (commit message: «Ноль/пусто для независимой кладки отклоняется
  существующим тостом диапазона») — ссылка не выдумана, поведение реальное.
- Перепроверена математика AC5b: равносторонний треугольник, сторона `a`,
  inradius `r = a/(2√3)`. При `a=60`: `r≈17.32` см, полутолщина стены
  33/2=16.5 см → остаток `r-half≈0.82` см, внутренний треугольник (offset)
  имеет сторону `a·(r-half)/r ≈ 60·0.82/17.32 ≈ 2.84` см, площадь
  `(√3/4)·2.84²≈3.5` см² — меньше 25 см², П5 отказывает при выполненном П1
  (60°≥15°). При `a=120`: `r≈34.64` см, остаток `34.64-16.5=18.14` см,
  сторона внутреннего треугольника `≈120·18.14/34.64≈62.8` см, площадь
  `≈1706` см² — намного больше 25 см², проходит. Числа в AC5b (`17.3`,
  `34.6`, «<25 см²», «проходит») подтверждаются независимым пересчётом.
  Побочно проверено, что синтетика AC5b не задевает другие правила
  (П2: 2 стены/узел ≤6; П3: длина стороны 60/120 см ≥ толщины 33 см) — тест
  действительно изолирует П5 от остальных ограничений, как заявлено.
- Grep по `git show --stat` для `783c04d1` — подтверждено, что кроме
  `docs/specs/329-junction-limits.md` ничего не менялось: гейты кода
  (`tsc`/`test`/`build`/`check-docs`/инварианты/смоки) не относятся к
  чисто документационной ревизии на этапе spec, не прогонял — так же, как
  в r1.
- Перечитаны §3, §6, §7, §9 целиком (не только делта) — чтобы убедиться,
  что обновлённое §2 не противоречит соседним разделам, которые delta не
  трогала (см. находку ниже про AC7).

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

| Находка r1 | Чем закрыта | Где это видно |
|---|---|---|
| **M1** — единый «тост» заявлен как канал отказа для всех пяти поверхностей, включая Resize, что расходится с уже задокументированным контрактом ручек (USER-GUIDE, строки 482–483) | §2 переписан: явный список из трёх каналов по поверхностям — тост (рисование/черновики/независимые/merge-split), существующий контракт приглушённой ручки с объяснением по hover/focus/нажатию для Resize (тост явно исключён: «тост не используется»), тост-в-трее по образцу #313 для «Толщины». Формулировка Resize синтезирует уже документированные строки 482–484 USER-GUIDE (упор в последнюю допустимую позицию + приглушение с объяснением), не изобретает новый визуальный канал | `docs/specs/329-junction-limits.md` §2, строки 26–38 |
| **M2** — AC5 сливал повтор фикстуры issue (нарушает П1 напрямую, дублирует AC1) и непроверяемую гипотезу «П5 независим от П1» без конкретных чисел | AC5 разделён: AC5a — сквозной смок фикстуры issue поверх AC1 (честно назван дублирующим по цели, не по механике: unit vs smoke); AC5b — синтетика с названными числами (сторона 60 см / стены 33 см → отказ по П5 при выполненном П1; сторона 120 см → проходит). Числа проверены пересчётом выше — корректны | `docs/specs/329-junction-limits.md` §8, строки 129–136 |
| **L1** (Low, не обязана) — параллель «(1 клетка)» у абсолютных порогов П4/П5 могла увести к масштабированию на `cell_cm` | Скобки убраны, П4 и П5 явно помечены «порог абсолютный ... не зависит от `cell_cm`» | `docs/specs/329-junction-limits.md` §2, строки 49–50, 52–53 |

Все три находки закрыты по существу, не переформулированы уклончиво: M1 и M2
дают именно то, что просил r1 (раздельные каналы по поверхности; отдельная
синтетика с числами), а не косметическую перефразировку исходного текста.

## Находки (r2)

### r2-M1 (Medium, в скоупе) — AC7 не обновлён вместе с §2 и не проверяет заявленный канал отказа для Resize/«Толщины»

`docs/specs/329-junction-limits.md`, §8, AC7 (текст не менялся диффом
r1→r2):

> «AC7. Resize/«Толщина», приводящие к нарушению любого из П1–П5, — отказ
> fail-closed, план байт-неизменен.»

M1 в r1 требовал: «Явно расписать, какой канал обратной связи используется
на КАЖДОЙ из пяти поверхностей» — и отдельно указывал, что «AC7
(Resize/«Толщина») тоже не называет способ обратной связи ... что
расходится с общей формулировкой §2». Автор исправил §2 (теперь там
детальный, специфичный по каждой поверхности контракт — вплоть до
формулировки «текст объяснения называет нарушенное правило П1–П5» для
Resize и «причина показывается тостом с названием правила (П3/П5)» для
«Толщины»), но **AC7 остался прежним** и по-прежнему не тестирует канал —
только байт-неизменность плана. §6 (план тестов) тоже не называет
конкретный тест на текст ручки/тоста для этих двух поверхностей — там есть
только «юниты на каждую формулу П1–П5» и «смок репро-фикстуры #329»,
которые формулу проверяют, а не канал отказа.

Это ровно тот класс дефекта, который правился в M1: нормативный текст §2
теперь делает более специфичные утверждения о видимом поведении (что
именно называет объяснение ручки, что именно показывает трей), чем было в
r1 — но ни одна acceptance criteria не привязана к доказательству именно
этой специфики, и §9 («принято предположительно») её тоже не перечисляет
как допущение.

**Чем это грозит.** Риск, который в r1 сформулирован как последствие
M1 («реализация по букве §2 добавит тост поверх существующей ручки, либо
автор тихо перепишет UX Resize»), не устранён полностью: теперь у §2 есть
правильный нормативный текст, но у AC7 нет проверки, что реализация ему
соответствует. Разработчик, ориентирующийся на AC (а не на прозу §2) при
написании тестов на этапе кода, может закрыть AC7 голым fail-closed-тестом,
не проверив, что ручка называет П1–П5, а трей — П3/П5, и разойтись с §2
незамеченным до код-ревью или позже.

**Что нужно сделать.** Дополнить AC7 (или завести AC7a/AC7b по аналогии с
AC5) явной проверкой канала: для Resize — текст hover/focus/click называет
нарушенное правило (П1–П5) и тост при этом не появляется; для «Толщины» —
трей показывает отказ значения с тостом, называющим правило (П3/П5). Либо,
если такая гранулярность признаётся избыточной для AC и достаточно прозы
§2, явно снять эту находку в комментарии автора с той же аргументацией —
но не оставлять молча, раз в этом раунде именно расхождение AC и §2 было
предметом M1.

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

Не проверялось заново — делта r1→r2 (`git diff 8dce8453..783c04d1`) эти
разделы байт-не тронула, и ни одно новое r2-наблюдение до них логически не
дотягивается:

- Продуктовая рамка (`docs/SCOPE.md`, соответствие J6/J1/J5/J7) — принято
  без повторной проверки.
- §1 (сценарий), §4 (рендер легаси-острия, ссылки на #309/#310 в
  `docs/WALL-THICKNESS.md`), §5 (бэкенд, прецедент
  `invalid_partition_opening_jamb_margin`) — принято без повторной
  проверки.
- §6 (артефакты/поверхности, i18n-ключи, golden-сцена), §7
  (производительность/touch) — принято без повторной проверки, за
  вычетом отмеченного выше пробела AC7↔§2 в §8, который относится к §8, а
  не к §6.
- AC1–AC4, AC6, AC8–AC10 — формулировки не менялись диффом, границы и
  способ доказательства уже проверены в r1 — принято без повторной
  проверки.
- §9 («принято предположительно»), §10 (риски), §11 (откат) — не менялись,
  принято без повторной проверки.
- Обязательные разделы §7.1 присутствуют по содержанию, артефакт
  корректного класса (полноценный файл ТЗ, задача не `small`) — принято
  без повторной проверки.
- Пять численных ограничений П1–П5 совпадают с решением владельца в чате
  issue дословно (проверено в r1) — сами числа delta не меняла (менялась
  только форма записи П4/П5 без «(1 клетка)», см. закрытие L1 выше),
  повторная сверка с чатом владельца не требовалась.

Источник: `docs/reviews/SPEC-REVIEW-329-r1.md` (committed at `9f7d1fd4`),
вывод получен на SHA `8dce8453975121a89263d44243e49059f7000da7`.

## Что проверено и корректно (делта r2)

- M1 закрыт по существу: канал отказа расписан по всем пяти поверхностям
  отдельно, Resize явно НЕ использует тост (снимает риск дублирующего
  сообщения из r1), формулировка синтезирует уже задокументированное
  поведение USER-GUIDE (строки 482–484), а не изобретает новый визуальный
  контракт.
- Канал «Толщины» (тост-в-трее по образцу #313) подтверждён существующим
  прецедентом — не выдумка, коммит `5e5dad27` содержит именно такое
  поведение для независимой кладки.
- M2 закрыт по существу: AC5a/AC5b разделены корректно, числа AC5b
  математически верны (пересчитано независимо, см. «Как проверялось»),
  синтетика действительно изолирует П5 от П1/П2/П3.
- L1 закрыт (не был обязателен) — абсолютность порогов П4/П5 теперь
  explicit, скобка с «клеткой» убрана, не вводит в заблуждение.
- Никаких новых догадок, выданных за факт, в самой делте (кроме находки
  r2-M1, которая не про новую догадку в тексте, а про рассинхрон текста и
  AC) не обнаружено.

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

- Весь материал, перечисленный в разделе «Унаследовано из r1» — сознательно
  не перепроверял, делта его не касается (см. обоснование там же).
- Код не менялся в этом коммите (только `docs/specs/**`, класс C) — гейты
  `typecheck`/`test`/`build`/`check-docs`/инварианты модели/смоки не
  прогонял: они не относятся к чисто документационной правке на этапе
  spec-review.
- Не проверял, как именно разработчик в итоге сформулирует текст
  ручки/тоста при реализации — это предмет код-ревью, а не спек-ревью;
  здесь оценивается только наличие проверяемого критерия в ТЗ (которого,
  по находке r2-M1, для этой специфики пока нет).
- Не запрашивал у владельца дополнительных продуктовых уточнений —
  находка r2-M1 технического характера (согласованность AC с прозой),
  решается автором ТЗ, а не владельцем.

## Вердикт

Жёлтый. Один Medium в скоупе задачи (r2-M1), High-находок нет. Оба Medium
раунда r1 (M1, M2) закрыты корректно и не переоткрываются. Находка r2-M1
чинится в этом же ТЗ (правка AC7/§8) без смены архитектуры документа;
отдельный issue не заводится (#202, находка в скоупе).