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 115f6ad4..5ac1c4c2 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
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-08
 located-in: [mesh-controller cmd/mesh-controller (release_plan.go, nextRollout and failFirstSend)]
-fixed-by:
+fixed-by: mesh-controller#165, mesh-lab#72
 replay: R335
 amended-design:
 ---
@@ -37,8 +37,8 @@ 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`). 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.
+passed (see `01-diagnosis.md`). The fix merged in mesh-controller pull request 165 (8170fc5), with its
+replay in mesh-lab pull request 72.
 
 - Once a module's gate has passed, the first machine's later reports no longer decide anything about it:
   the walk sends the rest.