The stage-order gate checks the assembly pass stages, and the converted relations lose their retired names in prose

The stage-order invariant, that no step of a pass reads a table a later step of the same pass writes, is checked for every stage stated as a jOOQ statement, not just the ones in the derivation stratum. StageOrderGateTest models the stratum FactCapture.derive runs, and it can now derive a jOOQ stage’s read set from the statements the stage executes (ViewReferences.relationsReadBy over a Query). The assembly pass, GraphitronAssemblyCapture.capture, runs the field-site @reference hop and walk stages (FieldReferenceStepHops.deriveKeyed/deriveKeyless, then FieldReferenceStepTargets.derive) and nothing checks their order. FieldReferenceStepTargets already exposes statements(dsl, graphName). FieldReferenceStepHops exposes none: its inserts are built and run inside insertKeyed/insertKeyless. When this lands, a hop or walk stage moved ahead of what it reads fails the build the way a misplaced stratum stage already does.

The plan that converted the column-scope departures and the argument and input-field walks into stages meant to cover these stages "on the way past". That did not happen, because they run in a different pass that the stratum gate does not model. The input-field walk in the stratum reads graphitron_field_reference_step_hop, which the assembly pass writes. That edge is sound today only because ModelCapture calls GraphitronAssemblyCapture.capture before FactCapture.derive, and no gate states that ordering.

These surfaces survived the retirement sweep. They go with the first commit that touches each area:

Found at R958’s In Review → Done gate. Filed rather than absorbed there: the gate part was scope the plan named on a wrong premise, that the hop stages sat in the stratum, and the implementer disclosed it in the item body; the prose part is the residue of that item’s retirement sweep.