[MaxGhenis]

Fixes a false positive from #560's test_a_pull_requests_own_commits_append_only, which is failing CI on open pull requests branched before #560 merged. It failed #567's shard 4 with nine "the registry was deleted" problems, one per own commit.

Cause

history_problems(base, head, full=False) walks rev-list --first-parent --reverse base..head and starts from registry_at(base). On a pull_request event, base is the merge base with master, now a master that has the registry. That breaks two kinds of pull request:

• Branched before Track B: held-out data registry for every Track B and open-population gate #560: its own commits have no registry, so each is reported as deleting it, whether or not the pull request has merged master since.
• Branched after Track B: held-out data registry for every Track B and open-population gate #560: the same happens as soon as master adds an entry, because each own commit lacks entries master added after the fork.

Change (src/populace_dynamics/track_b/holdout_registry.py)

history_problems takes a new keyword, pull_request (default False). The committed pull-request check passes pull_request=True; the push check does not.

With pull_request=True (a pull request's own commits):

• Start at the fork point. The walk starts from the registry at the first listed commit's first parent, where the listed commits leave landed history. If the fork point has no registry, own commits without one are fine.

• Landed merges keep both lines. A merge whose other parent brings in landed history (an ancestor of base that the first parent lacks) must extend _landed_union of its own predecessor and that parent's registry:

  • every entry, rule and source of both: each entry once, with each list at the longer of its two versions, and each rule as often as either line lists it, so dropping one copy of a repeated rule is a removal;
  • entries and rules that the base registry lists come first, in its order, then the pull request's others, then the landed line's. So another pull request's branch, once landed, is merged in master's order even when its own registry is not (a branch holding [H001, H003] against master's [H001, H002, H003]);
  • complete if either line is complete.

  The merge may instead extend the same union in the pull request's own order: its last valid registry's entries and rules, then the landed line's others. A stacked pull request that merged the request it builds on in its own order, before that request landed, so stays valid once it lands. The endpoint test still requires the base's order at the head, and CI always runs it.

  A field that differs between the two lines, or a list that each line extended differently, cannot be kept by any merge, and is reported at the merge. So is a line the union cannot combine: one that lists an entry id twice, or whose entries, rules or sources are malformed. A merge bringing in more than one line of landed history is reported.

• Unlanded merges. A merge of history that has not landed is compared with the pull request's own last valid registry.

Without it (pushes), the walk is master's: it starts at registry_at(base), where base is the push's before commit, and compares each first-parent commit with its predecessor. Merges are not treated apart.

Fail closed. A git failure while reading parents or ancestry raises LookupError. When one line has no registry, the union is the other line's. When either line repeats an entry id or is malformed, no union is formed: the merge is reported, naming that line ("registry: the pull request's registry cannot be combined at this merge: …", or "the landed registry").

Unchanged: the endpoint test (the head extends the base), validation with full, and the rule that a failing snapshot is not used as the next one's predecessor.

Review round 1 (Sol, at b6ecd8d): REQUEST CHANGES, answered in aa769ab

1. A landed side branch could erase protected entries. The landed parent's registry replaced the predecessor, so a merge of another pull request's stale landed tip could drop an entry this pull request held, and a later commit restore it, unseen. A canonical [H001, H002, H003] was also wrongly rejected against an incoming branch's [H001, H003]. Fixed by the union above. Both scenarios are now regressions.
2. Push comparisons could retreat behind before. Every walk started from the first listed commit's parent, so a push whose before is not on the tip's first-parent line was checked from an older commit. Fixed: push walks start at before, exactly as on master. Sol's scenario is a regression.

Sol's nonblocking notes are also answered: the property test now reaches multi-merge graphs, and the invariant below states the octopus case.

Review round 2 (at ac6dfe1): the coordinator's Opus delta review and Sol, both REQUEST CHANGES, answered in 3e587cca

1. The union failed open (Opus, blocking). _landed_union returned the landed registry, silently, when either line was not union-ready, and keyed entries by id, collapsing an id listed twice. Own commits are not validated (full=False), so three histories could hide a change to an own entry's units:

   • an own commit lists H006 again with other units, and a master merge keeps only the second;
   • a pull request branched before the registry creates one whose sources are a list, then a master merge drops its H006;
   • a merge of a landed tip whose sources are a list drops the pull request's H006.

   In each, a later commit adds H006 back with other units. Fixed: _union_ready requires each entry id once (as validate does), and a line that is not union-ready is reported at the merge. All three histories are regressions, each reported at its merge.

2. Repeated rules (Sol, medium). validate lets a rule repeat, but the union keyed rules by text. A master merge that kept a valid [one, one, incomplete] was reported, and [one, incomplete, one] → [one, incomplete] → [one, incomplete, one] passed. Fixed as the coordinator ruled: rules are counted in the union (each keyed by its text and its occurrence), so every copy is kept and dropping one is a removal. validate is unchanged. Both of Sol's histories are regressions, each in both layouts.

3. Stacked pull requests (Opus, nonblocking). B merged an unlanded A in the only order then accepted, its own; once A landed, that merge was reported, and no later commit could repair it. Fixed: a landed merge may also extend the union in the pull request's own order (above). The tradeoff is pinned by a test: an own-first master merge passes the history check, and the endpoint test reports it.

4. Invariant (1)'s wording (Opus). After a reported landed merge, the predecessor is that merge's union, not the last own snapshot. Corrected below.

5. Two unmergeable shapes (Opus, Sol; nonblocking, as at round 0 and on master). These are now listed under Limits.

6. Test gaps (Opus: 6 surviving mutants of aa769ab7; Sol: 8 scoped survivors of 12). A test now covers each one:

   • a landed merge that adds an own entry, which the next commit drops;
   • a landed merge that swaps two of the pull request's own entries. This one is reported, though the head still extends the base, which pins the base as the source of the order;
   • status_values and completion_record conflicts. The conflict test now runs over every immutable and every extending entry field, from the test module's own lists, so provenance and gate_identifiers are included;
   • landed rules the base lacks, in each order;
   • rules that are not a list;
   • a conflicting landed merge, reported once, with its union as the next predecessor. That is the documented "a failing snapshot is not a predecessor".
   • an own commit that fails right before a master merge. The merge is compared with the union of the last valid registry, not the failing one: after a rewrite of H001's units, a merge resolved to master's registry passes; after a commit that dropped H006, a merge without it is reported. 3e587cca lacked this test: the coordinator's round-3 reviewer found Sol's mutant for it surviving the targeted tests at 14c68e4f. Only the property test could catch it, and whether it does on every run is unconfirmed. The test is added in 789978f9.

   Three @examples pin the stale landed side in the property test: resolved with a drop, resolved correctly, and dropped then restored. The generator reached that class in 0 of 240 examples.

Review round 3 (the coordinator's Opus 5.5 delta review, at 14c68e4f, then 789978f9): APPROVE

• Every round-2 finding, the Opus review's and Sol's, is resolved. Two are now documented limits: u2 and u2b, the two unmergeable shapes.

• It reran the round-2 findings:

  • an own commit repeating an id, and a malformed own registry, are each reported at the merge, naming the pull request's line;
  • a landed tip with sources: [] is reported at the merge that drops H006;
  • a dropped repeated rule is reported;
  • a stacked pull request passes once its base lands.

• Repeated rules, as a multiset. For both the history check and the endpoint, it checked:

  • copies reordered;
  • a duplicate on one side only;
  • text changed with the count kept;
  • repeated rules on the conflict path;
  • the pull request's own order with copies.

  Sol's two layouts pass when kept and are reported when a copy is dropped and later restored.

• Regression. Round 1's 39 scenario checks still pass, and push mode matches master's in 1,484 of 1,484 cases.

• Replay. Over 389 remote branches, round 3 matches rounds 1 and 2. It differs from master's code only where master reports "the registry was deleted" on branches forked before the registry existed; starting at the fork point removes that by design.

• Tests at 789978f9. Both registry modules give 215 passed and 2 skipped (not a pull_request event, and the push-only check). The tier recount matches tier_counts.json.

• Two nonblocking notes, both applied in this body. Invariant (2)'s wording now says the repeated-id and malformed cases apply when both lines have a registry; when one line has none, the union is the other line's. The round-3 mutation result is below.

Invariants

• With pull_request=True, each own commit is compared with exactly one predecessor:

  • the registry at the fork point, for the first commit;
  • for a landed merge, the union of the current predecessor and the landed parent's registry, in the base's order or the pull request's own;
  • otherwise, the current predecessor: the last own snapshot that kept the rules or, after a reported landed merge, that merge's union.

  It must extend that predecessor.

• A commit is reported if and only if:

  • its registry removes, reorders or rewrites an entry of its predecessor, or otherwise breaks the append-only rule against it;
  • it deletes a registry its predecessor had;
  • it is a landed merge whose two lines cannot both be kept, or whose lines both have a registry and one of them repeats an entry id or is malformed;
  • or it is a merge bringing in more than one line of landed history, which is reported whatever its registry.

• A pull request whose own commits never change the registry, and whose merges keep both lines in master's order or its own, reports nothing, however master's registry moves.

• With pull_request=False, history_problems returns exactly what master's did, for every history.

Tests (tests/test_track_b_holdout_registry.py, +78 unit over master: 18,332 against 18,254; total 24,881)

Round 0 (b6ecd8d, ff29e5e):

• A pull request from before the registry, unmerged and after a master merge: passes.
• A pull request with its own registration while master grows, unmerged and merged: passes.
• Own commits after a master merge that rewrite an entry, delete the registry or drop a landed entry, and a merge that drops one: each reported exactly once, at that commit.
• Modify-then-restore on a pull request, with and without a master merge: reported at the modify commit.
• A merge of unlanded history: must extend the pull request's own registry.
• A merge of two landed lines (an octopus): reported.
• A crafted merge of the fork point, which the merge already contains, that drops an entry a master merge brought in: reported.
• A non-JSON registry at the fork point or at a landed parent: reported under that commit.
• Injected git failures in the parent and ancestry reads: raise.

Round 1 (aa769ab and after):

• Sol's scenarios: the stale landed branch (reported); the landed branch merged in master's order (passes) and in its own order (reported); and the push from a before off the tip's first-parent line, for delete and rewrite (reported).
• A push treats no merge apart: a merge of a side branch whose entry master itself dropped is compared with its first-parent predecessor only.
• Own extensions at a landed merge: kept (passes), dropped (reported), and diverged from master's (reported as a conflict). A landed merge that drops the pull request's own registration: reported.
• One line: an octopus of a landed and a contained parent brings in one line, kept or dropped.
• The first commit as a merge of an unlanded branch: reported for a rewrite it carries; not reported for an addition it leaves out.
• The union directly: order, rules, sources, complete from either line, missing and malformed inputs, and each kind of conflict.
• Property test (Hypothesis), rebuilt: each merge step builds what it merges, so graphs combine master growth, own commits, master merges, and merges of other pull requests' branches after they land (some forked before a master merge, so stale against what the pull request holds), resolved correctly or to the branch's own registry. The oracle tracks entries as indices and builds the expected registry from master's order, without the module's comparison code. At the committed settings (30 examples of up to 10 steps), one run's generate phase gave three or more first-parent merges in 18 of its 27 graphs, and at most eight (--hypothesis-show-statistics).

Round 3 (3e587cca):

• The union fails closed: a landed merge after an own commit that repeats H006, after an own registry whose sources are a list, and of a landed tip whose sources are a list. Each is reported at the merge, though a later commit adds H006 back with other units. Directly, each malformed or repeated-id line is reported, own or landed.
• Repeated rules: a master merge that keeps a registry listing a rule twice passes, in both layouts. One that drops a copy is reported, though the next commit restores it. So is an own commit's second copy dropped at a master merge. The union lists copies in each order.
• Order: a stacked pull request, both orders, before and after its base lands. Own order at a landed merge, for entries and for rules, passes the history check and fails the endpoint. A landed merge that swaps two own entries is reported.
• Survivors: the tests listed under review round 2, item 6, including a landed merge right after a failing own commit (789978f9).

Mutations

22 targeted mutants of this PR's new lines, each applied to the source alone and run serially against the module's history tests (-k on pull request, merge, landed, fork, history, push and union tests), then against the property test if those all passed. The source was restored after each one.

• At aa769ab7: 20 of 22 killed. The survivors were landed_merges_on_pushes (a push walk treating landed merges apart) and complete_not_kept (the union complete only when the landed line is).
• ac6dfe12 adds one test for each. Rerun on both: 2 of 2 killed. So 22 of 22 are killed by the tests at the head.

Each mutant and the first test that failed

Mutant	Killed by
start_at_base_on_pull_requests	test_a_pull_request_from_before_the_registry_passes[False]
fork_start_on_pushes	test_a_push_is_compared_from_its_before_commit[delete]
push_starts_empty	test_a_push_is_compared_from_its_before_commit[delete]
no_landed_merges_on_pull_requests	test_a_pull_request_passes_while_master_grows[True]
landed_merges_on_pushes	test_a_push_compares_a_merge_only_with_its_first_parent_line (survived at aa769ab7; killed by ac6dfe12's test)
landed_registry_replaces_predecessor	test_a_stale_landed_branch_cannot_drop_what_the_pull_request_holds
no_canonical_order	test_a_pull_request_passes_while_master_grows[True]
lists_take_the_landed_version	test_a_landed_merge_keeps_the_pull_requests_own_extensions[drops]
conflicts_ignored	test_a_landed_merge_keeps_the_pull_requests_own_extensions[diverges]
own_extras_left_out	test_a_stale_landed_branch_cannot_drop_what_the_pull_request_holds
start_at_last_parent	test_a_first_commit_that_merges_unlanded_history_starts_at_the_fork[rewrite]
no_containment_exclusion	test_an_octopus_of_a_landed_and_a_contained_parent_is_one_line
reversed_containment	test_an_octopus_of_a_landed_and_a_contained_parent_is_one_line
sources_from_landed_only	test_a_landed_union_orders_by_the_base_and_keeps_both_lines
complete_not_kept	test_a_landed_union_stays_complete_when_the_pull_request_is (survived at aa769ab7; killed by ac6dfe12's test)
rules_unordered	test_a_landed_union_orders_by_the_base_and_keeps_both_lines
malformed_returns_previous	test_a_landed_union_orders_by_the_base_and_keeps_both_lines
missing_incoming_returns_none	test_a_landed_union_orders_by_the_base_and_keeps_both_lines
schema_conflicts_skipped	test_a_landed_union_reports_what_no_merge_can_keep[schema]
source_conflicts_skipped	test_a_landed_union_reports_what_no_merge_can_keep[source]
immutable_conflicts_skipped	test_a_landed_union_reports_what_no_merge_can_keep[unit_keys]
divergent_lists_accepted	test_a_landed_merge_keeps_the_pull_requests_own_extensions[diverges]

Round 3, by the coordinator's round-3 reviewer, on the source at 14c68e4f and the tests at 789978f9. The source module is byte-identical at 3e587cca, 14c68e4f and 789978f9. There were 21 in-memory mutants: the reviewer's six, Sol's eight scoped survivors and nine on round 3's lines.

• At 14c68e4f, the committed tests killed 20 of 21. The survivor was failed_own_commit_used_for_union, which forms the union from the merge's first-parent registry instead of the last valid one. It passed the 91 targeted tests. The property test caught it only through a generated example, not a pinned one, so CI could miss it.
• 789978f9 adds test_a_landed_merge_after_a_failing_own_commit_unions_the_last_valid[rewrite|drop]. Under that mutant, both cases fail: in rewrite the merge is also reported, and in drop only the drop is. So pinned tests kill all 21 at the head.

Replay on the open pull requests

Run at ac6dfe12 on every open pull request's head, with master's tip (fe5ab5ab) as the base. That is CI's base too: on a pull request, the checked-out merge commit's merge base with master is master's tip. Each cell is the number of problems the own-commit check reports: master's history_problems, and this PR's with pull_request=True.

PR	Head	Own commits	Merges	Master's code	This PR
#581	1f51b60a	12	1	10	0
#580	2d081af9	1	0	0	0
#579	4a85f2a1	1	0	1	0
#577	c9c0f4a2	4	0	4	0
#575	1ec99fb0	4	1	2	0
#574	bdbd9146	7	1	4	0
#573	bde9d3dd	7	1	4	0
#572	3a07cc1e	6	1	4	0
#571	f78efbc6	6	0	6	0
#570	fda767c2	7	0	7	0
#569	b64705e2	5	1	5	0
#567	a184564b	11	1	9	0
#566	3d69b1fc	17	1	17	0
#565	4f1f70a2	7	0	7	0
#563	f3b9a719	3	0	3	0
#562	f865bb54	5	0	5	0
#561	dc0b6343	3	0	3	0
#554	2d0ed992	22	1	71	5
#582	ac6dfe12	4	0	0	0

• Track B B0.2: source, exposure, access and power records for B3 through J #554's five are real under the rule. All five are at e1c3c1e6, Track B B0.2: source, exposure, access and power records for B3 through J #554's own first draft of the registry. It added five entries that were not lone candidates, before the registry moved to Track B: held-out data registry for every Track B and open-population gate #560 with its rules. B0.2 will be resubmitted from a fresh branch, without that commit.
• Pushes: I ran master's last 12 first-parent commits, each as a one-commit push from its first parent, and the span from 1e739d32 to fe5ab5ab. Master's code and this PR's (pull_request=False) return the same problems on 13 of 13.

Limits

• The walk follows first parents. Commits that reach a pull request only through a merge of unlanded history are checked only through that merge's result, not one by one. The same was true before this PR.
• A landed side tip whose content master changed when landing it (fixed an entry, or left one out) cannot be merged by any resolution. The pull request should merge master instead. GitHub's merge commits don't produce this; a manual master merge can. It was reported at round 0 and on master too.
• A merge of a landed side tip resolved with a master entry that neither line holds is reported as a reorder, since that entry is inserted into the union. The pull request should merge master instead. It was reported at round 0 too.
• Own order at a landed merge is accepted there and reported only by the endpoint test, as noted above.

Not in this PR

• docs/design/track_b_holdout_registry_mutations.json still records the source as of Track B: held-out data registry for every Track B and open-population gate #560. Held-out data registry: round 7's follow-ups (unset event path, record ids, zero push boundary) #580, the round-7 follow-up, reruns the whole record on the merged source after this lands.

axiom: n/a: test infrastructure for the held-out data registry

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
social-security-model	Ready	Preview	Oct 25, 2026 4:16am UTC

[MaxGhenis]

Merged at 789978f9e19049fcd9619815e788b12a77f6aa23 (merge commit 4e20c6e4) by the Microcosm Dynamics coordinator session.

Gates at that head

• gh pr checks exited 0 on the latest run: all four pytest shards, pytest (3.14), both graph-integration jobs, lint, build and Vercel passed; deploy was skipped.
• The PR was MERGEABLE, with merge state CLEAN, and had no CHANGES_REQUESTED review.
• An independent review approved this exact head, and the merge was pinned to it with --match-head-commit.

Reviews

• Round 1: GPT-6.1 Sol, at b6ecd8d7. REQUEST CHANGES, answered in aa769ab7.
• Round 2, at ac6dfe12: the coordinator's Opus 5.5 delta review and GPT-6.1 Sol. Both requested changes; these were answered in 3e587cca and 14c68e4f.
• Round 3: the coordinator's Opus 5.5 delta review, of the source at 14c68e4f and the tests at 789978f9. APPROVE.
  • Every earlier finding is resolved.
  • Pinned tests kill all 21 targeted mutants.
  • Push mode matches master's in 1,484 of 1,484 cases.
  • The 389-branch replay matches rounds 1 and 2.
  • Both registry modules gave 215 passed and 2 skipped, and the tier recount matched.

The round-3 details are in the body's "Review round 3" and "Mutations" sections.

Follow-up: #580 reruns the registry's mutation record on the merged source.