Files
houseplan-card/docs/reviews/SPEC-REVIEW-32-r2.md
T
2026-08-30 21:29:56 +00:00

14 KiB
Raw Blame History

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.