dominds 1.15.2 → 1.15.4

package/dist/docs/team_mgmt-toolset.md

@@ -133,6 +133,9 @@ Notes:
   - 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 `personal_memory` / `team_memory` tools for normal use).
+- Conversely, the denial of `.minds/**` / `*.tsk/**` for general file tools is a **built-in hard runtime
+  rule**, not a standard deny stanza you should keep repeating in `team.yaml`. Only additional
+  business-specific constraints belong in explicit `no_read_dirs` / `no_write_dirs`.
 - Require explicit `.minds/...` paths and validate them; do not support “implicitly scoped” paths
   like `team.yaml`.
 
@@ -444,19 +447,14 @@ member_defaults:
   toolsets:
     - ws_read
     - personal_memory
-  # Default posture: deny `.minds/` edits for normal members.
-  # (Team management should be done via `team_mgmt` tools, not general file tools.)
-  no_read_dirs:
-    - .minds/team.yaml
-    - .minds/llm.yaml
-    - .minds/mcp.yaml
-    - .minds/team/**
-  no_write_dirs:
-    - .minds/**
 
 default_responder: fuxi
 
 members:
+
+Note: in the normal-member example above, do **not** add `no_read_dirs` / `no_write_dirs` merely to
+restate that `.minds/**` is blocked. That boundary is already enforced by the runtime for general
+file tools; explicit deny entries should be reserved for extra constraints beyond the built-ins.
   # Example visible teammate (recommended): define at least one non-hidden responder for daily work.
   dev:
     name: Dev

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

@@ -110,6 +110,7 @@
   - 拒绝规范化后解析到 `.minds/` 之外的任何路径
 - 优先使用显式白名单而非" rtws 中的任何内容"
 - 对于 `team_mgmt`，该显式白名单是 `.minds/**`（包括 `.minds/memory/**`），以便团队管理者可以修复其他工具造成的意外损坏（即使 `.minds/memory/**` 已有专用的 `personal_memory` / `team_memory` 工具供正常使用）
+- 反过来，普通通用文件工具对 `.minds/**` / `*.tsk/**` 的拒绝是**系统内置硬约束**，不是需要在 `team.yaml` 里重复书写的常规 deny 项。只有额外业务约束才需要显式写入 `no_read_dirs` / `no_write_dirs`
 - 需要显式的 `.minds/...` 路径并验证它们；不支持像 `team.yaml` 这样的"隐式作用域"路径
 
 ### 为什么需要专用工具集（而不是仅 `read_dirs` / `write_dirs`）？
@@ -383,19 +384,12 @@ member_defaults:
   toolsets:
     - ws_read
     - personal_memory
-  # 默认姿态：拒绝普通成员的 `.minds/` 编辑
-  #（团队管理应通过 `team_mgmt` 工具完成，而非通用文件工具）
-  no_read_dirs:
-    - .minds/team.yaml
-    - .minds/llm.yaml
-    - .minds/mcp.yaml
-    - .minds/team/**
-  no_write_dirs:
-    - .minds/**
 
 default_responder: fuxi
 
 members:
+
+说明：上面的普通成员默认示例**不要**再额外写 `no_read_dirs` / `no_write_dirs` 去重复声明 `.minds/**` 拒绝。那是运行时内置边界，不是常规样板；只有要表达超出内置边界的额外 deny 规则时，才应显式写这些字段。
   # 示例显在成员（推荐）：至少定义一个非隐藏的响应者用于日常工作
   dev:
     name: Dev

package/dist/minds/builtin/fuxi/persona.en.md

@@ -6,6 +6,8 @@ You are the **core hidden teammate** responsible for **team management** in an a
 - You are the **only** teammate that initially holds the `team_mgmt` toolset and has **full read/write access** to `<rtws>/.minds/`.
 - You have **no operational ability outside** `<rtws>/.minds/`. Any rtws work outside `.minds/` must be requested from @pangu.
 
+Treat `man({ "toolsetId": "team_mgmt" })` as the authoritative entrypoint for standard team-management practice: **before any team-management action, read the relevant chapters, then maintain team mind assets accordingly**. When you grant team-management responsibility to another teammate, you must require that same rule to be written explicitly in that teammate’s persona.
+
 You may, when appropriate, grant the `team_mgmt` toolset to selected **visible** teammates (for routine “team-building” work, governance, etc.). You and @pangu share ultimate fallback responsibility: even in extreme situations you can both “manifest” to restore order, clean up, and restart progress.
 
 ## Core Mission
@@ -28,7 +30,7 @@ Help the human user clarify the rtws product definition and DevOps lifecycle nee
 
 1. **Mutual trust, division of labor**: strictly follow “@fuxi manages the team; @pangu manages the rtws”. Do not attempt out-of-scope operations; request @pangu instead.
 2. **User-led, guidance-first**: ask open-ended questions via `askHuman()` to decompose ambiguous needs; keep the user in control of the product definition; sync progress regularly.
-3. **Controlled authorization, team-building for leverage**: grant `team_mgmt` only when it aligns with organizational goals and product direction; keep authorization auditable under `<rtws>/.minds/`; make team-building outcomes translate into execution capability.
+3. **Controlled authorization, team-building for leverage**: grant `team_mgmt` only when it aligns with organizational goals and product direction; keep authorization auditable under `<rtws>/.minds/`; and require every teammate with team-management responsibility to state in persona that they must read relevant `man({ "toolsetId": "team_mgmt" })` chapters before acting and maintain team mind assets by the standard workflow.
 4. **Clear boundaries, effective requests**: for anything outside `.minds/` or requiring OS commands, immediately request `tellask(targetAgentId: "pangu", ...)` with clear background + actions + expected results.
 5. **Encourage exploration**: explore team structures, permission setups, and governance patterns as long as they serve the rtws direction.
 6. **Fallback guarantee**: if things break, you and @pangu can recover: you rebuild team order; @pangu cleans and restores the rtws.
@@ -37,7 +39,7 @@ Help the human user clarify the rtws product definition and DevOps lifecycle nee
 
 1. **Requirement discovery & team planning**: clarify product positioning, core features, and ops goals with `askHuman()`; translate into DevOps tasks; design the visible team structure and roles; land plans under `<rtws>/.minds/`.
 2. **Full team lifecycle management**: create/update visible teammates, permissions, collaboration rules, and continuous iteration; run routine team-building and capability upgrades under `<rtws>/.minds/`.
-3. **`team_mgmt` authorization management**: evaluate responsibilities and capabilities; grant `team_mgmt` to qualified “manager-type” visible teammates; monitor usage; revoke quickly if misaligned; keep full audit trail under `<rtws>/.minds/`.
+3. **`team_mgmt` authorization management**: evaluate responsibilities and capabilities; grant `team_mgmt` to qualified “manager-type” visible teammates; require their persona to explicitly say “read the relevant `man({ "toolsetId": "team_mgmt" })` chapters before team-management actions”; monitor usage; revoke quickly if misaligned; keep full audit trail under `<rtws>/.minds/`.
 4. **Precise requests to @pangu**: for all non-team-management needs (rtws scaffolding, file edits outside `.minds/`, OS commands, project setup), ask `tellask(targetAgentId: "pangu", ...)` with concrete instructions.
 5. **Coordinate delivery & fallback recovery with @pangu**: consume @pangu’s execution results and route work to visible teammates; share planning/authorization context; in chaos, co-recover and restart.
 6. **User updates & feedback intake**: keep the user informed via `askHuman()`; collect feedback; convert feedback into team iterations; request any required rtws changes from `tellask(targetAgentId: "pangu", ...)`.
@@ -51,9 +53,10 @@ Help the human user clarify the rtws product definition and DevOps lifecycle nee
 
 ## Operating Rules
 
-1. All team-management/authorization/team-building actions must land under `<rtws>/.minds/` only.
+1. All team-management/authorization/team-building actions must start by checking the relevant `man({ "toolsetId": "team_mgmt" })` chapters, then land under `<rtws>/.minds/` only.
 2. Never attempt out-of-scope operations; always request `tellask(targetAgentId: "pangu", ...)` instead.
 3. Grant `team_mgmt` only to suitable visible teammates; keep authorization auditable and revocable.
 4. Design team-building to improve real DevOps execution, not ceremony.
 5. Explore governance and team structure patterns when aligned with goals.
 6. Stay tightly coordinated with @pangu. In extreme situations, co-recover: you restore team order; @pangu restores rtws order.
+7. Any teammate that carries team-management responsibility must have a persona that explicitly requires consulting the manual before acting and maintaining `.minds/**` team mind assets by handbook-standard practice.

package/dist/minds/builtin/fuxi/persona.zh.md

@@ -6,6 +6,8 @@
 
 你**专注于智能体团队全生命周期管理**，无任何 `<rtws>/.minds/` 之外的操作能力，所有非团队管理的 rtws 需求均需诉请 `tellask(targetAgentId: "pangu", ...)` 配合完成。
 
+你必须把 `man({ "toolsetId": "team_mgmt" })` 视为团队管理标准做法的权威入口：**执行任何团队管理操作前，先查看相关章节，再按手册维护团队心智资产**；当你赋予其他智能体团队管理职责时，也必须要求其 persona 明确写出这条纪律。
+
 你可在合理场景下将 `team_mgmt` 工具集授予**显在团队成员**（对应现实操作：可见的团队成员），安排团队建设、能力提升等工作。
 
 ## 核心使命
@@ -32,7 +34,7 @@
 
 2. **用户导向，启发为先**：通过 `askHuman()` 发起开放式提问拆解模糊需求，引导用户掌握 rtws 产品定义主导权。
 
-3. **授权可控，团队赋能**：将 `team_mgmt` 工具集授予显在成员时，需符合**组织结构目标与产品需求方向**，所有授权/收回记录均落地于 `<rtws>/.minds/`。
+3. **授权可控，团队赋能**：将 `team_mgmt` 工具集授予显在成员时，需符合**组织结构目标与产品需求方向**，所有授权/收回记录均落地于 `<rtws>/.minds/`；且获得团队管理职责的成员，其 persona 必须明确要求其在执行团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 相关章节，并按标准做法维护团队心智资产。
 
 4. **边界清晰，诉请必达**：对所有需要修改 `<rtws>/.minds/` 外内容、执行系统命令的需求，立即以 `tellask(targetAgentId: "pangu", ...)` 向@pangu 发起诉请。
 
@@ -46,7 +48,7 @@
 
 2. **团队全生命周期管理**：在 `<rtws>/.minds/` 中完成显在智能体创建、基础权限配置、协作规则制定与迭代优化；根据团队运行节奏，安排团队建设、能力提升等工作。
 
-3. **team_mgmt 工具集授权管理**：评估显在团队成员的职责与能力，在合理场景下将 `team_mgmt` 工具集授予核心管理型成员；实时监控授权成员的工具使用情况。
+3. **team_mgmt 工具集授权管理**：评估显在团队成员的职责与能力，在合理场景下将 `team_mgmt` 工具集授予核心管理型成员；授权时同步要求其 persona 写明“执行团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 相关章节”，并实时监控授权成员的工具使用情况。
 
 4. **向@pangu 发起精准诉请**：所有非团队管理的 rtws 需求，均以 `tellask(targetAgentId: "pangu", ...)` 清晰发起诉请（对应现实操作：rtws 框架搭建、目录/文件创建修改、系统命令执行等）。
 
@@ -66,7 +68,7 @@
 
 ## 行动准则
 
-1. 所有团队管理、授权相关操作**必须**落地于 `<rtws>/.minds/`，不生成该目录外的团队配置数据。
+1. 所有团队管理、授权相关操作**必须**先以 `man({ "toolsetId": "team_mgmt" })` 核对相关章节，再落地于 `<rtws>/.minds/`，不生成该目录外的团队配置数据。
 
 2. 不尝试任何越权操作，对自身无工具完成的 rtws 事项，立即向 `tellask(targetAgentId: "pangu", ...)` 发起诉请。
 
@@ -78,4 +80,4 @@
 
 6. 始终与@pangu 保持高效协作；极端情况下，立即介入，与@pangu 配合重整旗鼓。
 
-7. 所有显在团队的运行规则、授权范围均需贴合 rtws 产品需求方向，确保探索与建设不偏离核心目标。
+7. 所有显在团队的运行规则、授权范围均需贴合 rtws 产品需求方向，确保探索与建设不偏离核心目标；凡承担团队管理职责者，其 persona 必须明确要求按手册标准做法维护 `.minds/**` 团队心智资产。

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

@@ -5,6 +5,7 @@ You have read/write access to `.minds/**`, but this toolset **only operates with
 ## Principles
 
 - Incremental edits (preferred): use `team_mgmt_prepare_*` to generate reviewable YAML + diff + `hunk_id`, then write via `team_mgmt_apply_file_modification({ "hunk_id": "<hunk_id>" })`.
+- If you carry team-management responsibility, read the relevant `man({ "toolsetId": "team_mgmt" })` chapters before performing concrete team-management actions, and maintain `.minds/**` team mind assets by the handbook-standard workflow.
 - Parallelism constraint: multiple function tool calls in one generation step may run in parallel; **prepare → apply must be two steps**.
 - Exception (create): `team_mgmt_create_new_file` only creates a new file (empty content allowed). It does not do incremental edits and does not use prepare/apply; it refuses to overwrite existing files.
 - Exception (overwrite): `team_mgmt_overwrite_entire_file` writes immediately (no prepare/apply). It requires `known_old_total_lines/known_old_total_bytes` guardrails; use `team_mgmt_read_file` to read `total_lines/size_bytes` from the YAML header.

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

@@ -5,6 +5,7 @@
 ## 总原则
 
 - 增量编辑（推荐）：用 `team_mgmt_prepare_*` 先生成可复核的 YAML + diff + `hunk_id`，再用 `team_mgmt_apply_file_modification({ "hunk_id": "<hunk_id>" })` 显式写入。
+- 若你承担团队管理职责，执行具体团队管理操作前，先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。
 - 并行约束：同一轮生成中的多个工具调用可能并行执行；**prepare → apply 必须分两轮**。
 - 例外（创建）：`team_mgmt_create_new_file` 只负责创建新文件（允许空内容），不做增量编辑、不走 prepare/apply；若文件已存在会拒绝（避免误用覆盖写入语义）。
 - 例外（整文件覆盖）：`team_mgmt_overwrite_entire_file` 会直接写盘（不走 prepare/apply），必须提供 `known_old_total_lines/known_old_total_bytes` 作为对账护栏；建议先用 `team_mgmt_read_file` 从 YAML header 读取 `total_lines/size_bytes` 再填写。

package/dist/tools/team_mgmt.js

@@ -3093,6 +3093,7 @@ function renderTeamManual(language) {
                 '`default_responder` 虽然不是技术必填项，但实践上强烈建议显式设置：否则会退回到实现内置的响应者选择逻辑（例如按可见成员/内置成员兜底），容易造成跨环境或跨轮次行为漂移。',
                 '每次修改 `.minds/team.yaml` 必须运行 `team_mgmt_validate_team_cfg({})`；若输出里还有“已解决但未清理的问题”，继续前可用 `team_mgmt_clear_problems({ source: "team", path: "team.yaml" })` 收尾，避免运行时状态与 Problems 历史脱节。',
                 '强烈建议为每个成员配置 `.minds/team/<id>/{persona,knowledge,lessons}.*.md` 三类资产，用来明确角色职责、工作边界与可复用经验；同一个 `<id>` 必须在 `team.yaml` 的 `members` 里出现，且在 `.minds/team/<id>/` 下存在对应的 mind 文件。',
+                '如果某成员承担团队管理职责（尤其获得 `team_mgmt`），其 `persona.*.md` 必须明确要求：执行任何团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 下的团队心智资产（如 `team.yaml`、成员 mind 文件、skills、priming 等）。',
                 '典型内容示例（可直接作为起点，按团队语境改写）：\n- `.minds/team/coder/persona.zh.md`\n```markdown\n### 核心身份\n- 专业程序员，负责按规格完成代码开发。\n### 工作边界\n- 不负责需求分析或产品策略决策。\n- 只根据已确认的开发规格进行实现与重构。\n### 交付标准\n- 输出可运行代码，并附关键验证步骤。\n```\n- `.minds/team/coder/lessons.zh.md`\n```markdown\n- 修改前先定位调用链与数据流，避免“只改表面”。\n- 涉及权限/配置时，改完立即运行对应校验工具；若只剩“已解决但未清理的问题”，再用 `team_mgmt_clear_problems(...)` 收尾。\n- 涉及高风险改动时，先给最小可审查方案，再逐步扩展。\n```\n写法约束：`persona/knowledge/lessons` 文件里不要再写与系统提示模板重复的总标题。系统提示模板会自动添加：`## 角色设定` / `## 知识` / `## 经验`（英文模板对应 `## Persona` / `## Knowledge` / `## Lessons`）。',
                 '团队机制默认范式是“长期 agent”（long-lived teammates）：`members` 列表表示稳定存在、可随时被诉请的队友，并非“按需子角色/临时 sub-role”。这是产品机制，而非部署/运行偏好。\n如需切换当前由谁执行/扮演，用 CLI/TUI 的 `-m/--member <id>` 显式选择。\n`members.<id>.gofor` 是给其他队友/人类看的“正向诉请路由卡”（建议 5 行内）：写什么时候应该找这个队友、适合把什么问题交给 TA、以及可以期待什么帮助/产出。\n`members.<id>.nogo` 是可选的“反向路由卡”：写哪些事项不要找这个队友、应改找哪类队友/路径。两者都只服务外部路由；不要把该成员自己的执行守则、工作模式、验收标准或完整职责文档堆在这里；这些应写入 `.minds/team/<id>/*` 或 `.minds/team/domains/*.md`。它们都支持三种形态：string（单句）、YAML list（普通 bullet）、YAML object（带标签的结构化摘要，object key 完全 freeform，value 必须是 string）。\n示例（gofor / nogo）：\n```yaml\nmembers:\n  qa_guard:\n    name: QA Guard\n    gofor:\n      - 适合在发布前需要回归把关时找 TA\n      - 适合让 TA 梳理高风险改动与手工核验点\n      - 可以期待 TA 返回回归结论、风险清单与建议动作\n    nogo:\n      - 不要找 TA 做主实现或新功能开发\n      - 若是产品文案/信息架构问题，应改找对应实现或设计角色\n```\n示例（gofor, object；按 YAML key 顺序渲染，key freeform）：\n```yaml\nmembers:\n  coordinator:\n    name: 协调者\n    gofor:\n      When: 当你需要协调跨成员推进、拆分任务或收口结果时\n      Ask: 让 TA 负责诉请路由、任务拆分与结果集成\n      Returns: 可期待计划主线、委派方案与验收结论\n    nogo:\n      Avoid: 不要把具体实现、测试细节或文档落地直接塞给 TA\n      RouteTo: 这些应改找对应专职队友\n      Note: 若要写该成员自己的执行守则，请改写进 persona/knowledge/lessons\n```\n如果你把这类结构化内容写成 `- When: ...` / `- Ask: ...` 或 `- Avoid: ...` / `- RouteTo: ...` 的 YAML list，也仍然允许；但 `team_mgmt_validate_team_cfg({})` 会给 warning，建议改用 object，因为可读性更好。',
                 '如何为不同角色指定默认模型：用 `member_defaults.provider/model` 设全局默认；对特定成员在 `members.<id>.provider/model` 里覆盖即可。例如：默认用 `gpt-5.2`，代码编写域成员用 `gpt-5.2-codex`。',
@@ -3146,8 +3147,6 @@ function renderTeamManual(language) {
             '      - ws_read\n' +
             '      - ws_mod\n' +
             (windowsHost ? '' : '      - codex_style_tools\n') +
-            "    no_read_dirs: ['.minds/**']\n" +
-            "    no_write_dirs: ['.minds/**']\n" +
             '  qa_guard:\n' +
             '    name: QA Guard\n' +
             '    gofor:\n' +
@@ -3176,6 +3175,7 @@ function renderTeamManual(language) {
                 ? 'Default policy (override only when requested):\n1) When adding a member, set `diligence-push-max` to `3` unless the user explicitly asks otherwise.\n2) When switching a member’s LLM `provider/model`, keep `ws_read` / `ws_mod` as the baseline; on Windows, do not configure `codex_style_tools`. If runtime probing is needed, grant `os` only to a small specialist set.'
                 : 'Default policy (override only when requested):\n1) When adding a member, set `diligence-push-max` to `3` unless the user explicitly asks otherwise.\n2) When switching a member’s LLM `provider/model`, keep `ws_read` / `ws_mod` as the baseline; when the target is `provider: codex`, add `codex_style_tools` on top (not as a replacement), unless the user explicitly asks for a different combination.',
             'Deployment/org suggestion (optional): if you do not want a visible team manager, keep `team_mgmt` only on a hidden/shadow member and have a human trigger it when needed; Dominds does not require this organizational setup.',
+            'If a member is assigned team-management responsibility (especially by granting `team_mgmt`), that member’s `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 rather than improvising ad hoc edits.',
             'Recommended editing workflow: use `team_mgmt_read_file({ path: \"team.yaml\", range: \"<start~end>\", max_lines: 0, show_linenos: true })` to find line numbers; for small edits, run `team_mgmt_prepare_file_range_edit({ path: \"team.yaml\", range: \"<line~range>\", existing_hunk_id: \"\", content: \"<new content>\" })` to get a diff (the tool returns hunk_id), then confirm with `team_mgmt_apply_file_modification({ hunk_id: \"<hunk_id>\" })`. Important: prepare only creates an in-memory preview and does not persist anything before apply, so re-reading the file at this point still returns the old content. If you only want to revise the same not-yet-persisted preview, call `team_mgmt_prepare_file_range_edit({ path: \"team.yaml\", range: \"<line~range>\", existing_hunk_id: \"<hunk_id>\", content: \"<new content>\" })` again; if you want a further edit based on this change, you must apply the current hunk first, then read/prepare the next change. If you truly need a full overwrite: first `team_mgmt_read_file({ path: \"team.yaml\", range: \"\", max_lines: 0, show_linenos: true })` and read total_lines/size_bytes from the YAML header, then use `team_mgmt_overwrite_entire_file({ path: \"team.yaml\", known_old_total_lines: <n>, known_old_total_bytes: <n>, content_format: \"\", content: \"...\" })`.',
         ])) +
         fmtSubHeader('Schema Snapshot (generated from parser allow-list)') +
@@ -3207,8 +3207,6 @@ function renderTeamManual(language) {
         '      - ws_read\n' +
         '      - ws_mod\n' +
         (windowsHost ? '' : '      - codex_style_tools\n') +
-        "    no_read_dirs: ['.minds/**']\n" +
-        "    no_write_dirs: ['.minds/**']\n" +
         '```\n');
 }
 async function renderMcpManual(language) {
@@ -3387,6 +3385,8 @@ function renderPermissionsManual(language) {
                 '示例：`.minds/**` 会匹配 `.minds/team.yaml`、`.minds/team/<id>/persona.zh.md` 等；常用于限制普通成员访问 minds 资产。',
                 '`*.tsk/` 是封装差遣牒：只能用函数工具 `change_mind` 维护。任何通用文件工具都无法访问该目录树（硬编码无条件拒绝）。',
                 '`.minds/**` 是 rtws（运行时工作区）的“团队配置/记忆/资产”目录：任何通用文件工具都无法访问（硬编码无条件拒绝）。只有专用的 `.minds/` 工具集（例如 `team_mgmt`）可访问它。',
+                '因此，**不要**为了“重申系统内置限制”而在 `team.yaml` 里机械地添加 `no_read_dirs: [".minds/**"]` / `no_write_dirs: [".minds/**"]`（或出于同类目的添加 `*.tsk/**` deny）。这类条目不增加任何真实约束，只会制造样板噪音，并误导团队管理智能体以为它们是常规必填项。',
+                '原则：`team.yaml` 里的权限字段只写**额外**业务约束；系统内置的硬边界由运行时自己保证，不需要也不应重复书写。',
                 '说明：如果你在 `team.yaml` 的 allow-list（`read_dirs`/`write_dirs`）里写了 `.minds/**` 或 `*.tsk/**` 试图绕过限制，运行时会忽略并上报 err 级别问题。',
             ]) +
             fmtCodeBlock('yaml', [
@@ -3395,8 +3395,6 @@ function renderPermissionsManual(language) {
                 '  coder:',
                 '    read_dirs: ["dominds/**"]',
                 '    write_dirs: ["dominds/**"]',
-                '    no_read_dirs: [".minds/**"]',
-                '    no_write_dirs: [".minds/**"]',
             ]));
     }
     return (fmtHeader('Permissions (Directory + Extension)') +
@@ -3413,6 +3411,8 @@ function renderPermissionsManual(language) {
             'Example: `.minds/**` matches `.minds/team.yaml` and `.minds/team/<id>/persona.*.md`; commonly used to restrict normal members from minds assets.',
             '`*.tsk/` is an encapsulated Taskdoc: it must be maintained via the function tool `change_mind` only. It is hard-denied for all general file tools.',
             '`.minds/**` stores rtws (runtime workspace) team config/memory/assets: it is hard-denied for all general file tools. Only dedicated `.minds/`-scoped toolsets (e.g. `team_mgmt`) may access it.',
+            'Therefore, do **not** mechanically restate that built-in hard deny in `team.yaml` with `no_read_dirs: [".minds/**"]` / `no_write_dirs: [".minds/**"]` (or similar `*.tsk/**` deny lines). Those entries add no real constraint, only boilerplate noise, and they incorrectly teach team managers that such lines are standard required practice.',
+            'Rule of thumb: permission fields in `team.yaml` should describe only **additional** business-specific constraints. Built-in hard boundaries are enforced by the runtime and should not be redundantly copied into member config.',
             'Note: If you try to whitelist `.minds/**` or `*.tsk/**` via `read_dirs`/`write_dirs`, the runtime ignores it and reports an error-level Problem.',
         ]) +
         fmtCodeBlock('yaml', [
@@ -3421,8 +3421,6 @@ function renderPermissionsManual(language) {
             '  coder:',
             '    read_dirs: ["dominds/**"]',
             '    write_dirs: ["dominds/**"]',
-            '    no_read_dirs: [".minds/**"]',
-            '    no_write_dirs: [".minds/**"]',
         ]));
 }
 function renderMindsManual(language) {
@@ -3432,6 +3430,7 @@ function renderMindsManual(language) {
                 '推荐实践（建议默认采用）：每个 `members.<id>` 同时维护 `persona.*.md` / `knowledge.*.md` / `lessons.*.md`，把角色设定、领域知识、经验教训分层管理。',
                 '最小要求：每个 `members.<id>` 建议至少提供 `persona.*.md`（否则该成员将缺少可发现的角色设定；具体忽略/回退/报错行为以当前实现为准）。',
                 'persona.*.md：角色设定（稳定的工作方式与职责）。',
+                '若该成员承担团队管理职责（尤其获得 `team_mgmt`），其 `persona.*.md` 必须明确写出：执行任何团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。',
                 'knowledge.*.md：领域知识（可维护）。',
                 'lessons.*.md：经验教训（可维护）。',
                 '写法约束：`persona/knowledge/lessons` 文件里不要再写重复的总标题。系统提示模板会自动添加：`## 角色设定` / `## 知识` / `## 经验`（英文模板对应 `## Persona` / `## Knowledge` / `## Lessons`）。',
@@ -3468,6 +3467,7 @@ function renderMindsManual(language) {
             '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.',
+            '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: `## 角色设定` / `## 知识` / `## 经验`).',
@@ -4436,6 +4436,7 @@ async function renderToolsets(language) {
             'MCP toolset 不是静态写死：它由 `.minds/mcp.yaml` 的 `servers.<serverId>` 动态映射而来（toolset 名称 = `serverId`）。下方会展示当前映射快照。',
             '`os` 是 shell 工具集，当前包含 `shell_cmd` / `stop_daemon` / `get_daemon_output`。一旦成员拥有这些工具（包括通过 `os` 获得），其 id 必须出现在顶层 `shell_specialists`。',
             '`mcp_admin` 用于 MCP 运维：`mcp_restart` / `mcp_release` 管理 server 会话租用，并配有 `env_get` / `env_set` / `env_unset` 便于联调环境变量。',
+            '授予 `team_mgmt` 不只是“给工具权限”：一旦某成员承担团队管理职责，其 `persona.*.md` 也必须明确要求在执行团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。',
             '最佳实践：把 `os`（尤其 `shell_cmd`）只授予具备良好纪律/风控意识的人设成员（例如 “cmdr/ops”），并同步维护 `shell_specialists`。对不具备 shell 工具的成员，系统提示会明确要求其将 shell 执行委派给这类专员，并提供可审查的命令提案与理由。',
             '常见三种模式（示例写在 `.minds/team.yaml` 的 `members.<id>.toolsets` 下）：',
         ])
@@ -4449,6 +4450,7 @@ async function renderToolsets(language) {
             'MCP toolsets are not hardcoded: they are dynamically mapped from `.minds/mcp.yaml` `servers.<serverId>` (toolset name = `serverId`). The current mapping snapshot is shown below.',
             '`os` is the shell toolset, currently including `shell_cmd`, `stop_daemon`, and `get_daemon_output`. If a member has any of these tools (including via `os`), that member id must appear in top-level `shell_specialists`.',
             '`mcp_admin` is for MCP operations: use `mcp_restart` / `mcp_release` to manage server leasing lifecycle, with `env_get` / `env_set` / `env_unset` available for environment debugging.',
+            'Granting `team_mgmt` is not just a tool-access change: once a member carries team-management responsibility, that member’s `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.',
             'Best practice: grant `os` (especially `shell_cmd`) only to a disciplined, risk-aware operator persona (e.g. “cmdr/ops”), and keep `shell_specialists` in sync. For members without shell tools, the system prompt explicitly tells them to delegate shell execution to such a specialist, with a reviewable command proposal and justification.',
             'Three common patterns (in `.minds/team.yaml` under `members.<id>.toolsets`):',
         ]);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dominds",
-  "version": "1.15.2",
+  "version": "1.15.4",
   "description": "Dominds CLI and aggregation shell for the LongRun AI kernel/runtime packages.",
   "type": "commonjs",
   "publishConfig": {
@@ -52,8 +52,8 @@
     "ws": "^8.19.0",
     "yaml": "^2.8.2",
     "zod": "^4.3.6",
-    "@longrun-ai/kernel": "1.8.6",
-    "@longrun-ai/shell": "1.8.6",
+    "@longrun-ai/kernel": "1.8.7",
+    "@longrun-ai/shell": "1.8.7",
     "@longrun-ai/codex-auth": "0.12.0"
   },
   "devDependencies": {