ci: every Dependabot PR touching plugins/** fails the changelog-parity bump gate, because Dependabot cannot bump a manifest or write a changelog entry

[kyle-sexton]

Recurring, fully reproducible friction found while draining the Dependabot queue on 2026-09-12. It cost a manual commit on 7 of the 12 open Dependabot PRs, and it will recur on every future one that touches plugins/**.

The mechanic

scripts/check-changelog-parity.sh --check-bump origin/main requires a plugin manifest version bump plus a matching ## [<version>] entry whenever a change set modifies files under plugins/<name>/. Dependabot writes only package.json / package-lock.json, so every such PR fails:

PUBLISHED VERSION REUSE: miro still carries 0.4.0 while this change set modifies files under
plugins/miro/ -- bump the manifest and add a new '## [0.4.0]' release entry instead of editing in place.

The failure surfaces as a red lint job and a red ci-status, so the PR is unmergeable until a human (or an agent) pushes a second commit. The gate is correct and worth keeping; the gap is that nothing supplies the bump for the one author that structurally cannot.

Evidence from the 2026-09-12 drain

Every one of these needed a hand-written chore(<plugin>): bump to <version> commit carrying a manifest bump and a CHANGELOG entry before it could merge:

PR	Plugin	Version it had to claim
#4101	miro	0.4.2
#4102	miro	0.4.3
#4104	miro	0.4.4
#4085	ai-briefing	0.7.30
#4061	knowledge	0.13.52
#4031	knowledge	0.13.53

(#4100, #4032 and #4021 were exempt: they touch .github/ and the root manifest, not plugins/**.)

Two costs beyond the extra commit

1. It serializes the queue per plugin. Two Dependabot PRs touching the same plugin cannot both claim the same version, so they must be landed one at a time, each re-based and re-numbered after the previous merges. Three miro PRs meant three sequential CI cycles that could otherwise have been concurrent.

2. Version numbers are raced by ordinary PRs. Mid-drain, #4097 merged and consumed the exact three numbers already staged on these branches (miro 0.4.1, knowledge 0.13.51, ai-briefing 0.7.29), turning all three green branches into version-reuse failures and forcing a renumber-and-repush of each. Any manual-bump approach has this race; the wider the queue, the likelier it fires.

Options, roughly cheapest first

1. Extend the existing auto-commit precedent. .github/workflows/dependabot-miro-bundle.yml already detects a Dependabot PR, rebuilds a derived artifact, and pushes the result back to the branch. The same shape could compute the next patch version for each touched plugin and write the manifest bump plus a templated CHANGELOG entry. It inherits that workflow's known constraint: a GITHUB_TOKEN push does not retrigger workflows, which is why build(deps): bump the npm-minor-patch group in /plugins/miro/server with 3 updates #4102 and build(deps): bump the npm-minor-patch group in /plugins/miro with 3 updates #4022 sat with a single check run after the bundle bot pushed. Whatever lands here has to solve the re-trigger, or accept a manual nudge.
2. Treat the lockfile-only case as non-shipping. A bump that changes only package-lock.json for a dev dependency arguably does not change what a consumer receives. If the gate exempted that class, several of the six above would not have needed a bump at all. This is a policy call about what the version number is promising, and it is the gate's own semantics, so it needs a deliberate decision rather than a patch.
3. Document the manual step. Cheapest, fixes nothing, but at least stops each person rediscovering it. Worth doing only if 1 and 2 are both rejected.

Notes

• Do not "fix" this by exempting Dependabot from the gate wholesale. A dependency bump can genuinely change what a consumer receives (build(deps): bump the npm-minor-patch group in /plugins/miro/server with 3 updates #4102 bumped zod, a bundled runtime dependency, and did regenerate dist/index.min.js), so the version bump is the right outcome for at least some of these.
• The entry text matters less than its presence, but the existing convention is worth matching: see the ## [0.4.4] entry on plugins/miro/CHANGELOG.md for the shape a dependency bump has been getting, including the arrow form 4.1.11→5.0.0 rather than an em dash, since several plugin changelogs are in scripts/em-dash-purged-paths.txt.