TASK：Google fcop_minimal live e2e 验证

[joinwell52-AI]

TASK：Google fcop_minimal live e2e 验证

背景

Issue #2 已完成 Google FCoP Adapter 补全，专项单测 48/48 PASS。验收报告中第 8 条说明：

无有效 REPORT 不让 TASK 静默停 active：Adapter 侧 PASS；真实 Google API + FCoP MCP live e2e 未跑。

因此需要单独补一个真实环境 e2e，不再混入 Issue #2。

---

目标

在真实或 staging 环境中，用：

CODEFLOW_GOOGLE_TOOL_MODE=fcop_minimal

跑通 Google Agent 的最小 FCoP 闭环：

TASK
  → GoogleGenAiAdapter
  → fcop_minimal tools
  → write_report
  → submit_task
  → ReportSettlement
  → active/review 状态正确
  → audit 日志可查

---

验证范围

场景 A：正常完成

1. 创建一个简单 TASK，recipient 指向 Google 执行 agent，例如 DEV/OPS。
2. Google Agent 读取已注入 TASK 或使用最小工具。
3. 调用 write_report(status=done)。
4. 调用 submit_task。
5. ReportSettlement 判定 ok。
6. TASK 不静默停留 active。
7. REPORT 引用当前 TASK。
8. Audit log 中可看到工具调用链。

场景 B：无有效 REPORT 自动 blocked

1. 构造 Google run 无有效 write_report，或让其只输出普通文本。
2. ReportSettlement 自动写 blocked REPORT。
3. blocked REPORT 包含：

status: blocked
blocker_type: google_fcop_contract_failure
agent_provider: google
auto_generated: true
admin_action_required: true
reason: no_valid_report

4. TASK 不静默卡在 active。

场景 C：MODEL_NOT_FOUND

1. 临时设置错误模型名。
2. 触发 MODEL_NOT_FOUND。
3. 不重试 429/503 退避逻辑。
4. 写 RuntimeAlert。
5. 写 blocked REPORT 或 failed settlement 证据。

场景 D：PM 非 dispatch 场景不能派单

1. 使用 pm_self_report_only 或 hot path 自包含任务。
2. 确认工具列表中没有 write_task/create_task。
3. 普通文本“请 DEV 做”不被 Runtime 猜成派单。

---

必须收集证据

最终报告必须附：

1. 环境变量
2. 使用模型名
3. TASK 文件路径
4. REPORT 文件路径
5. lifecycle 前后状态
6. GoogleToolAudit 日志片段
7. RuntimeAlert 片段（如有）
8. npm test 或专项 e2e 命令输出

---

建议命令

根据实际项目启动方式执行，例如：

$env:CODEFLOW_GOOGLE_TOOL_MODE="fcop_minimal"
$env:GEMINI_MODEL="<有效模型名>"
npm start

或使用项目已有 e2e runner。

如果真实 GEMINI_API_KEY 不可用，必须说明：

live e2e 未能执行原因：无 API KEY / 网络 / quota / model 不可用
已完成替代验证：...

---

验收标准

1. CODEFLOW_GOOGLE_TOOL_MODE=fcop_minimal 在真实 run 中生效。
2. 正常任务能 write_report → submit_task。
3. ReportSettlement 被实际调用。
4. 无有效 REPORT 时自动 blocked。
5. MODEL_NOT_FOUND 不重试。
6. PM 非 dispatch 场景不能派单。
7. Audit log 能证明工具调用链。
8. 最终报告有完整证据链。

---

禁止项

• 不修改 Issue TASK：补完 Google FCoP Adapter 未落地部分并完成自测 #2 主线代码，除非 live e2e 暴露真实 bug。
• 不把单测结果冒充 live e2e。
• 不伪造 Google API 成功。
• 不通过手工移动文件绕过 lifecycle。

---

最终报告格式

# REPORT：Google fcop_minimal live e2e 验证

## 环境
- CODEFLOW_GOOGLE_TOOL_MODE=...
- GEMINI_MODEL=...
- API key 状态：可用/不可用

## 场景结果
### A 正常完成
PASS/FAIL
证据：...

### B no_valid_report blocked
PASS/FAIL
证据：...

### C MODEL_NOT_FOUND
PASS/FAIL
证据：...

### D PM 非 dispatch 不派单
PASS/FAIL
证据：...

## 总结
- ...

## 残留风险
- ...

优先级

P1。该任务是 Issue #2 的 live 验证补充，不阻塞 Issue #2 关闭。

[joinwell52-AI]

ADMIN 调度：暂缓执行

Issue #4 暂缓，等待 Issue #3 完成后再开始。

当前顺序：

1. Issue #3：TaskDispatcher failed-session restore，全量测试恢复绿灯
2. Issue #4：Google fcop_minimal live e2e 验证

请不要把 live e2e 与 failed-session restore 修复混在同一个工作单元里，避免范围污染。

[joinwell52-AI]

ADMIN 调度：开始执行 Issue #4

Issue #3 已完成并关闭，当前进入 Issue #4。

当前目标

验证真实环境下：

CODEFLOW_GOOGLE_TOOL_MODE=fcop_minimal

是否能跑通 Google Agent 的最小 FCoP 闭环：

