dominds 1.18.2 → 1.19.2

package/dist/docs/agent-priming.md

@@ -20,9 +20,9 @@ reminder snapshot.
   - transcript / tool / tellask history records
   - current reminder snapshot
 - Explicitly dropped:
-  - pending subdialogs
+  - pending sideDialogs
   - questions4human
-  - subdialog registry / subdialog responses
+  - sideDialog registry / sideDialog responses
   - other runtime-only waiting / blocking / orchestration state
 
 This is an intentional semantic downgrade relative to a full runtime snapshot: a new dialog inherits
@@ -153,12 +153,12 @@ Request contract:
 
 Runtime behavior:
 
-- On root dialog creation, selected scripts are replayed into `course-1`.
+- On main dialog creation, selected scripts are replayed into `course-1`.
 - If top-level frontmatter contains `reminders`, the current reminder snapshot is restored first.
 - 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.
-- `pending/q4h/subdialog-*` runtime state is not restored.
+- `pending/q4h/sideDialog-*` runtime state is not restored.
 
 ## Save Startup Script (WebUI)
 
@@ -173,7 +173,7 @@ Export rules:
 - Export the current reminder snapshot into top-level frontmatter.
 - Empty course export is rejected.
 - Frontmatter stores source dialog metadata (`rootId/selfId/course/status`).
-- `pending/q4h/subdialog-*` runtime state is not exported; this is an explicit semantic downgrade in
+- `pending/q4h/sideDialog-*` runtime state is not exported; this is an explicit semantic downgrade in
   the current priming design.
 
 ## Recent Usage Storage

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

@@ -19,9 +19,9 @@
   - transcript / tool / tellask 等历史 record
   - 当前 reminder 快照
 - 会明确丢弃：
-  - pending subdialogs
+  - pending sideDialogs
   - questions4human
-  - subdialog registry / subdialog responses
+  - sideDialog registry / sideDialog responses
   - 其它依赖运行中协程、阻塞关系、等待关系的 runtime state
 
 这意味着把某个对话“保存为启动脚本”时，语义上相对完整运行时状态是有降级的：新对话会继承历史和 reminder，但不会继承“仍在等待中的工作流状态”。
@@ -148,12 +148,12 @@ Darwin ...
 
 运行时行为：
 
-- 创建 root dialog 后，按 `scriptRefs` 回放脚本。
+- 创建 main dialog 后，按 `scriptRefs` 回放脚本。
 - 若脚本顶层 frontmatter 含 `reminders`，会先恢复当前 reminder 快照。
 - 回放事件写入 `course-1`，并统一标记 `sourceTag: priming_script`。
 - 同步注入 `dialog.msgs`，确保后续 LLM 上下文可见。
 - `showInUi=false` 时仅隐藏展示，不影响持久化与上下文。
-- `pending/q4h/subdialog-*` 等 runtime state 不会被恢复。
+- `pending/q4h/sideDialog-*` 等 runtime state 不会被恢复。
 
 ## 保存启动脚本（WebUI）
 
@@ -168,7 +168,7 @@ Darwin ...
 - 同时导出“当前 reminder 快照”到顶层 frontmatter。
 - 空历史禁止导出。
 - frontmatter 记录来源对话（rootId/selfId/course/status）。
-- `pending/q4h/subdialog-*` 等 runtime state 不导出；这是当前设计下的显式语义降级。
+- `pending/q4h/sideDialog-*` 等 runtime state 不导出；这是当前设计下的显式语义降级。
 
 ## recent 使用记录
 

package/dist/docs/app-constitution.md

@@ -107,7 +107,7 @@ The kernel is the Dominds host runtime: dialog driving, tool calling, persistenc
 An app is a distributable capability package, typically a **Node.js project (with `package.json`)**, that may provide:
 
 - Tools (tool/toolset) callable by the kernel (or other apps via the kernel).
-- Teammates (agents) that can be responders, can be told/asked, or act as “bridge” members.
+- Teammates (agents) that can become Dialog Responders, receive Tellasks, or act as “bridge” members.
 - `.minds/**` assets describing and composing team, tool integrations (e.g. MCP), environment requirements, etc.
 
 > Note: An app may _also_ be a Python (uv) project (with `pyproject.toml`) to expose CLIs/wrappers.

package/dist/docs/app-constitution.zh.md

