houseplan-card/docs/reviews/CODE-REVIEW-276-r3.md

CODE-REVIEW-276-r3

• Issue: https://github.com/Matysh/houseplan-card/issues/276
• Ветка: issue/276-reconcile-coincident-partition
• Проверенный HEAD: ff2f2063cf5b1f6292a6a4369274d0b59ea228dc (совпадает с заявленным в хендоффе автора)
• Предыдущий раунд: docs/reviews/CODE-REVIEW-276-r2.md, HEAD 82fe98bcd3fb76833c27dd888d265fc15583a43b, вердикт жёлтый (High: 0, Medium: 1 — M1-r2)
• Заход: r3 (код-ревью) · блокирующих циклов до этого раунда: 2/4

1. Скоуп проверки

Разбор по дельте (PROCESS.md §2.10): git diff 82fe98bc..HEAD (=git diff 82fe98bc..ff2f2063).

Коммиты дельты:

b5519e99 docs: review document for #276          ← публикация CODE-REVIEW-276-r2 (инфраструктура)
ff2f2063 test: stabilize Optimize overhead benchmark   ← дельта r3

Дельта строго локальна — git diff --stat показывает только:

demo/benchmark_coincident_partitions.mjs             |  22 +-
demo/golden/baselines/baselines-index.json           |  26 ++-
demo/golden/baselines/coincident-partition-*.png     | (4 новых файла)
demo/golden/baselines/{9 существующих сцен}.png      | (обновлены байты)
docs/reviews/CODE-REVIEW-276-r2.md                   | 222 +++ (публикация r2)

Ни один файл src/**, test/**, custom_components/** не тронут. Продуктовый код (src/coincident-partitions.ts, src/plan-optimizer.ts) дельтой не задет — значит контракт поведения не меняется, новая подсистема не затрагивается, ребейза на ушедший вперёд dev не было. Разбор по дельте, а не заново, оправдан по всем критериям §2.10.

Коммит ff2f2063 несёт Issue: #276, User-Visible: no — верно, видимого поведения нет. Поскольку коммит трогает demo/golden/baselines/**, обязательны и присутствуют Release: v1.67.0-beta.8 и Baseline-Reviewed: https://github.com/Matysh/houseplan-card/actions/runs/32684802336.

2. Закрытие раунда r2

Находка r2	Чем закрыта	Где видно
M1-r2 — benchmark:coincident-partitions гейтит pass по разности двух независимых p95 (candidateSummary.p95 - baselineSummary.p95) вместо уже вычисленной корректной парной статистики (overheadSummary.p95), из-за чего ~⅓ прогонов красные/зелёные без единой правки кода	Закрыта. measuredOverheadP95 = Math.max(0, overheadSummary.p95) — гейт теперь считает именно парную разницу candidateMs - baselineMs на каждой итерации, а не разность независимых квантилей. Дополнительно введены BATCH_SIZE=10 (усреднение таймер-шума внутри одного замера) и ABBA/BAAB-порядок (first,second,third,fourth со средним (second+third)/2 и (first+fourth)/2), гасящий линейный дрифт: для арифметической прогрессии позиций (1+4)/2 == (2+3)/2, поэтому линейный член дрифта вычитается точно	demo/benchmark_coincident_partitions.mjs:26-53,67; воспроизведено мной (см. §4) — 4/4 прогона стабильно pass: true, relativeP95 в диапазоне 12.2–14.1 % против 4 прогонов r2, где расчётная (но не используемая тогда) pairedOverhead.p95 не проходила бюджет все 4 раза

3. Унаследовано из r2 (без повторной проверки)

Источник: docs/reviews/CODE-REVIEW-276-r2.md, HEAD 82fe98bc. Дельта не касается перечисленного, поэтому вывод r2 (который для AC1,2,4,6-10,12-14 сам был унаследован из r1, HEAD 496e79a6) принят без повторного исполнения:

• AC1, AC2, AC4 (exact-match условие, byte-preserved fail-closed варианты, nested narrower/wider, orphan/overlap/draft/column/unknown-field) — src/coincident-partitions.ts дельтой не тронут ни в r2, ни в r3.
• AC3 (несколько hosted door/window/gate) — тесты из r2 (test/coincident-partitions.test.mjs:74-121) дельтой r3 не тронуты.
• AC5 (targeted golden: 5-см офсеты + hosted door до/после 10/30/virtual) — сценарии и тест формы из r2 (demo/golden/matrix.mjs, test/golden-matrix.test.mjs:258-286) дельтой r3 не тронуты; сама визуальная приёмка baseline произошла именно в дельте r3 (см. §4) и проверена там впрямую, а не по доверию.
• AC6, AC7, AC8 (Preview/atomic Apply/report/Undo/идемпотентность) — smoke_optimize_coincident_partition.mjs не менялся с r1; вывод принят.
• AC9 (preflight гейтит Apply), AC10 (consumer parity) — соответствующий код дельтой не тронут; выводы r1/r2 приняты как есть.
• AC12, AC13 (мутации, дешёвые гейты) — идентификаторы мутантов и состав гейтов не изменились дельтой r3; тем не менее дешёвые гейты (typecheck/test/build+sync/check-docs) перезапущены заново в этом раунде, а не унаследованы (см. §4), как и в r2.
• AC14 (changelog/docs/терминология) — уже закрыт в a6056111; дельта r3 не добавляет пользовательских документов (только review-документ и golden baseline).
• Раздел «Одно число — один источник» — дельта r3 не добавляет и не меняет ни одной пользовательски видимой величины (тесты, бенчмарк, эталонные изображения); вывод r1/r2 принят.

4. Как проверялось в этом раунде (гейты)

Дешёвые гейты — все перезапущены на HEAD ff2f2063, все green:

Гейт	Результат
npx tsc --noEmit	green, без вывода
npm test	1180/1180 passed, 0 skipped, 0 failed
npm run build && npm run bundle:sync	green; git status чист после сборки; cmp dist/houseplan-card.js custom_components/houseplan/frontend/houseplan-card.js и cmp dist/houseplan-card.js demo/srv/assets/houseplan-card.js — идентичны
node scripts/check-docs.mjs	green: «Documentation checks passed (7 files, 10 external links)» — дельта src/** не трогает, но гейт дёшев и перезапущен
node scripts/process-gate.mjs --issues	«гейт пройден, предупреждений 0»

node scripts/smoke-select.mjs --base 82fe98bc --head HEAD:

Исполняемого frontend-диффа нет (src/**/*.ts не тронут).
Browser-smoke этим диффом не выбираются — это не «пропустить проверки»,
а «выбирать нечего»: смоки проверяют собранную карточку.

