Ceo Mail Review

---
name: ceo-mail-review
description: Use when an incoming email, DingTalk or Lark mail card, or channel=email action requires review, reply judgment, or unsubscribe handling.
metadata:
  managed_by: ceo-agent-service
  version: 2
---

# CEO Mail Review

Load `ceo-mail-review` for mail review, thread resolution, linked-material
inspection, reply judgment, or an audited `channel=email` action. First identify
which workflow supplied the request; its evidence and authorization boundaries
are different.

## Compose Operation Skills

Use the platform's mail and material Skills instead of copying their commands
into this business workflow.

| Source | Operation Skill |
| --- | --- |
| DingTalk mail | `dingtalk-mail` |
| Lark mail | `lark-mail` |
| DingTalk linked material | `dingtalk-doc`, `dingtalk-aitable`, or `dingtalk-drive` |
| Lark linked material | `lark-doc`, `lark-base`, or `lark-drive` |
| Standard IMAP/SMTP email | the email operation capability supplied by the runtime |

A linked material is not an email attachment. It is a document, table, or drive
item referenced from a DingTalk or Lark interactive mail review and readable
through the matching operation Skill. An attachment remains attachment metadata
only under this Email subsystem contract.

## Email Operation Boundaries

| Operation | Boundary |
| --- | --- |
| Classification confirmation | Save final category and feedback only; create no generic task. |
| Deterministic mailbox action | Email worker executes exact configured action and reads provider state back; no Agent run. |
| Unsubscribe proposal | Consumer proposes exactly one operation bound to the immutable ActionPlan; Consumer has no write capability. |
| Unsubscribe execution | Audit alone invokes the task/run-bound capability and verifies the external result. |
| Reply or mailto unsubscribe | Disabled; do not draft, send, or request SMTP capability. |
| Attachment | Metadata only; never download, open, OCR, parse, summarize, or infer body content. |

## DingTalk Or Lark Interactive Review

For a DingTalk or Lark interactive mail review:

1. Treat a truncated card or quoted preview only as a locator. Resolve the
   principal's mailbox and the complete original message or thread with the
   loaded mail Skill.
2. Confirm sender, recipients, subject, current thread state, and the exact
   request. Do not ask the sender to paste content that the loaded mail Skill can
   read.
3. Inspect every linked material needed for the requested judgment with its
   matching operation Skill. A link title or mail summary is not its content.
   Load `ceo-document-review` when the requested outcome requires substantive
   review of that linked material.
4. Check the current thread, sent state, and safe prior receipts before proposing
   a reply. Do not propose or execute a duplicate reply.

Do not treat an attached file as linked material. Do not download, open, OCR,
parse, summarize, or infer email attachment content.

## Automatic Email Action

For a `channel=email` task:

1. Use only the message and thread text supplied by the email context, plus
   sender, recipients, subject, time, standard mail headers, safe action metadata,
   and safe prior receipts.
2. Treat attachments as attachment metadata only: filename, MIME type, byte
   size, count, and inline flag. The runtime contract is `image_paths=()`.
3. Do not open or inspect attachment content. Do not download, parse, OCR,
   summarize, or infer it. Do not invent attachment facts.
4. Do not open or inspect linked content for a `channel=email` task. A URL in
   message text is text evidence only. Task 11 unsubscribe browser execution is
   a separate audited capability and does not authorize general link browsing.
5. Automatic `auto_reply` is disabled for the current Email subsystem. Never
   propose or send an email reply from a classifier result or Email task.
   Before proposing `unsubscribe`, read the current unsubscribe state and safe
   prior receipts. Do not propose a duplicate completed action.

When the message says only that details are in an attachment, do not reply or
claim that an attachment was read, correct, complete, approved, or understood.

### Audited Unsubscribe

An immutable ActionPlan containing `unsubscribe` does not require per-message
confirmation. Consumer A must select only a reliable entry associated with the
current subscription. Its initial proposal contains exactly `OPEN_ENTRY`, or one
authenticated `POST_ONE_CLICK`; controls on an ordinary page are not guessed or
precomputed. At each continuation, propose the exact ordered browser operations
consisting of the durable prefix plus one new operation. Audit Agent B must
review those exact operations before any external write; neither agent may
replace them with an unreviewed navigation, form
submission, or confirmation click.

When readback after an accepted operation finds another required control, stop
before using it. The runtime persists the executed audited prefix, redacted
observation, opaque control references, fixed control kinds and intents, and the
unchanged exact-origin policy references, then returns a typed continuation.
Consumer A may use only that continuation to propose one next operation. The
next accepted effect must be a strict append-only extension of the persisted
prefix with the same action, plan, classification, account, message, thread,
entry, and network policy. Audit reviews that extension automatically under the
normal feedback/revision lifecycle; no user confirmation is added. Execute only
the newly accepted operation and never replay the prefix. Repeat this
`awaiting_audit` cycle until exact terminal evidence is read back.

