03 — The first durable MUTATING apply through OperatorRuntime

1. What it closes

The 540x macro proved OperatorRuntime.apply durably for a read-only command (dot_iu_healthcheck) under a briefly-open gate. Its doc 07 gap #2 asked for a durable mutating apply — turning the operator runtime from "read-only proven" to "governed mutation proven". This macro does it.

2. The proof driver

operator_runtime_durable_proof.py (in this macro folder) — a committed, reproducible driver. It drives the real OperatorRuntime + psql_executor against production, on the durable runtime/290 collection. Discovery-driven: the collection is resolved by collection_key, the reordered piece is the live highest piece_order — no uuid baked in. Deployment coordinates are argv, never hardcoded.

The operator_runtime_enabled + composer_enabled gates are opened ONLY for the mutating window and closed in a finally block — guaranteed inert end-state.

3. The seven-step durable proof (actor runtime_500x_op_proof)

step	call	status	mutating	ledger
1	plan(dot_iu_reorder_piece)	planned	t	1 row
2	apply(dot_iu_reorder_piece, new_order=0)	applied	t	1 row
3	verify(dot_iu_validate_collection)	verified	f	1 row
4	apply(dot_iu_checkpoint_collection)	applied	t	1 row
5	apply(dot_iu_reorder_piece, new_order=back)	applied	t	1 row
6	verify(dot_iu_validate_collection)	verified	f	1 row
7	apply(dot_iu_reorder_piece) gate shut	refused	t	1 row

Step 2 is the first durable mutating OperatorRuntime apply — it moves the piece at piece_order=2 to 0 via fn_iu_collection_reorder_piece. Step 5 is the compensation — the exact inverse, restoring the piece to piece_order=2. Step 7 proves the apply path is still fail-closed: with the composer gate shut the apply is refused (closed_gates=['iu_core.composer _enabled']) before any plan SQL runs.

4. Governed, bounded, reversible

• Governed: every apply runs only a DotCommandPlan whose statements are SELECT public.fn_* calls; _assert_governed re-checks before execution. dot_iu_reorder_piece → fn_iu_collection_reorder_piece, dot_iu_checkpoint_collection → fn_iu_collection_checkpoint.
• Gated: apply required gates are derived from the plan's target functions — both reorder and checkpoint require operator_runtime_enabled
  • composer_enabled. A shut gate refuses; the refusal is audited.
• Bounded: one piece, one collection. verify (steps 3, 6) confirms the collection still validates fail-closed after each mutation (fn_iu_collection_validate → ok=true).
• Reversible: step 5 is the compensation, proven durably. After it the membership order is 0/intro, 1/body, 2/236bdf6e — exactly the original.
• No secret logging: the ledger stores an md5 params_digest; the raw collection_id never enters the ledger SQL.

5. Durable footprint + end-state

dot_iu_command_run 4 → 11 (+7 this proof, all actor runtime_500x_op_proof, reversible by DELETE … WHERE actor=…). v_dot_iu_command_run_health afterwards: 11 total / 6 apply / 4 applied / 2 refused / 0 failed / 5 distinct commands / catalog 17. v_dot_iu_command_registry: dot_iu_reorder_piece 4 runs / 2 applied / 1 refused; dot_iu_checkpoint_collection 1 / 1 applied; dot_iu_validate_collection 2 / last_status=verified.

End-state: iu_core.operator_runtime_enabled=false, iu_core.composer_enabled=false — both inert.

6. Proven dot_iu_* commands this macro

dot_iu_create_file_from_pieces (→ fn_iu_compose, via runtime/290), dot_iu_reorder_piece (apply ×2 + plan + refused), dot_iu_checkpoint _collection (apply), dot_iu_validate_collection (verify ×2) — all through the governed runtime, all ledger-audited.