dominds 1.3.1 → 1.4.2

package/dist/docs/kernel-app-architecture.zh.md

@@ -1,285 +0,0 @@
-# Kernel–App 架构（原型 v0.1）
-
-English version: [English](./kernel-app-architecture.md)
-
-## 范围与目标
-
-本文件描述 Dominds 的 Kernel–App 分离原型设计，覆盖：
-
-- 两级 namespace（kernel 外层 / app 内层）与解析规则
-- app install json（`app --json`）扩展字段
-- export/import 语义与冲突处理
-- app defunc 语义
-- app 集成手册（`app_integration_manual`）
-- app 语言约束（work/ui language 与 i18n）
-- `<rtws>/.apps/<app-id>/team.yaml` 增量覆盖 DSL
-
-本原型的代码实现用于 **概念与功能验证**；本文件是“综合方案推进”的主载体（可被后续实现/迁移/评审稳定引用）。
-
-## 非目标
-
-- 2.x 前不引入协议/schema 版本与兼容策略
-- 2.x 前不引入 sandbox 隔离
-- run control 大幅扩展不在本文讨论（将单独出专项文档）
-
-## 核心概念
-
-- Kernel registry 维持当前 dominds 状态，内置能力将逐步迁出为独立 app。
-- 每个 app 维护独立 registry，**app 本地优先、允许同名覆盖**。
-- app 不会把对象注册到 kernel registry。
-- app 之间互相隔离，只有通过 export/import 显式交换对象。
-
-## Identity 与解析（Resolution）
-
-### 名称空间
-
-- 两级 scope：`kernel` 与 `app`。
-- 在“运行时解析”中，对象的 **短 ID**（例如 `toolsetId`、`memberId`、`toolName`）仍然以当前 kernel 的习惯用法为主。
-- 在“日志/诊断/Problems/文档”中，需要可唯一指认来源，因此引入 **Qualified Id**（仅用于诊断/显示，不强制写入 wire 协议）：
-  - `kernel:<name>`
-  - `app:<appId>:<name>`
-
-### 解析顺序（app 内）
-
-对任意解析请求（tool/toolset/member），在 app 内的解析顺序固定为：
-
-1. `local(app)`（含：app 自身注册 + import 进来的对象）
-2. `kernel`
-
-说明：
-
-- **允许同名覆盖**仅发生在 `local(app)` 覆盖 `kernel` 的场景。
-- App 之间互不覆盖；若 import 导致 `local(app)` 内部同名冲突，则 app 置为 defunc。
-
-## App install json（`app --json`）
-
-在现有 `DomindsAppInstallJsonV1` 基础上新增：
-
-- `depends?: [{ appId: string; versionRange: string }]`
-- `exports?: { members?: string[]; toolsets?: string[] }`
-
-约定：
-
-- `exports` 为空表示不允许被 import。
-- `exports` 可以列出多个对象，但 import 的最小单元固定为 **单个成员 / 单个工具集**（一次 import 指向一个 ID）。
-- `exports` 中的成员必须来自 `contributes.teammatesYamlRelPath` 的成员定义。
-- `exports` 中的工具集必须来自 `contributes.toolsets`。
-
-## Registry 与解析规则
-
-- App 内对象解析顺序：**local(app) → kernel**。
-- App 之间互不覆盖；若 import 后发生同名冲突，app 置为 defunc。
-- Kernel registry 不接收 app 注册对象，因此不存在“从 kernel registry 移除”这一操作。
-- defunc 的 app 不参与解析（但其对象也不会被“移除”——因为它们从未进入 kernel registry）。
-
-## Export / Import 语义
-
-### Export
-
-- 由 app install json 的 `exports` 声明。
-- Kernel 对外提供 app exports 查询（API 形态可在实现阶段确定）。
-
-### Import
-
-- **成员 import**：在 app 的 `team.yaml` 中声明。
-- **工具集 import**：在 app 的 `team.yaml` 中声明；运行时通过 dominds API 拉取工具集元信息，并注册到 app registry。
-
-推荐结构（示意）：
-
-```yaml
-imports:
-  members:
-    - app: foo_app
-      id: npc_foo
-  toolsets:
-    - app: bar_app
-      id: bar_toolset
-```
-
-### 冲突与依赖失败
-
-- import 冲突或依赖不满足 → app 置为 defunc。
-
-#### 冲突矩阵（最小规则集）
-
-| 场景                                        | 结果                      |
-| ------------------------------------------- | ------------------------- |
-| `local(app)` 与 `kernel` 同名               | 允许（local 覆盖 kernel） |
-| import 的 member/toolset 与 app 本地同名    | defunc                    |
-| import 的 member/toolset 与其它 import 同名 | defunc                    |
-| import 指向未 export 的对象                 | defunc                    |
-| depends 不满足（缺失/版本不匹配）           | defunc                    |
-
-## Defunc 语义
-
-- defunc 后 app 功能不可用。
-- 不会从 registry 移除（app registry 不再被使用；kernel registry 没有 app 对象）。
-- defunc 原因应被记录并可被诊断。
-
-### Defunc 触发条件（建议枚举）
-
-- `MANIFEST_INVALID`：install json 字段缺失/格式错误。
-- `DEPENDENCY_MISSING` / `DEPENDENCY_VERSION_MISMATCH`：depends 缺失或不满足。
-- `EXPORTS_INVALID`：exports 声明引用不存在的 member/toolset。
-- `IMPORT_NOT_EXPORTED`：import 指向的对象未在对方 exports 声明。
-- `IMPORT_CONFLICT`：import 引入同名冲突。
-- `TEAM_OVERRIDE_INVALID`：`<rtws>/.apps/<app-id>/team.yaml` 覆盖 DSL 解析或校验失败。
-- `IMPORT_FETCH_FAILED`：通过 API 拉取 toolset 元信息失败或返回无效。
-
-### 重试语义（建议）
-
-- defunc 默认 **可重试**：当依赖/配置问题被修复后，kernel 在下一次 app 刷新周期重新加载该 app。
-- 重试不会自动修改已有对话/历史 round；仅影响后续解析与新调用。
-
-### 可观测性（建议）
-
-- defunc 必须进入 Problems（或等价的可见面），至少包含：`appId`、`reasonKind`、`detail`、`firstSeenAt`、`lastSeenAt`、`retryable`、`suggestedAction`。
-- `app_integration_manual` 调用失败 **不触发 defunc**（失败应被记录，但不应让 app 进入不可用）。
-
-## App 集成手册（`app_integration_manual`）
-
-- kernel 固定工具：`app_integration_manual`
-- 参数：`{ appId: string, language?: string }`
-  - 未指定 `language` 时默认 **work language**。
-- kernel 通过 IPC 路由到 app host，由 app 返回内容。
-- app 可以静态输出 markdown，或运行时动态生成。
-- app 必须提供 zh/en 双语内容。
-- 调用失败不触发 defunc（返回错误即可）。
-
-## 语言约束
-
-- **work language** 来自 `LANG` 环境变量，kernel 与 app host 继承并且运行期不可变。
-- app 必须遵守 kernel 的 work language。
-- app UI 可以独立设置 ui language。
-- 所有 app 必须至少支持 zh/en 双语。
-
-## `team.yaml` 增量覆盖 DSL
-
-覆盖文件：`<rtws>/.apps/<app-id>/team.yaml`
-
-- 无需 `actions:` 顶层。
-- 使用领域特定语法，支持 **add/replace/modify/delete**。
-- 每次读取磁盘时执行动作，失败则 app 置为 defunc。
-
-示意：
-
-```yaml
-version: 1
-
-add:
-  members:
-    - id: npc_new
-      value:
-        name: 新NPC
-        toolsets: [trae_toolset]
-
-replace:
-  members:
-    - id: npc_old
-      value:
-        name: 旧NPC
-        hidden: true
-
-modify:
-  members:
-    - id: npc_village_head
-      set:
-        toolsets: [trae_toolset, extra_toolset]
-        streaming: true
-      unset: [tools]
-      merge:
-        model_params:
-          codex:
-            temperature: 0.2
-  member_defaults:
-    set:
-      provider: codex
-
-delete:
-  members:
-    - id: npc_removed
-
-set_default_responder: npc_village_head
-
-add_shell_specialist:
-  - npc_village_head
-
-remove_shell_specialist:
-  - npc_foo
-```
-
-语义约束：
-
-- `modify_member` 支持 `set`/`unset`/`merge`，其中 `merge` 对对象执行深合并。
-- 所有新增/替换/修改需经过现有 team.yaml 校验逻辑。
-- 出现冲突或解析失败，app 置 defunc。
-
-## 加载流程（建议）
-
-1. 解析并落实工具集（本地 toolsets + imports.toolsets），**先注册工具集与内含工具**
-2. 读取 app 内置 team.yaml
-3. 解析 imports.members
-4. 应用 `<rtws>/.apps/<app-id>/team.yaml` 覆盖
-5. 执行校验（此时工具/工具集已可解析）
-6. 成功 → 注册成员到 app registry
-7. 失败 → app defunc
-
-## 复核包（Review Packet）
-
-本节用于让 reviewer 在 30 分钟内完成复核并继续推进（不把实现细节写进差遣牒 progress）。
-
-### 产物索引（Artifacts）
-
-- 架构文档（语义源）：`dominds/docs/kernel-app-architecture.zh.md`
-- 英文对齐：`dominds/docs/kernel-app-architecture.md`
-
-### 近期变更影响面（Delta）
-
-- WebSocket 驱动不再接收 `runControlId/runControlInput`（run control 的大幅扩展另起专项文档）。
-- apps-host 的 run control 结果不再支持 `systemPromptPatch/prompt`（收敛为最小的 continue/reject 形态）。
-- kernel-driver 的 context-health 驱动逻辑对齐 driver-v2 的实现方式（仅作为原型期收敛/清理）。
-
-### 最小行为复核（Smoke，建议）
-
-以下 smoke 以“原型仅概念/功能验证”为前提，重点验证系统未因近期清理而破坏既有路径：
-
-1. `pnpm -C dominds run lint:types` 通过。
-2. 若当前 rtws 存在已启用 app：启动后 apps runtime 能启动 apps-host，并将 app 的 `contributes.toolsets` 注册为 proxy tools（不发生 name collision）。
-3. 在 WebUI 驱动对话与 Q4H 回答时，不再需要/不再发送 `runControlId/runControlInput`。
-
-## 原型现状与问题清单（Gap List）
-
-本原型当前已具备的“可验证骨架”（仅陈述事实，不承诺完备）：
-
-- 已有 apps runtime + apps-host IPC 基础设施，可启动 apps-host 子进程并转发 tool 调用。
-- 已支持按 app 的 `contributes.toolsets` 注册 proxy toolset/tool（用于概念/功能验证）。
-- 已支持 app 声明 dialog run controls 的注册（但 run control 语义扩展另起专项文档）。
-
-本原型尚未闭环/需要后续实现明确落点的事项（作为“现状与问题”产物）：
-
-- `depends/exports/imports` 的加载、校验与冲突处理目前主要停留在架构规格层，尚需落地实现与端到端验证。
-- defunc 的生命周期状态机、Problems 可观测面、可重试/重载入口需要实现级闭包（含日志/错误分类）。
-- `<rtws>/.apps/<app-id>/team.yaml` override DSL 的实际读取/动作执行/校验落点需要实现与回归。
-- `app_integration_manual(appId, language?)` 的 kernel 固定工具与 IPC 路由需要实现与回归。
-- 迁移路线图（内置能力迁出顺序、回滚策略、dogfooding gate）需在后续实现阶段形成可执行清单。
-
-## 完成定义（验收口径）
-
-当以下条件满足时，可认为本原型的“综合方案推进”文档交付完成：
-
-- 本文覆盖并明确：Identity/Resolution、defunc 触发与可重试、imports/exports 粒度与冲突矩阵、team.yaml override DSL、`app_integration_manual` 契约。
-- 关键规则使用“发生 X → 系统做 Y”的句式，且没有依赖读源码才能理解的隐式前提。
-- `kernel-app-architecture.zh.md` 与英文版 `kernel-app-architecture.md` 同步一致（zh 为语义基准）。
-
-## 关键落点（现有代码）
-
-- install json 解析：`dominds/main/apps/app-json.ts`
-- apps runtime：`dominds/main/apps/runtime.ts`
-- apps host contract：`dominds/main/apps-host/app-host-contract.ts`
-- apps host IPC：`dominds/main/apps-host/ipc-types.ts`
-- team.yaml 解析：`dominds/main/team.ts`
-- app teammates loader：`dominds/main/apps/teammates.ts`
-
----
-
-本文件为原型阶段设计草案，后续实现细节会跟随代码落地更新。

