feat(*): align empty-reply recovery with Hermes and let a turn end in silence

CHANGELOG.md

@@ -273,6 +273,28 @@ All notable changes to Raven are documented here.
 
 ### Changed
 
+- Empty and abnormal model replies are handled the way Hermes Agent handles
+  them. A reply that is only the silence marker `[SILENT]` ends the turn with
+  nothing sent; a scheduled run, a sub-agent's report or a Sentinel notice
+  may also spell it `SILENT`, `NO_REPLY` or `NO REPLY` and wrap it in a note,
+  but a reply to a person that is only "No reply." reaches them as written.
+  An A2A peer, which waits on the text, still gets the reply as written, and
+  the TUI and web UI draw one muted line, "Raven chose not to reply."; every
+  cron reminder teaches the marker, and a silent run counts as a success. An
+  empty reply is recovered by its kind: a plain one is resent unchanged up to
+  three times after a backoff (once when the call cost at least
+  `agents.defaults.emptyRetryCostThresholdUsd`, default 0.25 USD); one that
+  only thought is asked again and then at a lower reasoning effort; one cut
+  at the output limit is continued with more room; a refusal is never resent
+  but goes to a fallback model or fails with the model's explanation (one an
+  OpenAI-compatible model streams, which litellm drops from the stream, comes
+  back as an empty reply, and the first resend of an empty streamed reply asks
+  without streaming, where the refusal is read); and a turn left with nothing
+  fails in words that name what happened. A streamed answer whose connection
+  dies is continued where it stopped, then delivered marked as partial if it
+  stays cut. A compaction summary asks for reasoning effort `low` instead of
+  `minimal`, which Codex refuses.
+
 - A complete install now carries the `everos-cloud-memory` plugin, so the
   hosted EverOS is a memory backend a user can pick rather than a wheel
   attached to the release with no install path: the one-line installer,
@@ -1291,8 +1313,13 @@ All notable changes to Raven are documented here.
   hosting uses, waits out the same ladder after its one reconnect instead of
   failing the turn on the second error. An unattended run may also ask, with
   `agents.defaults.llmRetryAfterOutput`, for a streamed call that failed after
