fix(remediation): isolate soak/shadow tests from the production data dir (#3932)

[williamzujkowski]

Closes #3932.

Problem

The auto-remediation enforce-readiness gate reads the durable soak sink ~/.nexus-agents/learning/remediation-soak.jsonl (via summarizeRemediationShadow → soak.total → shadowSelections). The cycle's default soak sink (getRemediationSoakSink()) resolves under NEXUS_DATA_DIR, falling back to that home-dir file.

Which tests were writing to the real soak file

Only auto-remediation-cycle.test.ts. Two audit-mode cases called runAutoRemediationCycle({ mode: 'audit' }, ...) without injecting a soakSink, so buildSoakCollector fell through to the default durable singleton and persisted synthetic records into the operator's home-dir file:

• audit mode collects signals and runs the path → wrote routing:cli-floor:codex:docs
• forwards every collected signal to the run → wrote signalKeys a and b (the synthetic records the issue calls out)

Confirmed against the live file: 105 records, 70 of them synthetic a/b.

The other six soak/shadow/readiness test files were already isolated — they either use in-memory sinks (createRemediationShadowSink), inject an explicit temp-file createRemediationSoakSink(join(tmpdir(), ...)), or set NEXUS_DATA_DIR to a mkdtempSync dir + reset the singleton (auto-remediation-deps.test.ts, remediation-review-command.test.ts). The e2e test always injects a recording sink and uses throwaway git repos.

How they were isolated

auto-remediation-cycle.test.ts now pins NEXUS_DATA_DIR to a mkdtempSync temp dir for the whole suite (beforeEach/afterEach), with _resetRemediationSoakSinkForTests() on both ends and rmSync cleanup. This protects every case in the file — including future ones — regardless of whether they inject a sink. The writer already honors NEXUS_DATA_DIR via nexusDataPath('learning', ...) (learning is a cross-repo subdir; an explicit NEXUS_DATA_DIR overrides it), so no production-path threading was needed.

Regression guard

Added in the cycle test:

• getRemediationSoakFile() resolves under the temp NEXUS_DATA_DIR and not under ~/.nexus-agents — so a future test can't silently write to production.
• An audit cycle with no injected soakSink writes only under the temp dir and leaves the home-dir file's existence unchanged.

Sanity filter (added — defense-in-depth, the issue's preferred option)

readRemediationSoakSummary() now drops structurally-implausible records before summarizing, via the new isPlausibleSoakSignalKey / filterPlausibleSoakRecords. Real keys always carry the category:detail shape (routing:cli-floor:codex:docs, tech-debt:fitness-below-floor, …); the synthetic leaks were bare tokens (a, b, x). The check is conservative — it requires only the colon-delimited shape, not a known category enum — so no legitimate record (including future categories) is dropped. This means the readiness volume criterion can no longer be inflated by junk even if some leaked into the file historically.

Home-dir file

Per the issue, I did not clean the owner's real ~/.nexus-agents/learning/remediation-soak.jsonl — that runtime home-dir state is out of repo scope and the one-time cleanup is the owner's local action. Verified the file (105 lines, mtime 2026-06-17) was not touched by the test run after this change.

Gates

• tsc --noEmit clean; eslint clean on the 3 changed files; all 7 soak/shadow/readiness suites green (61 tests).
• Changeset .changeset/soak-test-isolation-3932.md ('nexus-agents': patch, fix). Zero any; no new MCP tool / CLI command; new exports consumed in-src (readRemediationSoakSummary → filterPlausibleSoakRecords → isPlausibleSoakSignalKey).

🤖 Generated with Claude Code