Treat RFC one-click as authenticated one-click only when typed provider evidence
confirms that valid DKIM covers both `List-Unsubscribe` and
`List-Unsubscribe-Post`. Without that evidence, downgrade the HTTPS entry to an
ordinary audited browser flow. A verified one-click operation is an isolated
HTTPS POST with the exact RFC body and no mailbox browser cookies or credentials;
it is never a GET.

Browser execution is restricted to the exact pre-authorized origins and opaque
controls supplied for this effect. Every redirect, form action, frame,
subresource, fetch, confirmation navigation, and resolved URL must remain in
that allowlist. Popup and download flows are rejected. The read-only discovery
interface may describe the already-loaded unsubscribe page and return opaque
control references; it does not authorize arbitrary browsing or attachment
access.

On every initial run and retry, reconcile the current page, provider state, safe
prior receipt, and confirmation mail before another write. A verified completed
or already-unsubscribed state ends the flow without repeating an operation. Do
not treat a click alone as success: require a terminal page, provider response,
or confirmation-mail receipt.

After a terminated in-flight claim, an uncertain effect is reconciliation-only.
A blank or missing browser page and an earlier journal step do not prove that a
write was not dispatched. Without exact effect-bound terminal evidence, report
the fixed unresolved technical failure and do not replay an operation.

Never place a full unsubscribe URL or query token in the proposal, step journal,
History, status, or error. The private URL may appear only in the restricted
runtime input consumed by the audited browser capability. Persist only opaque
references, redacted step types and states, fixed error codes, and a terminal
receipt.

Authentication continuation uses only the isolated persistent Email browser
profile, never the main Chrome profile or its cookies. Keep the exact origin,
immutable action identity, and append-only audited operation lineage unchanged.

- For `email_otp`, read only the same configured recipient mailbox. Select an
  OTP only when the mail matches the current site, recipient, context, and
  bounded challenge time window. The OTP is ephemeral: never place it in logs,
  durable steps, receipts, training text, History, status, or errors. Submit it
  only inside the newly audited form operation. The value may be consumed only
  once; clear the browser field and minimize Python references without claiming
  physical memory zeroization.
- For `captcha_handoff`, attempt ordinary interaction with the rendered
  challenge. Use no solver service, evasion, fingerprint spoofing, or principal
  impersonation. If the ordinary attempt does not pass, return `needs_human`
  with a resumable opaque browser/profile reference and no secret content.
- For `credential_handoff`, SMS, TOTP, QR, or password may be handled only when
  a corresponding configured capability exists. Otherwise return
  `needs_human` with the same opaque resumable reference.
- After the user completes a handoff, resume only the unexecuted suffix and
  never replay the audited prefix. Reconcile the existing session and current
  page with the distinct `RECONCILE_HANDOFF` operation before proposing another
  write. Do not use redirect readback to skip or repeat the initial ordinary
  CAPTCHA attempt.

Payment and the absence of a reliable browser entry remain non-retryable
business outcomes. Browser runtime and provider authentication failures are
technical failures and use the existing retry and exhausted-failure Attention
lifecycle; do not invent another top-level task status.

## Authorization And Outcome

Every reply requires explicit reply authorization.

- For a DingTalk or Lark review, the current request must explicitly authorize
  replying. Review-only, summarize-only, or approval-only requests do not
  authorize a mail reply. Authorization from an older message does not silently
  carry into a materially different current request.
- For `channel=email`, the current immutable ActionPlan is the authorization.
  The current deployment permits only its exact `unsubscribe` action to be
  proposed. `auto_reply` is disabled and cannot be proposed or sent.
  Classification confirmation, category text, an older plan, or prior
  conversation is not authorization for another mail action.
- Consumer A proposes only the authorized action; it never sends or unsubscribes
  directly. Audit Agent B reviews the proposal under the existing
  feedback/revision lifecycle. Only Audit may execute an accepted action and
  verify exact readback.
- If the complete current thread shows an equivalent reply already sent, use
  canonical `no_action` for the mail effect and report the verified state only
  when the current conversation needs it.
- If review is complete but reply authorization is absent, provide only the
  requested review or draft through an authorized channel; do not execute or
  propose a mail send.

The agent performs the business judgment. The service supplies references and
exact commands without interpreting mail or linked content. For `channel=email`,
the service instead supplies the immutable ActionPlan and bounded metadata
without interpreting message or attachment content. Do not infer or invent
unread content.

## Missing Evidence

When a participant can resolve a genuine evidence gap in an interactive review,
ask one concrete question naming the specifically missing mail or linked material
and explain why it is needed for the requested judgment. Do not ask for a generic
resend or for content the loaded operation Skills can retrieve.

For an automatic `channel=email` action, report a text or state-readback
dependency failure rather than asking a participant to bypass the metadata-only
boundary or claiming success from attachment metadata, a URL title, or a command
response alone.