@@ -106,7 +106,7 @@ Kernel 是 Dominds 的宿主运行时：负责对话驱动、工具调用、持
 App 是一个可分发/可安装的能力包，通常是一个 **Node.js 项目（含 `package.json`）**，并提供：
 
 - 工具（tool / toolset）：供 Kernel（或其它 app）在对话中调用。
-- 智能体队友（teammates）：可被选为 responder、被 tellask、或作为“接头人/桥接器”。
+- 智能体队友（teammates）：可担任对话主理人、被诉请，或作为“接头人/桥接器”。
 - `.minds/**` 资产：用来描述/装配团队、工具接入（如 MCP 配置）、环境变量需求说明等。
 
 > 备注：App **可以同时**是一个 Python（uv）项目（含 `pyproject.toml`），用于提供命令行入口/封装脚本。

package/dist/docs/cli-usage.md

@@ -208,7 +208,7 @@ Each dialog directory typically contains:
 - `dialog.yaml` - Dialog metadata
 - `latest.yaml` - Current turn + lastModified tracking
 - `course-001.jsonl` (and more) - Streamed message log
-- `subdialogs/` - Nested subdialogs
+- `sideDialogs/` - Nested sideDialogs
 
 ## Error Handling
 

package/dist/docs/cli-usage.zh.md

@@ -220,7 +220,7 @@ dominds read
 - `dialog.yaml` - 对话元数据
 - `latest.yaml` - 当前对话过程编号 + lastModified 跟踪
 - `course-001.jsonl`（第 1 程对话，后续还可以有编号递增的多程）- 流式消息文件
-- `subdialogs/` - 嵌套子对话
+- `sideDialogs/` - 嵌套支线对话
 
 ## 错误处理
 

package/dist/docs/design.md

@@ -330,24 +330,24 @@ Agent: [Clean mental state + Taskdoc only] + Specific sub-problem
 
 ## Architectural Patterns
 
-### Dialog Hierarchy
+### Dialog Tree
 
 ```
 
-Main Dialog (Root Dialog)
+Main Dialog
 ├── Taskdoc Reference → tasks/feature-auth.tsk/ (rtws Taskdoc package)
 ├── Reminders (Working Memory)
 ├── Dialog Messages (Ephemeral)
-└── Subdialogs (Tree-Structured, Stored Flat Under Main Dialog)
+└── SideDialogs (Tree-Structured, Stored Flat Under Main Dialog)
 ├── Specialized Agent A
 │ ├── Taskdoc Reference → tasks/feature-auth.tsk/ (Same Taskdoc package)
-│ ├── Parent Call Context
+│ ├── Asker Call Context
 │ ├── Local Reminders
 │ └── Local Dialog Messages
-│ └── Sub-Subdialogs (Further Nesting Possible)
+│ └── Nested SideDialogs (Further Nesting Possible)
 └── Specialized Agent B
 ├── Taskdoc Reference → tasks/feature-auth.tsk/ (Same Taskdoc package)
-├── Parent Call Context
+├── Asker Call Context
 ├── Local Reminders
 └── Local Dialog Messages
 
@@ -358,9 +358,9 @@ Main Dialog (Root Dialog)
 - All dialogs reference the same rtws Taskdoc (a `*.tsk/` Taskdoc package, e.g. `tasks/feature-auth.tsk/`)
 - Multiple dialog trees can reference the same Taskdoc for collaborative work
 - Taskdocs persist beyond individual conversations and survive team changes
-- Subdialogs can be tree-structured with unlimited nesting depth
-- All subdialog state is stored flat under the main dialog's (root dialog's) `subdialogs/` directory
-- Each subdialog maintains its own working memory while referencing the same Taskdoc
+- SideDialogs can be tree-structured with unlimited nesting depth
+- All sideDialog state is stored flat under the main dialog's `sideDialogs/` directory
+- Each sideDialog maintains its own working memory while referencing the same Taskdoc
 
 ### Memory Layers
 
@@ -372,7 +372,7 @@ Main Dialog (Root Dialog)
    - Taskdocs persist throughout the entire product lifecycle, spanning multiple conversations and team changes
    - Can link to other product documentation and evolve as project requirements change
 2. **Reminders**: Semi-persistent, dialog-scoped, survives conversation cleanup
-3. **Parent Call Context**: Inherited context for subdialogs
+3. **Asker Call Context**: Inherited context for sideDialogs
 4. **Dialog Messages**: Ephemeral, subject to cleanup for mental clarity
 
 #### rtws-Persistent Memory (DevOps Lifecycle)
@@ -398,9 +398,9 @@ Main Dialog (Root Dialog)
 
 ### Information Flow
 
-- **Upward**: Subdialogs communicate results and escalations to parents
-- **Downward**: Parents provide context and objectives to subdialogs
-- **Lateral**: Coordination through shared Taskdocs and parent mediation
+- **Tellasker-bound**: SideDialogs communicate results and escalations to tellaskers
+- **Side-bound**: Tellaskers provide context and objectives to sideDialogs
+- **Lateral**: Coordination through shared Taskdocs and tellasker mediation
 - **Temporal**: Reminders and Taskdocs provide continuity across time
 
 ---
@@ -417,7 +417,7 @@ For detailed implementation specifications, including core tools, technical arch
 - **Hierarchical Dialog Architecture**: Tree-structured dialogs with flat storage and autonomous management
 - **Memory Layers**: Dialog-scoped and rtws-persistent memory with autonomous evolution
 
-The implementation emphasizes autonomous agent operation, enabling agents to independently manage their cognitive state, create and manage subdialogs, and coordinate with minimal human oversight.
+The implementation emphasizes autonomous agent operation, enabling agents to independently manage their cognitive state, create and manage sideDialogs, and coordinate with minimal human oversight.
 
 ---
 

package/dist/docs/design.zh.md

@@ -332,23 +332,23 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 
 ## 架构模式
 
-### 对话层次结构
+### 对话树结构
 
 ```
