Workflow: disable Dependabot PRs and drive security fixes from alerts into board-tracked issues

[cliffhall]

Tracking issue. Alternative to #2060 — same goal (security fixes must reliably reach v2/main), but it never touches a Dependabot PR, because moving one is the part that cannot be made reliable.

Decision

Dependabot opens no PRs against this repo. Its alerts stay on and become the input to our own process; every dependency change — security or routine — arrives as an issue on the board and is fixed by a maintainer PR against v2/main, exactly like any other work. The Dependabot-PR carve-out from "every PR references an issue" is removed, not automated around.

Dependabot alert  →  scheduled sweep  →  issue (labeled, milestoned, boarded)  →  maintainer PR → v2/main

The alert is the durable, branch-neutral fact — "package X below version Y is vulnerable" is true regardless of branch. The PR is the perishable artifact: a Dependabot PR is a diff computed against main, correct only while main and v2/main are byte-identical. Consume the fact; don't move the artifact.

Sub-issues

Issue	Scope	Status
#2231	Release-time npm audit fix — /release step 1 now runs npm audit fix (root + every client) before the version bump, gated by local:gate, never --force. The replacement for npm version-update PRs — a monthly npm outdated sweep (dependency-refresh.yml + scripts/dependency-refresh.mjs) that files one idempotent tracking issue across the root install and every client. Builds the new flow; does not touch .github/dependabot.yml.	PR #2232 in review
#2233	Security-update PRs off, alerts consumed — a daily sweep reads Dependabot alerts (GITHUB_TOKEN has vulnerability-alerts: read, no PAT needed), groups them by bump rather than by advisory, re-verifies each vulnerable range against v2/main's own lockfile before filing, and files one board-tracked issue per bump. Disables automated-security-fixes and asserts it stays disabled.	Todo
#2235	.github/dependabot.yml itself — removes the five npm entries, switching off the flow #2231 replaces, and decides the github-actions entry (below). Split out of #2231 so every change to that one file lands in a single reviewable piece. ⚠️ Dependabot reads the file from the default branch, so this only takes effect at the next milestone merge.	Todo

github-actions version updates are out of scope and stay on Dependabot's own PR flow.

Revised. That carve-out contradicts the decision above: the github-actions entry opens a grouped monthly PR rewriting uses: refs across the workflows, and it arrives with no Closes #N and no board card — the same exception, narrowed to one ecosystem rather than removed. It is now in scope, and #2235 decides it (fold action bumps into the monthly sweep, keep the entry and file the issue by hand, or document the exception in AGENTS.md).

Why not retarget (#2060)

1. A Dependabot PR is a diff computed against main. Retargeting re-bases the comparison onto v2/main without recomputing anything, so it is only correct while the branches' manifests are identical. Workflow: retarget Dependabot security PRs onto v2/main, with a tracking issue and a merge guard #2060's drift threshold is a smoke alarm, not a fix.
2. Dependabot may not tolerate it. Workflow: retarget Dependabot security PRs onto v2/main, with a tracking issue and a merge guard #2060 flags this as unverified and gates the build on a manual experiment; its own fallback (a mirror PR cherry-picking the bump) concedes the machine-generated branch was never the right artifact to move.
3. The tracking issue is bolted on after the fact — manufactured by cron, with the PR body rewritten to Closes #N, and both kept idempotent hourly. Three pieces of mutable state per PR to retrofit an artifact that arrived out of process.

With no Dependabot PR in existence, #2060's hourly cadence, merge guard, and ruleset change are all unnecessary.

Known limitation

GitHub computes the dependency graph — and every alert — from the default branch (main). A vulnerable dependency introduced on v2/main and not yet merged to main produces no alert. Retargeting has the identical blind spot; nothing that consumes GitHub's alerts avoids it. #2233's lockfile re-check handles the other direction (alerts already fixed on v2/main); the release-time npm audit fix from #2231 is the second signal that partially covers this one. A scheduled npm audit --audit-level=high over v2/main's lockfiles would close it fully and is a separable follow-up.

Relationship to #2060

Alternatives, not complements. If this is accepted, close #2060 as superseded. Both are downstream of the same root cause, and #2060 names the real fix correctly: make v2/main the default branch, blocked on the org-level ~DEFAULT_BRANCH ruleset. Until it moves, this is the cheaper and more robust workaround, because it depends on no external bot's behavior and on no assumption that two branches stay identical.

Done when

All three sub-issues are closed.

[cliffhall]

Triage: Priority Medium (total 6)

• Severity 3 — the capability is missing; the workaround is watching the alerts page by hand and remembering to file the work, which is exactly the kind of thing that produced v2/main is running vulnerable dependency versions already fixed on main #2057
• Urgency 3 — wanted this milestone. There are 7 open alerts right now and the lockfile probe confirms v2/main is genuinely exposed (fast-uri@3.1.5, qs@6.15.3), but the fixes themselves are separate issues; this one is the pipeline
• Bonuses: none. Typed chore; the dependabot label is a routing tag, not a security label, and the milestone bonus is the re-scoring case

Deliberately scored to match #2060 (also Medium, total 6), since this replaces that issue rather than adding to it — swapping the approach should not change the queue position.

Board: #28, Status Todo, milestone v2.6.0 (alongside #2060).

[cliffhall]

Two decisions folded in, implemented directly rather than left as open follow-ups:

1. npm audit fix is now a mandatory pre-release step, ahead of the version bump, on v2/main — see the updated /release skill. This is the backstop this issue calls out: it catches whatever the alert-driven pipeline above has not yet turned into a merged fix, right before a release ships, rather than relying on remembering to check separately.
2. npm version updates are off, effective immediately — .github/dependabot.yml no longer has npm entries (github-actions version updates are unaffected, out of scope here). Replaced with a monthly sweep (.github/workflows/dependency-refresh.yml + scripts/dependency-refresh.mjs, tested in scripts/dependency-refresh.test.mjs) that runs npm outdated across the root install and every client and files/updates one tracking issue — no auto-generated PR. This closes the same "every PR references an issue" carve-out this issue argues for on the security-update side, but for routine bumps.

The alert-driven issue pipeline itself (the sweep that reads Dependabot alerts, groups by bump, verifies against v2/main's lockfile, and disables automated-security-fixes) is still the open part of this issue and unbuilt.

[cliffhall]

Split into #2231 for the two pieces above that don't depend on the alert-driven sweep (release-time audit fix + monthly npm-outdated issue) so they land now — the PR for #2231 is in progress. This issue stays open for the alert-consuming pipeline itself.