Follow label renames from GitHub's label webhook

[jarstelfox]

🤖

When someone renames a project label on GitHub, Pulldasher keeps showing that project's PRs under the old name. GitHub tells us about a rename once, through the repo's label event, and Pulldasher never listened for it. Today ops P-strapi-shared-fields is P-strapi-cli on GitHub, but /api/v1/projects still lists ops#1254, #1255, #1251, #1204 and #1198 under strapi-shared-fields, and Decide flags it as new.

Changes

• Webhook: a label event with action: edited and changes.name now renames the stored label on every PR and issue in that repo.
  • It updates the rows in place, and a name too long for the 32-character column fails instead of being cut short. A refetch loses who added the label and when, and the Projects tab sorts by that date.
• Projects: for a project label, renameProject also moves the hand-added issues (project_issues), the roadmap item and the ongoing mark to the new slug.
  • Each repo's rename arrives separately, so it waits until no repo has anything under the old label.
  • A roadmap item already tracking the new slug keeps it. The old item is left for a person to merge.
• Repair: bin/repair-renamed-labels lists stored labels their repo no longer has, with each one's new name taken from up to 5 of the affected items on GitHub (an old label on thousands of PRs would otherwise spend the board's GitHub quota).
  • --apply renames them the same way. A label with no single new name is listed and skipped.

Important

Turn on the Labels event in the Pulldasher webhook, or this code never runs. The webhook is set at the org level, and my token can't read org hooks (admin:org_hook), so I couldn't check whether it's ticked. config.example.js doesn't list it either.

Stale project labels on prod today (7)

Found by reading /api/v1/projects over the last 400 days and checking each P- label against its repo's labels on GitHub. The new names come from one item each. Only project labels are listed; the script's dry run also covers the others.

Repo	Stored label	Items	On GitHub now
ops	P-strapi-shared-fields	#1198 #1204 #1251 #1254 #1255	P-strapi-cli
fixbot	P-security-audit	#3375 #3382 #3383 #3384	P-security-remediation
expo	P-workbench-tab	#1325 #1333 #1334 #1344 #1346	P-workbench (already a project in ifixit)
expo	P-webview-status-bar-inset	#1332	P-app-safe-area-insets
server-templates	P-dev-monitoring	#5345	P-dev-ci-contention
ci-actions	P-architecture-summary	#16 #17	P-pr-architecture
ifixit	P-content-small	#64339	no project label (deleted, the script skips it)

Once this is deployed, the managing-projects skill's plan.mjs (#65343) can rename labels in place again instead of moving each PR to a new label. Its renameIn comment explains the workaround.

Not handled: a label deleted on GitHub also leaves rows behind. That's the deleted action on the same event, and it can be a follow-up.

QA

• Run npm test. The six tests in test/hooks-label-rename.test.js pass.
• On dev, run bin/repair-renamed-labels with no flag. It lists each stale label with its new name and changes nothing.
• On dev, rename a throwaway P- label. Reload: its PRs show under the new name.

This isn't deployed anywhere; prod waits for Jarred's go-ahead.

🤖 Generated with Claude Code