用途：把"测试这个应用的每个功能"这类宽泛请求，转化为以单一事实来源驱动的受控循环。它要求每个功能都锚定到代码，在唯一的规范表格中记录预期行为，逐条按用户故事执行测试并分类失败，只有在当前请求明确授权时才修复。
主要能力： 一、功能盘点。先梳理用户可见面，包括 CLI 命令与参数、Web 或桌面 UI 路由、API 端点、影响用户的后台任务或钩子、插件与安装发布面、导入导出与备份迁移等流程；每条功能以"作为某用户，我想要某能力，以便某结果"写成用户故事。 二、规范追踪表。只建或更新一个追踪表，有电子表格环境时用真实表格，否则用 CSV 并视为规范表格。列为：Feature ID、Surface、功能、用户故事、基于代码的预期行为、代码锚点、初始测试方式、初始测试命令或路由、状态、测试结果、错误、修复状态、重测结果、备注。每行至少一个代码锚点，行宽需保持可解析。 三、状态与缺陷分类。状态取值包括未测试、通过、产品失败、体验失败、后勤失败、测试设施失败、环境阻塞、已修复、修复后通过。缺陷分产品、体验、后勤、测试设施、环境五类，修复前必须归好类。 四、工作流程。盘点、测试、修复、重测四步，每个通过行都要求当前会话中的新证据。
必要用法：多数运行采用 plan_first；仅当应用边界、可写检出版本、生产风险或验收标准不清晰时才用 clarify_first。操作前先做仓库状态快照（路径、分支、最新远端、脏文件、相关开放 PR），读取 AGENTS.md、README、架构文档和功能入口，并先搜索是否已有 QA 追踪表。编辑生产代码前先选模式：report_only 为默认，可用于审计、盘点、测试、诊断或建表请求，可创建或更新追踪表、运行测试，但不得改变产品行为；apply_fixes 需要当前请求明确要求修复，且只覆盖已复现并分类的缺陷。模式不明确时用 report_only 并在表中记录拟修复项。
限制：不得创建零散笔记或重复追踪表；不得从产品愿望臆造预期行为，预期行为须来自当前代码、文档和可见用户面；不得用过期输出标记通过；不得擅自"修复"用户环境；不得从 audit、test、check、create a tracker 等词推断出修复授权。测试生产系统、使用付费外部服务、更改凭证或部署状态、删除用户数据、扩大应用边界前须上报。不得削弱断言以让测试通过，同一缺陷三次失败后停止并重新评估。完成前需保证每行都有用户故事、预期行为、代码锚点和状态，每个失败行在 report_only 下须明确记录为拟修复、超范围或有证据的阻塞，每个已应用修复都有重测结果，且追踪表结构可校验；最终回答需说明追踪表路径、改动文件、发现的缺陷、修复与验证命令。