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

feat: restore generation draft persistence

Browse Source
This commit is contained in:
kdletters
2026-04-25 11:41:09 +08:00
parent a6029639b0 03acbc5cb1
commit 2549a93379
60 changed files with 38221 additions and 382 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/audits/engineering/SERVER_NODE_FREEZE_AND_DEPRECATION_2026-04-24.md
View File

@@ -38,3 +38,15 @@
2. 确认前端不再通过任何路径调用 Node 后端能力。
3. 删除旧脚本、旧 smoke、旧 manifest 与 `server-node/` 目录。
4. 删除冻结基线检查中对历史引用的豁免。
## 6. 已确认迁移项
### 6.1 场景幕背景图提示词
2026-04-25 已把旧 Node 自动资产链路中的场景幕背景图提示词包装迁移到 Rust 主线：
1. 旧来源：`server-node/src/services/customWorldAgentAutoAssetService.ts` 的 `buildSceneActPrompt(...)`。
2. 新主源：`server-rs/crates/api-server/src/custom_world.rs` 的 `build_scene_act_background_image_prompt(...)`。
3. 使用位置：`generate_draft_foundation_act_backgrounds(...)` 收集 `sceneChapterBlueprints[].acts[]` 后，先构造幕背景图专用提示词，再调用 `generate_custom_world_scene_image_for_profile(...)`。
4. 保留语义：世界名、场景名、幕标题、幕摘要、幕目标、过渡钩子、主角色、辅助角色、世界气质、背景描述，以及“只生成环境背景，不出现角色立绘、站位 UI、对白框、按钮或文字”的约束。
5. 迁移边界：`server-node/` 仅作为历史来源说明，不再参与运行；后续调整统一修改 Rust 主源。

7
docs/design/CREATION_WORK_CARD_DELETE_ICON_DESIGN_2026-04-24.md
View File

@@ -6,7 +6,10 @@
## 落地规则
- 作品卡右上角固定展示删除 icon，底部主操作区只保留继续创作、查看详情、体验等正向操作。
- 作品卡整体就是继续创作 / 继续完善 / 查看详情入口，不再在底部展示“继续完善”等重复主按钮。
- 作品卡右上角固定展示删除 icon，底部主操作区只保留体验等必须独立触发的正向操作。
- 点击作品卡任意非独立按钮区域都进入继续完善链路；点击删除或体验时不得冒泡触发作品卡打开。
- 作品卡保留键盘可访问性：焦点落在卡片时按 Enter 或空格等同点击作品，焦点落在删除 / 体验按钮时只执行对应按钮动作。
- 删除入口不按发布状态隐藏：草稿、已发布作品均可删除。
- 删除入口不按玩法类型隐藏：RPG、大鱼吃小鱼、拼图作品均应在创作页可删除。
- 点击删除前保留浏览器确认弹窗，避免误触；删除中仅禁用当前作品卡的删除 icon。
@@ -18,3 +21,5 @@
- 大鱼作品按 `sourceSessionId` 删除创作 session，并同步清理消息、素材槽和运行快照。
- 拼图作品按 `profileId` 删除作品 profile，并同步清理来源 Agent session、消息和入口运行快照。
- RPG 已发布/持久草稿按 `profileId` 走既有自定义世界删除链路；纯 Agent session 草稿按 `sessionId` 走 owner-only session 删除过程，并清理消息、操作与草稿卡。
- 自定义世界 Agent 的异步进度写回必须通过 `upsert_custom_world_agent_operation_progress` 过程落到 SpacetimeDB，`server-rs` 只做字符串入参与过程封装，不在 API 层维护额外进度状态。
- `server-rs` 的删除路由使用 Axum 标准 `Path(sessionId)` 提取参数，并在进入 SpacetimeDB 前做 owner-only 与空值校验，避免 handler 签名和过程入参漂移。

12
docs/design/PLATFORM_HOME_PUBLIC_BROWSE_AND_LOGIN_MODAL_GATING_DESIGN_2026-04-19.md
View File

@@ -71,6 +71,7 @@
弹窗内默认只保留：
- 标题：`登录账号`
- 登录方式页签：`短信登录` / `密码登录`
- 手机号输入框
- 验证码输入框
- 获取验证码按钮
@@ -88,6 +89,17 @@
- “先登录再同步进度”这类描述性文案
- 占据视觉主体的装饰信息块
## 3.2.1 登录页签落地约束
账号面板需要把短信验证码登录和密码登录拆成互斥页签，避免两个登录表单在同一个面板里上下堆叠。
- 同时开放短信与密码登录时，面板顶部展示两个居中的文字页签，当前页签使用深色字重和短下划线强调。
- 只渲染当前页签对应的输入区；切换页签不弹出新面板，不展示二维码入口。
- `短信登录` 页签包含手机号、验证码、获取验证码和主按钮。
- `密码登录` 页签包含手机号/邮箱、密码、主按钮和忘记密码入口。
- 未开放某个登录方式时不展示对应页签，避免用户进入不可用表单。
- 移动端页签保持等分点击区域，输入框与按钮宽度仍随弹窗收缩。
## 3.3 登录成功后的行为
- 手机号登录成功后，关闭弹窗

4
docs/experience/PC_WORLD_CREATION_LAYOUT_OPTIMIZATION_2026-04-24.md
View File

