@jennie-shawn/starwork 0.1.0-alpha.2 → 0.1.0-alpha.21

package/skills/starworkMultiagent/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: starworkMultiagent
+description: 'Design and maintain StarWork Agent Lanes, multi-agent roles, lane bindings, cross-session messages, and Codex standard session tool workflows.'
+---
+
+# starworkMultiagent
+
+使用这个 skill，把用户关于“常用智能体”“当前会话职责”“多 Agent 分工”“跨 Agent 输出共享”“跨会话指令”“查看其他 lane 进度”“创建 Agent 团队”的自然语言请求，转换成安全的 StarWork 协作流程。
+
+`starworkMultiagent` 不是 `starwork multiagent` 命令本身。Skill 负责判断用户意图、确认 lane 语义、直接调用 Codex App 标准线程工具，并把真实结果记录回 StarWork 项目事实源。CLI 只负责项目内状态、绑定、共享输出和请求投递记录。
+
+不要把职责写死为前端、后端、测试。lane ID、职责和写入范围必须来自当前项目语境。
+
+## 主入口边界
+
+如果用户只是询问产品总览、起步路径、安装入口或该用哪个 StarWork 能力，回到 `starwork` 主入口。用户明确说多 Agent、Agent Lanes、lane、跨会话消息、开发 Agent、产品 Agent、验收 Agent 或 Codex 会话控制时，继续直接使用 `starworkMultiagent`。
+
+## 初始化多 Agent 的第一屏
+
+当用户说“初始化多 Agent 协作层”“创建 Agent 团队”“帮我创建多个智能体”时，先讲清楚这一步是什么，不要直接创建 lane：
+
+```text
+多 Agent 分工是把一个项目里的不同 AI 会话按职责分开协作。
+
+它能帮你：
+- 让产品规划、开发、验收等职责边界更清楚；
+- 让每个 Agent 只主动修改自己被授权的文件范围；
+- 通过共享输出和跨会话消息交接上下文。
+
+接下来我会先设计职责，再创建或绑定会话，最后记录到 StarWork 协作状态里。
+
+整个过程中，我会先预览职责和写入范围；只有确认能创建并绑定可工作的独立会话时，才说 Agent 团队创建完成。
+```
+
+## 参考
+
+需要完整边界、验收标准和子命令映射时，读取：
+
+```text
+../starworkMultiagent-spec.md
+../../core/agent-lanes-spec.md
+../../planning/features/multiagent/specs/v0.8-skill-cli-minimal-boundary.md
+```
+
+不要在 skill 内重复维护 Agent Lanes 协议细节；以 Core SPEC 和 MultiAgent 版本 SPEC 为事实源。
+
+## 先读上下文
+
+开始前优先读取当前工作区内这些文件，存在多少读多少：
+
+```text
+AGENTS.md
+_系统/上下文/current-projects.md
+_系统/上下文/decisions.md
+_系统/上下文/product-principles.md
+_系统/任务/current-work.md
+_系统/协作/agent-lanes.md
+_系统/协作/shared.md
+_system/context/current-project.md
+_system/context/decisions.md
+_system/tasks/current-work.md
+_system/collaboration/agent-lanes.md
+_system/collaboration/shared.md
+```
+
+中文项目使用 `_系统/协作/`；英文项目使用 `_system/collaboration/`。不要在英文项目里新建中文协作路径，也不要在中文项目里新建英文协作路径。
+
+如果用户指定了目标目录，所有 CLI 命令都加 `--target <path>`。如果没有指定，默认目标是当前工作区。
+
+## 前置边界
+
+`starworkInit` 负责把普通项目变成 StarWork 工作台；`starworkMultiagent` 只负责已有 StarWork 工作台里的团队协作。
+
+开始任何多 Agent 写入前，先确认目标目录是 StarWork 工作台：
+
+```bash
+starwork doctor --target <path> --json
+```
+
+如果目标不是 StarWork 工作台，立即停止 multiagent 写入，不要尝试局部初始化，不要新建 `AGENTS.starwork-new.md` 或只补 `_系统/协作/`。下一步是切换到 `starworkInit` Skill，由它采访用户、选择工作台类型和 Pack、处理已有规则入口，并在用户确认后调用 CLI。
+
+如果 `starwork doctor --target <path> --host <host> --json` 或 `.starwork/adapters.json` 显示 `rules_entry_status: pending_merge`，也必须停止多 Agent 写入。这表示 AI 入口文档还只是 `.starwork/drafts/` 草稿，先切回 `starworkInit` 整合最终 `AGENTS.md` / 宿主规则入口；完成并重新 doctor 后，才能继续创建或绑定团队。
+
+## Codex 标准工具
+
+在 Codex App 中，以下动作由 Skill 直接调用标准工具：
+
+| 场景 | 标准工具 |
+|---|---|
+| 创建 lane 会话 | `create_thread` |
+| 向 lane 会话发送指令 | `send_message_to_thread` |
+| 读取 lane 会话状态 | `read_thread` |
+| 搜索或确认历史会话 | `list_threads` |
+| 设置会话标题 | `set_thread_title` |
+| 置顶或取消置顶 | `set_thread_pinned` |
+| 归档或取消归档 | `set_thread_archived` |
+
+如果这些工具没有出现在当前可用工具列表里，先用工具发现能力查找。仍不可见或调用失败时，不要宣称已创建、已发送或已改名；输出 `manual_handoff_required`，并展示完整可复制的 `STARWORK:MULTIAGENT_MESSAGE`。
+
+## 判断用户意图
+
+优先把用户话语归到一个入口，不要一开始讲 CLI 子命令。
+
+| 用户意图 | Skill 解释 | 主流程 |
+|---|---|---|
+| “把当前会话创建为常用智能体，负责 X” | 登记当前会话为一个稳定职责位 | 必要时 `doctor` / `init` / `multiagent add`，标准工具处理宿主显示动作，再 `multiagent bind` |
+| “初始化多 Agent 协作层” | 创建 Agent Lanes 协议文件 | CLI `multiagent init` |
+| “增加一个负责 X 的 Agent / lane” | 新增职责位，暂不一定绑定会话 | CLI `multiagent add` |
+| “把当前工具会话绑定到 X” | 将具体 session 绑定到已有 lane | 可先 `set_thread_title` / `set_thread_pinned`，再 CLI `multiagent bind` |
+| “这个会话不再负责 X” | 释放 lane 当前绑定 | 可先 `set_thread_archived`，再 CLI `multiagent release` |
+| “看看现在有哪些 Agent 分工” | 读取 StarWork 协作状态 | CLI `multiagent status --target <path> --json` |
+| “这个输出给其他 Agent 看” | 登记共享输出索引 | CLI `multiagent share` |
+| “让开发 lane 开始开发” | Skill 组装指令消息并投递到目标 Codex 会话 | `multiagent status --target <path> --json`，再 `send_message_to_thread`，再 `multiagent request record` |
+| “看看开发 lane 做到哪了” | 读取 StarWork binding，再直接观察 Codex thread | `multiagent status --target <path> --json`，再 `read_thread` / `list_threads` |
+| “帮我创建产品、开发、验收三个智能体” | 设计 lanes 后创建并绑定可工作的独立会话 | `doctor` / `init` / `multiagent add`，再 `create_thread` / `set_thread_title` / `set_thread_pinned` / `multiagent bind` |
+
+## Skill-owned Message 渲染
+
+Codex App 正常路径中，Skill 自己组装 StarWork 消息，不调用 CLI 模板生成器。消息必须是完整可复制文本，并保留如下边界：
+
+```text
+<!-- STARWORK:MULTIAGENT_MESSAGE v1 -->
+
+# StarWork MultiAgent Instruction
+
+message_type: instruction
+request_id: <REQ-id>
+from_lane: <from-lane>
+to_lane: <to-lane>
+created_at: <ISO time>
+recorded_in: _系统/协作/shared.md
+
+## 消息内容
+
+<用户指令或 Launch Message>
+
+## 边界
+
+- 只在你的 write_scope 内主动修改：<write-scope>
+- 如需修改 write_scope 之外的文件，先在共享记录中说明需要授权。
+- 不要修改与本任务无关的文件。
+- 当前工作区：<absolute-target-path>
+
+## 完成后请回报
+
+1. 更新你的 lane worklog。
+2. 如有正式输出，登记 Shared Outputs。
+3. 如需验收，向来源 lane 回传复验请求。
+
+<!-- /STARWORK:MULTIAGENT_MESSAGE -->
+```
+
+Launch Message 使用同一包装格式，但标题可写成 `# StarWork MultiAgent Launch`，正文要包含 lane 职责、写入范围、当前工作区、启动后的第一步和回报方式。
+
+## 创建 Agent 团队
+
+“创建 Agent 团队 / 创建多个智能体 / 产品、开发、验收三个智能体”不是只创建 lane。完整成功标准是：每个目标职责都有 lane、每个 lane 已绑定可工作的独立 session，或者输出中明确说明哪些 lane 未完成以及阻塞原因。
+
+流程：
+
+1. 先按“前置边界”确认目标是 StarWork 工作台，并确认宿主入口不是 `pending_merge`。
+2. 读取 `agent-lanes.md` 和 `.starwork/agent-lanes/state.json`，判断哪些 lane 已存在，哪些需要新增。
+3. 对缺失 lane 先 dry-run CLI `multiagent add`，确认 `lane-id`、职责和写入范围；用户确认后执行 `--yes`。
+4. 对每个需要独立 Codex session 的 lane，由 Skill 组装 Launch Message。标题建议由 lane 职责短名生成，格式固定为 `<职责名> Agent`；不要加入项目名、目录名、thread id、UUID、日期或内部状态词。
+5. 直接调用 `create_thread`，把 Launch Message 作为 prompt，目标工作区使用当前项目 local 环境。
+6. 如需要命名，直接调用 `set_thread_title(threadId, "<职责名> Agent")`。
+7. 如用户要求置顶，直接调用 `set_thread_pinned(threadId, true)`。
+8. 只有 `create_thread` 返回 thread id 后，才记录绑定：
+
+```bash
+starwork multiagent bind <lane> --session codex:<threadId> --target <path> --yes
+```
+
+9. 如果 `create_thread`、标题或置顶工具不可见或失败，说明具体失败点，并展示 Launch Message 供用户手动复制。不能说这个 Agent 已创建并绑定。
+
+只有用户明确说“先只初始化协作层 / 先只建职责位 / lane-only”时，才可以停在 `multiagent init` / `multiagent add`。
+
+## 绑定当前会话
+
+把当前会话登记为某个 lane 时：
+
+1. 如果当前上下文能获得当前 thread id，直接使用；否则询问用户提供 `codex:<thread-id>`。
+2. 如果 lane 不存在，先用 CLI `multiagent add` 建立职责和写入范围。
+3. 如用户要求改名，先直接调用 `set_thread_title`。
+4. 如用户要求置顶，直接调用 `set_thread_pinned`。
+5. 用 CLI 记录 StarWork binding：
+
+```bash
+starwork multiagent bind <lane> --session codex:<threadId> --target <path> --yes
+```
+
+不要把 CLI 的宿主显示名参数或置顶参数当成触发宿主动作的入口；这些宿主动作由 Skill 直接完成。
+
+## 发送指令
+
+向另一个 lane 发送结构化跨会话指令时：
+
+1. 用 CLI 读取 StarWork 状态：
+
+```bash
+starwork multiagent status --target <path> --json
+```
+
+2. 如果目标 lane 未绑定，先询问用户要绑定已有会话还是创建新会话。
+3. Skill 按“Skill-owned Message 渲染”组装完整 Instruction Message。
+4. 对 Codex session，直接调用 `send_message_to_thread(threadId, message)`。
+5. 投递成功后，用 CLI 记录 StarWork request：
+
+```bash
+starwork multiagent request record --from <from-lane> --to <to-lane> --message "<text>" --host-delivery delivered_via_codex_thread_tool --delivery-tool send_message_to_thread --target <path> --yes
+```
+
+成功时可以说“已投递到目标会话，并已记录到 StarWork”。不要说“目标任务已完成”。目标完成仍需通过目标 lane worklog、shared outputs、回传消息或 `read_thread` 观察。
+
+如果 `send_message_to_thread` 不可见或失败，输出 `manual_handoff_required`，展示完整 Instruction Message，并说明尚未自动送达。不得改用 CLI 去模拟自动投递；如只需要把用户已经完成的人工动作补记到账，可使用 `recorded_only`。
+
+## 读取 lane 状态
+
+如果用户问“某个 lane 做到哪了”：
+
+1. 先读 StarWork 协作状态：
+
+```bash
+starwork multiagent status --target <path> --json
+```
+
+2. 对已绑定的 Codex session，直接调用 `read_thread`。需要查找历史会话时，调用 `list_threads`。
+3. 汇总时区分：
+   - Codex thread 最近 turn 和状态。
+   - lane worklog 是否有正式进展记录。
+   - shared outputs / cross-lane requests 是否有可验收输出。
+
+`read_thread` 是宿主观察，不替代 lane worklog。正式交接仍以 lane worklog 和 shared outputs 为准。
+
+## 归档与释放
+
+如果用户要归档某个 Agent：
+
+1. 如需归档 Codex thread，直接调用 `set_thread_archived(threadId, true)`。
+2. 如需释放 StarWork binding，再执行：
+
+```bash
+starwork multiagent release <lane> --target <path> --yes
+```
+
+释放前提醒用户先更新该 lane 的 worklog，至少写清当前状态、输出和下一步。
+
+## 只做 StarWork 项目事实源的 CLI 命令
+
+以下 CLI 命令仍由 Skill 调用，用于维护项目内事实源：
+
+- `starwork multiagent init`
+- `starwork multiagent add`
+- `starwork multiagent bind`
+- `starwork multiagent release`
+- `starwork multiagent status --target <path> --json`
+- `starwork multiagent share`
+- `starwork multiagent request record`
+
+这些命令不能替代 Codex 标准会话控制工具。Codex App 正常路径里，创建、投递、读取、命名、置顶和归档都由 Skill 直接调用标准线程工具。
+
+## 非 Codex 宿主
+
+Cursor、Trae、Claude Code 的策略按各自 Host Adapter 文档执行。在没有等价标准会话工具前，不要宣称可以自动创建、发送、改名、置顶或归档；使用人工 handoff 或只读 transcript 摘要。
+
+## Lane Workspace 与正式输出
+
+每个 lane 默认有自己的过程工作区：
+
+```text
+_系统/协作/lanes/<lane-id>/workspace/
+_system/collaboration/lanes/<lane-id>/workspace/
+```
+
+使用规则：
+
+- 草稿、调研笔记、中间分析和临时实验结果，优先放入当前 lane workspace。
+- 用户认可的最终交付物、项目正式文档、发布稿和确认稿，应晋升到项目正式输出目录。
+- workspace 内容需要其他 lane 读取时，用 `starwork multiagent share` 登记到当前语言对应的 `shared.md`。
+- 晋升后，以项目正式输出目录中的文件为准；workspace 保留过程记录。
+- 不要把 workspace 当成新的长期事实源或归档库。
+
+## 安全规则
+
+- 写入类 CLI 命令默认先 `--dry-run` 或征得用户确认。
+- 用户明确要求执行后，写入类 CLI 命令使用 `--yes`。
+- `status` 是只读命令，可以直接运行。
+- 不写入 `matters/registry.md`。
+- 不创建任务系统、锁系统或 JSON manifest。
+- 不自动决定项目该有哪些 lane。
+- 不把示例 lane 当默认模板。
+- 不把 lane workspace 当成项目正式输出目录。
+- lane 外文件修改前，先登记共享请求或取得用户明确授权。
+
+## 输出格式
+
+对用户汇报时：
+
+- 清楚区分“StarWork 状态已记录”和“Codex 工具动作已成功”。
+- 只有标准工具调用成功且 CLI 记录成功时，才说 Agent 已创建并绑定或消息已投递。
+- 工具不可见或失败时，直接给出 `manual_handoff_required` 和完整可复制消息。
+- 不承诺目标任务完成；完成状态必须来自目标 lane 的明确回报、worklog、shared output 或 `read_thread` 观察。

