From 9562fa793028d1eb7028242fffba6a1b54e65019 Mon Sep 17 00:00:00 2001 From: Levi Neuwirth Date: Tue, 18 Aug 2026 11:10:31 +0200 Subject: [PATCH] docs(lane): the sweep-crdt red is pre-existing on main Attribution is settled. The identical `build-crdt && sweep-crdt` pair, run at the merge base 72da24a in the primary worktree with its own target dir, fails the SAME test: 119 binaries green, one red, `ctrl_c_on_launcher_group_does_not_reach_spawned_daemon`. This branch is not implicated, and no branch can pass this gate stage on this machine until the underlying defect is fixed --- main included. The mechanism is unknown, and this records two explanations I offered and then refuted, so nobody re-runs them: - Load: refuted. Red on a quiet machine, load 2.77 at launch. - Memory pressure: refuted by correcting my own instrument. The sampler showed free memory at 543MB, which looked damning, but it recorded `free` --- not the meaningful figure on Linux. `available` was 27G. The 543MB was reclaimable cache. I had already reported the memory story before checking that, which was wrong. - Leaked daemons: refuted. Peak 58, up only 8 during the sweep, and the green standalone runs already ran at 46-50. What the bisect did establish: green in every smaller context tried --- the test alone three times at 0.15s against its own 5s deadline, its whole suite, a workspace run filtered to just it, the lib binary then the suite, and the three GPU suites in sweep order --- and red 4/4 in the full workspace sweep across two trees. Cumulative across the 37 binaries preceding it, and not flaky. Also notes that /tmp is a 30G tmpfs holding 21G of an unrelated project's stale target directories. Recorded as an observation about this machine, not as the cause, and not touched. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai --- docs/active-work.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/active-work.md b/docs/active-work.md index d92e53e..5cd4d9c 100644 --- a/docs/active-work.md +++ b/docs/active-work.md @@ -471,6 +471,43 @@ from #171 and #215. (2026-08-15, plain `cargo test --lib`, not a gate step). Isolated rerun green. Same budget as the occurrence above, now seen in two different selectors on one branch in one day. + - **RESOLVED ATTRIBUTION: the sweep-crdt red is PRE-EXISTING ON + MAIN.** The identical `build-crdt && sweep-crdt` pair run at the + merge base **`72da24a`**, in the primary worktree with its own + target dir, fails the SAME test: 119 binaries green, one red, + `ctrl_c_on_launcher_group_does_not_reach_spawned_daemon`. **This + branch is not implicated**, and no branch can pass this gate stage + on this machine until the underlying defect is fixed. + - **The MECHANISM is unknown, and two plausible explanations were + tested and REFUTED.** Recorded so nobody re-runs them: + - *Machine load*: refuted. Red on a quiet machine (load 2.77 at + launch, foreign workload gone). + - *Memory pressure*: refuted, **by correcting my own instrument**. + A sampler showed free memory falling to 543 MB and that looked + damning — but it recorded `free`, which on Linux is not the + meaningful figure. `available` was **27 G**. The 543 MB was + reclaimable cache. + - *Leaked daemons*: refuted. Peak 58 during the sweep, up only 8 + from the resting 50, and the green standalone runs already ran + at 46-50. + - **What the bisect DID establish.** Green in every smaller context + tried, and deterministic in the largest: the test alone (x3, 0.15s + against its 5s deadline); its whole 15-test suite; a + workspace-wide run FILTERED to just this test; the lib binary + (2145 tests) followed by the suite; and the three GPU suites in + sweep order. Red 4/4 in the full workspace sweep, across two + different trees. So it is cumulative across the 37 binaries that + precede it, and it is **not** flaky. + - **`/tmp` is a 30G tmpfs holding 21G**, almost all stale + `levshell-*-target` cargo directories belonging to an unrelated + project, 3-4 days old. Recorded as an observation about this + machine, **not** as the cause — `available` memory refutes that. + Not touched: they are not this project's to delete. + - **The earlier signature entry below overstated its case** and is + kept only for its measurements. It read the isolation runs as + proof of an environmental cause; they establish intermittence at + most, and the base-comparison above is what actually settled + attribution. - **`ctrl_c_on_launcher_group_does_not_reach_spawned_daemon`, a NEW signature, red TWICE and reproducibly** (2026-08-16, logs `20260816T063330Z` and `20260816T064549Z`, step `09-sweep-crdt` @@ -551,6 +588,11 @@ from #171 and #215. establishing an environmental cause, and no experiment here separated sweep contention, foreign load, and a genuine defect in the row. Do not record it as environmental until something does. + - **The gate cannot pass on this machine for ANY branch**, main + included, until the pre-existing sweep-crdt defect is fixed. That + is a decision point, not a thing to keep re-running: either the + defect gets its own lane, or this lane's readiness bar is restated + against a gate that main itself can pass. - **Clean evidence is not obtainable on this machine right now** — an unrelated `turso` workload (`./verify_task_state.sh turso-without-rowid`, target `/opt/target`)