Ask: Prune the accumulated blocked/infra-attempt/* and blocked/infra-model/* labels from the misospace/dispatch label set (and add a label-sync guard if the source keeps emitting them) so the kanban filter UI does not have to render 100+ dead labels.
Expected files: .github/labels.yaml, src/app/api/repos/route.ts or whatever reads labels, AGENTS.md (only if a guard rule is added)
Problem:gh label list --repo misospace/dispatch shows ~95 blocked/infra-attempt/N labels (N from 1 to ~95), plus 1 blocked/infra-model/name and 1 blocked/infra parent. These appear to be emitted by a loop somewhere that writes a fresh "blocked/infra-attempt/" per failed GHA attempt, never re-using prior IDs, never pruning them. They are noise on every kanban-board label filter, every repo add-label API call (which auto-creates labels in repos, see issues/label/route.ts comment block), and every audit view. The repo's own labels.yaml (the source of truth for managed labels per #373) does not declare any of them, so they are unmanaged drift. There is no operator-facing reason a single repo failure mode needs 95 unique identifiers.
Evidence:
gh label list --repo misospace/dispatch --limit 200 --json name | jq -r '.[].name' | grep '^blocked/infra' | wc -l returns ~97 (95 attempt + 1 model/name + 1 infra).- .github/labels.yaml enumerates status/, priority/p, type/, audit, agent/, pr-review-fix, ai-review — no
blocked/infra*. - issues/label/route.ts comment: "GitHub auto-creates a label that does not exist in the repo." — so a buggy label-emitter on the bridge or pr-followup path is free to spam new labels with no human review.
- AGENTS.md / SECURITY-ACCEPTED-RISKS.md do not flag this as expected behaviour.
Acceptance: All blocked/infra-attempt/* and blocked/infra-model/* labels are removed from misospace/dispatch via gh CLI or labels.yaml sync (whichever the repo's label-management workflow prefers). If the source emitting them is in-repo code (grep src/ for the literal "blocked/infra-attempt"), include a guard so new labels of that shape cannot be auto-created. Acceptance is a follow-up gh label list showing the blocked/infra* count is 0 or 1 (just the umbrella). Add a brief note in AGENTS.md or a doc in docs/ explaining why the umbrella is allowed and the per-attempt variants are not, so the next person does not regenerate them.
Ask: Prune the accumulated blocked/infra-attempt/* and blocked/infra-model/* labels from the misospace/dispatch label set (and add a label-sync guard if the source keeps emitting them) so the kanban filter UI does not have to render 100+ dead labels.
Expected files: .github/labels.yaml, src/app/api/repos/route.ts or whatever reads labels, AGENTS.md (only if a guard rule is added)
Problem:
gh label list --repo misospace/dispatchshows ~95blocked/infra-attempt/Nlabels (N from 1 to ~95), plus 1blocked/infra-model/nameand 1blocked/infraparent. These appear to be emitted by a loop somewhere that writes a fresh "blocked/infra-attempt/" per failed GHA attempt, never re-using prior IDs, never pruning them. They are noise on every kanban-board label filter, every repo add-label API call (which auto-creates labels in repos, see issues/label/route.ts comment block), and every audit view. The repo's own labels.yaml (the source of truth for managed labels per #373) does not declare any of them, so they are unmanaged drift. There is no operator-facing reason a single repo failure mode needs 95 unique identifiers.Evidence:
gh label list --repo misospace/dispatch --limit 200 --json name | jq -r '.[].name' | grep '^blocked/infra' | wc -lreturns ~97 (95 attempt + 1 model/name + 1 infra).blocked/infra*.Acceptance: All
blocked/infra-attempt/*andblocked/infra-model/*labels are removed from misospace/dispatch via gh CLI or labels.yaml sync (whichever the repo's label-management workflow prefers). If the source emitting them is in-repo code (grep src/ for the literal "blocked/infra-attempt"), include a guard so new labels of that shape cannot be auto-created. Acceptance is a follow-upgh label listshowing the blocked/infra* count is 0 or 1 (just the umbrella). Add a brief note in AGENTS.md or a doc in docs/ explaining why the umbrella is allowed and the per-attempt variants are not, so the next person does not regenerate them.