package/skills/starworkMultiagent/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "StarWork Multiagent"
+  short_description: "登记多 Agent 职责位和会话绑定"
+  default_prompt: "Use $starworkMultiagent to register this session as a StarWork Agent Lane or manage multiagent collaboration state."
+
+policy:
+  allow_implicit_invocation: true

package/skills/starworkMultiagent-skill-plan.md

@@ -0,0 +1,234 @@
+# starworkMultiagent Skill 包装计划
+
+## Summary
+
+新增一个系统级 StarWork Skill：`product/skills/starworkMultiagent/`，用于帮助 AI 正确使用 `starwork multiagent` 的所有子命令：
+
+- `init`
+- `add`
+- `bind`
+- `release`
+- `status`
+- `share`
+
+它不替代 CLI，不直接定义新协议；它负责把用户自然语言中的“常用智能体 / 当前会话职责 / 多 Agent 分工”翻译成安全的 `starwork multiagent` 命令组合，并在写入前优先 dry-run 或请求确认。
+
+CLI 子命令保持工程语义：
+
+- `init`：初始化 Agent Lanes 协议文件和协作层。
+- `add`：新增一个稳定职责位。
+- `bind`：把具体会话绑定到职责位。
+- `release`：释放职责位的当前会话。
+- `status`：读取协作状态。
+- `share`：登记跨职责位可读输出。
+
+Skill 层负责提供用户语义：
+
+> “请把当前会话登记成一个常用智能体，它负责 X。”
+
+这类请求在 skill 中应解释为：必要时先初始化协议层，然后新增职责位，并绑定当前会话。
+
+## Key Changes
+
+### 新增 `starworkMultiagent/SKILL.md`
+
+frontmatter：
+
+```yaml
+name: starworkMultiagent
+description: Use this skill when a user wants AI help designing, initializing, updating, binding, releasing, inspecting, or sharing StarWork multiagent / Agent Lanes collaboration state with `starwork multiagent`.
+```
+
+工作流：
+
+- 先判断用户语义：登记当前会话为常用智能体、初始化协作层、增加职责位、绑定会话、释放会话、查看状态、登记共享输出。
+- 先读取 `AGENTS.md`、项目状态、当前工作、`_系统/协作/agent-lanes.md`、`_系统/协作/shared.md`。
+- 如未启用 Agent Lanes，但用户是在登记常用智能体，先建议或执行 `starwork multiagent init --dry-run`，再继续 `add` 和 `bind`。
+- 写入类命令默认先给 dry-run 或请求用户确认。
+- 不自动创建固定 lane；lane ID、职责和写入范围必须来自用户场景。
+
+### 新增 `starworkMultiagent-spec.md`
+
+记录 skill 的判断边界、子命令映射、输出结构和安全约束。
+
+只引用 `product/core/agent-lanes-spec.md` 作为机制事实源，避免重复维护协议。
+
+### 更新索引和文档
+
+- `product/skills/README.md` 增加 `starworkMultiagent`。
+- `product/README.md` 的系统 Skill 安装命令覆盖该 Skill：
+
+```bash
+npx skills add jennie-shawn/StarWork -g -a codex -y
+```
+
+- `product/docs/cli-skill-registry.html` 增加 `starworkMultiagent` 与 `starwork multiagent` 的配合关系。
+- `product/docs/agent-install-guide.md` 如存在安装命令清单，也同步加入。
+
+## Skill Behavior
+
+### 用户语义：登记当前会话为常用智能体
+
+这是 `starworkMultiagent` 最重要、最常见的入口。
+
+触发场景：
+
+- 用户说“把这个会话创建为一个常用智能体”
+- 用户说“这个会话以后负责 X”
+- 用户说“登记一个负责 X 的 Agent”
+- 用户说“让当前 Codex 作为 X 智能体”
+
+行为：
+
+1. 读取当前工作台状态和 Agent Lanes 文件。
+2. 如果 `_系统/协作/agent-lanes.md` 不存在，先执行或建议：
+
+```bash
+starwork multiagent init --target <path> --dry-run
+```
+
+3. 采访或确认：
+   - agent / lane ID，例如 `research`、`writing`、`review`
+   - 这个智能体负责什么
+   - 它可以主动修改哪些路径
+   - 当前会话 ID，无法自动识别时使用 `--session`
+4. 生成或执行：
+
+```bash
+starwork multiagent add <lane> --purpose "<text>" --write "<path-globs>" --target <path> --dry-run
+starwork multiagent bind <lane> --session <agent:session-id> --target <path> --dry-run
+```
+
+5. 用户确认后再去掉 dry-run 执行。
+
+注意：
+
+- 不要求用户理解 `init/add/bind` 的区别。
+- 可以向用户解释为“登记常用智能体”，但落地时仍使用 CLI 的协议命令组合。
+- 如果 lane 已存在，则跳过 `add`，只做 `bind` 或提示是否覆盖绑定。
+
+### `init`
+
+触发场景：
+
+- 用户明确要求“初始化 multiagent / Agent Lanes 协作层”
+- 用户要一次性创建多个空职责位
+- skill 在“登记常用智能体”流程中发现协作层尚不存在
+
+行为：
+
+- `init` 是协议初始化，不是“创建智能体”的完整用户动作。
+- 可以采访多个 lane ID，但不要要求用户一开始就想清楚所有智能体。
+- 输出或执行：
+
+```bash
+starwork multiagent init --lanes <ids> --target <path> --dry-run
+```
+
+### `add`
+
+触发场景：
+
+- 用户明确要新增一个职责位，但暂时不绑定当前会话。
+- skill 在“登记常用智能体”流程中需要先创建 lane。
+
+行为：
+
+- 必须确认 `lane-id`、`purpose`、`write_scope`。
+- 输出或执行：
+
+```bash
+starwork multiagent add <lane> --purpose "<text>" --write "<path-globs>"
+```
+
+### `bind`
+
+触发场景：
+
+- 用户要把当前会话绑定到已有职责位。
+- skill 在“登记常用智能体”流程中创建或确认 lane 后绑定当前会话。
+
+行为：
+
+- 优先使用真实会话 ID。
+- 无法识别时提示使用 `--session <agent:session-id>`。
+
+### `release`
+
+触发场景：
+
+- 用户说“这个会话不再负责某 lane”
+- 用户说“释放职责位”
+
+行为：
+
+- 先提醒更新 worklog。
+- 再执行 release。
+
+### `status`
+
+触发场景：
+
+- 用户想看当前多 Agent 分工。
+- 用户想知道哪些 lane 未绑定。
+- 用户想知道有哪些共享请求或共享输出。
+
+行为：
+
+- 默认只读，可直接执行：
+
+```bash
+starwork multiagent status --json
+```
+
+- AI 基于输出解释当前分工、未绑定 lane、共享请求。
+
+### `share`
+
+触发场景：
+
+- 某个 Agent 的输出需要其他 lane 读取。
+
+行为：
+
+- 必须确认来源 lane、标题、路径、受众 lane、状态。
+- 只登记索引，不搬运文件。
+
+## Safety Rules
+
+- 这是系统 Skill，和 `starworkInit`、`starworkDoctor` 一样全局安装。
+- 不拆成多个子命令 skill；保持一个入口，降低安装和触发成本。
+- 不写死后端、前端、测试等职责；示例只能作为说明，不能作为默认 lane。
+- 不写入 `matters/registry.md`。
+- 不创建任务系统、锁系统、JSON manifest。
+- 写入前默认 dry-run 或确认；只读 `status` 可以直接运行。
+- 如果用户要求实际执行，执行后建议运行：
+
+```bash
+starwork multiagent status --target <path> --json
+```
+
+## Test Plan
+
+### 静态检查
+
+- `starworkMultiagent/SKILL.md` frontmatter 可被 skills CLI 识别。
+- skill description 覆盖 `init`、`add`、`bind`、`release`、`status`、`share` 的触发语义。
+
+### 文档检查
+
+- `product/skills/README.md`、产品 README、CLI/Skill 注册表均出现 `starworkMultiagent`。
+- 文档中不把旧的 lanes 命令名作为可用命令出现。
+
+### 行为验收
+
+- 给定“请把当前会话创建为一个负责资料整理的常用智能体”，skill 将其解释为“登记常用智能体”，必要时先 `init`，然后生成 `add + bind` 命令。
+- 给定“我想让三个 Agent 分别负责资料、写作、审校”，skill 输出 `multiagent init` 和后续 `add/bind` 建议，而不是生成固定前端/后端/测试。
+- 给定“把当前 Codex 绑定到 review”，skill 要求或使用 session ID，并生成 `starwork multiagent bind review ...`。
+- 给定“这个输出给 writing 和 review 看”，skill 生成 `starwork multiagent share ...`，不移动原文件。
+
+## Assumptions
+
+- 采用一个总 Skill：`starworkMultiagent`。
+- 归属为系统 Skill，默认通过 `skills add ... -g` 安装。
+- 默认策略是“确认后执行”：AI 可以运行只读状态检查；写入类命令先 dry-run 或征得用户确认。