/x-verify-tech

name: x-verify-tech
description: |
  根据已确认的 tech-design 和适用开发规范，验收本次 task/feat/diff 的技术符合性：先提取设计约束，再对照实际代码，复用项目检查/测试，按风险补少量验收测试，逐项报告通过、失败或未验证。用户提到 x-verify-tech，或要求核对实现是否符合技术设计、模块边界、协议与数据约束时使用。不替代 spec 功能验收或 x-verify-spec 的交付记录对账，不修改业务实现或设计。

x-verify-tech

回答“本次实现是否遵守已确认的技术设计与适用规范”。结论只覆盖明确范围、代码基线和已取得的证据；测试通过不等于全面正确证明，也不能保证没有漏洞。

输入与权限

• 项目根目录：明确可访问路径；项目文件路径相对此根目录。
• tech-design 路径、内容基线与确认依据：已有用户确认结论、来源及覆盖条目；文件存在、父 agent 接收或开发者声明不等于确认，已有确认无需重复征询。
• 本次范围：task/feat、设计条目或明确 diff 基线/文件范围及承接来源；包括受影响的共享约束，不自行扩成全仓验收。
• 适用规范：项目 `AGENTS.md`、相关 `.agents/skills`、开发规范的路径与已知约束；无附加规范也注明。按需提供 spec 路径及基线以澄清行为依据。
• 授权边界与报告位置：是否允许新增验收测试、可用隔离环境/数据和外部副作用限制；未指定报告文件时直接输出回执。

缺输入先列具体缺项和影响；确认缺失、来源冲突或需求/设计歧义的受影响项记为未验证，向用户列出需确认的问题，其余项继续。不从实现猜预期，不修改已确认设计或自动启动其他技能。

缺 `tech-design` 或本轮适用机制/用例的确认依据时，相关项为未验证，不能仅靠 spec 场景或测试绿灯宣称技术符合性通过。C/D/用例编号按各自权威来源定位；旧设计没有 C 映射时沿用其已有 D、场景/约束 ID 或章节定位，不强制补编号，发现真实机制或测试覆盖缺口才报告。

只在授权项目测试范围内新增验收测试或隔离测试文件，并输出报告。不改业务实现、已有断言、排除项、阈值、设计/spec、任务状态或门禁记录来获取绿灯；发现问题仅报告，不自动修复。安装依赖、搭平台及外部副作用另需授权。持久化测试使用隔离临时数据并清理，不操作生产或真实私人数据。

1. 先列设计约束，再找实现

先读 tech-design 和适用规范，尚不据实现建立预期。复用 [x-tech-design 开发规范](../x-tech-design/references/development-rules.md)，不另抄一份规则。该链接相对本技能目录解析；设计及规范中的项目路径相对项目根目录，其他文档的相对引用按其声明的基准解析。记录解析后的可访问路径；共用资源缺失时查找可访问的 x-tech-design 安装/仓库位置，不凭记忆补规范，仍不可读的项标未验证并列最小补法。

从本次范围提取约束清单：保留 `D01` 等已有编号；无编号用章节/行号定位，不回写设计。每项写来源、适用原因、预期/不变量和拟用方法。逐条核对共用规范 R1–R7 及项目附加规则；相关规则不能因设计漏写而跳过，无法确定落实方案时列设计缺口。小改动引用沿用基线，只检查差异及受影响约束。

按需读取 spec 的具体 feat/场景及已确认 C 约束来确定行为、边界或数据含义；沿用 tech-design 的 C→D→用例映射，核对保障约束的技术机制（如幂等、结果核对和并发控制），不复制功能验收全集，不代替功能验收。无法确定预期时列具体回指、分歧与影响，请用户确认，不用技术假设补需求。

2. 对照代码并复用检查

约束清单确定后，再定位真实入口、模块、schema、状态读写、配置和现有测试。读取项目已安装工具、测试配置与已有检查命令，先检查现有断言是否覆盖该约束，再运行相关检查/测试；开发报告和旧绿灯仅作线索，不能冒充本轮执行结果。

| 核对对象 | 可操作方法（判定标准来自设计与共用规范） | |---|---| | 模块边界与依赖（R1） | 对照公开入口、允许依赖和实际 import/调用；优先运行现成循环/内部访问检查，无工具则明确做代码审查，列出依赖链、内部访问位置及覆盖局限。局部搜索无命中不能证明全范围无循环 | | 协议与校验（R2–R3） | 从权威 schema 追生产者、消费者、边界校验和错误传播；核对 TS Zod 的运行时校验与类型推导、Python Pydantic 的实际校验入口，跨语言查生成/同步及漂移证据。仅声明模型/类型不能证明入口校验生效；已有不同方案依确认设计核对差距，不自动替换 | | 数据、概念与状态（R4–R5、R7） | 追数据所有者、值的权威存储和全部相关读写；对照派生值及缓存/索引/快照的更新、失效、重建与提交顺序。说明名称映射的语义依据，区分协议定义源和值来源；不靠字符串搜索判断唯一来源 | | 具名配置（R6） | 定位权威配置、单位/默认值、覆盖方式及实际使用点；对照边界行为与重复字面值，不把普通索引当业务阈值 |

