[P0] Establish the causal local-resource boundary and complete #654 qualification

[mohanagy]

Parent: #654
Target branch: next
Depends on: #689 merged, #690 completed
Blocks: #654 completion, merge of #681 and #680, and start of #657
Milestone: v0.33.0-beta.1 — Trust Foundation

Outcome

Close the remaining evidence gap in #654 by proving, with controlled and reproducible experiments, whether the local forks-worker startup failures are caused by shared-host resource contention rather than a repository defect that also affects isolated protected runners.

This issue is the final qualification gate for #654. It is primarily an evidence and reliability task. It may produce a narrowly scoped diagnostics/documentation PR when required, but it must not invent a code change merely to create a pull request.

Current confirmed state

The following work is already complete or pending merge:

• PR test: fail ordinary Vitest commands on absorbed worker-start errors #691 / issue [P0] Make ordinary Vitest commands fail on absorbed worker-start failures #690 introduced guarded ordinary npm run test:run and npm run test:coverage commands. They fail when raw Vitest logs contain:
  • Failed to start forks worker
  • Timeout waiting for worker to respond
    even if Vitest later exits zero.
• PR test(watch): make adaptive backoff assertions deterministic #692 / issue [P0] Replace uncontrolled wall-clock assertions in watch and refresh tests with deterministic scheduling #689 removes the scheduler-sensitive watcher/backoff assertions and has passed the complete six-lane protected matrix after rebasing onto test: fail ordinary Vitest commands on absorbed worker-start errors #691.
• On the shared local host, the guarded commands detected 13 worker-start failures and 13 handshake timeouts across 13 unrelated files while approximately 164 Node processes were active.
• On the identical test(watch): make adaptive backoff assertions deterministic #692 commit, all six isolated GitHub Actions lanes completed with zero occurrences of either signature.
• Earlier dedicated-runner evidence also showed zero occurrences across repeated CI matrices.

The remaining uncertainty is causal: the local/shared-host distinction is strongly supported, but it has not yet been demonstrated through a controlled quiet-versus-contended experiment on the same commit and environment.

Required question

Determine whether this statement is supported:

On a supported, isolated environment, Madar's authoritative guarded complete-suite commands complete without worker-start signatures; the reproducible local failures occur when unrelated concurrent Node/Vitest workloads starve Vitest's forks-worker startup handshake.

Do not broaden the claim beyond the collected evidence.

Step 1 — Freeze the qualification identity

Use one exact next commit after #689 and #690 are merged.

Record:

• commit SHA;
• OS and architecture;
• Node version;
• npm version;
• exact package-lock.json SHA-256;
• CPU core count;
• physical/logical memory;
• free memory before each run;
• process count;
• Node/Vitest process count;
• relevant ulimit/process limits;
• Vitest worker configuration;
• command;
• environment variables affecting Vitest/Node;
• raw log path and checksum.

Do not compare runs from different commits or lockfiles as if they were one experiment.

Step 2 — Define the experiment before running it

Pre-register at least these conditions on the same supported local host:

A. Quiet baseline

• no unrelated repository agent task;
• no unrelated Node/Vitest process;
• normal foreground services only;
• maxWorkers: 4 unchanged;
• guarded test:run and test:coverage.

B. Controlled external Node contention

Create an explicit, reversible load outside the Madar process. Prefer a small repository-controlled or temporary harness that can vary:

• number of competing Node processes;
• CPU duty cycle;
• optional memory pressure within safe machine limits;
• duration.

Do not use arbitrary background applications as the only contention source.

C. Controlled worker-count diagnostic

Run the same suite under worker counts 1, 2, and 4 for diagnosis only.

Do not change the repository's supported default merely because a lower diagnostic setting succeeds.

D. Recovery condition

After removing controlled contention, rerun the exact guarded commands and prove the environment returned to the quiet result.

The minimum experiment should demonstrate an A → B → D pattern on the same commit. Repeat enough times to distinguish a causal relationship from one coincidental pass/failure.

Step 3 — Measure the worker-start boundary

