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

# SPEC-REVIEW-329-r3

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

ТЗ: `docs/specs/329-junction-limits.md`. Ревизия под ревью — коммит
`1d2748d64bf2eafbcc8aade31652e226edf0e14a` («docs: spec #329 revision 3 —
AC7 proves the per-surface refusal channels»), базовый SHA раунда r2 —
`783c04d1813b0b201efb21b8bae1b0c497978cf1`. Класс C (`docs/specs/**`),
продуктовый код не тронут — `git show --stat 1d2748d6` подтверждает
единственный изменённый файл.

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

Раунд не первый. Предыдущий вердикт — жёлтый, r2, найден в комментарии
issue `claude[bot]` от 2026-08-27, зафиксирован на SHA `783c04d1`
(назван в шапке `docs/reviews/SPEC-REVIEW-329-r2.md`, committed at
`87792f4b`). Автор объявил делту в комментарии от 2026-08-27: «Ревизия 3
(1d2748d6): r2-M1 — AC7 разделён на AC7a (Resize: упор/приглушённая
ручка, объяснение называет правило, тост исключён, смок проверяет текст)
и AC7b («Толщина»: значение не применяется, тост с названием правила по
образцу #313, смок проверяет текст); §6 план тестов пополнен смоками
каналов отказа».

Дельта — `git diff 783c04d1..1d2748d6 -- docs/specs/329-junction-limits.md`:
16 строк (12 добавлено, 4 удалено) внутри одного файла, три места:
строка статуса в шапке (косметика — счётчик ревизии), одна строка в §6
(план тестов), блок AC7 → AC7a/AC7b в §8. Остальной документ (§1, §2,
§3, §4, §5, §7, AC1–AC6, AC8–AC10, §9, §10, §11) байт-не тронут диффом.

Делта локальна: не ребейз, не смена контракта поведения продукта (AC7a/b
дословно переносят уже принятый в r2 нормативный текст §2 в проверяемую
форму, новых решений не вводят), не задета новая подсистема, объём
сопоставим с точечной правкой одной находки. Полный разбор документа не
требуется — разбираю делту плюс то, до чего она логически дотягивается
(соответствие AC7a/b тексту §2 и адекватность как замены единственной
оставшейся находки r2).

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

- Прочитан диф `git diff 783c04d1..1d2748d6` построчно — сверен с
  требованием r2-M1 дословно (AC должен доказывать специфику §2: текст
  объяснения ручки Resize называет правило и не сопровождается тостом;
  трей «Толщины» показывает тост с названием правила).
- Перечитано §2 (не тронуто диффом, но AC7a/b должны ему соответствовать)
  — сверка терминов: «упирается в последнюю допустимую позицию»,
  «приглушена», «объяснение по hover/focus/нажатию называет нарушенное
  правило», «тост не используется» (Resize); «отказ значением в трее...
  тостом с названием правила (П3/П5)» («Толщина») — формулировки AC7a/b
  переносят эти фразы почти дословно, новых утверждений о поведении не
  вводят.
- Перечитан обновлённый фрагмент §6 — новая строка называет ровно то, что
  r2-M1 отметил отсутствующим («§6 тоже не называет конкретный тест на
  текст ручки/тоста»): «смоки каналов отказа: текст объяснения ручки
  Resize и текст тоста «Толщины» (AC7a/AC7b)».
- Перечитаны AC5a/AC5b (§8, не тронуты диффом r2→r3) как образец, по
  аналогии с которым r2-M1 просил построить AC7a/AC7b — форма совпадает:
  тот же паттерн «подпункт на surface + явный способ доказательства
  (смок) + пункт в §6».
- `git show --stat 1d2748d6` — подтверждено, что кроме
  `docs/specs/329-junction-limits.md` ничего не менялось: гейты кода
  (`tsc`/`test`/`build`/`check-docs`/инварианты/смоки) не относятся к
  чисто документационной ревизии на этапе spec, не прогонял — так же,
  как в r1/r2.
- Проверено, что AC7a покрывает все пять правил П1–П5 (текст: «Resize,
  приводящий к нарушению любого из П1–П5»), а AC7b — ровно П3/П5, что
  совпадает с §2 («толщина участвует в П3/П5») и не расширяет и не
  сужает область правил произвольно.
- Проверено отсутствие противоречий между новой формулировкой AC7a/b и
  §9 («принято предположительно») — AC7a/b не вводят новых допущений,
  которые требовалось бы туда добавить: канал уже был нормативным
  решением §2 в r2, здесь только достроена проверяемость.

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

| Находка r2 | Чем закрыта | Где это видно |
|---|---|---|
| **r2-M1** — AC7 не обновлён вместе с §2 и не проверяет заявленный канал отказа (текст объяснения ручки Resize называет правило и не сопровождается тостом; трей «Толщины» показывает тост с названием правила); §6 тоже не называет такой тест | AC7 разделён на AC7a (Resize: упор в последнюю допустимую позицию, приглушённая ручка, объяснение по hover/focus/нажатию называет нарушенное правило, тост явно исключён — «тост не показывается», план байт-неизменен, способ доказательства — смок, который «проверяет и байт-неизменность, и текст объяснения ручки») и AC7b («Толщина»: значение не применяется, тост с названием правила П3/П5 по образцу #313, план байт-неизменен, «смок проверяет текст тоста»). §6 дополнен строкой «смоки каналов отказа: текст объяснения ручки Resize и текст тоста «Толщины» (AC7a/AC7b)» | `docs/specs/329-junction-limits.md` §8, AC7a/AC7b; §6, добавленная строка (см. diff `783c04d1..1d2748d6`) |

Находка закрыта по существу: формулировки AC7a/AC7b дословно связывают
проверку с конкретными фразами §2 (channel per surface), а не
переформулируют проблему уклончиво. Гранулярность совпадает с тем, что
запрашивал r2-M1 («текст hover/focus/click называет нарушенное правило»,
«трей показывает отказ значения с тостом, называющим правило») — без
избыточной детализации (не требуется отдельный AC на каждое из пяти
правил П1–П5 для Resize; r2-M1 такой детализации и не просил).

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

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

- Продуктовая рамка (`docs/SCOPE.md`, соответствие J6/J1/J5/J7) —
  принято без повторной проверки (унаследовано ещё из r1 через r2).
- §1 (сценарий), §4 (рендер легаси-острия, ссылки на #309/#310), §5
  (бэкенд, прецедент `invalid_partition_opening_jamb_margin`) — принято
  без повторной проверки.
- §2 (нормативные ограничения, каналы отказа по поверхностям) — сама
  делта r3 её не меняла; закрытие M1 r1 и подтверждение прецедента
  #313 (коммит `5e5dad27`) остаются в силе из r2. AC7a/b в этом раунде
  сверены с текстом §2 на предмет соответствия (см. «Как проверялось»),
  но сам текст §2 повторно на корректность не проверялся.
- §3 (граница применения), §7 (производительность/touch) — принято без
  повторной проверки.
- AC1–AC4, AC5a/AC5b, AC6, AC8–AC10 — формулировки не менялись диффом
  r2→r3, границы и способ доказательства уже проверены в r1/r2 (AC5b —
  с независимым пересчётом математики в r2) — принято без повторной
  проверки.
- §9 («принято предположительно»), §10 (риски), §11 (откат) — не
  менялись, принято без повторной проверки.
- Обязательные разделы §7.1 присутствуют по содержанию, артефакт
  корректного класса (полноценный файл ТЗ, issue не помечен `small` —
  перепроверено меткой issue в этом раунде, см. ниже) — принято без
  повторной проверки структуры документа в остальном.
- Пять численных ограничений П1–П5 совпадают с решением владельца в
  чате issue дословно (проверено в r1) — делта r2→r3 их не касалась.

Источник: `docs/reviews/SPEC-REVIEW-329-r2.md` (committed at
`87792f4bc33b96da0db29954dca0f99585993f82`), вывод получен на SHA
`783c04d1813b0b201efb21b8bae1b0c497978cf1`.

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

- r2-M1 закрыт по существу: AC7a/AC7b проверяемо доказывают ровно те
  специфичные утверждения §2, которые в r2 были нормативным текстом без
  привязанного AC (текст ручки Resize называет правило и не
  сопровождается тостом; трей «Толщины» показывает тост с названием
  правила П3/П5).
- §6 (план тестов) больше не расходится с §8: строка про смоки каналов
  отказа явно ссылается на AC7a/AC7b.
- AC7a/b не вводят новых продуктовых решений и не расширяют скоуп —
  это перенос уже принятого в r2 нормативного текста §2 в форму
  acceptance criteria, дословно, без новых чисел/условий.
- Метка issue перепроверена (`gh issue view 329 --json labels`): `bug`,
  `P2`, `S4-spec-review` — не `small`, что подтверждает необходимость
  полноценного файла ТЗ (уже установлено в r1, здесь просто
  перепроверено, так как метки могли измениться за три раунда).
- `git show --stat` подтверждает единственный изменённый файл — класс C,
  гейты кода не применимы.

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

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

## Вердикт

Зелёный. Единственная находка r2 (r2-M1, Medium) закрыта по существу и
не переоткрывается; новых находок в делте r3 нет. Циклы ревью для этой
задачи исчерпывать не нужно — документ готов к переходу на следующий
этап.