create-windy 0.3.17 → 0.3.18

package/README.md

@@ -68,10 +68,9 @@ npx create-windy@latest my-dashboard \
 为离线部署提供运行时验签与限制态。
 
 选择 `system.license` 时，Server 与 Web 通过 npm 依赖
-`@southwind-ai/license@^0.1.1` 使用运行时能力；生成项目及 `create-windy` 模板快照都不包含
-`packages/license-sdk` 源码。公网 npm 已发布兼容的 `@southwind-ai/license@0.1.2`；
-发布包含该模块的新版创建器前，必须先确认目标 registry 中存在兼容版本，并完成真实
-安装回归。
+`@southwind-ai/license@^0.1.5` 使用运行时能力；生成项目及 `create-windy` 模板快照都
+不包含 `packages/license-sdk` 源码。发布包含该模块的新版创建器前，必须先确认目标
+registry 中存在该版本，并完成真实安装回归。
 
 未选择的模块会从 package、源码、依赖、Composition、Manifest、schema、migration
 和模块文档中物理排除，而不是只隐藏菜单或关闭 Feature。模块依赖会自动补齐；未知
@@ -130,40 +129,19 @@ bun run windy sync-docker
 bun run windy update --check
 bun run windy update --dry-run
 bun run windy update
-bun run windy reconcile --to <精确目标版本>
 ```
 
-更新器不检查 Git 工作区是否干净：只规划目标版本实际变更的受管文件，从 npm 历史
-artifact 重建 Base，并以 Base/Ours/Theirs 合并共享脚手架。未触及的业务修改不会进入
-更新判断；`package.json` 使用字段级合并；已发布 migration 只允许追加；冲突发生时不写
-项目，验证失败则从 `.windy/backups/` 自动回滚。项目锁定
-的 CLI 检测到新版后，会委托给目标版本生成完整更新计划。受管清单 schema v3 用不含
-hash 的 missing tombstone 记住客户删除的 `project-owned` 路径；后续版本不会把它
-当作首次新增而重建，客户自行恢复文件后则采纳客户实际正文基线。既有 schema v1/v2
-仍可读取，未知或损坏状态会 fail closed。
-
-当发布说明明确指出历史受管清单与确定性格式化结果不一致时，可使用
-`reconcile --to <精确目标版本>`。该命令默认只演练；显式增加 `--apply` 后也只更新
-`.windy/files.json` 和无正文报告，不修改项目源码或推进 Project Lock。来源/目标均
-校验公网 npm artifact identity 与 integrity，只有内置不可变 proof 完整命中的
-`windy-managed` 文件可以对账；`shared-scaffold` 也必须精确命中内置 proof，
-`project-owned` 和未知语义差异保持未决。对账不修改项目源码；中断仍通过
-`doctor --repair` 恢复事务。
-
-公网 `0.3.0` 的默认 Git + Oxc 项目需要先运行
-`create-windy@0.3.2 reconcile --to 0.3.0`，确认后增加 `--apply`，提交生成的清单和
-报告，再运行 `create-windy@0.3.2 update --to 0.3.2`。这里的同版本目标是为了同时
-校验来源与目标均为同一个不可变 `0.3.0` artifact，不会把 Project Lock 提前推进。
-
-公网 `0.2.34` 的默认推荐模块项目也先对账到 `0.3.0`。该 profile 只有在 Project
-Lock、Oxfmt 配置、manifest 与来源 artifact 哈希全部精确命中时才启用专属 proof；
-未知 formatter 输出继续保持未决。当前公网默认项目实测为 12 个可证明、0 个未决，
-而非默认的 sharp-sword 仍为 5 个可证明、2 个未决。
-
-发布后隔离回归确认全新 `0.3.2` 默认 Git/Oxc 项目 doctor 为 `0/0`。真实
-`0.2.34` 经 `12/0` 对账和 `160` 文件、`0` 冲突更新后，真实 `0.3.0` 经
-`81/2` 对账和 `30` 文件、`0` 冲突更新后，均完成正常 Husky/Oxfmt 提交并最终
-收敛到 Git 干净、doctor `0/0`。
+`0.3.17` 是 Starter 更新的最低支持基线。更新器不检查 Git 工作区是否干净：只规划
+目标版本实际变更的受管文件，从 source Project Lock 指向的精确 npm artifact 重建
+Base，并以 Base/Ours/Theirs 合并共享脚手架。未触及的业务修改不会进入更新判断；
+`package.json` 使用字段级合并；已发布 migration 只允许追加；冲突发生时不写项目，
+验证失败则从 `.windy/backups/` 自动回滚。项目锁定的 CLI 检测到新版后，会委托给
+目标版本生成完整更新计划。
+
+受管清单使用 schema v4：`hash` 冻结下游实际正文，`artifactHash` 在两者不同时记录
+公开模板基线；无正文的 missing tombstone 记住客户删除的 `project-owned` 路径。
+低于 `0.3.17` 的 Project Lock、旧清单 schema、损坏的 artifact lineage 或 recipe
+缺口都会在写文件前 fail closed，不提供旧状态的自动迁移路径。
 
 本地 Web 默认使用 8746；如果该端口属于其它服务，会自动尝试 8747、8748 等端口。
 如果检测到同一个项目已启动，则直接复用现有地址。