@dreb/coding-agent 2.70.1 → 2.72.0

package/docs/rpc.md

@@ -33,7 +33,7 @@ historical field as a safe process-spawn path.
 
 ### Process exit and pipe errors
 
-`RpcClient.onExit(listener)` receives an `RpcExitInfo` when the child dies: `{ code, signal }` from a process `exit`, or `{ error }` from a spawn/runtime `error`. Process exits also carry `stderrTail` — the last **2000 characters** of the child's captured stderr — so a host that only watches for exit codes can still surface the child's own diagnostic (for example the stdout backpressure guard's abort message) instead of an opaque exit code. In-flight requests are rejected with the exit reason.
+`RpcClient.onExit(listener)` receives an `RpcExitInfo` when the child dies: `{ code, signal }` from a process `exit`, or `{ error }` from a spawn/runtime `error`. Process exits also carry `stderrTail` — the last **2000 characters** of the child's captured stderr — so a host that only watches for exit codes can still surface the child's own diagnostic (for example the stdout backpressure guard's abort message, or the `Fatal: stdout write failed (EPIPE|ENOBUFS|...)` diagnostic the child writes before exiting 1 when a stdout pipe write fails) instead of an opaque exit code. In-flight requests are rejected with the exit reason.
 
 Child stdio pipe failures (e.g. an `EPIPE` when writing a large prompt to a dying child) are handled the same way: each pipe's `error` event fails in-flight requests with the pipe error and the captured stderr tail instead of crashing the host process.
 
@@ -514,7 +514,7 @@ Set the reasoning/thinking level for models that support it.
 
 Levels: `"off"`, `"minimal"`, `"low"`, `"medium"`, `"high"`, `"xhigh"`, `"max"`
 
-Note: `"xhigh"` is supported by GPT-5.2 through GPT-5.6 model families, the GPT-6 family (Astra and future variants), Claude Opus 4.6–4.x and Claude 5 families (where it maps to adaptive effort `"max"`), and Kimi Code K3. The separate normalized `"max"` tier is model-aware and currently supported by GPT-5.6 aliases and Sol/Terra/Luna variants, plus the GPT-6 family.
+Note: `"xhigh"` is supported by GPT-5.2 through GPT-5.6 model families, the GPT-6 family (Astra and future variants), Claude Opus 4.7+, Sonnet 5+ and Haiku 5.5 on Anthropic, GitHub Copilot and Bedrock (sent as native effort `"xhigh"`), Claude Opus 4.6+ and Sonnet 5+ on OpenRouter, Kimi Code K3, and Qwen 3.8+. The separate normalized `"max"` tier is model-aware and currently supported by GPT-5.6 aliases and Sol/Terra/Luna variants, the GPT-6 family, and Claude Opus/Sonnet 4.6+ and Haiku 5.5 on Anthropic, GitHub Copilot and Bedrock. Unsupported levels are clamped (`xhigh` → `max` on Claude Opus/Sonnet 4.6, otherwise `high`; `max` → `xhigh` → `high`). `availableThinkingLevels` in `get_state` lists only the levels the current model supports and may omit `"off"`: Claude Opus 5.5 cannot turn thinking off, so its list starts at `"minimal"` and `set_thinking_level` with `"off"` lands on `"minimal"` (the saved default is left unchanged).
 
 Response:
 ```json
@@ -1854,17 +1854,15 @@ Emitted when a message begins and completes. The `message` field contains an `Ag
 
 ### message_update (Streaming)
 
-Emitted during streaming of assistant messages. Contains both the partial message and a streaming delta event.
+Emitted during streaming of assistant messages. Carries a streaming delta event. By default, frames are **bounded**: they contain only the delta fields, never the cumulative message.
 
 ```json
 {
   "type": "message_update",
-  "message": {...},
   "assistantMessageEvent": {
     "type": "text_delta",
     "contentIndex": 0,
-    "delta": "Hello ",
-    "partial": {...}
+    "delta": "Hello "
   }
 }
 ```
@@ -1888,19 +1886,33 @@ The `assistantMessageEvent` field contains one of these delta types:
 
 Example streaming a text response:
 ```json
-{"type":"message_update","message":{...},"assistantMessageEvent":{"type":"text_start","contentIndex":0,"partial":{...}}}
+{"type":"message_update","assistantMessageEvent":{"type":"text_start","contentIndex":0}}
+{"type":"message_update","assistantMessageEvent":{"type":"text_delta","contentIndex":0,"delta":"Hello"}}
+{"type":"message_update","assistantMessageEvent":{"type":"text_delta","contentIndex":0,"delta":" world"}}
+{"type":"message_update","assistantMessageEvent":{"type":"text_end","contentIndex":0,"content":"Hello world"}}
+```
+
+#### Bounded wire projection (default)
+
+Every RPC server projects `message_update` events **before serialization**: the cumulative top-level `message` field and the nested `assistantMessageEvent.partial` field are omitted from every frame. Both fields grow with the response, so carrying them on every delta makes the JSONL stream quadratic in response length — long turns (especially large tool calls streamed as `toolcall_delta`) could flood the stdout pipe. The delta fields (`type`, `contentIndex`, `delta`, `content`, `toolCall`) are preserved unchanged, so total stdout volume stays proportional to response length.
+
+The projection applies recursively to `message_update` events nested inside `background_agent_event` payloads. It does **not** apply to command responses — `get_messages` and `get_dashboard_snapshot` still return complete messages — and `message_end` always carries the full final message as the authoritative transcript record.
+
+**Legacy full frames (opt-in).** Clients that still read `message` or `assistantMessageEvent.partial` from `message_update` can launch the server with `--rpc-full-message-updates` to restore the unprojected frames:
+
+```json
 {"type":"message_update","message":{...},"assistantMessageEvent":{"type":"text_delta","contentIndex":0,"delta":"Hello","partial":{...}}}
-{"type":"message_update","message":{...},"assistantMessageEvent":{"type":"text_delta","contentIndex":0,"delta":" world","partial":{...}}}
-{"type":"message_update","message":{...},"assistantMessageEvent":{"type":"text_end","contentIndex":0,"content":"Hello world","partial":{...}}}
 ```
 
-#### Dashboard-mode wire projection (`--ui dashboard`)
+The flag requires `--mode rpc` and is rejected with `--ui dashboard` (dashboard runtimes are always projected). A server started with the flag forwards it to the RPC-controlled subagent children it spawns, so nested `message_update` events relayed in `background_agent_event` payloads are full frames too. Prefer accumulating deltas or reading `message_end` instead.
+
+**TypeScript types.** `RpcEvent` (exported from the package and used by `RpcClient.onEvent`) types `message_update` as `RpcMessageUpdateEvent`: `message` and `assistantMessageEvent.partial` are optional, because they are absent unless the server runs with `--rpc-full-message-updates`.
 
-When the RPC server is launched with `--ui dashboard`, `message_update` events are projected **before serialization**: the cumulative top-level `message` field and the nested `assistantMessageEvent.partial` field are omitted from every frame. Both fields grow with the response, so carrying them on every delta makes the JSONL stream quadratic in response length; the dashboard reducer consumes only the delta fields (`type`, `contentIndex`, `delta`, `content`, `toolCall`), which are preserved unchanged.
+**Stdout write failures.** If a stdout write fails (`EPIPE` when the consumer has gone, `ENOBUFS`, ...), the server writes a `Fatal: stdout write failed (<code>: ...)` diagnostic to stderr and exits 1. A stdin close that arrives at the same time (a dying consumer usually closes both pipes) does not override this with a clean exit.
 
-The projection applies recursively to `message_update` events nested inside `background_agent_event` payloads. It does **not** apply to command responses — `get_dashboard_snapshot` still returns complete messages — and `message_end` always carries the full final message as the authoritative transcript record. RPC servers launched without `--ui dashboard` emit the full unprojected protocol shown above.
+#### Dashboard-mode image dedupe (`--ui dashboard`)
 
-The same dashboard-mode projection also dedupes images across the wire. Inline `image` blocks (PNG, JPEG, GIF, WebP) are content-identified by `sha256(mimeType + 0x00 + decodedBytes)`; the first occurrence of each unique image is sent inline, and every later occurrence anywhere in the event stream is replaced with
+Dashboard runtimes also dedupe images across the wire. Inline `image` blocks (PNG, JPEG, GIF, WebP) are content-identified by `sha256(mimeType + 0x00 + decodedBytes)`; the first occurrence of each unique image is sent inline, and every later occurrence anywhere in the event stream is replaced with
 
 ```json
 {"type": "image_reference", "id": "<64 hex chars>", "mimeType": "image/png", "size": 12345}

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@dreb/coding-agent",
-	"version": "2.70.1",
+	"version": "2.72.0",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"drebConfig": {