zizi 824183864e docs(architecture): 重构为产品/技术/映射三文档 + MVP 迁移产品功能口径

- 去版本化：能力清单拆为三文档（产品需求清单/技术架构与模块/需求模块映射），
  文件名去 v2.1 版本号为唯一权威副本；删除混合视角旧档《业务能力全景与模块归属》，
  ~20 处交叉引用重定向（git 留史）
- 模块 12→13：新增 game-module-studio（创作编排域），aigc 收敛为无状态生成原子；
  锁风门 Gate(owner=compliance)、专区 Zone(owner=project) 两横切显式建模
- MVP 口径迁移：验收单位由"能力项(131)"改为 Doc A 的 55 项 P0 产品功能，
  工作量≈137 技术项；CLAUDE/AGENTS/mvp-scope/执行 spec §7/工作流 全链同步
- 三轮评审（人工 + 3 独立 Opus）findings 已修复：0 断链/0 孤儿/0 重复 ID，
  计数 155/204/137 实测自洽；glossary 补锁风门/专区/创作会话/资产图术语
- 新增 docs/memorys 任务记忆与 agent-specs 重划/prompt 治理评审依据

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-07 12:38:14 +00:00

4.3 KiB

Raw Blame History

2026-06-07 三文档体系重构 + MVP 产品功能口径迁移

任务记忆：供后续相似任务读取参考。结论先行。

一句话结论

架构能力清单从「混合视角单档」拆为产品/技术/映射三文档（唯一权威副本、无版本号文件名）；模块 12→13（新增 game-module-studio）；MVP 验收口径从「能力项(131)」迁移为 Doc A 的 55 项 P0 产品功能（工作量参照 ≈137 技术项）。

一、三文档体系（唯一权威，改任一侧只动映射）

文档	路径	单位	总量	纪律
Doc A 产品需求清单	`docs/architecture/2026-06-07-产品需求清单.md`	产品功能 `P-{域}-nn`	155	只写用户可感知，不得出现模块/技术术语
Doc B 技术架构与模块	`docs/architecture/2026-06-07-技术架构与模块.md`	技术功能 `T-{模块}-nn`	204	纯工程分解，不得出现产品功能
Doc C 需求↔模块映射	`docs/architecture/2026-06-07-需求模块映射.md`	RTM 行	155	唯一承载 M:N；列=产品功能·首要owner·★主T·辅

产品(WHAT) 与技术(HOW) 是两视角，关系多对多；映射是易变耦合点，单独隔离成文，A/B 保持解耦纯净。
文件名不带版本号（去掉了 v2.1-）；版本历史交给 git，文档内只记「最近修订 + 摘要」。
旧混合档《业务能力全景与模块归属》已删除（git 留史），其 8 章节内容已二分进三文档 + 存活概要设计档，~20 处「蒸馏来源」引用已重定向。

二、13 模块（前缀）

STU(studio·新增创作编排域) / AGC(aigc·收敛为无状态生成原子) / RT / PRJ(含专区Zone实体) / FED(含按Zone分区) / TEL / PAY / TRD / CMU / IP / CMP(含锁风门Gate) / BIZ / AD。两条横切关注点显式建模、单一 owner：锁风门 Gate(owner=compliance, T-CMP-12)、专区 Zone 双轨(owner=project, T-PRJ-07)。

三、MVP 口径（三个单位勿混用）

口径	单位	MVP 值	用途
验收（对用户）	Doc A 产品功能	55 项 P0	唯一验收线（55/55 走通）
工作量（排期/人天）	技术项/能力项	≈137	人天估算（150 人天，缓冲≈13）
实现范围	Doc B 技术功能	经 Doc C 反查	不单列，Doc C 即桥

历史换算：旧 105(保守口径,废弃) / 131(能力项) → 重划后 ≈137 → 验收改用 55 P0 产品功能。
55 P0 按首要 owner 分布：feed13 / studio7 / compliance6 / biz6 / project5 / community5 / aigc3 / runtime3 / trade3 / ad2 / pay1 / telemetry1 / ip0。
工位：WS1(project+compliance) / WS2(aigc+studio) / WS3(runtime+feed) / WS4(前端承载UI) / WS5(telemetry+ad+trade+pay+community+biz)。studio 归 WS2。
demo 缺口 G1–G7 闭环骨架已并入 MVP（双轨专区/锁风门/统一发布编排/渠道状态机/按Zone分区）；编辑器精修(骨骼/动画/对白)、素材双轨、TapTap 等保持 P1 → MVP 后增量。

四、关键文件影响（同步口径）

CLAUDE.md(头条指标 55/55) · AGENTS.md/README(指针) · .agents/knowledge/{mvp-scope-and-milestones,tech-decisions,product-and-architecture,glossary}.md · docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md(§1.2 验收 + §7 工位映射全表) · .agents/workflows/mvp-execution-orchestration.md。模块重划评审依据：docs/agent-specs/2026-06-07-模块重划分-review.md（方案 B）。

五、评审结论（3 独立 Opus 评审，已修复）

0 Critical。独立复核确认：三文档 0 断链/0 孤儿/0 重复ID/0 非法前缀；55 口径全仓一致、owner 分布合计 55；删档零内容丢失零悬挂引用。已修：spec §7 合计校正为 137（补 ip + community 缺项）、glossary 补 4 术语（锁风门/专区Zone/创作会话/资产图）、Doc C 个别 owner/★ 修正。

六、复用要点

写架构/能力文档先分层：需求清单(产品语言) / 模块文档(领域边界,无产品功能) / 映射(RTM) 三分离。
设计文档「一份即唯一事实」，不做多版本文件；版本走 git，文内记修订日期+摘要。
MVP 范围用产品功能作验收单位（用户可感知），技术工作量经 RTM 反查——别把两个单位相加。

4.3 KiB Raw Blame History Unescape Escape