From f5c983cb389874995f1bc7fd48cf64456784e962 Mon Sep 17 00:00:00 2001
From: bingb0t5 <richard@rcnz.net>
Date: Mon, 24 Aug 2026 15:38:16 +0700
Subject: [PATCH] fix(test): settle Pi follow-up pane before the
 duplicate-captain-answer check

The adjacent-follow-up E2E case captured the tmux pane for its
duplicate-captain-answer assertion immediately after the session file
confirmed processing, with no settle wait, unlike every other
readiness check in this test. Sending two followUp deliveries queues
more Calm presentation work (an extra operational-user row plus its
hiding invalidation) than a single one, so the already-settled captain
answer's redraw could still be in flight at that instant, making the
check flaky. Poll the pane the same way the session-file wait already
does, and track the peak count seen along the way so a captain answer
that is genuinely rendered twice for even one frame still fails even
if a later redraw were to self-correct.
---
 tests/fm-calm-pi-extension.test.sh | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tests/fm-calm-pi-extension.test.sh b/tests/fm-calm-pi-extension.test.sh
index ad98a1e117..3fd765516e 100755
--- a/tests/fm-calm-pi-extension.test.sh
+++ b/tests/fm-calm-pi-extension.test.sh
@@ -1771,6 +1771,7 @@ TS
     local session_arg=${5:-}
     local shape=${6:-single}
     local extensions
+    local peak_captain_answer_count captain_answer_count
 
     tmux -L "$TMUX_SOCKET" kill-session -t "$TMUX_SESSION" 2>/dev/null || true
     if [ "$calm_state" = absent ]; then
@@ -1817,7 +1818,31 @@ TS
       fail "Pi follow-up $label case did not process the monitoring notification"
     fi
 
-    pane=$(tmux -L "$TMUX_SOCKET" capture-pane -p -t "$TMUX_SESSION" -S - 2>/dev/null || true)
+    # The session file above is the authoritative record of what Pi processed and
+    # settles as soon as the model turn completes; the pane is a separate, later
+    # redraw of that same state. Two adjacent followUp deliveries queue more
+    # presentation work (an extra operational-user row plus its Calm-hiding
+    # invalidation) than a single one, so the redraw that finally paints the
+    # already-settled captain answer can still be in flight the instant the
+    # session file confirms processing. Poll the same way the session-file wait
+    # above does rather than reading one immediate, possibly pre-redraw snapshot,
+    # and track the highest count seen along the way so a captain answer that
+    # is genuinely rendered twice for even one intermediate frame still fails
+    # this assertion even if a later redraw were to self-correct down to one.
+    i=0
+    peak_captain_answer_count=0
+    while [ "$i" -lt 100 ]; do
+      pane=$(tmux -L "$TMUX_SOCKET" capture-pane -p -t "$TMUX_SESSION" -S - 2>/dev/null || true)
+      captain_answer_count=$(printf '%s\n' "$pane" | grep -Fc "CAPTAIN_ANSWER_$label" || true)
+      [ "$captain_answer_count" -gt "$peak_captain_answer_count" ] && peak_captain_answer_count=$captain_answer_count
+      if printf '%s\n' "$pane" | grep -Fq "MONITOR_HANDLED_${label}_ONE"; then
+        break
+      fi
+      sleep 0.05
+      i=$((i + 1))
+    done
+    [ "$peak_captain_answer_count" -le 1 ] \
+      || fail "Pi follow-up $label case rendered a duplicate captain answer"
     [ "$(printf '%s\n' "$pane" | grep -Fc "CAPTAIN_ANSWER_$label" || true)" -eq 1 ] \
       || fail "Pi follow-up $label case rendered a duplicate captain answer"
     assert_contains "$pane" "CAPTAIN_PROMPT_$label" "Pi follow-up $label case hid the genuine captain prompt"