# Internet Food rerun recovery matrix

Status: Food local closure evidence rebuilt; **not an E2E or closure approval
until an independent exact-HEAD review passes**.
Previous one-edge envelopes are retained only as transaction-level regression
tests. They are not aggregate-ready evidence: a natural transition such as
`F-DELIVERING` intentionally leaves the order active, and the production
`VerifyFoodRerunStateReady` query must reject it. The closure fixture being
built must use one statement-aware transactional store, drive the same
`DomainEngine` through every legal natural successor until terminal state, and
only then call the production aggregate verifier against a separate committed
read session. No state-keyed helper, prefilled expected-resource map, or
single-edge test may be cited as readiness evidence.

This matrix is an engineering context record, not an approved requirements or
design document. Rows below that still name the old envelopes are an inventory
of required coverage and remain **unverified** until replaced by that durable
end-to-end domain-path evidence.

## Current durable evidence (2026-08-27)

### Selected-authority and transaction-proof amendments

The candidate adds the following executable evidence and narrows every
production selector before it orders or claims a row. A matching run digest is
not by itself authority: each queue/execution/root/fatal/pending reader joins
the order and requires the selected user authority plus the exact owned
`lane_id`/`ilu_id`/`world_unit_id` binding. Consequently a same-run row for a
different selected user cannot block, win ordering, or be mutated.

| Test | Production boundary and result |
| --- | --- |
| `TestFoodRerunAuthorityIsolationUsesCurrentRowsAtReadyPointAndExpiredEntrances` | An earlier same-run, same lane/ILU/world foreign-user queue is ignored by ready, point, and expired selectors; the selected row progresses and the foreign row is read back unchanged. |
| `TestFoodRerunPendingRootAndReadyProofIgnoreSameRunForeignUser` | Pending probe, root rehydrate, and aggregate ready verifier ignore an earlier same-run foreign-user root, while the raw committed row remains durable. |
| `TestFoodRerunRootAdmissionCommitLostAndPrecommitOutcomesReachTerminalVerify` | Both `F-SUBMIT` and `F-SCH-CREATE` cover root commit-response-lost recovery through the production guarded commit proof, then a separate rerun engine reaches `VerifyFoodRerunStateReady`; precommit failure leaves no committed order/queue residue and a retry is admitted. |
| `TestFoodNormalBatchWithCommittedRerunResidualNeverEntersRerunSQL` | A normal `RunOneBatch` on an engine previously configured for cleanup clears rerun mode before work selection; a committed residual is unchanged and no `food.rerun.*` statement executes. |

The transactional fixture keeps only committed raw rows. Its identity proof now
reads the exact `reservation_key` written by the production identity INSERT;
zero-effect checks derive legs, trips, availability, capacity buckets, stops,
ledger and settlement rows from the production statement arguments rather than
fixture constants. A second transaction reads the committed rows through the
same production query/verifier path.

The only rows that may currently be cited as production-path evidence are the
following tests in `industries/internet/food/runtime/rerun_natural_chain_durable_test.go`.
They use one transactional raw-row store, execute `DomainEngine.runOneCycle`,
commit every production mutation before an independent reader observes it, and
call `VerifyFoodRerunStateReady` only after the aggregate becomes terminal.

| Evidence | Coverage proved | Not proved |
| --- | --- | --- |
| `TestFoodRerunCancellationUsesCommittedPaymentRelease` | 8 cancellable active states, sealed `F-CANCEL-S`, payment/provider/merchant baseline recovery | retained-fatal variants |
| `TestFoodRerunNaturalChainUsesCommittedRowsUntilAggregateReady` | 5 post-pickup natural states continuously reach terminal aggregate | retained-fatal variants |
| `TestFoodRerunReadyRehydrationCleansEveryActiveSource` / `TestFoodRerunExpiredClaimReleasesSealedWorkThenExecutesIt` | ready rehydration and expired locator/inspect/fenced release for all 13 active cleanup successors | retained-fatal variants |
| `TestFoodRerunAuthorityIsolationUsesCurrentRowsAtReadyPointAndExpiredEntrances` / `TestFoodRerunPendingRootAndReadyProofIgnoreSameRunForeignUser` | current-vs-foreign same-run, same-lane/ILU/world competition at ready, point, expired, pending, root-rehydrate, and aggregate-ready entry | retained-fatal foreign cases beyond the scoped fatal locator regression |
| `TestFoodRerunExpiredReleaseReplaysCommittedMutationAfterCommitResponseLost` | committed release replay through the actual guarded commit-proof handoff | business-transaction commit-lost for every normal historical edge |
| `TestFoodRerunRetainedFatalNaturalResumePreservesEveryClassAtEveryEntry` | 5 natural source states × ready/point/expired × all 14 retained classes; same-identity resume, terminal aggregate proof, exact class and resource readback | normal historical-edge construction before the retained failure |
| `TestFoodRerunCancellableFatalStaleClosesOnlyAfterActualCancelWinner` | 8 cancellable states × ready/point/expired × all 14 retained classes; actual `F-CANCEL-S` winner followed by authenticated stale closeout | commit-response-lost variant |
| `TestFoodRerunCancellableStaleReplayPreservesFatalClassAfterCommitResponseLost` | 8 cancellable states × ready/point/expired × all 14 retained classes; committed stale closeout is replayed through guarded commit proof, then exact class/resource readback | normal historical-edge construction before the retained failure |
| `TestFoodRerunCancellableFatalWithoutWinnerFailsClosedForEveryLegalStateAndClass` | 7 non-root cancellable states × all 14 retained classes preserve started execution, ready queue, order/payment and owned capacity unchanged when no winner is proven | scheduled is N/A: its durable root marker causes the legal `F-CANCEL-S` winner to be produced before a no-winner branch exists |
| `TestFoodHistoricalRegistryProductionOutcomeMatrix` / `TestFoodHistoricalRegistryStrictStaleOrReplayBoundary` | all 57 non-root `edge/from-state` tuples are published by `publishFoodProgressionDecision`, then exercised through the normal claimant for success, guarded commit-response-loss replay, and retryable precommit failure followed by the same production retry; strict stale cases use a separately published legal competing edge and authenticated winner, while root-marker or single-successor tuples prove the committed replay boundary as stale N/A. Every committed path reaches terminal `VerifyFoodRerunStateReady`; identity namespace/ordinal assertions are derived from the emitted event/capacity/ledger mutation statements. | terminal/root-marker stale is deliberately N/A rather than fabricated; root admission tuples remain in the separate admission row |
| `TestFoodDecisionPublicationReportsCommittedInsert` | a successful `food.queue.publish.insert` commit reports `inserted=true` and is read back as the exact ready operation, preventing the publisher from returning the preceding `sql.ErrNoRows` branch result | replay publication (`inserted=false`) remains the existing idempotent path |
| `TestFoodRerunHistoricalNormalRegistryEdgeCommitsThenRerunsToTerminal` | all 57 non-root `edge/from-state` success tuples use the same production publisher and claimant and continue through terminal rerun verification; exact merchant, courier-capacity, and payment values are read from committed production rows | four-outcome authority is the shared matrix row above |
| `TestFoodRerunHistoricalRootAdmissionCommitsThenRerunsToTerminal` | both roots (`F-SUBMIT`, `F-SCH-CREATE`): the actual `AdmissionSink.SubmitRoot` transaction commits order/lines/payment/event/fact/root queue; a new rerun engine authenticates that committed source and reaches production ready | retained-fatal root branch is covered by the root/cleanup entry tests above, not by normal admission |

