Publish typed workload reports through software-first durable mailboxes

[!WARNING] Security boundary under review: the requester chose a self-contained software default with payload encryption between authorized guest/user endpoints; ordinary host mailbox services and stores must not intentionally hold payload-opening keys or plaintext. This default does not protect active guest memory from a compromised hypervisor. Stronger protection from an active malicious host is opt-in, hardware-qualified, and must refuse when unavailable. The older trusted-host host-sealing/default language below is a prior proposal, not current implementation authority. Current host-held payload keys and helper plaintext violate the intended software default. Do not enable B/operator plaintext, claim GO, or check boxes until ADR-001/057 and the restart/key-custody contract are reviewed and witnessed. All acceptance boxes remain open.

Architecture reconciliation: the requester chose the existing admitted per-VM helper plus retained per-mailbox journal/key custody, not one shared all-keys daemon. See #5260 (comment). The post-teardown reader and cold-boot evidence remain open.

Outcome

On ordinary supported hosts, every admitted production workload has a scoped, durable logical report mailbox in standalone MVM, without special confidential-computing hardware, a guest NIC or MVMD; the admitted per-VM helper must still meet the measured cold-boot gate. A workload explicitly emits a typed result or error; MVM records a separately attributed terminal observation for exit, timeout or crash. An authorized user/host endpoint can read and ACK after source teardown and local process restart; MVMD may discover and route opaque canonical envelopes and signed, non-sensitive status but cannot decrypt them. This is the software-first vertical slice of #4622; #5255 retains the lower-priority A → B guest-consumer acceptance, and #5259 tracks optional host-blind hardware qualification. No new mailbox queue or wire protocol.

Security/assurance boundary

Software-only default means the host administrator/hypervisor is inside the execution trust boundary. Signed plan and mailbox capabilities bind tenant, domain, mailbox, recipient, sender/boot/epoch, operation, kind, content type, payload bounds, policy and expiry; address, vsock reachability, CLI login or fleet route alone is not authority. Use canonical mvm-contract::protocol::mailbox envelope and MVM crypto/receipt verification; ciphertext store and MVMD hold no payload plaintext or recipient keys. The approved host or authorized endpoint may see plaintext; do not claim confidentiality from a malicious host that can read ordinary guest memory. A stronger attested host-blind profile may be added using the same envelope and a versioned, authenticated assurance policy, with protected guest-held keys, independently verified key release and protected I/O; if requested on an unqualified backend it fails closed and is never silently downgraded. #5259 owns its qualification.

Architecture for review

Keep one canonical MVM mailbox path without a shared process holding every mailbox opening key. Admission binds a logical report-mailbox identity and narrow Send grant into the signed execution plan by default. The existing admitted per-VM helper handles live guest traffic; per-mailbox encrypted journal and versioned key custody survive outside the source VM state. Do not create a second queue, accept a host dial as authority, or move all opening keys into one global daemon. Measure the helper’s full admitted boot cost against the cold-launch gate; if it fails, review a warm keyless front door rather than silently widening custody. Fail admission if the required mailbox path cannot be served on the selected backend.
A workload reports via an explicit bounded, versioned application value (result/error, content type, stable run/plan and message identity) independently of stdout/stderr. The guest initiates the message while running or at completion, including after 30 seconds. MVM records its own signed terminal outcome even if a guest crashes before submitting anything, but does not impersonate a guest-authored application result. Preserve existing CLI streams as diagnostics; no automatic raw-log-as-result. If diagnostic mirroring is chosen, grant it separately, cap bytes/rate/retention and expose truncation or refusal.
The canonical destination admission path commits encrypted envelope plus dedup identity in the MVM-owned journal outside the source VM state directory before returning a destination-signed V2 accepted_local_durable receipt for trusted-host crash durability. This is not independent whole-host rollback protection. Exit status and publication verdict are independent. A lost receipt is unknown until stable-ID reconciliation, never presumed rejected or accepted. The successor reader needs its own Receive capability and ACKs only after application acceptance; a lost ACK can redeliver, never claim exactly-once external effects. Full/expired/stale/wrong-tenant/revoked/oversized and disk/key failure are typed and bounded; retention and retry policy are reviewed in Persist encrypted mailbox journals, snapshots, and effect receipts #4630.
MVMD integration in tinylabscom/mvmd#254 consumes the canonical contract with separate fleet placement wrappers and never becomes a required mailbox data plane or plaintext reader. A user/host reader obtains data only as an authorized MVM endpoint. Optional host-blind endpoints use different attestation/key-custody witnesses but no competing mailbox format.

Dependency order and evidence gates

Implement canonical signed and encrypted mailbox envelopes #4628's canonical envelope/receipt codec roundtrip has been reconciled and tested; its MVMD migration box remains open and belongs with tinylabscom/mvmd#254.
Coordinate Add dedicated bounded mailbox vsock service and call/cast API #4629's live service owner/pin through Coordinate SpiralCore mailbox and FlowMux upstream integration #5057, then implement default narrow plan grant, bounded post-start guest Cast, independent mailbox budget and authorized local read/ACK. Do not create a second service in this slice.
Persist encrypted mailbox journals, snapshots, and effect receipts #4630 supplies encrypted destination journal, quotas, expiry, stable-ID dedup, durable acceptance, crash recovery and ACK state; no in-memory or VM-lifetime queue can satisfy this issue.
Only then wire typed report/error and separately reported publication into CLI/SDK/docs and MVMD's opaque consumption. Publish explicit workload results to durable local mailboxes for microVM chaining #5255's VM-to-VM workflow and Qualify SEV-SNP host-blind mailbox custody and boot latency #5259's SNP are follow-ons, not prerequisites.

Acceptance criteria

