docs: Test-Scoping fuer Implementer-Tasks, PowerUse in den Explore-Notes

Die Build-Sektion hat bisher ein Rezept mit allen sechs Testprojekten vorgegeben;
Implementer haben daraus "volle Suite vor fertig" gelesen. Bei bis zu 5
parallelen Tasks kostet das Stunden - und kann das nicht finden, wofuer es
teuer ist: jeder Task arbeitet in seinem eigenen Worktree mit nur seiner eigenen
Aenderung, eine Kollision zwischen zwei parallelen Tasks ist fuer beide
unsichtbar. Kollisionen zeigen sich nach dem Merge, und genau dort laeuft
verify_merges den Verify-Command einmal pro Batch.

Neue Regel: Solution-Build immer (42s, faengt projektuebergreifende
Compile-Brueche), Tests nur --no-build --filter auf das Beruehrte, und melden
welcher Filter benutzt wurde. Die Messwerte stehen dabei, damit die Regel nicht
als Geschmacksfrage gelesen wird.

Messung 2026-09-02, sequenziell nach einem Build: Worker.Tests 507s, Ui 33s,
Data 8s, Rest je 3s, Build 42s. Parallel ueber die Solution ist es schlechter,
nicht besser (Worker 801s, Ui 82s) - diese Tests legen echte Git-Worktrees an
und spawnen Prozesse, sie drangeln sich statt sich zu teilen.

Ausserdem korrigiert: die Zeile "dotnet build ClaudeDo.slnx requires .NET 9"
war veraltet.

CLAUDE.md

@@ -66,14 +66,38 @@ Commit freely (per task + the spec/plan docs). Never push without asking.
 
 ## Building & Testing
 
-`dotnet build ClaudeDo.slnx` requires .NET 9; on .NET 8 build individual projects with `-c Release` (a running Worker locks the `Debug` output).
+**Build the whole solution, test only what you touched.** Always `-c Release` — a running Worker locks the `Debug` output.
 
 ```bash
-dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release      # pulls in Ui + Data
-dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
-dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release   # also: Data.Tests, Ui.Tests, Localization.Tests, Installer.Tests, Releases.Tests
+dotnet build ClaudeDo.slnx -c Release                                    # ~40s, catches cross-project breaks
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --no-build \
+  --filter "FullyQualifiedName~Handoff"                                  # seconds, not minutes
 ```
 
+`.slnx` needs SDK 9+ (this machine is on 10). On an older SDK build the projects individually:
+`src/ClaudeDo.App` (pulls in Ui + Data) and `src/ClaudeDo.Worker`.
+
+### Do NOT run the full test suite to finish a task
+
+Measured 2026-09-02, sequentially after one build: **Worker.Tests 507s**, Ui.Tests 33s, Data.Tests 8s,
+Localization/Installer/Releases 3s each, build 42s — ~10 min for all six. Run in parallel across
+projects it is *worse*, not better (Worker.Tests 801s, Ui.Tests 82s): these tests create real git
+worktrees and spawn processes, so they thrash rather than share.
+
+With up to 5 implementer tasks running at once, a full suite per task costs hours — and **cannot find
+what it costs that for.** Each task works in its own worktree containing only its own change, so a
+collision between two parallel tasks is invisible to both. Collisions surface after the merge, which
+is exactly where `verify_merges` runs the list's verify command **once per batch**. The full suite is
+the merge gate's job, not the task's.
+
+So, per task:
+- **Build:** the whole solution, always. It's cheap and it catches the compile break your change
+  caused three projects over.
+- **Tests:** `--no-build --filter` scoped to what you touched. Add a filter for the classes covering
+  your change; if you genuinely can't scope it, run the one relevant test project, never all six.
+- **Report** what you ran and what you did not, so the merge session knows what is still unverified.
+- Never report "all tests pass" when you ran a filtered subset. Say which filter you used.
+
 ### Gotchas
 - **Subagents:** use the `sonnet` model; stage files explicitly by path — never `git add -A` (parallel sessions often leave unrelated WIP in the tree).
 - **Icons:** `PathIcon` *fills* its geometry — line-art icons must be filled geometry or a `Path Classes="icon-stroke"`, else they render invisible. Colour comes from the `ICON PAINTING` block in `IslandStyles.axaml` (class + state); setting `Foreground`/`Stroke` inline kills the hover state.