@microi.net/cli 5.5.9 → 5.6.1

package/skills/workspace-conventions/references/progressive-03-cli-/344/270/216-ide-/346/217/222/344/273/266/351/224/231/347/211/210/345/205/261/345/255/230/347/272/246/345/256/232.md

@@ -3,25 +3,25 @@
 > 按需读取；本文件由 SKILL.md 的原章节无损拆分。
 
 <!-- microi-progressive:chunk id=workspace-conventions-038 sha256=57098466d31d0636bf330fde545daff8cb8e4116ac6ea2efff8abc729fdcef77 -->
-## CLI 与 IDE 插件错版共存约定
-
-- CLI 与 IDE 插件共用配置、Token、MCP、Skills 或生成文件时，所有持久化协议必须按“新字段可选、旧字段保留、未知字段不删除”设计。不得将 JSON 解析到旧类型后只序列化已知字段。
-- 共享 JSON/Token 必须失败关闭：解析失败时保留原文件并停止写入；写入使用同目录临时文件原子替换，多进程可写文件还要使用带超时/死锁恢复的文件锁。
-- MCP 配置要写入工具来源与三段版本；替换同名或同 API/OsClient 的 Microi Server 时实行“较新提供者优先”，同时保留非 Microi MCP。Skills/AI 指令也要记录 bundle/file 版本，旧 bundle 不得覆盖新 bundle 已生成的内容。
-- 已发布的历史二进制无法被新代码追溯修复。诊断必须把无版本记录标记为 `legacy`，说明更新或用较新一端重新初始化的恢复路径；不得宣称新代码已让任意历史版本绝对共存。
-- 多 registry 联合发布没有跨站点原子事务。必须在递增版本前验证本轮必选目标的凭据/权限，对每个产物校验同版本，发布后逐端公开回读。可选目标（例如尚未开通 scope 的 npm CLI）预检或发布失败时，不得阻断已经通过预检的必选目标；必须保留同版本产物、明确报告部分完成并给出精确补发命令。要求全目标成功的发布应提供显式严格模式。补发只能复用完全相同的源码/产物；代码改动后必须发新版本。
-
-### 复盘：可选 npm 目标阻断两个扩展市场发布
-
-- 触发场景：联合发布同时包含两个扩展市场和 npm CLI，但 npm 组织 scope 尚未创建，脚本在版本递增前直接退出，导致已经具备权限的两个扩展市场也无法发布。
-- 根因：发布脚本把三个 registry 都视为同一个全局硬门禁，并把最容易受账号、scope 和 2FA 影响的 npm 放在扩展市场之前，没有区分必选目标、可选目标和严格发布模式。
-- 通用规则：默认发布按目标隔离；先完成并回读必选目标，再独立尝试可选目标。可选目标失败应保留同版本不可变产物并输出补发入口；只有显式严格模式才要求所有目标预检通过后继续。
-- 自动化检查：模拟 npm 未登录、scope 404 和 npm publish 非零退出，断言两个扩展市场的发布调用与回读仍会执行；另测严格模式在版本递增前停止，补发命令不递增版本且复用同版本产物。
-
-### 复盘：npm 已接收新版本但公共回读短暂 404
-
-- 触发场景：`npm publish` 已成功返回，npmjs.com 包页面也已出现新包或新版本，但紧随其后的 `npm view <package>@<version> version` 在数十秒内连续返回 E404，联合发布脚本因此把成功发布误报为失败。
-- 根因：新 scope/新版本在 npm 网站、写入节点和公共 registry 读取节点之间存在短暂传播窗口；固定少量、短间隔轮询不足以区分“尚未发布”和“已经接收但尚未公开传播”。
-- 通用规则：发布命令成功和公共回读确认必须作为两个阶段记录。npm 新版本回读使用 `--prefer-online` 和分钟级有限重试；重试结束仍为 E404 时标记 `pending-propagation`，禁止自动重发同一不可变版本，并提供独立只读验证命令稍后确认。只有发布命令本身失败且公共 registry 也始终不存在时，才进入补发流程。
-- 自动化检查：模拟 `npm publish` 成功后前几次 `npm view` 返回 E404、随后返回期望版本，断言不会重复发布；再模拟重试窗口结束仍为 E404，断言输出待传播状态和只读验证命令，而不是提示重新上传同一版本。
+## CLI 与 IDE 插件错版共存约定
+
+- CLI 与 IDE 插件共用配置、Token、MCP、Skills 或生成文件时，所有持久化协议必须按“新字段可选、旧字段保留、未知字段不删除”设计。不得将 JSON 解析到旧类型后只序列化已知字段。
+- 共享 JSON/Token 必须失败关闭：解析失败时保留原文件并停止写入；写入使用同目录临时文件原子替换，多进程可写文件还要使用带超时/死锁恢复的文件锁。
+- MCP 配置要写入工具来源与三段版本；替换同名或同 API/OsClient 的 Microi Server 时实行“较新提供者优先”，同时保留非 Microi MCP。Skills/AI 指令也要记录 bundle/file 版本，旧 bundle 不得覆盖新 bundle 已生成的内容。
+- 已发布的历史二进制无法被新代码追溯修复。诊断必须把无版本记录标记为 `legacy`，说明更新或用较新一端重新初始化的恢复路径；不得宣称新代码已让任意历史版本绝对共存。
+- 多 registry 联合发布没有跨站点原子事务。必须在递增版本前验证本轮必选目标的凭据/权限，对每个产物校验同版本，发布后逐端公开回读。可选目标（例如尚未开通 scope 的 npm CLI）预检或发布失败时，不得阻断已经通过预检的必选目标；必须保留同版本产物、明确报告部分完成并给出精确补发命令。要求全目标成功的发布应提供显式严格模式。补发只能复用完全相同的源码/产物；代码改动后必须发新版本。
+
+### 复盘：可选 npm 目标阻断两个扩展市场发布
+
+- 触发场景：联合发布同时包含两个扩展市场和 npm CLI，但 npm 组织 scope 尚未创建，脚本在版本递增前直接退出，导致已经具备权限的两个扩展市场也无法发布。
+- 根因：发布脚本把三个 registry 都视为同一个全局硬门禁，并把最容易受账号、scope 和 2FA 影响的 npm 放在扩展市场之前，没有区分必选目标、可选目标和严格发布模式。
+- 通用规则：默认发布按目标隔离；先完成并回读必选目标，再独立尝试可选目标。可选目标失败应保留同版本不可变产物并输出补发入口；只有显式严格模式才要求所有目标预检通过后继续。
+- 自动化检查：模拟 npm 未登录、scope 404 和 npm publish 非零退出，断言两个扩展市场的发布调用与回读仍会执行；另测严格模式在版本递增前停止，补发命令不递增版本且复用同版本产物。
+
+### 复盘：npm 已接收新版本但公共回读短暂 404
+
+- 触发场景：`npm publish` 已成功返回，npmjs.com 包页面也已出现新包或新版本，但紧随其后的 `npm view <package>@<version> version` 在数十秒内连续返回 E404，联合发布脚本因此把成功发布误报为失败。
+- 根因：新 scope/新版本在 npm 网站、写入节点和公共 registry 读取节点之间存在短暂传播窗口；固定少量、短间隔轮询不足以区分“尚未发布”和“已经接收但尚未公开传播”。
+- 通用规则：发布命令成功和公共回读确认必须作为两个阶段记录。npm 新版本回读使用 `--prefer-online` 和分钟级有限重试；重试结束仍为 E404 时标记 `pending-propagation`，禁止自动重发同一不可变版本，并提供独立只读验证命令稍后确认。只有发布命令本身失败且公共 registry 也始终不存在时，才进入补发流程。
+- 自动化检查：模拟 `npm publish` 成功后前几次 `npm view` 返回 E404、随后返回期望版本，断言不会重复发布；再模拟重试窗口结束仍为 E404，断言输出待传播状态和只读验证命令，而不是提示重新上传同一版本。
 <!-- /microi-progressive:chunk -->