dominds 1.23.2 → 1.23.4

package/dist/dialog-display-state.js

@@ -90,6 +90,27 @@ function isDialogLatestResumable(latest) {
 function isSameDisplayState(left, right) {
     return JSON.stringify(left) === JSON.stringify(right);
 }
+function isSideDialogResponseAnchor(record) {
+    return record?.type === 'tellask_anchor_record' && record.anchorRole === 'response';
+}
+function isNonIdleDisplayProjection(state) {
+    return state !== undefined && state.kind !== 'idle_waiting_user';
+}
+async function hasSideDialogFinalResponseAnchor(dialogId, latest) {
+    if (dialogId.selfId === dialogId.rootId) {
+        return false;
+    }
+    const rawCourse = latest.currentCourse;
+    const currentCourse = Number.isFinite(rawCourse) && rawCourse > 0 ? Math.floor(rawCourse) : 1;
+    const courseEvents = await persistence_1.DialogPersistence.loadCourseEvents(dialogId, currentCourse, 'running');
+    for (let index = courseEvents.length - 1; index >= 0; index -= 1) {
+        const event = courseEvents[index];
+        if (event.type === 'tellask_anchor_record') {
+            return isSideDialogResponseAnchor(event);
+        }
+    }
+    return false;
+}
 function classifyRunControlBucket(state) {
     if (!state)
         return 'none';
@@ -124,7 +145,16 @@ async function getRunControlCountsSnapshot() {
                 proceeding++;
                 continue;
             }
-            const latest = await persistence_1.DialogPersistence.loadDialogLatest(dialogId, 'running');
+            let latest = await persistence_1.DialogPersistence.loadDialogLatest(dialogId, 'running');
+            if (!latest) {
+                continue;
+            }
+            const healedLatest = await healStaleSideDialogRunControlAfterFinalResponse({
+                dialogId,
+                latest,
+                trigger: 'run_control_snapshot',
+            });
+            latest = healedLatest;
             if (latest?.generating === true) {
                 proceeding++;
             }
@@ -464,6 +494,9 @@ async function computeIdleDisplayStateFromPersistence(dialogId) {
             continueEnabled: true,
         };
     }
+    if (latest && (await hasSideDialogFinalResponseAnchor(dialogId, latest))) {
+        return { kind: 'idle_waiting_user' };
+    }
     const q4h = await persistence_1.DialogPersistence.loadQuestions4HumanState(dialogId, 'running');
     const pendingSideDialogs = await persistence_1.DialogPersistence.loadPendingSideDialogs(dialogId, 'running');
     const hasQ4H = q4h.length > 0;
@@ -479,15 +512,60 @@ async function computeIdleDisplayStateFromPersistence(dialogId) {
     }
     return { kind: 'idle_waiting_user' };
 }
