feat: delay long-running task notices

README.md

@@ -212,7 +212,9 @@ Bot fingerprint 包含 Bot ID、workspace、persona、agent、permissions、skil
 - `/new` 保持串行，清除当前 chat binding；下一条普通消息创建新 native session。
 - `/roles`、`/role`、`/agents`、`/agent` 会返回固定 retired 提示，不会转发给 ACP。
 
-同一 chat 的普通消息和 `/new` 串行执行，不同 chat 可并发。异步平台的普通消息通过 policy 后会立即确认：空闲时发送“已收到，正在处理。可随时发送 /status 查看状态。”，已有同 chat 工作时发送“已收到，已排队。可随时发送 /status 查看状态。”。每条消息的 ACP prompt 会等待该确认完成或安全失败后再开始；排队消息的确认不等待前项。确认发送失败只写不含消息正文或 provider 错误详情的安全日志，不阻止已入队任务；同步 webhook 不额外发送确认。QQ 对同一入站 `msg_id` 的确认使用 `msg_seq=1`，最终或错误回复使用 `msg_seq=2`；单条命令回复使用 `msg_seq=1`。
+同一 chat 的普通消息和 `/new` 串行执行，不同 chat 可并发。异步平台的普通消息轮到后立即开始 ACP prompt，不等待状态提示发送：15 秒内完成只发送真实结果；15 秒仍未完成时，running 发送“这条还在处理，完成后我会直接回复。”，queued 发送“前面还有任务，这条还在排队，轮到后我马上处理。”；发送过 queued 提示的消息真正开始时再发送“轮到这条了，我开始处理。”。入站后 60 秒、180 秒及之后每 300 秒按 queued/running 和 ACP `idleSeconds` 发送低频口语化提醒；延迟执行的 timer 不补发历史提醒。同步 webhook 不发送这些提示。
+
+每条异步入站有独立、串行的回复流，`replySequence` 从 1 动态递增；因此短任务最终回复使用 `msg_seq=1`，已发送提示时后续消息使用下一序号。平台发送失败只记录不含消息正文或 provider 错误详情的安全日志，不影响 ACP 任务或回复流中的后续发送，也不会把成功的 ACP 结果误报为 `Agent error`。最终结果加入回复流后即释放 per-chat lock，平台发送延迟不会阻塞下一项任务；完成与 shutdown 都会清理状态提醒 timer。
 
 ## HTTP 端点