dominds 1.18.2 → 1.19.2

package/dist/docs/fbr.md

@@ -7,17 +7,17 @@ Chinese version: [中文版](./fbr.zh.md)
 ## 1. What it is
 
 **Fresh Boots Reasoning (FBR)** is a Dominds mechanism for “reasoning again from a clean slate” on a bounded sub-problem,
-then reporting back to the tellasker dialog.
+then reporting back to the tellasker.
 
 In Dominds, FBR is triggered by the dedicated function tool `freshBootsReasoning({ tellaskContent: "...", effort?: N })`.
-The mechanism is the runtime-enforced contract applied to the spawned sideline dialog.
+The mechanism is the runtime-enforced contract applied to the spawned Side Dialog.
 
 ## 2. Design principles and tradeoffs
 
 ### 2.1 Predictability first: FBR is tool-less until final closure
 
 FBR is meant to be “reasoning over text”, not “an agent run that explores the environment”. To keep it safe and
-predictable, FBR sideline dialogs must be:
+predictable, FBR Side Dialogs must be:
 
 - **tool-less by construction during divergence/convergence** (technically enforced; not “please don’t use tools”), and
 - **closure-only in the final stage** (exactly two conclusion functions, no other tools), and
@@ -30,7 +30,7 @@ silent ignore is worse than an error.
 
 ### 2.3 Serial multi-pass reasoning, not “multi-agent collaboration”
 
-`fbr-effort` is an FBR intensity setting. Runtime interprets intensity `N` as `N` divergence rounds, then `N` convergence rounds, inside a **single FBR sideline conversation window**. The FBR sideline itself must finish denoising and closure before reporting upstream.
+`fbr-effort` is an FBR intensity setting. Runtime interprets intensity `N` as `N` divergence rounds, then `N` convergence rounds, inside a **single FBR Side Dialog conversation window**. The FBR Side Dialog itself must finish denoising and closure before reporting to tellasker.
 
 ## 3. User syntax
 
@@ -43,16 +43,16 @@ Use the dedicated FBR form:
 Notes:
 
 - FBR does not use `targetAgentId`, `sessionSlug`, or `mentionList`.
-- `tellaskContent` is the authoritative task context for the FBR sideline.
+- `tellaskContent` is the authoritative task context for the FBR Side Dialog.
 - `effort` is optional and sets per-call FBR intensity; when omitted, runtime uses the current member’s `fbr-effort`.
-- Intensity `N` maps to `N` serial FBR passes inside one sideline window.
+- Intensity `N` maps to `N` serial FBR passes inside one Side Dialog window.
 
 ### 3.2 Scope
 
 This document specifies the FBR mechanism and its `freshBootsReasoning({ tellaskContent: "...", effort?: N })` contract. General teammate Tellasks (`tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })`) follow
 the taxonomy and capability model in [`dialog-system.md`](./dialog-system.md).
 
-If you want a “fresh” sideline dialog that still has tools, use an explicit teammate identity via the general teammate Tellask flow.
+If you want a “fresh” Side Dialog that still has tools, use an explicit teammate identity via the general teammate Tellask flow.
 
 ## 4. Runtime contract (normative)
 
@@ -60,19 +60,19 @@ This section uses MUST / MUST NOT / SHOULD / MAY for requirements.
 
 ### 4.1 Isolation and context
 
-When driving an FBR sideline dialog created by `freshBootsReasoning({ tellaskContent: "..." })`, runtime MUST enforce:
+When driving an FBR Side Dialog created by `freshBootsReasoning({ tellaskContent: "..." })`, runtime MUST enforce:
 
-- **No dependency on tellasker dialog history**
-  - the tellaskee MUST NOT assume access to the tellasker dialog’s history
+- **No dependency on tellasker-side history**
+  - the tellaskee MUST NOT assume access to the tellasker-side dialog history
   - the tellaskee MUST treat the tellask body as the primary, authoritative task context
 - **Shared FBR iteration context**
   - all rounds launched by a single `freshBootsReasoning` call share the same FBR window assumptions and no-tools policy
-  - rounds run in the same sideline context as one continuous thread and stay isolated from the caller dialog history
+  - rounds run in the same Side Dialog context as one continuous thread and stay isolated from the tellasker-side dialog history
 - **No tool-based context fetch**
   - no reading files / running commands / browsing
   - no accessing Memory or rtws (runtime workspace) state
 
