Epic: quickfiler-bug-family — twelve QuickFiler defect clusters

.claude/agent-memory/atomic-executor/feedback_confirmatory_preflight_proportionate_bar.md

@@ -0,0 +1,43 @@
+---
+name: confirmatory-preflight-proportionate-bar
+description: On a confirmatory preflight over a small delta to an already-cleared plan, block only on an actually-wrong edit or an actual regression; incomplete enumerations are non-blocking observations
+metadata:
+  type: feedback
+---
+
+When a directive says "CONFIRMATORY PASS" over N named edits to a plan that already earned
+`PREFLIGHT: ALL CLEAR`, say `REVISIONS REQUIRED` only if one of those edits is actually wrong
+or actually regressed something the prior pass verified. Wording preferences, belt-and-braces
+suggestions, and *incomplete enumerations* go under an ALL CLEAR as non-blocking observations.
+
+**Why:** the prior ALL CLEAR is authority, not a starting point to re-litigate. Re-auditing the
+whole plan burns a cycle and risks the "make the citation exist" failure mode recorded in
+[[project_preflight_citation_match_propagates_false_fact]] — a delta that edits correct text to
+match a re-derived opinion. The user states the bar explicitly: "Hold a proportionate bar and
+converge."
+
+**How to apply:** distinguish a FALSE claim from an INCOMPLETE one. On #498 v2.3, `P4-T1` said
+its recorded value "is the sole input to the branch conditions in `P5-T4` and `P5-T5`" after
+`P5-T3` also gained a gate on it. That sentence is still true of the two tasks it names; it is
+merely no longer exhaustive, and the task's own governing text plus the binding "Conditional
+branches" rule both state the condition. Nothing is unsatisfiable and no executor is stranded,
+so it is an observation, not a blocker. Contrast with the genuinely blocking shapes in
+[[project_exact_count_gate_vs_remediation_loop]] and
+[[project_preflight_absolute_zero_gate_on_sibling_owned_assembly]], where a gate is
+*unsatisfiable* or *unwaivable*.
+
+**Polarity test for a clause an earlier task invalidates.** When phase N asserts a fact about a
+file that phases 1..N-1 change, ask which way the clause breaks. A clause that becomes FALSE at its
+own point strands the executor — it counts literally, records a mismatch, and leaves the task
+unchecked under the fail-closed rule (#464 `[P5-T11]`: "the two timer arming sites still bind" after
+`[P1-T6]` deleted the method holding one of them). A clause that becomes TRIVIALLY TRUE only loses
+gating power (#464 `[P6-T13]`: a zero-match search for `throw (e.InitializationException)` that
+`[P6-T10]` had already driven to zero). The first is blocking; the second is an observation, provided
+the task carries at least one other clause that can still fail. Same defect family, opposite cost.
+
+Cheap mechanical confirmations that make a confirmatory pass fast and defensible: diff the two
+committed plan revisions with `git diff -U0` and read only the hunk headers (a fifth undisclosed
+hunk is itself a finding); compare the `file:line` citation MULTISET across revisions to prove
+"no citation was touched"; compare the sorted task-ID list to prove "no addition, removal or
+renumbering". Still verify every factual assertion you make against the file — see
+[[feedback_verify_line_citations_with_numbered_output]].

.claude/agent-memory/atomic-executor/feedback_verify_line_citations_with_numbered_output.md

@@ -29,3 +29,34 @@ line citation against line-numbered output before asserting it."
   numbered read is far below the cost of a corrupted plan revision cycle.
 - Related: [[project_418_plan_rationale_clauses_are_evidence]] — unmeasured world-state claims in
   plan prose are the other recurring source of preflight churn.