@@ -24,4 +24,8 @@
- PC 端使用更明确的 `xl:grid`、固定信息侧栏和更小间距，让主内容首屏承载更多信息。
- 卡片在 PC 端降低无效高度，操作按钮与状态信息尽量同行展示。
- 作品卡片底部统计标签必须保留在卡片圆角范围内，不能为了压缩高度让标签贴边或被 `overflow-hidden` 裁掉。
- 卡片正文摘要优先缩短行数来给底部标签留空间；当标题、摘要或标签变长时，允许卡片自然增高。
- RPG 作品卡片点击行为按作品状态分流：草稿统一继续创作，已发布作品进入详情或世界；不要只依赖 `sourceType` 判断草稿可打开性。
- 整张作品卡片需要由卡片根节点承载点击与键盘打开能力，避免透明绝对定位按钮在真实浏览器中被判定不可见，导致自动化和用户点击不稳定。
- 保留现有 `platform-*` 视觉体系，避免引入新的 UI 系统。

14
docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md
View File

@@ -249,7 +249,19 @@
3. 针对初始同伴流程补一份单独的状态图 / 时序图
4. 对大 chunk 警告做代码分包
## 14. 一句话总结
## 14. SpacetimeDB 绑定桥接层要做同名去重
`server-rs/crates/spacetime-client` 里有一部分内容是围绕 SpacetimeDB 生成绑定补的手写桥接层。
经验：
- 新增 procedure、input type 或 mapper 时，先全局确认 `module_bindings/mod.rs`、`mapper.rs`、业务封装文件里是否已经存在同名声明
- `module_bindings/mod.rs` 同一个模块只保留一条 `pub mod` 和一条 `pub use`，不要同时放在 reducer 区和 procedure 区
- `mapper.rs` 的字符串枚举解析函数、API 入参结构只保留一个权威定义，业务侧统一复用
- 业务封装文件里同一个 procedure 只暴露一个客户端方法，避免 Rust 在编译期出现 E0428、E0252、E0119、E0592 这类重复定义错误
- 修复重复绑定时优先删除后追加的重复块，不要重写整文件，避免影响中文注释和生成绑定附近的大段内容
## 15. 一句话总结
这个项目真正的开发经验不是“怎么多写一个按钮”，而是：

4
docs/experience/README.md
View File

@@ -23,3 +23,7 @@
- 只需要读一份时，优先看 `PROJECT_WORK_EXPERIENCE_PLAYBOOK`。
- 做 UI 改动时，把本目录和根目录的 `UI_CODING_STANDARD.md` 对照着看。
- 做运行时流程改动时，把本目录和 `docs/audits/engineering/README.md` 一起看，能更快发现风险边界。
## 近期专项记录
- [RPG_DRAFT_IMAGE_PARALLEL_GENERATION_2026-04-24.md](./RPG_DRAFT_IMAGE_PARALLEL_GENERATION_2026-04-24.md)：记录 RPG 底稿阶段角色主形象与场景背景图并行生成约束。

32
docs/experience/RPG_ACT_BACKGROUND_PROMPT_SOURCE_2026-04-24.md Normal file
View File

@@ -0,0 +1,32 @@
# RPG 幕背景默认描述来源修正 2026-04-24
## 背景
草稿编辑器中“AI 生成幕背景”的“画面内容描述”曾出现类似“温馨员工宿舍第1幕背景；玩家入职后的首个落脚处；玩家会在温馨员工宿舍接住这一章的开场入口。”的默认文本。这类文本不是大模型直接写出的画面描述，而是前端或后端在缺少 `backgroundPromptText` 时，把地点名、幕标题、摘要规则句拼接出来的兜底文案。
## 落地约束
1. 幕背景图的默认画面描述必须来自草稿生成链路里的关键场景生成步骤，字段源为 `landmarks[*].actBackgroundPromptTexts[*]`。
2. `sceneChapterBlueprints[*].acts[*].backgroundPromptText` 只承接上述幕级大模型产物，不再用 `title`、`summary`、地点描述或规则句拼接。
3. 如果大模型漏产某一幕描述，后端规范化只保留空字符串，让后续生图前的 `backgroundPromptText` 校验暴露底稿质量问题，不能伪造可用默认文本。
4. 前端编辑器 sanitize 只展示已有 `act.backgroundPromptText`；缺失时留空，不能在 UI 层重新拼接默认描述。
5. 手动打开 AI 生成面板时，若字段为空，可由用户输入，但系统默认不替用户生成规则句。
## 当前实现
- `server-rs/crates/api-server/src/custom_world_foundation_draft.rs` 的关键场景框架 prompt 要求 LLM 为每个地点生成 3 条 `actBackgroundPromptTexts`。
- 草稿合成阶段通过 `build_scene_chapter_blueprints_from_landmarks` 把这些幕级描述写入 `sceneChapterBlueprints[*].acts[*].backgroundPromptText`。
- `normalize_scene_act_blueprint` 不再把缺失描述补成“标题 + 摘要 + 通用场景背景”格式。
- `src/components/rpg-creation-editor/RpgCreationEntityEditorShared.tsx` 不再用地点名、幕标题和 `actSummary` 生成 `backgroundPromptText` fallback。
## 验收要点
- 新草稿中每一幕的 `backgroundPromptText` 应该像自然的画面描述，包含主体、前中远景、站位空间、氛围识别点。
- 不应再出现“第1幕背景；玩家会在……”这类明显拼接句。
- 如果 LLM 漏掉 `actBackgroundPromptTexts`，生成幕背景图阶段应失败并提示缺少 `backgroundPromptText`，而不是静默使用拼接文案。
## 2026-04-24 并发限流错误处理补充
- 批量生成幕背景图时，`JoinSet` 子任务的成功值和失败值固定承载 `(chapter_index, act_index, message)`，用于把错误精确标记回对应章节幕。
- `Semaphore::acquire` 的 `AcquireError` 不能在子任务中转成裸 `String` 后直接使用 `?`，否则会破坏子任务统一错误类型并导致 `E0277`。
- 限流器异常应映射为同一组三元组错误，保持后续 `mark_scene_act_background_generation_error` 和部分成功保留逻辑可复用。

