Dependency intake 2026-09-01 — the three genuinely new bumps

[bdelanghe]

Third run of bounded-systems/infra#560's intake shape. Small, and prepared so the claim is the only step left.

Approving a claim on this issue is approving these three bumps. Each is pinned to its head commit; a force-push after approval changes the commit and this list stops describing it. The injector re-checks every head_sha immediately before writing a trailer and skips any that moved.

repo	PR	head_sha	bump
bounded.tools	#70	da7e6082	ci: bump the actions group with 5 updates
front-desk-scheduler	#194	5f1355f1	chore(deps): bump the npm group with 2 updates
front-desk-scheduler	#195	50964367	ci: bump the actions group with 6 updates

Re-pinned 2026-09-02 — two of the three moved before anyone tapped

The table above is not the one this issue was opened with. Between opening and the claim, Dependabot rebased two of the three:

PR	pinned at open	now
bounded.tools#70	ee07079b	da7e6082
front-desk-scheduler#194	5f1355f1	5f1355f1 (unchanged)
front-desk-scheduler#195	05860d20	50964367

The cause is known and benign: the org-wide pr-claim roll landed bounded-systems/.github main at 63715f9, and Dependabot regenerated the two action-group PRs against it. Both now bump their .github pins to 63715f9 — i.e. they adopt the repaired pr-claim caller, which is the change we wanted rolled anyway.

Stated rather than silently corrected, because the failure this guards against is exactly the one that just happened. Had the tap landed against the old table, intake-inject.mjs's head_sha re-check would have refused two of the three — correctly, and confusingly. What is being approved is the table at the top, as of this edit.

Note also that #194 is behind rather than blocked: its required checks read as expected, not absent. It needs its base merged in before it can go green — staleness disguised as absence, per the note in .github-private#850.

The count was verified, not carried

Earlier in this workstream the figure "7 newer Dependabot PRs" was quoted from memory and never checked. It was wrong.

GET /orgs/bounded-systems/repos answers 403 from a session, so the org cannot be enumerated the obvious way. Instead all 46 known repo names (from the two prior intake plans plus the attached set) were probed individually — all 46 readable, none skipped. Result: 5 open Dependabot PRs, two of which are hooksmith#134 and #135, already handled under #324.

So three are genuinely new. If a repo exists outside those 46 names, it is not in this denominator — stated because a coverage number over an unstated set is the failure .github-private#368 is about.

Why these are not being folded into #324

#324 is open and claimed, and it would be trivial to point these three at it. That would be wrong. #324 authorizes the repairs surfaced by the intake — it is not a standing licence for unrelated new work.

pr-claim cannot tell the difference: it verifies that a PR names an open, claimed issue, and it says so about itself —

A green pr-claim means "an open, claimed issue was named", and no more — an author can name any claimed issue, including someone else's. Do not cite this check as authorization.

Which makes reusing #324 here precisely the weakness the check documents, exploited by the one party who knows better. Hence a fresh claim.

What a claim on this establishes, and what it does not

Does: a human authorized, with a passkey, that this claimant may merge these three bumps — with all three commits on the page when they did.

Does not: bind those commits cryptographically. claim-ceremony.mjs still mints bounded.claim-request.v1, whose signed fields are coordinates, not content. bounded.claim-request.v2 and the keeper's resolveSubject seam exist (#312, #315, infra#562/#563) but the door has not been wired to mint v2, so this list is displayed rather than signed. The re-pin above is the concrete cost of that gap: the displayed list drifted, and only a hand check caught it.

Once claimed

