Restarting everything after one blocked step can resend material already entered or delivered. Partial resumption first distinguishes whether dispatch occurred. Continuing one live failed step, reading its original result, and checking retained input after restart are different boundaries with different evidence.
Do not reopen work preceding the failed step
The engine passes stepIndex and completedSteps to its failure callback and handles only the current step within the same execution. A pre-dispatch lookup failure can accept a constrained target relocation instead of restarting the earlier opening, extraction and input sequence.
The corresponding fixture uses extraction, confirmation click and another extraction, repairing the middle target name. It checks one open, one click and the two extractions in their original positions. This identifies completed versus newly executed work rather than celebrating a low click count alone. It is a synthetic substitute test, not fresh external submission success.
Do not resend a dispatched action as a repair candidate
When failure.dispatched is true, repairProgramStep reads the retained pending outcome through verifyOutcome before asking a model for another target. Missing original pending evidence or failed readback ends OUTCOME_UNKNOWN. A new patch cannot make an unknown earlier result safe.
A fixture sends once, produces an uncertain error and verifies the original result, requiring sent to remain one and no model decision. Counterexamples check that failed verification, cancellation and weakened expectations do not authorize retry. Preserving the original condition matters more than finding an easier target to confirm.
After restart, verify the same document and actual values
VerifyResumedInput reads a fresh observation from the retained tab and URL. Exactly one element must match role, name and type. A retained document title requires a unique title field, with both title and body checked through verifyField. Identical body text under another title is not accepted as the same original input.
The readback dispatch callback throws if sending is attempted. Confirmation cannot become reinserting the same body. Run-generation checks after awaited observation and value verification also prevent a late read from silently belonging to an obsolete execution. Resumption and new typing are different actions. Internal exact-value evidence also differs from a public structural diagnostic, so actual manuscript content is not copied into the shared example.
Release the guard after retaining verification evidence
Matching title and value lead to a read_after_repair checkpoint for the original step/task IDs before resumeInput is cleared from scope and task. The memory guard is not cleared before awaiting that record. Evidence persistence and release of protection therefore have an inspectable order.
Tests include another title, duplicate fields, changed URL and unmatched body. Protection remains and publishing or input replay is blocked by OUTCOME_PENDING. Plausible-looking text on screen is insufficient. The original input identity and matching current readback are both necessary before continuing.
Separate the reviewed resumption contract from new execution
This account explains retained broker/engine functions and historical partial-repair contracts. Internal model repair remains removed, and automatic connection of this helper to every current plugin has not been verified. I performed no new service replay or restart recovery for the article.
The linked synthetic outcome module compares an original condition with observations; it is not a manuscript recovery system or durable workflow engine. Resumption should preserve what is already complete rather than mean quickly starting over. Stopping at an unproven result is part of making the next stage trustworthy.