d97e194383
- 注册表:docs/architecture/README.md §2,37 份 canonical(frontmatter topic+canonical:true)与表双向机器对账
- 门:.agents/tools/docs-gate.py 六检(品牌根/canonical唯一/死链/入口卫生/留痕隔离/设计档申报),挂 .githooks/pre-commit(本仓已激活)+ .gitea/workflows/docs-gate.yml(待runner)+ wave-close 第8步;旧 check-deadlinks.sh 退役并入 G3
- 清缩:删 54 项历史档(plans 16/agent-specs 设计与spike 20/brainstorms 5/memorys 3/goals+作战清单完成史归档/王蓝莓design/SAA现状html/add-game-template);channel-spike 564K 代码资产迁仓级 spikes/;六件删前蒸馏已迁(代码评审16条open项→进度总账§5、prefix-cache字段表→cheap-model skill、意图基线29条→需求清单附录、九门降级rationale→验收门、A11 TODO→tech-decisions、3layer边界→littlejs-game-dev 指针)
- 修口径约90处:六处SAA『现行主线』旧标、Nacos/RocketMQ『未部署』旧述(07-01反转)、gameDefinition残留、全部死链改 git show 定位;AGENTS.md 249→136行(决策史归tech-decisions);_index 改纯在飞板;对外演示版 md→html
- 依据:docs/agent-specs/2026-07-02-文档治理-{全量普查与裁决-report,SoT注册表与治理门-设计}.md(四路普查191份md+Codex/Opus双评审必修项已折入);恢复基线 8ea97234(单档 git checkout 8ea97234 -- <路径>)
11 KiB
MVP 范围与里程碑事实蒸馏
蒸馏来源：
docs/superpowers/specs/mvp-execution-spec-design.md（HJ-MVP-SPEC-001，执行权威）、docs/architecture/产品/需求清单.md（Doc A 产品功能）、docs/architecture/产品/需求模块映射.md（Doc C 需求↔模块 RTM）、docs/architecture/架构/README.md（§1.2 指标、§9 路线）。 目的：让后续 Agent 一篇掌握 MVP 端到端闭环、量化验收线、范围口径、5 工位分工、M0-M5 里程碑、契约先行要点。 相关：架构模块见product-and-architecture.md；选型与"范围张力"见tech-decisions.md。契约先行 playbook 见../skills/contract-first-development.md。
1. 端到端闭环链路（一句话）
创作者登录 → 资产管理 → Prompt 生成 / 资产组装 → 预览试玩 → 发布 → 审核 → 游戏流推荐 → 玩家试玩 → 互动 → 分享 → 广告展示 → 收益归集 → 创作者钱包可见 → 遥测采集 → 质量评分 → 推荐优化。
数据回路闭环：遥测事件 → quality_score → feed 推荐排序 → 更多曝光/试玩 → 更多事件（feed 与 telemetry 互为反哺）。
2. 量化验收标准
| 指标 | 标准 | 出处与备注 |
|---|---|---|
| P0 产品功能覆盖 | 55 / 55 项 Doc A 的 P0 产品功能全部可用且可验证 | Doc A 产品口径（详见 §3） |
| 端到端链路 | 创作→生成→预览→发布→审核→游戏流→试玩→互动→广告→收益 全走通 | 执行 spec |
| 生成成功率 | ≥ 80%（基于 3-5 个模板，MVP 验收线） / ≥ 85%（技术决策版蓝图远期目标） | 两个数字并存：执行 spec §1.2 与 AI 链路验收均为 80%；技术决策版 §1.2/§4.1 为 85%。MVP 验收按 80% 判定 |
| 游戏流首屏 | P75 < 3s（技术决策版另列 P95 < 6s） | 执行 spec + 技术决策版 §7.1 |
| 冒烟测试 | 核心 5 条链路自动化通过（deploy/smoke-test.sh） |
执行 spec |
| Bug 门槛 | P0 Bug = 0；P1 遗留 ≤ 10 个 | 执行 spec §1.2 |
3. MVP 范围口径（「产品功能」口径）
MVP 以 Doc A 产品功能作为验收单位（用户可感知）。三文档体系下三个独立计数互不混用：
| 文档 | 计数单位 | 总量 | 其中 MVP |
|---|---|---|---|
| Doc A 产品需求清单 | 产品功能 P-id |
155 | 55 项 P0（= MVP 验收线） |
| Doc B 技术架构与模块 | 技术功能 T-id |
204 | 由 Doc C 反查（= MVP 实现范围） |
| Doc C 需求↔模块映射 | RTM 行 | 155 | — |
MVP 验收 = Doc A 的 55 项 P0 产品功能全部走通；其技术实现范围 = 这 55 项经 Doc C 反查到的 T-id 集合（不在此重复罗列，Doc C 即唯一桥接，改任一侧只动 Doc C）。
55 项 P0 产品功能按首要 owner（Doc C）分布：
| owner 模块 | P0 数 | owner 模块 | P0 数 |
|---|---|---|---|
| feed | 13 | community | 5 |
| studio | 7 | aigc | 3 |
| compliance | 6 | runtime | 3 |
| biz | 6 | trade | 3 |
| project | 5 | ad | 2 |
| telemetry | 1 | pay | 1 |
| ip | 0 | 合计 | 55 |
demo 闭环骨架(G1–G7)纳入 MVP P0：双轨专区(P-PLZ-01·P-LIC-06)、锁风门二态(P-LIC-05·P-PUB-03)、统一发布编排+渠道状态机(P-PUB-01)、按 Zone 分区(P-PLZ-01) 均为 P0 产品功能；其后端
T-PRJ-07/08·T-CMP-12·T-RT-32·T-FED-15经 Doc C 纳入实现范围。编辑器精修(骨骼/动画/对白 P-CRT-06/07·P-LIC-04)、素材双轨(P-MAT-*)、TapTap 提审、智能体多轮会话(P-CRT-05) 为 P1 → MVP 后增量。 工作量参照：技术实现工作量 ≈ 137 技术项，仅用于 §4 人天估算；验收口径以 55 P0 产品功能为准。关键口径见tech-decisions.md§4。
4. 5 工位编制（WS1-WS5）与职责边界
10 人、3 周（15 工作日 = 150 人天）。验收按 55 P0 产品功能；人天按技术功能(T-id)工作量估算（≈137 技术项，留约 13 人天缓冲）。下表"P0 数"为各工位 owner 模块的 P0 产品功能数（合计 55）。
| 工位 | 代号 | 人数 | 角色 | 职责边界（owner 模块） | MVP P0 产品功能数 |
|---|---|---|---|---|---|
| 平台基座 | WS1 | 2 | 后端 Senior×2 | Huijing fork / Gateway / DB / CI-CD / project + compliance | 11（project 5 + compliance 6） |
| AI 生成 | WS2 | 2 | AI 工程师 + 后端 | 10（aigc 3 + studio 7） | |
| 运行时与分发 | WS3 | 2 | 后端 + 前端(SDK) | runtime + feed / SDK / 多渠道导出 / 互动 / 分享 | 16（runtime 3 + feed 13） |
| 产品前端 | WS4 | 2 | 前端×2 | game-studio 全页面 / game-admin 审核+模板+看板（承载 55 项 P0 的 UI） | 不单算 |
| 数据与变现 | WS5 | 2 | 后端 + 产品运营 | telemetry + ad + trade + pay + community + biz / seed / 验收 | 18（tel1+ad2+trade3+pay1+cmu5+biz6） |
注：WS1 11 + WS2 10 + WS3 16 + WS5 18 = 55；WS4 不重复计数（承载 UI）。studio 后端模块归 WS2（与 aigc 同工位、调用链最紧密）；其编辑器重交互在 game-studio 前端(WS4)，后端
game-module-studio只持久化会话/资产图/对白树/任务链状态并编排（UX≠后端模块）。人天按 T-id 工作量核算（产品功能数 ≠ 人天，一项功能常展开多个 T-id），3 周窗口可吸收。
4b. PRD 功能到三仓三端的覆盖（覆盖度版核对结论）
模块架构与 MVP 覆盖度文档逐条核对 MVP PRD，结论：三仓库 + 内部子模块拆分完整覆盖 PRD，无需第四个模块。 关键映射示例：
| PRD 需求块 | game-cloud 模块 | game-studio 页面 | game-admin 页面 |
|---|---|---|---|
| 自然语言/模板创作 | aigc(prompt/template/generation) | creator/CreateProject·GenerationStatus | game/template |
| 预览与轻量编辑 | runtime(compiler/package) | creator/DraftEditor·PreviewPlay | — |
| 发布/版本/状态 | project(publish+bpm·version) | creator/PublishFlow·profile/MyGames | game/review·version·project |
| 游戏流/即点即玩/互动 | feed(recommend/interaction/share)·runtime | feed/FeedPage·play/PlayPage | game/feed |
| 审核/内容安全/推荐管理 | project+bpm·compliance·feed | — | game/review·content-safety·feed |
| 账号/权限 | system(OAuth2/SMS/RBAC) | auth/ | system/（原生） |
六处"看似遗漏"实则已覆盖：匿名玩家（framework 扩展匿名 token）、内容安全（aigc 加 service/safety/）、游戏运行容器（studio components/game-runtime/ 纯前端）、CDN（deploy 配置）、数据导出（telemetry-admin 接口）、防沉迷（system 用户表加 birthDate 字段预留）——均无需新模块。
5. 里程碑表（M0-M5）
| 里程碑 | 日期 | 验证标准 | 验证人 |
|---|---|---|---|
| M0 契约锁定 | 6/9 上午 | contracts/ 目录 7 个契约文件提交 git |
全员签字 |
| M1 全栈可启动 | 6/11（Day 3） | docker compose up → 全服务绿灯 + Swagger 可调 project CRUD |
WS1 lead |
| M2 创作链路跑通 | 6/18（Day 8） | Prompt → AI 生成 → 预览试玩 端到端（真 LLM，非 mock） | WS2 lead |
| M3 分发链路跑通 | 6/20（Day 10） | 发布 → 审核 → 游戏流 → 试玩 → 互动 → 分享 | WS3 lead |
| M4 变现链路跑通 | 6/23（Day 11） | 广告展示 → 收益 → 钱包可见 | WS5 lead |
| M5 MVP 交付 | 6/27（Day 15） | 种子用户走通全链路 + 冒烟全绿 + P0 Bug = 0 | 产品负责人 |
三周节奏：Week 1（6/9-6/13） 基座 + 各工位基于契约 mock 独立开发；Week 2（6/16-6/20） 链路串通 + 功能完善（Day 10 全链路端到端走通，允许有 bug）；Week 3（6/23-6/27） Day 11-12 专职联调（不加新功能）→ Day 13 修 P0 Bug + 性能/安全加固 → Day 14 冒烟脚本 + demo 内容（≥10 款）→ Day 15 灰度 staging + 10 人种子内测 + 交付确认。
6. 契约先行（Day 0）与 Mock/并行解耦
Day 0（6/9 上午）全员半天锁定下列 7 个 Day-0 契约文件，写入 contracts/ 提交 git。锁定后各工位 mock 对方接口独立开发，联调统一在 Day 11 起。 加上 Prompt Registry（contracts/prompts/）共构成 8 类契约（Prompt 即第 8 类，见 ../skills/prompt-governance.md）。
| 契约文件 | 内容 | 负责人 |
|---|---|---|
api-schemas/*.yaml |
各模块 API 的 OpenAPI 3.0 定义（Request/Response） | WS1 lead 主笔，全员 review |
db-schemas/V1__*.sql |
核心表结构（Flyway 迁移脚本） | WS1 |
sdk-interface.d.ts |
WanxiangGameSDK 全部 public API 类型 + postMessage 协议 | WS3 SDK 负责人 |
game-package.schema.json |
GamePackage manifest 格式 + 目录结构 | WS3 + WS2 |
events.schema.json |
telemetry 事件名 + 字段（v1） | WS5 |
dify-workflow-io.json（降级远期未部署，见 contracts/DEPRECATED-dify-workflow-io.md） |
Dify workflow 输入/输出契约 | WS2 |
ad-slot.schema.json |
广告位配置格式 | WS5 |
Mock 与真实对接节奏（并行解耦核心）：
| 工位 | 依赖谁 | Mock 方式 | 真实对接 |
|---|---|---|---|
| WS4（前端） | WS1/2/3/5 的 API | vite-plugin-mock 基于契约 yaml 自动生成 |
Day 6 起逐步替换（改 .env 的 VITE_API_BASE_URL） |
| WS3（SDK） | WS4（宿主） | 独立测试页模拟 postMessage | Day 6 集成 |
| WS2（aigc） | WS1（project） | 内存态写入 + MQ mock | Day 5 真实对接 |
| WS5（telemetry） | WS3（SDK 上报） | curl 模拟 /events/batch |
Day 6 真实对接 |
解耦纪律：每日 10:00 站会（每人 2 分钟）；阻塞超 30 分钟立即升级；后端新增/变更 API 必须同步更新 contracts/api-schemas/ 并通知前端。详细 playbook 见 ../skills/contract-first-development.md。
7. MVP 交付物清单（执行 spec §10）
game-cloud/（后端全模块可编译运行）、game-admin/（可登录可操作）、game-studio/（全链路可用）、contracts/（API/DB/SDK/事件契约）、deploy/（docker-compose 全栈/中间件/AI + sql/seed-*.sql + smoke-test.sh）、docs/mvp/（本 spec + 每日进展 changelog）。
主要执行风险与应对（⚠️ 本段为原执行 spec 风险预案，其中「Dify/OpenGame 攻坚 / 切纯 Dify+模板填充」已随 C2/HJ-GEN-001 失效——现行生成主线=new-api 网关+agent 写码于插件库，Dify/OpenGame 从未部署）：Dify/OpenGame 集成超预期 → WS2 前 3 天攻坚，失败则 Day 3 切纯 Dify+模板填充；联调期 bug 过多 → Week 3 前 2 天只联调不加功能、P0 优先；广告联盟审核未过 → 先 mock 广告，真实对接可延到 MVP 后 1 周；某工位落后 → Day 5/Day 10 两次检查点，落后则他工位支援。