For every run capture:

• child command exit code;
• guard exit code;
• worker-start signature count;
• handshake-timeout signature count;
• affected test files;
• whether affected files pass alone;
• total test files and assertions;
• test duration;
• peak RSS where practical;
• CPU/load average where practical;
• total process count;
• Node/Vitest process count;
• whether the process terminates cleanly;
• unrelated assertion failures;
• retained log path and checksum.

Vary controlled contention gradually where practical and identify the smallest observed load at which failures appear.

Do not claim a universal threshold from one machine. Report it as the observed boundary on the recorded host.

Step 4 — Prove the protected-runner distinction repeatedly

On the same exact commit, run at least three complete protected six-lane matrices:

Ubuntu × Node 20
Ubuntu × Node 22
macOS × Node 20
macOS × Node 22
Windows × Node 20
Windows × Node 22

For every lane and attempt report separately:

• job conclusion;
• guarded test command used;
• guarded coverage command used where applicable;
• worker-start signature count;
• handshake-timeout signature count;
• test and coverage exit statuses;
• log readability marker;
• injected/control-signature detection result.

A green job conclusion is insufficient without raw-log inspection.

Step 5 — Resolve the Node/npm support statement

The audited reference named npm 12.0.1, while current validated work uses npm 12.0.2 with the same lockfile.

Document the supported merge identity as:

• supported Node 20/22 patch lines that satisfy the locked toolchain;
• exact lockfile checksum;
• npm 12.0.1 audited reference;
• npm 12.0.2 accepted only when npm ci succeeds without mutating the lockfile and all protected gates pass.

Do not claim support for every npm patch version.

Update documentation only when current wording is inconsistent.

Step 6 — Re-evaluate every #654 acceptance criterion

Create a final matrix:

#654 acceptance criterion	Evidence	Result

#654 remains open until all of the above are satisfied.

In particular:

• root cause must be stated at the strength supported by the controlled experiment;
• no worker-start error may occur in the accepted quiet/reference and protected qualification runs;
• no unexplained timeout/nontermination may remain;
• the complete guarded commands must be the one authoritative suite contract;
• original and corrected logs must be retained;
• supported Node/npm/lock documentation must agree.

Permitted outcomes

Outcome A — causal local-resource distinction proven

#654 may be closed when:

• quiet A and recovery D are repeatedly clean;
• controlled B reproducibly introduces the signature;
• isolated protected matrices are repeatedly clean;
• no unexplained repository-level failure remains;
• every acceptance criterion is satisfied.

Outcome B — quiet local run still fails

Keep #654 open.

Investigate the reproducible repository or host-specific cause; do not attribute it to unrelated contention without evidence.

Outcome C — controlled contention does not affect failure rate

Keep #654 open and reject the current causal hypothesis.

Outcome D — local experiment cannot be isolated credibly

Use repeated protected matrices as the supported merge environment, document the local host as unsuitable for qualification, and obtain an additional clean dedicated local/VM runner before closing #654.

Do not lower the closure standard merely because the developer workstation cannot be isolated.

Explicit non-goals

