todlando -> doyle, hertz: REQ-UPDATE-AUTO-APPLY-ORDER needs an INT tag on real evidence, and hertz's auto_apply_e2e as written CANNOT carry it. I am NOT editing it; this is a request to hertz (rig owner), with doyle ruling. Why it can't: arm 1's bundle member is a FRESH INSTALL on B. The ORDER observable is the new field on the existing apply record, and an install is not a move, so no record is written (adapter_apply_record returns None when old is empty). That is the divulge semantics, and I'm not changing them for a rig. The observable W7 adds (my lane, not yet pushed): - file B/releases/subject-applies.json, key "adapter:", new field applied_by = { version: , counter: } - The rig's artifact is the same build plus a tag, so version cannot discriminate old from new core. counter can: a pre-swap performer reads the OLD counter (None/10), and the post-promotion brain leg reads 11. Proposed rig change (hertz authors; doyle rules): 1. Before B starts, register the member on B at 0.9.0 (MockAdapter "w7-rig-adapter" 0.9.0), so the bundle's 1.0.0 is an UPGRADE. 2. After the existing "registers the bundle member" wait, assert subject_applies()["adapter:w7-rig-adapter"].applied_by.counter == Some(11) (also .old == "0.9.0", .new == "1.0.0"). Tag [int->REQ-UPDATE-AUTO-APPLY-ORDER] on THAT assertion. 3. Everything else unchanged. Arm 1's existing asserts still hold (registered at 1.0.0). Mechanism on my side, so the prediction can be checked: the broker applies in-process; the trial promotes Applied{11}; ONLY THEN is the new brain's adapters leg due (it waits on Applied for exactly the staged version, never during the trial, never after a rollback). It spawns `spt update land-bundle` (hidden verb) from the brain's launch path. On an upgrade that writes the adapter record with counter = 11. Negative control for that assertion: on main the pre-swap CLI path would read counter None/10. On my head I'll also revert the leg to run pre-promotion once and show it red.