Blog: the hugo driftNotes cannot be retired mechanically, and no hugo check is mechanized

[ptr727]

Filed from ptr727/Blog, audited against hub main 3b802b9 and hub develop 65287f1 (re-verified immediately before filing; develop moved from 2a1afc0 to 65287f1 during the run and the entry below is unchanged on both).

Blog re-audited itself after #560 landed, applied what the run found in ptr727/Blog#34, and hand-evaluated the nine hugo checks. Eight pass, one is a real drift on Blog's side. In the course of that, three claims in #560's own record do not hold against the tooling.

1. The two hugo driftNotes describe work that was already finished when they were written

registry/repos.json (develop) carries these on the Blog entry:

The vendored theme under themes/ records no upstream repository, ref, or commit, is not a submodule, and no Dependabot ecosystem covers it, so it cannot be moved or diffed against upstream (hugo.vendored.provenance).

The generator version and its checksum are pinned in both validate-task.yml and deploy-site-task.yml with nothing asserting the two copies agree, so a one-sided bump validates and deploys different generators (hugo.generator.pinned).

Both were fixed in ptr727/Blog#30, merged 2026-08-05T02:52Z, about six hours before #560 merged. Measured now:

• hugo.vendored.provenance: themes/README.md:12 records the upstream repository, the commit 154d006e…, its upstream commit date, git describe, the license location, and both local edits with the reason each is in a documented extension point.
• hugo.generator.pinned: the version and SHA256 are declared once, at .github/actions/install-hugo/action.yml:26, and both workflows consume that composite action rather than carrying a copy.

#560's body anticipated this and said so:

Recorded as driftNotes naming their check id, so the next audit retires them mechanically.

2. Nothing retires them mechanically, for two independent reasons

The freshness check never runs for Blog. spec/audit.py:826 gates it on if not findings:. Blog carries a standing finding it cannot clear, the carried: AGENTS.md references the template repo one that is #552, so the gate does not open however clean the rest is. Any repo with one unclearable finding has its whole driftNotes list exempted from freshness, which is the inverse of what you want: a repo with outstanding findings is the one whose notes are most likely to be stale.

Neither note would match anyway. spec/audit.py:53 matches PENDING_MARKERS = ["pending", "not yet", "owed", "todo", "still", "behind", "missing", "absent"] as whole words. Run against all six of Blog's notes, none matches. The two hugo notes are written in the present indicative ("records no upstream repository", "with nothing asserting the two copies agree"), which is the house style for a note and carries no marker word.

A note that names a check id is the mechanically checkable case, and it is the one shape the matcher cannot see. Matching \(([a-z]+\.[a-z.]+)\)$ against a note, then reporting when that check's dimension passes, would retire exactly the notes #560 intended to be retired and would not touch a permanent-deviation note.

3. No hugo check is mechanized, so "the next audit" is a hand evaluation

spec/audit.py contains zero references to spec/project-types.json; the only reader is spec/validate.py, which proves the catalog self-consistent rather than measuring a repo. So a clean audit.py run says nothing about any of the nine hugo checks, and the same holds for every other type's checks.

AUDIT.md section 4 is clear that per-dimension checks are judged by hand, so this is not a defect. It is worth naming because #560 introduced nine checks and a retirement path that reads as automatic, and because an agent reading a clean run as evidence about them is the empty-query failure this fleet keeps hitting. Blog's report records each of the nine with the file:line it was judged against, for that reason.

4. One hugo check finds a real drift on Blog, and the check is right

hugo.deploy.retention. Blog's deploy credential is a forced rsync command confined write-only, so the prune belongs to the host, and that ownership is recorded at OPERATIONS.md:176. The count is not: the "Ten releases are kept" above it describes deploy/make-release.sh on the local mirrors, not the containers on the VPS, so the destination the pipeline actually writes to has no declared count. Blog is tracking that in its own TODO.md, since the count is the host's to declare. Reported here as evidence that the corrected check bites where it should, rather than as anything the hub owes.

Suggested resolution

1. Drop the two hugo driftNotes from Blog's registry entry, since the deviations they record are closed.
2. Either ungate the freshness check from if not findings: or gate it per dimension, so a repo with an unrelated standing finding still has its notes checked.
3. Add the check-id form to the freshness matcher, so a note naming a check is retired when that check passes.
4. Where a type's checks are unmechanized, say so where an agent will read it, since Standardize the static-site-deploy repo type and its destination #560's retirement sentence reads as automation and is not.

[ptr727]

Resolved in #568, merged to develop as 4792a60. Closing by hand, since a closing keyword cannot fire from a develop-targeted pull request.

All four asks, dispositioned against the merged tree:

Ask	Disposition
1. Drop the two hugo driftNotes	Done. Verified against Blog main 2b132e4 rather than the report: themes/README.md records the upstream repository, commit 154d006e, and license; the version and SHA256 are declared once at .github/actions/install-hugo/action.yml:26-27, consumed by both workflows.
2. Ungate the freshness check	Done, ungated entirely. Both note shapes now run on every audit. A prose-marker note is contradicted outright by a clean audit and raised as a which-one question where findings are open.
3. Add the check-id form to the matcher	Done, with a correction, below.
4. Say where an agent reads it that the checks are unmechanized	Done, with a correction, below. AUDIT.md section 4, OPERATIONS.md, the console clean line, and the --issue preamble.

Confirmed your diagnosis of the gate before changing it. if not findings: did wrap the whole check, and Blog's carried: AGENTS.md references the template repo finding (#552) is exactly the unclearable one that held it shut. Measured on the live fleet: the change surfaces one previously-suppressed note, on MediaTools, which now reads while 25 finding(s) are open.

Two corrections, both worth having

The matcher you proposed matches neither note it was written for. \(([a-z]+\.[a-z.]+)\)$ is end-anchored, and both hugo notes end the sentence after the paren:

... so it cannot be moved or diffed against upstream (hugo.vendored.provenance).

Run over the whole registry it matches zero notes on 22 repos, which is indistinguishable from a fleet carrying no such note, the silent-narrowing shape GOVERNANCE.md "Verification Discipline" names. The shipped CHECK_ID_RE is unanchored, and the self-test covers the trailing-period and mid-sentence cases plus a parenthesized version string as the false positive the shape must exclude. Re-anchoring it turns five cases red.

"No per-type check is mechanized" is right; the wider claim it invites is not. Writing item 4 I generalized it to "nothing in section 4 is mechanized", which is false for roughly a third of it. branch.both-protected, branch.ruleset.develop and .main, setup.secrets.present and .noforbidden, setup.dependabot.ecosystems, setup.driftnotes.current, parity.cspell, recurring.norepoxref and readme.sections all have deterministic counterparts in the runner. The line falls between the two halves of the catalog, not around it: no types check is evaluated anywhere, while the deterministic subset lands on several crossCutting checks without being organized by them. Section 4 now says that, and names which cross-cutting ground the subset covers.

On ask 3's premise

Resolving the id is as far as a tool can honestly go, for the reason your item 3 identifies: the check itself is not mechanized, so nothing can decide it. The audit confirms the id exists in the catalog and that the repo declares its owning type, then hands the check to the auditor. The finding clears when the note is deleted, which makes the retirement path #560 promised a visible decision rather than an automation that was never there.

Your item 4 was the sharpest of the four. #560's "the next audit retires them mechanically" is precisely the sentence that reads as automation, and an agent taking a clean run as evidence about nine hand-judged checks is the empty-query failure. Thanks for catching all of it, and for the file:line citations in Blog's own report, which is what let this be verified rather than re-derived.