-  it had produced output to be asked again (the deck launcher does); off, the
-  turn fails as before.
+  it had produced output to be asked again (the deck launcher does). Off, the
+  turn's answering call now hands back the words that streamed: with
+  empty-response recovery on the turn continues them (see the entry on empty
+  and abnormal replies above), and with it off they are delivered as they
+  stand with a note that the reply is partial. A sub-agent run and the turn's
+  other model calls, such as the wrap-up of a turn that ran out of steps,
+  still treat the cut as before.
 - The deck engine's second reader is bounded: one reading stops at 240 s and
   names the pages it did not get to, a deck's readings together stop at 15 min,
   a reading is recorded at the version of the pixels it read (the build's own

docs-site/docs/proactivity-design.md

@@ -202,9 +202,10 @@ check-and-reserve transaction:
 - The task-discovery menu is policy-gated. A user-selected option is a separate
   execution path, not a second pass through ProactiveSpawn for every action.
 - Cron is explicitly user-scheduled and bypasses `check()`. With a Sentinel
-  runner wired, successful fires update its shared counters and topic ledger.
-  This helps suppress overlapping Sentinel reminders; it is not a guarantee
-  of semantic deduplication across all messages.
+  runner wired, successful fires update its shared counters and topic ledger,
+  except a run the model ends with `[SILENT]`: it nudged no one, so it records
+  nothing. This helps suppress overlapping Sentinel reminders; it is not a
+  guarantee of semantic deduplication across all messages.
 
 ## State and feedback
 
@@ -282,10 +283,12 @@ broadcast. `raven/core/cron_stack.py` submits the work as a `CRON` turn in
 
 Successful recurring fires increase `silent_fire_count`; matching user
 activity resets it. Reaching `silent_fire_limit` (default `12`) disables the
-job. This counts fires without user activity, not failures. Cron's feedback
-record is marked neutral so it does not lower Sentinel's learned acceptance
-rate. Fixed-delay `every` schedules compute their next run from completion,
-not from the previous due time.
+job. This counts fires without user activity, not failures. A run the model
+ends with `[SILENT]` is not counted either: it sent the user nothing to
+respond to, so a check that mostly stays quiet is not disabled for it. Cron's
+feedback record is marked neutral so it does not lower Sentinel's learned
+acceptance rate. Fixed-delay `every` schedules compute their next run from
+completion, not from the previous due time.
 
 HeartbeatService (`schedulers/heartbeat/service.py`) checks `HEARTBEAT.md`
 with a structured model decision and runs agent work only on a `run` result.
@@ -294,10 +297,17 @@ while user work is busy. Wake drives Heartbeat, not Sentinel's tick loop.
 
 A successful Cron turn that explicitly replies uses the Spine's delivery
 path and does not enqueue a completion event or wake Heartbeat to repeat the
-reminder. Silent completions and failures still wake Heartbeat, as do missed
-reminders and automatic disabling. A successful retry clears its pending
-failure event; an explicit reply also clears any earlier silent completion.
-Unrelated events stay queued.
+reminder. The reminder also teaches the `[SILENT]` marker. Cron is a
+proactive origin, so a marker alone on the first or last line, or `[SILENT]`
+opening the reply, counts too, and a note on why the model stayed quiet does
+not defeat it. A run that ends this way is recorded as a success and delivers
+nothing: it enqueues no event and wakes no Heartbeat. A run in which the model
+produced no output after every retry is recorded as failed, delivers nothing,
+and does not wake Heartbeat either. Every other failure still wakes
+Heartbeat, as do a success that ends with neither a reply nor a marker,
+missed reminders and automatic disabling. A successful retry clears its
+pending failure event; an explicit reply or a `[SILENT]` run also clears any
+earlier completion event. Unrelated events stay queued.
 
 The Spine's Scheduler routes turns into per-conversation Lanes and origin
 concurrency pools; DeliveryHub routes output to outlets. User-inbound and

docs-site/docs/proactivity-design.zh.md

@@ -163,7 +163,8 @@ ProactiveSpawn 校验任务，以任务文字作为去重内容检查共享策
   在空闲检查后直接投递，不重新检查策略，因此没有完整的发送时配额或免打扰保障。
 - 任务发现菜单受策略约束。用户选择后的执行是独立路径，并非每种动作都再经 ProactiveSpawn。
 - Cron 是用户显式安排的任务，绕过 `check()`。接入 Sentinel runner 时，成功触发会更新
-  共享计数与话题账本。这有助于抑制重叠的 Sentinel 提醒，但不能保证所有消息语义上绝不重复。
+  共享计数与话题账本；模型以 `[SILENT]` 结束的运行没有提醒任何人，不做记录。
+  这有助于抑制重叠的 Sentinel 提醒，但不能保证所有消息语义上绝不重复。
 
 ## 状态与反馈 { #state-and-feedback }
 
@@ -228,17 +229,23 @@ CronService（`schedulers/cron/service.py`）在文件锁下持久化任务、
 
 周期任务成功触发会增加 `silent_fire_count`，匹配的用户活动会将其重置。
 达到 `silent_fire_limit`（默认 `12`）后任务被禁用。这里计数的是没有用户活动的触发，
-不是失败次数。Cron 的反馈记录记为中性，不会拉低 Sentinel 学习到的接受率。
+不是失败次数。模型以 `[SILENT]` 结束的运行同样不计数：它没有给用户发任何内容，
+用户无从回应，所以多数时候保持沉默的检查类任务不会因此被禁用。
+Cron 的反馈记录记为中性，不会拉低 Sentinel 学习到的接受率。
 固定延迟的 `every` 计划从完成时刻计算下一次运行时间，而不是从上一次应触发时刻计算。
 
 HeartbeatService（`schedulers/heartbeat/service.py`）通过结构化模型决策检查
 `HEARTBEAT.md`，仅在结果为 `run` 时执行 Agent 工作。`wake.py` 合并提前唤醒请求、
 限制频率，并在用户工作繁忙时延后。Wake 驱动 Heartbeat，不驱动 Sentinel 的节拍循环。
 
 已明确回复的成功 Cron 轮次通过 Spine 投递，不再生成完成事件或唤醒 Heartbeat 重复提醒。
-成功但未回复的轮次、失败、错过的提醒以及自动禁用仍会唤醒 Heartbeat。
-任务重试成功后会清除自身待处理的失败事件；明确回复后也会清除此前排队的静默完成事件。
-其他事件仍保留在队列中。
+提醒文本还会教模型使用 `[SILENT]` 标记。Cron 属于主动来源（proactive origin），
+标记单独占第一行或最后一行、或回复以 `[SILENT]` 开头，同样算沉默，
+所以模型附带的一句说明不会让标记失效。以标记结束的运行记为成功、不投递：
+不生成事件，也不唤醒 Heartbeat。模型在所有重试后仍什么都没给的运行记为失败、不投递，
+同样不唤醒 Heartbeat。其他失败、既没有回复也没有标记的成功轮次、错过的提醒以及自动禁用
+仍会唤醒 Heartbeat。任务重试成功后会清除自身待处理的失败事件；明确回复或以 `[SILENT]`
+结束后，也会清除此前排队的完成事件。其他事件仍保留在队列中。
 
 Spine 的 Scheduler 将轮次路由到按会话划分的 Lane 与按来源划分的并发池；
 DeliveryHub 将输出投递到出口。用户入站与响应修饰钩子区分真实用户轮次和系统来源工作。

docs-site/docs/proactivity.md

@@ -140,7 +140,8 @@ uv run raven sentinel config set --max-nudges-per-hour 1 --max-nudges-per-day 4
 
 Restart afterward. These are Sentinel policy limits, not account-wide billing
 caps. User-scheduled Cron jobs bypass the policy check; when the shared ledger
-is wired, their fires still consume counters seen by Sentinel.
+is wired, their fires still consume counters seen by Sentinel, except a run the
+model ends with `[SILENT]`.
 
 The policy is not a strict send-time barrier for queued messages. Injects are
 checked and charged when queued; deferred reminders are checked at registration

docs-site/docs/proactivity.zh.md

@@ -118,7 +118,8 @@ uv run raven sentinel config set --max-nudges-per-hour 1 --max-nudges-per-day 4
 ```
 
 修改后需重启。这些是 Sentinel 的策略限制，不是账户级费用上限。用户安排的 Cron 任务绕过
-策略检查；接入共享账本时，它们的触发仍会消耗 Sentinel 看到的计数。
+策略检查；接入共享账本时，它们的触发仍会消耗 Sentinel 看到的计数，
+模型以 `[SILENT]` 结束的运行除外。
 
 对于已入队消息，策略并不是严格的发送时刻限制。追加提醒在入队时检查并计入配额；延迟提醒
 在登记时检查，但目前缺少发送时重新检查和记录配额的回调。若要让 Sentinel 提醒避开免打扰

docs/Proactivity-Implementation.md

@@ -409,7 +409,9 @@ the dispatcher.
 pops the pending messages for that session and appends them to the agent's
 outgoing reply. The agent loop applies this in its `after_send` chain and skips
 it for system-origin turns so a proactive reply does not get a nudge layered on
-top of itself.
+top of itself. A turn the model ends on a silence marker has no reply for it to
+modify: the chain runs with no outbound text, the modifier is not called, and the
+queued nudge waits for the next reply.
 
 Constraints: a TTL drops stale entries, a per-session cap evicts the oldest
 beyond it (FIFO), and the pending queue is persisted through the shared
@@ -515,12 +517,14 @@ A cron fire also writes the shared NudgePolicy ledger (a topic-tag fire plus a
 dispatched record marked neutral) so the Sentinel suppresses its own proactive
 nudge on the same topic within the dedup window, without dragging down the
 acceptance rate the Sentinel learns from (a cron is user-initiated, not the
-Sentinel's own proposal). A recurring job that fires repeatedly with no user
+Sentinel's own proposal). A run the model ends on a silence marker nudged no
+one, so it writes nothing. A recurring job that fires repeatedly with no user
 response is automatically disabled when `silent_fire_count` reaches
-`silent_fire_limit` (default 12). Successful fires increment this count; user
-activity for the matching channel and recipient resets it. This counts fires
-without user activity, not execution failures, and contains runaway "every few
-minutes forever" jobs.
+`silent_fire_limit` (default 12). Successful fires increment this count, except
+a run the model ends on a silence marker, which sent the user nothing to respond
+to; user activity for the matching channel and recipient resets it. This counts
+fires without user activity, not execution failures, and contains runaway "every
+few minutes forever" jobs.
 
 ---
 

docs/specs/2026-08-21-acp-agent-compatibility.md

@@ -74,7 +74,7 @@ build is validated against it.
 | `tool_call_update` status | **Supported** | `completed` or `failed`, from the emit site's verdict: the loop derives it from the registry's own failure convention (the model-facing text of a failed tool starts with `Error`), which is the same rule the retry-hint logic uses. A tool that reports a friendly `Error: ...` message is therefore classified as failed here too -- breaking the convention mislabels the transcript row as well. |
 | `ToolCallContent` `diff` | **Supported** | Structured `{path, newText, oldText?}` carried from the write tools, which hold both versions of the file. `oldText` is omitted only for a file that did not exist -- the schema defines its absence as "new file", so omitting it for a file whose previous content is merely unavailable would render every line of a rewrite as an addition. |
 | `ToolCallContent` `terminal` | **Not supported** | See `terminal/*` below. |
-| `stopReason` | `end_turn`, `cancelled`, `max_turn_requests`, `max_tokens` | A turn that would otherwise end `end_turn` is reported `max_turn_requests` when the agent loop's own budget ended it (the tool-call cap, the wall clock or a stalled tool) and a wrap-up answered in its place, and `max_tokens` when generation stopped at the model's output ceiling. The budget is read first. Either way the reply reads complete and is not, and the stop reason is the one place a delegating client can learn that. |
+| `stopReason` | `end_turn`, `cancelled`, `max_turn_requests`, `max_tokens` | A turn that would otherwise end `end_turn` is reported `max_turn_requests` when the agent loop's own budget ended it (the tool-call cap, the wall clock or a stalled tool) and a wrap-up, or the cut answer it left no room to continue, answered in its place, and `max_tokens` when generation stopped at the model's output ceiling. The budget is read first. A stream cut mid-answer and delivered as a partial spent no budget and stays `end_turn`; its reply says it is partial. Either way the reply reads complete and is not, and the stop reason is the one place a delegating client can learn that. |
 | `refusal` as a stop reason | **Not sent** | It would come from the runtime's `action_blocked` notice, and that notice carries no turn id: `_run_turn` has none to give it, and the runtime shares a lane with the client's turn (see `_owns_lane`), so a refusal seen on this session cannot be shown to belong to this prompt. Latching it anyway made a *foreign* turn's block the reported outcome of a turn that completed normally, which is a false statement about this turn; reporting `end_turn` is merely a less specific true one. The refusal itself is not lost -- it is delivered as message content, which is what the person reads. Restoring it needs a turn id on the notice, which means threading one through the agent loop. |
 | A failed turn | **Explained, then ended** | A prompt is never answered with a JSON-RPC error. Measured from the other direction on codex-acp: an error in reply to a turn-shaped request makes clients tear down the whole turn. The failure is surfaced as message content and the turn ends with a stop reason. |
 | `plan` | **Not sent** | `PlanEntry.priority` is required (`high`/`medium`/`low`) and Raven's DAG has no source for it. A plan would have to be invented. |

i18n/messages.json

@@ -2531,6 +2531,10 @@
       "en": "A question went unanswered, so the turn continued without an answer.",
       "zh": "有提问没有得到回答，这一回合在没有答案的情况下继续了。"
     },
+    "gui.notice.silent_turn": {
+      "en": "Raven chose not to reply.",
+      "zh": "Raven 选择不回复。"
+    },
     "gui.hub.auto_use": {
       "zh": "技能由 Raven 按需自动使用，暂不支持单独停用",
       "en": "Skills are picked up by Raven on demand; per-skill toggling is not supported yet"

raven/a2a/runtime.py

@@ -297,8 +297,12 @@ async def _run_one_shot_turn(
     carries a `SentinelExtras` payload this call has none of) -- it is a
     proactive, system-origin turn a peer agent asked for, which is exactly what
     `HEARTBEAT` already means elsewhere (`raven/cli/gateway_commands.py`'s
-    `on_heartbeat_execute`). `HEARTBEAT`'s only special case is scheduler lane
-    pooling, irrelevant here since this path never reaches the Scheduler.
+    `on_heartbeat_execute`). Two things ride a proactive origin: scheduler lane
+    pooling, irrelevant here since this path never reaches the Scheduler, and
+    the silence protocol, under which a reply that is or closes on a Silence
+    Marker is withheld. The peer is waiting on the text, so the turn is run
+    with `reply_awaited` and takes no part in that protocol: the reply comes
+    back as the model wrote it.
 
     `conversation_id` is minted by the caller (`RavenAgentExecutor.execute`), not
     here: an A2A `SendMessage` carries no conversation of its own (unlike a
@@ -352,7 +356,7 @@ def drain() -> list[TurnRequest]:
         return []
 
     text_sink: dict[str, str] = {}
-    await agent_loop.run_turn(req, emit, drain, stream=False, text_sink=text_sink)
+    await agent_loop.run_turn(req, emit, drain, stream=False, text_sink=text_sink, reply_awaited=True)
     return text_sink.get("text", "")