当 .NET 测试项目被解决方案筛选器/CI…

在 .NET 仓库中创建缺失的测试项目，或仅修复其缺失的 ProjectReference 与 .sln/.slnx/.slnf 注册，使 CI 的真实构建入口能发现测试。

适用场景

解决思路

1. 在任何其他发现之前，先检查仓库根目录的 .agents/skill-overlays/dotnet-test/scaffold-dotnet-test-project.md；若存在则读取一次并应用其仓库特定的命名、布局、框架与策略绑定。
2. 应用 overlay 前要求其 frontmatter 声明 core: dotnet-test/scaffold-dotnet-test-project、binding-revision: "1"、mode: extend；任一缺失或不符则报告不匹配并继续使用本技能的通用指导，不应用 overlay。
3. 若 overlay 存在但不可读或与仓库冲突，报告问题并继续使用通用指导；若不存在则正常继续；仅当任务不绑定仓库或用户明确禁止所有文件/工具访问时才跳过查找。
4. 编辑前先检查仓库，然后严格选择一条路径：无合适测试项目则创建一个有界项目、引用生产项目并注册；测试项目存在但缺少所需 ProjectReference 则只添加该引用并验证直接执行与入口点执行；测试项目直接通过但不在 .sln/.slnx/.slnf 中则把现有项目注册到 CI 使用的确切入口点；项目、引用与入口点都已正确则保持工作区不变。
5. 若合适的项目、生产引用与请求的入口点注册都已存在，则做零文件改动：不添加或删除冒烟测试、不规范化项目、不重建包、不编辑基线/快照副本，报告现有路径后停止。
6. 从任务当前工作目录开始；技能上下文的 Base directory 是指令所在处而非用户仓库；不要搜索父级临时目录或把技能安装目录当作工作区；若看不到预期文件，先确认当前目录再断定项目缺失。
7. 把每个编辑与验证命令锚定到用户指定或从当前目录确立的仓库路径；若存在同名 fixture、解决方案或复制树，不要编辑或验证它们来替代请求的树。
8. 更改解决方案产物前记录其确切路径；更改后立即列出同一产物并要求测试项目出现后再继续。
9. 只读取足够信息以确定：生产项目与请求的测试范围；CI 使用的命令与 .sln/.slnx/.slnf 或项目图；是否存在合适测试项目、它引用什么、注册在哪里；邻近测试框架、运行器、目标框架、nullable 与 implicit usings 约定；包或 SDK 版本是否来自 Directory.Packages.props、Directory.Build.props、global.json 或 MSBuild SDK 声明。
10. 若用户报告测试项目直接通过但解决方案级发现为零，将其视为注册证据，在考虑创建项目之前先检查入口点。
11. 仅在项目缺失时创建：为最窄的请求生产项目选择一个测试项目，按顺序遵循用户明确框架选择、邻近测试项目、仓库级包/SDK 约定、标准 SDK 模板。
12. 仅当模板生成的框架代际与包风格匹配仓库契约时才使用 dotnet new 模板；创建前检查模板可用性；注意通用 dotnet new xunit 通常生成 xUnit 2 包，对于集中管理 xunit.v3 的仓库应使用仓库或已安装的 xUnit v3 模板，或直接创建最小 SDK 项目；绝不要先生成带版本的 xUnit 2 引用再改写为 xUnit v3。
13. 创建后：对齐目标框架、nullable、implicit usings、运行器与包风格；仅对请求测试所涉及的生产项目使用 dotnet add <test-project> reference <production-project>；删除模板示例文件如 UnitTest1.cs，然后创建以行为命名的测试文件而不是复用模板文件名；集中包管理提供版本时省略包版本。
14. 对于通过 dotnet test 运行的 xUnit v3 项目，保留或添加 <OutputType>Exe</OutputType> 与 <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport>；仅 OutputType=Exe 只证明自托管运行器路径，不证明仓库 dotnet test 命令能发现。
15. 项目存在时只修复缺失的边：缺少生产引用则用 dotnet add <test-project> reference <production-project>，检查结果项目，保持其他项目元素与所有测试源文件不变，比较前后使添加的 ProjectReference 是唯一语义变更。
16. 缺少 .sln 或 .slnx 注册则运行 dotnet sln <entry-point> add <test-project>，然后立即对同一路径运行 dotnet sln <entry-point> list；若项目缺失则修复未发生，不要验证同级解决方案或报告成功。
17. 缺少 .slnf 注册则必要时把现有项目加入其底层解决方案，然后在筛选器中包含同一项目路径；若底层解决方案已包含它，则只编辑筛选器。
18. 存在多个解决方案产物时只修改用户指定或 CI 调用的那一个，不要替换为更容易的格式；没有解决方案产物则保留现有面向项目的工作流，不要为美观创建解决方案。
19. 对于新建项目，用用户请求的最小冒烟套件替换模板示例；每个测试必须调用真实生产符号并断言具体确定性结果，不依赖网络、挂钟、进程或真实文件系统。
20. 对于现有项目的接线修复，除非用户明确要求测试行为变更，否则不添加、改写、重命名或扩展测试；注册与测试编写是分开的操作。
21. 运行最窄命令证明所选路径：新建项目需 dotnet test <test-project>、CI 使用的确切入口点命令与注册列表，若入口点是包含测试的 .slnf/.slnx 则对其运行 dotnet test 而非只证明能构建；缺少引用需目标项目测试加请求的确切解决方案/根测试命令；缺少 .sln/.slnx 注册需该确切产物的列表与 dotnet test，绝不用另一解决方案兜底；缺少 .slnf 条目需检查筛选器条目并运行确切 CI 筛选器构建命令，不要前置故意失败的替代命令；已正确/无操作则对现有引用与注册做结构检查，除非请求执行否则不要仅为证明无操作而运行测试，因为会创建 bin/obj 并削弱逐字节清洁证据。
22. 添加开关前检查仓库命令；不要前置推测性的 --no-restore 尝试，也不要把替代方案藏在 command-a || command-b 中；运行配置的入口点命令，其干净退出即为证据。
23. 对每次接线修复，直接调用确切验证命令并保留其退出状态；读取生成文件、评分脚本或后续构建不能替代观察该命令成功完成。
24. 报告完成前检查最终变更文件集；仅当 bin/obj 或等价构建产物在任务前不存在且非有意跟踪时，删除本任务创建的这些产物；绝不删除预先存在的产物；保留通过命令的完整结果，以便交接时说明确切入口点与发现的测试数。
25. 对于无操作，检查而非改写并报告现有路径；绿色的 dotnet build 不是测试发现证据；若验证受阻，报告确切失败命令与首个可操作错误；绝不把未运行或失败的命令描述为成功。
26. 交接内容与变更成比例：项目创建/复用/修复需测试项目路径与所选路径；生产引用需被引用的 .csproj 或无需变更的原因；构建注册需确切的 .sln/.slnx/.slnf 条目或项目工作流；测试发现需通过的 harness 级命令与发现的测试。
27. 完成检查：创建前已检查现有项目；只引用并测试请求的生产范围；框架、运行器、目标框架与集中包约定保持完整；新建项目已删除模板示例；仅接线修复时现有测试代码未动；确切仓库入口点能发现并运行测试项目。

适用边界 · 注意事项

• 不要仅用于在已接线的项目中编写测试（应使用 code-testing-agent）。
• 不要用于运行测试、迁移，或在不更改项目或 CI 文件的情况下纠正 MSTest 语法/配置（应使用 writing-mstest-tests）。
• 不要为每个源项目创建一个测试项目，也不要为美观创建解决方案或规范化可工作的文件。