package/dist/docs/showing-by-doing.md

@@ -1,208 +0,0 @@
-# Showing-by-Doing (做给祂看): Make Tellask Real
-
-Chinese version: [中文版](./showing-by-doing.zh.md)
-
-## Summary
-
-Dominds has a real, runtime-enforced Tellask mechanism (`!?@...`) and a real, runtime-enforced Fresh Boots Reasoning
-(FBR) mechanism (`!?@self`). Even if system prompts explain these mechanisms in detail, most foundation models were not
-trained in a world where “asking a teammate to run a shell command” is actually possible, so they often treat such text
-as aspirational or hypothetical.
-
-**Showing-by-Doing (做给祂看)** is a tiny, highly realistic “first impression” procedure executed at dialog creation
-time. It runs a short, real Tellask + real FBR round-trip so the model gains _felt-sense_ that:
-
-- teammate Tellasks are real and will be executed
-- tool outputs are real and will be returned
-- FBR is real and will produce a report back to the caller
-
-This makes subsequent use of Tellasks and `!?@self` FBR more reliable across the entire dialog lifecycle.
-
-As a consequence, we can **dramatically simplify system prompts**: keep only short, accurate statements of the Tellask/FBR
-contracts, and rely on Showing-by-Doing to establish “this is real and works here”.
-
-Related docs:
-
-- Tellask runtime: `dominds/docs/dialog-system.md`
-- Terminology (Mainline/Sideline): `dominds/docs/dominds-terminology.md`
-- FBR (`!?@self`): `dominds/docs/fbr.md`
-- Work language vs UI language: `dominds/docs/i18n.md`
-
----
-
-## Goals
-
-- Establish immediate trust that **Tellask is not “just prompt text”**: it is an executable, backend-driven mechanism.
-- Establish immediate trust that **FBR is not “just reasoning”**: it is a concrete sideline dialog that reports back.
-- Keep the procedure safe, small, and deterministic (default command: `uname -a`).
-- Persist and display the interaction so it is credible from multiple angles (backend record + frontend transcript).
-
-## Non-goals
-
-- Running arbitrary user-provided commands as part of dialog creation.
-- Collecting sensitive system information (beyond minimal OS/kernel identification).
-- Replacing proper documentation: this is an experiential supplement, not the main spec.
-
----
-
-## Definitions (user-facing)
-
-- **Mainline dialog**: the primary thread where the user and the main agent interact.
-- **Sideline dialog**: a temporary work thread created by Tellask / FBR, reporting results back to the mainline.
-- **Tellask**: a structured request (`!?@<memberId> ...`) from a tellasker to a tellaskee.
-- **Shell specialist**: a teammate designated to run shell commands safely (configured via `shell_specialists`).
-- **FBR**: Fresh Boots Reasoning, implemented as `!?@self` (a tool-less sideline dialog). See `dominds/docs/fbr.md`.
-
----
-
-## Runtime flow (at dialog creation)
-
-Showing-by-Doing runs **before** the first user message is processed (a “prelude”), unless the user opts out.
-
-### 1) Choose the shell execution path
-
-1. If the team config includes at least one `shell_specialists` member, pick one deterministically (e.g. the first).
-2. Otherwise, let the **Dominds runtime** execute the baseline command directly (not via agent tools).
-
-Note: team config validation normally requires `shell_specialists` to be non-empty if any teammate has shell tools, and
-also requires that only listed shell specialists have shell tools. In other words, “no `shell_specialists` configured”
-usually means “shell tools are disabled for all user-facing teammates”.
-
-Baseline command:
-
-- `uname -a`
-
-If `uname -a` fails (e.g. non-POSIX host), the runtime should fall back to a platform-appropriate equivalent, but the
-default “muscle memory” path is intentionally `uname -a` because it is common, low-risk, and quick.
-
-### 2) Real teammate Tellask: ask for `uname -a`
-
-If a shell specialist exists, the main agent (tellasker) issues **a real Tellask** to the shell specialist (tellaskee),
-in the server-wide **work language** (see `dominds/docs/i18n.md`).
-
-The Tellask body should be short and operational:
-
-- ask the shell specialist to run `uname -a`
-- ask them to return the raw output verbatim
-- ask them to include an error + alternative command if `uname` is not available
-
-The result must be recorded as a normal, debuggable transcript that clearly shows:
-
-- the Tellask headline + body
-- the shell specialist’s command execution
-- the returned output
-
-Minimal configuration example:
-
-```yaml
-# .minds/team.yaml
-shell_specialists:
-  - cmdr
-```
-
-### 3) Real FBR: reflect on what the environment implies
-
-After obtaining the environment snapshot (from the shell specialist or direct tool run), the main agent issues a real
-`!?@self` Tellask to trigger **FBR**.
-
-The FBR Tellask body should include:
-
-- the exact `uname -a` output
-- the main agent’s tool availability assumptions (e.g. “in mainline I may have `fs`/`os`/`mem`; in FBR you have no tools”)
-- the question: “What should I be careful about in this environment? Which CLI tools should I prioritize, and why?”
-
-The FBR response should return a compact report that the main agent can reuse, typically:
-
-- environment notes (OS family, kernel, container/VM hints if any)
-- do/don’t list (pitfalls)
-- a short “preferred commands” shortlist (e.g. `rg`, `sed`, `jq`, `tar`, `ps`, `lsof`, depending on host)
-
-### 4) Summarize into an “Environment Quickstart” note
-
-The main agent then writes a short, user-visible summary to the mainline dialog so the knowledge is explicit and
-searchable in the transcript.
-
----
-
-## Fallback behavior
-
-Showing-by-Doing should degrade gracefully:
-
-- **No `shell_specialists` configured**: the Dominds runtime runs `uname -a` directly, then do FBR.
-- **Shell specialist fails or times out**: the Dominds runtime runs `uname -a` directly and continue, marking the
-  specialist attempt as failed in the transcript.
-- **`uname` not available / command fails**: run FBR with “environment unknown”; the report should explicitly list what
-  is missing and suggest what to gather later.
-
----
-
-## Persistence, caching, and reuse
-
-### 1) Persist as real dialog records (backend + frontend)
-
-All Showing-by-Doing steps must be persisted as standard dialog artifacts (messages + events) so they remain credible:
-
-- they survive restarts (subject to normal dialog persistence rules)
-- they are debuggable in logs/storage
-- they are rendered in the WebUI transcript (ideally as a collapsible “Prelude” section)
-
-### 2) Process-wide cache (per teammate)
-
-To avoid repeating `uname -a` + FBR on every new dialog, the backend process may maintain a **server-scoped cache** keyed
-by (at minimum):
-
-- tellasker teammate id (the agent whose dialogs are being created)
-- an environment fingerprint derived from the `uname -a` output (exact string or hashed)
-
-Cache payload (recommended):
-
-- the full Showing-by-Doing transcript (Tellask + output + FBR + summary)
-- a short “Environment Quickstart” distilled form (for compact context injection)
-- timestamps + a version tag for future schema changes
-
-Reuse policy:
-
-- If a valid cache entry exists, a new dialog may **reuse** the cached transcript instead of re-running.
-- Reused entries should still be visible in the new dialog’s transcript, clearly labeled as “Reused from cache”.
-
-Invalidation (recommended):
-
-- invalidate when the environment fingerprint changes
-- allow a manual “Refresh environment snapshot” action for debugging
-
-### 3) Carry across `clear_mind`
-
-After each `clear_mind` (entering the next “journey stage”), do **not** rely on reminders for this.
-
-Instead, inject a small, stable **course prefix** into the model context at the start of each new course (i.e. the first
-few messages in the historical dialog section). This prefix should be a condensed transcript distilled from the original
-Showing-by-Doing run (shell snapshot + FBR highlights + quickstart), so the agent keeps its “felt-sense” of Tellask/FBR
-and environment constraints without re-running the prelude.
-
----
-
-## UX requirements (WebUI)
-
-### Display
-
-- Render Showing-by-Doing as a realistic transcript the user can inspect.
-- Prefer a collapsible “Prelude” section at the top of the dialog, with clear labels:
-  - “Teammate Tellask (shell)”
-  - “FBR (`!?@self`)”
-  - “Environment Quickstart”
-
-### Opt-out
-
-The dialog creation UI should include an explicit opt-out, e.g.:
-
-- Checkbox: “Skip Showing-by-Doing (do not run environment prelude)”
-
-If opted out, no prelude actions are executed and no prelude transcript is generated.
-
----
-
-## Safety notes
-
-- Default to a single, low-risk command (`uname -a`).
-- Do not run anything that modifies the filesystem or network as part of this prelude.
-- Treat the prelude transcript as user-visible by default; avoid including secrets or personally identifying details.

