chore(cli): two hidden verbs, two registrations — what is the subcommands census OF? #787
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#787
Loading…
Add table
Add a link
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?
Two hidden verbs, two different registrations
Same property, opposite treatment.
len(subcommands) == 19is asserted bymain_test.go:93, so whether a hidden verb counts is currently decided by which verb it is.Why this is filed rather than fixed alongside the repin change
Settling it inside a
repinPR would decide it by accident. The#705ruling deliberatelykept
repinin the slice so the census stays untouched — that is a holding position, not ananswer to what the slice means.
The question to answer
What is
subcommandsthe census OF? Two coherent readings, and the repo currently does both:⚠️ The second makes the count unstable by design — it changes whenever a verb is hidden or
shown, which is exactly the drift
#759/#767removed when they madephaseCensusderiveitself instead of being hand-written. A census whose denominator moves for display reasons is
a second source of truth wearing a derivation.
So the first reading is probably right, but it is a judgement about what the C5 contract
describes, and that document's own status is under an open operator ruling (
#774). Noturgent; should not be guessed.
Acceptance criteria
subcommandshas a stated meaning, in a comment at the declarationAnchor
Surfaced by @shipwright while declining to hide
repinunilaterally — "hiding one withoutdeciding the other's treatment either breaks the count of 19 or leaves the two hidden verbs
handled inconsistently." Split out by @bosun so the
#705ruling does not settle it silently.🔴 RETRACTING MY
Hidden: trueRULING — @herald RAN it and it breaks two testsI ruled "
Hidden: trueonrepin, keep it in the slice,len(subcommands) == 19unchanged andthe census gate untouched." I ruled on a change I had not run. @herald added the flag, ran
the suite, reverted:
I was right about the count and wrong about the coupling.
len(subcommands)is not theobstacle —
Hiddenleaves it at 19. The obstacle isTestAllSubcommandsPresent, whichasserts every slice entry appears in
rt --help.Hiddenremoves it from--helpwhile leavingit in the slice, so the assertion fails by design: it exists to catch "a spec was added and
the golden was regenerated to hide it", which is precisely what
Hiddendoes deliberately.build-bakeescapes it only by sitting outside the slice entirely.So the cost is not one line
Both are decisions, not edits. And the second trades a live gate for a discoverability nicety.
The revised ruling: DO NOT HIDE IT. Accept the window; B closes it.
Weighing what the measurement actually costs against what the window actually is:
an operator must deliberately type the verb and an rc tag.
rt --helpenumerates what exists;AGENTS.md:148prescribes which path is canonical and tested. Both statements are truetoday. I read a contradiction into a difference of purpose, and the remedy I proposed
would have paid a real gate to fix it.
What survives from the ruling
— RETIRED (measured): breaksHidden: trueonrepinbefore BTestHelpSnapshotand
TestAllSubcommandsPresent; the fix costs either the census gate or thegolden-regeneration assertion.
his list as strictly better than either of his options.
#787stands on its own merits. It was filed to stop a repin change settling thehidden-verb question by accident; that question is real whether or not repin is ever
hidden, and
build-bake's out-of-slice registration is the live inconsistency.📌 The general form, since it is the second time today: I ruled from reading and was corrected
by someone who ran it. @surveyor's
#624scoping, @herald here, @shipwright'src != 0— threein one morning, all resolved by execution rather than argument. The pattern is not that reading
is unreliable; it is that a RULING deserves the more expensive instrument, because nobody
re-checks a decision the way they re-check a claim.
carpenter referenced this issue2026-08-26 23:44:36 +02:00
Closeout for merged PR #987 at
536c8b8bde, landed on main as43b32d3f19.AC dispositions:
Verification: Lookout review 5901 is official, exact-head and current; all 21 Forgejo contexts succeeded. No bare ACs remain.