36
docs/experience/RPG_DRAFT_IMAGE_PARALLEL_GENERATION_2026-04-24.md Normal file
View File

@@ -0,0 +1,36 @@
# RPG 底稿图片并行生成说明 2026-04-24
## 背景
RPG 草稿生成进入底稿素材阶段后，角色主形象与场景幕背景图都依赖同一份结构化底稿，但二者之间没有数据依赖。旧流程先生成所有角色主形象，再生成场景背景图，导致用户需要串行等待两类图片任务。
## 落地约束
1. 角色主形象与场景背景图必须在 API 编排层并行发起，且类内每个角色、每一幕背景也必须同时调用生图接口，不能只做到“角色大类”和“背景大类”并行。这里的场景背景图指 `sceneChapterBlueprints[*].acts[*]` 中每一幕的 `backgroundImageSrc`，不是世界封面图，也不是只按章节或地点生成一张图。
2. SpacetimeDB reducer 只负责持久化操作进度和底稿写入，不承载外部 LLM / 图片生成调用。
3. 生图前必须已经有文本设定：角色主形象使用角色对象的 `visualDescription`；幕背景图使用对应幕的 `backgroundPromptText`。缺字段时应中断并暴露底稿质量问题，不能退回 `description`、`summary` 或通用兜底词直接生图。
4. 并行分支各自基于同一份底稿副本写入素材字段，完成后只合并背景图生成产物字段，避免覆盖角色图片字段或其他草稿内容。
5. 单个大类失败仍按原有失败语义终止底稿写入，保留“生成角色主形象失败”和“生成幕背景图失败”的进度提示。
## 当前实现
- `server-rs/crates/api-server/src/custom_world.rs` 在 `spawn_custom_world_draft_foundation_job` 中使用 `tokio::join!` 同时执行：
- `generate_draft_foundation_role_visuals`
- `generate_draft_foundation_act_backgrounds`
- 角色分支使用 `JoinSet` 把所有角色主形象任务一次性投递，返回后再按角色位置写入 `imageSrc` 与 `generatedVisualAssetId`。
- 背景分支使用 `JoinSet` 把 `sceneChapterBlueprints[*].acts[*]` 的每一幕背景任务一次性投递，返回后写入 `backgroundImageSrc`、`backgroundAssetId`、`generatedScenePrompt`、`generatedSceneModel`。
- `merge_generated_act_backgrounds` 只把背景图字段合并回角色分支副本，再进入后续草稿卡编译和 SpacetimeDB 写入。
- 幕背景 prompt 同时兼容 `backgroundPromptText`、`scenePromptText`、`visualPromptText`、`promptText`、`imagePromptText`、`backgroundPrompt`、`visualPrompt`，避免 LLM 输出字段别名导致整批背景图被误判缺失。
- 每个角色主形象、每一幕背景图都必须独立自动重试，单项最多尝试 3 次。幕背景图允许部分成功：只要至少一幕成功，就必须保留已成功写入的 `backgroundImageSrc` 并继续生成草稿卡；全部幕都失败时才把素材阶段标记为“生成幕背景图失败”。
- 图片任务仍然一次性投递，保证角色与幕背景两类任务不回退到串行编排；但真正请求上游生图服务时必须共用并发闸门。并发数由 `GENARRATIVE_DRAFT_ASSET_GENERATION_MAX_CONCURRENT_REQUESTS` 或 `DRAFT_ASSET_GENERATION_MAX_CONCURRENT_REQUESTS` 配置，默认 4，避免固定为 2 导致多角色、多幕草稿总耗时过长。
- 幕背景图失败文案必须带第几章、第几幕和幕标题，不能只显示“第1幕 / 第2幕 / 第3幕”，否则多章节同名幕会被用户误认为同一失败项重复上报。
- 中止或部分失败前必须持久化已经成功生成的部分底稿到会话 `draftProfile`，不能因为某个角色或某一幕失败而丢掉其它已生成的 `imageSrc / generatedVisualAssetId / backgroundImageSrc / backgroundAssetId`。
- 每一幕自动生图必须记录 operation、session、第几章、第几幕、sceneId、sceneName、attempt、elapsedMs 与供应商真实错误，避免再次出现只看到“生成幕背景图失败”但无法定位哪张图、哪次请求、哪个上游原因的问题。
- 前端 `CharacterAnimator` 对带 `generatedVisualAssetId` 但尚无 `animationMap` 的自定义角色，所有状态优先渲染生成主图；只有真正发布了动作集后才按动作帧播放，避免运行或战斗状态回落到模板 sprite。
## 后续注意
如果后续图片供应商出现强限流，再在网关层做队列或供应商侧限流；不要在 RPG 底稿编排层恢复逐张串行，否则会重新退化成多张图片总耗时累加。

