收紧story与custom world迁移能力边界

docs/technical/README.md

@@ -14,6 +14,7 @@
 - [RUNTIME_STORY_TO_STDB_PHASE1_TRANSPORT_ABSTRACTION_2026-04-20.md](./RUNTIME_STORY_TO_STDB_PHASE1_TRANSPORT_ABSTRACTION_2026-04-20.md)：把 `runtimeStoryService` 改成可替换 transport，为后续 STDB provider 接入预留稳定边界。
 - [RUNTIME_STORY_TO_STDB_PHASE2_CONTRACT_DESIGN_2026-04-20.md](./RUNTIME_STORY_TO_STDB_PHASE2_CONTRACT_DESIGN_2026-04-20.md)：梳理 runtime story 从 Express 迁到 STDB 所需的聚合 view、procedure、mapper 与前端 provider 设计。
 - [RUNTIME_STORY_TO_STDB_PHASE2A_COMPAT_BRIDGE_2026-04-20.md](./RUNTIME_STORY_TO_STDB_PHASE2A_COMPAT_BRIDGE_2026-04-20.md)：确认 runtime story 当前 STDB/Express 快照真源分裂，并补一层只改 story 边界的 STDB 兼容桥。
+- [STORY_WORLD_TO_STDB_CAPABILITY_FIRST_PLAN_2026-04-20.md](./STORY_WORLD_TO_STDB_CAPABILITY_FIRST_PLAN_2026-04-20.md)：明确 story / custom world 后续迁移顺序应先拆 capability/provider，再逐段迁移纯逻辑，避免整块硬搬。
 - [TASK_AUTO_COMMIT_WORKFLOW_2026-04-20.md](./TASK_AUTO_COMMIT_WORKFLOW_2026-04-20.md)：任务完成后按文件边界自动提交的脚本与协作约定。
 - [NODE_DEV_STARTUP_HOTFIX_2026-04-20.md](./NODE_DEV_STARTUP_HOTFIX_2026-04-20.md)：`npm run dev` 启动失败的热修记录、根因与验证结果。
 - [NODE_SERVER_KNOWLEDGE_GRAPH_2026-04-08.md](./NODE_SERVER_KNOWLEDGE_GRAPH_2026-04-08.md)：当前 Node 运行时后端的技术栈、入口、鉴权、存储与接口知识图谱。

docs/technical/STORY_WORLD_TO_STDB_CAPABILITY_FIRST_PLAN_2026-04-20.md

@@ -0,0 +1,103 @@
+# Story / World 向 STDB 迁移：能力先迁、逻辑后搬实施方案（2026-04-20）
+
+更新时间：`2026-04-20`
+
+## 1. 为什么先迁能力，不先整块搬逻辑
+
+当前 `runtime story` 和 `custom world` 都不是“只差把逻辑换个地方跑”。
+
+真实问题有两类：
+
+1. 依赖面过大，很多 service 直接吃 `RuntimeRepositoryPort` 这类大接口
+2. `LLM / SSE / HTTP request / 账号鉴权 / snapshot/session 存取` 仍然缠在一起
+
+如果在这个阶段直接把整块逻辑搬去 STDB，会出现两种风险：
+
+1. 把 Express 耦合一并搬过去，结果不是迁移而是复制
+2. 在 STDB 里同时承接“确定性规则”和“非确定性外部能力”，边界会继续变脏
+
+因此后续迁移顺序固定为：
+
+1. 先拆能力口子
+2. 再给能力口子补 STDB provider
+3. 最后再搬只依赖这些能力口子的纯逻辑
+
+## 2. 迁移分层
+
+### 2.1 可以先收进 STDB 的能力
+
+这类能力适合先做成 capability/provider：
+
+1. runtime snapshot 读取与写回
+2. custom world session 读取与写回
+3. custom world profile / works 聚合读取
+4. runtime story state 聚合读取
+5. runtime story action 聚合写入结果
+
+它们的共同特点：
+
+1. 以数据真源为主
+2. 可以明确建模为 table / view / procedure
+3. 前后端 contract 可以稳定冻结
+
+### 2.2 不能直接塞进 reducer 的能力
+
+以下能力不应和纯规则一起直接塞进 STDB reducer：
+
+1. LLM 调用
+2. SSE 流式输出
+3. 图片 / 资产生成
+4. 长任务轮询与异步编排
+5. 旧 HTTP 鉴权链路
+
+这些能力应该保留在 Express 或 procedure / orchestrator 边界，直到它们被进一步拆清。
+
+## 3. 当前代码收口原则
+
+这一轮先不扩大兼容桥，而是先把依赖面收紧：
+
+1. `storyActionService` 只依赖 `RuntimeStoryCapability`
+2. `CustomWorldSessionStore` 只依赖 `CustomWorldSessionCapability`
+3. `CustomWorldAgentSessionStore` 只依赖 `CustomWorldSessionCapability`
+4. `listCustomWorldWorkSummaries` 只依赖 `CustomWorldWorkSummaryCapability`
+
+这一步的意义不是“已经迁完 STDB”，而是：
+
+1. 后续替换 provider 时，不再需要动整块 `RuntimeRepositoryPort`
+2. 测试 stub 会被迫只实现真实需要的能力
+3. 可以更准确地区分“真源能力迁移”和“业务逻辑迁移”
+
+## 4. 后续实施顺序
+
+### 4.1 Story
+
+1. 继续收紧 `runtime story` 所需 capability
+2. 为 `get state / resolve action` 设计正式 STDB provider contract
+3. 让 `storyActionService` 改为吃 provider，而不是直接认具体仓储
+4. 再把可确定性的结算逻辑逐段迁入 STDB
+
+### 4.2 Custom World
+
+1. 先把 `session / works / profile` 各自 capability 固化
+2. 为 `custom world session` 提供 STDB provider
+3. 为 `agent session` 的会话存取提供 STDB provider
+4. 保留 `LLM / asset / stream` 在 orchestrator 边界
+5. 等会话和作品真源稳定后，再搬纯状态推导逻辑
+
+## 5. 本轮落地点
+
+本轮只做一件事：
+
+1. 把 `story/custom world` 的 service 依赖从大仓储接口改成最小 capability
+
+本轮不做：
+
+1. 新增更大范围兼容桥
+2. 直接把 `custom world agent` 整块搬进 STDB
+3. 把 LLM / stream / asset orchestration 一起迁移
+
+## 6. 验收标准
+
+1. `server-node` 编译通过
+2. 相关测试 stub 不再依赖完整 `RuntimeRepositoryPort`
+3. 文档明确固定“能力先迁、逻辑后搬”的顺序