dominds 1.16.6 → 1.16.8

package/dist/dialog-display-state.js

@@ -51,6 +51,7 @@ const evt_registry_1 = require("./evt-registry");
 const log_1 = require("./log");
 const persistence_1 = require("./persistence");
 const persistence_errors_1 = require("./persistence-errors");
+const interjection_pause_stop_1 = require("./runtime/interjection-pause-stop");
 const log = (0, log_1.createLogger)('dialog-display-state');
 let broadcastToClients;
 const activeRunsByDialogKey = new Map();
@@ -128,11 +129,21 @@ async function getRunControlCountsSnapshot() {
             }
             else if (latest?.executionMarker?.kind === 'interrupted' &&
                 isStoppedReasonResumable(latest.executionMarker.reason)) {
-                const q4h = await persistence_1.DialogPersistence.loadQuestions4HumanState(dialogId, 'running');
-                const pendingSubdialogs = await persistence_1.DialogPersistence.loadPendingSubdialogs(dialogId, 'running');
-                if (q4h.length === 0 && pendingSubdialogs.length === 0) {
+                // Keep run-control counts aligned with actual Continue affordance:
+                // - ordinary interrupted dialogs count as resumable only when no blocker remains
+                // - interjection-paused dialogs still count as resumable even if blocker facts remain,
+                //   because the intended UX is that Continue exits the temporary paused projection
+                //   and re-evaluates the original task from fresh facts
+                if ((0, interjection_pause_stop_1.isUserInterjectionPauseStopReason)(latest.executionMarker.reason)) {
                     resumable++;
                 }
+                else {
+                    const q4h = await persistence_1.DialogPersistence.loadQuestions4HumanState(dialogId, 'running');
+                    const pendingSubdialogs = await persistence_1.DialogPersistence.loadPendingSubdialogs(dialogId, 'running');
+                    if (q4h.length === 0 && pendingSubdialogs.length === 0) {
+                        resumable++;
+                    }
+                }
             }
         }
         catch (error) {
@@ -470,6 +481,27 @@ async function refreshRunControlProjectionFromPersistenceFacts(dialogId, trigger
             latest.executionMarker.kind === 'dead') {
             return { kind: 'dead', reason: latest.executionMarker.reason };
         }
+        if (latest.executionMarker?.kind === 'interrupted' &&
+            (0, interjection_pause_stop_1.isUserInterjectionPauseStopReason)(latest.executionMarker.reason)) {
+            // WARNING:
+            // This is the one place where the projection intentionally preserves the paused-interjection
+            // stopped state ahead of the current blocker facts. That is not a bug: after a user
+            // interjection we want the UI to keep showing "original task paused; click Continue" even if
+            // the underlying dialog is still waiting on Q4H/subdialogs.
+            //
+            // The true source-of-truth decision about what Continue should do next lives in
+            // `flow.ts`'s resume path, which performs a fresh fact scan at resume time and then either:
+            // - restores `blocked`, or
+            // - keeps driving immediately.
+            //
+            // Do not "heal" this branch away by prioritizing blocker facts here; that would collapse the
+            // temporary interjection UX and make repeated interjection turns revert too early.
+            return {
+                kind: 'stopped',
+                reason: latest.executionMarker.reason,
+                continueEnabled: isStoppedReasonResumable(latest.executionMarker.reason),
+            };
+        }
         const q4h = await persistence_1.DialogPersistence.loadQuestions4HumanState(dialogId, 'running');
         const pendingSubdialogs = await persistence_1.DialogPersistence.loadPendingSubdialogs(dialogId, 'running');
         const hasQ4H = q4h.length > 0;

package/dist/docs/dialog-system.md

@@ -155,6 +155,51 @@ Dialog state is persisted to storage at key points:
 
 This ensures crash recovery and enables the backend to resume from any persisted state without depending on frontend state.
 
+### User Interjection Pause And Continue Semantics
+
+When a dialog still carries an inter-dialog reply obligation, but the user temporarily interjects and asks it to handle a local question first, the system must distinguish between the **UI projection** and the **true driving source state**.
+
+**Normative semantics**:
+
+1. Every user interjection message is driven as a complete normal round.
+2. If that round needs tools, the system MUST finish the full tool round and any post-tool follow-up before pausing.
+3. The system only projects the original task as resumable `stopped` when this interjection has actually parked an original task that still needs explicit restoration.
+4. If there is no parked original task to resume afterwards (for example, no inter-dialog reply obligation needs reassertion), the interjection round should simply finish and return to the true underlying state without showing this special `stopped` panel.
+5. As long as the user keeps sending new messages, the dialog stays in temporary interjection-chat handling, and that paused projection remains in place only if it was established in the first place.
+6. Only an explicit UI `Continue` attempts to restore the original task.
+
+**Key point**: this `stopped` state is only a temporary run-control / UI projection. It is not the same as an ordinary system-stop failure, and it is not the final business source of truth. It also does not apply to every interjection; it exists only when there really is a parked original task to resume.
+
+After the user clicks `Continue`, the backend MUST re-evaluate fresh persistence facts and decide which true-source case now applies. It must not infer the result purely from the visible `displayState`:
+
+- **Case 1: the dialog no longer has a reply obligation**
+  If there is also no blocker, the dialog should simply continue driving. If it has already become ordinary idle-waiting-user, then `resume_dialog` is no longer actually resumable.
+- **Case 2: the dialog still has a reply obligation and is still suspended**
+  Typical examples are pending Q4H or pending subdialogs. In this case, `Continue` should exit the interjection-paused projection and restore the true `blocked` state.
+- **Case 3: the dialog still has a reply obligation but is no longer suspended and is eligible to proceed**
+  For example, the blocker has disappeared, or a queued prompt provides a valid continuation path. In this case, `Continue` must not first fall back to an intermediate placeholder `blocked/idle` state; it should keep driving immediately.
+
+**This leads to two implementation constraints**:
+
+- `refreshRunControlProjectionFromPersistenceFacts()` MUST preserve the special "interjection handled; original task paused" `stopped` projection until the user explicitly clicks `Continue`; otherwise the UI collapses back to ordinary `blocked` too early and breaks multi-turn interjection UX. Conversely, when there is no parked original task, this paused projection should not be created at all.
+- The actual outcome of `Continue` MUST be decided in the resume drive path by re-reading fresh persistence facts. "Continue is clickable" does not mean "the dialog will definitely enter proceeding immediately".
+- The run-control toolbar's `resumable` count should align with "manual Continue attempt is meaningful". Therefore an interjection-paused `stopped` dialog still counts as resumable even when underlying blocker facts remain, because the business meaning of `Continue` there is "exit the temporary paused projection and re-evaluate from source-of-truth facts".
+
+**Mental-model warning**:
+
+- Do not reason about this flow from `displayState.kind === 'stopped'` alone.
+- Do not reason about it from blocker facts alone and then wonder why the UI still shows `stopped`.
+- Do not reason about it from `resume_dialog` eligibility alone and assume resumption always means immediate running.
+
+You need all of the following together to understand the behavior correctly:
+
+- reply-guidance suppression / deferred reassertion for interjection turns
+- flow logic for "pause after local interjection reply" plus "fresh-fact second decision after Continue"
+- dialog-display-state projection preservation
+- websocket resume entry semantics distinguishing "allowed to attempt Continue" from "actually re-entered driving"
+
+This is an intentionally cross-module semantic contract. Do not locally "simplify" one piece based only on its surface meaning.
+
 ---
 
 ## 3-Type Teammate Tellask Taxonomy

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

@@ -154,6 +154,51 @@
 
 这确保了崩溃恢复，并使后端能够从任何持久化状态恢复，而不依赖于前端状态。
 
+### 用户插话暂停与 Continue 语义
+
+当某个对话仍带有跨对话回复义务，但用户临时插话要求它先处理本地问题时，系统必须区分**UI 投影**与**真实驱动源状态**。
+
+**规范语义**：
+
+1. 每条用户插话消息都按正常驱动轮完整执行。
+2. 若该轮需要工具，则必须先完整跑完该工具轮及其 post-tool follow-up。
+3. 只有当这条插话确实打断了一个仍待恢复的“原任务”时，系统才把该原任务投影为可 `Continue` 的 `stopped`，让用户先看到最后一条回复。
+4. 若当前并不存在待恢复的原任务（例如没有待重申的跨对话回复义务），则插话轮结束后应直接回到真实 underlying state，而不显示这个特殊 `stopped` 面板。
+5. 只要用户继续发送新消息，就继续作为插话临时对话处理；这个 paused projection 仅在它已被建立时持续保持。
+6. 只有用户显式点击 UI `Continue`，系统才尝试恢复原任务。
+
+**关键点**：这里的 `stopped` 只是一个临时 run-control / UI 投影，不等于普通 system-stop 失败，也不是最终的业务真源；并且它不是所有插话都会出现，只在“确有一个待恢复的原任务被临时停靠”时出现。
+
+点击 `Continue` 后，后端必须重新从 persistence 真源判定当前对话属于哪一种情况，而不能只根据表面的 `displayState` 做静态推断：
+
+- **情况 1：当前对话没有回复义务**
+  这时若也没有其他 blocker，就应直接继续 drive；若已回到普通待用户输入态，则 `resume_dialog` 不应再被视为可继续。
+- **情况 2：当前对话仍有回复义务，但处于 suspend 状态**
+  常见于仍在等待 Q4H / pending subdialogs。此时 `Continue` 应退出插话 paused projection，并恢复成真实的 `blocked`。
+- **情况 3：当前对话仍有回复义务，但已不再 suspend，具备继续推进条件**
+  例如 blocker 已消失，或存在允许继续的 queued prompt。此时 `Continue` 不应先落一个中间 `blocked/idle` 占位态，而应直接继续 drive。
+
+**因此有两个实现约束**：
+
+- `refreshRunControlProjectionFromPersistenceFacts()` 在用户尚未点击 `Continue` 前，必须保留这层“插话已处理；原任务已暂停”的 `stopped` 投影；否则 UI 会过早塌回普通 `blocked`，破坏多轮插话体验。反过来，如果当前其实没有待恢复原任务，则根本不应建立这层 paused projection。
+- 真正决定 `Continue` 结果的逻辑，必须在恢复驱动路径中重新读取 fresh persistence facts；不能把“可点 Continue”误解为“必然立即 proceeding”。
+- run-control 工具栏中的 `resumable` 计数，应与“是否允许手动 Continue 尝试”保持一致。因此，处于 interjection-paused `stopped` 的对话即便底层仍有 blocker，也应计入 `resumable`；因为 `Continue` 的业务语义正是“退出这层临时 paused projection，并从真源重判下一步”。
+
+**心智模型提醒**：
+
+- 不能只看 `displayState.kind === 'stopped'` 就理解这条链路。
+- 不能只看 blocker facts 就理解为什么 UI 仍显示 `stopped`。
+- 也不能只看 `resume_dialog` eligibility 就推断恢复后一定马上运行。
+
+必须把以下几块一起看，才能形成完整且精确的理解：
+
+- reply-guidance 中对插话轮的回复义务 suppression / deferred reassertion
+- flow 中“插话回复后停车”与“Continue 后 fresh fact 二次判定”
+- dialog-display-state 中 paused projection 的保留策略
+- websocket resume 入口对“可尝试 Continue”与“实际已恢复 drive”的区分
+
+这是一条跨模块协同语义，不允许在单点上做“表面看起来更简单”的局部简化。
+
 ---
 
 ## 三类队友诉请分类

package/dist/docs/team_mgmt-toolset.md

@@ -55,6 +55,20 @@ Rationale:
 - The framework source tree should not be the “primary” place the team config format is explained.
   Each rtws may have different policies and defaults.
 
+### Scope Boundary of This Document (important)
+
+- This document is responsible for stable design intent, conceptual boundaries, responsibility split,
+  and why the system is designed this way.
+- This document should **not** become a home for overly detailed runtime specifications such as exact
+  injection order, current fallback rules, full topic inventories, dynamic enumeration results,
+  field-by-field rendering details, or authoring rules that are expected to evolve with the implementation.
+- For “what the runtime does today”, use:
+  - `man({ "toolsetId": "team_mgmt" })`
+  - the corresponding implementation and runtime validators
+- If the design document and the runtime handbook disagree about current behavior, the runtime handbook
+  wins and the design doc should be corrected afterward. Readers should not treat this design doc as a
+  runtime specification manual.
+
 ## Current Problem Statement
 
 In typical deployments we deny direct `.minds/` access via the general-purpose rtws tools:
@@ -166,7 +180,10 @@ reading source code.
 - `man({ "toolsetId": "team_mgmt", "topics": ["team"] })` → how to manage `.minds/team.yaml` (+ templates).
 - `man({ "toolsetId": "team_mgmt", "topics": ["team", "member-properties"] })` → list supported member fields and meanings.
 - `man({ "toolsetId": "team_mgmt", "topics": ["minds"] })` → how to manage `.minds/team/<id>/*.md` (persona/knowledge/lessons).
+- `man({ "toolsetId": "team_mgmt", "topics": ["skills"] })` → how to manage `.minds/skills/*` (injection point, tone, heading levels, migration boundaries).
 - `man({ "toolsetId": "team_mgmt", "topics": ["priming"] })` → how to manage startup scripts under `.minds/priming/*`.
+- `man({ "toolsetId": "team_mgmt", "topics": ["env"] })` → how to manage `.minds/env.*.md` (runtime-environment injection point, tone, heading levels).
+- `man({ "toolsetId": "team_mgmt", "topics": ["toolsets"] })` → inspect the actually visible toolsets in the current installation/rtws and common grant patterns.
 - `man({ "toolsetId": "team_mgmt", "topics": ["permissions"] })` → how `read_dirs`/`write_dirs` and deny-lists work.
 - `man({ "toolsetId": "team_mgmt", "topics": ["troubleshooting"] })` → common failure modes and how to recover.
 
@@ -200,6 +217,20 @@ must cover (at minimum) the information that used to live there:
   - Explain tool exposure controls (whitelist/blacklist) and naming transforms (prefix/suffix).
   - Explain secret/env wiring patterns and operational troubleshooting (Problems + logs, restart,
     hot reload semantics).
+- `!skills`:
+  - Explain `.minds/skills/*` as reusable team skill assets.
+  - Explain the boundary that a skill is prompt/guidance content, not a permission system.
+  - Explain when content should remain a skill versus being elevated into an app / toolset /
+    teammate contract.
+- `!env`:
+  - Explain `.minds/env.*.md` as the place for current-rtws runtime-environment orientation, not
+    persona definition or a dump of repo-wide policy.
+  - Explain its boundary relative to `persona/knowledge/lessons`, skills, and priming.
+- `!toolsets`:
+  - Explain that the visible toolsets include built-in toolsets, toolsets exposed by installed
+    apps, and MCP toolsets dynamically registered from `.minds/mcp.yaml`.
+  - Explain why this topic must be rendered from runtime state rather than maintained as a static
+    list in the design docs.
 
 ## Dynamic Loading from the Dominds Installation (Runtime Resources)
 
@@ -220,10 +251,29 @@ Recommended sources by topic:
     `dominds/main/llm/defaults.yaml` (via `__dirname` resolution in the backend build output).
   - Prefer reusing `LlmConfig.load()` and formatting its merged view, or adding a helper that returns
     both “defaults-only” and “merged” provider maps.
-- `man({ "toolsetId": "team_mgmt", "topics": ["toolsets"] })` (if added)
+- `man({ "toolsetId": "team_mgmt", "topics": ["toolsets"] })`
   - Load from the in-memory registries at runtime (`listToolsets()` / `listTools()` in
     `dominds/main/tools/registry.ts`), rather than maintaining a separate list.
 
+### Why `toolsets` Must Stay a Dynamic Topic
+
+- `toolsets` is not a stable inventory that should be hardcoded in a design document.
+- The visible toolsets are jointly determined by:
+  - framework built-ins
+  - toolsets exposed by the currently installed Dominds apps
+  - MCP toolsets mapped at runtime from `.minds/mcp.yaml` `servers.<serverId>`
+- The MCP portion is inherently **dynamic**: teams can add/remove servers, rename exposure, and
+  constrain tool exposure per rtws, so the resulting toolset set changes with the live installation
+  and workspace state.
+- This is intentional. The design binds capability discovery to the actual runtime environment
+  instead of to a static document that will drift:
+  - it avoids maintaining a doomed-to-drift toolset list in the design docs
+  - it avoids misleading readers into treating MCP-derived toolsets as framework built-ins
+  - it ensures the team manager sees the capabilities that are truly available in this installation
+    and this rtws right now
+- Therefore the design docs should explain the mechanism and rationale only; the current toolset list
+  belongs to runtime `man(...topics:["toolsets"])`.
+
 Keep these as **static/manual text** (not dynamically loaded):
 
 - High-level explanations, best practices, and “why” sections.
@@ -240,13 +290,17 @@ Startup script directories:
 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.
+- 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.
 - Freely add/edit assistant or user messages, and fully rewrite scripts when workflows evolve.
 
 Recommended format:
 
 - Frontmatter (optional, recommended): metadata such as `title` and `applicableMemberIds`.
-- Message blocks (required): `### user` / `### assistant`, optionally fenced markdown blocks.
+- Record blocks (required): `### record <type>` with the actual content inside the corresponding markdown/json block.
 
 Maintenance guidance:
 
@@ -488,14 +542,22 @@ Best practices:
 
 ## Managing `.minds/team/<member>/*.md` (agent minds)
 
-The runtime reads these on every dialog start:
+At dialog start, the runtime reads that member’s `persona.*.md` / `knowledge.*.md` / `lessons.*.md`
+assets.
 
-- `.minds/team/<id>/persona.md`
-- `.minds/team/<id>/knowledge.md`
-- `.minds/team/<id>/lessons.md`
+- For exact language-file selection, fallback rules, injection order, and other current authoring
+  details, use `man({ "toolsetId": "team_mgmt", "topics": ["minds"] })`.
 
 See `dominds/main/minds/load.ts` (`readAgentMind()`).
 
+Authoring rule (important):
+
+- `persona.*.md` is spliced into that member's `role=system` prompt, so it should normally be written directly to the agent itself.
+- In practice, prefer second-person "you" when defining responsibilities, boundaries, working style, and delivery expectations.
+- Do not write `persona.*.md` as a third-person biography or as operator-facing documentation for a human/team manager.
+- `knowledge.*.md` / `lessons.*.md` also end up in the member's system prompt, specifically under `## Knowledge` / `## Lessons`. `knowledge` is better for stable facts, indexes, conventions, and decision cues; `lessons` is better for reusable heuristics such as “if X happens, do Y, avoid Z”. Both should still be written to help that member act, not to narrate the member from the outside.
+- Heading levels should follow the system-prompt wrapper too: the outer template already provides `## Persona` / `## Knowledge` / `## Lessons`, so bodies should usually start at `###` or plain bullets instead of repeating `#` / `##` or restating the wrapper title.
+
 Suggested structure:
 
 ```
@@ -513,6 +575,33 @@ Suggested structure:
       lessons.md
 ```
 
+## Managing `.minds/skills/*` (skill assets)
+
+Design-level positioning:
+
+- `.minds/skills/*` stores reusable team skill / operating-guidance assets.
+- Its job is to capture “when to use this, how to do it, and where the boundary is”, not to grant
+  permissions.
+- If a skill depends on scripts, privileged tools, MCP, external binaries, or reusable execution
+  capability, the design should usually elevate it into a Dominds app / toolset / teammate contract
+  rather than stopping at Markdown alone.
+- This design doc intentionally limits itself to boundary and migration guidance. For current file
+  naming, injection semantics, heading levels, and language-file rules, use
+  `man({ "toolsetId": "team_mgmt", "topics": ["skills"] })`.
+
+## Managing `.minds/env.*.md` (runtime-environment notes)
+
+Design-level positioning:
+
+- `.minds/env.*.md` exists to describe stable facts about the current rtws runtime environment so
+  members can orient themselves quickly.
+- It should not take on the role of persona definition, skill tutorial, giant operating manual, or
+  repo-wide policy dump.
+- Those responsibilities belong, respectively, in `persona/knowledge/lessons`, skills, priming, or
+  the repo’s own policy files.
+- This design doc only defines that boundary. For the current injection position, fallback behavior,
+  and authoring guidance, use `man({ "toolsetId": "team_mgmt", "topics": ["env"] })`.
+
 ## Bootstrap Policy: Shadow bootstrap members
 
 Preferred behavior for initial bootstrap:

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

@@ -42,6 +42,15 @@
 - 该手册与工具行为版本化，因此保持准确
 - 框架源代码树不应是团队配置格式被解释的"主要"地方。每个 rtws 可能具有不同的策略和默认值
 
+### 本文档的粒度边界（重要）
+
+- 本文档只负责说明稳定的设计目标、概念边界、职责划分，以及为什么这样设计。
+- 本文档**不应**承载过细的运行时规格，例如精确的注入顺序、当前回退规则、完整 topic 列表、动态枚举结果、逐字段渲染细节、或会随实现演进而频繁变化的 authoring 细则。
+- 这类“当前实现到底怎么做”的信息，应统一以下列入口为准：
+  - `man({ "toolsetId": "team_mgmt" })`
+  - 对应实现代码与运行时校验
+- 如果设计文档与运行时手册在“当前行为”上发生冲突，应默认以运行时手册为准，并回头修正文档，而不是让读者继续把设计文档当成运行时规格书。
+
 ## 当前问题陈述
 
 在典型部署中，我们通过通用 rtws 文件工具拒绝直接的 `.minds/` 访问：
@@ -137,7 +146,10 @@
 - `man({ "toolsetId": "team_mgmt", "topics": ["team"] })` → 如何管理 `.minds/team.yaml`（+ 模板）
 - `man({ "toolsetId": "team_mgmt", "topics": ["team", "member-properties"] })` → 列出支持的成员字段及其含义
 - `man({ "toolsetId": "team_mgmt", "topics": ["minds"] })` → 如何管理 `.minds/team/<id>/*.md`（persona/knowledge/lessons）
+- `man({ "toolsetId": "team_mgmt", "topics": ["skills"] })` → 如何管理 `.minds/skills/*`（skills 的注入位置、口吻、标题层级、迁移边界）
 - `man({ "toolsetId": "team_mgmt", "topics": ["priming"] })` → 如何管理 `.minds/priming/*` 启动脚本（格式、维护、复用）
+- `man({ "toolsetId": "team_mgmt", "topics": ["env"] })` → 如何管理 `.minds/env.*.md`（运行环境提示的注入位置、口吻、标题层级）
+- `man({ "toolsetId": "team_mgmt", "topics": ["toolsets"] })` → 查看当前安装/rtws 下实际可见的 toolsets 及常见授权模式
 - `man({ "toolsetId": "team_mgmt", "topics": ["permissions"] })` → `read_dirs`/`write_dirs` 和拒绝列表如何工作
 - `man({ "toolsetId": "team_mgmt", "topics": ["troubleshooting"] })` → 常见故障模式及如何恢复
 
@@ -163,6 +175,16 @@
   - 解释 MCP 服务器如何映射到工具集（`<serverId>`）以及如何通过 `.minds/team.yaml` 授予这些工具集
   - 解释工具暴露控制（白名单/黑名单）和命名转换（前缀/后缀）
   - 解释密钥/env 接线模式和问题排查（问题 + 日志、重启、热重载语义）
+- `!skills`：
+  - 解释 `.minds/skills/*` 属于可复用的团队技能资产
+  - 解释 skill 的职责边界：它是提示/指导资产，不是权限系统
+  - 解释何时应继续保留为 skill，何时应升级为 app / toolset / teammates contract
+- `!env`：
+  - 解释 `.minds/env.*.md` 用于描述当前 rtws 的运行环境，而不是定义人格或复制仓库总规范
+  - 解释它与 `persona/knowledge/lessons`、skills、priming 的分工边界
+- `!toolsets`：
+  - 解释当前可见 toolsets 包含内建 toolsets、已安装 apps 暴露的 toolsets、以及由 `.minds/mcp.yaml` 动态注册的 MCP toolsets
+  - 解释为什么该主题必须以运行时动态视图为准，而不是在设计文档里维护一份静态名单
 
 ## 从 Dominds 安装动态加载（运行时资源）
 
@@ -179,9 +201,23 @@
 - `man({ "toolsetId": "team_mgmt", "topics": ["llm", "builtin-defaults"] })`
   - 从运行时用于默认值的同一安装资源加载：`dominds/main/llm/defaults.yaml`（通过后端构建输出中的 `__dirname` 解析）
   - 优先重用 `LlmConfig.load()` 并格式化其合并视图，或添加一个返回"仅默认值"和"合并"提供商映射的助手
-- `man({ "toolsetId": "team_mgmt", "topics": ["toolsets"] })`（如果添加）
+- `man({ "toolsetId": "team_mgmt", "topics": ["toolsets"] })`
   - 在运行时从内存中注册表加载（`dominds/main/tools/registry.ts` 中的 `listToolsets()` / `listTools()`），而不是维护单独的列表
 
+### 为什么 `toolsets` 必须是动态主题
+
+- `toolsets` 不是一份稳定、可写死在设计文档里的清单。
+- 当前可见的 toolsets 由三部分共同决定：
+  - 框架内建 toolsets
+  - 当前安装的 Dominds apps 所暴露的 toolsets
+  - `.minds/mcp.yaml` 中 `servers.<serverId>` 在运行时映射出来的 MCP toolsets
+- 其中 MCP 部分天然是**动态的**：团队可以按 rtws 需要增删 server、调整命名、控制工具暴露；因此 toolset 集合会随当前安装状态与当前 rtws 配置而变化。
+- 这样设计的原因，是把“能力发现”绑定到当前实际运行环境，而不是绑定到一份很快过时的静态文档：
+  - 避免设计文档维护一份注定漂移的 toolset 名单
+  - 避免读者误以为某个 MCP toolset 是框架内建常量
+  - 让团队管理者面对的始终是“此刻这个安装与这个 rtws 真实可用的能力”
+- 因此，设计文档只需要解释机制与原因；“当前有哪些 toolsets”应由运行时 `man(...topics:[\"toolsets\"])` 动态呈现。
+
 将这些保持为**静态/手册文本**（而非动态加载）：
 
 - 高级解释、最佳实践和"为什么"部分
@@ -197,13 +233,17 @@
 核心原则：
 
 - 启动脚本会映射为真实对话历史；它不是只读日志，而是可编辑的启动引导剧本。
+- 其运行时语义不是 system prompt，而是“创建对话时先恢复 reminders，再把 records 尽可能回放成对话历史消息”。
+- 因此内容口吻必须跟着 record 类型走：`human_text_record` 写成用户/诉请者对智能体说的话；`agent_words_record` 写成智能体已经说出口的话；`agent_thought_record` 仅适合非常克制地承载内部推理痕迹。
+- `ui_only_markdown_record` 等部分技术 record 不会变成喂给模型的 chat message，因此不能拿它们充当主要行为引导。
+- 外层结构应是“顶层 frontmatter + 多个 `### record <type>` 块”；不要再包一层 `# 启动脚本` / `## 历史` 这类装饰标题。
 - 团队管理者应鼓励按业务场景维护脚本，并可直接增删改 assistant/user 消息内容。
 - 允许完全重写脚本以匹配新的协作模式、质量标准和语言风格。
 
 推荐格式：
 
 - frontmatter（可选但推荐）：`title`、`applicableMemberIds` 等元数据。
-- 消息块（必填）：使用 `### user` / `### assistant`，支持 fenced markdown 块。
+- record 块（必填）：使用 `### record <type>`；具体内容放在对应的 markdown/json block 中。
 
 维护建议：
 
@@ -421,14 +461,20 @@ members:
 
 ## 管理 `.minds/team/<member>/*.md`（智能体心智）
 
-运行时在每次对话开始时读取这些：
+运行时在每次对话开始时会读取该成员的 `persona.*.md` / `knowledge.*.md` / `lessons.*.md` 资产。
 
-- `.minds/team/<id>/persona.md`
-- `.minds/team/<id>/knowledge.md`
-- `.minds/team/<id>/lessons.md`
+- 具体语言文件选择、回退规则、注入顺序与其它 authoring 细则，请以 `man({ "toolsetId": "team_mgmt", "topics": ["minds"] })` 为准。
 
 见 `dominds/main/minds/load.ts`（`readAgentMind()`）。
 
+写法约束（重要）：
+
+- `persona.*.md` 会被拼进该成员的 `role=system` 提示，因此默认应该直接写给“这个成员智能体本人”。
+- 也就是说，`persona.*.md` 应优先使用第二人称“你”来规定职责边界、工作方式与交付标准。
+- 不要把 `persona.*.md` 写成第三人称人物简介，不要把它当成给团队管理员/人类读者的说明书，也不要使用“祂”这类旁白口吻。
+- `knowledge.*.md` / `lessons.*.md` 也同样会进入该成员的系统提示，分别落在 `## 知识` / `## 经验`。`knowledge` 更适合稳定事实、索引、约定、判断依据；`lessons` 更适合复用型经验规则（例如“遇到 X 信号先做 Y，不要做 Z”）。两者都应以“帮助该成员当下工作”为目标，而不是面向旁观者写注释。
+- 标题层级也要按 system prompt 模板来写：系统外层已经自动提供 `## 角色设定` / `## 知识` / `## 经验`，所以正文通常应从 `###` 或普通 bullet 开始，不要再写 `#` / `##`，也不要把文件名或这些章节名重复当标题。
+
 建议的结构：
 
 ```
@@ -446,6 +492,24 @@ members:
       lessons.md
 ```
 
+## 管理 `.minds/skills/*`（技能资产）
+
+设计层面的定位：
+
+- `.minds/skills/*` 用来承载可复用的团队技能/操作指导资产。
+- 它的重点是“什么时候用、怎么做、边界是什么”，而不是授予权限。
+- 如果某个 skill 需要脚本、专有工具、MCP、外部二进制、或稳定复用的执行能力，那么设计上通常更适合上升为 Dominds app / toolset / teammates contract，而不应只停留在 markdown 文案。
+- 设计文档在这里仅说明边界与迁移方向；具体文件命名、注入位置、标题层级、语言文件选择等，以运行时 `man({ "toolsetId": "team_mgmt", "topics": ["skills"] })` 为准。
+
+## 管理 `.minds/env.*.md`（运行环境说明）
+
+设计层面的定位：
+
+- `.minds/env.*.md` 用来描述“当前 rtws 运行环境”的稳定背景信息，帮助成员理解所处环境。
+- 它不应承担 persona 定义、skill 教程、团队制度大全、或仓库全局规范汇总的职责。
+- 这类内容按分工应分别落在 `persona/knowledge/lessons`、skills、priming、或仓库自己的规范文件中。
+- 设计文档在这里仅强调用途边界；具体注入位置、回退规则、标题建议等，以运行时 `man({ "toolsetId": "team_mgmt", "topics": ["env"] })` 为准。
+
 ## 引导策略：影子成员引导
 
 初始引导的首选行为：

package/dist/llm/kernel-driver/flow.js

@@ -10,6 +10,7 @@ const log_1 = require("../../log");
 const load_1 = require("../../minds/load");
 const persistence_1 = require("../../persistence");
 const driver_messages_1 = require("../../runtime/driver-messages");
+const interjection_pause_stop_1 = require("../../runtime/interjection-pause-stop");
 const reply_prompt_copy_1 = require("../../runtime/reply-prompt-copy");
 const work_language_1 = require("../../runtime/work-language");
 const client_1 = require("../client");
@@ -40,6 +41,30 @@ async function buildReplyToolReminderPrompt(args) {
         }),
     });
 }
