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

SPEC-REVIEW-292-r2

• Issue: https://github.com/Matysh/houseplan-card/issues/292
• Этап: ревью ТЗ (PROCESS.md §2.4)
• Артефакт ТЗ: docs/specs/292-resize-availability-audit.md, HEAD 70bbb982 (правка r1 внесена коммитом 70bbb982 docs: clarify resize reasons and rollback, поверх 52ad67e7, на котором получен вердикт r1)
• Заход: r2 · блокирующих циклов израсходовано 1 из 4 (зелёный вердикт бюджет не тратит, §4/§227)
• Предыдущий вердикт: жёлтый, r1, docs/reviews/SPEC-REVIEW-292-r1.md, получен на SHA 52ad67e7. SHA не был назван в теле вердикта r1 (только в тексте документа) — восстановлен по коммиту docs: specify resize availability audit, на который ссылается комментарий автора «ТЗ подготовлено и отправлено на внешнее ревью».
• Ревьюер: Claude (роль ревьюер ТЗ, PROCESS.md §6)

Скоуп ревью

Разбор по дельте (PROCESS.md §2.9): единственный изменённый файл между 52ad67e7 и HEAD (кроме публикации самого документа r1) — docs/specs/292-resize-availability-audit.md, 43 строки добавлено / 12 удалено в разделах 1, 2, 5 и двух новых разделах (9 «Риски и меры», 10 «Откат»). Продуктовый код не менялся — git diff 52ad67e7..HEAD --stat показывает только этот файл и docs/reviews/SPEC-REVIEW-292-r1.md. Дельта локальна: правка того же документа, без ребейза, без смены контракта поведения за пределами того, что обсуждалось в r1, без новой подсистемы. Условия §2.9 для полного разбора не выполнены — сокращаю объём разбора до дельты плюс всё, до чего дельта дотягивается (разделы 1–2, 5–6 читались целиком повторно, поскольку правка §5 логически связана с §2 и §6; разделы 3, 4, 7, 8, раздел «Принятые предположения» дельтой не задеты и наследуются из r1 без повторной проверки).

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

1. Восстановлен SHA вердикта r1 (52ad67e7) и посчитана дельта: git diff 52ad67e7..HEAD -- docs/specs/292-resize-availability-audit.md.
2. Прочитан целиком docs/reviews/SPEC-REVIEW-292-r1.md — обе находки (Medium и три Low) сверены построчно с новым текстом документа.
3. Перечитаны разделы 1, 2, 5, 6 текущей редакции и новые разделы 9, 10 — проверено, что убранное обещание «Optimize исправит эту стену» согласовано между §2, §5 и §9 (риск №3), а не противоречит друг другу.
4. Проверено, что раздел 7 (AC1–AC9) не менялся дельтой и не апеллирует к дифференцированному тексту reason (нет AC, которое требовало бы двух вариантов сообщения для одного SafeResizeReason) — иначе снятие обязательства в §5 создало бы новое несоответствие AC.
5. Проверено переномерование разделов 9→11, 10→12, 11→13: содержимое внутри этих трёх блоков не изменилось, только заголовки; внутренних числовых ссылок вида «раздел N» в документе нет (grep -n "раздел [0-9]" — пусто), риск «битой» перекрёстной ссылки не подтвердился.
6. Сверен комментарий автора («Правки r1 внесены… добавлены персона/сценарий, риски и rollback») с фактическим диффом — заявление соответствует изменённым строкам, а не голословно.
7. Код не читался повторно за пределами того, что уже зафиксировано в r1 (src/resize.ts, src/houseplan-card.ts), так как дельта не касается технического контракта — она снимает требовавшую контракта формулировку.

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

Находка r1	Чем закрыта	Где это видно
Medium — обещание «предложить Optimize, только если кандидат #290 существует» не имеет технической опоры (нет поля-признака в SafeResizeReason, нет AC, различающего два текста)	Обещание убрано целиком, а не реализован недостающий контракт: текст для side-angle/diagonal стал безусловным и никогда не рекомендует Optimize; новый вариант reason/поле контекста явно объявлен не входящим в задачу	docs/specs/292-resize-availability-audit.md:100 («Resize поддерживает только точные оси, без обещания автоматического Optimize»); §5 хвост, строки 107–109 («Динамический признак… и новые варианты SafeResizeReason не вводятся этой задачей»); согласованно в §2, строки 45–48
Low — отсутствуют разделы «Сценарий и персона», «Риски и меры», «Откат» (PROCESS.md §7.1)	Все три раздела добавлены явно	§1 переименован в «Сценарий, персона и подтверждение» с блоками «Кто и где» / «Момент проблемы» / «До/после» (строки 11–22); новый §9 «Риски и меры» (строки 202–212); новый §10 «Откат» (строки 214–217)
Low — AC1–AC8 не помечают явно способ доказательства	Не закрыта: раздел 7 не изменён дельтой (git diff не касается AC1–AC9)	docs/specs/292-resize-availability-audit.md:132-189 — тот же текст, что на r1, без явных тегов unit/smoke/code review