-主对话（根对话）
+主线对话
 ├── 差遣牒引用 → tasks/feature-auth.tsk/（rtws 任务包）
 ├── 提醒项（工作记忆）
 ├── 聊天消息（临时）
-└── 子对话（树结构，扁平存储在主对话下）
+└── 支线对话（树结构，扁平存储在主线对话下）
     ├── 专业智能体 A
     │   ├── 差遣牒引用 → tasks/feature-auth.tsk/（相同的任务包）
-    │   ├── 父调用上下文
+    │   ├── 诉请者上下文
     │   ├── 本地提醒项
     │   └── 本地聊天消息
-    │   └── 子子对话（可进一步嵌套）
+    │   └── 嵌套支线对话（可进一步嵌套）
     └── 专业智能体 B
         ├── 差遣牒引用 → tasks/feature-auth.tsk/（相同的任务包）
-        ├── 父调用上下文
+        ├── 诉请者上下文
         ├── 本地提醒项
         └── 本地聊天消息
 ```
@@ -358,9 +358,9 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 - 所有对话引用相同的 rtws 差遣牒（一个 `*.tsk/` 任务包，例如 `tasks/feature-auth.tsk/`）
 - 多个对话树可以引用相同的差遣牒进行协作工作
 - 差遣牒超越单个对话持续存在并经历团队变化
-- 子对话可以是具有无限嵌套深度的树结构
-- 所有子对话状态扁平存储在主对话的 `subdialogs/` 目录下
-- 每个子对话在引用相同差遣牒的同时维护自己的工作记忆
+- 支线对话可以是具有无限嵌套深度的树结构
+- 所有支线对话状态扁平存储在主线对话的 `sideDialogs/` 目录下
+- 每个支线对话在引用相同差遣牒的同时维护自己的工作记忆
 
 ### 记忆层
 
@@ -372,7 +372,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
    - 差遣牒在整个产品生命周期中持续存在，跨越多个对话和团队变化
    - 可以链接到其他产品文档并随项目要求演变
 2. **提醒项**：半持久化、对话范围，在对话清理中存活
-3. **父调用上下文**：子对话继承的上下文
+3. **诉请者上下文**：支线对话继承的上下文
 4. **聊天消息**：临时，受清理以保持心理清晰
 
 #### rtws 持久化记忆（DevOps 生命周期）
@@ -398,9 +398,9 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 
 ### 信息流
 
-- **向上**：子对话向父级传达结果和升级
-- **向下**：父级向子对话提供上下文和目标
-- **横向**：通过共享差遣牒和父级调解进行协调
+- **面向诉请者**：支线对话向诉请者传达结果和升级
+- **面向支线**：诉请者向支线对话提供上下文和目标
+- **横向**：通过共享差遣牒和诉请者调解进行协调
 - **时间性**：提醒项和差遣牒提供跨时间的连续性
 
 ---
@@ -417,7 +417,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 - **层次对话架构**：具有扁平存储和自主管理的树结构对话
 - **记忆层**：具有自主演进的对话范围和 rtws 持久化记忆
 
-该实现强调自主智能体操作，使智能体能够独立管理其认知状态、创建和管理子对话，并在最少的人工监督下进行协调。
+该实现强调自主智能体操作，使智能体能够独立管理其认知状态、创建和管理支线对话，并在最少的人工监督下进行协调。
 
 ---
 

package/dist/docs/dialog-persistence.md

@@ -47,7 +47,7 @@ The implementation follows this architecture.
 
 ### Design Principles
 
-- **Flat Subdialog Storage**: All subdialogs are stored flat under the main dialog's (root dialog's) `subdialogs/` directory, regardless of nesting depth
+- **Flat SideDialog Storage**: All sideDialogs are stored flat under the main dialog's `sideDialogs/` directory, regardless of nesting depth
 - **Append-Only Streams**: Message streams are append-only for audit trails and replay capability
 - **Atomic Operations**: All persistence operations are atomic to prevent corruption
 - **Human-Readable Formats**: Storage uses YAML and JSONL for transparency and debugging
@@ -160,42 +160,42 @@ These paths are enforced by the memory tools (see `main/tools/mem.ts`) and loade
 **DialogID Schema**: The system uses a `self+root` ID schema implemented in the `DialogID` class:
 
 - **selfDlgId**: The unique identifier for this specific dialog instance
-- **rootDlgId**: The identifier for the root dialog in the hierarchy (defaults to selfDlgId for root dialogs)
+- **rootDlgId**: The identifier for the main dialog in the hierarchy (defaults to selfDlgId for main dialogs)
 - **Serialization**: When `rootDlgId` differs from `selfDlgId`, the full ID is formatted as `rootDlgId#selfDlgId`; otherwise, it's just `selfDlgId`
 