+
+## Corollary: never assert a file LOCATION you have not listed (#498 preflight cycle 2)
+
+The same rule governs *where* a file lives, not only which line. In #498 preflight cycle 2 I
+reported that the CSharpier tool manifest is at `.config/dotnet-tools.json` and asked the planner
+to "correct" a plan sentence that was already right. `.config/` does not exist in this repository
+at all; the manifest is at the repo root as `dotnet-tools.json` with `"isRoot": true`, which
+CLAUDE.md also states. The planner independently verified and correctly REJECTED the observation.
+
+**How to apply:** before writing "the file is at X", run `ls X` or `find . -maxdepth 2 -name <f>`.
+Ecosystem defaults are the trap — `.config/dotnet-tools.json` is the .NET convention and this repo
+deviates from it. A plausible-by-convention location is a hypothesis, not a fact. (Re-confirmed
+independently during #488 preflight round 2: still root-level, still no `.config/`.)
+
+## Corollary: verify the citation ANCHOR SHA, not only the numbers (#488 preflight round 2)
+
+A plan that declares "line citations are anchored to `<SHA>`" is making a second, separate claim
+that is easy to miss once the numbers themselves check out. In #488 the plan anchored to the
+then-tip-of-main `988e819b`, but the branch had advanced to `0a6aaa31`, and in between
+`QuickFiler.Test/QuickFiler.Test.csproj` gained one `<Compile Include>` line near the top. Every
+citation below that insertion shifted by one: the plan's `line 82` and `467-471` were correct at
+HEAD (where the executor works) and off by one at the declared anchor. Round 1 verified the
+numbers against HEAD and passed them, without noticing the anchor label had gone stale.
+
+**How to apply:**
+- Run `git merge-base --is-ancestor <ANCHOR> HEAD` and then `git diff --name-only <ANCHOR> HEAD`,
+  and intersect that list with every file the plan cites by line. A hit means the anchor is
+  load-bearing and must be re-derived or re-labelled.
+- The *numbers* being right at HEAD does not clear the *anchor*; an executor told to resolve
+  against the anchor will mislocate. Re-anchor to the current branch HEAD and say so.
+- Cheap and mechanical — do it once per preflight round, before checking any individual citation.

.claude/agent-memory/atomic-executor/project_agent_memory_tracked_breaks_unscoped_git_gates.md

@@ -32,5 +32,14 @@ untracked) — neither alone proves "no file was added or removed". Note also th
 `git diff --name-only` is worktree-vs-index; if anything gets staged mid-execution, switch to
 `git diff --name-only HEAD -- <pathspec>`.
 
+**Re-check Phase 0 after a revision pass fixes the late phases.** On issue #501 the planner was told
+to scope the clean-tree checks and scoped only the two *commit-time* tasks (P9-T4, P9-T6), leaving
+the **Phase 0 baseline** task's `git status --porcelain` "produced zero output lines" acceptance
+unscoped. That one is the *most* certain to fail: at execution start the planner's own dirty
+agent-memory files and the not-yet-committed plan file are still in the tree (measured: three
+entries). When you accept a fix for this defect class, re-grep the whole plan — the natural mental
+model is "clean tree at the end", so authors patch the end and miss the baseline capture.
+
 Related: [[project_preflight_selfderived_gate_thresholds_are_blind]],
-[[project_418_plan_rationale_clauses_are_evidence]].
+[[project_418_plan_rationale_clauses_are_evidence]],
+[[project_preflight_ac_checkoff_and_tooloutput_paths]].

.claude/agent-memory/atomic-executor/project_analyzer_version_skew_fresh_worktree.md

@@ -1,12 +1,56 @@
 ---
 name: analyzer-version-skew-fresh-worktree
-description: Fresh TaskMaster worktree fails first analyzer build with CS0006 (missing Meziantou/Sonar/BannedApi analyzer DLLs) — csproj Analyzer Include paths lag packages.config; install the old versions into gitignored packages/
+description: Fresh TaskMaster worktree fails EVERY build (not just the analyzer gate) with CS0006 — 16 csproj <Analyzer Include> paths lag packages.config; it recurs after each Dependabot analyzer bump and blocks the whole plan, so surface it at P0-T13
 metadata:
   type: project
 ---
 