30
docs/experience/RPG_ROLE_VISUAL_DESCRIPTION_CHAIN_2026-04-24.md Normal file
View File

@@ -0,0 +1,30 @@
# RPG 角色形象描述数据链路核查 2026-04-24
## 结论
草稿生成阶段会让大模型为每个可扮演角色和场景角色生成 `visualDescription`，该字段是角色主形象生成和资产工坊“形象描述”输入框的同一份默认文本来源。
本次核查发现前端 `normalizeCustomWorldProfileRecord` 曾在规范化 `playableNpcs` / `storyNpcs` 时丢弃 `visualDescription`、`actionDescription`、`sceneVisualDescription`。因此后端草稿 JSON 中有大模型生成的文字，但草稿进入前端编辑器后，资产工坊可能只能回退到 `description`，用户看不到真正的角色形象文字描述。
## 数据链路
1. 后端草稿生成：`server-rs/crates/api-server/src/custom_world_foundation_draft.rs`
- 角色框架名单 prompt 要求 LLM 输出 `visualDescription`、`actionDescription`、`sceneVisualDescription`。
- `visualDescription` 定义为打开角色形象图像生成面板时默认填入的角色形象描述。
2. 后端角色主形象生成：`server-rs/crates/api-server/src/custom_world.rs`
- `generate_draft_foundation_role_visuals` 从角色对象读取 `visualDescription`。
- 缺失时直接失败，提示不能在角色形象设定文本生成前生图。
- 生图成功只写回 `imageSrc` 和 `generatedVisualAssetId`，不会覆盖 `visualDescription`。
3. 草稿持久化：草稿 profile JSON 保留角色对象字段，`visualDescription` 应与图片字段一起进入保存载荷。
4. 前端规范化：`src/data/customWorldLibrary.ts`
- `normalizePlayableNpc` / `normalizeStoryNpc` 必须保留三类资产描述字段。
5. 资产工坊展示：`src/components/rpg-creation-asset-studio/RpgCreationRoleAssetStudioModalImpl.tsx`
- modal 用角色对象构造 `baseRole`。
- `buildDefaultRolePromptBundle(baseRole)` 优先把 `role.visualDescription` 转成 `visualPromptText`。
- `RpgCreationRoleVisualSection` 的“形象描述” TextArea 展示 `visualPromptText`。
## 验收要点
- 草稿生成完毕后，打开某个角色的资产工坊，应在“形象描述”框看到 LLM 生成的 `visualDescription`。
- 如果角色有 `visualDescription`，缓存中的旧 `visualPromptText` 不应覆盖它。
- 如果角色缺 `visualDescription`，才允许前端回退到更弱的字段或缓存文本。

24
docs/prd/AI_NATIVE_AGENT_FIRST_CUSTOM_WORLD_CREATOR_PHASE4_IMPLEMENTATION_PLAN_2026-04-14.md
View File

@@ -361,10 +361,26 @@
1. `id`
2. `name`
3. `role`
4. `publicMask`
5. `hiddenHook`
6. `relationToPlayer`
7. `summary`
4. `description`
5. `visualDescription`
6. `actionDescription`
7. `sceneVisualDescription`
8. `publicMask`
9. `hiddenHook`
10. `relationToPlayer`
11. `summary`
### 角色资产工坊默认文本来源
`visualDescription` 是角色主形象生成入口的默认形象描述主源，必须在可扮演角色 / 场景角色的草稿生成步骤中跟随角色一并生成，不允许在资产工坊打开时再用本地规则把 `description`、`role`、`tags` 拼成默认文案。
生成要求：
1. `description` 只写角色定位，控制在 8 到 18 个汉字内，用于角色卡摘要。
2. `visualDescription` 专门写角色外观，包含轮廓、服饰 / 身体特征、携带物或材质气质，不写性格规则和玩法说明。
3. `actionDescription` 专门写动作气质，用于动作生成默认文本。
4. `sceneVisualDescription` 专门写角色常出现的场景氛围，用于场景图或角色场景联动默认文本。
5. 资产工坊默认值优先读取 `visualDescription`，只有历史草稿缺失该字段时才允许回退到 `description`。
### 插入规则

53
docs/technical/AI_GENERATION_DRAFT_PERSISTENCE_DESIGN_2026-04-24.md Normal file
View File