Третья находка (Low, теги доказательства) осталась незакрытой, хотя r1 просил закрыть все Low в той же правке. Решаю её здесь так же, как обозначил в r1: смысл способа доказательства везде однозначен (AC1/AC3/AC4/AC6/AC7/AC8 — unit по fixture; AC2 — unit; AC5 — production smoke; AC9 — сводный список команд), явные теги ничего не меняют по существу. Снимаю с записью, не возвращая документ на третий заход из-за чисто оформительской правки — бюджет циклов дороже, чем эта строка (см. верхний блок задачи про #150).

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

Без повторной проверки принято из docs/reviews/SPEC-REVIEW-292-r1.md (получено на SHA 52ad67e7), так как дельта r2 не касается этих разделов:

• продуктовая рамка и соответствие job J6 (docs/SCOPE.md);
• границы с #293 (раздел 6 «Не входит»);
• корректность терминов («Оптимизировать планы», «mixed-role») — сверены с docs/USER-GUIDE.ru.md и checkMixedRoleRecords;
• AC2 как эмпирически подтверждённый факт (пара room-a/room-b edge 2);
• соразмерность локальных гейтов в §9 (ныне §9 «Локальные гейты» под старым номером не переименован — это раздел 7/AC9, не путать с новым §9 «Риски») этапу spec — код не менялся, гейты не запускались;
• отсутствие открытых продуктовых вопросов владельцу — подтверждено также прямой цитатой автора в комментарии «Аналитика подтверждена».

Что проверено и корректно (дополнительно к унаследованному)

• Снятие обещания Optimize согласовано во всех трёх местах, где оно упоминалось (§2, §5, §9) — не осталось хвостов старой формулировки нигде в файле (grep -n "предложить Optimize" и grep -n "кандидат #290" по файлу дают пустой результат).
• Выбранное решение (никогда не обещать вместо «обещать только при доказанном кандидате») строже, чем любой из двух путей, предложенных в r1: оно не требует нового технического контракта и не оставляет риска ложного обещания ни в одном случае — при этом не противоречит AC6 («один resolver, один reason type»), которое иначе требовало бы явного исключения.
• Это решение — техническое, не продуктовое: оно про честность конкретной строки подсказки, а не про объём видимого пользователю изменения; эскалация владельцу не требовалась и не была бы уместна (PROCESS.md §7.1: владельцу — только вопросы о том, что человек видит/делает и объёме задачи).
• Переномерование разделов не создало разрывов: сверено отсутствием численных внутренних ссылок вида «раздел N» в тексте документа.

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

• Разделы 3, 4, 6, 7 (AC1–AC9), 8, 11 (бывший 9, «Ожидаемые файлы»), 12 (бывший 10, «Release»), 13 (бывший 11, «Принятые предположения») — дельта их не касалась, унаследованы из r1 без повторного построчного разбора (см. раздел «Унаследовано»).
• Продуктовый код (src/resize.ts, src/houseplan-card.ts) — не перечитывался повторно; в r1 уже зафиксировано, что архитектура даёт один статический текст на один SafeResizeReason, и именно на этом факте построена правка r2, так что перепроверка не добавила бы нового знания.
• docs/specs/README.md (таблица issue ↔ ТЗ) — вне зоны ответственности ревью ТЗ, как и в r1.
• Гейты (typecheck/test/build/check-docs) не запускались — код не менялся, этап spec, раздел AC9 не входит в дельту этого раунда.
• Состояние #289/#290 (оба ещё не прошли ревью на момент r1) не перепроверялось повторно; ничего в дельте r2 не меняет эту зависимость.

Вердикт

Medium-находка r1 закрыта решением, разрешённым самим вердиктом r1 (снятие обещания вместо ввода нового технического контракта), без остаточного несоответствия AC. Обе содержательные Low-находки (недостающие разделы) закрыты явно. Третья, чисто оформительская Low-находка (явные теги способа доказательства AC) не закрыта правкой, но снимается здесь с записью как не влияющая на однозначность документа — открывать третий заход ради неё нецелесообразно. High: 0, Medium: 0 (в задаче не осталось). Документ готов к переходу дальше по конвейеру.

Вердикт: зелёный · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 0
Документ: docs/reviews/SPEC-REVIEW-292-r2.md