Don't call an unstyled top bar drift; it means the page wasn't ready #17

Merged
geusebio merged 1 commit from fix/unstyled-chrome-is-inconclusive into main 2026-08-09 10:59:55 +00:00
Owner

The first live run filed #16 against PrintShop, telling an entirely up-to-date app that it was pinned to an old grey-ooo/brand-kit and should run composer update. It is a false positive, and the mechanism is worth writing down.

What happened

From the CI runner, printshop.grey.ooo answered with its @splash interstitial — visible in the debug toolbar of the screenshot the job attached to #16. That page carries the topbar markup and the full six-entry roster, but not brand-kit.css.

The result measures as:

  • an auto-height 1394px bar
  • every --gooo-* token resolving to empty
  • nothing logged as an error, because nothing failed

The confirmation pass is powerless against it: the splash is served consistently on a cold hit, so both visits agreed perfectly on the same wrong answer. Local runs never reproduced it because a warm app serves the real page and conforms.

Gating measurement on load — added while building this — did not help either. The splash had loaded.

The fix

Wait for the stylesheet to have visibly taken effect (the bar actually being --gooo-topbar-h tall), and if it never does, refuse to judge the app at all: recorded as unreachable, run goes red, the app's ticket left exactly as it was.

This follows the rule the harness already claimed to follow and didn't quite: chrome present but unstyled means "the page wasn't ready", not "this app is stale".

It gives up ticketing a stylesheet that genuinely 404s. That is the right trade — a missing sheet is hardly ever explained by the consumer's version pin, and the pin is the only thing a drift ticket knows how to say. badResources in summary.json still separates a real 404 from an app that was mid-boot, and now carries into the failure message.

The height check therefore stops being a finding and becomes the gate, so it is gone from the checks list. The empty-token case it used to double up on is reachable on its own now.

Verification

  • Blocking brand-kit.css against a live app reproduces the exact 1394px signature and is now thrown as inconclusive rather than checked as drift.
  • Full local audit unchanged for the other five apps: someones.computer 4 problems, niall.chat 3, stuff.grey.ooo 2, git.grey.ooo 1, grey.video conforms — and printshop conforms.

Follow-up

#16 should be closed as a false positive once this is on main; the next run will not re-file it. Left open for now so the evidence stays attached to it.

PrintShop's splash is expected behaviour, not a defect: printshop.grey.ooo is a staging
deployment, so it runs in debug mode and serves its assets through PHP, which is what makes
a cold hit slow enough to show an interstitial at all. It is still the canonical PrintShop
URL in GreyOooApps::ALL and the one users reach from the switcher, so it stays in scope for
conformance — this fix is what makes checking it reliable rather than a reason to drop it.

The first live run filed #16 against PrintShop, telling an entirely up-to-date app that it was pinned to an old `grey-ooo/brand-kit` and should run `composer update`. It is a false positive, and the mechanism is worth writing down. ## What happened From the CI runner, `printshop.grey.ooo` answered with its `@splash` interstitial — visible in the debug toolbar of the screenshot the job attached to #16. That page carries the topbar markup and the full six-entry roster, but not `brand-kit.css`. The result measures as: - an auto-height `1394px` bar - every `--gooo-*` token resolving to empty - **nothing logged as an error**, because nothing failed The confirmation pass is powerless against it: the splash is served consistently on a cold hit, so both visits agreed perfectly on the same wrong answer. Local runs never reproduced it because a warm app serves the real page and conforms. Gating measurement on `load` — added while building this — did not help either. The splash *had* loaded. ## The fix Wait for the stylesheet to have visibly taken effect (the bar actually being `--gooo-topbar-h` tall), and if it never does, refuse to judge the app at all: recorded as unreachable, run goes red, the app's ticket left exactly as it was. This follows the rule the harness already claimed to follow and didn't quite: **chrome present but unstyled means "the page wasn't ready", not "this app is stale".** It gives up ticketing a stylesheet that genuinely 404s. That is the right trade — a missing sheet is hardly ever explained by the consumer's version pin, and the pin is the only thing a drift ticket knows how to say. `badResources` in `summary.json` still separates a real 404 from an app that was mid-boot, and now carries into the failure message. The height check therefore stops being a *finding* and becomes the *gate*, so it is gone from the checks list. The empty-token case it used to double up on is reachable on its own now. ## Verification - Blocking `brand-kit.css` against a live app reproduces the exact `1394px` signature and is now thrown as inconclusive rather than checked as drift. - Full local audit unchanged for the other five apps: someones.computer 4 problems, niall.chat 3, stuff.grey.ooo 2, git.grey.ooo 1, grey.video conforms — and printshop conforms. ## Follow-up #16 should be closed as a false positive once this is on `main`; the next run will not re-file it. Left open for now so the evidence stays attached to it. PrintShop's splash is expected behaviour, not a defect: `printshop.grey.ooo` is a staging deployment, so it runs in debug mode and serves its assets through PHP, which is what makes a cold hit slow enough to show an interstitial at all. It is still the canonical PrintShop URL in `GreyOooApps::ALL` and the one users reach from the switcher, so it stays in scope for conformance — this fix is what makes checking it reliable rather than a reason to drop it.
The first live run (#16) told PrintShop, which is entirely up to date, that it
was pinned to an old brand-kit and should run `composer update`. From the CI
runner the app answered with its `@splash` interstitial, which carries the
topbar markup and the full roster but not `brand-kit.css`. That measures as an
auto-height 1394px bar with every `--gooo-*` token empty, and nothing is logged
as an error because nothing failed — so the confirmation pass saw the identical
result twice and waved it through. Reproducing it needs a cold hit; a warm app
serves the real page and conforms, which is why local runs never showed it.

Gating on `load` was not enough: the splash *had* loaded. So wait for the
stylesheet to have visibly applied — the bar actually being `--gooo-topbar-h`
tall — and if it never does, refuse to judge the app at all. Recorded as
unreachable, run goes red, the app's ticket left untouched.

This gives up ticketing a genuinely 404ing stylesheet, which is the right
trade: a missing sheet is hardly ever explained by the consumer's version pin,
and that pin is the only thing a drift ticket knows how to say. `badResources`
in summary.json still separates a real 404 from an app that was mid-boot.

The height check therefore stops being a finding and becomes the gate, so it is
gone from the checks; the empty-token case it used to double up on is now
reachable on its own.

Verified by blocking brand-kit.css against a live app: reproduces the exact
1394px signature and is thrown as inconclusive rather than checked as drift.
The other five apps are unaffected — same results as before the change.
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/symfony-brand-kit!17
No description provided.