11 Commits

Author	SHA1	Message	Date
lhk229	a8f3793865	审批观察不再抢提交点的幂等键，做方案链路能收束了 ... project_generic_submit_runtime_observation_locked 把 currentAction 改写成 「Fast GDD 审批观察已落盘」，然后用 pending.action_id 调 append_game_creator_agent_runtime_task_projection_once。但那把幂等键是 (runId, actionId, phase)，提交点已经在 phase=completed 上用同一个 actionId 写过一条 currentAction=「Fast GDD v1 已完成 create-only 提交」。三项全同即判为 同一条投影，9 个比对字段里 currentAction 不同 —— 必然硬报错，不是偶发。 后果是撕裂写：报错发生在 standalone pending 已经被改成 observed-approved 之后， v4 batch 还停在 ready/executing。两个恢复锚点从此不一致，恢复扫描只认原始 executing 形状，把策划子 Run 打成 needs-reconciliation；而重放路径的 phase == "completed" 闸门又因此永远过不去，撕裂再也修不回来。做方案链路的审批 因此从来没有成功过一次。 改法是让审批投影沿用提交点的 currentAction。9 字段全同，helper 视为重放直接 返回 Ok，链路继续往下推进 batch、清锚点、唤醒。审批这件事由 gdd_decided 审计 记录和 plan.submit_gdd.observed 事件承载，本来就不需要再占一条 task 投影—— 全仓库另外 9 个调用点都是「一个 action 一条投影」，只有这里想写第二条。 同一处还补上诊断。project_receipt_locked 里 13 处失败原本全部塌缩成一个 recovery_pending bool，其中两处是显式 let _ = error; 丢掉错误原文。receipt 已经 是用户决策的线性化点，这些失败都不能报成命令错误，于是唯一逃出来的症状就是 recoveryPending=true —— 说不出是哪一步、为什么。真因就是这样被藏了整条链路。 现在每处先写一条 agent.runtime.plan.gdd_projection_gap 记录再置位，带 step 标签 和脱敏后的错误原文；记录是 best-effort 的，诊断不能把已提交的 receipt 变成失败。 真机验证（gpt-5.6-luna，未开 GUI）：turn outcome=settled、 reconciliationAgentCount=0，state/phase=approved、approvedGddRef.version=1、 recoveryPending=false、两个锚点残留 0/0、project-planning 终态 idle/completed、 gdd_projection_gap 0 条、game/fast_gdd.md 落盘。修前同一条链路 2/2 复现 needs-reconciliation。 顺带给 buildCargoCliArguments 加 --quiet，压掉每次 spawn 重印的 cargo 进度行。 注意它不压 rustc 警告，只在重新编译时才有区别。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 10:34:40 +00:00
lhk229	adfa6ed8d3	做方案链路补无头审批入口，不再只能靠 GUI 拍板 ... decide_game_creator_plan_gdd 此前只有 Tauri command 一个入口，无头跑 --plan 到审批卡就永远收不了尾。补两条 CLI： - --plan-gdd-status <项目路径>：只读投影 - --plan-gdd-decide <项目路径> <approve|revise|reject> [--response-id] [--stdin] 审批卡的 identity 由 CLI 自己 hydrate，不让调用方手拼 gddId/fingerprint—— 拼错的后果是 PLAN_STALE_APPROVAL，而不是一条能读懂的用法错误。hydrate 抽成 hydrate_game_creator_plan_gdd_state_for_path，GUI 与 CLI 共用同一道权限闸。 swarm 测试脚本的审批必须和 CLI 并发做：Run 停在审批位时状态是 waiting-for-user-input，而 swarm CLI 恰好把这个状态算作「本轮还在跑」，turn 永远不 settle、CLI 也就永远不退出。等 CLI 退出再审批那一步根本到不了，实测 是干等到超时。改成认「等待 Fast GDD 审批决定」这条投影文案触发。并发子进程 单独跟踪，不占 activeChild 槽位，否则 Ctrl-C 杀不到 CLI。 decide 回执带 recoveryPending 时补一次 --agent-resume：审批回执落盘和唤醒 后台任务是两件事，唤醒失败被降级成 recoveryPending，审批已生效而 Run 仍停在 等待位，实测只有补这一次恢复才会重新起 turn。 真机验证：影子机器人解谜需求跑通到 state=approved、approvedGddRef.version=1、 game/fast_gdd.md 落盘，全程未开 GUI。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 09:45:34 +00:00
lhk229	276606fc70	修正无头应答器收 stdin 的时机 ... CLI 的 REPL 是「先打印提示符再读行」，所以第一个「你>」出现时本轮还没开始跑：它 就是用来读我们这条任务的。在那里收 stdin，等确认卡弹出来已经是 EOF，自动应答器 根本没机会回 approve，一轮真实跑就这样收在 pending-confirmation。改成按提示符计 数，投递之后的下一个提示符才收口。 同时补上原本缺的那条：总控可能判定直接回复而不起持久 Run，那条路径没有 turn 回 执，只等回执会一直干等到超时——实测白等了十分钟。提示符收口对两种情况都成立。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:40 +00:00
lhk229	af1fc63de2	无头立项策划默认按五分钟设计目标收口 ... --plan 之前吃 --task 那条 50 分钟的默认上限，那是做游戏链路的量级。立项策划 的设计目标是五分钟出方案，给一分钟余量；再久就是卡住，早失败比让 harness 空 等更有用。显式 --timeout-minutes 仍然压过默认值，做游戏链路不变。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 05:38:14 +00:00
lhk229	5100c18fba	新增立项策划链路的无头入口 ... `--swarm-chat` 加 `--plan`，把新根 Run 绑定到 project-supervisor-plan standard 档，和 GUI「做方案」按钮走同一条门禁；与 --autonomous-game-build / --game-chat-smoke 互斥，非总控父 Agent 拒绝。plan 与做游戏同为 standard 档， 只按 profile 匹配会串链，因此 plan 入口按 source 精确认领自己的 Run。plan 根 Run 不接受 steer，无头入口把 source 交给后端才能触发既有否决，其余入口维持 不带 source 的旧行为。 harness 侧 --plan 跳过游戏产物验收和试玩，改为报告策划产物落盘清单。立项策划 跑 standard 档，agent.delegate 这类动作按项目权限策略必须逐个确认，而确认只从 CLI stdin 读；自主构建档没有这一步，所以只给 --plan 加一个 stdin 应答器，确认 本身仍然走后端确认命令。做游戏链路不受影响。 真实无头跑已验证：plan 根 Run 正常起来，source=project-supervisor-plan、 runProfile=standard，两个 agent.delegate 确认卡自动批准并进入委派。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 04:39:54 +00:00
kdletters	15c227cebf	修复AGC Windows运行与全量测试稳定性 ... 完善Codex CLI、App Server、ConPTY与进程会话在Windows下的发现、启动、恢复和退出行为 修复Agent Runtime、Provider重试、项目写锁及工具交接账本的并发与跨测试串线问题 补齐配置目录、路径脱敏、原子写入、浏览器探测和本地Provider smoke的跨平台兼容 增强Goal Contract、自动策略、资源生成及运行态恢复的契约和回归测试 更新AI游戏创作智能体App技术文档中的Windows稳定性说明 验证AGC开发态、Release打包、打包后GUI运行及完整agc:check门禁	2026-08-13 13:36:21 +08:00
kdletters	5550e24f83	接入 Codex 节点 Agent 并完善总控交互 ... 新增 Codex app-server 与 CLI 节点执行模式并保留 Provider 回退 加固节点凭据隔离、终态未知回收、进程生命周期与持久恢复边界 修复资源画布等价刷新闪烁 为 Supervisor steer 增加 LLM 回复与条件中断 补齐配置界面、测试和技术文档	2026-08-10 20:58:43 +08:00
AIGameCreator App	26ef00f7b9	修复游戏创作脚本剩余ESLint错误 ... 整理配置检查与测试文件导入顺序 调整配置向导无限循环写法通过Lint门禁	2026-07-28 12:49:48 +08:00
AIGameCreator App	427a8c151a	完善自主构建正式产物与终端测试 ... 新增终端 AppData 配置向导并强化跨平台密钥与进程树安全 升级自主构建为十六任务产物 DAG 并接入两类真实画布素材 完善完成基线、并发补验、验证证据与受限画布返工合同 强化确定性与真实 Swarm E2E 的 exactly-once 和正式产物校验 修复确定性 Provider 终态修复后的复验交付状态 同步更新客户端实现计划、决策记录和踩坑说明	2026-07-27 04:04:06 +08:00
AIGameCreator App	ddbca15e30	修复Agent Swarm聊天测试Runner冲突 ... 为人工聊天测试复制隔离 AppData，避免复用正式 Runner 新增空闲 Runner 安全收束与临时目录清理 补齐初始化占位页校验、回归测试和开发文档	2026-07-23 13:52:06 +08:00
AIGameCreator App	917fcd5726	添加Agent Swarm一键测试入口 ... 新增 agc:test 确定性自动验收短命令。 新增 agc:test:chat 自动发现 AppData、创建测试项目并启动自主 Swarm。 复用正式预览服务完成浏览器打开、信号停止和安全清理。 补充命令契约、跨平台目录、项目哨兵和预览地址测试。 同步客户端技术方案与团队复验流程。	2026-07-23 12:15:26 +08:00