Observed while implementing #10090 (adding one gh label create line to scripts/pm/ensure-pm-labels.sh).
The script header carries this warning:
⚠️ GitHub hard-caps label descriptions at 100 characters: gh label create / gh label edit get HTTP 422 above that, and the || true (needed for idempotent reruns) swallows the failure — an over-long -d line means the label is NEVER created on a repo where it doesn't exist yet, silently, and a rerun can never repair it. Keep every -d in this file ≤100 characters (measured: a ~145-char description 422'd in live use).
Every property of that paragraph is a measured hazard, and nothing enforces it. The only thing standing between an over-cap -d and a label that is never created on some repo is the author counting characters by hand. It has already been paid once by hand: PR #9322 ("label descriptions ≤100 chars") trimmed the instances that had drifted over.
Live headroom is thin, so this is not theoretical: measuring the current file, repo:objectui is at exactly 100 characters, and five more descriptions sit between 96 and 98. Any editorial touch-up to those lines lands over the cap, 422s, and is swallowed.
Shape of a fix when graded (deliberately not implemented here — it is a new gate, out of scope for the one-line card):
- a check that parses every
-d "..." out of the script and fails above 100 characters. Measured in characters, not bytes: needs:contract-review is currently 97 chars / 101 bytes and lives, so the byte count is not the binding measure — a naive byte-length guard would red on a label GitHub accepts. - it belongs to the
scripts/** gate family that node scripts/pm/dispatch-gates.mjs already routes for this path.
Verification note from the #10090 run: the check is cheap to run out-of-tree — putting a fake gh on PATH that records label create invocations turns the script into a dry-run listing (48 create calls today) and the description lengths fall straight out of it. The script itself has no dry-run mode, which is the other half of why nothing measures this.
Duplicate check: enumerated all 11 open domain:skills cards; semantic issue search returned zero for this and for its own positive control, so it was not relied on.
Generated by Claude Code
Observed while implementing #10090 (adding one
gh label createline toscripts/pm/ensure-pm-labels.sh).The script header carries this warning:
Every property of that paragraph is a measured hazard, and nothing enforces it. The only thing standing between an over-cap
-dand a label that is never created on some repo is the author counting characters by hand. It has already been paid once by hand: PR #9322 ("label descriptions ≤100 chars") trimmed the instances that had drifted over.Live headroom is thin, so this is not theoretical: measuring the current file,
repo:objectuiis at exactly 100 characters, and five more descriptions sit between 96 and 98. Any editorial touch-up to those lines lands over the cap, 422s, and is swallowed.Shape of a fix when graded (deliberately not implemented here — it is a new gate, out of scope for the one-line card):
-d "..."out of the script and fails above 100 characters. Measured in characters, not bytes:needs:contract-reviewis currently 97 chars / 101 bytes and lives, so the byte count is not the binding measure — a naive byte-length guard would red on a label GitHub accepts.scripts/**gate family thatnode scripts/pm/dispatch-gates.mjsalready routes for this path.Verification note from the #10090 run: the check is cheap to run out-of-tree — putting a fake
ghon PATH that recordslabel createinvocations turns the script into a dry-run listing (48 create calls today) and the description lengths fall straight out of it. The script itself has no dry-run mode, which is the other half of why nothing measures this.Duplicate check: enumerated all 11 open
domain:skillscards; semantic issue search returned zero for this and for its own positive control, so it was not relied on.Generated by Claude Code