dominds 1.3.1 → 1.4.2

package/dist/docs/keep-going.md

@@ -1,176 +0,0 @@
-# Keep-Going (Diligence Auto-Continue) — Design Doc
-
-## Summary
-
-Dominds root dialogs are intended for long-run operation. A root dialog “stopping” (becoming idle)
-is often not what operators want: they want the agent to keep pushing forward until it either:
-
-- legitimately suspends for a human decision (Q4H), or
-- legitimately suspends waiting for subdialogs (tellask/backfill).
-
-This document specifies a runtime mechanism (“keep-going”) that, for **root/main dialogs only**,
-prevents the dialog from stopping: whenever the driver would otherwise stop, it auto-sends a short
-diligence prompt (rendered as a normal user bubble) and continues generation, except when the dialog
-is legitimately suspended (Q4H or pending subdialogs).
-
-## Goals
-
-- Prevent root dialogs from stopping except for legitimate suspension states (Q4H / subdialogs).
-- Keep behavior predictable and bounded (no infinite loops).
-- Make the nudge text configurable per workspace (rtws) and language.
-- Provide a clear, user-controlled “disable” mechanism.
-
-## Non-goals
-
-- Auto-completing / auto-marking a dialog as done.
-- Applying this behavior to subdialogs (subdialogs remain scoped and should report back to their caller).
-
-## Definitions
-
-- **Root/main dialog**: a `RootDialog` (`dlg.id.rootId === dlg.id.selfId`), the primary conversation thread.
-- **Subdialog**: a `SubDialog`, created for tellask / scoped work.
-- **Q4H**: “Questions for Human”, initiated via `!?@human`, which suspends dialog progression until the human responds.
-
-## Expected “normal” completion path (recommended)
-
-When the agent needs a human decision to conclude (e.g., confirm a choice or decide whether to mark the dialog done), the correct path is:
-
-1. The agent issues a Q4H (`!?@human`) with the necessary context and explicit decision request.
-2. The WebUI surfaces the Q4H clearly.
-3. The human decides and either:
-   - marks the root dialog “done” manually, or
-   - provides the requested info so the dialog can proceed.
-
-This is the “controlled convergence” path. The keep-going mechanism should **not** override legitimate suspension states.
-
-## Keep-going behavior (“auto-continue” fallback)
-
-### Trigger conditions (must all hold)
-
-- Dialog is the **root/main dialog** (never for subdialogs).
-- Dialog is **not suspended**:
-  - no pending Q4H, and
-  - no pending subdialogs (waiting for backfill).
-- The driver would otherwise stop the generation loop (i.e., no tool/function outputs require another iteration).
-
-### Action
-
-The runtime auto-sends a diligence prompt (rendered as a normal user bubble) and runs another
-generation iteration.
-
-### Boundedness
-
-To avoid infinite loops, keep-going has a per-dialog budget (per-member `diligence-push-max`) that controls
-how many auto-continued diligence prompts can be injected for a given dialog before the runtime forces a
-Q4H suspension.
-
-- Default: **3**
-- If `< 1`, keep-going is effectively disabled for that member
-- Configurable per-member via `diligence-push-max` in `.minds/team.yaml`
-
-### Reset on Q4H
-
-When a dialog becomes suspended due to a pending Q4H (Questions for Human), the keep-going injection
-counter is reset. This ensures that after the human answers the Q4H and the dialog is resumed, the
-dialog gets a fresh keep-going budget again.
-
-### Budget exhausted → force Q4H
-
-When the keep-going budget is exhausted, the runtime creates a Q4H entry that asks the human whether
-to continue or stop. This converts “boundedness” into a legitimate suspension point and avoids
-infinite auto-continue loops.
-
-### Disable switch
-
-Keep-going can be disabled per-rtws in either of these ways:
-
-- If the selected diligence file exists but its content is empty/whitespace, keep-going is disabled (no injection).
-
-Keep-going can be disabled per-member in either of these ways:
-
-- If `diligence-push-max < 1`, keep-going is disabled for that member (no injection).
-
-## Diligence prompt resolution
-
-Let `<rtws>` be the current runtime workspace (i.e., `process.cwd()`).
-
-Resolution order:
-
-1. `<rtws>/.minds/diligence.<work-lang-id>.md` (e.g., `diligence.zh.md`)
-2. `<rtws>/.minds/diligence.md` (language-agnostic fallback)
-3. Built-in fallback text (hardcoded i18n; `zh` is canonical and embedded in source)
-
-If the first existing file in the above order has empty/whitespace content, **disable** keep-going.
-
-Note: YAML frontmatter in diligence files is **ignored** by the runtime. If present, it is treated as
-non-content metadata and stripped from the prompt body.
-
-### Team member cap: `diligence-push-max`
-
-Each team member can optionally cap keep-going via `.minds/team.yaml`:
-
-```yaml
-members:
-  alice:
-    diligence-push-max: 10
-```
-
-Rules:
-
-- If missing, `diligence-push-max` defaults to **3** for that member.
-- If `diligence-push-max < 1`, keep-going is disabled for that member (no injection), even if the diligence file exists.
-- Built-in shadow members `fuxi` and `pangu` default to `diligence-push-max: 0` unless explicitly overridden in team.yaml.
-
-## UX notes
-
-- Keep-going is a runtime-only nudge, but it should be **visible**: the diligence prompt is rendered
-  as a normal user message bubble (auto-sent by the runtime) so operators can understand why an
-  extra iteration occurred.
-- Users should observe that the agent continues with a brief follow-up after tool-only operations.
-- When the agent truly needs user intervention, it should use Q4H. Keep-going should not try to “fake” completion.
-
-## Implementation (backend)
-
-### Where
-
-Implemented in the LLM driver loop (`dominds/main/llm/driver.ts`) as a small post-iteration check:
-
-1. If `suspendForHuman` is true, stop (Q4H / subdialog pending).
-2. If there is any tool feedback, continue normally.
-3. Otherwise (root only), attempt keep-going auto-continue:
-   - If disabled → stop normally.
-   - If budget exhausted → create Q4H and stop.
-   - Else → auto-send diligence prompt and continue.
-
-### Message type
-
-We inject the diligence prompt as an auto-sent user message:
-
-- `ChatMessage` of type `prompting_msg` with `role: 'user'`
-
-This ensures:
-
-- It is present in the model context
-- It is persisted as a human message record
-- It renders in the chat timeline as a normal user bubble (like any other user message)
-
-## Observability
-
-Recommended follow-ups (not required for initial implementation):
-
-- Add a structured log line when keep-going is triggered, including:
-  - dialog id
-  - language
-  - which diligence source was used (lang-specific / generic / built-in / disabled)
-- Optional metrics counter for “keep-going triggered” and “keep-going disabled by empty file”.
-
-## Testing
-
-Regression tests should cover:
-
-- Root dialog: tool-only output → diligence injection → continued response
-- Root dialog: empty assistant output → diligence injection → continued response
-- Subdialog: no diligence injection
-- Workspace config:
-  - `.minds/diligence.md` is honored when lang-specific file is absent
-  - empty diligence file disables keep-going

