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