@@ -0,0 +1,53 @@
# AI 生成过程草稿持久化设计（2026-04-24）
## 1. 背景
当前创作类模板已经具备 session / message / operation 级别的最终态落库能力，但部分流式生成只把模型增量推给前端。若 HTTP/SSE 连接、浏览器页面或 LLM 请求在最终解析前中断，用户只能看到短暂流式文本，服务端缺少可恢复的生成中间态。
本设计补齐“生成过程中已经生成的内容必须持续持久化”的机制，并要求该机制对所有创作模板统一生效。
## 2. 目标
1. 每次模板生成开始前创建或绑定一个 `ai_task`。
2. 模型每次产出可见文本增量时，写入 `ai_text_chunk`，并同步更新 `ai_task.latest_text_output` 与对应 stage 的 `text_output`。
3. 生成失败或连接中断时，不丢弃已经落库的 chunk；后续可用 `ai_task.latest_text_output` 作为续写上下文。
4. 成功解析并 finalize 后，将最终结构化结果继续写回各模板原有 session 表，保持现有业务快照不变。
## 3. 统一落库边界
### 3.1 真相表
- `ai_task`：记录一次模板生成任务的业务来源、状态、最新聚合文本、结构化结果。
- `ai_task_stage`：记录模板生成阶段状态；当前创作对话统一使用 `DraftGeneration`。
- `ai_text_chunk`：按 `sequence` 追加保存模型增量文本，是断点恢复的最小粒度。
### 3.2 适用模板
- 自定义世界创作 Agent。
- 解谜游戏创作 Agent。
- 大鱼吃小鱼创作 Agent。
- 后续新增模板必须复用同一生成草稿持久化工具，不允许只在 UI 内存保存流式文本。
## 4. 续写策略
1. 发起生成时，后端根据 `template_key + session_id + operation_id` 创建稳定 `task_id`。
2. LLM 流式回调收到 `replyText` 的最新可见文本后，计算相对上一次文本的增量；只有非空增量写入 `ai_text_chunk`。
3. 写入失败不应阻断当前生成主流程，但必须记录 warn 日志，避免因持久化瞬时失败导致用户生成直接失败。
4. 若最终解析失败，`ai_task` 保持 `Running` 或显式 `Failed`，已写入的 `latest_text_output` 仍可作为下一轮 prompt 的“已生成草稿”。
5. 下一轮续写 prompt 应优先带上最近未完成任务的 `latest_text_output`；本次先落地服务端 chunk 持久化能力，后续模板 prompt 可逐步消费该草稿。
## 5. 编码要求
1. 持久化逻辑放在 `server-rs/crates/api-server` 的通用工具中，由各模板路由接入。
2. 不引入 `server-node` 兼容分支。
3. SpacetimeDB 写入必须通过 `spacetime-client` 已生成绑定，不在 reducer 中访问网络或文件系统。
4. 所有新增 Rust 代码保留中文注释，且只做局部修改，避免重写包含中文的大文件。
## 6. 失败排查原文日志
1. RPG 草稿生成链路的模型输入与模型输出原文日志统一收口在 `platform-llm` 网关层，避免每个模板调用点重复实现。
2. 只有发生请求失败、上游非 2xx、响应读取失败、JSON/SSE 解析失败或空响应时，才将本次模型输入与已拿到的模型输出原文分别写入文件；正常成功生成不默认落盘原文，避免日志体积不可控。
3. 日志目录默认使用仓库运行目录下的 `logs/llm-raw`，可通过 `LLM_RAW_LOG_DIR` 覆盖；每次失败写成同一 trace 前缀下的 `*.input.json` 与 `*.output.txt` 两个 UTF-8 文件。
4. `*.input.json` 记录 provider、model、stream、attempt、maxTokens 与完整 messages；`*.output.txt` 记录上游 HTTP 原文、非流式响应原文、SSE 原始事件文本，或请求尚未到达上游时的错误摘要。
5. 文件名只使用时间戳、进程号、递增序号与安全化错误阶段，不包含用户输入、sessionId 或 API key；输入 JSON 不写入 API key。
6. 文件日志失败只写 warn，不影响草稿生成主错误返回；该日志仅用于本地开发与排障，不作为 SpacetimeDB 真相态。

35
docs/technical/CREATION_AGENT_PUBLISH_GATE_NORMALIZE_WRITEBACK_FIX_2026-04-24.md Normal file
View File

