Automating rung 1: what a dependency-fixing bot may do, and the two things it must never do

[bdelanghe]

Detection is automated (per-PR scan plus the Tuesday rescan). Remediation is not — a red lane produces a finding and waits for a person. REMEDIATION.md says most reds clear at rung 1 (relock within declared ranges), which is mechanical. So the obvious question is whether rung 1 can be a bot.

Mostly yes. But the 2026-08-03 front-desk-scheduler remediation (#118 → front-desk#122/#123/#125) produced two constraints that are not obvious up front, and a naive implementation gets both wrong in the harmful direction.

Constraint 1 — a fresh advisory is unfixable for 24h, and "make it green" is the wrong objective

Deno's minimum dependency age policy (24h default) refuses any npm version published less than a day ago. When an advisory and its fix land the same day — which is the common case for a fast-moving package — the fix is unreachable for up to 24 hours on every Deno repo in the fleet. The failure is silent: deno install does not announce a skipped version, it resolves lower.

A bot optimising for "the check goes green" reaches for --minimum-dependency-age 0. On #118 that flag, tried and discarded by hand, pulled hono 4.13.0 published nineteen minutes earlier plus an unrelated jose bump — because the flag is global, not per-package. The result is a PR that adopts a minutes-old minor version while describing itself as a security fix. That is the exact supply-chain shape the gate exists to refuse, produced by the tool meant to improve security.

So the bot needs "blocked by the age gate — retry after <timestamp>" as a first-class outcome, not a failure and not something to route around. It must never relax the gate. (A human who genuinely must can use the smallest relaxation that admits one version — --min-dep-age 1170, or a cutoff timestamp — but that is a judgement call with a written justification, which is what #123 did.)

Corollary worth encoding: a cutoff timestamp also lets the bot verify a future resolution without committing it — resolve at the boundary, check the outcome, throw it away. That turns "will this clear tomorrow?" into a fact rather than a guess.

Constraint 2 — check the parents before assuming you are blocked on upstream

#118 concluded the fix needed an override because a plain resolve would not take it, and framed one option as waiting for @bounded-systems/verbspec-mcp / the SDK to move. Both parents' ranges already admitted the fixed version (hono ^4 and ^4.11.4). No upstream release was ever going to be the trigger; the constraint was the clock.

These two look identical from outside — "the resolver won't take the fix" — and they have opposite remedies: one waits for a release that is coming, the other waits for a timer. The tell is whether the declared ranges already admit the fixed version. A bot can compute that; it is exactly the sort of check a human skips.

Proposed scope

May do, unattended:

• Rung 1 only — fresh resolve, no manifest edits, no age-gate flags of any kind
• Run the repo's tests and rescan
• Open a PR when clean; report the before/after finding table

Must escalate, never attempt:

• Anything above rung 1 — a bump outside a declared range (brand: style-dictionary 4.4.0 → 5.4.4, CVSS 8.8), or a transitive chain (drift-gate: brace-expansion → minimatch → ts-morph ^23 → ^28). These are judgement, and Remediation queue: clear findings and remove report-only grace (it has no expiry and no owner) #8's history shows they are not rare.
• Any osv-scanner.toml acceptance. An ignore entry is a decision with a reason, and a bot has no reason.
• Merging. Auto-merging bot dependency bumps into main is itself a supply-chain path, and it sits badly with an org whose posture is bounded authority and one auditable pipeline per change. Ending at a green PR is the right stopping point, not a limitation.

Prerequisite, and it is blocking: ~44 callers are pinned behind the shared lane (#10). A fixer shipped today would run a stale scanner in most of the fleet, and its fixes would be validated against whatever 62990dd pinned rather than current main. Re-pinning has to be decided first.

Cheaper first move

For the npm and Cargo repos this is largely turning on Dependabot, which already did most of conformance-kit's table (#48–#52) and needs no new code. The custom lane only earns its keep where Dependabot cannot go — deno.lock, which is why the converter exists. Worth splitting on that line before building anything.

The honest caveat

Three factual errors were corrected during that one remediation: #118's diagnosis of the resolver, #123's self-contradicting deletion condition, and a claim in a comment on infra#104. Each surfaced because someone re-derived an inherited claim. A bot would have propagated all three at speed. That is an argument for keeping the human at the PR, not an argument against the bot.

[bdelanghe]

The shape: a called lane acting on its own repo, not a central actuator

The rung-1 bot doesn't need the credential this issue's original framing implied — and the reason generalises past this bot.

Distribute it the way deps.yml is distributed, and let each repo run it on itself. A reusable workflow invoked by repo-health runs in repo-health, so its GITHUB_TOKEN already has contents: write on exactly the one repo it needs to relock. It reads the finding, relocks, runs that repo's own tests, opens a PR against itself. No broker entry, no GH_APPS change, no org-wide grant, no fleet-sync — the authority is per-repo by construction rather than by downscoping, which is the stronger version of the same property.

That also puts the remediation next to the toolchain it needs. A central bot would have to install Deno, Node, Bun, and Cargo and guess which applies; a lane running in the repo inherits whatever that repo's CI already sets up.

The boundary that decides what it may touch

GITHUB_TOKEN cannot write .github/workflows/* — GitHub rejects it without the workflow scope. That single fact partitions the whole problem cleanly:

target	actor	why
lockfiles (deno.lock, package-lock.json, bun.lock, Cargo.lock)	this lane, self-acting	ordinary files; own GITHUB_TOKEN suffices
uses: pins in .github/workflows/*	Dependabot	GitHub privileges it specially; nothing else can without escalation

So the two mechanisms are not competing designs to choose between — they are the two halves the constraint carves out, and each is the only thing that can do its half without a posture change. That is a better argument for the split than "Dependabot already owns npm and Cargo," which is what this issue said before.

Scope, unchanged but now enforceable

Rung 1 only — fresh resolve, no manifest edits, no age-gate flags of any kind. Anything above rung 1 (a bump outside a declared range, a transitive chain like drift-gate's ts-morph ^23→^28) opens or updates an issue instead. No osv-scanner.toml acceptances: an ignore entry is a decision with a reason, and a bot has no reason.

The part worth building carefully: the merge gates

Tonight's one-off sweep runs under four gates, and they are currently prose in an ephemeral scheduled prompt — unversioned, untested, unreviewed, gone once it fires. That is the same shape as a control that lives nowhere, which is what this whole rollout keeps rediscovering. In a lane they become code self-test can test, the way test_scan_posture.py pins the exit-code triage:

• G1 — zero checks is not green. "All checks passed" is vacuously true on a repo with no CI. Require ≥1 completed check. Same hollow-green refusal as caller-pins' empty-census guard.
• G2 — every completed check green, with a named carve-out for a red osv that matches a known pre-existing finding on that repo's main.
• G3 — no major bumps. The org template groups patterns: ["*"] with no update-types filter, so majors ride along; guest-room and prx both scope theirs to ["minor","patch"] deliberately, and prx says why in a comment.
• G4 — 405 … N of N required status checks are expected means the branch is STALE, not that checks are missing. Rebase; never re-run.

G1 and G3 are the two that would actually have bitten: a repo with no CI auto-merging an actions/checkout 4→7 bump is both failure modes at once.

Still not automated, deliberately

Merging. A bot that both proposes and merges dependency changes is itself a supply-chain path. Ending at a green PR is the right stopping point.

---

Generated by Claude Code