diff --git a/FIX.org b/FIX.org
index 65916b0..599a708 100644
--- a/FIX.org
+++ b/FIX.org
@@ -1784,18 +1784,36 @@ reason, since review found the tagged types were sharing a line that was
 false for two of them — both arities, both no-expected-type positions, the
 byte's range, the pattern's range and the ~defconst~ rule.
 
-~dune test~ exits 1 on this branch roughly half the time, with *no FAIL line
+~dune test~ exits 1 on this branch about half the time, with *no FAIL line
 anywhere* — the ~Flan.Wire.Closed~ flake an earlier lane wrote up further up
-this file. Measured rather than assumed, because 2-of-2 early failures looked
-like mine: running ~test_dev.exe~ alone (15 seconds, not the ten-minute
-suite) gives 4 failures in 6 on this branch and *2 in 6 on a detached
-worktree at this branch's own base commit*, 1526b6f, with none of this lane
-in it. Same exception, same mechanism, and the difference is noise at that
-sample size.
+this file. Green runs are real (2 of the last 4 exit 0); the rest are that
+race.
 
-One detail worth adding to that earlier writeup, which said both observed
-failures landed on ~dev-trap-null-alloc~: it is not row-specific. Five of my
-six failures were that row and the sixth was ~dev-trap-free-all~, so what is
-racy is ~trap_park~ itself and every row that calls it, which is what the
-mechanism described there would predict. Per the sweep policy the ~@x86~ and
+*This lane makes it fire more often, and that is worth saying plainly rather
+than filing the whole thing under "known flake".* Measured, because early
+runs looked like the lane had broken something:
+
+| what                                  | full ~dune test~ |
+| base commit 1526b6f, none of the lane | 0 failures in 5  |
+| this lane                             | 5 failures in 5  |
+| this lane, my 3 acceptance rows off   | 1 failure in 3   |
+
+Isolated, ~test_dev.exe~ alone (15 seconds, not the ten-minute suite) gives 4
+in 6 here against 2 in 6 at the base — much closer, which is the shape you
+would expect if the lane is not touching the racy code but *is* changing the
+load around it. The three acceptance rows add three compile-and-run jobs to
+the pool that ~test_dev~ runs alongside, and a busier machine is slower to
+answer the poll that races.
+
+So: not a new defect, and nothing in ~check.ml~/~emit.ml~/~x86.ml~ here is
+implicated — but the next lane to add acceptance rows will push the rate up
+again, and the fix the earlier writeup already named (catch ~Closed~ in
+~trap_park~'s poll and read it as the program having ended) is now worth
+doing rather than noting.
+
+One detail to add to that earlier writeup, which had only seen the flake on
+~dev-trap-null-alloc~: it is not row-specific. Five of my six isolated
+failures were that row and the sixth was ~dev-trap-free-all~, so what is racy
+is ~trap_park~ itself and every row that calls it — which is exactly what the
+mechanism described there predicts. Per the sweep policy the ~@x86~ and
 ~@sanitize~ sweeps were not run here.