@@ -0,0 +1,35 @@
# 创作 Agent 发布门槛结果页归一化回写修正
日期：`2026-04-24`
## 1. 问题现象
`custom_world.publish_gate` 诊断日志显示：
1. `has_draft_profile=true`
2. `has_result_preview=true`
3. `has_world_hook=true`
4. `has_core_conflicts=true`
5. 但仍存在 `publish_missing_player_premise / publish_missing_main_chapter / publish_missing_first_act`
这说明接口可正常读取 session，问题不在 `GET /api/runtime/custom-world/agent/sessions/:sessionId` 本身，而在结果页 profile 回写到 session 时，发布门槛需要的部分结构字段没有稳定保留下来。
## 2. 根因
前端结果页通过 `normalizeCustomWorldProfileRecord` 把 `resultPreview.preview` 转成 `CustomWorldProfile`。该归一化模型原本主要服务作品库与运行时展示，只保留了 `settingText / summary / playerGoal / creatorIntent / anchorContent / sceneChapterBlueprints` 等字段，没有把后端发布门槛直接读取的顶层 `worldHook / playerPremise` 纳入 `CustomWorldProfile` 稳定字段。
当自动保存或发布前执行 `sync_result_profile` 时，前端会把归一化后的 profile 传回 SpacetimeDB。若这份 profile 中缺少顶层 `playerPremise`，且 `creatorIntent / anchorContent` 又未包含可读玩家切入字段，后端最终 publish gate 会继续报 `publish_missing_player_premise`。
## 3. 修复口径
1. `CustomWorldProfile` 显式声明 `worldHook / playerPremise` 为 Agent 发布快照兼容字段。
2. `normalizeCustomWorldProfileRecord` 保留顶层 `worldHook / playerPremise`，并在缺失时从 `creatorIntent.worldHook / creatorIntent.playerPremise / summary / playerGoal` 做最小回填。
3. 不在 UI 新增规则说明文案；这两个字段只作为后端发布门槛与 session 回写的稳定数据槽位。
4. 后端 publish gate 继续以 SpacetimeDB 中的 `draft_profile_json` 为最终真相源，前端只负责把结果页当前 profile 完整同步回去。
## 4. 验收标准
1. 从 `resultPreview.preview` 构建结果页 profile 后，`worldHook / playerPremise` 不会被前端归一化丢弃。
2. 自动保存或点击发布前执行 `sync_result_profile` 时，传回后端的 profile 保留发布门槛所需顶层字段。
3. 若当前草稿确实包含玩家切入与 `sceneChapterBlueprints[*].acts`，后端诊断日志不应再出现对应结构 blocker。
4. 若草稿真实缺失章节或第一幕，`publish_missing_main_chapter / publish_missing_first_act` 仍应保留，不做前端假放行。

11
docs/technical/CUSTOM_WORLD_ASSET_PROMPT_DEFAULTS_2026-04-24.md
View File

@@ -52,3 +52,14 @@
- 不再把 `server-node/src/prompts/characterAssetPrompts.ts` 作为主链修改目标。
- 默认描述字段必须由世界草稿生成阶段写入，前端只负责把字段填入输入框并允许用户编辑。
- UI 不默认展示规则解释文案，正式约束只进入后端 prompt。
## 5. 自动草稿素材回写约束
- 世界草稿自动素材生成与草稿页手动生成使用同一套 `server-rs/crates/api-server/src/custom_world_ai.rs` 场景图接口和 OSS/SpacetimeDB 资产持久化链路。
- 自动批量生成幕背景时，后端必须把已成功生成的 `backgroundImageSrc/backgroundAssetId/generatedScenePrompt/generatedSceneModel` 写回 `sceneChapterBlueprints[*].acts[*]`，不能因为同批某一幕失败而丢弃已成功图片。
- 某一幕连续重试仍失败时，只允许在该幕写入 `backgroundGenerationError` 作为诊断字段；只要至少一幕成功，草稿仍应完成并让前端展示成功图片。
- 只有全部幕背景均失败时，才把“生成幕背景图失败”作为草稿素材阶段失败原因保存。
- Rust 服务实际生图模型读取 `DASHSCOPE_SCENE_IMAGE_MODEL` / `DASHSCOPE_COVER_IMAGE_MODEL` / `DASHSCOPE_REFERENCE_IMAGE_MODEL`；兼容旧 `DASHSCOPE_IMAGE_MODEL`，避免 `.env.example` 中配置了模型但服务端仍使用硬编码模型。
- 自动草稿幕背景不能把 `backgroundPromptText` 直接作为最终 `prompt` 传给 DashScope；它必须像草稿页手动生成一样，把幕级描述作为 `userPrompt`，并用同一个地点对象的 `name/description/dangerLevel` 作为场景上下文，再由 `build_custom_world_scene_image_prompt` 统一拼入世界名、世界摘要、风格、玩家目标、场景名、场景描述和负面词。用户不修改默认描述直接点生成时，手动生成与自动草稿生成的正式生图上下文必须一致。
- 自动草稿幕背景的默认尺寸必须与草稿页手动生成默认尺寸一致，当前统一为 `1280*720`；不能在自动链路中单独改成 `1600*900`，否则同一 prompt 在同一模型下也可能因供应商尺寸支持或耗时不同而表现不一致。
- 批量自动生图失败日志必须保留 `AppError.details.message` 中的供应商真实原因，不能只记录 `AppError.message()` 的 HTTP 泛化文案，否则排查时只能看到“上游服务请求失败”，无法确认是尺寸、模型、限流、超时还是内容审核失败。

41
docs/technical/CUSTOM_WORLD_DRAFT_ASSET_PREVIEW_2026-04-24.md Normal file
View File

