Disable Dependabot npm version updates in dependabot.yml, and close the github-actions PR carve-out

[cliffhall]

Sub-issue of #2229. Scoped out of #2231 / PR #2232, which lands the replacement machinery first — the monthly npm outdated sweep (.github/workflows/dependency-refresh.yml + scripts/dependency-refresh.mjs) and the release-time npm audit fix. This issue is the config change that switches the old flow off, and it is the only issue that touches .github/dependabot.yml.

Why it is separate from #2231

PR #2232 originally carried the .github/dependabot.yml edit alongside the new workflow. Splitting it out keeps every change to that one file in a single reviewable piece — and there is a second, unresolved half to it (github-actions, below) that should not hold up the sweep landing.

The split has a consequence worth stating: between #2232 merging and this issue landing, Dependabot npm version-update PRs and the monthly tracking issue both exist. That overlap is duplicate signal rather than conflicting action, so it is harmless — but it is the reason this should follow closely rather than sit in the backlog.

Scope

1. Remove the five npm ecosystem entries

Root plus clients/{web,cli,tui,launcher} — v2 is not an npm workspace, so each carries its own package.json + lockfile and needs its own entry. Routine npm bumps are handled by the #2232 sweep from then on.

The file's header comment has to be rewritten in the same change: it currently exists to explain the per-client entries being deleted, and the target-branch note it carries stops applying to anything but the github-actions entry.

Two comments landing in #2232 assert this is already done and are false until this issue lands:

• .github/workflows/dependency-refresh.yml:3 — "Dependabot version updates are disabled in .github/dependabot.yml"
• scripts/dependency-refresh.mjs:4 — "Dependabot's version updates were disabled in .github/dependabot.yml"

#2232 will word both as pending and point here; this issue flips them to the past tense.

2. Decide the github-actions entry

#2229's decision is "Dependabot opens no PRs against this repo" — but it also declares github-actions out of scope, which leaves that entry live. As written it opens one grouped monthly PR against v2/main rewriting uses: refs across the workflows, and that PR arrives with no Closes #N and no board card — precisely the carve-out from "every PR references an issue" that #2229 exists to remove. So the carve-out is not closed by #2229 as scoped; it is narrowed to one ecosystem.

Current surface is 9 distinct actions:

actions/attest-build-provenance@v4   docker/build-push-action@v7
actions/cache@v6                     docker/login-action@v4
actions/checkout@v7                  docker/metadata-action@v6
actions/setup-node@v7                docker/setup-buildx-action@v4
                                     docker/setup-qemu-action@v4

Important

Decided: A. Confirmed by the maintainer 2026-09-03. .github/dependabot.yml is deleted outright rather than left with an empty updates: list — an empty list is a schema error Dependabot flags — and scripts/dependency-refresh.mjs grows a release-tag check for every uses: ref. B and C are kept below as the record of what was weighed, not as live options.

Three options were considered:

A. Fold actions into the monthly sweep (recommended). Remove the github-actions entry too, leaving .github/dependabot.yml with an empty updates: list or deleted outright, and teach dependency-refresh.mjs to report stale uses: refs in the same tracking issue. Costs a new check — npm outdated says nothing about actions, so this means parsing uses: out of the workflow YAML and comparing each ref against the action's latest release tag via the GitHub API. Consistent with #2229's stated decision, and the sweep already has the token scope to read public releases.

B. Keep the entry, create the issue by hand. Cheapest, and honest as long as it is written down: the monthly grouped PR arrives, a maintainer files an issue for it at review time and edits Closes #N into the body. Leaves one standing exception to the rule, enforced by nothing.

C. Leave it exactly as is. Only defensible if the exception is documented in AGENTS.md rather than left implicit, since a rule with a silent exception is the failure mode #2229 is arguing against.

On A's actual yield: all 9 refs are pinned to moving major tags (@v4/@v6/@v7), so the actions section of the monthly issue is empty today because no major bump is available — not because everything is current to the patch. With the repo pinned this way a v7 → v8 jump is the only thing that section will ever surface. The exactly-pinned comparison (v7.0.0 behind v7.0.1) is coverage for a pinning style the repo does not currently use, and a SHA pin cannot be ranked against tags at all. Say this in the PR so an empty section is not read as a stronger claim than it is.

