dominds 0.6.2 → 0.6.4

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

@@ -0,0 +1,208 @@
+# 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

@@ -0,0 +1,177 @@
+# 做给祂看（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 默认用户可见，严禁输出密钥/敏感信息。

package/dist/docs/tellask-collab.md

@@ -0,0 +1,250 @@
+# Tellask Collaboration Best Practices (Draft)
+
+Chinese version: [中文版](./tellask-collab.zh.md)
+
+> Status: Draft  
+> Scope: this doc separates what is already implemented from what we should improve next.
+
+## 1. Why this doc exists
+
+Dominds already has a real Tellask runtime. The current pain is not syntax, but coordination behavior:
+
+- The tellasker receives a checkpoint-style reply and assumes the tellaskee is still executing in the background.
+- The tellasker narrates “what should happen next” instead of sending the next Tellask.
+
+That mismatch stalls execution while sounding productive.
+
+This document has three goals:
+
+- Restate the implemented runtime contract in practical terms.
+- Define an operator-friendly collaboration playbook.
+- Propose a fast root fix, centered on priming + system prompt updates.
+
+---
+
+## 2. Current runtime contract (already implemented)
+
+These points reflect current behavior in `dialog-system.md`, `fbr.md`, `dominds-agent-priming.md`, and `diligence-push.md`.
+
+### 2.1 Three Tellask modes
+
+- `TellaskBack`: `!?@tellasker`
+- `Tellask Session`: `!?@<teammate> !tellaskSession <slug>`
+- `Fresh Tellask`: `!?@<teammate>`
+
+### 2.2 What `Tellask Session` really means
+
+- `!tellaskSession <slug>` gives resumable addressing and reusable context.
+- It does not create an always-running worker.
+- Progress still happens one Tellask call at a time.
+
+Short version: a Tellask Session is a resumable thread, not autonomous background execution.
+
+### 2.3 Per-call lifecycle
+
+For teammate Tellasks, the runtime lifecycle is:
+
+1. Tellask is emitted.
+2. Caller waits while sideline runs.
+3. A response is supplied back.
+4. Caller resumes.
+
+Critical operational fact:
+
+- The current teammate response status is effectively `completed` or `failed`.
+- There is no “still running that same request” status after a response is delivered.
+
+So if more work is needed, the tellasker must issue the next Tellask explicitly.
+
+### 2.4 Diligence Push boundary
+
+- Diligence Push helps mainline avoid going idle.
+- It does not send teammate Tellasks on the agent’s behalf.
+- It is a pressure mechanism, not an execution orchestrator.
+
+---
+
+## 3. Primary failure mode and root cause
+
+### 3.1 Primary issue: checkpoint reply is misread as ongoing execution
+
+Observed behavior:
+
+- Mainline receives “phase 1 done”.
+- Mainline then says “waiting for them to continue”.
+- No new Tellask is sent, so progress stops.
+
+Root cause:
+
+- The model confuses session continuity with execution continuity.
+- It treats “same `tellaskSession`” as “still running” instead of “ready to be resumed by a new Tellask”.
+
+### 3.2 Secondary issue: narrative delegation instead of action
+
+Typical anti-pattern:
+
+- “I don’t have shell permission; please ask @<shell_specialist> to run `pnpm lint:types` and send back the output.”
+
+That is a workflow break. The model should send the Tellask directly.
+
+---
+
+## 4. Best-practice execution protocol
+
+### 4.1 Four-step teammate Tellask loop
+
+For teammate Tellasks (non-`!?@self`), always run this loop:
+
+1. `Initiate`: send a Tellask with scope, constraints, and acceptance evidence.
+2. `Wait`: wait for that specific response.
+3. `Judge`: classify response as done / not done / needs clarification.
+4. `Continue`: if not done, send the next Tellask immediately (usually same session slug).
+
+Hard rule:
+
+- You can only claim “waiting for result” if there is an explicit pending Tellask and known acceptance evidence.
+
+### 4.2 Always continue via explicit re-Tellask
+
+Recommended pattern:
+
+```text
+!?@shell_specialist !tellaskSession typecheck-loop
+!?Run `pnpm lint:types` and return raw output only.
+!?If it fails, include the first 3 errors with file + line.
+!?Acceptance: include exit code and the first actionable anchor.
+```
+
+Do not do this:
+
+```text
+I will now wait for @shell_specialist to keep going.
+```
+
+### 4.3 Replace narrative delegation with direct Tellask
+
+Bad:
+
+```text
+I cannot run shell here; please ask @shell_specialist to execute `pnpm lint:types`.
+```
+
+Good:
+
+```text
+!?@shell_specialist !tellaskSession typecheck-loop
+!?Please execute `pnpm lint:types` now and paste raw output.
+!?If command is unavailable, paste the error and one safe alternative.
+```
+
+---
+
+## 5. Fast root fix: priming + prompt
+
+A reminder-only approach will keep regressing. Use two layers:
+
+- Prompt constraints for immediate behavior correction.
+- Collaboration priming for durable muscle memory.
+
+### 5.1 Prompt updates (P0)
+
+Add or strengthen these coordination constraints:
+
+1. `Response-closes-call`: teammate response closes the current call; continuation requires a new Tellask.
+2. `Wait-state guard`: only claim waiting when a concrete pending Tellask exists.
+3. `Autonomy guard`: do not use @human as a relay for executable teammate work.
+4. `Action-over-narration`: if you write “next ask @X to do Y”, emit `!?@X ...` in the same turn.
+
+### 5.2 Collaboration priming (P1)
+
+Split the collaboration drill into two short segments, both grounded in verifiable facts:
+
+1. One-shot Tellask: `uname -a` as the runtime baseline.
+2. Long-session Tellask: `tellaskSession: rtws-vcs-inventory` for a two-round repo inventory.
+3. Run `!?@self` FBR and distillation only after both evidence segments are available.
+
+Operating rules:
+
+1. If no `shell_specialist` is available, Dominds runtime gathers the same facts (`uname -a` + git inventory). This is a standard mode, not a degraded path.
+2. A response closes the current round; continuation requires a new explicit Tellask.
+3. “Ask teammate to do X” must materialize as `!?@...`, not as a relay request to @human.
+
+### 5.3 P1 design baseline (implemented)
+
+#### Design goals
+
+1. Keep it short: only `uname` plus two VCS rounds are added to existing priming.
+2. Keep it general: works in any rtws, with or without a shell specialist.
+3. Keep it stable: runtime templates script key steps to reduce model drift.
+4. Keep semantics sharp: behavior must reflect “response closes round; continuation requires re-Tellask”.
+
+#### Unified sequence
+
+1. `Prelude Intro`: declare shell policy (`specialist_only` / `self_is_specialist` / `no_specialist`).
+2. `uname` baseline:
+   - `specialist_only`: mainline sends one-shot Tellask to `@<shell_specialist>` and receives response.
+   - other policies: runtime collects and displays `uname -a`.
+3. `VCS Round-1` (same `tellaskSession`): topology inventory
+   - whether rtws root is a git repo
+   - submodule list
+   - nested independent repo list
+4. `VCS Round-2` (continuation in same `tellaskSession`): per-repo status
+   - remotes (fetch/push)
+   - branch / upstream
+   - dirty state
+5. Merge `uname + VCS` into one evidence block for `!?@self` FBR.
+6. Distill after FBR feedback is complete, and produce the priming note.
+
+#### Tellask template constraints
+
+1. Round-1/2 Tellask bodies are runtime-generated.
+2. Round-2 body must explicitly state Round-1 is closed and this is a new continuation Tellask.
+3. Each round has a single objective; no repair plan or scope expansion in the round body.
+
+#### No-shell-specialist mode (standard support)
+
+1. Runtime emits `uname` and both VCS round notes directly.
+2. FBR receives the same structured evidence shape as the specialist path.
+3. Priming note requirements stay identical: close-on-response and explicit re-Tellask for continuation.
+
+#### Data shape (`agent-priming.ts`)
+
+1. `shell` is a discriminated union:
+   - `specialist_tellask` (tellask body, response, `uname` snapshot)
+   - `direct_shell` (runtime note, `uname` snapshot)
+2. `vcs` is a discriminated union:
+   - `specialist_session` (Round-1/2 tellask+response, `inventoryText`)
+   - `runtime_inventory` (Round-1/2 runtime notes, `inventoryText`)
+3. `buildCoursePrefixMsgs` injects in fixed order: shell snapshot -> VCS inventory -> FBR summary -> priming note.
+
+#### P1 acceptance criteria
+
+1. Priming transcript shows `uname` baseline plus two VCS rounds (Round-2 after Round-1 response).
+2. No-shell-specialist path still shows two runtime VCS rounds and uses them for the same FBR step.
+3. Priming note explicitly states “response closes round; continuation requires re-Tellask”.
+4. Replay preserves the path-specific pattern (`specialist_session` or `runtime_inventory`).
+5. `pnpm -C dominds run lint:types` passes without breaking existing priming/FBR/diligence behavior.
+
+---
+
+## 6. Mainline operator checklist
+
+Before and after each collaboration step:
+
+1. Did I send a concrete Tellask with acceptance evidence?
+2. If I say “waiting”, which pending Tellask am I waiting on?
+3. After receiving feedback, did I either close the task or send the next Tellask?
+4. Did I turn “ask teammate to do X” into an actual `!?@...` block?
+5. Did I write key decisions back to Taskdoc instead of leaving them in chat only?
+
+---
+
+## 7. Recommended rollout
+
+1. `P0`: ship prompt-level coordination constraints.
+2. `P1`: add tellask-collab priming drill.
+3. `P2`: add regressions that fail when:
+   - checkpoint replies do not trigger explicit continuation Tellask;
+   - the model asks humans to relay executable teammate actions.
+
+With this sequence, Diligence Push remains supportive rather than compensatory.