docs(design): 交互系统执行案与项目文档整理
- 新增交互系统执行案 (P-002a)，含层级状态模型、行为规则、边界情况 - 新增概念草案 concept.md、头脑风暴记录 - 新增 Agent 配置 (策划/PM/程序) 及角色记忆 - 新增 P-002 质量门审查报告、任务汇报、工作日志 - 更新路线图、current.md 等项目计划文档 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -1,5 +1,7 @@
|
||||
# PM Agent Memory Index
|
||||
|
||||
- [流水线阶段判断 2026-06-03](pipeline-status-20260603.md) — v0.1 处于阶段④执行案完善中，质量门未通过
|
||||
- [流水线阶段 2026-06-05 P002](pipeline-status-20260605-p002.md) — P-002 质量门不通过，三个系统均需修正执行案
|
||||
- [流水线阶段 2026-06-05](pipeline-status-20260605.md) — P-001 完成，v0.1 处于③执行案待确认（历史状态）
|
||||
- [流水线阶段判断 2026-06-03](pipeline-status-20260603.md) — v0.1 处于阶段④执行案完善中，质量门未通过（历史状态）
|
||||
- [Roadmap 对齐问题](roadmap-alignment.md) — roadmap.md 缺少 v0.5-v0.7，需与 game-vision.md 对齐
|
||||
- [设计文档质量审查](design-doc-review.md) — 交互系统技术越界、收集系统缺v0.1执行细节、边界情况不足
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: pipeline-status-20260605-p002
|
||||
description: P-002 执行案质量门审查结果 -- 整体不通过，三个系统均需修正
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
|
||||
P-002 执行案质量门审查于 2026-06-05 完成，整体判定不通过。
|
||||
|
||||
**审查结论**：
|
||||
- 交互系统：不通过（技术越界 + 边界情况缺失）
|
||||
- 收集系统：不通过（v0.1 执行内容匮乏 + 边界情况完全缺失）
|
||||
- 角色控制：有条件通过（需创建独立执行案 + 少量补充）
|
||||
|
||||
**核心阻塞项**：
|
||||
1. 三个系统均缺失独立执行案文件（应为 `<系统名>-execution.md`）
|
||||
2. 三个系统均缺失迭代记录表头
|
||||
3. 交互系统技术越界（JSON 数据结构、程序实现注释、白盒占位模型需求）
|
||||
4. 收集系统 v0.1 部分仅 4 行，不可直接实现
|
||||
5. 交互系统和收集系统的边界情况均严重不足
|
||||
|
||||
**审查记录**：`docs/plans/reviews/P-002-review.md`
|
||||
|
||||
**Why:** 执行案质量门是③到④的必要门槛，不通过则无法进入程序设计阶段。当前设计文档同时承担设计案和执行案双重角色，需拆分。
|
||||
|
||||
**How to apply:** 下次会话时，v0.1 的状态应为"③执行案修正中"。策划需按审查报告的修正方向产出独立执行案文件后，重新提交质量门审查。
|
||||
|
||||
**Related:** [[pipeline-status-20260605]] [[design-doc-review]]
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
name: pipeline-status-20260605
|
||||
description: P-001 原型阶段启动准备完成，当前处于流水线③执行案待确认状态
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
|
||||
## 当前状态（2026-06-05）
|
||||
|
||||
- 阶段：原型阶段
|
||||
- 当前版本：v0.1
|
||||
- 流水线位置：③执行案待确认/更新（P-002）
|
||||
- P-001 原型阶段启动准备已完成
|
||||
|
||||
## P-001 完成内容
|
||||
|
||||
1. prototype-roadmap.md 审查完成 -- v0.1 范围对齐，发现 v0.2/v0.3 有细节遗漏（建议更新但未修改）
|
||||
2. roadmap.md v0.3 已补全"零花钱经济"
|
||||
3. 角色汇报机制已建立（reports/ 下三个模板文件）
|
||||
4. 草案归档已补充 D-001 和 D-002 记录
|
||||
|
||||
## 待决策事项
|
||||
|
||||
- prototype-roadmap.md 的 4 项建议更新需用户确认
|
||||
- v0.2/v0.3 验收标准待 v0.1 完成后详细定义（合理，不阻塞）
|
||||
|
||||
## 下一步
|
||||
|
||||
P-002：v0.1 执行案确认与更新，提交执行案质量门审查
|
||||
|
||||
## 相关记忆
|
||||
|
||||
- [[pipeline-status-20260603]]：上一轮流水线状态
|
||||
- [[design-doc-review]]：交互系统技术越界、收集系统缺边界情况
|
||||
- [[roadmap-alignment]]：roadmap 对齐问题
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
name: roadmap-alignment
|
||||
description: roadmap.md 与 game-vision.md 的版本规划不一致，缺少 v0.5-v0.7
|
||||
description: 路线图已于 2026-06-05 全面重新评估，3 版本扩展为 4 版本，与可行性评估对齐
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
|
||||
# Roadmap 对齐问题
|
||||
# 路线图重新评估完成（2026-06-05）
|
||||
|
||||
game-vision.md 中定义了 8 个版本（v0.1-v0.7 + v1.0），但 roadmap.md 仅覆盖 v0.1-v0.4 + v1.0，缺少：
|
||||
原 3 版本规划（v0.1-v0.3）已扩展为 4 版本（v0.1-v0.4），关键变化：
|
||||
- 原 v0.2（弹珠+NPC+室内+音效）拆分：弹珠独立为 v0.2，NPC/时间系统为 v0.3
|
||||
- 原 v0.3（时间+经济+NPC联动）拆分：时间+NPC 为 v0.3，经济+叙事为 v0.4
|
||||
- 经济系统从 v0.3 后移到 v0.4，降低单版本工作量
|
||||
- roadmap.md 已补全批量生产阶段 v0.5-v0.7
|
||||
|
||||
- v0.5 — 四驱车 + FC/街机 + 收集扩展
|
||||
- v0.6 — 乡下章节
|
||||
- v0.7 — 整合 + 多支线 + 结局系统
|
||||
**Why:** 原 v0.2/v0.3 范围过大（各 20-32 天），单人开发风险高。拆分后每版本聚焦一个核心假设
|
||||
**How to apply:** 后续版本开发时，每版本聚焦一个假设，范围不再膨胀。如果发现范围偏大应及时拆分而非堆叠
|
||||
|
||||
此外，v0.3 roadmap 中未提及 game-vision 中包含的零花钱经济系统。
|
||||
|
||||
**Why:** 版本规划不完整会影响长期任务拆解和里程碑追踪
|
||||
**How to apply:** 当 v0.1 接近完成或开发者要求更新 roadmap 时，提醒补全这些版本。不阻塞 v0.1 当前工作。
|
||||
关联记忆：[[pipeline-status-20260605]]
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
- [Project Tech Stack](project-tech-stack.md) — D-002 确定的技术架构、模块选择、风险和工期预估
|
||||
- [Codebase Cleanup Needed](feedback-codebase-cleanup.md) — Variant_* 遗留代码需在 v0.1 前清理
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: feedback-codebase-cleanup
|
||||
description: 评估发现遗留代码需要清理，避免后续开发混乱
|
||||
metadata:
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# 遗留代码清理
|
||||
|
||||
**Rule:** v0.1 开始前需要清理 Source/ChildHood/ 中的 Variant_Combat、Variant_Platforming、Variant_SideScrolling 三个遗留游戏模式代码。
|
||||
|
||||
**Why:** 技术可行性评估时发现这些代码与 ChildHood 核心玩法无关，是之前原型实验的遗留。保留会污染代码库、增加编译时间、干扰新开发者理解项目结构。
|
||||
|
||||
**How to apply:** 在 v0.1 实施阶段的第一步，将这些目录归档或删除。清理后 ChildHoodCharacter、ChildHoodPlayerController、ChildHoodGameMode 作为项目基类保留。
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: project-tech-stack
|
||||
description: ChildHood 项目的技术栈选择和架构决策记录
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
|
||||
# ChildHood 技术栈与架构决策
|
||||
|
||||
**Why:** 技术可行性评估（D-002）确定的架构方向，后续所有技术设计需以此为基准。
|
||||
|
||||
**How to apply:** 新系统设计时参照此文档选择模块和方案；如有偏差需记录原因。
|
||||
|
||||
## 引擎与插件
|
||||
- UE 5.7.4，已启用 StateTree + GameplayStateTree + ModelingToolsEditorMode
|
||||
- 不使用 GAS、Nanite、Lumen、MassEntity
|
||||
- 已有模块依赖：Engine、AIModule、UMG
|
||||
|
||||
## 核心架构方案
|
||||
- 角色控制：ACharacter + Enhanced Input + SpringArm（已有基类 ChildHoodCharacter）
|
||||
- 交互系统：C++ Interface + SphereOverlap + UMG Widget
|
||||
- NPC：StateTree（已启用插件）+ 自定义对话 JSON 解析
|
||||
- 数据驱动：DataAsset + DataTable（对应 GameConfig/ CSV/JSON）
|
||||
- 小游戏：独立 GameMode + PlayerController，进入时切换
|
||||
- 时间系统：GameState 中的 TimeManager Subsystem
|
||||
- 存档：USaveGame + SaveGameToSlot
|
||||
|
||||
## 关键风险记忆
|
||||
- 小游戏（弹珠/四驱车/FC/街机）是最大风险，内容量决定工期
|
||||
- 弹珠操作手感必须在 v0.2 做 Throwaway 原型验证
|
||||
- Source/ 中的 Variant_* 遗留代码需清理
|
||||
- 叙事文本和美术资产是隐性工作量最大的非代码任务
|
||||
|
||||
## 工期预估参考
|
||||
- v0.1: 10-18 天，v0.2: 20-32 天，v0.3: 18-29 天
|
||||
- 全项目：158-249 天（约 5-8 个月全职）
|
||||
Reference in New Issue
Block a user