Phase B: per-phase memory instrumentation (ADR-029)

[chaospheremk]

Phase B — Memory instrumentation

Phase B of the reconciliation plan (plans/polished-inventing-whisper.md). PR #26 ported six categories of work-computer platform fixes onto trunk, but the underlying 8+ GB working-set ceiling on the ~30k-object live run is undiagnosed (no JSONL retained). Before another live run, add structured memory measurement so the next run produces data we can reason from.

What changed

scripts/Invoke-ADPermissionAnalysis.ps1

• New Get-RuntimeMemorySnapshot helper. Returns a 6-field hashtable:
  • managedHeapMB — GC.GetTotalMemory($false) / 1MB, 1dp (no forced collection)
  • workingSetMB — Process.WorkingSet64 / 1MB, 1dp
  • privateBytesMB — Process.PrivateMemorySize64 / 1MB, 1dp
  • gen0Collections, gen1Collections, gen2Collections — GC.CollectionCount(n)
• Snapshot embedded in data.memory for:
  • Every PhaseStart / PhaseEnd event (Phases 1-6, 12 boundaries).
  • Every Phase 2 EnumerationProgress event (~5000-object cadence).
  • New MidEnumerationDrain events emitted only when a drain pass freed >=1 completed handle (so post-run analysis can correlate drain bursts with managed-heap movement).

The helper lives in the entry script. Runspaces don't call it — the orchestrator's drain block already sees per-batch boundaries.

CHANGELOG.md

Entry under [Unreleased] / Added.

Why this and not a speculative memory fix

Phase A already shipped the obvious memory mitigations (Item-pinning removal, mid-enumeration drain, incremental $aceRecords). Those weren't enough. Without per-phase telemetry we don't know:

• Whether the peak lives in Phase 2 (in-flight pipelines), Phase 3 (parsed ACE list), Phase 4 (caches), Phase 5 (index), or Phase 6 (pivot accumulator).
• Whether the heap is managed-side dominant or process-side (unmanaged buffers, AD assembly internals).
• Whether GC is collecting at all (gen-2 count tells us).

Speculate-fixing into that unknown is how engineering teams build the wrong solution well. Measure first.

ADR-029 in the vault project notebook captures the rationale.

Verification

• Invoke-Build -Configuration Release — clean, 150 tests pass / 0 failed / 1 skipped, coverage 93.01% (gate 86% per ADR-026).
• Hand run against unreachable.invalid (LDAP bind fails as expected, exit 1) — first PhaseStart event in the JSONL carries data.memory with all 6 fields populated.

Follow-up

Phase C of the reconciliation plan: controlled re-run protocol on the work computer using this instrumentation. Phase D selects targeted optimisations from the captured data.

Notes

• No behaviour change. Helper is read-only — no GC.Collect, no Process.Refresh, no side effects.
• No new dependencies. System.GC and System.Diagnostics.Process are already loaded.
• The ADR lives in the vault project notebook (../decisions.md) under the dual-track workflow, not in this repo.