开发、发布与升级交付
适用模板基线 be4326b5b47794328accc120b6e250497af37191，模块与框架版本见版本基线。本文说明开发、发布、升级与接收的证据边界，不提供任何新包、消费者或网站已交付的结论。
一次交付分成四种结果
| 结果 | 至少记录什么 | 不能据此宣称什么 |
|---|---|---|
| 源码合并 | owning repo、base/head、完整 diff 审阅、该精确 head 按仓库政策要求的构建/验证证据、合并提交 | 包已进入 registry、消费者已升级 |
| 包发布 | 包名/版本、实际 source-to-dist 映射、不可变产物摘要、发布 job | 仅凭 package.json 的版本声明不能证明产物内容 |
| 消费者采用 | 消费者提交、manifest/lock、实际包来源、目标 Unity/平台、精确 head 外部运行证据 | 历史其他项目或其他 head 的通过不属于本项目 |
| 网站交付 | 文档 source SHA、精确 head 云构建、部署回执、固定部署 URL、实际页面内容 | 网站通过不能代替 Unity、包或业务验收 |
固定模板生成契约及 CI 范围明确了生成物和运行证据的区别；内容与业务验收应另行记录。T1 T2
开发与源码合入
- 确认对应框架、玩法包、模板或文档仓库的维护者及规则。新项目以本文固定的现行模板为基线，不凭可读性将已冻结旧模板当作当前维护目标。T2
- 保留消费者和上游已有改动，从当前目标版本建立隔离分支，记录仓库、target、base/head 和变更范围。
- 审阅完整差异，并更新受影响调用方。接口替换与迁移切换到新入口，删除失效配置和文档；资产变更另查 GUID、场景和预制体引用。
- 按 owning repo 的政策取得精确 reviewed head 的必需构建/验证结果。缺失、失败、跳过或其他 SHA 的结果不能填成通过；没有相应证据时明确保持“未确认”。这不替所有消费者规定统一测试环境或增加新的测试范围。
- 合并前重新读取 MR identity、target、head、冲突和可合并状态，以 SHA guard 合并同一 head。head 改变后重新审阅并取相应 CI。
- 按已审阅的发布流程交付，并将 source、package、consumer、website 的结果分别写入回执。实际仓库/包访问、维护归属、资源权限和发布证据均应明确，不能由源码可读或文档存在推定。
包发布的来源链
以每个包为单位记录包源路径、源码完整 SHA、manifest 版本、模块打包工具版本/提交、产物文件摘要、registry 发布回执，以及消费者下载到的包内来源记录。Feature 模块版本、gameplay 主包版本和工具版本不能相互代替。
现有本地材料包含 FeatureEnergy、FeatureSpellIndicator 的 package.json、README、CHANGELOG 和运行时源码，足以说明接口；不包含模块 source-to-dist 的实现、当前打包配置、tarball、包内来源回执或消费者实际安装证据。不能据 Feature 1.0.0 声明就把 registry 包与所读源码画等号。需要 gameplay owner 提供同 SHA 的模块打包配置、module-dashboard 的发布实现/回执、module-manager 的导入边界和真实消费者 PackageCache 来源证据。
模板生成契约明确保留 com.wenjing.libgameplay@1.1.0，且该旧主包缺少可核对 Git 来源回执；本稿不把它升级为源码声明的 1.1.1，也不把独立 Feature 包当成已安装主包。T1
升级采用步骤
- 保存消费者现有 source SHA、Unity 版本、manifest、lock、注册表访问方式和运行证据。先确定要升级公共框架、主包、独立 Feature 还是模板复制内容。
- 由上游提供所选版本的 changelog、API diff、依赖变化及 source-to-dist 证据。模板固定依赖 framework 2.8.38，所读框架源码声明 2.8.45；现有材料没有这段版本区间的完整 diff 和发布记录，不能声明直接兼容升级。
- 在消费者隔离分支更新精确依赖及相应调用方。复制的产品定制由接收者维护；库由上游包维护，不能通过覆盖整个模板目录来升级消费者改动。T1
- 要宣称实际采用通过，应记录对应项目/平台的包解析、冷导入、程序集/资源装配和实际使用路径证据，执行环境按消费者规则确定。失败时保留阶段、实际文件及 source/head；不要拿旧项目或旧 head 的结果替代。此项是成功声明所需的证据，不要求为了审阅本文另建消费者测试任务。
- 验收后发布消费者版本，并记录回退所需的旧提交、包来源和资源/配置组合。回退具体机制必须来自该产品发布流程，本稿不虚构自动回滚能力。
模板生成与接收
正式入口 scripts/generate-project.py REQUEST.json 只交付固定 client/config 组合，支持 Python 3.9+、Git 和具排他重命名能力的 macOS/Linux 本地文件系统。请求必须包含两仓完整 SHA、同 client SHA 的 generator_commit、产品/演练身份、接收者、资源限制及尚不存在的绝对输出目录。T1 T3
输出是 generated-review-artifact，含客户端、config、HANDOFF 和 delivery-receipt。生成器不创建仓库、不裁剪 Profile、不发布包、不证明依赖可取或 Unity 已运行。若 publish 阶段返回结果未知，先核对目标目录及回执；不能把超时当作未生成并覆盖重跑。使用新目标的修订请求应关联原请求并保留残留。T1 T3
现有 config 基线 7d3c0868a6b3977d73bb5ab154262f8e8eebdc59 的导出缺口来自模板指南的调查记录：luban.conf 为说明内容，导出脚本及部分语言输出不足。此次未取得 config 源码，不把该记录当作重新检查结论；补齐需该 SHA 的实际 config 文件、Luban 版本、源表、导出命令/回执、输出摘要和客户端引用关系。T1
模板 CI 与网站交付
模板固定 README 明确普通 CI 只运行 Static。分支为 static-repository；合入 master 的 push 不创建 job；master 定时或主动请求为 static-master-requested。Unity、新项目生成、APK、产品回归和 Airtest 保留为独立外部工作流工具，Static 成功不证明这些步骤通过。T2
网站交付应记录文档 source/head、依赖锁摘要、实际生成的搜索索引与来源元数据、对应构建/发布回执及固定部署 URL。确认目标页面内容和版本后，再记录内容验收；同一版本 URL 不应随后续主干改变。网站构建或发布成功不能替代包、Unity 或业务通过。发布结果未知时，先核对现有部署与回执，再决定重试。
要提升为相应交付成功声明所需的材料
- framework 2.8.38 → 2.8.45 的完整源码 diff、CHANGELOG 和实际发布映射。
- gameplay 模块打包/导入脚本及版本，source-to-dist 清单、tarball 摘要和消费者包内来源证据。
- 固定 config 的导出链与授权资源的 source/export/reference 对照。
- 同次请求的生成回执、包解析/Unity 外部 job、消费者项目及平台结果。
- 网站 reviewed head 的 provider 构建/部署回执、固定 URL 与内容证据。
固定来源
以下是内部固定来源，需要原仓内网和账号权限，公网读者不能保证可访问。链接保留仓库身份、完整 SHA 和相对路径供定位，不授予访问或资源转用权限；正文已独立说明所需字段与使用边界。