GenarrativeAI/Genarrative
5
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

Prune obsolete docs and update navigation

Browse Source
This commit is contained in:
高物
2026-04-25 15:10:24 +08:00
parent 1c5f9303a2
commit 2ebfd1cf55
341 changed files with 1352 additions and 90709 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/planning/BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md
View File

@@ -259,7 +259,7 @@
可复用来源：
- `README.md`
- `docs/technical/NODE_SERVER_KNOWLEDGE_GRAPH_2026-04-08.md`
- `docs/technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md`
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md`
### 5.2 技术研发情况

4
docs/planning/BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md
View File

@@ -101,8 +101,8 @@
- `docs/prd/AI_NATIVE_CUSTOM_WORLD_CREATION_FLOW_OPTIMIZATION_PRD_2026-04-06.md`
- `docs/prd/AI_NATIVE_STORY_ENGINE_PHASE1_IMPLEMENTATION_PLAN_2026-04-06.md`
- `docs/prd/AI_NATIVE_STORY_ENGINE_PHASE2_IMPLEMENTATION_PLAN_2026-04-06.md`
- `docs/technical/NODE_SERVER_KNOWLEDGE_GRAPH_2026-04-08.md`
- `docs/planning/CURRENT_GAME_ITERATION_PRIORITIES_2026-04-03.md`
- `docs/technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md`
- `docs/audits/engineering/README.md`
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md`
## 5. 三个方向的共用材料包

293
docs/planning/CURRENT_GAME_ITERATION_PRIORITIES_2026-04-03.md
View File

