游戏模板接入与自主交付实施方案
- Asset
- ADP-DEV-FEAT-DOC-0100
- Feature
- game-template-adoption
- 领域
- developer-tooling
- 作用域
- cross-cutting
- 文档状态
- draft
- 产品生命周期
- planned
- 文档 Owner
- DOC
- 事实源
- canonical-docs
- 更新
- 2026/10/14
本页为尚未落地的历史采用计划。旧 Worker Profile、规划 Action 和 Plane Run 依赖已停用，相关工作包必须重新按 全部 Issue 类型的 Symphony 方案规划后才能执行；它们不是当前部署或接入步骤。人工规划与历史证据保留。
目标与执行边界
目标版本为 V1 有限范围试点：把在研的 Unity 模板作为可选择、可追溯的项目起步资产，完成 “游戏想法 → 首版方案 → 采用合适的模板内容 → Agent 实现 → 外部 CI 出包 → 制作人试玩 → 下一版”。 成功标准是交付一个独立新游戏和一次真实反馈驱动的迭代，不是复制仓库或增加 Action 数量。
本文是实施方案，不代表功能已经实现、模板已经成熟、试点已经立项或任何 Run 正在执行。 本方案作为独立交付项目 GAP / 游戏自动化交付试点的唯一合同。Plane 物化按固定来源推进， 规划对象创建与实际工程执行分别记录；不得由任务已创建推断 Agent 已启动。 工程 readiness 只由资产目录派生，缺失证据保持缺失，不以本方案的完整度代替。
首批建议技术范围为 Unity 单机短局游戏、一个完整核心循环、一个首发目标平台；当前 Android 已有模板构建证据，可作为候选。具体玩法、目标用户、风格、设备和平台尚未决定，由试点首版方案确定。 这项未知只阻塞试点专属实施，不阻塞模板盘点、生成入口和平台接入准备。
V1 不要求补完模板全部业务系统，不建设通用游戏引擎，不承诺一套模板覆盖所有类型；不默认加入 联网、账号、商业化、排行榜、运营后台或五个岗位仓库。后端和配套仓库按实际交付需要选择。
制作人与 Agent 的职责
用户已接受“Agent 自主推进工程，制作人决定产品方向与体验”的分工。 工程授权沿用当前 Project Workspace 政策，不增加逐任务、代码、合并、部署或凭据操作的人工批准门。 产品评审用于表达产品决定，不用于重复授予工程权限；工具实际权限和证据要求仍然生效。
| 决定 | 负责方 | 记录与继续条件 |
|---|---|---|
| 目标玩家、核心玩法、体验假设、首版范围与风格 | 制作人；Agent 起草备选与取舍 | 首版产品方案；已有明确决定直接引用，避免重复确认 |
| 模板适用性、模块选择、技术架构、任务拆分 | Agent | 采用说明与技术方案；改变产品规则或范围时升级为产品决定 |
| 编码、独立代码审查、外部 CI、返工、合并和获授权部署 | Agent | 精确源码、MR、CI、产物和部署事实；作者不能用自述代替独立审查 |
| 首个可玩版本是否体现想法、是否值得继续 | 制作人试玩；Agent 整理反馈 | 绑定具体版本的体验结论与下一轮范围 |
| 已定范围内的细节修复与改进 | Agent | 执行有界迭代，不逐项请求批准 |
| 改核心玩法、扩范围、接受明显体验妥协 | 制作人 | 更新产品基线再继续受影响工作；独立工程工作可继续 |
正常路径只有两个主要产品评审点：开工前首版方案，以及第一个可玩版本后的体验评审。 反馈迭代结束仍需呈现结果；只有未决产品取舍才再次要求决定，不把每个提交变成人工审批。 没有试玩反馈时可继续独立修复工程问题，但不得编造体验通过或无限自行调优。
已知基线与证据限制
下列 commit 是此次评估的来源，不是未来实施分支的永久基线。每个 WP 开工时由所属 registry 重新解析 owner、仓库和 base 分支，从最新目标分支建立隔离工作区，并在 MR 记录完整 base/head SHA。
| 来源 | 固定 revision 与定位 | 对实施的影响 |
|---|---|---|
| 游戏模板 | wjunityman/wj-unity-game-template，b09cd8139bfe819d1df81df50e34a1877f1b3eb2；TemplateProfiles/、scripts/init-project.sh、GameMain/Procedure/ | 模板混合核心、业务和示例；Profile 为 catalog-only |
| 平台引导与 Worker | autoai/dsp-plugins，ed1a61bacd45b694a594a3454d1131d78092e629；bundles/web/dsh-project-bootstrap/src/project.ts、profiles/ | 引导已有模板映射，但默认复制可变分支、失败退回空骨架，且不提交模板源码到新远端 |
| 文档与现有业务合同 | 本方案起始 docs revision da85c0f83075c72deaf33f662f4901aa012f13e1 | 规划改由指定仓库的 BMGD/OpenSpec 产物持有，复用原生 Issue、资源采用与执行边界，详细能力以各 canonical Feature 为准 |
模板成熟度清单自报 13 项 closed、6 项 partial、5 项 external-required、6 项 supporting； 这些状态不代表对任意游戏均已验收。玩法工厂仍显式创建 Starter、Pinball、Match3， 模块工厂也不消费 Profile 来生成精简内容。文档部分路径仍指向旧的 GameProcedure 目录。
模板流水线 174535
证明上述模板提交曾通过模板契约、前端新项目演练和 Android APK 构建。新项目演练使用
--roles none，不证明五仓整体联动；产品回归和真机 PoC 当时仍为未执行的手动作业。
后续失败作业 446381
在规范快照与规范库状态不一致处停止，不能用它推断 Unity 代码损坏，也不能用历史绿灯
宣布当前交付已就绪。实时状态继续读取原系统，不在本文维护进度表。
需求与完成条件
以下 REQ/AC 是本方案的交付合同，不是新增测试授权。尚无覆盖本次完整采用流程的正式验证资产， 不伪造 verified_by 或把模板历史 CI 绑定成新功能已通过的证据。
R1：需求决定采用范围
ADP-DEV-REQ-DOC-0101：Agent 根据目标玩法、平台、离线/联网要求及资源需求，给出采用、部分采用
或不采用的结论；指出复用项、改造项、未完成项、外部依赖和成本来源。选择不得改变已定产品目标。
AC ADP-DEV-AC-DOC-0101：首版方案包含完整核心循环、范围与非目标、可观察的体验假设；
采用说明逐项对应需求与固定来源。制作人决定有记录，不因模板自带系统增加游戏功能。
R2：最小模板真正可生成
ADP-DEV-REQ-DOC-0102：先交付一种明确的最小组合；生成结果中的代码、场景、Prefab、程序集、
配表、包依赖、启动与玩法注册保持一致。移除未选择示例及其失效入口，不只隐藏按钮。
文件可安全移除前先完成引用解耦；单纯停用但仍携带全部工程不算精简交付完成。
AC ADP-DEV-AC-DOC-0102：生成内容清单与实际工程一致；外部 CI 对精确派生提交完成适用的
依赖解析、启动及出包检查，未选系统不会成为启动或构建的隐含必需项。所需检查没有现成入口时
记录“无法验证”，不能新增测试或假装通过。
R3：初始化形成可继续开发的远端工程
ADP-DEV-REQ-DOC-0103：一次采用绑定各模板仓完整提交、引擎/包依赖及参数；统一处理项目名、
应用标识、配置仓路径、目标平台、必要场景与生成内容。平台调用模板拥有的正式生成能力，
删除现有 bootstrap 中重复复制/改名算法与空骨架成功回退，不长期保留双入口行为。
AC ADP-DEV-AC-DOC-0103：目标 registry、远端源文件、实际默认分支和交付提交可相互定位；
Worker 从远端独立获取到完整工程。返回“成功”必须晚于精确源码交付和状态读回；失败保留可恢复
记录，不覆盖已有项目，不把 README 仓库或本地副本当成可开工结果。
R4：平台基于已采用版本执行
ADP-DEV-REQ-DOC-0104：资源采用、仓库规划产物、原生 Issue 和执行使用相同采用身份与版本来源。
复用已有 Plane 业务对象和源文件引用；仅在真实缺口存在时扩展业务 API/UI，不建立另一套项目状态机。
模板目录文件仅表达生成输入/来源，不存储 Run 状态或第二份任务规划。
AC ADP-DEV-AC-DOC-0104：规划明确区分复用、适配、新建及缺失输入；每个任务绑定一个注册
仓库和可用 Action。Worker 实际部署与项目登记有 owning evidence；包发布、Action 名称存在或
资源卡片可见不能代替就绪。执行状态从 Symphony owning 服务读取；历史 Run 不再产生新执行。
R5：独立产品交付与体验迭代
ADP-DEV-REQ-DOC-0105：新游戏通过自己的外部 CI 产生带版本、提交、平台和摘要的实际产物，
提供试玩入口；首次试玩反馈驱动一次有界迭代，预测效果与实际观察分开记录。
AC ADP-DEV-AC-DOC-0105：交付从进入、操作、反馈到胜负/结束和重开的完整游戏循环；
制作人可以取得并试玩确切版本，反馈关联该版本，第二版列明改变与遗留。构建成功、规则正确与
体验认可分别记录；不能从某项成功推导其余成功。
R6：责任与生命周期可持续
ADP-DEV-REQ-DOC-0106：模板维护、平台编排、构建接入和产品代码各有 owner。生成后产品代码由
产品仓维护；真正共享的包按固定版本消费。后续升级使用显式迁移任务，不自动覆盖产品改动。
AC ADP-DEV-AC-DOC-0106：每项失败与后续改动可路由到 owner；停用有问题的采用版本不会
删除在研模板或已建产品。范围内替换遵循 clean break，旧实现、入口和失效文档同步移除。
不借本任务删除范围外半产品，也不为未指定消费者增加兼容层。
目标流程与关键实现约束
流程为：产品方案与采用评估 → 产品方向确定 → 固定采用来源 → 生成独立源码并交付远端 → 项目与 Worker 就绪 → 规划/实现/独立审查 → 外部 CI 与试玩交付 → 制作人反馈 → 下一版。
生成输入至少包括项目稳定 identity、目标仓库、各模板 revision、内容选择、引擎与依赖版本、 产品/应用标识和目标平台。实际字段和格式由模板 owner 在 WP-0101 固定；源声明只存一份， 产品仓保存本次采用的不可变来源记录，Plane 引用该记录，不复制一套可编辑模板配置。 第三方资源及插件的使用范围、来源和授权随实际选择核对；不能把模板能访问资源等同于新产品可分发。
初始化由代码确定性编排：读取并冻结输入 → 独立 staging 生成 → 建仓/登记 → 分支、提交、MR 与精确头交付 → 读回远端和 registry → 记录来源与交付结果。未通过阶段不能继续报告整体成功。 新仓初始 README 与模板提交之间的过渡不算可用产品；远端变更仍走所属 repo 的审阅流程。
稳定初始化身份由目标 Project、目标仓集合与采用输入版本确定。重复调用复用已完成步骤；相同身份 但输入不同、目标路径非空且归属不符、同一目标已有进行中的初始化时停止冲突，不覆盖或另建重复项目。 超时先读回 Git/Plane 实际结果再决定重试，不盲重放写操作。多仓不承诺原子事务，逐仓记录部分结果， 下一次仅继续未完成步骤；取消后停止新副作用，已经提交的数据保留并明确呈现。
模板生成不启动 Unity 验证；验证只由外部 CI Runner 执行。Agent 创建的审阅会话独立于实现会话， MR/CI 必须绑定精确 head。Symphony 业务凭据按项目限定， 不增加 lease、heartbeat、旁路调度或 Runtime 业务快照。
里程碑
| ID | 结果 | 退出条件 | 依赖 |
|---|---|---|---|
ADP-DEV-M-DOC-0101 | M1 最小采用合同 | 确定支持范围、最小内容、来源与生成合同；范围外内容清楚 | 无 |
ADP-DEV-M-DOC-0102 | M2 可重复生成与平台接入 | 目标源码已入库，失败不假成功，采用身份与 Worker 交接一致 | M1 |
ADP-DEV-M-DOC-0103 | M3 首个可玩产品 | 独立游戏仓外部 CI 产物可取得，完整核心循环可试玩 | M2、首版产品方向 |
ADP-DEV-M-DOC-0104 | M4 反馈驱动第二版 | 反馈绑定版本、改进有范围、第二版交付且限制诚实记录 | M3、真实试玩反馈 |
工作包与依赖
以下 WP 的 owner 是实施责任；资产 owner DOC 只表示本文持有计划。执行路由从各 Project Workspace registry 重读，不依赖历史路径。每项实施任务只修改一个 owning repo；表中包含多个 owner 的 WP 必须在开工前按 repo 拆成关联执行任务，不由一个 Task 隐式跨仓修改。
| WP ID / 名称 | Owner / 仓库与范围 | implements | depends_on | 交付、验收与证据 |
|---|---|---|---|---|
ADP-DEV-WP-DOC-0101 采用合同与模板边界 | Unity中台库 unity-project-template-codex / unity-game-template-codex 先核对 registry，主载体 wj-unity-game-template；模板文档、Profile、依赖与引用盘点 | R1、R2、R6 | 无 | 选择游戏模板/基础模板的技术依据；最小组合与删除清单；固定来源；同步真实代码定位。源码审阅与 MR，不宣称运行通过 |
ADP-DEV-WP-DOC-0102 最小生成实现 | Unity中台库模板 owner；TemplateProfiles/、生成入口、相关场景/程序集/注册/依赖 | R2、R3 | WP-0101 | 一条正式生成路径，完整产品身份替换，清理选定范围内旧路径；外部 CI 的精确模板与派生提交证据。配套仓需改动则分别交付 |
ADP-DEV-WP-DOC-0103 可靠项目实体化 | AutoDevSystem DSP owner / dsp-plugins；dsh-project-bootstrap 与必要业务交付工具 | R3、R6 | WP-0101、WP-0102 | 固定版本调用生成入口、远端源码/MR 交付、幂等恢复和部分失败记录；删除空骨架成功回退及重复改名实现 |
ADP-DEV-WP-DOC-0104 采用与规划接线 | AutoDevSystem Plane、DSP、docs owners；先审阅现有资源采用/规划业务 API，再按 repo 拆任务 | R1、R4、R6 | WP-0101；最终联调依赖 WP-0103 | 接通已有对象与版本来源；Agent 读取采用内容和缺口；产品评审与工程审批分离。仅真实 API/UI 缺口才修改 Plane，不增加 Runtime 协议 |
ADP-DEV-WP-DOC-0105 产品 CI 与产物交付 | GameBuild unity-autobuild-pipeline-codex；wj-unity-autobuild-pipeline 与试点产品 CI 分别交付 | R2、R5 | WP-0101；产品接入依赖 WP-0103 | 恢复适用模板基线、固定实际工具链/Runner/依赖源；产品独立出包和产物链接。现有 job 适用性与未覆盖范围明确 |
ADP-DEV-WP-DOC-0106 项目 Worker 就绪 | AutoDevSystem DSP owner / dsp-plugins；既有 Profile、实例与 DSH 项目配置 | R4 | WP-0103、WP-0104 | owning CI 发布/部署证据与 DSH 项目配置一致；只装配当前目标需要的 Action；不以名称注册推断可执行 |
ADP-DEV-WP-DOC-0107 试点首版 | 新游戏 Project Workspace；仓库 identity 待产品方案确定，当前不得物化成可执行任务 | R1、R5 | WP-0102～WP-0106、首版产品方向 | 单仓 Task 拆分与依赖、真实代码/资源、独立审阅、外部 CI、试玩包、未达目标说明；制作人体验结论 |
ADP-DEV-WP-DOC-0108 第二版与推广评估 | 试点 owner；缺陷属于模板/平台时回到对应 owner 的独立任务 | R5、R6 | WP-0107、真实试玩反馈 | 有界反馈清单与第二版；记录模板修改量、人工介入原因、失败点及复用收益；据证据决定是否扩大支持范围 |
WP-0101 的模板/DSP 评估 revision 见基线表；WP-0104 的 Plane、WP-0105 的构建仓与配套仓精确 revision 必须在源调查后补入执行任务。缺少 repo/base_revision 的任务保持未准入，不猜值。 WP-0104 的现状调查和 WP-0105 的构建准备可在 M1 后独立进行；WP-0107 不能越过生成、交付和接入依赖。 不在首轮给出缺乏依据的工期；完成 WP-0101 后按引用解耦、配套仓改动和 CI 实况更新估算。
各 WP 共用的 forbidden_scope：范围外游戏逻辑与数据、未选商业化/联网能力、旁路 Runtime、 未授权测试新增/扩写，以及将模板未完成功能批量补完。技术实现不得自行改变产品评审基线。
验证、停止与回退
本地验证：根据项目策略禁止执行。只能检查源码/diff、编辑、提交及读取外部 CI 结果。 本方案不授权新增或扩写测试、断言、fixture、mock、快照或测试辅助代码；不得以验收标准解释为写测试授权。 外部 CI 可运行适用的现有检查。需要新的自动化验证时，先明确缺失证据，只有用户明确要求编写并提供 具体用例/输入与预期后才实现指定范围。没有适用 CI 或证据时记录“无法验证”，不以本地执行补偿。
| 证据层 | 读取什么 | 不能据此声称什么 |
|---|---|---|
| 源码与采用 | 固定 Git blobs、生成输入/内容、MR 精确 head、registry | 不证明运行或体验通过 |
| 模板外部 CI | 适用现有模板契约、新项目演练及构建 job | 前端演练不证明配套仓全部联通 |
| 产品外部 CI | 目标游戏精确提交、平台、工具链、产物摘要及可取地址 | 模板 APK 不替代产品 APK；包生成不等于发布或真机通过 |
| 产品体验 | 制作人对具体版本的试玩记录、观察与取舍 | Agent 预计效果不等于用户认可 |
| Automation | Symphony 官方执行状态 | Git/目录/评论/业务状态不能代替执行状态 |
WP-0101～0106 遇到版本不可取得、来源/授权不明、引用无法解耦、CI 不可用、输入冲突或平台能力 缺口时停止受影响步骤，保留具体证据并由 owner 修复；不创造新的人工工程批准门。 WP-0107～0108 缺产品方向或真实反馈时停止相应产品决定，独立工程工作继续；不把沉默当作认可。
代码回退通过 owning repo 的审阅 revert MR 和外部 CI；生成失败只清理本次明确拥有、未交付的 临时目录，保留已有仓库、远端提交、用户数据与部分完成记录。已经交付的产品停止自动推进后 由单独修复任务恢复，不删除项目。若采用版本有缺陷，停止新增采用，已有产品固定版本并显式迁移； 不添加旧参数映射、旧运行读写或双模式来隐瞒问题。产品体验未达标回到有界修订，不以回滚模板掩盖。
最终交付与剩余输入
最终应交付：受管的最小模板版本、可靠的初始化入口、项目采用与来源记录、远端产品源码、 Worker 与 CI 接入证据、首个试玩版本、真实反馈和第二版；每项都能路由到 owner。 模板内容与实现细节留在模板仓，平台只保存接入合同；游戏策划留在对应游戏的 canonical 内容源。
尚需在相应阶段确定的事实是：试点玩法与用户/风格/首发平台、支持的最小内容、配套仓实际必要性、 准确来源组合、现有 CI 覆盖与资源分发授权。它们分别由产品方案或技术盘点收敛，不阻止本方案交付， 也不构成让全部工作等待用户的新授权门。
GAP 历史物化候选
游戏自动化交付试点项目身份与 owning Workspace 不迁移。原 gap-v1 revision 2 是 Epic/Run 模型专用候选，不是当前 v3 普通 Issue 候选，已从活动下载入口移至仓库 catalog/archives/materializations/game-template-adoption/gap-v1.json 只读归档。
原 8 个 Epic、4 个版本、4 个里程碑、需求输入、来源 revision 和关系全部保留，字节摘要与原路径记在同目录 README。它不再允许物化或请求旧 Run；本归档不代表远端对象已迁移。GAP 控制仓负责停止旧消费者并保全既有对象。
后续采用先将需求方案转为 OpenSpec，工作以普通 Issue 及关系组织，重新形成精确候选和摘要。不得把原 Epic 审批自动当作新候选授权，不预设或伪造已完成的产品试玩、部署与验收。