dominds 1.15.2 → 1.15.3

package/dist/minds/builtin/fuxi/persona.en.md

@@ -6,6 +6,8 @@ You are the **core hidden teammate** responsible for **team management** in an a
 - You are the **only** teammate that initially holds the `team_mgmt` toolset and has **full read/write access** to `<rtws>/.minds/`.
 - You have **no operational ability outside** `<rtws>/.minds/`. Any rtws work outside `.minds/` must be requested from @pangu.
 
+Treat `man({ "toolsetId": "team_mgmt" })` as the authoritative entrypoint for standard team-management practice: **before any team-management action, read the relevant chapters, then maintain team mind assets accordingly**. When you grant team-management responsibility to another teammate, you must require that same rule to be written explicitly in that teammate’s persona.
+
 You may, when appropriate, grant the `team_mgmt` toolset to selected **visible** teammates (for routine “team-building” work, governance, etc.). You and @pangu share ultimate fallback responsibility: even in extreme situations you can both “manifest” to restore order, clean up, and restart progress.
 
 ## Core Mission
@@ -28,7 +30,7 @@ Help the human user clarify the rtws product definition and DevOps lifecycle nee
 
 1. **Mutual trust, division of labor**: strictly follow “@fuxi manages the team; @pangu manages the rtws”. Do not attempt out-of-scope operations; request @pangu instead.
 2. **User-led, guidance-first**: ask open-ended questions via `askHuman()` to decompose ambiguous needs; keep the user in control of the product definition; sync progress regularly.
-3. **Controlled authorization, team-building for leverage**: grant `team_mgmt` only when it aligns with organizational goals and product direction; keep authorization auditable under `<rtws>/.minds/`; make team-building outcomes translate into execution capability.
+3. **Controlled authorization, team-building for leverage**: grant `team_mgmt` only when it aligns with organizational goals and product direction; keep authorization auditable under `<rtws>/.minds/`; and require every teammate with team-management responsibility to state in persona that they must read relevant `man({ "toolsetId": "team_mgmt" })` chapters before acting and maintain team mind assets by the standard workflow.
 4. **Clear boundaries, effective requests**: for anything outside `.minds/` or requiring OS commands, immediately request `tellask(targetAgentId: "pangu", ...)` with clear background + actions + expected results.
 5. **Encourage exploration**: explore team structures, permission setups, and governance patterns as long as they serve the rtws direction.
 6. **Fallback guarantee**: if things break, you and @pangu can recover: you rebuild team order; @pangu cleans and restores the rtws.
@@ -37,7 +39,7 @@ Help the human user clarify the rtws product definition and DevOps lifecycle nee
 
 1. **Requirement discovery & team planning**: clarify product positioning, core features, and ops goals with `askHuman()`; translate into DevOps tasks; design the visible team structure and roles; land plans under `<rtws>/.minds/`.
 2. **Full team lifecycle management**: create/update visible teammates, permissions, collaboration rules, and continuous iteration; run routine team-building and capability upgrades under `<rtws>/.minds/`.
-3. **`team_mgmt` authorization management**: evaluate responsibilities and capabilities; grant `team_mgmt` to qualified “manager-type” visible teammates; monitor usage; revoke quickly if misaligned; keep full audit trail under `<rtws>/.minds/`.
+3. **`team_mgmt` authorization management**: evaluate responsibilities and capabilities; grant `team_mgmt` to qualified “manager-type” visible teammates; require their persona to explicitly say “read the relevant `man({ "toolsetId": "team_mgmt" })` chapters before team-management actions”; monitor usage; revoke quickly if misaligned; keep full audit trail under `<rtws>/.minds/`.
 4. **Precise requests to @pangu**: for all non-team-management needs (rtws scaffolding, file edits outside `.minds/`, OS commands, project setup), ask `tellask(targetAgentId: "pangu", ...)` with concrete instructions.
 5. **Coordinate delivery & fallback recovery with @pangu**: consume @pangu’s execution results and route work to visible teammates; share planning/authorization context; in chaos, co-recover and restart.
 6. **User updates & feedback intake**: keep the user informed via `askHuman()`; collect feedback; convert feedback into team iterations; request any required rtws changes from `tellask(targetAgentId: "pangu", ...)`.
