Repository navigation
Nothing detects drift between the reviewed root page and the bytes actually served #16140
Description
The gap
site/mrveiss.github.io/index.html is the reviewed source. The bytes actually served at https://mrveiss.github.io/ come from a manual copy into a separate repository that holds index.html and nothing else.
They are identical right now — verified at closure of #16135:
git show origin/Dev_new_gui:site/mrveiss.github.io/index.html 11965 bytes
curl https://mrveiss.github.io/ 11965 bytes, 200
cmp IDENTICAL
That is a measurement, not a property. Nothing re-checks it.
Why the manual copy should stay
The README states the reason and it is a good one: the root site is the first thing a visitor sees, and a push reaching it without a human reading the diff is a worse failure than a page that is briefly stale. This issue does not propose automating the deploy. Automating it would trade a visible staleness for an invisible one.
What is actually wrong
The copy being manual is a design decision. The copy being unverified is not — it is the absence of a check, and it fails in the direction that produces no symptom:
- source edited, copy not made → the repository looks reviewed and current; the live page is stale, and reviewing the source is what convinces you it is not
- copy edited directly in the deploy repository → the live page carries content that never passed review, and the source still looks like the source of truth
Both states look correct from whichever side you are standing on. A divergence between a reviewed artefact and a deployed one is only visible to something holding both, and nothing holds both.
This is the same shape as the npm audit gate in #16131: an artefact that is trusted because a nearby thing was checked.
Acceptance criteria
- A check compares the tracked
site/mrveiss.github.io/index.htmlagainst the bytes served at the deployed root, and fails on any difference - The failure message states which side is ahead, so the reader knows whether the fix is "copy the file" or "someone edited the live page directly"
- The check runs on a schedule rather than only on PRs touching that path — a copy that was never made produces no PR, so a path-triggered check cannot see the case it exists for
- A fetch failure is reported as could not check, never as a pass — the guard must distinguish no difference from did not look
- The manual copy step is unchanged; the deploy stays deliberate
Related
- The user root https://mrveiss.github.io/ is a 404 — no landing page for the three public repos #16135 — the landing page; closed on evidence that the two matched at that moment
- feat(site): a landing page for the user root, which is currently a 404 (#16135) #16136 — the PR that added the source
- The npm audit gate scans one of thirteen tracked package.json files, and an unaudited one pinned a vulnerable js-yaml #16131 — the same "trusted because something adjacent was checked" shape, in the npm audit gate
Activity
docs(process): a rule that costs something when it applies gets skipp…
mrveiss commentedon Sep 9, 2026
Dissolved, not fixed — the failure mode no longer exists
This issue asked for a detector for drift between the tracked source and the served bytes. An operator design change removes the thing that could drift: everything site-related moves out of
AutoBot-AIintomrveiss/mrveiss.github.io, where the page is now both authored and deployed.There is no copy step, so there are no two sets of bytes. A detector for divergence between one file and itself has nothing to report.
Closing this as dissolved rather than fixed matters, because the two are not interchangeable. A fix would mean the guard exists and passes. Nothing was built here — the design changed underneath the issue, and saying so plainly is the difference between a closed issue that is honest and one that will be read later as evidence a check exists.
Each criterion, against the new shape
site/…/index.htmlagainst served bytesWhat survives, and where it went
The fourth criterion is the durable one, and it is not being dropped on the floor. Its principle — a guard must distinguish no difference from did not look — is now carried by
mrveiss.github.io#2, filed against a real and currently unguarded gap: that repository has no CI at all (.github/workflows→ 404), so nothing checks the page's content before it deploys. Its final criterion is that a failure names which assertion failed, distinguishing a failed check from one that did not run.That is a different failure from this issue's. This one was the reviewed bytes and the served bytes disagree. The new one is the bytes are wrong before they are ever served — front matter that silently re-enables the theme layout, an unbalanced script tag, a dead link, consent defaults moved after
gtag.js. The old design's review-and-CI half caught some of that by inheritance; the new design has to earn it back explicitly, and it currently has not.Related: #16145 closed as relocated · #16149 removes the tracked tree · #16135 criteria re-read against the new shape
docs(process): four corrections found in review, two of them missing …
refactor(site): remove the root-page copy, its source is now one repo (…