# Genre Contract: Email / 邮件 (`platform.email`)

## 核心定位（硬约束）

- 交付物是可复制到邮件客户端的邮件成稿，不代表已发送，也不执行收件人查询、邮件发送、草稿箱或邮箱管理；实际邮件操作切到 `lark-mail`。
- 视觉策略默认使用 `formal`；仅在用户要求且不违反组织规范或所选 content contract 时调整。全文禁止 emoji、高亮块和装饰性组件。
- 默认只使用短段落、列表和普通链接等基础结构。只有已由用户说明、平台文档或可信配置确认目标平台完整支持飞书富文本时，才允许使用 `rich` 或 rich block；不得根据“邮件”“HTML 邮件”、飞书文档承载或平台名称自行推断支持。
- 一封邮件只承担一个主要沟通任务；主题、首段、正文和行动请求围绕同一目的。不得编造发件人身份、收件人关系、事实、权限、承诺、截止时间、附件或已完成动作；缺失但必需的信息使用清楚的占位符。
- 不使用封面或目录。即使已确认平台能力，表格、图片、`callout`、画板及其他 rich block 也只能在信息确有需要时使用，并确保复制、投递和接收后的语义完整。

## 适用与消歧

用户明确要“写邮件、邮件成稿、邮件草稿、邮件措辞、email、e-mail”，或要求起草回复、跟进、通知、邀约、外联邮件时使用，内容保存在哪里不影响本合同生效。

查看、搜索、发送、回复或管理邮箱中的真实邮件属于 `lark-mail` 操作；邮件系统说明、邮件数据分析、营销方案或把邮件作为信息来源时不触发本合同。若任务既要成稿又要实际发送，先按本合同形成并确认内容，再切到 `lark-mail` 执行发送。

## 邮件主任务

| 主任务 | 内容脊柱 |
|-|-|
| 请求 / 决策 | 目的或结论 → 必要背景 → 明确请求 / 选项 → 期望时间或下一步 |
| 通知 / 同步 | 关键变化 → 影响范围 → 接收方需知 / 需做 → 时间点与联系入口 |
| 回复 / 跟进 | 对应的前情 → 新信息或直接答复 → 未决事项 → 下一步 |
| 邀约 / 外联 | 联系缘由 → 与收件人的相关性 → 具体提议 → 低成本回应方式 |
| 致歉 / 问题沟通 | 承认影响 → 已确认事实 → 补救动作 → 后续安排与边界 |

## 成稿要求

- 成稿先给主题，再给正文；只有用户要求或材料明确时才列出收件人、抄送人等信封字段。主题准确表达对象、事项或所需行动，不使用标题党、空泛寒暄或无信息量的“重要通知”。
- 称呼依据已知关系和语境选择；关系不明时使用稳妥中性的称呼或显式占位符，不擅自套用亲密、职级或性别称谓。
- 首段尽快说明来意、结论或与既有线程的关系。背景只保留收件人理解、判断或行动所需的信息，不把完整报告、会议纪要或思考过程原样搬入邮件。
- 行动请求写清需要谁在何时以何种方式完成什么；材料没有给出负责人或时间时，不自行补造。多个并列事项使用列表，优先让收件人能直接逐项回应。
- 提及链接、附件或引用材料时说明其用途；未实际提供或上传的材料写成待补占位符，不声称“见附件”。回复和跟进邮件只补充新信息，不机械复述整个线程。
- 结尾与邮件目的匹配：请求类明确回应方式，通知类说明无需动作或下一节点，外联类保留易于拒绝或调整的空间。署名仅使用已知身份；身份不明时使用占位符，不虚构姓名、团队或联系方式。

## 交付前检查

确认收件人能从主题和首段判断“为什么收到、需要知道或做什么”，事实、责任人、时间和附件状态均有依据，正文没有无关铺垫或重复，语气符合关系与风险，全文无 emoji；若使用 rich block，已有目标平台支持飞书富文本的确认依据；复制到邮件客户端后仍清晰可读，且未把“成稿”误写成“已发送”。