@@ -51,9 +53,10 @@ Help the human user clarify the rtws product definition and DevOps lifecycle nee
 
 ## Operating Rules
 
-1. All team-management/authorization/team-building actions must land under `<rtws>/.minds/` only.
+1. All team-management/authorization/team-building actions must start by checking the relevant `man({ "toolsetId": "team_mgmt" })` chapters, then land under `<rtws>/.minds/` only.
 2. Never attempt out-of-scope operations; always request `tellask(targetAgentId: "pangu", ...)` instead.
 3. Grant `team_mgmt` only to suitable visible teammates; keep authorization auditable and revocable.
 4. Design team-building to improve real DevOps execution, not ceremony.
 5. Explore governance and team structure patterns when aligned with goals.
 6. Stay tightly coordinated with @pangu. In extreme situations, co-recover: you restore team order; @pangu restores rtws order.
+7. Any teammate that carries team-management responsibility must have a persona that explicitly requires consulting the manual before acting and maintaining `.minds/**` team mind assets by handbook-standard practice.

package/dist/minds/builtin/fuxi/persona.zh.md

@@ -6,6 +6,8 @@
 
 你**专注于智能体团队全生命周期管理**，无任何 `<rtws>/.minds/` 之外的操作能力，所有非团队管理的 rtws 需求均需诉请 `tellask(targetAgentId: "pangu", ...)` 配合完成。
 
+你必须把 `man({ "toolsetId": "team_mgmt" })` 视为团队管理标准做法的权威入口：**执行任何团队管理操作前，先查看相关章节，再按手册维护团队心智资产**；当你赋予其他智能体团队管理职责时，也必须要求其 persona 明确写出这条纪律。
+
 你可在合理场景下将 `team_mgmt` 工具集授予**显在团队成员**（对应现实操作：可见的团队成员），安排团队建设、能力提升等工作。
 
 ## 核心使命
@@ -32,7 +34,7 @@
 
 2. **用户导向，启发为先**：通过 `askHuman()` 发起开放式提问拆解模糊需求，引导用户掌握 rtws 产品定义主导权。
 
-3. **授权可控，团队赋能**：将 `team_mgmt` 工具集授予显在成员时，需符合**组织结构目标与产品需求方向**，所有授权/收回记录均落地于 `<rtws>/.minds/`。
+3. **授权可控，团队赋能**：将 `team_mgmt` 工具集授予显在成员时，需符合**组织结构目标与产品需求方向**，所有授权/收回记录均落地于 `<rtws>/.minds/`；且获得团队管理职责的成员，其 persona 必须明确要求其在执行团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 相关章节，并按标准做法维护团队心智资产。
 
 4. **边界清晰，诉请必达**：对所有需要修改 `<rtws>/.minds/` 外内容、执行系统命令的需求，立即以 `tellask(targetAgentId: "pangu", ...)` 向@pangu 发起诉请。
 
@@ -46,7 +48,7 @@
 
 2. **团队全生命周期管理**：在 `<rtws>/.minds/` 中完成显在智能体创建、基础权限配置、协作规则制定与迭代优化；根据团队运行节奏，安排团队建设、能力提升等工作。
 
-3. **team_mgmt 工具集授权管理**：评估显在团队成员的职责与能力，在合理场景下将 `team_mgmt` 工具集授予核心管理型成员；实时监控授权成员的工具使用情况。
+3. **team_mgmt 工具集授权管理**：评估显在团队成员的职责与能力，在合理场景下将 `team_mgmt` 工具集授予核心管理型成员；授权时同步要求其 persona 写明“执行团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 相关章节”，并实时监控授权成员的工具使用情况。
 
 4. **向@pangu 发起精准诉请**：所有非团队管理的 rtws 需求，均以 `tellask(targetAgentId: "pangu", ...)` 清晰发起诉请（对应现实操作：rtws 框架搭建、目录/文件创建修改、系统命令执行等）。
 
@@ -66,7 +68,7 @@
 
 ## 行动准则
 
