dominds 0.8.4 → 0.8.6

package/README.md

@@ -188,7 +188,7 @@ dominds
    - Provide the required provider env var and write it to your shell rc (or set it manually). Setup applies it immediately to the running server.
    - Click **Go to App**.
 3. In the app, create a new dialog with **shadow member** `@fuxi` (Fuxi is hidden by default; use the “Shadow members” picker in the dialog creation modal). Until you add visible members, you’ll mostly work through shadow members.
-4. Tell `@fuxi` your product idea and ask it to propose and apply a suitable agentic team configuration by updating `.minds/team.yaml` (Fuxi has the `team-mgmt` toolset scoped to `.minds/**`).
+4. Tell `@fuxi` your product idea and ask it to propose and apply a suitable agentic team configuration by updating `.minds/team.yaml` (Fuxi has the `team_mgmt` toolset scoped to `.minds/**`).
 
 ## Core Philosophy
 
@@ -248,7 +248,7 @@ Result: fewer bad side effects, higher plan fidelity, and more first‑try succe
 - **[Roadmap](docs/roadmap.md)** — Major-version plan and evolution
 - **[OEC Philosophy](docs/OEC-philosophy.md)** — Philosophy and safety stance
 
-- **[Team Mgmt Toolset](docs/team-mgmt-toolset.md)** — Managing team members via tools
+- **[Team Mgmt Toolset](docs/team_mgmt-toolset.md)** — Managing team members via tools
 - **[Text Editing Tools (ws_mod)](docs/txt-editing-tools.md)** — `ws_mod` toolset design doc (as implemented)
 - **[i18n](docs/i18n.md)** — Language and localization rules
 - **[Dialog System](docs/dialog-system.md)** — Dialog runtime model and streaming

package/README.zh.md

@@ -159,7 +159,7 @@ Dominds 面向“长期开发运作（DevOps）”场景设计，基于社会化
 - **[Roadmap](docs/roadmap.zh.md)** — 发展规划与版本演进方向
 - **[OEC Philosophy](docs/OEC-philosophy.zh.md)** — 全方位优化管理法
 
-- **[Team Mgmt Toolset](docs/team-mgmt-toolset.zh.md)** — 团队管理工具集
+- **[Team Mgmt Toolset](docs/team_mgmt-toolset.zh.md)** — 团队管理工具集
 - **[Text Editing Tools (ws_mod)](docs/txt-editing-tools.zh.md)** — 文本编辑工具集设计文档（以当前实现为准）
 - **[i18n](docs/i18n.zh.md)** — 语言支持与本地化配置
 - **[Dialog System](docs/dialog-system.zh.md)** — 对话系统与流式事件

package/dist/access-control.js

@@ -165,7 +165,7 @@ function hasReadAccess(member, targetPath) {
         return false;
     }
     // Minds (`.minds/**`) is reserved rtws state.
-    // It is hard-denied for general file tools; only dedicated `.minds/`-scoped tools (team-mgmt)
+    // It is hard-denied for general file tools; only dedicated `.minds/`-scoped tools (team_mgmt)
     // may bypass this via an internal-only flag.
     const isMinds = isMindsPath(relativePath);
     const allowMindsBypass = member.internal_allow_minds === true;
@@ -224,7 +224,7 @@ function hasWriteAccess(member, targetPath) {
         return false;
     }
     // Minds (`.minds/**`) is reserved rtws state.
-    // It is hard-denied for general file tools; only dedicated `.minds/`-scoped tools (team-mgmt)
+    // It is hard-denied for general file tools; only dedicated `.minds/`-scoped tools (team_mgmt)
     // may bypass this via an internal-only flag.
     const isMinds = isMindsPath(relativePath);
     const allowMindsBypass = member.internal_allow_minds === true;
