Skill v1.0.0

name: 真实验证 description: Use when 强制门禁——在智能体闭环开发阶段4（含 bug 修复验证）、根因定位修复验证、Github协作提交前，必须调用本 skill 执行真实验证 metadata: version: "1.0.0"

定位

本 skill 是 myworkflow 所有编程 skill 的验证门禁。不通过本 skill = 不允许进入下一步（提交/合并/标记完成）。

核心原则：你不是在"检查代码"，你是在"使用产品"。像真实用户一样运行、点击、输入、观察。不允许站在代码外面指指点点。

协作级别（三级模型）：验证动作与执行级别无关——L1 单智能体自验、L2 子智能体各自验证自己的小件、L3 团队各 owner 验证自己的交付物；跨交付物接口兼容交给 integration-verify。同一交付物不按阶段拆窗口验证（步骤在交付物内部）。

协作语义与等待纪律（硬规则）

• L3 只用于大型、长程任务：把一个超大任务切成若干相互独立的部分，模仿真人团队「各自独立工作 → 沟通 → 整合」；每个 member ≈ 一个 L2（端到端做完自己那份再整合）。不要因为“任务大”就建团——要因为“需要持续负责人与并行独立交付”才建团。
• member 之间可直接沟通：任务切分不可能一开始就完美，执行中会出现交叉、重叠、接口变化；member 之间直接协商比“上报 leader 再转发”高效。leader 只在边界冲突需裁决、目标变更、验收标准修改时介入；改了交付边界同步 leader（记录在案），不必阻塞等批准。
• member ≠ leaf：leaf 寿命绑定单个任务、只与派发者沟通、任务完成即结束；member 长期存在（睡眠/随时唤醒复用），管一个领域、可跨任务复用、可直接与其它 member/leader 沟通。
• 等待纪律（硬规则）：本 skill 涉及长命令 / 测试 / 构建 / 网络请求时，≥30 秒一律放后台任务或派 leaf，本回合内不等待（不轮询、不 sleep、不反复检查同一任务）；结果靠二次唤醒取。leader 与 member 都不阻塞。

触发

• 强制调用（不可跳过）：
• 智能体闭环开发 阶段4 开始时 → 返回 ✅ 进阶段 5，❌ 进阶段 5 问题循环
• 智能体闭环开发 阶段4（bug 修复验证）→ ✅ 进完成，❌ 进循环
• 根因定位与全面排查 的修复验证环节 → 回修复步骤
• Github协作 提交前自检 → 不允许提交
• 不触发仅限：纯文档修改、纯配置修改、无代码变更的讨论。
• 红旗自检（开始前必读）："跑几个测试就差不多了"→ 不，TDD 测试测代码，本 skill 测产品，两者不等价；"改动很小肉眼看看就行"→ 改了代码就必须跑，没有"改动小"豁免；"系统太复杂无法完整跑起来"→ 把能跑的部分跑起来，跑不起来说明你根本不了解它；"跑全量测试太慢了"→ 慢也比上线后出 bug 快；"看日志/输出就够了"→ 用户不看日志，用户看页面/CLI 输出/文件结果，模拟用户操作；"之前已经验证过了"→ 每次改动后重新验证，上次通过 ≠ 这次通过。

执行流程

步骤 0：接收调用参数

调用方传入：项目根目录、项目类型（Web应用/CLI工具/库/前端SPA/后端API/全栈/脚本/其他）、本次变更概要（改了什么、影响哪些功能）、主入口/启动命令、测试命令、用户关键路径（≥5 条）。

步骤 1：环境就绪检查（硬门禁）

程序启动不起来 = 验证不通过。没有任何借口。

1. 启动程序主入口：执行启动命令，确认程序正常启动（server 监听端口、CLI 输出 help、SPA 编译成功可访问）。
2. 启动失败 → 这是第一个要修复的问题：输出完整启动错误日志，标记 ❌，立即返回调用方。
3. 启动成功 → 记录启动耗时、关键日志行（截取前 20 行）作为验证证据。

