[beta.30][P2] Reconcile successful job-run cancel and delete confirmations after state transitions #334

Finding and evidence classification

Source inspection of released 0.1.1-beta.29 at 4b148ebe824b3de445a12d30e95b8f5c30d53655 identifies a second exact-replay ordering defect in job-run cancellation and deletion.

This finding is deterministically source-inspected; it was not observed or reproduced by the beta.29 owner campaign. The campaign verified application-job cancellation itself. It did not establish exact cancellation replay after termination or deletion replay after tombstoning.

Tracking: release epic #282; functional acceptance #305 under #294. Related definition-confirmation repair: #333.

Deterministic scenarios

Cancellation followed by a terminal state

1. An authorized caller previews and confirms cancellation of an owned, active disposable run.
2. The cancellation confirmation succeeds and its idempotency outcome is recorded.
3. The run reaches a terminal state, such as Cancelled.
4. While the original plan remains valid, the caller repeats exactly the same confirmation.
5. Current source rejects the now-terminal run with job_run_action_invalid before inspecting the recorded confirmation outcome.

Deletion followed by a retained tombstone

1. An authorized caller previews and confirms deletion of an owned terminal disposable run.
2. The deletion confirmation succeeds and retains the run's deletion tombstone.
3. The caller repeats exactly the same successful confirmation within the original valid plan.
4. The ordinary owned-run lookup excludes deleted rows, so the endpoint returns job_run_action_invalid before replay reconciliation.

Both scenarios prevent a client from recovering the recorded successful outcome after its response becomes uncertain. They do not establish repeated dispatch, data corruption or an authority bypass.

Source evidence

ConfirmRunActionAsync at the immutable beta.29 source loads the ordinary owned run and checks terminal/deleted state before calling confirmations.ConfirmAsync.

McpOperatorJobStore at the same source records deletion through DeletedAtUtc, while GetRunOwnedAsync passes includeDeleted: false. The rejecting state is therefore a direct consequence of the first successful operation.

Focused repair

Recognize a consumed exact confirmation before applying mutable run-state or dispatch-readiness conditions that only govern a fresh action. Preserve current identity, tenant, policy, target and ownership admission plus complete confirmation binding and original expiry.

Use a dedicated authorized read of retained run tombstones when reconciling a successful deletion. It must retain exact subject, client, resource, instance, tenant, agent and target binding. A missing ordinary projection is not permission to disclose an unrelated historical result.

A replay must return the recorded successful action result without contacting execution authority again, requesting cancellation again, creating another accepted-operation/run audit or changing the run. Preserve original recorded result fields for new receipts. Any compatibility handling for older run-ID-only receipts must remain explicit, bounded and authorized. Malformed or inconsistent references must fail closed.

Fresh cancellation still requires a currently admissible active owned run and valid dispatch prerequisites. Fresh deletion still requires a terminal owned run. A failed validation must not consume an otherwise fresh confirmation, and a stale or changed request must not dispatch.

Acceptance criteria

• An exact successful cancellation confirmation replays after the owned run becomes terminal, with no second cancellation request.
• An exact successful deletion confirmation replays after the run is tombstoned, without deleting or writing again.
• Replays preserve the recorded run identity and original action-result fields for newly completed receipts; legacy handling is tested separately.
• Current policy/permission revocation, wrong actor/client/resource/instance/tenant/agent, changed target binding, changed reason/payload and expired or mismatched confirmation remain denied.
• Retained tombstone reconciliation proves current ownership and cannot disclose another caller's or target's result.
• Pending and failed outcomes remain accurately classified; malformed or mismatched result references cannot become success.
• Fresh terminal-run cancellation and active-run deletion remain rejected without consuming a new plan or producing an execution/audit mutation.
• Focused endpoint/store regressions assert unchanged persistence and exactly one underlying cancellation/accepted-operation/run-audit effect. Retain [beta.30][P2] Reconcile exact job-definition mutation replay before mutable ETag validation #333's definition-replay controls.
• Include the narrow repair in beta.30 through existing validation and release workflows, and carry fresh owner run-action retests forward in [beta.30][P1] Finish admitted MCP functional, runtime and policy-race acceptance #305/[QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294.