fix(epic): clear the eight review residuals left by the bugs-2026-09-06 run

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

@@ -0,0 +1,39 @@
+---
+name: cs1769-forces-reflection-for-outlook-returning-apis
+description: A UtilitiesCS method returning Task<Outlook.X> cannot be awaited from UtilitiesCS.Test at all (CS1769, embedded interop type as generic argument) — a plan that says "call it on a mocked Explorer" is unimplementable as written and needs a reflective helper
+metadata:
+  type: project
+---
+
+Any `UtilitiesCS` API whose return type is `Task<T>` where `T` is an Outlook interop type — for
+example `OlTableExtensions.GetTableInViewAsync`, which returns `Task<Outlook.Table>` — **cannot be
+awaited from `UtilitiesCS.Test`**. The build fails with:
+
+    error CS1769: Type 'Task<Table>' from assembly 'UtilitiesCS, ...' cannot be used across
+    assembly boundaries because it has a generic type argument that is an embedded interop type.
+
+**Why:** both projects embed the Outlook interop types rather than referencing a shared PIA, so
+`Outlook.Table` is a distinct type per assembly and cannot cross the boundary as a generic type
+argument. This is the same CS1769 constraint that `DfDeedle.DefaultTableEtl` is declared over
+`object` to avoid, and it is why the four existing `GetTableInViewAsync` binding sites in
+`OlTableExtensions_Tests.cs` all go through the reflective `InvokeAsyncResult` helper rather than
+calling the method directly. Reflection is *required*, not stylistic.
+
+**How to apply:**
+- Bind by name plus an explicit parameter-`Type[]`, invoke, cast the result to the **non-generic**
+  `Task`, `await` that, then read `task.GetType().GetProperty("Result").GetValue(task)`. The
+  non-generic `Task` and `object` both cross the boundary fine.
+- `typeof(Outlook.Explorer)` in a `Type[]` is fine; only the *generic argument* position is
+  rejected.
+- The explicit `Type[]` is a hidden coupling to the signature. A plan that adds a parameter to the
+  production method in a later phase silently breaks every reflective binding, including ones the
+  plan does not list — budget a micro-action to update them, the same way the plan already budgets
+  one for the direct call sites.
+- Declare the array once as a `private static Type[] SignatureTypes => ...` in a new test file so a
+  future signature change is a one-place edit.
+
+Encountered on issue #825 (2026-09-09): the plan's P2-T1 said the new test "calls
+GetTableInViewAsync on a mocked Explorer", which does not compile; the fix was a local reflective
+helper mirroring `InvokeAsyncResult`.
+
+Related: [[project_test_file_name_vs_partial_class_name]], [[project_outlook_action_ambiguity]]

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

