用途
/verify 是变更发布前的最后一道关卡，用于对后端 HTTP 接口做 HTTP 级别的实际验证。其核心观点是：单元测试只能证明代码能编译、方法按作者预期返回，无法证明运行中的服务能接受真实载荷、返回约定结构、维持跨服务契约，或承受生产流量中出现的各种异常形状。
核心原则是：在对运行中的服务执行 curl 并得到正确的响应体、状态码和副作用之前，任何“已完成”的声明都不可信，并且必须有新鲜、已记录的输出。其他一切只是转述。
主要能力
每次运行都围绕以下设计目标展开：
- 证据而非断言：每个“通过”都由保存在工单目录下的 curl -i 输出作为支撑。
- 载荷真实性：夹具来自真实行形状（数据库采样）或用户提供的用例，而非凭空编造的 JSON。
- 变体覆盖：每个接口至少覆盖正常路径、一个边界、一个负例。
- 迭代纪律：失败时向 /work 传递具体的差异说明，而不是“它坏了，修一下”。
- 升级边界：检测无效的 /work 循环并升级，而不是无限重试。
- 环境受限的爆炸半径：默认 local/dev；audit/stg 载荷运行仅在用户明确指定该目标时允许；prod 永不允许。
硬性规则（Iron Law）包括：
- 在每个断言都针对活跃目标服务通过之前，不得声称“生产就绪”。
- 不得在用户授权目标与数据范围之外做实时验证。
- 不得在没有生成 curl 测试装置、记录 curl -i 输出、保存请求夹具的情况下做 API 验证。
- 对可达的 HTTP 接口，不得用单元测试、字节码、Mapper SQL 或代码阅读代替 curl。
- 本技能不得对 prod 发起载荷运行。
- audit/stg 载荷运行需要用户明确指示并记录目标环境。
- 在写入 verify.md 且其状态为 pass | fail-escalated | fail-user-required 之前，不得退出。
使用方式
标准模式下的流水线位置为：
- /explore → explore.md
- /work → work.md（代码 + 单元/集成测试 + lint/build）
- /verify → verify.md（HTTP 级 E2E 证明；失败时重新触发 /work）
在以下任一情况下调用 /verify：
- 某个 <YYYYMM>/<slug> 的 /work 刚完成，用户希望在合并前获得证明。
- 存在配对的 work.md，但当前会话没有新鲜的 HTTP 级证据。
- 用户提供 API 路径和至少一个载荷，要求临时验证（独立模式）。
- 收到针对既有接口的缺陷报告，希望在改代码前复现并守住修复（此时 /verify 先运行、捕获失败的 curl，再交给 /explore → /work → /verify）。
仅在以下情况跳过：纯前端改动且未触及后端；不改变任何 HTTP 契约的配置改动；仅文档/注释提交。
独立模式（无工单目录）：当不存在 <artifact-root>/.backend/<YYYYMM>/<slug>/ 目录且用户要求临时 API 验证时，从请求或既有夹具中确定接口（方法 + 路径）、目标服务和样例载荷，仅询问缺失的输入或数据访问授权；由接口推导 slug 并选择 artifact 根目录；创建目录后从第二阶段开始；第六阶段只写 verify.md。
输入与输出
输入来源包括：explore.md（契约、变更接口、跨服务契约）、work.md（编辑的文件、跨服务影响、后续事项）、服务自身的 CLAUDE.md（运行命令、本地端口、profile、认证方案）、项目根 CLAUDE.md、用户消息（额外载荷、环境覆盖）、已保存夹具、以及实时的只读 MySQL（采样真实行形状，PII 脱敏）。
输出（三项均为完成所必需）：
- curl 测试装置：<artifact-root>/.backend/<YYYYMM>/<slug>/harness/*.sh，可复用 shell 脚本，每个接口一个，BASE_URL/TOKEN 可配置。
- 夹具载荷：<artifact-root>/.backend/<YYYYMM>/<slug>/fixtures/*.json，各变体载荷体，已去除 PII。
- 运行日志与报告：<artifact-root>/.backend/<YYYYMM>/<slug>/verify.md 与 runs/run-<N>.log。
目录结构（工单验证后）包含 explore.md、work.md、verify.md、harness/、fixtures/、runs/。
七个阶段
各阶段必须按序完成，不得交错；第四与第五阶段之间的循环是唯一合法的循环，不允许临时重试。
- 阶段 0：加载与校验契约。确定 artifact 根目录与工单目录，通读 explore.md 与 work.md；宣布变更类型与范围；从 work.md 与 explore.md 推导必须探测的接口目标列表；校验至少推导出一个接口目标、每个目标暴露可达的 local/dev profile、work.md 状态非 blocked；确认目标环境（默认 local/dev，audit/stg 需明确指示，prod 永不允许）；输出验证计划检查点。
- 阶段 1：载荷来源。优先级从高到低为：用户提供的载荷、已保存夹具、实时 MySQL 采样（只读、仅 dev、LIMIT 限制、PII 脱敏）、合成载荷（仅用于边界/负例，须在 verify.md 中说明理由）。每个接口至少三个变体：happy、boundary、negative；缺陷修复额外增加 regression 变体。夹具写入 fixtures/<endpoint>.<variant>.json，写前脱敏。
- 阶段 2：装置生成。为每个接口生成 harness/<endpoint>.sh，加载 _env.sh，按变体调用，使用 curl -i --max-time 等参数并将输出追加到运行日志；脚本内联声明断言；断言辅助定义在 harness/_assert.sh 中，使用纯 bash + jq + grep。按服务族处理认证策略；无法到达的接口不生成装置，记录 [BLOCK] 并询问用户。
- 阶段 3：执行。启动目标服务（如 cd <service> && ./gradlew bootRun --args='--spring.profiles.active=dev'），轮询健康检查端点。
适用场景与限制
适用场景：后端 HTTP 接口改动后、合并前的 HTTP 层证明；对既有接口的缺陷复现；用户提供路径与载荷的临时验证。
限制与边界：默认仅 local/dev；audit/stg 需用户明确指定并记录；禁止对 prod 做载荷运行；不得用单元测试或代码阅读代替对可达接口的 curl；必须有 curl 测试装置、记录的 curl -i 输出与保存的请求夹具；不得提交未脱敏的 PII；在 verify.md 写入并给出有效状态前不得退出。
关于价格、收费或商业方案，当前资料未提供相关信息。