Not a measured defect. A note from #1164's clearance (co1), filed so it is not lost.
terminal_peek in scripts/drivers/terminals/herdr/ops.sh (currently around line 793) decides confirmed-gone (rc 12) vs. unknown-failure (rc 11) with a bash case substring match against herdr's raw stdout error body: case "$stdout_body" in *pane_not_found*) ... ;; *) ... ;; esac. herdr's own documented shape for this is JSON ({"error":{"code":"pane_not_found",...}}), but the check never parses it as JSON — it just asks whether the literal text pane_not_found occurs anywhere in the blob.
The risk
If herdr ever changes how it spells that error — renames the code, nests it under a different key, changes casing, or wraps the JSON in something that escapes or reformats the substring — the case falls through to the default arm silently. There is no error, no warning, and no crash: the read just gets classified as rc 11 (unknown, "cannot tell") instead of rc 12 (confirmed gone), and callers built on that distinction (SKILL.md's peek exit-code guidance, #1158's whole point) quietly start treating a real "gone" as "cannot tell". A version bump on herdr's side, not a code change on ours, is enough to trigger it.
This is the same family this team has been chasing today: a read failure that does not surface as a failure, it surfaces as a different, wrong value that looks like a legitimate answer.
How to settle it
Parse the JSON structurally (e.g. via the sqlite3/json_extract pattern already used elsewhere in this file for herdr's other JSON replies) and compare the extracted error.code field for equality, instead of a substring match against the raw body. Not urgent — #1164 does not depend on it, and the current substring match is correct against herdr's shape as measured today — but it should not be silently inherited by the next thing built on this taxonomy.
Not a measured defect. A note from #1164's clearance (co1), filed so it is not lost.
terminal_peekinscripts/drivers/terminals/herdr/ops.sh(currently around line 793) decides confirmed-gone (rc 12) vs. unknown-failure (rc 11) with a bashcasesubstring match against herdr's raw stdout error body:case "$stdout_body" in *pane_not_found*) ... ;; *) ... ;; esac. herdr's own documented shape for this is JSON ({"error":{"code":"pane_not_found",...}}), but the check never parses it as JSON — it just asks whether the literal textpane_not_foundoccurs anywhere in the blob.The risk
If herdr ever changes how it spells that error — renames the code, nests it under a different key, changes casing, or wraps the JSON in something that escapes or reformats the substring — the
casefalls through to the default arm silently. There is no error, no warning, and no crash: the read just gets classified as rc 11 (unknown, "cannot tell") instead of rc 12 (confirmed gone), and callers built on that distinction (SKILL.md's peek exit-code guidance, #1158's whole point) quietly start treating a real "gone" as "cannot tell". A version bump on herdr's side, not a code change on ours, is enough to trigger it.This is the same family this team has been chasing today: a read failure that does not surface as a failure, it surfaces as a different, wrong value that looks like a legitimate answer.
How to settle it
Parse the JSON structurally (e.g. via the
sqlite3/json_extractpattern already used elsewhere in this file for herdr's other JSON replies) and compare the extractederror.codefield for equality, instead of a substring match against the raw body. Not urgent — #1164 does not depend on it, and the current substring match is correct against herdr's shape as measured today — but it should not be silently inherited by the next thing built on this taxonomy.