模块版本创建与 Bundle 交付

创建模块版本

先检查项目 Git 状态和差异，只提交预期的 module.json 与 methods/*.json：

HTTP 方法的 methodBody 必须先按 HTTP methodBody 源契约 收敛为 snake_case；兼容读取旧字段不代表新提交可以继续写驼峰。

baijimu workspace project checkout <projectId> --workspace-id <workspaceId> --directory <directory>
cd <directory>
git status --short
git diff -- module.json
git add -- module.json
git commit -m '<message>'
git push
commitId="$(git rev-parse HEAD)"

使用返回的真实 commitId 在所属 Bundle 内创建新的不可变语义版本：

baijimu bundle resource module version create <bundle> --workspace-id <workspaceId> --project-id <projectId> \
  --resource-key <moduleId> \
  --version <semanticVersion> \
  --git-commit-id <commitId>

这一步只让 module-service 生成不可变快照和安装 Artifact，不产生模块市场条目，也不 触发审核或安装。模块没有独立发布入口。

纳入 Bundle

读取数据库当前定义及修订，将其 data.definition 保存为 definition.json，在根级 resources 中纳入 Owner 返回的模块身份和精确版本：

{"resourceType":"MODULE","resourceKey":"owner-returned-module-key","semanticVersion":"1.0.0"}

显示名和版本行 ID 不能代替 resourceKey。无需在 module.json 增加身份字段。 平台应用如需一同交付，也应在同一 resources 中选择 PLATFORM_APPLICATION 的精确版本。 创建资源版本不会自动修改 Bundle。编辑时保留其他资源、属性和配置，按统一定义流程提交完整内容：

baijimu bundle definition update <bundle> --workspace-id <workspace> \
  --expected-revision <readRevision> --definition @definition.json
baijimu bundle version create <bundle> --workspace-id <workspace> \
  --version <bundleVersion> --definition-revision <returnedRevision>

创建 Bundle 版本时校验所选 Module 身份、精确版本和归属，由 Owner 返回安装 Artifact。 资源实现的 Git 提交只用于模块版本；Bundle 本身按数据库修订发布。以上步骤不会自动升级已安装 Runtime。

验证

1. 模块定义归属预期 bundleId。
2. 模块版本的 gitCommitId 与项目提交一致。
3. 版本定义包含预期 module.json 和方法文件。
4. 作者清单选择的 moduleId + semanticVersion 与 Owner 返回的对象及版本相同，并在创建 Bundle 版本时通过服务端校验。
5. 市场审核和安装对象都是 Bundle，不存在独立模块市场记录。
6. Bundle 安装后 Runtime 服务版本和方法列表正确。
7. 同一模块在同一 Runtime 只能安装一次，安装重试不会生成重复记录。
8. Bundle 升级后属性、外部资源标识和用户配置没有被默认值覆盖。

需要由其他用户、工具或自动化接手修改、送审和发布时，使用 Bundle 修改与发布工作流，并由执行用户独立完成 认证和权限校验。项目文档不能转移发布权限，也不能让发布者绕过审核者边界。