lhk229
2f3dd86fb3
WP1（本轮只改生产代码，测试由下一工作包处理）： - 新增 static_delegate_lineage_counters：沿 repair_of_delegation_id 反向重放整条 delivery 链，现算目标节点的 (repair_depth, clarification_round)。二者都是运行时 派生值，故意不落盘——若给 StaticDelegateDeliveryRecord 加 repair_depth 字段并用 #[serde(default)] 兜底，磁盘上已有的返工记录会读出 0，深度门失效，等于让 “返工的返工”漏洞原样复活（fail-open，不可接受）。链上推断对历史记录反而是精确 的：#165 之前不存在 NeedsUserInput，老记录天然被正确分类为“非澄清”。 传播规则：R3 根节点 depth=0/round=0；R1 澄清跳 round=parent.round+1、depth 不变 （不重置深度，否则可插一次澄清洗掉返工深度变成无限返工）；R2 返工跳 depth=parent.depth+1、round 重置为 0（返工后重新开工，不能吃掉澄清轮次预算）。 反向重放遇到重复 id、缺失节点或跳数超过 STATIC_DELEGATE_LINEAGE_MAX_HOPS 时 fail closed，返回 (u32::MAX, u32::MAX) 使调用方的门必然拒绝。 - 抽出 static_delegate_original_is_awaiting_clarification 作为“这一跳是否续接自 澄清”的唯一权威判据源，validate_static_delegate_repair_request_at 与 validate_static_delegate_clarification_continuation_at 共用，避免两处口径漂移。 - 重写 validate_static_delegate_repair_request_at 里原先无差别拒绝返工深度>=1 的 门：先用共享判据分类候选是澄清续接还是质量返工；返工路径按链上 depth 校验， 错误文案原样保留“静态委派返工深度最多为 1”（现有测试已断言该字符串）；澄清 路径改为按链上 round 校验，用新文案“静态委派澄清轮次已达上限”。函数签名不变。 - 澄清轮次上限按 source 区分：新增 static_delegate_clarification_round_limit_at， 通过 read_game_creator_agent_runtime_run_profile_binding 读取 binding.source， AGENT_RUNTIME_SUPERVISOR_GAME_CHAT_SOURCE 取 1，其余取 3——game-chat 单主路径 定位零打扰，#165 从未承诺给它 3 轮预算。 验证：cargo check --all-targets 通过。cargo test 里 tests::collaboration::static_deliveries::clarification_continuation_chain_supports_multiple_rounds 按预期失败——它断言的是旧的“D2->D3 必被返工深度门拒绝”行为，新逻辑下 D2->D3 是 合法的第 2 轮澄清续接，测试留给下一工作包更新。project_supervisor_concurrent_repair_dispatch_creates_exactly_one_delivery 偶发失败，经对比 20 次 vs 20 次基线（约 10%-15% 失败率两边相当）确认是本机既有的 并发计时 flaky 测试，非本次改动引入的回归。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AI Native Visual RPG
一个以“AI 叙事 + 本地规则 + 像素演出”为核心的视觉 RPG 原型。
当前已经具备这些主要能力：
- 世界与角色选择
- AI 剧情推进与流式对话
- 战斗演出、NPC 战斗、切磋
- NPC 交易、送礼、求助、招募
- 宝藏交互
- 同伴跟随与战斗
- 游戏主流程内嵌的角色资产工坊、自定义世界实体编辑与角色形象编辑
- 自动存档与继续游戏
运行
前置条件：
- Node.js
- Rust / Cargo
- SpacetimeDB CLI
安装依赖：
npm install
准备环境变量：
- 复制
.env.example为.env.local - 填入
LLM_API_KEY/ARK_API_KEY - 按需设置
VITE_LLM_MODEL - 如需启用阿里云短信验证码登录，填写
ALIYUN_SMS_ACCESS_KEY_ID、ALIYUN_SMS_ACCESS_KEY_SECRET，并确认SMS_AUTH_PROVIDER="aliyun" - 本地联调短信登录时，建议将
VITE_AUTH_ALLOW_DEV_GUEST设为false，避免开发模式自动进入游客账号而跳过登录页 - 如需打印完整 prompt/output，可把
VITE_LLM_DEBUG_LOG设为true
启动开发环境：
npm run dev
补充说明：
npm run dev会启动 SpacetimeDB standalone、独立bgfilter-worker、Rustapi-server、主站 Vite 与后台 Vite，适合完整联调；内部 worker ready 后才启动 API。- 主站默认地址是
http://127.0.0.1:3000，后台可从http://127.0.0.1:3000/admin/进入，也可直连http://127.0.0.1:3102。 - 五个模块可独立启动：
npm run dev:spacetime、npm run dev:api-server、npm run dev:bgfilter-worker、npm run dev:web、npm run dev:admin-web；其中dev:api-server会安全带起同 runner 的 BgFilter worker 依赖。 - 如需自动刷新后端模块，使用
npm run dev -- --watch；其中spacetime-module改动后只会重新发布模块，不会重启 standalone，Rust 源码改动会把api-server与bgfilter-worker作为一个组合单元重启。主站和后台前端源码变化交给 Vite 自身 HMR，不由外层 watcher 重启。非 watch 模式下可在npm run dev终端输入rs api-server、rs bgfilter-worker、rs web、rs admin-web、rs spacetime或rs all，其中rs spacetime也是只重新发布模块。
构建生产包：
npm run build
常用检查
类型检查：
npm run lint
编码检查：
npm run check:encoding
内容引用校验：
npm run check:data
编辑器 override 校验：
npm run check:overrides
关键内容 smoke 检查：
npm run check:smoke
一键内容检查：
npm run check:content
主要结构
主运行时：
主流程内嵌编辑能力：
- src/components/image-editor/ImageCanvasEditorView.tsx
- src/components/rpg-creation-editor/RpgCreationEntityEditorModal.tsx
- src/components/rpg-creation-asset-studio/RpgCreationRoleAssetStudioModal.tsx
核心数据：
- src/data/scenePresets.ts
- src/data/characterPresets.ts
- src/data/npcInteractions.ts
- src/data/treasureInteractions.ts
文档入口
docs/ 已在 2026-05-15 完成压缩整理，旧 PRD、设计、审计、阶段计划和技术流水账不再作为实现依据。当前只读取：
- docs/README.md：当前文档总入口。
- docs/【项目基线】当前产品与工程约束-2026-05-15.md：产品、命名、UI、协作和废弃路线。
- docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md：DDD 边界、API 分组、SpacetimeDB schema 规则和表目录。
- docs/【玩法创作】平台入口与玩法链路-2026-05-15.md：创作入口、草稿架和各玩法当前口径。
- docs/【开发运维】本地开发验证与生产运维-2026-05-15.md：本地启动、检查、部署、埋点和运营查询。
- UI_CODING_STANDARD.md：像素 UI 资产与编码规范。