@@ -290,11 +290,11 @@ function getAccessDeniedMessage(operation, targetPath, language = 'en') {
         lines.push('');
         if (language === 'zh') {
             lines.push(`- 说明：\`.minds/\` 是 rtws（运行时工作区）的“团队配置/记忆/资产”目录，通用文件工具无法读写（硬编码无条件拒绝）。`);
-            lines.push(`- 提示：若团队配置了 \`team-mgmt\` 工具集，请使用其中工具（\`team_mgmt_*\`）代管；若未配置或你不具备权限，请诉请具备 \`team-mgmt\` 权限的成员/团队管理员成员代管。`);
+            lines.push(`- 提示：若团队配置了 \`team_mgmt\` 工具集，请使用其中工具（\`team_mgmt_*\`）代管；若未配置或你不具备权限，请诉请具备 \`team_mgmt\` 权限的成员/团队管理员成员代管。`);
         }
         else {
             lines.push(`- Note: \`.minds/\` stores rtws (runtime workspace) team config/memory/assets and is hard-denied for general file tools.`);
-            lines.push(`- Hint: If your team configured the \`team-mgmt\` toolset, use its tools (\`team_mgmt_*\`); otherwise (or if you lack access), tellask a team-admin / a member with \`team-mgmt\` access to manage it for you.`);
+            lines.push(`- Hint: If your team configured the \`team_mgmt\` toolset, use its tools (\`team_mgmt_*\`); otherwise (or if you lack access), tellask a team-admin / a member with \`team_mgmt\` access to manage it for you.`);
         }
     }
     if (isRootDialogsPath(targetPath)) {

package/dist/agent-priming.js

@@ -138,6 +138,7 @@ async function emitSyntheticTellaskCall(dlg, payload) {
                 callName: payload.callName,
                 callId,
                 mentionList,
+                sessionSlug: payload.callName === 'tellask' ? payload.sessionSlug?.trim() : undefined,
                 tellaskContent: payload.tellaskContent,
             });
             return {

package/dist/dialog.js

@@ -519,6 +519,7 @@ class Dialog {
             msgId: options.msgId,
             grammar: options.grammar,
             userLanguageCode: options.userLanguageCode ?? this._lastUserLanguageCode,
+            q4hAnswerCallIds: options.q4hAnswerCallIds,
         };
         this._updatedAt = (0, time_1.formatUnifiedTimestamp)(new Date());
     }
