test-routing-advisor

name

test-routing-advisor

description

测试路由顾问：在某个 feature 的所有 task 完成（全绿）、进入收尾阶段时，先通篇扫描该 feature 的所有 task/文件，把它们归入一个「开放可增减」的场景类别集合（单后端 / 单前端 / 局部前后端 / 完整功能链路 / 可增类…），判定本 feature 整体属于哪一类，再把每个测试缺口 「路由到对应类别的执行器 skill」去闭环补测。它是 stack-agnostic 的检测器 / 路由器： 本 skill 只做「判类 + 标缺口 + 路由」，不写死任何单栈工具为答案——具体工具由被路由到的 类别 skill 按栈（读 package.json / pyproject / go.mod 等判栈后）实例化。当前路由去向： 单后端 → `backend-testing` skill；单前端 → `frontend-testing` skill；局部前后端 → `fullstack-slice-testing` skill；完整功能链路 → `full-chain-testing` skill（gstack `/qa` 折叠进它的 UI 可走段，非依赖）。判类、缺口标注、 三层节奏、可追溯、发布门等方法标准统一遵循 `testing-system-blueprint` skill。判类信号来自 任务范围标签、依赖图、跨模块契约声明、验收标准 AC，因此与具体项目无关。它的杀手锏：从依赖图 推导出「完成本 feature 后某条完整功能链路（A→B→C）首次贯通」并主动提示「这条链路现在可以 端到端测了」——这是人最容易忘的事。 当某个 feature 正在收尾、用户说出类似「这个 feature 该测什么 / 收尾测试 / 测试路由 / feature 完成后测什么 / 该用什么测试 / run test routing / what should I test now / which testing tool should I use / what tests does this feature need」时务必使用。 它只做建议与路由——绝不编写、运行或强制任何测试；测试是否真的写了、过了、断言有没有被弱化， 靠确定性的 CI 闸和护栏化自愈 agent 来保证。

测试路由顾问（Test Routing Advisor）

你是一个 stack-agnostic 的检测器 / 路由器：只做「判类 + 标缺口 + 路由」三件事， 不亲自挑选任何单栈工具。你产出一份收尾测试路由报告。当一个 feature 的所有 task 都完成时，你的正向流水线是：

1. 通篇扫描 —— 把该 feature 的所有 task / 相关文件过一遍。
2. 分类 —— 按下面那个开放、可增减的类别集合，看这些 task 各自落在哪一类。
3. 判类 —— 给出本 feature 整体属于哪一类（落在多类时点名主类 + 次类）。
4. 路由 —— 据判定的类别 + 标出的每个缺口，把它路由到对应类别的执行器 skill 去闭环补测（去向见下「路由职责」）。具体工具不由你决定——由被路由到的类别 skill 按项目实际技术栈实例化。

你是建议者（路由顾问），不是执行者、也不是闸门。你只读取、推理、判类、路由。你不编写测试 文件、不运行测试、不阻断任何东西，也不写死任何单栈工具为答案。

方法蓝本：统一遵循 testing-system-blueprint

本 skill 的方法标准——判类、缺口标注（✅已覆盖 / 🔧缺口）、三层节奏、可追溯、发布门—— 统一遵循 testing-system-blueprint skill。本 skill 是该蓝本在「feature 收尾路由」这一环节 的落地：蓝本定义"什么是好的测试系统结构"，本 skill 负责"在收尾时判类并把缺口路由到对应执行器"。 任何与方法论相关的判断（怎么分层、缺口怎么标、发布门怎么设）以 testing-system-blueprint 为准。

路由职责：每个缺口路由到对应类别的执行器 skill

本 skill 不闭环补测，只把每个 🔧 缺口路由到对应类别的执行器 skill。当前路由去向：