@@ -1,293 +0,0 @@
# 当前游戏优先迭代清单（2026-04-03）
## 结论先说
当前阶段最不该做的，是继续零散加玩法、加场景、加文案，却让主链路、规则底座和工程门禁继续处在半完成状态。
按现有文档和代码状态看，建议优先级顺序如下：
1. `P0`：先恢复工程绿色基线，并把运行时主链路继续拆开
2. `P1`：再落统一角色属性底座，作为战斗 / 对话 / 招募 / Build / 掉落 / 任务的共同语义基础
3. `P1`：在统一属性底座之上，重做 Build、运行时物品奖励、任务系统三条核心玩法链
4. `P2`：最后收尾编辑器共享层、本地 API 分层、移动端体验与运行时包体优化
一句话判断：
**现在的优先级不是“继续扩玩法宽度”，而是“先把底层规则、主流程边界和工程可维护性补齐，再扩玩法深度”。**
补充更新（`2026-04-21`）：
当前与“主流程边界补齐”直接对应的执行基线，已经从泛化的 `GameShell / useStoryGeneration / customWorld` 热点讨论，收口成两条正式技术方案：
1. [../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)：负责创作入口 -> Agent session -> result preview -> published profile 主链。
2. [../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)：负责平台入口 -> 继续游戏/开始游戏 -> RPG runtime -> runtime story 主链。
因此本文里的 `P0-2`，当前应按这两条主线落地，而不是继续围绕旧 `GameShell` / `PreGameSelectionFlow` / `runtimeRoutes.ts` 命名做泛化式重构。
---
## 优先级清单
## P0-1：恢复绿色基线，收紧质量门禁
### 为什么必须排第一
- `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md` 已明确指出：当前最值得优先优化的不是继续加功能，而是把“半完成的工程化”补齐。
- 文档中提到过 `lint` 失败、`build` warning、核心热区文件被 ESLint ignore、部分测试未进入默认套件，这意味着当前代码库还不在真正稳定的绿色基线。
- 在这种状态下继续叠加新玩法，只会把问题扩散到更多运行时链路和编辑器链路。
### 本阶段要做什么
- 修复现有 `lint` / `build warning` / 明确可见的门禁破口
- 缩小高风险核心文件的 ignore 范围
- 让 `lint + typecheck + test + build + check:content` 成为可信的统一门禁
- 对 warning 建立“尽快清零”策略，而不是长期带病开发
### 做到什么算完成
- 主开发分支长期保持 `npm run check` 可稳定通过
- 核心运行时文件不再依赖长期 ignore 才能过门禁
- 构建 warning 收敛到零或有非常明确的短期处理计划
### 为什么它比新功能更优先
- 没有绿色基线，后续所有大改都缺少可靠回归保护
- 这一步是后面统一属性、任务重构、物品系统重构的前置条件
---
## P0-2：继续拆运行时主链路，防止核心 hook 和壳层继续膨胀
### 为什么必须紧跟在 P0-1 后面
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md`、`docs/experience/PROJECT_WORK_EXPERIENCE_PLAYBOOK.md`、`docs/experience/ADVENTURE_RUNTIME_DEV_EXPERIENCE.md` 都反复强调：这个项目是叙事、状态、演出、界面四条链路耦合的复合项目，不能靠大文件硬扛。
- `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-03-30.md` 和 `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md` 一致指出，`useStoryGeneration`、`useCombatFlow`、`GameShell` 仍然是当前最大的复杂度集中点。
- 如果不先拆主链，后面的统一属性系统、任务系统、物品导演层都会继续堆进现有巨型流程控制器，技术债只会翻倍。
### 本阶段要做什么
- 按 [../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md) 收口创作链，统一 `Agent session -> result preview -> published profile`
- 按 [../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md) 收口 `rpgEntry -> rpgSession -> rpgRuntime -> rpgRuntimeStory -> rpgProfile`
- 旧 `GameShell / PreGameSelectionFlow / runtimeRoutes.ts / storyActionService.ts` 只作为历史热区名或兼容 façade，不再作为当前新任务默认落点
### 做到什么算完成
- 新功能接入时，不需要再跨 `story + combat + panel + modal` 四五层一起改
- 核心流程可以按领域补测试，而不是只能做人工回归
- 后续玩法扩展能优先加领域模块，而不是继续往大 hook 里塞逻辑
### 这一项的实际意义
- 这是“后续还能继续做大”的结构前提
- 不做这一步，任何系统升级都会越来越难落地
---
## P1-1：落地统一角色属性系统，作为全玩法共同底座
### 为什么它是最优先的玩法底座
- `docs/prd/AI_NATIVE_UNIFIED_ROLE_ATTRIBUTE_SYSTEM_PRD_2026-04-02.md` 已经把问题说得很清楚：当前玩家、NPC、怪物、Build、对话、掉落还没有共享同一套解释坐标。
- 当前项目已经有 NPC 关系、怪物标签、Build 语义、自定义世界生成能力，但这些系统之间还缺一套统一的世界级属性 schema。
- 如果先做任务、物品、Build 深化，而不先统一属性，后面很容易再次出现“每个系统各自解释角色”的分裂。
### 本阶段要做什么
- 为预设世界固化世界级属性 schema
- 为玩家角色、怪物、关键 NPC 补 `attributeProfile`
- 建立统一的属性解析与校验层
- 先让对话 / 招募 / 送礼 / 详情面板开始读取这套新属性解释
### 做到什么算完成
- 玩家、NPC、怪物都能落到同一套属性语义里
- 聊天、送礼、招募至少有一条链可以直接解释到属性层
- 自定义世界也能生成并持久化自己的属性 schema
### 为什么这项优先于“多做内容”
- 这是后面 Build、物品、任务三条系统统一升级的共同前提
- 没有这层底座，玩法会继续“能跑，但彼此不共语义”
---
## P1-2：把 Build 系统从“标签互相影响”改成“标签匹配角色属性”
### 为什么这里要尽快做
- `docs/prd/BUILD_SYSTEM_ATTRIBUTE_SIMILARITY_PRD_2026-04-02.md` 指出：当前 Build 更像标签网络效应，解释成本高、平衡成本高、角色差异感不够强。
- 一旦统一角色属性系统先落地，Build 就是最适合第二个接入的玩法层，因为它最直接影响战斗反馈和角色成长感。
### 本阶段要做什么
- 为 Build 标签补属性亲和度向量
- 改写 `buildDamage` 逻辑，让每个标签独立匹配当前角色属性画像
- 调整 Build 面板文案，从“标签协同”转成“属性适配度”
### 做到什么算完成
- 玩家能理解“为什么这个标签适合当前角色”
- 新增标签只影响自身贡献，不再扰动整张标签网络
- Build 面板能解释收益来自哪些属性
### 实际收益
- 提高可解释性
- 降低平衡难度
- 让角色差异感真正进入 Build 体验
---
## P1-3：重做运行时物品奖励，让奖励真正贴合场景、NPC、最近事件和 Build 缺口
### 为什么它值得排在任务系统前面
- `docs/design/AI_NATIVE_RUNTIME_ITEM_SYSTEM_REDESIGN_2026-04-02.md` 明确指出：当前宝藏、NPC、任务、锻造等入口都有物品，但缺少统一导演层，奖励与场景/NPC/事件的贴合度不够高。
- 相比任务系统，运行时物品奖励能更快提升“世界贴脸感”和“当下反馈质量”，且可以先从宝藏入口低风险落地。
### 本阶段要做什么
- 增加运行时物品上下文采样、导演层、编译器和叙事回写层
- 统一宝藏、NPC 奖励、怪物掉落、任务奖励的物品生成入口
- 让奖励优先围绕 Build 标签、限时 Build Buff、少量数值补足来设计
### 做到什么算完成
- 至少宝藏和 NPC 奖励接入统一导演层
- 物品能解释“为什么在这里出现、和谁有关、补的是什么方向”
- 物品来源可以进入背包、剧情、锻造与存档的同一套结构
### 实际收益
- 奖励不再像泛用掉落池
- 世界、人物、最近剧情与成长反馈终于真正连起来
---
## P1-4：把任务系统从“单目标单阶段”升级成“意图 -> 合约 -> 信号推进”
### 为什么它仍然是高优先级
- `docs/prd/AI_NATIVE_QUEST_SYSTEM_PRD_2026-04-02.md` 已经指出：当前任务闭环是成立的，但任务来源偏静态、结构偏扁平、状态过粗、奖励和关系变化也不够贴语境。
- 当前项目已经具备任务 UI、任务奖励、NPC 交互、剧情推进链，这说明任务系统适合做“升级”，而不是推倒重来。
### 本阶段要做什么
- 新增任务生成上下文、AI 任务意图层、本地任务编译层
- 把任务推进改成统一 signal 驱动
- 支持多 step、阶段揭示、完成后回报、后续钩子
### 做到什么算完成
- NPC 接任务不再只是静态模板，而是能根据当前局面生成任务意图
- 运行时能用统一 signal 推进任务步骤
- 奖励除了货币/道具，还能自然进入关系、情报、后续机会
### 为什么它排在物品系统之后
- 任务系统耦合更深，适合作为统一属性和统一奖励导演层之后的升级项
- 先把属性和物品奖励理顺，任务系统落地时会更稳
---
## P2-1：收尾编辑器共享层与本地 API 分层，让内容扩张不再继续拖慢主项目
### 为什么它不是最前面，但也不能拖太久
- 最近几份工程审查都指出：编辑器共享层、本地 JSON 写入接口、LLM 代理、Vite 插件职责仍然处于迁移中间态。
- 当前项目已经进入“内容工具很多、正式运行时也很重”的阶段，若不收尾这部分，后续每次扩内容都会重复踩基础设施问题。
### 本阶段要做什么
- 继续拆 editor shared 层
- 清理迁移残留和死分支
- 把本地 API 至少按 `llm proxy / json editor api / asset catalog` 分职责拆开
### 做到什么算完成
- 编辑器保存、共享组件、共享 client 不再重复实现
- 本地 API 分工清晰，dev / preview 边界清楚
- 编辑器扩展不再继续依赖大聚合组件
---
## P2-2：继续优化移动端冒险体验、首屏信息密度与运行时包体
### 为什么它放在 P2
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md` 和 `docs/experience/MOBILE_UI_DEV_EXPERIENCE.md` 都强调：冒险页必须优先保证上方演出、一屏选项和文本区自适应。
- 但从当前文档判断，移动端体验和包体问题更像“持续治理项”，不是当前阶段最核心的系统阻塞点。
### 本阶段要做什么
- 继续优化冒险页一屏布局与文本滚动策略
- 拆 `GameCanvas`、`AdventurePanel` 等高热区大模块
- 按真实交互热区继续做 chunk 拆分
### 做到什么算完成
- 手机首屏稳定容纳画布、文本和关键选项
- 核心页面热区模块更容易维护和测试
- 构建产物中的主 chunk 有持续下降趋势
---
## 不建议当前优先做的事
以下内容不是不能做，而是不建议排在当前这轮前面：
- 大量新增世界、场景、角色 preset
- 继续横向扩 NPC 交互种类，但不补统一规则底座
- 继续堆宝藏、掉落、锻造分支，但不先做统一物品导演层
- 继续增加任务模板数量，但不升级任务 contract
- 继续往 `useStoryGeneration` / `useCombatFlow` / `GameShell` / `PreGameSelectionFlow` / `runtimeRoutes.ts` / `storyActionService.ts` 里直接塞新逻辑
原因很简单：
**这些工作会让表面内容变多，但不会让项目变得更稳，反而会放大当前已经存在的结构问题。**
---
## 推荐迭代顺序
### 第一阶段：先稳住工程与主流程
1. 绿色基线与门禁收紧
2. 创作链按 `CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md` 收口
3. RPG 进入游戏与运行时链按 `RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md` 收口
### 第二阶段：先补统一语义底座
1. 统一角色属性系统
2. Build 改为属性适配
### 第三阶段：再深化 AI 原生玩法闭环
1. 运行时物品导演层
2. 任务意图与 contract 系统
### 第四阶段：最后做工具与体验收尾
1. 编辑器共享层 / 本地 API 分层
2. 移动端体验与包体优化
---
## 本清单的主要依据
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md`
- `docs/experience/PROJECT_WORK_EXPERIENCE_PLAYBOOK.md`
- `docs/experience/ADVENTURE_RUNTIME_DEV_EXPERIENCE.md`
- `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-03-29.md`
- `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-03-30.md`
- `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md`
- `docs/design/AI_NATIVE_RUNTIME_ITEM_SYSTEM_REDESIGN_2026-04-02.md`
- `docs/prd/AI_NATIVE_UNIFIED_ROLE_ATTRIBUTE_SYSTEM_PRD_2026-04-02.md`
- `docs/prd/BUILD_SYSTEM_ATTRIBUTE_SIMILARITY_PRD_2026-04-02.md`
- `docs/prd/AI_NATIVE_QUEST_SYSTEM_PRD_2026-04-02.md`
## 最后结论
如果只保留一句话，那就是：
**当前最优先的迭代方向，不是继续堆新内容，而是先把工程基线、主流程边界和统一规则底座补齐；只有这样，AI 原生任务、物品、Build 和后续内容扩展才会真正开始越做越顺。**

4
docs/planning/ENGINEERING_DEAD_CODE_AND_HIDDEN_BRANCH_CLEANUP_PLAN_2026-04-21.md
View File

@@ -139,10 +139,10 @@ Git 分支治理可以后置做，但不能和首轮工程清洗混在一起，
本计划基于现有文档已经确认的结论推进，重点参考：
1. `docs/audits/engineering/ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md`
1. `docs/audits/engineering/README.md`
2. `docs/audits/engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md`
3. `docs/audits/engineering/CURRENT_ENGINEERING_OPTIMIZATION_OPPORTUNITIES_2026-04-20.md`
4. `docs/planning/EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md`
4. `docs/technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md`
5. `docs/experience/PROJECT_WORK_EXPERIENCE_PLAYBOOK.md`
按当前审计结果，首轮就应重点关注下面 3 组对象。

588
docs/planning/EXPRESS_BACKEND_PARALLEL_WORKSTREAM_PLAN_2026-04-08.md
View File

@@ -1,588 +0,0 @@
# Express 后端化并行任务拆分规划（2026-04-08）
## 1. 目的
这份文档用于把 [EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md](./EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md) 进一步拆成可并行推进、尽量互不冲突的任务流。
目标不是把大重构拆成很多零碎 TODO，而是把它拆成：
- 可以同时开工
- 写入边界清晰
- 交付物明确
- 依赖关系稳定
- 最后容易集成
---
## 2. 并行拆分原则
## 2.1 基本原则
- 每条任务尽量拥有独占目录或独占模块，不去抢同一批热点文件。
- 热点集成文件只由“集成岗”或最后一轮集成处理，不作为多个任务的日常编辑目标。
- 先搭协议边界，再迁规则执行，再收缩前端。
- 前端与后端可以并行推进，但前提是先冻结 contract。
- 编辑器链路和正式运行时链路分开拆，避免互相阻塞。
## 2.2 当前最容易冲突的文件
以下文件建议默认只由集成岗或最后一轮联调处理：
- `server-node/src/context.ts`
- `server-node/src/routes/runtimeRoutes.ts`
- `server-node/src/app.ts`
- `src/services/apiClient.ts`
- `src/hooks/useStoryGeneration.ts`
- `src/hooks/useGameFlow.ts`
- `src/components/GameShell.tsx`
其他任务如果必须影响这些文件，优先通过：
- 新增独立模块
- 新增 adapter
- 新增中间层入口
而不是直接在热点文件中大改。
---
## 3. 建议并行批次
## 批次 A：可立即并行开工
- 任务 0：集成岗与接口冻结
- 任务 1：共享 contract 与目录抽离
- 任务 2：PostgreSQL 持久化基线收口
- 任务 3：服务端 HTTP 基础设施与统一响应壳层
- 任务 8：编辑器 API 归口与工具链隔离
- 任务 9：测试、观测与部署基线
## 批次 B：在 contract 初版落地后并行开工
- 任务 4：服务端 AI 编排收口
- 任务 5：运行时领域模块 A，Story / Combat / NPC
- 任务 6：运行时领域模块 B，Inventory / Quest / Build / Runtime Item
- 任务 7：前端 SDK、鉴权、持久化瘦身
## 批次 C：在服务端 action 和 view model 稳定后开工
- 任务 10：前端主流程壳层与大 hook 瘦身
---
## 4. 任务拆分
## 任务 0：集成岗与接口冻结
### 目标
负责冻结边界、维护接口文档、控制热点文件的合并节奏，避免多人同时改核心入口。
### 独占范围
- `docs/planning/**`
- `docs/technical/**`
- 最终集成时的热点入口文件
### 主要输出
- 统一任务看板
- contract 版本表
- 热点文件编辑规则
- 每日或每阶段集成清单
### 验收标准
- 团队知道哪些文件不能多人同时改
- 每条任务都有明确的上游 contract 与下游接入点
---
## 任务 1：共享 Contract 与目录抽离
### 目标
先把前后端共同识别的类型、schema、响应结构、错误结构抽出来，切断 `server-node -> src/**` 的长期反向依赖。
### 独占范围
- `packages/shared/**`
- 新建的共享类型、schema、contract 目录
### 可改边界
- `server-node/src/**` 中的 import 替换入口
- `src/**` 中的 import 替换入口
### 暂不负责
- 具体业务规则迁移
- 前端页面行为调整
- 数据库实现细节
### 主要输出
- 统一 API envelope
- 统一错误对象
- 统一 action / response contract
- 统一领域类型和状态枚举
### 验收标准
- 新增服务端模块不需要继续直接依赖前端目录里的实现细节
- 前后端都以共享 contract 为边界协作
### 并行关系
- 可与任务 2、任务 3、任务 8、任务 9 同时启动
- 是任务 4、任务 5、任务 6、任务 7 的上游基础
---
## 任务 2：PostgreSQL 持久化基线收口
### 目标
把“已经切到 PostgreSQL”的状态收成真正稳定的后端基线，清掉 SQLite 残留口径与仓储层耦合问题。
### 独占范围
- `server-node/src/config.ts`
- `server-node/src/db.ts`
- `server-node/src/repositories/**`
- `server-node/src/app.test.ts`
- `.env.example`
### 暂不负责
- 剧情规则
- 选项结算
- 前端状态瘦身
### 主要输出
- PostgreSQL 连接配置
- 仓储层接口统一
- 数据表初始化/迁移方案
- 运行时持久化测试基线
- 文档中的数据库现状统一
### 验收标准
- 后端运行时数据完全以后端数据库为准
- 配置、日志、测试、文档里不再把 SQLite 写成当前正式现状
### 并行关系
- 可与任务 1、任务 3、任务 8、任务 9 同时启动
- 为任务 5、任务 6、任务 7 提供稳定持久化基础
---
## 任务 3：服务端 HTTP 基础设施与统一响应壳层
### 目标
建立统一的服务端响应结构、错误结构、请求链路日志、版本字段和中间件壳层。
### 独占范围
- `server-node/src/http.ts`
- `server-node/src/errors.ts`
- `server-node/src/middleware/**`
- `server-node/src/app.ts`
### 可改边界
- 为 route 层提供新的响应 helper
- 为后续 action 接口提供统一 envelope
### 暂不负责
- 具体 story / combat / quest 业务逻辑
- 前端页面层接入
### 主要输出
- 统一 JSON 响应格式
- 统一错误格式
- `requestId`
- `latency` 与关键日志字段
- 路由级版本与元信息壳层
### 验收标准
- 后端所有新接口都能套用同一层响应约定
- 前端不需要为不同接口写多套错误解析逻辑
### 并行关系
- 可与任务 1、任务 2、任务 8、任务 9 同时启动
- 是任务 4、任务 5、任务 6、任务 7 的共同基础
---
## 任务 4：服务端 AI 编排收口
### 目标
把正式运行时的 prompt 组装、模型调用、容错、SSE 转发都收回后端，浏览器不再保留正式运行时 AI fallback。
### 独占范围
- `server-node/src/services/llmClient.ts`
- `server-node/src/services/chatService.ts`
- `server-node/src/services/storyService.ts`
- `server-node/src/services/customWorldGenerationService.ts`
- `server-node/src/services/questService.ts`
- `server-node/src/services/runtimeItemService.ts`
### 可新增目录
- `server-node/src/modules/ai/**`
### 暂不负责
- 前端主流程组件
- 数据库存储实现
### 主要输出
- 后端统一 AI orchestration 层
- 流式接口统一适配
- prompt 复用策略
- 前端 fallback 清理清单
### 验收标准
- 正式运行时不再依赖浏览器端大体量 AI 实现作为兜底
- AI 失败、超时、流式中断都能在后端统一处理
### 并行关系
- 建议在任务 1、任务 3 有初版后启动
- 可与任务 5、任务 6、任务 7 并行
---
## 任务 5：运行时领域模块 A，Story / Combat / NPC
### 目标
把剧情推进、战斗结算、NPC 交互这些最核心的运行时状态迁移到后端领域模块。
### 独占范围
- `server-node/src/modules/story/**`
- `server-node/src/modules/combat/**`
- `server-node/src/modules/npc/**`
### 可改边界
- 为 route/action 层提供服务接口
- 为前端提供 view model 所需聚合结果
### 暂不负责
- 背包、Build、任务奖励编排
- 编辑器接口
### 主要输出
- story action resolver
- combat resolution service
- npc interaction service
- 统一返回给 UI 的 presentation/view model 结构
### 验收标准
- 前端不再本地决定 function 合法性、战斗结果、NPC 关键关系变化
- 点击选项时，后端能返回完整下一步展示结果
### 并行关系
- 依赖任务 1、任务 3
- 可与任务 4、任务 6、任务 7 并行
---
## 任务 6：运行时领域模块 B，Inventory / Quest / Build / Runtime Item
### 目标
把任务推进、运行时物品、背包/装备、Build 收益等剩余核心规则迁到后端。
### 独占范围
- `server-node/src/modules/inventory/**`
- `server-node/src/modules/quest/**`
- `server-node/src/modules/build/**`
- `server-node/src/modules/runtime-item/**`
### 可改边界
- 调用任务 2 的仓储层
- 使用任务 1 的共享 contract
### 暂不负责
- 前端页面层改造
- Story / Combat / NPC 主链路
### 主要输出
- inventory mutation service
- quest signal progression service
- build calculation service
- runtime item resolution service
### 验收标准
- 背包、任务、Build、运行时物品不再由前端保留正式结算逻辑
- 这些领域能独立测试，不依赖 UI hook
### 并行关系
- 依赖任务 1、任务 2、任务 3
- 可与任务 4、任务 5、任务 7 并行
---
## 任务 7：前端 SDK、鉴权、持久化瘦身
### 目标
让前端从“业务执行层”退回“API 消费层 + 表现层状态协调层”。
### 独占范围
- `src/services/apiClient.ts`
- `src/services/authService.ts`
- `src/services/storageService.ts`
- `src/services/aiService.ts`
- `src/hooks/useGamePersistence.ts`
- `src/hooks/useGameSettings.ts`
### 暂不负责
- 页面组件大范围重构
- `useStoryGeneration.ts` 主流程瘦身
### 主要输出
- 轻量前端 SDK
- 统一鉴权请求层
- 统一错误态与重试策略
- 远端快照/设置消费层
- 正式运行时浏览器 fallback 下线方案
### 验收标准
- 前端服务层不再保留完整正式规则或正式 AI 编排
- 存档与设置以后端返回结果为准
### 并行关系
- 依赖任务 1、任务 3
- 可与任务 4、任务 5、任务 6 并行
- 为任务 10 提供稳定的 API 消费层
---
## 任务 8：编辑器 API 归口与工具链隔离
### 目标
把编辑器的写盘、生成、任务查询能力从“散落接口”整理成清晰的编辑器后端模块，避免继续污染正式运行时。
### 独占范围
- `src/editor/shared/**`
- `src/components/preset-editor/**`
- `src/components/npcVisualEditorPersistence.ts`
- `src/components/preset-editor/characterAssetStudioPersistence.ts`
- `scripts/dev-server/**`
- `server-node/src/modules/editor/**`
- `server-node/src/modules/assets/**`
### 暂不负责
- 主游戏运行时 action 逻辑
- 正式剧情流转
### 主要输出
- `/api/editor/*` 与 `/api/assets/*` 命名空间
- 统一 editor client SDK
- 写接口权限边界
- 编辑器工具链迁移清单
### 验收标准
- 编辑器组件不再散落直连多个写接口
- 编辑器 API 与运行时 API 的职责边界清晰
### 并行关系
- 可与任务 1、任务 2、任务 3、任务 9 同时启动
- 与任务 5、任务 6、任务 10 基本不冲突
---
## 任务 9：测试、观测与部署基线
### 目标
为整个后端化改造提供自动回归、链路日志和部署基线，避免“功能迁过去了但不可验证”。
### 独占范围
- `server-node/src/**/*.test.ts`
- `scripts/**`
- 部署与运维相关文档
- 反向代理与 smoke 测试脚本
### 暂不负责
- 具体业务模块实现
### 主要输出
- 后端接口测试
- 关键主链路 smoke
- request/response 日志校验
- 同域部署基线
- 回滚、备份、迁移检查清单
### 验收标准
- `web + server` 改造过程有最小自动回归保护
- 关键接口失败时能追踪到请求链路
### 并行关系
- 可与任务 1、任务 2、任务 3、任务 8 同时启动
- 后续持续跟进任务 4、任务 5、任务 6、任务 7、任务 10 的交付
---
## 任务 10：前端主流程壳层与大 Hook 瘦身
### 目标
在服务端 action 和前端 SDK 稳定后，把 `GameShell`、`useStoryGeneration` 这一层改成真正的表现层协调器。
### 独占范围
- `src/hooks/useStoryGeneration.ts`
- `src/hooks/story/**`
- `src/hooks/useGameFlow.ts`
- `src/components/GameShell.tsx`
- `src/components/AdventurePanel.tsx`
- `src/components/NpcModals.tsx`
- `src/components/auth/**`
### 暂不负责
- 数据库、服务端仓储
- 编辑器 API
### 主要输出
- 面向 action/view model 的前端流程层
- 页面表现态与业务态分离
- 大 hook 拆分后的协调层
- 更容易测试和替换的主流程壳层
### 验收标准
- 前端主流程不再直接吞下完整运行时规则
- 页面层主要消费后端 view model，而不是本地自算结果
### 并行关系
- 依赖任务 5、任务 6、任务 7 至少有一轮稳定输出
- 是最后一批大规模前端接入任务
---
## 5. 推荐协作顺序
## 第一步：先定边界
先启动：
- 任务 0
- 任务 1
- 任务 2
- 任务 3
这一轮完成后，团队会得到：
- 统一 contract
- 稳定数据库基线
- 稳定后端响应壳层
- 稳定任务分工边界
## 第二步：领域层和工具层分头推进
在第一步基础上并行启动：
- 任务 4
- 任务 5
- 任务 6
- 任务 7
- 任务 8
- 任务 9
这一轮是整个改造的主生产阶段。
## 第三步：最后收前端主流程
最后启动：
- 任务 10
原因很简单：
- 如果太早改 `useStoryGeneration` 和 `GameShell`，前端还没有稳定的 action contract 和 view model，会反复返工。
---
## 6. 建议的多人分工方式
如果是 4 人并行，建议：
- 1 人负责任务 1 + 任务 0 的 contract/集成
- 1 人负责任务 2 + 任务 3 的后端基建
- 1 人负责任务 4 + 任务 5 的运行时主链
- 1 人负责任务 8 + 任务 9，之后转入任务 7 或任务 10
如果是 6 人并行，建议：
- 1 人负责任务 0 + 任务 1
- 1 人负责任务 2
- 1 人负责任务 3 + 任务 9
- 1 人负责任务 4
- 1 人负责任务 5
- 1 人负责任务 6 + 任务 8
前端主流程任务 10 建议在第二轮由最熟悉当前 UI 壳层的人接手。
---
## 7. 合并规则建议
- 每条任务优先新增目录和新模块，少直接改热点文件。
- 热点文件统一在集成窗口合并，不在多个任务里同步推进。
- 任何任务如果需要改 `useStoryGeneration.ts`，默认先暂停并和任务 10 对齐。
- 任何任务如果需要改 `server-node/src/routes/runtimeRoutes.ts`，默认先走任务 0 的接口冻结表。
- 编辑器链路和正式运行时链路不要混在同一个 PR 里。
---
## 8. 一句话结论
这次重构最稳的并行方式不是“大家一起改前后端”，而是：
**先用 contract、数据库基线和 HTTP 壳层把边界钉死，再让服务端领域迁移、编辑器归口、前端瘦身分轨并行，最后由主流程壳层统一接入。**

447
docs/planning/EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md
View File

@@ -1,447 +0,0 @@
# Express 后端化工程重构规划（2026-04-08）
## 1. 背景
当前项目已经引入 `Express` 后端，且 `server-node/` 已经承接了运行时鉴权、存档、设置、自定义世界、剧情生成、角色聊天、NPC 对话、运行时物品意图、任务生成等能力。
但从当前工程状态看，项目仍处于“后端已存在，但运行时领域层尚未完全脱前端”的过渡态，主要表现为：
- 前端 `src/hooks/useStoryGeneration.ts` 仍然承担了大量运行时编排、规则拼接与状态推进职责。
- 前端 `src/services/ai.ts` 仍然保留了完整的 AI 调用、提示词拼装和本地兜底实现。
- 前端 `src/hooks/useGamePersistence.ts` 仍在承担较重的存档恢复、schema 纠偏与归一化职责。
- `server-node/src/**` 当前仍在直接引用 `src/types`、`src/data`、`src/services` 中的内容，分层尚未真正闭合。
- 编辑器相关写接口仍然散落在前端组件与 `jsonClient` 中，运行时 API 与编辑器 API 还没有完全归口。
现在既然已经明确“前端只负责做表现，所有逻辑、数据都放到后端进行运算和存储”，就需要把这个原则升级成整个工程的硬边界，而不是只停留在一部分接口迁移完成的状态。
---
## 2. 重构总原则
本轮重构只坚持一个核心原则：
**前端不是业务执行层，而是表现层；后端才是唯一的运行时真相来源。**
进一步展开为：
- 前端只负责页面结构、动画演出、输入采集、局部交互态、加载态和错误态展示。
- 后端负责鉴权、会话、规则计算、剧情推进、AI 编排、任务推进、道具结算、Build 结算、存档读写与持久化。
- 浏览器内不再保留“正式运行时业务规则”的第二套实现。
- 浏览器内允许存在少量纯表现计算，但不允许成为游戏状态真相来源。
- 编辑器能力与正式运行时能力分离，避免 dev 工具链继续污染正式运行时边界。
---
## 3. 重构目标
## 3.1 目标状态
- 浏览器只发送“玩家意图”和必要的展示参数，不直接提交完整运行时真相。
- `Express` 后端成为唯一的运行时状态源、规则执行源和 AI 调度源。
- 运行时快照、任务状态、NPC 状态、背包、属性、Build、剧情历史全部以后端持久化结果为准。
- 前端不再直接 import 正式运行时 AI 逻辑、提示词逻辑和关键规则逻辑。
- `server-node` 不再依赖 `src/**` 中的前端实现细节，而是依赖独立共享层。
- 编辑器 API、运行时 API、资产生成 API 形成清晰命名空间和权限边界。
## 3.2 非目标
- 本轮不追求一次性重写所有玩法系统。
- 本轮不再讨论关系型数据库选型切换，当前后端以 `PostgreSQL` 为准。
- 本轮不改动已有中文剧情、设定和文案方向。
- 本轮不为了“前后端分离”牺牲移动端体验与当前主流程可玩性。
---
## 4. 职责边界
| 领域 | 前端职责 | 后端职责 |
| --- | --- | --- |
| 页面与流程壳层 | 页面切换、面板开关、布局、自适应、动效、加载态 | 不负责页面 UI |
| 用户输入 | 收集点击、拖拽、表单输入、选项选择 | 校验输入是否合法，解释输入对应的运行时动作 |
| 游戏状态 | 仅持有当前展示所需 view model 和局部 UI state | 持有完整游戏状态、快照、事件日志、版本号 |
| 剧情推进 | 展示文本流、选项、动画时间线 | 生成剧情、决定选项集合、推进故事状态 |
| 战斗与数值 | 播放攻击、受击、死亡、位移 | 计算伤害、蓝耗、CD、死亡、掉落、逃跑结果 |
| NPC/同伴交互 | 展示面板、聊天输入框、关系反馈演出 | 计算关系变化、招募条件、交易合法性、对话结果 |
| 背包/装备/Build | 展示背包、装备栏、Build 面板 | 计算背包变化、装备结果、Build 收益与约束 |
| 任务系统 | 展示任务卡片、任务进度、奖励动画 | 生成任务、推进 signal、发放奖励 |
| AI 调用 | 不直接请求正式运行时模型 | 统一做 prompt 组装、模型调用、超时重试、日志 |
| 持久化 | 最多保留极少量表现态缓存 | 负责存档、设置、用户数据、迁移、恢复 |
| 编辑器 | 调用 SDK、展示工具面板 | 负责写盘、生成任务、队列、权限与审计 |
## 4.1 前端允许保留的状态
- 当前面板是否打开
- 当前动画是否播放中
- 当前流式文本已经显示到哪一段
- 表单草稿、搜索词、临时筛选条件
- 与展示相关的 viewport / media / motion 状态
## 4.2 前端禁止继续承载的职责
- function 合法性判定
- 怪物/NPC/任务/物品结算
- 正式运行时 prompt 组装
- 正式运行时 AI fallback
- 存档 schema 迁移主逻辑
- 以 `localStorage` 作为正式运行时主存储
- 编辑器组件直接散落 `fetch('/api/...')` 访问写接口
---
## 5. 当前工程问题归纳
## 5.1 运行时领域逻辑仍然偏前端中心
- `useStoryGeneration` 仍然是大体量编排热区，承接了剧情、NPC、战斗后续、任务和部分故事引擎逻辑。
- `src/services/ai.ts` 体量很大，说明正式运行时 AI 编排尚未完全移出浏览器。
- 当前“后端接口 + 前端兜底”的过渡模式，容易让正式逻辑继续双份存在。
## 5.2 服务端分层还没真正闭合
- `server-node` 当前仍直接引用 `src/types`、`src/data`、`src/services`。
- 这意味着后端虽然有了入口，但核心领域模型仍然绑在前端目录结构上。
- 继续沿着这条路开发，会让后端无法独立测试、独立构建和独立演进。
## 5.3 运行时持久化边界还不够干净
- 虽然正式存档已经走远端接口，但前端仍承担较重的恢复、归一化、迁移纠偏逻辑。
- 这会导致“存档解释权”同时存在于前后端两边，后续迭代容易失配。
## 5.4 编辑器与运行时 API 仍然混杂
- 编辑器读写接口目前仍然有散落访问点。
- 资产生成、JSON 写盘、运行时 API 还没有形成清晰的接口分域。
- 继续混用会让权限控制、生产部署和后续多人协作变得困难。
## 5.5 当前协议更像“接口迁移”，还不是“后端驱动运行时”
- 目前很多接口是把已有前端逻辑搬成了远端调用入口。
- 但真正理想状态应该是：玩家点击后，后端完成规则结算、状态推进、AI 调用和持久化，再把展示模型返回给前端。
---
## 6. 目标架构
```text
Browser
├─ 页面 / 动画 / 交互 / ViewModel 渲染
├─ 轻量前端 SDK（只负责请求与状态绑定）
└─ 局部 UI State
packages/shared
├─ contracts
├─ schemas
├─ domain-types
└─ api-client-types
server-node
├─ src/modules/auth
├─ src/modules/runtime-session
├─ src/modules/story
├─ src/modules/combat
├─ src/modules/npc
├─ src/modules/inventory
├─ src/modules/build
├─ src/modules/quest
├─ src/modules/custom-world
├─ src/modules/editor
├─ src/shared/http
├─ src/shared/infra
└─ src/shared/llm
storage
├─ postgres
├─ uploads
└─ generated
```
## 6.1 共享层原则
- `packages/shared` 只放类型、schema、协议、纯函数和序列化约定。
- 共享层不放浏览器专属实现，也不放 Node 专属 IO。
- 所有可执行运行时规则默认放后端，不放共享层。
## 6.2 前端目录目标
前端建议逐步收敛成下面的职责结构：
```text
src/
├─ app
├─ pages
├─ widgets
├─ features
├─ entities
├─ shared/api
├─ shared/ui
└─ shared/lib
```
其中：
- `shared/api` 只保留面向后端 contract 的 SDK。
- `features` 只组织交互流程和 UI 组合，不再承载正式运行时规则。
- 超大 hook 逐步拆成“页面状态协调层 + 远端 action 调用层 + 表现层状态”。
---
## 7. 关键协议重构方向
当前最值得尽快统一的，不是继续加接口数量，而是把协议升级成“意图驱动”。
推荐核心动作协议：
```json
{
"sessionId": "runtime-session-id",
"clientVersion": 12,
"action": {
"type": "story_choice",
"functionId": "fight_attack",
"targetId": "npc_merchant_01",
"payload": {
"optionId": "opt_02"
}
}
}
```
后端统一返回：
```json
{
"sessionId": "runtime-session-id",
"serverVersion": 13,
"viewModel": {},
"presentation": {
"storyText": "",
"options": [],
"battlePlayback": null,
"toast": null
},
"patches": [],
"meta": {
"requestId": "req_xxx"
}
}
```
协议约束：
- 前端不再提交完整 `gameState` 作为后端运算依据。
- 前端提交的是“玩家意图”，不是“玩家已经算好的结果”。
- 后端返回的是“下一帧该怎么演”的展示模型，而不是只回一个零散字段。
---
## 8. 分阶段重构路线
## P0：先冻结边界，建立共享协议层
### 本阶段目标
把“前端只做表现，后端负责运行时真相”从口头原则变成工程边界。
### 主要任务
- 提取 `shared contracts`，把 `server-node` 对 `src/**` 的依赖逐步迁出。
- 固化统一的 API 响应结构、错误结构、`requestId`、版本字段。
- 明确运行时 API 命名空间与编辑器 API 命名空间。
- 新功能一律禁止再把正式运行时规则写回前端。
- 为关键运行时入口补健康检查、日志字段、耗时统计。
### 交付物
- 共享类型与 schema 目录
- 统一 API 约定文档
- 服务端模块边界草图
- 前端 SDK 基础层
### 验收标准
- `server-node` 可以不依赖 `src/**` 中的前端运行时实现继续编译。
- 新增运行时需求不再允许“前端先写一版、后端再补一版”。
## P1：把运行时状态与持久化解释权收回后端
### 本阶段目标
让后端成为运行时状态、快照、恢复和迁移的唯一解释者。
### 主要任务
- 建立 `runtime session` / `snapshot aggregate`。
- 将存档恢复、版本迁移、默认值补齐、schema 纠偏迁到后端。
- 把前端 `useGamePersistence` 收敛为“拉取快照 + 触发保存 + 接收 view model”。
- 设置、快照、自定义世界库统一归入运行时仓储接口。
- 明确哪些内容允许本地缓存，哪些必须以后端结果为准。
### 交付物
- 统一的运行时 session API
- 快照版本迁移服务
- 服务端持久化 schema 文档
### 验收标准
- 前端不再承担正式存档恢复迁移的主逻辑。
- 同一份存档的解释权只存在于后端。
## P2：把核心规则结算从前端迁到后端
### 本阶段目标
把“剧情推进、战斗、NPC、任务、物品、Build”这些真正影响状态的领域结算全部后端化。
### 主要任务
- 把 function 合法性过滤迁入后端。
- 把战斗结算、蓝耗、伤害、死亡、掉落、逃跑结果迁入后端。
- 把 NPC 交互决策、招募条件、关系变化、交易合法性迁入后端。
- 把任务推进 signal、奖励结算、运行时物品结果、Build 结果迁入后端。
- 前端收到的只是一份下一步展示所需的聚合 view model 与演出计划。
### 交付物
- 运行时 action resolver
- 统一领域服务接口
- 面向 UI 的 view model assembler
### 验收标准
- 前端点击一个选项时，发送的是 action，不是本地先算完再上传结果。
- 正式运行时的数值、资源、状态迁移不再依赖浏览器逻辑。
## P3：把 AI 编排彻底收口到后端
### 本阶段目标
让浏览器彻底退出正式运行时 AI 调用与 prompt 组装。
### 主要任务
- 把剧情生成、角色聊天、NPC 对话、自定义世界生成、任务生成、物品意图生成等统一后端执行。
- 清理前端正式运行时代码中的 AI fallback。
- 将 prompt 构造、模型容错、超时、重试、日志、SSE 转发统一收口到后端。
- 对需要复用的 prompt 纯函数进行共享层抽取，但执行权只留在后端。
### 交付物
- 后端 AI orchestration 模块
- 统一 SSE/streaming 适配层
- 精简后的前端 AI SDK
### 验收标准
- 浏览器正式运行时代码不再直接 import 大体量 AI 编排模块。
- 无后端时，正式运行时不再默默回退到另一套浏览器逻辑。
## P4：把编辑器与资产流程独立成正式后端模块
### 本阶段目标
让编辑器能力不再作为运行时副产物存在，而是成为有边界的工具后端模块。
### 主要任务
- 建立 `/api/editor/*`、`/api/assets/*` 等明确命名空间。
- 给编辑器写接口补权限、环境门禁、审计日志。
- 统一编辑器 JSON 读写、资产生成、任务查询接口。
- 前端编辑器组件全部改走统一 SDK，不再散落直连接口。
### 交付物
- editor API contract
- 统一 editor client SDK
- 生成任务与写盘适配器
### 验收标准
- 编辑器写接口不再散落在多个组件内部。
- 运行时 API 与编辑器 API 的职责边界清晰。
## P5：补齐质量门禁、部署路径和观测能力
### 本阶段目标
让这次后端化重构可以稳定上线，而不是只在本地联调成立。
### 主要任务
- 为后端补单测、接口测试和关键链路 smoke。
- 为前端补 contract 测试，确保 UI 不依赖本地规则。
- 建立 `Nginx/Caddy -> dist + /api` 的同域部署路径。
- 为流式接口补代理配置、超时、取消和日志。
- 为数据库迁移、备份、回滚预留脚本。
### 验收标准
- `web + server` 可以独立构建、独立测试、联合部署。
- 关键主流程至少具备一条可自动验证的 smoke path。
---
## 9. 具体迁移清单
## 9.1 优先迁移对象
- `src/hooks/useStoryGeneration.ts`
- `src/hooks/useGamePersistence.ts`
- `src/services/ai.ts`
- `src/services/aiService.ts`
- `src/services/storageService.ts`
- `src/services/authService.ts`
- 编辑器持久化模块与 `src/editor/shared/jsonClient.ts`
## 9.2 优先抽离到共享层的内容
- 领域类型定义
- zod schema 或等价校验协议
- API 请求与响应 contract
- 纯序列化函数
- 前后端都要认识的 enum / id / status 常量
## 9.3 不建议抽到共享层的内容
- 依赖数据库、文件系统、LLM、日志的服务
- 正式运行时规则执行器
- 存档迁移执行器
- 资产生成任务调度器
---
## 10. 实施顺序建议
推荐顺序如下：
1. 先抽共享类型与协议，切断 `server-node -> src/**` 的反向依赖。
2. 再把运行时 session、快照解释权、存档迁移收回后端。
3. 再迁核心规则结算，让前端从“业务执行层”退回“表现协调层”。
4. 然后彻底收口 AI 编排，移除正式运行时浏览器 fallback。
5. 最后归整编辑器 API、部署路径、测试门禁和观测能力。
不建议的顺序：
1. 先零散把几个接口改成后端。
2. 继续保留前端完整 fallback。
3. 最后再补共享层和协议。
这个顺序会把“双份逻辑并存”的过渡期拖得很长，后面会越来越难收口。
---
## 11. 风险与控制点
- 最大风险不是“迁不动”，而是长期维持双份规则。
- 后端化期间必须避免再往前端加新的正式运行时规则。
- 协议演进要带版本号，否则快照和 UI 很容易错位。
- 前端瘦身不能牺牲移动端一屏体验，表现层拆分仍要遵守移动端优先。
- 编辑器 API 必须和正式运行时隔离，不要为了方便继续走混用路径。
---
## 12. 一句话结论
这次重构的核心不是“把几个请求改成走 Express”，而是：
**把项目从“前端主导运行时、后端承接部分接口”的过渡架构，升级成“Express 后端统一持有运行时真相，前端只负责表现和交互”的正式工程架构。**

5
docs/planning/README.md
View File

@@ -3,12 +3,10 @@
## 当前入口
- [ENGINEERING_DEAD_CODE_AND_HIDDEN_BRANCH_CLEANUP_PLAN_2026-04-21.md](./ENGINEERING_DEAD_CODE_AND_HIDDEN_BRANCH_CLEANUP_PLAN_2026-04-21.md)：面向无用历史代码、隐形多数据链路和半成品实现的一轮工程大清洗执行计划，强调先建台账、再删重收口、最后恢复主工程可读性。
- [CURRENT_GAME_ITERATION_PRIORITIES_2026-04-03.md](./CURRENT_GAME_ITERATION_PRIORITIES_2026-04-03.md)：当前阶段最值得优先做什么、为什么，以及它和审计/PRD 的对应关系。
- [../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)：当前创作入口、Agent session、结果页自动保存、作品库与进入世界主链的正式文件级重构基线；涉及目录落位、命名规范、阶段验收与工作包拆分时优先看这一份。
- [../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)：当前平台入口、继续游戏、角色选择、RPG runtime 与 runtime story 主链的正式文件级重构基线；涉及入口壳层、session、runtime、story、route/service/repository 拆分时优先看这一份。
- [CURRENT_AGENT_CREATION_FLOW_OPTIMIZATION_PLAN_2026-04-20.md](./CURRENT_AGENT_CREATION_FLOW_OPTIMIZATION_PLAN_2026-04-20.md)：创作链高层目标、冻结边界与执行顺序说明；文件级拆分与阶段验收以创作链重构执行方案为准。
- [EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md](./EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md)：基于“前端只做表现、逻辑与数据全部后端化”的工程重构规划。
- [EXPRESS_BACKEND_PARALLEL_WORKSTREAM_PLAN_2026-04-08.md](./EXPRESS_BACKEND_PARALLEL_WORKSTREAM_PLAN_2026-04-08.md)：将后端化重构拆成可并行推进、尽量不冲突的任务流与协作顺序。
- [../technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md](../technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md)：当前后端唯一落地口径，后续排期涉及服务端、数据真相或 SpacetimeDB 时优先按这一份判断方向。
- [BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md](./BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md)：北京市方向 13 / 21 / 24 的统一判断、共用材料框架和准备顺序。
- [BEIJING_DIRECTION13_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION13_APPLICATION_MATERIALS_2026-04-14.md)：方向 13 软件智能化提升奖励的硬门槛、必交材料、底稿建议和证据清单。
- [BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md)：方向 21 “创赢未来”成长计划的报名表、BP、Demo 和融资规划整理。
@@ -18,4 +16,5 @@
- 需要排期、拆阶段、判断先修基线还是先加功能时，先看这份。
- 当前如果要推进创作链或 RPG 运行时主链重构，先看上面的两份 `2026-04-21` 执行方案，再回来看高层优先级和冻结边界。
- 涉及后端方案时，不再参考已删除的 Express / Node 规划文档，统一回到 Rust / SpacetimeDB 当前基线。
- 这份文档大量引用了经验文档、工程审查和 PRD，适合作为跨文档导航页使用。