检查 Caveman Cloud…

当被要求启动、批准、取消、推进或回滚 Caveman 实验时，先只读检查状态与结果，再给出一个受支持建议或阻断执行。

适用场景

解决思路

1. 把每次生命周期变更视为生产控制动作：先读取当前状态和结果，然后只报告一个受支持的推荐或阻断。
2. 记住当前 agent MCP 有意只读：control-api 尚未以原子方式强制执行完整生命周期转换表和证据门禁。
3. 门禁1：对 review、inspect、explain 或 recommend 的请求只授权读取。
4. 门禁2：绝不要批准结果处于 pending、必需 guardrails 缺失或证据报告 breach 的实验。
5. 门禁3：绝不要把实验 lift 转换成 `verified_savings`；只有 active real traffic 加上 provider-causal、provider-complete ledger evidence 才能这样做。
6. 门禁4：绝不要提供 organization id；project 和 tenant scope 来自已登录的 Caveman identity 和 server RBAC。
7. 门禁5：绝不要执行生命周期变更，即使用户已批准；精确的 `<action>:<experiment_id>` 字符串可由 agent 生成，不是人类意图的证明。
8. 门禁6：未知状态和服务器错误按 fail closed 处理；报告确切的 `cave_snake_code`。
9. Step 1：加载 project 和 experiment，优先使用 MCP：`caveman_context {}`。
10. Step 1：使用 `caveman_experiment_get {"action":"get","experiment_id":"<id>"}` 获取实验详情。
11. Step 1：使用 `caveman_experiment_get {"action":"results","experiment_id":"<id>"}` 获取实验结果。
12. Step 1：当用户未指定 id 时，使用 `{"action":"list"}`。
13. Step 1：CLI fallback：运行 `caveman cloud experiments list`。
14. Step 1：CLI fallback：运行 `caveman cloud experiments show <id>`。
15. Step 1：CLI fallback：运行 `caveman cloud experiments results <id>`。
16. Step 1：如果 login、project、experiment 或 results 不可用，停止。
17. Step 2：报告当前生命周期状态和安全类别。
18. Step 2：报告 control 和 candidate 样本量。
19. Step 2：报告 quality 或 eval 结果。
20. Step 2：在存在时报告 latency、error、cost、retry、drop 和 escalation guardrails。
21. Step 2：报告 evidence cost。
22. Step 2：报告 rollback 或 hold reason。
23. Step 2：报告结果是 pending、failed、promotable 还是 active。
24. Step 2：缺失不等于通过；如果必需字段缺失，声明 `evidence incomplete`，并且不要提议 approval。
25. Step 3：提议一个动作；允许的动作包括 `start`：仅从可启动的 draft 或 queued 状态且已配置 graders 时。
26. Step 3：`approve`：仅当证据完整且通过，并且当前角色可批准该 safety class 时。
27. Step 3：`cancel`：停止用户不再需要的非 active 实验。
28. Step 3：`rollback`：通过服务器关联的 policy path 回滚 active 或有害变更；当前部署可能如实用 `cave_not_implemented` 拒绝，绝不要把该响应描述为 rollback。
29. Step 3：展示 recommendation 和 id，例如：`Proposed action: approve experiment 7f...`、`Reason: candidate passed quality and every configured guardrail.`、`Execution: blocked until server-authoritative lifecycle and evidence gates ship.`
30. Step 3：不要把早先泛化表述如 “manage it” 或 “do what is best” 当作 mutation approval。
31. Step 4：不要发出或运行可执行生命周期命令。
32. Step 4：解释当前 server 尚未原子化强制执行每个 evidence/state transition；因此 CLI 和 MCP agent surfaces 只暴露 experiment reads。
33. Step 5：如果 operator 说他们执行了命令，重新读取 detail 和 results。
34. Step 5：报告 server-observed post-state、audit 或 result response，以及返回的任何 policy-delivery status。
35. Step 5：绝不要仅凭 operator 意图推断成功。
36. Step 5：使用如下 close：`Action: <action> <experiment-id>`、`Before: <state>`、`Server response: <status and cave_snake_code if any>`、`After: <re-read state>`、`Basis: experiment evidence only. Verified savings unchanged unless the signed ledger independently records active, provider-causal real-traffic savings.`

适用边界 · 注意事项

• 不适用于非 Caveman Cloud 的实验生命周期；需要其他平台时不要套用这些只读门禁。
• 不适用于要求实际执行 start/approve/cancel/rollback 变更的场景；当前 server 未原子化强制执行，agent 只读并应阻断执行。
• 不适用于把实验 lift 直接记为 `verified_savings`，除非 signed ledger 独立记录 active、provider-causal real-traffic savings。