ci: drop the two dependabot labels this repo does not have

[os-bill]

Fixes #1743

Description

.github/dependabot.yml asked for two labels this repository does not have. Dependabot cannot create labels, so it failed the whole labelling step and said so in its first comment on every PR it opened, from #1058 (2026-08-10) onward. Both names are removed.

⚠️ The durable lesson: this defect was unfalsifiable from Dependabot's own error message. The bot reports that a label could not be applied — never which one. The filed issue named automated, and deleting only that name would have left the notice repeating on the next Dependabot PR with nothing new to read and no way to tell whether the fix had worked. Establishing that a second name was also missing required checking each referenced name against the repository's actual label set; it could not be got by reading the notice more carefully.

Type of Change

• CI/CD update

Related Issues

Fixes #1743

Changes Made

• Removed automated from the npm block's labels: list.
• Removed github-actions from the GitHub-Actions block's labels: list — the second missing name, invisible from the bot's notice.
• Added an empty-frontmatter changeset (this PR releases nothing).

Both blocks now request only dependencies and skip-changeset, which do exist. ⛔ The package-ecosystem: "github-actions" value on line 25 is a different key and is untouched — only the label entry was removed.

The verification, in full

Every name the file references was checked against two independent sources, with a control so the two misses read as measurements rather than a broken endpoint:

name	block	in .github/labels.yml	live in repo	action
dependencies	npm + actions	declared	FOUND	kept
skip-changeset	npm + actions	declared	FOUND	kept
automated	npm	not declared	not found	removed
github-actions	actions	not declared	not found	removed
ci/cd (control)	—	declared	FOUND	—

The control leg matters: the same channel, same repository, returns a real label for ci/cd (color 6e5494, "CI plumbing and the verification pipeline"). So the two 404s are genuine absences, not a denied endpoint returning empty.

.github/labels.yml calls itself "the single source of truth for this repository's labels" and governs the taxonomy by design ("no ad-hoc labels"). Neither removed name appears in it.

Why removed rather than created

dependencies already marks these PRs and is enough to filter them, so a new label would serve the config rather than a reader. Creating labels would also widen the manifest to match a stale config; this brings the config to the manifest instead, which is the direction .github/labels.yml prescribes. Reversible at one line each if the maintainer wants the cross-repo axis.

Why a real changeset and not skip-changeset

⭐ Both routes are sanctioned and either is defensible; the reasoning is the deliverable, so here it is.

AGENTS.md calls skip-changeset "the lone exception … for PRs that ship nothing to users", and this PR genuinely ships nothing — so that label would not have been a reach to turn a red check green. I went the other way for three reasons:

1. Repo precedent. This repository's CI-config and housekeeping PRs consistently use an empty-frontmatter changeset, not the label — docs-app-runs-on-content-changes.md and docs-anchor-existence-guard.md are two pure .github/ changes that do exactly this.
2. The gate itself calls them equivalent. .github/workflows/changeset-check.yml documents the empty-frontmatter changeset as "the sanctioned 'this PR releases nothing' declaration, on par with the skip-changeset label."
3. It leaves an auditable record. The changeset states why this PR releases nothing, in the diff, reviewable. A label is repository state that does not travel with the commit, and applying it is a write on the PR rather than a reviewable artifact.

Testing

• Unit tests pass — 164 test files, 3438 passed, 1 skipped
• Linting passes
• Build succeeds

pnpm verify (= validate && typecheck && lint && lint:i18n-gate && hygiene && hygiene:tokens && build && test) run in full on the pushed tree:

########## VERIFY_EXIT=0 ##########
  ✓ Validation passed (1975ms)
  ✓ i18n lint gate: 0 `i18n/missing-*` issues
  ✓ source hygiene clean
  ✓ source token ratchet clean
  ✓ Build complete (2687ms)
  Test Files  164 passed (164)
       Tests  3438 passed | 1 skipped (3439)

No test was added — see the note below on why that is a reporting matter rather than something to fix inside this PR.

Additional Notes

Observed, not acted on — reported for the seat to file if it agrees, ⛔ not fixed here:

• .github/labeler.yml carries a guard for this exact defect class. Its header states the invariant ("Every label key must already exist in the repository — actions/labeler does not create them") and test/labeler-config.test.ts enforces it. Nothing enforces the same invariant for .github/dependabot.yml: no test in the repo reads that file's labels: list, which is why this survived a month. Extending the guard would close the class, but it adds a new verification surface, so it is out of scope for this card.
• .github/labeler.yml itself is clean — all six of its keys are declared in the manifest.
• The taxonomy comment at the top of .github/labels.yml lists the workflow group as "needs-user-decision / skip-changeset", but the manifest also declares pm:queue and pm:dispatched. Comment drift only; no behaviour depends on it.
• chore(deps): bump better-sqlite3 from 12.11.1 to 13.0.3 #1058 and chore(deps-dev): bump @changesets/cli from 2.31.1 to 3.0.1 #1264 are still open and were not touched. Now that the config requests only labels that exist, Dependabot's labelling step should succeed on the next PR it opens; the two existing PRs keep their current labels until their branches are recreated, which needs a human — an agent seat cannot issue that command, as the at-mention is rewritten with U+00B7 and stores inert.
• The label manifest declares 16 labels while at least 7 more are in live use — skip-delete is load-bearing, not belt-and-braces #1501 remains open and is not addressed here; its scope is the manifest disagreeing with live usage, which is a different problem from this one config line.

Environment note: REST label enumeration returned 403 in this container ("GitHub access is not enabled for this session") — the same wall #1501 records. The per-name checks above went through a different channel, which succeeded and carried the control leg.

🤖 Generated with Claude Code

https://claude.ai/code/session_019YKN9TPqDSSXUaYqp2j7MZ

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 8, 2026 5:33am UTC