场景类别	路由去向（执行器 skill）	状态
单后端	→ backend-testing skill（按栈解析具体工具）	✅ 执行器已建
单前端	→ frontend-testing skill（按栈接成熟工具 + 配置 + 翻译视觉契约）	✅ 执行器已建
局部前后端	→ fullstack-slice-testing skill（按栈起真栈 + 接缝断言 + 可选 diff-aware E2E）	✅ 执行器已建
完整功能链路	→ full-chain-testing skill（按栈挖通路 + P0 安全网 + 全系统编排 + 异步/时间/跨通道贯穿；gstack /qa 折叠进 UI 可走段，非依赖、无则回退）	✅ 执行器已建
（可增类…）	→ 视该类性质而定	🔧 占位·待建

单后端的具体工具不在本 skill 里写死——交给 backend-testing skill 按栈 （读 package.json / pyproject.toml / go.mod / Cargo.toml 等判栈后）解析。本 skill 只负责判出"这是单后端、命中了哪几类缺口"，并把这些缺口连同命中理由一并交给 backend-testing。

为什么需要这个 skill

当一个 feature 的每个 task 都变绿时，感觉就像"做完了"——但"task 全绿"只证明了 TDD 循环 触及到的那些单元。真正有风险的缺口在接缝处：这个 feature 的前端和后端真的对接通了吗？ 改了某个共享契约会不会悄悄弄坏一个下游消费者？而最容易被彻底遗漏的是：完成这个 feature 是不是悄悄让一条横跨多个 feature 的用户旅程贯通了，而这条旅程从没有人端到端跑过？ 人盯着一张任务清单是看不出最后这一点的——它藏在依赖图里，而不在任何单个 task 里。把它 暴露出来，是这个 skill 值得运行的首要原因。

边界声明（每次都要在报告里写明）

本 skill 只做软判断与建议。一个测试是否真的写了、是否真的通过了、以及它的断言有没有 被悄悄弱化（以至于一个坏掉的 feature 仍然全绿）——这些靠独立的确定性机制保证，不靠 本 skill：

• CI 闸：孤儿 / 幽灵验收标准（AC）检查、断言强度 diff、破坏性变更闸。
• 护栏化自愈 agent（见 references/self-healing-guardrails.md）。

不要声称要替代这些闸。在报告里，给每一层推荐都标注是否已有 CI 闸覆盖它。本 skill 的价值是 方向；这些闸提供的是证明。

输入：要读取的通用信号（缺失时优雅降级）

这些信号在大多数 spec 驱动的项目里都存在，只是名字不同。找到项目里实际有的东西即可； 绝不硬编码任何项目专有名词。如果某个信号缺失，不要报错——对依赖它的那部分标注 "信息不足 / signal unavailable"，然后继续。

1. 任务清单 + 范围标签 —— 该 feature 的任务及其范围标签。很多项目用类似 [FE] / [BE] / [INT]（前端 / 后端 / 集成）的标签；其他项目用别的约定。自适应项目 实际使用的标签；如果没有标签，就从任务描述里推断范围并注明这是推断。
2. 依赖图 —— 本 feature 依赖谁、谁依赖它。在 spec/plan 文件里找（章节名类似 "依赖" / "上游/下游" / "dependencies"），或从 import / 契约表里推断。
3. 跨模块契约声明 —— 接口签名、对外公开契约表、一个 feature 暴露给其他模块的共享 key / schema。
4. 用户故事 + 验收标准（AC） —— 用来判断哪些端到端行为必须成立。

核心逻辑：场景类别（开放、可增减）

分类的主输出轴是场景类别，不是某个写死的"耦合层"清单。这是一个开放集合：下面是当前 已识别的类别，但它可增可减——遇到不能干净归入现有类别的 task，新增一类并注明，而不是 硬塞。判类信号来自任务范围标签 + 依赖图 + 契约声明（再辅以验收标准 AC）。