@@ -670,8 +671,8 @@ class Dialog {
     async updateQuestions4Human(questions) {
         return await this.dlgStore.updateQuestions4Human(this, questions);
     }
-    async persistUserMessage(content, msgId, grammar, userLanguageCode) {
-        return await this.dlgStore.persistUserMessage(this, content, msgId, grammar, userLanguageCode);
+    async persistUserMessage(content, msgId, grammar, userLanguageCode, q4hAnswerCallIds) {
+        return await this.dlgStore.persistUserMessage(this, content, msgId, grammar, userLanguageCode, q4hAnswerCallIds);
     }
     async persistAgentMessage(content, genseq, type, provider_data) {
         return await this.dlgStore.persistAgentMessage(this, content, genseq, type, provider_data);
@@ -1047,7 +1048,7 @@ class DialogStore {
     /**
      * Persist a user message to storage
      */
-    async persistUserMessage(_dialog, _content, _msgId, _grammar, _userLanguageCode) { }
+    async persistUserMessage(_dialog, _content, _msgId, _grammar, _userLanguageCode, _q4hAnswerCallIds) { }
     /**
      * Persist an assistant message to storage
      */

package/dist/docs/design.md

@@ -554,7 +554,7 @@ dominds dialog start --taskdoc-path tasks/auth-system.tsk
 - Requirements evolve through `change_mind` operations
 - rtws hard rules:
   - `*.tsk/**` is encapsulated Taskdoc state and is hard-denied for all general file tools.
-  - `.minds/**` is reserved rtws state (team config/memory/assets) and is hard-denied for all general file tools; manage it via dedicated tools like `team-mgmt`.
+  - `.minds/**` is reserved rtws state (team config/memory/assets) and is hard-denied for all general file tools; manage it via dedicated tools like `team_mgmt`.
   - DevOps context: ad-hoc temp scripts are a taboo. If a tool script is needed, align with teammates and the human, then formalize it in the rtws before use.
 
 **Collaboration Example**:

package/dist/docs/design.zh.md

@@ -552,7 +552,7 @@ dominds dialog start --taskdoc-path tasks/auth-system.tsk
 - 要求通过 `change_mind` 操作演变
 - rtws 硬性规则：
   - `*.tsk/**` 是封装的差遣牒状态，所有通用文件工具都硬性拒绝。
-  - `.minds/**` 是保留的 rtws 状态（团队配置/内存/资产），所有通用文件工具都硬性拒绝；通过 `team-mgmt` 等专用工具进行管理。
+  - `.minds/**` 是保留的 rtws 状态（团队配置/内存/资产），所有通用文件工具都硬性拒绝；通过 `team_mgmt` 等专用工具进行管理。
   - DevOps 场景：忌讳临时脚本。如需工具脚本，应与队友和人类对齐后，在 rtws 中正式设计/命名/规范化再使用。
 
 **协作示例：**

package/dist/docs/dialog-system.md

@@ -118,6 +118,7 @@ Frontend clients never drive dialogs. Instead, they:
 - Subscribe to the current dialog's PubChan for real-time updates
 - Receive events for messages, state changes, and UI indicators
 - Send user input via API endpoints (drive_dlg_by_user_msg, drive_dialog_by_user_answer)
+- Never maintain a full cached dialog corpus in frontend memory: keep only render-scope view data; fetch non-rendered nodes on demand, and drop collapsed subtrees so re-expand always refetches from backend
 
 All driving logic, resumption decisions, and state management remain purely backend concerns.
 

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

@@ -117,6 +117,7 @@
 - 订阅当前对话的 PubChan 以获取实时更新
 - 接收消息、状态变化和 UI 指标的事件
 - 通过 API 端点发送用户输入（drive_dlg_by_user_msg, drive_dialog_by_user_answer）
+- **绝不在前端维护任何全量（缓存）对话列表**：前端仅保留当前可渲染视图所需的数据；未渲染节点必须按需向后端请求，折叠后应丢弃其子节点内存并在下次展开时重拉
 
 所有驱动逻辑、恢复决策和状态管理仍然是纯粹的后端关注点。
 

package/dist/docs/memory-system.md

@@ -46,7 +46,7 @@ The same information can be categorized by “who needs to see it / who maintain
 team governance and team management are functions too.
 
 - Team-memory tools (`add_team_memory` / `replace_team_memory` / `drop_team_memory` / `clear_team_memory`) are typically granted only to a small subset of agents (governance roles).
-- Content under `rtws/.minds/` (including env notes) is typically editable only by agents with the **team-mgmt toolset**.
+- Content under `rtws/.minds/` (including env notes) is typically editable only by agents with the **team_mgmt toolset**.
 - If you don’t have the permission, the right move is: draft a patch-level proposal (content + rationale + impact) and tellask the responsible role agent to apply it, instead of leaving key agreements in chat or private reminders.
 
 ---
@@ -194,7 +194,7 @@ The goal for agents’ day-to-day work is not “write more docs”. It’s a lo
 3. **Maintain your working set (individual memory)**: compress token-worthy details into a tiny reminders set (1–3 items, prefer update-in-place).
 4. **Drop noise (when needed)**: when noise starts degrading attention and judgment, distill first, then `clear_mind` to start a new course.
 
-> Permission note: if you don’t have team-memory tools or the team-mgmt toolset, don’t skip “public declaration”. Draft a merge-ready update and ask the governance/team-mgmt role agent to apply it to `team_memory` or `.minds/**`.
+> Permission note: if you don’t have team-memory tools or the team_mgmt toolset, don’t skip “public declaration”. Draft a merge-ready update and ask the governance/team_mgmt role agent to apply it to `team_memory` or `.minds/**`.
 
 ### Where to write what (quick rules)
 

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

@@ -45,7 +45,7 @@ TL;DR：
 上述“集体记忆”并不意味着“任何智能体都能随意改”。Dominds 的一个核心原则就是**社会化分工**：连“团队治理/团队管理”本身也应被视为一种职能。
 
 - `team_memory` 的维护工具（`add_team_memory` / `replace_team_memory` / `drop_team_memory` / `clear_team_memory`）通常只会配备给**少部分智能体**（团队治理角色）。
-- `rtws/.minds/` 目录内容（包括 env 提示等）通常只有配备了 **team-mgmt 工具集**的智能体才有权限更改。
+- `rtws/.minds/` 目录内容（包括 env 提示等）通常只有配备了 **team_mgmt 工具集**的智能体才有权限更改。
 - 当你没有相应权限时，正确动作是：**起草修改提案（内容 + 理由 + 影响面）→ 诉请具备权限的职能智能体合并落地**，而不是把关键约定留在对话里或私有提醒项里。
 
 ---
@@ -193,7 +193,7 @@ TL;DR：
 3. **维护个人工作集（个体记忆）**：把仍在高频影响决策的细节压缩到少量提醒项（1–3 条，优先原地更新）。
 4. **清噪（必要时）**：当噪音开始影响注意力与判断力（造成误判/低质量决策），先提炼再 `clear_mind`，开启新一程。
 
-> 权限提示：如果你没有 `team_memory` 或 team-mgmt 权限，不要“跳过公开宣告”。请把建议写成可合并的补丁内容，然后诉请具备权限的治理/团队管理职能智能体更新 `team_memory` 或 `.minds/**`。
+> 权限提示：如果你没有 `team_memory` 或 team_mgmt 权限，不要“跳过公开宣告”。请把建议写成可合并的补丁内容，然后诉请具备权限的治理/团队管理职能智能体更新 `team_memory` 或 `.minds/**`。
 
 ### 写到哪里（快速规则）
 

package/dist/docs/team-mgmt-toolset.md

@@ -1,6 +1,6 @@
-# Team Management Toolset (`team-mgmt`)
+# Team Management Toolset (`team_mgmt`)
 
-Chinese version: [中文版](./team-mgmt-toolset.zh.md)
+Chinese version: [中文版](./team_mgmt-toolset.zh.md)
 
 This document specifies a dedicated **team management toolset** whose only job is managing the
 rtws’s “mindset” configuration files under `.minds/` (team roster, LLM providers, and agent
@@ -29,7 +29,7 @@ equivalent of the `ws_mod` toolset + unrestricted `read_dirs`/`write_dirs`), bec
 
 ## Migration Plan (Replacing legacy builtin team-manager knowledge)
 
-This document is a **design spec** for the new `team-mgmt` toolset. It is not something we should
+This document is a **design spec** for the new `team_mgmt` toolset. It is not something we should
 ever tell an agent to “look up” at runtime.
 
 Instead, the runtime “single source of truth” for team management guidance should be
@@ -75,9 +75,9 @@ This makes sense for “normal” agents, but it blocks the team manager from do
 - Providing general-purpose file editing across the repo.
 - Making `.minds/` broadly writable by default team members.
 
-## Proposed `team-mgmt` Toolset
+## Proposed `team_mgmt` Toolset
 
-The `team-mgmt` toolset mirrors a minimal subset of `fs`/`txt`, but **hard-scopes** all operations to
+The `team_mgmt` toolset mirrors a minimal subset of `fs`/`txt`, but **hard-scopes** all operations to
 `.minds/` and rejects anything outside.
 
 ### Naming Conventions (Human / UI)
@@ -124,7 +124,7 @@ Notes:
   - Reject paths containing `..`.
   - Reject any path that resolves outside `.minds/` after normalization.
 - Prefer an explicit allowlist over “anything in the rtws”.
-  - For `team-mgmt`, that explicit allowlist is `.minds/**` (including `.minds/memory/**`) so the
+  - For `team_mgmt`, that explicit allowlist is `.minds/**` (including `.minds/memory/**`) so the
     team manager can repair accidental corruptions made by other tools (even though `.minds/memory/**`
     already has dedicated `memory` / `team_memory` tools for normal use).
 - Require explicit `.minds/...` paths and validate them; do not support “implicitly scoped” paths
@@ -133,7 +133,7 @@ Notes:
 ### Why a dedicated toolset (instead of only `read_dirs` / `write_dirs`)?
 
 `read_dirs` / `write_dirs` are still valuable, but they are configured in `.minds/team.yaml`, which
-may not exist during bootstrap. A dedicated `team-mgmt` toolset:
+may not exist during bootstrap. A dedicated `team_mgmt` toolset:
 
 - Lets the team manager create `.minds/team.yaml` safely from “zero state”.
 - Keeps the scope bounded even if the member’s directory allow/deny lists are empty.
@@ -387,7 +387,7 @@ member_defaults:
     - ws_read
     - memory
   # Default posture: deny `.minds/` edits for normal members.
-  # (Team management should be done via `team-mgmt` tools, not general file tools.)
+  # (Team management should be done via `team_mgmt` tools, not general file tools.)
   no_read_dirs:
     - .minds/team.yaml
     - .minds/llm.yaml
@@ -426,7 +426,7 @@ Best practices:
 - Keep `.minds/team.yaml` ownership tight; only the team manager should be able to edit it.
 - Avoid repeating built-in constraints in `team.yaml`:
   - `*.tsk/**` (encapsulated Taskdocs) are hard-denied for all general file tools.
-  - `.minds/**` is hard-denied for general file tools; only the dedicated `team-mgmt` toolset can access it.
+  - `.minds/**` is hard-denied for general file tools; only the dedicated `team_mgmt` toolset can access it.
     Put these in `no_*` only when you need extra explicitness; they are enforced regardless.
 
 ## Managing `.minds/team/<member>/*.md` (agent minds)
@@ -460,8 +460,8 @@ Suggested structure:
 
 Preferred behavior for initial bootstrap:
 
-- The shadow `fuxi` instance should get `team-mgmt` (and the manual tool), not broad `ws_mod`.
-- The shadow `pangu` instance should get broad rtws toolsets (e.g. `ws_read`, `ws_mod`, `os`), but not `team-mgmt`.
+- The shadow `fuxi` instance should get `team_mgmt` (and the manual tool), not broad `ws_mod`.
+- The shadow `pangu` instance should get broad rtws toolsets (e.g. `ws_read`, `ws_mod`, `os`), but not `team_mgmt`.
 - After `.minds/team.yaml` is created, the team definition becomes the source of truth.
 
 This avoids needing to grant full rtws access to configure the team.
@@ -472,7 +472,7 @@ This avoids needing to grant full rtws access to configure the team.
   `member_defaults.model`.
 - **Provider not found**: Ensure `.minds/team.yaml` `provider` keys exist in merged provider config
   (`dominds/main/llm/defaults.yaml` + `.minds/llm.yaml`).
-- **Access denied when editing `.minds/`**: Intended for general file tools; use `team-mgmt` tools.
+- **Access denied when editing `.minds/`**: Intended for general file tools; use `team_mgmt` tools.
 - **MCP tools not visible in Tools view**:
   - Confirm `.minds/mcp.yaml` exists and is valid.
   - Open **Problems** and look for MCP-related errors.

package/dist/docs/team-mgmt-toolset.zh.md

@@ -1,6 +1,6 @@
-# 团队管理工具集（`team-mgmt`）
+# 团队管理工具集（`team_mgmt`）
 
-英文版：[English](./team-mgmt-toolset.md)
+英文版：[English](./team_mgmt-toolset.md)
 
 本文档指定了一个专用的**团队管理工具集**，其唯一职责是管理 rtws（运行时工作区）`.minds/` 下的"心智"配置文件（团队名单、LLM 提供商和智能体心智文件），而不授予广泛的运行时工作区访问权限。
 
@@ -23,7 +23,7 @@
 
 ## 迁移计划（替换传统的内置团队管理者知识）
 
-本文档是新的 `team-mgmt` 工具集的**设计规范**。这不是我们应该在运行时让智能体"查阅"的内容。
+本文档是新的 `team_mgmt` 工具集的**设计规范**。这不是我们应该在运行时让智能体"查阅"的内容。
 
 相反，运行时团队管理的"单一事实来源"应该是函数工具 `team_mgmt_manual` 的输出。
 
@@ -61,9 +61,9 @@
 - 提供跨仓库的通用文件编辑
 - 默认让 `.minds/` 可广泛写入
 
-## 提议的 `team-mgmt` 工具集
+## 提议的 `team_mgmt` 工具集
 
-`team-mgmt` 工具集镜像 `fs`/`txt` 的最小子集，但**硬作用域**所有操作到 `.minds/` 并拒绝任何外部操作。
+`team_mgmt` 工具集镜像 `fs`/`txt` 的最小子集，但**硬作用域**所有操作到 `.minds/` 并拒绝任何外部操作。
 
 ### 命名约定（人类 / UI）
 
@@ -104,12 +104,12 @@
   - 拒绝包含 `..` 的路径
   - 拒绝规范化后解析到 `.minds/` 之外的任何路径
 - 优先使用显式白名单而非" rtws 中的任何内容"
-  - 对于 `team-mgmt`，该显式白名单是 `.minds/**`（包括 `.minds/memory/**`），以便团队管理者可以修复其他工具造成的意外损坏（即使 `.minds/memory/**` 已有专用的 `memory` / `team_memory` 工具供正常使用）
+  - 对于 `team_mgmt`，该显式白名单是 `.minds/**`（包括 `.minds/memory/**`），以便团队管理者可以修复其他工具造成的意外损坏（即使 `.minds/memory/**` 已有专用的 `memory` / `team_memory` 工具供正常使用）
 - 需要显式的 `.minds/...` 路径并验证它们；不支持像 `team.yaml` 这样的"隐式作用域"路径
 
 ### 为什么需要专用工具集（而不是仅 `read_dirs` / `write_dirs`）？
 
-`read_dirs` / `write_dirs` 仍然很有价值，但它们配置在 `.minds/team.yaml` 中，在引导期间可能不存在。专用的 `team-mgmt` 工具集：
+`read_dirs` / `write_dirs` 仍然很有价值，但它们配置在 `.minds/team.yaml` 中，在引导期间可能不存在。专用的 `team_mgmt` 工具集：
 
 - 让团队管理者能够从"零状态"安全地创建 `.minds/team.yaml`
 - 即使成员的目录允许/拒绝列表为空，也保持作用域边界
@@ -335,7 +335,7 @@ member_defaults:
     - ws_read
     - memory
   # 默认姿态：拒绝普通成员的 `.minds/` 编辑
-  #（团队管理应通过 `team-mgmt` 工具完成，而非通用文件工具）
+  #（团队管理应通过 `team_mgmt` 工具完成，而非通用文件工具）
   no_read_dirs:
     - .minds/team.yaml
     - .minds/llm.yaml
@@ -372,7 +372,7 @@ members:
 - 保持 `.minds/team.yaml` 的所有权严格；只有团队管理者应该能够编辑它
 - 避免在 `team.yaml` 中重复内置约束：
   - `*.tsk/**`（封装的 Taskdocs）对所有通用文件工具被硬性拒绝
-  - `.minds/**` 对通用文件工具被硬性拒绝；只有专用的 `team-mgmt` 工具集可以访问它
+  - `.minds/**` 对通用文件工具被硬性拒绝；只有专用的 `team_mgmt` 工具集可以访问它
     - 只有当你需要额外的显式性时才将这些放入 `no_*`；无论如何都会强制执行
 
 ## 管理 `.minds/team/<member>/*.md`（智能体心智）
@@ -406,8 +406,8 @@ members:
 
 初始引导的首选行为：
 
-- 影子成员 `fuxi` 实例应该获得 `team-mgmt`（和手册工具），而不是广泛的 `ws_mod`
-- 影子成员 `pangu` 实例应该获得广泛的 rtws 工具集（例如 `ws_read`、`ws_mod`、`os`），但不获得 `team-mgmt`
+- 影子成员 `fuxi` 实例应该获得 `team_mgmt`（和手册工具），而不是广泛的 `ws_mod`
+- 影子成员 `pangu` 实例应该获得广泛的 rtws 工具集（例如 `ws_read`、`ws_mod`、`os`），但不获得 `team_mgmt`
 - 在创建 `.minds/team.yaml` 后，团队定义成为事实来源
 
 这避免了需要授予完整的 rtws 访问权限来配置团队。
@@ -416,7 +416,7 @@ members:
 
 - **"缺少必需的 provider/model"**：确保 `.minds/team.yaml` 有 `member_defaults.provider` 和 `member_defaults.model`
 - **找不到提供商**：确保 `.minds/team.yaml` 的 `provider` 键存在于合并的提供商配置中（`dominds/main/llm/defaults.yaml` + `.minds/llm.yaml`）
-- **编辑 `.minds/` 时访问被拒绝**：通用文件工具的预期行为；使用 `team-mgmt` 工具
+- **编辑 `.minds/` 时访问被拒绝**：通用文件工具的预期行为；使用 `team_mgmt` 工具
 - **MCP 工具在工具视图中不可见**：
   - 确认 `.minds/mcp.yaml` 存在且有效
   - 打开**问题**并查找 MCP 相关错误