maintain-verification-skill

维护验证技能

应用一有变化，功能映射就会过时。本技能是对由 create-verification-skill 技能生成的技能（或任何包含功能映射的项目本地验证技能）进行维护的循环。严谨性的衡量单位是功能，而不是每句话：从源代码覆盖每个功能文件，并在实际运行中测试每项功能，无需把每个要点都变成终端命令。

结果

选择一项，并说明是哪一项：

• clean — 每项功能都有源代码和实际运行方面的覆盖；没有值得发布的改动。不创建分支，也不创建 PR。
• changed — 通过一个 PR 发布经过验证的文档、测试框架或映射修正。
• blocked — 无法完成覆盖，或无法安全发布已验证的修复。明确说明阻碍原因。

编辑范围

只能编辑验证技能自身的目录（其 SKILL.md、features/ 以及它拥有的任何测试框架脚本）。运行期间绝不编辑产品代码：映射描述的行为若已不再符合应用现状，要么是文档偏差（修正映射），要么是产品回归（报告问题，不要在文档中掩盖）。

执行

0. 定位目标。 找到需要维护的验证技能：项目本地技能，其正文包含启动／驱动章节和功能映射（通常位于 .agents/skills/verify-*/）。有多个候选项 → 询问要选哪一个；没有候选项 → 停止，并指向 /create-verification-skill，不要自行编造目标。

1. 索引卫生。 阅读功能映射 README，并对同级文件执行 glob。修复缺失、多余、重复或失效的条目。保持轻量；不要生成清单。

2. 源码检查阶段。 每个功能文件分配一个只读子 Agent，并发启动。每个子 Agent 根据源码说明“这个面向用户的功能如何运作？”，通过引用指出可能存在的文档偏差，并返回一条简洁的实时验证方案。子 Agent 绝不驱动应用，也不编辑文件。返回格式：功能摘要 / 源码入口 / 可能存在的偏差或无 / 一条方案。

3. 核对。 每个功能文件都必须有返回的摘要。将重叠的方案合并为尽可能少的应用状态。抽查引用所指的偏差；无需重新证明没有问题的说法。检查近期变更中是否有未列入映射、面向用户的界面——只有找到具体源码路径，才能判定其缺失。

4. 实时验证阶段。 即使源码看起来没有问题，也必须执行。所有驱动操作均由协调者负责；遵循验证技能本身的启动模型——对于服务和 UI，使用一个长期运行的实例并串行驱动；对于短生命周期 CLI，则每次驱动都使用一个全新的隔离会话（由技能的 Launch 章节决定，而不是本流程）。至少验证每个功能一次，并在整个过程中始终遵守以下三项不变量，不因故障而改变：(1) 绝不驱动一个自上次出现意外情况后尚未通过健康检查的实例——首次驱动前先运行 doctor；以会话为单位时，每个新会话都运行 doctor；每次驱动失败后再次运行 doctor；如果 doctor 无法发现故障（例如进程正常但 UI 状态卡死），则重置到已知状态或重新启动，而不是抱着侥幸心理；(2) 已采集的证据在每次清理后都必须保留，并在其指定位置检查，不能想当然；(3) 驱动启动的所有内容都不得在该驱动失去用途后继续存留——无论会话卡住、已退出还是共享，都要清理失败迭代留下的残留（对于共享实例，清理残留，而不是实例本身）。若 doctor 因技能偏差而失败，则将其视为偏差：在编辑范围内修复并重试一次——只重启被修复内容影响的部分——然后再将本次验证标记为 blocked。只有提供具体前置条件（身份验证、授权、操作系统、外部状态）和已尝试的路径，才能将无法访问的功能标记为 verified-unreachable；如果映射遗漏了该前置条件，则属于偏差。分诊中进行的任何测试框架修复，都必须在合并前重新实时驱动验证。最后的清理须在本次运行的最后一次驱动之后执行——包括重新验证——确保没有任何内容在本次运行结束后继续存留（证据按技能要求保留）。

5. 分诊。 面向用户的描述错误或缺失 → 文档偏差，修复。功能正常但测试框架无法驱动 → 测试框架缺陷，修复；测试框架修复遵循与生成相同的辅助工具规则（脚本必须可执行，并在技能正文中记录调用方式）。应用功能实际损坏 → 产品缺陷；记录并告知用户，不要纳入此 PR。

6. 提交或停止。 对于有变更的情况：提交一个 PR，仅包含已验证的修正，并先重新阅读每个已变更文件。对于无问题或受阻的情况：不提交 PR，如实报告结果和覆盖范围。

在临时位置简要记录运行情况（已覆盖的功能、无法访问的前置条件、确认的偏差、结果）；不要提交这些记录。