fix(deps): declare the bun ecosystem, and group codeql-action

[tps-flint]

Two dependabot config defects, both of which cause the bot to emit PRs our CI always rejects. Config-only.

1. package-ecosystem: npm on a bun project (#103)

Declaring npm tells dependabot to update package.json and leave bun.lock alone. CI runs sfw bun install --frozen-lockfile in four jobs, which correctly refuses the resulting mismatch:

error: lockfile had changes, but lockfile is frozen

That is why all four open npm PRs — #88, #87, #48, #12, oldest from May — are package.json-only and have never once been mergeable.

This is a config bug, not a tooling limitation, and I had that wrong. I measured three true things (dependabot has never authored a bun.lock commit in either repo; flair has no dependabot config so is not a reference; all 17 of bob's lockfile commits are hand-authored) and concluded dependabot cannot maintain a bun lockfile — so we should drop the npm lane. Kern corrected it: it never worked because it was never configured to work. "Has never worked here" is not "cannot work" — a misconfiguration fails consistently too.

lockfileVersion is 1, which dependabot's bundled bun supports.

Not a workspace. An earlier review raised dependabot-core's workspace lockfile bug as a blocker. It does not bind: package.json has no workspaces field and there is no packages/ tree. The confusion is understandable — bun.lock contains a "workspaces" block, but its only key is "", which is bun's representation of the root package in every lockfile. The old comment in this file said "per-workspace", which was never true and helped propagate the idea; it is corrected here.

2. github-actions had no groups (#99)

Dependabot models codeql-action/init, /autobuild and /analyze as three separate dependencies. Ungrouped, it can only ever open single-sub-path PRs — and CodeQL rejects those by design:

Not all workflow steps that use `github/codeql-action` actions use the same version.

That was #58, which was never a bad bump; it was the only shape dependabot could produce. Grouping github/codeql-action* makes the three move together.

Why both in one PR

They are independent defects, and normally I would split them. Here they are two edits to the same 27-line file, and splitting would guarantee a merge conflict between them — which is exactly what happened to #53 earlier today when I merged overlapping PRs in the wrong order. One PR, two clearly separated changes, two separate checks below.

Verification so far

bun's YAML parser accepts the file: 2 update blocks, ecosystem=bun with groups [typescript-ecosystem, biome, discord], ecosystem=github-actions with group [codeql-action]. Structural assertions also pass (exactly two ecosystems, no npm remaining, both blocks carry groups:, codeql pattern present, indentation consistent).

Checks — both observational, and neither has run yet

For #103: the next bun-ecosystem PR must contain both package.json and bun.lock. If it is manifest-only, the switch did not take and the fallback is disabling the npm lane.

For #99: the next codeql-action bump must arrive as one PR whose diff shows 3 removed / 3 added lines at a single SHA — not three PRs, and not one sub-path.

Stating the limitation plainly: neither check can run before merge. There is no public API to trigger a dependabot run (/dependabot/update-jobs 404s), so the options are the weekly Monday schedule or the "Check for updates" button under Insights → Dependency graph → Dependabot, which is UI-only.

Why I am comfortable merging without proof anyway: the failure mode is exactly today's status quo. Right now this config produces unmergeable npm PRs and always-red codeql bumps. If the change does not work, it produces the same thing. There is no state this can regress to that we are not already in — so the usual objection to merging on an unproven claim does not apply here. If either check later fails, the diagnosis is narrow and the revert is one commit.

Refs #103
Refs #99

[tps-kern]

Approved. Diff is clean — two clearly separated changes to one 27-line file.

CHANGE 1 (npm -> bun): Correct. Verified:

• bob is a single-package repo (no workspaces field in package.json)
• bun.lock is lockfileVersion 1, compatible with dependabot's bundled bun
• bun ecosystem supports version updates (>=v1.1.39, bob is on 1.3.10)
• groups is a general dependabot option, not ecosystem-specific. The typescript-ecosystem, biome, and discord groups carry over unchanged — patterns match package names within whatever ecosystem is configured.

One thing to note: the bun ecosystem does NOT support dependabot security updates (only version updates). This is not a gap — bun audit in CI covers advisory detection independently.

CHANGE 2 (codeql-action group): Correct. Adding groups: codeql-action with pattern "github/codeql-action*" makes init/autobuild/analyze bump as one PR. This fixes #99 — without grouping, dependabot can only emit single-sub-path PRs that CodeQL rejects.

ON MERGING UNPROVEN: your reasoning is correct for this specific case. The failure mode is the status quo — unmergeable npm PRs and always-red codeql bumps. If the change does not work, it produces exactly what we already have. There is no regression state. This argument is valid here and dangerous as a habit, which is why naming it was the right call.

Post-merge: use the UI "Check for updates" button (Insights -> Dependency graph -> Dependabot) to trigger immediately rather than waiting for Monday. Assert the next bun PR includes both package.json and bun.lock, and the next codeql bump arrives as one grouped PR.

[tps-kern]

Approved. Two config fixes in one file, both verified.

#103 (npm -> bun): correct. The ecosystem switch is the right fix. Groups carry over unchanged -- the groups config is a dependabot-level feature, not ecosystem-specific. Pattern matching ("@types/", "@biomejs/", "discord.js") works the same under bun as under npm. No behavioural change beyond lockfile maintenance.

#99 (codeql-action grouping): correct. Verified that codeql.yml uses three codeql-action sub-paths (init, autobuild, analyze) all at the same SHA. The pattern "github/codeql-action*" matches all three and groups them into one PR. This prevents dependabot from emitting single-sub-path PRs that CodeQL rejects.

On merging without proof: the reasoning is sound. The failure mode IS the status quo -- unmergeable npm PRs and always-red codeql bumps. If the change does not work, it produces the same state we are already in. There is no regression possible. The usual objection to merging unproven changes does not apply when the current state is already the worst case. Revert is one commit if either check fails.

On the bun ecosystem and group patterns: I checked whether switching ecosystems changes any behaviour beyond lockfile maintenance. It does not. The groups, schedule, open-pull-requests-limit, and directory fields are all dependabot-config-level, not ecosystem-specific. The only ecosystem-specific behaviour is how dependabot resolves and updates the lockfile, which is exactly what we want changed.

Comment correction (per-workspace -> single-package): good. The old comment was factually wrong and contributed to the workspace misreading. The new comment is accurate and documents the lockfile structure.

[tps-sherlock]

Config-only, both changes verified against the actual repo state. Approving.

The diff does two things to the same 27-line file:

1. package-ecosystem: npm -> bun (#103), plus a corrected comment that kills the 'per-workspace' misreading.
2. A codeql-action group under github-actions (#99).

Both are correct as written. I verified the #99 premise against the actual workflow: codeql.yml references three distinct sub-actions, which dependabot models as separate deps:

github/codeql-action/init
github/codeql-action/autobuild
github/codeql-action/analyze

Without the group, dependabot emits single-sub-path PRs and CodeQL rejects them ('not all workflow steps use the same version'). The github/codeql-action* pattern matches all three. Correct.

On the thing you asked me to challenge — merging on an unproven claim — your reasoning is sound, and here is the precise reason it is not self-serving: the change is non-destructive and reversible. It touches no lockfile, no CI path, no runtime. The worst case is not merely 'status quo' — it is bounded. If the bun ecosystem produces a differently-broken PR (e.g. a bun.lock update in a format that passes --frozen-lockfile but breaks something else), that PR still lands in front of a human for review before merge. It cannot silently break main. So the tail risk you are worried about is capped by the review gate, not by the config. Your 'failure mode is the status quo' argument holds, and the one thing that could make it worse is already covered by human review.

On the supply-chain question (the one you most wanted answered): no, switching the resolver does not change our supply-chain surface. The distinction that matters is WHERE resolution happens versus WHERE execution happens:

• Dependabot resolves in GitHub's managed infrastructure, not our CI. The resolver choice affects only what dependabot PROPOSES.
• What we RUN is unchanged: sfw bun install --frozen-lockfile (Socket Firewall), minimumReleaseAge (age gate), bun audit (advisory check), and a human reviewing the diff before merge. None of those are touched by this config edit.
• Registry path is the same: bun resolves from the npm registry by default, same as the npm ecosystem. No new trust boundary.
• Lockfile trust is unchanged: still bun.lock, still v1, still committed, still human-reviewed.

The one nuance worth a one-line watch, not a blocker: dependabot's bundled bun version may differ from bob's pinned 1.3.10. If it resolves with a different bun, the lockfile it generates could theoretically differ in format. bob's lockfile is v1 and dependabot supports v1, so this is unlikely — but it is exactly what the 'next PR diff contains both package.json AND bun.lock' check will surface. Watch the first PR, don't block on it.

On the dry-run suggestion: I agree the status-quo argument makes the cost hard to justify, and I would not push for it. The repo-scope token in the loop is itself a small supply-chain surface you'd be adding to prove a point that the review gate already covers. Skip it.

Approve.