# Test Routing Advisor

> 测试路由顾问：在某个 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 来保证。

- Skill: `fufankeji/test-routing-advisor` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add fufankeji/test-routing-advisor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fufankeji/test-routing-advisor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: fufankeji (https://skillmd.com/u/fufankeji)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fufankeji/test-routing-advisor

---


# 测试路由顾问（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 旅程不标，防
     过度测）；要把失败定位到旅程步骤、并落实"首现即回补下层"安全网语义才标⑤可追溯·安全网定位。命中
     规则见 `tool-mapping.md` 的「条件命中」表。
5. **状态标注**，给每条推荐都打上：
   - ✅ 已被 CI 闸 / superpowers/spec-kit 流程自动覆盖 / 执行器 skill 已建
   - ⚠️ 需人工决策
   - 🔍 需新调研（含路由去向仍为占位·待建的类别）
   - 🔧 结构性缺口（路由到对应类别 skill 闭环补测）；并注明现成 ✅ / 需自建 🔧（栈无关判定）

报告结尾附上那句边界提醒：*本报告只做判类与路由；具体工具由对应类别 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 按栈执行。