docs(workflow): 建立问题管理三段式工作流与经验知识库

- 新增 problem-solving skill：固化「问题分析→工作记录→知识沉淀」9步流程与3模板
- 新建 docs/knowledge/ 经验知识库（README/INDEX/临时方案登记/坑-UE5引擎含2条迁移示例）
- GIT-GUIDE 补 §2.7 临时代码 [TEMP-INVESTIGATE] 约定、§2.8 fix 提交引用 issue
- CLAUDE.md 项目管理段加问题管理引用
- 配套 Gitea 标签 type:bug / type:investigation（后台已建）

.claude/agent-memory/game-reviewer/MEMORY.md

@@ -1,4 +0,0 @@
-# game-reviewer 记忆索引
-
-- [Gitea Token Permission](gitea-token-permission.md) — reviewer token 为空，所有操作使用 PM role
-- [P-012 Review](p012-review-note.md) — Issue #32 交互系统程序实现二次审查未通过记录

.claude/agent-memory/game-reviewer/gitea-token-permission.md

@@ -1,12 +0,0 @@
----
-name: gitea-token-permission
-description: reviewer token 权限限制——仅可评论，标签操作需用 PM token
-metadata:
-  type: feedback
----
-
-reviewer token 为空字符串，无法执行任何 API 操作（评论、标签均不可）。PM token 可执行全部操作。
-
-**Why:** gitea-config.json 中 reviewer 角色未配置 token（token 字段为空字符串）。
-
-**How to apply:** 所有 Gitea API 操作（评论、标签更新）均使用 PM 角色执行：`node .claude/skills/gitea-collab/gitea.js --role pm issue comment/labels <number>`。评论内容仍以"审查 Agent (ai-reviewer)"署名。

.claude/agent-memory/game-reviewer/p012-review-note.md

@@ -1,16 +0,0 @@
----
-name: p012-review-note
-description: Issue #32 交互系统程序实现审查——二次审查未通过记录
-metadata:
-  type: project
----
-
-Issue #32 (P-012 交互系统程序实现) 二次审查未通过。首次审查发现 2 个重大问题 + 5 个中等问题。程序提交修改汇报后，二次审查发现修改汇报声称的修复并未在代码中体现，4 个问题实际未修复：
-1. SetInteracting(true) 双调用（InteractionManager 反射 + Character 直接调用）——运行时 Bug
-2. DoorActor::OnInteractStarted_Implementation 仍调用 ToggleDoor ——代码残留
-3. ExecuteCameraReturn 未清空 CachedPushCamera ——冗余回位
-4. AddToBackpack 缺 TODO 注释
-
-**Why:** 程序修改汇报与实际代码变更不一致，可能修改未提交或修改了错误文件。
-
-**How to apply:** 后续审查此 Issue 时，重点关注以上 4 个代码位置的修复状态，并验证修改汇报与实际代码变更一致。

.claude/refs/GIT-GUIDE-LITE.md

@@ -1,139 +0,0 @@
-# Git 快速参考（AI 用）
-
-> 从 [GIT-GUIDE.md](GIT-GUIDE.md) 精简。完整规范见原文。
-
----
-
-## 分支策略
-
-**develop 长期开发分支模型** — 单人开发 + 多 Agent 协作。
-
-```
-main ─────────── 永远可玩可编译，受保护，禁止直接推送
-  │
-  │   PR (Gitea)     ← 里程碑/迭代结束时，PM 发起
-  │
-  └── develop ──── 长期分支，所有 agent 在此工作
-```
-
-| 分支 | 生命期 | 说明 |
-|---|---|---|
-| `main` | 永久 | 稳定版本，受保护 |
-| `develop` | 永久 | 日常开发分支，所有 agent 共用 |
-
-**辅助分支（可选，用于实验）：**
-
-| 分支 | 前缀 | 生命期 | 说明 |
-|---|---|---|---|
-| 原型 | `prototype/` | 实验完即删 | 技术验证，随便写 |
-| 发布 | `release/` | 永久 | 从 main 切出，版本标记 |
-
-**流程：**
-1. 所有开发在 `develop` 上进行 → 2. 迭代完成时创建 PR → 3. 审查通过后合并回 `main`
-
----
-
-## 提交规范
-
-**格式：** `<type>(<scope>): <中文描述>`
-
-- subject ≤ 50 字符，中文描述，技术术语保留英文
-- body 可选，每行 ≤ 72 字符
-
-**Type（必选）：**
-
-| Type | 用途 |
-|---|---|
-| `feat` | 新功能 |
-| `fix` | Bug 修复 |
-| `art` | 美术资源 |
-| `level` | 关卡/场景 |
-| `audio` | 音效/音乐 |
-| `bp` | 蓝图逻辑 |
-| `refactor` | 重构（不改功能） |
-| `config` | 项目/引擎配置 |
-| `docs` | 文档 |
-| `wip` | 进行中（未完成） |
-
-**Scope（可选，常用）：**
-`player` `enemy` `combat` `ui` `camera` `inventory` `dialogue` `quest` `save` `audio` `animation` `ai` `level` `vfx`
-
-**示例：**
-```
-feat(player): 实现角色跳跃和二段跳
-fix(camera): 修复穿墙时摄像机卡顿问题
-bp(enemy): 实现巡逻-追击-攻击状态机
-wip(crafting): 合成系统UI初步框架
-config: 启用Nanite和Lumen
-```
-
----
-
-## UE5 注意事项
-
-- 蓝图与 C++ 分开提交
-- `.uasset` / `.umap` 无法 diff → commit message 必须写清改了什么
-- 不提交 `Binaries/` `Intermediate/` `Saved/` `.vs/`
-
----
-
-## 版本号
-
-`v主版本.次版本.修订号` — 主版本=里程碑，次版本=新系统，修订号=小修
-
----
-
-## 远程仓库
-
-**SSH 地址**：`ssh://sc-gitea@micecola.top:2223/starmen1265/ChildHood.git`
-
-> ⚠️ 用户名是 `sc-gitea`（非默认 `git`），端口是 `2223`（非默认 22）
-
-**切换远程地址**：
-```bash
-git remote set-url origin ssh://sc-gitea@micecola.top:2223/starmen1265/ChildHood.git
-```
-
-**SSH config**（`~/.ssh/config`）：
-```
-Host gitea micecola.top
-    HostName micecola.top
-    Port 2223
-    User sc-gitea
-    IdentityFile ~/.ssh/id_ed25519_gitea
-    IdentitiesOnly yes
-```
-
-**内网地址**（家里用）：`ssh://sc-gitea@192.168.1.22:2223/starmen1265/ChildHood.git`
-
-完整规范见 → [GIT-GUIDE.md](GIT-GUIDE.md)
-
----
-
-## 自动化工作流
-
-`git-workflow.sh` 脚本封装了常用 git 操作：
-
-```bash
-# 开始工作：确保在 develop 上且最新
-bash .claude/scripts/git-workflow.sh ready
-
-# 提交修改
-bash .claude/scripts/git-workflow.sh commit <type> <scope> "中文描述"
-
-# 推送到远程
-bash .claude/scripts/git-workflow.sh push
-
-# 查看状态
-bash .claude/scripts/git-workflow.sh status
-```
-
-### PM 发布流程
-
-```bash
-# 创建 develop → main PR
-bash .claude/scripts/git-workflow.sh release "迭代名称"
-
-# 用户在 Gitea 合并后同步
-bash .claude/scripts/git-workflow.sh post-release
-```

