[zxch3n]

Related issue

Problem / pressure

Encrypted Meta/history dispatch and realtime offers need one durable execution decision per user turn. Admission must also verify the original signing device, current ledger authority and ownership of the target machine, including after snapshot recovery or a confirmed credential revocation.

Summary

• Route actual start/continue execution through the existing SQLite journal using agent-start:<userTurnId>. Preserve original receipts, clock floors, explicit reset, and completed/uncertain evidence across restart. Uncertain execution is never automatically resubmitted.
• Retain original encrypted update frames and operation ranges in workspace-local SQLite. Reverify the signature, reconstruct the exact original turn and bind its prompt/configuration, session and original expiry before authorization. UI account IDs remain display-only.
• Default production construction to host.authorizeExecution(workspaceId, requesterDevice). The verified signing device must be active, have a current non-Guest member role, and belong to the same ledger membership as the target machine device. Another device of that member can execute; cross-member execution fails with e2ee_machine_not_owned and “加密工作区暂不支持使用其他成员的机器”. Ordinary workspace visibility/project-sharing checks remain unchanged.
• Recover snapshot-only pending turns by fetching and verifying original signed updates from Streams. Missing originals and ordinary network failures remain retryable within the original execution window; the snapshot author never substitutes for the original signer.
• Confirmed member removal or machine-device revocation synchronously closes workspace execution admission and clears native authorization grants before the existing owner drain. Late refresh/authorization results and late originals cannot create a journal start. Only identity-verified member removal erases member data; device revocation retains local originals. These failures stay scoped to their workspace.

Execution boundary

verified original update -> exact turn + signing device + original expiry
                                           |
Meta/history or offer -> SessionExecutionService
                         current device/role + same-member machine policy
                         SQLite claim(userTurnId)
                         agent create/restore/prompt -> settlement

The optional LodyOptions.authorizeEncryptedExecution override keeps the native host signature:

type AuthorizeEncryptedExecution = (
  workspaceId: string,
  requesterDevice: string // verified signing public key, lowercase hex
) => Effect.Effect<ExecutionAuthorization, unknown>;

ExecutionAuthorization is Authorized or Denied with reason invalid-request, not-authorized, e2ee_machine_not_owned, unavailable or closed. The durable signed turn's original 15-minute execution window is independent of the host's ledger-read cache. Future encrypted realtime ingress must provide equally verified origin evidence through this boundary; this PR does not implement that transport.

Validation

• Deterministic RED → GREEN reproductions cover cross-member prompt submission, cached authorization surviving a confirmed backfill revocation, and late authorization creating a SQLite start after workspace closure.
• Real production Lody.create regressions use native custody, signed ledger/content and SQLite, with synthetic cloud I/O and an ACP harness; no authorization callback/mock host is injected. They cover same-member devices, other Members, Guest/revoked/removed signers, real UI account IDs, snapshot backfill, missing originals, confirmed member/device revocation and ordinary network recovery.
• Journal tests cover overlapping durable/realtime claims, duplicate delivery, restart, uncertain settlement, original evidence preservation and workspace isolation. Watcher tests retain ordinary not_visible and project_not_shared denials.
• 9 affected CLI suites / 612 tests passed, no expected failures. CLI typecheck, affected type-aware Oxlint (0 errors), Effect lint, changed-file Oxfmt, docs check and public/platform/process/presence boundary guards passed.
• Only affected local checks ran. No hosted-CI wait, deployment, encrypted-network acceptance or latency-threshold claim.