chore(agents): 移除agent记忆系统，决策记录已在docs中维护

2026-06-12 18:04:52 +08:00
parent 0c57d69ff7
commit 906e2aa7a2
29 changed files with 2 additions and 964 deletions
@@ -1,5 +0,0 @@
-# 策划 Agent Memory Index
-
- [千禧年怀旧文化灵感](nostalgia-culture-inspirations.md) — 电视剧/广播体操/广场舞/电话热线/零食/小孩游戏/乡下活动灵感汇总
- [建筑与区域规划](building-area-plan.md) — 城市主场景完整建筑清单、可进入室内、新增设施共识
- [v0.1执行案状态](v01-execution-status.md) — 三份执行案已通过二次质量门审查，流水线可推进至④程序设计
@@ -1,37 +0,0 @@
---
-name: building-area-plan
-description: 城市主场景建筑与区域规划共识，包含完整建筑清单、可进入室内、新增设施
-metadata:
-  type: project
---
-
-## 城市主场景建筑清单（2026-06-10 确认）
-
-来源：头脑风暴-2026-06-10-建筑与区域规划.md
-
-### 关键变更（vs 原场景设计）
-
- 小伙伴家：原"全部不可进入" → 4家可进入（简化室内）
- 包机房：合并进街机店后屋
- 废品回收：固定摊位 + 流动收废品车
- 秘密基地：多处散布（工地围挡后、平房区死角等）
- 新增店铺：粮油店、服装店/裁缝铺、鞋店（主街东侧）、储蓄所（西侧）
- 新增设施：棋牌室（纯氛围）、公交站牌（纯装饰）、公共厕所、自行车棚、信报箱
-
-### 主街布局（东西排列）
-
-东→：学校操场 | 小卖部 | 粮油店 | 书店 | 服装店 | 鞋店 · 公交站 · 棋牌室 | 储蓄所 | 录像出租 | 网吧 | 街机店 ←西
-
-### 可进入室内（~12个）
-
-完整：主角家、合并小卖部、书店、街机店、网吧、录像出租点
-简化：死党A家（小区内）、死党B家（平房区）、老板儿子家（小卖部后屋）、女班长家（主角家同楼）
-
-### 不做的元素
-
-菜地（留乡下）、装修、游泳（河边不下水）
-
-### How to apply:
- 场景与世界观.md 已更新为最新清单
- 新增店铺和设施在后续版本逐步添加（见版本映射）
- 概念草案不变（冻结），变更记录在系统设计案中
@@ -1,87 +0,0 @@
---
-name: nostalgia-culture-inspirations
-description: 千禧年怀旧文化元素灵感 + 迈皋桥地区历史地理考据，含共识和待深入项
-metadata:
-  type: project
---
-
-## 头脑风暴记录
-
-来源：brainstorm-2026-06-05-nostalgia-culture.md
-日期：2026-06-05/06
-状态：方向确认完毕，待后续决定具体用法
-
-### ⭐ 电话热线玩电视游戏 — 最值得深入
-
- 2000年前后电视台互动节目：打电话用按键音控制屏幕上的射击游戏
- 作为游戏内小游戏的潜力最大：小游戏+叙事+时代感三合一
- 体验流程：走到电话旁 → 拨号 → 进入简化版射击游戏 → 打完显示话费 → 「完了，肯定要被我妈骂」
- starmen1265 明确标记为「值得深入」
-
-### 电视剧/动画文化
-
- 千禧年小孩记忆锚点：还珠格格、西游记、灌篮高手、龙珠、迪迦奥特曼、数码宝贝
- Cartoon Network 通过有线电视收看，是「有有线才能看的频道」
- 引进外国剧：排球女将、成长的烦恼等
- 城郊特有：CRT电视、天线收台、拍电视机、有线电视刚铺开
-
-### 广播体操
-
- 第八套广播体操（1997）或「雏鹰起飞」（少儿版）
- 潜力方向：氛围事件、节奏小游戏、叙事道具
- 城郊特色：泥土操场、大喇叭杂音、冬天缩手做
-
-### 广场舞/社区活动
-
- 2000年前后是前身形态（十几到几十人、收录机放磁带）
- 城郊特色：扭秧歌、露天电影、露天卡拉OK
-
-### 迈皋桥地区历史地理考据（关键发现）
-
-**2000年的迈皋桥处于"正在城市化"的过渡状态**：
- 迈皋桥广场不存在（约2005年随地铁建成，原址是石牌坊+屠宰场）
- 红山路已存在（90年代建成）
- 老街1998年启动拆迁，新旧交替
- 734厂已拆，741厂（华电）还在转型
- 大片菜地+农村平房正在被小区取代
- 南北十里长沟是臭水沟（"龙须沟"），2013年才整治
- 两座7000+职工的国营大厂曾主导整个社区
- 小卖部、大市场、高桥市场等商业氛围浓厚
-
-### How to apply:
- 电话热线游戏适合进入小游戏系统设计，需确定版本归属
- 电视剧/动画元素适合做世界氛围素材（电视内容、贴纸、NPC对话）
- 广播体操和广场舞适合作为场景氛围事件
- 迈皋桥考据直接用于场景设计的"半城半乡"氛围塑造
- 华电子弟学校、工厂宿舍区、菜地、老街都是高还原度的场景元素
-
---
-
-## 2026-06-10 灵感补充
-
-来源：头脑风暴-2026-06-10-建筑与区域规划.md
-
-### 重点新发现（⭐⭐⭐）
-
-1. **钻狗洞的秘密基地** — 多处散布（工地围挡后、平房区死角），高探索叙事价值
-2. **叠纸飞机** — 纸张收集+折叠选择+飞行结果三层玩法
-3. **不知道名字的小哥哥** — 一次性邂逅NPC，极高情感潜力微型叙事线
-4. **体力系统+家庭动态事件** — 吃饭补充体力→不吃炒饭→换速冻水饺→给饭钱
-5. **爷爷奶奶家亲戚小孩** — 乡下NPC角色体系（之前乡下NPC完全空白）
-
-### 新零食/小吃（具体品牌品种）
-
-大大泡泡糖、秀逗（超酸糖）、无花果丝、老鼠屎（盐津葡萄）、跳跳糖、烤鱿鱼、烤里脊
-
-### 新小孩游戏
-
-双人拍手/互推游戏、猜在哪个手里、跑步比赛、叠纸飞机
-
-### 新人物/社交
-
- 北方来南方的同学（与"转学生"角色互补）
- 等着去别人家（串门文化）
-
-### 新乡下活动
-
-钓鱼（鱼竿）、游泳、挤牛奶、喂鸡掏鸡蛋、菜地浇水、打水漂
@@ -1,26 +0,0 @@
---
-name: v01-execution-status
-description: v0.1三份执行案的质量门审查状态——二次审查已通过，但Gitea Issues标签尚未同步
-metadata:
-  type: project
---
-
-## v0.1 执行案审查状态（截至2026-06-05）
-
-三份执行案在二次审查（P-002-review-r2.md）中全部 **✅ 通过**：
- `interaction-system-execution.md` (v0.1.2) — 优秀
- `collection-system-execution.md` (v0.1.1) — 优秀
- `player-controller-execution.md` (v0.1.1) — 良好
-
-### Why:
-首次审查有5条阻塞问题（缺失独立文件、技术越界、内容匮乏、边界缺失），经过3轮迭代全部修正。
-
-### 待同步事项:
- Gitea Issues #1/#2/#3 仍标记为 `gate:execution-fail`、`status:blocked`，需 PM 更新标签
- Pipeline Tracker (#8) 仍显示③为「质量门未通过」，需 PM 更新为通过
- `v01-scope.md` 中 "WASD 步行移动" 需更新为 "WASD 跑步移动"（策划待同步项）
-
-### How to apply:
- 策划侧当前无阻塞任务，流水线可推进至④程序设计
- 非阻塞建议（数据类型描述改行为语言、拾取物外观改纯视觉语言）留待量产阶段
- 物品系统无独立执行案，④程序设计阶段由程序统一处理
@@ -1,5 +0,0 @@
- [Level Builder Tool](level-builder-tool.md) — 白模关卡自动生成 Python 脚本（tools/level-builder/，265→238 Actor 修复后验证通过）
- [UE5.7 Python API](ue57-python-api.md) — 实测 API 差异（set_actor_rotation、new_level、CWD、import 路径、Rotator 关键字参数）
- [V01 Bugfix](level-builder-bugfix-v01.md) — 8个白模关卡问题诊断修复（搭建指南6+解析器双重解析+构建器静默fallback）
- [BSP Pivot Types](bsp-pivot-types.md) — 38种 BSP 资产实测锚点+自动补偿机制（角落/底边中心/底面中心）
- [交互系统架构](interaction-effect-architecture.md) — v1.0 Effect/Action 数据驱动架构（Manager在GI、AInfo Tick、门派生、Prompt独立）
@@ -1,34 +0,0 @@
---
-name: bsp-pivot-types
-description: BlockingStarterPack 全部 38 种 BSP 资产的实测锚点位置和补偿方案
-metadata:
-  type: project
---
-
-# BSP 资产锚点实测数据（2026-06-08）
-
-## 锚点模式分类
-
-| 模式 | 资产 | 特征 | 补偿 |
-|------|------|------|------|
-| **角落** | Floor_*, Cube, Fence_Small_400 | min≈(0,0,0) | XY 各偏半尺寸 |
-| **底边中心** | Wall_*, BarrierWall_* | min≈(0, ±half_thickness, 0) | X 偏半宽度，Y 已居中 |
-| **底面中心** | Cylinder, CirclePlatform, 家具, 道具 | min≈(-half, -half, 0) | 无需补偿 |
-
-## 关键实测尺寸（非 default_size）
-
- **BarrierWall_600**: 实际 600×**60**×**210**cm（非 mapping 中的 20×100）
- **BarrierWall_200**: 实际 200×**60**×**210**cm
- **Floor_1000x1000**: Z 范围 -20 到 2（厚度 22cm，表面在 Z=2）
- **Fence_Small_400**: 实际 407×6×112cm
- **Wall_400x300**: 所有墙体 Y 方向已居中（±10cm）
-
-## 补偿实现
-
-`asset_mapping.py` 中 `pivot_offset_xy` 字段 + `get_pivot_compensation()` 函数：
- 输入: asset_key, scale, rotation
- 输出: (dx, dy) 偏移量
- builder 中: spawn_pos = json_pos - compensation
-
-## Why: 搭建指南统一用视觉中心坐标，但 BSP 资产锚点各异，不补偿会差半模型
-## How to apply: 新增 BSP 资产时先跑 check_pivots.py 实测锚点，再填 pivot_offset_xy。新增搭建指南时位置直接写视觉中心即可。
@@ -1,31 +0,0 @@
---
-name: interaction-effect-architecture
-description: 交互系统 v1.0 Effect/Action 数据驱动架构决策记录
-metadata:
-  type: project
---
-
-## 交互系统架构决策（v1.0 重构，2026-06-11）
-
-### 核心架构：Effect/Action 数据驱动
-
-交互物不关心"交互后发生什么"，只配置 Effect（由 Action 组成）交给 EffectManager 执行。
-
-**Why:** v0.1 用 switch(Type) 硬编码，新增交互类型需改代码。v1.0 配数据即可。
-
-### Manager 归属
- FInteractionManager / FEffectManager 是普通 C++ 类，不是 UObject
- 由 ASystemDriver (AInfo) 持有，随 World 生灭
- 不依赖 UE Subsystem 生命周期，显式控制创建顺序和 Tick 顺序
- 所有 UObject 引用用 TWeakObjectPtr，回调用 TFunction
- GameInstance 不持有任何交互系统对象，只有 UPersistenceSubsystem 跨 World
-
-### 分层规则
- 表现层只读 Manager 缓存（getter），不碰 Component
- Manager 在选择变化时从 Component 读一次并缓存
- 逻辑事件仅用于 "A 影响 B"（如 Consume → Persistence）
-
-### 协调方式
- Character 输入回调通过 ASystemDriver::Get(World) 访问两个 Manager
- Driver::BeginPlay 中 TFunction 连线 EffectManager.OnEffectComplete → Manager.OnInteractionFinished
- PromptComponent 通过 Driver 获取 Manager，只读缓存
@@ -1,27 +0,0 @@
---
-name: level-builder-bugfix-v01
-description: v01白模关卡8个问题的诊断和修复记录，包括搭建指南/解析器/构建器的修改
-metadata:
-  type: project
---
-
-# v01 白模关卡问题修复记录（2026-06-08）
-
-## 修复的文件
-
-| 文件 | 修改内容 |
-|------|---------|
-| `docs/technical/关卡-v01-搭建指南.md` | 修复6个问题：全局地面、Z1双Floor、西边界旋转统一、东边界改Wall_400x300、Z1房屋墙旋转、院门改WallDoorDouble、南边界Z7去重 |
-| `tools/level-builder/parsers/build_guide_parser.py` | 新增 `_deduplicate_actors()` 去重；`_parse_phase_ground` 缩小范围到B1段；支持 `旋转 (P,Y,R)` 列名；支持全局地面标题 |
-| `tools/level-builder/builder/scene_builder.py` | `load_asset` 失败时用 Cube 占位 + `[MISSING]` 前缀 + MI_DevPink 标记 |
-| `tools/level-builder/config/asset_mapping.py` | 新增 `WallDoorDouble_400x300` 资产映射 |
-| `tools/level-builder/parsers/markdown_table.py` | `parse_rotation` 增加箭头注释处理说明 |
-
-## 诊断结论
-
- 8个问题中6个源头在**搭建指南**，2个涉及执行案
- 解析器有双重解析bug（地面段解析了边界表格）已修复
- 构建器有静默fallback已改为醒目标记
-
-## Why: 用户检查生成的白模关卡发现多处明显错误，需要追溯源头并修复
-## How to apply: 重新生成关卡时使用修复后的 JSON（238 Actor）。如再出问题，先查搭建指南再查解析器。
@@ -1,44 +0,0 @@
---
-name: level-builder-tool
-description: 白模关卡自动生成 Python 脚本工具，位于 tools/level-builder/
-metadata:
-  type: project
---
-
-# Level Builder 工具
-
-## 位置
-`tools/level-builder/`
-
-## 功能
-两阶段流水线：解析搭建指南 Markdown → JSON → UE5 Actor
-
-## 使用方式
-```bash
-# 解析
-python tools/level-builder/main.py parse -i docs/technical/关卡-v01-搭建指南.md -o output/level_v01.json
-
-# 验证
-python tools/level-builder/main.py validate -i output/level_v01.json
-
-# 报告
-python tools/level-builder/main.py report -i output/level_v01.json -o output/搭建报告.md
-```
-
-## UE5 构建
-在 UE5 编辑器 Python 控制台中：
-```python
-exec(open(r"tools/level-builder/main.py").read())
-# 然后 main(["build", "-i", "output/level_v01.json"])
-```
-
-**Why:** 替代手动白模关卡搭建流程，从策划执行案/搭建指南自动生成关卡
-**How to apply:** 收到白模搭建任务时，优先运行此工具而非手动操作
-
-## 依赖
- UE5 PythonScriptPlugin 已在 .uproject 中启用
- 37 种 BSP 资产映射（config/asset_mapping.py）
- 当前解析搭建指南（parsers/build_guide_parser.py），未来扩展执行案解析器
-
-## 数据
- v0.1 解析结果：265 个 Actor（STR:123, PROP:53, BND:61, INTR:10, COLL:9, LGT:8, PLAY:1）
@@ -1,69 +0,0 @@
---
-name: ue57-python-api
-description: UE5.7 Python API 实测差异记录——set_actor_rotation、new_level、CWD 问题
-metadata:
-  type: project
---
-
-# UE5.7 Python API 实测差异
-
-## 2026-06-07 实测（UE 5.7, PythonScriptPlugin）
-
-### `set_actor_rotation()` 需要 `teleport_physics` 参数
-```python
-# UE5.6 文档写法（会报错）:
-actor.set_actor_rotation(unreal.Rotator(pitch, yaw, roll))
-
-# UE5.7 正确写法:
-actor.set_actor_rotation(unreal.Rotator(pitch, yaw, roll), False)
-```
-**Why:** UE5.7 改了 API 签名，positional argument `teleport_physics` 变为必需
-**How to apply:** 所有 `set_actor_rotation()` 调用都加第二个参数 `False`
-
-### `unreal.Rotator` 位置参数顺序不是 (Pitch, Yaw, Roll)
-```python
-# ❌ 错误：位置参数顺序非 P,Y,R，Yaw=90 会落到 Pitch(Y显示)
-actor.set_actor_rotation(unreal.Rotator(0, 90, 0), False)
-
-# ✅ 正确：用关键字参数避免歧义
-actor.set_actor_rotation(unreal.Rotator(pitch=0, yaw=90, roll=0), False)
-```
-**Why:** UE5.7 Python `unreal.Rotator` 的位置参数顺序与关键字参数名不一致，第二个位置参数映射到 Pitch 而非 Yaw
-**How to apply:** 所有 `unreal.Rotator()` 调用必须使用关键字参数 `pitch=, yaw=, roll=`
-
-### `-ExecutePythonScript` 模式下 CWD 不是项目目录
-```python
-# ❌ 错误：CWD 是引擎 Binaries 目录
-PROJECT_ROOT = Path(os.getcwd())
-# → E:\...\UE_5.7\Engine\Binaries\Win64
-
-# ✅ 正确：通过环境变量传入
-PROJECT_ROOT = Path(os.environ.get("LB_PROJECT_ROOT", ""))
-```
-**Why:** UE5 引擎启动时将 CWD 设为引擎二进制目录
-**How to apply:** 由 bat 脚本设置 `LB_PROJECT_ROOT` 环境变量，Python 脚本从中读取
-
-### `new_level()` 需要 `asset_path` 参数
-```python
-# ❌ 错误：
-unreal.EditorLevelLibrary.new_level()
-
-# ✅ 正确：
-unreal.EditorLevelLibrary.new_level("/Game/Maps/LVL_SuburbanV01")
-```
-
-### `AssetToolsSubsystem` 在 UE5.7 Python 中不可用
-`unreal.get_editor_subsystem(unreal.AssetToolsSubsystem)` 报 `no attribute 'AssetToolsSubsystem'`
-改用 `unreal.EditorLevelLibrary.new_level(asset_path)` 创建关卡
-
-### 目录名含连字符导致 Python import 失败
-```
-tools/level-builder/  ← 连字符
-from tools.level_builder.config...  ← 下划线，Python import 不支持连字符
-```
-修复：将 level-builder 根目录加入 sys.path，使用 `from config.asset_mapping import ...` 代替完整路径
-
-## 相关文件
- `tools/level-builder/builder/scene_builder.py`
- `tools/level-builder/build_cmdline.py`
- `tools/level-builder/build_level.bat`
@@ -1,12 +0,0 @@
---
-name: subagent-permissions
-description: 后台子 Agent 需要预授权 Edit/Write 权限才能修改文件
-metadata:
-  type: feedback
---
-
-后台子 Agent（game-dev 等）无法弹出交互式权限确认，缺少 Edit/Write 授权时会直接被拒绝文件修改。
-
-**Why:** 首次启动 game-dev 后台 Agent 实现 P-011 时，因 settings.json 缺少 Edit/Write 权限，Agent 只读了技术文档但无法修改源码。
-
-**How to apply:** 在 `.claude/settings.json` 的 `permissions.allow` 中添加 `"Edit"` 和 `"Write"`（2026-06-10 已添加）。如果后续新增需要后台运行的工具，同样需要预授权对应权限。
@@ -1,35 +0,0 @@
---
-name: pipeline-status-20260603
-description: 2026-06-03 的流水线阶段判断结果，v0.1 处于阶段④执行案完善中
-metadata:
-  type: project
---
-
-# 流水线阶段判断 — 2026-06-03
-
-**当前版本**: v0.1 场景漫游与环境交互
-**流水线阶段**: ④ 执行案（质量门未通过）
-**游戏开发阶段**: 预制作
-
-## 各阶段状态
-
-| 阶段 | 状态 |
-|------|------|
-| ① 全局设计案 | 通过 |
-| ② 版本Roadmap | 通过（但需补全 v0.5-v0.7） |
-| ③ 当前版本设计文档 | 通过 |
-| ④ 执行案 | **未通过质量门** |
-| ⑤ 程序设计 | 不存在（前置未通过） |
-| ⑥ 美术产出 | 部分就位（主角模型已开始，白盒占位未系统产出） |
-| ⑦ 程序实现 | 未开始 |
-
-## 关键发现
-
- 设计文档产出良好，覆盖面广
- 但执行案与全局设计混合在同一文档中，未按流水线要求独立
- 程序实现完全未启动（仅有 UE5 第三人称模板代码）
- 模板变体代码（Variant_Combat/Platforming/SideScrolling）未清理
- GameConfig/ 无实际配置文件
-
-**Why:** 首次 /plan 诊断的基线快照
-**How to apply:** 后续 /plan 调用时对比此基线判断进度变化
@@ -1,28 +0,0 @@
---
-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]]
@@ -1,35 +0,0 @@
---
-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 +0,0 @@
---
-name: roadmap-alignment
-description: 路线图已于 2026-06-05 全面重新评估，3 版本扩展为 4 版本，与可行性评估对齐
-metadata:
-  type: project
---
-
-# 路线图重新评估完成（2026-06-05）
-
-原 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
-
-**Why:** 原 v0.2/v0.3 范围过大（各 20-32 天），单人开发风险高。拆分后每版本聚焦一个核心假设
-**How to apply:** 后续版本开发时，每版本聚焦一个假设，范围不再膨胀。如果发现范围偏大应及时拆分而非堆叠
-
-关联记忆：[[pipeline-status-20260605]]
@@ -1,6 +0,0 @@
-# game-reviewer 记忆索引
-
- [Gitea Token Permission](gitea-token-permission.md) — reviewer token 仅可评论，标签操作需用 PM token
- [P-006 Review](p006-review-note.md) — Issue #17 白模搭建审查通过记录
- [P-009 Review](p009-review-note.md) — Issue #20 收集系统程序设计审查通过记录
- [P-014 Review](p014-review-note.md) — Issue #39 交互系统技术方案修订审查通过记录（v1.1）
@@ -1,12 +0,0 @@
---
-name: gitea-token-permission
-description: reviewer token 权限限制——仅可评论，标签操作需 PM token
-metadata:
-  type: feedback
---
-
-reviewer token (ff336234...) 权限不足，无法修改 Issue 标签（HTTP 403: write permission is required）。评论操作正常。
-
-**Why:** reviewer token 可能被配置为只读 + 评论权限。
-
-**How to apply:** 标签更新操作使用 PM 角色执行：`node .claude/skills/gitea-pm/gitea.js --role pm issue labels <number> --set <ids>`
@@ -1,14 +0,0 @@
---
-name: p006-review-note
-description: Issue #17 P-006 白模搭建审查通过记录
-metadata:
-  type: project
---
-
-P-006（Issue #17）v0.1 白模关卡搭建审查于 2026-06-08 通过。
-
-**结论:** 7 区域完整覆盖执行案，238 Actor，偏差记录详尽。
-
-**已知偏差:** Z5 巷子宽度 260cm vs 设计 300cm（重大但不阻塞，260cm 仍可通行）。
-
-**How to apply:** 后续 6b-6f 子任务可继续推进。空间精度偏差由用户决定是否修正。
@@ -1,19 +0,0 @@
---
-name: p009-review-note
-description: Issue #20 P-009 收集系统程序设计审查通过记录
-metadata:
-  type: project
---
-
-## P-009 收集系统程序设计审查 (2026-06-10)
-
- Issue: #20
- 审查类型: 程序设计（质量门 2）
- 产出文件: `docs/technical/收集系统-技术方案.md`
- 结果: **通过**
-
-### 审查要点
- 技术方案文档路径实际为中文文件名 `收集系统-技术方案.md`（非 Issue 中标注的 `collection-system-tech.md`）
- 执行案文件名也是中文：`收集系统-执行案.md`（非 `collection-system-execution.md`）
- 6 个检查维度全部通过：执行案覆盖度、美术资源需求、架构清晰度、数据流、技术风险、工作量与拆分建议
- 标签操作：移除了 gate:art-fail(30) 和 status:in-review(14)，添加了 review:pass(33)
@@ -1,35 +0,0 @@
---
-name: p014-review-note
-description: Issue #39 交互系统技术方案修订审查通过记录
-metadata:
-  type: project
---
-
-## P-014 交互系统技术方案审查
-
- **Issue**: #39
- **审查日期**: 2026-06-11
- **审查类型**: 程序设计（技术方案修订）
- **结果**: 通过
-
-### 审查历程
-
-1. v1.0 初次审查未通过，提出 7 个问题
-2. v1.1 修订后重新审查，7 个问题全部解决，通过
-
-### 7 个审查问题及解决状态
-
-1. 模板 A/E 关闭流程补充 HideNarrative + CameraReturn -- 已解决
-2. CancelEffect() 行为完整定义（含 WaitForInput 暂停态和 PerformCleanup） -- 已解决
-3. 随机文本选取逻辑（bRandomSelect + PickRandomNarrative） -- 已解决
-4. FSelectedInfo 结构体定义（bHasSelection, PromptText, WorldPosition, bIsConsumed） -- 已解决
-5. FTurnState 结构体定义（StartRotation, TargetRotation, ElapsedTime, Duration） -- 已解决
-6. 观察类关闭机制实现 bWaitForInput（非 TotalDuration 硬控） -- 已解决
-7. 时序图标注改为 FInteractionManager(ASystemDriver持有) -- 已解决
-
-### 产出文件
-
- `docs/technical/交互系统-技术方案.md` (v1.1)
-
-**Why:** 记录交互系统技术方案的审查历程，便于后续追溯架构决策。
-**How to apply:** 后续涉及交互系统技术方案变更时参考此记录。
@@ -1,2 +0,0 @@
- [Project Tech Stack](project-tech-stack.md) — D-002 确定的技术架构、模块选择、风险和工期预估
- [Codebase Cleanup Needed](feedback-codebase-cleanup.md) — Variant_* 遗留代码需在 v0.1 前清理
@@ -1,14 +0,0 @@
---
-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 作为项目基类保留。
@@ -1,36 +0,0 @@
---
-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 个月全职）