docs: U2 has a second occurrence, and this time the fragments were read

The worker-identity tip gate went red on step 03-lib with one failure:
m6_1_pty_raw_mode_disables_kernel_echo. U2 already had that exact
selector but no fragments, so it could not be matched. Reading the
durable gate log rather than filtering a rerun supplies them.

The fragment reframes the failure. stty -a returned the EMPTY STRING,
not a wrong mode --- so this is not raw mode failing to disable echo,
it is stty producing no output at all, which points at PTY or spawn
readiness under load rather than termios handling. The assertion own
message is misleading on exactly that point, and anyone diagnosing it
from the message will look in the wrong place.

Occurrence 2 also EXCLUDES the change under test, which occurrence 1
could not. The tree carried zero code change since a 13/13 green run on
this same lane --- the only delta was three lines of markdown. A docs
edit cannot break a PTY test, so the diff is ruled out as a cause
rather than merely doubted. Isolated rerun passes in 0.01s.

Still no mechanism, and the row says so. Two occurrences establish
intermittence and a load correlation; neither establishes cause. The
row now names the discriminating control for a third: loop the selector
under synthetic load logging stty output every iteration, since whether
stty is empty EVERY time it fails is what separates a readiness race
from a termios one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
This commit is contained in:
Levi Neuwirth 2026-08-09 22:40:54 +02:00
parent 80b3dcf897
commit 7675142d4f
No known key found for this signature in database
1 changed files with 12 additions and 7 deletions

View File

@ -570,19 +570,24 @@ the lane's only `pmacs-gpu` addition is the arm that went red.
The next agent to touch this row should reproduce at 1-in-10 and
instrument which side closes the pipe, rather than re-running for green.
### U2 — `m6_1_pty_raw_mode_disables_kernel_echo`, one local occurrence
### U2 — `m6_1_pty_raw_mode_disables_kernel_echo`, SECOND occurrence; fragments captured
Has a selector, which U1 lacks — but still no fragments, so it cannot
be matched either. Recorded so a recurrence is recognisable.
Recorded first with a selector but **no fragments**, so it could not be
matched. The second occurrence (2026-08-09, worker-identity lane) was
read from the durable gate log rather than a filtered rerun, so the row
is now matchable — and the fragment changes what the failure looks
like.
| field | value |
|---|---|
| **selector** | `--lib process::tests::m6_1_pty_raw_mode_disables_kernel_echo` |
| **job / flavor** | local (Linux), during `cargo test --tests --no-fail-fast` — the lib target alongside a full PTY-heavy corpus |
| **required fragments** | **none captured** — output was filtered to the `FAILED` line |
| **status** | **new incident, unreproduced** |
| **what IS established** | it failed once (`1916 passed; 1 failed`), in no registry row, under a full-corpus run |
| **what is NOT** | any mechanism. Not reproduced in a later full `--tests --no-fail-fast` sweep (108 targets, exit 0) nor in 3 isolated `--lib` runs (1917/0 each) |
| **required fragments** | `panicked at src/process.rs:3953` · `raw mode should disable echo; stty -a output was: ""`**captured on occurrence 2** |
| **status** | **two occurrences, load-correlated; the diff is EXCLUDED on occurrence 2** |
| **what IS established** | Occurrence 1: failed once (`1916 passed; 1 failed`) under a full-corpus run. Occurrence 2: `1919 passed; 1 failed` in `scripts/gate` step `03-lib` at load ~21, and **the tree contained ZERO code change since a 13/13 green run on the same lane** — the only delta was three lines of `docs/active-work.md`. A markdown edit cannot break a PTY test, so the change under test is ruled out as a cause rather than merely doubted. Passes isolated (`1 passed`, 0.01s) |
| **what the fragment REFRAMES** | `stty -a` returned the **empty string**, not a wrong mode. So this is not "raw mode failed to disable echo" — it is `stty` producing **no output at all**, which points at PTY/spawn readiness under load rather than at termios handling. The assertion's own message is misleading on this point, and anyone diagnosing it from the message alone will look in the wrong place |
| **what is NOT** | any mechanism, still. Not reproduced in a later full sweep (108 targets, exit 0), nor in 3 isolated `--lib` runs (1917/0 each), nor in the isolated rerun after occurrence 2. Two occurrences establish intermittence and a load correlation; neither establishes cause |
| **discriminating control if a third lands** | run the selector in a loop under synthetic load with `stty -a` output logged on every iteration — the open question is whether `stty` is empty *every* time it fails, which would separate a readiness race from a termios one |
| **rival explanation not excluded** | leaked `pmacs --daemon` processes, which the handoff names as a standing confound for any load-sensitive local red |
### U3 — the R7 selector again, fragments lost the same way U2's were