diff --git a/docs/reviews/SPEC-REVIEW-329-r3.md b/docs/reviews/SPEC-REVIEW-329-r3.md new file mode 100644 index 00000000..b4b6aa8a --- /dev/null +++ b/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 нет. Циклы ревью для этой +задачи исчерпывать не нужно — документ готов к переходу на следующий +этап.