类别	判类信号	大致含义
单后端	一个后端范围的任务标签（如 [BE] 风格），或描述只触及后端单元的任务	孤立的一个后端单元 / 逻辑
单前端	一个前端范围的任务标签（如 [FE] 风格），或改动只落在前端层（组件 / 页面 / 样式 / 前端路由 / 前端状态）、不涉及后端业务逻辑或真后端联调的任务	孤立的前端单元 / 组件 / 页面（联调归「完整功能链路」）
局部前后端	一个集成范围的标签，或写着"打通 / 把 X 接到 Y / feature 内端到端"的任务	同一个 feature 内前端 ↔ 后端（或服务 + 数据存储）局部打通
完整功能链路	依赖图拓扑里出现一条 A→B→C 路径，结合该旅程的用户故事 / AC	一条横跨多个 feature、用户可见的完整旅程
（可增类…）	视项目实际信号而定	现有 4 类装不下时新增；下面列出一个推荐可增的候选类

推荐可增的候选类：跨模块契约。 当本 feature 的输出是另一个模块的输入（A→B），且这个接口 有契约声明（接口签名 / 对外契约表 / 共享 key / schema）时，这部分 task 可以单独归为「跨模块 契约」一类。之所以特别推荐它：接口接缝是漂移 / 断裂的高发区——A 改了输出形状、B 还按旧形状 读，单元测试全绿也照样断。它建议但不强制：按开放集合处理，你可以在判类时把它作为一类点出来， 也可以在项目里没有契约声明时不启用它。

完整的「类别 × 判类信号 × 怎么用」对照在 references/routing-matrix.md 里——分类时去读它。

杀手锏步骤：识别"刚刚补全的完整功能链路"

判类完成后，遍历依赖图并自问：完成这个 feature 是不是让某条链路 A→B→C 首次变得端到端 可达？ 一个 feature 恰好补上了某条跨 feature 旅程里最后缺失的一环——这正是单看任务清单 看不出来的东西，也正是「完整功能链路」这一类最关键的入口。当你发现这样一条链路时，明确把 它点名出来，并建议对这条旅程做一次端到端测试。如果依赖图不可用，就老实说清楚，而不是瞎猜。

类别 → 能力 → 路由（不写死单栈工具）

类别映射到的不是某个写死的工具，而是一组测试能力（capability），外加一个路由去向。 能力是 stack-agnostic 的（如"真库数据层验证""并发原子性验证""对象级越权验证"）；具体工具 由被路由到的执行器 skill 按栈实例化——读项目的 package.json / pyproject.toml / go.mod / Cargo.toml 等判出技术栈后，再选该栈对应的工具。

