通知與投遞
「工作已完成」和「外部平台已經收到」是兩個結果。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 開啟同一工作階段檢視產物。