dominds 1.28.0 → 1.29.0

package/dist/tools/prompts/control/en/principles.md

@@ -42,7 +42,7 @@ Default to `task`. Use `dialog` only when the note is truly dialog-local; use `a
 - `agent` reminders stay visible in later dialogs you lead
 - Can be added, modified, or deleted at any time
 - Should stay compact, scannable, and directly actionable by default
-- Before `clear_mind`, first state this dialog task goal in a current-dialog scoped (`scope=dialog`) continuation-package reminder. A Main Dialog records only discussion facts that other dialogs/teammates sharing the same Taskdoc truly need to know into Taskdoc, then keeps resume-critical details for this dialog in `dialog` reminders; a Side Dialog directly maintains sufficiently detailed `dialog` continuation-package reminders. If Dominds has already warned that context is tight or critical, Side Dialog reminders have no fixed length limit and rough multi-reminder carry-over is acceptable
+- Main Dialogs have a fixed goal reminder. Read the whole reminder: if it says to ask the human, ask first and record the answer with `set_dialog_goal`; if it says "proceed from the Taskdoc" and has no parallel-dialog note, continue from the Taskdoc; if the same reminder says Dominds has confirmed a parallel dialog, ask the human first. Ordinary `dialog` continuation-package reminders keep details easy to lose during resume. Side Dialogs maintain sufficiently detailed `dialog` continuation-package reminders and state that Side Dialog's task goal. If Dominds has already warned that context is tight or critical, Side Dialog reminders have no fixed length limit and rough multi-reminder carry-over is acceptable
 
 **Difference from memory:**
 | Feature | dialog reminder | task reminder | agent reminder | personal memory |
@@ -91,6 +91,7 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 | delete_reminder  | Delete reminder                                  |
 | update_reminder  | Update reminder content                          |
 | migrate_reminder | Move an over-shared reminder back to this dialog |
+| set_dialog_goal  | Set this Main Dialog's goal                      |
 | do_mind          | Create new Taskdoc section                       |
 | mind_more        | Append entries to Taskdoc (defaults to progress) |
 | change_mind      | Replace existing Taskdoc section                 |
@@ -124,7 +125,7 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 
 - **Current work**: next step, blockers, key pointers
 - **Easy-to-lose details**: temporary paths, ids, commands, sample inputs
-- **Course transition**: current-dialog scoped (`scope=dialog`) continuation-package notes before `clear_mind`; they must state this dialog task goal, including rough multi-reminder carry-over when already degraded
+- **Course transition**: Main Dialog goals come from the fixed goal reminder; ordinary `dialog` continuation packages keep next steps, key pointers, run/verify notes, and volatile details. Side Dialog continuation packages must state that Side Dialog's task goal, including rough multi-reminder carry-over when already degraded
 - **Task carry-over**: if you should keep seeing the note under the current Taskdoc, use `task`
 - **Global urgent cue**: if you should keep seeing it across later dialogs you lead, and it is urgent, short-lived, and globally visible, use `agent`
 
@@ -141,7 +142,7 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 - Do not duplicate system state: background process status, in-flight background asks/collaboration, browser/session attachment state, and similar environment state automatically maintained by Dominds do not belong in manual reminders. Dominds-managed reminders, panels, and tool outputs are the authoritative place for that state; manual copies go stale easily and create cognitive noise
 - Team-facing: keep `progress` scannable and centered on what is still effective now; do not let it degrade into a personal log, raw chronology, scratchpad, or stale history pile. Use `mind_more` for small additions; when cleanup/reordering/compression is needed, call `recall_taskdoc` first and then use `change_mind` with the returned `content_hash` as `previous_content_hash`
 - Condense when needed: `mind_more` is not the default bookkeeping move. If one topic already has several phase notes, prefer `change_mind` to merge them into the current summary; put the detailed expansion in formal rtws documentation and keep a document pointer in Taskdoc. If the replacement would overwrite existing content, proceed only with direct human confirmation or after applying a human-approved SOP/acceptance standard that considers the existing content
-- Collapse before clearing: the Main Dialog first states this dialog task goal in a `scope=dialog` continuation-package reminder, then writes only facts that other dialogs/teammates sharing the same Taskdoc truly need into the appropriate Taskdoc sections, and keeps resume-critical details for this dialog in `dialog` reminders; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed `dialog` continuation-package reminders. If Dominds has already warned that context is tight or critical, rough multi-reminder carry-over is acceptable; once the new course starts, continue this dialog from the task goal in `scope=dialog` reminders before reconciling
+- Collapse before clearing: in a Main Dialog, first read the fixed goal reminder. If it says to ask the human, ask and record the answer with `set_dialog_goal`. Then write only facts that other dialogs/teammates sharing the same Taskdoc truly need into the appropriate Taskdoc sections, and keep resume-critical details for this dialog in `dialog` reminders. A Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed `dialog` continuation-package reminders that state that Side Dialog's task goal. If Dominds has already warned that context is tight or critical, rough multi-reminder carry-over is acceptable; once the new course starts, continue this dialog from the fixed Main Dialog goal reminder or the Side Dialog task goal in `scope=dialog` reminders before reconciling
 - Avoid raw-material dumps: do not paste long logs or large tool outputs into reminders
 - Documentation layering: Taskdoc says “what the team should sync on / do next now”; formal rtws documentation carries “why, how, detailed evidence, and the full process”. When Taskdoc references formal rtws documentation, use a stable path/section name/relevant command instead of copying the full content
 
@@ -165,5 +166,5 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 1. `dialog` reminders end with the dialog; `task` reminders stay visible under the current Taskdoc; `agent` reminders stay visible in later dialogs you lead
 2. Use `do_mind` to create missing Taskdoc sections; use `mind_more` for small Taskdoc additions; use `change_mind` for full-section replacement of existing sections only after merging existing content and calling `recall_taskdoc` for the current `content_hash`; use `never_mind` when a whole section file should be deleted. Do not treat `mind_more` as a chronology tool; when cleanup, stale-entry removal, or same-topic consolidation is needed, use `recall_taskdoc` then `change_mind`
 3. `do_mind` / `mind_more` / `change_mind` / `never_mind` do not start a new course
-4. A continuation-package reminder must be current-dialog scoped (`scope=dialog`) and state this dialog task goal. In the Main Dialog, write only facts that other dialogs/teammates sharing the same Taskdoc truly need into Taskdoc, while reminders keep details still not covered by Taskdoc but easy to lose when resuming this dialog; in a Side Dialog after Dominds warns that context is tight or critical, maintain sufficiently detailed `dialog` continuation-package reminders only
+4. Main Dialog goals live in the fixed goal reminder and must be changed with `set_dialog_goal`; ordinary `dialog` reminders keep continuation details only. Side Dialog continuation-package reminders must be current-dialog scoped (`scope=dialog`) and state that Side Dialog's task goal. In the Main Dialog, write only facts that other dialogs/teammates sharing the same Taskdoc truly need into Taskdoc, while reminders keep details still not covered by Taskdoc but easy to lose when resuming this dialog
 5. Do not turn `task` / `agent` reminders into a long-term fact dump; move durable knowledge into `personal_memory`

package/dist/tools/prompts/control/en/scenarios.md

@@ -15,7 +15,7 @@
 
 ### Scenario Description
 
-Use reminders for the current task's current work: next steps, blockers, and volatile details that are not meant to become the team's Taskdoc bulletin board. A continuation package prepared before `clear_mind` is resume state for the current dialog, so it must explicitly use `scope=dialog` and state this dialog task goal.
+Use reminders for the current task's current work: next steps, blockers, and volatile details that are not meant to become the team's Taskdoc bulletin board. Main Dialog goals come from the fixed goal reminder and are maintained with `set_dialog_goal`; ordinary continuation packages before `clear_mind` keep resume details only. Side Dialog continuation packages must explicitly use `scope=dialog` and state that Side Dialog's task goal.
 
 ### Example
 
@@ -31,10 +31,15 @@ add_reminder({
   scope: 'dialog',
 });
 
-// clear_mind continuation packages must explicitly use dialog and state this dialog task goal
+// Main Dialog goals are maintained through the fixed goal reminder; ordinary dialog reminders keep resume details
+set_dialog_goal({
+  mode: 'goal',
+  goal: 'Keep reviewing control-manual course-transition guidance.',
+});
+
 add_reminder({
   content:
-    'Continuation goal: keep reviewing control-manual course-transition guidance; next check whether scenarios/index still imply task scope for continuation packages',
+    'Next check whether scenarios/index still imply task scope for continuation packages; focus on the control manual reminder-scope wording.',
   scope: 'dialog',
 });
 
@@ -59,7 +64,7 @@ delete_reminder({
 ### Key Points
 
 - Default to `task` for ordinary next steps, temporary blockers, and current-work details under the same Taskdoc
-- Use `dialog` only for notes that are truly local to the current dialog; continuation packages before `clear_mind` must explicitly use `scope=dialog` and state this dialog task goal
+- Use `dialog` only for notes that are truly local to the current dialog. Main Dialog goals come from the fixed goal reminder; Side Dialog continuation packages state that Side Dialog's task goal in `scope=dialog`
 - Use `agent` only for urgent, short-lived, globally visible cues
 - If the information should synchronize the whole team's current effective state, put it in Taskdoc `progress` instead
 - If the note is durable knowledge rather than an active current-work cue, move it to `personal_memory` instead

package/dist/tools/prompts/control/en/tools.md

@@ -45,7 +45,7 @@ Add reminder.
 Use when:
 
 - Adding a new temporary current-work item
-- Before `clear_mind`, first state this dialog task goal in a current-dialog scoped (`scope=dialog`) continuation-package reminder. A Main Dialog records only discussion facts that other dialogs/teammates sharing the same Taskdoc truly need to know into Taskdoc, then keeps resume-critical details for this dialog in `dialog` reminders; a Side Dialog directly maintains sufficiently detailed `dialog` continuation-package reminders. When Dominds has already warned that context is tight or critical, Side Dialog reminders have no fixed length limit and rough bridge notes are acceptable
+- Before `clear_mind`, ordinary `dialog` continuation packages keep next steps, key pointers, run/verify notes, and volatile details. Main Dialog goals come from the fixed goal reminder and are maintained with `set_dialog_goal`. A Side Dialog directly maintains sufficiently detailed `dialog` continuation-package reminders and states that Side Dialog's task goal. When Dominds has already warned that context is tight or critical, Side Dialog reminders have no fixed length limit and rough bridge notes are acceptable
 - Record only manually maintained current-work / continuation details; do not put environment state automatically maintained by Dominds, such as background process status, in-flight background asks, or session attachment state, into manual reminders
 
 **Parameters:**
@@ -135,7 +135,41 @@ migrate_reminder({
 });
 ```
 
