TASK-143 — check the merged result of every open change, and name the pair that disagrees

[ranjiao]

What was actually established, before anything was changed

The spec warned not to assume the diagnosis. Two things were measured first.

1. ci.yml already tests the merge result. actions/checkout resolves
refs/pull/N/merge on a pull_request event. PR #16's run that same morning
says so verbatim:

git fetch ... +9e18354...:refs/remotes/pull/16/merge
HEAD is now at 9e18354 Merge 96822a4e... into e9d8c4dc...

So "check out something different" would have been a change that looks right,
passes review, and prevents nothing.

2. For #14 and #15 that workflow never ran at all.

actions/runs?head_sha=e3f8621...     → total_count: 0
actions/runs?head_sha=765b2c1...     → total_count: 0
commits/<sha>/check-runs             → total_count: 0   (both)
gh pr checks 14 / 15                 → "no checks reported on the ... branch"

"Each was green on its own base" was each agent's own local suite run, not a CI
verdict. Both PRs were non-draft and merged cleanly against e9d8c4dc, and
PR #16 — created 33 seconds after #15 — did get a run, so Actions was working.
The cause of the two missing runs is not established; only the fact is.

The two real defects

1. The merge result is computed against the base as it stood when the event
   fired, and GitHub never re-fires pull_request when the base moves. TASK-100 — the two store files are in claims[], so a collision on them is reportable #14
   and TASK-110 — measure what Perry's own state costs, and propose a retention policy #15 were both computed against e9d8c4dc; TASK-100 — the two store files are in claims[], so a collision on them is reportable #14 landed on 02e61fd and
   TASK-110 — measure what Perry's own state costs, and propose a retention policy #15 landed on top of TASK-100 — the two store files are in claims[], so a collision on them is reportable #14. No run ever saw the tree that shipped. This is not
   theoretical: during this one session feat/work-modes moved 45ef9c6 →
   551274f → 60916fb3.
2. Nothing ever tests two open changes together.

The mechanism

tests/merge-check merges the base tip with every candidate and runs the suite
on that tree. If red, it re-runs the failing check three more ways — on the base
alone (pre-existing, attributed to nobody), on each candidate alone (that
change's own regression), and on each surviving pair. Green apart, red
together, is the pair.

merge-check.yml is a separate workflow because its triggers differ: it also
runs on push to an integration branch, which is the moment a base moves
under the PRs still open against it.

Happy path is one suite run; attribution only runs when the combined tree is red.

Rejected

• Filtering candidates by file overlap. TASK-100 — the two store files are in claims[], so a collision on them is reportable #14 touched schema/state-schema.json
  and bin/perry-lint; TASK-110 — measure what Perry's own state costs, and propose a retention policy #15 touched bin/perry-state-cost and its test — zero
  overlap. Any same-files shortcut misses exactly this failure.
• A pull_request-only job. It cannot fire when the base moves.
• Re-running everything on every merge. It names no pair, so it is not a check.

Verification

1 — the pair reconstructed. e9d8c4dc + e3f8621 + 765b2c1, full suite,
no module named on the command line:

CONFLICTING PAIR — pr14 × pr15 · test_state_cost.py
    pr14 alone: absent   pr15 alone: green   together: red
    FAIL: test_a_rewritten_path_carries_its_superseded_versions
    FAIL: test_an_unclaimed_file_under_the_state_root_is_still_reported

Exit 1, and those are the two failures the spec describes. The old mechanism
on the same commits: merge(e9d8c4dc, 765b2c1) runs test_state_cost at
21 tests, all green, and merge(e9d8c4dc, e3f8621) does not contain the
module at all. Green both ways, red merged — the miss reproduced, then caught.

2 — an independent pair is not reported. Two changes to the same tool
(bin/perry-state-cost gains a --rev alias; tests/test_state_cost.py gains
two argument-error tests) — the kind a same-area heuristic would flag:

pre-existing on the base — attributed to nobody:
  · test_diagnose.py
✓ nothing new is red on the merged result

Exit 0.

3 — attribution. The report names change × change × check. Where it cannot
narrow to a pair it says so and names the whole set rather than guessing. In the
run above it also correctly separated a solo breakage from a pair.

Live in CI (run 32391788811, 3m26s), which is also the pre-existing step
earning its place on the first green run:

merge-check · base feat/work-modes @ 60916fb3
  #27  d5bbdc0a  TASK-143 — ...
  … 1 check(s) red — baselining them on the base alone
pre-existing on the base — attributed to nobody:
  · test_host_support.py
✓ nothing new is red on the merged result

Without that step this run would have blamed the only open PR for a failure the
base already had.

The same tree, two verdicts

On commit d5bbdc0, both workflows ran against the same merged tree:

workflow	verdict	why
tests (ci.yml)	failure — ✗ test_host_support.py	red is red; nothing says whether this PR caused it
merge-check	success — attributed to nobody	same module, checked on the base alone first, found already red there

That is the whole argument for the differential. ci.yml has come back
failure on essentially every pull request since 2026-08-20 05:41, which is
why nobody reads it. A check that cannot be green is not a gate.

Two things a reviewer should not miss

Needs repository admin, not attempted here. Marking merge-check a
required status check in branch protection. Until an admin applies that,
this reports; it cannot refuse a merge. A workflow silently depending on an
unapplied setting would be worse than no change.

test_host_support::test_concurrent_mixed_registers_do_not_exceed_global_cap
is load-flaky — green 3/3 alone, red under a loaded parallel sweep, and red on
the CI base above. A test that flips under load can satisfy "green alone, red
together" by luck and name two innocent PRs. It is the most likely source of a
false accusation from this mechanism and is worth its own row.

Diff size

feat/work-modes is ahead of origin, so this PR carries those commits until the
branch is pushed. My own code diff is 4 files, +624 lines —
tests/merge-check, .github/workflows/merge-check.yml, a comment in ci.yml,
one line in AGENTS.md. git diff -- perry/ is empty.

🤖 Generated with Claude Code