Корректно: инструмент подтверждает, что дельта не касается рендер-пути, браузерные смоки в этом раунде не нужны.

Целевая проверка находки M1-r2 — сам предмет дельты, разобран не по чтению, а исполнением:

$ for i in 1 2 3 4; do npm run benchmark:coincident-partitions; done
RUN 1: overheadP95Ms=3.47ms  relativeP95=12.2%  pass=true
RUN 2: overheadP95Ms=3.75ms  relativeP95=13.4%  pass=true
RUN 3: overheadP95Ms=3.93ms  relativeP95=14.1%  pass=true
RUN 4: overheadP95Ms=3.59ms  relativeP95=13.0%  pass=true

4/4 стабильно зелёные (в r2 корректная-но-неиспользуемая метрика проваливала бюджет все 4 раза подряд при том же коде реконсиляции — реальный оверхед не менялся между раундами, поменялась только надёжность его измерения). Дополнительно проверено, что метрика умеет падать: временно (без коммита, только в рабочей копии) понижен ABSOLUTE_OVERHEAD_MS с 25 до 0.001 — pass корректно стал false; файл возвращён в исходное состояние, git status/git diff после возврата пусты.

Проверка легитимности golden-приёмки (класс D, коммит только с Release/Baseline-Reviewed, PROCESS.md §8/правило 13):

gh run view 32684802336 → headSha 82fe98bcd3fb76833c27dd888d265fc15583a43b (= HEAD r2, как и требуется —
  артефакт снят с ветки на проверенном ревью SHA, а не откуда попало)
  job golden: шаг «Capture or verify golden matrix» — 4× missing-baseline для новых сцен coincident-partition-*
    (ожидаемое поведение для «initial no-baseline CI run», demo/golden/README.md:24)
  job «Upload golden candidates/diffs»: «With the provided path, there will be 105 files uploaded» — полный артефакт
