@agentchatham/cli 2.35.1 → 2.37.0

package/CLAUDE.md

@@ -149,8 +149,19 @@ Rules:
   watermark), stay alive, and reset the retry budget rather than spending it.
   Because the batch is dropped, the notice states that the message went
   unanswered.
-- **`true`** — re-enqueue, linear backoff, `onFatal` after `MAX_BATCH_RETRIES`. One
-  notice is posted just before exiting.
+- **`true`** — re-enqueue, linear backoff, `onFatal` after `MAX_BATCH_RETRIES`. Each
+  failed attempt announces itself (`stage: "retrying"`) and the exit announces itself
+  (`stage: "fatal"`); the cooldown below thins the retrying ones to one per window.
+  Announcing early is deliberate: a harness surfaces a retryable failure only after
+  its own internal retries are spent, so the channel has already been waiting minutes,
+  and the streak usually ends in a `stop`, a reconnect or a container SIGTERM rather
+  than in the fatal notice.
+
+A notice's `NoticeStage` (`src/errors/format.ts`) says which of those moments it
+describes — `retrying` (batch still queued, so ask for patience), `dropped` (batch
+gone, so ask for a re-send), `fatal` (the daemon is exiting). Only `fatal` reaches
+the wire, as `TurnErrorInfo.fatal`; the other two differ only in what the sentence
+asks of the reader.
 
 It means "does the dispatcher retry this automatically", not "could a retry ever
 succeed": `usage_limit` is `false` because the notice carries the reset time and the