docs: review document for #329

Issue: #329
User-Visible: no

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

@@ -0,0 +1,163 @@
+# 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 нет. Циклы ревью для этой
+задачи исчерпывать не нужно — документ готов к переходу на следующий
+этап.