5 Commits

Author	SHA1	Message	Date
suzmii	028b20a590	修复清单快照误判：CAS 判据面收窄为「资源 + 版本」，预览起停不再触发用户可见拒收 ... - projectResourceLiveUpdateModel 新增 manifestCasFingerprint，按 { assets, versions } 判定同版本号冲突 - 同 revision 且判据面一致时，仅非 CAS 账目状态（preview 运行地址/端口、任务进度、项目名）变化改为 accepted 并让内容落地，revision 不推不退 - 判据面变化仍判 revision-conflict，保留「改了被保护内容却没推 revision」的可观测信号，不吞真实缺陷 - 新增回归用例：同 revision 仅预览状态变化必须被接受；同 revision 资产变化必须仍被拒收 - 变异验证：把判据改回整份 JSON 指纹后，新用例以 expected 'revision-conflict' to be 'accepted' 失败 - 定向验证：projectResourceLiveUpdateModel 17 passed、workspaceLauncherManifestMerge 5 passed、appSurface 413 passed、npm run typecheck exit 0、npm run check:encoding 4399 files passed、git diff --check 干净 - 同步 decision-log 与 pitfalls 记录 CAS 判据面契约与本次取证	2026-09-12 13:30:18 +08:00
suzmii	1b7261685c	登记素材上传配对的踩坑与覆盖边界：断言打在生产函数上，端到端 UI 未覆盖 ... - `pitfalls.md` 新增「素材上传不要把『上传前读到的 revision』贴到『上传后读到的清单』上」：现象（每次上传都先吃一条拒收提示）、根因（上传本身推进 revision，错配必然发生而非竞态）、处理（上传动作与配对读收进同一个函数，调用方拿不到中间那个 revision，也就没机会贴错）、同类文案坑（`unresolved` 三条进入路径里有两条重读是**成功**的，写成"读取磁盘清单失败"就是误报）、验证与变异，并记录关联文件与提交。 - 覆盖边界（按当下口径写清，防止后人误读）：断言打在生产函数 `uploadProjectAssetFilesAndReadSnapshot` 上 —— 它同时拥有上传与配对读，所以配对语义是真测的；但 AGC 侧**没有**「资源面板上传 → 拒收提示条」的端到端 UI 用例（现有 harness 只有聊天入口的 `/asset.upload`，资源面板 file input 无用例），因此「界面上不再出现拒收提示」是推理结论而非端到端断言，禁止当成端到端覆盖引用。 - 同一条边界同时写进 `projectResourceLiveUpdateModel.test.ts` 用例组头部，随断言一起走，避免只看测试文件的人误读。 - 纯文档 + 测试注释，无功能改动。	2026-09-11 22:19:14 +08:00
suzmii	006e9cc2f3	素材上传不再每次触发一次拒收提示：上传与清单配对读放进同一个函数 ... - 原缺陷：上传路径在上传**前**读 get_local_game_project_revision，上传完把那个**旧 revision** 交给 reloadManifestAfterAssetCommand；后者重新读盘拿**新清单**再打上旧 revision。上传本身会推进项目 revision（Rust advance_agent_runtime_project_revision_locked），于是这一对是撕裂的，「同 revision 不同指纹」被 projectResourceLiveUpdateModel 判成 revision-conflict —— 用户每上传一次素材就先看到一条「资源清单更新被拒收…」。 - projectResourceLiveUpdateModel.ts 新增 uploadProjectAssetFilesAndReadSnapshot：上传动作与"配对读"由同一个函数拥有，配对读复用既有 rereadAuthoritativeProjectManifestSnapshot（同一次读里配对 revision + 清单，并再读一次 revision 确认没被写盘插队）。调用方拿不到中间那个 revision，也就没有机会把它贴错。 - index.tsx 的 uploadResourcePanelFiles 改用它，删掉上传前那次 revision 读取与旧 revision 的传递。 - 附带文案误报：describeProjectManifestMergeRejection 的 unresolved 文案由「重新读取磁盘清单失败，请重新打开项目」改为「未能按磁盘清单重新对齐，请重新打开项目」。unresolved 有三条进入路径，其中两条**重读是成功的**（读到的一对比手上旧、或读到的是撕裂的一对），写成"读盘失败"是误报；新文案对所有路径都成立。WorkspaceLauncher.tsx 在"读到了但不采用"那一支补注释说明 stage 不是读失败。 - 断言：projectResourceLiveUpdateModel.test.ts 新增「素材上传后的清单快照必须配对」——假后端在上传时推进 revision，断言 merge 判 accepted 且 projectManifestMergeRejectionDecision 为 null（即"上传一次不产生拒收提示"），并附一条对照钉子显式写出旧形状、断言它必被判 revision-conflict；另新增 unresolved 文案不得包含"读取磁盘清单失败"的用例。 - 变异验证（提交前已跑）：把 uploadProjectAssetFilesAndReadSnapshot 还原成"上传前读 revision + 上传后读清单"→ 配对用例变红（并给出 revision-conflict 的失败信息），还原后复跑 15 passed。 - 门禁：projectResourceLiveUpdateModel 15 passed、workspaceLauncherManifestMerge 5 passed。	2026-09-11 21:33:54 +08:00
suzmii	f88e6aa5fe	清单快照被拒收不再静默：可见提示 + 强制重读磁盘真相 ... - WorkspaceLauncher：applyManifestSnapshot 拒收分支此前直接 return，改为必须先留痕（console.warn 记 decision/source/两个 revision）再走恢复； - 新增 manifestMergeNotice 状态与提示条，DOM 暴露 data-manifest-merge-decision / -stage / -source / -held-revision / -snapshot-revision 作为排障观察点； - 新增 recoverRejectedManifestSnapshot：重读磁盘 revision + 清单并重建 merge 状态，把被拒快照漏掉的新资源真正带进项目上下文； - 同一项目只允许一条恢复在飞，避免拒收成串到达时打满读取槽； - 重读期间若有更新的快照已被接受，绝不回退 revision（宁可报未解决，不放宽 CAS）； - scope-mismatch 仍只记日志不弹提示：串项目的快照对用户没有可执行语义； - projectResourceLiveUpdateModel：新增拒收判定、三阶段文案与 rereadAuthoritativeProjectManifestSnapshot（两次读 revision 夹一次读清单，撕裂就放弃）； - styles.css：新增 .launcher-manifest-merge-notices 绝对定位提示位，容器不吃点击，与 .game-resource-book-notices 同口径； - 新增 apps/ai-game-creator-shell/tests/workspaceLauncherManifestMerge.test.tsx：拒收可见 + 重读采纳 + 重读失败报未解决 + 不回退 revision + 串项目快照保持静默； - projectResourceLiveUpdateModel.test.ts 追加拒收可见性/重读三读/撕裂放弃/跨项目拒绝/revision 非法/三阶段文案可区分六条断言。	2026-09-11 19:23:25 +08:00
menghao	03a4410272	game agent无限画布开发 (#136) ... 主要工作是共享同一套“画布内核与通用 UI 源码”，网站和 Tauri 只分别实现宿主适配层。 --------- Co-authored-by: 段舒康 <kdletters@qq.com> Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/136 Co-authored-by: menghao <mh18530625731@163.com> Co-committed-by: menghao <mh18530625731@163.com>	2026-08-12 10:54:16 +08:00