升级核心包

应用拥有自己的业务代码，平台能力通过 Go module 与 @modu/web 提供。核心升级的单位是配套依赖版本；业务不再通过合并脚手架源码获取更新。

升级前确认

阅读目标版本的变更说明，核对 Go/npm 配套版本、公开接口变化、迁移要求和扩展 CoreAPI 兼容性。版本号的用途见版本与文档基线。

当前 0.7 属于开发基线，核心包尚未正式发布当前版本 0.7.0 尚未正式发布。以下流程用于已配置私有源、已取得真实配套产物的独立应用。

1. 更新配套依赖

将命令中的 X.Y.Z 替换为维护者实际交付的版本；它是占位符，不是已发布版本。

# 应用 server/
GOWORK=off go get github.com/igwen6w/modu/server@vX.Y.Z
GOWORK=off go mod tidy
GOWORK=off go list -m -json github.com/igwen6w/modu/server

# 应用 web/
pnpm add @modu/web@X.Y.Z --save-exact

检查最终选中的 Go module graph，不能仅根据 go.sum 判断版本。前端提交精确依赖与更新后的锁文件。

2. 重新生成装配清单

# 应用 server/
go run ./cmd/modu catalog generate
go run ./cmd/modu catalog check
go run ./cmd/modu check

这些命令以当前核心和应用扩展生成最终 catalog。出现声明或版本冲突时先修复，再启动应用。

3. 迁移与回归

# 应用 server/
go run . artisan migrate
go build ./...
go vet ./...
# 使用专用测试数据库
go test ./...

# 应用 web/
pnpm extension:check
pnpm test
pnpm typecheck
pnpm lint
pnpm build
pnpm extension:verify-build

检查登录、权限、自有业务 CRUD、扩展启停及持久数据。兼容升级保留业务配置和已存数据，不重跑演示种子，不执行 reset 或 fresh。

4. 提交应用升级

同一提交包含 Go/npm 配套依赖、锁文件、生成的 catalog，以及发布说明要求的公开接口适配。应用配置和业务实现继续由应用维护。

如果兼容版本仍要求复制核心 service、页面或迁移文件，说明应用依赖边界需要修复；将缺失能力收敛到核心公开接口后再通过包交付。

破坏性变化

项目仍在开发阶段，可以通过明确的破坏性版本调整公开接口。这次 0.7 重构建立新的开发基线 0.7.0 重构建立了新的开发起点，没有提供旧源码项目或生产数据库自动转换工具。版本说明必须写清适用起点和所需代码调整。