docs: review document for #292

Issue: #292
User-Visible: no

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

@@ -0,0 +1,137 @@
+# 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
+```