The normal-history source construction gap is closed for all 59 tuples. The
prose/table entries below remain a route inventory; final Food approval still
requires the mandatory independent exact-HEAD review.

The closure rule is the repository-level requirement in `AGENTS.md` at commit
`b1705c4e`: only a terminal aggregate plus the production read-only verifier
is a Food ready proof. A transaction-level edge test remains useful regression
coverage, but it is never a substitute for this row's terminal-chain evidence.

## Scope and evidence boundary

- The selected Food authority is the only scope: the node probe is restricted
  to its owned lanes/worlds and aggregate proof is restricted to the selected
  `user_authority_digest`.
- `DomainEngine` enables this only for `RerunCleanup`. Normal Run and normal
  cutoff Drain retain their existing future-root guards.
- A business transition is one transaction in
  `executeClaimedFoodWork`: business mutation, order CAS, event, operation
  fact, and queue/execution completion commit together. Therefore an observed
  mid-transaction interruption is either absent after rollback or is recovered
  from the committed proof; it is not repaired by direct table writes.
- Allocation is intentionally a separate transaction before `F-ASSIGN`.
  It is the one legal cross-transaction resource reservation: it creates
  `assignment=proposed`, `trip=proposed`, `leg=pending`, pending stops, and
  increments courier `occupied_units`. Rerun now explicitly reverses exactly
  this shape through `releaseFoodProposedProvider` when `F-CANCEL-S` cancels a
  ready order.

## Business-semantics guard

- No Food business state, registered edge, or terminal-state definition is
  changed. Rerun selects only the existing registered `F-CANCEL-S` feedback
  edge for cancellable states; post-pickup orders still use their existing
  fulfillment and finance edges.
- The proposed-allocation release is an internal, exact resource transition
  inside the existing `F-CANCEL-S` feedback transaction. The order terminal
  event, operation fact, queue/execution acknowledgement, and payment release
  are still written by the ordinary claimed-work transaction and its sealed
  contract. No standalone SQL marks an order terminal.
- It uses CAS-locked assignment/courier/trip/leg/stop rows and rejects every
  shape except the valid `proposed` reservation. The allocation transaction
  never inserted a capacity ledger acquire entry, so its exact inverse changes
  the bucket only and deliberately does not fabricate a negative ledger row.
- Historical order lines, catalog, promotions/redemptions, ledger, identity
  reservations/checkpoints, and cursors are never rewritten or reset.

## Required ready-entry mutation-set evidence (inventory; unverified unless named above)

`TestFoodRerunCleanupReadySuccessEnvelope` is parameterized over all thirteen
active source states and enters through the production ready queue. The
claimed work is selected, validated, claimed and committed by `DomainEngine`.
The minimal transaction-store fixture applies the emitted production SQL
`SET`/`VALUES` rows to a transaction-local raw table copy and publishes that
copy only on `Commit`. Its resource proof is then read in a separate
transaction from that committed row store. The reader receives neither
transaction-local state nor an executed-SQL journal. The case is state-keyed,
not grouped by handler family.

After every transition chain reaches a terminal order state, the same test must
open a separate production `VerifyFoodRerunStateReady` read-only transaction.
It must expose a residual while any active order, queue/execution lease,
merchant/courier capacity delta, payment hold, or delivery graph residue
remains. This is a write-after-read assertion, not an inspection of an
uncommitted executor session or a statement-ID/argument map.

The registry source fixture uses each actual `contract.EdgeID` as the durable
source event/fact/queue edge. It never derives an edge from just `FromState`;
the two root tuples have the dedicated root rehydrate path, nonterminal targets
continue through point-entry `DomainEngine`, and terminal targets are explicitly
source-loader-only N/A because their state machine has no legal successor.

Additional rerun-only guards covered by production-entry tests:

