同步master最新变更
合入当前主线的多窗口与配置更新 保留AGC画布交互和JSON识别修复 保留双方新增的项目排障记录并解决文档冲突
This commit is contained in:
@@ -2,6 +2,18 @@
|
||||
|
||||
> 用途：记录已经确认、会影响后续开发的长期技术/产品/协作决策。短期讨论不要写在这里。
|
||||
> 当前口径：历史条目的旧路径、旧版本和已退役对象只用于追溯，不构成现行实现依据；如与当前代码或 `docs/README.md` 冲突，以当前代码和最新专题文档为准。
|
||||
|
||||
## 2026-09-16 AGC 同 AppData 多窗口共享 Agent Runner
|
||||
|
||||
- 背景：双击或再次启动 AGC 客户端时报「应用启动失败」，启动日志为 `startup.runner.owner-lock.failed details=AI 游戏创作界面已由同一 AppData 目录中的其他进程运行`。原设计（2026-07-27 / 2026-08-23）要求同一 AppData 只有一个 GUI owner，第二个界面进程在 setup 阶段就失败退出。
|
||||
- 决策（锁语义）：`agent-runner.gui-owner.lock` 改为**界面参与锁** `agent-runner.gui-participant.lock`，以共享句柄打开，同一 AppData 的任意数量窗口可同时持有；Runner 的启动检查、attach 门禁与 watchdog 只用“能否独占取得该文件”判断是否仍有窗口存活。全部窗口退出后才关停 Runner 并清理 endpoint。
|
||||
- 决策（claim 采纳与发布）：窗口启动先**采纳**durable claim（同一 epoch/revision），只有 claim 缺失或不可读才发布新 claim；登录、refresh、退出或换号才发布新 claim（新 epoch + 本窗口 revision），成为新的登录态权威。同一 claim 的重复 attach 是幂等空操作，不再清空 Runner 登录态；只有 epoch 变化或携带明确登出参数才允许替换 / 清空。并发发布以最后一次成功写入的 claim 为准，落败窗口按最新 claim 有界重试。
|
||||
- 决策（事件与退出）：manifest 失效与 Runtime update relay 的接收端从单槽改为按 `event_sink_token` 去重的注册表并广播，发送失败只淘汰该接收端；GUI 退出先释放本窗口参与锁，仍有其它窗口时保留 Runner（`agent.runner.gui_exit.retained_for_other_windows`），最后一个窗口才请求关闭。Runner 启动失败时先按最新 endpoint 复用一次，避免两个窗口同时冷启动时的实例锁竞争被误报成启动失败。
|
||||
- 边界：本机 GUI ↔ Runner 协议方法与参数不变，不引入多 Runner、不做跨 AppData 会话共享；项目级 `.agent/project.lock` 不变，多窗口仍不能并行写同一项目；平台登录态 generation 单调与 claim 失配失败关闭语义保持不变；混用新旧版本二进制访问同一 AppData 不属于支持场景。
|
||||
- 验证：定向 Rust `runner::tests::gui_owner_*` 11 条与新增的参与锁多窗口 / 存活判定 / claim 采纳与轮换 / 同 claim 第二个窗口不清空登录态用例全部通过；真实 debug 二进制 Windows smoke 证明同一 AppData 两个 GUI 都完成 `startup.setup.complete`、只存在一个 `--agent-runner` 进程、关闭一个窗口后另一个窗口与 Runner 继续存活、最后一个窗口退出后 Runner 退出并删除 endpoint；`npm run check:encoding`、`npm run check:doc-index`、`git diff --check` 通过。
|
||||
- 未验证 / 已知环境问题：真实安装包双开需要重新构建发布后才能验证；`durable_provider_handoff_prevents_shutdown_even_when_corrupt`、`durable_provider_retry_prevents_shutdown_and_reopens_writes`、`runtime_interrupt_for_true_steer_decision_only_interrupts_older_provider_cursor` 三条用例在本机改动前的基线上即失败（Windows 安全对象 owner 校验与 Provider 请求重复），与本决策无关。
|
||||
- 关联文档：`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`（2026-09-16 节）、`docs/project-memory/plans/【里程碑】AGC同AppData多窗口共享Runner-2026-09-16.md`。
|
||||
|
||||
## 2026-09-16 图标图集自动拆图上限提高到 256
|
||||
|
||||
- 背景：AGC 图标图集自动连通域识别在一次生成中识别出 86 个区域，原有 64 片上限在后处理阶段阻断了请求；该上限同时影响 api-server 自动 / 手动切片、SpacetimeDB 批量落库和统一生成结果 item 数量。
|
||||
|
||||
@@ -8,6 +8,12 @@ JSON 的文本读取分支不等于卡面应该展示原始 State 摘要。卡
|
||||
|
||||
工作台向窗口标题栏发布运行项目时，若 effect 依赖普通函数派生的回调，发布 Context 会重新渲染工作台，进而再次发布并清理，形成更新深度循环。转发入口须稳定，并在提交阶段更新实际处理器引用；发布数据变化与卸载清理分开。回归测试必须组合真实窗口 Provider 和工作台消费者，只有独立画布测试无法覆盖这条反馈链；回归时用有界发布次数阻止测试失控。画布快速操作时暴露的更新深度错误，也须检查外层状态同步，不能直接归因于滚轮频率。
|
||||
|
||||
## 2026-09-16 从 Codex 里启动 AGC 客户端会看到被重定向的 `%APPDATA%`
|
||||
|
||||
- **现象**：在 Codex 会话里用 `Start-Process` 启动 `genarrative-ai-game-creator-shell.exe` 做排障时，子进程写 `C:\Users\<user>\AppData\Roaming\world.genarrative.ai-game-creator\...` 的内容会落到 `C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\...`；同一个 `Test-Path` / `Get-ChildItem` 命中的是重定向视图，只有 `\\?\C:\Users\...` 形式能区分真实路径。
|
||||
- **影响**：用 agent 拉起的客户端复现「多开 / 登录态冲突 / 锁文件被占用」类问题时，可能与用户双击开始菜单快捷方式的真实进程不是同一份 AppData，从而得出「两个实例没有互相冲突」或「日志里没有那条失败」的错误结论。
|
||||
- **处理**：把用户双击快捷方式（或从 Codex 之外启动）的进程作为唯一用户侧证据；核对待查文件时同时比对真实 `AppData\Roaming` 路径与 `Packages\...\LocalCache\Roaming` 路径；排障结论里写明客户端是「谁启动的」。
|
||||
|
||||
## Windows 已登记生图资产未刷新
|
||||
|
||||
Direct 工具桥会 canonicalize 项目根，事件中的路径可能带 `\\?\` / `\\?\UNC\`，而前端项目路径仍是普通盘符或 UNC。失效监听不能直接比较原始字符串；识别为同一项目后，用当前项目路径重读 manifest，保留项目切换与 revision 门禁。普通 `agc_generate_image` 成功提交也必须发出失效通知，不能依赖整轮 Agent 结束。回归需覆盖两种 Windows 前缀、其它项目事件拒收，以及 Agent 尚未结束和后续失败时已登记图片卡片仍可见。
|
||||
|
||||
@@ -51,6 +51,8 @@ SpacetimeDB crate、SDK、CLI / standalone 与生成 bindings 按 `2.8.3` 对齐
|
||||
|
||||
## AGC DirectProject 与 UI workflow
|
||||
|
||||
- AGC 的本地 `llm.customEnabled` 默认关闭，只能手动修改配置文件；开启后设置支持自定义 Responses 端点、读取 `/models`、勾选和预览 `visibleModels`。对话下拉只显示勾选项，LLM 请求经客户端凭据代理直连自定义上游；不会回退官方中转，平台资源服务仍使用账号权限。详见 AGC 后台模型别名与对话选择规范。
|
||||
|
||||
- DirectProject 对话先在完整历史中按回合/原始 item 身份关联，再分页渲染；每个回合只有一个呈现入口。有流按 item `seq` 交替文本和工具，无流采用历史正文；禁止位置猜配或同时展示累计回复与 item 正文。流写入单调归并，收尾等待落盘任务，不按磁盘“最后一段”猜最终回复位置。详见 AGC 实施计划的“DirectProject 回合展示唯一归属”。
|
||||
- 回合生命周期只由活动 client 回合快照和 Direct 事件恢复；Provider 的历史终态通知不能创建活动 client 回合。消息发送时间保存在历史信封，原始 item 不混入宿主字段；完成后的中间文本和工具默认收进“执行过程”，最终回复及失败提示保持可见。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user