feat: model operation outcome guarantees

README.md

@@ -55,8 +55,9 @@ runs it. It demonstrates all of the following:
    validator, operation, and schema-neutral `Value` arguments;
 7. validated result values decoded back to the typed application result;
 8. independent dispatch of the same `status` operation name on both interfaces;
-9. distinct domain rejection, host/backend failure, `PermissionDenied`, stale
-   validator recovery, interface membership, and lookup failure codes; and
+9. distinct domain rejection, rollback-confirmed and outcome-unknown
+   host/backend failures, `PermissionDenied`, stale validator recovery, interface
+   membership, and lookup failure codes; and
 10. canonical failure precedence when several request fields are invalid.
 
 Run it inside the development shell:
@@ -212,17 +213,28 @@ failures, while unsupported descriptor formats remain local
 For operation calls, `Internal` and `ResourceLimitExceeded` guarantee that the
 operation did not run or that its effects were rolled back.
 `OperationOutcomeUnknown` is the only protocol code that makes no such
-guarantee, so Clients must not automatically retry it. The current host API maps
-implementation failures and invalid post-execution results conservatively to
-`OperationOutcomeUnknown`.
+guarantee, so Clients must not automatically retry it. `wip::HostError`
+therefore requires both a `HostErrorKind` and an `EffectGuarantee`; implementation
+panic, result encoding, and result validation default to an unknown outcome.
+Host-private diagnostics are bounded locally but never copied into protocol
+messages.
 
-Providers remain responsible for backend atomicity. Enter a transaction, lock,
-stable-handle scope, or conditional-update primitive before invoking the
-`with_object` callback, and retain it until the callback returns. Mutable
-operations must make validator comparison and backend commit atomic and return a
-validator for the committed state. The runtime never validates one object and
-then resolves a second snapshot, but it cannot make an arbitrary external
-backend atomic by itself.
+`ExecutionContext` carries a runtime-neutral cancellation token, monotonic
+deadline, and optional Host-defined resource budget through resolution and
+execution. Cancellation and deadlines are cooperative: the runtime checks them
+immediately before typed invocation, while providers enforce them during backend
+work. A pre-invocation limit failure is `ResourceLimitExceeded`; after invocation
+it is safe to use that code only when non-commit or rollback is confirmed.
+
+Providers remain responsible for backend atomicity. `with_object` returns a typed
+`ProviderResult`, and `execute_operation` receives an `OperationAttempt` that
+separates `NotStarted` from `Started`. A transactional provider holds its
+transaction across the callback, commits successful attempts, and may call
+`OperationAttempt::confirm_rollback` only after every operation effect has been
+rolled back. Without that proof, post-invocation failures remain
+`OperationOutcomeUnknown`. Mutable operations must still make validator
+comparison and backend commit atomic and return a validator describing the state
+that becomes committed.
 
 ## Validation