@@ -0,0 +1,41 @@
# 世界草稿图片生成与预览补齐说明
更新时间：`2026-04-24`
## 1. 检查结论
当前 server-rs 的世界底稿生成链路已经在 `draft_foundation` 后台任务中补齐两类图片：
1. `playableNpcs` 与 `storyNpcs` 中的每个角色都会调用角色主形象生成链路，并把 `imageSrc`、`generatedVisualAssetId` 写回底稿。
2. `sceneChapterBlueprints[].acts[]` 中的每一幕都会调用场景图生成链路，并把 `backgroundImageSrc`、`backgroundAssetId`、生成提示词与模型信息写回底稿。
图片生成后不落本地真值，而是通过 OSS `put_object -> head_object -> confirm_asset_object -> bind_asset_object_to_entity` 确认对象，并用兼容的 `/generated-*` 路径供前端读取。
## 2. 前端缺口
结果页的场景列表此前只把每个场景的第一张幕背景图作为场景卡封面。这样虽然后端已经生成了每一幕图片，但用户只能看到第一幕，无法在结果页确认同一场景下其他幕的图片是否存在。
## 3. 本次落地
1. 在 `CustomWorldEntityCatalog` 中增加每幕图片缩略条，来源为当前场景匹配到的 `sceneChapterBlueprints[].acts[].backgroundImageSrc`。
2. 保留原来的场景卡封面策略：第一幕背景图仍作为主封面，旧的场景图字段继续作为兜底。
3. 缩略条只展示已生成图片的幕，不额外暴露章节结构文本，避免结果页变成规则说明面板。
4. 增加结果页测试，覆盖同一场景下两幕背景图都能在前端以图片形式预览。
## 4. 验收点
1. 生成世界草稿完成后，角色页签中所有可扮演角色和场景角色能展示 `imageSrc`。
2. 场景页签中，每个场景卡片仍展示主封面。
3. 场景卡片下方能横向预览该场景所有已生成幕背景图。
4. OSS 未配置或上传失败时，后端任务应失败并把错误写入 operation，而不是生成伪本地路径。
## 5. 上游图片服务失败降级
`draft_foundation` 的底稿文本结构是进入结果页和继续编辑的主产物，角色主图、幕背景图属于可后补资产。若 DashScope 或 OSS 上游临时不可用，后台任务不应把整份底稿标记为失败。
本次补充后：
1. 角色主图分支失败时，operation 记录错误信息并继续使用未带角色图的底稿。
2. 幕背景图分支失败时，operation 记录错误信息并继续使用未带幕图的底稿。
3. 已成功的并行资产分支仍会合并回底稿，不会被失败分支覆盖。
4. 后续可通过资产工坊或单项生成动作补齐缺失图片。

3
docs/technical/README.md
View File

@@ -7,6 +7,8 @@
- [BIG_FISH_DIRECTION_TOUCH_CONTROL_2026-04-24.md](./BIG_FISH_DIRECTION_TOUCH_CONTROL_2026-04-24.md)：记录大鱼吃小鱼从固定摇杆改为屏幕首触点方向控制，并要求本地直达局在未操作时保持对象运动。
- [BIG_FISH_DIRECT_ROUTE_PLAYGROUND_2026-04-24.md](./BIG_FISH_DIRECT_ROUTE_PLAYGROUND_2026-04-24.md)：记录 `/big-fish` 大鱼吃小鱼玩法直达入口，明确复用现有 `BigFishRuntimeShell` 和本地占位运行态的调试边界。
- [PUZZLE_DIRECT_ROUTE_PLAYGROUND_2026-04-24.md](./PUZZLE_DIRECT_ROUTE_PLAYGROUND_2026-04-24.md)：记录 `/puzzle` 拼图玩法直达入口，明确复用现有 `PuzzleRuntimeShell` 和本地占位图运行态的调试边界。
- [CREATION_AGENT_PUBLISH_GATE_NORMALIZE_WRITEBACK_FIX_2026-04-24.md](./CREATION_AGENT_PUBLISH_GATE_NORMALIZE_WRITEBACK_FIX_2026-04-24.md)：记录结果页 profile 归一化回写丢失顶层 `worldHook / playerPremise` 导致 publish gate 继续误报结构 blocker 的根因，并冻结前端归一化保留发布字段的修复口径。
- [CUSTOM_WORLD_RESULT_ENTITY_GENERATION_FIX_2026-04-24.md](./CUSTOM_WORLD_RESULT_ENTITY_GENERATION_FIX_2026-04-24.md)：记录世界结果页在 Agent 草稿模式下新增场景、新增 NPC 生成成功但结果页字段不可用的根因，并冻结 `api-server` 生成归一化层补齐 profile 字段的修复口径。
- [ADMIN_CONSOLE_SERVICE_DESIGN_2026-04-23.md](./ADMIN_CONSOLE_SERVICE_DESIGN_2026-04-23.md)：冻结 Rust `api-server` 内后台管理服务首版方案，明确管理员用户名密码登录、管理员 JWT 鉴权、数据库概览、受控 API 调试台与同源管理页面的落地边界。
- [SPACETIME_MODULE_LIB_RS_SPLIT_EXECUTION_2026-04-23.md](./SPACETIME_MODULE_LIB_RS_SPLIT_EXECUTION_2026-04-23.md)：冻结 `server-rs/crates/spacetime-module/src/lib.rs` 的模块地图、二级落位点与迁移顺序，要求后续 SpacetimeDB 主工程改动按对应模块落位，不再继续堆回单大文件。
@@ -164,4 +166,3 @@

26
docs/technical/RPG_GENERATION_RESTORE_AND_PERSISTENCE_2026-04-24.md Normal file
View File