- A ready `started` execution whose retained class is restartable
  (`retryable_precommit`, `cancelled`, or `commit_unknown`) commits only the
  read inspection then takes the ordinary existing-identity restart path; it
  cannot enter strict fatal resume or remain blocked.
- `F-PAY-FAIL` zero-effect proof checks both balanced ledger reservations
  (ordinals 0 and 1), so a half-reserved reversal is not treated as zero effect.
- `DrainOneBatch(RerunCleanup=true)` enables the pre-run path only for that
  drain. The next public `RunOneBatch` on the same engine clears it before any
  normal work, so measurement does not issue rerun SQL.
- The next logical epoch reads the SQL aggregate result over persisted root,
  queue/lease, event, operation-fact and settlement columns; the test does not
  calculate a maximum in test code.
- Ready, point, expired, root, pending, and fatal candidate readers join the
  selected order and scope `authority_digest`, `user_authority_digest`, and the
  exact bound lane/ILU/world before their `ORDER BY`. A foreign same-run user
  or old attempt is a read-only miss and cannot mutate or win ordering
  competition.

| Source state | Required emitted resource effect |
| --- | --- |
| scheduled, submitted, reassign-pending | payment `released`, balanced release ledger pair |
| accepted, preparing | merchant in-flight `0`, capacity release entry, payment `released`, ledger pair |
| ready with proposed allocation | courier occupied `0`, assignment/trip/leg `released`, pending stops cancelled, **no** synthetic capacity entry, payment `released`, ledger pair |
| courier-assigned, partner-arrived | courier committed/occupied `0`, availability `available`, assignment/trip/leg `released`, pending stops cancelled, capacity release entry, payment `released`, ledger pair |
| picked-up | trip and leg become `in_delivery`; no cancellation or capacity reset |
| in-delivery | courier capacity `0/0`, availability `available`, assignment `completed`, capacity release entry, payment `capture_pending` |
| payable, payment-failed-retryable | payment `reversed_terminal`, reversal ledger pair, delivery financial outcome `reversed_terminal` |
| completed | settlement CAS and payment `settled` |

## State × recovery route

All entries below are the nonterminal states in
`foodActiveProgressionStates`. The implementation test
`TestFoodRerunCleanupLegalResidueResolvesThroughSealedRoute` is parameterized
over this full list and validates the sealed route catalog.

| Residual order state | Cleanup transition | Resource result required before readiness | Why this is legal |
| --- | --- | --- | --- |
| `food_scheduled` | `F-CANCEL-S` → `food_cancelled_system` | payment hold released | sealed feedback route |
| `food_submitted` | `F-CANCEL-S` → `food_cancelled_system` | payment hold released | sealed feedback route |
| `food_accepted` | `F-CANCEL-S` → `food_cancelled_system` | merchant in-flight decremented; payment hold released | feedback transaction has merchant release path |
| `food_preparing` | `F-CANCEL-S` → `food_cancelled_system` | merchant in-flight decremented; payment hold released | feedback transaction has merchant release path |
| `food_ready`, no allocation | `F-CANCEL-S` → `food_cancelled_system` | payment hold released | sealed feedback route |
| `food_ready`, proposed allocation | `F-CANCEL-S` → `food_cancelled_system` | courier occupied units decremented; assignment/trip/leg released; pending stops cancelled; payment hold released | exact proposed-allocation transition; no synthetic capacity ledger entry |
| `food_courier_assigned` | `F-CANCEL-S` → `food_cancelled_system` | committed courier capacity released; availability restored; graph released; payment hold released | existing `releaseFoodProvider` feedback path |
| `food_partner_arrived` | `F-CANCEL-S` → `food_cancelled_system` | committed courier capacity released; availability restored; graph released; payment hold released | existing `releaseFoodProvider` feedback path |
| `food_reassign_pending` | `F-CANCEL-S` → `food_cancelled_system` | prior provider is already released by `F-REASSIGN-*`; payment hold released | sealed feedback route |
| `food_picked_up` | `F-DELIVERING` → `food_in_delivery` | continue rather than cancel after pickup | model forbids cancellation after pickup |
| `food_in_delivery` | `F-PAYABLE` → `food_payable` | courier occupied capacity released by payable delivery transaction | sealed fulfillment/finance route |
| `food_payable` | `F-PAY-FAIL` → `food_payment_failed_terminal` | authorization reversed; zero open hold | sealed finance route |
| `food_payment_failed_retryable` | `F-PAY-FAIL` → `food_payment_failed_terminal` | authorization reversed; zero open hold | sealed finance route |
| `food_completed` | `F-SETTLE` → `food_settled` | settlement completes; zero open hold | sealed finance route |

Terminal states are not reset. A terminal row with a nonterminal queue,
execution, capacity net, payment hold, or delivery-graph state fails the
ready proof rather than being masked.

## Local acceptance command

The Food-only closure evidence is exercised with:

```bash
go test ./industries/internet/food/... -count=1 -timeout 300s
```

This is local production-path unit evidence only. It neither starts a TiDB
cluster nor claims E2E/QPS completion.

## Registry accounting and production-entry matrix

The immutable Food registry contains 27 edge identities and 59 exact
`edge/from-state` tuples. `TestCanonicalRegistry` and
`TestCompileExecutableTransitionContractsMatchesIndependentAuthority` verify
that full registry independently from recovery. Pre-run cleanup is not
permitted to choose an arbitrary tuple: for each of its thirteen active source
states it can only select the sealed cleanup successor below. Thus every
remaining tuple is historical normal-run lineage; it is authenticated as the
source event/fact before this table's successor is produced, never replayed as
a cleanup shortcut.

