The rationale for freezing REQUIRED_TRAINS instead of deriving it named the
wrong reason in two places (the comment and the ledger section). Re-derived
read-only with git:
20850191 parents 5187fcdc8d13373b absorb merge, sync #1b9ceed6e parents 3e4a6181f3fbfdbb absorb merge, sync #2f4abe0a5 parents 43dcc1d2a76961de absorb merge, sync #3
All three absorb merges DO take the upstream tip as their literal second
parent, so «only f4abe0a5 has an upstream commit as its literal second parent»
was false. What holds is the first-parent shape: only f4abe0a5 sits on this
branch's first-parent line; 20850191 and b9ceed6e were made on lane lines and
reached mainline as the second-parent side of a lane-integration merge over a
campaign commit (0aa74e9f over 816e7b82; 0f9a8daf over 4c32691e). The re-tie
merge f61ea3c2 is not the cause and cannot be: it is an ancestor of all three
syncs, so it predates them.
The widened alternative is quantified rather than asserted: «second parent
descends from a recorded upstream tip» matches 35 / 15 / 6 merges on this tree
for the three tips, so it would demand a train row for every lane merge made
after a sync. The example given was 8fb08d44, which is not a merge at all; the
C6 lane merge is 9faccf31, whose second parent it is.
The design is unchanged — still a frozen inventory, still no subprocess — and
the TRAIN-F6 row now names both the absorb merge 20850191 and the integration
merge 0aa74e9f, so the one row recorded by its carrier says so.
8578a2af6d