可机验的相关项实际运行；语义项给出文件/符号、调用或读写链及判断理由，明确标为代码审查，不能伪称自动验证。静态检查全绿不能代替协议权威性、数据归属等语义审查。

3. 按风险补少量针对性验证

优先复用 tech-design 已编号用例的主定义，引用用例 ID 并检查其实际断言/观察是否验证相应 D 机制；不要另抄测试正文或改低验收标准。为现有证据未覆盖的约束选择能观察违约的方法，主要使用项目已装测试框架。按适用风险选择真实边界集成、非法/边界输入、持久化失败、重复请求、并发或恢复；不要求每个任务全套工具/用例，也不搭新的测试体系。动态机制的证据不能由静态阅读替代。

获授权后可新增少量验收测试或隔离测试文件；补充探针以报告内局部编号标识，回指原 C/D/用例，不冒充或重定义主用例。若需扩充正式测试设计，列缺口交 x-tech-design 维护主定义，本技能不改设计。expected 必须回指设计、规范或 spec，不从被测输出生成；不 mock 掉待验证机制（如验存储却替换持久化层），其他替身须说明替代边界和证据限制。故障注入须保留待验证的真实处理路径。

核实命令、工作目录、选择范围、退出码、实际执行/跳过数和关键断言/观察。零测试、关键用例跳过、错误退出、超时、环境故障或只测替身均不能通过；确定违约/断言反例记失败，未执行到有效验证或证据不足记未验证。缺工具/环境/授权时不自动安装或改断言，列未验证项和最小补法。测试总数不能代替逐项证据映射。对于“成功但回执丢失后重试”，须验证结果未知不会被当作失败、去重/结果核对路径真实执行及最终副作用数量；只验证重试函数返回成功不足以证明机制。一个 C 的一条用例通过也不等于全部约束或功能需求覆盖，业务覆盖对账仍由 x-verify-spec 核对。

4. 逐项交付证据与结论

使用 [短报告模板](templates/verify-tech-report.md)，表格可按实际范围缩减，删除占位符。证据短而具体：设计/规范条目、适用性、代码位置、检查命令或审查方法、来源支持的预期、实际结果、基线与局限。日志只摘关键事实并给可定位来源；失败给最小反例或实际违约证据，未验证给缺项及最小补法。

记录代码基线（Git HEAD 加工作区差异/相关文件内容哈希，不能只记 HEAD）、设计/规范及使用的 spec 基线；新增测试的路径和最终内容也纳入基线。执行证据注明环境及来源；报告中的方法、命令和结果必须实际发生。代码或相关输入改变后重跑受影响证据，不能沿用旧通过。

• 适用项只有 **通过 / 失败 / 未验证**；一项含多个约束时全部有充分证据才通过，部分缺失须拆行或记未验证。
• 不适用单列具体理由，不伪装通过；工具缺失、未实现、未执行或缺证据不是不适用。
• 整体结论：任一失败为 **失败**，同时保留未验证清单；无失败但有未验证为 **未验证**；全部适用项通过且范围/基线可核实才为 **通过**。没有适用项时说明原因，不宣称验收通过。

回执包含范围、报告路径或正文、逐项结果和限制、待确认问题及新增测试路径（无则注明）。范围外缺陷可另列提示，不扩改。保持设计不改、仅报告，不自动调用 x-fix、x-qa-gate 或其他技能。

委派输入

父 agent 委派时给自足输入，不要求子 agent 猜父会话；委派本身不扩展测试或副作用授权：

任务：使用 x-verify-tech 验收技术符合性，不修改业务实现或设计。
技能入口：<可访问的 SKILL.md；共用规范及模板也须可访问>
项目根目录：<路径>
tech-design：<路径、基线、已有用户确认结论/来源/覆盖条目>
范围：<task/feat/设计条目或 diff 基线及文件；承接来源>
规范与 spec：<适用规范路径/约束；按需使用的 spec 路径/基线>
授权与输出：<允许新增测试的范围、隔离环境/数据、副作用限制；报告位置>
返回：<证据表、整体结论、局限/待确认项、新增测试路径；不自动修复>