-Intuition: “fresh boots” means “fresh relative to the caller thread”, not “ignores baseline system rules”. Runtime may
+Intuition: “fresh boots” means “fresh relative to the tellasker-side thread”, not “ignores baseline system rules”. Runtime may
 still inject baseline policy/safety/formatting context, but the tellask body remains the authority.
 
 ### 4.2 Tool-less (prompt + technical enforcement)
@@ -86,8 +86,8 @@ Tool-less FBR has two layers, both required:
 
 The FBR system prompt MUST communicate (wording may vary, meaning must hold):
 
-- this is an FBR sideline dialog; the tellask body is the primary context
-- do not assume access to tellasker dialog history
+- this is an FBR Side Dialog; the tellask body is the primary context
+- do not assume access to tellasker-side dialog history
 - if critical context is missing, list what is missing and why it blocks reasoning
 - do not emit any tellasks (including `tellaskBack` or `askHuman`)
 
@@ -108,11 +108,11 @@ If a provider integration normally injects a tool prompt or schema, then for FBR
 - omit it entirely, OR
 - inject text that is identical to the appended “no tools” notice
 
-Under no circumstances should the FBR sideline dialog see any tool definitions.
+Under no circumstances should the FBR Side Dialog see any tool definitions.
 
 #### 4.2.3 The LLM request MUST be “zero tools”
 
-For divergence/convergence, the LLM request for an FBR sideline dialog (`freshBootsReasoning`) MUST have **zero tools available**:
+For divergence/convergence, the LLM request for an FBR Side Dialog (`freshBootsReasoning`) MUST have **zero tools available**:
 
 - the request payload must not include tool/function definitions (effective tool list must be empty)
 - provider tool-calling / function-calling modes must not be enabled
@@ -126,17 +126,17 @@ If the model attempts any other tool/function call, runtime MUST hard-reject it
 
 ### 4.3 Tellask restriction: none allowed
 
-FBR sideline dialogs MUST NOT issue any tellask call (including `tellaskBack({ tellaskContent: "..." })`, `tellask({ ... })`, `tellaskSessionless({ ... })`, or `askHuman({ tellaskContent: "..." })`).
-If critical context is missing, the FBR sideline should **list the missing items** and why they block reasoning, then return.
+FBR Side Dialogs MUST NOT issue any tellask call (including `tellaskBack({ tellaskContent: "..." })`, `tellask({ ... })`, `tellaskSessionless({ ... })`, or `askHuman({ tellaskContent: "..." })`).
+If critical context is missing, the FBR Side Dialog should **list the missing items** and why they block reasoning, then return.
 
 ### 4.4 Output contract (easy to distill)
 
-An FBR sideline dialog should denoise internally and post only one upstream-visible final artifact.
+An FBR Side Dialog should denoise internally and post only one tellasker-visible final artifact.
 
 1. **Divergence**: stay open to wild or minority ideas without forcing early consensus.
 2. **Convergence**: discard unsupported wild ideas as noise and keep only stable cross-round consensus.
 3. **Final closure**: end by calling exactly one of the two conclusion functions above.
-4. **Upstream delivery**: caller receives only the final low-noise conclusion, or the final “unreasonable situation” conclusion.
+4. **Tellasker delivery**: the tellasker receives only the final low-noise conclusion, or the final “unreasonable situation” conclusion.
 
 ### 4.5 Violations and errors (loud + debuggable)
 
@@ -156,16 +156,16 @@ An FBR sideline dialog should denoise internally and post only one upstream-visi
 
 When `fbr-effort = N`:
 
-- runtime expands one `freshBootsReasoning({ tellaskContent: "..." })` into **N divergence rounds + N convergence rounds + up to N finalization retries** inside one sideline dialog
+- runtime expands one `freshBootsReasoning({ tellaskContent: "..." })` into **N divergence rounds + N convergence rounds + up to N finalization retries** inside one Side Dialog
 - divergence rounds must explore distinct angles and stay open to ideas that may later be discarded
 - convergence rounds must denoise autonomously and preserve only stable consensus
 - conclusion functions are exposed only after divergence and convergence are complete
 - if the model still does not end via one of the required conclusion functions after `N` finalization retries, runtime must programmatically produce the `presentUnreasonableSituation` result
-- tellasker dialog receives only the final low-noise conclusion or the final unreasonable-situation conclusion
+- tellasker receives only the final low-noise conclusion or the final unreasonable-situation conclusion
 
 ## 6. FBR-only model overrides: `fbr_model_params`
 
-`fbr_model_params` overrides model params **only when driving FBR sideline dialogs**:
+`fbr_model_params` overrides model params **only when driving FBR Side Dialogs**:
 
 - Schema: identical to `model_params` (documented by `model_param_options` in `dominds/main/llm/defaults.yaml`)
 - Scope: `freshBootsReasoning({ tellaskContent: "..." })` only