@@ -0,0 +1,34 @@
+---
+name: epic-child-branch-anchored-diff-lists-inherited-commits
+description: On an epic child branch cut from the integration branch, `git diff <merge-base HEAD origin/main>` lists every sibling commit's paths, so footprint gates written against it are unsatisfiable
+metadata:
+  type: project
+---
+
+A feature branch cut from an epic **integration** branch inherits every sibling feature's commits, so
+`git merge-base HEAD origin/main` resolves below all of them. An anchored two-dot diff against that
+base then lists the whole inherited set, not this feature's change.
+
+Measured on issue #821 (`bug/...-821-exec`, 2026-09-09): merge base `6f08302a` = `origin/main` tip,
+but **70 commits** and **184 paths** sat between it and HEAD. The anchored diff returned **192 paths**
+against **38** authored ones. The inherited set included `UtilitiesCS.Test/UtilitiesCS.Test.csproj`,
+entries under `.claude/agent-memory/`, and files named in the spec's own out-of-scope list.
+
+**Why:** plans routinely write footprint gates as "zero `.csproj` in `git diff --name-only (git
+merge-base HEAD origin/main)`" or "every path in that span belongs to the permitted set". On an epic
+child branch both are **unsatisfiable regardless of what the executor does** — a sibling already put a
+`.csproj` in the span. Plan #821 anticipated the mechanism but scoped it to four documents; the real
+set was two orders of magnitude larger.
+
+**How to apply:**
+- Discriminate with `git diff --name-only HEAD` (authored, pre-commit) **plus** `git status
+  --porcelain --untracked-files=all` for untracked paths. That pair is the change the feature authored.
+- Prove any offending inherited path is genuinely inherited, don't just assert it: `git log --oneline
+  <mb>..HEAD -- <path>` names the sibling commit, and `git diff --name-only HEAD -- <path>` returning
+  empty proves the worktree never touched it.
+- Run the anchored span anyway and report it in full. Record the condition as *not met as literally
+  written*, with the discriminating evidence beside it. Do **not** silently substitute the narrower
+  span and call the gate passed, and do not widen the permitted-path list to swallow the inherited set.
+- Beware `git log (git merge-base HEAD origin/main)..HEAD` from Bash-invoked pwsh: the `..HEAD` suffix
+  after a parenthesised expression does **not** concatenate and the command silently reports 0 commits.
+  Substitute the literal SHA. See [[project-pwsh-command-quoting-from-bash]].

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

@@ -0,0 +1,34 @@
+---
+name: fresh-worktree-needs-sdk-and-packages-config-restore
+description: A fresh TaskMaster worktree needs .dotnet-sdk provisioning AND `/p:RestorePackagesConfig=true`; the plan-standard `dotnet tool restore` and `msbuild /t:Restore` both no-op or fail
+metadata:
+  type: project
+---
+
+Two bootstrap steps that plans routinely omit, both required before any gate can run in a cold
+TaskMaster worktree. Measured on issue #821, worktree `rr0908-821`, 2026-09-09.
+
+**1. `dotnet tool restore` fails outright with no repo-local SDK.** `global.json` pins sdk `8.0.205`
+with `rollForward: latestFeature` and search paths `.dotnet-sdk` then `$host$`. A fresh worktree has
+no `.dotnet-sdk`, and the host had only `10.0.400`, which `latestFeature` on an `8.0.2xx` pin rejects.
+`dotnet tool restore` exits `-2147450725` printing `global.json`'s own `errorMessage`. Fix: run
+`./scripts/vscode/Install-RepoDotNetSdk.ps1` (~733 MB, ~1 min). It resolves its target from
+`$PSScriptRoot/../..`, so invoking it by path in the target worktree is safe.
+
+**2. `msbuild TaskMaster.sln /t:Restore /m` restores nothing.** It handles `PackageReference` only;
+every project here is legacy `packages.config`. It exits 0 printing `Nothing to do. None of the
+projects specified contain packages to restore.` while `packages/` stays absent —
+`UtilitiesCS.csproj` alone carries **153** `..\packages\` references, so every later build would fail
+on unresolvable `HintPath`/`Analyzer Include` rather than on a real diagnostic. Fix: add
+`/p:RestorePackagesConfig=true`, which installed **172** packages.
+
+**Why it matters for plan execution:** a plan may explicitly forbid provisioning ("do not provision a
+repo-local .NET SDK: that is environment setup outside this plan's scope"). That instruction assumes a
+usable SDK exists. When it does not, the plan is unexecutable at task 1 and the executor is past
+preflight, so it cannot block — do the minimum needed and record it as a named deviation.
+
+**How to apply:** both writes land only on gitignored or untracked-output paths — `.dotnet-sdk/` is
+ignored at `.gitignore:350` (`.dotnet*/`, confirm with `git check-ignore -v .dotnet-sdk/x`) and
+`packages/` is restore output — so neither widens an AC20-style footprint. Record each as an explicit
+numbered deviation in the bootstrap artifact, quoting the failing command, its exit code and the
+observation that proved the need, rather than quietly fixing the environment.

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

@@ -1,6 +1,6 @@
 ---
 name: msbuild-log-has-two-absolute-path-leak-classes
-description: A raw MSBuild file-logger log carries TWO distinct absolute host paths — the worktree root AND the main-checkout root via csc.exe /analyzerconfig: — so a worktree-root-only sanitisation leaves ~36 leaks per log
+description: A raw MSBuild file-logger log carries FOUR absolute-host-path leak classes — worktree root, main-checkout root, MSBuildUserExtensionsPath and _DeploymentUrl — so even a two-root sanitisation leaves ~21 account-name leaks per log
 metadata:
   type: project
 ---
@@ -15,6 +15,21 @@ prefixes, not one:
    emits two `/analyzerconfig:` arguments back to back for the same file: the main-checkout one
    and the worktree-rooted one.
 
+**Two further classes survive both root rewrites** (measured on issue #825, 2026-09-09, at
+`Verbosity=detailed`): after rewriting both roots, 21 lines per log still carried `C:\Users\`, in
+these forms:
+
+3. **`MSBuildUserExtensionsPath`** — a property-reassignment line echoing
+   `C:\Users\<account>\AppData\Local\Microsoft\MSBuild` "expanded from the environment".
+4. **`_DeploymentUrl`** — three property-reassignment lines echoing a OneDrive folder under the
+   user profile (a ClickOnce publish URL carried by the VSTO project).
+
+Neither is under any repository root, so neither root substitution reaches it. A plan whose gate
+demands a **zero** count of the token `C:\Users\` in the committed logs therefore cannot pass on a
+two-root rewrite, however correct that rewrite is. Add a **third** pass mapping the user-profile
+root (`C:\Users\<account>`) to `<user-profile-root>`, applied *after* the two root passes so it
+only reaches residuals. Record it as a deviation if the plan's decision record names only two.
+
 **Why:** when running inside a linked worktree, the main-checkout root is an *ancestor* of the
 worktree root, so it is not itself prefixed by the worktree-root string and a worktree-root-only
 substitution never matches it. Measured on issue #730 (2026-09-02): 36 `csc.exe` invocations per

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

@@ -0,0 +1,30 @@
+---
+name: noexecute-early-return-premise-hides-reachable-entry-point-tests
+description: A plan claiming an entry-point block is unreachable because tests only use a -NoExecute early return is often false; verify by searching for calls that omit the switch before accepting an uncovered-by-construction argument.
+metadata:
+  type: project
+---
+
+A plan premise of the form "the existing tests exercise this entry point only through its `-NoExecute`
+early return, so no unit test can reach the block below it" must be verified before it is relied on.
+In `scripts/vscode/Invoke-MSTestWithCoverage.ps1` it was **false**: six pre-existing tests call
+`Invoke-MSTestWithCoverageMain` **without** `-NoExecute` and do reach the post-processing block, with
+`ConvertTo-KoverageCoberturaXml` mocked.
+
+**Why:** issue #815's plan decision D3 built two things on that premise — an argument that the one
+added wiring line is "uncovered by construction", and an AC10 allowance letting the entry point's
+missed LINE count rise by 1. Both were wrong in the safe direction (the line turned out covered;
+missed stayed 10), but the premise also hid a real regression: the mocked document those six tests
+supply is the minimal stub `<coverage line-rate="0.8" />`, which carries no `<packages>` node.
+`Assert-CoberturaLineCoverageThreshold` tolerates it because it reads only the root attribute; any
+new call that parses deeper throws, and the whole PoshQC test stage went red at P5-T6.
+
+**How to apply:** before accepting an unreachability or uncovered-by-construction claim about an
+entry-point block, run `git grep -n` for calls to the function and check which ones omit the guarding
+switch. When adding a call into such a block, check what the existing mocks return: a stub that
+satisfies the *previous* consumer can be structurally invalid for a new one. The right remedy is to
+make the stub structurally realistic (here, adding an empty `<packages />`), not to relax the new
+function's validation — that keeps every assertion exact and keeps fail-fast behaviour intact. Note
+the collateral: the two test files needing the fixture fix were outside the spec's Write Set, and one
+of them sits at 496 of 500 lines, so the edit had to be a same-line replacement with zero net lines.
+Related: [[project-plan-checkoff-fixpoint-breaks-terminal-clean-tree-gate]].

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

@@ -0,0 +1,27 @@
+---
+name: pester5-helper-function-must-live-in-beforeall
+description: A helper function defined at Pester 5 test-file scope is not resolvable from an It block; define it inside BeforeAll or every test using it fails CommandNotFoundException.
+metadata:
+  type: project
+---
+
+In Pester 5, a `function` defined at the top level of a `*.Tests.ps1` file is **not** resolvable from
+inside an `It` block. The test file is evaluated during the discovery pass into a session state the
+run pass does not share, so the run pass raises `CommandNotFoundException: The term '<name>' is not
+recognized`. Define the helper inside the file's `BeforeAll` block instead; `It` blocks run in a
+child scope of the containing block, so a function defined there resolves.
+
+**Why:** cost me one wasted red run on issue #815. The plan required a private differential helper in
+the new test file; placed at file scope, the one test that called it failed with
+`CommandNotFoundException` while the other six passed, which reads like a production defect and is
+not one. Moving the function body unchanged into `BeforeAll` turned `PASSED=6 FAILED=1` into
+`PASSED=7 FAILED=0`.
+
+**How to apply:** when a Pester 5 test file needs a helper function, put it in `BeforeAll` from the
+start. The same rule does not apply to `$script:`-scoped *variables*, which do survive from
+`BeforeAll` into `It` — that is the established idiom in `tests/scripts/vscode/`. If a plan's task
+text says the file "contains" the helper without saying where, `BeforeAll` is the only placement that
+works, and moving it there is a mechanically necessary micro-action rather than a plan deviation.
+Record the move in the pass-after artifact if it happens after a fail-before run was captured, since
+it changes the delivered test file. See [[compile-red-needs-body-level-references]] for the analogous
+C# case where placement decides whether a test can observe what it claims to.

.claude/agent-memory/atomic-planner/MEMORY.md

@@ -2,6 +2,8 @@
 
 ## Preflight revision seams (per-issue)
 
+- [#826](project_826_factory_outside_try_reachability_seams.md) — a seam invoked OUTSIDE the `try` makes both catch bodies reachable; enumerate the seam's line vs the `try`'s, not the catch clauses
+- [#815](project_815_coverage_aggregation_exposure_plan_seams.md) — `.//line` baseline already zero (needs a positive control); pinned nine-name allowlist zeroes the differential helper; test tree tighter than production; 500 lines legal, 501 not
 - [#810 R1–R2](project_810_teardown_dropdown_residuals_plan_seams.md) — inherited paths must be a RULE not a list (executor writes agent-memory mid-run); never upper-bound a csharpier checked-file delta; `TokenSource` null before Cleanup too
 - [#791](project_791_hc_deadline_cancel_teardown_plan_seams.md) — `QfcDatamodel` excluded from coverage; no shell var survives between tasks · [#781](project_781_excludefromcodecoverage_guard_plan_seams.md) — `[ExcludeFromCodeCoverage]` makes changed-line coverage unmeasurable
 - [#736 R1–R5](project_736_efc_archiveroot_boundary_sink_plan_seams.md) — 485-line test file voids the Write Set; hardcoded floors; one shared `try`; name-vs-content gates; existence-only `*.log`