TASK → GoogleGenAiAdapter → write_report → submit_task → ReportSettlement → lifecycle 正确状态

执行要求

请按 Issue #4 原始验收范围执行，至少覆盖：

1. 正常完成场景：write_report → submit_task → ReportSettlement done。
2. 无有效 REPORT 场景：自动 blocked REPORT，reason=no_valid_report。
3. MODEL_NOT_FOUND 场景：不走 429/503 重试，留下 RuntimeAlert / blocked 证据。
4. PM 非 dispatch 场景：pm_self_report_only 或 hot path 下不暴露 write_task/create_task，普通文本不能被 Runtime 猜派单。

必须提交证据

最终 REPORT 必须包含：

• 环境变量
• 模型名
• TASK 路径
• REPORT 路径
• lifecycle 前后状态
• GoogleToolAudit 日志片段
• RuntimeAlert 片段，如有
• 运行命令和结果

注意：不要用单测结果冒充 live e2e。

[joinwell52-AI]

ADMIN 调度：先跑通最小闭环

当前先不要一次性覆盖 A/B/C/D 四个场景。

第一阶段只做 Scenario A：正常完成闭环。

目标

在真实环境下跑通：

CODEFLOW_GOOGLE_TOOL_MODE=fcop_minimal
TASK → GoogleGenAiAdapter → write_report → submit_task → ReportSettlement → lifecycle 正确状态

第一阶段验收

必须提交：

1. 使用的环境变量：CODEFLOW_GOOGLE_TOOL_MODE、GEMINI_MODEL。
2. TASK 文件路径。
3. REPORT 文件路径。
4. lifecycle 前后状态。
5. write_report 调用证据。
6. submit_task 调用证据。
7. ReportSettlement 调用/判定证据。
8. GoogleToolAudit 日志片段。
9. 运行命令与结果。

暂缓

以下场景先不做，等 A 跑通后再追加：

• no_valid_report 自动 blocked
• MODEL_NOT_FOUND
• PM 非 dispatch 场景

目标是先证明 Google 槽能真实跑完一条最小 FCoP 任务闭环。

[joinwell52-AI]

PM 验收：Phase-1 最小闭环通过，但需后续修正语义瑕疵

收到 Phase-1 回报。

验收结论

Issue #4 Phase-1 目标判定为 通过：

PM → OPS TASK
OPS(Google fcop_minimal) → write_report
OPS(Google fcop_minimal) → submit_task
TASK active → review

说明 Google OPS 槽已经能真实完成一条 FCoP 检查任务，并将 TASK 提交到 review。

证据摘要

• TASK：fcop/_lifecycle/review/TASK-20260608-001-PM-to-OPS.md
• task_id：TASK-20260608-001
• thread_key：issue4-fcop-minimal-ops-check
• 主检查 REPORT：fcop/reports/REPORT-20260608-006-OPS-to-PM.md
• submit 绑定 REPORT：fcop/reports/REPORT-20260608-008-OPS-to-PM.md
• lifecycle：active → review
• GoogleToolAudit：write_report status=ok，submit_task status=ok
• 运行模式：CODEFLOW_GOOGLE_TOOL_MODE=fcop_minimal，CODEFLOW_FCOP_ONE_SHOT=1

不关闭 Issue #4 的原因

虽然物理闭环已跑通，但仍有语义瑕疵：

1. runner 末尾 settled status=failed。
2. submit_task 成功后模型 turn 2+ 重复 submit，导致 expected state active, got review。
3. 主检查 REPORT-006 缺 references/task_id，被 ledger 记为 orphan。
4. submit 绑定的是 REPORT-008，而非主检查 REPORT-006。
5. TASK frontmatter 出现 to: inbox 污染，需要后续修正 authority/default routing 行为。

后续处理

建议新开一个小修复任务，先修复：

• submit_task 成功后立即早停，避免重复 submit。
• ReportSettlement 不应在物理提交成功后把 runner 结算为 failed。
• write_report 必须绑定当前 task_id / references，避免 orphan REPORT。
• submit_task 应绑定主检查 REPORT，而不是 blocked 自动报告。

Issue #4 继续保持 open，用于后续 Phase-2/Phase-3 验证。

[joinwell52-AI]

ADMIN 调度：Issue #5 已完成，复跑 Phase-1

Issue #5 已完成并关闭。当前回到 Issue #4，复跑 Phase-1：PM → OPS 检查 FCoP 落地与 MCP 工具。

复跑目标

确认修复后的真实链路为“语义干净跑通”：

PM → OPS TASK
OPS(Google fcop_minimal) → write_report
OPS(Google fcop_minimal) → submit_task
TASK active → review
ReportSettlement done/ok
runner settled status != failed

本次必须验证

1. TASK active → review。
2. runner settled status 不再是 failed。
3. 不再出现 turn 2+ 重复 submit_task 污染。
4. 主 REPORT 绑定当前 task_id，不再 orphan。
5. GoogleToolAudit 是 clean chain：write_report ok → submit_task ok。
6. 全量测试仍 0 fail。

仍暂缓

本次仍只复跑 Phase-1，不跑 no_valid_report / MODEL_NOT_FOUND / PM 非 dispatch 场景。