package/dist/docs/showing-by-doing.zh.md

@@ -1,177 +0,0 @@
-# 做给祂看（Showing-by-Doing）：把诉请机制变成“体感”
-
-英文版：[English](./showing-by-doing.md)
-
-## 摘要
-
-Dominds 的诉请（Tellask，`!?@...`）与扪心自问（FBR，`!?@self`）并不是“写在系统提示里的约定”，而是**后端真实可驱动、可执行、可回传、可持久化**的机制。
-
-问题在于：即使系统提示把诉请机制写得再细，大多数基础模型也并未在“真的可以随时拉一个队友去跑 shell 命令并把结果带回来”的世界里被训练过，因此容易把这些提示当成“说说而已 / 仅供参考”。这会直接削弱诉请与 FBR 的可用性。
-
-因此引入 **“做给祂看”**：在一个对话创建之初，运行一段极短、极拟真的“真实诉请 + 真实 FBR”往返，让智能体产生明确的体感：
-
-- 诉请是真的，会被执行
-- 工具输出是真的，会被带回并写入对话记录
-- `!?@self` FBR 也是真的，会作为支线对话产出报告并回传
-
-体感建立后，系统提示可以**大幅简化**：只保留“短而准确”的契约说明即可，把“这在本环境里真实可用”的可信度交给做给祂看来完成。
-
-相关文档：
-
-- 诉请机制与子对话：`dominds/docs/dialog-system.md`
-- 术语约定（主线/支线；诉请方/应答方）：`dominds/docs/dominds-terminology.md`
-- FBR（`!?@self`）：`dominds/docs/fbr.md`
-- 工作语言 vs UI 语言：`dominds/docs/i18n.md`
-
----
-
-## 目标
-
-- 在对话一开始就建立“诉请/回传/持久化都是真的”的信任。
-- 在对话一开始就跑通一次 `!?@self` 的 FBR 回路。
-- 过程足够小、可控、低风险（默认只执行 `uname -a`）。
-- 记录从多角度都高度拟真：后端存档 + 前端可见的对话转录。
-
-## 非目标
-
-- 不在创建对话时执行任意用户输入的命令。
-- 不收集敏感信息（默认只采集最小的 OS/Kernel 识别信息）。
-- 不替代系统提示/设计文档：这是“体感补强”，不是完整规范的主载体。
-
----
-
-## 概念（用户视角）
-
-- **主线对话**：用户与主要智能体交互的那条线。
-- **支线对话**：由诉请 / FBR 触发的临时工作线，产出结果回传主线。
-- **诉请（Tellask）**：以 `!?@<memberId> ...` 向队友/对话发起的结构化请求。
-- **Shell 专家（shell specialist）**：被允许执行 shell 命令并回传结果的队友（由 `shell_specialists` 配置指定）。
-- **FBR（扪心自问）**：以 `!?@self` 触发的“无工具支线推理”，产出报告回传主线。
-
----
-
-## 运行流程（对话创建时）
-
-做给祂看发生在**第一条用户消息被处理之前**（可视为一个 Prelude / 序幕），除非用户在创建对话时明确选择跳过。
-
-### 1）选择执行路径
-
-1. 如果 team 配置里存在 `shell_specialists`，选择一个 shell 专员（建议确定性选择：列表第一个）。
-2. 否则，由 **Dominds 运行时**直接执行基线命令（不通过智能体工具）。
-
-补充：team 配置校验一般会要求——只要有队友拥有 shell 工具，就必须配置非空的 `shell_specialists`；同时，非 shell 专员不应持有 shell 工具。因此“没有配置 `shell_specialists`”通常意味着“对用户可见的队友都没有 shell 工具可用”。
-
-基线命令（默认）：
-
-- `uname -a`
-
-`uname -a` 失败时（例如非 POSIX 环境），可以改用平台等价命令；但默认肌肉记忆路径保留 `uname -a`，因为它低风险、快、且信息量刚好够用。
-
-### 2）真实队友诉请：让 shell 专员执行 `uname -a`
-
-若存在 shell 专员，则主线智能体（诉请方）以**工作语言**（server-wide，见 `dominds/docs/i18n.md`）向 shell 专员（应答方）发起真实诉请，要求：
-
-- 执行 `uname -a`
-- 原样返回输出
-- 若命令不可用，返回错误信息，并给出替代命令建议
-
-结果必须以正常对话转录的方式落盘并展示，至少清晰体现：
-
-- 诉请的 headline + body
-- shell 专员实际执行了命令
-- 返回的原始输出
-
-最小配置示例：
-
-```yaml
-# .minds/team.yaml
-shell_specialists:
-  - cmdr
-```
-
-### 3）真实 FBR：基于环境信息做一次“扪心自问”
-
-拿到环境快照（来自 shell 专员或直接运行）后，主线智能体触发一次 `!?@self` FBR，并在 FBR 的诉请正文里带上：
-
-- `uname -a` 的完整输出
-- 主线可用工具的假设（例如“主线可能有 `fs`/`os`/`mem`；但 FBR 你没有任何工具”）
-- 问题：在这个环境里要注意什么？优先用哪些命令行工具，为什么？
-
-FBR 产出应尽量短而可复用，典型包括：
-
-- 环境判断（OS 家族、内核、是否容器/VM 线索）
-- 注意事项（坑点清单）
-- “优先工具/命令” shortlist（例如 `rg`、`sed`、`jq`、`tar`、`ps`、`lsof` 等，视环境而定）
-
-### 4）把结果收敛成“环境速记”
-
-主线智能体在主线对话里追加一条短总结（Environment Quickstart），让关键信息显性化、可检索。
-
----
-
-## 降级策略
-
-- **未配置 `shell_specialists`**：由 Dominds 运行时直接执行 `uname -a`，然后进入 FBR。
-- **shell 专员失败/超时**：记录失败原因，由 Dominds 运行时直接执行 `uname -a`，继续进入 FBR。
-- **`uname` 不存在/执行失败**：跳过命令执行，直接让 FBR 以“环境未知”输出：缺什么信息、为什么关键、后续如何补齐。
-
----
-
-## 持久化、缓存与复用
-
-### 1）记录必须“像真的一样”
-
-做给祂看的每一步都必须作为标准对话记录落盘（消息 + 事件），并在 WebUI 中可见：
-
-- 可跨重启（遵循常规对话持久化）
-- 可 debug（日志/存储都有迹可循）
-- 前端可查看转录（建议 UI 上做一个可折叠 Prelude 区域）
-
-### 2）仅进程内缓存（按智能体维度）
-
-为了避免每次新对话都重复跑 `uname -a` + FBR，后端进程可以维护一个**进程内缓存**（重启失效），按（至少）主线智能体 id 做 key。
-
-缓存内容建议包含：
-
-- 完整转录（诉请 + shell 输出 + FBR + 速记）
-- 一份更短的 distilled “环境速记”（用于注入上下文）
-- 时间戳 + 版本号（未来 schema 变化用）
-
-复用策略：
-
-- 若命中缓存，新对话可以直接复用首次的转录与速记，不再重复执行。
-- 复用的记录在新对话里仍应可见，并清楚标记“来自缓存复用”。
-
-### 3）跨 `clear_mind` 携带
-
-每次 `clear_mind` 进入下一程时，不要依赖 reminder 来承载这件事。
-
-改为：在每一程对话的上下文里，注入一段小而稳定的 **course prefix**（可理解为“历史消息区最开头的几条 msg”），内容是从首次做给祂看中提炼出的压缩转录（shell 快照 + FBR 摘要 + 环境速记）。这样智能体能持续保留“体感”和环境约束，而无需重复执行 Prelude，也不必每次把整段长转录重新塞进上下文。
-
----
-
-## WebUI 需求
-
-### 展示
-
-- 做给祂看应以真实对话转录展示，用户可展开查看细节。
-- 建议在对话顶部提供一个可折叠 Prelude 区域，并带上清晰标签：
-  - “队友诉请（shell）”
-  - “FBR（`!?@self`）”
-  - “环境速记（Environment Quickstart）”
-
-### 创建对话时可选择跳过（opt-out）
-
-创建对话框上提供明确开关，例如：
-
-- Checkbox：“跳过做给祂看（不执行环境序幕）”
-
-若选择跳过，则不执行任何 Prelude 行为，也不生成 Prelude 转录。
-
----
-
-## 安全注意事项
-
-- 默认只执行 `uname -a`（低风险、只读、快）。
-- Prelude 禁止任何会改写文件/网络/系统状态的操作。
-- 由于 Prelude 默认用户可见，严禁输出密钥/敏感信息。