@microi.net/cli 6.0.3 → 6.0.5

package/skills/workspace-conventions/SKILL.md

@@ -45,7 +45,7 @@ description: 每次 Microi 任务开始前必读的基础规范。用于识别
 工作区保护始终有效：保留他人差异与共享进程，临时产物只放根 `.tmp/`，闭源源码只从独立内部仓提交。修改/提交前读取 [共享工作区与 Git 保障](references/progressive-04-工作区与平台专项保障.md#多对话共享工作区变更归属保护强制)；启动构建、测试服务或浏览器前读取同文件资源/OOM规则并检查现有资源。后端/任务/权限变更读取分布式与安全章节；平台源码定位、文档和 Skills 修改读取对应章节。平台能力四项检查仍固定保留在本入口。
 
 <!-- microi-progressive:begin -->
-<!-- microi-progressive:chunk id=workspace-conventions-000 sha256=aca51a9aec956dd31d4865eeb25b3d33452106b363659970773b40b48d22e346 -->
+<!-- microi-progressive:chunk id=workspace-conventions-000 sha256=0c3f889089f09b9b43f1ae7168f9e20a7aa3e1324b1cf5c94052a78ffb1792b9 -->
 ## 任务启动前 Skill 读取规则（强制）
 
 AI 处理任何 Microi 低代码、V8、MCP、OpenClaw、采集引擎、前端、后端、UniApp、文档、测试或交付任务前，必须先按任务类型读取相关 `microi.skills/**/SKILL.md`。不能等到写代码或出问题后才补读。
@@ -81,7 +81,7 @@ AI 处理任何 Microi 低代码、V8、MCP、OpenClaw、采集引擎、前端
 
 - “无需修改”必须逐项有具体理由，例如纯内部优化无元数据变化可不升应用版本，现有 MCP 已支持该配置可不新增工具；不得默认四项都做，也不得默认四项都省略。需要修改的项目应在本次授权范围内完成并验证，受权限、网络或发布渠道阻挡时明确未完成项，不能用本地修改代替线上发布。
 - 任务若只要求分析、评审或制定规范，仍保持只读或仅修改指定规范；身份标记不授权无关线上写入。客户部署、容器更新和应用自动安装与官方发布是独立动作，服从用户指定的手动/自动边界；用户明确手动更新时不得擅自部署。
-- 收尾必须区分“源码/文档已修改、测试通过、应用已发布回读、Skills/插件已打包或已分发、镜像已推送、客户已安装或已部署”。只有实际渠道验收成功才能说其它用户已可获取；不得把文档本地构建或插件本地副本同步称为已上线。
+- 收尾必须区分“源码/文档已修改、测试通过、应用已发布回读、Skills/插件已打包或已分发、镜像已推送、客户已安装或已部署”。npm、NuGet、Docker、Visual Studio Marketplace、Open VSX 等制品渠道以发布命令明确成功作为发布完成依据，默认不做发布后回读、不等待索引或 CDN 传播；不得把本地构建或插件本地副本同步称为已发布。发布成功不等于目标服务已部署，运行与业务验收仍按任务要求执行。
 
 ### 平台回归与独立应用测试归属（强制）
 

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

@@ -2,28 +2,28 @@
 
 > 按需读取；本文件由 SKILL.md 的原章节无损拆分。
 
-<!-- microi-progressive:chunk id=workspace-conventions-038 sha256=5dbfb261596e9c61fcc330adca7a1ff40a3a1508cd89be3c7b10410e591aa557 -->
+<!-- microi-progressive:chunk id=workspace-conventions-038 sha256=1b65652abc8ca096a22d79a62b32c74557e5fc3daa7d81f3c192c4b9e37e4665 -->
 ## 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）预检或发布失败时，不得阻断已经通过预检的必选目标；必须保留同版本产物、明确报告部分完成并给出精确补发命令。要求全目标成功的发布应提供显式严格模式。补发只能复用完全相同的源码/产物；代码改动后必须发新版本。
+- 多 registry 联合发布没有跨站点原子事务。必须在递增版本前验证本轮必选目标的凭据/权限，对每个产物校验同版本，按各渠道发布命令明确返回成功记录发布完成，默认不追加公开回读。可选目标（例如尚未开通 scope 的 npm CLI）预检或发布失败时，不得阻断已经通过预检的必选目标；必须保留同版本产物、明确报告部分完成并给出精确补发命令。要求全目标成功的发布应提供显式严格模式。补发只能复用完全相同的源码/产物；代码改动后必须发新版本。
 
 ### 复盘：可选 npm 目标阻断两个扩展市场发布
 
 - 触发场景：联合发布同时包含两个扩展市场和 npm CLI，但 npm 组织 scope 尚未创建，脚本在版本递增前直接退出，导致已经具备权限的两个扩展市场也无法发布。
 - 根因：发布脚本把三个 registry 都视为同一个全局硬门禁，并把最容易受账号、scope 和 2FA 影响的 npm 放在扩展市场之前，没有区分必选目标、可选目标和严格发布模式。
-- 通用规则：默认发布按目标隔离；先完成并回读必选目标，再独立尝试可选目标。可选目标失败应保留同版本不可变产物并输出补发入口；只有显式严格模式才要求所有目标预检通过后继续。
-- 自动化检查：模拟 npm 未登录、scope 404 和 npm publish 非零退出，断言两个扩展市场的发布调用与回读仍会执行；另测严格模式在版本递增前停止，补发命令不递增版本且复用同版本产物。
+- 通用规则：默认发布按目标隔离；先完成必选目标发布，再独立尝试可选目标。可选目标失败应保留同版本不可变产物并输出补发入口；只有显式严格模式才要求所有目标预检通过后继续。
+- 自动化检查：模拟 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，断言输出待传播状态和只读验证命令，而不是提示重新上传同一版本。
+- 通用规则：发布命令明确返回成功即可报告该渠道发布成功，不需要再执行 `npm view`、市场版本查询、制品下载或轮询，不默认添加 `--verify-all` / `--verify-only`，也不以索引传播延迟把成功降为待完成。只有发布结果不明确、报错，或用户明确要求渠道核验时才按需回读；结果未知时先查状态，禁止盲目重复上传。成功发布的不可变版本不得因传播延迟重新上传或升版。用户要求的线上部署、实际页面和业务联调仍独立执行。
+- 自动化检查：模拟发布命令明确成功，断言直接记录该渠道发布成功且不触发回读或重传；模拟结果未知，断言进入状态诊断而非盲目上传；用户显式要求核验时保留只读验证入口。
 ## Git 大文件推送检查（强制）
 
 - 每次 Git 推送前检查暂存内容及全部待推送提交中新引入的 Blob，不能只看工作树、最新提交或首尾文件差异；中间提交加入后又删除的大文件仍会进入历史。以刚核验的远端引用为基线，结合 `git rev-list --objects` 与 `git cat-file --batch-check` 检查真实对象大小；基线或对象不完整时先补齐并复核，不能绕过检查。

package/skills/workspace-conventions/references/progressive-04-/345/267/245/344/275/234/345/214/272/344/270/216/345/271/263/345/217/260/344/270/223/351/241/271/344/277/235/351/232/234.md

@@ -139,7 +139,7 @@ AI 在工作区任意任务中生成的**一次性临时脚本、诊断文件、
 - 文档改动后执行 `npm run docs:build`；验收时检查本次没有无理由新增 `.md` 页面或导航路由。
 
 <!-- /microi-progressive:chunk -->
-<!-- microi-progressive:chunk id=workspace-conventions-009 sha256=90d90834a2080c2a2f08bae1092557761b6b23c79274f8d4dc2b115c121f5b51 -->
+<!-- microi-progressive:chunk id=workspace-conventions-009 sha256=4551654837b9b34fc1d4dabcda3147541a61b484a52ad8ddc02ac84c1c822372 -->
 ## 多对话共享工作区变更归属保护（强制）
 
 ### 功能验收后的源码提交与推送（强制）
@@ -147,7 +147,7 @@ AI 在工作区任意任务中生成的**一次性临时脚本、诊断文件、
 - 每个已完成并通过相应验收的功能、修复或独立里程碑，必须把本任务源码、测试和必要文档按实际 Git 仓库分别提交并推送；不能仅保存在工作区、stash、临时目录或已发布产物中。用户明确要求不提交/不推送、只读任务和未完成的实验除外，不为无改动仓库制造空提交。
 - 提交前回读工作树、暂存区、上游和远端；按可核验的本任务 hunk 暂存，保留其它对话的改动与既有暂存项。公开根仓只提交公开代码；闭源目录只从各自独立仓库根提交并推送到其已有内部远端，严格执行公开仓闭源路径门禁，不能用 gitlink 或强制添加绕过隔离。
 - 推送前先获取上游的新提交并安全整合；共享工作区有并行改动时优先在隔离候选中合并，不用整树 stash/reset 覆盖他人成果，不强推共享分支，不绕过仓库 Hook。需要精确回滚时保留独立、说明清楚的功能提交；回滚已推送功能通常使用新的反向提交，不改写共享历史。
-- 正式发布的候选必须包含此前已交付功能和本任务已核验的源码，先按仓安全本地提交，再冻结包含闭源源码在内的完整构建输入、提交号和内容哈希；仅更新说明页面时也要核对整个站点候选。Git 远端推送/回读与制品发布是独立交付步骤，默认可并行或在制品之后补推，不能把远端已包含 HEAD、推送成功或 Gitee/GitLab/GitHub 可达作为 NuGet、API/PC Docker、官网 Docker 等合格制品的上传前置条件。保留对应产品的 Full、闭源隔离、DLL 加密、候选/产物一致性、最终冒烟和渠道回读；官网继续执行整站构建与内容/入口验收。隔离工作树干净或持有发布锁，均不能代替源码完整性检查。
+- 正式发布的候选必须包含此前已交付功能和本任务已核验的源码，先按仓安全本地提交，再冻结包含闭源源码在内的完整构建输入、提交号和内容哈希；仅更新说明页面时也要核对整个站点候选。Git 远端推送/回读与制品发布是独立交付步骤，默认可并行或在制品之后补推，不能把远端已包含 HEAD、推送成功或 Gitee/GitLab/GitHub 可达作为 NuGet、API/PC Docker、官网 Docker 等合格制品的上传前置条件。保留对应产品的 Full、闭源隔离、DLL 加密、候选/产物一致性、最终冒烟；渠道发布命令明确成功即完成该渠道发布，默认不回读、不等待传播，异常或结果未知时按需诊断。官网继续执行整站构建与内容/入口验收。隔离工作树干净或持有发布锁，均不能代替源码完整性检查。
 - 收尾逐仓记录本地提交号、远端分支和独立回读结果，分别报告源码、NuGet、Docker、官网及客户部署。远端网络、认证或容量故障首次失败后最多短重试一次，累计定向排障不超过 5 分钟；保存本地提交、失败原因和待补推清单，已通过全部制品门禁的渠道立即继续发布，不得反复请求同一例外授权。源码冲突、归属不明、保护路径违规、缺少实际构建输入或候选漂移必须先解决，不能当作可忽略的远端故障。后续合并改变源码/构建输入时重新冻结并按新候选验收，禁止将新提交冒充已发布制品来源；缺少远端回执仍标为源码未交付，不得宣称全部完成。
 - 官方应用发布仅验收 `microi_itdos` 对应主租户 `iTdos` 的更新与回读，不批量升级、不等待线上子租户；子租户升级是独立部署任务。Full 仍保留已登记的隔离主、子测试租户及越权、升级回归，不将测试夹具称为官网子租户部署。
 - 发布边界必须在 `Microi一键编译发布.sh` 及其调用入口生效，不能只依赖 AI 提示词。普通用户直接运行脚本同样保留适用的 Full、DLL 加密、冒烟和候选校验；运行脚本不授予官方 iTdos 写入权，也不授权升级其全部生产子租户。