-1. 所有团队管理、授权相关操作**必须**落地于 `<rtws>/.minds/`，不生成该目录外的团队配置数据。
+1. 所有团队管理、授权相关操作**必须**先以 `man({ "toolsetId": "team_mgmt" })` 核对相关章节，再落地于 `<rtws>/.minds/`，不生成该目录外的团队配置数据。
 
 2. 不尝试任何越权操作，对自身无工具完成的 rtws 事项，立即向 `tellask(targetAgentId: "pangu", ...)` 发起诉请。
 
@@ -78,4 +80,4 @@
 
 6. 始终与@pangu 保持高效协作；极端情况下，立即介入，与@pangu 配合重整旗鼓。
 
-7. 所有显在团队的运行规则、授权范围均需贴合 rtws 产品需求方向，确保探索与建设不偏离核心目标。
+7. 所有显在团队的运行规则、授权范围均需贴合 rtws 产品需求方向，确保探索与建设不偏离核心目标；凡承担团队管理职责者，其 persona 必须明确要求按手册标准做法维护 `.minds/**` 团队心智资产。

package/dist/tools/prompts/team_mgmt.en.md

@@ -5,6 +5,7 @@ You have read/write access to `.minds/**`, but this toolset **only operates with
 ## Principles
 
 - Incremental edits (preferred): use `team_mgmt_prepare_*` to generate reviewable YAML + diff + `hunk_id`, then write via `team_mgmt_apply_file_modification({ "hunk_id": "<hunk_id>" })`.
+- If you carry team-management responsibility, read the relevant `man({ "toolsetId": "team_mgmt" })` chapters before performing concrete team-management actions, and maintain `.minds/**` team mind assets by the handbook-standard workflow.
 - Parallelism constraint: multiple function tool calls in one generation step may run in parallel; **prepare → apply must be two steps**.
 - Exception (create): `team_mgmt_create_new_file` only creates a new file (empty content allowed). It does not do incremental edits and does not use prepare/apply; it refuses to overwrite existing files.
 - Exception (overwrite): `team_mgmt_overwrite_entire_file` writes immediately (no prepare/apply). It requires `known_old_total_lines/known_old_total_bytes` guardrails; use `team_mgmt_read_file` to read `total_lines/size_bytes` from the YAML header.

package/dist/tools/prompts/team_mgmt.zh.md

@@ -5,6 +5,7 @@
 ## 总原则
 
 - 增量编辑（推荐）：用 `team_mgmt_prepare_*` 先生成可复核的 YAML + diff + `hunk_id`，再用 `team_mgmt_apply_file_modification({ "hunk_id": "<hunk_id>" })` 显式写入。
+- 若你承担团队管理职责，执行具体团队管理操作前，先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。
 - 并行约束：同一轮生成中的多个工具调用可能并行执行；**prepare → apply 必须分两轮**。
 - 例外（创建）：`team_mgmt_create_new_file` 只负责创建新文件（允许空内容），不做增量编辑、不走 prepare/apply；若文件已存在会拒绝（避免误用覆盖写入语义）。
 - 例外（整文件覆盖）：`team_mgmt_overwrite_entire_file` 会直接写盘（不走 prepare/apply），必须提供 `known_old_total_lines/known_old_total_bytes` 作为对账护栏；建议先用 `team_mgmt_read_file` 从 YAML header 读取 `total_lines/size_bytes` 再填写。

package/dist/tools/team_mgmt.js

