perf: refresh the machine-pinned render baseline - #37
Merged
Conversation
PostCSS resolution changed bun.lock, which is part of the controlled harness fingerprint, so the approved baseline could no longer validate fresh captures. Record ten clean balanced-power rounds on the pinned 12900H host and promote them with the fail-closed generator. A diagnostic using the old numeric limits and the new harness fingerprint found no statistically detected regression across all 28 cells. Retain the raw JSON and Markdown beside the promoted baseline, and align the runbook's declared power mode with the recorded runner profile.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#35 changed
bun.lockto resolve patched PostCSS.bun.lockis intentionally part of the controlled render harness fingerprint, so the approved baseline became stale even though runtime code did not change. Every localbench:checkstopped before timing analysis with the one expected mismatch:harness.sources.bun.lockand its aggregate digest.Evidence
Captured ten clean, counterbalanced rounds on the pinned host:
7.1.3-2-cachyos, x641.3.14, Node24.3.0, Chromium149.0.7827.55balanced1Before promotion, I replaced only the old baseline's stale harness fingerprint in a temporary diagnostic copy and ran the strict comparator against the new capture. That preserved every old numeric limit. Result: all 28 cells passed; no statistically detected regression. Worst Sheetwrite median ratio was
1.111×forscroll-right.top-left, below the existing ratio/noise decision.The committed baseline was then produced by
generate-baseline.ts --write-baseline, not edited by hand. The exact raw JSON and generated Markdown are retained asrender-baseline-raw.*; the baseline records the raw path and SHA-256.A final baseline-vs-own-capture check passes all cells at
1.000×. That final check proves fingerprint/provenance consistency only; the old-limit diagnostic above is the non-circular regression evidence.Runbook correction
The runbook said
--power-mode performance, while the actual pinned baseline and controlled host usebalanced. Correct the reproduction commands and remove the stale claim that no approved baseline exists. CI still runs deterministic smoke matrices and broad ceilings; matched wall-clock comparisons remain deliberate local evidence.Verification
bun test bench/test/baseline-generation.test.ts bench/test/check.test.ts: 12 pass, 0 failbun run changeset:ci: passes; empty changeset, no package bumpNo runtime source, dependency, workflow, or threshold changes.