diff --git a/04-ISSUES/335-a-passed-gate-was-failed-by-the-first-machines-later-reports/00-report.md b/04-ISSUES/335-a-passed-gate-was-failed-by-the-first-machines-later-reports/00-report.md
index 97e327ec..115f6ad4 100644
--- a/04-ISSUES/335-a-passed-gate-was-failed-by-the-first-machines-later-reports/00-report.md
+++ b/04-ISSUES/335-a-passed-gate-was-failed-by-the-first-machines-later-reports/00-report.md
@@ -2,7 +2,7 @@
 status: located
 opened: 2026-10-08
 located-in: [mesh-controller cmd/mesh-controller (release_plan.go, nextRollout and failFirstSend)]
-fixed-by: mesh-controller#165, mesh-lab#72
+fixed-by:
 replay: R335
 amended-design:
 ---
@@ -37,17 +37,22 @@ build that worked, recorded it as failed, and so blocked its delivery until a ne
 ## Fix
 
 The controller judged the first machine's report again on every step of the walk, also after the gate had
-passed (see `01-diagnosis.md`). mesh-controller#165:
+passed (see `01-diagnosis.md`). The fix is proposed in mesh-controller pull request 165, with its replay in
+mesh-lab pull request 72; `fixed-by:` is filled when they merge.
 
-- once a module's gate has passed, the first machine's later reports no longer decide anything about it:
-  the walk sends the rest;
-- a module carried by another module's send takes over that pass before its step is read;
-- a walk stopped after a module's gate passed never puts that module back, and says what stopped it.
+- Once a module's gate has passed, the first machine's later reports no longer decide anything about it:
+  the walk sends the rest.
+- A module carried by another module's send takes over that pass before its step is read.
+- A guard, not reached with the two changes above: should a later path still stop a walk at a module whose
+  gate passed, that module is not put back and its build is not marked failed. The walk stops with the
+  reason, and the module is left sent to its first node only, which `plans retry` takes up again.
 
 ## How it is checked
 
 `TestReplay335` in the controller replays the live case with only what the controller had before the fix:
 a passed gate on the laptop, the laptop's later report not about this build (or a failure of another
-send), and the walk 30 minutes and 9 seconds after the first send. On the commit before the fix it fails
+send), and the walk 30 minutes and 9 seconds after the first send. A second test drives the walk over a
+tier of two modules, the second carried by the first's send, and fails if the carried module's step is read
+before it takes over the pass. On the commit before the fix it fails
 with "laptop did not report it applied within 30m0s", and the passed build reaches the put-back. It is R335
-in mesh-lab's replays register (mesh-lab#72), proved to fail before the fix and pass on it.
+in mesh-lab's replays register, proved to fail before the fix and pass on it.