运行面验证

目标是让改动的代码在真实入口上执行，并用捕获到的输出证明它做了声明的事。

测试、类型检查和构建是 CI 的证据，不是本技能的验证步骤；需要它们时单独执行并单独报告。在脚本里直接 import 内部函数再打印返回值，等于自己写了一个单元测试，应用并没有运行。

项目或全局规则定义了交付分档时，常规及以上档位需要本技能的 PASS，微小档不做运行面验证。

确定范围

• 在 Git 仓库中先确定完整范围：已提交的分支差异（相对上游或基线分支）和未提交的工作区改动都要看，不只看 HEAD~1。报告提交数。
• diff 是事实，PR 描述、提交信息和用户说法是对 diff 的声明。两者都读，不一致本身就是发现。
• 验证改动却找不到任何改动时说明并停止；建立或维护验证入口时，以指定功能和当前行为为范围。不在仓库中且用户未指定范围时询问。

找到运行面

运行面是用户（人或程序）接触改动的地方：

内部函数不是运行面：沿调用方追到上表中的某一行，在那里观察。

普通交付中只改文档、测试、无产物的类型声明或不改变行为的构建配置时，报告 SKIP，写一句原因，不用跑测试填补。建立或维护项目验证入口仍需执行配方中的真实功能。测试与源码混合时只验证源码部分；可以读测试了解预期，但随后要去运行应用。

获取启动方式

1. 先找项目已有的启动或验证入口：仓库根目录和改动所在子目录的技能、Makefile、Taskfile、package.json 脚本、README 和 CI 配置。monorepo 中优先找改动所在包自己的入口。
2. 没有现成入口时，从 README 和构建配置冷启动，限时约 15 分钟。卡住时报告 BLOCKED，写明停在哪一步、缺什么。
3. 冷启动成功且用户要求或项目约定沉淀时，把有效的构建、启动和驱动命令补进项目已有文档；已有文档只在它给出的命令失效或缺步骤时修改。维护项目验证说明时，写清开发期快速检查与提交、发布所用的权威检查各是哪个入口，以及两者结果不一致时以哪个为准。

需要建立或维护可复用的项目验证入口时，读取 项目验证配方，按实际执行结果沉淀启动、健康检查、功能驱动和清理方式。普通交付验证不自动创建项目技能。

驱动改动

• 用最短路径让改动代码执行：改了参数就带参数运行，改了处理函数就请求那个路由，改了错误处理就触发那个错误。
• 执行前回读计划：如果每一步都是构建、类型检查或跑测试文件，那是在重跑 CI，不是验证；找到能到达运行面的步骤，或报告 BLOCKED。
• 端到端走真实入口：用户点按钮，就点按钮，而不是只调用底层接口。各部分单独正常不代表连起来正常。
• 涉及删除、发布、发送或写到工作区外，且没有 dry-run 或安全目标时，不在真实目标上执行；验证周边能验证的部分，并写明哪条路径没跑及原因。
• 隔离共享状态：按项目规则选择临时目录，使用独立端口、独立 tmux socket 等，不与用户或其他会话的进程、端口和锁冲突。
• 工作区里有无关未提交改动时，它们可能掩盖或制造问题；必要时在只应用本次改动的临时 worktree 中验证。

主动试探

声明成立只是一半。在同一运行面上，围绕改动试探作者可能没测的情况，选与改动相关的：

• 新参数：空值、重复传入、与冲突参数同用、拼错时错误信息是否指出问题。
• 新接口：错误方法、畸形请求体、缺必填字段、超大负载。
• 改动的错误路径：相邻未改的错误路径是否同样被处理。
• 交互界面：中途中断、调整窗口、粘贴异常输入、快速重复操作。
• 状态与持久化：执行两次、在旧状态上执行、两个会话同时执行。

至少做一次试探。没发现问题的试探也要记录，例如“传入空 --from，得到明确错误，退出码 2”。

防止假绿

以下情况不能算通过：

• 检查被跳过但仍输出成功；
• 代码提前返回导致输出为空，而断言对空结果为真；
• 只看了源码或构建日志，没有打开生成物、页面或产物；
• 改动路径根本没被触发，例如期望 429 却一直收到 200。

通过必须至少有一个非跳过、非空的用例实际经过改动路径。

报告

## 运行面验证：<一句话说明改了什么>

结论：PASS | FAIL | BLOCKED | SKIP

声明：<改动应实现什么；diff 与描述不一致时写出>
方式：<使用的启动入口或冷启动过程，启动了什么>

### 步骤

1. [通过|失败|注意|试探] <对运行中的应用做了什么> → <观察到什么>
   <证据：命令输出、响应体、截图或面板捕获>

### 发现

- <运行时注意到的问题、摩擦、意外、diff 与声明的差异、环境问题；每个试探即使通过也列一行>

• 构建、安装和检出是准备工作，不列为步骤；测试和类型检查结果不放进步骤。
• [试探] 标记主动试探；全是 [通过] 没有 [试探] 说明只重放了正常路径。
• 证据要能被读者看到：读者无法访问本机文件时，把关键输出内联，截图用可发送文件的工具发出，不只给本地路径。
• 发现栏的门槛放低：运行中让你停顿、绕路或意外的都写；PR 页面上别人已经能看到的 CI 结果或评论不算你的观察。

结论定义

• PASS：运行了应用，改动在运行面上按预期工作。测试通过、构建干净、代码看起来正确都不算。
• FAIL：运行后不符合预期、破坏了其他功能，或 diff 与声明实质不一致。
• BLOCKED：无法到达能观察改动的状态，如构建失败、缺依赖、服务起不来。这不是对改动的判定；报告前先查完改动目录下可能提供运行环境的技能和脚本。
• SKIP：没有运行面。

4 项中 3 项通过就是 FAIL，直到第 4 项通过或有充分解释；含糊输出的处理见下方共享证据规则。

统一约束

• 证据与验收：遵循 ../_shared/common-acceptance.md，本 skill 只补充其中没有的要求。