@@ -0,0 +1,26 @@
# RPG 生成流程刷新恢复与即时持久化设计（2026-04-24）
## 背景
- RPG 共创从 Agent 聊天页触发 `draft_foundation` 后进入生成过程页。
- 旧实现只持久化 `activeSessionId` 与 `activeOperationId`，刷新时恢复入口会无条件回到 Agent 聊天页。
- operation 失败后继续创作也会因为 operation 指针被清空而缺失生成页上下文。
## 目标
1. 生成中刷新网页后仍停留在生成过程页。
2. 生成完成后结果页内容第一时间落入作品持久化链路。
3. 生成失败后从创作入口继续处理该草稿时，优先回到生成过程页展示失败状态，而不是 Agent 聊天页。
## 落地规则
- 前端只保存恢复指针，不在 UI 持久层复制世界数据。
- `sessionStorage` 与 URL query 中增加生成页来源字段 `customWorldGenerationSource`，当前仅支持 `agent-draft-foundation`。
- 初始恢复时：
- 若存在 `activeOperationId` 且来源为 `agent-draft-foundation`，先进入 `custom-world-generating`。
- 否则若 session 已经可构建结果预览，进入 `custom-world-result`。
- 其他情况进入 `agent-workspace`。
- operation 进入 `completed` 或 `failed` 后仍保留 `activeOperationId`，直到用户离开、重新发起操作或清理工作区，保证刷新和继续创作能恢复完成/失败状态。
- 生成完成后由 `useRpgCreationResultAutosave` 在结果页立即保存。生成页跳结果页前必须先同步最新 session 并写入 `generatedCustomWorldProfile`，确保自动保存消费的是最新快照。
## 验收点
- 生成中刷新：URL/sessionStorage 可恢复 `custom-world-generating`，页面显示“世界草稿生成进度”。
- 生成失败刷新或继续创作：页面仍显示生成过程页和失败信息，不展示 Agent 聊天页。
- 生成完成：跳到结果页后触发 `upsertRpgWorldProfile`，保存请求带 `sourceAgentSessionId`。

12
docs/technical/RUST_LOCAL_AND_REMOTE_DEPLOYMENT_SCRIPTS_2026-04-22.md
View File

@@ -37,8 +37,9 @@ npm run dev:rust
4. 等待 `spacetime --root-dir=server-rs/.spacetimedb/local server ping http://127.0.0.1:3101` 可用。
5. 执行 `spacetime --root-dir=server-rs/.spacetimedb/local publish <本地数据库名> --server http://127.0.0.1:3101 --module-path server-rs/crates/spacetime-module -c=on-conflict --yes`，确保 publish 的签名身份与 standalone 的本地控制库一致，并在当前开发阶段允许新版模块表结构变化且发生 schema 冲突时清除旧模块数据。
6. 注入 `GENARRATIVE_API_*` 与 `GENARRATIVE_SPACETIME_*` 后启动 `cargo run -p api-server`；直接运行 `api-server` 时，如未显式设置 `GENARRATIVE_SPACETIME_DATABASE`，服务端也会向上查找 `spacetime.local.json` 作为本地默认库名。
7. 注入 `GENARRATIVE_BACKEND_STACK=rust`、`RUST_SERVER_TARGET`、`GENARRATIVE_RUNTIME_SERVER_TARGET` 后启动 Vite。
8. 任一子进程退出时，脚本回收其余子进程。
7. 等待 `http://127.0.0.1:<api-port>/healthz` 返回 HTTP 响应后再启动 Vite，避免前端初始化请求早于 Rust `api-server` 监听完成并在终端刷出 `ECONNREFUSED 127.0.0.1:<api-port>`。
8. 注入 `GENARRATIVE_BACKEND_STACK=rust`、`RUST_SERVER_TARGET`、`GENARRATIVE_RUNTIME_SERVER_TARGET` 后启动 Vite。
9. 任一子进程退出时，脚本回收其余子进程。
Vite 代理覆盖范围：
@@ -84,6 +85,13 @@ npm run dev:rust:logs -- --follow
1. 如果首页公开广场出现 `上游服务请求失败`，优先检查 `api-server` 错误详情里的 `ws://.../v1/database/<database>/subscribe` 是否指向了未发布的库。
2. `spacetime --root-dir=server-rs/.spacetimedb/local list --server http://127.0.0.1:3101` 应能看到 `spacetime.local.json` 中的库名；若没有，执行 `spacetime --root-dir=server-rs/.spacetimedb/local publish <本地数据库名> --server http://127.0.0.1:3101 --module-path server-rs/crates/spacetime-module -c=on-conflict --yes`。
3. 发布库名与 `GENARRATIVE_SPACETIME_DATABASE` 不一致时，`/api/runtime/custom-world-gallery` 会从 Rust `api-server` 返回 `502`，前端首页只能展示空态或错误提示，无法自行修复。
4. 如果 Vite 输出 `/api/auth/refresh`、`/api/auth/login-options` 或 `/api/runtime/custom-world-gallery` 的 `ECONNREFUSED`，先确认当前脚本是否已经打印 `等待 api-server 就绪` 并通过；正常情况下 Vite 只会在 `/healthz` 可访问后启动，不应再因为 Rust 监听未完成而代理失败。
编译警告治理：
1. Rust 本地栈启动日志应保持可行动，运行态未使用函数不应长期保留为普通编译警告。
2. 仅供测试断言使用的辅助函数使用 `#[cfg(test)]` 限定，避免进入 `cargo run -p api-server` 的普通二进制编译。
3. 已无调用入口且无迁移价值的映射函数直接删除；如果后续新增同类 SpacetimeDB 记录映射，再按实际调用路径补回，避免提前保留死代码。
## 3. Ubuntu 发布包脚本