package/dist/docs/keep-going.zh.md

@@ -1,162 +0,0 @@
-# Keep-Going（鞭策）— 设计文档
-
-## 概述
-
-Dominds 根对话旨在长期运行。根对话"停止"（变为空闲）通常不是操作员想要的：他们希望智能体持续推进，直到：
-
-- 合法地暂停等待人类决策（Q4H），或
-- 合法地暂停等待子对话（tellask/backfill）。
-
-本文档指定了一个运行时机制（"keep-going"），仅针对**根/主对话**，防止对话停止：每当驱动程序即将停止时，它会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的子对话）。
-
-## 目标
-
-- 防止根对话停止，除非处于合法暂停状态（Q4H / 子对话）。
-- 保持行为可预测和有界（无无限循环）。
-- 使鞭策语文本可按工作区（rtws）和语言配置。
-- 提供清晰的用户控制的"禁用"机制。
-
-## 非目标
-
-- 自动完成/自动将对话标记为完成。
-- 将此行为应用于子对话（子对话保持范围，应向其调用者报告）。
-
-## 定义
-
-- **根/主对话**：`RootDialog`（`dlg.id.rootId === dlg.id.selfId`），主要对话线程。
-- **子对话**：`SubDialog`，为 tellask / 作用域工作创建。
-- **Q4H**："Questions for Human"，通过 `!?@human` 发起，暂停对话进度直到人类响应。
-
-## 预期的"正常"完成路径（推荐）
-
-当智能体需要人类决策来结束时（例如，确认选择或决定是否将对话标记为完成），正确的路径是：
-
-1. 智能体发出 Q4H（`!?@human`）并提供必要的上下文和明确的决策请求。
-2. WebUI 清楚地呈现 Q4H。
-3. 人类决定并：
-   - 手动将根对话标记为"完成"，或
-   - 提供请求的信息以便对话继续。
-
-这是"受控收敛"路径。keep-going 机制不应覆盖合法的暂停状态。
-
-## Keep-Going 行为（"自动继续"回退）
-
-### 触发条件（必须全部满足）
-
-- 对话是**根/主对话**（绝不会是子对话）。
-- 对话**未暂停**：
-  - 没有待处理的 Q4H，并且
-  - 没有待处理的子对话（等待回填）。
-- 驱动程序即将停止生成循环（即没有工具/函数输出需要另一次迭代）。
-
-### 操作
-
-运行时自动发送一个鞭策语（渲染为正常的用户气泡）并运行另一次生成迭代。
-
-### 有界性
-
-为避免无限循环，keep-going 有一个按对话的预算（每个成员的 `diligence-push-max`），控制对于给定对话在运行时强制 Q4H 暂停之前可以注入多少个自动继续的鞭策语。
-
-- 默认值：**3**
-- 如果 `< 1`，则该成员的 keep-going 有效禁用
-- 可通过 `.minds/team.yaml` 中的 `diligence-push-max` 按成员配置
-
-### Q4H 时重置
-
-当对话因待处理的 Q4H（Questions for Human）而暂停时，keep-going 注入计数器会被重置。这确保在人类回答 Q4H 并恢复对话后，对话会获得新的 keep-going 预算。
-
-### 预算耗尽 → 强制 Q4H
-
-当 keep-going 预算耗尽时，运行时会创建一个 Q4H 条目，询问人类是否继续或停止。这将"有界性"转换为合法的暂停点，并避免无限自动继续循环。
-
-### 禁用开关
-
-可以通过以下任一方式按 rtws 禁用 keep-going：
-
-- 如果选中的鞭策语文件存在但其内容为空/仅空白，则禁用 keep-going（不注入）。
-
-可以通过以下任一方式按成员禁用 keep-going：
-
-- 如果 `diligence-push-max < 1`，则该成员的 keep-going 被禁用（不注入）。
-
-## 鞭策语解析
-
-让 `<rtws>` 为当前运行时工作区（即 `process.cwd()`）。
-
-解析顺序：
-
-1. `<rtws>/.minds/diligence.<work-lang-id>.md`（例如，`diligence.zh.md`）
-2. `<rtws>/.minds/diligence.md`（语言无关的回退）
-3. 内置回退文本（硬编码的 i18n；`zh` 是规范的并嵌入在源代码中）
-
-如果上述顺序中第一个存在的文件具有空/空白内容，则**禁用** keep-going。
-
-注意：鞭策语文件中的 YAML frontmatter 会被运行时忽略。如果存在，它被视为非内容元数据并从提示正文中剥离。
-
-### 团队成员上限：`diligence-push-max`
-
-每个团队成员可以选择通过 `.minds/team.yaml` 限制 keep-going：
-
-```yaml
-members:
-  alice:
-    diligence-push-max: 10
-```
-
-规则：
-
-- 如果缺失，`diligence-push-max` 对于该成员默认为 **3**。
-- 如果 `diligence-push-max < 1`，则该成员的 keep-going 被禁用（不注入），即使鞭策语文件存在。
-- 内置影子成员 `fuxi` 和 `pangu` 默认为 `diligence-push-max: 0`，除非在 team.yaml 中显式覆盖。
-
-## UX 备注
-
-- Keep-going 是一个仅运行时的提示，但它应该是**可见的**：鞭策语渲染为正常的用户消息气泡（由运行时自动发送），以便操作员理解为什么会出现额外的迭代。
-- 用户应该观察到智能体在仅工具操作后继续简短的跟进。
-- 当智能体真正需要用户干预时，它应该使用 Q4H。Keep-going 不应试图"假装"完成。
-
-## 实现（后端）
-
-### 位置
-
-在 LLM 驱动程序循环中实现（`dominds/main/llm/driver.ts`），作为迭代后的小检查：
-
-1. 如果 `suspendForHuman` 为 true，则停止（Q4H / 子对话待处理）。
-2. 如果有任何工具反馈，则正常继续。
-3. 否则（仅限根），尝试 keep-going 自动继续：
-   - 如果禁用 → 正常停止。
-   - 如果预算耗尽 → 创建 Q4H 并停止。
-   - 否则 → 自动发送鞭策语并继续。
-
-### 消息类型
-
-我们将鞭策语作为自动发送的用户消息注入：
-
-- 类型为 `prompting_msg`、角色为 `'user'` 的 `ChatMessage`
-
-这确保了：
-
-- 它存在于模型上下文中
-- 它作为人类消息记录持久化
-- 它在聊天时间线中渲染为正常的用户气泡（像任何其他用户消息一样）
-
-## 可观察性
-
-建议的后续步骤（初始实现不需要）：
-
-- 当触发 keep-going 时添加结构化日志行，包括：
-  - 对话 id
-  - 语言
-  - 使用的鞭策语来源（语言特定/通用/内置/禁用）
-- 为"keep-going 触发"和"keep-going 因空文件禁用"添加可选的指标计数器。
-
-## 测试
-
-回归测试应覆盖：
-
-- 根对话：仅工具输出 → 鞭策语注入 → 继续响应
-- 根对话：空助手输出 → 鞭策语注入 → 继续响应
-- 子对话：无鞭策语注入
-- 工作区配置：
-  - 当语言特定文件缺失时，`.minds/diligence.md` 被遵守
-  - 空的鞭策语文件禁用 keep-going

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