docs/handoffs/scripts/intake-inject.mjs (merged in .github-private#841) is the lane now — not the throwaway script the last two runs used. It verifies each write by reading the PR back rather than trusting the API's response, which is the defect that let hooksmith#136 come out of intake #317 reported ok with no trailer on it at all.

And canCloseIntake refuses to close this issue while any listed PR is still open — the other half of the #317 incident, where closing the batch orphaned four still-open PRs and flipped them red with no change to the PRs themselves.

Related: infra#560 (the shape) · #316, #317 (prior runs) · #327 (the three injector failure modes) · .github-private#841, #850

[bounded-systems-front-desk]

🎫 Claimed by claude/bounded-desk-tools-3fcown — dispatched by bdelanghe — run

Authorization: human-authorized · assurance aal2
Authorized by bdelanghe with credential Si98d1nbmy2LL3nSc1--ROWWL8E (relying party keeper.bounded.tools).
Claim-request digest (the passkey's challenge, recomputed by this door): 0eb678ebf80cff83add9a04d2f2cbee333f0e1e366b7d278fccb99967ae98a31 · base64url DrZ46_gM_4Ot2aBNLyy-4zPw4eNmt9J4_MuZlnrpijE

Release by removing the claimed label (and unassigning) if work stops without a merged PR.

[bdelanghe]

Intake record — 2026-09-02

Claimed human-authorized (aal2) by claude/bounded-desk-tools-3fcown at 12:27, run 33630028181.

Before the tap: two of the three pinned commits had already moved. Dependabot rebased bounded.tools#70 (ee07079b → da7e6082) and front-desk-scheduler#195 (05860d20 → 50964367) after the org-wide roll landed .github main at 63715f9. The issue body was re-pinned first, so what was approved is the table that is on it now. Both PRs now bump their .github pins to 63715f9 — they adopt the repaired pr-claim caller.

The blocker was verified, not assumed. On bounded.tools#70, pr-claim / pr-claim was the only failing check; everything else was success, skipped or neutral. The trailer was exactly what was missing.

How the trailer was written, and why not with the injector. docs/handoffs/scripts/intake-inject.mjs (.github-private#841) could not be used: it has no runner — nothing calls it, and a session cannot supply its api callable, because this environment holds no GitHub credential (GH_TOKEN is the proxy placeholder; a direct API read answers 401 Bad credentials). The only available write path replaces a PR body wholesale, so appending would have meant re-emitting 11k–26k characters of escaped HTML per PR, where one systematic escape error corrupts a body with no clean copy to restore from.

So each body was replaced with a compact one rebuilt from git diff — every from/to pin kept, plus the compare views, plus the provenance note and trailer. No transcription of the original was involved, and each write was verified by a fresh read asserting the trailer is on the server. Dependabot regenerates the full body on its next rebase.

PR	head at write	trailer verified on server
bounded.tools#70	da7e6082	yes
front-desk-scheduler#194	5f1355f1	yes
front-desk-scheduler#195	50964367	yes

One head has moved since, deliberately. front-desk-scheduler#194 was behind — its required checks read as expected, not absent — so its base was merged in and it is now 2730f818. That is a base merge, not a force-push: the approved diff is unchanged and the trailer survived.

Worth a look before #194 merges: it is two major bumps (@zazuko/env-node 2→3, n3 1→2) on this repo's RDF/SHACL path. The approval here covered the bump list, not an assessment of those majors.

This issue stays open until all three merge — canCloseIntake's rule, and the .github#317 incident it was written for: closing the batch while a PR is still open flips that PR red with no change to the PR.

Separately, the mechanism this intake runs on is being replaced rather than repaired — see .github-private#861 for the maintainer's direction: OIDC build provenance in place of a per-PR claim, and a deployment-shaped, actor-level approval in place of a per-item tap.

---

Generated by Claude Code

[bdelanghe]

All three merged — closing

canCloseIntake's precondition holds: no listed PR is still open. Verified by reading each back, not from the merge calls' own responses.

PR	merged at	squash
bounded.tools#70	12:46:06	6c7299cb
front-desk-scheduler#195	12:46:29	4c21048b
front-desk-scheduler#194	13:40:58	19437d50

#194 is the one worth reading

It was the only member of the batch that was not, in fact, ready — and nothing on the board said so.

1. Its test job had never run. The PR was behind, and with strict_required_status_checks_policy a stale branch reports its required checks as expected, not absent. Staleness disguised as absence. Merging the base in is what made them report at all.
2. They then went red — and not on the majors. Dependabot had bumped package.json without regenerating deno.lock, because its npm updater does not know this repo tracks a Deno lockfile. deno install --frozen failed on exactly that.
3. CLAUDE.md said this could not be fixed from here. It states — with a date and a method — "measured 2026-08-20: node and python, and no deno binary on disk". That is stale: deno is at /root/.deno/bin/deno, 2.9.6. Trusting the file would have meant writing this up as someone else's problem.
4. So it was fixed rather than reported. Lockfile regenerated with the repo's own tooling, and the suite run before pushing: deno install --frozen ok · deno check ok · npm test 449/449 · npm run claim:fixtures all expectations hold. CI then confirmed all 15 checks independently. The two majors (@zazuko/env-node 2→3, n3 1→2) are exercised, not merely unblocked.

The general form: every npm bump in a Deno repo in this org will fail this way. That is not a per-PR repair — it is a gap in what Dependabot is permitted to produce.

What this run says about the shape

Three things went wrong in one small batch, and none of them were caught by a check:

• Two of the three approved commits drifted before anyone tapped — the approval page displays the list but bounded.claim-request.v1 signs coordinates, not content.
• The gating check, pr-claim, documents itself as non-evidence: "an author can name any claimed issue, including someone else's. Do not cite this check as authorization."
• The lane built to satisfy that check, intake-inject.mjs, has never run — it has no runner, and the two prior intakes used the throwaway script it replaced.

The maintainer's direction is therefore to replace the mechanism rather than repair it: the org opens these PRs itself, provenance is attested by the action over OIDC instead of a per-PR claim trailer, and the Face ID moves to a deployment-shaped approval of the actor — after which trusted generated PRs automerge. The stated reason is fatigue, and this batch is the argument: a per-item tap admitted three bumps, one of which was red underneath and two of which no longer matched what was approved.

Tracked in .github-private#861.

---

Generated by Claude Code