-On a clean TaskMaster worktree, the first `msbuild TaskMaster.sln ... /p:EnableNETAnalyzers=true` fails with `error CS0006: Metadata file '..\packages\Meziantou.Analyzer.3.0.101\...\Meziantou.Analyzer.dll' could not be found` (also SonarAnalyzer.CSharp.10.27.0.140913 and Microsoft.CodeAnalysis.BannedApiAnalyzers.3.3.4).
+On a clean TaskMaster worktree, the first `msbuild TaskMaster.sln ... /t:Rebuild` fails with
+`error CS0006: Metadata file '..\packages\<Analyzer>.<oldVersion>\...\<X>.dll' could not be found`.
 
-**Why:** This is a pre-existing repo-wide skew on `origin/main` (commits like 097f0ba2 "Bump the analyzers-dev-deps group"): `packages.config` was bumped to newer analyzer versions (Meziantou 3.0.123, BannedApi 5.6.0, Sonar 10.29.0.143774) but the hand-written `<Analyzer Include>` DLL paths in 16 first-party csproj files still reference the OLD versions. On dev/CI machines the old analyzer package folders linger in `packages/`; a clean-worktree restore installs only the current `packages.config` versions, so the old folders are absent -> CS0006.
+**Why:** pre-existing repo-wide skew. `packages.config` and the `<Import>`/`<Error>` restore-check lines are
+bumped by Dependabot ("Bump the analyzers-dev-deps group"), but the hand-written `<Analyzer Include>` DLL
+paths in **16** first-party csproj files still name the OLD versions. On dev/CI machines the old package
+folders linger in the gitignored `packages/`; a clean-worktree restore installs only the current
+`packages.config` versions, so the old folders are absent.
 
