When automation fails, the first question is how far it got. Stopping before finding a button differs from pressing it and failing to read the result. I retained prepared and dispatched checkpoints so recovery would not default to repeating the same action.
A preparation record is not evidence of the action
Execute parses the contract, creates a step ID and records prepared. Dispatch has its own checkpoint and execution-epoch check before the driver proceeds. Preparation is a record of intent, not an input result.
Prepared alone cannot establish that the user's text arrived. Conversely, lack of visible change cannot establish non-delivery. Checkpoints and actual outcomes need to be read together. Intent, dispatch and verification therefore retain different evidence. A failed prerequisite checkpoint must not simply be ignored while continuing native input without the intended record. Storage failure is part of the execution boundary too.
Treat errors after dispatch conservatively
Catch considers the dispatched flag and uncertain-outcome errors before retaining an unknown result. A delivered mutation does not disappear because an error occurred. It cannot share the recovery policy of a target never found.
A gap can also exist between writing a checkpoint and sending a native event. A dispatched record must therefore not be advertised as proof of remote processing. It conservatively blocks replay; confirmed service storage needs separate evidence. The boundary retains uncertainty instead of manufacturing certainty.
An unconfirmed text input can remain pending too
After an unverified fill or rich-text dispatch, eligible conditions retain pending-input metadata: task, step, tab, target and expected input. Existing content needs inspection before another write because the manuscript may have arrived only partially.
This is internal recovery material, not text to copy into a public log or article. Sensitive-input exclusions do not constitute universal anonymization. The public maker journal explains state and rules without including actual customer bodies or identity.
Distinguish a first rejected click from partial completion
Flow has a narrow case for a first click with no completed steps, confirmed non-dispatch and a valid replanning path. It is not treated like a partially executed flow with earlier successful effects. Protection for existing uncertainty and partial progress remains.
Repeating earlier steps can duplicate storage or navigation. Claiming a repair of only the failed point requires knowing completed steps and dispatch phase. Creating a recovery plan differs from replaying the original procedure from the start. The journal must make that difference visible.
Restart does not automatically permit replay
Changed execution epochs reject late calls, while uncertain results need separate inspection. Reopening the browser does not turn a previously dispatched action into non-delivery. Local receipts, durable journals and service outcomes also have different lifetimes.
I read current checkpoints, error classification and flow-recovery conditions. I did not intentionally interrupt an operational reservation to test replay. Recorded phases differ from an exactly-once guarantee over the entire system. Honest interpretation of failure records is part of recovery design.
Error wording should point toward the next inspection
Showing only failed makes rerun look like the only option. Distinguishing preparation failure from post-dispatch uncertainty changes what should be inspected first. An agent can read the existing result instead of pressing the same button.
Business saves, deliveries and approvals need the same separation of intent, dispatch and checked outcome. I wanted recovery appropriate to the phase rather than an automatic repair that conceals it. An explainable boundary lets an operator choose the next needed action without overstating certainty.