# 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
```