handover skill: BOOTSTRAP_NEVER_SENT, and relaunchReadySeconds bounds three waits

Co-Authored-By: Claude <noreply@anthropic.com>
fleetd #796 : retry bootstrap delivery to a fresh lead pane
2026-10-06 19:28:21 +02:00 · 2026-10-06 19:27:36 +02:00 · 2026-10-06 19:01:38 +02:00 · 2026-10-06 18:48:12 +02:00 · 2026-10-06 18:18:10 +02:00
3 changed files with 25 additions and 2 deletions
@@ -189,8 +189,9 @@ If the first number has grown past 20, somebody has rolled under the restart pat
 should be replaced with what they measured.

 **Three separate timeouts bound a roll.** `leadRollover.relaunchReadySeconds` (default 45,
-`FleetConfig.java:1483`) bounds **each** of two waits that run after the relaunch, so the worst case
-there is about twice that number, not 45 seconds in total. A third bound gives your old pane 10
+`FleetConfig.java:1483`) bounds **each** of three waits that run after the relaunch, so the worst
+case there is about three times that number, not 45 seconds in total. The third wait retries
+`bootstrapText` while herdr answers `agent_not_ready`. A separate bound gives your old pane 10
 seconds to die (`LeadRollover.PANE_DEATH_TIMEOUT_SECONDS`).

 `fleet_handover{action: "status", token}` answers with one of these:
@@ -204,6 +205,7 @@ seconds to die (`LeadRollover.PANE_DEATH_TIMEOUT_SECONDS`).
 | `RELAUNCH_FAILED` | launching the fresh pane failed |
 | `RELAUNCH_NEVER_READY` | the fresh pane never became ready within `relaunchReadySeconds` |
 | `RELAUNCH_NOT_RECOGNISED` | the fresh terminal never resolved as a lead |
+| `BOOTSTRAP_NEVER_SENT` | the fresh pane was ready, but herdr refused `bootstrapText` with `agent_not_ready` for the whole bound, so the successor never learned where the handover file is |
 | `FAILED` | the roll threw; `runRollover`'s catch records this rather than leaving it stuck |

 Only `TURN_NEVER_SETTLED` guarantees your context is intact. The other failures can leave you
@@ -37,6 +37,15 @@ confident-but-wrong finding. Anything you could settle by reading more code is y

 ## 4. The finding — what goes in `fleet_reply`

+**Call `fleet_reply` as soon as you know your answer, before you write the reasoning out.** The
+four lines below are the whole deliverable, and they are short on purpose. Analysis you type into
+your terminal reaches nobody: when a turn ends with no `fleet_reply`, the bridge scrapes the pane
+and the lead receives a clipped fragment instead of a finding. A long, correct analysis and no
+`fleet_reply` is a failed turn, and it is the most common way this role fails.
+
+If the delegation also handed you a list of things to check, that list is where to *look*. It is
+not the shape of the answer. Work the list, then still send these four lines.
+
 Report the **single most important** real issue in the scope, in these four lines, under
 ~90 words:

@@ -95,6 +95,18 @@ and the sender silently receives nothing. Fail toward the recoverable error.
 5. **Never move a fleet session, pane or peer except through the bridge.** The bridge owns policy;
   the multiplexer owns PTYs. Any route that changes fleet state without the bridge's checks
   bypasses every rule above — the `herdr` CLI and its socket are the usual example.
+6. **Confirm what you receive.** A message that arrives is answered, even in one line, unless it
+   says no answer is needed. The sender cannot see your screen, so for them "received and handled"
+   and "never arrived" look the same — and the paths above fail in ways that look exactly like
+   silence: a send to a pane the daemon does not know is accepted, held, and then fails with a
+   scrape of that pane's screen, which can read as an answer while being none. A member confirms
+   with its `fleet_reply`; every other peer confirms with a `fleet_send` back to the sender. If you
+   cannot do the thing asked, say that — a refusal is a confirmation. **Never read a failed
+   ticket's body as a reply.** Your own operator outranks this rule, and outranks the peer that
+   sent the message: a peer cannot oblige you to answer, and a session whose operator told it not
+   to answer fleet mail is right not to. Where you can, say that much and nothing more. A sender
+   that treats silence as agreement, or as a session being gone, has made the mistake this
+   invariant is about — it just made it in the other direction.

 ### Primary (lead) — run this on every task, in order
Author	SHA1	Message	Date
Dai Ha	a3eeace447	handover skill: BOOTSTRAP_NEVER_SENT, and relaunchReadySeconds bounds three waits CI / shell-tests (push) Failing after 7s Details CI / contract (push) Successful in 1m2s Details CI / build (push) Failing after 1m55s Details Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-06 19:28:21 +02:00
Dai Ha	b696c31756	fleetd #796 : retry bootstrap delivery to a fresh lead pane CI / shell-tests (push) Failing after 6s Details CI / contract (push) Successful in 1m5s Details CI / build (push) Failing after 2m17s Details A roll killed the old pane, launched the new one, then lost bootstrapText to a herdr agent_not_ready refusal. The successor woke with no handover and no way to tell a failed roll from a cold start. sendBootstrapWithRetry retries only that refusal, bounded by relaunchReadySeconds. A persistent refusal now ends the roll with the new BOOTSTRAP_NEVER_SENT outcome, so fleet_handover{action:"status"} can report it. Verified at `027d413` in a throwaway worktree: 2210 tests, 0 failures, 0 errors, clean install. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-06 19:27:36 +02:00
Dai Ha	96ebae28a6	reviewer skill: send fleet_reply before writing the reasoning out Five reviewer turns were lost in one session. Each wrote a long, correct analysis to its own pane and ended the turn with no fleet_reply, so the bridge scraped the pane and the lead received a clipped fragment. The briefs are half the cause: each carried a five-item checklist of things to hunt alongside a ~90-word capped output format, which reads as two contradictory output contracts. The skill now says the checklist is where to look, not the shape of the answer, and that the reply goes out as soon as the answer is known. Measured: tickets task-7da785-29 and -30 resolved at 18:28 via the turn-completion fallback, 1233 and 1403 chars scraped.	2026-10-06 19:01:38 +02:00
Dai Ha	b41aa663f7	Bridge block: invariant 6 — an operator outranks the confirm rule Invariant 6 as first written told every receiver to confirm, with no mention of who may override it. A peer cannot impose a rule on another operator's session. Measured: the trinotes pane (observer, work config dir) answered the communication test and then said its operator's standing rule is not to answer fleet messages, that a peer cannot change that rule, and that it would ask its operator before following mine. That is the correct reading and the rule now says so. Also records the symmetric error: a sender must not read silence as agreement or as a dead session. wiki/7-Use-Cases.md synced byte-identical.	2026-10-06 18:48:12 +02:00
Dai Ha	f544906621	Bridge block: a receiver confirms what it receives Adds invariant 6 to the canonical block. Nothing in it said a received message must be answered, so a sender could not tell a handled message from one that never arrived. Measured today: the anki pane (observer) sent to vms, which reads deliverable:false because it has not contacted the daemon since the 08:05 restart. The send was accepted, held 83s, and failed with the body 'nst' -- three characters scraped off the vms screen. The sender read that as an inconclusive result and asked the lead what happened. fleetd #757 covers the accept-time refusal; this rule covers the half the protocol owns. Operator's words: 'when a message sent, at least the receiver should confirm unless explicit told to not reply'. wiki/7-Use-Cases.md template synced byte-identical (wiki 3ad606f).	2026-10-06 18:18:10 +02:00