Repository navigation
Conversation
…to routine-wake triage The pause recheck is reached for an ordinary crew only once its agent is confidently dead, and the triage refused every agent that was not alive, so the recheck it was wired to could never be offered. A worker whose agent has exited beside an open pull request is now offered, the model is told which, and the question reads a wait for the merge word of that pull request as the already reported merge whoever gives it.
Owner
Author
|
Superseded by #48, the same change on a fresh branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
The first Jev item, merged as pull request 38, was accepted from a proposal table as: "Routine monitoring checks - Jev decides: does this check need firstmate, or is it routine? - Stops the stream of 'nothing new' turns; routine checks are closed without a message." All Jev items were then ordered merged: "merge all jev items".
It is live but is not closing the checks it was built for. Since it went live the supervisor has still been woken, one at a time, for every "stale: (paused Ns, awaiting external - declared pause, rechecked on a long cadence not a wedge; confirm the wait still holds)" recheck of the ten JewelTrek pull requests that are open and waiting for a merge word (jeweltrek2627-slim pull requests 222 to 231; examples at 18:49Z and 18:51Z on 2026-10-05 for tasks jt-diamond-cert-mismatch-flag and jt-diamond-consignor-statement, whose metadata carry pr= and whose pull requests are open). state/.watch-triage.log in the firstmate home shows exactly one "jev triage" line all evening (a different task, delivered at confidence 0.61) and none for these.
What Changed
jev_triage_task_evidenceinbin/fm-watch.shnow offers a paused task whose agent state isdeadas well asalive, instead of refusing everything butalive. The evidence gains aworker_agentfield (runningorexited), and any other agent state (missing, ambiguous, unreadable, unverified) is still delivered without asking.routinewhether the agent is running or has exited. Every other wait of an exited agent, and a wait on a person for anything other than that merge, isneeds_firstmate.worker_agentevidence value, and further pull-request reads: no-checks output is still offered, while a pending required check, a draft, and a conflict are delivered. The pull-request gate itself is unchanged; only its comment now says a repository with no checks is not a blocker.docs/configuration.mdanddocs/verification/jev-wake-triage.mdare updated to match, with the live answers re-recorded on 2026-10-06.Risk Assessment
✅ Low: The change is a small, well-bounded widening of one eligibility gate (agent state
deadnow offered alongsidealive) plus question wording, matching the intent's failing sequence (handle_paused_stale is reached for an ordinary crew only when the agent is dead, which the old gate always refused), with the deterministic pull-request read, confidence floor, and streak cap unchanged and behavioral tests covering the new path.Testing
Ran the targeted triage test file (passes), then drove a real
bin/fm-watch.shprocess over an isolated firstmate home with a real tmux server on a private socket, the realbin/fm-pr-state.shreading the real JewelTrek pull requests, and real Jev calls using the key from the firstmate home. On the base commit the exited-agent merge-word recheck was delivered with no Jev line, exactly as reported; on the target it was absorbed at confidence 0.99 with nothing queued, for both PR 228 and PR 222 using the real tasks' own status lines. Adversarial cases were all delivered: PR 230 (now conflicting) and a task with no recorded pull request without asking Jev, and an exited worker waiting on a choice, on a question, or on CI after asking. A running agent on the merge word was also absorbed. The live watcher ran on the tmux backend while the real fleet uses herdr; a read-only check with this change's backend library showed the three real herdr endpoints sampled readdead, the state the fix now offers. No UI surface, so no screenshots; the evidence is the watcher's own output, wake queue and triage log.absorbed jev-routine declared-pause-recheck (confidence=0.99 ...)stale: fmlive:fm-park (paused 14526s, awaiting external ...), 1 wake-queue line added, empty triage logjev triage delivered declared-pause-recheck (choice=needs_firstmate confidence=1.0 / 0.91), wake queuedjev triage delivered ... (choice=routine confidence=0.22 floor=0.6), wake queued. Delivered only by the confidence floor, as the verification doc already records.alive,absorbed jev-routine declared-pause-recheck (confidence=0.99 ...), 0 wake-queue lines addedfm_backend_agent_state herdrprintsdeadfor jt-diamond-consignor-statement, jt-diamond-cert-mismatch-flag and jt-diamond-memo-return-by-datejev triageabsorb lines appearing in the firstmate home's state/.watch-triage.logEvidence: Live watcher transcript (all driven cases, base and target)
Source: Live watcher transcript (all driven cases, base and target)
Evidence: Live driver script
Source: Live driver script
Evidence: Before and after on the reported case (exited agent, open PR 228, captain's merge word)
Evidence: Guards still deliver (target, exited agent)
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
bin/fm-watch.sh:1724- Admittingdeadagents means an exited worker with a non-merge wait (for examplepaused: CI is running, resuming on my own) is now kept from being absorbed only by the model's answer; no code gate separates it from a merge wait. The branch's own live table (docs/verification/jev-wake-triage.md, rowci/exited) shows the model still choosesroutinethere (routine probability 0.56, confidence 0.10-0.12), so only the 0.6 confidence floor delivers it. This is bounded: a required check that is pending or failing is refused in code by the pull-request read, the six-in-a-row streak cap forces a delivery, and the doc records the tradeoff. Noted as an acknowledged tradeoff; no change requested.MERGEABILITY: conflicting, so its recheck will keep waking the supervisor after this ships. That is the designed behaviour for a blocked pull request, not a defect; the other nine (222 to 229, 231) read open with no blocker and are eligible to be closed.absorbed jev-routine declared-pause-recheck (confidence=0.99 ...)stale: fmlive:fm-park (paused 14526s, awaiting external ...), 1 wake-queue line added, empty triage logjev triage delivered declared-pause-recheck (choice=needs_firstmate confidence=1.0 / 0.91), wake queuedjev triage delivered ... (choice=routine confidence=0.22 floor=0.6), wake queued. Delivered only by the confidence floor, as the verification doc already records.alive,absorbed jev-routine declared-pause-recheck (confidence=0.99 ...), 0 wake-queue lines addedfm_backend_agent_state herdrprintsdeadfor jt-diamond-consignor-statement, jt-diamond-cert-mismatch-flag and jt-diamond-memo-return-by-datejev triageabsorb lines appearing in the firstmate home's state/.watch-triage.logbash tests/fm-jev-wake-triage.test.sh(all cases pass, including the new exited-agent case)live-drive.sh <target> exited .../pull/228 <real status lines>: real watcher, real tmux, real PR read, real Jev call; absorbed, nothing queuedlive-drive.sh <base d0dd8b5 via git archive> exited .../pull/228 ...: same setup on the base commit; stale wake delivered, no Jev linelive-drive.sh <target> exited .../pull/222 <jt-diamond-memo-return-by-date's last two status lines>: absorbedlive-drive.sh <target> exited .../pull/230 ...: PR reads conflicting; delivered without a Jev calllive-drive.sh <target> exited .../pull/228with a waiting-to-be-told-which, a decide-the-migration, and a CI-running status line: Jev asked each time, wake delivered each timelive-drive.sh <target> exited "" ...(nopr=in metadata): delivered without a Jev calllive-drive.sh <target> running .../pull/228 ...: stand-in agent process the backend classifies as alive; absorbedbin/fm-pr-state.shagainst jeweltrek2627-slim pull requests 222 to 231 (read-only)fm_backend_agent_state herdr <window>for three real task endpoints in the firstmate home (read-only): alldeadChecked the Jev key appears in no evidence file, watcher output or state; worktree left cleandocs/verification/jev-wake-triage.md:12- The live-answers record says its calls were sourced from bin/fm-watch.sh at commit 1f534a99, which exists locally but is not an ancestor of the target commit 5ea1dcd, so it will not be reachable from main after merge. I left it unchanged because it is the commit the recorded run actually used, and bin/fm-watch.sh differs between 1f534a99 and the target only by one added shellcheck comment line, so the question text and criteria the record vouches for are identical. Re-pointing it at a branch commit would misstate where the evidence was taken; the author can re-run and restamp if a reachable reference is wanted.✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.