@microi.net/cli 6.3.0 → 6.3.2

package/skills/workspace-conventions/references/progressive-02-microi-net-api-/346/234/254/345/234/260/345/220/257/345/212/250/347/272/246/345/256/232.md

@@ -131,14 +131,14 @@ AI 通过 MCP 修改 `diy_field`、`diy_table`、`sys_menu`、`sys_osclients`、
 3. 最终交付说明必须写清楚：改了哪个表/字段，回读值是什么，刷新了哪些缓存，验证入口是什么。若某个缓存刷新接口失败或只能部分成功，需要把失败消息原样摘要出来，不能把“写入成功”当作“页面一定生效”。
 
 <!-- /microi-progressive:chunk -->
-<!-- microi-progressive:chunk id=workspace-conventions-031 sha256=cea2d1c912ffc31136a859fd10f282c488b5b8d1bf3f2ced7c39084b23e5ccf5 -->
+<!-- microi-progressive:chunk id=workspace-conventions-031 sha256=d88cab04e7e2d1cc243fe1786b1d18728069813cf30e2c9da18975fc8c32de07 -->
 ## MCP 可用性排查约定
 
 VS Code、Cursor 或 Codex 设置界面显示某个 MCP 服务器“已启用”，不代表当前 AI 会话一定已经成功加载了对应工具。AI 在声称“可以通过 MCP 操作”之前，必须完成一次真实可调用性验证：
 
-- 先用当前会话可用的工具发现能力查找目标 MCP 工具；若工具发现为 0，不能继续假设 MCP 可用。
+- 先用当前会话可用的工具发现能力查找目标原始 MCP 工具及 `microi_codex` 单入口；单入口存在时先用 `profiles/list_tools/describe_tool`，不能因未展开全部 `microi_*` 就认定没有工具。发现为 0 时不能假设原生 MCP 可用，但仍可按下方官方 CLI 通道验证。
 - 再用 MCP 资源/模板列表或最小 `initialize` / `tools/list` 探测确认服务器握手成功。若返回 `handshaking with MCP server failed`、`initialize response`、`connection closed` 等错误，要明确说明“配置存在但当前会话不可调用”。
-- 同时检查 `.vscode/mcp.json`、`.cursor/mcp.json`、`.mcp.json` 和 `~/.codex/config.toml` 是否能解析，并确认目标服务器名、`MICROI_API_URL`、`MICROI_OS_CLIENT`、`MICROI_TOKEN_FILE` 已写入。
+- 按实际宿主检查配置是否能解析，例如 `.vscode/mcp.json`、`.cursor/mcp.json`、`.mcp.json`、`.workbuddy/mcp.json`、`~/.workbuddy/mcp.json` 或 `~/.codex/config.toml`，确认目标服务器名和连接引用；不要把其它宿主的配置缺失当作当前宿主故障，也不输出秘密。
 - 如果手动启动 `mcp-server.js` 能响应，而当前 AI 会话仍握手失败，应优先怀疑 MCP stdio 协议兼容、初始化响应格式/大小、服务器进程提前退出或插件生成的 Codex 配置顺序问题，而不是简单归因于“用户没启用”。
 - 当 MCP 工具数量较多时，`tools/list` 的前段必须优先返回通用建模和维护工具，例如 `microi_get_db_schema`、`microi_get_field_list`、`microi_add_field`、`microi_update_field`、`microi_refresh_schema_cache`、`microi_create_table`、`microi_create_module`、`microi_get_event_code`、`microi_save_event_code`。部分 AI 客户端或模型上下文只注入前若干个工具，若核心工具排在后面，会误报“缺少 MCP 工具”。
 - MCP 的初始化说明必须使用真实 `MICROI_OS_CLIENT` 作为租户边界。中文显示名通过 ASCII 的 `MICROI_LABEL_BASE64` 传输并在 MCP 内解码，旧版 `MICROI_LABEL` 只作兼容；显示名不能当成租户 Key 写入“只能管理某租户”的安全提示。
@@ -205,16 +205,16 @@ AI 只要修改了 `Microi.Server/**` 下会影响 `Microi.net.Api` 运行结果
 这条规则优先于“避免打断正在运行服务”的默认谨慎策略；本地开发联调场景下，用户通常需要 launch profile 当前端口上的后端加载最新代码。
 
 <!-- /microi-progressive:chunk -->
-<!-- microi-progressive:chunk id=workspace-conventions-036 sha256=b91c431950e4c5d268d40c6372e5780b2c7e8b4ca4339871085cda91b7d932bc -->
+<!-- microi-progressive:chunk id=workspace-conventions-036 sha256=c891cd4e25e36eb46befe0a2305d59170c0dcd76ad8bc7d8448cb07453ba3776 -->
 ## MCP 可调用性诊断补充
 