-This schema enables efficient management of subdialog relationships while maintaining unique identification for each dialog instance.
+This schema enables efficient management of sideDialog relationships while maintaining unique identification for each dialog instance.
 
 ### Design Rationale
 
 The `self+root` ID schema was implemented to address several challenges in dialog management:
 
-1. **Hierarchical Relationship Tracking**: Provides clear lineage information for each dialog, making it easy to trace subdialogs back to their root dialog
-2. **Efficient Storage Organization**: Allows for flat storage of subdialogs while preserving relationship information
-3. **Unique Identification**: Ensures each dialog instance has a unique identifier, even when multiple subdialogs exist
+1. **Hierarchical Relationship Tracking**: Provides clear lineage information for each dialog, making it easy to trace sideDialogs back to their main dialog
+2. **Efficient Storage Organization**: Allows for flat storage of sideDialogs while preserving relationship information
+3. **Unique Identification**: Ensures each dialog instance has a unique identifier, even when multiple sideDialogs exist
 4. **Simplified Persistence**: Enables straightforward serialization and deserialization of dialog relationships
 5. **Improved Debugging**: Provides clear identification in logs and debugging information
-6. **Scalability**: Supports deep subdialog hierarchies without complex storage structures
+6. **Scalability**: Supports deep sideDialog hierarchies without complex storage structures
 
 This design balances the need for clear hierarchical relationships with efficient storage and retrieval operations.
 
 ### Active Dialog Structure
 
 ```
-.dialogs/run/<rootDialogId>/
+.dialogs/run/<mainDialogId>/
 ├── dialog.yaml               # Dialog metadata with strong typing
 ├── latest.yaml               # Current course and lastModified tracking
 ├── reminders.json            # Persistent reminders
 ├── <course>.jsonl            # Streamed messages for each course
 ├── <course>.yaml             # Course metadata
 ├── artifacts/                # Binary artifacts (e.g. MCP tool output images; referenced by func_result_msg.contentItems)
-└── subdialogs/               # Flat subdialog storage
-    ├── <subDialogId1>/       # First-level subdialog
-    │   ├── dialog.yaml       # Subdialog metadata
-    │   ├── latest.yaml       # Subdialog current state
-    │   ├── reminders.json    # Subdialog reminders
-    │   ├── <course>.jsonl    # Subdialog events
-    │   └── <course>.yaml     # Subdialog course metadata
-    └── <subDialogId2>/       # Another subdialog
+└── sideDialogs/               # Flat sideDialog storage
+    ├── <subDialogId1>/       # First-level sideDialog
+    │   ├── dialog.yaml       # SideDialog metadata
+    │   ├── latest.yaml       # SideDialog current state
+    │   ├── reminders.json    # SideDialog reminders
+    │   ├── <course>.jsonl    # SideDialog events
+    │   └── <course>.yaml     # SideDialog course metadata
+    └── <subDialogId2>/       # Another sideDialog
         ├── dialog.yaml
         ├── latest.yaml
         ├── reminders.json
@@ -212,9 +212,9 @@ This design balances the need for clear hierarchical relationships with efficien
 
 In this structure:
 
-- Root dialogs have `selfDlgId` equal to `rootDlgId`
-- Subdialogs have distinct `selfDlgId` values with the same `rootDlgId` as their parent
-- Subdialog directories use only the `selfDlgId` for file system organization
+- Main dialogs have `selfDlgId` equal to `rootDlgId`
+- SideDialogs have distinct `selfDlgId` values with the same `rootDlgId` as their parent
+- SideDialog directories use only the `selfDlgId` for file system organization
 - Metadata stores only the `selfDlgId`; full `rootDlgId#selfDlgId` is reconstructed during loading
 - The full `rootDlgId#selfDlgId` format is used for in-memory identification and operations
 
