Organize repository into conventional .NET layout

[thomhurst]

Summary

• organize production projects under src/
• move tests, benchmarks, examples, tooling, scripts, and shared build assets into conventional top-level directories
• update solutions, project references, MSBuild imports, workflows, scripts, documentation, and source-path helpers
• regenerate and accept current snapshot baselines

Why

The repository root contained dozens of project directories, making navigation noisy and obscuring the distinction between product code, tests, tooling, examples, and benchmarks. This adopts a conventional .NET repository layout without changing package or project behavior.

Validation

• dotnet build TUnit.slnx --no-restore — passed (0 errors; 3 existing NU1903 warnings)
• 16 source-generator snapshot suite/TFM runs — passed
• Engine F# and VB TRX tests — passed
• repository validator: 170 XML/MSBuild files, 15 workflows, 17 PowerShell scripts
• git diff --check — passed

[claude]

Code review

Scope note: This PR touches 3,662 files (a full repo reorg into src//tests//benchmarks//examples//tools//eng/), which exceeds gh pr diff's fetch limit and the Files API's 3,000-file cap. Rather than reviewing a partial diff, I checked out the actual PR head commit (34057d1) locally and ran direct verification against the real file tree:

• All ProjectReference paths in the 128 .csproj/.fsproj/.vbproj files resolve to existing files (0 broken).
• All MSBuild <Import> paths across 167 .csproj/.props/.targets files resolve correctly (0 broken) — including cross-directory imports like src/TUnit.Analyzers.Roslyn414/*.csproj → ../../eng/Roslyn.props, which correctly account for the added directory depth.
• TUnit.slnx / TUnit.CI.slnx / TUnit.Dev.slnx project paths are consistently updated to the new layout.
• CI workflows and the execute-pipeline action (dotnet.yml, dotnet-build-different-locale.yml, mock-benchmarks.yml) have working-directory/publish paths updated to match.
• scripts/profile-tunit.ps1 / .sh were adapted correctly — since -Project now accepts a category-relative path (e.g. tests/TUnit.TestProject), the scripts now derive the executable/output name from the path leaf ($ProjectName / PROJECT_NAME) instead of using the raw parameter directly. Good catch on that edge case.
• Git.cs test helpers (TUnit.Core.SourceGenerator.Tests, TUnit.Assertions.SourceGenerator.Tests) were correctly updated from Sourcy.Git.RootDirectory to RootDirectory/tests, and all call sites consistently use the new Git.TestsDirectory member.
• No .received.txt files were accidentally committed (checked per CLAUDE.md rule 2).
• Docs, README.md, CLAUDE.md, and .claude/docs/* / .github/copilot-instructions.md / CONTRIBUTING.md were all updated in lockstep with the new paths, including a new "Repository layout" section explaining the convention.
• Noticed the move also quietly drops a handful of orphaned/duplicate snapshot files (e.g. old AssertionMethodGeneratorTests.Generates*Assertions.*.verified.txt under the pre-existing TUnit.Assertions.SourceGenerator.Tests dir) that were already stale duplicates of the current CharAssertionGeneratorTests.* snapshots at the base commit — this looks like incidental cleanup, not data loss.

I wasn't able to run dotnet build/dotnet restore in this sandbox (SDK 10.0.302 pinned by global.json isn't installed here — closest available is 10.0.301), so I couldn't do a full compile as a final check. Given the path-resolution results above (zero broken references across every MSBuild file in the repo) and the PR description's own validation notes (dotnet build passed, 16 snapshot suite/TFM runs passed, F#/VB TRX tests passed), I'm confident this is a mechanically sound, behavior-preserving move.

No issues found. Checked for bugs and CLAUDE.md compliance.

[chatgpt-codex-connector]

💡 Codex Review

TUnit/tools/TUnit.Pipeline/Modules/GetPackageProjectsModule.cs

Line 20 in 34057d1

SourceProject("TUnit.Assertions.FSharp"),

Use the .fsproj path for F# package

When the release pipeline reaches PackTUnitFilesModule, this entry is turned into src/TUnit.Assertions.FSharp/TUnit.Assertions.FSharp.csproj because SourceProject always appends .csproj. That file does not exist—the project is src/TUnit.Assertions.FSharp/TUnit.Assertions.FSharp.fsproj—so package publishing will fail or skip the F# assertions package instead of packing it.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Follow-up review

Re-checked this PR against the prior review threads.

Codex's P1 finding (F# package would publish the wrong/missing file) is fixed. At the original head (34057d1), GetPackageProjectsModule.cs built project paths with a local SourceProject(name) => new(Path.Combine(sourceDirectory, name, $"{name}.csproj")) helper, which is wrong for TUnit.Assertions.FSharp (a .fsproj) — PackTUnitFilesModule would have resolved a non-existent TUnit.Assertions.FSharp.csproj and silently skipped/broken that package.

Commit dd8e417 ("fix: restore Sourcy project discovery") replaces the whole hand-rolled string-concatenation helper with generated Sourcy.DotNet.Projects.* members (via new Sourcy.DotNet/Sourcy.Git package references in TUnit.Pipeline.csproj). I confirmed Sourcy.DotNet.Projects.TUnit_Assertions_FSharp now resolves from the real file on disk (src/TUnit.Assertions.FSharp/TUnit.Assertions.FSharp.fsproj), so this isn't a one-off patch — it removes the whole class of "assume .csproj" bugs, since extensions now come from actual discovered files instead of a naming convention. Good architectural response to the finding rather than a narrow fix.

The same commit adds empty .sourcyignore markers under .claude/ and tests/TUnit.Templates.Tests/Snapshots/, which per the commit message keeps generated Sourcy identifiers stable by excluding agent worktrees and template-test fixture trees (which contain project-like files) from discovery — reasonable given the new reliance on Sourcy for package paths.

Nothing else outstanding. Verified no other spot in tools//eng/ still does manual $"{name}.csproj"-style path construction that could hit the same bug.