用途：闭环跟踪外联发出之后的结果，按 sent、replied、meeting_booked、no_reply_48h、no_reply_7d、closed_won、closed_lost 等状态记录每个外联事件，并为渠道评分与假设验证提供数据。
主要能力：读取 memory/outreach-feedback.jsonl 作为状态文件，读取 memory/pipeline.json 获取潜客上下文，并遵循 USER.md 中的输出偏好（Telegram 最多 10 行）。定时模式通过 feedback-checker-001 cron 在每天 10:00 和 16:00 运行：对 status 为 sent 的条目，若发送超过 48 小时且 checked_48h 为 false，则通过 Composio/Gmail 检查是否收到回复，收到则更新为 replied 并记录 reply_at，否则更新为 no_reply_48h 并置 checked_48h；若发送超过 7 天且 checked_7d 为 false，则做最终检查，仍无回复则更新为 no_reply_7d 并置 checked_7d。每次检查后更新 memory/channel-scores.json，按渠道记录 sent_count、reply_count、reply_rate、meeting_count。检测到新回复时会在下一次 Evening Recap 中包含，并通知 CEO；无新回复时输出 HEARTBEAT_OK 保持静默。
使用方式：CEO 说出 check outreach 或 any replies? 时触发按需模式，立即运行完整检查并报告所有待跟进外联的状态，格式包含姓名、渠道、时间与回复片段，并给出 30 天回复率与最佳渠道。新增外联时由 outreach-sender 或 CEO 追加条目，字段包括 id、ts、prospect、channel、type、status、sent_at、checked_48h、checked_7d。当回复带来会议或洞察时更新 learning 字段，并把学习结果反馈给 hypothesis-tracker。
适用场景与限制：适用于需要持续追踪多渠道路（email、linkedin、reddit、hn、devto）外联效果并据此优化渠道策略的流程。资料未提供安装命令、独立界面或可视化报表；其自动检查依赖 Composio/Gmail 与 cron 环境，具体权限与配置暂未提供。相关技能包括 outreach-sender、pipeline-manager、morning-brief、evening-recap 和 hypothesis-tracker。