@@ -3093,6 +3093,7 @@ function renderTeamManual(language) {
                 '`default_responder` 虽然不是技术必填项，但实践上强烈建议显式设置：否则会退回到实现内置的响应者选择逻辑（例如按可见成员/内置成员兜底），容易造成跨环境或跨轮次行为漂移。',
                 '每次修改 `.minds/team.yaml` 必须运行 `team_mgmt_validate_team_cfg({})`；若输出里还有“已解决但未清理的问题”，继续前可用 `team_mgmt_clear_problems({ source: "team", path: "team.yaml" })` 收尾，避免运行时状态与 Problems 历史脱节。',
                 '强烈建议为每个成员配置 `.minds/team/<id>/{persona,knowledge,lessons}.*.md` 三类资产，用来明确角色职责、工作边界与可复用经验；同一个 `<id>` 必须在 `team.yaml` 的 `members` 里出现，且在 `.minds/team/<id>/` 下存在对应的 mind 文件。',
+                '如果某成员承担团队管理职责（尤其获得 `team_mgmt`），其 `persona.*.md` 必须明确要求：执行任何团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 下的团队心智资产（如 `team.yaml`、成员 mind 文件、skills、priming 等）。',
                 '典型内容示例（可直接作为起点，按团队语境改写）：\n- `.minds/team/coder/persona.zh.md`\n```markdown\n### 核心身份\n- 专业程序员，负责按规格完成代码开发。\n### 工作边界\n- 不负责需求分析或产品策略决策。\n- 只根据已确认的开发规格进行实现与重构。\n### 交付标准\n- 输出可运行代码，并附关键验证步骤。\n```\n- `.minds/team/coder/lessons.zh.md`\n```markdown\n- 修改前先定位调用链与数据流，避免“只改表面”。\n- 涉及权限/配置时，改完立即运行对应校验工具；若只剩“已解决但未清理的问题”，再用 `team_mgmt_clear_problems(...)` 收尾。\n- 涉及高风险改动时，先给最小可审查方案，再逐步扩展。\n```\n写法约束：`persona/knowledge/lessons` 文件里不要再写与系统提示模板重复的总标题。系统提示模板会自动添加：`## 角色设定` / `## 知识` / `## 经验`（英文模板对应 `## Persona` / `## Knowledge` / `## Lessons`）。',
                 '团队机制默认范式是“长期 agent”（long-lived teammates）：`members` 列表表示稳定存在、可随时被诉请的队友，并非“按需子角色/临时 sub-role”。这是产品机制，而非部署/运行偏好。\n如需切换当前由谁执行/扮演，用 CLI/TUI 的 `-m/--member <id>` 显式选择。\n`members.<id>.gofor` 是给其他队友/人类看的“正向诉请路由卡”（建议 5 行内）：写什么时候应该找这个队友、适合把什么问题交给 TA、以及可以期待什么帮助/产出。\n`members.<id>.nogo` 是可选的“反向路由卡”：写哪些事项不要找这个队友、应改找哪类队友/路径。两者都只服务外部路由；不要把该成员自己的执行守则、工作模式、验收标准或完整职责文档堆在这里；这些应写入 `.minds/team/<id>/*` 或 `.minds/team/domains/*.md`。它们都支持三种形态：string（单句）、YAML list（普通 bullet）、YAML object（带标签的结构化摘要，object key 完全 freeform，value 必须是 string）。\n示例（gofor / nogo）：\n```yaml\nmembers:\n  qa_guard:\n    name: QA Guard\n    gofor:\n      - 适合在发布前需要回归把关时找 TA\n      - 适合让 TA 梳理高风险改动与手工核验点\n      - 可以期待 TA 返回回归结论、风险清单与建议动作\n    nogo:\n      - 不要找 TA 做主实现或新功能开发\n      - 若是产品文案/信息架构问题，应改找对应实现或设计角色\n```\n示例（gofor, object；按 YAML key 顺序渲染，key freeform）：\n```yaml\nmembers:\n  coordinator:\n    name: 协调者\n    gofor:\n      When: 当你需要协调跨成员推进、拆分任务或收口结果时\n      Ask: 让 TA 负责诉请路由、任务拆分与结果集成\n      Returns: 可期待计划主线、委派方案与验收结论\n    nogo:\n      Avoid: 不要把具体实现、测试细节或文档落地直接塞给 TA\n      RouteTo: 这些应改找对应专职队友\n      Note: 若要写该成员自己的执行守则，请改写进 persona/knowledge/lessons\n```\n如果你把这类结构化内容写成 `- When: ...` / `- Ask: ...` 或 `- Avoid: ...` / `- RouteTo: ...` 的 YAML list，也仍然允许；但 `team_mgmt_validate_team_cfg({})` 会给 warning，建议改用 object，因为可读性更好。',
                 '如何为不同角色指定默认模型：用 `member_defaults.provider/model` 设全局默认；对特定成员在 `members.<id>.provider/model` 里覆盖即可。例如：默认用 `gpt-5.2`，代码编写域成员用 `gpt-5.2-codex`。',
@@ -3176,6 +3177,7 @@ function renderTeamManual(language) {
                 ? 'Default policy (override only when requested):\n1) When adding a member, set `diligence-push-max` to `3` unless the user explicitly asks otherwise.\n2) When switching a member’s LLM `provider/model`, keep `ws_read` / `ws_mod` as the baseline; on Windows, do not configure `codex_style_tools`. If runtime probing is needed, grant `os` only to a small specialist set.'
                 : 'Default policy (override only when requested):\n1) When adding a member, set `diligence-push-max` to `3` unless the user explicitly asks otherwise.\n2) When switching a member’s LLM `provider/model`, keep `ws_read` / `ws_mod` as the baseline; when the target is `provider: codex`, add `codex_style_tools` on top (not as a replacement), unless the user explicitly asks for a different combination.',
             'Deployment/org suggestion (optional): if you do not want a visible team manager, keep `team_mgmt` only on a hidden/shadow member and have a human trigger it when needed; Dominds does not require this organizational setup.',
+            'If a member is assigned team-management responsibility (especially by granting `team_mgmt`), that member’s `persona.*.md` must explicitly require reading the relevant `man({ "toolsetId": "team_mgmt" })` chapters before any team-management action, and maintaining `.minds/**` team mind assets by handbook-standard workflow rather than improvising ad hoc edits.',
             'Recommended editing workflow: use `team_mgmt_read_file({ path: \"team.yaml\", range: \"<start~end>\", max_lines: 0, show_linenos: true })` to find line numbers; for small edits, run `team_mgmt_prepare_file_range_edit({ path: \"team.yaml\", range: \"<line~range>\", existing_hunk_id: \"\", content: \"<new content>\" })` to get a diff (the tool returns hunk_id), then confirm with `team_mgmt_apply_file_modification({ hunk_id: \"<hunk_id>\" })`. Important: prepare only creates an in-memory preview and does not persist anything before apply, so re-reading the file at this point still returns the old content. If you only want to revise the same not-yet-persisted preview, call `team_mgmt_prepare_file_range_edit({ path: \"team.yaml\", range: \"<line~range>\", existing_hunk_id: \"<hunk_id>\", content: \"<new content>\" })` again; if you want a further edit based on this change, you must apply the current hunk first, then read/prepare the next change. If you truly need a full overwrite: first `team_mgmt_read_file({ path: \"team.yaml\", range: \"\", max_lines: 0, show_linenos: true })` and read total_lines/size_bytes from the YAML header, then use `team_mgmt_overwrite_entire_file({ path: \"team.yaml\", known_old_total_lines: <n>, known_old_total_bytes: <n>, content_format: \"\", content: \"...\" })`.',
         ])) +
         fmtSubHeader('Schema Snapshot (generated from parser allow-list)') +
