lhk229
e43133875a
生产实测：出 GDD 后点「修改」而不是「批准」，修订委派从头到尾建不出来。盘上现场 （gameagent-c6948da6 / gameagent-347c9786）逐层剥出三个独立缺陷，前两个叠在一起， 修掉上层才露出下层。 1. claim 快照与 delivery 全等比较 claim 的 structuredResult 是「父 Agent 当时观察到了什么」的冻结快照；审批把 delivery 从 EvidenceReady 原地改写成 UserRevisionRequested 后，快照仍停在 EvidenceReady。claim 提交（含幂等重放）按全等判，于是 agent.run_status 每次 重放都 failed，Supervisor 永远拿不到回执。实测空转 43 轮，报「静态委派 claim 与 delivery 身份或结果冲突」。 改为「delivery 是不是 receipt 的合法后继」：除 contractStatus 外每字段逐字 不变、且方向唯一（EvidenceReady → UserRevisionRequested）才放行。原型没有 claim 这层快照，单一真相就地改，结构上不存在这个冲突。 2. park 死锁（被 1 掩盖） 修掉 1 之后 barrier 能正常求值了，userRevisionPending=1 却被 has_waiting() 计成「有在等的委派」，main_loop 于是 park 成「等待专业 Agent 委派回执 / 回执全部 ready 后自动唤醒当前父 run」——那条回执只能来自本 run 自己要创建的修订委派，等的是自己。实测 8 分钟零事件。 has_waiting() 里那个计数是承重的：三处自动恢复路径靠它挡住自动唤醒， runtime_tools/delivery.rs 现场还有 debug_assert 钉着这份依赖。所以不动它， 另加 has_external_wait()（只计 waitingDelegations / unknownContractStatus）， 两处 park 决策点改用它。两个谓词问的是相反的问题：自动恢复该不该收手 vs 当前这轮该不该 park。落进 main_loop 本来就写好的 user_revision_pending 分支 （phase=planning、next_step=调用 agent.delegate）即可。 3. 用户修订与质量返工共用「唯一返工轮」文案 用户修订跳带 repairOfDelegationId 但不是澄清续跑，落进 Repair 分支拿到 「这是对已认领委派 X 的唯一返工轮」——用户第一次点修改就被告知只能改这一次。 counter 层早就正确（lineage_counters 对该跳原样继承 depth/round），错的只有 这句话。新增 StaticDelegateHopNote::UserRevision，判据是原 delivery 的 contractStatus，并同澄清分支一样加 target == project-planning 门，做游戏 / 做素材的返工跳逐字保持 Repair——那句话是它们 replaceExisting=true 的唯一授权 信号。playbook 第 6 条同步改成「约束的是单条 delivery 不是整条链」。 原型对应的是 USER_REVISION_SOFT_LIMIT = 16，且超过只提示不拒绝。 守门三条，都验过非空转： - revise 端到端补上此前缺失的那一步——mark 与 dispatch 之间的 claim 重放，正是 生产上唯一会失败的地方；并断言 !is_clear() && !has_external_wait() && has_waiting() 三者同时成立。把比较改回全等即复现生产原文错误。 - 128 种计数组合的 detail↔barrier 等价性测试里写死两个谓词的分叉点，合并回一个 就会炸。 - user_revision hop note 不得含「唯一返工轮」，须含「不消耗返工深度」「不是最后一轮」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Genarrative / 陶泥儿
一个 AI 原生互动内容与小游戏平台，当前主站聚焦图片画布创作、项目与素材管理，以及账号、钱包和后台管理等平台公共能力。
当前已经具备这些主要能力：
- 图片画布编辑、项目与素材管理
- 图片、视频、音频等外部生成任务
- 账号、钱包、充值、兑换码与个人资料
- 后台运营、配置与生产运维工具
- AI 游戏创作独立 App
运行
前置条件：
- Node.js
- Rust / Cargo
- SpacetimeDB CLI
安装依赖：
npm install
该命令会按根 package.json 的 npm workspaces 一次安装主站、Admin、Mobile、Desktop、AGC、Preview Deployer、内部 packages 与工具依赖；仓库只使用根 package-lock.json，不要在子目录单独执行 npm install / npm ci 或提交嵌套 lockfile。
准备环境变量：
- 复制
.env.example为.env.local - 只填写本次联调所需配置；不要提交
.env.local、密钥、Token 或其它本地认证信息 - api-server 环境变量和 Provider 配置以
.env.example及当前开发运维文档为准
启动开发环境：
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
主要结构
主运行时：
- src/active-main.tsx
- src/ActiveApp.tsx
- src/AuthenticatedApp.tsx
- src/routing/activeAppRoutes.tsx
- src/components/platform-entry/PlatformEntryActiveFlowShell.tsx
创作与项目能力：
- src/components/image-editor/ImageCanvasEditorView.tsx
- src/components/creation-home/CreationLandingView.tsx
- src/components/project/ProjectGalleryView.tsx
文档入口
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 资产与编码规范。