-### 5. clear_mind
+### 5. set_dialog_goal
+
+Set the fixed "Goal for this Main Dialog" reminder.
+
+Use when:
+
+- The fixed reminder says "not set" or "needs human confirmation": first ask the human what this Main Dialog should work on next, then record the answer with `mode="goal"`
+- Dominds allows this Main Dialog to proceed from the Taskdoc: record that with `mode="follow_taskdoc"`
+
+**Parameters:**
+
+- `mode` (required): `goal` / `follow_taskdoc`
+- `goal`: required when `mode="goal"`; write what this Main Dialog should work on next
+
+**Failures:**
+
+- Side Dialogs cannot call this tool
+- If Dominds has confirmed that the same agent now has another parallel dialog, `mode="follow_taskdoc"` fails; the fixed reminder keeps "proceed from the Taskdoc" and adds a parallel-dialog note telling the agent to ask the human first
+
+**Example:**
+
+```js
+set_dialog_goal({
+  mode: 'goal',
+  goal: 'Finish the fixed Main Dialog goal reminder and run reminder-scope regression tests.',
+});
+```
+
+```js
+set_dialog_goal({
+  mode: 'follow_taskdoc',
+});
+```
+
+### 6. clear_mind
 
 Start a new dialog course.
 
@@ -160,7 +194,7 @@ status: ok|error
 - If you just finished writing the same continuation info via `add_reminder` / `update_reminder`, prefer `clear_mind({})`
 - If you are not sure whether it duplicates something, a small amount of redundancy is acceptable; do not risk losing information just to force perfect dedupe
 
-### 5. do_mind
+### 7. do_mind
 
 Create a new Taskdoc section. It fails if the target section already exists.
 
@@ -178,7 +212,7 @@ Create a new Taskdoc section. It fails if the target section already exists.
 - Does not start a new course
 - Changes visible to all teammates
 
-### 6. change_mind
+### 8. change_mind
 
 Update taskdoc chapter.
 
@@ -205,7 +239,7 @@ updated_at: <update timestamp>
 - Changes visible to all teammates
 - Constraint rule: `constraints` must include only task-specific hard requirements; do not repeat global rules. If a duplicate is found, delete it and inform the user
 
