Unify operation policy, durable state, and remote-effect reconciliation #4

Outcome

Timeouts and crashes must not leave users guessing whether remote work happened. Extend the existing publish and allocation receipts into a consistent operation model.

Priority: P1 · Foundation

Scope

• Classify operations as local edit, remote read, preview, allocation, or live write; represent query cost and approval requirements explicitly.
• Persist operation ID, pinned scope, relevant revision/hash, timestamps, progress, approval evidence, result/receipt, and retry/cancel policy.
• Define states such as prepared, approved where required, submitted, verified, failed, cancelled, and uncertain. Record intent before remote submission.
• Centralize policy enforcement so UI, CLI, and agent routes cannot bypass required gates.
• Use provider idempotency when supported and operation-specific reconciliation otherwise. Do not claim exactly-once delivery across external services.

Acceptance criteria

• A crash after submission never causes an automatic repeat of an uncertain non-idempotent operation.
• Approvals apply to the exact target and revision and become invalid when those change.
• A safe retry and an explicit new attempt have distinct identities and UI behavior.
• Cancellation does not falsely claim an already-submitted remote action was undone.
• Existing publish and widget-ID safeguards remain intact; agent warehouse execution and publishing remain unavailable unless separately designed and approved.

Validation

Inject failures before submission, after submission, and before receipt persistence. Assert no duplicate remote effect and correct reconciliation using fixtures.

Dependencies

• Define a typed, versioned command and event contract #2 — Define a typed, versioned command and event contract
• Extract a desktop-independent Studio engine and diagnostic CLI #3 — Extract a desktop-independent Studio engine and diagnostic CLI