no reader row on any registry has a currency check, so the support window goes stale silently

[rubenhensen]

Question

Nothing in this fleet notices when a new SDK version publishes, so the reader list goes stale silently and is only ever corrected by someone tripping over it. What watches it, and where does that watcher live?

Split out of #327, which found it while answering a narrower question.

The gap, measured

Both halves of the reader list in COMPATIBILITY.md are stale right now, and both gates that guard it are green:

row	pinned	published	gate that reads it
crates.io pg-core	0.6.1 (moving to 0.6.3 in #352)	0.6.3	pg-compat/tests/support_window.rs
npm @e4a/pg-wasm	0.6.1	0.6.3	pg-compat-js/test/manifest.test.mjs

Both gates check internal consistency and nothing else: the Rust one compares the document's rows against pg-compat's readers(), the Node one compares the document's rows against the installed alias's own package.json. Document versus install, never install versus registry. So a row can be years old with every check passing.

This is the root cause under #268 and #327 both — and note #268's framing, that "the crates.io rows are unchecked", was only half of it. The npm rows are checked, just not for the property that goes stale.

Why the obvious reuse does not work

The first answer was to reuse postguard-e2e#22's publish-watcher, which already opens a PR when a new SDK version ships. Checked, and it cannot reach:

1. compat/registries.mjs:8-11 — registryOf handles npm and nuget and throws on anything else. There is no crates.io backend. (One implementation note if it gains one: crates.io's API rejects requests without a User-Agent.)
2. It rewrites its own repo's compat/manifest.json and its coupled pins. Aiming it at this repo means cross-repo PR writes, needing a credential this fleet has deliberately not granted — the same trade-off #332 and #334 are weighing. Decide them together if more than one wants a credential.

The schedule: tension, which is not a contradiction

#318 deliberately gave its drift detector no schedule:, reasoning that a disarmed gate can only do harm when something merges, that every merge already fires a pull_request and a push run, and that a nightly nobody reads would be a silent gate about a silent gate.

That reasoning does not transfer here, and the difference is the whole point. A ruleset drifts because someone edited something, so a merge-triggered check always fires on the change that caused it. A reader row goes stale because the world changed — a version published in another registry, with no commit in this repo — so a merge-triggered check never fires at all. The event that matters happens while nobody is pushing.

Say this explicitly wherever it lands, or the next person reads the two decisions as contradictory and reverts one.

To settle

1. Scheduled job here, or teach the e2e watcher crates.io plus a cross-repo token? The first is self-contained and needs no credential; the second centralises the logic but pays the credential price and couples two repos' release paths.
2. What it does on a finding — open a PR moving the row and the pin (the e2e watcher's shape, and the only one that produces something mergeable), or fail loudly and leave it to a human. Note a PR here is not a two-line edit: moving the crates.io row means regenerating pg-compat/Cargo.lock, and moving an npm row means reinstalling an alias.
3. Whether staleness should ever be an error rather than a notification. A row two patches behind is not a broken gate — it is a gate testing an older reader than it claims. That is weaker than advertised but not wrong, so a red build may be the wrong instrument.
4. The nuget E4A.PostGuard 0.6.0 row, which is declared-but-ungated by decision in #268 and would be covered for free by anything that watches registries. Fold it in or restate why not.

The half a coding agent cannot do

A scheduled job in this repo means a file under .github/workflows/, and the dobby-coder App lacks workflows: write — the push is rejected at the remote. Whoever builds this ships the pushable half (script, tests, documents) and hands the maintainer ready-to-paste YAML. Confirm the handover comment exists at the URL it is claimed to be at: this map has one recorded case (#324) of a handover being reported and never posted.

Part of #247 (workstream C).

[rubenhensen]

Item 4 has a different answer than "gate it or restate why not": the nuget row is not a reader row at all

Found on 2026-08-19 while working #348, which had to decide whether the sender-spoofing advisory needed a NuGet row.

COMPATIBILITY.md's Reader list carries nuget E4A.PostGuard 0.6.0, and the list is defined as "the list the compat gates install and run as readers". E4A.PostGuard cannot read a container. pg-ffi, which the .NET SDK binds, exports exactly three symbols — pg_seal, pg_free, pg_last_error (pg-ffi/src/lib.rs on origin/main, three #[no_mangle] sites) — and this is not a recent narrowing:

$ git log --all --oneline -S"pg_unseal" -- pg-ffi
(empty)
$ git show origin/main:pg-ffi/src/lib.rs | grep -ci unseal
0

A pg_unseal has never existed anywhere in the crate's history. The row names a sealer.

This reframes item 4 rather than answering it. The row is "declared-but-ungated by decision in #268", which reads as a coverage gap to be closed later — but a currency check on a row whose package can never satisfy the row's own definition buys nothing. Three candidate answers, and the choice is a scoping decision this ticket already owns:

1. Drop it from the Reader list and, if the .NET seal surface is worth pinning, give it a separate declared row with its own name (Sealer list, or a direction column). Cheapest and stops the document asserting something false.
2. Keep it and gate it, accepting that what is being checked is "the pinned NuGet version is current", not "this reader opens our containers" — which is a currency check with no compat check behind it, and worth saying out loud in the document if chosen.
3. Redefine the list as "published artifacts in the support window" rather than readers, which makes the row honest but weakens what the heading promises about the rows that are readers.

Note the machine-read constraint from root CLAUDE.md before touching the block either way: pg-compat-js/test/manifest.test.mjs parses the fenced <registry> <package> <versions...> rows and pg-compat/tests/support_window.rs reads the same block, so adding a column or a second block is a change to both gates, not just to the document.

One aside that lands on item 1 rather than item 4: the crates.io User-Agent requirement noted in this ticket is real and it fails in a way that looks like a different bug — an unset UA returns a body with no versions key, which reads as "the crate was never published" rather than as a rejected request. Measured again on 2026-08-19 against pg-core, pg-cli, pg-ffi and pg-pkg; with a UA set, the two unpublished ones (pg-ffi, pg-pkg) return an errors key, which is how you tell the two cases apart.