• No graph, retrieval, Pack, extraction, MCP, installer, or release behavior changes.
• No retries.
• No timeout inflation.
• No test skip/quarantine.
• No permanent worker reduction.
• No benchmark/product claim work.
• No [P0][Graph PR B] Add deterministic semantic multigraph storage and artifact v2 #657 implementation.
• No merge of feat(qualification): freeze the independent qualification contract (#655) #681 or feat(graph): PR A — plural relationship queries and explicit topology APIs (#656) #680 before [P0] Stabilize the complete Vitest suite and protected CI merge gate #654 is complete.
• No beta tag or npm publication.
• No general performance optimization unrelated to the worker-start boundary.

Validation

At minimum, on the frozen commit:

npm ci
npm run typecheck
npm run build
npm run test:run
npm run test:coverage
npm run verify:pack-parity
npm pack --dry-run
npm run registry:validate
npm run release:verify

Run affected historical files independently and in the previously failing groupings.

Every full run must use the guarded commands and retain raw evidence.

Acceptance criteria

• One exact commit and lockfile identity is used for the final qualification.
• Quiet-host and controlled-contention conditions are pre-registered and reproducible.
• The same host demonstrates a clean → failing-under-contention → clean-after-contention pattern, or an additional dedicated local/VM runner supplies the missing clean-host evidence.
• The causal claim is limited to what the experiment proves.
• Three complete protected six-lane matrices pass on the exact commit.
• Raw logs show zero known worker-start signatures in every accepted protected lane.
• Control samples prove raw-log scanning was active in every attempt.
• No unexplained timeout, nontermination, or unrelated assertion failure remains in accepted qualification runs.
• Historical affected files pass alone and in representative groupings.
• Node/npm/lock documentation matches validated reality.
• One authoritative guarded complete-suite command contract is documented and used by protected CI.
• Original failure logs and final evidence receipts are retained and linked.
• Every [P0] Stabilize the complete Vitest suite and protected CI merge gate #654 acceptance criterion is mapped to evidence and satisfied.
• [P0] Stabilize the complete Vitest suite and protected CI merge gate #654 is closed only after the complete matrix is reviewed.
• No unrelated roadmap scope enters the work.

Rollback

This issue should not require a product rollback. Revert any diagnostics-only repository change that proves unreliable while retaining the evidence artifacts and issue record. Never revert the guarded commands merely because they expose a real environmental failure.

Agent handoff

Start only after #689 and #690 are merged into next. Use one isolated worktree and one exact commit. Reserve exclusive access to heavy local runs. Stop unrelated local agents and test processes before quiet qualification. Pre-register the experiment, run quiet and controlled conditions, retain all logs, inspect raw protected CI logs, and return the final #654 criterion matrix. Do not begin #657 or merge #681/#680. Stop after the #654 closure decision.

[mohanagy]

Pre-registered experiment plan (written before any qualification run)

Recording this before executing, so the contention levels and success criteria cannot be chosen after seeing results.

Frozen qualification identity

Field	Value
Commit	b1300f8fcc2758404abc5e6064433c4d8b2ab40b (next, after #689 and #690)
OS / arch	Darwin 25.3.0, arm64
Node	v22.22.3
npm	12.0.2
package-lock.json SHA-256	0144eb0ddf92f78c69f10089d0e0414485594966ff5be4f36f655c7aa5cff53e
CPU	16 physical / 16 logical
Memory	48 GiB
ulimit -n	1048576
ulimit -u	8000
Vitest	forks pool, maxWorkers: 4, no retry
Worktree	isolated, clean

All runs use this one commit and lockfile.

What "quiet" means on this host, stated honestly

This host cannot reach zero Node processes: the orchestration session itself runs MCP servers, and a desktop editor and chat client are resident. Measured baseline:

• 1,172 total processes; 324 are Node
• 0 Node processes above 1% CPU
• 0.2% aggregate Node CPU out of a possible 1600%
• ~76% CPU idle, 43% memory free
• 0 Vitest processes

So the resident Node processes are idle stdio-blocked infrastructure, not CPU competitors. Rather than claim an unattainable zero-process condition, condition A is defined as: no Vitest process, no concurrent repository work, aggregate Node CPU under ~1%, and no other command issued by this session during the run. Every remaining process is accounted for as agent infrastructure, editor, or system service.

If quiet A still fails under that definition, this host will be declared unsuitable and the standard will not be lowered — see Outcome D.

Conditions

A — quiet baseline. Guarded test:run, then guarded test:coverage, at the repository default maxWorkers: 4, with no other activity from this session.

B — controlled external Node contention. A temporary harness outside the repository spawning N busy-loop Node processes at full duty cycle for the duration of the run, with a cleanup trap. Levels attempted in ascending order and all recorded regardless of outcome: N = 4, 8, 16, 32. The smallest N at which signatures appear is reported as the observed boundary on this host only — not as a universal threshold.

C — worker-count diagnostic. maxWorkers 1, 2, 4 under the same contention level. Diagnostic only; the repository default will not change because a lower count survives.

D — recovery. After killing the load and verifying zero remaining harness processes, repeat condition A exactly.

Causal criterion, fixed in advance

The hypothesis is supported only if A clean → B reproducibly dirty → D clean, with A and D each repeated so a single coincidental pass cannot carry the conclusion. If B does not raise the signature rate, the contention hypothesis is rejected and #654 stays open. If A fails, the host is unsuitable and #654 stays open.

Capture per run

Condition, commit, command, exit code, guard result, both signature counts, affected files, test totals, duration, load average, free memory, total/Node/Vitest process counts, worker count, clean termination, retained log path and its SHA-256. Failed runs are retained, not discarded, and no run will be repeated until green and then reported alone.

Non-goals reaffirmed

No retries, no timeout inflation, no permanent worker reduction, no skips, no product change, and no weakening of the guarded runner merged in #690.

[mohanagy]

Experiment executed — the contention hypothesis is refuted

Four complete guarded runs on the frozen commit b1300f8fcc2758404abc5e6064433c4d8b2ab40b, following the plan pre-registered above. The pre-registered causal pattern A → B → D was not obtained, and the result contradicts the hypothesis this issue set out to confirm.

Results

Run	Condition	Pre-run aggregate Node CPU	Pre-run load	Exit	Failed to start forks worker	Timeout waiting for worker to respond	Files failed	Duration
A1	quiet, test:run	47.8%	11.35	1	16	16	4	609 s
A2	quiet, test:coverage	0.1%	2.54	1	20	20	1	547 s
A3	quiet repeat, test:run	152.4%	3.84	1	13	13	1	452 s
B16	16 busy Node processes, test:run	1471.7%	5.21	1	14	14	2	612 s

Raw logs retained with SHA-256: A1 57ddfa19…, A2 c1fceb c3…, A3 448b1069…, B16 efc8ba7f…. No run was discarded, and no run was repeated until green.

What this shows

Quiet condition A failed. A2 began with 0.1% aggregate Node CPU and a load average of 2.54 on 16 cores — quiet by the definition pre-registered before any run — and produced 20 occurrences of each signature, the highest count of the four.

Controlled contention did not increase the failure rate. B16 saturated the host at 1471.7% aggregate Node CPU across 16 competing busy-loop processes and produced 14 occurrences — fewer than the quietest run. Across a load range spanning four orders of magnitude (0.1% → 1471.7%), the signature count stayed in a narrow band of 13–20.

This satisfies Outcome B (quiet run still fails) and Outcome C (controlled contention does not change failure behavior) simultaneously. Both require that #654 stay open and the causal conclusion be rejected.

Correction to earlier conclusions in this roadmap

Earlier waves — including analysis I posted myself — treated concurrent Node workloads as the well-supported explanation, citing an lsof observation of competing processes and the 0-of-18 versus 6-of-6 contrast. That inference does not survive a controlled test. The correlation was real; the causation was not. Load and failure rate are effectively independent on this host.

What still holds

• The host-versus-isolated-runner distinction is unchanged. The identical commit is 0/0 clean across all six protected lanes, repeatedly, while this host has never produced a clean guarded complete-suite run.
• The guard merged in [P0] Make ordinary Vitest commands fail on absorbed worker-start failures #690 is working exactly as designed — it detected 63 signatures across four runs that would previously have been buried under a summary line.
• Ruled out on this host: file-descriptor limits (ulimit -n 1048576) and per-user process limits (ulimit -u 8000 against 846 current user processes).
• The affected file set is different in every run. Since a worker-start failure is the pool failing to spawn a worker for a file, it is independent of that file's content — consistent with the randomness observed since the original investigation.

Remaining uncertainty, stated plainly

The mechanism is unknown. It is reproducible on this macOS arm64 host irrespective of CPU load, and absent on Ubuntu, macOS, and Windows GitHub-hosted runners. Whether it is specific to this machine, to this OS/architecture combination, or to a resident-process condition that CPU metrics do not capture is not established by this experiment.

Recommended next step

Per Outcome D, obtain a dedicated clean VM or ephemeral local runner and reproduce the same frozen commit and lockfile there. That single experiment distinguishes the two live possibilities — a defect specific to this workstation, versus something reproducible on any comparable macOS/arm64 environment — and it is the shortest path to either completing #654 or correctly scoping the remaining defect.

Protected CI alone is not sufficient grounds to mark #654 done; isolated runners prove the supported integration environment is clean, not that the local failure is understood.

Worker-count diagnostic C and recovery condition D were not run: with A failing and B showing no effect, the A → B → D pattern is unreachable, and further local permutations cannot rescue a hypothesis the data has already rejected. That deviation from the pre-registered plan is recorded here rather than silently omitted.

#654 remains open.

[mohanagy]

Diagnostics run 31718841614 is invalidated for final qualification — workflow defect, not an environment result

The defect

The cleanup-verification step I wrote used:

set -euo pipefail
IDLE=$(pgrep -f 'idle-load.mjs' | wc -l | tr -d ' ')

pgrep exits 1 when it correctly finds no matching process. Under pipefail that status propagates through the pipeline, and under set -e the command substitution aborts the step. So the step could only fail: zero survivors aborted it, and surviving processes tripped the explicit non-zero check.

Reproduced locally before changing anything:

IDLE=$(pgrep -f "definitely-no-such-process-xyz" | wc -l | tr -d " ")   → exit 1, step aborts
pgrep -f "…" > file 2>/dev/null || true; IDLE="$(wc -l < file)"          → exit 0, IDLE=0

Consequence in the real run: Verify load cleanup before recovery failed on attempts 1 and 2, and both D — recovery steps were skipped. Condition D was unreachable, so the run cannot satisfy the A → B → D contract and is not counted as one of the three accepted VM attempts.

This is a defect in my diagnostics workflow. It is not a test failure, not an environment result, and not evidence about Madar.

Preliminary observations from the invalidated run — recorded, not counted

Attempt 1 reached A, B1 and B2 before the defective step. Runner identity verified as Darwin 25 arm64, 3 logical CPUs, 7 GiB — note this is a far smaller machine than the 16-core/48 GiB workstation.

Condition	Node CPU before	Exit	Worker-start	Handshake
A quiet test:run	0.0%	0	0	0
A quiet test:coverage	0.0%	0	0	0
B1 — 64 idle Node processes	0.0%	0	0	0
B2 — CPU saturated (293% aggregate)	293%	0	0	0

Toolchain, lockfile, checkout cleanliness, and the scanner positive control all passed. These are preliminary only, because the run never reached recovery.

Corrections applied

Confined entirely to the diagnostics workflow; the frozen source under test is unchanged at b1300f8fcc2758404abc5e6064433c4d8b2ab40b, with zero non-workflow files touched.

• Survivor counting redirects pgrep to a file and swallows its exit code, so a correct zero-survivor result is a normal success.
• Load liveness is proven with kill -0 against the PID file rather than counting intended PIDs. Expected versus live counts and the live PID list are recorded, and a B condition is explicitly marked invalid when the intended load was not established.
• B1 and B2 carry cleanup traps, so load is removed even if the guarded suite or metadata collection fails; live PIDs are re-counted after cleanup.
• Signature counts now come from the raw guard log when it survives. On a dirty run the wrapper echoes matching lines into its own report, so the outer transcript overcounts. Demonstrated on a fixture: the same single event counts 1 in the raw guard log and 3 in the outer transcript. The metadata records signature_source, both counts, and both checksums; a clean run whose guard log was deleted falls back to the outer log.
• Isolated historical files now record handshake signatures and a readable marker, not just worker-start counts.
• Every generated helper is syntax-checked in-workflow.

Ten deterministic shell probes were run locally before pushing: zero-match counting, single live PID, idle and busy cleanup, stale-PID invalidation, guard-log versus outer-log source selection, both-signature recording, and bash -n.

A second finding, caught by the repository's own guard

CI failed on all six lanes for the first corrected head because tests/unit/vitest-guard-policy.test.ts — "contains no raw vitest run invocation in any workflow" — flagged this workflow's npx vitest run in the isolated historical-file step.

That test, added by #690, correctly caught a real violation in a file this branch introduced. It was not weakened. The isolated runs now go through npm run test:run -- <path>, which keeps them single-file while also applying the canonical scan. The policy test passes locally at the new head.

Status

• Invalidated diagnostics run: 31718841614
• Corrected workflow-control head: 173bc6913a7e0538d8f352da7add5fd0a1aac843
• Frozen source under test: unchanged
• Protected matrix attempt 1 (31711572439, run_attempt 1): six lanes clean, 0/0, control-verified
• Protected matrix attempt 2 (31711572439, run_attempt 2): six lanes clean

No result was discarded or misreported as accepted evidence. #693 and #654 both remain open.

[mohanagy]

Protected matrix attempt 3 is not clean — a different failure class, newly surfaced

Attempt 3 of run 31711572439 on the frozen commit b1300f8f failed on one lane.

Attempt	Result	Worker-start	Handshake	Control
1	six lanes clean	0	0	verified
2	six lanes clean	0	0	verified
3	windows-latest Node 22 failed; other five clean	0	0	verified

This is not the #654 symptom. Raw-log signature counts across the whole attempt-3 archive are 0 / 0, with an injected-sample control confirming the search was live. No worker-start or handshake signature occurred.

The failure is a test timeout:

FAIL tests/unit/workspace.test.ts > worktree artifact routing >
     keeps a linked worktree graph outside the source checkout and isolated from the primary checkout
Error: Test timed out in 20000ms.

Why this matters for closure

Two criteria are now unmet, and neither can be argued away:

• [P0] Establish the causal local-resource boundary and complete #654 qualification #693 requires three clean protected six-lane matrices on the frozen commit. Two are clean; the third is not.
• [P0] Stabilize the complete Vitest suite and protected CI merge gate #654 requires that no unexplained timeout or nontermination remain. This is an unexplained timeout inside a protected qualification run.

So #654 cannot complete on the current evidence regardless of how the macOS 26 VM qualification concludes.

Character of the new failure

This looks like the same family #689 addressed — a wall-clock bound on an operation whose duration the test does not control — but in a different test and not covered by that work. The operation is git-worktree manipulation, which is materially slower on Windows filesystems, and the bound is a fixed 20 s.

It appeared on attempt 3 of an otherwise identical commit, so it is intermittent rather than deterministic. It did not appear in attempts 1 or 2, nor in the earlier post-merge matrices on this commit.

I am recording it rather than re-running until it passes. Re-running until green and reporting only the green attempt is precisely the failure mode this issue exists to prevent.

Recommendation

Treat this as a separate defect in the same class as #689 rather than folding it into #654's causal question. It needs its own reproduction, its own timing-assumption analysis, and its own fix — the pattern established by #689 applies directly: replace the fixed wall-clock bound with an observable barrier, or prove the operation genuinely cannot exceed the bound on supported platforms.

#693 and #654 both remain open.

[mohanagy]

The corrected macOS 26 ARM64 qualification may continue to establish its environment boundary, but it can no longer produce the complete #654 decision by itself.

Protected matrix attempt 3 independently exposed a Windows Node 22 timeout in tests/unit/workspace.test.ts with zero canonical worker signatures. Detailed follow-up is now tracked in #695.

Interpret #693 only for the frozen macOS ARM64 boundary. Even when all accepted A/D VM conditions are clean, #654 remains open until #695 is complete and three clean exact-commit protected matrices exist. Do not rerun the failed Windows matrix until green and treat only the rerun as evidence.

[mohanagy]

Corrected VM qualification complete — fresh macOS 26 ARM64 baseline is clean

Run 31722725288 on workflow-control head 173bc691, testing frozen source b1300f8fcc2758404abc5e6064433c4d8b2ab40b. All three matrix attempts completed on separately provisioned macos-26 VMs, max-parallel: 1.

Identity — verified independently from the artifacts, not from step conclusions

Identical across all three attempts: arch=arm64, darwin_major=25, 3 logical CPUs, 7 GiB; tested source commit equals the frozen SHA; Node v22.22.3; npm 12.0.2; lock 0144eb0d…; 0 dirty files after npm ci.

Scanner positive control — all three attempts

Poisoned sample rejected with scanner exit 1, direct counts forks=1 handshake=1. Zero counts below are therefore proven, not assumed.

Conditions

Attempt	Condition	Status	Signature source	Worker-start	Handshake	Duration
1	A quiet test:run	0	outer_log	0	0	188 s
1	A quiet test:coverage	0	outer_log	0	0	347 s
1	B1 — 64 idle Node processes	1	guard_log	0	1	179 s
1	B2 — CPU saturation	0	outer_log	0	0	277 s
1	D recovery test:run	0	outer_log	0	0	175 s
1	D recovery test:coverage	0	outer_log	0	0	350 s
2	A quiet test:run	0	outer_log	0	0	173 s
2	B1 — 64 idle	0	outer_log	0	0	169 s
2	B2 — CPU saturation	0	outer_log	0	0	266 s
2	D recovery test:run	0	outer_log	0	0	160 s
3	A quiet test:run	0	outer_log	0	0	159 s
3	B1 — 64 idle	0	outer_log	0	0	167 s
3	B2 — CPU saturation	0	outer_log	0	0	294 s
3	D recovery test:run	0	outer_log	0	0	227 s

Load validity was proven rather than assumed: B1 recorded expected=64, live=64, condition_valid=true and B2 expected=3, live=3, condition_valid=true on every attempt. Cleanup recorded 0 idle survivors and 0 busy survivors before every recovery condition, so each D ran on a genuinely unloaded VM.

The one dirty condition

Attempt 1's B1 produced one handshake-timeout occurrence and failed the guarded command. Note its signature source is guard_log — the dirty run retained its guard log, which is exactly the sourcing correction made after the first invalidated run, and it prevents the wrapper's own echoed diagnostics from inflating the count.

That is a 1-of-3 partial reproduction with a single occurrence, against a workstation that produces 13–20 occurrences in every run including quiet ones. B2 CPU saturation stayed clean on all three attempts, consistent with the workstation experiment that already rejected CPU contention.

Environment-boundary verdict, stated narrowly

The frozen commit is clean on repeated fresh macOS 26 ARM64 VMs: quiet A and recovery D passed on all three attempts, with coverage additionally clean on attempt 1, under proven scanner controls and verified cleanup.

Simple CPU saturation does not reproduce the symptom on a fresh VM. A high idle-process count reproduced it once in three attempts, at one occurrence — enough to suggest process pressure is weakly contributory, nowhere near enough to explain the workstation's behaviour, and notably absent from the workstation's own quiet runs where the load was 0.1% Node CPU.

The exact workstation mechanism remains unknown. CPU contention is not the root cause, and this evidence does not name a replacement.

Why this issue stays open

• [P0] Replace the Windows worktree artifact-routing wall-clock timeout with deterministic phase evidence #695 independently blocks [P0] Stabilize the complete Vitest suite and protected CI merge gate #654: the Windows linked-worktree timeout is unresolved.
• Three accepted clean protected six-lane matrices do not yet exist — attempt 3 on the frozen commit failed one lane on that Windows timeout.
• [P0] Stabilize the complete Vitest suite and protected CI merge gate #654's own criteria are therefore not satisfiable yet.

Artifacts (30-day retention): 9190956427 (attempt 1, 316,251 B), 9191426689 (attempt 2, 203,586 B), 9191949071 (attempt 3, 202,755 B), each containing per-condition raw and outer logs, metadata, process and memory snapshots, and SHA256SUMS.txt.

#693 and #654 both remain open.