Review/amend ADR-057 for default software-only reporting, narrow grants, trusted-host-versus-host-blind claims, content/version and acceptance states; explicitly preserve the host-blind fail-closed upgrade boundary.
Every supported production workload launch gets its own plan-bound logical mailbox and a working post-start send path without MVMD, with measured per-VM helper startup inside the cold-boot gate; unsupported/unavailable paths refuse before dispatch. Cold-boot p50/p95/p99 versus a pinned baseline and first durable-publication latency are reported separately, not inferred from a VMM-only boot metric.
Guest-authored typed result/error and host-authored terminal observation are distinguishable; stdout/stderr CLI behavior is retained, never silently reinterpreted as result. Nonzero exit, no result, timeout/crash, multiple submissions, oversized/full and failed/unknown publication are explicit.
Destination-signed V2 accepted_local_durable only follows persistent encrypted local admission and stable dedup identity; authorized read/ACK, retry/lost ACK, source teardown and host restart preserve accepted data while local storage/keys remain available. Bounded expiry, quotas, attempts, dead letter and disk/key-loss behavior are tested.
Wrong tenant/domain/recipient/sender/grant/operation/boot/epoch/policy, replay, tamper, version, expiry, capacity and overlong input fail closed without plaintext leakage or starving other services; every exposed reader has independent Receive authority.
MVMD consumes canonical opaque envelopes or signed safe metadata via tinylabscom/mvmd#254, with no alternate mvmd.mailbox.v1 authority or recipient decryption keys; standalone MVM works with MVMD absent.
Unit, mock-I/O, CLI, BDD and supported builder-VM live validation, workspace tests, gated checks, clippy, docs and CLI reference evidence are attached before any implementation checkbox is checked. No production/security claim or closure while unchecked items remain.

No implementation or production witness is asserted by creating this issue. No authorization to use a billable host or merge to a shared branch is implied.

Product wording confirmed for the software-first profile

