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

# SPEC-REVIEW-32-r2

- Issue: https://github.com/Matysh/houseplan-card/issues/32
- Этап: ревью ТЗ (PROCESS.md §2.4), заход r2
- Материал: `docs/specs/032-unified-danger-confirmation.md` на SHA `4ba1b273`
  (коммит «docs: budget unified confirmation surface»), тело issue #32, все
  комментарии по 2026-08-30 включительно
- Предыдущий раунд: `docs/reviews/SPEC-REVIEW-32-r1.md`, вердикт жёлтый,
  материал зафиксирован на SHA `206bcd1a`. SHA был назван в самом документе r1
  (в его теле, не в комментарии-вердикте issue — комментарий #4 SHA не
  называет; сам документ его называет дважды: в шапке «Материал» и в финальной
  строке вердикта)
- Трек: полный (владелец снял `small` 2026-08-30)
- Бюджет: заход r2, блокирующих циклов израсходовано **1 из 4** (r1 был
  жёлтым и потратил цикл; текущий раунд, если зелёный, цикла не образует, #227)

## Скоуп проверки r2 — по дельте (PROCESS.md §2.9/§2.10)

Дельта объявлена командой `git diff 206bcd1a..HEAD -- docs/specs/032-unified-danger-confirmation.md`
и ограничена ровно шестью добавленными строками в одном файле:

```
+ (в §5.2, после строки про eager root)
+ Это осознанный прирост initial View graph: Lit и `hp-dialog` уже находятся в
+ eager-графе, поэтому новый presentation/controller должен добавить не более
+ **3 KiB gzip** к baseline 284055 B и оставить весь initial View ниже
+ действующего бюджета **300000 B gzip** (headroom до задачи: 15945 B).

+ (новая строка в таблице §9)
+ | AC-13 | Initial View остаётся ≤300000 B gzip, а прирост к baseline 284055 B — ≤3 KiB gzip | `npm run bundle:budget` + сравнение manifest initial graph |

+ (в списке команд §10)
+ npm run bundle:budget
```

Второй файл в диапазоне, `docs/reviews/SPEC-REVIEW-32-r1.md` (150 строк), —
это сам документ предыдущего раунда, положенный конвейером; он не редактировался
автором и не входит в предмет разбора.

Дельта локальна по критерию §2.10: не ребейз (dev не продвинулся —
`git merge-base --is-ancestor origin/dev HEAD` истинно, слияние чистое), не
смена контракта поведения, не задета новая подсистема, объём (6 строк)
несопоставим с исходной задачей. Полный повторный разбор не требуется —
проверяю закрытие M1 и всё, до чего дотягивается эта дельта: раздел §5.2,
таблицу AC (только новая строка AC-13) и список команд §10. Остальные разделы
и AC-1…AC-12 наследуются из r1 без повторной проверки (раздел ниже).

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

| Находка r1 | Чем закрыта | Где это видно |
|---|---|---|
| **M1** — DoR-пункт «влияние на производительность и бюджеты названо» не закрыт: §5.2 сознательно кладёт controller в eager root graph, но не называет ожидаемый прирост/headroom, AC не привязан к размеру eager-бандла, §10 не требует `bundle:budget` | Все три требуемых фикса внесены в одну правку: (1) в §5.2 добавлено предложение с ожидаемым порядком прироста «не более 3 KiB gzip» и headroom «15945 B»; (2) добавлен AC-13 с явным порогом и способом доказательства; (3) `npm run bundle:budget` добавлен в список §10 рядом с `bundle:sync` | `docs/specs/032-unified-danger-confirmation.md` §5.2 (после строки «Controller находится в eager root…»), таблица §9 строка AC-13, список команд §10 (строка `npm run bundle:budget` сразу после `npm run bundle:sync`) |

Числа не голое заявление автора — перепроверены исполнением, не чтением:
собрал бандл (`npm run build && npm run bundle:sync`) и прогнал сам гейт:

```
$ npm run bundle:budget
initial View: 284055 B gzip (budget 300000 B, headroom 15945 B)
lazy editor: 143904 B gzip
lazy locale: 47816 B gzip
```

Совпадение точное: `284055 B` baseline, `300000 B` бюджет, `15945 B` headroom —
все три числа из правки §5.2/AC-13 совпадают с фактическим текущим состоянием
дерева побайтово. Это не догадка, выданная за факт (запрещённый спеке паттерн,
PROCESS.md §7.1): автор явно исполнил гейт перед тем, как вписать числа в ТЗ,
и они прошли независимую перепроверку. Дополнительно проверил внутреннюю
арифметику: `300000 − 284055 = 15945` (сходится) и что заявленный лимит роста
`≤3 KiB` не съедает весь headroom — после гипотетического прироста в 3072 Б
остаётся ещё 12873 Б до стены, то есть формулировка согласована сама с собой.

Также проверил, что число `300000 B` (а не устаревшее `256000 B` из
`AGENTS.md` #337) — актуальный порог: `scripts/bundle-budget.mjs` экспортирует
`INITIAL_VIEW_GZIP_BUDGET = 300_000`, рекалибровано решением по #367 задолго до
этой задачи. `AGENTS.md` не переправлен после той рекалибровки и называет
старое число — это не находка этого ревью (файл не в диффе issue #32, ошибка
предшествует задаче и не создана и не унаследована текстом ТЗ #32 — ТЗ, в
отличие от AGENTS.md, использует правильное, актуальное число). Оставляю как
наблюдение, не завожу отдельный issue: по PROCESS.md документация уступает
факту автоматизации, актуальный факт уже верно отражён в правке #32, и
единственный практический эффект устаревшей строки в AGENTS.md — не связанный
с этой задачей риск ввести в заблуждение будущего читателя `AGENTS.md`, что не
является дефектом дельты #32.

M1 закрыт полностью и подтверждён исполнением, не чтением.

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

Без повторной проверки в r2, источник — `docs/reviews/SPEC-REVIEW-32-r1.md` на
SHA `206bcd1a` (дельта их не касается):

- Полнота охвата 8 call sites `confirm(` в `src/**` и соответствие таблице §4.1.
- Границы со специализированными диалогами (`_roomDeleteDialog`,
  `_partitionDeleteDialog`, `confirm.erase_decor`, backup/import/optimize) —
  не дублируются, уже свой `hp-dialog`.
- Существующий focus/autofocus/Escape-контракт `hp-dialog.ts` (строки 237–396),
  на который ссылается §6.1 ТЗ, — не выдуман.
- Race-safety claim по `_deleteSpace` (blocker-проверка до `confirm()`).
- Lock-инвариант `docs/SCOPE.md` не нарушается и не переопределяется; AC-9 (в
  прежней нумерации r1 это тот же AC-9, номер не сдвинулся) отдельно требует
  отсутствия unlock после cancel/stale state.
- Обязательные разделы §7.1 присутствуют (сценарий, «до/после», проблема,
  scope/не-scope, контракт, UX, данные/миграция, AC1-12 на тот момент, план
  автотестов, риски, откат, release-артефакты).
- §6.1 «warning/on акцент» для unlock-кнопки — явно сформулированное как
  открытый на усмотрение реализации техническое допущение, не догадка,
  выданная за факт.
- Открытых продуктовых вопросов нет — комментарий владельца от 2026-08-30
  закрывает тему; новых продуктовых вопросов дельта r2 не поднимает (правка
  чисто техническая — числовой бюджет).
- Ссылки issue ↔ ТЗ на месте в обоих направлениях.
- i18n-ключи: точные имена не названы (признано приемлемым в r1, паритет
  проверяется `test/i18n.test.mjs` через AC-11) — дельта r2 эту область не
  трогает, вывод не пересматривается.
- Соответствие `docs/CONFIG-COMPATIBILITY.md` («миграция отсутствует») —
  не пересматривается, дельта миграций не касается.

## Находки нового раунда

Нет. Дельта r2 — точечный, полностью проверенный числами фикс единственной
находки r1, новых проблем не вносит.

## Что проверено и корректно (r2, сверх наследования)

- Дельта ограничена одним файлом класса C (`docs/specs/032-*.md`), продуктовый
  код не тронут — `git diff --stat 206bcd1a..HEAD` показывает только
  `docs/reviews/SPEC-REVIEW-32-r1.md` (публикация r1, не редактировалась) и
  сам файл ТЗ.
- `git merge-base --is-ancestor origin/dev HEAD` — истина: ветка не отстаёт от
  `dev` (`8955c02e`), рёбейз не требуется, полный разбор по этой причине не
  предписан.
- Все три числа новой правки (`284055`, `300000`, `15945`) подтверждены
  реальным прогоном `npm run build && npm run bundle:sync && npm run
  bundle:budget` на этом дереве, а не переписаны с чужих слов.
- AC-13 сформулирован проверяемо и однозначно, способ доказательства назван
  (`npm run bundle:budget` + сверка manifest initial graph), согласуется с
  остальной таблицей §9 по формату.

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

- AC-1…AC-12 заново — дельта их доказательства не задевает, наследуются из r1
  без повторного чтения кода (см. раздел выше).
- Реализацию — её всё ещё нет, стадия `S4-spec-review`.
- `npx tsc --noEmit` / `npm test` для этой правки не требовались и не
  гонялись отдельно от `bundle:budget` — правка не в `src/**`, `npm run build`
  внутри `bundle:sync` уже включает `tsc --noEmit` как первый шаг и прошёл
  чисто (лог показал `tsc --noEmit && rollup -c` без ошибок).
- `check-docs.mjs` не гонял — дельта не в `src/**`, автор уже отчитался
  «passed» под свою правку, а сам гейт по построению не зависит от текста ТЗ.
- Стабильность числа `284055 B` во времени (не проверял, изменится ли оно к
  моменту реализации) — это ожидаемо: AC-13 меряет фактический бандл на
  момент кода, число в §5.2 — целевой ориентир, не заморожённая константа;
  ревью кода перепроверит тем же гейтом на своём SHA.

## Вердикт

M1 закрыт полностью, закрытие подтверждено исполнением гейта, а не чтением
текста. Новых High/Medium-находок в дельте r2 нет. DoR-пункт «влияние на
производительность и бюджеты названо» теперь выполнен. Итог: **зелёный** —
issue готов к переходу в `S5-ready`.