+async function healStaleSideDialogRunControlAfterFinalResponse(args) {
+    if (args.dialogId.selfId === args.dialogId.rootId ||
+        (args.latest.needsDrive !== true &&
+            args.latest.generating !== true &&
+            args.latest.executionMarker?.kind !== 'interrupted' &&
+            !isNonIdleDisplayProjection(args.latest.displayState))) {
+        return args.latest;
+    }
+    if (args.latest.executionMarker?.kind === 'dead') {
+        return args.latest;
+    }
+    if (args.latest.pendingCourseStartPrompt) {
+        return args.latest;
+    }
+    if (!(await hasSideDialogFinalResponseAnchor(args.dialogId, args.latest))) {
+        return args.latest;
+    }
+    log.warn('Healing stale sideDialog run-control flags after final response anchor', undefined, {
+        dialogId: args.dialogId.valueOf(),
+        trigger: args.trigger,
+        previousGenerating: args.latest.generating ?? null,
+        previousNeedsDrive: args.latest.needsDrive ?? null,
+        previousDisplayState: args.latest.displayState ?? null,
+        previousExecutionMarker: args.latest.executionMarker ?? null,
+    });
+    await persistence_1.DialogPersistence.mutateDialogLatest(args.dialogId, () => ({
+        kind: 'patch',
+        patch: {
+            generating: false,
+            needsDrive: false,
+            displayState: { kind: 'idle_waiting_user' },
+            executionMarker: undefined,
+        },
+    }));
+    return await persistence_1.DialogPersistence.loadDialogLatest(args.dialogId, 'running');
+}
 async function refreshRunControlProjectionFromPersistenceFacts(dialogId, trigger) {
-    const latest = await persistence_1.DialogPersistence.loadDialogLatest(dialogId, 'running');
+    let latest = await persistence_1.DialogPersistence.loadDialogLatest(dialogId, 'running');
     if (!latest) {
         return null;
     }
-    if (latest.generating === true) {
+    if (hasActiveRun(dialogId)) {
         return latest;
     }
-    if (hasActiveRun(dialogId)) {
+    const healedStaleSideDialogRunControl = await healStaleSideDialogRunControlAfterFinalResponse({
+        dialogId,
+        latest,
+        trigger,
+    });
+    if (!healedStaleSideDialogRunControl) {
+        return null;
+    }
+    latest = healedStaleSideDialogRunControl;
+    if (latest.generating === true) {
         return latest;
     }
     const desired = await (async () => {
@@ -524,6 +602,9 @@ async function refreshRunControlProjectionFromPersistenceFacts(dialogId, trigger
                 continueEnabled: true,
             };
         }
+        if (await hasSideDialogFinalResponseAnchor(dialogId, latest)) {
+            return { kind: 'idle_waiting_user' };
+        }
         const q4h = await persistence_1.DialogPersistence.loadQuestions4HumanState(dialogId, 'running');
         const pendingSideDialogs = await persistence_1.DialogPersistence.loadPendingSideDialogs(dialogId, 'running');
         const hasQ4H = q4h.length > 0;
@@ -610,16 +691,20 @@ async function reconcileDisplayStatesAfterRestart() {
             });
             continue;
         }
-        const existing = latest?.displayState;
-        const existingMarker = latest?.executionMarker;
+        if (!latest) {
+            continue;
+        }
+        const existing = latest.displayState;
+        const existingMarker = latest.executionMarker;
         if (existingMarker && existingMarker.kind === 'dead' && dialogId.selfId !== dialogId.rootId) {
-            if (latest?.generating === true) {
+            if (latest.generating === true) {
+                const displayState = latest.displayState ?? { kind: 'dead', reason: existingMarker.reason };
                 try {
                     await persistence_1.DialogPersistence.mutateDialogLatest(dialogId, () => ({
                         kind: 'patch',
                         patch: {
                             generating: false,
-                            displayState: latest.displayState ?? { kind: 'dead', reason: existingMarker.reason },
+                            displayState,
                             executionMarker: existingMarker,
                         },
                     }));
@@ -632,6 +717,24 @@ async function reconcileDisplayStatesAfterRestart() {
             }
             continue;
         }
+        if (dialogId.selfId !== dialogId.rootId &&
+            (latest.generating === true ||
+                latest.needsDrive === true ||
+                latest.executionMarker?.kind === 'interrupted' ||
+                isNonIdleDisplayProjection(latest.displayState))) {
+            const healedStaleSideDialogRunControl = await healStaleSideDialogRunControlAfterFinalResponse({
+                dialogId,
+                latest,
+                trigger: 'restart_reconciliation',
+            });
+            if (!healedStaleSideDialogRunControl) {
+                continue;
+            }
+            latest = healedStaleSideDialogRunControl;
+            if (latest.generating !== true && latest.needsDrive !== true) {
+                continue;
+            }
+        }
         if (isRecoverableGeneratingLatest(latest)) {
             try {
                 await persistence_1.DialogPersistence.mutateDialogLatest(dialogId, () => ({
@@ -653,7 +756,7 @@ async function reconcileDisplayStatesAfterRestart() {
             }
             continue;
         }
-        if (latest?.generating === true || latest?.needsDrive === true) {
+        if (latest.generating === true || latest.needsDrive === true) {
             const nextIdle = await computeIdleDisplayStateForReconciliation(dialogId);
             if (!nextIdle) {
                 continue;

package/dist/dialog.js

@@ -983,6 +983,10 @@ class Dialog {
         if (!trimmed) {
             throw new Error('Prompt is required to queue registered assignment update');
         }
+        // This is runtime scheduling state, not a durable redo log. Persisted business facts already
+        // record the latest assignment in the asker stack and pending records; if the process dies
+        // before this prompt is consumed, recovery should surface those facts loudly for the LLM to
+        // decide the next action. Do not add persistence here just to make the queued bubble replayable.
         if (existing?.kind !== 'registered_assignment_update') {
             const created = {
                 kind: 'registered_assignment_update',

package/dist/docs/dialog-system.md

@@ -327,9 +327,11 @@ This makes Type B sideDialogs reusable across multiple Tellask sites without los
 **Updated Tellask While an Earlier Round Is Still Waiting (normative)**:
 
 - For a registered Side Dialog (`same agentId!sessionSlug`), runtime maintains one current waiting tellasker round.
-- If a newer TYPE B Tellask arrives before the earlier round replies, runtime immediately closes the earlier waiting round with a system-generated failed Tellask result. The wording must describe the conversation fact in business terms, not protocol jargon.
+- If a newer TYPE B Tellask arrives before the earlier round replies, runtime updates pending state and the sideDialog asker stack to the newer round. The earlier call-site still needs a same-`callId` correspondence point, but UI/LLM wording must not claim the target Side Dialog has already received the update until the Side Dialog actually consumes the update prompt.
 - The tellaskee is not force-stopped. Instead, its next runtime prompt explains that the work request has been updated, explicitly says not to send a standalone acknowledgement, and includes the latest full assignment.
 - Delivery of that updated assignment prompt is queued in-order at the next safe turn boundary. Runtime must not reject the update merely because another normal queued prompt already exists; queued prompts are ordered work, not a single overwrite slot.
+- The `registered_assignment_update` up-next item is runtime scheduling state, not a durable redo log. Do not make this queue a new persistence protocol merely to make the update bubble immediately replayable.
+- Business self-healing after a backend restart comes from loud facts and sufficient context: pending reminders, asker-stack assignment state, missing old-call terminal facts, and missing assignment anchors should let the LLM decide whether to resend, correct, or wait. It is not a goal to guarantee that every in-memory queued update survives process death.
 - A Side Dialog reply produced before that updated assignment prompt is rendered locally MUST NOT be delivered to the tellasker as the newer round's result.
 
 **Key Characteristics**:
@@ -1291,8 +1293,10 @@ sequenceDiagram
   alt registry hit
     Reg-->>Driver: existing sideDialog selfId
     opt earlier round still waiting
-      Driver-->>Tellasker: close earlier waiting round with system-generated business notice
       Driver->>Side: queue update notice + latest full assignment
+      Driver-->>Tellasker: report earlier round superseded and update registered
+      Side-->>Driver: later consumes update prompt and writes assignment anchor
+      Driver-->>Tellasker: upgrade call-site link to the concrete assignment bubble
     end
     Driver->>Side: restore + drive
   else registry miss

package/dist/docs/dialog-system.zh.md

@@ -452,6 +452,8 @@ flowchart TD
 
 5. **支线对话响应供应**：支线对话通过持久化将响应写入*当前诉请者*的上下文（不是回调）。对于 TYPE B，每次诉请都会用最新的诉请者 + tellaskInfo 更新支线对话的 `assignmentFromAsker`，因此响应被路由到最近的诉请者（主线或支线对话）。这支持分离操作、复用和崩溃恢复。
 
+   TYPE B 长线诉请更新的确认边界必须谨慎区分：pending 状态与 `asker-stack.jsonl` 更新，只表示运行时已接受/登记新要求；只有支线 driver 实际消费 `registered_assignment_update` up-next、写入可见更新气泡和 assignment anchor 后，才表示目标支线已收到并开始处理更新。`registered_assignment_update` up-next 是运行态调度状态，不是持久化 redo log；不要为了“更新气泡”即时可重放而新增严格持久队列。后端进程重启后的业务自愈依赖 loud facts 与足够上下文（pending reminder、asker stack 最新 assignment、旧 call 是否缺少终态、目标支线是否缺少 assignment anchor），让 LLM 自主决定重发、修正或等待，而不是追求技术层面绝不丢内存队列。
+
 6. **支线对话注册表**：已注册的支线对话（TYPE B 长线诉请）在主线对话作用域的注册表中跟踪。注册表在 `clear_mind` 操作中持续存在，并在主线加载时重建。
 
 7. **状态保留契约**：
@@ -1290,7 +1292,9 @@ sequenceDiagram
 
 call-site 呼应不变量：每个 `tellask` 发起点的 `callId`，后续都必须在诉请者对话历史里留下同
 `callId` 的呼应点。正常支线回复、跨程 carryover、已注册会话被更新后的替代通知都可以结束这次
-call；不能静默删除或覆盖 pending 轮次。
+call；不能静默删除或覆盖 pending 轮次。已注册会话被更新时，替代通知的文案不能在目标支线实际消费
+更新前宣称“更新已送达/目标支线正在按新要求处理”；在此之前只能表达“旧轮已被新要求登记替换，等待
+目标支线在安全边界消费更新”。
 
 WebUI 外链不变量：生成 `/dl/*` URL 时必须在业务现场显式写出目标语义，避免复用泛化 deep-link
 helper。`/dl/callsite` 只表示诉请者对话里的发起气泡：`selfId/course` 是诉请者对话坐标，`callId`

package/dist/docs/diligence-push.md

@@ -15,6 +15,10 @@ This document specifies two related runtime controls:
 - **Auto-continue injection**: for **main dialogs only**, whenever the driver would otherwise stop,
   runtime auto-sends a short diligence prompt (rendered as a normal user bubble) and continues
   generation, except when the dialog is legitimately suspended (Q4H or pending Side Dialogs).
+- **Side Dialog quirk recovery push**: when a provider/API quirk explicitly requests a one-time
+  `diligence_push_once` recovery, a Side Dialog may receive a built-in runtime template, but only
+  when it currently has an active reply obligation; the template must name the one `replyTellask*`
+  tool confirmed by runtime.
 - **Required tool-use control**: for ordinary main and side dialog rounds, the Diligence Push
   checkbox controls whether the provider request must end through a Dominds tool call. When checked,
   the model is expected to call a tool such as `askHuman`, `tellask*`, `replyTellask*`, or another
@@ -32,8 +36,9 @@ This document specifies two related runtime controls:
 ## Non-goals
 
 - Auto-completing / auto-marking a dialog as done.
-- Auto-injecting Diligence Push prompts into Side Dialogs (Side Dialogs remain scoped and should
-  report back to their tellasker).
+- Auto-injecting ordinary Diligence Push prompts into Side Dialogs (Side Dialogs remain scoped and
+  should report back to their tellasker; only the provider-quirk recovery exception may use the Side
+  Dialog template).
 
 ## Definitions
 
@@ -57,7 +62,8 @@ This is the "controlled convergence" path. The diligence-push mechanism should *
 
 ### Trigger conditions (must all hold)
 
-- Dialog is the **Main Dialog** (never for Side Dialogs).
+- Dialog is the **Main Dialog**; Side Dialogs only use the provider deadlock recovery exception
+  below.
 - Dialog is **not suspended**:
   - no pending Q4H, and
   - no pending Side Dialogs (waiting for backfill).
@@ -69,7 +75,15 @@ Some provider/API quirk handlers may request a one-time Diligence Push recovery
 same-context retries for a known deadlock pattern. This is not the ordinary "dialog is about to go
 idle" path. In that recovery-only case, pending sideDialogs do not veto the single Diligence Push
 injection, because the deadlock may happen in a function-result-driven generation round right after
-the main dialog has already registered an in-flight tellask/sideDialog. Q4H remains a hard blocker.
+the main dialog has already registered an in-flight tellask/sideDialog.
+
+Side Dialogs may also use this recovery path, but only when an active reply obligation still exists.
+If no active reply obligation exists, runtime does not inject a push and leaves the retry-stopped
+state for a human to handle. The Side Dialog recovery template does not read rtws diligence files;
+it uses a built-in bilingual template containing the current time, the current Tellask goal, and the
+single runtime-confirmed `replyTellask*` tool (for example
+`replyTellaskSessionless({ replyContent })`). The LLM must not guess the reply variant. Q4H remains
+a hard blocker.
 
 ### Action
 
@@ -164,7 +178,10 @@ post-iteration check:
    special case described above where one recovery-only Diligence Push may ignore pending
    sideDialogs.
 2. If there is any tool feedback, continue normally.
-3. Otherwise (root only), attempt diligence-push auto-continue:
+3. Otherwise, attempt diligence-push auto-continue:
+   - Main Dialog: resolve the rtws diligence file or built-in fallback text.
+   - Side Dialog: only for provider-quirk recovery with an active reply obligation; otherwise do
+     not inject.
    - If disabled → stop normally.
    - If budget exhausted → emit an informational UI notice and stop further automatic Diligence
      Pushes for the current budget.
@@ -198,7 +215,11 @@ Regression tests should cover:
 
 - Main dialog: tool-only output → diligence injection → continued response
 - Main dialog: empty assistant output → diligence injection → continued response
-- SideDialog: no diligence injection
+- SideDialog: ordinary idle path has no diligence injection
+- SideDialog: provider quirk recovery + active reply obligation → inject the Side Dialog template in
+  the work language, include the current Tellask goal, and name the exact active `replyTellask*`
+- SideDialog: provider quirk recovery + no active reply obligation → no injection; leave the
+  stopped/give-up state for human handling
 - rtws config:
   - `.minds/diligence.md` is honored when lang-specific file is absent
   - empty diligence file disables diligence-push

package/dist/docs/diligence-push.zh.md

@@ -12,6 +12,7 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 本文档指定两个相关但不同的运行时控制：
 
 - **自动续推注入**：仅针对**主线对话**，当驱动程序即将停止时，运行时会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的支线对话）。
+- **支线 quirk 恢复续推**：当 provider/API quirk 明确给出一次性 `diligence_push_once` 恢复动作时，支线对话可使用运行时内置模板续推，但仅限当前存在活跃回贴义务（active reply obligation）的场景；模板必须点名运行时确认的唯一 `replyTellask*` 工具。
 - **强制工具调用控制**：对于普通的主线/支线对话轮次，`鞭策` 勾选项控制本轮 provider 请求是否必须通过 Dominds 工具结束。勾选时，模型应通过 `askHuman`、`tellask*`、`replyTellask*` 或其他运行时函数完成这一轮，而不是用普通文本直接收尾。FBR 中间轮是刻意例外：它们可以处于无可调用工具状态；FBR 收口阶段则必须调用两个结论工具之一。
 
 ## 目标
@@ -24,7 +25,7 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 ## 非目标
 
 - 自动完成/自动将对话标记为完成。
-- 将自动鞭策语注入应用于支线对话（支线对话保持范围，应向其诉请者报告）。
+- 将普通自动鞭策语注入应用于支线对话（支线对话保持范围，应向其诉请者报告；只有 provider quirk 恢复特例可使用支线模板）。
 
 ## 定义
 
@@ -48,18 +49,20 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 
 ### 触发条件（必须全部满足）
 
-- 对话是**主线对话**（绝不会是支线对话）。
+- 对话是**主线对话**；支线对话只适用下文 provider 死锁恢复特例。
 - 对话**未暂停**：
   - 没有待处理的 Q4H，并且
   - 没有待处理的支线对话（等待回填）。
 - 驱动程序即将停止生成循环（即没有工具/函数输出需要另一次迭代）。
 
-### 例外：provider deadlock recovery
+### 例外：provider 死锁恢复
 
 某些 provider/API quirk 在识别到已知的 same-context deadlock，并停止沿用同一上下文自动重试后，
 会请求一次性的鞭策恢复。这不是普通的“对话即将空转停止”路径。在这个仅用于恢复的特例里，
 即使主线对话已经登记了在途诉请/支线对话，pending sideDialog 也不应否决这一次鞭策注入；因为卡死
-可能正发生在函数结果驱动的生成轮次里。Q4H 仍然是硬阻塞条件。
+可能正发生在函数结果驱动的生成轮次里。
+
+支线对话也可使用这条恢复路径，但必须满足当前仍有活跃回贴义务（active reply obligation）；否则不注入鞭策语，保留 retry stopped 状态交给人类处理。支线恢复模板不读取 rtws diligence 文件，而是使用内置双语模板，包含当前时间、当前诉请目标，并点名运行时已确认的唯一 `replyTellask*` 工具（例如 `replyTellaskSessionless({ replyContent })`），禁止让 LLM 自行猜测 reply 变体。Q4H 仍然是硬阻塞条件。
 
 ### 操作
 
@@ -138,7 +141,9 @@ members:
 1. 如果对话处于暂停状态，则停止（Q4H / 支线对话待处理）；但上文所述 deadlock-recovery 特例除外，
    即那一次恢复专用的鞭策可忽略 pending sideDialog。
 2. 如果有任何工具反馈，则正常继续。
-3. 否则（仅限主线对话），尝试 diligence-push 自动继续：
+3. 否则尝试 diligence-push 自动继续：
+   - 主线对话：按 rtws diligence 文件 / 内置回退文本解析并续推。
+   - 支线对话：仅在 provider quirk 恢复且存在活跃回贴义务（active reply obligation）时，注入支线内置模板；没有活跃回贴义务时不注入。
    - 如果禁用 → 正常停止。
    - 如果预算耗尽 → 发出一条仅用于提示的 UI 信息，并停止继续自动鞭策当前预算。
    - 否则 → 自动发送鞭策语并继续。
@@ -171,7 +176,9 @@ members:
 
 - 主线对话：仅工具输出 → 鞭策语注入 → 继续响应
 - 主线对话：空助手输出 → 鞭策语注入 → 继续响应
-- 支线对话：无鞭策语注入
+- 支线对话：普通 idle 无鞭策语注入
+- 支线对话：provider quirk recovery + 活跃回贴义务（active reply obligation）→ 注入支线模板，文案使用工作语言，包含当前诉请目标，并准确点名运行时确认的 `replyTellask*`
+- 支线对话：provider quirk recovery + 无活跃回贴义务 → 不注入，保留 stopped/giveup 给人类处理
 - rtws 配置：
   - 当语言特定文件缺失时，`.minds/diligence.md` 被遵守
   - 空的鞭策语文件禁用 diligence-push

package/dist/docs/llm-provider-isolation.md

@@ -12,7 +12,7 @@ This means:
 - `apiType: anthropic` owns official Anthropic Messages semantics, including object-shaped `model_params.anthropic.thinking`.
 - `apiType: anthropic-compatible` owns Anthropic-compatible gateway semantics, including boolean `model_params.anthropic-compatible.thinking` mapped to provider `enabled` / `disabled` request objects.
 
-Some providers expose OpenAI-compatible or Anthropic-compatible endpoints while still requiring explicit provider quirks. Volcano Engine Ark Coding Plan now uses the OpenAI-compatible Chat Completions shape with its dedicated `/api/coding/v3` endpoint; the historical Anthropic-compatible Volcano tool-call quirks have been removed. Kimi Code also uses the OpenAI-compatible Chat Completions shape, but must use the built-in `kimi-code` provider's dedicated `/coding/v1` endpoint, real Dominds User-Agent, `prompt_cache_key`, and Kimi-specific `thinking`/`reasoning_effort` request shaping. See [`volcengine-coding-plan-openai-compatible.zh.md`](./volcengine-coding-plan-openai-compatible.zh.md) for the Volcano migration design record.
+Some providers expose OpenAI-compatible or Anthropic-compatible endpoints while still requiring explicit provider quirks. Volcano Engine Ark Coding Plan now uses the OpenAI-compatible Chat Completions shape with its dedicated `/api/coding/v3` endpoint; the historical Anthropic-compatible Volcano tool-call quirks have been removed. Kimi Code also uses the OpenAI-compatible Chat Completions shape, but must use the built-in `kimi-code` provider's dedicated `/coding/v1` endpoint, versioned `KimiCLI/Dominds/<version>` User-Agent, `prompt_cache_key`, and Kimi-specific `thinking`/`reasoning_effort` request shaping. See [`volcengine-coding-plan-openai-compatible.zh.md`](./volcengine-coding-plan-openai-compatible.zh.md) for the Volcano migration design record.
 
 Similar field names across wrappers do not imply compatibility. For example, `reasoning_effort`, `verbosity`, `parallel_tool_calls`, and web search controls may look similar but can still differ in accepted values, payload shape, lifecycle events, validation rules, and runtime meaning.
 

package/dist/docs/llm-provider-isolation.zh.md

@@ -12,7 +12,7 @@ Dominds 把每个 LLM provider wrapper 视为独立的协议适配器，而不
 - `apiType: anthropic` 只负责 Anthropic 官方 Messages 语义，包括 object 形态的 `model_params.anthropic.thinking`。
 - `apiType: anthropic-compatible` 负责 Anthropic 兼容网关语义，包括 boolean 形态的 `model_params.anthropic-compatible.thinking`，并映射为 provider 请求里的 `enabled` / `disabled` object。
 
-某些 provider 虽然暴露 OpenAI-compatible 或 Anthropic-compatible endpoint，但仍可能需要明确的 provider quirk profile。火山方舟 Coding Plan 现在走 OpenAI-compatible Chat Completions 形态，并使用专属 `/api/coding/v3` endpoint；历史 Anthropic-compatible 火山工具调用 quirk 已取消。Kimi Code 也走 OpenAI-compatible Chat Completions 形态，但必须使用内置 `kimi-code` provider 的专属 `/coding/v1` endpoint、真实 Dominds User-Agent、`prompt_cache_key` 和 Kimi 专用 `thinking`/`reasoning_effort` 请求整形。火山迁移设计记录见 [`volcengine-coding-plan-openai-compatible.zh.md`](./volcengine-coding-plan-openai-compatible.zh.md)。
+某些 provider 虽然暴露 OpenAI-compatible 或 Anthropic-compatible endpoint，但仍可能需要明确的 provider quirk profile。火山方舟 Coding Plan 现在走 OpenAI-compatible Chat Completions 形态，并使用专属 `/api/coding/v3` endpoint；历史 Anthropic-compatible 火山工具调用 quirk 已取消。Kimi Code 也走 OpenAI-compatible Chat Completions 形态，但必须使用内置 `kimi-code` provider 的专属 `/coding/v1` endpoint、带 Dominds 版本的 `KimiCLI/Dominds/<version>` User-Agent、`prompt_cache_key` 和 Kimi 专用 `thinking`/`reasoning_effort` 请求整形。火山迁移设计记录见 [`volcengine-coding-plan-openai-compatible.zh.md`](./volcengine-coding-plan-openai-compatible.zh.md)。
 
 不同 wrapper 下看起来同名的字段，不代表它们可以互相兼容。比如 `reasoning_effort`、`verbosity`、`parallel_tool_calls`、web search 相关开关，名字可能相似，但可接受值、请求载荷形状、流事件生命周期、校验规则和运行时含义都可能不同。
 

package/dist/docs/tellask-revive-context-refactor.zh.md

@@ -418,6 +418,16 @@ replace pending 不是 silent overwrite，也不是 failed-result fallback。它
 
 这样既保留“抽掉旧义务”的业务语义，也让持久层维持 append/truncate-only，不做 YAML 数组整体覆盖。
 
+**更新投递确认边界（已定案）**：
+
+- `registered_assignment_update` 的 up-next 队列是运行时调度状态，不是严格持久化 redo log。不要为了让“更新气泡”即时可重放，把这条队列升级成新的持久事务日志。
+- 诉请者侧反馈必须区分两种事实：
+  - **更新已登记 / 已排队**：pending record 与 asker stack 已按新诉请更新，支线后续应按最新 assignment 推进；这只说明运行时接受了更新。
+  - **目标支线已实际收到并开始处理更新**：支线 driver 已消费 up-next，写入可见的更新 assignment 气泡与 assignment anchor；只有这个事实才能支撑“目标支线已经收到/正在按新要求处理”的主线反馈。
+- 如果支线正忙，更新 prompt 可以留在内存 up-next 中等待安全边界异步消费。主线不应在消费前渲染“已送达目标支线”语义的气泡；最多表达“旧轮已被新诉请登记替换，目标支线尚待消费更新”。
+- 后端进程意外退出时，不追求技术角度严格自愈不丢 up-next。业务自愈边界是：LLM 能看到足够事实（pending reminder、asker stack 最新 assignment、旧 call 是否缺少终态、目标支线是否缺少 assignment anchor），从而自主判断是否需要重发/修正/继续等待。
+- 因此，维护者修复这类时序问题时，优先做真实状态反馈与 loud diagnostics，不要把 up-next 队列泛化成持久化 redo log。
+
 ### 7.3 Reply tool 与 direct fallback
 
 `replyTellask*` 是精确回贴路径；direct fallback 是过渡兼容路径。
@@ -576,6 +586,7 @@ Dominds 不做同 course 内 context window 裁剪。上下文规则是：
   - replace pending 从 stack 中抽调旧 frame，再把新 obligation 压栈顶；
   - 原 call site 只出现 pointer，不出现真实回复正文；
   - Type B registered update 压栈、先回复新诉请、再恢复旧诉请；
+  - Type B registered update 在支线消费更新前，主线不得宣称目标支线已收到/正在处理更新；
   - 重启恢复后 pending 与 arrival fact 一致。
 
 ## 9. 已定案问题
@@ -589,4 +600,5 @@ Dominds 不做同 course 内 context window 裁剪。上下文规则是：
 5. 旧 pending record 缺少 `callSiteCourse` / `callSiteGenseq` 不迁移、不隔离兼容、不 fallback。旧 `.dialogs/` 可丢弃；新 validator 直接要求必填，缺失即 loud fail / quarantine。
 6. reply obligation 是栈，不是槽。root 与 side dialog 统一使用 `asker-stack.jsonl` 持久化 `AskerDialogStackFrame`，文件只允许 append/truncate。LLM context 从栈顶注入当前义务，而不是扫描历史 JSONL 对话。
 7. replace pending 是特殊栈操作：抽调旧 frame，再把新 obligation 压到栈顶；找不到旧 frame 必须 loud fail，不能静默 fallback 成普通 push。
-8. 实现术语升级为 `MainDialog` / `SideDialog` / `askerDialog` / `assignmentFromAsker` / `askerStack`。旧 `supdialog` 术语退出实现代码与文档；用户可见文案继续使用“主线对话 / 支线对话、诉请者 / 被诉请者”。
+8. Type B registered update 的 up-next 队列保持运行态内存调度，不升级为持久化 redo log；主线反馈必须等目标支线实际消费更新并写入 assignment anchor 后，才表达“目标支线已收到/开始处理更新”。
+9. 实现术语升级为 `MainDialog` / `SideDialog` / `askerDialog` / `assignmentFromAsker` / `askerStack`。旧 `supdialog` 术语退出实现代码与文档；用户可见文案继续使用“主线对话 / 支线对话、诉请者 / 被诉请者”。

package/dist/docs/volcengine-coding-plan-openai-compatible.zh.md

@@ -61,15 +61,16 @@ Dominds 现有火山方舟 Coding Plan 接入主要围绕 Anthropic-compatible
 ```yaml
 providers:
   volcano-engine-coding-plan:
-    name: Volcano Engine Coding Plan
+    name: Volcano Ark Coding Plan
     apiType: openai-compatible
     apiQuirks:
       - same-context-empty-response
+      - volcengine-invalid-parameter-aggressive-retry
     baseUrl: https://ark.cn-beijing.volces.com/api/coding/v3
     apiKeyEnvVar: ARK_API_KEY
 ```
 
-`apiType: openai-compatible` 表示底层 HTTP endpoint、Chat Completions 请求形态和 SSE 基础形态接近 OpenAI Chat Completions。历史上用于火山 Anthropic-compatible 文本 tool_use / 空对象参数拼接的专项 quirks 已删除；当前内置只保留 `same-context-empty-response` 这类通用 provider 重试/诊断 quirk。
+`apiType: openai-compatible` 表示底层 HTTP endpoint、Chat Completions 请求形态和 SSE 基础形态接近 OpenAI Chat Completions。历史上用于火山 Anthropic-compatible 文本 tool_use / 空对象参数拼接的专项 quirks 已删除；当前内置保留 `same-context-empty-response` 这类通用 provider 重试/诊断 quirk，并增加 `volcengine-invalid-parameter-aggressive-retry`，用于火山方舟 Coding Plan 偶发 `400 InvalidParameter` 但同 payload 可重放成功的场景，将其归类为 aggressive 策略重试。
 
 ### 具体模型优先
 

package/dist/llm/api-quirks.d.ts

@@ -4,6 +4,7 @@ import type { ProviderConfig } from './client';
 import type { LlmRetryStrategy } from './gen';
 export type LlmFailureKind = 'retriable' | 'rejected' | 'fatal';
 export declare const SAME_CONTEXT_EMPTY_RESPONSE_API_QUIRK = "same-context-empty-response";
+export declare const VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_API_QUIRK = "volcengine-invalid-parameter-aggressive-retry";
 export type LlmFailureSummary = {
     kind: LlmFailureKind;
     message: string;

package/dist/llm/api-quirks.js

@@ -1,10 +1,11 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.XCODE_BEST_STREAM_INTERNAL_ERROR_CODE = exports.SAME_CONTEXT_EMPTY_RESPONSE_API_QUIRK = void 0;
+exports.XCODE_BEST_STREAM_INTERNAL_ERROR_CODE = exports.VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_API_QUIRK = exports.SAME_CONTEXT_EMPTY_RESPONSE_API_QUIRK = void 0;
 exports.normalizeProviderApiQuirks = normalizeProviderApiQuirks;
 exports.createLlmFailureQuirkHandlerSession = createLlmFailureQuirkHandlerSession;
 const persistence_errors_1 = require("../persistence-errors");
 exports.SAME_CONTEXT_EMPTY_RESPONSE_API_QUIRK = 'same-context-empty-response';
+exports.VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_API_QUIRK = 'volcengine-invalid-parameter-aggressive-retry';
 const DOMINDS_LLM_EMPTY_RESPONSE_ERROR_CODE = 'DOMINDS_LLM_EMPTY_RESPONSE';
 const XCODE_BEST_EMPTY_RESPONSE_SINGLE_RETRY_DELAY_MS = 3000;
 const XCODE_BEST_EMPTY_RESPONSE_GIVE_UP_THRESHOLD = 5;
@@ -16,6 +17,8 @@ const XCODE_BEST_UNEXPECTED_EOF_RETRY_MESSAGE = 'xcode.best upstream stream ende
 const XCODE_BEST_MISREPORTED_403_RETRY_MESSAGE = 'xcode.best returned 403 for a transient upstream failure; retrying aggressively.';
 exports.XCODE_BEST_STREAM_INTERNAL_ERROR_CODE = 'XCODE_BEST_STREAM_INTERNAL_ERROR';
 const XCODE_BEST_STREAM_INTERNAL_RETRY_MESSAGE = 'xcode.best upstream stream reported internal_error from peer; retrying aggressively.';
+const VOLCENGINE_INVALID_PARAMETER_MESSAGE_FRAGMENT = 'a parameter specified in the request is not valid';
+const VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_MESSAGE = 'Volcano Ark Coding Plan returned transient 400 InvalidParameter; retrying aggressively.';
 const LOCAL_FILE_IO_ERROR_CODES = new Set(['ENOENT', 'ENOTDIR', 'EISDIR', 'EACCES', 'EPERM']);
 const LOCAL_FILE_IO_SYSCALLS = new Set([
     'open',
@@ -69,6 +72,18 @@ function isXcodeBestStreamInternalFailure(failure, error) {
     const code = failure.code ?? readErrorCode(error);
     return code === exports.XCODE_BEST_STREAM_INTERNAL_ERROR_CODE;
 }
+function isVolcengineTransientInvalidParameterFailure(args) {
+    const statuses = readFailureAndErrorStatuses(args);
+    if (!statuses.includes(400) || statuses.includes(429)) {
+        return false;
+    }
+    const code = (args.failure.code ?? readErrorCode(args.error))?.trim();
+    if (code !== 'InvalidParameter') {
+        return false;
+    }
+    return (args.failure.message.toLowerCase().includes(VOLCENGINE_INVALID_PARAMETER_MESSAGE_FRAGMENT) ||
+        errorChainIncludesMessageFragment(args.error, VOLCENGINE_INVALID_PARAMETER_MESSAGE_FRAGMENT));
+}
 const XCODE_BEST_RETRY_QUIRK_RULES = [
     {
         statusPolicy: { kind: 'only_status', status: 403 },
@@ -494,9 +509,28 @@ function createSameContextEmptyResponseFailureQuirkHandlerSession(providerConfig
         },
     };
 }
+function createVolcengineInvalidParameterAggressiveRetryQuirkHandlerSession() {
+    return {
+        quirkName: exports.VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_API_QUIRK,
+        onFailure(args) {
+            if (!isVolcengineTransientInvalidParameterFailure({
+                failure: args.failure,
+                error: args.error,
+            })) {
+                return { kind: 'default' };
+            }
+            return {
+                kind: 'retry_strategy',
+                retryStrategy: 'aggressive',
+                message: VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_MESSAGE,
+            };
+        },
+    };
+}
 const FAILURE_QUIRK_HANDLER_FACTORIES = {
     'xcode.best': createXcodeBestFailureQuirkHandlerSession,
     [exports.SAME_CONTEXT_EMPTY_RESPONSE_API_QUIRK]: createSameContextEmptyResponseFailureQuirkHandlerSession,
+    [exports.VOLCENGINE_INVALID_PARAMETER_AGGRESSIVE_RETRY_API_QUIRK]: createVolcengineInvalidParameterAggressiveRetryQuirkHandlerSession,
 };
 function normalizeProviderApiQuirks(providerConfig) {
     const raw = providerConfig.apiQuirks;

package/dist/llm/defaults.yaml

@@ -14,6 +14,9 @@
 #   `500 auth_unavailable: no auth available` infrastructure failures.
 #   `apiQuirks: same-context-empty-response` detects repeated empty responses in the same
 #   dialog generation context and stops same-context retry loops with a deadlock-break prompt.
+#   `apiQuirks: volcengine-invalid-parameter-aggressive-retry` classifies Volcano Ark Coding Plan
+#   transient `400 InvalidParameter` failures as aggressive retry when the shape matches that
+#   provider's replay-successful instability.
 # - tool_result_max_chars: optional transport-level cap for a single tool-result text payload
 #   before Dominds projects it into the provider request. Use this when a provider/gateway enforces
 #   a stricter per-item string limit than Dominds' built-in defaults.
@@ -498,6 +501,7 @@ providers:
     apiType: openai-compatible
     apiQuirks:
       - same-context-empty-response
+      - volcengine-invalid-parameter-aggressive-retry
     baseUrl: https://ark.cn-beijing.volces.com/api/coding/v3
     apiKeyEnvVar: ARK_API_KEY
     tech_spec_url: https://www.volcengine.com/docs/82379/1928261
@@ -577,6 +581,7 @@ providers:
         context_window: '204K'
       glm-5.1:
         name: GLM-5.1
+        optimal_max_tokens: 180000
         supports_thinking: true
         default_thinking: true
         supports_image_input: false
@@ -586,6 +591,7 @@ providers:
         context_window: '256K'
       glm-4.7:
         name: GLM-4.7
+        optimal_max_tokens: 180000
         supports_thinking: true
         default_thinking: false
         supports_image_input: false

package/dist/llm/gen/anthropic.js

@@ -1955,9 +1955,13 @@ class AnthropicGen {
             completionTokens,
             totalTokens: promptTokens + completionTokens,
         };
+        const messages = anthropicToChatMessages(response, genseq, forceJsonResponse ? ANTHROPIC_JSON_RESPONSE_TOOL_NAME : undefined);
+        const orderedOutputs = outputs.length > 0
+            ? [...outputs, ...messages.map((message) => ({ kind: 'message', message }))]
+            : [];
         return {
-            messages: anthropicToChatMessages(response, genseq, forceJsonResponse ? ANTHROPIC_JSON_RESPONSE_TOOL_NAME : undefined),
-            ...(outputs.length > 0 ? { outputs } : {}),
+            messages,
+            ...(orderedOutputs.length > 0 ? { outputs: orderedOutputs } : {}),
             usage,
             llmGenModel: returnedModel,
         };