.claude/refs/development-workflow.md

@@ -1,285 +0,0 @@
-# 游戏开发工作流
-
-> 本文档定义游戏项目的开发阶段、任务管理、角色职责、产出标准和质量检查规则。
-> 项目采用 3 阶段开发模型：草图 → 总路线 → 迭代。每个阶段有独立的技能文件管理任务序列。
->
-> 项目管理工具当前使用 Gitea。PM 操作详见 `gitea-pm` 技能，通用协作详见 `gitea-collab` 技能。
-> 阶段技能文件：
-> - `.claude/skills/project-initializer.md` — 项目初始化
-> - `.claude/skills/stage-sketch.md` — 草图阶段
-> - `.claude/skills/stage-roadmap.md` — 总路线阶段
-> - `.claude/skills/stage-iteration.md` — 迭代阶段
-
----
-
-## 角色定义
-
-| 角色 | 职责 | 产出位置 | PM 如何判断其进度 |
-|------|------|----------|-------------------|
-| **策划** (Design) | 玩法设计、数值平衡、叙事、系统机制 | `docs/design/`、`GameConfig/` | 扫描 `docs/design/` 和 `GameConfig/` 目录中的文件 |
-| **程序** (Dev) | 系统实现、技术架构、Bug 修复 | `Source/`、`Content/`、`docs/technical/` | 扫描对应目录中的文件 |
-| **美术** (Art) | 美术需求分析、资产规格、风格指南 | `docs/art/`、`Content/` | 扫描对应目录中的文件 |
-| **PM** | 进度管理（3阶段状态机）、任务分配与追踪、开发决策咨询 | **Gitea Issues + Milestones** | 通过 Gitea 读取任务和里程碑 |
-| **审查** (Reviewer) | 审查交付物质量、更新 Issue 标签和评论 | Issue 评论 | 通过 `review:pass/fail` 标签 |
-
-### 协作规则
-
-- **策划先行**：设计文档是其他角色的需求源
-- **程序读设计**：实现前必须先读取对应设计文档和配置表
-- **文档即交接**：Agent 之间不直接通信，通过共享文档目录 + 任务 Issue 评论交接（参见 `gitea-collab` 技能）
-- **冲突时用户说了算**：玩法/数值/叙事的最终决定权在用户
-- **PM 是进度调度器**：PM 管理进度和任务分配，不做审查
-- **审查是子代理**：角色完成工作后启动 game-reviewer 子代理审查，审查结果返回给角色，角色向用户汇报
-- **会话启动先调 PM**：每次工作会话开始时，用户先调 PM 执行进度检查，确认当前状态后再进入具体工作
-- **用户驱动角色切换**：角色间的工作切换由用户手动触发，PM 不自动指派任务
-- **角色任务汇报**：各角色通过项目管理工具在任务 Issue 下评论汇报进度，PM 据此追踪
-
-### 进度汇报规则
-
-- 进度管理唯一真实来源是 **项目管理工具**（当前为 Gitea Issues + Milestones）。具体操作参见 `gitea-pm` / `gitea-collab` 技能
-- 各角色完成工作后在对应 Issue 下评论汇报，不更新本地 report 文件
-- PM 通过项目管理工具读取任务和评论，给出行动建议
-- 角色完成工作后自行启动 game-reviewer 子代理审查，审查通过后 PM 请示用户关闭 Issue
-- 任务追踪使用唯一任务 ID（格式：`[角色前缀]-[三位数字]`），对应 Issue 标题前缀
-- 审查结果通过 Issue 评论发布
-
----
-
-## 开发阶段
-
-项目开发分为三个阶段，每个阶段有独立的技能文件管理任务序列。
-
-```
-草图阶段 ─── "这个游戏是什么？能不能做？" ─── 概念设计 + 技术可行性
-    ↓
-总路线阶段 ─── "全面设计蓝图" ─── 9 份设计文档 + 版本路径图
-    ↓
-迭代阶段 ─── "按版本迭代开发" ─── 插件准备 → 执行案 → 开发 → 整合 → 修复
-    ↑                                              ↓
-    └──── 迭代完成，有下一个迭代 ←── 迭代完成 ───────┘
-```
-
-**阶段转换由 PM 建议但需用户确认**。阶段技能文件定义了每个阶段的任务序列和转换条件。
-
----
-
-### 草图阶段
-
-**目的**：确定游戏是什么——玩法方向、美术风格、技术可行性。
-
-**关注问题**：这个游戏是什么？为什么要做？做不做得了？
-
-#### 任务序列（2 个任务）
-
-1. **概念设计** (D-XXX) — 策划产出概念草案
-2. **技术可行性评估** (P-XXX) — 程序评估技术可行性（依赖概念设计完成）
-
-#### 完成标志
-
-两个任务都关闭 + 草图阶段里程碑下无 open issues → 进入总路线阶段。
-
-#### 详细任务定义
-
-参见 `.claude/skills/stage-sketch.md`。
-
----
-
-### 总路线阶段
-
-**目的**：建立完整的游戏设计蓝图，规划版本迭代路径。
-
-**关注问题**：游戏长什么样？有哪些系统？分几个版本做？
-
-#### 任务序列（9 个任务）
-
-1. **设计总索引** (D-XXX) — 必须完整
-2. **世界观设计** (D-XXX) — 允许占位
-3. **剧情设计** (D-XXX) — 允许占位
-4. **角色设计** (D-XXX) — 允许占位
-5. **系统设计** (D-XXX) — ⚠️ 必须完整
-6. **关卡设计** (D-XXX) — ⚠️ 必须完整
-7. **UI 设计** (D-XXX) — 允许占位
-8. **音频设计** (D-XXX) — 允许占位
-9. **版本路径图** (D-XXX) — 必须完整（依赖 2-8）
-
-**占位规则**：除系统设计和关卡设计外，其他文档允许空文件占位（标题+章节+「待填充」），后续迭代完善。
-
-#### 完成标志
-
-所有任务关闭 + 里程碑下无 open issues → 进入迭代阶段。
-
-#### 详细任务定义
-
-参见 `.claude/skills/stage-roadmap.md`。
-
----
-
-### 迭代阶段
-
-**目的**：按版本迭代推进开发，每个迭代完成一个可玩版本。
-
-**关注问题**：这个版本做什么？做到什么程度？Bug 修了没？
-
-#### 任务序列（每迭代 6-9 个任务）
-
-| 任务 | 角色 | 说明 |
-|------|------|------|
-| 插件资产检查与准备 | 程序 | 仅首次迭代 |
-| 设计案迭代补充 | 策划 | 可选 |
-| 策划执行案 | 策划 | 必选 |
-| 程序需求分析 | 程序 | 必选 |
-| 关卡搭建 | 程序 | 有场景时 |
-| 系统开发 | 程序 | 必选 |
-| 优化意见 | 程序 | 必选 |
-| 资产接入整合 | 程序 | 必选 |
-| Bug 修复 | 程序 | 必选 |
-
-**关键规则**：PM 每次激活时只创建下一个可创建的任务，不要一次全部创建。
-
-#### 迭代完成
-
-Bug 修复关闭 → 询问用户是否有下一个迭代：
-- **有** → 关闭当前里程碑 → 创建下一个迭代里程碑 → 继续
-- **没有** → 返回总路线阶段
-
-#### 详细任务定义
-
-参见 `.claude/skills/stage-iteration.md`。
-
----
-
-## 设计文档层级关系
-
-草案、设计案、执行案三者的关系：
-
-| 层级 | 定位 | 比喻 | 特点 |
-|------|------|------|------|
-| **草案** (概念草案.md) | 给游戏**定调** | 灵魂 | 回答"这个游戏是什么"，简略但方向明确 |
-| **设计案** | 给游戏**定骨架** | 骨架 | 基于草案的原则展开系统设计，定义有哪些系统、系统关系、核心行为 |
-| **执行案** | 给游戏**填血肉** | 血肉 | 细化到程序可直接实现的交互规则和行为细节 |
-
-设计案初始基于草案的原则进行设计。在后续迭代中遇到具体问题时，可以灵活调整或替换草案中的元素——草案是方向指引，不是硬性约束。
-
----
-
-## 执行案规范
-
-### 执行案格式
-
-每个执行案文件顶部必须包含**迭代记录表头**：
-
-```markdown
-# <系统名>执行案
-
-## 迭代记录
-
-| 迭代版本 | 修改日期 | 状态 | 说明 |
-|----------|----------|------|------|
-| v0.1 | 2026-06-10 | 📝 设计中 | 初始版本 |
-
-> 状态标记：📝 设计中 | 🔄 开发中 | ✅ 已同步
-
----
-
-## 系统概述
-（描述该系统做什么、服务于什么体验目标）
-
-## 行为规则
-（当前最新状态的所有行为规则）
-```
-
-### 执行案必须包含
-
-1. **系统概述**：这个系统做什么、服务于什么体验目标
-2. **完整的行为规则清单**：每个操作的触发条件、触发后表现、结束条件
-3. **状态和状态转换**：系统有哪些状态、什么条件触发状态变化
-4. **边界情况处理**：异常/极端情况下的系统行为
-5. **与其他系统的交互**：本系统与其他系统的关联和影响
-
-### 执行案不应包含
-
-- 用什么引擎组件实现
-- 代码/脚本架构怎么组织
-- 数据用什么格式存储
-- 具体的参数精确值（调优参数标注"建议值，可调"）
-
-### 关卡执行案
-
-- 当版本开发涉及场景搭建时，策划额外产出一份关卡执行案
-- 关卡执行案将场景设计案的氛围描述转化为空间精度搭建指南（坐标、尺寸、BSP 资产映射）
-- 使用混合坐标体系：区域用场景绝对坐标，区域内物件用相对偏移坐标
-- 交互物和收集品的位置标注必须与交互系统/收集系统执行案交叉引用
-- 完整规范参见 `.claude/refs/level-execution-template.md`
-
----
-
-## 审查流程
-
-> 审查由 **game-reviewer 子代理**执行，不再由 PM 执行。
-> 角色完成工作后自行启动 reviewer 子代理。
-
-### 审查触发
-
-角色完成工作 → 在 Issue 下评论汇报 → 改标签为 `status:in-review` → 启动 game-reviewer 子代理
-
-### 审查标准
-
-审查标准定义在 `.claude/skills/quality-gate-review.md`，包含 4 道质量门：
-1. 执行案质量门 — 完整性、清晰性、边界情况、系统关联、技术越界
-2. 程序设计质量门 — 执行案覆盖度、美术需求、架构、数据流、风险、工作量
-3. 美术资产验收门 — 需求覆盖、资产到位、规格、缺失处理
-4. 程序实现验收门 — 设计一致性、覆盖度、资产使用、偏差处理
-
-### 审查结果
-
-- **通过** → reviewer 更新标签为 `review:pass` → 角色向用户汇报 → 用户决定是否关闭
-- **未通过** → reviewer 更新标签为 `review:fail` + `status:blocked` → 角色向用户汇报 → 修改后重新提交
-
----
-
-## 审查质量标准
-
-> 以下标准供 game-reviewer 子代理使用。详细标准定义在 `.claude/skills/quality-gate-review.md`。
-
-### 执行案质量标准
-
-- [ ] 是否覆盖了该系统所有玩家可感知的行为？
-- [ ] 每个操作是否明确了触发条件、触发后表现、结束条件？
-- [ ] 边界情况是否都处理了？
-- [ ] 与其他系统的关联是否说明？
-- [ ] 是否有模糊地带？行为描述是否无歧义？
-- [ ] 是否误入了技术细节？参数值是否标注为"建议值，可调"？
-- [ ] 迭代记录表头是否存在且填写完整？
-
-### 程序设计质量标准
-
-- [ ] 是否完整回应了执行案中的每条行为规则？（逐条对照）
-- [ ] 美术资源需求是否列得具体（尺寸、数量、触发时机）？
-- [ ] 类与组件架构是否清晰？
-- [ ] 数据流是否明确？
-- [ ] 技术风险是否识别？
-- [ ] 工作量估算是否给出？实现拆分建议是否合理且可操作？
-
-### 美术资产验收标准
-
-- [ ] 资源需求清单中的每一项是否都有对应的美术产出？（逐项对照）
-- [ ] 资产文件是否已放置在对应目录？
-- [ ] 资产规格是否符合需求？
-- [ ] 未到位资产是否有明确的处理方案？
-
-### 程序实现验收标准
-
-- [ ] 实现是否与程序设计方案一致？（逐条对照）
-- [ ] 最终实现是否完整覆盖了执行案中的所有行为规则？
-- [ ] 美术资产是否已正确集成并使用？
-- [ ] 偏差清单是否已梳理清楚？重大偏差是否有处理方案？
-
----
-
-## 单人独立开发的特殊考量
-
-- **无法并行**——同一时间只能做一件事，选择更关键
-- **精力有限**——避免一次性拆分太多并行任务
-- **心流重要**——建议按「完整做完一个小系统」而非「同时推进多个系统」的方式工作
-- **早期验证**——越早能跑起来看到东西，越不容易失去动力
-- **文档交接**——Agent 之间通过文档交接，PM 是进度调度器，reviewer 负责质量把关

