v1.3.2

v1.3.2 — 2026-10-17

• 邮件建连、等待服务器响应、TLS 握手三处都加了超时（默认 15 秒，可用 mailTimeoutMs 覆盖）——IMAP / SMTP 服务器不回包时不再把 DSH 卡住
• 文档与实现对齐：清理只针对 INBOX，其它文件夹不扫描；不再宣称「邮箱里永远最多一封」

v1.3.1

v1.3.1 — 2026-10-15

• 兼容 PTC 模式：嵌套调用走 tool/ptc-dispatch-start 时也能正确计数
• 安装说明改为从 GitHub 装（这个包没有发布到 npm）

v1.3.0 — 修好「收不到通知」，并支持 STARTTLS

修好「任务跑完收不到通知」

这次是两个故障叠加，而且一直是静默失败——发不出去也不报错，所以看起来像"插件坏了"。

1. 「这一轮动手多不多」永远被算成 0 次

统计工具调用次数时翻的是会话对象上的 session.events 数组，而它在运行时是空的
（诊断日志实测：tools: counted=6 fromEvents=0 eventsArray=0，旧逻辑却写下 skip: 39s 且 0 次工具）。
于是「时长不到 3 分钟、但工具调用 ≥5 次」这条判据永远是假的，这类通知全哑。

现在插件自己在 session/event 事件流里累加 tool/call（两条路取最大值），不再依赖那个数组。

2. smtp.qq.com 的 465 端口不再提供 TLS

2026-10-12 起该端口回的是明文 220 问候语，直接 TLS 握手会报 wrong version number
（同一时间 smtp.163.com:465 正常）——于是「跑满 3 分钟」的通知也发不出去。

新增 mail.starttls，用 587 明文连接 + STARTTLS 升级：

配置	连接方式
"port": 587, "starttls": true	明文连上再 STARTTLS（推荐）
"port": 465, "starttls": false	连上立刻 TLS（隐式 TLS）

新增 debugTrace（默认关）

设成 true 后，插件会把「挂载情况 / 收到哪些事件 / 每轮为什么发或不发 / 发信成功还是失败」
逐行写进包目录下的 _trace.log。再遇到"收不到通知"，不用猜——node test-mail.mjs 测通道，
_trace.log 看判定。

其他

• 发信失败时日志附带连接方式提示（端口 / starttls 组合）
• README：465 / 587 二选一说明、收不到邮件的两步排查法；修正安装说明
  （这个包没发布到 npm，改成从 GitHub 装）
• 版本 1.2.0 → 1.3.0

完整改动：7bf9fdb...v1.3.0