The requester accepted the explicit trusted-host limit for now. The software-only mailbox profile may make a production claim about signed scope, tenant/recipient separation, encrypted durable storage, MVMD/relay blindness, and refusal/recovery only after their implementation and witnesses pass. It must not claim confidentiality of a running ordinary guest from the host administrator/hypervisor. Hardware confidential execution is an optional, separately qualified stronger profile (#5259); a request for that profile refuses if the platform cannot provide it, without silent downgrade. Preserve one canonical envelope and service path across profiles.

This confirms product wording, not #5260 or ADR-057 implementation or a security test. The current active dependency order remains #4629 local service (coordinate patch ownership in #5057) → #4630 encrypted durable destination journal → this typed reporting slice → optional MVMD opaque integration in tinylabscom/mvmd#254. #5255 retains deferred A → B guest reading. All #5260 boxes remain unchecked.

Dependency-safe implementation started: typed content contract, not mailbox delivery

On an isolated MVM feature branch feat/mailbox-workload-report based on origin/main@97e775f3753b299e90e8ca455ad615a948f3737a, I added a local, unmerged mvm-contract::protocol::workload_report payload DTO and export (crates/mvm-contract/src/protocol/workload_report.rs, protocol/mod.rs) plus tests/workload_report.rs. It is versioned application content intended inside canonical MailboxMessageKind::Cast, not another envelope or queue. ReportIdentity names signed plan ID/nonce and stable MessageId; ReportKind distinguishes explicit result from error with a bounded code; WorkloadReport::new/encode/decode bound the encoded body to the canonical plaintext ceiling, refuse unsupported versions/malformed/base64/unknown fields, expose a redacted Debug, and provide verify_identity(expected) for an admission-derived identity comparison. This does not authorize itself: the future #4629/#4630 path must verify the enclosing signed envelope, capability, recipient/tenant/epoch, exact outer report content type, and expected identity from the admitted plan/header, then apply the smaller signed-capability/frame/store limits before publication. Host-observed terminal status and publication verdict remain separate future work.

I coordinated ownership with the parallel #4629/#4630 implementation thread: it owns service/storage/transport contract; my diff touches only the new content module, its export, and tests. No guest listener, host service, durable journal, CLI behavior, MVMD path, or production readiness changed. No #5260 checkbox is complete from this DTO alone.

Validation actually run on macOS: cargo test -p mvm-contract --test workload_report (3 passed); TMPDIR=/tmp cargo test -p mvm-contract (all crate suites and doc-tests passed); cargo clippy -p mvm-contract --all-targets -- -D warnings (passed); cargo check -p mvm-contract --no-default-features --features protocol (passed); cargo fmt --all -- --check and git diff --check (passed). Initial full-crate background run passed test binaries but its doctest failed because the terminal's transient TMPDIR was removed; rerunning with /tmp corrected the environment and passed. cargo doc -p mvm-contract --no-deps completed with 37 pre-existing rustdoc warnings outside this module, none in the new file. Not run: cargo test --workspace, workspace clippy/check, gated Linux/builder-VM or live VM. No push, PR, shared-branch landing or billable test host.

Follow-on integration proof in the unmerged content branch

After the typed result/error DTO slice, I added one focused cross-crate regression in crates/mvm-core/tests/mailbox_crypto.rs on feat/mailbox-workload-report (base 97e775f3753b299e90e8ca455ad615a948f3737a). It builds a typed report with plan ID/nonce and stable message ID, seals it as a canonical mailbox Cast with the report MIME/version, verifies the signed capability grants that content type, opens the ciphertext, decodes the unchanged report and compares its untrusted identity with expected admitted identity. Negative assertions reject a missing content-type grant, a wrong run nonce, and a signed capability with an encoded-payload cap below the report length. The outer encoded envelope does not contain application payload text. This is a cryptographic interop witness, not a guest submission, durable acceptance, read/ACK, or production runtime path.

Validation actually run: TMPDIR=/tmp cargo test -p mvm-core --test mailbox_crypto 19 passed; cargo clippy -p mvm-core --test mailbox_crypto -- -D warnings passed; cargo fmt --all -- --check and git diff --check passed. Previous TMPDIR=/tmp cargo test -p mvm-contract passed all 1,300 crate tests. No workspace-wide suite, live builder-VM, cold-boot benchmark, CLI or MVMD test was run. I confirmed with the parallel #4629/#4630 owner that this test path does not overlap their service/store edits. All #5260 implementation checkboxes remain unchecked pending those paths and the final end-to-end evidence.

Studio consumer handoff (not an implementation claim): please keep a typed mvm-client library read/ACK surface in the #4629/#4630 → #5260 integration path. Studio's accepted ADR 0005 requires in-process library calls, not mvmctl shell-outs. Its current output drawer already consumes mvm_client::stream::open_vm_output with source/origin, gaps and truncation; keep that diagnostic stream distinct from guest-authored WorkloadReport, host-authored terminal observation, and the destination's publication/ACK verdict. A missing report, refused/unknown publication, and verified durable acceptance need distinguishable states, tied to the admitted run/plan, so Studio can render them without inventing a result from stdout/stderr.

The existing mvm_client::mailbox::recv(name) from PR #5253 is not this consumer contract: it pops a VM-lifetime in-memory queue and can lose a popped message if the later audit write fails. Please do not have Studio poll it as a production report inbox or treat a returned message as accepted_durable. A library-level authorized non-destructive/lease-and-ACK reader with explicit source/run/provenance and refusal semantics should be validated with the journal/recovery work; avoid a second mailbox or Studio-side transport. Separately, #5265 owns supervisor-protected entrypoint stdout/stderr recording. Neither mailbox reporting nor a fixture should be called a fix for its HVF capture.recorded = false smoke.

This note adds a consumer requirement only. No checkbox, approved ADR, live-HVF, or Studio compatibility claim follows from it.

Receive/ACK contract handoff for the parallel local mailbox implementation (proposal before wire changes)

The user asked us to address the missing independent reader and acknowledgement seam. Ownership split with the #4629/#4630 implementation thread: it retains MVM core journal/crypto/transport, hostd service/process/launch and guest outbox; this branch owns only canonical mvm-contract::protocol::mailbox delivery/lease/ACK DTOs and tests. Reuse existing signed MailboxGrant { mailbox, authority_key, epoch } in the admitted execution plan and an independently verified SignedMailboxCapability with Receive operation; do not mint ambient ACK authority from knowing an address, connecting to vsock, or carrying a host-dial token. No signed plan field/schema change is proposed.

Proposed V1 lease binds exact tenant/domain/mailbox/recipient, sender boot/message ID, unique delivery ID, destination execution epoch and policy epoch, consumer principal and fresh consumer session, Receive capability ID, ciphertext commitment, issuance/expiry, and fresh lease nonce. Destination authority signs the lease under a distinct domain. ACK signs the whole signed lease, a fresh ACK nonce and acknowledgement time under the authorized consumer identity; runtime must verify both signatures, current signed plan/capability, current policy/epoch/session, exact lease ownership and dedup identity before appending/fsyncing ACK. A replay of the same ACK is an idempotent already-acknowledged result (not a second effect), while a conflicting/wrong-consumer/stale/expired ACK refuses. The DTO crate enforces data bounds and structural binding only; signature verification, lease allocation, replay state, ciphertext storage and fsync remain in MVM core/runtime (#4629/#4630). A lost ACK means bounded redelivery, never exactly-once application effects. This does not make the currently unmerged journal API production-ready until a delivery token/consumer binding and negative tests exist.

This proposal is for review alongside ADR-057 and #4629/#4630. It changes no existing signed-plan behavior, does not mark any box complete, and does not authorize enabling a guest reader before the core/runtime gate proves the semantics.

Reader/ACK security review conditions before runtime exposure

The parallel #4629/#4630 owner reviewed the proposed lease/ACK DTO boundary and identified three conditions that prevent declaring a guest reader ready merely because a journal can append ACK: (1) SignedMailboxDeliveryAck must be signed by the independently authorized consumer endpoint key whose identity is bound to the Receive capability subject, not a FlowMux egress-client key, transport peer, source sender, or destination authority. In the trusted-host software tier an explicitly granted local host reader may hold a scoped host key; a user reader holds its own key. A guest reader requires a guest-held per-boot mailbox key enrolled against an authenticated current boot and signed plan; until then no guest ACK exposure/VM-to-VM claim. (2) MVM derives/mints ConsumerSessionId from a verified current reader session, compares it on receive/ACK, fences old sessions on replacement, and never trusts a caller-supplied session token solely because a socket connects. (3) Enforce a bounded control-frame codec before parsing for the signed lease and ACK, and persist ACK replay/dedup identity (mailbox, message/delivery ID, session, lease+ACK nonce and exact commitment) through restart. Exact duplicate ACK is idempotent; conflicting reuse or stale epoch/session/expired lease refuses. DTO scope checks are data consistency only; MVM core/hostd must verify both signatures, capability revocation/policy and current plan/boot, and journal/fsync ACK before returning success.

I am updating the unmerged mvm-contract DTO/tests for bounded control bytes and replay identity; no service/store path or signed plan schema is being changed here. These are implementation gates for #4629/#4630 and #5260, not evidence that guest Receive/ACK is implemented or accepted.

Dependency-safe reader/ACK contract implementation (unmerged)

On feat/mailbox-workload-report (base MVM 97e775f3753b299e90e8ca455ad615a948f3737a), I added canonical version-one MailboxDeliveryLease, SignedMailboxDeliveryLease, MailboxDeliveryAck, SignedMailboxDeliveryAck, bounded 16-KiB pre-parse lease/ACK codecs and distinct signature domains to mvm-contract::protocol::mailbox. The signed lease binds tenant/domain/mailbox/recipient, sender boot/message and delivery IDs, destination epoch and policy, exact consumer principal + MVM-authenticated session, Receive capability ID, ciphertext commitment, time window and lease nonce. The ACK signs the entire signed lease plus an ACK nonce/time, and the canonical MailboxAckReplayIdentity keys one ACK per lease, intentionally excluding the ACK nonce: changed ACK bytes or nonce for the same lease must conflict, not create a second effect. No MailboxGrant or ExecutionPlan field was changed.

check_scope is explicitly structural only: it checks signed-plan mailbox/epoch, signed Receive capability's address/subject/operation/ID/policy/epoch/time and the caller-provided verified current consumer session. The codec bounds an untrusted lease/ACK before JSON allocation. It does not verify signatures, create or authenticate a reader session, check revocation, compare stored message commitment, or persist replay state. Before guest/user ACK can be exposed, MVM core/runtime must verify destination-authority lease signature and consumer-signed ACK under the separated domains, bind the consumer key to capability.subject and the authenticated current reader session, and journal/fsync both the ACK identity and exact signed-ACK commitment. The FlowMux egress key is not mailbox authority. A trusted-host local reader may have its own scoped key; guest-held key enrollment for a replacement remains a separate reviewed gate, not silently implied by the DTO.

Focused cargo test -p mvm-contract --test mailbox_delivery: 4 passed, covering exact reader scope, wrong tenant/recipient/consumer/grant, Send-only refusal, stale epoch/session/policy, expiry/ACK timing, unknown fields, oversized control input, and retry identity conflict properties. TMPDIR=/tmp cargo test -p mvm-contract passed all crate tests/doc-tests; cargo clippy -p mvm-contract --all-targets -- -D warnings, no-default-features protocol check, cargo fmt --all -- --check, and git diff --check passed. Earlier full workspace tests/check/clippy passed before these new contract types; they have not been rerun against this final diff, nor have live builder-VM, receipt-signature, journal/replay or guest-reader tests. The #4629/#4630 owner is reviewing the shape and retains core/hostd/guest runtime implementation. No #5260 or #4629/#4630 checkbox is complete from this DTO alone; no commit, push, PR or merge.

Canonical reader/ACK contract slice implemented locally; runtime gate still open

The user authorized addressing the missing Receive/ACK seam. In the unmerged MVM branch feat/mailbox-workload-report (base 97e775f3753b299e90e8ca455ad615a948f3737a) I extended only mvm-contract::protocol::mailbox and focused contract tests, coordinating a disjoint ownership boundary with the #4629/#4630 runtime owner. No existing signed-plan field or authority type was changed: MailboxGrant still pins mailbox/authority key/epoch, and the independently signed MailboxCapabilityGrant must explicitly carry Receive for the exact address, consumer, epoch, policy and time.

New versioned DTOs: a destination-signed delivery lease binds exact address, sender boot/message+delivery ID, recipient epoch/policy, consumer principal/session, Receive capability ID, ciphertext commitment, expiry and lease nonce; a consumer-signed ACK embeds the whole signed lease and its own nonce/time under a distinct signature domain. Both lease and ACK use a 16-KiB encoded-control cap checked before JSON parsing. The canonical ACK replay key identifies one ACK per lease, deliberately excluding the ACK nonce; durable runtime state must pair that key with the exact signed ACK commitment so changed bytes or nonce conflict rather than create a second ACK. A guest-only signed reader enrollment additionally binds plan ID/nonce, mailbox/recipient, Receive cap/consumer, fresh guest boot/session, execution/policy epoch, per-boot mailbox ACK public key and validity window; its codec has the same bound. This is not a second mailbox envelope or queue.

Authority caveat: DTO check_scope tests data consistency only. It does not verify any signature, authenticate the current guest boot/session, prove possession of the mailbox ACK key, check revocation or append/fsync ACK. The runtime owner is implementing a distinct per-boot mailbox key in the guest identity drive (not FlowMux/host sealing), host-signed enrollment, and core/hostd verification; a warm child with the inherited parent key must refuse Receive/ACK until fresh rekey/enrollment. Trusted-host key provisioning is the software tier and does not assert host-blindness. Guest-facing ACK remains disabled until those runtime/crash/replay witnesses pass.

Validation on this contract diff: cargo test -p mvm-contract --test mailbox_delivery 6 passed, including wrong tenant/recipient/consumer/grant, Send-only refusal, stale plan nonce/parent boot/session/epoch/policy, expired lease/ACK, malformed/oversized control, unsupported version, invalid key/signature shape and roundtrips. TMPDIR=/tmp cargo test -p mvm-contract passed all crate suites/doc-tests; scoped cargo clippy -p mvm-contract --all-targets -- -D warnings, no-default-features protocol check, and cargo fmt --all -- --check passed. Workspace check/clippy are running on the latest diff; prior workspace tests passed before these new DTOs and must be rerun if this branch is considered ready. No runtime implementation/guest e2e/boot measurement or #5260 checkbox is claimed complete, and nothing was merged or pushed.

Per-boot guest reader enrollment contract added on the unmerged DTO branch

The user explicitly approved a distinct per-boot guest-held mailbox ACK signing key, independent of FlowMux and the host's mailbox-sealing key. I extended the canonical V1 contract on feat/mailbox-workload-report with MailboxGuestReaderEnrollment and SignedMailboxGuestReaderEnrollment: the host-authority-signed binding names exact signed plan ID/nonce, tenant/domain/mailbox/recipient, Receive capability ID and consumer principal, fresh guest BootId and MVM-authenticated ConsumerSessionId, execution/policy epoch, independent ACK public key and bounded validity. Its signature domain is distinct from the lease and ACK domains. The 16-KiB codec bounds untrusted input before JSON parsing. MailboxGuestReaderScope checks structural consistency with verified plan/grant, Receive cap and current boot/session; it refuses stale warm-parent boot, wrong plan nonce/recipient, stale session/epoch/policy, Send-only grant, expired window, zero public key and malformed signature shape.

This DTO is not an enrollment service or cryptographic verifier: MVM runtime must sign under the authority key pinned in the admitted plan, validate the Ed25519 public key, prove possession of the guest-held key, authenticate the current boot/session, fence a restored child's inherited parent key until rekey, and persist/recover the binding or require re-enrollment after helper restart. The parallel #4629/#4630 owner is implementing identity-drive provisioning and core/hostd checks without editing these contract paths. Guest Receive/ACK remains disabled until that work has positive, negative, crash and replay witnesses; no host-blind claim follows from a host-prepared software-tier seed.

Validation of the current contract slice: six cargo test -p mvm-contract --test mailbox_delivery tests pass; all mvm-contract test suites/doc-tests, scoped clippy -D warnings, no-default-features protocol check, and cargo fmt --all -- --check passed. Workspace check/clippy and workspace tests are running on this diff. The branch is not committed, pushed or merged, and no #5260/#4629/#4630 acceptance box is being marked complete.

Pinned contract handoff for the parallel runtime implementation

MVM feat/mailbox-workload-report@fd8b9d9dc91f8fc5b8885c1784eeb0ce948717bc is the local, unpushed, unmerged review pin for the typed result/error content, bounded canonical reader-enrollment/lease/ACK contracts and tests. Parent is 97e775f3753b299e90e8ca455ad615a948f3737a. I sent this exact pin and interface notes to the #4629/#4630 implementation session, which retains guest key provisioning, live send, journal, destination receipt and cryptographic/session verification; no overlapping runtime path was edited here. This is a contract pin, not a production or end-to-end delivery pin. The two branches must only be integrated with explicit authorization and against the current source, never by assuming either other's uncommitted files are present.

Validation on this pin: cargo test -p mvm-contract and focused cargo test -p mvm-core --test mailbox_crypto passed, cargo check --workspace, cargo clippy --workspace -- -D warnings, no-default-features protocol check and formatting passed. The final cargo test --workspace is still compiling under concurrent host load; its result remains unknown and no full-green claim is made. No guest Receive/ACK, builder-VM live flow, MVMD path or boot-performance witness is implied, and all implementation acceptance boxes remain unchecked.

Integration gate against committed local-durable foundation (read-only review)

I rebased the unmerged typed-report/reader-contract branch to current origin/main@1a0117fa969b18b062d65d31258a9d2326e4a148 as feat/mailbox-workload-report@b7db12ef6e0cfdac0b868165357a4e9f4b692d76 (not pushed). Focused tests on the rebased source passed: mailbox_delivery 6/6, workload_report 3/3, mvm-core --test mailbox_crypto 19/19. I reviewed the other session's committed foundation feat/mvm-mailbox-local-seam@9ca5bf628d5c3bf6b93e136d200bb7934b8dd94f by exact Git object, without merging it; that owner reports compile/fmt passing but execution tests/clippy still unproven on the integrated source.

The committed foundation contains MVM encrypted durable journal/anchor and a host-local signed receipt path. It does not yet implement #5260: crates/mvm-hostd/src/mailbox_launch.rs still creates a Send-only Call grant for application/vnd.mvm.guest-message v1, max 16KiB and a reply route. A typed result/error requires a signed-plan-derived Cast grant with application/vnd.mvm.workload-report v1 and no reply route. Capability verification must refuse the new content until that authority is granted deliberately, not inferred from the outbox file or host dial. DurableMailboxService::serve_guest currently returns a guest Result<(),Refusal> after journal commit; the signed receipt returned by the host-facing durable::send is a separate API. Guest local outbox staging and guest Ok must not be reported as a verified signed destination receipt. The foundation's receive_next/acknowledge are host-local primitives without per-boot enrolled guest signing key, signed lease/ACK, authenticated current session or guest reader path. The existing mvm-client::mailbox::recv and CLI machine mailbox recv destructively consume VM-lifetime plaintext without authorized lease/ACK and cannot safely serve typed reports.

I sent these exact compatibility findings to the parallel owner. Next shared gate: test and pin a report-specific signed Cast template/guest receipt path and independent enrolled Receive/ACK runtime API; then authorize integration of the two feature branches, re-run workspace/gated/Linux/live checks and update docs/CLI/SDK semantics. No issue checkbox, shared-branch landing, or production claim follows from this source review.

Signed-plan report policy contract pin (private feature branch, not activation)

The #4629/#4630 runtime owner identified a security mismatch: the currently admitted MailboxGrant carries only mailbox, authority key and epoch, while the host's separate template still grants Call/guest-message/16KiB; changing that template to Cast/report MIME alone would mint report send authority without any signed-plan ceiling. I implemented a versioned optional signed-plan report policy in local unpushed/unmerged feat/mailbox-workload-report@5f343a06f686dfd76dff80bcad24890a1448e964 (parent b7db12e). MailboxGrant.report: Option<MailboxReportSendPolicy> is omitted when absent, preserving legacy signed-plan bytes; absence refuses typed report emission, not silently upgrading old plans. Its V1 wire policy has a validated nonzero payload ceiling ≤ canonical 1MiB schema maximum. MailboxGrant::check_report_send requires exactly canonical Cast, application/vnd.mvm.workload-report v1, no reply route, and an encoded report body within the plan ceiling. Runtime must intersect this signed-plan ceiling with a separately verified Send capability, effective 64KiB frame overhead, destination journal quota, current identity/epoch/recipient/policy and revocation; a transport connection or host template is never authority. A new default-on production grant must be minted into the plan and verified before hostd derives this capability; no present launch is thereby enabled.

Tests: contract mailbox_delivery 8/8 and workload_report 3/3 passed; focused mvm-core signing test verified adding/widening the policy after signing invalidates the signature; scoped mvm-contract clippy -D warnings, protocol-only no_std check, fmt and diff-check passed. A synthesis content-address test was added after the first core compile began and is rerunning; full workspace --tests cannot pass this contract-only commit by itself because three hostd test fixture literals need the new report: None field. The runtime owner explicitly agreed to update those hostd fixture literals after cherry-picking the pin and will adapt hostd template/service to derive Cast/report authority from the verified plan, not template-only. No hostd/agentd runtime files were modified in this contract branch. No completion checkbox, production claim, public push, or shared-branch landing follows from this policy pin.

Runtime owner handoff and remaining UX gate

The former #4629/#4630 runtime owner committed the private WIP source handoff feat/mvm-mailbox-local-seam@4bc9e6ee946d9e3656784da7fb98575ead3cbb3a (parent d7848da), clean worktree, and retired from that implementation. A new guest Receive/ACK implementation session is verifying the attached matching source before editing; I sent the exact canonical DTO/enrollment/ACK API and constraints. My separate unpushed report-contract feature branch is feat/mailbox-workload-report@5f343a06f686dfd76dff80bcad24890a1448e964: the initial DTO commit was already cherry-picked into runtime earlier, but the signed-plan report policy commit remains unpicked. I assigned the new runtime integrator the private cherry-pick, three hostd test fixture literals, plan-derived Cast/report MIME/no reply-route capability, and guest signed durable verdict while keeping my scope on typed report/CLI/SDK UX after a tested reader API pin. No shared branch has been merged or pushed.

Key acceptance gap remains: the committed WIP service's host-local Receive/ACK primitive is not a guest verified lease/ACK endpoint, and the current SDKs still derive legacy results from stdout. Do not present write_outbox success, a host dial or an HVF capture receipt as accepted_durable or as typed application output. The new runtime integrator must demonstrate authenticated current boot/session possession, per-boot reader key, signed Receive capability/enrollment, lease/ciphertext verification, durable ACK/replay, and source teardown/host restart before UX wiring. My final default-profile synthesis test encountered a macOS linker failure with unrelated undefined symbols after compilation; a nonincremental retry is running, so that particular witness remains unverified. Contract 8/8, focused signed-plan tamper, scoped clippy and protocol-only check passed. All #5260 boxes remain unchecked.

ACK UX boundary for the software-first trusted-local slice

The guest Receive/ACK implementer asked whether the CLI/SDK must receive a second destination-signed ACK-commit receipt. Recommendation for trusted-local V1: no new signature format is required solely for local UX if MVM verifies the signed Receive cap/enrollment/current session and exact guest-signed ACK lease, persists the ACK and replay disposition in its journal, advances the anchor, then returns an operation-correlated Acknowledged response. The CLI/SDK may describe this as locally acknowledged by MVM; it must not present the response as an exportable signed destination receipt, durable acceptance of a send, or exactly-once application effect. A lost ACK reply is unknown until the exact ACK identity is retried/queried; a conflicting ACK for the same lease refuses. A bare unauthenticated or uncorrelated success response is insufficient even for this trusted-host UX; protect against stale/replayed replies and wrong lease/session. The signed accepted_durable receipt for publication remains distinct and required before reporting a published result.

Signed ACK-commit evidence for remote/fleet or a stronger malicious-host profile is a separate reviewed extension if such a product claim is needed later. This recommendation does not check off #4629/#4630/#5260: the reader implementation remains provisional/uncommitted until its host, Linux guest and live boot tests run. No new signature/queue is added by this note.

Validation correction for local signed-plan report policy commit 5f343a06f686dfd76dff80bcad24890a1448e964: the default-profile mvm-core synthesis test previously failed at the macOS linker with undefined symbols after compiling, not at an assertion. Retried the same cargo test -p mvm-core --lib plan::synthesis::tests::a_mailbox_grant_is_minted_into_the_signed_plan_and_absence_stays_none -- --exact with CARGO_INCREMENTAL=0 and TMPDIR=/tmp: 1 passed, 0 failed (14m38s build). This proves the signed report-policy addition moves the synthesized plan ID; it does not prove production hostd integration or a default-on mailbox launch. Contract mailbox_delivery 8/8, workload_report 3/3, signed-plan tamper test 1/1, scoped contract clippy/protocol-only check and formatting also passed. Full workspace --tests on this policy commit remains unrun because the separately owned hostd test fixtures still require report: None after private integration; no checkboxes or readiness claim changed.

Additional validation on separate private report-policy commit 5f343a06f686dfd76dff80bcad24890a1448e964: cargo check --workspace passed (9m40s) and cargo clippy --workspace -- -D warnings passed (12m07s) on the macOS host, with no compiler errors/warnings. This is ordinary workspace lib/bin validation, not --tests/gated Linux validation: the three hostd test fixture literals in the independent runtime branch still need report: None when the new field is cherry-picked. Focused report-policy contract (8/8), typed payload (3/3), signing tamper (1/1) and synthesis plan-ID test (1/1 with CARGO_INCREMENTAL=0) passed separately. The guest Receive/ACK implementation session reports focused reader/journal/guest/host tests and Linux guest check, but its live HVF exchange has not yet produced an immutable test pin. Do not infer combined integration or production readiness from these disjoint checks; all implementation acceptance boxes remain unchecked.

Implementation-scope reconciliation for typed reporting (no checkbox claim): #5255 now records the requester-delegated standalone MVM choice of a distinct, versioned trusted-host local-crash-durable receipt, not today's V1 accepted_durable with a same-host anchor: #5255 (comment). The current #5260 body/acceptance text still says accepted_durable; read that as a pending issue-description amendment, not permission to emit V1 strong acceptance from FileJournalAnchor. accepted_local_durable V2 is defined/tested in the private canonical contract at 79599dddffeca4f004d0b2c4f1d5f0e8f309c68f, and #4630 private composition at 434cca038bfc2325bf13b51e4080af9646dfc2b3 has a V2 signer and test-scoped journal path only. Default-build production still refuses mailbox launch; Dev Send is ephemeral with Reader unavailable. The next required runtime evidence is persistent versioned history+payload keys and authenticated restart scope, finite retention/expiry, the existing hostd bind_local adapter, then explicit guest result/error submission, authorized CLI/SDK read/ACK and publication verdict, and finally source teardown/process restart/refusal/boot-performance tests. Stdout/stderr remain diagnostics; VM-to-VM A→B stays deferred under #5255. No billable host, full workspace/gated/Linux/live test, push or merge is claimed by this note. Keep all implementation boxes unchecked until corresponding witnesses pass.

Latest-source reconciliation after #5377 landed: I fetched origin/main@2033b886926b86a2e2d6e7df8a504a00695a4cb1, synced a clean attached reporting worktree on new topic branch feat/mailbox-workload-report-current, and preserved its older private contract history separately. Merged #5377 (landed as 6850b989ea) already contains the canonical typed report DTO/signed-plan policy, V2 accepted_local_durable, MVM-owned encrypted journal, retained key custody, local guest outbox receipt validation and boot-bound reader/ACK. Do not reimplement that foundation or treat earlier private-branch pins as the current source.

#5377's exact-head workspace test/check/Clippy/gated checks and host-process mailbox BDD passed, and its selected GCP ci_live lane passed on a prior pinned head, but no booted guest was run for the local-durable mailbox receipt/ACK. This is not a #5260 completion witness: explicit workload result/error submission and outcome handling, authorized user/host mvm-client lease/read/ACK and CLI/SDK UX, source teardown and process-restart retrieval, workload exit vs publication verdict, and cold-boot/first-publication timing still require source-level review and tests. The issue body still says V1 accepted_durable in some places; the delegated software-first guarantee is distinct V2 local-crash-durable, not independent full-host rollback or host-blindness. #5255 keeps deferred guest-to-guest A→B work. Leave #5260 checkboxes unchecked until each corresponding outcome is executed and verified. No new push, PR, billable host or shared-main landing from this reporting session.

Current local, unpublished report-ingress work: feat/mailbox-workload-report-current@00936a6da96747c72e546cf93c7fa225758524b3 adds explicit extensions["mvm.mailbox"].report.max_payload_bytes authoring, binds the typed Cast/result/error body to the admitted signed plan and source MessageId, and stages an immutable guest report without calling staging a publication receipt. The host refuses non-report content, wrong plan/message identity, absent report grant and oversized submissions. The legacy ungranted Call path remains unchanged. Follow-up local commit 0c4fd6484b66ea68c7e33797ea4a4aea16f5262f persists a bounded, signed V2 destination receipt in the guest before removing the pending source intent, exposes a guest-local verifier with None = unknown, and amends ADR-057 to label the long-lived service as the unshipped #5260 target and to state that the trusted local service may temporarily open plaintext. Negative tests cover a linked evidence path, tampered receipt, wrong mailbox and lost/untypeable verdict. Checks at the latest local pin: TMPDIR=/tmp cargo test --workspace, cargo check --workspace, cargo clippy --workspace -- -D warnings, cargo fmt --all -- --check, git diff --check, and just lints::honesty all passed. just check::gated passed at its immediately preceding pin; it has not been rerun since the guest-only receipt/ADR follow-up. The initial full test invocation without TMPDIR=/tmp hit unrelated macOS SUN_LEN failures from Delta's long temp path; the short-path rerun passed.

This is an ingress and in-guest receipt slice, not #5260 completion. The current production helper remains per-VM, stops with its VM, and the public mvm-client::mailbox::recv is an old VM-lifetime destructive queue read, not an independently authorized local-durable report reader. The accepted issue target requires one warm MVM-owned service outside VM lifecycle, default narrow report grants without per-VM boot setup, an authorized read/ACK after source teardown and restart, distinct host terminal observation/publication status, and live cold/first-publication measurements. All remain unimplemented/unwitnessed. No acceptance checkbox is checked and no shared branch has been pushed or merged.

Topology reconciliation (no implementation/checkbox claim): #5260's Architecture for review proposes one warm MVM-owned service outside VM lifetime, but the separately commissioned guest Receive/ACK work explicitly used a per-VM helper with persisted enrollment across helper restart, which is what current source and merged #5377 implement. #4629 specifies one canonical dedicated typed mailbox service and independent resource budgets, not one process holding every tenant's opening keys. The #5126 standalone requirement rules out an externally required deployment; it does not decide local process cardinality. My earlier suggestion to replace the helper with one all-keys warm daemon conflated logical service ownership/readiness with key-custody topology and was premature. I have stopped that migration and removed the unreviewed topology assertion from the local ADR draft; the trusted-host plaintext-boundary clarification remains. We need a single reviewed choice for the #5260 performance/post-teardown target (per-VM helper, shared front door with independent per-mailbox custody, or single shared key-holding process), including how it meets boot latency and authorized read/ACK after teardown. No new service or merge is being started on the basis of the prior recommendation.

Architecture choice confirmed by requester after reconciling #4629/#4630 and the guest Receive/ACK implementation: do not replace the current per-VM helper with one process holding every mailbox's opening keys. Retain the one canonical MVM mailbox protocol/service path: the admitted, per-VM helper handles live guest traffic, while per-mailbox encrypted journal and versioned key custody persist outside VM state. The authorized host/user reader must re-open that same retained state after source teardown/restart using independent signed Receive authority, not legacy destructive mailbox recv or a second queue. Measure the helper's full admitted cold-boot cost against the <300 ms gate; if it fails, revisit a warm keyless front door rather than pooling all plaintext/key custody. This choice does not remove the default-report or post-teardown acceptance requirements and does not mark any checklist box complete. The issue body's earlier 'one warm service / no per-VM helper' design proposal is superseded by this decision and should not be treated as implementation authority. No code has been merged to shared main on its basis.

Local report-side handoff after the approved per-VM-helper architecture reconciliation: clean, unpublished feat/mailbox-workload-report-current@98b82c9337e31890f7764acf7fbd2fb2f73c74f6 (base 2033b886). Explicit signed-plan report policy, plan/nonce/MessageId-bound Cast, immutable guest staging, bounded signed V2 receipt archive, and in-guest mailbox_report_client status <message-id> now distinguish verified accepted_local_durable from unknown. The example is guest-local, not the independently authorized host/user read+ACK after teardown. ADR-057 now retains per-VM helper plus per-mailbox journal/key custody; no global all-keys daemon. Verified on this exact local pin: TMPDIR=/tmp cargo test --workspace, cargo check --workspace, cargo clippy --workspace -- -D warnings, just check::gated, just lints::honesty, fmt and diff check. Operator read/ACK remains separately owned and has no reviewed source pin; the mailbox demo session reported its synthetic-plan authority shortcut removed pending a real signed launch record. Cold-boot and live report/teardown/restart evidence have not been run. All #5260 boxes remain unchecked; no shared merge/push/PR or billable host.

Session archival handoff, not implementation approval: typed-report source is clean/unpublished local feat/mailbox-workload-report-current@98b82c9337e31890f7764acf7fbd2fb2f73c74f6 at /Users/auser/work/tinylabs/mvmco/mvm/.delta/worktrees/v3xnxzkfe42w/mvm, ahead 3/behind 4 vs origin/main. WorkloadReport and optional signed-plan policy already exist in main; this branch's additional host-side GuestSealer / payload-key sealing, immutable staging, guest-local V2 receipt archive and example status command were tested under the previous trusted-host profile. The host-side sealing/host-held payload-opening key is NOT suitable for the newly selected self-contained endpoint-E2E default; do not cherry-pick or merge it as a host-blind implementation. Use only as a reference for validation and adapt report emission after a reviewed guest/user key custody/release contract. The verified mailbox-demo integrator was sent the exact source path/pin and asked to own downstream report adaptation and mvm-client operator UX once its secure authority API is reviewed. #5260 remains security-held, all boxes unchecked; no current HVF E2E or stronger malicious-host claim follows from the old branch checks.

Navigation Menu

Repository navigation

Publish typed workload reports through software-first durable mailboxes #5260

Outcome

Security/assurance boundary

Architecture for review

Dependency order and evidence gates

Acceptance criteria

Product wording confirmed for the software-first profile

Dependency-safe implementation started: typed content contract, not mailbox delivery

Follow-on integration proof in the unmerged content branch

Receive/ACK contract handoff for the parallel local mailbox implementation (proposal before wire changes)

Reader/ACK security review conditions before runtime exposure

Dependency-safe reader/ACK contract implementation (unmerged)

Canonical reader/ACK contract slice implemented locally; runtime gate still open

Per-boot guest reader enrollment contract added on the unmerged DTO branch

Pinned contract handoff for the parallel runtime implementation

Integration gate against committed local-durable foundation (read-only review)

Signed-plan report policy contract pin (private feature branch, not activation)

Runtime owner handoff and remaining UX gate

ACK UX boundary for the software-first trusted-local slice

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Publish typed workload reports through software-first durable mailboxes #5260

Description

Outcome

Security/assurance boundary

Architecture for review

Dependency order and evidence gates

Acceptance criteria

Activity

auser commented on Nov 9, 2026

Product wording confirmed for the software-first profile

auser commented on Nov 9, 2026

Dependency-safe implementation started: typed content contract, not mailbox delivery

auser commented on Nov 9, 2026

Follow-on integration proof in the unmerged content branch

auser commented on Nov 9, 2026

auser commented on Nov 10, 2026

Receive/ACK contract handoff for the parallel local mailbox implementation (proposal before wire changes)

auser commented on Nov 10, 2026

Reader/ACK security review conditions before runtime exposure

auser commented on Nov 10, 2026

Dependency-safe reader/ACK contract implementation (unmerged)

auser commented on Nov 10, 2026

Canonical reader/ACK contract slice implemented locally; runtime gate still open

auser commented on Nov 10, 2026

Per-boot guest reader enrollment contract added on the unmerged DTO branch

auser commented on Nov 10, 2026

Pinned contract handoff for the parallel runtime implementation

auser commented on Nov 10, 2026

Integration gate against committed local-durable foundation (read-only review)

auser commented on Nov 11, 2026

Signed-plan report policy contract pin (private feature branch, not activation)

auser commented on Nov 11, 2026

Runtime owner handoff and remaining UX gate

auser commented on Nov 11, 2026

ACK UX boundary for the software-first trusted-local slice

auser commented on Nov 11, 2026

auser commented on Nov 11, 2026

auser commented on Nov 11, 2026

auser commented on Nov 14, 2026

auser commented on Nov 15, 2026

auser commented on Nov 15, 2026

auser commented on Nov 15, 2026

auser commented on Nov 15, 2026

auser commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions