fix(bin): prevent false missed-reply escalations

[kunchenguid]

Intent

Fix the false "missed reply" escalations firstmate raises against a healthy secondmate. A user hit this: over one day, 51 pending-reply-missed decisions piled up against a live, responsive mate that had actually answered - because the mate's correlated corr= reply line was written to the mate's OWN home status file instead of the parent channel the resolver scans, so the reply never matched and each record escalated as missed and never resolved.

The captain reviewed the diagnosis and chose to ship the full fix, and requires a repro-first workflow. Captain's exact words: "for the finding 1 fix, do B then. make sure we create an e2e repro that produces the problem, then fix it, and then confirm the repro is gone."

So: build an end-to-end reproduction that actually produces a false pending-reply-missed escalation FIRST; then apply the fix; then confirm the same repro no longer produces the problem. The repro becomes the regression test.

Option B: make the mate's report helper pick the parent channel itself so the mate cannot hand it the wrong file; stop treating the remote parent-replies file as "wrote to the wrong home"; put a readable file path on the missed-reply notice instead of a checksum; and when the answer landed in the mate's own copy of the same status filename as the parent channel, copy that one line onto the parent channel so it can match.

The fix must stop the false misses without weakening the standing safety property that a sighting under the mate home is not by itself acknowledgement.

What Changed

• Make the secondmate report helper resolve and write to the parent channel instead of accepting a caller-provided status path.
• Restate correlated replies stranded in the mate’s same-basename status file before escalation, while preserving the rule that arbitrary mate-home sightings are not acknowledgements.
• Exclude remote parent reply channels from wrong-home detection and include readable source paths in missed-reply notices, with updated documentation and regression coverage.

Risk Assessment

✅ Low: The change now durably repairs same-basename wrong-home replies across normal and recovery escalation paths while preserving arbitrary mate-home sightings as non-acknowledgements, with bounded supporting changes and behavior-focused regression coverage.

Testing

The successful changed-file baseline was supplemented with the focused pending-reply suite and end-to-end CLI checks: the historical implementation reproduced one recovery and a false pending-reply-missed escalation, while the target restated the reply onto the parent channel and resolved without recovery; the report helper also wrote only to the parent channel. All checks passed and the worktree was left clean.

Evidence: Historical repro versus fixed end-to-end behavior

Source: Historical repro versus fixed end-to-end behavior

=== Historical implementation (base commit) ===
implementation=base
final_phase=escalated
recovery_sends=1
pending_reply_missed=1
parent_channel:
  blocked [key=pending-reply-4a6e07efd7c46ded]: pending-reply-missed: task=mate pending-reply-id=4a6e07efd7c46ded request=status of healthy mate
=== Fixed implementation (target commit) ===
implementation=fixed
final_phase=resolved
recovery_sends=0
pending_reply_missed=0
parent_channel:
  done [corr=0963009433cf87e8]: healthy mate answered

Evidence: Reusable end-to-end reproduction script

Source: Reusable end-to-end reproduction script

#!/usr/bin/env bash
set -eu
LIB=$1
LABEL=$2
ROOT=$3
SCRATCH="$ROOT/.pending-reply-e2e-$LABEL"
rm -rf "$SCRATCH"
mkdir -p "$SCRATCH/parent/state" "$SCRATCH/mate/state"
# shellcheck disable=SC1090
. "$LIB"
export FM_PENDING_REPLY_GRACE_SECS=0 FM_PENDING_REPLY_NOW=17000
STATE="$SCRATCH/parent/state"
MATE="$SCRATCH/mate"
RECOVERY_LOG="$SCRATCH/recovery.log"
: > "$RECOVERY_LOG"
recovery_hook() { printf 'recovery sent\n' >> "$RECOVERY_LOG"; }
export FM_PENDING_REPLY_SEND_HOOK=recovery_hook
corr=$(fm_pending_reply_create "$SCRATCH/parent" "$STATE" mate "status of healthy mate")
fm_pending_reply_mark_delivered "$STATE" "$corr"
cat > "$STATE/mate.meta" <<EOF
window=session:fm-mate
endpoint_task_id=mate
worktree=$MATE
project=$MATE
harness=echo
kind=secondmate
mode=secondmate
home=$MATE
projects=alpha
EOF
printf 'done [corr=%s]: healthy mate answered\n' "$corr" > "$MATE/state/mate.status"
# Exercise both original and recovery busy->idle turns: the historical
# implementation reaches pending-reply-missed; the fixed one repairs first.
fm_pending_reply_tick_one "$STATE" "$corr" busy "$MATE"
fm_pending_reply_tick_one "$STATE" "$corr" idle "$MATE"
fm_pending_reply_tick_one "$STATE" "$corr" busy "$MATE"
fm_pending_reply_tick_one "$STATE" "$corr" idle "$MATE"
rec=$(fm_pending_reply_path "$STATE" "$corr")
printf 'implementation=%s\n' "$LABEL"
printf 'final_phase=%s\n' "$(fm_pending_reply_get "$rec" phase)"
printf 'recovery_sends=%s\n' "$(wc -l < "$RECOVERY_LOG" | tr -d ' ')"
printf 'pending_reply_missed=%s\n' "$(grep -c 'pending-reply-missed' "$STATE/mate.status" 2>/dev/null || true)"
printf 'parent_channel:\n'
if [ -f "$STATE/mate.status" ]; then sed 's/^/  /' "$STATE/mate.status"; else printf '  <empty>\n'; fi
rm -rf "$SCRATCH"

Evidence: Secondmate report helper parent-channel CLI transcript

Source: Secondmate report helper parent-channel CLI transcript

$ FM_HOME=<mate-home> bin/fm-secondmate-report.sh done 0123456789abcdef "audit clean"
exit=0
parent_channel=done [corr=0123456789abcdef]: audit clean (via-helper)
mate_self_status=absent

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 4 issues found → auto-fixed (4) ✅

• 🚨 tests/fm-pending-reply.test.sh:1287 - The required repro does not actually produce the reported pending-reply-missed escalation on the pre-fix code. It drives only the original busy→idle turn; without the fix this reaches recovery_sent, not the second completed recovery turn that escalates. This contradicts the explicit criterion to “create an e2e repro that produces the problem” first. Extend this same-basename scenario through the recovery busy→idle transition so the old implementation emits pending-reply-missed while the fixed implementation resolves.
• 🚨 bin/fm-pending-reply-lib.sh:1298 - Same-basename repair remains bypassed for recovery_failed and recovery_unknown. If no self-home answer exists during the first scan, recovery delivery fails or becomes unknown, and the answer then lands in state/<task_id>.status, the next watcher pass calls tick_one without sm_home and this branch escalates immediately. Thus an authorized answer can still produce a false recovery-delivery escalation. Resolve metadata and perform the same-basename copy before every delivered-record escalation boundary.
• ⚠️ bin/fm-pending-reply-lib.sh:1201 - The new exclusion skips every file named parent-replies.status, although the intent requires excluding the remote parent-replies channel only. During normal local-mate scanning, a mate that mistakenly writes its correlated answer to its own state/parent-replies.status now loses even the wrong-home evidence and readable-path diagnostic. Narrow this exclusion to a home proven to use the remote parent route; the unconditional basename alias exceeds the required behavior.
• ⚠️ bin/fm-secondmate-report.sh:47 - The changed argument check introduces an unrequested no-note acceptance path: fm-secondmate-report.sh done <corr> writes a terminal correlated line and resolves the expectation without an answer. The stated helper contract is (verb, corr, note), and the previous interface required a note argument. Remove this fallback by requiring a non-empty note in status mode; document mode can continue using its required document path.

🔧 Fix: Resolve late replies before recovery escalation
3 issues (1 error, 2 warnings) still open:

• 🚨 tests/fm-pending-reply.test.sh:1288 - The required repro still does not actually produce pending-reply-missed on the pre-fix implementation. It exercises only the original busy→idle turn, which previously entered recovery_sent; the separate recovery-failure test produces a recovery-delivery escalation instead. This contradicts the required “e2e repro that produces the problem” workflow. Extend the same-basename scenario through the recovery busy→idle turn and demonstrate that the old implementation emits pending-reply-missed while the fixed implementation resolves.
• ⚠️ bin/fm-pending-reply-lib.sh:1213 - The new exclusion skips every file named parent-replies.status, while the intent requires excluding the remote parent-replies channel specifically. A local mate that mistakenly writes its correlated answer there now loses wrong-home evidence and the readable-path diagnostic. The accompanying test uses an unbound arbitrary directory rather than proving a remote route. Narrow the exclusion to a home proven to use the remote parent route.
• ⚠️ bin/fm-secondmate-report.sh:47 - The changed argument check adds an unrequested no-note mode: fm-secondmate-report.sh done <corr> writes a terminal correlated line and resolves the expectation without an answer. The required helper contract is (verb, corr, note). Require a non-empty note in status mode; document mode may continue using its required document path.

🔧 Fix: Tighten reply routing and regression coverage
2 warnings still open:

• ⚠️ bin/fm-pending-reply-lib.sh:1175 - The required readable missed-reply path is truncated when a valid mate-home path contains a comma. For example, a sighting under /tmp/team,west/state/child.status is stored verbatim in the comma-separated field, then ${sightings%%,*} reports only /tmp/team. This contradicts the requirement to “put a readable file path on the missed-reply notice instead of a checksum.” Use an unambiguous representation that preserves the complete first path.
• ⚠️ bin/fm-secondmate-report.sh:68 - The change introduces an unnecessary FM_ROOT_OVERRIDE fallback for FM_HOME. FM_ROOT_OVERRIDE conventionally identifies the code/tool root, not a secondmate home, and the documented contract requires invoking the helper with FM_HOME. No intent requirement needs this alias; remove it and require FM_HOME explicitly.

🔧 Fix: Preserve reply paths and require explicit home
1 error still open:

• 🚨 bin/fm-pending-reply-lib.sh:1232 - The readable sighting identity persists an unescaped filename into the line-oriented record. A child file named $'child\nphase=resolved\nx.status' containing the correlation produces an embedded phase=resolved record line; the subsequent resolve check then treats the request as resolved without any parent-channel answer. This contradicts the required standing safety property that a mate-home sighting alone is not acknowledgement. Persist a single-line reversible encoding of the complete path before using it in either sighting field.

🔧 Fix: Encode wrong-home paths before persistence
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• bin/fm-test-run.sh --changed --exclude-family real-herdr-gated
• Pre-run baseline: bin/fm-test-run.sh --changed --exclude-family real-herdr-gated
• bin/fm-test-run.sh tests/fm-pending-reply.test.sh
• pending-reply-e2e-repro.sh <base-library> base <worktree> followed through both busy→idle turns
• pending-reply-e2e-repro.sh bin/fm-pending-reply-lib.sh fixed <worktree> followed through both busy→idle turns
• FM_HOME=<mate-home> bin/fm-secondmate-report.sh done 0123456789abcdef "audit clean"

✅ **Document** - passed

✅ No issues found.

🔧 **Lint** - 1 issue found → auto-fixed ✅

• ⚠️ linter found issues (exit code 1)

🔧 Fix: Fix pending-reply ShellCheck warnings
✅ Re-checked - no issues remain.

✅ **Push** - passed

✅ No issues found.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with the reply-routing fix preserving the rule that arbitrary mate-home sightings cannot acknowledge an obligation.

The changed paths mechanically resolve the parent channel, restrict restatement to the local mate’s matching status filename, encode diagnostic paths safely, and cover the relevant normal, recovery, remote, and adversarial-path cases.

_{Reviews (1): Last reviewed commit: "no-mistakes(lint): Fix pending-reply She..." | Re-trigger Greptile}