不可接受的启动验证：没实际执行（"启动命令看起来没问题"）；执行了但没等完全启动就判断"应该起来了"；端口被占用/编译报错仍声称"环境就绪"。

步骤 2：全量测试套件（硬门禁）

跑全量，不是挑几个文件跑。跑完报告统计数据，不能只说"通过了"。

按项目类型执行正确的全量测试命令：

规则：

• 必须执行项目定义的全量测试命令（不是挑几个测试文件）。无测试套件 → 跳过本步骤，直接进步骤 3 改为手动验证（不豁免，见下方「豁免条件」）。超时默认 5 分钟，大型项目可延长。

报告统计数据：

## 全量测试结果
| 总测试数 | 通过 | 失败 | 跳过 | 耗时 | 通过率 |
### 失败测试详情（如有）：[测试名]: [错误信息摘要]

判定：通过率 100% → ✅ 进步骤 3；<100% → ❌ 列出所有失败测试，标记不通过，返回调用方；有跳过 → ⚠️ 列出跳过的测试及原因，判断是否掩盖问题。

步骤 3：用户视角端到端验证（硬门禁）

最核心步骤。以真实用户的身份，走完所有关键路径。不允许只测 happy path。

3.1 列出所有用户通道

根据项目类型和本次变更，列出用户可能走的所有通道（至少 5 条；少于 5 条 → 想得不够全面，重新列举）：

3.2 逐条验证每条通道

对每条通道：1) 描述用户操作（"打开页面 X → 输入 Y → 点击 Z → 看到 W"）→ 2) 实际执行（启动浏览器/运行命令/调用 API）→ 3) 观察结果 → 4) 对比期望 → 5) 记录证据（终端输出/截图/HTTP 响应/文件输出——不允许只用文字描述）。

3.3 异常与边界路径（强制）

happy path 通过 ≠ 功能完成。用户不会只走 happy path。

对每条用户通道，至少验证以下异常场景：

步骤 4：回归检查

你改了 A，可能坏了 B。必须检查所有可能受影响的已有功能。

1. 识别影响面：列出本次变更可能影响的所有已有功能/模块。
2. 逐项验证：对每个可能受影响的功能走一遍核心流程。
3. 记录结果：

## 回归检查
| 已有功能 | 是否受影响 | 验证方式 | 验证结果 |
| [功能A] | 是——共享[模块] | 执行[操作]→观察[结果] | ✅/❌ |
| [功能B] | 否——独立模块 | Grep 确认无交叉引用 | ✅ |

步骤 5：输出验证报告

报告必须有具体数据。不允许"验证通过"四个字代替。

## 🔍 真实验证报告
 
### 环境就绪
-启动命令：`[命令]` / 启动结果：✅ 成功 / ❌ 失败 / 启动耗时：[N]s
-关键日志：
  ```
  [前 20 行启动日志]
  ```
 
### 全量测试
-命令：`[命令]` / 总数-通过-失败-跳过：[N]/[N]/[N]/[N] / 通过率：[N]%
-失败详情：[列表或"无"]
 
### 用户通道验证（共 [N] 条）
| # | 通道描述 | 期望结果 | 实际结果 | 证据 | 判定 |
|---|---------|---------|---------|------|------|
| 1 | [用户操作流程] | [期望] | [实际] | [日志/截图/输出] | ✅/❌ |
 
### 异常/边界验证（共 [N] 条）
| # | 异常场景 | 期望行为 | 实际行为 | 证据 | 判定 |
|---|---------|---------|---------|------|------|
| 1 | [空输入/非法输入/重复操作...] | [期望] | [实际] | [日志/截图] | ✅/❌ |
 
### 回归检查
| 已有功能 | 验证方式 | 结果 |
|---------|---------|------|
| [功能名] | [怎么验证的] | ✅/❌ |
 