Общий conclusion прогона «failure» — это штатно: golden-job фейлится на отсутствующих
baseline ровно для того, чтобы получить артефакт для локального `golden:accept --reviewed --from=...`
(механизм описан в demo/golden/README.md), а не признак сломанного прогона.

baselines-index.json: matrixVersion 41→42, acceptedAt 2026-08-24T03:17:51Z (после createdAt прогона 02:58:12Z — порядок корректный), chromium 151.0.7922.34 — совпадает с пином CI. Изменившихся хэшей ровно 9 (существующие сцены) + 4 новых — совпадает с формулировкой хендоффа «девять byte-различий» и «четыре новых сцены».

Не запускался (по необходимости, обосновано):

• Полный golden:verify/golden:capture — предрелизный гейт (§8/§11.4); сами эталоны уже приняты штатным golden:accept --reviewed на полном Linux CI артефакте (см. выше), повторная локальная съёмка ничего не добавляет к ревью и дала бы другой байтовый PNG на другой машине (demo/golden/README.md).
• python -m pytest tests_backend — дельта не касается custom_components/**/*.py.
• Остальные browser-смоки — инструмент выбора не вернул ни одной связи, дельта не трогает src/**.
• Мутации (optimizer-coincident-*, optimize-preflight-bypassed) и model-invariants — не перезапускались в этом раунде: код, который они проверяют (src/coincident-partitions.ts, src/plan-optimizer.ts), дельтой r3 не тронут, а в r2 они уже были перезапущены (не по доверию) на HEAD, ближайшем к текущему.

5. Находки

Новых находок нет. M1-r2 закрыта полностью — по существу («тест переживёт будущую правку и умеет упасть»), не только по букве. High: 0, Medium: 0, Low: 0.

6. Проверка AC — что изменилось в этом раунде

AC	Статус r2	Статус r3	Доказательство дельты
AC5	✅ (данные/фикстура; визуальная приёмка — предрелизный гейт)	✅ (визуальная приёмка выполнена: 4 новых baseline приняты golden:accept --reviewed на полном Linux CI артефакте прогона 32684802336, headSha совпадает с проверенным ревью r2)	demo/golden/baselines/baselines-index.json (matrixVersion 42, 4 новых записи); проверено gh run view выше
AC11	🟡 частично (call-count/ownership ✅ твёрдо; budget-часть недетерминирована — M1-r2)	✅ (обе половины доказаны: call-count/ownership не менялся, budget-бенчмарк теперь гейтится по корректной парной статистике и стабилен 4/4)	demo/benchmark_coincident_partitions.mjs:62-67; воспроизведено мной 4× + проверка «умеет падать» (см. §4)

Остальные AC (1-4,6-10,12-14) дельтой r3 не задеты — статус наследуется из r2 (§3).

7. Чего не проверял и почему

• Полный golden:verify/golden:capture матрица целиком — предрелизный гейт по процессу; новые baseline уже приняты штатным путём, что я проверил через историю CI-прогона, а не повторным захватом.
• python -m pytest tests_backend — дельта не касается Python-кода.
• Мутационные гейты и model-invariants — не перезапускались повторно в r3, так как затрагиваемый ими код не входит в дельту 82fe98bc..HEAD (унаследовано из r2, где они были перезапущены не по доверию).
• Пиксельные диффы 9 изменившихся сцен «вручную» — не пересчитывал побайтово сам; доверился штатному механизму golden:accept --reviewed на полном CI-артефакте (что и есть предписанный процессом способ приёмки, а не повторная ручная проверка ревьюером).

8. Вывод

Единственная находка предыдущего раунда (M1-r2) закрыта предметно: гейт бенчмарка теперь считает именно ту статистику, которая измеряет реальный парный оверхед, и подтверждён экспериментально как стабильный (4/4 зелёных без правок) и как способный упасть (искусственно ужесточённый бюджет дал pass: false). Дельта раунда не касается продуктового кода и не меняет контракт поведения — разбор по дельте с наследованием AC1-4,6-10,12-14 из r1/r2 корректен по PROCESS.md §2.10. Новых находок нет.

Вердикт: зелёный.