.github/labels.conf + CONTRIBUTING + labels.test — swap glm for kimi on the panel while kimi is down #222
Labels
No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:docs
scope:guards
scope:labels
scope:release-flow
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heavy-duty/ceremony#222
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
kimi-reviewer-andresmgslis temporarily unavailable (vendor tokenexhausted; @andres is restoring it). That is not a cosmetic outage, because of
how the panel resolves:
With three identities and one of them always the author, kimi is in the
required set for every possible author. So while it is down, no new PR on
this repo can converge — #219's release PR and #217 both need it, and so would
any fix that arrives in the meantime.
What this does not affect: !218 (
960e581) and !221 (286403d) alreadycarry kimi's approval at their exact current heads, banked before the
outage. Those two are unaffected as long as nothing pushes to them — a new
commit would invalidate an approval that cannot currently be renewed.
glm-reviewer-andresmgslhas been reviewing on this board throughout at@andres's direction — it found the auto-merge
ghregression on #198 that fourother passes missed, and it has withdrawn and corrected its own verdicts when
shown evidence. It is an org member (
id=8) and resolves on this instance. Itsverdicts have been advisory only, because it is not in
panel=.Spec
Swap
kimi→glminpanel=. The panel stays three identities, so"two cross-vendor approvals" in
CONTRIBUTING.mdremains accurate and noprose about the count changes.
Three files move together, because the #195 guard is bidirectional.
test/labels.test.sh'sroster_in_syncdiffs.github/labels.confagainstCONTRIBUTING.md's roster table in both directions, and itstable-side mutation case hard-codes the identity it removes:
.github/labels.conf— thepanel=line;CONTRIBUTING.md— the roster table row;test/labels.test.sh— the mutationsedmust name an identity that isactually in the table, or the "in the table but not the conf" case
mutates nothing and stops testing anything.
This is a swap, not a removal-and-replace of the bench. When kimi
returns, @andres's instruction is to add it back alongside glm, giving a
four-identity panel. That is a second edit and is deliberately not done
here — it changes "two cross-vendor approvals" to three, which is a real
change to the review cost and to
CONTRIBUTING.md's prose, not a rostersubstitution.
glm-boxis assumed for the roster table's box column, following the<vendor>-boxconvention of its neighbours. @andres should correct it ifthe tenant is named otherwise; nothing machine-readable depends on that
column.
Tasks
.github/labels.conf:panel=names codex, glm, cluade.CONTRIBUTING.md: roster table row swapped, box column set.test/labels.test.sh: the table-side mutation names an identity presentin the table.
changelog.d/fragment.Acceptance criteria
panel=and theCONTRIBUTING.mdroster table name the same threeidentities, and
test/labels.test.sh'sroster_in_syncpasses.the guard still tests something after the edit.
panel=resolves on this instance.test/run.shendsfailed 0; shellcheck- and actionlint-clean.authors — verifiable on the next PR's reconciler pass.
Test plan
test/labels.test.shwhole, including both bidirectional mutation cases.CONTRIBUTING.md— the guard must red onconf/table drift rather than pass one-way.
test/labels.test.sh's mutation namingkimiafterkimi leaves the table — the case silently stops proving anything, which is
the #195 rot class one layer down.
test/run.sh→failed 0.Dependencies
None. Does not unblock !218/!221 — those still need @andres's ruling on the
authorship gate; their required set merely becomes codex + glm, and codex's
REQUEST_CHANGESstands either way.