用途
Test Placement Advisor 用于解决 RHDH 动态插件生态中的一个具体问题：一项变更、缺陷修复或新功能，究竟应该在哪个仓库、哪一测试层级、哪个文件位置进行测试，以及如何创建该测试。其指导规则是：选择能够真正捕获该 bug 的最廉价环境。技能指出，大多数插件验证并不需要集群，而且越来越多的情况也不需要 Docker。
何时使用
- 新增插件、插件版本升级或插件配置变更需要测试覆盖时。
- 某个 bug 逃逸到了集群 e2e 运行，团队希望改用更廉价的回归测试时。
- 审查一个在错误层级添加了测试的 PR 时（例如为纯 UI 逻辑添加集群 e2e）。
主要能力
步骤一：收集上下文
在推荐之前，需明确：被验证的内容是什么（插件逻辑/UI 组件、打包/发布产物、插件在 RHDH 内的加载/渲染、平台行为如 Helm/Operator/ingress/auth）；变更发生在何处（插件源码、打包元数据、RHDH 应用本身）；是否需要渲染 UI；是否需要真实外部服务（GitHub、Keycloak、LDAP、托管数据库）；是否需要集群基础设施（ConfigMap 重载、路由、operator、pod 日志、端口转发）。
步骤二：决策表
技能提供了一张决策表，将开发者想要验证的内容映射到仓库、测试类型/工具链，以及是否需要集群或 Docker。例如：插件逻辑/组件/API 对应 rhdh-plugins 仓库的单元+组件测试（不需要集群和 Docker）；插件能否作为动态插件构建对应 npx @red-hat-developer-hub/cli plugin export；发布的 OCI 产物安装与后端插件启动对应 rhdh-plugin-export-overlays 的原生 smoke 测试；插件在真实 RHDH 应用中加载并渲染 UI 对应 rhdh 的免集群 E2E；RHDH 容器行为对应 Docker smoke；Helm chart/Operator/ingress/真实 Keycloak/OCP 上的 RBAC 对应集群 e2e。概括规则为：源码 bug → rhdh-plugins；产物 bug → overlays；集成/渲染 bug → rhdh；平台 bug → 集群 e2e。
步骤三：层级阶梯
从最廉价到最昂贵排列：L1 单元（Jest/Vitest，无集群，毫秒到秒级）、L2 集成（startTestBackend + supertest）、L3 组件（RTL + 开发服务器）、L4a 免集群 E2E（Playwright + 本地 harness）、L4b 完整 E2E（Playwright + 集群）。
步骤四：如何创建测试
针对每个位置给出具体说明，包括路径、模板文件、运行命令、已知限制等。例如 rhdh-plugins 的测试位于 plugins: workspaces/<workspace>/plugins/<plugin>/src/**，参照邻近的 *.test.ts(x) 模式；overlays 原生 smoke 测试位于 overlays: smoke-tests-native/，通过编写 dynamic-plugins.yaml 列出 oci:// 产物引用来验证；rhdh 的 L1–L3 参照 rhdh: docs/testing.md。
步骤五：编写测试
强调通过镜像真实文件而非凭记忆编写，因为 Backstage 测试接口会变化（例如 @backstage/test-utils 已改名为 @backstage/frontend-test-utils）。要求打开模板完整阅读后再改编，并在报告完成前运行测试。同时说明 Codecov 在两个仓库中为 informational: true，没有覆盖率阈值，仅以覆盖率差值为理由的测试会在审查中被拒绝。
已知无法实现的事项
技能列出了经过调研、当前不可行的事项：在没有 RHDH 应用的情况下渲染前端动态插件；为当前插件使用 @backstage/frontend-dynamic-feature-loader；在最小化 startTestBackend 中运行扩展 catalog 的模块。
输出格式
要求给出具体建议：仓库、层级/工具链、位置、脚手架步骤、为什么不在别处、成本（大致反馈时间）。
限制与注意事项
技能中的部分 harness 仍在审查中，在推荐特定 harness 或脚本前需验证其路径是否存在于目标仓库 main 分支；若不存在，应告知开发者该功能在对应 PR 中待合并，而非断言其存在。路径以仓库前缀标识：rhdh:、overlays:（= rhdh-plugin-export-overlays）、plugins:（= rhdh-plugins）。部分参考资料仅存于 Jira。