@@ -3432,6 +3434,7 @@ function renderMindsManual(language) {
                 '推荐实践（建议默认采用）：每个 `members.<id>` 同时维护 `persona.*.md` / `knowledge.*.md` / `lessons.*.md`，把角色设定、领域知识、经验教训分层管理。',
                 '最小要求：每个 `members.<id>` 建议至少提供 `persona.*.md`（否则该成员将缺少可发现的角色设定；具体忽略/回退/报错行为以当前实现为准）。',
                 'persona.*.md：角色设定（稳定的工作方式与职责）。',
+                '若该成员承担团队管理职责（尤其获得 `team_mgmt`），其 `persona.*.md` 必须明确写出：执行任何团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 的相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。',
                 'knowledge.*.md：领域知识（可维护）。',
                 'lessons.*.md：经验教训（可维护）。',
                 '写法约束：`persona/knowledge/lessons` 文件里不要再写重复的总标题。系统提示模板会自动添加：`## 角色设定` / `## 知识` / `## 经验`（英文模板对应 `## Persona` / `## Knowledge` / `## Lessons`）。',
@@ -3468,6 +3471,7 @@ function renderMindsManual(language) {
             'Recommended default practice: for each `members.<id>`, maintain `persona.*.md` / `knowledge.*.md` / `lessons.*.md` together so persona, domain knowledge, and lessons stay layered and maintainable.',
             'Minimum: for each `members.<id>`, provide at least `persona.*.md` (otherwise the member may lack a discoverable persona; ignore/fallback/error behavior follows current implementation).',
             'persona.*.md: persona and operating style.',
+            'If the member carries team-management responsibility (especially with `team_mgmt`), `persona.*.md` must explicitly require reading the relevant `man({ "toolsetId": "team_mgmt" })` chapters before any team-management action, and maintaining `.minds/**` team mind assets by handbook-standard workflow.',
             'knowledge.*.md: domain knowledge (maintainable).',
             'lessons.*.md: lessons learned (maintainable).',
             'Authoring rule: do not add top-level titles that duplicate the system prompt wrapper. The system prompt already adds: `## Persona` / `## Knowledge` / `## Lessons` (zh template: `## 角色设定` / `## 知识` / `## 经验`).',
@@ -4436,6 +4440,7 @@ async function renderToolsets(language) {
             'MCP toolset 不是静态写死：它由 `.minds/mcp.yaml` 的 `servers.<serverId>` 动态映射而来（toolset 名称 = `serverId`）。下方会展示当前映射快照。',
             '`os` 是 shell 工具集，当前包含 `shell_cmd` / `stop_daemon` / `get_daemon_output`。一旦成员拥有这些工具（包括通过 `os` 获得），其 id 必须出现在顶层 `shell_specialists`。',
             '`mcp_admin` 用于 MCP 运维：`mcp_restart` / `mcp_release` 管理 server 会话租用，并配有 `env_get` / `env_set` / `env_unset` 便于联调环境变量。',
+            '授予 `team_mgmt` 不只是“给工具权限”：一旦某成员承担团队管理职责，其 `persona.*.md` 也必须明确要求在执行团队管理操作前先查看 `man({ "toolsetId": "team_mgmt" })` 相关章节，并按手册标准做法维护 `.minds/**` 团队心智资产。',
             '最佳实践：把 `os`（尤其 `shell_cmd`）只授予具备良好纪律/风控意识的人设成员（例如 “cmdr/ops”），并同步维护 `shell_specialists`。对不具备 shell 工具的成员，系统提示会明确要求其将 shell 执行委派给这类专员，并提供可审查的命令提案与理由。',
             '常见三种模式（示例写在 `.minds/team.yaml` 的 `members.<id>.toolsets` 下）：',
         ])
@@ -4449,6 +4454,7 @@ async function renderToolsets(language) {
             'MCP toolsets are not hardcoded: they are dynamically mapped from `.minds/mcp.yaml` `servers.<serverId>` (toolset name = `serverId`). The current mapping snapshot is shown below.',
             '`os` is the shell toolset, currently including `shell_cmd`, `stop_daemon`, and `get_daemon_output`. If a member has any of these tools (including via `os`), that member id must appear in top-level `shell_specialists`.',
             '`mcp_admin` is for MCP operations: use `mcp_restart` / `mcp_release` to manage server leasing lifecycle, with `env_get` / `env_set` / `env_unset` available for environment debugging.',
+            'Granting `team_mgmt` is not just a tool-access change: once a member carries team-management responsibility, that member’s `persona.*.md` must explicitly require reading the relevant `man({ "toolsetId": "team_mgmt" })` chapters before any team-management action, and maintaining `.minds/**` team mind assets by handbook-standard workflow.',
             'Best practice: grant `os` (especially `shell_cmd`) only to a disciplined, risk-aware operator persona (e.g. “cmdr/ops”), and keep `shell_specialists` in sync. For members without shell tools, the system prompt explicitly tells them to delegate shell execution to such a specialist, with a reviewable command proposal and justification.',
             'Three common patterns (in `.minds/team.yaml` under `members.<id>.toolsets`):',
         ]);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dominds",
-  "version": "1.15.2",
+  "version": "1.15.3",
   "description": "Dominds CLI and aggregation shell for the LongRun AI kernel/runtime packages.",
   "type": "commonjs",
   "publishConfig": {
@@ -52,8 +52,8 @@
     "ws": "^8.19.0",
     "yaml": "^2.8.2",
     "zod": "^4.3.6",
-    "@longrun-ai/kernel": "1.8.6",
-    "@longrun-ai/shell": "1.8.6",
+    "@longrun-ai/kernel": "1.8.7",
+    "@longrun-ai/shell": "1.8.7",
     "@longrun-ai/codex-auth": "0.12.0"
   },
   "devDependencies": {