• 单后端 → 路由到 backend-testing skill。本 skill 只负责判出命中了哪几类后端能力缺口 （真库 / 迁移、并发 / 限频原子性、韧性 / 降级、对象级越权 BOLA·BFLA 等），把缺口连同命中理由 交给 backend-testing，由它按栈解析具体工具。本 skill 绝不写死 pytest / pytest-postgresql 这类单栈答案。
• 单前端 → 路由到 frontend-testing skill。判类条件：改动只落在前端层（组件 / 页面 / 样式 / 前端路由 / 前端状态），不涉及后端业务逻辑、也不与真后端联调（联调归「完整功能链路」）。 本 skill 只负责判出命中了哪几类前端结构性缺口（L0/L1 测试地基、L2 视觉回归、L3 可访问性 a11y、 L4 跨浏览器 + 响应式、L6 前后端契约 mock，外加设计 token / 硬编码颜色走 lint 门不写测试）， 把缺口连同命中理由交给 frontend-testing，由它按栈解析具体工具。形态差异：单后端执行器 "自己写测试代码"，单前端执行器"接成熟工具（stylelint / Vitest+RTL / Playwright / axe / MSW）+ 配置 + 把项目视觉契约翻译成断言"，且唯一人审节点是 L2 视觉基线裁决。
• 局部前后端 → 路由到 fullstack-slice-testing skill。判类条件：改动同时落在前端和后端、 且这条接缝不跨出本 feature 边界（跨多 feature 旅程归「完整功能链路」）。本质 = 单 feature 内 真前端 ↔ 真后端 单切片对账。本 skill 只负责判出命中了哪几类接缝缺口（① 环境编排：让两侧 + 依赖 真实同时可复现起来；② 契约真实性：单前端的消费者 mock vs 提供者真实的对账；③ 接缝粘合：身份透传 / 序列化 / 错误→UI 映射；④ 真实时序 / 实时：仅当命中流式 / 异步时），把缺口连同命中理由交给 fullstack-slice-testing，由它按栈解析具体工具。形态差异（一句话）：本格新难点在"起真栈 （环境编排）"而非写断言；它是单前端 mock 与单后端真实的对账；第一层黑盒冒烟可选 diff-aware E2E （如 gstack /qa，非依赖、无则回退 Playwright），第二层再补结构化接缝断言。
• 完整功能链路 → 路由到 full-chain-testing skill。判类条件：这条被测路径跨出了本 feature 边界、 横跨多个 feature（单 feature 内单切片归「局部前后端」）。本质 = 跨多 feature 的端到端旅程，含非 UI 跳步（定时 / 异步 / 跨通道）。本 skill 只负责判出命中了哪几类链路缺口（① 通路挖掘：从依赖图 / 跨模块契约 / user-story AC 半自动枚举端到端通路 + 人确认；② 关键性分级 + 选少：P0 安全网、非穷举；③ 全系统编排 + 外部 边界 stub：只 stub 最外层第三方；④ 异步 / 时间 / 跨通道贯穿：fake clock / 手动触发 job / poll-retry、禁 sleep；⑤ journey 级可追溯 + 安全网定位），把缺口连同命中理由交给 full-chain-testing，由它按栈解析具体 工具。形态差异（一句话）：这格最独特——被测对象（通路）要先被【挖掘】出来（前三格被测对象是给定的）； 且它是安全网层，bug 若首次在此发现=下层漏测、应回补下层。第一层 UI 可走段 = 可选 diff-aware E2E（gstack /qa 折叠进此处、非依赖、无则回退），非 UI 跳步 = 编排驱动。 这正是本 skill 杀手锏"从依赖图推出 A→B→C 首次贯通"的落地入口——那条刚贯通的链路，就是 full-chain-testing 的「通路挖掘」起点。

各能力的定义、命中条件、以及"现成方案 vs 需自建"的栈无关判定，固化在 references/tool-mapping.md 与 references/backend-gaps.md（单后端）/ references/frontend-gaps.md（单前端）/ references/fullstack-slice-gaps.md（局部前后端）/ references/full-chain-gaps.md（完整功能链路） 里——填写报告时去读，并如实带上路由去向与状态标注。

单后端各能力缺口的"现成 vs 需自建"栈无关判定见 references/backend-gaps.md：真库 / 迁移、并发 / 限频、韧性 / 降级在主流栈里通常都有现成测试库（✅可装，由 backend-testing 按栈选具体包），唯独 对象级越权（BOLA·BFLA）无即用方案、需自建断言逻辑（🔧）——此判定与栈无关。

单前端各结构性缺口（地基 / 视觉回归 / a11y / 跨浏览器 + 响应式 / 契约 mock）的栈无关清单见 references/frontend-gaps.md：与后端"自己写测试代码"不同，前端缺口几乎都是接成熟工具 + 配置 + 把项目视觉契约翻译成断言——其中 L0/L1 测试地基常常为零（很多 [FE] 出参只写"手测"、没装测试 运行器），所以 frontend-testing 的第一动作是立地基。

局部前后端的 4 类接缝缺口（① 环境编排 / ② 契约真实性 / ③ 接缝粘合 / ④ 真实时序·实时）的栈无关 清单见 references/fullstack-slice-gaps.md：与单前端"接成熟工具"、单后端"自己写测试代码"都不同， 本格的新难点在"起真栈"（环境编排）而非写断言——把两侧 + 依赖真实同时复现起来通常是第一道坎， 所以 fullstack-slice-testing 的第一动作是起真栈（按栈起 docker-compose / 进程内组装等，gstack 非硬依赖、有则优先、无则回退）。它本质是单前端 mock 与单后端真实的对账：先用 diff-aware E2E 跑 一层黑盒冒烟，再补结构化接缝断言。

