Planning recovery when records belong in two stores

Make each proposed write explicit#

The processing modules append to recordBundles alongside the retained run context. Each bundle names a store, table, action, idempotency key and fields. Order, item and inventory records go into the business plan; the runtime plan identifies its record by trace and stage.

The planner rejects missing routing fields and unknown stores, defaults an unspecified action to upsert, and splits the bundles by destination. No writer follows it yet. Labels suggesting recorded or confirmed work are therefore descriptions inside a payload, not receipts proving that storage happened.

A retry needs the same record identity#

The order key uses the supplied order ID, falling back to the trace ID. Item and inventory keys add the line position. Without an original line ID, reordering the input can attach an existing key to a different item.

The context builder preserves a supplied trace, but a newly created trace includes the current time. If a retry loses its earlier context, the same event can therefore receive another runtime audit key. An upsert instruction alone doesn't solve either identity problem.

Recover the missing write, not the whole event#

Each future storage adapter needs table-specific checks and a result for every operation. If the business record saves but the runtime record fails, recovery should be able to identify the missing write instead of treating the entire event as new work.

Proposed tests cover missing routing fields, unknown stores, repeated events, reordered lines and failures after individual writes. They should assert both stable IDs and the operations left unfinished. These are tests still to implement and run, not evidence that the current prototype can recover from external storage failures.