核心用法
本 Skill 提供诊断与自愈双模式：
诊断模式（diagnose.sh）：执行 4 步只读检查——BlueBubbles 服务可达性、webhook 注册状态、OpenClaw 网关响应、近期投递活动，全部通过返回 exit 0，任一失败则需干预。
自愈模式（heal.sh）：自动识别故障类型并修复：网关崩溃时重启 OpenClaw 服务；webhook 进入退避状态时删除旧注册并重注册新端点；支持 --dry-run 预览操作。修复后自动重跑诊断验证。
典型触发场景：OpenClaw 网关重启后 iMessage 中断、用户反馈收不到消息、作为 HEARTBEAT.md 定期巡检任务。
显著优点
1. 故障模式覆盖全面：针对网关重启断连、BB 退避机制、服务未启动三大高频场景设计专用修复路径
2. 零配置弹性：环境变量与命令行参数双支持，默认端口匹配 OpenClaw 标准部署
3. 可观测性强：诊断结果以 ✅/❌ 直观输出，agent 可程序化解析
4. 原子化修复：reset-webhook.sh 将删除+重注册封装为幂等操作，避免部分成功状态
潜在局限
- 依赖外部服务：无法自动启动 BlueBubbles.app（macOS 端），需用户手动介入
- 本地网络假设：默认
127.0.0.1部署，跨主机或容器网络需手动覆盖变量 - 凭证明文传输：
BB_PASSWORD通过环境变量传递，多用户系统存在泄露面 - 无持久化日志：诊断与修复日志未提及结构化存储，问题溯源依赖终端输出
适合人群
- OpenClaw + BlueBubbles 自建 iMessage 桥接用户
- 将 iMessage 集成纳入自动化工作流的开发者
- 需要最小化人工干预的运维场景
常规风险
- 服务中断风险：
heal.sh会主动重启网关，可能导致短暂消息投递窗口丢失 - 误修复风险：Dry-run 非强制，直接运行可能在不必要时触发 webhook 重置，导致消息乱序
- 权限需求未明示：重启网关、操作 webhook 需确认执行用户对 OpenClaw 进程及 BB API 的访问权限
- 网络暴露面：若
OPENCLAW_WEBHOOK_URL配置为公网地址且未校验来源，存在伪造消息注入可能