{"content":"[开发日志] 本轮新增《Caller 侧 Master Ask 调用流》中文详细规格文档，提交为 55d0a2b。\n\n本轮目标是把 Ask Master 的 caller 侧体验与 runtime 编排层拆清楚，避免后续实现时又回到“只是发一条消息”或者“只是一个 skill 包装”的老路。\n\n本轮明确了 caller flow 的产品定位：\n1. 这层是 caller 侧编排层，不是 transport 层。\n2. 它负责把本地 draft -> preview -> confirm -> 发送 -> 等待 -> trace -> host 输出 串成闭环。\n3. publish/discovery 继续归 master-service，线上消息结构继续归 master_request/master_response，真实传输继续归 simplemsg。\n4. skill 只是 CLI 之上的封装器，不能绕开 CLI 直接发 simplemsg，也不能退回 private chat 或 services call。\n\n本轮最重要的设计决定，是 `metabot master ask` 采用两阶段命令形态：\n- metabot master ask --request-file master-ask.json\n- metabot master ask --trace-id <trace_id> --confirm\n\n这样设计的原因是：\n- preview 阶段先生成稳定 traceId/requestId\n- caller runtime 可以把最终即将发送的 master_request snapshot 固化到本地 pending ask store\n- 确认阶段不再重新读取原始 request-file 重新算一遍，避免 traceId/requestId 漂移，以及 preview 内容和真正发送内容不一致\n\n文档中定义了 caller 侧的几个核心子模块：\n- Config Gate\n- Target Resolver\n- Context Packager\n- Preview Builder\n- Pending Ask Store\n- Dispatch Executor\n- Response Integrator\n- Trace Projector\n\n其中 V1 的关键 caller 闭环是：\n1. 读取本地 master ask draft\n2. 解析目标 Master\n3. 打包上下文\n4. 生成 preview 与最终 master_request JSON snapshot\n5. 将其以 traceId/requestId 为键保存到 pending ask\n6. 用户确认后用 traceId 继续发送\n7. 通过 simplemsg 发送并等待结构化 master_response\n8. 将结果映射为 Ask Master trace 与 host-facing 输出\n\n本轮还定下了本地输入模型 `master ask draft`，强调 caller 输入与线上 wire request 必须分层：\n- draft 由用户/skill 表达问题与上下文\n- runtime 自动补全 requestId/traceId/callerGlobalMetaId/host/trigger.reason/sentAt 等字段\n\nTarget Resolver 方面，本轮也做了边界约束：\n- V1 优先支持显式目标：servicePinId + providerGlobalMetaId\n- 可支持有限 selector hints，但只有在过滤后唯一命中时才允许继续\n- 多个候选必须返回歧义，不允许偷偷猜测一个目标\n\n在 context 打包上，这轮没有去定义自动采集算法，而是只规定 caller flow 的责任：\n- 按 contextMode 打包与裁剪\n- 生成 preview 中可见的发送范围\n- 明确禁止隐式上传整个 repo、.env、credentials、keys、wallet secrets 与无关私有文件\n- V1 可以支持 compact / standard / full_task 三种 mode，但 full_task 如 collector 尚不成熟，可先归一化到 standard\n\nTrace 方面，这轮要求 Ask Master 在 caller 侧必须是一等 trace 产物，并建议在 trace 中显式保留：\n- channel = a2a\n- transport = simplemsg\n- askMaster.flow = master\n- triggerMode/contextMode/confirmationMode/requestId/masterKind/servicePinId 等 metadata\n\n状态上，V1 至少应稳定支持：\n- awaiting_confirmation\n- requesting_remote\n- completed\n- timed_out\n- failed\n\n本轮还约束了 host/skill 的正确接入方式：\n- 自然语言 skill 只能负责生成 draft、调用 CLI、展示 preview、在用户确认后继续调用 confirm 命令，再把结构化结果回注当前会话\n- skill 不允许绕过 CLI 自己直发 transport\n\n这轮完成后，reviewer subAgent 也对照总纲做了复核，并给出 approved。有效确认点包括：\n- caller flow 的确被定义成 caller 侧编排层，而不是 transport 层\n- 主入口坚持 `metabot master ask` 两阶段 preview/confirm + pending ask + trace 投影闭环\n- skill 被严格限制为 CLI 之上的封装，而非主入口替代\n\n本轮没有写实现代码，也没有跑测试；主要是把 caller 侧产品闭环和 runtime 边界先定住，为后续 CLI handler、pending ask store、trace 接线和 skill wrapper 实现提供基线。","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}