Channel Debug Core 用于处理 vercel-openclaw 中 Slack、Telegram、Discord、WhatsApp 的渠道投递问题。
用途：在提出任何修复方案前，先完成证据收集与验证，避免凭猜测下结论。技能明确要求不得重复写 most likely，必须收集直接证据。
并行优先规则：针对线上部署，渠道调试以并行通道开始。父 agent 创建一个 artifact 根目录，并在任何补丁提案之前启动以下通道：Vercel/应用日志（channel_vercel_logs）、沙箱运行时（channel_sandbox_runtime）、工作流状态（channel_workflow_state）、渠道专项（channel_<channel>）。
合并门：每个通道必须返回交接，或标记为不可用并说明尝试的回退；至少一个运行时边被验证为坏；矛盾证据已加入假设表；既有已知修复已与当前证据对比。未满足前不得提出修复。
项目定向预检：在任何 vercel、npx sandbox 或 npx workflow 调查之前，证明命令针对的是预期的 Vercel 项目与团队。需检查 .vercel/project.json 并与事故目标比对；不一致时不要依赖推断的项目上下文，改用明确的项目/团队/部署定向并在交接中记录不匹配。资料指出该仓库的 .vercel/project.json 可能链接到 release 45（projectName: vercel-openclaw-45，projectId: prj_ag6Uzj9b4deNK98jVS5SO0H2Shmx）；对于 release 46，应使用明确目标上下文（projectName: vercel-openclaw-46，projectId: prj_JSzrXyJiMzT6F7BUA76Naa7nkjRa，team vercel-internal-playground）。若工具输出注明其从 .vercel 推断项目，需先证明推断项目与事故目标一致，否则视为可疑。
必需管理员接口：先采集 GET /api/admin/why-not-ready、GET /api/channels/summary、GET /api/admin/sandbox-diag、GET /api/admin/logs，保存原始 JSON 后再继续；日志为环形缓冲，可能淘汰重要事件。
就绪性三要素：分别报告 route-ready（平台路由/原生路由似已注册）、native-accepted（lastForward.ok 为 true 且 classification 为 accepted，或等同的处理程序接受证据）、user-visible-reply（真实用户看到回复或状态更新）。不得合并为 connected。
部署证明：运行或请求等同证据，如 git rev-parse HEAD、git ls-remote origin main、curl "$URL/api/admin/sandbox-diag"。若无法将部署运行时与所读源码关联，应说明并停止代码级结论。
证据存档规则：证据写在 .agent-runs/channel-debug/<timestamp>/<channel>/ 下；不要提交运行时证据；需脱敏管理密钥、绕过密钥、bot token、webhook 密钥和平台访问令牌。
发布环境文件：事故引用发布专用 env 文件（如 .env.45）时，仅用于调查该发布的线上运行。允许用途包括部署 URL/应用 URL、Vercel 项目/团队/部署上下文、用于日志/工作流/沙箱 CLI 的 Vercel token、ADMIN_SECRET、部署保护绕过、验证特定渠道运行所需的平台凭据。规则为：source 文件而非打印；不复制到 artifacts；交接中不包含原始值；仅记录文件名和使用的变量名。env 文件视为凭据/上下文输入，而非部署证明。
沙箱运行时探针：沙箱通道必须首先识别实际的 Vercel Sandbox 运行时 ID，先使用 /api/admin/sandbox-diag 和 /api/channels/summary，再访问 CLI。若 ID 为 oc-prj*、prj_、OPENCLAW_INSTANCE_ID 或 VERCEL_PROJECT_ID，不得作为 <sandbox_id> 传给 sandbox exec 或 sandbox connect。当 npx sandbox / sandbox 可用时，收集只读证据，包括进程、端口（3000/8787）以及 /tmp/openclaw/openclaw-.log 的尾部日志。配置仅打印形状，不打印密钥，读取 /home/vercel-sandbox/.openclaw/openclaw.json 并输出 channels 键、pluginAllow 以及各渠道是否存在。若 CLI 因 ID 不兼容或认证无法解析沙箱而失败，保存 CLI 失败信息并切换到应用管理员 SSH/exec 回退，回退必须运行相同的只读探针。
工作流状态探针：工作流通道必须在把工作流路径视为健康或故障之前检查 Vercel Workflow 状态，运行 npx workflow inspect runs --backend vercel，输出到 $ART/workflow/runs.txt 与 runs.stderr.txt。按渠道、事故时间、request ID、delivery ID、平台事件 ID 和 drainChannelWorkflow 关联。收集工作流运行 ID、状态、当前/最后步骤、重试次数或重复步骤证据、终态错误、是否发生原生转发尝试、是否写入 channels.forward_outcome。若 npx workflow 不可用或无法检查 Vercel 状态，保存失败并回退到按 workflow/channel 事件过滤的 Vercel 日志、/api/admin/logs 和 /api/channels/summary.lastForward。不得将本地工作流数据用作生产行为证据。
既有修复对比：在提出补丁前，将当前证据与已知既有修复和失败签名对比，包括 openclaw-42 零插件网关卡死、陈旧沙箱公共 URL/沙箱未监听、工作流重试耗尽、route-ready 与 native-accepted 不匹配、近期 accepted-forward 覆盖陈旧 configSync 失败、渠道特有签名/原始正文/密钥问题。仅凭重复的操作员消息不够，需按运行时信号匹配：状态码、路由探针、进程/日志证据、Workflow 状态和 lastForward。
当无法实时访问时的回退：若无法调用已部署端点，产生静态代码路径审计并将运行时边标记为 unknown；不得仅凭代码声称运行时行为。
适用场景：vercel-openclaw 项目中 Slack、Telegram、Discord、WhatsApp 渠道投递异常的排查与诊断。
限制：需要访问部署端点、Vercel 日志、沙箱 CLI 与工作流 CLI；无法实时访问时只能做静态审计；证据需脱敏且不得提交运行时证据；不得将 env 文件或本地工作流数据作为部署证明或生产行为证据。