The following is the complete 59-tuple audit inventory. `Entry` names the
only recovery disposition for an interrupted row in that source state—not a
permission to execute the tuple again. Every non-root tuple first enters
`TestFoodRerunHistoricalNormalRegistryEdgeCommitsThenRerunsToTerminal` through
the production normal claimant; the two root tuples first enter
`TestFoodRerunHistoricalRootAdmissionCommitsThenRerunsToTerminal` through
`AdmissionSink.SubmitRoot`. Each then loads the committed source and reaches
the production aggregate verifier. The `Envelope` column is retained only as
the legacy entry/outcome inventory and is not the source of this proof.

| Registry tuple | Source → target | Capacity / finance effect | Entry and legal recovery disposition | Envelope |
| --- | --- | --- | --- | --- |
| F-SCH-CREATE | none → scheduled | none / create hold | rerun root → `F-CANCEL-S` | normal `AdmissionSink.SubmitRoot` + rerun: `TestFoodRerunHistoricalRootAdmissionCommitsThenRerunsToTerminal` |
| F-SUBMIT | none → submitted | none / create hold | rerun root → `F-CANCEL-S` | normal `AdmissionSink.SubmitRoot` + rerun: `TestFoodRerunHistoricalRootAdmissionCommitsThenRerunsToTerminal` |
| F-SCH-ACT | scheduled → submitted | release future soft reserve / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | scheduled → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | scheduled → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | scheduled → cancelled_system | release all / release-refund | source rehydrate → same sealed system cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-MERCHANT-ACCEPT | submitted → accepted | reserve prepare / retain hold | source rehydrate → `F-CANCEL-S` or authenticated stale | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-MERCHANT-REJECT | submitted → merchant_rejected | none / release hold | source rehydrate → `F-CANCEL-S` or authenticated stale | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-MERCHANT-TIMEOUT | submitted → merchant_timeout | none / release hold | source rehydrate → `F-CANCEL-S` or authenticated stale | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | submitted → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | submitted → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-M | submitted → cancelled_merchant | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | submitted → cancelled_system | release all / release-refund | source rehydrate → same sealed system cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PREPARE | accepted → preparing | prepare reserved→occupied / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | accepted → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | accepted → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-M | accepted → cancelled_merchant | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | accepted → cancelled_system | release all / release-refund | source rehydrate → same sealed system cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-READY | preparing → ready | release prepare / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | preparing → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | preparing → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-M | preparing → cancelled_merchant | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | preparing → cancelled_system | release all / release-refund | source rehydrate → same sealed system cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-ASSIGN | ready → courier_assigned | available→committed / retain hold | source rehydrate → `F-CANCEL-S`, reverse proposal if present | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | ready → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S`, reverse proposal if present | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | ready → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S`, reverse proposal if present | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-M | ready → cancelled_merchant | release all / release-refund | source rehydrate → `F-CANCEL-S`, reverse proposal if present | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | ready → cancelled_system | release all / release-refund | source rehydrate → same sealed cancellation, reverse proposal if present | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-ASSIGN | reassign_pending → courier_assigned | available→committed / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-SUPPLY-REJECT | reassign_pending → supply_rejected | release all / release hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | reassign_pending → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | reassign_pending → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | reassign_pending → cancelled_system | release all / release-refund | source rehydrate → same sealed cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-ARRIVE | courier_assigned → partner_arrived | committed retained / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-REASSIGN-P | courier_assigned → reassign_pending | release provider / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-REASSIGN-T | courier_assigned → reassign_pending | release provider / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | courier_assigned → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | courier_assigned → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-P | courier_assigned → cancelled_provider | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | courier_assigned → cancelled_system | release all / release-refund | source rehydrate → same sealed cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-REASSIGN-P | partner_arrived → reassign_pending | release provider / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-REASSIGN-T | partner_arrived → reassign_pending | release provider / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PICKUP | partner_arrived → picked_up | committed→occupied / retain hold | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DEADLINE | partner_arrived → deadline_missed | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-C | partner_arrived → cancelled_customer | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-P | partner_arrived → cancelled_provider | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-CANCEL-S | partner_arrived → cancelled_system | release all / release-refund | source rehydrate → same sealed cancellation | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-NOSHOW | partner_arrived → no_show_cancelled | release all / release-refund | source rehydrate → `F-CANCEL-S` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-DELIVERING | picked_up → in_delivery | occupied retained / retain hold | ready/point/expired retained fatal → same-identity natural resume | active source ready/point/expired success: `TestFoodRerunCleanupNaturalPointEnvelope`, `TestFoodRerunCleanupReadySuccessEnvelope`, `TestFoodDomainEngineExpiredFatalNaturalSources` |
| F-PAYABLE | in_delivery → payable | occupied→released / capture eligible | ready/point/expired retained fatal → same-identity natural resume | active source ready/point/expired success: `TestFoodRerunCleanupNaturalPointEnvelope`, `TestFoodRerunCleanupReadySuccessEnvelope`, `TestFoodDomainEngineExpiredFatalNaturalSources` |
| F-PAY-OK | payable → completed | none / capture-settle | source rehydrate → `F-PAY-FAIL` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PAY-PARTIAL | payable → partial_completed | none / capture-adjust-refund | source rehydrate → `F-PAY-FAIL` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PAY-RETRY | payable → payment_failed_retryable | none / retain retryable | source rehydrate → `F-PAY-FAIL` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PAY-FAIL | payable → payment_failed_terminal | none / settle-reverse | ready/point/expired retained fatal → same-identity natural resume | active source ready/point/expired success: `TestFoodRerunCleanupNaturalPointEnvelope`, `TestFoodRerunCleanupReadySuccessEnvelope`, `TestFoodDomainEngineExpiredFatalNaturalSources` |
| F-PAY-OK | payment_failed_retryable → completed | none / capture-settle | source rehydrate → `F-PAY-FAIL` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PAY-PARTIAL | payment_failed_retryable → partial_completed | none / capture-adjust-refund | source rehydrate → `F-PAY-FAIL` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PAY-RETRY | payment_failed_retryable → payment_failed_retryable | none / retain retryable | source rehydrate → `F-PAY-FAIL` | production point no-replay: `TestFoodRerunCleanupHistoricalRegistryTuplesCannotReplay` |
| F-PAY-FAIL | payment_failed_retryable → payment_failed_terminal | none / settle-reverse | ready/point/expired retained fatal → same-identity natural resume | active source ready/point/expired success: `TestFoodRerunCleanupNaturalPointEnvelope`, `TestFoodRerunCleanupReadySuccessEnvelope`, `TestFoodDomainEngineExpiredFatalNaturalSources` |
| F-SETTLE | completed → settled | none / close balanced intent | ready/point/expired retained fatal → same-identity natural resume | active source ready/point/expired success: `TestFoodRerunCleanupNaturalPointEnvelope`, `TestFoodRerunCleanupReadySuccessEnvelope`, `TestFoodDomainEngineExpiredFatalNaturalSources` |

