Approve and recover supplier communication

An action can produce a supplier message in draft. Approval is a separate live operation that can send that message. CLI 0.6.14 and MCP 0.2.14 support the complete review and receipt flow.

1. Review the exact message

maglev deliveries review DELIVERY_ID --json > reviewed-delivery.json

The review resolves the current manufacturer contact and includes the sender, recipient, copied recipients, subject, English and Chinese bodies, channel, project version and reviewSha256. Present all of it to the principal, including the external effect. The read itself saves no approval and sends nothing.

A missing contact or stale RFQ context requires correction before approval. Reading a directory contact never grants permission to contact it or disclose private files.

2. Approve that review

After the principal has approved the displayed content, create approval.json using the digest from that exact review. With jq installed:

jq '{expectedReviewSha256: .review.reviewSha256}' reviewed-delivery.json > approval.json
maglev deliveries approve DELIVERY_ID --input approval.json --confirm --json

A live key with approvals:write is required. The API checks the current fields under a transaction before freezing the message and recording approval. Any changed recipient, CC, content or project causes a conflict and no send. Never automatically refresh a digest after a conflict.

The equivalent HTTP sequence is GET /api/v1/deliveries/{id}/review, then JSON POST /api/v1/deliveries/{id}/approve with expectedReviewSha256. MCP uses review_delivery then approve_delivery with the same digest and confirm: true.

3. Inspect the receipt

maglev deliveries get DELIVERY_ID --json

Dispatch status	Meaning
ready	Approved and saved; no provider attempt yet
sending	A worker holds a 60-second lease; the provider may already have received the request
uncertain	Provider outcome is unresolved, for example after a timeout
accepted	A successful provider response or authenticated event establishes submission
failed	The send was rejected, or a signed failed/suppressed event closed an unresolved dispatch

providerAccepted: true describes submission to the provider. The legacy delivery status sent also includes manually recorded sends. Neither proves a supplier reply, quote or production.

dispatch.receipt reports authenticated provider events separately:

{
  "scope": "provider_email",
  "providerDeliveryReported": true,
  "events": {
    "sent": "2026-09-17T12:00:00.000Z",
    "delivered": "2026-09-17T12:00:02.000Z"
  }
}

This is a shortened, synthetic example. Missing events mean unknown. delivered means the provider reports delivery to a receiving mail server. recipientDeliveryConfirmed stays false: this email-level event does not establish delivery to each CC recipient, reading, a reply or acceptance of manufacturing work.

The API retains sent, delivered, delivery_delayed, bounced, complained, failed and suppressed timestamps independently. A message can have both accepted submission and later negative evidence. Check the event facts before deciding what to do next; repeated or out-of-order events do not erase earlier facts.

Current production configuration: the email transport and provider webhook credentials are not configured as of September 17. Approval therefore remains explicitly approved and unsent. WeChat is a manual outbox workflow. A working approval API is not evidence that an email was sent.

4. Recover the same dispatch

After an interrupted response, read the saved delivery before making another write. If recovery is authorized and appropriate:

maglev deliveries retry DELIVERY_ID --confirm --json

Recovery reuses the saved recipient, payload and provider idempotency key. An active lease returns the existing state. Retries stop after 23 hours from the first attempt; changed credentials, revoked keys, changed context or expired deduplication require review or reconciliation. Never create a replacement message or manually resend merely because the outcome is unknown.

A matching signed provider event can also reconcile a lost send response without another send. Once a receipt closes the dispatch, retry returns the saved acceptance or refuses a failed dispatch. A webhook arriving before the HTTP response cannot be overwritten by that late response.

A repeated approval returns its durable state without restarting an attempted email. Use the retry endpoint for an unresolved dispatch. The client does not retry automatically.

Reject a draft

maglev deliveries reject DELIVERY_ID rejects a draft and retains its record. It cannot cancel an approved or attempted email. For a message already approved, inspect its receipt and actual provider outcome.

Limits

This flow handles reviewed communication and recoverable provider submission. It does not sign NDAs, disclose engineering files to a factory, accept a quote, reserve capacity, buy freight or start production. Those actions need their own evidence and authorization. Engineering uploads have a separate owner-controlled transfer workflow.