I2: exercise privileged identities on a schedule — a green job that did nothing is not evidence

[bdelanghe]

Implements I2 of docs/session-capability-invariants.md — a privileged capability is exercised on a schedule, not only when needed. Currently graded Aspirational: nothing does this.

The evidence

registry-graph.yml reported success on every weekly scheduled run for over a month. The App identity it uses, bounded-systems-front-desk[bot], has never once successfully pushed to this repo.

Both statements are true because the job early-exits:

[ -z "$(git status --porcelain)" ] && { echo "in sync"; exit 0; }

Success meant "the registry hadn't changed". The proof is the absence of any branch either job would have left behind:

$ git ls-remote --heads origin | grep -E 'bootstrap-pin/bump|registry-graph/'
(no output)

Merging #84 was simply the first time anything needed that push, and it 403'd (#87). registry-graph.yml carries the identical latent failure and is not red today only because it has had no work to do — it will fail the first time the registry actually changes.

Why a scheduled probe rather than better assertions

#87 adds a preflight that would catch the missing scope at mint time — but only on a run that reaches the mint step with work to do. A capability nothing exercises stays unverified however good the assertions around it are. The gap here is temporal, not logical.

Shape

One scheduled workflow per privileged identity. Mint the token, push a no-op branch, delete it, fail loudly on any non-200. Report the identity and the operation in the failure so the log names what is missing.

This is the ticket-window pattern (board-parity.yml #58, claim-ticket.yml #61) turned on the org's own plumbing rather than on the board — the same argument, one layer in.

Worth considering: emit the last-successful-exercise timestamp somewhere durable, so "N days since this identity last worked" is a readable number rather than something reconstructed from run history and git ls-remote, which is how it was found today.

Done when

• Each privileged identity has a probe that fails if its grant were removed.
• The probe's failure names the identity and the operation, not a bare 403.
• Removing a grant in a test installation turns the probe red within one cycle.

Blocked

Cannot go green until #87 grants contents: write. That is a feature — a probe that passes today would be lying. Land it red, or land it alongside the fix.

[bdelanghe]

Unblocked, one prediction confirmed, and a constraint that changes the shape

1. The "Blocked" section is discharged

Cannot go green until #87 grants contents: write.

#87 is closed. The diagnosis in its title was wrong, which matters here: it was never the App installation. The broker's front-desk entry never requested contents, and it could not be given any — contents is privileged (infra#140) and front-desk is the unpinned fan-in entry, so unsafePrivilegedApp() would refuse it outright. The fix was a separately pinned entry (infra#172). A probe can now land green rather than deliberately red.

2. This issue's second prediction was correct

registry-graph.yml carries the identical latent failure and is not red today only because it has had no work to do.

Verified — all three defects, untouched by the #87 work:

app: front-desk                                   # no `contents`
require: contents, pull_requests                  # asserts it...
GH_TOKEN: steps.app-token.outputs.token || …      # ...then ignores the verdict
git push origin "$b"                              # 403

Fixed in #100 / infra#176 before it fires, rather than after a fifth hand-repair.

3. The constraint: a central probe workflow cannot work

This is the part that changes the design, and it was not visible when this was filed.

A GH_APPS entry's workflowRef pins exactly one workflow ref. (Singular — unlike DOLTHUB_CREDS, which takes workflowRefs.) The broker matches it exactly and refuses otherwise; unsafePrivilegedApp requires the pin for any privileged permission, so no privileged identity can be left unpinned to make a probe convenient.

So the shape proposed here — "one scheduled workflow per privileged identity", read as a probe workflow that mints and exercises each — cannot mint any of them. It would be a different workflowRef, and every privileged entry would refuse it. The stronger the pinning, the less a central prober can reach.

Three ways out, and the choice is a real one:

	how	cost
A. Probe mode inside each pinned workflow	a schedule: trigger + a no-op branch push/delete in the workflow that already owns the pin	exercises the actual identity and ref; adds a branch of logic to each privileged workflow
B. A second entry per identity, pinned to the probe	front-desk-pin-probe, etc., pinned to probe.yml	one central prober; but it exercises a different registry entry, so it proves the App's grant, not the entry the real job uses — the exact failure being probed for would slip through
C. Make workflowRef accept a list	broker change, mirroring DOLTHUB_CREDS.workflowRefs	one prober that exercises the real entries; widens each pin to two refs, and the Lean model + check-sync follow

A is the recommendation. B looks tidiest and is the one that would fail silently — a probe that green-lights an entry nobody uses is a green job that did nothing, which is this issue's own thesis. C is defensible and the most work.

Worth noting the .github-side half of #87 is a partial substitute already: honouring the require: verdict means a scope gap now produces a named error and a pushed branch instead of a bare 403. That narrows the blast radius on each occurrence, but it is still only checked when the job has real work — the temporal gap this issue is about is untouched.

Current state of the identities

front-desk-pin is verified live (MINT: success on a re-run of org-defaults, 2026-08-03). front-desk-registry is merged-pending-deploy. Neither has yet exercised the git push that follows the mint — both jobs early-exit when there is nothing to do, which is exactly why this issue exists.

---

Generated by Claude Code