Close the codeblocks drift: stale baselines, and cancel the GHCR plan it justified - #593
Merged
Conversation
…k it justified Re-recorded linux/ on master (dc11791, all 55) and ran local bin/dtest against it: 55 screenshots compared, no failures. Debian ARM and Ubuntu ARM are pixel-identical. The drift that produced five explanations over three weeks was old amd64/Chrome-152 recordings compared against current renders. Because a green gate and a blind gate look the same, the instrument was checked before the result was believed: forcing background-color #ff0000 on .post-article .highlight pre produced 16 failures - all 8 desktop plus all 8 mobile codeblocks keys and nothing else - and reverting returned it to 0. Clean 0 -> injected 16 -> reverted 0. The consequence worth the most is a deletion. The GHCR container-publishing plan - publish this 2.54 GB image, run CI inside it - existed solely to close a Debian-vs-Ubuntu gap by construction. There is no gap, so it is cancelled rather than left in the doc as a tempting someday. The rejected alternative, a split where CI owned pixel truth and dtest was merely behavioural with divergent keys screened, is dead too: an expected-red list is what rotted into "everything is expected red" before #566. What replaces both: bin/dtest is authoritative for DETECTING visual defects, so a local red is a real defect and there is no expected-red list. CI keeps RECORDING, because the agreement is measured rather than structural - Debian and Ubuntu upgrade freetype independently, so it can end with nothing in this repo changing. Reopen only on a dtest red that a master re-record then makes green. Two rules added, both about the shape rather than this drift: - Suspect the baselines BEFORE the mechanism. All five theories were stories about a mechanism; none was a check on the instrument. "Are these current?" is the cheapest question available and would have ended it in a day. - Two observers agreeing proves nothing when they share the input under test. Local and CI failing the same 8 keys read as corroboration and was an artifact - both were reading the same stale baselines, so every hypothesis predicted red on both. Also records why this family and not another: dense monospace text is where any rendering difference lands first, so the codeblocks screenshots are the suite's canary, not an arbitrary victim - which is why they kept looking like evidence for whichever theory was current. And docs 20.10's O3 entry is corrected; it asserted "the 10 red Linux baselines are NOT stale", which was exactly backwards and was repeated for three weeks. Gates: OKF 0 ERRORs, bash -n clean, unit 289 runs / 6185 assertions / 0 failures, hugo-build green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011SP5gaqXEgUie8pdFrmbeJ
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
1 participant
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.
What
Closes the screenshot drift that produced five wrong explanations over three weeks, and cancels the work that drift was being used to justify.
The answer was stale baselines. Not emulation, not arch, not the tolerance change, not the merge-commit checkout, not Debian-vs-Ubuntu.
Evidence
Re-recorded
linux/on master (dc11791ab, all 55), then ran localbin/dtestagainst it:Debian ARM (local container) and Ubuntu ARM (CI) are pixel-identical.
The gate was verified before the green was believed — a green gate and a blind gate look the same:
55 compared, no failuresbackground-color: #ff0000on.post-article .highlight pre55 compared, no failuresConsequences
bin/dtestis authoritative for DETECTING visual defects. Local red = real defect. No expected-red list — which is what rotted into "everything is expected red" before Re-record 127 stale baselines and delete the tolerance shield #566.Two rules added
Also corrects
docs/20.10O3, which asserted "the 10 red Linux baselines are NOT stale" — exactly backwards, and repeated for three weeks.Gates
OKF 0 ERRORs ·
bash -nclean · unit 289 runs / 6185 assertions / 0 failures ·hugo-buildgreen ·bin/dtestgreenDocs + one comment block; no functional change.
🤖 Generated with Claude Code
https://claude.ai/code/session_011SP5gaqXEgUie8pdFrmbeJ