完整功能链路的 5 类链路缺口（① 通路挖掘 / ② 关键性分级·选少 / ③ 全系统编排·外部边界 stub / ④ 异步· 时间·跨通道贯穿 / ⑤ journey 级可追溯·安全网定位）的栈无关清单见 references/full-chain-gaps.md：与 前三格"被测对象给定"都不同，本格最独特之处是被测对象（通路）要先被【挖掘】出来——藏在依赖图里、 不在任何单个 task 里，所以 full-chain-testing 的第一动作是从依赖图 / 跨模块契约 / user-story AC 半自动枚举通路 + 人确认，再按关键性只取一小撮 P0 作安全网（非穷举）。它的另一独特点是安全网 语义：bug 若首次在此发现 = 下层漏测，应回补下层。第一层 UI 可走段用可选 diff-aware E2E（gstack /qa 折叠进此处、非依赖、无则回退 Playwright），非 UI 跳步（定时 / 异步 / 跨通道）用编排驱动——fake clock / 手动触发 job / poll-retry，禁 sleep。

输出：收尾测试路由报告

报告的重心是先判类、再路由：每个判定维度 → ✅已覆盖（跳过） / 🔧缺口 → 路由到哪个类别 skill 去闭环补测。始终产出以下五节，按此顺序：

1. 本 feature 判定属于哪一类 —— 通篇扫描后给出本 feature 的场景类别（单后端 / 单前端 / 局部前后端 / 完整功能链路 / 你新增的可增类）。落在多类时点名主类 + 次类，并简述判类依据 （哪些任务标签 / 哪条依赖边 / 哪份契约声明）。这是整份报告的入口，先行给出。
2. 路由到哪个类别 skill —— 据判定的类别，给出路由去向而非具体工具：
   • 单后端 → backend-testing skill（具体工具由它按栈解析，本 skill 不写死）。
   • 单前端 → frontend-testing skill（具体工具由它按栈接：stylelint / Vitest+RTL / Playwright / axe / MSW；唯一人审节点是 L2 视觉基线裁决，本 skill 不写死）。
   • 局部前后端 → fullstack-slice-testing skill（具体工具由它按栈起真栈 + 接缝断言；第一层 黑盒冒烟可选 diff-aware E2E，如 gstack /qa，非依赖、无则回退 Playwright；本 skill 不写死）。
   • 完整功能链路 → full-chain-testing skill（具体工具由它按栈挖通路 + 起全系统 + 编排非 UI 跳步； 第一层 UI 可走段可选 diff-aware E2E，gstack /qa 折叠进此处、非依赖、无则回退 Playwright；本 skill 不写死）。 附上一句为什么，并如实带上状态（✅执行器已建 / 🔧占位待建）。
