Mika Kuns
416997d7e0
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.
Explore-notes
Distilled, reusable maps of complex subsystems, produced by deep code exploration. The goal: stop re-exploring the same subsystem from scratch in every new session.
These sit between the CLAUDE.md files and the code:
- CLAUDE.md — high-level orientation, hand-maintained, always-loaded.
- explore-notes — deeper subsystem detail (flows, who-calls-whom, invariants) that is too fine-grained for a CLAUDE.md but stable enough to be worth caching. Read on demand.
- code — the only source of truth.
Index
| Note | Covers |
|---|---|
| worker-task-pipeline | TaskRunner end-to-end: config resolution, worktree, CLI invocation, streaming, commit |
| usage-monitoring | OAuth usage endpoint, gate, throttle, per-run token accounting, usage pill/modal |
| external-mcp | The claudedo MCP tool surface + its two test-enforced conventions |
| review-merge | Approve=merge-unit, verify gate, MergeCommit/revert, diff stack, conflict resolver |
| conpty-sessions | Interactive/planning/list-handler launch specs + the arg-flattening gotcha |
| installer-preflight | CLI version/login/auto-mode research, the ExecutableResolver/shim root cause, and the Installer's Checks/+SystemCheckPage implementation status |
| list-virtualization-spike | Phase 2a gate spike: virtualized ListBox + the existing ghost-drag InputHitTest model, verified headless |
Rules
- Only stable structure. Flows, responsibilities, entry points, invariants, relative file paths. No line numbers, no exhaustive symbol dumps — those rot fastest.
- Verify before trusting. A note is a starting map, not authority. Always confirm against current code before acting on it. Each note records the commit it was verified against so you can diff for drift.
- Not a substitute for CLAUDE.md. If a fact belongs in orientation, put it there.
Header every note must carry
> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
> Last verified against commit `<short-hash>` (<date>).
> Drift check: `git log --oneline <short-hash>..HEAD -- <paths this note covers>`
> Stable structure only (no line numbers). See docs/explore-notes/README.md.
Workflow
- Before deep-exploring a subsystem, check for a matching note here and read it first; explore only to fill gaps or confirm.
- After a deep explore, distill the durable findings into a new/updated note and bump its "verified against" commit line.
- If the drift check shows the covered paths changed a lot since the verified commit, treat the note as suspect and re-verify the parts you rely on.