14 KiB
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на SHA4ba1b273(коммит «docs: budget unified confirmation surface»), тело issue #32, все комментарии по 2026-08-30 включительно - Предыдущий раунд:
docs/reviews/SPEC-REVIEW-32-r1.md, вердикт жёлтый, материал зафиксирован на SHA206bcd1a. SHA был назван в самом документе r1 (в его теле, не в комментарии-вердикте issue — комментарий #4 SHA не называет; сам документ его называет дважды: в шапке «Материал» и в финальной строке вердикта) - Трек: полный (владелец снял
small2026-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.