fix(labels): from:customer stops advertising a deleted board field (backend#2743)

[LukasWodka]

Summary

The from:customer label's description advertised "auto-bumps Priority to P1". RFC-BACKEND-0008 D5 deleted the Priority single-select from board project 2 and replaced it with the binary prioritylabel; customer-priority-bump.yml writes no board field at all — its one write is gh issue edit --add-label priority. The label that triggers the rule was promising an outcome the automation stopped producing, in every repo that runs it.

The fix is a label sweep, already applied (labels are repo settings, not files): all twenty enrolled repos now carry, byte-identical and with the colour untouched:

Filed from a customer request — automation adds the binary `priority` label

The diff in this PR is the note beside the write it describes, plus the honest statement of what is still not checked.

How the repo list was derived — never typed

repo-inventory.yml, filtered to repos whose callers: declare customer-priority-bump.yml: required — the same authority caller-drift.py and triage-labels-check.py use. The label name came from the reusable's own trigger-label input default, and the label the automation writes from the --add-label its run: block executes. The sweep then refused, before touching anything:

• any replacement text that did not name the label the workflow actually writes (proven: feeding it the old text refused with does not name the label(s) the workflow writes ['priority'], with the mutation anchor confirmed applied);
• any text still carrying Priority to / P1 / board field;
• a text over GitHub's 100-character limit;
• a run that derived zero enrolled repos or zero --add-label writes.

Fail closed on the sweep too: a repo whose labels could not be read or edited exits 3 as UNKNOWN, never as compliant. None did — 20 of 20 read and 20 of 20 edited.

Before / after, measured

	before	after
enrolled repos derived from the inventory	20	20
repos carrying from:customer	20	20
distinct descriptions	1 — Filed from a customer request — auto-bumps Priority to P1	1 — Filed from a customer request — automation adds the binary \priority` label`
colour	#FF6B35 on all 20	#FF6B35 on all 20, unchanged

Uniformly wrong before, uniformly right after — the good case the ticket predicted, and no repo had drifted off the shared text, so nothing was flattened.

One correction to the ticket: it is 20 repos, not 21. The inventory declares 20 enrolled and exempts none — the 16 that already had the labels plus the 4 .github#364 created. triage-labels-check.py's own docstring says the same ("TWENTY repos"). Reported rather than reproduced, which is the whole reason the list is derived at run time.

The description check is deferred to backend#2744 — with a reason

The check the ticket asks about, scripts/triage-labels-check.py, is not on develop. It lives on PR .github#364, still open — an 8-file change that also adds triage-labels.yml, a selftest and a mutation suite. Extending it from a branch off develop means either duplicating the file (a guaranteed conflict with an open PR) or stacking on that PR, which org standards forbid. Nothing in this PR touches a file .github#364 touches other than customer-priority-bump.yml, and there in a different hunk — the run: step, not the header block #364 rewrites.

So the split is: this PR fixes the lie people actually read, and backend#2744 arms the machine check on top of #364, where the check and its single declared source can land together. #2744 also carries the design question worth deciding rather than guessing: where the declaration lives (repo-inventory.yml, whose top-level keys caller-drift.py validates, versus a workflow_call input nothing consumes), and the derived assertion that matters most — the trigger label's description must name the label the reusable writes, which is the assertion that would have reddened at D5 instead of waiting for a human.

Arm while green is satisfied in the right order: the labels were swept first, so all twenty agree byte-for-byte today and #2744 can land green.

Also found, not fixed here

.github/ISSUE_TEMPLATE/feature.yml still asks for a P1 — High / P2 — Normal / P3 — Nice-to-have priority dropdown — the same D5-removed vocabulary, in a second place. It drops no label and blocks no automation (the answer lands in the issue body as prose), so it is a separate call about what the templates should ask for, not part of this sweep. Flagging it rather than widening the diff.

Test plan

• make check — green (ruff, shellcheck, house-rules 0 findings, actionlint 0 findings, every selftest and every --dry mutation anchor). Output in the session log.
• The sweep script was mutation-proven before it ran: the stale text is refused, the anchor confirmed present in the mutated copy.
• Live re-measurement after the sweep: 20 readable repos, 1 distinct description, exit 0.
• No workflow logic changed — the diff is 22 comment lines inside an existing run: block, and actionlint -shellcheck passes over it.

Closes tracebloc/backend#2743

---

Note

Low Risk
Comment-only change in CI workflow; label metadata was updated separately with no automation path modified.

Overview
Aligns human-facing label text with what customer-priority-bump actually does after RFC D5 removed the board Priority field and the workflow only runs gh issue edit --add-label priority.

The repo label fix is already live (not in this diff): all twenty enrolled repos now describe from:customer as automation adding the binary priority label, replacing the stale “auto-bumps Priority to P1” copy that survived because labels were cloned repo-wide.

This PR only adds workflow comments beside that gh issue edit step—history of the wrong description, the 2026-08-27 sweep, and that triage-labels-check.py still checks label existence, not description text (planned in backend#2744 on top of .github#364). No workflow logic or actionlint behavior changes.

^{Reviewed by Cursor Bugbot for commit b13cef3. Bugbot is set up for automated code reviews on this repo. Configure here.}