-### 7. mind_more
+### 9. mind_more
 
 Append entries to a Taskdoc section; defaults to `progress`, reducing full-section replacement pressure.
 
@@ -235,7 +269,7 @@ mind_more({
 - If stale entries must be removed, reordered, or compressed, call `recall_taskdoc` first and then use `change_mind` with the returned `content_hash` as `previous_content_hash` for a full-section replacement; if a whole section file should be deleted, use `never_mind`
 - When one topic already has several phase notes, prefer `change_mind` to merge them into a concise current announcement instead of continuing to call `mind_more`
 
-### 8. never_mind
+### 10. never_mind
 
 Delete a Taskdoc section file.
 
@@ -250,7 +284,7 @@ Delete a Taskdoc section file.
 - Use it only when the whole section is no longer valid. If you only need to remove stale entries or compress structure, prefer `recall_taskdoc` followed by `change_mind` with the cleaned full section and returned `content_hash` as `previous_content_hash`
 - Does not start a new course
 
-### 9. recall_taskdoc
+### 11. recall_taskdoc
 
 Read taskdoc chapter.
 
@@ -284,6 +318,15 @@ update_reminder({
 clear_mind({});
 ```
 
+### Set Main Dialog Goal
+
+```typescript
+set_dialog_goal({
+  mode: 'goal',
+  goal: 'Finish the fixed Main Dialog goal reminder and verify single-/multi-dialog state changes.',
+});
+```
+
 ### Switch Course and Add One Extra Continuation Note
 
 ```typescript
@@ -382,8 +425,9 @@ message: <error message>
 ## Reminder Content Guidance
 
 - Normal reminders should stay concise, fresh, and directly actionable; often 1-3 items total
-- For a continuation package, explicitly use `scope=dialog` and structure notes by default: current dialog task goal, next step, key pointers, run/verify, easy-to-lose volatile details
-- If Dominds has already warned that context is tight or critical: the Main Dialog first states this dialog goal in a `dialog` continuation-package reminder, then records only facts that other dialogs/teammates sharing the same Taskdoc truly need into the appropriate Taskdoc sections, and finally keeps necessary resume-critical details for this dialog in continuation-package reminders; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed `dialog` continuation-package reminders with no fixed length limit. Rough multi-reminder bridge notes are acceptable; once the new course starts, continue this dialog from the task goal in `scope=dialog` reminders before reconciling
+- Main Dialog goals come only from the fixed goal reminder: read the whole reminder; if it says to ask the human, ask first and record the answer with `set_dialog_goal`; if it says "proceed from the Taskdoc" and has no parallel-dialog note, continue from the Taskdoc
+- For an ordinary continuation package, explicitly use `scope=dialog` and structure notes by default: next step, key pointers, run/verify, easy-to-lose volatile details. Side Dialog continuation packages must also state that Side Dialog's task goal
+- If Dominds has already warned that context is tight or critical: the Main Dialog first follows the fixed goal reminder, then records only facts that other dialogs/teammates sharing the same Taskdoc truly need into the appropriate Taskdoc sections, and finally keeps necessary resume-critical details for this dialog in continuation-package reminders; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed `dialog` continuation-package reminders with no fixed length limit. Rough multi-reminder bridge notes are acceptable; once the new course starts, continue this dialog from the fixed Main Dialog goal reminder or the Side Dialog task goal in `scope=dialog` reminders before reconciling
 - Keep only details still not covered by Taskdoc but easy to lose when resuming this dialog; do not repeat team-shared status. If the team needs “where we are now / which decisions are in effect / what is next / which blockers still hold”, write it back to Taskdoc `progress`
 - Do not manually record environment state automatically maintained by Dominds, such as whether background processes are still running, in-flight background asks/collaboration, or browser/session attachment state. Manual copies go stale easily and conflict with the Dominds-managed status, creating cognitive noise
 - Do not paste long logs, large tool outputs, or raw material into reminders

package/dist/tools/prompts/control/zh/index.md

@@ -26,7 +26,7 @@
 
 control 是 Dominds 的**对话控制工具集**，用于管理对话状态、提醒、差遣牒，以及跨对话回复收口语义：
 
-- **提醒管理**：提醒分 `dialog` / `task` / `agent` 三个 scope；默认是 `task`，用于同一差遣牒任务下的普通手头工作；`dialog` 用于真正对话局部的提醒，准备 `clear_mind` 的接续包必须显式 `scope=dialog` 并写明本路对话任务目标；`agent` 只用于紧急、短期、全局刺眼提醒
+- **提醒管理**：主线对话固定显示“本路主线目标”提醒；若它要求先问人类，就立即问人类并用 `set_dialog_goal` 记录答案。普通提醒分 `dialog` / `task` / `agent` 三个 scope；默认是 `task`，用于同一差遣牒任务下的普通手头工作；`dialog` 用于真正对话局部的接续细节；`agent` 只用于紧急、短期、全局刺眼提醒
 - **差遣牒操作**：追加、替换或删除任务契约章节（goals/constraints/progress）；其中 `progress` 是全队共享、准实时、可扫读的任务公告牌
 - **上下文维护**：在不丢关键恢复线索的前提下降低认知负载
 - **回复路由**：在支线/回问语境下，区分回问诉请者、发送最终回贴与普通文本的职责边界
@@ -58,11 +58,13 @@ control 是 Dominds 的**对话控制工具集**，用于管理对话状态、
 - 记录阻塞问题
 - 在 `clear_mind` 前承载当前对话范围的接续包；若 Dominds 已提醒当前程吃紧/告急，可先带多条粗略提醒项过桥
 
+主线对话会一直带一条 Dominds 维护的“本路主线目标”提醒。必须完整读完这条提醒：看到它要求先问人类，就问“这一路主线接下来具体推进什么？”，得到答案后用 `set_dialog_goal` 记录。看到它写“依差遣牒推进”且没有并行对话提示，才按差遣牒继续；若同一条提醒说 Dominds 已确认有并行对话，也必须先问人类。
+
 提醒不用于手工复制 Dominds 会自动维护的系统状态，例如后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等。这些状态以 Dominds 自动维护的提醒、面板和工具输出为准；手工记录很容易过时并造成认知干扰。
 
 scope 规则：
 
-- `dialog`：当前对话手头工作；准备 `clear_mind` 的接续包必须显式使用这个范围，并写明本路对话任务目标
+- `dialog`：当前对话手头工作与接续细节；主线目标看固定“本路主线目标”提醒，支线接续包需要写清本路支线任务目标
 - `task`：当前差遣牒任务下的手头工作，默认范围
 - `agent`：在由你主理的后续对话里也应继续看到的紧急、短期、全局刺眼提醒
 

package/dist/tools/prompts/control/zh/principles.md

@@ -42,7 +42,7 @@
 - `agent` 提醒会在由你主理的后续对话里继续可见
 - 可随时添加、修改、删除
 - 默认应保持少量、可扫读、可直接指导下一步
-- 准备 `clear_mind` 时，必须先用当前对话范围（`scope=dialog`）接续包提醒项写明本路对话任务目标；主线对话只把确需同一差遣牒其它对话/队友知会的讨论事实补进差遣牒，再把恢复本路对话容易丢的信息留在 `dialog` 提醒项；支线对话直接维护足够详尽的 `dialog` 接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，也可先保留多条粗略提醒项过桥
+- 主线对话固定有“本路主线目标”提醒。完整读完这条提醒：它要求先问人类就先问并用 `set_dialog_goal` 记录；它写“依差遣牒推进”且没有并行对话提示，才按差遣牒继续；如果同一条提醒说 Dominds 已确认有并行对话，也先问人类。普通 `dialog` 接续包只保留恢复本路对话容易丢的细节；支线对话直接维护足够详尽的 `dialog` 接续包提醒项并写清本路支线任务目标。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，也可先保留多条粗略提醒项过桥
 
 **与 memory 的区别：**
 | 特性 | dialog reminder | task reminder | agent reminder | personal memory |
@@ -90,6 +90,7 @@
 | delete_reminder  | 删除提醒                          |
 | update_reminder  | 更新提醒内容                      |
 | migrate_reminder | 将误扩散的共享提醒迁回当前对话    |
+| set_dialog_goal  | 设置本路主线目标                  |
 | do_mind          | 创建新差遣牒章节                  |
 | mind_more        | 向差遣牒追加条目（默认 progress） |
 | change_mind      | 整章替换已有差遣牒章节            |
@@ -123,7 +124,7 @@
 
 - **当前手头工作**：当前下一步、阻塞、关键定位信息
 - **易丢细节**：临时路径、id、命令、样例输入
-- **换程接续**：在 `clear_mind` 前整理当前对话范围（`scope=dialog`）接续包，必须写明本路对话任务目标；若 Dominds 已提醒当前程吃紧/告急，可先保留多条粗略提醒项
+- **换程接续**：主线目标看固定“本路主线目标”提醒；普通 `dialog` 接续包只写下一步、关键定位、运行/验证方式和容易丢的临时细节。支线接续包必须写清本路支线任务目标；若 Dominds 已提醒当前程吃紧/告急，可先保留多条粗略提醒项
 - **任务延续提示**：如果在当前差遣牒任务内都应该继续看到它，用 `task`
 - **全局刺眼提示**：如果它应该在由你主理的后续对话里继续看到，而且是短期、紧急、全局刺眼提醒，用 `agent`
 
@@ -140,7 +141,7 @@
 - 避免重复系统状态：后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等 Dominds 会自动维护的信息，不要写进手工提醒项；这些状态以 Dominds 自动维护的提醒、面板和工具输出为准，手工副本容易过时并造成认知干扰
 - 面向全队：`progress` 应保持可扫读、以“当前仍有效”为准，不要退化成个人日志、流水账、临时便签或历史残影堆积；少量新增用 `mind_more`，需要清旧/重排/压缩时先调用 `recall_taskdoc`，再用 `change_mind` 并携带返回的 `content_hash` 作为 `previous_content_hash`
 - 按需整理：`mind_more` 不是默认记账动作。若同一主题已有多条阶段性记录，优先用 `change_mind` 合并成当前摘要；把细节放进 rtws 正式文档，并在差遣牒里保留文档定位 pointer。若会冲掉原有内容，必须有直接人类确认，或已按人类认可 SOP/验收标准充分考虑原有内容后再改写
-- 换程前收束：主线对话先用 `scope=dialog` 接续包提醒项写明本路对话任务目标，再把确需同一差遣牒其它对话/队友知会的讨论事实写入差遣牒合适章节，最后把恢复本路对话容易丢的信息留在 `dialog` 提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的 `dialog` 接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，则先保留多条粗略提醒项过桥也可以；当前程只做保信息 + `clear_mind`，Dominds 真正开启新一程后第一步按 `scope=dialog` 提醒项里的任务目标继续本路对话，再收敛
+- 换程前收束：主线对话先看固定“本路主线目标”提醒；如果它要求先问人类，就先问人类并用 `set_dialog_goal` 记录。然后只把确需同一差遣牒其它对话/队友知会的讨论事实写入差遣牒合适章节，最后把恢复本路对话容易丢的信息留在 `dialog` 提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的 `dialog` 接续包提醒项并写清本路支线任务目标。若 Dominds 已提醒上下文吃紧/告急，则先保留多条粗略提醒项过桥也可以；当前程只做保信息 + `clear_mind`，Dominds 真正开启新一程后第一步按固定主线目标提醒或支线 `dialog` 提醒项里的任务目标继续本路对话，再收敛
 - 拒绝原料堆积：不要把长日志/大段 tool output 直接塞进提醒项
 - 文档分层：差遣牒写“现在应如何同步/推进”，正式文档写“为什么、怎么做、详细证据和完整过程”。差遣牒需要引用正式文档时，写稳定路径/章节名/相关命令，而不是复制整段内容
 
@@ -164,5 +165,5 @@
 1. `dialog` 提醒会随对话结束而结束；`task` 提醒会在当前差遣牒任务内继续可见；`agent` 提醒会在由你主理的后续对话里继续可见
 2. 缺失差遣牒章节用 `do_mind` 创建；差遣牒少量新增可用 `mind_more` 追加；已有章节整段替换用 `change_mind`，请确保合并已有内容，并先调用 `recall_taskdoc` 取得当前 `content_hash` 作为 `previous_content_hash`；确需删除整章文件时用 `never_mind`。不要把 `mind_more` 当流水账工具；需要整理、去旧、合并同主题记录时先 `recall_taskdoc` 再 `change_mind`
 3. `do_mind` / `mind_more` / `change_mind` / `never_mind` 不开启新 course
-4. 接续包提醒项必须是当前对话范围（`scope=dialog`）并写明本路任务目标；主线对话只把确需同一差遣牒其它对话/队友知会的事实写入差遣牒，提醒项保留差遣牒仍未覆盖、但恢复本路对话容易丢的细节；支线对话在吃紧/告急时只维护足够详尽的 `dialog` 接续包提醒项
+4. 主线目标只看固定“本路主线目标”提醒，并用 `set_dialog_goal` 修改；普通 `dialog` 提醒只放接续细节。支线接续包提醒项必须是当前对话范围（`scope=dialog`）并写明本路支线任务目标；主线对话只把确需同一差遣牒其它对话/队友知会的事实写入差遣牒，提醒项保留差遣牒仍未覆盖、但恢复本路对话容易丢的细节
 5. 不要把 `task` / `agent` 提醒堆成长期事实仓库；耐久知识应迁到 `personal_memory`

package/dist/tools/prompts/control/zh/scenarios.md

@@ -15,7 +15,7 @@
 
 ### 场景描述
 
-使用 reminders 承接当前任务的手头工作：下一步、临时阻塞、易丢细节，而不是把它写成面向全队同步的 Taskdoc 公告牌。准备 `clear_mind` 的接续包是当前对话恢复线索，必须显式 `scope=dialog` 并写明本路对话任务目标。
+使用 reminders 承接当前任务的手头工作：下一步、临时阻塞、易丢细节，而不是把它写成面向全队同步的 Taskdoc 公告牌。主线对话的目标看固定“本路主线目标”提醒，并用 `set_dialog_goal` 维护；准备 `clear_mind` 的普通接续包只放恢复现场需要的细节。支线对话的接续包必须显式 `scope=dialog` 并写明本路支线任务目标。
 
 ### 示例
 
@@ -31,10 +31,15 @@ add_reminder({
   scope: 'dialog',
 });
 
-// clear_mind 接续包必须显式 dialog，并写明当前这一路对话的任务目标
+// 主线目标用固定提醒维护；普通 dialog 接续包只保留恢复现场需要的细节
+set_dialog_goal({
+  mode: 'goal',
+  goal: '继续复核 control 手册换程引导。',
+});
+
 add_reminder({
   content:
-    '接续目标：继续复核 control 手册换程引导；下一步先检查 scenarios/index 是否还把接续包暗示成 task',
+    '下一步先检查 scenarios/index 是否还把接续包暗示成 task；重点看 control 手册的提醒范围说明。',
   scope: 'dialog',
 });
 
@@ -59,7 +64,7 @@ delete_reminder({
 ### 关键点
 
 - 同一差遣牒任务内的普通下一步、临时阻塞、手头细节默认用 `task`
-- 真正只对当前对话有效的提醒才用 `dialog`；准备 `clear_mind` 的接续包必须显式 `scope=dialog`，并写明本路对话任务目标
+- 真正只对当前对话有效的提醒才用 `dialog`；主线目标看固定“本路主线目标”提醒，支线接续包才在 `scope=dialog` 里写明本路支线任务目标
 - 只有紧急、短期、全局刺眼提醒才用 `agent`
 - 如果信息需要向全队同步当前有效状态、关键决策、下一步或仍成立阻塞，应写入 Taskdoc `progress`
 - 如果内容本质上是长期知识而不是当前手头工作提示，应改存到 `personal_memory`

package/dist/tools/prompts/control/zh/tools.md

@@ -45,7 +45,7 @@
 **适用：**
 
 - 添加新的临时手头工作条目
-- 若准备 `clear_mind`，必须用 `scope=dialog` 接续包提醒项写明本路对话任务目标；主线对话只把确需同一差遣牒其它对话/队友知会的讨论事实补进差遣牒，再保留恢复本路对话容易丢的信息；支线对话直接维护足够详尽的 `dialog` 接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，先记粗略过桥信息也可以
+- 若准备 `clear_mind`，普通 `dialog` 接续包只写下一步、关键定位、运行/验证方式和容易丢的临时细节；主线目标看固定“本路主线目标”提醒并用 `set_dialog_goal` 维护；支线对话直接维护足够详尽的 `dialog` 接续包提醒项并写清本路支线任务目标。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，先记粗略过桥信息也可以
 - 只记录需要你手工维护的手头工作/接续细节；不要在手工提醒项里记录后台进程状态、后台进行中诉请、会话附件状态等 Dominds 会自动维护的信息
 
 **参数：**
@@ -135,7 +135,41 @@ migrate_reminder({
 });
 ```
 
-### 5. clear_mind
+### 5. set_dialog_goal
+
+设置当前主线对话的“本路主线目标”提醒。
+
+**适用：**
+
+- 固定提醒写着“未设置”或“需要人类确认”时：先问人类“这一路主线接下来具体推进什么？”，再用 `mode="goal"` 记录答案
+- Dominds 允许本路主线直接按差遣牒推进时：用 `mode="follow_taskdoc"` 记录“依差遣牒推进”
+
+**参数：**
+
+- `mode`（必需）：`goal` / `follow_taskdoc`
+- `goal`：`mode="goal"` 时必需；写清这一路主线接下来具体推进什么
+
+**失败：**
+
+- 支线对话不能调用
+- 当 Dominds 已确认同一智能体有其它并行对话时，`mode="follow_taskdoc"` 会失败；固定提醒会保留“依差遣牒推进”，并补充“已有并行对话，先问人类”
+
+**示例：**
+
+```js
+set_dialog_goal({
+  mode: 'goal',
+  goal: '补齐主线目标提醒机制，并跑提醒范围回归测试。',
+});
+```
+
+```js
+set_dialog_goal({
+  mode: 'follow_taskdoc',
+});
+```
+
+### 6. clear_mind
 
 开启新一程对话。
 
@@ -160,7 +194,7 @@ status: ok|error
 - 若你刚刚已经 `add_reminder` / `update_reminder` 完同一份接续信息，优先直接 `clear_mind({})`
 - 若不确定是否重复，少量重复可以接受；不要为了“绝不重复”而冒信息丢失风险
 
-### 5. do_mind
+### 7. do_mind
 
 创建新的差遣牒章节。若目标章节已存在，会失败。
 
@@ -178,7 +212,7 @@ status: ok|error
 - 不开启新 course
 - 变更对所有队友可见
 
-### 6. change_mind
+### 8. change_mind
 
 更新差遣牒章节。
 
@@ -205,7 +239,7 @@ updated_at: <更新时间戳>
 - 变更对所有队友可见
 - 约束规则：`constraints` 只写任务特有硬要求，不得重复系统提示/工具文档中的全局规则；一经发现重复，必须删除并告知用户
 
-### 7. mind_more
+### 9. mind_more
 
 向差遣牒章节追加条目；默认追加到 `progress`，用于降低整章替换压力。
 
@@ -232,7 +266,7 @@ mind_more({
 - 若需要删除陈旧项、重排结构或压缩公告牌，先调用 `recall_taskdoc`，再使用带返回 `content_hash` 作为 `previous_content_hash` 的 `change_mind` 做整章替换；若要删除整个章节文件，使用 `never_mind`
 - 当同一主题已经有多条阶段记录时，优先 `change_mind` 合并成当前仍有效的简明公告，而不是继续 `mind_more`
 
-### 8. never_mind
+### 10. never_mind
 
 删除差遣牒章节文件。
 
@@ -247,7 +281,7 @@ mind_more({
 - 仅用于章节整体不再成立；如果只是删除几条陈旧项或压缩结构，优先先 `recall_taskdoc`，再用带返回 `content_hash` 作为 `previous_content_hash` 的 `change_mind` 写回整理后的全文
 - 不开启新 course
 
-### 9. recall_taskdoc
+### 11. recall_taskdoc
 
 读取差遣牒章节。
 
@@ -280,6 +314,15 @@ update_reminder({
 clear_mind({});
 ```
 
+### 设置本路主线目标
+
+```typescript
+set_dialog_goal({
+  mode: 'goal',
+  goal: '把固定主线目标提醒改到位，并验证单路/多路状态切换。',
+});
+```
+
 ### 换程时补一条额外接续信息
 
 ```typescript
@@ -375,8 +418,9 @@ message: <错误消息>
 ## 提醒项内容建议
 
 - 默认提醒项应保持短、新、能直接指导下一步，常见 1–3 条
-- 若用于接续包，必须显式 `scope=dialog`，并默认优先结构化内容：当前对话任务目标、下一步行动、关键定位、运行/验证、容易丢的临时细节
-- 若 Dominds 已提醒上下文吃紧/告急：主线对话先用 `dialog` 接续包提醒项写明本路目标，再把确需同一差遣牒其它对话/队友知会的讨论事实写入差遣牒合适章节，最后保留恢复本路对话必要的接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的 `dialog` 接续包提醒项，没有固定长度限制；多条粗略提醒项也可以，Dominds 真正开启新一程后第一步按 `scope=dialog` 提醒项里的任务目标继续本路对话，再收敛整理
+- 主线目标只看固定“本路主线目标”提醒：完整读完它；它让你问人类就先问人类并用 `set_dialog_goal` 记录；它写“依差遣牒推进”且没有并行对话提示，才按差遣牒继续
+- 若普通提醒用于接续包，必须显式 `scope=dialog`，并默认优先结构化内容：下一步行动、关键定位、运行/验证、容易丢的临时细节；支线接续包还要写清本路支线任务目标
+- 若 Dominds 已提醒上下文吃紧/告急：主线对话先按固定“本路主线目标”提醒处理目标，再把确需同一差遣牒其它对话/队友知会的讨论事实写入差遣牒合适章节，最后保留恢复本路对话必要的接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的 `dialog` 接续包提醒项，没有固定长度限制；多条粗略提醒项也可以，Dominds 真正开启新一程后第一步按固定主线目标提醒或支线 `dialog` 提醒项里的任务目标继续本路对话，再收敛整理
 - 接续包只保留差遣牒仍未覆盖、但恢复本路对话容易丢的细节；不要重复团队共享状态。要向全队同步“现在到哪了 / 哪些决策已生效 / 下一步是什么 / 哪些阻塞仍成立”，请写回 Taskdoc `progress`
 - 不要手工记录 Dominds 会自动维护的系统状态，例如后台进程是否仍在运行、后台进行中的诉请/协作、浏览器/会话附件状态等；手工记录很容易过时，并与 Dominds 自动维护的状态冲突，造成认知干扰
 - 不要把长日志、大段 tool output、原始材料直接塞进提醒项

package/dist/tools/team_mgmt-manual.js

@@ -110,12 +110,13 @@ async function renderTeamMgmtGuideContent(language, topicsRaw = []) {
                     '最小示例：\n```yaml\nproviders:\n  my_provider:\n    apiKeyEnvVar: MY_PROVIDER_API_KEY\n    models:\n      my_model: { name: "my-model-id" }\n```\n然后在 `.minds/team.yaml` 里引用 `provider: my_provider` / `model: my_model`。',
                     '覆盖/合并语义：`.minds/llm.yaml` 会在内置 defaults 之上做覆盖（以当前实现为准）；定义一个 provider key 并不意味着“禁用其他内置 provider”。',
                     '不要在文件里存 API key，使用环境变量（apiKeyEnvVar）。',
+                    '认证边界：内置 `apiType: codex` provider 只接受完整、可刷新且来自文件的 ChatGPT 托管 OAuth（最终 `auth_mode: chatgpt`）。临时认证仓、不完整 `chatgpt`、`chatgptAuthTokens`、API key、外部 headers、Agent Identity、PAT、Bedrock 及未知新模式都会在请求前拒绝。需要其他认证时，改用自定义 `apiType: openai` Responses provider；若仍无法覆盖，请向 Dominds 提交 feature request。以后同步 codex-rs 时不得自动扩大此边界。',
                     'member_defaults.provider/model 需要引用这里的 key。',
                     '`model_param_options` 可选：用于记录该 provider 支持的 `.minds/team.yaml model_params` 选项（文档用途）。',
-                    '`apiQuirks` 可选：写在 `providers.<providerKey>.apiQuirks`，类型是 `string|string[]`；需要多个 quirk 时用数组，例如 `apiQuirks: [same-context-empty-response]`。它是 provider 级 transport / 网关兼容开关，用来描述“这个供应商/网关的 API 有非标准行为”，不是 `.minds/team.yaml` 的成员参数，也不是 `model_params`。',
-                    '使用原则：只有在你确认某个上游网关确实偏离了标准协议，而且 Dominds 已为这个偏差实现了命名 quirk 时才配置；不要把它当作随意调参入口。当前实现里，未知 quirk 值通常不会报错，但也不会带来任何效果。',
-                    '当前已知示例：OpenAI Responses 包装层支持 `apiQuirks: xcode.best`（或数组里包含它），用于识别 vendor keepalive、处理 xcode.best 特有的失败模式，以及把网关返回的 HTML 版 502 Bad Gateway 错误页和 `500 auth_unavailable: no auth available` 这类基础设施失败归类为 conservative 策略重试。OpenAI-compatible Chat Completions 包装层支持 `apiQuirks: same-context-empty-response`，用于“同一对话 generation 上下文连续返回 empty response”时先做少量临时重试；支持 `apiQuirks: volcengine-invalid-parameter-aggressive-retry`，用于火山方舟 Coding Plan 偶发 `400 InvalidParameter` 但同 payload 可重放成功的场景，将其归类为 aggressive 策略重试；支持内置 `kimi-code` provider 使用的 `apiQuirks: kimi-code`，用于 Kimi Code 专用 User-Agent（`KimiCLI/Dominds/<version>`）、`prompt_cache_key` 和 `thinking`/`reasoning_effort` 请求整形；也支持 `apiQuirks: minimax-reasoning-details`，用于 MiniMax OpenAI-compatible `/v1` 默认启用 `reasoning_split: true`，并跨轮完整保留 `reasoning_details`；支持 `apiQuirks: minimax-thinking-type`，用于把请求里的 `thinking: true` / `thinking: { type: "enabled" }` 归一化为 `thinking: { type: "adaptive" }`（MiniMax 的 `/v1` API 拒绝 `enabled`，只接受 `adaptive` / `disabled`）。最小示例：\n```yaml\nproviders:\n  my_gateway:\n    apiType: openai-compatible\n    baseUrl: https://example.invalid/v1\n    apiKeyEnvVar: MY_GATEWAY_API_KEY\n    apiQuirks: same-context-empty-response\n    models:\n      my_model: { name: "upstream-model-id" }\n```',
-                    '边界提醒：`apiQuirks` 只影响实现里显式消费它的 provider/generator。就当前实现看，OpenAI Responses 与 OpenAI-compatible 路径会读取它；不要假设所有 `apiType` 都支持或需要它。若配置后行为仍异常，应继续检查上游网关文档、抓流事件类型，并结合 `team_mgmt_check_provider(...)` / 运行日志排查。',
+                    '`apiQuirks` 可选：写在 `providers.<providerKey>.apiQuirks`，类型是 `string|string[]`；需要多个 quirk 时用数组，例如 `apiQuirks: [same-context-empty-response]`。它是 provider 级 transport / 网关兼容 / 请求整形开关，用来描述“这个供应商/网关/API 路径有非标准行为”，不是 `.minds/team.yaml` 的成员参数，也不是 `model_params`。',
+                    '使用原则：只有在你确认某个 provider/API 路径确实存在非标准行为，且 Dominds 已为这个偏差或请求整形需求实现了命名 quirk 时才配置；不要把它当作随意调参入口。当前实现里，未知 quirk 值通常不会报错，但也不会带来任何效果。',
+                    '当前已知示例：内置 Codex (ChatGPT) provider 默认启用 `apiQuirks: codex-anti-early-finalization`，只在 Codex provider 的 `instructions` 里按当前工作语言追加“每轮完成必要推理后再作答”的请求整形提示，用于规避 ChatGPT/Codex 路径疑似思考过早截断/提前收尾的问题；它不会应用到 OpenAI API provider。OpenAI Responses 包装层支持 `apiQuirks: xcode.best`（或数组里包含它），用于识别 vendor keepalive、处理 xcode.best 特有的失败模式，以及把网关返回的 HTML 版 502 Bad Gateway 错误页和 `500 auth_unavailable: no auth available` 这类基础设施失败归类为 conservative 策略重试。OpenAI-compatible Chat Completions 包装层支持 `apiQuirks: same-context-empty-response`，用于“同一对话 generation 上下文连续返回 empty response”时先做少量临时重试；支持 `apiQuirks: volcengine-invalid-parameter-aggressive-retry`，用于火山方舟 Coding Plan 偶发 `400 InvalidParameter` 但同 payload 可重放成功的场景，将其归类为 aggressive 策略重试；支持内置 `kimi-code` provider 使用的 `apiQuirks: kimi-code`，用于 Kimi Code 专用 User-Agent（`KimiCLI/Dominds/<version>`）、`prompt_cache_key` 和 `thinking`/`reasoning_effort` 请求整形；也支持 `apiQuirks: minimax-reasoning-details`，用于 MiniMax OpenAI-compatible `/v1` 默认启用 `reasoning_split: true`，并跨轮完整保留 `reasoning_details`；支持 `apiQuirks: minimax-thinking-type`，用于把请求里的 `thinking: true` / `thinking: { type: "enabled" }` 归一化为 `thinking: { type: "adaptive" }`（MiniMax 的 `/v1` API 拒绝 `enabled`，只接受 `adaptive` / `disabled`）。最小示例：\n```yaml\nproviders:\n  my_gateway:\n    apiType: openai-compatible\n    baseUrl: https://example.invalid/v1\n    apiKeyEnvVar: MY_GATEWAY_API_KEY\n    apiQuirks: same-context-empty-response\n    models:\n      my_model: { name: "upstream-model-id" }\n```',
+                    '边界提醒：`apiQuirks` 只影响实现里显式消费它的 provider/generator。就当前实现看，Codex、OpenAI Responses 与 OpenAI-compatible 路径会读取它；不要假设所有 `apiType` 都支持或需要它。若配置后行为仍异常，应继续检查上游网关文档、抓流事件类型，并结合 `team_mgmt_check_provider(...)` / 运行日志排查。',
                 ])
             : fmtHeader('.minds/llm.yaml') +
                 fmtList([
@@ -124,12 +125,13 @@ async function renderTeamMgmtGuideContent(language, topicsRaw = []) {
                     'Minimal example:\n```yaml\nproviders:\n  my_provider:\n    apiKeyEnvVar: MY_PROVIDER_API_KEY\n    models:\n      my_model: { name: "my-model-id" }\n```\nThen reference `provider: my_provider` and `model: my_model` in `.minds/team.yaml`.',
                     'Merge/override: `.minds/llm.yaml` overrides built-in defaults (per current implementation); defining one provider does not imply disabling other built-in providers.',
                     'Do not store API keys in the file; use env vars via apiKeyEnvVar.',
+                    'Authentication boundary: the built-in `apiType: codex` provider accepts only complete, refreshable, file-backed managed ChatGPT OAuth (final `auth_mode: chatgpt`). It rejects ephemeral credentials, incomplete `chatgpt`, `chatgptAuthTokens`, API keys, external headers, Agent Identity, PAT, Bedrock, and unknown future modes before a request. Use a custom `apiType: openai` Responses provider for other authentication, or submit a Dominds feature request if that is insufficient. Future codex-rs syncs must not widen this boundary automatically.',
                     'member_defaults.provider/model must reference these keys.',
                     'Optional: `model_param_options` documents `.minds/team.yaml model_params` knobs (documentation only).',
-                    '`apiQuirks` is optional under `providers.<providerKey>.apiQuirks`, with type `string|string[]`; use an array for multiple quirks, for example `apiQuirks: [same-context-empty-response]`. It is a provider-level transport / gateway compatibility switch for non-standard upstream API behavior. It is not a `.minds/team.yaml` member field and not part of `model_params`.',
-                    'Use it only when you have confirmed that an upstream gateway deviates from the expected protocol and Dominds has an explicitly named quirk for that deviation. Do not treat it as a generic tuning field. In the current implementation, unknown quirk values are usually ignored rather than rejected, so a typo may silently do nothing.',
-                    'Known current example: the OpenAI Responses wrapper supports `apiQuirks: xcode.best` (or an array containing it) for vendor keepalive recognition, xcode.best-specific failures, and gateway-returned HTML 502 Bad Gateway plus `500 auth_unavailable: no auth available` infrastructure failures. The OpenAI-compatible Chat Completions wrapper supports `apiQuirks: same-context-empty-response` for repeated empty responses in the same dialog generation context; `apiQuirks: volcengine-invalid-parameter-aggressive-retry` for Volcano Ark Coding Plan transient `400 InvalidParameter` failures where the same payload can succeed on replay, classified as aggressive retry; `apiQuirks: kimi-code` for the built-in Kimi Code provider request shaping: `KimiCLI/Dominds/<version>` User-Agent, `prompt_cache_key`, and `thinking`/`reasoning_effort`; and `apiQuirks: minimax-reasoning-details` for MiniMax OpenAI-compatible `/v1`, enabling `reasoning_split: true` by default and preserving `reasoning_details` across turns; `apiQuirks: minimax-thinking-type` for the MiniMax `/v1` endpoint, which only accepts `thinking.type` in `{adaptive, disabled}` and rejects `enabled`, so the request-side `thinking: true` and the object form `thinking: { type: "enabled" }` are both normalized to `thinking: { type: "adaptive" }`. Minimal example:\n```yaml\nproviders:\n  my_gateway:\n    apiType: openai-compatible\n    baseUrl: https://example.invalid/v1\n    apiKeyEnvVar: MY_GATEWAY_API_KEY\n    apiQuirks: same-context-empty-response\n    models:\n      my_model: { name: "upstream-model-id" }\n```',
-                    'Boundary reminder: `apiQuirks` only affects providers/generators that explicitly read it in code. In the current implementation, the OpenAI Responses and OpenAI-compatible paths consume it; do not assume every `apiType` supports or needs it. If behavior is still wrong after setting it, continue with upstream gateway docs, raw stream event inspection, and `team_mgmt_check_provider(...)` / runtime logs.',
+                    '`apiQuirks` is optional under `providers.<providerKey>.apiQuirks`, with type `string|string[]`; use an array for multiple quirks, for example `apiQuirks: [same-context-empty-response]`. It is a provider-level transport / gateway compatibility / request-shaping switch for non-standard upstream API behavior. It is not a `.minds/team.yaml` member field and not part of `model_params`.',
+                    'Use it only when you have confirmed that a provider/API path has non-standard behavior and Dominds has an explicitly named quirk for that deviation or request-shaping need. Do not treat it as a generic tuning field. In the current implementation, unknown quirk values are usually ignored rather than rejected, so a typo may silently do nothing.',
+                    'Known current example: the built-in Codex (ChatGPT) provider enables `apiQuirks: codex-anti-early-finalization` by default; it appends a work-language-specific reasoning-completion guard only to Codex provider `instructions` to reduce suspected early reasoning truncation / premature finalization on the ChatGPT/Codex path, and does not apply to the OpenAI API provider. The OpenAI Responses wrapper supports `apiQuirks: xcode.best` (or an array containing it) for vendor keepalive recognition, xcode.best-specific failures, and gateway-returned HTML 502 Bad Gateway plus `500 auth_unavailable: no auth available` infrastructure failures. The OpenAI-compatible Chat Completions wrapper supports `apiQuirks: same-context-empty-response` for repeated empty responses in the same dialog generation context; `apiQuirks: volcengine-invalid-parameter-aggressive-retry` for Volcano Ark Coding Plan transient `400 InvalidParameter` failures where the same payload can succeed on replay, classified as aggressive retry; `apiQuirks: kimi-code` for the built-in Kimi Code provider request shaping: `KimiCLI/Dominds/<version>` User-Agent, `prompt_cache_key`, and `thinking`/`reasoning_effort`; and `apiQuirks: minimax-reasoning-details` for MiniMax OpenAI-compatible `/v1`, enabling `reasoning_split: true` by default and preserving `reasoning_details` across turns; `apiQuirks: minimax-thinking-type` for the MiniMax `/v1` endpoint, which only accepts `thinking.type` in `{adaptive, disabled}` and rejects `enabled`, so the request-side `thinking: true` and the object form `thinking: { type: "enabled" }` are both normalized to `thinking: { type: "adaptive" }`. Minimal example:\n```yaml\nproviders:\n  my_gateway:\n    apiType: openai-compatible\n    baseUrl: https://example.invalid/v1\n    apiKeyEnvVar: MY_GATEWAY_API_KEY\n    apiQuirks: same-context-empty-response\n    models:\n      my_model: { name: "upstream-model-id" }\n```',
+                    'Boundary reminder: `apiQuirks` only affects providers/generators that explicitly read it in code. In the current implementation, the Codex, OpenAI Responses, and OpenAI-compatible paths consume it; do not assume every `apiType` supports or needs it. If behavior is still wrong after setting it, continue with upstream gateway docs, raw stream event inspection, and `team_mgmt_check_provider(...)` / runtime logs.',
                 ]);
     }
     if (want('mcp')) {

package/dist/tools/team_mgmt.js

@@ -932,6 +932,7 @@ exports.teamMgmtCheckProviderTool = {
                             'openai-compatible': { temperature: 0 },
                             anthropic: { max_tokens: 16, temperature: 0 },
                             'anthropic-compatible': { max_tokens: 16, temperature: 0 },
+                            google: { temperature: 0 },
                         },
                     });
                     let out = '';
@@ -1343,6 +1344,8 @@ exports.teamMgmtListModelsTool = {
                             specific = mpo.anthropic;
                         else if (providerCfg.apiType === 'anthropic-compatible')
                             specific = mpo['anthropic-compatible'];
+                        else if (providerCfg.apiType === 'google')
+                            specific = mpo.google;
                         else
                             specific = undefined;
                     }