### 总体判定
-✅ 全部通过 —— 所有测试、所有通道、所有异常场景、所有回归检查均通过
-❌ 不通过 —— 以下项目未通过：[列表 + 期望 vs 实际]
 
### 证据附件
-[如有截图/日志文件，附上路径]

判定与阻断规则

通过条件（全部满足才算通过）：

• [ ] 步骤 1：程序主入口启动成功
• [ ] 步骤 2：全量测试通过率 100%（无测试套件 → 手动验证全部用户通道取代）
• [ ] 步骤 3：所有用户通道（≥5 条）全部 ✅
• [ ] 步骤 3：异常/边界场景全部 ✅（至少覆盖：空输入、非法输入、未授权访问）
• [ ] 步骤 4：所有受影响的已有功能回归检查 ✅
• [ ] 步骤 5：验证报告包含具体数据（非空泛描述）

阻断规则：

豁免条件（严格受限）：

• 无测试套件 → 手动验证所有用户通道 + 所有异常场景（步骤 3 工作量翻倍）。
• 无法启动（纯库项目）→ 全量测试 100% 通过 + 写一个使用该库的示例程序并验证其输出。
• 无用户界面（纯后端 API）→ 用 curl/Postman 逐条调用所有 API 端点，验证响应体/状态码。

与其他 skill 的交互

完成标志

• [ ] 验证报告已生成（包含步骤 1-5 全部内容）
• [ ] 所有步骤通过（或已标注不通过项）
• [ ] 验证证据可审查（终端输出 / 截图 / 日志文件）
• [ ] 总体判定明确（✅ 或 ❌，不允许模糊表述）

证据口径映射（与 myworkflow-subagent-protocol 一致，不重复其长段）

• produced（回执）：验证报告已产出（路径 + 各步骤结论）；只有报告路径不算完成。
• verified（可复核证据）：步骤 1–5 每步有真实命令 + exit code + 证据附件（截图/日志/产物 sha256，有 runId 写 runId）；超时、无输出、非空文件都不算证据。
• accepted（owner 验收）：返回 ✅ 且「完成标志」逐条满足（报告必填字段齐全、判定与阻断规则全部通过）才算通过；超时/无输出 ≠ 失败也 ≠ 完成。

证据纪律（反臆测 E1–E6）

1. E3 实跑优先：任何「通过/失败/可用」结论，必须来自真实执行——命令 + exit code + 日志片段（或 runId、截图路径）。没有 exit code 或 runId 的检查不算验证；只读代码猜行为也是臆测。
2. E3 未核实就写未核实：核实不了的写「未核实」或「无法判定」，禁止用「应该/大概/可能/通常」当结论；宁缺勿猜。
3. E5 禁止编造：不得编造测试结果、截图、日志、runId 或「已验证通过」；没跑过就写没跑过，缺证据就空缺并说明影响。
4. 证据出处：每条判定记录出处（命令、exit code、日志行、runId、文件路径:行号），让第三方可复核。
5. E2 假设显式化：拿不到证据时先标「假设（未核实）」并立即去实测；E1 不凭记忆或惯例判断功能是否可用。
6. E6 交叉核对：关键事实至少两个独立来源（源码 + 实测）；两处证据冲突以可执行结果为准，并记录冲突。

取证格式：命令 → exit code → 关键日志行/截图 → 判定；四者缺一即证据不足。

反例：只写「测试通过」不贴命令与 exit code、拿别人的运行结果当自己跑的、截图与结论对不上——均视为未验证。

检查点：报告里出现「已验证」却没有 exit code/runId、或结论含「应该/可能」→ 直接判不通过并退回补证据。

E7 代价优先（谨慎执行）

• 高风险验证路径（涉及生产数据、发布、重启、不可逆操作）：先备份与预演/dry-run、小步执行，并记录回滚方式；不确定按高风险处理。
• 验证结论必须含代价评估：影响面、是否不可逆、如何回滚；缺代价说明的「通过」只算「未核实」。