Notes

⚠️ The file's current header records that Dependabot security updates are enabled in repo settings, not in this file, and kept working while the file was missing entirely (#1833, #1840). That is the evidence that deleting it does not silently disable security PRs — carry it into the PR body or #2233, because it is the one piece of institutional knowledge that dies with the file.

⚠️ Dependabot reads .github/dependabot.yml from the default branch (main), so nothing in this issue takes effect when the PR merges to v2/main — only at the next milestone merge. Verification that the npm PRs actually stopped (and that security-update PRs kept working, per the existing note in the file) has to happen after that merge, not at PR review time.

Done when

• The five npm entries are gone and the file's header comment reflects what is left.
• The github-actions entry is removed per decision A, and action staleness is reported by the sweep instead.
• The two stale header comments from chore(deps): npm audit fix before release bump; monthly npm-outdated issue #2232 are corrected.
• Behavior re-verified after the next v2/main → main milestone merge.

[cliffhall]

Triage: Priority Medium (total 7)

• Severity 2 — tooling hygiene, not user-facing. The failure mode is a Dependabot PR arriving with no issue and no board card, and (after chore(deps): npm audit fix before release bump; monthly npm-outdated issue #2232 merges) a window of duplicate signal from both the npm PRs and the monthly tracking issue. The workaround — a maintainer files the issue by hand — is trivial.
• Urgency 3 — wanted this milestone. It directly follows PR chore(deps): npm audit fix before release bump; monthly npm-outdated issue #2232 and is what closes out the .github/dependabot.yml half of Workflow: disable Dependabot PRs and drive security fixes from alerts into board-tracked issues #2229.
• Bonuses: +1 milestoned (filed through the create flow, so the approval is real rather than a formality), +1 sub-issue of the Workflow: disable Dependabot PRs and drive security fixes from alerts into board-tracked issues #2229 epic.

Consistent with its siblings #2231 and #2233, both Medium.

Board: #28, Status Todo, milestone v2.6.0.

[cliffhall]

Decision on §2 (github-actions): option A — fold action bumps into the monthly sweep.

So .github/dependabot.yml is removed outright rather than left with a lone github-actions entry. One correction to the issue as written: "an empty updates: list" is not actually available — Dependabot's schema requires at least one entry and flags a zero-entry list as an invalid config. Deleted it is.

scripts/dependency-refresh.mjs picks up the watch the deleted entry was doing: it parses every uses: ref under .github/workflows, compares each against that action's latest release tag, and renders the stale ones as one more section of the same monthly tracking issue.

Staleness is compared only to the precision the ref specifies, which is the part worth recording. v7 is a moving major tag that GitHub repoints at every v7.x release, so v7 against a latest of v7.0.1 is up to date and only v8 makes it stale. An exactly-pinned v7.0.0 is behind v7.0.1. A SHA pin is deliberately immovable, so a tag comparison says nothing about it and it is never reported.

⚠️ A consequence for whoever reads the first sweep: all 9 refs in this repo are moving major tags (@v4/@v6/@v7), so an empty GitHub Actions section means "no major bump is available", not "everything is current to the patch". With the repo pinned this way, a v7 → v8 jump is the only thing that section will ever surface. The exactly-pinned branch is coverage for a pinning style the repo does not currently use, kept so the check stays correct if a workflow later pins hard or moves to SHA pins.

Two other notes for the record:

• No AGENTS.md change is needed. The carve-out was never written down there, so there is nothing to correct — option C is the one that would have required an edit.
• The security-update note survives the file. Its header recorded that Dependabot security updates are configured in repo settings rather than in dependabot.yml, and kept working while the file was missing entirely (build(deps): bump the npm_and_yarn group across 5 directories with 12 updates #1833, build(deps): bump the npm_and_yarn group across 5 directories with 2 updates #1840). That is the evidence deleting it does not silently disable security PRs, so it moved into the dependency-refresh.yml header rather than dying with the file. Workflow: consume Dependabot security alerts into board-tracked issues and disable security-update PRs #2233 is where those get turned off deliberately.

The last "Done when" item — re-verifying after the next v2/main → main milestone merge — is unchanged and cannot be closed at PR review time, since Dependabot reads its config from the default branch.