Module execution_scope 

Ambient EXECUTION SCOPE — an immutable owner token minted once per Harn program run and readable, like crate::observability::request_id, from hostlib builtins on the synchronous dispatch stack.

Unlike request_id (which a host pushes only at served ingress and which is None for standalone harn run/harn test), the execution scope is established by the VM itself at the top-level program boundary (Vm::execute_scoped), so it is ALWAYS present during real execution and is never a shared sentinel. That is exactly what lets the verdict issuance authority bind a proof-of-execution receipt to the specific run that PRODUCED the evidence: run_test captures the active scope when it records a real execution, and harness.verdict.issue mints a positive verdict only when the current active scope EQUALS that captured owner — so an old green handle cannot bless a later, different run (the cross-run replay class).

The scope is a stack so nested program executions restore the outer owner on return; the innermost entry wins for current_execution_scope. When no scope is active (there is no owning execution), issuance FAILS CLOSED — it never falls back to a default owner.

Structs

ExecutionScopeGuard

RAII guard returned by enter_execution_scope. Popping the stack on drop keeps the ambient balanced even when the enclosed program run panics or returns an error.

Functions

current_execution_scope

Currently-active execution scope, or None when no owning program run is active on this task. Verdict issuance treats None as fail-closed.

enter_execution_scope

Push scope onto the ambient stack for the lifetime of the returned guard. The innermost entry wins for current_execution_scope.

mint_execution_scope

Mint a fresh, process-unique, immutable execution-scope id. The pid prefix keeps ids from colliding across processes that share the (in-process) result store’s namespace; the monotonic counter keeps them distinct within one process. Callers push the returned id via enter_execution_scope.