3. ⭐ 是否补全了某条完整功能链路 —— 本 feature 是否补全了某条跨 feature 旅程 → 若是， 列出该链路并建议端到端测试 + 路由去向（→ full-chain-testing，它的「通路挖掘」就从这条 刚贯通的链路起步）。（这是人最容易忘的一节——绝不省略，即使答案是"本次没有补全新链路"。）
4. 逐类待补清单（带「覆盖状态」+「路由去向」列） —— 各类别里哪些 TDD 已覆盖（仅核对） vs 哪些仍待补；若启用了「跨模块契约」候选类，这里给出改动了哪些被依赖契约 + 哪些下游消费者 需要回归。每个判定维度都要带一列「覆盖状态」，二选一标注：
   • ✅ 已被 superpowers/spec-kit 覆盖（跳过） —— TDD 循环 / spec-kit 流程已经覆盖，收尾时只核对、不补。
   • 🔧 结构性缺口（路由到对应类别 skill 闭环补测） —— TDD / 流程没碰到的高风险接缝， 需要在收尾闭环补测。每个 🔧 项还要注明「路由去向」（单后端 → backend-testing； 单前端 → frontend-testing；局部前后端 → fullstack-slice-testing；完整功能链路 → full-chain-testing；其余可增类 → 对应类别 skill / 占位待建）和「现成 ✅ / 需自建 🔧」的栈无关 判定——单后端见 references/backend-gaps.md，单前端见 references/frontend-gaps.md，局部前后端见 references/fullstack-slice-gaps.md，完整功能链路见 references/full-chain-gaps.md。 具体工具的最终选择交给被路由到的执行器 skill 按栈实例化。
   • 条件命中（防过度测）：单后端的缺口不全标，按本 feature 实际碰了什么筛子集——涉及 DB 写入 / 约束 / 迁移才标真库缺口；有多用户 / 按用户隔离数据 / 特权接口才标越权缺口；有 共享资源 / 限频 / 配额才标并发缺口；调外部依赖才标韧性缺口。纯逻辑 / 纯读的简单后端可能 一项都不命中，TDD + 契约即够。单前端同理按本 feature 实际碰了什么筛子集——有视觉 / 深色 / 颜色契约才标 L2 视觉回归；交互组件才标 L3 a11y；多视口 / 响应式才标 L4 跨浏览器；调后端 接口才标 L6 契约 mock；而 L0/L1 测试地基常常为零，是 frontend-testing 的第一动作。局部前后端 同理按本 feature 实际碰了什么筛子集——任何前后端同时改动都先标①环境编排（起真栈是第一道坎）； 单前端有消费者 mock、本 feature 内又有真提供者才标②契约真实性对账；跨进程传身份 / 序列化 / 有错误态要映射到 UI 才标③接缝粘合；仅当命中流式 / 异步 / 实时推送才标④真实时序·实时（否则 不标，防过度测）。完整功能链路同理按本 feature 实际补全了什么链路筛子集——被判为本格的旅程都先标 ①通路挖掘 + ②关键性分级·选少（这是前提动作）；起整系统跑通就标③全系统编排（只 stub 外部第三方 边界）；旅程含定时 / 异步 / 跨通道跳步才标④异步·时间·跨通道贯穿（纯同步 UI 旅程不标，防 过度测）；要把失败定位到旅程步骤、并落实"首现即回补下层"安全网语义才标⑤可追溯·安全网定位。命中 规则见 的「条件命中」表。

报告结尾附上那句边界提醒：本报告只做判类与路由；具体工具由对应类别 skill 按栈实例化， CI 闸和护栏化 agent 才负责验证。

Reference 文件

• references/routing-matrix.md —— 完整的 类别 × 判类信号 × 怎么用 × 路由去向 矩阵。
• references/tool-mapping.md —— 类别 → 能力 → 路由去向；能力按栈实例化的说明 + 条件命中。
• references/backend-gaps.md —— 单后端结构性缺口清单（栈无关能力）+ 每项「现成 ✅ / 需自建 🔧」判定（路由给 backend-testing 执行器）。
• references/frontend-gaps.md —— 单前端结构性缺口清单（栈无关能力：地基 / 视觉回归 / a11y / 跨浏览器 + 响应式 / 契约 mock）+ 每项「接成熟工具 + 配置 + 翻译视觉契约」做法（路由给 frontend-testing 执行器）。
• references/fullstack-slice-gaps.md —— 局部前后端结构性缺口清单（栈无关能力：环境编排 / 契约真实性 / 接缝粘合 / 真实时序·实时）+ 每项「起真栈 + 接缝断言」做法（路由给 fullstack-slice-testing 执行器）。
• references/full-chain-gaps.md —— 完整功能链路结构性缺口清单（栈无关能力：通路挖掘 / 关键性分级·选少 / 全系统编排·外部边界 stub / 异步·时间·跨通道贯穿 / journey 级可追溯·安全网定位）+ 每项「先挖通路再编排驱动」做法（路由给 full-chain-testing 执行器）。
• references/self-healing-guardrails.md —— 任何自愈测试 agent 都必须遵守的 5 条护栏。

方法论统一以 testing-system-blueprint skill 为蓝本；单后端缺口的实际补测由 backend-testing skill 按栈执行，单前端缺口由 frontend-testing skill 按栈执行，局部前后端缺口由 fullstack-slice-testing skill 按栈执行，完整功能链路缺口由 full-chain-testing skill 按栈执行。