@@ -1,286 +0,0 @@
-# Kernel–App Architecture (Prototype v0.1)
-
-Chinese version: [中文版](./kernel-app-architecture.zh.md)
-
-## Scope and Goals
-
-This document describes the Kernel–App separation prototype in Dominds, covering:
-
-- Two-level namespace (kernel outer / app inner) and resolution rules
-- App install json (`app --json`) extensions
-- Export/import semantics and conflict handling
-- App defunc semantics
-- App integration manual (`app_integration_manual`)
-- App language policy (work/ui language and i18n)
-- Incremental override DSL for `<rtws>/.apps/<app-id>/team.yaml`
-
-The prototype code is used for **concept and functional validation**. This document is the main artifact for “driving the integrated plan forward” (stable reference for implementation/migration/review).
-
-## Non-goals
-
-- No protocol/schema versioning or compatibility strategy before 2.x
-- No sandbox isolation before 2.x
-- Run-control expansion is out of scope (will be specified in a dedicated doc)
-
-## Core Concepts
-
-- Kernel registry stays in the current Dominds state; built-in capabilities will gradually move out to apps.
-- Each app owns its own registry, **local-first, same-name override allowed**.
-- Apps do not register objects into the kernel registry.
-- Apps are isolated from each other; exchange only via explicit export/import.
-
-## Identity and Resolution
-
-### Namespaces
-
-- Two-level scope: `kernel` and `app`.
-- For runtime resolution, short IDs (e.g. `toolsetId`, `memberId`, `toolName`) follow current kernel conventions.
-- For logs/diagnostics/Problems/docs, we need a stable, source-qualified identifier, so we introduce **Qualified Id** (display/diagnostics only; not forced into the wire protocol):
-  - `kernel:<name>`
-  - `app:<appId>:<name>`
-
-### Resolution order (inside an app)
-
-For any resolution request (tool/toolset/member), the order is fixed:
-
-1. `local(app)` (app self-registered + imported objects)
-2. `kernel`
-
-Notes:
-
-- “Same-name override allowed” only applies when `local(app)` overrides `kernel`.
-- Apps never override each other; if imports create same-name conflicts inside `local(app)`, the app becomes defunc.
-
-## App install json (`app --json`)
-
-Add fields to `DomindsAppInstallJsonV1`:
-
-- `depends?: [{ appId: string; versionRange: string }]`
-- `exports?: { members?: string[]; toolsets?: string[] }`
-
-Rules:
-
-- Empty `exports` means nothing is importable.
-- `exports` only lists **single member / single toolset** IDs (fixed granularity).
-- `exports` may list multiple objects, but the minimal import unit is fixed to **a single member / a single toolset** (each import points to exactly one ID).
-- Exported members must come from `contributes.teammatesYamlRelPath`.
-- Exported toolsets must come from `contributes.toolsets`.
-
-## Registry and Resolution
-
-- App resolution order: **local(app) → kernel**.
-- Apps do not override each other; import conflicts put the app into defunc.
-- Kernel registry never receives app objects, so there is no removal from kernel registry.
-- A defunc app does not participate in resolution (but its objects are not “removed”, since they never entered the kernel registry).
-
-## Export / Import Semantics
-
-### Export
-
-- Declared by `exports` in app install json.
-- Kernel exposes app exports (API shape can be decided during implementation).
-
-### Import
-
-- **Members**: declared in app `team.yaml`.
-- **Toolsets**: declared in app `team.yaml`; loaded via dominds API and registered into the app registry.
-
-Suggested structure (example):
-
-```yaml
-imports:
-  members:
-    - app: foo_app
-      id: npc_foo
-  toolsets:
-    - app: bar_app
-      id: bar_toolset
-```
-
-### Conflicts and Dependency Failures
-
-- Import conflicts or dependency failures → app defunc.
-
-#### Conflict matrix (minimal rules)
-
-| Case                                                  | Result                         |
-| ----------------------------------------------------- | ------------------------------ |
-| Same name in `local(app)` vs `kernel`                 | Allowed (local shadows kernel) |
-| Imported member/toolset conflicts with app-local name | defunc                         |
-| Imported member/toolset conflicts with another import | defunc                         |
-| Import points to a non-exported object                | defunc                         |
-| depends not satisfied (missing/version mismatch)      | defunc                         |
-
-## Defunc Semantics
-
-- Defunc means the app is unusable.
-- No registry removal is needed (app registry is no longer used; kernel has no app objects).
-- Defunc reason should be recorded for diagnosis.
-
-### Defunc triggers (suggested enumeration)
-
-- `MANIFEST_INVALID`: missing/invalid install json fields.
-- `DEPENDENCY_MISSING` / `DEPENDENCY_VERSION_MISMATCH`: depends missing or not satisfied.
-- `EXPORTS_INVALID`: exports references missing member/toolset.
-- `IMPORT_NOT_EXPORTED`: import points to an object not declared in exports.
-- `IMPORT_CONFLICT`: same-name conflicts introduced by imports.
-- `TEAM_OVERRIDE_INVALID`: override DSL parse/validation failed for `<rtws>/.apps/<app-id>/team.yaml`.
-- `IMPORT_FETCH_FAILED`: fetching toolset metadata via API failed or returned invalid data.
-
-### Retry semantics (suggested)
-
-- Defunc is **retryable by default**: once dependencies/config are fixed, kernel retries loading the app on the next refresh cycle.
-- Retry does not mutate existing dialogs/history; it only affects future resolution/new calls.
-
-### Observability (suggested)
-
-- Defunc must surface in Problems (or equivalent), including at least: `appId`, `reasonKind`, `detail`, `firstSeenAt`, `lastSeenAt`, `retryable`, `suggestedAction`.
-- `app_integration_manual` call failures **must not trigger defunc** (they should be observable but not make the app unusable).
-
-## App Integration Manual (`app_integration_manual`)
-
-- Kernel-fixed tool: `app_integration_manual`
-- Params: `{ appId: string, language?: string }`
-  - If `language` is omitted, default to **work language**.
-- Kernel routes the call to the app host via IPC.
-- App can return static markdown or runtime-generated content.
-- Apps must provide zh/en content.
-- Failure does not trigger defunc (return an error is enough).
-
-## Language Policy
-
-- **Work language** comes from the `LANG` environment variable; kernel and app host inherit and it is immutable at runtime.
-- Apps must follow kernel work language for reasoning/logic content.
-- Apps may provide their own UI with a user-configurable UI language.
-- All apps must support at least zh/en.
-
-## Incremental Override DSL for `team.yaml`
-
-Override file: `<rtws>/.apps/<app-id>/team.yaml`
-
-- No `actions:` top level.
-- Domain-specific DSL with **add/replace/modify/delete**.
-- Each load applies actions; failures put the app into defunc.
-
-Example:
-
-```yaml
-version: 1
-
-add:
-  members:
-    - id: npc_new
-      value:
-        name: New NPC
-        toolsets: [trae_toolset]
-
-replace:
-  members:
-    - id: npc_old
-      value:
-        name: Old 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
-```
-
-Rules:
-
-- `modify_member` supports `set`/`unset`/`merge`; `merge` is a deep merge on objects.
-- All changes must pass existing team.yaml validation.
-- Conflicts or parse failures → app defunc.
-
-## Suggested Load Flow
-
-1. Resolve and register toolsets first (local toolsets + imports.toolsets), **including their tools**
-2. Read app built-in team.yaml
-3. Resolve imports.members
-4. Apply `<rtws>/.apps/<app-id>/team.yaml` overrides
-5. Validate (toolsets/tools are now resolvable)
-6. Success → register members into app registry
-7. Failure → app defunc
-
-## Review Packet
-
-This section is meant to let a reviewer validate and continue in ~30 minutes (without putting implementation details into Taskdoc progress).
-
-### Artifacts
-
-- Architecture (semantic source): `dominds/docs/kernel-app-architecture.zh.md`
-- English alignment: `dominds/docs/kernel-app-architecture.md`
-
-### Delta (recent changes)
-
-- WebSocket driving no longer accepts `runControlId/runControlInput` (run-control expansion is intentionally split into a dedicated doc).
-- apps-host run control result no longer supports `systemPromptPatch/prompt` (collapsed to a minimal continue/reject shape).
-- kernel-driver context-health driving logic is aligned with driver-v2 style (prototype-stage cleanup).
-
-### Minimal smoke (suggested)
-
-Given this is a prototype for concept/functional validation, this smoke list focuses on ensuring recent cleanups do not break existing paths:
-
-1. `pnpm -C dominds run lint:types` passes.
-2. If the current rtws has enabled apps: startup initializes apps-host and registers proxy tools for each app’s `contributes.toolsets` (no name collisions).
-3. WebUI dialog driving + Q4H answering no longer requires/sends `runControlId/runControlInput`.
-
-## Prototype Status and Gap List
-
-What is already present as a verifiable skeleton (facts only, not a completeness claim):
-
-- Apps runtime + apps-host IPC infrastructure exists (forks apps-host and forwards tool calls).
-- Proxy registration for app-declared `contributes.toolsets` exists (concept/functional validation).
-- App-declared dialog run controls can be registered (run-control semantic expansion is out of scope here).
-
-What is not yet closed / needs implementation-level landing points (the “status & issues” deliverable):
-
-- `depends/exports/imports` loading/validation/conflict handling is currently mostly at the spec level; needs implementation + end-to-end verification.
-- Defunc lifecycle state machine, Problems surfacing, retry/reload entrypoints need an implementation-closed loop (including logging/error taxonomy).
-- `<rtws>/.apps/<app-id>/team.yaml` override DSL: read/apply/validate landing points + regression.
-- Kernel-fixed `app_integration_manual(appId, language?)` tool + IPC routing needs implementation + regression.
-- Migration playbook (which built-ins to migrate first, rollback strategy, dogfooding gates) should be produced in the implementation phase.
-
-## Completion Criteria (Acceptance)
-
-This prototype-stage “integrated plan” document can be considered complete when:
-
-- It explicitly specifies: Identity/Resolution, defunc triggers + retry, imports/exports granularity + conflict matrix, team.yaml override DSL, and the `app_integration_manual` contract.
-- Key rules are written as “when X happens → the system does Y”, without requiring readers to infer behavior from source.
-- `kernel-app-architecture.zh.md` and this English version are kept consistent (zh is the semantic source of truth).
-
-## Key Anchors (existing code)
-
-- install json parsing: `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 parsing: `dominds/main/team.ts`
-- app teammates loader: `dominds/main/apps/teammates.ts`
-
----
-
-This document is a prototype-stage design draft; details may evolve during implementation.