# 支付超时诊断验收用例

## 1. 目标

验证当前单 Diagnosis Agent 能诊断支付超时问题，并为一次精确 Run 暴露安全、可核对的 Trace。

## 2. 输入

- `session_id`：`mvp-demo-payment-timeout-001`
- 问题：结合知识库和日志证据诊断支付超时，并给出有边界的修复建议
- Profile：`mvp-demo`

## 3. 验收标准

1. `POST /api/chat` 按 `metadata -> status* -> content|failure -> done` 顺序发送 named SSE；`content` 与 `failure` 必须互斥且只出现一次。
2. `metadata.session_id` 和 `metadata.run_id` 非空；该精确 ID 对能唯一定位持久化 Run 与 Trace。
3. Run 的 `intent=DIAGNOSIS`，终态、`release_outcome` 与 SSE `done` outcome 一致。
4. `agent_step.agent_name` 只出现 `diagnosis_agent`。AgentStep 只保存消息数量/角色、输出是否存在、Tool 名称等 metadata，不保存 Prompt、消息正文、模型正文或 Thought。
5. 每条 `tool_invocation` 都属于精确 `run_id`，Tool 名称属于 ACI allowlist，只保存有界的身份、状态、错误码、耗时和字节数 metadata；不得包含 SQL、日志查询正文、raw response、凭据或 evidence body。
6. `content` 只在 Harness guards 与 Release Policy 完成后发布；guard 或技术失败只能发布固定安全 fallback，不能泄漏 Agent 或 Tool 原始 JSON。
7. `query_logs` 明确标记为 Mock。`query_mysql` 只针对配置的隔离只读数据源验证；本验收不声称接入真实 CLS 或生产业务 MySQL。

## 4. 需要检查的 Trace 字段

- `data.runId` 与 `data.run.runId`
- `data.session.sessionId`、`data.session.intent`、`data.session.releaseOutcome`
- `data.steps[*].agentName`、`data.steps[*].thought` 与 metadata 字段
- `data.toolInvocations[*].toolName`、identity、status、error code、duration 与 size 字段
- `data.summary`

## 5. 已知边界

- 这是一次真实应用 E2E 验收，不能替代确定性的单元与契约测试。
- 外部模型、Redis、Milvus 和隔离数据源的可用性可能影响 live Run；失败时必须记录精确 session/run identity。
- 敏感配置治理和生产 CLS/业务 MySQL 接入不属于本次 MVP 验收范围。