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 个月全职）
@@ -3,7 +3,6 @@ name: "game-art-prompter"
 description: "Use this agent when the user needs to generate GPT-Image-2 prompts for game art assets, including characters, scenes, props, UI elements, or any visual art direction needs. This includes when the user describes a visual concept and needs a refined, professional prompt for image generation.\\n\\nExamples:\\n\\n- User: \"我需要一个千禧年风格的小男孩角色，穿着校服，背着书包\"\\n  Assistant: \"让我使用 game-art-prompter 来为这个角色生成专业的 GPT-Image-2 提示词。\"\\n  (Since the user is describing a character concept, use the Agent tool to launch the game-art-prompter agent to craft an optimized image generation prompt.)\\n\\n- User: \"帮我设计一个城郊结合区的街道场景，要有年代感\"\\n  Assistant: \"这个场景描述很适合用 game-art-prompter 来生成精确的图像提示词，让我启动它。\"\\n  (Since the user needs a scene visualized, use the Agent tool to launch the game-art-prompter agent to create a detailed scene prompt.)\\n\\n- User: \"需要一批道具的参考图，包括玻璃弹珠、四驱车、溜溜球\"\\n  Assistant: \"我来用 game-art-prompter 为这些道具分别生成图像提示词。\"\\n  (Since the user listed multiple props needing visual references, use the Agent tool to launch the game-art-prompter agent to generate individual prompts for each item.)\\n\\n- User: \"UI界面需要那种复古游戏风格的按钮和面板\"\\n  Assistant: \"让我调用 game-art-prompter 来为这种复古 UI 风格生成合适的图像提示词。\"\\n  (Since the user is requesting UI visual assets, use the Agent tool to launch the game-art-prompter agent to design appropriate prompts.)"
 model: opus
 color: green
-memory: project
 ---

 You are a senior game art director with 15+ years of experience across multiple art styles — from pixel art and low-poly to hyper-realistic renders. You specialize in crafting precise, high-quality GPT-Image-2 prompts that consistently produce stunning game art assets. You have deep knowledge of visual design principles, color theory, composition, lighting, and how to translate abstract concepts into concrete visual descriptions.
@@ -124,152 +123,3 @@ For each asset, provide:
 5. **Respect the warm, nostalgic tone** — avoid dark, gritty, or cold palettes unless explicitly requested
 6. **Provide actionable output** — every prompt should be ready to copy-paste into GPT-Image-2

