0.3.3: affected tests handle non-C# changes; docs match the code

CHANGELOG.md

@@ -3,6 +3,25 @@
 All notable changes to DotNetDevMCP are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow [SemVer](https://semver.org/).
 
+## [0.3.3] - 2026-09-24
+
+Prompted by an external evaluation; each claim was checked against the code first.
+
+### Fixed
+- `dotnet_test_affected`: a change to a file the reference walk can't trace (a `.csproj`, `.razor`, `appsettings.json`,
+  resources, or a deleted `.cs` file) returned "No changed .cs files" and ran nothing. It now runs the test projects that
+  reference the project holding the file, and lists the file in `untracedFiles`. A changed `.props`, `.targets`,
+  `global.json`, `nuget.config` or `.editorconfig` runs the whole solution. Documentation files and files outside every
+  project (CI workflows) are still ignored.
+
+### Documentation
+- Removed `docs/architecture/system-overview.md`, which described components that were never built (`MergeAnalyzer`,
+  `CodeReviewEngine`, `AgentCoordinator`, `DependencyAnalyzer`...). The wiki's Architecture page describes the code as it is.
+- The BenchmarkDotNet suite now says what it measures: orchestration overhead with simulated work, not Roslyn or test runs.
+- README: known gaps list the NuGet package reference gap and the lack of a sandbox; a test confirms calls through an
+  interface or base class are followed. New "Using it at work?" line.
+- CONTRIBUTING no longer points at a `docs/ai-context` file that doesn't exist.
+
 ## [0.3.2] - 2026-09-24
 
 Security release, prompted by two external reviews; each claim was checked against the code first. Upgrade from 0.3.0/0.3.1.

CONTRIBUTING.md

@@ -97,10 +97,8 @@ public class FeatureTests
 **Required documentation updates:**
 
 1. **Code Comments**: XML docs for public APIs
-2. **AI Context**: Update `docs/ai-context/project-context.json`
-3. **Architecture**: Update relevant docs in `docs/architecture/`
-4. **ADRs**: Create ADR for significant architectural decisions
-5. **README**: Update if adding major features
+2. **ADRs**: Create an ADR in `docs/architecture/adr/` for significant architectural decisions
+3. **README and wiki**: Update if you add or change a tool, a parameter or a behavior users can see
 
 ### 5. Test Your Changes
 
