通知与投递
“工作已完成”和“外部平台已经收到”是两个结果。Anyy 可以发布带标题的通知，也可以向当前用户或当前 Channel 的可信来源发送消息与受支持附件；它不会把任意账号当成可联系的地址。
发文字提醒，还是发送文件
这两种动作使用不同接口，不能混用参数：
| 目标 | 可用方式 |
|---|---|
| 发一条文字通知，带可选标题 | notify_user；用 delivery 指定 Gateway、可信来源或某平台的默认绑定，不接受附件 |
| 回复文字和已有产物附件 | send_message；target 只能为 current_user 或 origin，没有 delivery 或选择平台的参数 |
例如，发到已经配置的默认 Telegram 绑定时，可以说：
把检查结果整理成一条文字通知，发给我的默认 Telegram 绑定，不发送附件。
对应通知路由为 delivery: { target: "current_user_default", channel: "telegram" }。notify_user 的默认绑定路由必须指定 channel，但没有 attachments 输入。
需要发送报告文件时，应在已经由可信 Telegram 来源发起、且该报告产物可用的会话中请求：
将这份报告作为附件回复到当前 Telegram 对话。
这时通过 send_message 回复可信 origin。不要在 Dashboard 对话中要求“把附件发到我任意选择的平台默认绑定”：当前消息接口没有这项选择能力，文字通知接口也不能携带文件。
current_user 使用运行时当前路由：普通 Dashboard/TUI 请求走 Gateway，可信 Channel 对话通常回到来源。显式选择 origin 必须有可信来源元数据，不能靠平台名或收件人描述生成。
文字通知和计划任务的路由
delivery.target | 实际含义 |
|---|---|
gateway | 发布到当前 Profile 的 Gateway 事件流 |
origin | 回复当前 Channel 会话的可信来源 |
current_user_default | 解析指定平台的当前用户默认绑定；通知同时提供 delivery.channel |
none | 仅 Dashboard/CLI 调度管理可用于不发送用户结果；不是 notify_user 支持的目标 |
这些 delivery 值不是 send_message.target 的可选值。
先通过 Dashboard → Channel 或 anyy setup channel 连接账号，完成发送者访问策略/配对并测试。只有已配置、通过访问验证的绑定才是有效目标。定时任务的投递配置见定时自动化，账号连接见消息平台。
两种发送都有审计，重发可能重复。来源或默认绑定不存在时，应处理路由配置，不能让 Anyy 猜收件人。
对话里的系统卡片会保留
与会话关联的独立通知显示为系统通知卡片。切换对话再返回、刷新或重新连接后，它仍保留该身份；较早通知可随历史加载，同一通知不会重复出现。
发布前，Anyy 会保存经过敏感信息保护的完整正文，并为它建立独立持久归属。后续释放投递重试正文不会清掉这份历史。删除会话会同时移除其通知历史。
这些展示记录独立于 Pi 对话消息，不进入模型上下文，也不改变所选会话分支。带附件的消息可以沿用对话投影，因此不会再复制成一张独立系统通知卡。
这项保证不涵盖没有会话归属的 Profile 级实时事件，例如 Heartbeat 通知。旧版若已经释放原始正文，也不能用 Job 状态或摘要拼造回那条通知。
怎样确认投递结果
发布成功表示事件已交给 Anyy 的投递管线，不能单独证明 Telegram、邮件、短信等服务最终送达。
消息可能返回 Receipt，后续状态取决于 Adapter 的确认能力：有的能确认接收，有的只能确认已分发。需要排查时：
- 在来源对话核对系统卡片，或打开后台子会话/Cron 历史，确认工作确实结束。
- 检查目标绑定与 Channel 健康状态，并查看可用的 Receipt。
- 状态不明时先检查先前发送，再决定是否重发，避免第一条已到达但确认延迟造成重复。
send_message 的附件必须在当前会话作用域内可用，并符合当前/可信来源 Channel 支持的媒体种类和大小；不支持会报错，不会静默丢掉。选择默认平台的 notify_user 仍然只能发文字。需要换接收方式时，可在 Dashboard 打开同一会话查看产物。