The data is confirmed, the conclusion I disagree with. Not fixing it here — reasoning below, and it needs a decision from a human rather than an edit from me.
Confirmed. Two rows do invert, and only two:
mobile-documents-search lcp 2311 fcp 2329.335
mobile-dsm lcp 2319 fcp 2325.841
Not from this PR. These rows arrived in 669640b ("refresh Lighthouse budget baseline for HeadlessChrome/151", #1690), a Copilot-authored commit that repo automation pushed onto this branch. My only edit to that file is 0b07be4, which ran Prettier over it (0.060 → 0.06, 0.080 → 0.08) because format:changed was failing the required Static PR checks job on the unformatted blob. The base at da66b28 has no inverted rows.
"Regenerate from complete reports" cannot be done from here, and would not hold. All ten rows carry integer lcpMs against fractional fcpMs, which is the generator's own rounding, not two report sets spliced together — and the two inversions are 18ms and 7ms, i.e. inside that rounding on runs where LCP and FCP land on the same paint. Regenerating means running the Lighthouse job, and this container measures on a different Chrome build than CI, which is the drift that produced the mess in the first place. Hand-editing measurement data to satisfy an invariant is the one thing that must not happen to a baseline file.
There is a live problem here, but it is a different one. The refresh has made the advisory job worse, not better. On 0b07be4 it failed again with the comparison reversed — baseline now HeadlessChrome/151, run measured on HeadlessChrome/150 — so Nothing is graded from this run, all ten routes, exactly as before. The CI runner pool is not homogeneous, so any single pinned baseline browser will mismatch on some runners and the gate will keep reporting evidence-incomplete regardless of how often the baseline is refreshed. That wants either a pinned runner image or a version-tolerant comparison in scripts/check-lighthouse-budget.mjs — a change to the gate, not to the data, and out of scope for a phone-layout PR.
Suggested disposition: the lcpMs >= fcpMs guard you propose is a reasonable thing to add to check-lighthouse-budget.mjs, alongside the runner-drift fix, in a PR that owns that script. I have not added it here because a guard that rejects rows the generator itself produces would turn an advisory job into a blocking one for reasons unrelated to any diff that trips it.
Generated by Claude Code
Originally posted by @BigSimmo in #1689 (comment)
The data is confirmed, the conclusion I disagree with. Not fixing it here — reasoning below, and it needs a decision from a human rather than an edit from me.
Confirmed. Two rows do invert, and only two:
Not from this PR. These rows arrived in
669640b("refresh Lighthouse budget baseline for HeadlessChrome/151", #1690), a Copilot-authored commit that repo automation pushed onto this branch. My only edit to that file is0b07be4, which ran Prettier over it (0.060→0.06,0.080→0.08) becauseformat:changedwas failing the required Static PR checks job on the unformatted blob. The base atda66b28has no inverted rows."Regenerate from complete reports" cannot be done from here, and would not hold. All ten rows carry integer
lcpMsagainst fractionalfcpMs, which is the generator's own rounding, not two report sets spliced together — and the two inversions are 18ms and 7ms, i.e. inside that rounding on runs where LCP and FCP land on the same paint. Regenerating means running the Lighthouse job, and this container measures on a different Chrome build than CI, which is the drift that produced the mess in the first place. Hand-editing measurement data to satisfy an invariant is the one thing that must not happen to a baseline file.There is a live problem here, but it is a different one. The refresh has made the advisory job worse, not better. On
0b07be4it failed again with the comparison reversed — baseline now HeadlessChrome/151, run measured on HeadlessChrome/150 — soNothing is graded from this run, all ten routes, exactly as before. The CI runner pool is not homogeneous, so any single pinned baseline browser will mismatch on some runners and the gate will keep reporting evidence-incomplete regardless of how often the baseline is refreshed. That wants either a pinned runner image or a version-tolerant comparison inscripts/check-lighthouse-budget.mjs— a change to the gate, not to the data, and out of scope for a phone-layout PR.Suggested disposition: the
lcpMs >= fcpMsguard you propose is a reasonable thing to add tocheck-lighthouse-budget.mjs, alongside the runner-drift fix, in a PR that owns that script. I have not added it here because a guard that rejects rows the generator itself produces would turn an advisory job into a blocking one for reasons unrelated to any diff that trips it.Generated by Claude Code
Originally posted by @BigSimmo in #1689 (comment)