Filed unassigned by the dev seat landing PR #13092 (which had to compute that file's exact byte budget, which is how the stale line surfaced). Comment-only; the gate itself is correct and green.
The two lines, eight apart
scripts/pm/check-skill-line-ratchet.mjs, inside CEILINGS:
['.claude/skills/pm-dispatch/references/landing-operations.md', 80],
and eight lines below, in the comment block attached to the release-aftercare.md entry:
// count (headroom 0, same convention as the entries above). Its pointer from
// landing-operations.md rides existing slack on that file's last
// MERGED-tracking line, so that ceiling stays at 82 — no re-wrap, no cut.
['.claude/skills/pm-dispatch/references/release-aftercare.md', 58],
"that ceiling" is landing-operations.md's, and it is 80, not 82. The file's own header comment records the move explicitly:
landing-operations.md moved the other way (82 to 80, its standing headroom locked in)
So the release-aftercare comment was true when written and went stale when that re-pin landed. Nothing reads it, so nothing went red.
Why it is worth a card rather than nothing
It is wrong in the direction that costs an author a round. Two claims, both false today:
- "that ceiling stays at 82" — a reader planning an edit to landing-operations.md reads 2 lines of headroom that do not exist. The real state is 80/80, headroom 0, and the gate says so on every run:
✓ check-skill-line-ratchet: .claude/skills/pm-dispatch/references/landing-operations.md is 80 lines (ceiling 80; headroom 0).
- "rides existing slack on that file's last MERGED-tracking line" — there is no slack on that line or any other. Measured with the script's own
wrapLine over every paragraph and list item in the file: the canonical wrap of each one is already the number of lines it occupies, so no paragraph gives a line back without a content cut.
The file is the one with the tightest budget in the ratcheted set and it is edited often, so the wrong number is read at exactly the moment it matters.
Suggested shape (not prescriptive)
Correct the number to 80 and drop or restate the "rides existing slack" clause, since headroom 0 is what the same block asserts for every other entry. It is a comment edit inside a governed file, so it needs the usual net-0 discipline in whatever PR carries it — cheap to fold into any other ratchet-script round rather than spending a PR on its own.
Generated by Claude Code
Filed unassigned by the dev seat landing PR #13092 (which had to compute that file's exact byte budget, which is how the stale line surfaced). Comment-only; the gate itself is correct and green.
The two lines, eight apart
scripts/pm/check-skill-line-ratchet.mjs, insideCEILINGS:and eight lines below, in the comment block attached to the release-aftercare.md entry:
"that ceiling" is landing-operations.md's, and it is 80, not 82. The file's own header comment records the move explicitly:
So the release-aftercare comment was true when written and went stale when that re-pin landed. Nothing reads it, so nothing went red.
Why it is worth a card rather than nothing
It is wrong in the direction that costs an author a round. Two claims, both false today:
✓ check-skill-line-ratchet: .claude/skills/pm-dispatch/references/landing-operations.md is 80 lines (ceiling 80; headroom 0).wrapLineover every paragraph and list item in the file: the canonical wrap of each one is already the number of lines it occupies, so no paragraph gives a line back without a content cut.The file is the one with the tightest budget in the ratcheted set and it is edited often, so the wrong number is read at exactly the moment it matters.
Suggested shape (not prescriptive)
Correct the number to 80 and drop or restate the "rides existing slack" clause, since headroom 0 is what the same block asserts for every other entry. It is a comment edit inside a governed file, so it needs the usual net-0 discipline in whatever PR carries it — cheap to fold into any other ratchet-script round rather than spending a PR on its own.
Generated by Claude Code