@@ -192,15 +192,15 @@ freshBootsReasoning({ tellaskContent: "You are doing tool-less FBR. Use ONLY the
 
 ```yaml
 member_defaults:
-  # Run 3 rounds inside one tool-less FBR sideline per `freshBootsReasoning({ tellaskContent: "..." })`.
+  # Run 3 rounds inside one tool-less FBR Side Dialog per `freshBootsReasoning({ tellaskContent: "..." })`.
   fbr-effort: 3
 
 members:
   ux:
-    # Run 5 rounds per `freshBootsReasoning({ tellaskContent: "..." })` in the same sideline.
+    # Run 5 rounds per `freshBootsReasoning({ tellaskContent: "..." })` in the same Side Dialog.
     fbr-effort: 5
 
-    # Make FBR more exploratory without changing tellasker dialog behavior.
+    # Make FBR more exploratory without changing tellasker behavior.
     fbr_model_params:
       codex:
         temperature: 0.9
@@ -209,16 +209,16 @@ members:
         max_tokens: 1200
 ```
 
-## 8. Relationship to general sideline dialogs
+## 8. Relationship to general Side Dialogs
 
 - `freshBootsReasoning({ tellaskContent: "..." })` is a special case: tool-less, body-first, tellask-restricted, optionally fanned out in sequence via `fbr-effort`.
-- General `tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })` sidelines remain fully capable (tools/toolsets as configured).
-- If you need “same persona + tools” in a sideline, use an explicit teammate identity (`tellask` / `tellaskSessionless`).
+- General `tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })` Side Dialogs remain fully capable (tools/toolsets as configured).
+- If you need “same persona + tools” in a Side Dialog, use an explicit teammate identity (`tellask` / `tellaskSessionless`).
 
 ## 9. Acceptance checklist
 
 - `freshBootsReasoning({ tellaskContent: "..." })` triggers tool-less FBR; the LLM request is technically “zero tools”.
 - The system prompt body contains no tool instructions; tool-related wording comes only from the separate fixed notice.
-- FBR sidelines cannot issue teammate Tellasks (including `tellaskBack`).
+- FBR Side Dialogs cannot issue teammate Tellasks (including `tellaskBack`).
 - `fbr-effort` defaults to `3`, accepts `0..100`, rejects invalid values, and fails loudly when disabled.
 - `fbr_model_params` applies only to FBR and follows the same schema/merge intent as `model_params`.

package/dist/docs/fbr.zh.md

@@ -6,7 +6,7 @@
 
 ## 1. 这是什么
 
-**扪心自问（FBR, Fresh Boots Reasoning）** 是 Dominds 的一种工作机制：在诉请者对话推进过程中，智能体可以把一个边界清晰的子问题“拆出去”，以 **更干净的上下文** 重新推理一次，然后把结论回贴到诉请者对话中。
+**扪心自问（FBR, Fresh Boots Reasoning）** 是 Dominds 的一种工作机制：在诉请者推进过程中，智能体可以把一个边界清晰的子问题“拆出去”，以 **更干净的上下文** 重新推理一次，然后把结论回贴到诉请者中。
 
 在 Dominds 里，FBR 通过专用函数工具 `freshBootsReasoning({ tellaskContent: "...", effort?: N })` 触发；FBR 的核心是运行时对该支线对话施加的一组强制约束与串行语义。
 
@@ -18,7 +18,7 @@ FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请
 
 - **发散/收敛阶段技术上 0 工具**（不是“提示词里说别用工具”）
 - **最终收口阶段只开放两个结论函数**
-- **上下文以诉请正文为权威**（不是“默认继承诉请者对话历史”）
+- **上下文以诉请正文为权威**（不是“默认继承诉请者一侧历史”）
 
 这两点让 FBR 更像一个可控的“推理试算器”，而不是另一个会自行探索环境的智能体。
 
@@ -28,7 +28,7 @@ FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请
 
 ### 2.3 串行多轮推理，而不是“多代理协作”
 
-`fbr-effort` 是 FBR 的力度设置。运行时会把力度 `N` 解释为在**单一子对话窗口**内先执行 `N` 轮发散，再执行 `N` 轮收敛，并要求 FBR 子对话自己完成去噪和正式收口后再回贴上游。
+`fbr-effort` 是 FBR 的力度设置。运行时会把力度 `N` 解释为在**单一支线对话窗口**内先执行 `N` 轮发散，再执行 `N` 轮收敛，并要求 FBR 支线对话自己完成去噪和正式收口后再回贴诉请者。
 
 ## 3. 用户语法
 
@@ -59,17 +59,17 @@ FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请
 
 当运行时驱动由 `freshBootsReasoning({ tellaskContent: "..." })` 创建的 FBR 支线对话时，必须强制满足：
 
-- **不依赖诉请者对话上下文**：
-  - 被诉请者不得假设能访问**诉请者对话**历史
+- **不依赖诉请者一侧上下文**：
+  - 被诉请者不得假设能访问**诉请者一侧的对话历史**
   - 被诉请者必须把诉请正文当作主要且权威的任务上下文
 - **FBR 轮次共享窗口**：
   - 同一次 `freshBootsReasoning` 启动的全部轮次共享同一套 FBR 约束上下文（无工具、无诉请上下文注入）
-  - 所有轮次在同一 FBR 子对话内连续推理，形成一段共享上下文历史，同时继续与主线对话历史隔离
+  - 所有轮次在同一 FBR 支线对话内连续推理，形成一段共享上下文历史，同时继续与主线对话历史隔离
 - **不得通过工具补上下文**：
   - 不得读文件/跑命令/浏览
   - 不得读取 Memory 或 rtws（运行时工作区）状态
 
-直觉上：FBR 的“初心”不是“忘掉一切系统规则”，而是“相对诉请者对话不继承历史”。运行时仍可能无条件注入基础规则（安全、格式、少量只读摘要等），但 **推理依据必须以诉请正文为主**。
+直觉上：FBR 的“初心”不是“忘掉一切系统规则”，而是“相对诉请者不继承历史”。运行时仍可能无条件注入基础规则（安全、格式、少量只读摘要等），但 **推理依据必须以诉请正文为主**。
 
 ### 4.2 无工具（提示词 + 技术强制）
 
@@ -83,7 +83,7 @@ FBR 的阶段性约束必须同时满足两类要求：
 FBR 支线对话的 system prompt 必须明确包含（措辞可不同，但语义必须到位）：
 
 - 这是一次 FBR 支线对话，诉请正文是主要任务上下文
-- 不要假设能访问诉请者对话历史
+- 不要假设能访问诉请者一侧的对话历史
 - 若诉请正文缺少关键上下文，需要列出缺失信息与阻塞原因
 - 不得发起任何诉请（包括 `tellaskBack` 或 `askHuman`）
 
@@ -127,12 +127,12 @@ FBR 支线对话不得发起任何 tellask 调用（包括 `tellaskBack({ tellas
 
 ### 4.4 输出契约（在 FBR 内部完成去噪）
 
-FBR 支线对话应在内部完成去噪与收口，只向上游回贴一个最终结果。
+FBR 支线对话应在内部完成去噪与收口，只向诉请者回贴一个最终结果。
 
 1. **发散阶段**：对离谱、少数派、反直觉想法保持开放，不急于压成共识。
 2. **收敛阶段**：自主去噪，只保留跨轮稳定共识与正文可支撑内容。
 3. **最终收口**：必须以 `presentLowNoiseHighlyInformativeConclusion` 或 `presentUnreasonableSituation` 二选一结束。
-4. **上游交付**：诉请者只接收低噪高信息结论，或“当前现状无法被合理看待”的最终结论。
+4. **诉请者交付**：诉请者只接收低噪高信息结论，或“当前现状无法被合理看待”的最终结论。
 
 ### 4.5 违规与报错（必须“响亮可调试”）
 
@@ -151,12 +151,12 @@ FBR 支线对话应在内部完成去噪与收口，只向上游回贴一个最
 
 当 `fbr-effort = N`：
 
-- 运行时必须把一条 `freshBootsReasoning({ tellaskContent: "..." })` 扩展为单一 FBR 子对话内的 **N 轮发散 + N 轮收敛 + 最多 N 次最终收口重试**
+- 运行时必须把一条 `freshBootsReasoning({ tellaskContent: "..." })` 扩展为单一 FBR 支线对话内的 **N 轮发散 + N 轮收敛 + 最多 N 次最终收口重试**
 - 发散轮必须切换不同视角，允许大胆但可能最终被丢弃的候选想法
 - 收敛轮必须自主去噪，只保留稳定共识
 - 只有完成发散轮与收敛轮之后，运行时才开放两个结论函数
 - 如果模型在最终收口阶段连续 `N` 次仍不调用规定函数，运行时必须程序化地产出 `presentUnreasonableSituation` 的结果
-- 诉请者对话最终只接收低噪结论，或“不合理现状”结论
+- 诉请者最终只接收低噪结论，或“不合理现状”结论
 
 ## 6. 模型参数覆盖：`fbr_model_params`
 
@@ -187,15 +187,15 @@ freshBootsReasoning({ tellaskContent: "你正在做无工具的 FBR。请只使
 
 ```yaml
 member_defaults:
-  # 默认每次 `freshBootsReasoning({ tellaskContent: "..." })` 在单一 FBR 子对话内串行执行 3 轮。
+  # 默认每次 `freshBootsReasoning({ tellaskContent: "..." })` 在单一 FBR 支线对话内串行执行 3 轮。
   fbr-effort: 3
 
 members:
   ux:
-    # 每次 `freshBootsReasoning({ tellaskContent: "..." })` 在单一 FBR 子对话内串行执行 5 轮。
+    # 每次 `freshBootsReasoning({ tellaskContent: "..." })` 在单一 FBR 支线对话内串行执行 5 轮。
     fbr-effort: 5
 
-    # 让 FBR 更“发散”，但不影响诉请者对话风格。
+    # 让 FBR 更“发散”，但不影响诉请者风格。
     fbr_model_params:
       codex:
         temperature: 0.9

package/dist/docs/i18n.md

@@ -6,7 +6,7 @@ Dominds has two independent language settings:
 
 ## 1) Work language (server-wide)
 
-- **What it affects:** agent system prompts, internal guide messages, inter-dialog (teammate/subdialog) narrative formatting.
+- **What it affects:** agent system prompts, internal guide messages, inter-dialog (teammate/sideDialog) narrative formatting.
 - **How to set:** standard locale environment variables (`LANG`).
 - **Default:** OS default language (best-effort); falls back to `en`.
 - **Supported (v1):**
@@ -40,7 +40,7 @@ LANG=en_US.UTF-8 dominds webui
 ## 2) UI language (per WebUI client)
 
 - **What it affects:** WebUI UI copy + the language the agent is asked to use when replying to the current user.
-- **What it does NOT affect:** the agent’s internal working language, system prompts, or teammate/subdialog formatting language.
+- **What it does NOT affect:** the agent’s internal working language, system prompts, or teammate/sideDialog formatting language.
 - **How to set:** WebUI dropdown in the top-right (stored in `localStorage` as `dominds-ui-language`).
 - **Supported (v1):** `en`, `zh`.
 

package/dist/docs/i18n.zh.md

@@ -6,7 +6,7 @@ Dominds 有两个独立的语言设置：
 
 ## 1) 工作语言（服务器范围）
 
-- **影响范围：** 智能体系统提示、内部指导消息、对话间（队友/子对话）叙事格式化。
+- **影响范围：** 智能体系统提示、内部指导消息、对话间（队友/支线对话）叙事格式化。
 - **设置方式：** 标准语言环境变量（`LANG`）。
 - **默认值：** 操作系统的默认语言（尽最大努力）；回退到 `en`。
 - **支持的语言（v1）：**
@@ -39,7 +39,7 @@ LANG=en_US.UTF-8 dominds webui
 ## 2) UI 语言（每个 WebUI 客户端）
 
 - **影响范围：** WebUI 界面文案 + 智能体在回复当前用户时被要求的语言。
-- **不影响范围：** 智能体的内部工作语言、系统提示或队友/子对话格式化语言。
+- **不影响范围：** 智能体的内部工作语言、系统提示或队友/支线对话格式化语言。
 - **设置方式：** WebUI 右上角的下拉菜单（存储在 `localStorage` 中，键为 `dominds-ui-language`）。
 - **支持的语言（v1）：** `en`, `zh`。
 

package/dist/docs/mcp-support.md

@@ -90,7 +90,7 @@ implemented config surface.
 - That runtime instance remains **leased to that dialog** for future function tool calls from the same
   toolset.
 - If another dialog uses the same MCP toolset concurrently, Dominds creates **another** MCP runtime
-  instance for that requesting dialog (no cross-dialog sharing).
+  instance for that tellasker (no cross-dialog sharing).
 - On first lease, Dominds adds a **sticky owned reminder** to the dialog instructing the agent to
   release the lease when it is confident the runtime instance won’t be needed again soon.
 
@@ -378,12 +378,13 @@ Semantics:
 
 ## HTTP Headers (`streamable_http`)
 
-`streamable_http` servers can optionally define HTTP request headers. Values use the same literal
-or `{ env: ... }` mapping form as `env`:
+`streamable_http` servers can optionally define HTTP request headers. Values can be literal strings,
+copied from env with `{ env: ... }`, or built as `prefix + env` with `{ prefix, env }`:
 
 ```yaml
 headers:
   Authorization:
+    prefix: 'Bearer '
     env: MCP_AUTH_TOKEN
   X-Client-Name: 'dominds'
 ```
@@ -416,7 +417,7 @@ servers:
     # 2) streamable_http
     # transport: streamable_http
     # url: http://127.0.0.1:3000/mcp
-    # headers: {} # optional (supports literal or { env: NAME } values)
+    # headers: {} # optional (supports literal, { env: NAME }, or { prefix, env } values)
     # sessionId: '' # optional
 
     # Tool exposure controls

package/dist/docs/mcp-support.zh.md

@@ -304,11 +304,12 @@ env:
 
 ## HTTP 头（`streamable_http`）
 
-`streamable_http` 服务器可以选择性地定义 HTTP 请求标头。值使用与 `env` 相同的字面量或 `{ env: ... }` 映射形式：
+`streamable_http` 服务器可以选择性地定义 HTTP 请求标头。值可以是字面量字符串、`{ env: ... }` 环境变量复制，或用 `{ prefix, env }` 组装成 `prefix + env`：
 
 ```yaml
 headers:
   Authorization:
+    prefix: 'Bearer '
     env: MCP_AUTH_TOKEN
   X-Client-Name: 'dominds'
 ```
@@ -341,7 +342,7 @@ servers:
     # 2) streamable_http
     # transport: streamable_http
     # url: http://127.0.0.1:3000/mcp
-    # headers: {} # 可选（支持字面量或 { env: NAME } 值）
+    # headers: {} # 可选（支持字面量、{ env: NAME } 或 { prefix, env } 值）
     # sessionId: '' # 可选
 
     # 工具暴露控制

package/dist/docs/memory-system.md

@@ -8,7 +8,7 @@ TL;DR:
 
 - Make dialog history disposable (noise is cheap to drop).
 - Make key artifacts survivable (you can `clear_mind` and still keep moving).
-- Publicly declare and openly discuss progress in real time (and keep it auditable) to enforce timely coordination: that’s where the real leverage comes from when multiple agents and multiple mainline dialogs work in parallel (Taskdoc / team memory / env notes).
+- Publicly declare and openly discuss progress in real time (and keep it auditable) to enforce timely coordination: that’s where the real leverage comes from when multiple agents and multiple Main Dialogs work in parallel (Taskdoc / team memory / env notes).
 
 Key rule: **the Taskdoc is the task’s live coordination bulletin board**. Put key decisions/status/next steps in `progress`, hard rules in `constraints`, and don’t leave them only in chat or reminders.
 
@@ -38,7 +38,7 @@ The same information can be categorized by “who needs to see it / who maintain
 - **Collective-scope (shared by team/task)**:
   - rtws-level “env notes” (`.minds/env*.md`): the workspace’s baseline facts, runtime constraints, and gotchas
   - team memory (`team_memory`)
-  - Taskdoc: in a healthy workflow, the same Taskdoc is expected to be progressed by multiple mainline dialogs (different responders), so treat it as the collective single source of truth
+  - Taskdoc: in a healthy workflow, the same Taskdoc is expected to be progressed by multiple Main Dialogs (different Dialog Responders), so treat it as the collective single source of truth
 
 ### Permissions and division of labor
 
@@ -164,7 +164,7 @@ Some reminders are generated by the runtime (e.g. background process status, MCP
 
 Reminders are your tiny working set: injected every turn, and preserved across `clear_mind`.
 
-In message semantics, these should be treated as **self reminders**: they belong on the `role=assistant` side and should read like first-person working notes rather than fresh external instructions.
+In message semantics, default injected reminder wrappers should still be treated as **runtime system notices**: Dominds' built-in and fallback wrappers belong on the `role=user` side, carry a standard notice marker such as `[System notice]`, and address the LLM in second person (for example, “You set a reminder so the runtime system can remind you: ...”). Ideally they would use `role=environment`, but current LLM APIs generally do not support that role, so Dominds carries default runtime wrappers on `role=user`; custom reminder owners keep responsibility for the role they emit under their own contract. Insert the reminder projection before the real dialog messages and wrap it in a paired header/footer; the footer should say that only the reminder items between that header and footer are system reminders rather than user instructions, so it does not weaken real user instructions in the dialog history.
 
 Guidelines:
 
@@ -215,7 +215,7 @@ The goal for agents’ day-to-day work is not “write more docs”. It’s a lo
 ### Where to write what (quick rules)
 
 - **Taskdoc `progress`**: key decisions, current status, next steps (the shared bulletin board)
-- **Taskdoc `constraints`**: hard rules/safety/compliance/style (must be visible to all mainlines)
+- **Taskdoc `constraints`**: hard rules/safety/compliance/style (must be visible to all Main Dialogs)
 - **Team memory `team_memory`**: stable team conventions and invariants (worth reusing)
 - **Env notes `.minds/env*.md`**: rtws baseline facts, runtime constraints, gotchas (align humans + all agents to the same environment)
 - **Individual memory `personal_memory`**: personal preferences + responsibility-area rtws index (keep accurate)

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

@@ -163,7 +163,7 @@ TL;DR：
 
 提醒项是你为自己维护的“超小工作集”：它会在每次生成时注入上下文，并能跨 `clear_mind` 保留。
 
-在消息语义上，这类提醒应视为**自我提醒**：落在 `role=assistant` 侧，并使用第一人称口吻，避免伪装成新的外部指令。
+在消息语义上，默认提醒项包装注入上下文时仍应视为**运行时系统提示**：Dominds 内置和 fallback 包装落在 `role=user` 侧，带 `【系统提示】` 头标，并使用第二人称口吻（例如“你设置了提醒项，让运行时系统提醒你：……”）。理想情况下它们应是 `role=environment`，但当前 LLM API 普遍不支持，所以默认运行时包装用 `role=user` 承载；自定义 reminder owner 仍按自身契约决定输出 role。提醒项投影应插入在真实对话消息之前，并使用成对 header/footer；footer 只说明该 header/footer 之间的提醒项是系统提醒、并非用户指令，避免误伤对话历史中的真实用户指令。
 
 建议：
 

package/dist/docs/mottos.md

@@ -160,7 +160,7 @@ Taskdoc Structure:
 
 **In dominds (recommended syntax)**
 
-- Fresh Boots Reasoning (FBR) is **common**, and should usually be done via **transient self-subdialogs**.
+- Fresh Boots Reasoning (FBR) is **common**, and should usually be done via **transient self-sideDialogs**.
 - Use `freshBootsReasoning({ tellaskContent: "..." })` for the default “fresh boots” session: isolate one sub-problem, answer, and return.
 - Use `freshBootsReasoning({ tellaskContent: "..." })` whenever you need tool-less, clean-slate reasoning on a bounded sub-problem.
 

package/dist/docs/mottos.zh.md

@@ -160,7 +160,7 @@
 
 **在 dominds 中（推荐语法）**
 
-- 扪心自问（FBR）是**常见的**，通常应该通过**瞬态子对话**完成。
+- 扪心自问（FBR）是**常见的**，通常应该通过**瞬态支线对话**完成。
 - 使用 `freshBootsReasoning({ tellaskContent: "..." })` 进行默认的“初心”会话：隔离一个子问题，回答，然后返回。
 - 需要对边界清晰的子问题做“无工具、清洁上下文”推理时，直接使用 `freshBootsReasoning({ tellaskContent: "..." })`。
 

package/dist/docs/q4h.md

@@ -32,7 +32,7 @@ This document specifies a WebUI enhancement:
 
 ## Definitions (user-facing terms)
 
-- **Mainline dialog / sideline dialog**: user-facing terms for the primary thread and temporary work threads.
+- **Main Dialog / Side Dialog**: user-facing terms for the primary thread and temporary work threads.
 - **Call site**: the location in the conversation where a Tellask was issued (for Q4H: where `askHuman({ tellaskContent: "..." })` appears).
 - **Answer mode**: the input is bound to a specific pending Q4H question so `Send` becomes “answer this question”.
 
@@ -82,8 +82,8 @@ Required:
 
 Recommended (optional but improves resilience / reduces dependency on global Q4H state arrival timing):
 
-- `rootId`: root dialog id
-- `selfId`: originating dialog id (root or sideline)
+- `rootId`: main dialog id
+- `selfId`: originating dialog id (root or Side Dialog)
 - `course`: course number (1-based)
 - `msg`: message index (best-effort fallback locator)
 - `callId`: tellask callId when the Q4H was created from an `askHuman({ tellaskContent: "..." })` tellask block

package/dist/docs/q4h.zh.md

@@ -85,7 +85,7 @@ WebUI 通过 `window.location.search` 识别 deep link 参数。
 
 推荐（可选，但能降低对全局 Q4H 状态到达时机的依赖）：
 
-- `rootId`：根对话 id
+- `rootId`：主线对话 id
 - `selfId`：来源对话 id（主线或支线）
 - `course`：course 编号（1-based）
 - `msg`：messageIndex（仅用于 best-effort 回退定位）

package/dist/docs/roadmap.md

@@ -8,7 +8,7 @@ This document outlines Dominds’ stage goals and major-version evolution to ali
 
 Dominds’ long-term direction is to solidify “agent social division of labor” into a reusable, extensible, installable/uninstallable runtime system: **microkernel + Apps**.
 
-Terminology (Mainline/Sideline, etc.): [`dominds-terminology.md`](./dominds-terminology.md)
+Terminology (Main Dialog/Side Dialog, etc.): [`dominds-terminology.md`](./dominds-terminology.md)
 
 ---
 
@@ -26,7 +26,7 @@ Become a **microkernel for agent social division of labor and collaboration**:
 
 Positioning: validate “stable and effective ways of working”, and make the core mechanisms work end-to-end, reliably, and debuggably.
 
-- Establish reusable work patterns: mainline progress + parallel sideline dialogs + result backflow/aggregation (Tellask / FBR, etc.).
+- Establish reusable work patterns: Main Dialog progress + parallel Side Dialogs + result backflow/aggregation (Tellask / FBR, etc.).
 - Harden a minimal runtime loop: dialog persistence, tool invocation, streaming output + transcripts, basic observability and failure diagnosis.
 - Iterate in small steps: allow internal structure to change rapidly while continuously distilling what is stable/effective into explicit constraints.
 

package/dist/docs/team_mgmt-toolset.md

@@ -291,7 +291,7 @@ Core principles:
 
 - Startup scripts are mapped into real dialog history; they are not read-only logs.
 - Their runtime semantics are not “extra system prompt text”, but “restore reminders first, then replay records into dialog history where possible”.
-- Therefore tone must follow the chosen record type: write `human_text_record` as what a user/requester says to the agent; write `agent_words_record` as what the agent has already said; use `agent_thought_record` only sparingly for internal reasoning traces.
+- Therefore tone must follow the chosen record type: write `human_text_record` as what the user says to the agent; write `agent_words_record` as what the agent has already said; use `agent_thought_record` only sparingly for internal reasoning traces.
 - Some technical record types such as `ui_only_markdown_record` are persisted but do not become model-facing chat messages, so they should not be your main steering layer.
 - The outer file structure should be “top-level frontmatter + repeated `### record <type>` blocks”; do not wrap the file in decorative `# Startup Script` / `## History` headings.
 - Team managers should treat them as editable startup playbooks.
@@ -469,7 +469,15 @@ env:
     env: MY_LOCAL_MCP_TOKEN
 ```
 
-For `streamable_http`, `headers` supports the same literal-or-env mapping.
+For `streamable_http`, `headers` supports literal strings, env mappings, and prefixed env
+mappings:
+
+```yaml
+headers:
+  Authorization:
+    prefix: 'Bearer '
+    env: MY_LOCAL_MCP_TOKEN
+```
 
 ### Operational behavior (hot reload + last-known-good)
 
@@ -510,7 +518,7 @@ members:
 Note: in the normal-member example above, do **not** add `no_read_dirs` / `no_write_dirs` merely to
 restate that `.minds/**` is blocked. That boundary is already enforced by the runtime for general
 file tools; explicit deny entries should be reserved for extra constraints beyond the built-ins.
-  # Example visible teammate (recommended): define at least one non-hidden responder for daily work.
+  # Example visible teammate (recommended): define at least one non-hidden teammate for daily work.
   dev:
     name: Dev
     icon: '🧑‍💻'

package/dist/docs/team_mgmt-toolset.zh.md

@@ -387,7 +387,7 @@ transform:
 
 ### Env 和 headers 接线
 
-Prefer copying from the host environment for secrets:
+对于 secrets，优先从主机环境复制：
 
 ```yaml
 env:
@@ -395,7 +395,14 @@ env:
     env: MY_LOCAL_MCP_TOKEN
 ```
 
-对于 `streamable_http`，`headers` 支持相同的字面量或 env 映射。
+对于 `streamable_http`，`headers` 支持字面量字符串、env 映射，以及带前缀的 env 映射：
+
+```yaml
+headers:
+  Authorization:
+    prefix: 'Bearer '
+    env: MY_LOCAL_MCP_TOKEN
+```
 
 ### 操作行为（热重载 + 最近已知良好状态）