ci: close two version/CI gaps a green PR cannot show you

[lilyshen0722]

TASK-100, two of its three parts. The third — strict: true, so a PR's checks must have run against current main — is a branch-protection change with a measured blast radius; numbers below, raised for @sam rather than done unilaterally.

1. The version guard could not see a PR pair

It compares this PR against its base, so two open PRs bumping the same package to the same version are both green: neither branch contains the other's commit.

I assumed that pair would conflict on the version line. It does not — measured, two branches both taking cli 0.1.30 → 0.1.31 while touching different files under cli/src merge with no conflict, producing a single 0.1.31 that holds both PRs' source. git sees one line changed the same way on both sides and has nothing to report. npm then carries a version mapping to an artifact neither PR alone produced, which is exactly #979 and #1017.

Older PR keeps the version, newer picks the next — always clearable by one author alone. Failing both would deadlock.

Only an added version line counts. Every stale branch carries an old package.json without proposing anything, and an earlier draft of my own measurement counted those: it reported 69 version claims across 33 PRs when the true number of PRs modifying a published package.json is 3.

2. Stacked PRs are under-gated, and it reads as a full green

Every guard here is declared branches: [main], so none of them runs on a PR based on another feature branch:

PR	base	checks
#1219	docs/checklist-rule-18-source-assertions	5
#1172	docs/checklist-rule-19-fail-noisy	4
#1132	docs/ax-two-call-sites	5
any main-based PR	main	~12

Absent from all three: the version guard, the stale-base guard, CodeQL analyze. Nothing counts checks, so a short green is indistinguishable from a clean one. A stacked base is also an auto-close dependency — when the parent merges and its branch is deleted, GitHub closes or silently retargets the child, and a retarget lands a diff that was never CI'd against main.

The new guard has no branches filter, deliberately: a check scoped to main cannot see the PRs it exists to catch.

Merging this reds those three PRs. That is the intent; they retarget to main and rebase.

Verification

pair, older PR claims the same version	red, names the older PR
pair, no overlap	pass
#1217 against real open PRs (proposes cli 0.1.20; older #1215 proposes 0.1.19)	pass, and correctly reports "proposes no version" for the stale commonly-mcp it merely carries
either gh call failing	red — an unchecked error yields an empty version list, which reads as "bumps nothing" and passes
base = main	pass
base = feature branch	red

Part 3, for @sam — strict: true has a blast radius

Currently strict: false, one required context (Test & Coverage), no required reviews. Turning on "require branches to be up to date":

• 33 of 33 main-based open PRs are behind main. Zero are up to date. Every one becomes unmergeable until rebased, including docs(adr-024): D3a — resolve the claim/batch blocker by partitioning on claim result #1083 and docs(plans): typed hire fields — schema shape (TASK-032) #1097, which you ruled to press ~10 minutes ago.

Worth knowing what the freeze already costs: #1215, #1217 and #1218 all show Source changed ⇒ version bumped green, from runs days old, and all three propose versions below current main (cli 0.1.19/0.1.20 vs main 0.1.30; mcp 0.3.5 vs 0.3.7). Today those runs would red. They conflict on the version line, so git stops the walk-back — the guard's green is stale, not load-bearing here, but it is stale.

Suggested sequence: press the PRs you have already ruled on, then flip strict: true, then rebase the rest.

🤖 Generated with Claude Code