### 59-tuple rerun applicability and outcome disposition

This second, complete inventory gives the outcome classification that the
registry table above intentionally separates from ordinary normal-run lineage.
`N/A` is not an untested route: it means rerun has no legal authority to
execute that historical tuple again. Its persisted event/fact/order version is
only authenticated while the current state selects the one active cleanup
successor. `C` means the old retained-fatal identity can only become an
authenticated stale closeout after the sealed `F-CANCEL-S` winner; it is not
replayed. `N` means the identical sealed post-pickup identity is resumed only
after the zero-effect proof. The tests named below enter through production
`DomainEngine` point/ready/expired paths.

| Tuple / source | Applicability | Outcome evidence |
| --- | --- | --- |
| F-SCH-CREATE / none | N/A: root creation is not a residual execution item | source is rehydrated as its current active state; no historical root tuple replay |
| F-SUBMIT / none | N/A: root creation is not a residual execution item | source is rehydrated as its current active state; no historical root tuple replay |
| F-SCH-ACT / scheduled | N/A: historical edge | current `scheduled` uses active C row |
| F-DEADLINE / scheduled | N/A: historical edge | current `scheduled` uses active C row |
| F-CANCEL-C / scheduled | N/A: historical edge | current `scheduled` uses active C row |
| F-CANCEL-S / scheduled | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-MERCHANT-ACCEPT / submitted | N/A: historical edge | current `submitted` uses active C row |
| F-MERCHANT-REJECT / submitted | N/A: historical edge | current `submitted` uses active C row |
| F-MERCHANT-TIMEOUT / submitted | N/A: historical edge | current `submitted` uses active C row |
| F-DEADLINE / submitted | N/A: historical edge | current `submitted` uses active C row |
| F-CANCEL-C / submitted | N/A: historical edge | current `submitted` uses active C row |
| F-CANCEL-M / submitted | N/A: historical edge | current `submitted` uses active C row |
| F-CANCEL-S / submitted | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-PREPARE / accepted | N/A: historical edge | current `accepted` uses active C row |
| F-DEADLINE / accepted | N/A: historical edge | current `accepted` uses active C row |
| F-CANCEL-C / accepted | N/A: historical edge | current `accepted` uses active C row |
| F-CANCEL-M / accepted | N/A: historical edge | current `accepted` uses active C row |
| F-CANCEL-S / accepted | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-READY / preparing | N/A: historical edge | current `preparing` uses active C row |
| F-DEADLINE / preparing | N/A: historical edge | current `preparing` uses active C row |
| F-CANCEL-C / preparing | N/A: historical edge | current `preparing` uses active C row |
| F-CANCEL-M / preparing | N/A: historical edge | current `preparing` uses active C row |
| F-CANCEL-S / preparing | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-ASSIGN / ready | N/A: historical edge | current `ready` uses active C row and exact proposed-allocation inverse when applicable |
| F-DEADLINE / ready | N/A: historical edge | current `ready` uses active C row and exact proposed-allocation inverse when applicable |
| F-CANCEL-C / ready | N/A: historical edge | current `ready` uses active C row and exact proposed-allocation inverse when applicable |
| F-CANCEL-M / ready | N/A: historical edge | current `ready` uses active C row and exact proposed-allocation inverse when applicable |
| F-CANCEL-S / ready | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-ASSIGN / reassign_pending | N/A: historical edge | current `reassign_pending` uses active C row |
| F-SUPPLY-REJECT / reassign_pending | N/A: historical edge | current `reassign_pending` uses active C row |
| F-DEADLINE / reassign_pending | N/A: historical edge | current `reassign_pending` uses active C row |
| F-CANCEL-C / reassign_pending | N/A: historical edge | current `reassign_pending` uses active C row |
| F-CANCEL-S / reassign_pending | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-ARRIVE / courier_assigned | N/A: historical edge | current `courier_assigned` uses active C row |
| F-REASSIGN-P / courier_assigned | N/A: historical edge | current `courier_assigned` uses active C row |
| F-REASSIGN-T / courier_assigned | N/A: historical edge | current `courier_assigned` uses active C row |
| F-DEADLINE / courier_assigned | N/A: historical edge | current `courier_assigned` uses active C row |
| F-CANCEL-C / courier_assigned | N/A: historical edge | current `courier_assigned` uses active C row |
| F-CANCEL-P / courier_assigned | N/A: historical edge | current `courier_assigned` uses active C row |
| F-CANCEL-S / courier_assigned | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-REASSIGN-P / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-REASSIGN-T / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-PICKUP / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-DEADLINE / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-CANCEL-C / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-CANCEL-P / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-CANCEL-S / partner_arrived | Active C | success: cancellation point/ready; stale: expired winner; commit replay: ready winner; failure: N/A for old fatal identity |
| F-NOSHOW / partner_arrived | N/A: historical edge | current `partner_arrived` uses active C row |
| F-DELIVERING / picked_up | Active N | success: point/ready/expired; commit replay: expired; stale: expired winner; failure: expired retained claim |
| F-PAYABLE / in_delivery | Active N | success: point/ready/expired; commit replay: expired; stale: expired winner; failure: expired retained claim |
| F-PAY-OK / payable | N/A: historical edge | current `payable` uses active N `F-PAY-FAIL` row |
| F-PAY-PARTIAL / payable | N/A: historical edge | current `payable` uses active N `F-PAY-FAIL` row |
| F-PAY-RETRY / payable | N/A: historical edge | current `payable` uses active N `F-PAY-FAIL` row |
| F-PAY-FAIL / payable | Active N | success: point/ready/expired; commit replay: expired; stale: expired winner; failure: expired retained claim |
| F-PAY-OK / payment_failed_retryable | N/A: historical edge | current `payment_failed_retryable` uses active N `F-PAY-FAIL` row |
| F-PAY-PARTIAL / payment_failed_retryable | N/A: historical edge | current `payment_failed_retryable` uses active N `F-PAY-FAIL` row |
| F-PAY-RETRY / payment_failed_retryable | N/A: historical edge | current `payment_failed_retryable` uses active N `F-PAY-FAIL` row |
| F-PAY-FAIL / payment_failed_retryable | Active N | success: point/ready/expired; commit replay: expired; stale: expired winner; failure: expired retained claim |
| F-SETTLE / completed | Active N | success: point/ready/expired; commit replay: expired; stale: expired winner; failure: expired retained claim |

