| name | backend-testing |
| description | 单后端闭环测试执行器（stack-agnostic / project-agnostic）。当一个后端 feature 收尾、需要补 superpowers/spec-kit 开发期 TDD 与契约测试覆盖不了的后端结构性测试缺口时使用：先读项目栈 （package.json / pyproject.toml / go.mod / pom.xml 等）按栈实例化对应工具，再针对实际命中的缺口 RED→GREEN 补测并固化为回归。覆盖四类后端结构性缺口——真库数据层/迁移/事务/约束、鉴权与越权 （BOLA/BFLA）、并发/竞态/限频原子性、韧性/故障注入（重试/超时/降级）。触发词：单后端测试 / 后端缺口补测 / backend testing / 真库测试 / 越权测试 / 并发测试 / 韧性测试 / 后端集成测试 / 后端回归补测。遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束（只写 tests/、断言 不可弱化、禁伪造修复、有界重试、产 PR 人审）。被 test-routing-advisor 在判定"单后端"时调用，也可直接触发。 |
backend-testing · 单后端闭环测试执行器
这个 skill 解决什么
开发期 TDD（superpowers）和契约/spec 测试（spec-kit）覆盖的是"功能是否如规约工作"。
但后端有一类结构性缺口，它们不属于单个功能点、而属于系统的运行时性质——真实数据库行为、跨身份的访问控制、并发下的不变量、外部依赖故障时的韧性。这些缺口在开发期 TDD 里几乎不会被自然写到，等到生产事故才暴露。
本 skill 是这些缺口的闭环补测执行器：在一个后端 feature 收尾时被调用（由 test-routing-advisor 路由判定为"单后端"，或直接触发），把命中的结构性缺口用 RED→GREEN 补齐、固化为回归，并按蓝本纳入发布门。
关键洞：code-review ≠ test。代码评审只靠阅读发现问题、不生成可重复运行的回归；评审里"看出并修掉"的缺陷，没有固化成测试就会在下次重构中复发。本 skill 的产物是能再次跑红/跑绿的测试，不是一份评审意见。缺陷固化的方法论可复用 superpowers:test-driven-development 与 superpowers:systematic-debugging。
遵循 testing-system-blueprint 蓝本（按名引用即可）：风险分级排序、可追溯 ID、发布门、三层节奏。
两条绝对约束（先读，贯穿全程）
- stack-agnostic（栈无关）：四类缺口一律用"能力描述 + 按栈实例化 lookup"表达，绝不把某一栈写死为唯一答案。每类能力都给多栈示例，并明确：先读项目栈文件，再实例化该栈对应的工具。项目用什么栈、装什么库，由项目自身决定，本 skill 只提供能力到工具的映射。
- project-agnostic（项目无关）：不出现任何业务名词。允许使用通用后端概念（BOLA / BFLA / 真库 / 迁移 / 事务 / 约束 / 并发 / 竞态 / 限频 / 契约 / 故障注入）。
工作流（六步闭环）
步骤 0 · 识栈
读项目栈文件，确定语言与运行时，后续所有工具选择都基于此实例化：
| 栈线索文件 | 语言/运行时 | 后续工具来源 |
|---|
pyproject.toml / requirements.txt / setup.py | Python | 见各缺口的 Python 行 |
package.json（含 tsconfig.json） | Node / TS | Node 行 |
go.mod | Go | Go 行 |
pom.xml / build.gradle | JVM | JVM 行 |
| 其他 | 按需 | 用"能力"反查该栈生态等价物 |
找不到栈文件就停下来问，别假设。多栈 monorepo 则对被测后端目录就近识别。
步骤 1 · 条件命中（防过度测）
不是四类全测，只对该 feature 实际命中的子集补。逐项判断：
| 缺口 | 命中条件 | 不命中示例 |
|---|
| 真库数据层 | feature 涉及 DB 写入 / 唯一约束·外键·CHECK / schema 迁移 | 纯只读聚合、无迁移 |
| 越权 BOLA·BFLA | 存在多用户对象归属 / 特权（管理员）端点 | 单租户内部工具、无身份隔离 |
| 并发/竞态 | 存在共享资源争用 / 限频 / 配额 / 计数器 / 库存式扣减 | 无共享可变状态的纯函数式处理 |
| 韧性/故障注入 | 调用外部依赖（HTTP API / 第三方 SDK / 消息队列 / 远程缓存） | 纯本地逻辑、无外呼 |
纯逻辑 / 纯读的 feature 很可能只命中 0–1 项——这是正常的，不要硬凑。
步骤 2 · 覆盖区分
对每个命中的维度，先判断它是否已被开发期 TDD/契约测试覆盖，再决定是否补：
✅ 已被开发期 TDD/契约覆盖（跳过）——别重复造。🔧 结构性缺口（待闭环补）——需要本 skill 补。对每个 🔧 再标注实例化方式：
现成工具 ✅ 可装——该栈有成熟库，装上即用。需自建 🔧——该栈无即用方案，按模式自建 fixture/脚手架（越权类几乎总是这种）。
把这一步的结论写成一张小表（维度 / 命中 / 覆盖状态 / 实例化方式），作为后续补测的清单。
步骤 3 · RED→GREEN 闭环补测
对每个 🔧 缺口，逐个走：
- RED：先写会失败的测试，确认它确实跑红（红得有意义——是因为缺陷/未覆盖而红，不是因为测试写错而红）。
- GREEN：让测试跑绿。
- 若缺陷是真实存在的（评审已发现但没固化），按
superpowers:test-driven-development / superpowers:systematic-debugging 修复产品码使其转绿。
- 若只是缺覆盖（行为本就正确），补测后即应为绿，无需改产品码。
- 固化为回归：测试留在
tests/，进入回归集，下次自动跑。
具体工具与代码模式见 references/gaps.md，按步骤 0 识别的栈取对应行。
步骤 4 · 按蓝本归档
每个新增的回归测试：
- 按
testing-system-blueprint 的风险分级排序（高风险缺口优先、优先进发布门）。
- 挂可追溯 ID（关联 feature / 缺口 / 若有则关联缺陷来源）。
- 纳入发布门：明确哪些是阻断发布的（如越权可绕过、约束失效），哪些是告警级。
- 对齐三层节奏（蓝本定义的快/中/慢分层；真库与并发类通常落在较慢层，单测层只放纯逻辑）。
步骤 5 · 交付（产 PR · 人审）
补测以 PR 形式交付，由人审核合并，与蓝本及自愈护栏一致。PR 说明里列出：命中维度、跳过维度及理由、每个新增回归对应的缺口 ID 与风险级别。
四类缺口速览（详见 references/gaps.md）
- 真库数据层 / 迁移 / 事务 / 约束——能力：起真实 DB 容器 + 跑迁移 up/down 往返，断言约束、事务回滚、迁移可逆。
- 鉴权 / 越权 BOLA·BFLA——能力：造两个不同身份/权限的 token fixture，参数化遍历对象级与特权级端点，断言跨身份访问被拒（403/404）。框架无关，几乎总是自建。
- 并发 / 竞态 / 限频原子性——能力：并发打同一端点/资源，断言不变量与原子性（无超卖、无双花、限频准确）。
- 韧性 / 故障注入——能力：拦截外呼注入超时/错误序列，断言重试、超时、降级、熔断按预期生效。
每类都是"能力 + 按栈 lookup"——读栈后实例化对应工具，而不是锁定单一栈。
自愈护栏（不可越过）
补测过程允许有界自动迭代（RED→修→GREEN），但受以下护栏约束：
- 只写
tests/，不改产品码——除非该缺口是评审已确认的真实缺陷且需 GREEN，此时改动须最小、可追溯、并在 PR 中单独说明。默认动作是补测，不是改实现。
- 断言不可弱化——禁止为了让测试转绿而放松断言（如把
403 改成 or 200、把并发不变量删掉）。转绿必须靠正确的产品码或正确的测试，不能靠降低标准。
- 禁伪造修复——不得用 sleep、mock 掉被测逻辑本身、跳过/
skip 标记等手段伪装通过。
- 有界重试升级——自动迭代有上限；连续失败达上限即停止并升级给人，不无限刷。
- 产 PR 人审——所有产物以 PR 交付，人工审核后合并（可 reference 蓝本的审核约定）。
护栏的目的：让闭环可以自动跑，但任何"看起来绿了其实没测到"的捷径都被堵死。
与上下游的关系
- 上游：
test-routing-advisor 判定"单后端"时调用本 skill（也可被用户直接触发）。
- 蓝本：所有归档/分级/发布门/节奏遵循
testing-system-blueprint（按名引用，不在此复制其内容）。
- 方法论复用：缺陷固化与调试复用
superpowers:test-driven-development 和 superpowers:systematic-debugging。