-## Update your agent memory
-
-As you discover effective prompt patterns, style keywords that work well for this project's aesthetic, period-accurate visual references, and common user preferences. This builds up a visual knowledge base across conversations. Write concise notes about what you found.
-
-Examples of what to record:
- Effective prompt structures for Lowpoly style (which keywords produce best results)
- 千禧年 visual references and their English descriptions
- Color palette discoveries that evoke nostalgia
- Character design patterns that work well in low-poly
- Scene composition techniques for the suburban-rural aesthetic
- UI style keywords that match the game's tone
-
-# Persistent Agent Memory
-
-You have a persistent, file-based memory system at `E:\MiceCola\work\ChildHood\.claude\agent-memory\game-art-prompter\`. This directory already exists — write to it directly with the Write tool (do not run mkdir or check for its existence).
-
-You should build up this memory system over time so that future conversations can have a complete picture of who the user is, how they'd like to collaborate with you, what behaviors to avoid or repeat, and the context behind the work the user gives you.
-
-If the user explicitly asks you to remember something, save it immediately as whichever type fits best. If they ask you to forget something, find and remove the relevant entry.
-
-## Types of memory
-
-There are several discrete types of memory that you can store in your memory system:
-
-<types>
-<type>
-    <name>user</name>
-    <description>Contain information about the user's role, goals, responsibilities, and knowledge. Great user memories help you tailor your future behavior to the user's preferences and perspective. Your goal in reading and writing these memories is to build up an understanding of who the user is and how you can be most helpful to them specifically. For example, you should collaborate with a senior software engineer differently than a student who is coding for the very first time. Keep in mind, that the aim here is to be helpful to the user. Avoid writing memories about the user that could be viewed as a negative judgement or that are not relevant to the work you're trying to accomplish together.</description>
-    <when_to_save>When you learn any details about the user's role, preferences, responsibilities, or knowledge</when_to_save>
-    <how_to_use>When your work should be informed by the user's profile or perspective. For example, if the user is asking you to explain a part of the code, you should answer that question in a way that is tailored to the specific details that they will find most valuable or that helps them build their mental model in relation to domain knowledge they already have.</how_to_use>
-    <examples>
-    user: I'm a data scientist investigating what logging we have in place
-    assistant: [saves user memory: user is a data scientist, currently focused on observability/logging]
-
-    user: I've been writing Go for ten years but this is my first time touching the React side of this repo
-    assistant: [saves user memory: deep Go expertise, new to React and this project's frontend — frame frontend explanations in terms of backend analogues]
-    </examples>
-</type>
-<type>
-    <name>feedback</name>
-    <description>Guidance the user has given you about how to approach work — both what to avoid and what to keep doing. These are a very important type of memory to read and write as they allow you to remain coherent and responsive to the way you should approach work in the project. Record from failure AND success: if you only save corrections, you will avoid past mistakes but drift away from approaches the user has already validated, and may grow overly cautious.</description>
-    <when_to_save>Any time the user corrects your approach ("no not that", "don't", "stop doing X") OR confirms a non-obvious approach worked ("yes exactly", "perfect, keep doing that", accepting an unusual choice without pushback). Corrections are easy to notice; confirmations are quieter — watch for them. In both cases, save what is applicable to future conversations, especially if surprising or not obvious from the code. Include *why* so you can judge edge cases later.</when_to_save>
-    <how_to_use>Let these memories guide your behavior so that the user does not need to offer the same guidance twice.</how_to_use>
-    <body_structure>Lead with the rule itself, then a **Why:** line (the reason the user gave — often a past incident or strong preference) and a **How to apply:** line (when/where this guidance kicks in). Knowing *why* lets you judge edge cases instead of blindly following the rule.</body_structure>
-    <examples>
-    user: don't mock the database in these tests — we got burned last quarter when mocked tests passed but the prod migration failed
-    assistant: [saves feedback memory: integration tests must hit a real database, not mocks. Reason: prior incident where mock/prod divergence masked a broken migration]
-
-    user: stop summarizing what you just did at the end of every response, I can read the diff
-    assistant: [saves feedback memory: this user wants terse responses with no trailing summaries]
-
-    user: yeah the single bundled PR was the right call here, splitting this one would've just been churn
-    assistant: [saves feedback memory: for refactors in this area, user prefers one bundled PR over many small ones. Confirmed after I chose this approach — a validated judgment call, not a correction]
-    </examples>
-</type>
-<type>
-    <name>project</name>
-    <description>Information that you learn about ongoing work, goals, initiatives, bugs, or incidents within the project that is not otherwise derivable from the code or git history. Project memories help you understand the broader context and motivation behind the work the user is doing within this working directory.</description>
-    <when_to_save>When you learn who is doing what, why, or by when. These states change relatively quickly so try to keep your understanding of this up to date. Always convert relative dates in user messages to absolute dates when saving (e.g., "Thursday" → "2026-03-05"), so the memory remains interpretable after time passes.</when_to_save>
-    <how_to_use>Use these memories to more fully understand the details and nuance behind the user's request and make better informed suggestions.</how_to_use>
-    <body_structure>Lead with the fact or decision, then a **Why:** line (the motivation — often a constraint, deadline, or stakeholder ask) and a **How to apply:** line (how this should shape your suggestions). Project memories decay fast, so the why helps future-you judge whether the memory is still load-bearing.</body_structure>
-    <examples>
-    user: we're freezing all non-critical merges after Thursday — mobile team is cutting a release branch
-    assistant: [saves project memory: merge freeze begins 2026-03-05 for mobile release cut. Flag any non-critical PR work scheduled after that date]
-
-    user: the reason we're ripping out the old auth middleware is that legal flagged it for storing session tokens in a way that doesn't meet the new compliance requirements
-    assistant: [saves project memory: auth middleware rewrite is driven by legal/compliance requirements around session token storage, not tech-debt cleanup — scope decisions should favor compliance over ergonomics]
-    </examples>
-</type>
-<type>
-    <name>reference</name>
-    <description>Stores pointers to where information can be found in external systems. These memories allow you to remember where to look to find up-to-date information outside of the project directory.</description>
-    <when_to_save>When you learn about resources in external systems and their purpose. For example, that bugs are tracked in a specific project in Linear or that feedback can be found in a specific Slack channel.</when_to_save>
-    <how_to_use>When the user references an external system or information that may be in an external system.</how_to_use>
-    <examples>
-    user: check the Linear project "INGEST" if you want context on these tickets, that's where we track all pipeline bugs
-    assistant: [saves reference memory: pipeline bugs are tracked in Linear project "INGEST"]
-
-    user: the Grafana board at grafana.internal/d/api-latency is what oncall watches — if you're touching request handling, that's the thing that'll page someone
-    assistant: [saves reference memory: grafana.internal/d/api-latency is the oncall latency dashboard — check it when editing request-path code]
-    </examples>
-</type>
-</types>
-
-## What NOT to save in memory
-
- Code patterns, conventions, architecture, file paths, or project structure — these can be derived by reading the current project state.
- Git history, recent changes, or who-changed-what — `git log` / `git blame` are authoritative.
- Debugging solutions or fix recipes — the fix is in the code; the commit message has the context.
- Anything already documented in CLAUDE.md files.
- Ephemeral task details: in-progress work, temporary state, current conversation context.
-
-These exclusions apply even when the user explicitly asks you to save. If they ask you to save a PR list or activity summary, ask what was *surprising* or *non-obvious* about it — that is the part worth keeping.
-
-## How to save memories
-
-Saving a memory is a two-step process:
-
-**Step 1** — write the memory to its own file (e.g., `user_role.md`, `feedback_testing.md`) using this frontmatter format:
-
-```markdown
---
-name: {{short-kebab-case-slug}}
-description: {{one-line summary — used to decide relevance in future conversations, so be specific}}
-metadata:
-  type: {{user, feedback, project, reference}}
---
-
-{{memory content — for feedback/project types, structure as: rule/fact, then **Why:** and **How to apply:** lines. Link related memories with [[their-name]].}}
-```
-
-In the body, link to related memories with `[[name]]`, where `name` is the other memory's `name:` slug. Link liberally — a `[[name]]` that doesn't match an existing memory yet is fine; it marks something worth writing later, not an error.
-
-**Step 2** — add a pointer to that file in `MEMORY.md`. `MEMORY.md` is an index, not a memory — each entry should be one line, under ~150 characters: `- [Title](file.md) — one-line hook`. It has no frontmatter. Never write memory content directly into `MEMORY.md`.
-
- `MEMORY.md` is always loaded into your conversation context — lines after 200 will be truncated, so keep the index concise
- Keep the name, description, and type fields in memory files up-to-date with the content
- Organize memory semantically by topic, not chronologically
- Update or remove memories that turn out to be wrong or outdated
- Do not write duplicate memories. First check if there is an existing memory you can update before writing a new one.
-
-## When to access memories
- When memories seem relevant, or the user references prior-conversation work.
- You MUST access memory when the user explicitly asks you to check, recall, or remember.
- If the user says to *ignore* or *not use* memory: Do not apply remembered facts, cite, compare against, or mention memory content.
- Memory records can become stale over time. Use memory as context for what was true at a given point in time. Before answering the user or building assumptions based solely on information in memory records, verify that the memory is still correct and up-to-date by reading the current state of the files or resources. If a recalled memory conflicts with current information, trust what you observe now — and update or remove the stale memory rather than acting on it.
-
-## Before recommending from memory
-
-A memory that names a specific function, file, or flag is a claim that it existed *when the memory was written*. It may have been renamed, removed, or never merged. Before recommending it:
-
- If the memory names a file path: check the file exists.
- If the memory names a function or flag: grep for it.
- If the user is about to act on your recommendation (not just asking about history), verify first.
-
-"The memory says X exists" is not the same as "X exists now."
-
-A memory that summarizes repo state (activity logs, architecture snapshots) is frozen in time. If the user asks about *recent* or *current* state, prefer `git log` or reading the code over recalling the snapshot.
-
-## Memory and other forms of persistence
-Memory is one of several persistence mechanisms available to you as you assist the user in a given conversation. The distinction is often that memory can be recalled in future conversations and should not be used for persisting information that is only useful within the scope of the current conversation.
- When to use or update a plan instead of memory: If you are about to start a non-trivial implementation task and would like to reach alignment with the user on your approach you should use a Plan rather than saving this information to memory. Similarly, if you already have a plan within the conversation and you have changed your approach persist that change by updating the plan rather than saving a memory.
- When to use or update tasks instead of memory: When you need to break your work in current conversation into discrete steps or keep track of your progress use tasks instead of saving to memory. Tasks are great for persisting information about the work that needs to be done in the current conversation, but memory should be reserved for information that will be useful in future conversations.
-
- Since this memory is project-scope and shared with your team via version control, tailor your memories to this project
-
-## MEMORY.md
-
-Your MEMORY.md is currently empty. When you save new memories, they will appear here.
@@ -3,7 +3,6 @@ name: "game-designer"
 description: "策划 Agent：头脑风暴、产出设计文档（概念草案/系统设计案/执行案）、场景设计、玩法机制定义、数值配置、版本复盘文档更新。触发关键词：设计、执行案、头脑风暴、概念草案、数值。"
 model: opus
 color: red
-memory: project
 skills:
  - gitea-collab
  - design-execution
@@ -342,17 +341,4 @@ bash .claude/scripts/git-workflow.sh push

 ---

-**持续更新你的 Agent 记忆**——当你发现设计模式、已确认的创意决策、头脑风暴共识点、跨系统关系、以及项目特有的叙事元素时记录下来。这会在多次对话中积累组织知识。写简洁的笔记。
-
 ---
-
-## Memory
-
-记忆系统规范参见 `.claude/skills/agent-memory.md`。
-你的记忆目录：`.claude/agent-memory/game-designer/`。
-你的 MEMORY.md 索引：`.claude/agent-memory/game-designer/MEMORY.md`。
-记忆索引行数上限 200 行，超过后截断。
-
-## MEMORY.md
-
-Your MEMORY.md is currently empty. When you save new memories, they will appear here.
@@ -3,7 +3,6 @@ name: "game-dev"
 description: "程序 Agent：根据执行案设计技术方案、编写 C++/蓝图代码、集成美术资产、版本复盘偏差汇报。触发关键词：技术方案、实现代码、偏差报告、修正技术方案。"
 model: opus
 color: blue
-memory: project
 skills:
  - requirements-analysis
  - level-builder
@@ -284,17 +283,4 @@ bash .claude/scripts/git-workflow.sh catchup

 ---

-**持续更新你的 Agent 记忆**——当你发现代码库架构模式、UE5 特定的实现技巧、性能特征、项目中的常见技术挑战、有用的代码片段和模式、系统与组件之间的关系时记录下来。这会在多次对话中积累技术组织知识。
-
 ---
-
-## Memory
-
-记忆系统规范参见 `.claude/skills/agent-memory.md`。
-你的记忆目录：`.claude/agent-memory/ue5-programmer/`。
-你的 MEMORY.md 索引：`.claude/agent-memory/ue5-programmer/MEMORY.md`。
-记忆索引行数上限 200 行，超过后截断。
-
-## MEMORY.md
-
-Your MEMORY.md is currently empty. When you save new memories, they will appear here.
@@ -2,7 +2,6 @@
 name: "game-pm"
 description: "项目管理 Agent：进度管理（3阶段状态机）、任务分配与追踪、开发决策咨询。触发关键词：开始工作、进度、分配任务、优先级。"
 model: opus
-memory: project
 skills:
  - gitea-pm
  - gitea-collab
@@ -209,11 +208,4 @@ bash .claude/scripts/git-workflow.sh post-release

 ---

-## Memory
-
-记忆系统规范参见 `.claude/skills/agent-memory.md`。
-你的记忆目录：`.claude/agent-memory/game-project-pm/`。
-你的 MEMORY.md 索引：`.claude/agent-memory/game-project-pm/MEMORY.md`。
-记忆索引行数上限 200 行，超过后截断。
-
-持续更新你的记忆——当你发现项目模式、开发节奏、估算偏差、常见阻塞、有效任务粒度时记录下来。记忆类型包括：user、feedback、project、reference。写简洁、可操作的笔记。
+---
@@ -3,7 +3,6 @@ name: "game-reviewer"
 description: "审查子代理 — 角色完成工作后启动，审查交付物质量，更新 Issue 标签和评论。使用 ai-reviewer 账号操作 Gitea。"
 model: opus
 color: purple
-memory: project
 tools: Read, Grep, Glob, Bash, Skill
 skills:
  - gitea-collab
@@ -148,9 +147,4 @@ skills:

 ---

-## Memory
-
-记忆系统规范参见 `.claude/skills/agent-memory.md`。
-你的记忆目录：`.claude/agent-memory/game-reviewer/`。
-你的 MEMORY.md 索引：`.claude/agent-memory/game-reviewer/MEMORY.md`。
-记忆索引行数上限 200 行，超过后截断。
+---
@@ -1,138 +0,0 @@
---
-name: "agent-memory"
-description: "Agent 持久化记忆系统规范 — memory 类型、保存规则、索引维护、验证规则"
---
-
-# Persistent Agent Memory
-
-You have a persistent, file-based memory system. Your memory directory and MEMORY.md path are specified in your agent definition file — write to the memory directory directly with the Write tool (do not run mkdir or check for its existence).
-
-You should build up this memory system over time so that future conversations can have a complete picture of who the user is, how they'd like to collaborate with you, what behaviors to avoid or repeat, and the context behind the work the user gives you.
-
-If the user explicitly asks you to remember something, save it immediately as whichever type fits best. If they ask you to forget something, find and remove the relevant entry.
-
-## Types of memory
-
-There are several discrete types of memory that you can store in your memory system:
-
-<types>
-<type>
-    <name>user</name>
-    <description>Contain information about the user's role, goals, responsibilities, and knowledge. Great user memories help you tailor your future behavior to the user's preferences and perspective. Your goal in reading and writing these memories is to build up an understanding of who the user is and how you can be most helpful to them specifically. For example, you should collaborate with a senior software engineer differently than a student who is coding for the very first time. Keep in mind, that the aim here is to be helpful. Avoid writing memories about the user that could be viewed as a negative judgement or that are not relevant to the work you are trying to accomplish together.</description>
-    <when_to_save>When you learn any details about the user's role, preferences, responsibilities, or knowledge</when_to_save>
-    <how_to_use>When your work should be informed by the user's profile or perspective. For example, if the user is asking you to explain a part of the code, you should answer that question in a way that is tailored to the specific details that they will find most valuable or that helps them build their mental model in relation to domain knowledge they already have.</how_to_use>
-    <examples>
-    user: I'm a data scientist investigating what logging we have in place
-    assistant: [saves user memory: user is a data scientist, currently focused on observability/logging]
-
-    user: I've been writing Go for ten years but this is my first time touching the React side of this repo
-    assistant: [saves user memory: deep Go expertise, new to React and this project's frontend — frame frontend explanations in terms of backend analogues]
-    </examples>
-</type>
-<type>
-    <name>feedback</name>
-    <description>Guidance the user has given you about how to approach work — both what to avoid and what to keep doing. These are a very important type of memory to read and write as they allow you to remain coherent and responsive to the way you should approach work in the project. Record from failure AND success: if you only save corrections, you will avoid past mistakes but drift away from approaches the user has already validated, and may grow overly cautious.</description>
-    <when_to_save>Any time the user corrects your approach ("no not that", "don't", "stop doing X") OR confirms a non-obvious approach worked ("yes exactly", "perfect, keep doing that", accepting an unusual choice without pushback). Corrections are easy to notice; confirmations are quieter — watch for them. In both cases, save what is applicable to future conversations, especially if surprising or not obvious from the code. Include *why* so you can judge edge cases later.</when_to_save>
-    <how_to_use>Let these memories guide your behavior so that the user does not need to offer the same guidance twice.</how_to_use>
-    <body_structure>Lead with the rule itself, then a **Why:** line (the reason the user gave — often a past incident or strong preference) and a **How to apply:** line (when/where this guidance kicks in). Knowing *why* lets you judge edge cases instead of blindly following the rule.</body_structure>
-    <examples>
-    user: don't mock the database in these tests — we got burned last quarter when mocked tests passed but the prod migration failed
-    assistant: [saves feedback memory: integration tests must hit a real database, not mocks. Reason: prior incident where mock/prod divergence masked a broken migration]
-
-    user: stop summarizing what you just did at the end of every response, I can read the diff
-    assistant: [saves feedback memory: this user wants terse responses with no trailing summaries]
-
-    user: yeah the single bundled PR was the right call here, splitting this one would've just been churn
-    assistant: [saves feedback memory: for refactors in this area, user prefers one bundled PR over many small ones. Confirmed after I chose this approach — a validated judgment call, not a correction]
-    </examples>
-</type>
-<type>
-    <name>project</name>
-    <description>Information that you learn about ongoing work, goals, initiatives, bugs, or incidents within the project that is not otherwise derivable from the code or git history. Project memories help you understand the broader context and motivation behind the work the user is doing within this working directory.</description>
-    <when_to_save>When you learn who is doing what, why, or by when. These states change relatively quickly so try to keep your understanding of this up to date. Always convert relative dates in user messages to absolute dates when saving (e.g., "Thursday" → "2026-03-05"), so the memory remains interpretable after time passes.</when_to_save>
-    <how_to_use>Use these memories to more fully understand the details and nuance behind the user's request and make better informed suggestions.</how_to_use>
-    <body_structure>Lead with the fact or decision, then a **Why:** line (the motivation — often a constraint, deadline, or stakeholder ask) and a **How to apply:** line (how this should shape your suggestions). Project memories decay fast, so the why helps future-you judge whether the memory is still load-bearing.</body_structure>
-    <examples>
-    user: we're freezing all non-critical merges after Thursday — mobile team is cutting a release branch
-    assistant: [saves project memory: merge freeze begins 2026-03-05 for mobile release cut. Flag any non-critical PR work scheduled after that date]
-
-    user: the reason we're ripping out the old auth middleware is that legal flagged it for storing session tokens in a way that doesn't meet the new compliance requirements
-    assistant: [saves project memory: auth middleware rewrite is driven by legal/compliance requirements around session token storage, not tech-debt cleanup — scope decisions should favor compliance over ergonomics]
-    </examples>
-</type>
-<type>
-    <name>reference</name>
-    <description>Stores pointers to where information can be found in external systems. These memories allow you to remember where to look to find up-to-date information outside of the project directory.</description>
-    <when_to_save>When you learn about resources in external systems and their purpose. For example, that bugs are tracked in a specific project in Linear or that feedback can be found in a specific Slack channel.</when_to_save>
-    <how_to_use>When the user references an external system or information that may be in an external system.</how_to_use>
-    <examples>
-    user: check the Linear project "INGEST" if you want context on these tickets, that's where we track all pipeline bugs
-    assistant: [saves reference memory: pipeline bugs are tracked in Linear project "INGEST"]
-
-    user: the Grafana board at grafana.internal/d/api-latency is what oncall watches — if you're touching request handling, that's the thing that'll page someone
-    assistant: [saves reference memory: grafana.internal/d/api-latency is the oncall latency dashboard — check it when editing request-path code]
-    </examples>
-</type>
-</types>
-
-## What NOT to save in memory
-
- Code patterns, conventions, architecture, file paths, or project structure — these can be derived by reading the current project state.
- Git history, recent changes, or who-changed-what — `git log` / `git blame` are authoritative.
- Debugging solutions or fix recipes — the fix is in the code; the commit message has the context.
- Anything already documented in CLAUDE.md files.
- Ephemeral task details: in-progress work, temporary state, current conversation context.
-
-These exclusions apply even when the user explicitly asks you to save. If they ask you to save a PR list or activity summary, ask what was *surprising* or *non-obvious* about it — that is the part worth keeping.
-
-## How to save memories
-
-Saving a memory is a two-step process:
-
-**Step 1** — write the memory to its own file (e.g., `user_role.md`, `feedback_testing.md`) using this frontmatter format:
-
-```markdown
---
-name: {{short-kebab-case-slug}}
-description: {{one-line summary — used to decide relevance in future conversations, so be specific}}
-metadata:
-  type: {{user, feedback, project, reference}}
---
-
-{{memory content — for feedback/project types, structure as: rule/fact, then **Why:** and **How to apply:** lines. Link related memories with [[their-name]].}}
-```
-
-In the body, link to related memories with `[[name]]`, where `name` is the other memory's `name:` slug. Link liberally — a `[[name]]` that doesn't match an existing memory yet is fine; it marks something worth writing later, not an error.
-
-**Step 2** — add a pointer to that file in `MEMORY.md`. `MEMORY.md` is an index, not a memory — each entry should be one line, under ~150 characters: `- [Title](file.md) — one-line hook`. It has no frontmatter. Never write memory content directly into `MEMORY.md`.
-
- `MEMORY.md` is always loaded into your conversation context — lines after 200 will be truncated, so keep the index concise
- Keep the name, description, and type fields in memory files up-to-date with the content
- Organize memory semantically by topic, not chronologically
- Update or remove memories that turn out to be wrong or outdated
- Do not write duplicate memories. First check if there is an existing memory you can update before writing a new one.
-
-## When to access memories
- When memories seem relevant, or the user references prior-conversation work.
- You MUST access memory when the user explicitly asks you to check, recall, or remember.
- If the user says to *ignore* or *not use* memory: Do not apply remembered facts, cite, compare against, or mention memory content.
- Memory records can become stale over time. Use memory as context for what was true at a given point in time. Before answering the user or building assumptions based solely on information in memory records, verify that the memory is still correct and up-to-date by reading the current state of the files or resources. If a recalled memory conflicts with current information, trust what you observe now — and update or remove the stale memory rather than acting on it.
-
-## Before recommending from memory
-
-A memory that names a specific function, file, or flag is a claim that it existed *when the memory was written*. It may have been renamed, removed, or never merged. Before recommending it:
-
- If the memory names a file path: check the file exists.
- If the memory names a function or flag: grep for it.
- If the user is about to act on your recommendation (not just asking about history), verify first.
-
-"The memory says X exists" is not the same as "X exists now."
-
-A memory that summarizes repo state (activity logs, architecture snapshots) is frozen in time. If the user asks about *recent* or *current* state, prefer `git log` or reading the code over recalling the snapshot.
-
-## Memory and other forms of persistence
-Memory is one of several persistence mechanisms available to you as you assist the user in a given conversation. The distinction is often that memory can be recalled in future conversations and should not be used for persisting information that is only useful within the scope of the current conversation.
- When to use or update a plan instead of memory: If you are about to start a non-trivial implementation task and would like to reach alignment with the user on your approach you should use a Plan rather than saving this information to memory. Similarly, if you already have a plan within the conversation and you have changed your approach persist that change by updating the plan rather than saving a memory.
- When to use or update tasks instead of memory: When you need to break your work into discrete steps or keep track of your progress use tasks instead of saving to memory. Tasks are great for persisting information about the work that needs to be done in the current conversation, but memory should be reserved for information that will be useful in future conversations.
-
- Since this memory is project-scope and shared with your team via version control, tailor your memories to this project