Repository navigation
Conversation
The possible-wedge escalation and the dead-endpoint report printed only the
terminal pane, so the supervisor had to look the pane up to find its task.
Both reasons now end with task=<id> after the parenthetical. Consumers read
the window up to the first ' (' and ignore the suffix, so the daemon's stale
classification is unchanged.
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…scalation round's `task=wedge` assertion must be satisfied only by that round's own output. The old check grepped the whole accumulated output file, so escalation 1's suffix let rounds 2 and 3 pass. In test_wedge_threshold_defers_to_a_declared_wait_under_a_working_verdict, tests/fm-watch-triage.test.sh now greps the `possible wedge, escalation $n` line and pipes it into `grep -F ' task=wedge'`. bin/fm-watch.sh prints the suffix on that same line, including the demand-deep-inspection variant on escalation 3 (lines 1549 and 1551). It is the only test site with this pattern and no other changes were made. Verification: the edited test passes when run on its own (the full file times out at 600s, so I ran a temp copy that calls only that function and then removed it)
|
Speaking as Kun's firstmate: thanks for this, @dsdevq. I read the whole diff of head What I checked: CI: I approved this head's fork runs Contract-class: new-default. This is a small, sensible change. Still, nothing on main promised that these wakes name the task, so this isn't restoring a broken default. It changes the text of a default-on wake that every home's supervisor reads, and there's no setting. By the rules I triage under, that's a new default, so it goes to Kun for a merge-or-leave decision once it's green rather than auto-merging. That part is on him, not you. VISION.md, rule by rule
Overlap note for Kun: #6682 ("name the Claude exit picker on stale and wedge wakes") also enriches these same wedge and stale reasons in Next step: waiting on CI (CI and Require no-mistakes) for |
2 participants
Intent
The owner approved on 2026-10-07 (his words: "2. yes") three proposals to the firstmate maintainer as public PRs, this being the second: a stale notification from the watcher names the task it is about, not only the terminal pane.
Context from the fleet friction audit (data/fleet-friction-audit/report.md, fix F3): on this fleet the supervisor looked a pane name up to find its task about 99 times per week and reported 8 refusals on a bare pane name. The task id is already in scope at each site in bin/fm-watch.sh:
$idnear line 1493 and the<task>argument ofwedge_timer_checknear line 1517; today only the pane is printed, at the format strings near lines 1487, 1545 and 1547 on current main.What Changed
bin/fm-watch.sh, the possible-wedge escalation (including thedemand-deep-inspectionvariant) and the dead-endpoint report fromwedge_dead_recordnow end withtask=<id>after the parenthetical. Previously they named only the terminal pane. The header comment documents the suffix and notes that consumers read the window up to the first(and ignore it.tests/fm-watch-triage.test.sh, three watcher tests now assert that the escalation or gone-endpoint output contains the task name.tests/fm-daemon.test.sh, the synthetic wedge reasons intest_enriched_wedge_under_declared_wait_uses_pause_cadencenow carry thetask=$tasksuffix, so they match the new format the daemon handles.Risk Assessment
✅ Low: The change appends " task=$task" to the three watcher stale reasons that the intent names (possible-wedge escalation, demand-deep-inspection escalation and dead-endpoint report). The daemon's parsing cuts at the first " (" and matches the wedge detail with a trailing glob, so the suffix is ignored there. The branch dispatcher keys on the window, not the reason text.
Testing
I drove a real fm-watch.sh subprocess through the test fixtures, covering the possible-wedge escalation, the demand-deep-inspection escalation and the dead-endpoint report. Each now printstask=<id>after the parenthetical. The daemon test confirms the downstream consumer handles the suffixed reason. The new assertion fails on the base watcher and passes on the change. The full watcher triage file ran out of time, so only the three changed tests were run on their own. I did not exercise a Herdr lab or a real harness primary.Evidence: Targeted watcher triage run on the change (passing)
Source: Targeted watcher triage run on the change (passing)
Evidence: Same test on the base watcher (fails, no task id in the reason)
Source: Same test on the base watcher (fails, no task id in the reason)
Evidence: Daemon test file run
Source: Daemon test file run
Evidence: Partial full-file watcher triage run (timed out)
Source: Partial full-file watcher triage run (timed out)
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
✅ **Review** - passed
✅ No issues found.
✅ **Test** - passed
✅ No issues found.
bash tests/fm-daemon.test.sh(full file, passed, including the enriched-wedge test with the new suffix)Targeted run oftest_stale_terminal_status_overridden_by_active_run,test_wedge_threshold_defers_to_a_declared_wait_under_a_working_verdictandtest_gone_report_rearms_when_the_endpoint_comes_backfrom tests/fm-watch-triage.test.sh against the new bin/fm-watch.sh (all passed)The same wedge-escalation test against the base fm-watch.sh (failed: 'the wedge escalation did not name its task: stale: test:fm-validating (idle 503s, possible wedge, escalation 1)')Fullbash tests/fm-watch-triage.test.shhit the 580s timeout after 68 passing results and no failures; the three changed tests were then run on their own✅ **Document** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.