@@ -222,25 +222,25 @@ In this structure:
 
 Modern strongly-typed dialog metadata using TypeScript interfaces:
 
-#### Root Dialog Example
+#### Main Dialog Example
 
 ```yaml
 id: 'aa/bb/cccccccc' # Unique dialog identifier (selfDlgId only)
 agentId: 'alice' # Agent responsible for this dialog
 taskDocPath: 'task.tsk' # Path to the rtws Taskdoc package directory
 createdAt: '2024-01-15T10:30:00Z' # ISO timestamp when created
-# No parent fields for root dialogs
+# No parent fields for main dialogs
 ```
 
-#### Subdialog Example
+#### SideDialog Example
 
 ```yaml
 id: 'dd/ee/ffffffff' # Unique dialog identifier (selfDlgId only)
 agentId: 'bob' # Agent responsible for this dialog
 taskDocPath: 'task.tsk' # Path to rtws Taskdoc package directory (inherited from parent)
 createdAt: '2024-01-15T10:35:00Z' # ISO timestamp when created
-supdialogId: 'aa/bb/cccccccc' # Parent dialog's selfDlgId
-assignmentFromSup: # Assignment context from parent
+askerDialogId: 'aa/bb/cccccccc' # Parent dialog's selfDlgId
+assignmentFromAsker: # Assignment context from parent
   mentionList: ['@bob']
   tellaskContent: 'Implement user authentication; create secure login system with JWT tokens'
   originMemberId: 'alice'
@@ -257,7 +257,7 @@ currentCourse: 3 # Current course number (1-based)
 lastModified: '2024-01-15T11:45:00Z' # ISO timestamp of last activity
 messageCount: 12 # Total messages in current course
 functionCallCount: 3 # Total function calls in current course
-subdialogCount: 1 # Total subdialogs created
+sideDialogCount: 1 # Total sideDialogs created
 status: 'active' # Current dialog status
 ```
 
@@ -266,7 +266,7 @@ status: 'active' # Current dialog status
 - New message events
 - Course transitions
 - Function call results
-- Subdialog creation
+- SideDialog creation
 - Any dialog modification
 
 **UI Integration**: Dialog list displays `lastModified` timestamp from this file for accurate sorting and display.
@@ -302,7 +302,7 @@ Simple text file containing the current course number:
 
 ### Root-generation anchors and reconciliation records
 
-To support root dialog fork, persistence now records which root-generation viewpoint a piece of dialog state belongs to.
+To support main dialog fork, persistence now records which root-generation viewpoint a piece of dialog state belongs to.
 
 **Root-generation anchor**:
 
@@ -311,25 +311,25 @@ To support root dialog fork, persistence now records which root-generation viewp
 
 **Purpose**:
 
-- Any state snapshot that must stay aligned across the entire root dialog tree must be anchored to the root generation rather than each subdialog's local course/genseq
+- Any state snapshot that must stay aligned across the entire main dialog tree must be anchored to the root generation rather than each sideDialog's local course/genseq
 - When forking at `(course, genseq)`, the retained state is the latest consistent snapshot at or before `(rootCourse=course, rootGenseq=genseq-1)`
 
 **New / strengthened persisted records**:
 