-**How to apply:** Do NOT edit the 16 csproj files (out of scope, huge churn). Install the missing OLD analyzer versions into the gitignored `packages/` folder with the winget nuget.exe: `nuget install Meziantou.Analyzer -Version 3.0.101 -OutputDirectory packages` (repeat for `Microsoft.CodeAnalysis.BannedApiAnalyzers 3.3.4` and `SonarAnalyzer.CSharp 10.27.0.140913`). This touches no tracked files. Also required on a fresh worktree before any build: `pwsh ./scripts/vscode/Install-RepoDotNetSdk.ps1` then `./.dotnet-sdk/dotnet.exe tool restore` (for csharpier 1.2.6) and `pwsh ./scripts/vscode/Invoke-Restore.ps1` (nuget restore). csharpier via repo SDK: `./.dotnet-sdk/dotnet.exe tool run csharpier format|check .`.
+Observed instances (the pair moves with each bump; re-measure, do not assume):
+- 2026-08 @ `61edc19` (epic/quickfiler-bug-family-integration): `<Analyzer Include>` names
+  `Meziantou.Analyzer.3.0.156` + `Roslynator.Analyzers.4.16.0`; restore installs `3.0.174` + `4.16.1`.
+  AsyncFixer 2.1.0, BannedApiAnalyzers 5.6.0, SonarAnalyzer.CSharp 10.32.0.713 all agree — only 2 skew.
+- earlier: Meziantou 3.0.101, BannedApi 3.3.4, Sonar 10.27.0.140913.
+
+**Blast radius is the whole solution, not just the analyzer gate.** `<Analyzer Include>` is unconditional, so
+the plain nullable Rebuild (`/p:TreatWarningsAsErrors=true`, no analyzer properties) fails identically. Only
+`VBFunctions` and `UtilitiesCS` emit the 10 diagnostics; the other 13 projects fail transitively on the broken
+project reference. `SVGControl` / `SVGControl.Test` are the only projects that build (they carry no stale
+reference). Consequence: `<Test>/bin/Debug` is EMPTY, so any full-suite or scoped vstest task and any coverage
+baseline is unreachable, and every "analyzer Rebuild returns EXIT_CODE: 0" acceptance in the plan is
+unsatisfiable. Diagnose it at the first analyzer gate rather than at the first test run.
+
+**How to apply:**
+1. Verify it is pre-existing, not yours: `git status --porcelain -- '*.csproj' '*/packages.config'` must be
+   empty; then `ls -d packages/Meziantou* packages/Roslynator*` vs
+   `grep -n "Analyzer Include" <proj>.csproj`. The `<Import>` at csproj line ~3 shows the NEW version while
+   the `<Analyzer Include>` block shows the OLD one — that contrast is the fingerprint.
+2. Remedy that touches no tracked file: install the missing OLD versions into the gitignored `packages/`
+   (`nuget install Meziantou.Analyzer -Version <old> -OutputDirectory packages`, likewise Roslynator).
+3. **But check the delegation prompt first.** A caller may explicitly forbid this — the #498 execution
+   directive said "If a restore still produces `error CS0006` from skewed analyzer package versions, report it
+   rather than working around it." In that case record the red baseline truthfully with `ExpectedExitCode: 1`
+   and stop at the first task that needs a built assembly, rather than provisioning the packages.
+4. The durable fix is upstream: update the 16 `<Analyzer Include>` version strings in the same commit as the
+   `packages.config` bump. Worth an issue; it recurs on every analyzer bump.
+
+**Resolved instance, 2026-08-26 @ `61edc19` (#498).** After the orchestrator provisioned the two missing
+gitignored package dirs, the SAME analyzer and nullable Rebuild recipes went from `EXIT_CODE: 1` / 10 CS0006
+to `EXIT_CODE: 0`, 0 errors, 5 warnings (all the uncoded `System.Reactive.PackagesConfigCheck.targets`
+packages.config advisory, on QuickFiler/TaskMaster/ToDoModel/UtilitiesCS/UtilitiesCS.Test). `git status
+--porcelain -- packages` stayed empty, so the ownership gate was untouched. All 9 test assemblies then
+existed and the full suite ran 6482/6482 green at 84.78% repo line rate.
+
+**Never carry a CS0006 baseline forward as the plan's baseline.** Under a Baseline-Comparison Rule, a
+non-zero Phase-0 analyzer/nullable baseline permanently DEGRADES the Phase-8 gates into gates that cannot
+fail, and licenses every intermediate "analyzer Rebuild returns 0" check to pass while compiling nothing.
+If the provisioning gap is later fixed, re-run both gates and OVERWRITE the artifacts, deleting the
+`ExpectedExitCode: 1` line — the field is what normalizes a red row to `pass` in PR-body collection.

.claude/agent-memory/atomic-executor/project_concurrent_executor_same_worktree.md

@@ -15,3 +15,31 @@ Detection signals (reusable):
 **Why:** The orchestrator apparently launched (or left alive) a duplicate executor on the same branch/worktree. Racing it corrupts `FlagTasks.cs`, the csproj, and later test/coverage runs.
 
 **How to apply:** Before Phase 0 baseline, snapshot `git status --porcelain` and key mtimes; re-check after a few tool calls. If untracked/modified files you did not author appear or advance, STOP — do not stash/reset (it clobbers the other writer via 3-way merge) and do not race. Report the concurrent-execution conflict to the orchestrator and let it enforce a single executor per worktree. See [[epic-orchestrator-worktree-isolation]] for the worktree-isolation principle.
+
+## Second confirmed occurrence — #501 breadcrumb-coordinator-hub, 2026-08-27
+
+Worktree `agent-a5f370e5c08f8ddb0`, plan `breadcrumb-coordinator-hub-defects-501/plan.2026-08-24T09-40.md`.
+Detected during preflight, before writing anything. Two additional signals, both cheaper and more
+decisive than the source-file mtime sweep:
+
+- **The plan file's own checkbox count advances while you only read.** Fingerprinted the plan at
+  preflight (sha256 `6bf57583...`, `DONE: 0`). Minutes later, without writing, it was sha256
+  `446430ed...`, `DONE: 5`, then `DONE: 7`. The plan file IS the shared todo list, so a check-off
+  count that rises during your own turn is proof of a second writer by itself. Re-hash the plan
+  immediately before the first check-off, always.
+- **A bootstrap side-effect DIRECTORY growing localises the other agent to a task ID.** Phase 0
+  provisioning tasks have large filesystem side effects (`.dotnet-sdk/` from
+  `Install-RepoDotNetSdk.ps1`, `packages/` from `Invoke-Restore.ps1`). Sampling `du -sk .dotnet-sdk`
+  twice ~20s apart names the task the sibling is inside even before it writes its evidence artifact.
+  Here `.dotnet-sdk/` appeared holding only `dotnet.exe` + `host/`, grew to 764 MB, then `packages/`
+  followed — the sibling was mid-P0-T6, then P0-T7, then P0-T8.
+
+**Why this one mattered:** the launching agent's prompt was the literal string
+`SendMessage placeholder - not used` — no plan path, no directive, no task. A degenerate or
+placeholder delegation message is itself a signal that the harness may have double-launched; treat
+it as a reason to fingerprint shared state before acting, not as a licence to go find work to do.
+
+**How to apply (addendum):** blocking is permitted only at preflight, and a concurrent-writer
+conflict is detectable at preflight for free — hash the plan, count the evidence dir, sample twice.
+Do that BEFORE the first check-off. Once you have written even one artifact you have joined the race
+and the clean stop is no longer available.

.claude/agent-memory/atomic-executor/project_directory_scoped_format_breaks_ownership_gates.md

@@ -0,0 +1,31 @@
+---
+name: directory-scoped-format-breaks-ownership-gates
+description: A final-QC csharpier pass scoped to whole DIRECTORIES can rewrite must-not-write files, contradicting the same plan's unmodified-file assertions; scope the mutating pass to explicit file paths.
+metadata:
+  type: project
+---
+
+A plan that correctly refuses a repo-wide `dotnet tool run csharpier format .` (because concurrent
+sibling epic children share the branch) can still defeat itself by scoping the MUTATING pass to
+directories rather than to explicit file paths. Observed on plan
+`docs/features/active/breadcrumb-router-navigation-defects-498/plan.2026-08-24T09-39.md` (P7-T1):
+the scoped list named 6 files plus `QuickFiler.Test/Controllers`, `QuickFiler.Test/Viewers`, and
+`UtilitiesCS.Test/OutlookObjects/Folder` — 181 `.cs` files, of which the plan writes about 7.
+
+**Why:** those directories contain files the same plan lists as MUST NOT WRITE and asserts are
+unmodified via `git status --porcelain -- <path>` producing no output
+(`QuickFiler.Test/Viewers/FolderBreadcrumbAssetContractTests.cs`,
+`UtilitiesCS.Test/OutlookObjects/Folder/BreadcrumbStateModelSelectorTests.cs`,
+`BreadcrumbStateModelSequenceTests.cs`). If csharpier rewrites any of them the plan fails its own
+ownership acceptance criteria. Whether it actually rewrites them depends on the pre-existing
+baseline formatting state, which the plan captures only later — so the gate is a coin flip, not a
+guarantee.
+
+**How to apply:** at preflight, whenever a plan scopes the mutating format pass, check that every
+entry is a FILE path, not a directory, and cross-check each entry against the plan's must-not-write
+list and against every task whose acceptance is "`git status --porcelain -- <path>` produces no
+output". Flag a bare directory as a Blocking revision. New files created mid-plan must be added to
+the list by path, which the plan should say explicitly. See
+[[project_csharpier_pipefiles_nonenforcing_gate]] and
+[[project_count_idiom_pitfalls_csharpier_and_measureobject]] for the companion traps in verifying
+that the format step actually did something.