@@ -335,14 +333,6 @@ What is the change we're proposing?
 What becomes easier or more difficult?
 ```
 
-### AI-Friendly Documentation
-
-Update `docs/ai-context/project-context.json` when:
-- Adding new features or layers
-- Making architectural changes
-- Changing design decisions
-- Updating dependencies
-
 ## Pull Request Process
 
 1. **Self-Review**: Review your own code first

Directory.Build.props

@@ -9,10 +9,10 @@
     <NoWarn>$(NoWarn);CS1591</NoWarn> <!-- Missing XML comment for publicly visible type or member -->
 
     <!-- Version Information -->
-    <Version>0.3.2</Version>
+    <Version>0.3.3</Version>
     <IsPackable>false</IsPackable>
     <AssemblyVersion>0.2.0.0</AssemblyVersion>
-    <FileVersion>0.3.2.0</FileVersion>
+    <FileVersion>0.3.3.0</FileVersion>
 
     <!-- Package Metadata -->
     <Authors>Ahmed Mustafa</Authors>

README.md

@@ -126,7 +126,7 @@ Measured with BenchmarkDotNet on an i7-10750H, .NET 10.0.9. The orchestration be
 
 After an edit, the agent usually reruns the whole suite. `dotnet_test_affected` asks Roslyn instead: take the symbols declared in the changed files, follow references (up to `maxDepth` hops, default 8) until you land in a method with `[Fact]`, `[Theory]`, `[Test]`, `[TestCase]` or `[TestMethod]`, then run exactly those. Changed files default to the git working tree, or `gitBase: "main"` for a branch. `dryRun: true` lists the tests without running them; `framework: "net10.0"` runs one target framework of multi-targeted test projects.
 
-The walk has a time budget (`maxSelectionSeconds`, default 10). A change to code that everything depends on reaches too much to trace cheaply; then the whole solution runs instead and the response says so (`selectionComplete: false`). The same happens when the selection is more than 20% of all tests (`maxSelectedFraction`), where a filtered run is no faster. You never get a silently partial selection. Runs are killed after `timeoutSeconds` (default 600) so a hanging test cannot hang the agent; the response names the test modules that never finished. `maxDepth: 3` narrows more changes but misses more tests. Works with VSTest and with Microsoft.Testing.Platform (`"test": { "runner": "Microsoft.Testing.Platform" }` in global.json).
+The walk has a time budget (`maxSelectionSeconds`, default 10). A change to code that everything depends on reaches too much to trace cheaply; then the test projects that reference the changed projects run instead (the whole solution if that's all of them), and the response says so (`selectionComplete: false`, `ranScope`). The same happens when the selection is more than 20% of all tests (`maxSelectedFraction`), where a filtered run is no faster. Changed files the walk can't trace (a `.csproj`, `.razor`, `appsettings.json`, a deleted file) switch to the same project fallback and are listed in `untracedFiles`; a changed `Directory.Build.props`, `global.json` or `.editorconfig` runs the whole solution. You never get a silently partial selection. Runs are killed after `timeoutSeconds` (default 600) so a hanging test cannot hang the agent; the response names the test modules that never finished. `maxDepth: 3` narrows more changes but misses more tests. Works with VSTest and with Microsoft.Testing.Platform (`"test": { "runner": "Microsoft.Testing.Platform" }` in global.json).
 
 On this repository, editing `ConcurrentExecutor.cs` selects 22 of 44 tests (the `ConcurrentExecutorTests` plus the `OrchestrationServiceTests` that reach it through `OrchestrationService`). Measured through the MCP tool, build included, i7-10750H:
 
@@ -156,6 +156,7 @@ trust, run the agent and the server in a container with no credentials. Don't ex
 - **Want to help?** Start with a [good first issue](https://github.com/csa7mdm/DotNetDevMCP/labels/good%20first%20issue) or read [CONTRIBUTING](https://github.com/csa7mdm/DotNetDevMCP/blob/main/CONTRIBUTING.md). Running DotNetDevMCP on your own solution and reporting what happened helps just as much.
 - **Docs**: the [wiki](https://github.com/csa7mdm/DotNetDevMCP/wiki) (tutorial, tool reference, troubleshooting) is open to edits.
 - **Security**: report [privately](https://github.com/csa7mdm/DotNetDevMCP/security/advisories/new).
+- **Using it at work?** [Tell me in Discussions](https://github.com/csa7mdm/DotNetDevMCP/discussions/categories/show-and-tell): it decides what gets built next. If your team wants help setting it up on your solution (affected-test tuning, `--clean-env` for private feeds, CI), or wants early input on team features (shared config, audit logging, sandboxed runs), say so there.
 - Everyone here follows the [Code of Conduct](https://github.com/csa7mdm/DotNetDevMCP/blob/main/CODE_OF_CONDUCT.md). If DotNetDevMCP saves you time, you can [sponsor its development](https://github.com/sponsors/csa7mdm).
 
 ## Build from source
@@ -192,9 +193,9 @@ Built on the official [MCP C# SDK](https://github.com/modelcontextprotocol/cshar
 
 ## Status
 
-0.3.2. The Roslyn tools are mature (they come from SharpTools). Testing, build, git and orchestration are newer and have been exercised on this repository and a few others; expect rough edges on unusual project layouts. Issues and PRs welcome, see [CONTRIBUTING](https://github.com/csa7mdm/DotNetDevMCP/blob/main/CONTRIBUTING.md).
+0.3.3. The Roslyn tools are mature (they come from SharpTools). Testing, build, git and orchestration are newer and have been exercised on this repository and a few others; expect rough edges on unusual project layouts. Issues and PRs welcome, see [CONTRIBUTING](https://github.com/csa7mdm/DotNetDevMCP/blob/main/CONTRIBUTING.md).
 
-Known gaps: `dotnet_test_affected` follows C# references only (no reflection, no DI-by-convention, no string-keyed lookups), so a change reached only through those paths will not select the test; use `dryRun` to check what it picks. Tests that hang instead of failing are only caught by a run that finishes. Test attribute detection covers xUnit, NUnit and MSTest by attribute name. Past the command-line length limit the filter widens from methods to classes, then to the whole project (more tests, never fewer).
+Known gaps: `dotnet_test_affected` follows C# references only (no reflection, no DI-by-convention, no string-keyed lookups), so a change reached only through those paths will not select the test; use `dryRun` to check what it picks. Calls through an interface or base class are followed. The project fallback follows `ProjectReference`s only: a test project that uses the changed code through a NuGet package is not found. Builds and tests are not sandboxed (see Security). Tests that hang instead of failing are only caught by a run that finishes. Test attribute detection covers xUnit, NUnit and MSTest by attribute name. Past the command-line length limit the filter widens from methods to classes, then to the whole project (more tests, never fewer).
 
 ## Credits and license
 

benchmarks/DotNetDevMCP.Benchmarks/README.md

@@ -1,10 +1,13 @@
 # DotNetDevMCP Performance Benchmarks
 
-This project contains comprehensive performance benchmarks for the DotNetDevMCP orchestration components using BenchmarkDotNet.
+BenchmarkDotNet micro-benchmarks for the orchestration layer (`ConcurrentExecutor`, `WorkflowEngine`, `ResourceManager`).
 
-## Purpose
+## What these measure, and what they don't
 
-Measure and validate the performance improvements achieved through concurrent operations and orchestration. Target: **measured 3.8x on this repository's test suite; see README for the benchmark tables** over sequential execution.
+Every operation here is a simulated `Task.Delay`. The numbers show the scheduling and throttling overhead of the orchestration
+classes compared with a sequential loop and `Task.WhenAll`; they say nothing about Roslyn, `dotnet build` or `dotnet test`.
+For real workloads (affected-test selection on the Polly repository, build and test wall time, response sizes), see
+[benchmarks/polly](../polly/README.md).
 
 ## Benchmark Categories