-- `subdialog_created_record`
+- `sideDialog_created_record`
   - persisted in the root transcript
-  - marks when a subdialog already exists on the root timeline, so fork can decide whether to include it
+  - marks when a sideDialog already exists on the root timeline, so fork can decide whether to include it
 - `reminders_reconciled_record`
 - `questions4human_reconciled_record`
-- `pending_subdialogs_reconciled_record`
-- `subdialog_registry_reconciled_record`
-- `subdialog_responses_reconciled_record`
+- `pending_sideDialogs_reconciled_record`
+- `sideDialog_registry_reconciled_record`
+- `sideDialog_responses_reconciled_record`
 
 **Required behavior**:
 
 - These reconciliation records are state snapshots, not LLM transcript content; message reconstruction must skip them
-- Any subdialog transcript record that participates in root-fork cutoff trimming must carry `rootCourse/rootGenseq`
-- When writing a forked root, persistence appends a baseline reconciliation set into `course-1` so reminders / Q4H / pending subdialogs / registry / responses are restored to the pre-cutoff state
+- Any sideDialog transcript record that participates in root-fork cutoff trimming must carry `rootCourse/rootGenseq`
+- When writing a forked main dialog, persistence appends a baseline reconciliation set into `course-1` so reminders / Q4H / pending sideDialogs / registry / responses are restored to the pre-cutoff state
 
 ---
 
@@ -394,14 +394,14 @@ started_at: '2024-01-15T11:30:00Z'
 completed_at: '2024-01-15T11:45:00Z'
 message_count: 12
 function_calls: 3
-subdialogs_created: 1
+sideDialogs_created: 1
 status: 'completed'
 ```
 
 ### Taskdoc Storage
 
 Taskdocs are rtws artifacts that exist independently and are referenced by dialogs through paths.
-In practice, the Taskdoc is also the task’s **live coordination bulletin board** across mainlines/agents.
+In practice, the Taskdoc is also the task’s **live coordination bulletin board** across Main Dialogs/agents.
 Taskdocs MUST be encapsulated Taskdoc packages (`*.tsk/`).
 
 ```yaml
@@ -456,7 +456,7 @@ The following operations are implemented.
 ### Dialog Creation
 
 1. Generate unique dialog ID using `generateDialogID()`
-2. Create `DialogID` instance with `selfDlgId` and `rootDlgId` (rootDlgId defaults to selfDlgId for root dialogs)
+2. Create `DialogID` instance with `selfDlgId` and `rootDlgId` (rootDlgId defaults to selfDlgId for main dialogs)
 3. Create dialog directory structure
 4. Write initial `dialog.yaml` metadata with the serialized DialogID
 5. Initialize `latest.yaml` to `currentCourse: 1`
@@ -470,28 +470,28 @@ The following operations are implemented.
 3. Increment course counter if starting a new course
 4. Ensure atomic writes to prevent corruption
 
-### Subdialog Creation
+### SideDialog Creation
 
-1. Generate unique subdialog ID using `generateDialogID()`
+1. Generate unique sideDialog ID using `generateDialogID()`
 2. Create `DialogID` instance with:
-   - `selfDlgId`: the newly generated subdialog ID
-   - `rootDlgId`: inherited from the supdialog's `rootDlgId`
-3. Create subdialog directory under parent's `subdialogs/` (using only `selfDlgId` for directory name)
+   - `selfDlgId`: the newly generated sideDialog ID
+   - `rootDlgId`: inherited from the askerDialog's `rootDlgId`
+3. Create sideDialog directory under parent's `sideDialogs/` (using only `selfDlgId` for directory name)
 4. Set Taskdoc path reference from parent
 5. Set parent call context in metadata
-6. Initialize subdialog state, storing only `selfDlgId` in metadata
+6. Initialize sideDialog state, storing only `selfDlgId` in metadata
 7. The full `DialogID` with `rootDlgId` is reconstructed during loading based on directory structure
 
 ### Dialog Completion
 
 1. Update dialog status to "completed"
 2. Finalize all course metadata
-3. For root dialogs:
+3. For main dialogs:
    - Move dialog directory from `run/` to `done/`
-   - Include all subdialogs in the move
-4. For subdialogs:
+   - Include all sideDialogs in the move
+4. For sideDialogs:
    - Update status in metadata