+async function loadFreshSuspensionStatusFromPersistence(dialog) {
+    const q4h = await persistence_1.DialogPersistence.loadQuestions4HumanState(dialog.id, dialog.status);
+    const pendingSubdialogs = await persistence_1.DialogPersistence.loadPendingSubdialogs(dialog.id, dialog.status);
+    const hasQ4H = q4h.length > 0;
+    const hasSubdialogs = pendingSubdialogs.length > 0;
+    return {
+        q4h: hasQ4H,
+        subdialogs: hasSubdialogs,
+        blockingSubdialogs: hasSubdialogs,
+        canDrive: !hasQ4H && !hasSubdialogs,
+    };
+}
+function buildDisplayStateFromSuspensionStatus(args) {
+    if (args.q4h && args.subdialogs) {
+        return { kind: 'blocked', reason: { kind: 'needs_human_input_and_subdialogs' } };
+    }
+    if (args.q4h) {
+        return { kind: 'blocked', reason: { kind: 'needs_human_input' } };
+    }
+    if (args.subdialogs) {
+        return { kind: 'blocked', reason: { kind: 'waiting_for_subdialogs' } };
+    }
+    return { kind: 'idle_waiting_user' };
+}
 async function loadPendingDiagnosticsSnapshot(args) {
     const ownerDialogIdObj = new dialog_1.DialogID(args.ownerDialogId, args.rootId);
     try {
@@ -304,6 +329,8 @@ async function executeDriveRound(args) {
     let subdialogReplyTarget;
     let activeTellaskReplyDirective;
     let activePromptWasReplyToolReminder = false;
+    let shouldPauseAfterLocalUserInterjection = false;
+    let resumeFromInterjectionPause = false;
     const allowResumeFromInterrupted = driveOptions?.allowResumeFromInterrupted === true || humanPrompt?.origin === 'user';
     const driveSource = resolveDriveRequestSource(humanPrompt, driveOptions);
     try {
@@ -340,6 +367,11 @@ async function executeDriveRound(args) {
                 });
                 return;
             }
+            resumeFromInterjectionPause =
+                humanPrompt === undefined &&
+                    allowResumeFromInterrupted &&
+                    latest?.executionMarker?.kind === 'interrupted' &&
+                    (0, interjection_pause_stop_1.isUserInterjectionPauseStopReason)(latest.executionMarker.reason);
         }
         catch (err) {
             log_1.log.warn('kernel-driver failed to check execution facts before drive; proceeding best-effort', err, {
@@ -382,10 +414,39 @@ async function executeDriveRound(args) {
                     return;
                 }
             }
-            const suspension = await dialog.getSuspensionStatus();
+            // WARNING:
+            // `allowResumeFromInterrupted` covers multiple stop reasons, but the interjection-pause case
+            // is semantically special. Clicking Continue here does NOT mean "blindly clear stopped and
+            // drive". We must re-read the fresh persistence facts first because there are three distinct
+            // true-source cases behind the same visible stopped panel:
+            // - no active reply obligation / not suspended anymore -> continue real driving now
+            // - active reply obligation + suspended -> restore true blocked state
+            // - active reply obligation + still proceeding entitlement (for example queued upNext) ->
+            //   continue real driving now
+            //
+            // Do not refactor this branch using only `displayState` or only the previous interrupted
+            // marker. The correct behavior emerges from combining fresh blocker facts, queued prompt
+            // state, and the deferred reply reassertion logic elsewhere.
+            const suspension = resumeFromInterjectionPause
+                ? await loadFreshSuspensionStatusFromPersistence(dialog)
+                : await dialog.getSuspensionStatus();
             const queuedPrompt = dialog.peekUpNext();
             const queuedSubdialogPromptCanResume = dialog instanceof dialog_1.SubDialog && queuedPrompt !== undefined;
             if (!suspension.canDrive && !queuedSubdialogPromptCanResume) {
+                if (resumeFromInterjectionPause) {
+                    const restoredState = buildDisplayStateFromSuspensionStatus({
+                        q4h: suspension.q4h,
+                        subdialogs: suspension.subdialogs,
+                    });
+                    await (0, dialog_display_state_1.setDialogDisplayState)(dialog.id, restoredState);
+                    log_1.log.debug('kernel-driver continue after interjection pause restored true suspended state from fresh persistence facts', undefined, {
+                        dialogId: dialog.id.valueOf(),
+                        restoredState,
+                        waitingQ4H: suspension.q4h,
+                        waitingSubdialogs: suspension.subdialogs,
+                    });
+                    return;
+                }
                 const lastTrigger = dialog_global_registry_1.globalDialogRegistry.getLastDriveTrigger(dialog.id.rootId);
                 const lastTriggerAgeMs = lastTrigger !== undefined ? Math.max(0, Date.now() - lastTrigger.emittedAtMs) : undefined;
                 log_1.log.debug('kernel-driver skip queued auto-drive while dialog is suspended', undefined, {
@@ -413,6 +474,15 @@ async function executeDriveRound(args) {
                 });
                 return;
             }
+            if (resumeFromInterjectionPause) {
+                log_1.log.debug('kernel-driver continue after interjection pause passed fresh fact scan and will keep driving', undefined, {
+                    dialogId: dialog.id.valueOf(),
+                    waitingQ4H: suspension.q4h,
+                    waitingSubdialogs: suspension.subdialogs,
+                    hasQueuedUpNext: dialog.hasUpNext(),
+                    queuedSubdialogPromptCanResume,
+                });
+            }
         }
         const minds = await (0, load_1.loadAgentMinds)(dialog.agentId, dialog);
         const policy = (0, guardrails_1.buildKernelDriverPolicy)({
@@ -508,6 +578,14 @@ async function executeDriveRound(args) {
             dlg: dialog,
             prompt: effectivePrompt,
         });
+        // Only park into the special interjection stopped-panel state when this user turn has
+        // suppressed a still-pending inter-dialog reply obligation that must be reasserted later.
+        // User interjections without a parked original task should simply finish and fall back to the
+        // dialog's true underlying state, without showing the special stopped panel.
+        shouldPauseAfterLocalUserInterjection =
+            effectivePrompt?.origin === 'user' &&
+                replyGuidance.suppressInterDialogReplyGuidance &&
+                replyGuidance.deferredReplyReassertionDirective !== undefined;
         activeTellaskReplyDirective = replyGuidance.activeReplyDirective;
         activePromptWasReplyToolReminder = isReplyToolReminderPrompt(effectivePrompt);
         if (effectivePrompt && effectivePrompt.userLanguageCode) {
@@ -573,28 +651,64 @@ async function executeDriveRound(args) {
                                 });
                             }
                             else {
-                                if (typeof driveResult.lastAssistantSayingGenseq !== 'number' ||
-                                    !Number.isFinite(driveResult.lastAssistantSayingGenseq) ||
-                                    driveResult.lastAssistantSayingGenseq <= 0) {
-                                    throw new Error(`Subdialog response supply invariant violation: missing lastAssistantSayingGenseq for dialog=${dialog.id.valueOf()}`);
-                                }
-                                const responseGenseq = Math.floor(driveResult.lastAssistantSayingGenseq);
-                                const directFallbackCallId = `direct-fallback-${(0, id_1.generateShortId)()}`;
-                                let supplied = false;
-                                if (subdialogReplyTarget) {
-                                    supplied = await (0, subdialog_1.supplySubdialogResponseToSpecificCallerIfPendingV2)({
-                                        subdialog: dialog,
-                                        responseText: driveResult.lastAssistantSayingContent,
-                                        responseGenseq,
-                                        target: subdialogReplyTarget,
-                                        deliveryMode: 'direct_fallback',
-                                        replyResolution: {
-                                            callId: directFallbackCallId,
-                                            replyCallName: activeTellaskReplyDirective.expectedReplyCallName,
-                                        },
-                                        scheduleDrive: args.scheduleDrive,
+                                if (!activePromptWasReplyToolReminder) {
+                                    const language = (0, work_language_1.getWorkLanguage)();
+                                    followUp = {
+                                        prompt: await buildReplyToolReminderPrompt({
+                                            dlg: dialog,
+                                            directive: activeTellaskReplyDirective,
+                                            language,
+                                        }),
+                                        msgId: (0, id_1.generateShortId)(),
+                                        grammar: 'markdown',
+                                        origin: 'runtime',
+                                        userLanguageCode: language,
+                                        tellaskReplyDirective: activeTellaskReplyDirective,
+                                        subdialogReplyTarget,
+                                    };
+                                    log_1.log.debug('kernel-driver queued subdialog replyTellask reminder after plain reply', undefined, {
+                                        dialogId: dialog.id.valueOf(),
+                                        targetCallId: activeTellaskReplyDirective.targetCallId,
+                                        targetOwnerDialogId: subdialogReplyTarget?.ownerDialogId,
                                     });
-                                    if (!supplied) {
+                                }
+                                else {
+                                    if (typeof driveResult.lastAssistantSayingGenseq !== 'number' ||
+                                        !Number.isFinite(driveResult.lastAssistantSayingGenseq) ||
+                                        driveResult.lastAssistantSayingGenseq <= 0) {
+                                        throw new Error(`Subdialog response supply invariant violation: missing lastAssistantSayingGenseq for dialog=${dialog.id.valueOf()}`);
+                                    }
+                                    const responseGenseq = Math.floor(driveResult.lastAssistantSayingGenseq);
+                                    const directFallbackCallId = `direct-fallback-${(0, id_1.generateShortId)()}`;
+                                    let supplied = false;
+                                    if (subdialogReplyTarget) {
+                                        supplied = await (0, subdialog_1.supplySubdialogResponseToSpecificCallerIfPendingV2)({
+                                            subdialog: dialog,
+                                            responseText: driveResult.lastAssistantSayingContent,
+                                            responseGenseq,
+                                            target: subdialogReplyTarget,
+                                            deliveryMode: 'direct_fallback',
+                                            replyResolution: {
+                                                callId: directFallbackCallId,
+                                                replyCallName: activeTellaskReplyDirective.expectedReplyCallName,
+                                            },
+                                            scheduleDrive: args.scheduleDrive,
+                                        });
+                                        if (!supplied) {
+                                            supplied = await (0, subdialog_1.supplySubdialogResponseToAssignedCallerIfPendingV2)({
+                                                subdialog: dialog,
+                                                responseText: driveResult.lastAssistantSayingContent,
+                                                responseGenseq,
+                                                deliveryMode: 'direct_fallback',
+                                                replyResolution: {
+                                                    callId: directFallbackCallId,
+                                                    replyCallName: activeTellaskReplyDirective.expectedReplyCallName,
+                                                },
+                                                scheduleDrive: args.scheduleDrive,
+                                            });
+                                        }
+                                    }
+                                    else {
                                         supplied = await (0, subdialog_1.supplySubdialogResponseToAssignedCallerIfPendingV2)({
                                             subdialog: dialog,
                                             responseText: driveResult.lastAssistantSayingContent,
@@ -607,35 +721,21 @@ async function executeDriveRound(args) {
                                             scheduleDrive: args.scheduleDrive,
                                         });
                                     }
-                                }
-                                else {
-                                    supplied = await (0, subdialog_1.supplySubdialogResponseToAssignedCallerIfPendingV2)({
-                                        subdialog: dialog,
-                                        responseText: driveResult.lastAssistantSayingContent,
-                                        responseGenseq,
-                                        deliveryMode: 'direct_fallback',
-                                        replyResolution: {
-                                            callId: directFallbackCallId,
-                                            replyCallName: activeTellaskReplyDirective.expectedReplyCallName,
-                                        },
-                                        scheduleDrive: args.scheduleDrive,
-                                    });
-                                }
-                                if (!supplied && subdialogReplyTarget) {
-                                    const diagnostics = await loadPendingDiagnosticsSnapshot({
-                                        rootId: dialog.id.rootId,
-                                        ownerDialogId: subdialogReplyTarget.ownerDialogId,
-                                        expectedSubdialogId: dialog.id.selfId,
-                                        status: dialog.status,
-                                    });
-                                    log_1.log.debug('kernel-driver failed to supply subdialog response to specific caller', undefined, {
-                                        calleeId: dialog.id.valueOf(),
-                                        targetOwner: subdialogReplyTarget.ownerDialogId,
-                                        targetOwnerDialogId: subdialogReplyTarget.ownerDialogId,
-                                        targetCallType: subdialogReplyTarget.callType,
-                                        targetCallId: subdialogReplyTarget.callId,
-                                        diagnostics,
-                                    });
+                                    if (!supplied && subdialogReplyTarget) {
+                                        const diagnostics = await loadPendingDiagnosticsSnapshot({
+                                            rootId: dialog.id.rootId,
+                                            ownerDialogId: subdialogReplyTarget.ownerDialogId,
+                                            expectedSubdialogId: dialog.id.selfId,
+                                            status: dialog.status,
+                                        });
+                                        log_1.log.debug('kernel-driver failed to supply subdialog response to specific caller', undefined, {
+                                            calleeId: dialog.id.valueOf(),
+                                            targetOwnerDialogId: subdialogReplyTarget.ownerDialogId,
+                                            targetCallType: subdialogReplyTarget.callType,
+                                            targetCallId: subdialogReplyTarget.callId,
+                                            diagnostics,
+                                        });
+                                    }
                                 }
                             }
                         }
@@ -716,6 +816,26 @@ async function executeDriveRound(args) {
                     },
                 });
             }
+            if (shouldPauseAfterLocalUserInterjection &&
+                !interruptedBySignal &&
+                followUp === undefined &&
+                driveResult?.lastAssistantSayingContent !== null) {
+                const pauseReason = (0, interjection_pause_stop_1.buildUserInterjectionPauseStopReason)();
+                await (0, dialog_display_state_1.setDialogDisplayState)(dialog.id, {
+                    kind: 'stopped',
+                    reason: pauseReason,
+                    continueEnabled: true,
+                });
+                (0, dialog_display_state_1.broadcastDisplayStateMarker)(dialog.id, {
+                    kind: 'interrupted',
+                    reason: pauseReason,
+                });
+                log_1.log.debug('kernel-driver paused original task after local user interjection reply', undefined, {
+                    dialogId: dialog.id.valueOf(),
+                    rootId: dialog.id.rootId,
+                    selfId: dialog.id.selfId,
+                });
+            }
         }
         catch (error) {
             tailError = error;

package/dist/llm/kernel-driver/reply-guidance.js

@@ -6,6 +6,8 @@ exports.buildReplyObligationSuppressionGuide = buildReplyObligationSuppressionGu
 exports.buildReplyObligationReassertionPrompt = buildReplyObligationReassertionPrompt;
 const dialog_1 = require("../../dialog");
 const dialog_instance_registry_1 = require("../../dialog-instance-registry");
+const persistence_1 = require("../../persistence");
+const interjection_pause_stop_1 = require("../../runtime/interjection-pause-stop");
 const reply_prompt_copy_1 = require("../../runtime/reply-prompt-copy");
 const work_language_1 = require("../../runtime/work-language");
 const tellask_special_1 = require("./tellask-special");
@@ -81,6 +83,17 @@ function buildPromptContentWithExactReplyToolName(args) {
     return `${note}\n\n${args.prompt.content}`;
 }
 async function shouldSuppressInterDialogReplyGuidanceForUserInterjection(args) {
+    // WARNING:
+    // This suppression decision is not a cosmetic prompt tweak. It is one leg of the full
+    // interjection-pause state machine:
+    // 1. user interjection suppresses the live reply obligation here;
+    // 2. `flow.ts` answers locally and parks the original task in a resumable stopped state;
+    // 3. manual Continue later decides from fresh persistence facts whether the dialog should stay
+    //    blocked or resume real driving.
+    //
+    // Do not "simplify" this into a pure display-state check or a pure pending-subdialog check.
+    // The business anchor is the deferred reply reassertion, while the paused execution marker keeps
+    // repeated interjection turns behaving as local side conversation until explicit Continue.
     const prompt = args.prompt;
     if (!prompt) {
         return false;
@@ -91,7 +104,18 @@ async function shouldSuppressInterDialogReplyGuidanceForUserInterjection(args) {
     if (prompt.tellaskReplyDirective !== undefined) {
         return false;
     }
-    return await args.dlg.hasPendingSubdialogs();
+    const latest = await persistence_1.DialogPersistence.loadDialogLatest(args.dlg.id, args.dlg.status);
+    if (latest?.deferredReplyReassertion?.reason === 'user_interjection_while_pending_subdialog') {
+        return true;
+    }
+    if (latest?.executionMarker?.kind === 'interrupted' &&
+        (0, interjection_pause_stop_1.isUserInterjectionPauseStopReason)(latest.executionMarker.reason)) {
+        return true;
+    }
+    // Use strict persistence reads here. This branch changes business behavior, so a read failure
+    // must loud-fail the round instead of being silently treated as "pending subdialogs exist".
+    const pendingSubdialogs = await persistence_1.DialogPersistence.loadPendingSubdialogs(args.dlg.id, args.dlg.status);
+    return pendingSubdialogs.length > 0;
 }
 async function resolvePromptReplyGuidance(args) {
     const prompt = args.prompt;

package/dist/llm/kernel-driver/tellask-special.js

@@ -140,8 +140,8 @@ async function deliverTellaskBackReplyFromDirective(args) {
     // the dialog running `replyTellaskBack` is the ask-back responder, while
     // directive.targetDialogId points to the ask-back requester that must receive the canonical
     // tellaskBack result. Keep those roles explicit, otherwise it is very easy to accidentally
-    // write the same business result once from the reply-tool path and then again from a fallback
-    // path that treats the responder's plain assistant words as if they were the canonical reply.
+    // write the same business result twice by confusing the responder's local plaintext with the
+    // canonical upstream delivery that must come only from an explicit reply tool call.
     const rootDialog = args.replyingDialog instanceof dialog_1.RootDialog
         ? args.replyingDialog
         : args.replyingDialog instanceof dialog_1.SubDialog
@@ -910,9 +910,6 @@ function findDeliveredTellaskBackReplyOnAskBackRequester(args) {
     return undefined;
 }
 async function extractAskBackResponderPlaintextFallback(args) {
-    // This fallback is intentionally second-class: it exists only for legacy/plain-reply flows
-    // where no explicit `replyTellaskBack` canonical result has been delivered. It must never
-    // compete with or overwrite an already delivered canonical tellaskBack result.
     try {
         return extractLastAssistantResponse(args.responderDialog.msgs, 'Supdialog completed without producing output.');
     }
@@ -1253,6 +1250,7 @@ async function executeTellaskCall(dlg, mentionList, body, callId, callbacks, opt
                         tellaskContent: body,
                         responseBody: responseText,
                         status: 'completed',
+                        deliveryMode: 'direct_fallback',
                         language: (0, work_language_1.getWorkLanguage)(),
                     });
                     askBackRequesterDialog.setSuspensionState('resumed');

package/dist/persistence.js

@@ -1553,7 +1553,7 @@ class DiskFileDialogStore extends dialog_1.DialogStore {
         // Duplicate final results are not harmless transcript noise. They mean two different program
         // paths both believed they owned the same business-level completion fact for one callId.
         // In ask-back flows this usually points to identity confusion between requester/responder or
-        // canonical reply-tool delivery versus fallback plaintext synthesis. We fail fast here so the
+        // canonical reply-tool delivery versus another mistaken write path. We fail fast here so the
         // second writer keeps its own stack trace instead of silently corrupting the dialog transcript.
         const err = new Error(`${args.kind} duplicate callId invariant violation: rootId=${args.dialog.id.rootId} selfId=${args.dialog.id.selfId} ` +
             `callId=${args.callId} callName=${args.callName} existingCourse=${args.existingCourse} ` +

package/dist/runtime/interjection-pause-stop.d.ts

@@ -0,0 +1,5 @@
+import type { DialogInterruptionReason } from '@longrun-ai/kernel/types/display-state';
+export declare function buildUserInterjectionPauseStopReason(): Extract<DialogInterruptionReason, {
+    kind: 'system_stop';
+}>;
+export declare function isUserInterjectionPauseStopReason(reason: DialogInterruptionReason | undefined): boolean;

package/dist/runtime/interjection-pause-stop.js

@@ -0,0 +1,35 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.buildUserInterjectionPauseStopReason = buildUserInterjectionPauseStopReason;
+exports.isUserInterjectionPauseStopReason = isUserInterjectionPauseStopReason;
+const USER_INTERJECTION_PAUSE_STOP_DETAIL = 'user_interjection_pause_resume_original_task';
+// WARNING:
+// This special stop reason is only a UI/run-control projection for "user interjected, and there
+// is still an original task parked for explicit Continue". It is intentionally encoded as
+// `system_stop`, but it does NOT mean the same thing as ordinary system-stop failure semantics.
+//
+// Not every user interjection should use this reason. If there is no parked original task to
+// resume afterwards, the interjection should simply complete and the dialog should fall back to
+// its true underlying state without showing this stopped panel.
+//
+// Do not change this file in isolation. The complete behavior depends on coordinated logic across:
+// - `reply-guidance.ts`          suppressing upstream reply obligation during interjection chat
+// - `flow.ts`                   parking after the local reply, then re-running fresh-fact resume
+// - `dialog-display-state.ts`   preserving this paused projection until explicit Continue
+// - `websocket-handler.ts`      treating Continue as "resume attempt" rather than immediate success
+//
+// Reading only this stop reason or only `displayState.kind === 'stopped'` gives an incomplete and
+// often wrong mental model.
+function buildUserInterjectionPauseStopReason() {
+    return {
+        kind: 'system_stop',
+        detail: USER_INTERJECTION_PAUSE_STOP_DETAIL,
+        i18nStopReason: {
+            zh: '插话已处理；原任务已暂停。点击“继续”恢复原任务，继续发送新消息则继续这段临时对话。',
+            en: 'Interjection handled; the original task is paused. Click Continue to resume it, or send another message to keep this temporary side conversation going.',
+        },
+    };
+}
+function isUserInterjectionPauseStopReason(reason) {
+    return reason?.kind === 'system_stop' && reason.detail === USER_INTERJECTION_PAUSE_STOP_DETAIL;
+}

package/dist/server/websocket-handler.js

@@ -102,6 +102,15 @@ function emitRunControlRefresh(reason) {
     });
 }
 function buildResumeIneligibleMessage(latest) {
+    // WARNING:
+    // `resume_dialog` eligibility is intentionally based on the freshly healed projection, not on a
+    // naive local check of raw blocker facts. In particular, the paused-interjection stopped state
+    // must remain resumable here so the user can explicitly press Continue even while the underlying
+    // dialog may still be blocked.
+    //
+    // The actual outcome of that Continue attempt is decided later in `flow.ts` from fresh facts:
+    // it may restore `blocked`, or it may immediately continue driving. Do not reinterpret a
+    // resumable stopped state here as "guaranteed to run now".
     const state = latest?.displayState;
     if (!state) {
         return {
@@ -1288,6 +1297,11 @@ async function handleResumeDialog(ws, packet) {
     }
     const dialogIdObj = new dialog_1.DialogID(dialog.selfId, dialog.rootId);
     const latest = await (0, dialog_display_state_1.refreshRunControlProjectionFromPersistenceFacts)(dialogIdObj, 'resume_dialog');
+    // WARNING:
+    // Passing this gate only means "a manual Continue attempt is allowed". It does not mean the
+    // dialog is guaranteed to re-enter proceeding immediately. For the paused-interjection flow, the
+    // resumed drive itself performs a second fresh-fact decision and may land in true `blocked`
+    // instead of proceeding.
     if (!(0, dialog_display_state_1.isDialogLatestResumable)(latest)) {
         const ineligible = buildResumeIneligibleMessage(latest);
         log.warn('resume_dialog rejected after fresh fact scan', undefined, {

package/dist/tools/team_mgmt.js

@@ -3429,14 +3429,15 @@ function renderMindsManual(language) {
         return (fmtHeader('.minds/team/<id>/*') +
             fmtList([
                 '推荐实践（建议默认采用）：每个 `members.<id>` 同时维护 `persona.*.md` / `knowledge.*.md` / `lessons.*.md`，把角色设定、领域知识、经验教训分层管理。',
-                '最小要求：每个 `members.<id>` 建议至少提供 `persona.*.md`（否则该成员将缺少可发现的角色设定；具体忽略/回退/报错行为以当前实现为准）。',
-                'persona.*.md：角色设定（稳定的工作方式与职责）。',
+                '共同去向（按当前实现）：这三类文件会在每次对话开始时按工作语言读取，并分别拼进 system prompt 的 `## 角色设定` / `## 知识` / `## 经验` 章节；它们是写给“当前成员智能体自己”看的长期提示，不是给团队管理者/人类旁观者读的人物简介。',
+                '最小要求：每个 `members.<id>` 建议至少提供 `persona.*.md`。当前实现中，缺失 persona 时会回退到内置默认 persona 文案；缺失或空白的 knowledge/lessons 会在系统提示中以本地化的“无”占位显示。',
+                'persona.*.md：角色设定（稳定的工作方式与职责）。它会进入该成员的 `role=system` 提示，因此默认应直接写给该智能体本人，使用第二人称“你”来规定职责、边界与工作方式；不要把它写成第三人称人物简介，更不要使用“祂”这类旁白口吻。',
+                'knowledge.*.md：领域知识。它会进入 `## 知识`，适合写“当前成员在该职责下反复要用到的稳定事实 / 索引 / 约定 / 判断依据”；口吻可用第二人称提示，或零人称资料式 bullet，但目标始终是帮助该成员立刻行动，不是对外介绍这个成员。',
+                'lessons.*.md：经验教训。它会进入 `## 经验`，适合写成可复用的行为准则，例如“遇到什么信号 -> 先做什么 / 不要做什么 -> 为什么”；不要写成任务流水账、会议纪要或第三人称成长故事。',
                 '若该成员承担团队管理职责（尤其获得 `team_mgmt`），其 `persona.*.md` 必须明确写出：执行任何团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。',
-                'knowledge.*.md：领域知识（可维护）。',
-                'lessons.*.md：经验教训（可维护）。',
-                '写法约束：`persona/knowledge/lessons` 文件里不要再写重复的总标题。系统提示模板会自动添加：`## 角色设定` / `## 知识` / `## 经验`（英文模板对应 `## Persona` / `## Knowledge` / `## Lessons`）。',
+                '语言选择（按当前实现）：优先读取 `persona.zh.md` / `knowledge.zh.md` / `lessons.zh.md` 这类工作语言文件，其次才回退到无语言后缀的 `persona.md` / `knowledge.md` / `lessons.md`；不会跨语言回退到另一种语言文件。',
+                '标题层级约束：`persona/knowledge/lessons` 文件里不要再写重复的总标题。系统提示模板会自动添加：`## 角色设定` / `## 知识` / `## 经验`（英文模板对应 `## Persona` / `## Knowledge` / `## Lessons`）。因此正文通常应从 `###` 小节或普通 bullet 开始，而不是再写 `#` / `##`，也不要再把文件名或“角色设定/知识/经验”重复当标题写一遍。',
                 'Codex provider 专属能力：若该成员使用 `provider: codex`，可在 `persona.*.md` 中单独写一行 `@codex-system-prompt`，把 stock Codex 内置系统提示拼接进当前 persona；需要固定某个模板版本时写 `@codex-system-prompt:<model>`。建议把这行放在文件最前面，再继续写本团队自己的角色边界与交付要求。',
-                '语言文件命名：优先按工作语言提供 `persona.zh.md` / `persona.en.md` 等；是否回退到 `persona.md`/其他语言版本，以当前实现为准。',
             ]) +
             fmtCodeBlock('text', [
                 '.minds/',
@@ -3450,12 +3451,12 @@ function renderMindsManual(language) {
                 '@codex-system-prompt',
                 '',
                 '### 核心身份',
-                '- 专业程序员，负责按规格完成代码开发。',
+                '- 你是专业程序员，负责按规格完成代码开发。',
                 '### 工作边界',
-                '- 不负责需求分析或产品策略决策。',
-                '- 只根据已确认的开发规格进行实现与重构。',
+                '- 你不负责需求分析或产品策略决策。',
+                '- 你只根据已确认的开发规格进行实现与重构。',
                 '### 交付标准',
-                '- 输出可运行代码，并附关键验证步骤。',
+                '- 你要输出可运行代码，并附关键验证步骤。',
             ]) +
             fmtCodeBlock('markdown', [
                 '- 修改前先定位调用链与数据流，避免“只改表面”。',
@@ -3466,14 +3467,15 @@ function renderMindsManual(language) {
     return (fmtHeader('.minds/team/<id>/*') +
         fmtList([
             'Recommended default practice: for each `members.<id>`, maintain `persona.*.md` / `knowledge.*.md` / `lessons.*.md` together so persona, domain knowledge, and lessons stay layered and maintainable.',
-            'Minimum: for each `members.<id>`, provide at least `persona.*.md` (otherwise the member may lack a discoverable persona; ignore/fallback/error behavior follows current implementation).',
-            'persona.*.md: persona and operating style.',
+            'Shared destination (current implementation): these three files are read at every dialog start and are spliced into the system prompt as `## Persona` / `## Knowledge` / `## Lessons`. They are long-lived prompt assets written for the current member agent itself, not operator-facing biographies for a team manager or human observer.',
+            'Minimum: for each `members.<id>`, provide at least `persona.*.md`. In the current implementation, a missing persona falls back to built-in default persona text, while missing/blank knowledge and lessons render as the localized “none” placeholder.',
+            'persona.*.md: persona and operating style. It is injected into that member\'s `role=system` prompt, so write it directly to the agent in second person ("you") when specifying responsibilities, boundaries, and working style; do not turn it into a third-person biography.',
+            'knowledge.*.md: domain knowledge. It lands in `## Knowledge`, so use it for stable facts, indexes, conventions, and decision cues that the member repeatedly needs in this responsibility. Second-person guidance or neutral reference bullets are both fine, as long as the text helps the member act now rather than describing the member from the outside.',
+            'lessons.*.md: lessons learned. It lands in `## Lessons`, so prefer reusable heuristics such as “if signal X appears -> do / avoid Y -> because Z”. Do not treat it as a task log, meeting minutes, or a third-person growth narrative.',
             'If the member carries team-management responsibility (especially with `team_mgmt`), `persona.*.md` must explicitly require reading the relevant `man({ "toolsetId": "team_mgmt" })` chapters before any team-management action, and maintaining `.minds/**` team mind assets by handbook-standard workflow.',
-            'knowledge.*.md: domain knowledge (maintainable).',
-            'lessons.*.md: lessons learned (maintainable).',
-            'Authoring rule: do not add top-level titles that duplicate the system prompt wrapper. The system prompt already adds: `## Persona` / `## Knowledge` / `## Lessons` (zh template: `## 角色设定` / `## 知识` / `## 经验`).',
+            'Language selection (current implementation): prefer work-language variants such as `persona.en.md` / `knowledge.en.md` / `lessons.en.md`, then fall back to `persona.md` / `knowledge.md` / `lessons.md`. There is no cross-language fallback to another language-specific file.',
+            'Heading rule: do not add top-level titles that duplicate the system prompt wrapper. The system prompt already adds: `## Persona` / `## Knowledge` / `## Lessons` (zh template: `## 角色设定` / `## 知识` / `## 经验`). In practice, bodies should usually start at `###` subsections or plain bullets rather than another `#` / `##`, and should not restate the filename or wrapper title as a heading.',
             'Codex-provider-specific capability: if this member uses `provider: codex`, you may place a standalone `@codex-system-prompt` line inside `persona.*.md` to splice the stock Codex built-in system prompt into the current persona. Use `@codex-system-prompt:<model>` to pin a specific bundled prompt variant. Put that line near the top, then continue with your team-specific role boundaries and delivery rules.',
-            'Language variants: prefer working-language files like `persona.en.md` / `persona.zh.md`; whether it falls back to `persona.md` or other languages follows current implementation.',
         ]) +
         fmtCodeBlock('text', [
             '.minds/',
@@ -3487,12 +3489,12 @@ function renderMindsManual(language) {
             '@codex-system-prompt',
             '',
             '### Core Identity',
-            '- Professional programmer responsible for implementing approved development specs.',
+            '- You are a professional programmer responsible for implementing approved development specs.',
             '### Work Boundaries',
-            '- Not responsible for requirement discovery or product strategy.',
-            '- Implements/refactors only against confirmed specs.',
+            '- You are not responsible for requirement discovery or product strategy.',
+            '- You implement/refactor only against confirmed specs.',
             '### Delivery Standard',
-            '- Deliver runnable code plus key verification steps.',
+            '- You deliver runnable code plus key verification steps.',
         ]) +
         fmtCodeBlock('markdown', [
             '- Trace call chain and data flow before editing; avoid patching only symptoms.',
@@ -3508,6 +3510,8 @@ function renderSkillsManual(language) {
                 '语言选择：Dominds 当前工作语言是 `zh|en`，但 skill 文件后缀采用更通行的 `cn|en`。当工作语言为 `zh` 时优先读取 `SKILL.cn.md`，当工作语言为 `en` 时优先读取 `SKILL.en.md`，两者都可回退到无语言标识的 `SKILL.md`；不会跨语言兜底到另一种语言文件。',
                 '可移植优先格式：遵循当前主流 Agent Skills 生态公共子集，使用 `SKILL.md + YAML frontmatter`。最小必备字段是 `name` 与 `description`，正文 markdown 即真正的技能提示词/操作指引。',
                 'Dominds 当前实现会把匹配到的 skill 内容直接注入 agent system prompt；因此这里的技能更接近“指导知识包”。这与部分平台的“先只加载 name/description、命中后再延迟加载正文”不同，请控制体量，把长参考资料拆到同目录其它文件并在正文里按需引用。',
+                '去向与口吻（按当前实现）：`name` 会成为 skills 小节里的标题，`description` 会作为说明文字显示，正文会原样进入 `Prompt` 区块。因此三者都属于写给“当前成员智能体”的系统提示内容。推荐把 `name` 写成稳定技能名，把 `description` 写成“何时用/何时不用”，把正文写成简洁的操作指引（多用祈使句/第二人称），不要写成 marketplace 营销文案、第三人称人物介绍，或对团队管理者的旁白说明。',
+                '标题层级约束：skills 模板已经自动包好 `### Skills（工作技能）` 和每个 skill 的 `#### <name>` 标题。正文通常应从普通 bullet、步骤列表，或至多 `#####` 小节开始；不要在正文里再写 `# <skill-name>` / `## ...` 来重复外层标题结构。',
                 '为兼容公开来源，可保留 `allowed-tools` / `user-invocable` / `disable-model-invocation` 字段；但在 Dominds 中：这些字段目前只用于迁移/文档语义，不会自动授予工具权限，也不会改变运行时调度逻辑。',
                 '最重要的边界：skill 不是权限系统。真正的工具能力仍由 `.minds/team.yaml` 的 `toolsets` / `tools` 与已安装 Dominds apps 决定。',
                 '团队管理职责的智能体可以联网搜索公开 skill 定义（优先官方文档/官方仓库/官方 marketplace 条目），也可以直接基于团队真实操作经验自行总结编写。迁移前必须核对 license、适用场景、是否依赖脚本/外部工具、是否夹带与本团队冲突的人设/权限假设。',
@@ -3526,13 +3530,11 @@ function renderSkillsManual(language) {
                 'disable-model-invocation: false',
                 '---',
                 '',
-                '# Repo Debugger',
-                '',
-                '## 入口',
+                '##### 入口',
                 '- 先确认失败信号与复现入口。',
                 '- 若需要 shell，必须使用当前团队已授权的 Dominds 工具/专员，不得把 `allowed-tools` 视为自动授权。',
                 '',
-                '## 操作步骤',
+                '##### 操作步骤',
                 '1. 收集报错与最近变更。',
                 '2. 最小化复现。',
                 '3. 定位根因并给出验证方案。',
@@ -3572,6 +3574,8 @@ function renderSkillsManual(language) {
             'Language selection: Dominds work language is currently `zh|en`, but skill filenames use the more portable `cn|en` suffixes. When work language is `zh`, Dominds prefers `SKILL.cn.md`; when it is `en`, Dominds prefers `SKILL.en.md`; both may fall back to `SKILL.md`. There is no cross-language fallback.',
             'Portable-first format: follow the common Agent Skills subset used by GitHub/Codex/Claude/skills.sh style ecosystems: `SKILL.md + YAML frontmatter`. The minimum required fields are `name` and `description`; the Markdown body is the actual skill prompt/operating guidance.',
             'Current Dominds behavior eagerly injects matched skills into the agent system prompt. That makes a Dominds skill closer to a guidance knowledge pack than to a lazily loaded marketplace artifact. Keep bodies tight, and move long references into sibling files that the body points to.',
+            'Destination and tone (current implementation): `name` is rendered as the skill heading, `description` appears as visible description text, and the body is inserted verbatim into the `Prompt` block inside system prompt. Write all three for the current member agent. Use a stable skill name, trigger-oriented description, and concise operating guidance in the body; avoid marketplace sales copy, third-person biographies, or operator-facing narration.',
+            'Heading rule: the wrapper already provides `### Skills` and `#### <name>` for each skill. Bodies should usually start with plain bullets, numbered steps, or at most `#####` subsections; do not repeat the outer structure with another `# <skill-name>` / `## ...` inside the body.',
             'For compatibility with public skill sources, Dominds accepts `allowed-tools`, `user-invocable`, and `disable-model-invocation`; however, in Dominds these fields are currently informational only. They do not grant tools and do not change runtime dispatch yet.',
             'The hard boundary: a skill is not a permission system. Real tool access still comes from `.minds/team.yaml` (`toolsets` / `tools`) and installed Dominds apps.',
             'A team-management agent may browse the web for public skill definitions (prefer official docs/repos/marketplace listings), or write skills directly by summarizing the team’s own repeatable operating guidance. Before importing, verify license, applicability, script/tool dependencies, and any hidden persona/permission assumptions.',
@@ -3591,13 +3595,11 @@ function renderSkillsManual(language) {
             'disable-model-invocation: false',
             '---',
             '',
-            '# Repo Debugger',
-            '',
-            '## Entry',
+            '##### Entry',
             '- Confirm the failure signal and reproduction path first.',
             '- If shell is required, use only the Dominds tools/specialists actually granted by the team; never treat `allowed-tools` as auto-authorization.',
             '',
-            '## Procedure',
+            '##### Procedure',
             '1. Gather the error signal and recent changes.',
             '2. Minimize reproduction.',
             '3. Isolate root cause and propose verification.',
@@ -3636,14 +3638,19 @@ function renderPrimingManual(language) {
         return (fmtHeader('.minds/priming/*（启动脚本）') +
             fmtList([
                 '目录约定：个人脚本放在 `.minds/priming/individual/<member-id>/<slug>.md`；团队共享脚本放在 `.minds/priming/team_shared/<slug>.md`。',
-                '脚本语义：启动脚本会映射成“对话历史”并在创建对话时注入；它不是只读日志，而是可编辑的行为引导层。',
+                '脚本语义（按当前实现）：创建对话时，frontmatter 里的 `reminders` 会先恢复为该对话的提醒状态；随后脚本 records 会被追加进持久化事件流，并尽可能回放成真正的对话历史消息。它不是 system prompt，也不是只读日志，而是可编辑的“起手历史/行为引导层”。',
                 '推荐格式：`frontmatter + record 块`。每个 `### record <type>` 对应一个持久化事件（去掉 `ts`），可忠实复原 tool 记录与 call-id 等技术细节。',
+                '口吻规则取决于 record 类型，而不是统一写成一种旁白：`human_text_record` 会变成 `role=user` 的 prompting message，应写成“用户/诉请者正在对这个智能体说的话”；`agent_words_record` 会变成 `role=assistant` 的可见回复，应写成“这个智能体已经说出口的话”；`agent_thought_record` 会变成 thinking message，只适合非常克制地承载内部推理痕迹，不适合拿来写通用制度说明。',
+                '`func_call_record` / `func_result_record` / tellask 相关 records 属于技术回放层：如果要保留，就应写真实调用名、参数、结果与关联 id，而不是随手写一段 prose 摘要来冒充工具历史。',
+                '`ui_only_markdown_record` 以及若干运行时技术 record 会被持久化，但不会转成喂给模型的 chat message；不要指望这类 record 去直接塑造模型行为。',
                 '严格约束：不支持 `### user` / `### assistant` 旧写法。',
                 '`func_call_record` 使用三反引号 `json`；其余 record 建议使用 6 重反引号 markdown block（避免与正文三反引号冲突）。',
                 '建议在 frontmatter 里维护 `title`、`applicableMemberIds` 等元数据；`team_shared` 脚本可用 `applicableMemberIds` 控制适用成员。',
+                'frontmatter.reminders 的写法也要遵循 reminder 语义：内容应短小、像工作集提示，不要塞成长文手册；若省略 `scope`，当前实现默认是 `dialog`；只有明确希望后续对话也继续可见时，才使用 `personal` 或 `agent_shared`。',
                 '维护原则：允许任意编辑/重写脚本内容，包括新增或改写 assistant 消息，以引导期望行为（而不是拘泥于历史实录）。',
                 '每次修改 `.minds/priming/**` 后，建议运行 `team_mgmt_validate_priming_scripts({})` 做格式/路径校验。',
                 'WebUI 支持把“当前 course 历史”直接导出为个人启动脚本；导出后应由团队管理者审阅并按团队规范再编辑。',
+                '结构层级约束：priming 文件的外层结构以“顶层 frontmatter + 多个 `### record <type>` 块”为准；不要再包一层 `# 启动脚本` / `## 历史` 之类的装饰性章节。真正喂给模型的文本结构，应写在各个 record 自己的 markdown/json block 里。',
                 'slug 规范：使用 `[A-Za-z0-9._-]` 路径段，可多级；严禁 `..`、绝对路径或非法字符。',
             ]) +
             fmtCodeBlock('markdown', [
@@ -3680,14 +3687,19 @@ function renderPrimingManual(language) {
     return (fmtHeader('.minds/priming/* (startup scripts)') +
         fmtList([
             'Directory convention: individual scripts live at `.minds/priming/individual/<member-id>/<slug>.md`; team-shared scripts live at `.minds/priming/team_shared/<slug>.md`.',
-            'Script semantics: startup scripts are mapped into dialog history at creation time. They are not read-only logs; they are editable behavior-guidance assets.',
+            'Script semantics (current implementation): at dialog creation, frontmatter `reminders` are restored into dialog reminder state first; then records are appended to the persisted event stream and replayed into dialog history when possible. A priming script is not system prompt text and not a read-only log; it is an editable “startup history / behavior-guidance” asset.',
             'Recommended format: `frontmatter + record blocks`. Each `### record <type>` maps to one persisted event (without `ts`) for faithful replay, including tool records and call-id links.',
+            'Tone depends on record type, not on one narrator voice: `human_text_record` becomes a `role=user` prompting message, so write it as what the user/requester is saying to the agent; `agent_words_record` becomes a visible `role=assistant` reply, so write it as words the agent has already said; `agent_thought_record` becomes a thinking message and should be used sparingly, not as a place for general policy prose.',
+            '`func_call_record` / `func_result_record` / tellask-related records are technical replay artifacts. Keep real call names, arguments, results, and linked ids if you include them; do not replace them with loose prose summaries.',
+            '`ui_only_markdown_record` and several runtime-only technical records persist on disk but do not become chat messages for model context. Do not rely on those record types to steer the model directly.',
             'Strict rule: legacy `### user` / `### assistant` sections are not supported.',
             '`func_call_record` uses triple-backtick `json`; other records should use six-backtick markdown blocks to avoid nested-fence collisions.',
             'Use frontmatter for metadata like `title` and `applicableMemberIds`; for `team_shared`, `applicableMemberIds` narrows applicability.',
+            'frontmatter.reminders should follow reminder semantics too: keep them short like working-set prompts rather than mini-manuals. If `scope` is omitted, the current implementation defaults it to `dialog`; use `personal` / `agent_shared` only when you intentionally want later dialogs to keep seeing the reminder.',
             'Maintenance principle: freely edit or fully rewrite scripts, including assistant messages, to shape expected behavior.',
             'After each edit under `.minds/priming/**`, run `team_mgmt_validate_priming_scripts({})` for format/path validation.',
             'WebUI can export current-course history into an individual startup script; team managers should review and refine exported scripts.',
+            'Structure rule: the outer file structure is “top-level frontmatter + repeated `### record <type>` blocks”. Do not wrap the script in decorative `# Startup Script` / `## History` headings. The model-facing structure belongs inside each record’s own markdown/json block.',
             'Slug rule: use `[A-Za-z0-9._-]` path segments (nested allowed); reject `..`, absolute paths, and illegal characters.',
         ]) +
         fmtCodeBlock('markdown', [
@@ -3725,17 +3737,19 @@ function renderEnvManual(language) {
     if (language === 'zh') {
         return (fmtHeader('.minds/env.*.md（运行环境提示）') +
             fmtList([
-                '用途：为“当前 rtws 的运行环境”提供一段稳定的介绍文案。Dominds 会将其注入到 agent 的 system prompt 中，注入位置在“团队目录（Team Directory）”之前。',
+                '用途：为“当前 rtws 的运行环境”提供一段稳定的介绍文案。Dominds 会将其注入到 agent 的 system prompt 的 `## 运行环境` 章节，注入位置在“团队目录（Team Directory）”之前。',
                 '文件位置：写在当前 rtws 的 `.minds/` 下；切换 rtws（例如 `-C ux-rtws`）时，应在对应 rtws 的 `.minds/` 下分别维护。',
                 '推荐文件名：`env.zh.md`（中文语义基准）与 `env.en.md`（英文对齐）。',
                 '回退规则：优先按工作语言读取 `env.<lang>.md`；如不存在，可回退到 `env.md`（以当前实现为准）。空文件/仅空白会被当作“无提示”。',
+                '口吻建议：它虽然进入 system prompt，但职责不是定义人设，而是给当前成员做环境定向。最合适的是简洁、可核实的事实说明，可用中性 bullet，也可用“你当前处于……”这类第二人称 briefing；核心是让成员快速知道自己身处哪个 rtws、有哪些关键路径/入口/端口/约束。',
+                '标题层级约束：系统模板已经提供 `## 运行环境` 标题，所以 `env.*.md` 正文通常应从 `###` 小节或普通 bullet 开始；不要再写一层 `# 环境说明` / `## 本 rtws ...` 来重复模板标题。',
+                '边界提醒：不要把 `env.*.md` 写成 persona、skill、工具手册或仓库总规范大杂烩；不要在这里重复团队职责边界、长篇流程制度，或凭空编造环境事实。',
                 'i18n 约定：`zh` 为语义基准。不要把 `zh` 通过翻译 `en` 来更新；应让 `en` 追随 `zh` 的语义。',
                 '管理者提醒：若发现缺失/质量不佳/与实际环境不符，应与人类用户讨论并确认措辞，然后再写入/更新对应的 `env.*.md`（避免“凭空编造”的环境描述）。',
             ]) +
             fmtCodeBlock('text', [
-                '# 示例（片段；请按你的 rtws 真实环境改写）',
-                '## 本 rtws 的 Dominds 运行环境说明',
-                '',
+                '示例（片段；请按你的 rtws 真实环境改写）',
+                '### 当前 rtws 概况',
                 '- 本 rtws 用于 Dominds 自我开发与联调。',
                 '- Dominds 程序来源：本机全局 link 的 `dominds`，由 `./dominds/` 构建产物提供。',
                 '- WebUI dev/UX：`./dev-server.sh` 使用 `ux-rtws/` 作为 rtws（避免污染根 rtws）。',
@@ -3743,17 +3757,19 @@ function renderEnvManual(language) {
     }
     return (fmtHeader('.minds/env.*.md (runtime environment intro)') +
         fmtList([
-            'Purpose: provide a stable intro note describing the “current rtws runtime environment”. Dominds injects it into the agent system prompt, positioned before “Team Directory”.',
+            'Purpose: provide a stable intro note describing the “current rtws runtime environment”. Dominds injects it into the `## Runtime Environment` section of the agent system prompt, positioned before “Team Directory”.',
             'Location: place it under the current rtws `.minds/`. If you switch rtws (e.g. `-C ux-rtws`), maintain a separate `env.*.md` under that rtws’s `.minds/`.',
             'Recommended filenames: `env.zh.md` (canonical semantics) and `env.en.md` (English aligned to zh).',
             'Fallback behavior: prefer `env.<lang>.md` by working language; if missing, it may fall back to `env.md` (per current implementation). Empty/whitespace-only content is treated as “no intro”.',
+            'Tone guidance: although it enters system prompt, its job is environmental orientation rather than persona definition. Prefer concise, verifiable facts in neutral bullets or a brief second-person orientation like “you are currently in...”; the goal is to help the member quickly understand the active rtws, key paths, entrypoints, ports, and constraints.',
+            'Heading rule: the system template already provides the `## Runtime Environment` heading, so `env.*.md` bodies should usually start at `###` subsections or plain bullets rather than another `# Environment Notes` / `## This rtws ...` wrapper.',
+            'Boundary reminder: do not turn `env.*.md` into a persona file, skill, tool manual, or giant repo-policy dump. Avoid duplicating role rules, long procedures, or speculative environment claims.',
             'i18n rule: `zh` is canonical. Do not update `zh` by translating from `en`; update `en` to match `zh` semantics.',
             'Manager reminder: if the file is missing / inaccurate / low quality, discuss wording with the human user and then write/update `env.*.md` (avoid fabricating environment details).',
         ]) +
         fmtCodeBlock('text', [
-            '# Example (snippet; tailor to your real rtws)',
-            '## Dominds runtime environment notes',
-            '',
+            'Example (snippet; tailor to your real rtws)',
+            '### Current rtws overview',
             '- This rtws is used for Dominds self-development and integration.',
             '- Program source: a globally linked `dominds` built from `./dominds/`.',
             '- WebUI dev/UX: `./dev-server.sh` uses `ux-rtws/` as rtws (keeps root rtws clean).',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dominds",
-  "version": "1.16.6",
+  "version": "1.16.8",
   "description": "Dominds CLI and aggregation shell for the LongRun AI kernel/runtime packages.",
   "type": "commonjs",
   "publishConfig": {