.claude/refs/进度管理流程修改方案.md

@@ -1,248 +0,0 @@
-ChildHood 项目当前使用本地 Markdown 文件（docs/plans/current.md、reports/、reviews/、archive/）进行进度管理。用户已在 Gitea 上搭建了 Issue/Milestone/看板基础设施（3 个 Issue、1 个 Milestone、1
-     个看板），并希望将进度管理完全迁移到 Gitea，不再保留本地降级模式。
-
-     核心目标：Gitea 成为唯一的进度管理真实来源，获得可视化看板、Web 面板随时查看、更结构化的任务管理体验。
-
-     ---
-     一、结论：可行，但有前提条件
-
-     迁移可行，Gitea API 能覆盖当前进度管理 80%+ 的需求。但有两个前提条件必须先解决：
-
-     1. UTF-8 编码问题：现有 3 个 Issue 的中文全部乱码，说明之前通过 API 创建时编码处理有误。这是阻塞性问题，必须在迁移前解决。
-     2. API Token 写权限验证：ai-pm 账号的 Token 需要验证对 Issue/Milestone/Label/Comment 的写操作权限。
-
-     ---
-     二、本地概念 → Gitea 映射设计
-
-     任务 (P-002)          → Issue（标题含任务ID前缀，如 "P-002 v0.1 执行案"）
-     版本 (v0.1)           → Milestone（如 "v0.1-基础交互"）
-     任务完成 [x]          → Issue 关闭 (state=closed)
-     任务状态              → Label（status:backlog / in-progress / blocked / in-review / done）
-     流水线步骤            → Label（pipeline:3-execution / 4-tech-design / ...）
-     角色归属              → Label（role:design / dev / art / pm）+ assignee
-     质量门判定            → Label（gate:execution-pass/fail / tech-pass/fail / ...）
-     角色汇报              → Issue 评论
-     审查记录              → Issue 评论（摘要+链接）+ 本地文件（详细内容保留）
-     任务依赖              → Issue Dependencies API
-     流水线总览            → Meta Issue（body 中维护流水线进度表）
-
-     需要创建的 Label 体系（共约 20 个）
-
-     ┌──────────────┬─────────────────────────────────────────────────────────────────────────────────────────────┬────────────────────┐
-     │     类别     │                                           Labels                                            │        用途        │
-     ├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────┼────────────────────┤
-     │ status (6)   │ status:backlog status:ready status:in-progress status:blocked status:in-review status:done  │ 任务生命周期状态   │
-     ├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────┼────────────────────┤
-     │ pipeline (5) │ pipeline:3-execution pipeline:4-tech-design pipeline:5-art pipeline:6-impl pipeline:7-retro │ 当前在流水线哪一步 │
-     ├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────┼────────────────────┤
-     │ role (4)     │ role:design role:dev role:art role:pm                                                       │ 归属角色           │
-     ├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────┼────────────────────┤
-     │ gate (8)     │ gate:execution-pass/fail gate:tech-pass/fail gate:art-pass/fail gate:impl-pass/fail         │ 质量门审查结果     │
-     └──────────────┴─────────────────────────────────────────────────────────────────────────────────────────────┴────────────────────┘
-
-     本地文件处理策略
-
-     ┌──────────────────────┬────────────────────┬─────────────────────────────────────────────────────────────────────┐
-     │         文件         │        策略        │                                原因                                 │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ current.md           │ 废弃               │ 流水线进度迁移到 Pipeline Tracker Meta Issue；任务列表迁移到 Issues │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ reports/*.md         │ 废弃               │ 角色汇报迁移到 Issue 评论                                           │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ reviews/*.md         │ 保留本地           │ 审查记录是结构化文档，内容复杂；Issue 评论中放结论摘要+文件链接     │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ archive/             │ 冻结现有，不再新增 │ closed Issues = 归档，通过 Milestone 过滤查看历史                   │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ prototype-roadmap.md │ 保留本地           │ 信息量太大（4版本×多维度），不适合放 Milestone description          │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ roadmap.md           │ 保留本地           │ 全局路线图，不迁移                                                  │
-     ├──────────────────────┼────────────────────┼─────────────────────────────────────────────────────────────────────┤
-     │ work-log.md          │ 保留本地           │ 粒度不匹配 Gitea time tracker                                       │
-     └──────────────────────┴────────────────────┴─────────────────────────────────────────────────────────────────────┘
-
-     ---
-     三、需验证的 API 接口（按优先级）
-
-     P0 — 阻塞性验证（迁移前必须通过）
-
-     ┌─────┬───────────────────────────────────┬────────────────────────────────────────────┬─────────────────────────┬────────────────────┐
-     │  #  │               操作                │                    端点                    │        验证内容         │      管理场景      │
-     ├─────┼───────────────────────────────────┼────────────────────────────────────────────┼─────────────────────────┼────────────────────┤
-     │ 1   │ 创建含中文的 Issue                │ POST /repos/{owner}/{repo}/issues          │ UTF-8 编码正确显示      │ 创建任何任务       │
-     ├─────┼───────────────────────────────────┼────────────────────────────────────────────┼─────────────────────────┼────────────────────┤
-     │ 2   │ 创建含中文的评论                  │ POST /repos/{index}/comments               │ UTF-8 编码正确显示      │ 角色汇报、审查结论 │
-     ├─────┼───────────────────────────────────┼────────────────────────────────────────────┼─────────────────────────┼────────────────────┤
-     │ 3   │ 创建 Label                        │ POST /repos/{owner}/{repo}/labels          │ 含中文名的 Label 能创建 │ 初始化标签体系     │
-     ├─────┼───────────────────────────────────┼────────────────────────────────────────────┼─────────────────────────┼────────────────────┤
-     │ 4   │ 给 Issue 添加/移除 Label          │ POST/DELETE /issues/{index}/labels         │ Label 正确关联          │ 状态变更           │
-     ├─────┼───────────────────────────────────┼────────────────────────────────────────────┼─────────────────────────┼────────────────────┤
-     │ 5   │ 更新 Issue（状态/标题/body/指派） │ PATCH /repos/{owner}/{repo}/issues/{index} │ 所有字段正确更新        │ 任务状态推进       │
-     ├─────┼───────────────────────────────────┼────────────────────────────────────────────┼─────────────────────────┼────────────────────┤
-     │ 6   │ 关闭/重开 Issue                   │ PATCH ... state=closed/open                │ 状态切换正确            │ 任务完成/回退      │
-     └─────┴───────────────────────────────────┴────────────────────────────────────────────┴─────────────────────────┴────────────────────┘
-
-     P1 — 核心功能验证
-
-     ┌─────┬──────────────────────────────────┬────────────────────────────────────────────┬──────────────────┬──────────────────┐
-     │  #  │               操作               │                    端点                    │     验证内容     │     管理场景     │
-     ├─────┼──────────────────────────────────┼────────────────────────────────────────────┼──────────────────┼──────────────────┤
-     │ 7   │ 读取 Issue 列表（含过滤）        │ GET /issues?state=open&labels=&milestones= │ 过滤参数生效     │ PM 会话启动      │
-     ├─────┼──────────────────────────────────┼────────────────────────────────────────────┼──────────────────┼──────────────────┤
-     │ 8   │ 读取 Issue 评论列表              │ GET /issues/{index}/comments               │ 返回完整评论历史 │ PM 读取角色汇报  │
-     ├─────┼──────────────────────────────────┼────────────────────────────────────────────┼──────────────────┼──────────────────┤
-     │ 9   │ Issue 依赖关系（添加/读取/删除） │ POST/GET/DELETE /issues/{index}/blocks     │ 依赖链正确建立   │ P-003 依赖 P-002 │
-     ├─────┼──────────────────────────────────┼────────────────────────────────────────────┼──────────────────┼──────────────────┤
-     │ 10  │ 创建/更新 Milestone              │ POST/PATCH /milestones                     │ 新版本创建       │ 版本管理         │
-     └─────┴──────────────────────────────────┴────────────────────────────────────────────┴──────────────────┴──────────────────┘
-
-     P2 — 可选验证
-
-     ┌─────┬────────────┬──────────────────────────────────────┬────────────────────────────┐
-     │  #  │    操作    │                 端点                 │            说明            │
-     ├─────┼────────────┼──────────────────────────────────────┼────────────────────────────┤
-     │ 11  │ 时间追踪   │ POST /issues/{index}/stopwatch/start │ 替代 work-log.md，优先级低 │
-     ├─────┼────────────┼──────────────────────────────────────┼────────────────────────────┤
-     │ 12  │ Issue 搜索 │ GET /repos/issues/search             │ 跨仓库搜索，可能用不到     │
-     └─────┴────────────┴──────────────────────────────────────┴────────────────────────────┘
-
-     ---
-     四、新流程设计
-
-     4.1 PM 会话启动追踪（核心变化）
-
-     旧：读 current.md → 读 reports/*.md → 汇报
-
-     新：
-     1. GET /milestones → 确认当前版本 Milestone
-     2. GET /issues?state=open&milestones={当前版本ID} → 获取当前版本所有活跃任务
-     3. 读取 Pipeline Tracker Meta Issue body → 了解流水线位置
-     4. 读取各 Issue 的 Labels → 理解每个任务状态/角色/质量门
-     5. 读取相关 Issue 评论 → 了解角色最新汇报
-     6. 读本地 reviews/ 最新审查记录（如有）
-     7. 向用户汇报 + 建议
-
-     4.2 角色汇报进度
-
-     旧：更新 docs/plans/reports/<role>-report.md
-
-     新：在对应 Issue 下评论
-
-     ## 策划汇报 — 2026-06-06
-
-     **任务ID**: P-002a
-     **状态**: 已完成
-     **产出**: `docs/design/prototype/interaction-system-execution.md`
-
-     ### 完成内容
-     - 创建独立执行案文件
-     - 移除技术越界内容
-     - 补充 4 个边界情况
-
-     ### 待确认
-     - 交互取消行为链是否满足需求
-
-     4.3 质量门审查
-
-     旧：审查 → 写 reviews/<ID>-review.md → 更新 current.md
-
-     新：
-     1. PM 执行审查（仍读本地文件内容逐条检查）
-     2. 写本地 reviews/<ID>-review.md（详细记录保留本地）
-     3. 在对应 Issue 下发审查结论评论（摘要 + 文件链接）
-     4. 通过 API 更新 Issue Labels：移除 status:in-review，添加 status:blocked + gate:execution-fail（不通过时）
-     5. 更新 Pipeline Tracker Meta Issue body 中的进度表
-
-     4.4 任务归档
-
-     旧：current.md 中 [x] → 移到 archive/ 文件
-
-     新：用户确认完成 → PATCH /issues/{index} state=closed → 发完成评论（日期+产出链接）→ 不再需要 archive/ 文件
-
-     4.5 新任务创建
-
-     旧：在 current.md 中添加 - [ ] P-XXX ...
-
-     新：
-     1. POST /issues 创建 Issue（标题含任务ID、body 含模板信息、关联 Milestone、打上初始 Labels）
-     2. 如有依赖 → POST /issues/{index}/blocks 设置依赖关系
-     3. PM 更新 Pipeline Tracker Meta Issue body
-
-     ---
-     五、实施步骤
-
-     步骤 1：API 验证脚本
-
-     编写 scripts/gitea-api.py 封装所有 API 操作，解决 UTF-8 编码问题。Agent 通过 python scripts/gitea-api.py <command> <args> 调用，而非裸 curl/python 内联。
-
-     验证所有 P0 + P1 接口。同时修复现有 3 个乱码 Issue（重建或更新内容）。
-
-     步骤 2：Label 体系初始化
-
-     通过脚本创建全部约 20 个 Labels。为现有 3 个 Issue 打上正确 Labels。
-
-     步骤 3：创建 Pipeline Tracker Meta Issue
-
-     将 current.md 中的流水线进度表迁移到一个 Meta Issue 的 body 中。
-
-     步骤 4：修改 PM Agent 的 system prompt
-
-     修改 .claude/agents/game-pm.md：
-     - 会话启动：从 Gitea API 读取进度（替代读 current.md + reports/）
-     - 质量门审查：审查后更新 Issue Labels + 评论
-     - 任务创建/归档：通过 API 创建/关闭 Issue
-     - 不再维护 current.md
-
-     步骤 5：修改策划/程序 Agent 的 system prompt
-
-     修改 .claude/agents/game-designer.md 和 .claude/agents/game-dev.md：
-     - 完成工作后在对应 Issue 下评论汇报（替代更新 reports/ 文件）
-
-     步骤 6：验证与稳定
-
-     用 PM Agent 按新流程完成一次完整工作会话，确认 API 调用链路稳定、数据准确。
-
-     ---
-     六、风险与缓解
-
-     ┌────────────────────────────┬──────┬──────────────────────────────────────────────────┐
-     │            风险            │ 等级 │                     缓解措施                     │
-     ├────────────────────────────┼──────┼──────────────────────────────────────────────────┤
-     │ 网络不可用导致 PM 无法工作 │ 中   │ 接受此风险——Gitea 是自建服务，可用性由用户掌控   │
-     ├────────────────────────────┼──────┼──────────────────────────────────────────────────┤
-     │ UTF-8 编码问题重现         │ 高   │ 封装 Python 脚本统一处理编码，ensure_ascii=False │
-     ├────────────────────────────┼──────┼──────────────────────────────────────────────────┤
-     │ 看板列位置不可 API 操作    │ 低   │ 用 Labels 替代看板列概念；用户手动拖拽（频率低） │
-     ├────────────────────────────┼──────┼──────────────────────────────────────────────────┤
-     │ Agent 调用 API 出错        │ 中   │ 封装脚本统一错误处理和重试；API 调用前本地记录   │
-     └────────────────────────────┴──────┴──────────────────────────────────────────────────┘
-
-     ---
-     七、关键修改文件清单
-
-     ┌──────────────────────────────────────┬───────────────────────────────────────────────────────────┐
-     │                 文件                 │                         修改内容                          │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ scripts/gitea-api.py                 │ 新建 — API 封装脚本，解决编码和错误处理                   │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ .claude/agents/game-pm.md            │ 大幅修改 — PM 的进度读取/质量门/任务管理全部改为 API 调用 │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ .claude/agents/game-designer.md      │ 中等修改 — 汇报方式从写文件改为 Issue 评论                │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ .claude/agents/game-dev.md           │ 中等修改 — 同上                                           │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ .claude/refs/development-workflow.md │ 小改 — 协作规则中更新进度汇报方式描述                     │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ docs/plans/current.md                │ 废弃 — 不再维护                                           │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ docs/plans/reports/*.md              │ 废弃 — 不再维护                                           │
-     ├──────────────────────────────────────┼───────────────────────────────────────────────────────────┤
-     │ docs/technical/gitea-api-guide.md    │ 更新 — 补充新验证的 API 端点和脚本用法                    │
-     └──────────────────────────────────────┴───────────────────────────────────────────────────────────┘
-
-     ---
-     八、验证方式
-
-     1. API 验证：用 ai-pm Token 依次执行 P0 全部 6 项操作，确认中文显示正确、写权限可用
-     2. Label 创建：创建全部 Labels 并在 Web 面板确认显示正确
-     3. 端到端测试：PM Agent 用新流程完成一次完整的工作会话启动追踪，确认 API 调用链路正确
-     4. 质量门测试：PM 对一个 Issue 执行质量门审查，确认 Labels 更新和评论发布正确

.claude/skills/floorplan-recognizer/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: "floorplan-recognizer"
+description: >
+  户型图识别工具。当需要"识别户型图"、"解析户型"、"提取户型信息"、"看户型有哪些房间/窗户"、
+  "floor plan recognition"、"户型图推导输入"时使用。用 qwen-vl-max 把链家等房产户型图解析成
+  结构化 JSON（房间/朝向/窗户形态），并生成「路径 B 文字钉死」片段，作为居民楼立面推导的可靠输入。
+---
+
+# 户型图识别工具 (Floorplan Recognizer)
+
+> 户型图图片 → qwen-vl-max 解析 → 结构化 JSON + 「路径 B 文字钉死」片段
+
+## 为什么需要它
+
+AI 生图模型（GPT-Image-2）独立读户型图不可靠——会用"住宅常识"脑补（默认卧室大窗、阳台落地窗、漏房间），
+导致路径 B「户型图推导」每张图都要**人工逐项校验窗户形态与比例**（见 `docs/art/美术风格指南.md` 路径 B 劣势）。
+
+本工具先用专门的视觉大模型 qwen-vl-max 把户型图**解析成结构化清单**，把"人工逐项校验"降级为
+"AI 出清单 + 人工快速核对"。
+
+> 评测结论（详见 `ai-art-research/生成结果/户型图识别评测/评测对比.md`）：qwen-vl-max 在房间完整性、
+> 面积 OCR 精度、备注诚实度上领先 gpt-4o / qwen-vl-plus / gpt-4o-mini。
+
+## 触发条件
+
+- 用户说"识别/解析这张户型图"、"提取户型信息"、"看看这个户型有哪些房间/窗户"
+- 路径 B 户型图推导前，需要可靠的「房间 + 窗户形态」清单作为"文字钉死"依据
+- 用户提供了一张链家/房产户型图要求分析
+
+## 工具位置
+
+```
+ai-art-research/tools/
+  floorplan_parse.py    # 生产版（固定 qwen-vl-max，生成文字钉死片段）⭐ 本技能用这个
+  floorplan_eval.py     # 评测版（可换模型对比）
+```
+
+依赖 `ai-art-research/.env` 的 `APIYI_API_KEY`（与 `image_gen.py` 共用）。
+
+## 工作流
+
+### 步骤 1：解析户型图
+
+```bash
+cd ai-art-research
+python tools/floorplan_parse.py --image <户型图路径>
+```
+
+产出（存 `生成结果/户型图识别/`）：
+- `<时间戳>_apiyi_qwen-vl-max.json` — 结构化结果（房间/朝向/窗户/立面对应表）
+- `<时间戳>_apiyi_qwen-vl-max.钉死.md` — 「路径 B 文字钉死」片段（可直接粘进生图 prompt）
+- `.meta.json` — 调用元数据
+
+### 步骤 2：人工快速核对
+
+对照原图，重点核对「文字钉死」片段里的 ⚠️ 核对项（这些是评测发现的脑补重灾区）：
+- **卫生间朝向 / 是否暗卫**（模型间分歧最大）
+- **阳台朝向**（皆南 vs 一南一北类分歧）
+- **窗户类型 / 大小**（均为推测值）
+
+房间数量与单间面积经评测高度可信（qwen-vl-max 与 gpt-4o 面积 OCR 完全一致），一般无需核对。
+
+### 步骤 3：喂给路径 B 生图
+
+把核对后的「文字钉死」片段贴进 `ai-art-research/prompts/居民楼-*-户型图推导-v*.txt` 的窗户形态段落，
+作为户型图推导立面的"文字钉死"依据，再走 `image_gen.py --fuse` 生图。
+
+## 注意事项
+
+- 走 API易 的 **vision chat 接口（按 token 计费）**，与生图通道（codex 按订阅 / apiyi 按张）独立，互不影响
+- 窗户类型/朝向/大小是模型**推测**，务必核对；房间结构与面积可信
+- 若某张图效果不稳，可用 `floorplan_eval.py --image <图> -m <模型>` 换模型对比（参考评测对比.md）
+- 链家等彩色标准化户型图适配良好；纯手绘/模糊扫描图效果会下降
+- `ai-art-research/` 被项目 `.ignore` 屏蔽，操作需用显式路径（不进 Glob 检索）

.claude/skills/problem-solving/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: "problem-solving"
+description: "问题解决技能 — 改 bug / 排查复杂问题时，按「问题分析 → 工作记录 → 知识沉淀」三段式产出。当需要「修 bug」「排查问题」「调查原因」「问题分析」「写工作记录」「沉淀知识库」时使用。"
+---
+
+# 问题解决（Problem Solving）
+
+> 改 bug / 做复杂改动时，按「问题分析 → 工作记录 → 知识沉淀」三段式产出。
+> **核心范式**：Gitea issue 是工作台（承载问题分析 + 工作记录，事务性）；`docs/knowledge/` 是精选集（只收值得长期保留的坑）；临时代码验证完即删。
+
+## 触发条件
+
+- 用户要求**修 bug、排查问题、调查根因**，且问题非一行 typo 类简单修改
+- 用户说「修 bug」「排查」「为什么…」「调查」「这个问题怎么回事」等
+- 改动涉及多个文件 / 需要先理解现状才能动手的复杂改动
+
+**不触发**（直接改 + 普通 `fix(scope)` 提交）：明显的单行修复、typo、数值微调。
+
+---
+
+## 九步流程
+
+### 1. 判断复杂度
+
+简单修复（单行、明显错误）→ 直接改 + `fix(scope)` 提交，**不走本流程**。
+复杂问题（需调查、跨文件、根因不明）→ 继续后续步骤。
+
+### 2. 开 / 关联 Gitea issue
+
+调用 `gitea-pm` / `gitea-collab` skill：
+- 没有对应 issue → 开一个，打标签 `type:bug`（缺陷修复）或 `type:investigation`（纯调查）+ `status:in-progress`
+- 已有 issue → 关联，更新为 `status:in-progress`
+
+> 每个「要解决的问题」都应有对应 issue——问题分析和工作记录都挂在它上面。
+
+### 3. 问题分析（写入 issue 描述 / 首条评论）
+
+按「问题分析模板」填写：现象 / 复现 / 影响范围 / 假设与验证 / 初步结论。这是调查过程的留痕。
+
+### 4. 本地调查
+
+写临时验证代码验证假设（文件名前缀 `tmp_` / `dev_`，文件头 `// [TEMP-INVESTIGATE: issue#XX] 验证后删除`）。**关键验证代码片段**以代码块形式记入 issue「假设与验证」章节。
+
+### 5. 清理临时代码
+
+验证完**即删**——删除 `tmp_`/`dev_` 文件、`git revert` 或删除 `[TEMP-INVESTIGATE]` 的 commit。最后 `grep -r "TEMP-INVESTIGATE" Source/ tools/` 确认无残留。
+
+> 原则：删除的是可运行 artifact，保留的是 insight（结论 + 片段已写入 issue）。
+
+### 6. 修复
+
+写正式代码 / 蓝图，遵循 `code-implementation` skill 规范 + Git 规范（`fix(scope)`，C++ 与蓝图分开提交，见 `docs/common/GIT-GUIDE.md`）。
+
+### 7. 工作记录（写入 issue 关闭总结评论）
+
+按「修复总结模板」发一条评论：问题 / 根因 / 解决方案 / 验证 / 影响范围 / 是否沉淀知识库。
+
+> **与 deviation-report 的分工**：问题涉及「实现 vs 执行案偏差」时（有执行案对照）→ 用 `deviation-report` skill 写偏差报告；纯 bug 修复（无执行案对照）→ 用本「修复总结」。两者互补。
+
+### 8. 知识库评估
+
+判断这个坑是否值得长期保留（**任一为是**即提炼）：
+- 会复发吗？（换人/换系统会再踩）
+- 根因非显而易见吗？（光看代码看不出来）
+- 当前是临时方案吗？
+
+**是** → 提炼一条进 `docs/knowledge/` 对应主题文件（`坑-<主题>.md`），更新 `docs/knowledge/INDEX.md`；若是临时方案，再登记到 `docs/knowledge/临时方案登记.md`。
+**否** → issue 关闭即可，不必沉淀。
+
+> 动手前先读 `docs/knowledge/INDEX.md`，看有没有相关坑可避让。
+
+### 9. 关闭 issue
+
+更新 issue 为 `status:done`，在评论里记录产出位置（分析评论 / 修复总结评论 / 知识库条目路径）。
+
+---
+
+## 模板
+
+### 问题分析模板（issue 描述 / 首条评论）
+
+```markdown
+## 问题现象
+## 复现步骤
+## 影响范围
+## 假设与验证（调查过程）
+- 假设1：… → 验证手段：… → 结论：…
+- 假设2：…
+## 初步结论 / 根因
+## 关键验证代码片段（临时代码已删，仅留片段）
+```
+
+### 修复总结模板（issue 关闭总结评论）
+
+```markdown
+## 修复总结
+### 问题（一句话）
+### 根因
+### 解决方案（改了哪些 文件/蓝图/C++，分条）
+### 验证（怎么确认修好）
+### 影响范围（是否波及其他系统）
+### 是否沉淀知识库？（是→已提炼到 docs/knowledge/xxx；否→为何不必）
+```
+
+### 知识条目模板（`docs/knowledge/坑-<主题>.md`）
+
+```markdown
+### [K-XXX] 标题
+- 来源: Gitea issue #XX
+- 症状: …
+- 根因: …
+- 避坑做法: …（核心价值）
+- 状态: ✅正式方案 / ⚠️临时方案（预计转正时机：…）
+- 关联: [[系统-技术方案]]、相关代码位置 file:line
+```
+
+ID 全库统一递增（K-001、K-002…），不分主题。新增后同步更新 `INDEX.md`。详见 `docs/knowledge/README.md`。
+
+---
+
+## 产出物清单（每次复杂问题必须交付）
+
+1. ✅ issue 问题分析（描述 / 首条评论）
+2. ✅ issue 关闭总结评论（修复总结）
+3. ⚙️〔条件〕`docs/knowledge/` 知识条目 + `INDEX.md` 更新（仅当值得沉淀）
+4. ✅ 临时代码已清理（`grep TEMP-INVESTIGATE` 无残留）
+
+---
+
+## 核心原则
+
+- **issue 是工作台，知识库是精选集**：别把过程流水账灌进 docs，只提炼有长期价值的。
+- **临时代码验证完即删**：仓库只留正式实现，结论和片段留在 issue。
+- **诚实记录根因**：工作记录的价值在于「为什么」，不在于「我改了什么」——后者看 commit 就知道。

.gitignore

@@ -125,3 +125,13 @@ ai-art-research/.env
 *.swo
 *~
 temp.txt
+
+# ==============================
+# AI 生图 — codex 运行残留（codex exec -o 输出，每次覆盖，不入库）
+# ==============================
+ai-art-research/.codex_lastmsg.txt
+
+# ==============================
+# 外部规范/国标参考 PDF（本地保留，不进版本库）
+# ==============================
+ai-art-research/*.pdf

CLAUDE.md

@@ -5,9 +5,10 @@
 ## 项目概况
 
 - **引擎**: Unreal Engine 5.7.4
+- **引擎安装路径**: `E:\Program Files\Epic Games\UE_5.7`（**本项目必须使用此 5.7 引擎**；本机另有 5.6 在 `E:/MiceCola/work/UE_5_6`，切勿误用——5.6 的 UBT 不认项目 Target.cs 中的 5.7 专属枚举，会直接 RulesError）
 - **美术风格**: 3D Lowpoly，温暖色调，怀旧氛围
 - **核心玩法**: 模拟千禧年前后城郊结合区儿童的日常生活（探索、小游戏互动、收集、剧情叙事）
-- **灵感来源**: NDS《放学后少年》自由探索 + PS《我的暑假》日常叙事节奏
+- **灵感来源**: NDS《放学后少年》自由探索 + PS《我的暑假》日常叙事节奏 +《深夏时光》玩法
 - **时代背景**: 2000年前后，城市边缘的城郊结合区（如南京迈皋桥），兼顾乡村情节
 - **开发者**: starmen1265（单人独立开发）
 
@@ -16,18 +17,27 @@
 ## 项目管理
 
 - **工具**: Gitea（Issues + Milestones）
-- **PM 技能**: `gitea-pm`（任务创建/关闭、里程碑管理、Pipeline Tracker）
-- **通用技能**: `gitea-collab`（任务查询、进度汇报、审查操作）
 - **进度查询**: Pipeline Tracker（Meta Issue，仅记录当前阶段和阶段历史）
 - **配置文件**: `.claude/skills/gitea-pm/gitea-config.json`（含连接信息、Token、角色映射、标签定义）
+- **问题管理**: 改 bug / 排查复杂问题走 `problem-solving` skill（问题分析 + 工作记录挂 Gitea issue，经验沉淀进 `docs/knowledge/`）；详见 [`docs/knowledge/README.md`](docs/knowledge/README.md)
 
 ---
 
 ## Git 规范
 
-详见 [.claude/refs/GIT-GUIDE-LITE.md](.claude/refs/GIT-GUIDE-LITE.md)。核心要点：
+详见 [docs/common/GIT-GUIDE.md](docs/common/GIT-GUIDE.md)。核心要点：
 
 - `main` 永远可玩可编译
-- 分支: `feature/` `fix/` `prototype/` `release/`
+- 分支: `develop/`
 - 提交: `<type>(<scope>): <中文描述>`，subject ≤ 50 字符
 - UE5: 蓝图与 C++ 分开提交；.uasset/.umap commit message 必须写清内容
+
+---
+
+## AI 生图
+
+- **默认走 Codex 通道**（ChatGPT Plus 订阅额度，不按张计费），完整流程见 [`ai-art-research/codex生图工作规范.md`](ai-art-research/codex生图工作规范.md)。该通道为**协作模式**：`codex exec` 由**用户在终端执行**，Claude 负责组装 prompt 与捞图/命名/写 meta 收尾——Claude Code 的安全分类器会硬拦 `codex exec --dangerously-bypass-approvals-and-sandbox`（“Create Unsafe Agents”，不可配置放行），无法自动跑。
+- **apiyi 兜底**（`tools/image_gen.py`，按张计费）：撞 ~40–50 张/3h 限额 / 需真透明背景 / 需 Claude 全自动批量时使用；这条通道 Claude 可全自动跑。
+- **必须复用现有资产**：`ai-art-research/prompts/*.txt`、`tools/image_gen.py` 的 `STYLE_SEED_EN` 风格种子、`生成结果/` 命名规则（`<时间戳>_gpt-image-2_<模式>.png` + 同名 `.meta.json`，新增 `backend: codex|apiyi` 字段）。
+- codex 不在默认 PATH，执行路径：`~/.codex/packages/standalone/current/bin/codex.exe`（命令模板：`codex exec --enable image_generation --dangerously-bypass-approvals-and-sandbox -C ai-art-research -o <lastmsg> "<prompt>"`，prompt 内须明示“用内置 image_gen 工具、不要写脚本/不要用 API key”）。
+- ⚠️ `ai-art-research/` 被项目 `.ignore` 屏蔽，不进 ripgrep/Glob 检索；操作需用显式路径。

ChildHood.uproject

@@ -37,6 +37,13 @@
 			"TargetAllowList": [
 				"Editor"
 			]
+		},
+		{
+			"Name": "Tripo3DUEBridge",
+			"Enabled": true,
+			"SupportedTargetPlatforms": [
+				"Win64"
+			]
 		}
 	]
 }