-   - Notify supdialog of completion using the full serialized DialogID
+   - Notify askerDialog of completion using the full serialized DialogID
 5. Archive old dialogs based on retention policy
 
 ### Memory Updates
@@ -524,7 +524,7 @@ The following operations are implemented.
 
 ### Storage Optimization
 
-**Flat Subdialog Storage**: Prevents deep directory nesting that can impact filesystem performance.
+**Flat SideDialog Storage**: Prevents deep directory nesting that can impact filesystem performance.
 
 **Append-Only Streams**: Optimizes for write performance and enables efficient streaming.
 
@@ -592,14 +592,14 @@ The persistence layer has been **completely modernized** with no backward compat
 - **Real-time Tracking**: Current course and lastModified timestamps
 - **Atomic Updates**: Automatically updated on all dialog modifications
 - **UI Integration**: Dialog list displays accurate timestamps from persisted records
-- **Status Management**: Tracks dialog status, message counts, and subdialog counts
+- **Status Management**: Tracks dialog status, message counts, and sideDialog counts
 
 #### ✅ Modern Persistence Layer (`main/persistence.ts`)
 
 - **Type-Safe Operations**: All methods use strong TypeScript interfaces
 - **Atomic File Operations**: All writes use temporary files + rename pattern
 - **Automatic Timestamps**: latest.yaml updated automatically on events
-- **Unified APIs**: Consistent interface for root dialogs and subdialogs
+- **Unified APIs**: Consistent interface for main dialogs and sideDialogs
 
 #### ✅ Updated API Layer (`main/server/api-routes.ts`)
 
@@ -645,20 +645,20 @@ The redesigned file organization should support both streaming and restoration m
 rtws/
 ├── dialogs/
 │   ├── active/           # Currently streaming dialogs
-│   │   ├── {root-dialog-id}/    # Root dialog directory (selfDlgId = rootDlgId)
+│   │   ├── {main-dialog-id}/    # Main dialog directory (selfDlgId = rootDlgId)
 │   │   │   ├── stream.jsonl      # Append-only message stream
 │   │   │   ├── metadata.yaml     # Dialog configuration and state
 │   │   │   ├── checkpoints/      # Periodic state snapshots
 │   │   │   ├── temp/             # Temporary files during streaming
-│   │   │   └── subdialogs/       # Subdialog storage
-│   │   │       └── {sub-dialog-id}/  # Subdialog directory (uses only selfDlgId)
+│   │   │   └── sideDialogs/       # SideDialog storage
+│   │   │       └── {side-dialog-id}/  # SideDialog directory (uses only selfDlgId)
 │   │   │           ├── stream.jsonl
 │   │   │           ├── metadata.yaml
 │   │   │           └── checkpoints/
 │   │   └── index.json            # Fast lookup for active dialogs
 │   ├── archived/         # Completed/paused dialogs
 │   │   ├── {date}/              # Organized by completion date
-│   │   │   ├── {root-dialog-id}.tar.gz  # Compressed dialog archive with subdialogs
+│   │   │   ├── {main-dialog-id}.tar.gz  # Compressed dialog archive with sideDialogs
 │   │   │   └── metadata.json       # Archive metadata
 │   │   └── index.json            # Archive lookup index
 │   └── templates/        # Dialog templates and presets
@@ -668,8 +668,8 @@ rtws/
 
 In this proposed structure:
 
-- Root dialogs are organized by their `root-dialog-id`
-- Subdialogs are stored within their root dialog's `subdialogs/` directory, using only their `selfDlgId` for directory names
+- Main dialogs are organized by their `main-dialog-id`
+- SideDialogs are stored within their main dialog's `sideDialogs/` directory, using only their `selfDlgId` for directory names
 - Metadata stores only the `selfDlgId` in the `id` field
 - The full `rootDlgId#selfDlgId` format is reconstructed during loading and used in indexes for efficient lookup
 
@@ -732,7 +732,7 @@ The key innovation is creating a **seamless interface** between streaming and di
 
 #### File System Reliability
 
-- **Error Recovery**: Handle file system errors gracefully with retry logic
+- **Error Recovery**: Report file-system errors loudly and retry only where the operation is explicitly designed to be retryable
 - **Corruption Detection**: Use checksums to detect and handle file corruption
 - **Backup Strategy**: Regular backups of critical dialog data
 - **Cleanup Policies**: Automatic cleanup of temporary and obsolete files