The explicit test mapping for every active outcome in this table is:

- C success = `TestFoodRerunCleanupCancellationPointEnvelope` and
  `TestFoodRerunCleanupReadySuccessEnvelope`; C expired stale =
  `TestFoodDomainEngineExpiredFatalCancellationSources`; C replay =
  `TestFoodDomainEngineReadyFatalCancellationSourcesCommitReplay`.
- N success = `TestFoodRerunCleanupNaturalPointEnvelope`,
  `TestFoodRerunCleanupReadySuccessEnvelope`, and
  `TestFoodDomainEngineExpiredFatalNaturalSources`; N stale =
  `TestFoodDomainEngineExpiredFatalNaturalSourcesStaleWinner`; N failure =
  `TestFoodDomainEngineExpiredFatalNaturalSourcesFailure`; N commit replay =
  `TestFoodDomainEngineExpiredFatalNaturalSourcesResumeCommitReplay`.

| Source state | Only rerun successor | Resource effect / return proof | Ready / point / expired entry | Production-path evidence |
| --- | --- | --- | --- | --- |
| `food_scheduled` | `F-CANCEL-S` | release hold | root/point rehydrate; future schedule is not skipped | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_submitted` | `F-CANCEL-S` | release hold | point/ready/expired fatal leaves predecessor then publishes cancellation | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_accepted` | `F-CANCEL-S` | merchant baseline plus hold | point/ready/expired | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_preparing` | `F-CANCEL-S` | merchant baseline plus hold | point/ready/expired | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_ready` | `F-CANCEL-S` | proposed courier release if present, then hold release | point/ready/expired | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_reassign_pending` | `F-CANCEL-S` | provider already released; release hold | point/ready/expired | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_courier_assigned` | `F-CANCEL-S` | committed courier baseline, graph release, hold release | point/ready/expired | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_partner_arrived` | `F-CANCEL-S` | committed courier baseline, graph release, hold release | point/ready/expired | point + ready success; expired `F-CANCEL-S` winner stale for 3 retained classes: `TestFoodDomainEngineExpiredFatalCancellationSources` |
| `food_picked_up` | `F-DELIVERING` | delivery continues; no cancellation | point/ready/expired retained fatal only after zero-effect proof | point + ready success; expired same-identity resume + transaction for 3 retained classes: `TestFoodDomainEngineExpiredFatalNaturalSources` |
| `food_in_delivery` | `F-PAYABLE` | courier capacity release | point/ready/expired retained fatal only after zero-effect proof | point + ready success; expired same-identity resume + transaction for 3 retained classes: `TestFoodDomainEngineExpiredFatalNaturalSources` |
| `food_payable` | `F-PAY-FAIL` | terminal payment reverse | point/ready/expired retained fatal only after zero-effect proof | point + ready success; expired same-identity resume + transaction for 3 retained classes: `TestFoodDomainEngineExpiredFatalNaturalSources` |
| `food_payment_failed_retryable` | `F-PAY-FAIL` | terminal payment reverse | point/ready/expired retained fatal only after zero-effect proof | point + ready success; expired same-identity resume + transaction for 3 retained classes: `TestFoodDomainEngineExpiredFatalNaturalSources` |
| `food_completed` | `F-SETTLE` | settlement closure | point/ready/expired retained fatal only after zero-effect proof | point + ready success; expired same-identity resume + transaction for 3 retained classes: `TestFoodDomainEngineExpiredFatalNaturalSources` |

The table's resource-family tests execute the production Food transition
transactions with locked rows and assert the actual capacity/payment/ledger
effects. `TestFoodRerunCleanupReadinessScopesNodeThenChecksAggregateBuckets`
then proves no queue/execution/active order/open hold/net capacity/graph
residue remains, including the configured merchant/courier baseline. Catalog,
order-line, promotions/redemptions, ledger history, identity data and cursors
are deliberately not reset.

## Retained fatal-class caller ledger

This ledger implements the closure rule recorded by `AGENTS.md` at
`ba93f934`: every retained non-restartable class must either remain exactly
preserved until a proven completion/replay/stale outcome, or fail closed with
no queue/resource/business write. The three formerly exceptional classes
`proof_conflict`, `evidence`, and `state_version` are retained classes, not
retryable results.

| Caller / entry | Exact-class handoff | Success / replay / stale result | Failure result | Evidence |
| --- | --- | --- | --- | --- |
| `recoverNextExpiredFoodClaim` → `recoverExpiredFoodClaim` | locator class is re-read in the locked inspection; the inspection is authoritative | rerun performs no release and lets the exact durable row reach the resolver | normal Run returns the same class | `TestFoodExpiredRetainedFatalClassesStayOnRerunResolver` |
| `DomainEngine.runOneCycle` expired entry | expiry inspection, root/source probe, then rerun resolver operate on the same queue/operation identity | authenticated winner completes stale queue/execution with original class | malformed proof stops with no rewrite | `TestFoodDomainEngineExpiredFatalPassesToSameIdentityStaleResolver` |
| `recoverFoodRerunFatalStaleResidueInLane` | locked `last_error_class` is passed as `errorClass` to both closeout and commit-response recovery | `drainStaleFoodSourceWithCompletionClass` / `recoverCompletedFoodStaleSourceWithCompletionClass` exact-CAS preserve it | no winner or foreign/invalid proof fails closed | `TestFoodRerunFatalResidueAuthenticatesWinnerBeforeStaleCloseout` (ready, expired, commit-lost, retained-winner) |
| `claimAndExecute` → `resumeFoodRerunFatalNaturalWork` | strict rerun-only claim returns `claimedFoodWork.preserveCompletionClass` | same sealed identity reaches ordinary business transaction with the original class | no proof or normal Run cannot resume; no fence moves | `TestFoodRerunFatalNaturalWorkResumesOnlyZeroEffectSameIdentity`, `TestFoodRerunFatalNaturalWorkRejectsIncompleteProof`, `TestFoodNormalRunCannotResumeFatalNaturalWork` |
| `executeClaimedWork` | passes the exact class to `executeClaimedFoodWork` | completion exact-CAS retains the class | execution error returns before generic release/retry/disposition | `TestFoodRerunFatalResumeFailureRetainsClaimAndDiagnosis`, `TestFoodCompletionCASPreservesRerunFatalClass` |
| `executeClaimedFoodWork` commit-loss proof | passes the exact class to `recoverCommittedFoodResultWithCompletionClass` | replay accepts only matching completed execution class | proof conflict fails closed | `TestFoodRerunFatalCommitRecoveryRetainsOriginalClass` |
| winner proof during stale closeout | completed winner permits blank or valid retained nonrestartable history only | stale source retains its own original class; winner history remains independently validated | restartable or invalid winner class is rejected | `TestFoodCompletedWinnerExecutionProofAllowsOnlyDurableFatalHistory`, `.../expired-fatal-with-retained-natural-winner` |
| `releaseFoodClaim` / `recordFoodExecutionDispositionWithFence` | restartable input and prior class are required | not applicable to retained fatal history | retained fatal fence is rejected before opening a mutating session | `TestFoodRetainedFatalFenceCannotEnterRetryOrDisposition` |

No caller may use `outcomeChecked` or a recheckable-class exception to turn a
retained fatal class into `retryable_precommit`; that old bypass was removed.

## Fatal natural-edge rerun-resume matrix

This is a deliberately narrow recovery of an interrupted **post-pickup**
natural edge. It is reachable only while `RerunCleanup` is enabled. Normal
Run and ordinary cutoff Drain cannot invoke it: their point claimant remains
`food.queue.candidate.by-id` and the test
`TestFoodNormalRunCannotResumeFatalNaturalWork` asserts that no fatal-resume
transaction is opened.

It is not a generic retry. The only allowed outcome is a re-fenced claim for
the same `operation_id`, `queue_item_id`, edge, source state/version and
authority. The previous fatal execution class is carried only by that
rerun-cleanup claim and remains stored through a successful completion,
commit-response proof, or authenticated stale closeout. A subsequent execution
failure leaves the exact claim and class in place: it must not enter the normal
release/retry/disposition path. `completed` plus the authenticated winner
event/fact/queue proof is the stale outcome; `last_error_class` is not reused
as a stale marker when it contains the historical fatal diagnosis. Any failed
proof leaves both queue and execution fences untouched.

| Current state | Existing legal edge → target | Allowed entry | Exact no-effect evidence before reclaim | Resource/ledger evidence | Expected rerun result | Transaction coverage |
| --- | --- | --- | --- | --- | --- | --- |
| `food_picked_up` | `F-DELIVERING` → `food_in_delivery` | ready fatal queue | current order/version and matching source event; no operation fact or exact identity reservation | active trip; picked-up/open delivery leg | same sealed queue re-claimed, then normal fulfillment transaction | ready: `picked-up-ready` |
| `food_in_delivery` | `F-PAYABLE` → `food_payable` | expired owned claimed queue | current order/version and matching source event; no operation fact or exact identity reservation | committed assignment/availability/courier bucket; in-delivery/open leg; one completed and one pending stop; authorized open hold; no capacity-entry for this operation | same sealed queue re-claimed, then normal finance/delivery transaction | expired: `in-delivery-expired` |
| `food_payable` | `F-PAY-FAIL` → `food_payment_failed_terminal` | expired owned claimed queue | current order/version and matching source event; no operation fact or exact identity reservation | delivered/open leg; capture-pending or retryable open hold; no ledger entry for this operation | same sealed queue re-claimed, then normal terminal-finance transaction | expired: `payable-expired` |
| `food_payment_failed_retryable` | `F-PAY-FAIL` → `food_payment_failed_terminal` | expired owned claimed queue | current order/version and matching source event; no operation fact or exact identity reservation | delivered/open leg; retryable open hold; no ledger entry for this operation | same sealed queue re-claimed, then normal terminal-finance transaction | expired: `retryable-expired` |
| `food_completed` | `F-SETTLE` → `food_settled` | owned claimed queue; commit response may be lost | current order/version and matching source event; no operation fact or exact identity reservation | delivered/settled leg; captured, zero-open-hold payment; no ledger entry for this operation | same sealed queue re-claimed; a lost claim-commit response is accepted only after queue+execution proof replay | commit-unknown: `completed-commit-lost` |

The zero-effect queries are production transaction reads over the tables in the
resource-evidence column. `TestFoodRerunFatalNaturalWorkResumesOnlyZeroEffectSameIdentity`
asserts each query's actual table set and that this preliminary transaction
writes only queue/execution claim fences—not order, event, operation-fact,
payment, capacity, ledger, or settlement business rows. Its companion
`TestFoodRerunFatalNaturalWorkRejectsIncompleteProof` removes the final
resource proof and verifies that no claim fence moves.

The remaining nine active states in the state matrix never use this resume
path: their only rerun successor is the existing sealed `F-CANCEL-S` feedback
transition. `TestFoodRerunCleanupResourceFamiliesExecuteSealedTransitions`
maps all thirteen active states to their registered route and executes the
eight concrete resource-transition families (payment, merchant capacity,
proposed/committed provider, delivery, payable, terminal finance, settlement).
The transition registry, legal source/target pairs, and terminal definitions
are unchanged.

## Interruption point × handling

| Interruption point | Durable evidence and rerun behavior | Fail-closed condition |
| --- | --- | --- |
| Root marker only (`F-SUBMIT`/`F-SCH-CREATE`) | Rerun-specific root reader finds `ready` marker regardless of `available_at`, rehydrates source, publishes `F-CANCEL-S`, and atomically completes marker | bad source lineage or non-ready claimed marker |
| Source event/fact only | `loadNextProgressionSource` rehydrates by authoritative event/fact/order version; rerun does not apply normal scheduled cutoff | source/event/fact lineage mismatch |
| Event + normal successor queue | Existing decision may win first; its CAS advances the order, then cleanup rehydrates the new active state. A stale competing queue is authenticated and completed as stale rather than replayed | no authenticated current winner |
| Queue claimed / execution started | durable watermark includes `claim_expires_at`; `recoverNextExpiredFoodClaim` releases/re-proves before progression. A rerun whose clock is below an unexpired lease is rejected rather than waiting or running backward | lease cannot be authenticated or commit proof conflicts |
| `ready` or expired owned `claimed` queue with a fatal execution result | for a post-pickup natural edge with an exact zero-effect proof, rerun alone re-fences the identical sealed operation and runs its normal transaction; it never clears/reclassifies the fatal result. If that execution errors, it retains the claim/class rather than entering ordinary retry. Other current predecessors take their ordinary legal cleanup successor (`F-CANCEL-S`, fulfillment, or finance). Only after a strict authenticated winner event/fact/queue/execution proof advances that order may the obsolete queue/execution be terminalized; retained fatal class remains audit evidence while completed queue/winner proof represents stale closeout | foreign authority/owner, malformed queue/execution/attempt, fact/reservation/resource proof, missing winner proof, or a fatal successor all fail closed without a fence change |
| Business transaction interrupted before commit | transaction rollback leaves source/claim for retry; no partial business/resource rows are visible | retry/release CAS fails |
| Commit response unknown | `recoverCommittedFoodResult` validates event, operation fact, queue, execution, and result digests; stale-source recovery is separately authenticated | outcome cannot be proven; no automatic data rewrite |
| Allocation committed before `F-ASSIGN` | `food_ready` cleanup invokes the proposed allocation release transition in the feedback transaction | assignment/courier/trip/leg shape is not the exact valid proposal |
| Cleanup complete | node proof checks queues, executions, active orders, payment holds, and per-order capacity net; aggregate proof additionally checks merchant/courier configured baseline and delivery graph terminality | any residual blocks next Run |

## Safe logical clock

`ReadFoodPersistedLogicalWatermark` reads the maximum selected-authority time
from order/root fields, events, queue availability/claim expiry, execution,
operation facts, capacity entries, payment, ledger, allocation/delivery graph,
fanout, and settlement. It is read-only and returns zero only when there is no
durable logical timestamp. It does not use a guessed duration.

`TestReadFoodPersistedLogicalWatermarkTakesFutureMaximumAcrossRecoveryChain`
uses a mixed future root, queue availability, claim expiry, event, operation
fact, and settlement completion timeline and proves the API returns the
settlement maximum. The common coordinator consumes this API result to choose
the successor logical epoch; Food does not manufacture an offset itself.

## Intentional non-repair

Food has no inventory decrement table or stock mutation path: catalog items
are reference data and `food_order_line` records requested/fulfilled amounts.
Promotion/redemption, ledger, identity reservations/checkpoints, and cursors
are historical/audit data and are neither reset nor treated as capacity. A
contradiction in those or in a delivery graph is reported by the normal proof
path; it is not hidden by SQL correction.