dominds 0.9.2 → 0.10.0

package/dist/dialog-instance-registry.js

@@ -57,12 +57,6 @@ async function getOrRestoreRootDialog(rootId, status) {
         currentCourse: rootState.currentCourse,
         contextHealth: rootState.contextHealth,
     });
-    const persistedSubdialogAgentPrimingMode = rootMetadata.subdialogAgentPrimingMode === 'do' ||
-        rootMetadata.subdialogAgentPrimingMode === 'reuse' ||
-        rootMetadata.subdialogAgentPrimingMode === 'skip'
-        ? rootMetadata.subdialogAgentPrimingMode
-        : 'reuse';
-    rootDialog.setSubdialogAgentPrimingMode(persistedSubdialogAgentPrimingMode);
     const persistedDisableDiligencePush = latest && typeof latest.disableDiligencePush === 'boolean'
         ? latest.disableDiligencePush
         : defaultDisableDiligencePush;

package/dist/dialog.js

@@ -829,8 +829,6 @@ class RootDialog extends Dialog {
     constructor(dlgStore, taskDocPath, id, agentId, initialState) {
         super(dlgStore, taskDocPath, id, agentId, initialState);
         this._status = 'running';
-        // Root-level inheritance policy for newly created subdialogs.
-        this._subdialogAgentPrimingMode = 'reuse';
         // Tracks all dialogs in this dialog tree for O(1) lookup
         this._localRegistry = new Map();
         // Tracks Type-B registered subdialogs by agentId!sessionSlug
@@ -843,12 +841,6 @@ class RootDialog extends Dialog {
     setPersistenceStatus(status) {
         this._status = status;
     }
-    get subdialogAgentPrimingMode() {
-        return this._subdialogAgentPrimingMode;
-    }
-    setSubdialogAgentPrimingMode(mode) {
-        this._subdialogAgentPrimingMode = mode;
-    }
     /**
      * Register a dialog (self or subdialog) in the local registry.
      */

package/dist/docs/agent-priming.md

@@ -0,0 +1,148 @@
+# Agent Priming (Startup Scripts) Design
+
+Chinese version: [中文](./agent-priming.zh.md)
+
+## Goal
+
+Priming is unified as an editable, versionable, replayable Markdown startup-script mechanism.
+
+- Script-as-history: startup scripts are preloaded dialog history.
+- Faithful replay: scripts preserve and replay technical details (including tool records and `callId` links).
+- Explicit selection: users choose scripts at dialog creation time.
+- Visibility control: script-origin bubbles can be shown or hidden in UI.
+
+## Storage Layout
+
+All scripts live under `.minds/priming/` in rtws:
+
+- Individual: `.minds/priming/individual/<team-member-id>/<slug>.md`
+- Team shared: `.minds/priming/team_shared/<slug>.md`
+
+Constraints:
+
+- `slug` uses `[A-Za-z0-9._-]` path segments and may be nested.
+- Path escape is forbidden (absolute path, `..`, NUL, illegal chars).
+- Canonical refs:
+  - `individual/<team-member-id>/<slug>`
+  - `team_shared/<slug>`
+
+## Script Format (Strict)
+
+Each file uses `frontmatter + record blocks`.
+
+### Top-level frontmatter (optional)
+
+```yaml
+---
+kind: agent_priming_script
+version: 3
+title: Environment Probe Startup
+applicableMemberIds:
+  - ux
+---
+```
+
+### Record blocks (required)
+
+Each section must be `### record <record-type>`.
+
+Strict rules:
+
+- No legacy format: `### user` / `### assistant` is no longer supported.
+- `func_call_record`: use triple-backtick `json` with a full JSON object.
+- All other record types: use markdown blocks; six backticks (``````markdown) are recommended to avoid collisions with inner triple-backtick content.
+- For non-`func_call_record` blocks, block frontmatter stores metadata and the markdown body maps to the record’s main text field (`content` / `response` / `result`).
+
+Example:
+
+````markdown
+### record human_text_record
+
+```markdown
+---
+genseq: 1
+msgId: priming-1
+grammar: markdown
+---
+
+Run an environment probe first.
+```
+````
+
+### record func_call_record
+
+```json
+{
+  "type": "func_call_record",
+  "genseq": 1,
+  "id": "call_probe_1",
+  "name": "exec_command",
+  "arguments": {
+    "cmd": "uname -a"
+  }
+}
+```
+
+### record func_result_record
+
+```markdown
+---
+genseq: 1
+id: call_probe_1
+name: exec_command
+---
+
+Darwin ...
+```
+
+```
+
+## About `~~~markdown`
+
+`~~~markdown` originally helped avoid fence collisions when content already included triple-backtick blocks.
+
+Now the canonical export is six-backtick markdown blocks for non-`func_call_record`, and triple-backtick JSON for `func_call_record`. The parser still accepts `~~~` and varying backtick fence lengths.
+
+## Create Dialog Flow (WebUI)
+
+Priming area in create-dialog modal:
+
+- Dropdown: recent scripts (backend-managed per agent, max 20).
+- `<None> startup script`: no priming injection.
+- `More…`: live backend disk scan on query; selecting a result writes it back to dropdown and selects it.
+- `UI display` checkbox: controls whether priming-origin bubbles are rendered.
+
+Request contract:
+
+- `create_dialog` may include `priming`:
+  - `scriptRefs: string[]` (UI currently single-select: 0 or 1 item)
+  - `showInUi: boolean`
+
+Runtime behavior:
+
+- On root dialog creation, selected scripts are replayed into `course-1`.
+- Replayed events are tagged with `sourceTag: priming_script`.
+- Replay is injected into `dialog.msgs` for downstream model context.
+- `showInUi=false` only affects rendering; persistence/context remain unchanged.
+
+## Save Startup Script (WebUI)
+
+- Toolbar uses an icon save button.
+- Prompt shows concrete path:
+  `.minds/priming/individual/<current-agent-id>/<slug>.md`
+- Existing target requires explicit overwrite confirmation.
+
+Export rules:
+
+- Export full course record history.
+- Empty course export is rejected.
+- Frontmatter stores source dialog metadata (`rootId/selfId/course/status`).
+
+## Recent Usage Storage
+
+- Backend per-agent file:
+  `<rtws>/.dialogs/recent-priming/<agent-id>.json`
+- Max 20 entries (trimmed on write).
+- Recent dropdown is fetched from backend each time.
+- Usage is recorded only when dialog creation succeeds.
+```

package/dist/docs/agent-priming.zh.md

@@ -0,0 +1,145 @@
+# Agent Priming（启动脚本）设计
+
+英文版：[English](./agent-priming.md)
+
+## 目标
+
+将 priming 统一为“可编辑、可版本化、可回放”的 Markdown 启动脚本能力。
+
+- 脚本即历史：启动脚本本质上是预置对话历史。
+- 忠实复原：脚本默认记录并复原完整技术细节（含 `role=tool` 相关记录、`callId` 等关联字段）。
+- 显式选择：创建对话时由用户明确选择，不做隐式注入。
+- 可见性可控：可选择是否在 UI 展示由脚本注入的历史气泡。
+
+## 存储布局
+
+脚本统一放在 rtws 的 `.minds/priming/` 下：
+
+- 个人脚本：`.minds/priming/individual/<team-member-id>/<slug>.md`
+- 团队共享脚本：`.minds/priming/team_shared/<slug>.md`
+
+约束：
+
+- `slug` 由 `[A-Za-z0-9._-]` 路径段组成，可多级。
+- 严禁越界路径（绝对路径、`..`、NUL、非法字符）。
+- `scriptRef` 统一形如：
+  - `individual/<team-member-id>/<slug>`
+  - `team_shared/<slug>`
+
+## 脚本格式（严格）
+
+脚本文件采用 `frontmatter + record 块`。
+
+### 顶层 frontmatter（可选）
+
+```yaml
+---
+kind: agent_priming_script
+version: 3
+title: 环境探针启动
+applicableMemberIds:
+  - ux
+---
+```
+
+### record 块（必填）
+
+每段必须是：`### record <record-type>`。
+
+严格规则：
+
+- 不存在旧写法，不再支持 `### user` / `### assistant`。
+- `func_call_record`：使用三重反引号 `json`，内容是完整 JSON 对象。
+- 其它 record：使用 markdown block，建议 6 重反引号（``````markdown）避免和正文里的三反引号冲突。
+- 非 `func_call_record` 的 markdown block 可在块内使用 frontmatter 记录元字段；正文映射该 record 的主文本字段（如 `content` / `response` / `result`）。
+
+示例：
+
+````markdown
+### record human_text_record
+
+```markdown
+---
+genseq: 1
+msgId: priming-1
+grammar: markdown
+---
+
+先做环境探针。
+```
+````
+
+### record func_call_record
+
+```json
+{
+  "type": "func_call_record",
+  "genseq": 1,
+  "id": "call_probe_1",
+  "name": "exec_command",
+  "arguments": {
+    "cmd": "uname -a"
+  }
+}
+```
+
+### record func_result_record
+
+```markdown
+---
+genseq: 1
+id: call_probe_1
+name: exec_command
+---
+
+Darwin ...
+```
+
+```
+
+## 关于 `~~~markdown`
+
+`~~~markdown` 的历史动机是避免外层 fenced block 与正文三反引号冲突。当前推荐是 6 重反引号 markdown block；解析器仍接受 `~~~` 与不同长度反引号 fenced 风格，但标准导出采用 6 重反引号（`func_call_record` 除外）。
+
+## 创建对话流程（WebUI）
+
+创建对话 modal 的 priming 区域：
+
+- 下拉列表：展示 recent 脚本（后端按 agent 维护，最多 20 条）。
+- `<无> 启动脚本`：不注入启动脚本。
+- `更多……`：按输入文本实时后端扫描磁盘匹配；确认后回填下拉并选中。
+- `UI 展示` 勾选框：控制是否展示脚本注入的历史气泡。
+
+请求结构：
+
+- `create_dialog` 可带 `priming`：
+  - `scriptRefs: string[]`（当前 UI 单选，传 0 或 1 项）
+  - `showInUi: boolean`
+
+运行时行为：
+
+- 创建 root dialog 后，按 `scriptRefs` 回放脚本。
+- 回放事件写入 `course-1`，并统一标记 `sourceTag: priming_script`。
+- 同步注入 `dialog.msgs`，确保后续 LLM 上下文可见。
+- `showInUi=false` 时仅隐藏展示，不影响持久化与上下文。
+
+## 保存启动脚本（WebUI）
+
+- toolbar 使用图标按钮“保存启动脚本”。
+- 提示输入 `slug`，并显示路径：
+  `.minds/priming/individual/<当前-agent-id>/<slug>.md`
+- 若目标文件存在，必须确认覆盖。
+
+导出规则：
+
+- 从当前 course 导出完整 record 历史。
+- 空历史禁止导出。
+- frontmatter 记录来源对话（rootId/selfId/course/status）。
+
+## recent 使用记录
+
+- 后端按 agent 保存：`<rtws>/.dialogs/recent-priming/<agent-id>.json`
+- 最多 20 条（写入时裁剪）。
+- recent 列表每次从后端读取。
+- 仅在“创建对话成功”时记录 recent。
+```

package/dist/docs/dialog-system.md

@@ -962,7 +962,7 @@ At the start of every subdialog course, the runtime must prepend a role header t
 - EN (example): `This is an FBR sideline dialog; the tellasker dialog is @xxx (may be the same agent).`
 - ZH（示例）: `这是一次 FBR 支线对话；诉请者对话为 @xxx（可能与当前对话同一 agent）。`
 
-**Insertion point**: prefer a single insertion point by updating `formatAssignmentFromSupdialog()` (covers `dialog.ts`, `tellask-bridge`, and `agent-priming`).
+**Insertion point**: prefer a single insertion point by updating `formatAssignmentFromSupdialog()` (covers `dialog.ts`, `tellask-bridge`).
 Frontend twin must stay in sync: `dominds/webapp/src/shared/utils/inter-dialog-format.ts`.
 
 **Storage**: All subdialogs are stored flat under the main dialog's (root dialog's) `subdialogs/` directory, regardless of nesting depth.

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

@@ -953,7 +953,7 @@ interface RegistryMethods {
 - ZH：`这是一次 FBR 支线对话；诉请者对话为 @xxx（可能与当前对话同一 agent）。`
 - EN：`This is an FBR sideline dialog; the tellasker dialog is @xxx (may be the same agent).`
 
-**插入点**：优先通过 `formatAssignmentFromSupdialog()` 单点注入（覆盖 `dialog.ts` / `tellask-bridge` / `agent-priming`），前端 twin 同步：`dominds/webapp/src/shared/utils/inter-dialog-format.ts`。
+**插入点**：优先通过 `formatAssignmentFromSupdialog()` 单点注入（覆盖 `dialog.ts` / `tellask-bridge`），前端 twin 同步：`dominds/webapp/src/shared/utils/inter-dialog-format.ts`。
 
 ### 生命周期管理
 

package/dist/docs/dominds-agent-priming.md

@@ -1,218 +1,27 @@
-# Dominds Agent Priming: Guide the Agent to Show It to Itself
+# Dominds Agent Priming (Deprecated in this branch)
 
-Chinese version: [中文版](./dominds-agent-priming.zh.md)
+English version: [中文](./dominds-agent-priming.zh.md)
 
-## Summary
+## Status
 
-Dominds has a real, runtime-enforced Tellask mechanism (`tellask* function call`) and a real, runtime-enforced Fresh Boots Reasoning
-(FBR) mechanism (`freshBootsReasoning`). 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.
+In this branch, the legacy hardcoded Agent Priming implementation has been fully removed from runtime behavior.
 
-**Agent Priming** is a tiny, highly realistic “first impression” procedure executed at dialog creation time. It runs a
-short, real Tellask + real return + real FBR + real distillation so the model gains _felt-sense_ that:
+- No automatic dialog-creation priming flow runs.
+- No priming cache/reuse modes are executed at startup.
+- No dedicated priming API behavior is enforced by the runtime.
 
-- teammate Tellasks are real and will be executed
-- tool outputs are real and will be returned and persisted
-- `freshBootsReasoning` FBR is real and will report back
-- distillation is expected (extract the best, dedupe, reconcile), not “repeat each draft”
+## What this means for current behavior
 
-More precisely: it **guides the agent to show it to itself** — letting it personally walk through
-(Tellask → return → FBR → distillation), moving from “I’ve heard this exists” to “I just used it”.
+- The runtime does **not** auto-run startup tellasks, environment probes, or distillation-only priming notes.
+- FBR is still available only through normal runtime contracts, including `freshBootsReasoning`.
+- `fbr_effort` still controls how many serial FBR sideline dialogs are spawned for a single `freshBootsReasoning` call (see [`fbr.md`](./fbr.md)).
 
-This is structurally related to the psychology notion of a **priming effect**: an early, concrete stimulus can
-significantly shape subsequent expectations and behaviors. In Dominds we anchor this “priming” in **verifiable runtime
-interactions**, instead of relying on longer, declarative system-prompt text.
+## Planned replacement
 
-As a consequence, we can **dramatically simplify system prompts**: keep only short, accurate statements of the
-Tellask/FBR contracts, and rely on a real priming run to establish “this works here”.
+Priming is being reimplemented from scratch as **startup-script replay**:
 
-Related docs:
+1. Persist normal dialog history as a deterministic startup script artifact.
+2. Replay that script through a dedicated interface when startup priming is required.
+3. Keep behavior explicit, observable, and easy to version by script artifact and replay contract.
 
-- Tellask runtime: [`dialog-system.md`](./dialog-system.md)
-- Terminology (Mainline/Sideline): [`dominds-terminology.md`](./dominds-terminology.md)
-- FBR (`freshBootsReasoning`): [`fbr.md`](./fbr.md)
-- Work language vs UI language: [`i18n.md`](./i18n.md)
-
----
-
-## Goals
-
-- Establish immediate trust that Tellask/return/persistence are real.
-- Run a real `freshBootsReasoning` FBR loop at dialog creation.
-- Build muscle memory for the timing contract: initiate FBR, wait for feedback, then synthesize/decide.
-- Make distillation itself part of the “felt” experience (dedupe/reconcile/extract-the-best).
-- 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 (`tellask({ targetAgentId: "<memberId>", sessionSlug: "<slug>", tellaskContent: "..." })`) 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 `freshBootsReasoning` (a tool-less sideline dialog). See [`fbr.md`](./fbr.md).
-
----
-
-## Runtime flow (at dialog creation)
-
-Agent Priming runs **before** the first user message is processed, 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).
-
-Baseline command:
-
-- `uname -a`
-
-If `uname -a` fails (e.g. non-POSIX host), the runtime may 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 member exists, the main agent (tellasker) issues **a real Tellask** to the shell specialist member
-(tellaskee), in the server-wide work language.
-
-The Tellask body should be short and operational:
-
-- run exactly `uname -a`
-- return raw output verbatim
-- if `uname` fails: include error + one safe alternative command
-
-### 3) Real FBR: reflect on what the environment implies
-
-After obtaining the environment snapshot, the main agent issues a real `freshBootsReasoning` Tellask to trigger FBR.
-
-The FBR body should include:
-
-- the exact `uname -a` output (explicitly name the command; it may change in the future)
-- the tool constraint (FBR has no tools; mainline tool availability is separate)
-- the question: “What should I be careful about in this environment? Which CLI tools should I prioritize, and why?”
-
-Optional parallel drafts:
-
-- If the team member config enables `fbr_effort` (default `3`), the runtime creates multiple `freshBootsReasoning` FBR sideline
-  dialogs concurrently so the agent produces multiple independent “fresh boots” drafts for the mainline dialog to
-  distill.
-- These drafts have **no stable identity mapping**, and there is no meaningful ordering requirement; the mainline dialog
-  should treat them as anonymous drafts rather than fixed personas.
-- If `fbr_effort` is `0`, skip FBR.
-- If `fbr_effort` is greater than `100`, the runtime errors out and stops priming (invalid config).
-
-Phase boundary (critical):
-
-- `freshBootsReasoning` is the **initiation action**, not completed decision-making.
-- Mainline must enter a wait phase until feedback from that FBR run returns.
-- If `fbr_effort = N`, mainline must wait for all N drafts before distillation; do not finalize from partial drafts.
-
-### 4) Distill into an “Agent Priming” note
-
-After confirming feedback from that FBR run has been collected, the main agent writes a short, user-visible **Agent Priming** note via a **normal generation** in the mainline
-dialog. It should be explicitly distilled (dedupe/reconcile/extract-the-best) rather than repeating each draft.
-
-Implementation constraint (matches runtime behavior):
-
-- Do not introduce a separate system-prompt assembly path for distillation.
-- The runtime may use a non-persisted **internal prompt** to anchor “this generation is distillation”.
-- The runtime may also include the shell snapshot and FBR drafts as “evidence” inside that internal prompt (for this
-  drive only, not persisted), so distillation does not depend on any queue timing/concurrency details.
-- During the Agent Priming lifecycle (from prelude start until the priming note is produced), runtime must suppress
-  diligence-push injections; restore normal diligence behavior only after priming completes.
-
-Implementation note (internal prompt):
-
-- The runtime may provide the driver with a non-persisted, non-rendered **internal prompt** (used only in the LLM
-  context for this drive) to explicitly anchor the generation as “distillation”.
-- The internal prompt must not be written into dialog history or persisted storage (to avoid transcript pollution
-  across courses).
-- The internal prompt is a per-drive task directive; it must not replace the system prompt or introduce a separate
-  system-prompt assembly path.
-
-Implementation note (avoid Taskdoc bias):
-
-- Distillation must be Taskdoc-agnostic: the same Agent Priming prefix can be reused across dialogs with different
-  Taskdocs.
-- Therefore, the runtime may choose to **skip injecting Taskdoc** for the one distillation drive, so Taskdoc progress
-  or implementation details do not bias environment conclusions.
-
----
-
-## Persistence, caching, and reuse (in-process only)
-
-### 1) Persist as real dialog records (backend + frontend)
-
-All priming steps must be persisted as standard dialog artifacts (messages + events) and visible in the WebUI.
-
-### 2) Process-wide cache (per agent)
-
-To avoid repeating `uname -a` + FBR + distillation on every new dialog, the backend process may maintain an in-process cache
-(lost on restart) keyed by the mainline agent id.
-
-Reuse policy:
-
-- If a valid cache entry exists, a new dialog may reuse the cached transcript and Agent Priming note.
-- Reused entries should still be visible in the new dialog transcript, labeled as “reused from cache”.
-
-### 2.5) Mainline choice must propagate to sideline dialogs
-
-The priming choice selected at mainline dialog creation must propagate to all sideline dialogs under that root dialog.
-
-Propagation semantics:
-
-- Mainline chooses **Skip** (`skip`): all sideline dialogs must also **Skip** (`skip`).
-- Mainline chooses **Do Again** (`do`) while cache exists: all sideline dialogs must also run fresh (`do`).
-- Mainline chooses **Show it now** (`do`) when cache does not exist, or chooses **Reuse** (`reuse`):
-  sideline dialogs use **reuse-or-do** (`reuse`): reuse cache when available for that sideline agent;
-  otherwise run a fresh priming.
-
-Notes:
-
-- Different sideline agents may have different cache states; `reuse` is evaluated per sideline agent.
-- Priming must not run invisibly in the background; it must be persisted and user-visible as standard dialog artifacts.
-
-### 3) Carry across `clear_mind`
-
-After each `clear_mind` (entering the next course), do not rely on reminders.
-
-Instead, inject a small, stable **course prefix** into model context at the start of each course: a condensed transcript
-(shell snapshot + FBR highlights + Priming note).
-
----
-
-## UX requirements (WebUI)
-
-### Display
-
-- Render Agent Priming as a realistic transcript the user can inspect.
-- Prefer a collapsible top section with clear labels:
-  - “Teammate Tellask (shell)”
-  - “FBR (`freshBootsReasoning`)"
-  - “Agent Priming”
-
-### Opt-out
-
-Dialog creation should provide an explicit opt-out to skip priming.
-
-Additional UX constraints:
-
-- If the dialog owner is a hidden shadow member, the default priming preference should be **Skip**.
-- Shadow-member priming preferences should be stored separately from visible-member preferences (they should not affect each other).
-
----
-
-## Safety notes
-
-- Default to a single, low-risk command (`uname -a`).
-- Do not run anything that modifies the filesystem or network as part of priming.
-- Treat the priming transcript as user-visible by default; avoid including secrets or personally identifying details.
+Until the new interface is fully landed, this document should be treated as a migration note, not an active runtime contract.