Menü
执行 A2C-SMCP Python SDK 的用户验收测试（UAT）。通过 tmux MCP 工具在真实终端环境中验证 CLI 命令和端到端协议流程。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Minimal greet skill for strict-mode seed derivation
Minimal review skill for strict-mode seed derivation
Minimal scan skill for strict-mode seed derivation
Well-formed minimal SKILL used as the canonical happy-path source for UAT seed derivation across mcp / marketplace / user sources.
创建、更新或删除 UAT 场景文档，确保以 tmux 终端交互验证为核心，符合 A2C-SMCP SDK 的 UAT 最佳实践。重型场景自动加载对应设计指南。无参数时自动扫描 Git 变更，分析受影响的场景并批量更新。
创建、扩充、验收 A2C-SMCP UAT 种子服务与数据。种子按 SKILL 来源（mcp / marketplace / user / _common）分目录组织，每条种子伴随**可执行的验收方法**，供 UAT scenarios 复用。无参数时进入交互向导；带 source+name 则定向走对应 recipe。
| name | uat |
| description | 执行 A2C-SMCP Python SDK 的用户验收测试（UAT）。通过 tmux MCP 工具在真实终端环境中验证 CLI 命令和端到端协议流程。 |
用户验收测试（UAT）技能。通过 tmux 终端自动化工具，以真实用户视角对 A2C-SMCP SDK 的 CLI 命令和协议流程进行端到端验收测试。
你是一名 QA 测试工程师，负责对 A2C-SMCP Python SDK 执行用户验收测试。你将使用 tmux MCP 工具在真实终端环境中模拟用户操作，验证 CLI 命令和协议交互是否符合预期。
执行任何测试前，必须确认以下条件：
uv sync --all-groups 已执行，a2c-computer 命令可用mcp__tmux__* 系列工具（创建 session、执行命令、捕获输出）如果任一条件未满足，停止测试并提示用户先完成准备工作。
resources/scenarios/<scenario>.mdresources/seeds/<source>/<name>；逐条跑
acceptance（/uat-seed audit <source> <name>）。任一 ❌ → 进入
Seed 升级流程 后再执行 scenario；
任一缺失 → 进入 Seed 缺口流程execute-command 发送 CLI 命令capture-pane 获取输出/fix-issue 或 /uat-seed 还是直接报 FAILa2c-uat # 主 session
a2c-uat-server # Server 进程（需要完整链路时）
a2c-uat-computer # Computer 进程（需要完整链路时）
a2c-uat-agent # Agent 进程（需要完整链路时）
a2c-uat-cli # 独立 CLI 命令（不需要完整链路时）
所有测试必须保证三端日志可收集。具体策略：
capture-pane 获取对应 pane 的完整输出/tmp/a2c-uat-logs/ 目录日志文件路径约定：
/tmp/a2c-uat-logs/
├── server.log # Server 进程输出
├── computer.log # Computer CLI 输出
└── agent.log # Agent 客户端输出
启动进程时使用 tee 双写：
uv run python server_script.py 2>&1 | tee /tmp/a2c-uat-logs/server.log
1. 创建 tmux session + windows
2. 启动进程（重定向到日志文件）
3. 等待进程就绪（轮询 capture-pane 检查输出）
4. 执行测试用例
5. 测试完成后 kill session（自动清理所有进程）
只需要一个 tmux window，直接执行 a2c-computer 子命令：
tmux session: a2c-uat
└── window: cli → a2c-computer marketplace add <url> --trust
启动方式：
a2c-uatcapture-pane 获取输出验证需要三个 tmux window，分别运行 Server / Computer / Agent：
tmux session: a2c-uat
├── window: server → Server 进程（端口动态分配，写入 /tmp/a2c-uat-port）
├── window: computer → a2c-computer run --url http://127.0.0.1:<PORT>
└── window: agent → Agent 客户端 Python 脚本
启动流程（严格按顺序）：
a2c-uata2c-computer run --url ...，等待连接成功详见 resources/test-env-setup.md。
resources/seeds/<source>/<name>）必须当次 audit
PASS 才作为前置；不允许带 FAIL/Flaky 的 seed 进入正式测试/uat-seedScenario 中所有 fixture（MCP Server、marketplace 仓库、SKILL 包等）只能通过
resources/seeds/<source>/<name>路径引用——不在 scenario 文档里 inline 长 fixture。 当 seed 行为与 scenario 期望不符时，本节定义诊断 → 升级流程。
| 现象 | 含义 | 默认动作 |
|---|---|---|
| 种子 acceptance FAIL（仍可复现） | seed 自身坏了（被 _common 改动 / SDK 行为变化 / 平台差异） | 暂停 scenario → /uat-seed audit <source> <name> 复现 → 走 upgrade |
| scenario 期望与 seed 提供的"被测行为"对不上 | seed 的失败维度不准 / 触发的不是 scenario 想测的代码路径 | 暂停 → /uat-seed audit 取 seed 实际期望 → 与 scenario 期望比对 → 二选一改 |
| scenario 需要的形态在 seeds 不存在 | 缺新 seed（新模式 / 新失败维度 / 新组合） | 进入 缺口流程 |
/fix-issue，不动 seed/uat-seed upgrade/uat-seed audit <name> 独立跑能否复现 FAIL？能 → seed 病；不能 → SUT 病a2c-smcp-protocol/docs/specification/skill.md 找 seed 的 axis 对应条款/add-feature 协议先行）1. /uat-seed audit <source> <name> # 独立复现
2. 决定 upgrade 维度：
- 资产本体（脚本 / 目录 / 归档）问题 → 修资产
- acceptance 断言过紧 / 过松 → 修 acceptance（确保仍对齐协议条款）
- axis 在 failure-axes.md 不准确 → 先改 failure-axes
3. /uat-seed audit <source> <name> # 验收
4. 若 seed 派生自 _common/<x> → 跑全部派生方 audit（README 内"已派生引用"列）
5. 回到 scenario，重跑相关 UAT 用例
6. 在 UAT 报告"Seed 反馈"节登记升级条目（含 axis、修了什么、为什么）
在 UAT 执行期间遇到（不是 scenario 编写时——那是
/uat-scenario的责任）： 例如 P1/P2 用例发现需要"archive 模式 happy" 但 seed 库当前只有 resources 模式。
1. 在当前 UAT 报告暂列该用例为 ⏭️ Skipped + 注明"待 seed: ..."
2. 完成本场景其他用例
3. 场景结束时统一汇报缺口：
- 缺口名（按 failure-axes.md 命名约定）
- 在哪条用例需要
- 期望被测行为（一句话）
4. 由用户决策：
a. 立刻调 /uat-seed create <source> <name> 补 → 补完回测
b. 留到下个开发周期，本场景接受 Skipped 通过
反模式（禁止）：
对所有 FAIL 结果执行二次复验：
capture-pane 的行数，检查是否有延迟输出## UAT 报告 - [场景名称]
日期：YYYY-MM-DD
分支：[当前分支]
环境：tmux session a2c-uat
### 测试结果摘要
- 总用例数：N
- 通过：N ✅
- 失败：N ❌
- 跳过：N ⏭️
### 用例详情
| # | 用例 | 优先级 | 引用 seed | 结果 | 复验 | 备注 |
|---|------|--------|-----------|------|------|------|
| 1 | ... | P0 | seeds/mcp/server_resources_ok | ✅ | - | |
### 失败用例详情
#### [用例名称]
- **步骤**：...
- **预期**：...
- **实际**：...
- **诊断**：SUT bug / Seed bug / Scenario 期望不准（参 [诊断三问](#诊断三问fail-时逐条回答)）
- **引用 seed**：`seeds/<source>/<name>` —— 当次 `/uat-seed audit` 状态：✅ / ❌
- **tmux 输出**：
[粘贴 capture-pane 内容]
- **日志线索**：[从 /tmp/a2c-uat-logs/ 中提取的关键错误信息]
### Seed 反馈（本场景对种子库的变更需求与已执行升级）
| 类型 | seed | axis | 触发用例 | 动作 | 状态 |
|---|---|---|---|---|---|
| upgrade | seeds/mcp/server_resources_ok | happy | F-05 | 修 acceptance.sh 断言：补 ref source 字段验证 | ✅ done |
| 缺口 | seeds/mcp/server_archive_ok | happy | F-08 | `/uat-seed create mcp server_archive_ok` | ⏭️ 待执行 |
| 缺口 | seeds/marketplace/strict-false-conflict | MK-STR-02 | M-12 | 同上 | ⏭️ 待执行 |
> **规则**：本节为空 = 当次跑没有 seed 病；任一行 ⏭️ 待执行 意味着相关用例仍是
> Skipped；用户决策补 seed 后回测。
### 进程日志摘要
#### Server
[最近 N 行关键输出]
#### Computer
[最近 N 行关键输出]
#### Agent
[最近 N 行关键输出]
请执行 UAT 测试。
首先确认前置条件：
a2c-computer 命令是否可用？判断执行模式：
$scenario 已指定）加载场景 $scenario 的测试用例并开始执行。
$scenario）扫描 resources/scenarios/ 目录，获取所有可用场景列表。
对每个场景，严格按以下步骤执行：
步骤 1：环境准备
按场景类型（CLI-only / 完整链路）创建 tmux session 和必要的进程。
步骤 2：执行场景
执行该场景的所有测试用例，完整流程：加载场景 → 逐用例执行（发送命令、捕获输出、对比预期、标记 PASS/FAIL）→ 输出该场景 UAT 报告
步骤 3：环境清理
每个场景完成后：
/tmp/a2c-uat-* 临时文件步骤 4：上下文管理
执行 /compact [场景名] UAT 完成。通过 X/Y 用例。[若有失败：失败用例：xxx] 压缩上下文。
步骤 5：结果判断
输出总汇总报告。