-当用户反馈“Codex/VS Code 设置中能看到 MCP，但当前 AI 会话不能调用对应工具”时，不能只回答“当前会话没有注入”。必须按层排查：
+当用户反馈“Codex/WorkBuddy/VS Code 设置中能看到 MCP，但当前 AI 会话不能调用对应工具”时，不能只回答“当前会话没有注入”。必须按层排查：
 
-1. 先确认 `.vscode/mcp.json`、`.cursor/mcp.json`、工作区根 `.mcp.json` 和 `~/.codex/config.toml` 都能解析，且目标 server key 为稳定 ASCII 格式，例如 `microi_itdos`，不要使用中文名或横杠。
-2. 再用 Microi.Agent 插件的“诊断 MCP 可调用性”命令，或等价脚本直接启动对应 `mcp-server.js` / `mcp-codex-stdio-adapter.js`，执行 `initialize` 和 `tools/list`，确认 `microi_get_db_schema`、`microi_get_field_list`、`microi_add_field`、`microi_update_field`、`microi_refresh_schema_cache` 等核心工具真实返回。
+1. 先核对实际宿主及其项目/用户级配置，而非只凭模型自述。WorkBuddy 使用 `.workbuddy/mcp.json` / `~/.workbuddy/mcp.json`，Codex 使用 `~/.codex/config.toml`；检查相应配置能解析且目标 server key 为稳定 ASCII 格式。连接保持用户选定的 API、OsClient、Type、Network；不要求安装无关宿主。
+2. 用 Microi.Agent 插件的“诊断 MCP 可调用性”命令，或官方 `microi mcp tools --profile <mcpName> --workspace "<工作区>" --json` 进行真实握手和目录读取，确认核心工具及其 Schema；工具总数不能硬编码，也不能从配置文件存在推断成功。
 3. 如果当前 AI 客户端支持工具发现或延迟加载，AI 必须先主动执行工具发现/热加载流程，例如 `tool_search`、客户端 MCP refresh、Microi.Agent 的启动/诊断命令；不要先让用户手动重启、重载或重新生成 MCP。
-4. 如果真实握手成功但 Codex 当前对话仍没有注入 `mcp__...` 工具，AI 仍应优先使用等价的 MCP stdio JSON-RPC 直连 fallback 完成当前任务：读取对应 MCP 配置、启动 adapter/server、执行 `initialize`、`tools/list`、`tools/call`，并严格遵守该 MCP 绑定的 API Server 和 OsClient 边界。直连脚本必须放在 `.tmp/` 或使用一次性 stdin，不得散落到项目目录。
-5. 只有在客户端不支持热加载、直连 fallback 也无法完成任务，或写操作边界无法确认时，才告知用户需要新开对话、重载 Codex 或检查 MCP 配置。说明必须写清楚：MCP 配置和进程是否可用、当前会话为什么没有注入工具、已经尝试过哪些自动恢复动作。
+4. 同时发现 `microi_codex` 单入口；存在时通过 `profiles/list_tools/describe_tool` 使用。原生入口仍不可用且宿主允许终端执行时，按 [官方 CLI 通道](../../microi-codex-installer/SKILL.md#当前对话没有吾码工具时继续工作) 运行 `microi mcp call <microi_tool> --params-stdin --profile <mcpName> --workspace "<工作区>" --json`，先调用 `microi_get_status` 核对身份再继续任务。使用包内同源标准 stdio MCP，不让 AI 临时实现桥接，也不绕过确认、权限和回读。
+5. 只有宿主明确要求的信任/启用操作、终端不可用、官方通道失败或授权边界无法确认时，才提出最小用户操作。明确禁用或策略拒绝不使用替代通道绕过。说明配置、握手、CLI 调用和原生工具注册各自证据；不能把“当前未发现工具”解释为已证实“不支持热加载”，也不把新开对话作为默认前置条件。
 6. 如果握手失败，要把失败层级说清楚：配置文件解析失败、路径不存在、token 文件缺失、MCP 进程启动失败、`initialize` 失败、`tools/list` 缺核心工具，不能把这些问题混成“用户没启用 MCP”。
 7. Microi.Agent 生成 MCP 配置时应清理旧的中文/横杠 Microi MCP key，只保留 `microi_<osClient>` 或 `microi_<osClient>_<host>` 形式，避免不同 AI 客户端因 namespace 不稳定而无法注入工具。