955 Commits

Author	SHA1	Message	Date
lhk229	34bcd61824	补齐 M1C-1 漏掉的 agent_db 守恒断言，并让审批投影恢复区分瞬时错误 ... M1C-1 给 agent_db 新增了 planning 决策预留车道并从普通追加额度里扣除，但 ordinary_append_soft_limit_preserves_action_receipt_record_slots 仍断言两车道的守恒 律，差额恰好是新车道的 2_097_280 字节；记录额度同样少算 128 条。master 没有这个常量， 所以 master CI 绿而本分支必红。断言补到三车道，记录额度改为 999_680。 审批投影恢复的收敛此前不分错误性质：`.agent/project.lock` 正被占用这类瞬时错误也会 把策划根 run 永久标成 needs-reconciliation——比收敛出现之前的强传播更糟。现在先过 static_delegate_parent_wake_error_is_transient（复用委派唤醒的既有判据，避免两处分类 漂移），瞬时错误照旧上抛，由调用方转成 recovery_pending 下一轮重试；只有持久不一致 才收敛到那个 run。新增回归覆盖这条分支。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:55:38 +00:00
lhk229	a60f95b554	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-17 04:30:42 +00:00
lhk229	8d5338ce82	P2：reject 不是死路，锁住真正的约束 ... 原判定「reject 后同一 session 无法再次提交，因为 CAS 门只放行 collecting / revision_requested」不成立。提交门在 phase 判据之前先要求 session 的 activeRunId 等于 当前策划子 run，而 schema 不变量禁止 rejected / revision_requested / approved / awaiting_* / recovery_required 保留 activeRunId——两者互斥，终态 phase 根本到不了那条 phase 判据。把 rejected 加进允许集只会多一个不可达分支，续跑仍然起不来；连既有的 revision_requested 也已经是不可达的。 真正决定 reject 能否重做的是 M1C-2b 的 continuation 起点 writer：技术方案 §8.6 要求它 「以新 activeRunId 写 revision+1 successor」，而唯一能同时带 activeRunId 又过提交门的 phase 只有 collecting。本提交不改行为，只把这条因果写进门旁注释，并加一条回归锁住它： 终态 session 挂 activeRunId 在指纹阶段就被 PLAN_INVALID_SCHEMA 拒绝，而落回 collecting 的 continuation 能过提交门。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:28:49 +00:00
lhk229	1fa56a7aee	修复 M1C-1 打破的两条用户修订委派测试 ... M1C-1 让 UserRevisionRequested 与 EvidenceReady 共用同一套客观证据要求 （terminal completed、无缺失产物、验证已满足）。这两条测试仍沿用 M1C-0 时期的模拟 方式：拿一条 needs-repair 的 structuredResult 直接翻 contract_status，落盘时被判成 「evidence-ready/user-revision-requested 与客观证据冲突」——构造本身自相矛盾，不是 代码回归。改成先让 expected_artifacts 真实落盘、再按真实证据重建 structuredResult， 语义也更准：用户是在已交付的产物上要求修订。 已确认为既有破坏：两条在 A+B 之前的 c89a13e68 上以相同行号 panic。M1C-1 的验证范围 只写了 planning_submit/planning_storage 定向测试与 cargo check，delegation.rs 改了 +254 行却没跑，破坏就发生在那次改动里。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:16:09 +00:00
kdletters	abb3912530	增加分支与提交搜索校验 ... 增加分支和 commit 的输入搜索下拉构建前复核固定仓库中的分支与 commit 归属补充预览控制面接口合同、配置和测试	2026-08-17 12:04:31 +08:00
lhk229	a40080d525	P1：窄投影恢复失败不再掐掉整轮 resume，plan_gdd blocker 改类型化判别 ... A. reconcile_plan_gdd_approval_projections_at 挂在 resume 的第一行却用 `?` 强传播， 一次 Fast GDD 投影失败会掐掉全项目所有 Agent 的恢复；而它本身正是 receipt 投影失败 后的重试入口，掐掉它等于连兜底一起废掉。改成把 fail-closed 收敛到策划根 Supervisor 这个 run，其余 Agent 照常恢复；无法归属时才退回全局上抛。 B. main_loop 原来用 contains("approvalPending=awaiting_decision") 区分 plan_gdd blocker 的子状态，而三个 blocked 里只有一个含这个子串——尚未提交（下一步是 agent.delegate）和 receipt 锚点收尾都会掉进 else 被打成 needs-reconciliation，把最 正常的推进态当成故障停掉。改由构造方给出 PlanGddCompletionBlockerKind，消费方穷尽 match，判不出 kind 时保持 fail-closed。这两个推进态不再产生等待态，和 runtime.plan_update 一样让本轮循环继续。 映射抽成纯函数并建起 main_loop 至今没有的 mod tests：四个 kind × 两条映射全覆盖。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:02:54 +00:00
lhk229	c89a13e682	把 Fast GDD 审批等待的可恢复判据钉成不变量 ... 判据在 task record 的 status 而不是 phase：审批等待只改 phase、保留 status=running，恢复扫描仍会拉起；真正的澄清等待才会把 status 一并写成 waiting-for-user-input。一旦有人把审批等待也写成后者，审批命令的通用 wake 会静默变成 no-op，用户点完批准/修改/退回不会有任何东西继续跑，且无报错。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 03:28:24 +00:00
kdletters	ced4b56dee	优化预览发布记录展示 ... 发布记录增加后端校验后的 Web 端口号 列表隐藏已成功卸载的容器记录 兼容恢复旧运行记录并回填 Web 端口 补充后端、前端测试和技术说明	2026-08-17 10:47:58 +08:00
lhk229	4498c15f90	完成 M1C-2a验收前置门 ... 固定 plan 根 Goal Contract 与唯一 Fast GDD 验收节点。 记录并校验 Supervisor 根 Run 的完整分页 file.read 证据。 接通认领后三态审批前置门、幂等 pending 恢复与完成门。 修复审批后 session 校验及 pending/receipt 优先级边界。 补齐恢复、finalization、身份冲突和工作包边界回归。 同步 Fast GDD 技术方案与项目决策日志。	2026-08-17 02:40:11 +00:00
lhk229	d96fa7b755	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-15 12:03:01 +00:00
lhk229	f45e90e36b	M1C-1：落地 Fast GDD 审批闭环与完成门 ... 新增 plan-gdd approval receipt、pending、审批命令及三动作幂等投影。 接入 receipt 恢复、generic submit 锚点精确消费与 terminal observation 完整性校验。 接入 exact plan-root completion blocker，并补充 pending、recovery、作用域和 identity 回归。 同步 Fast GDD 技术方案与项目决策记录。	2026-08-15 12:00:57 +00:00
lhk229	23559b1b1c	修复 CI 五条失败：三处校验的位置错误放大了作用域 ... 撤回 M1B-2 对 tool-plan 交接判据的跨 loop 上提并补正向回归 恢复扫描的锚点探测器不再对不可读 state 强读，交还下游 fail-closed 兜底 planning 存储把链接路径统一分类为 PLAN_UNTRUSTED_PATH Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 09:45:44 +00:00
kdletters	41874ab391	新增内网容器预览部署控制面 ... 新增分支与指定提交的预览部署 SPA 和 Jenkins 代理服务 新增多实例 Docker 预览流水线、端口租约、实时健康状态和卸载能力 新增 /build 内网路由、systemd 部署资产和运维文档 修正容器 Nginx 健康检查探针	2026-08-15 17:18:10 +08:00
lhk229	f93103760a	M1C-0b：合并原分支最新修复 ... 合入 Agent 主循环栈溢出修复 保留 M1C-0b 静态委派状态前向兼容实现	2026-08-15 08:08:01 +00:00
lhk229	53f2ba30c3	修复 Agent 主循环栈溢出：专用 worker 判据从枚举入口改为不变量 ... CI 上 background_agent_runtime_recovers_stale_running_before_pending_task 在 tokio-rt-worker 栈溢出。根因是 recovery_scan.rs 手写 tauri::async_runtime::spawn 直接 跑 drain_game_creator_agent_background_tasks——正是仓库规定必须上 16 MiB 专用 worker 的那个 future。pitfalls 2026-08-03 按入口枚举了三个（普通后台任务、静态委派子任务、 manifest ready-task 首次执行），恢复重启是第四个，从未被列进去；漏掉一个入口不会产生 任何信号，故判据改写为不变量：所有会进入 Agent 主循环的 future 必须在 agent-runtime-worker-* 专用线程上轮询。 改动： - 统一常量 AGENT_RUNTIME_BACKGROUND_WORKER_STACK_BYTES - spawn_next_*_with_lock 改用专用线程；签名保持 -> ()，8 个调用点不动。该入口是 best-effort 幂等语义（拿不到锁即返回、后续 wake 重试），建线程失败只需记录并随闭包 释放锁，无需交还锁、也就不需要握手 - recovery_scan.rs 两处手写 spawn 收敛为 helper 调用。恢复重启顺带补上首轮轮询握手： 原写法把执行锁 move 进一个无人保证会被轮询的 future，运行时关停时 run 会永远停在 running 且无主 回归钉不变量而非钉余量：drain 入口在 cfg(test) 下记录线程名，用例断言必须以 agent-runtime-worker- 开头。变异验证——改回手写 spawn 且 RUST_MIN_STACK=16MiB（因而不 溢出）时，用例仍以 ["tokio-rt-worker", "tokio-rt-worker"] 失败。 实测（同机、二分 RUST_MIN_STACK，默认栈 2048 KiB）： - started 变体：master 需 1536-1792 KiB，修复前 HEAD 需 2048-2176 KiB - 队列 drain：master 需 1280-1536 KiB，修复前 HEAD 需 1792-1856 KiB，余量已不足 256 KiB - 修复后两条用例在 1024 KiB（半个默认栈）下通过 同过滤器 A/B（runtime_actions + collaboration，同一 skip）： - 修复前 HEAD：19 failed，且在 planning_strategy 处栈溢出 abort - 修复后：289 passed / 0 failed 修复前分支实际有三处溢出点（recovery、response_stream::provider_handoff_*、 planning_strategy::tool_planning::*），CI 只报了最先撞上的那个；三处修复后均通过。 共享 tokio pool 不再被长时间占用，mock LLM 超时类失败同时大幅减少。 需回流 master：master 同样存在恢复重启走默认栈与 drain_next_* 余量偏低，只是尚未触发。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 08:04:06 +00:00
lhk229	89bbfd135a	M1C-0b：补齐静态委派状态前向兼容 ... - 未知 contractStatus 保留为 Unknown(raw) 并接入完成屏障、等待、返工与谱系门禁 - 补齐 planning Provider、自治 liveness 与终态扫描的 fail-closed 消费路径及回归 - 保持已知状态和损坏 sidecar 行为不变，更新技术方案与共享决策记录	2026-08-15 07:04:40 +00:00
lhk229	f45db359bd	合并最新 master 到 feat/five_min_design，并修复 master 的 Windows 构建中断 ... master 侧 5 个提交（8e78be766..9f5c84ee7）。仅一处冲突： src/view/home/index.tsx 的 react import——我们这侧对该文件只有 prettier 格式化 改动，master 新增的 useRef 在合并后正文里用了 2 次，取 master 那行。 修复 master 带来的 Windows 构建中断（E0658）： project/manifest.rs 的 #[cfg(windows)] 分支用了 std 未稳定 API `MetadataExt::number_of_links`（rust-lang#63010），而 rust-toolchain.toml 锁在 stable 1.96.0。该文件与 origin/master 逐字节相同，即 master 自身在 Windows 上就 构建不过——Linux CI 上 #[cfg(windows)] 整块不参与编译，所以 CI 全绿。 改为本仓库既有写法：自声明 ByHandleFileInformation 调 GetFileInformationByHandle （另见 runner/endpoint.rs、tool_plan_handoff/storage_windows.rs 等六处）。保留原 错误文案与 fail-closed 语义（取不到句柄信息与确实是硬链接同等拒绝），并按 endpoint.rs 先例一并拒绝 directory / reparse point。 该修复目前只在本分支，须回流 master，否则下次合并会再撞一次。踩坑记录见 pitfalls.md 2026-08-15 条。 验证： - cargo check --offline --all-targets 通过（修复前 E0658，修复后 Finished） - cargo fmt --check 通过 - 定向 Rust 测试 project::manifest / godot / static_delegate / collaboration::static_deliveries 65 passed / 0 failed - agc:typecheck 通过；check:encoding 通过（5376 files）；git diff --check 干净 - 前端 vitest apps/ai-game-creator-shell/tests：738 passed / 1 failed，唯一失败是 已知的 Windows symlink EPERM（agentSwarmTestEntry），非本次回归 两条既有环境失败，已核实与本次合并无关： - command_exec::tests 两条报「找不到受信任的 rg 可执行文件」，该文件相对合并基线 逐字节相同 - npm run check:native-shells 在合并前的 master worktree 上失败得一模一样 （spawnSync npm.cmd EINVAL，脚本 spawn npm.cmd 未带 shell: true） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:37:00 +00:00
lhk229	1d4d77ef3d	立项策划：落地 M1C-0 合入复核结论，三条 M1C-1 前置与一条哨兵订正 ... 生产代码零改动（delegation.rs 三个 hunk 全在 mod tests 内），本次只补回归与文档。 复核确认「今天行为零变化」成立且可证：contract_status 生产赋值点只有两处且都从 客观事实派生；StaticDelegateClaimRecord 全仓库唯一构造点是运行时构造，不是 agent 提交的 JSON；durable sidecar 在 .agent/runtime/** 下被 file_ops 与 filesystem 各 三处拒写；前端无 contractStatus 消费者。lineage 三个 fail-closed 出口全部返回 (u32::MAX, u32::MAX)，新分支的哨兵检查接得住。 三条 M1C-1 前置写进技术方案第 23.7、23.8 节与 decision-log： ① UserRevisionRequested 不进 repair_required_count / user_input_required_count 任一 barrier，写入方落地即意味着 Supervisor run 可在用户修订未派出时完成； ② validate_static_delegate_structured_result 对该变体只有否定约束，缺正向一致性 分支，UserRevisionRequested + failed + 缺产物 能通过校验落盘； ③ 前向兼容失败粒度是整个子系统——list_static_delegate_deliveries_at 逐条 ? 上抛， 一条解析失败即整个目录枚举失败。bump schema version 救不了（版本校验在 parse 之后）。 文档订正：STATIC_DELEGATE_LINEAGE_MAX_HOPS = 32 限的是链上节点数不是跳数 （判据排在入链之前），真实跳数上限 31，第 23.7 节原写 32 跳已订正。 测试： - static_delegate_user_revision_preserves_existing_clarification_round 名不副实， 它把 UserRevisionRequested 放在目标位置，而计数循环只遍历父节点集合，新分支 从未被执行。改名为 ..._parent_hop_preserves_depth_and_clarification_round，补 一跳真正以用户修订为父的续跑并加反证；原断言留作对照组并注明性质。 - 新增 concurrent_user_revision_dispatch_creates_exactly_one_delivery，父节点为 UserRevisionRequested 且 depth 已为 1，两侧同时钉住并发下恰好放行一条。 - user_revision_continuation_... 补兄弟检查断言（depth 门对用户修订失效后，它是 该路径上唯一剩下的扇出约束）。 变异测试：摘掉 counters 分支 4 条变红（含新增反证 left (2,0) / right (1,1)）； 摘掉 gate 分支 3 条变红（并发用例 left 0 / right 1）。两处守卫各自有回归覆盖。 验证：定向 41 passed / 0 failed；npm run check:encoding 通过（5374 files）； git diff --check 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:17:39 +00:00
kdletters	9f5c84ee71	重构AGC项目管理界面 ... 参考成熟桌面项目管理器重构紧凑项目表、搜索和行尾菜单 支持Windows路径及Godot根目录和一层子目录工程识别与导入 修复1280×720页面溢出、列表滚动和末行菜单裁切 补充项目页回归测试、PRD、技术方案和项目记忆	2026-08-15 11:43:58 +08:00
lhk229	27c3eb847a	立项策划：完成 M1B-2 GDD 提交与恢复 ... 接入 plan.submit_gdd 原生工具及 exact planning Provider 绑定与结构化注入 实现 create-only GDD 提交点、索引 Markdown session 恢复与策划子 run 收口 补齐定向门禁与阶段文档记录，审批 receipt UI 和构建准入留待后续	2026-08-14 14:23:58 +00:00
kdletters	578f8019fc	优化AGC项目入口并识别Godot工作区 ... 项目页只保留打开项目和新建项目并统一原生目录选择 按根目录及一层子目录识别project.godot并记录相对Godot根 保持.agent位于用户选择的工作区根并补齐Windows构建门禁 补充响应式布局、测试、技术方案和共享项目记忆	2026-08-14 21:53:43 +08:00
lhk229	4d3f87cd39	修复完美像素无法识别自身产物的网格 (#169) ... 边缘 profile 用的是跨度 2 的中心差分，硬块边界落在列 b-1|b 之间时 profile[b-1] 与 profile[b] 逐位相等：两者跨的是同一条边，逐行被加数 相同、求和顺序相同。峰值判定两侧都用严格大于，会把这个 2 宽平台的 两端一起丢掉，于是最干净的输入反而 0 个峰、被判为未识别到网格—— 完美像素处理不了自己的输出。 estimate_step_size 左邻比较放宽为 >=，右邻保持严格 >：平台只保留 一个索引，且是右端，正好是左闭右开语义下的真实块边。两侧都放宽则 会把长度 K 的常数段整段判为峰。 walk 与 snap_uniform_cuts 的 argmax 同样改为 >=，取等值段的最后一 个索引。取第一个会让每条切线落在真实边界左边 1px，每个 cell 因此 混进 1/4 的邻块。实测在 266x253 的最近邻放大像素画上，切线命中真实 块边从 2.6% 升到 98.5%，左右镜像、上下翻转、180° 旋转下一致；龙图 内容区内 134/134 全中。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/169 Co-authored-by: Linghong <ink29535@proton.me> Co-committed-by: Linghong <ink29535@proton.me>	2026-08-14 20:42:58 +08:00
k88936	d901945c77	移除视频快速编辑支持 (#157) ... 当前实现: 视频快速编辑错误地复用了图片快速编辑的panel, 然后发起一个实际是生成视频的请求 策划建议删除. 因为后端没有实际意义上的视频快速编辑, 所以api 后端代码没有改动, 只在前端删除入口和处理 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/157 Co-authored-by: 王德宇 <kvtodev@outlook.com> Co-committed-by: 王德宇 <kvtodev@outlook.com>	2026-08-14 18:52:56 +08:00
kdletters	d155e303bd	实现AGC回车自动创建工作区 ... 首页普通回车自动分配系统文档目录下的唯一工作区并启动项目总控 保留加号按钮手动选择目录和Shift回车换行语义 统一Windows Linux与macOS默认项目路径解析并移除产品态tmp默认值 补充自动工作区安全测试 首页交互回归与技术方案说明	2026-08-14 17:45:27 +08:00
lhk229	a17f725834	立项策划：合入 M1C-0 用户修订 lineage 分类 ... M1C-0 在隔离 worktree 上以 09c7d7af8（M1A-2 收口）为基线开发，缺 M1A-4、 M1A 残余收口、M1A-2 回归修复与 M1B-1 共六个提交，故走 merge 而非 fast-forward。 代码零冲突：本包改顶层 src-tauri/src/delegation.rs，M1A-4 改 src-tauri/src/agent/runtime_tools/delegation.rs，同名不同文件； tests/collaboration/static_deliveries.rs 两侧各自追加测试，自动合并。 两处文档状态句冲突，按「原分支事实优先」解决：保留 M1A-4 与 M1B-1 的已落地 事实，删去本包基线上「.agent/planning 存储仍未实现」「M1B-1 及之后仍未开始」 两句已被 M1B-1 推翻的表述；顺带把状态句和第 23.6 节第五行遗漏的 M1A-4 补回。 decision-log 的 M1C-0 条补一段合入说明，并订正其关联行里自指的 M1C-0 为 M1C-1。 合入后验证：cargo check --offline --all-targets 通过，npm run check:encoding 通过（5373 files），git diff --check 干净。定向测试与逐项复核另行跟进。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 07:10:02 +00:00
lhk229	f453c2ca27	立项策划：落地 M1B-1 planning storage 与写入隔离 ... - 新增 plan GDD、index、session 与提交输入的 strict schema、canonical JSON 和 typed 指纹。 - 落地 GDD 连续版本链、index 权威对账与锁内 recovery、session CAS/原子替换/受限恢复。 - 封锁 planning sidecar 与 fast_gdd 投影的通用写入、patch、删除和 checkpoint restore，并校验专用 writer 身份。 - 同步 Fast GDD 技术方案、决策记录与排障记忆。	2026-08-14 06:47:14 +00:00
lhk229	323db581fa	修复 M1A-2 引入的回归：未知工具名不是身份违规 ... background_agent_runtime_persists_receipts_for_rejected_actions 在本分支 恒失败（3/3），master 通过。首个 tool-plan 请求能收到，动作被拒绝后第二次 Provider follow-up 不再发出，测试等待超时。不是已知的 mock-LLM 本机 flake。 根因是 M1A-2 给主循环加身份门时用了 agent_runtime_tool_allowed_for_agent， 而该函数对非 project-planning 的 Agent 退化成「这个工具名是否已知」。于是 普通 Agent 调用一个不存在的工具（模型编名字，常见协议错误）被判成身份违规， main_loop 直接 mark_needs_reconciliation 并返回 NeedsReconciliation，整个 run 中断。现役语义是未知工具产出一条 rejected observation、run 继续、由下 一轮 tool-plan 收束。 两类必须分开：身份禁止某个已知工具是安全边界，命中即硬拒；工具名根本不存在 是可恢复的协议错误，不得升级成中断整个 run。 新增 agent_runtime_tool_rejected_by_agent_identity，只在「该 Agent 带 exact allowlist 且工具不在其中」时为真。三个命中即中断或整体拒绝的调用点改用它： main_loop（本次回归直接原因）、provider_action_batch 的 identity_block（原会 把普通 Agent 的未知工具从 rejected 误判成 blocked）、runtime_tools/policy （原本就正确限定 planning，改为复用同一判据以免再次分叉）。parallel_ledger 内部批次资格判定不变，其下一行的 command_id 检查本就拦得住。 planning 侧约束未放松，两条单测分别钉死普通 Agent 与 planning 两侧。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 06:35:45 +00:00
lhk229	5fa662be30	立项策划：收口 M1A 复核残余，retry 强判据前置且身份哨兵改为编译期约束 ... retry 强判据必须排在全部分支之前。plan 分支原先排在 delegated 与 autonomous-game-build 之后，两支都能绕开 reject_supervisor_plan_root_retry_without_identity： 一是 plan source 配伪造 parent 会落 delegated 支，直接返回 agent-delegate-retry，强判据根本不执行。二是 binding.source 是 plan 配 autonomous profile 会落 autonomous 支，因 plan 在可信集合内而被原样取回， 复活启动路径 reject_supervisor_plan_autonomous_profile 明令禁止的组合。 两者都要 durable 状态先畸变才可达，但强判据存在的意义正是对畸变状态 fail closed。守卫提到函数开头无条件执行，合法 plan 根 run 对它恒真； plan 分支不再重复读 durable 状态。autonomous 支另加一次 reject_supervisor_plan_autonomous_profile，兜住顶部守卫按 task.source 判定所挡不住的那一种。回归已用变异测试确认去掉任一守卫即变红。 __all_agents__ 身份哨兵改为编译期约束。四个不带 agentId 的 wrapper 会以 哨兵跳过按身份的工具面收窄与原始工具 identity 复核，M1A-2 之后调用点只剩 测试，但将来新增生产调用点漏改是静默拿全量目录而非编译失败。四个 wrapper 与对应 re-export 一并加 cfg(test)。该哨兵已扩散到两个文件，是正在复制的 模式而非单点遗留。 订正 M1A-3 决策条里「agent-background-task 唯一构造点」的错误结论： task_start 与 recovery_scan 各还有一处同形状的空 source 兜底，且 recovery_scan 那条不经过 plan 根强判据。经复核有意不改，理由随条记录。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 05:20:18 +00:00
lhk229	c22b929080	立项策划：落地 M1A-4，plan 根 run 只能委派策划子 Agent ... 补 M1A-2 的反方向。原先只做了「目标是 project-planning 时要求父是 plan 根」，反过来「父是 plan 根时目标必须是 project-planning」没做， 也没记为 deferred。后果是 plan 根 run 可以委派任意专业 Agent，而被 委派者拿常规 standard 工具面（能写文件、跑命令），第 24 节「策划全程 零构建」当时只由 Prompt 兜底。 执行层：observe_agent_runtime_agent_delegate 补对称分支； observe_agent_runtime_agent_spawn_isolated 对 plan 根 run 一律拒——它是 第二条造子 Agent 的通道，只堵 delegate 等于留后门。两条共用 typed kind=plan-root-child-target-unsupported。 强弱判据分工与 M1A-3 一致：弱判据从 task journal 读 source 决定是否 管辖，强判据 validate_project_supervisor_plan_root_binding_at 决定是否 合法，其 Err 永远落进拒绝分支。不可写成 is_ok() 当作「不是 plan 根」， 那会在 binding 损坏时放行任意子 Agent 创建。 上下文层：plan source 下不拼 supervisorIntro 与 $visualContract。不改 .md 内容，不新增 composition key。 三条有意保留的取舍已冻结进 decision-log，非待办： $isolatedAgentTemplates 仍列出专业角色名（被执行层硬拒后的死文本， 上下文层收窄边界到此为止）；task journal 读取失败对所有 source fail closed（改成放行是新的 fail-open）；plan 根 prompt 断言偏弱 （执行层是该场景唯一保障）。 同步方案 §22 证据表、§23.8 PR 表、§24 不变量，并订正 M1A-2 决策条里 含糊的「Supervisor 根 run 继续使用现役工具面」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 05:02:46 +00:00
lhk229	7db5118e27	立项策划：落地 M1C-0 用户修订 lineage 分类 ... 新增 UserRevisionRequested durable 状态并保持未知状态 serde fail-closed 区分用户修订、澄清 continuation 与质量返工的 lineage 计数及深度门 补充连续修订、真实 agent.delegate、32-hop 和历史兼容回归 同步 Fast GDD、Runtime 文档与 M1C-0 决策记录	2026-08-14 04:02:53 +00:00
lhk229	09c7d7af8d	立项策划：收口 M1A-2 工具面与角色提示 ... 收紧 planning 子 Agent 原生工具目录与 MCP/web search 边界 增加静态委派父根身份与 fail-closed 执行校验 补齐 planning Prompt Bundle、final-reply 终态约束与解析层拒绝 保留项目权限 deny/confirm 并同步恢复归一化策略 同步技术方案与项目决策记录	2026-08-14 02:58:18 +00:00
lhk229	17f7152f70	立项策划：落地 M1A-3，plan 根 run retry 保源且身份失败不降级 ... 新增 plan 根 run 强判据，核 durable binding 而非只看内存 source retry 在 generic 兜底前保留 project-supervisor-plan 身份校验失败返回 plan-root-retry-identity-unsupported gui 与 delegate 对照回归保持现役兜底 同步 Fast GDD 方案、decision-log 与 pitfalls	2026-08-13 14:11:34 +00:00
lhk229	65f471210f	立项策划：落地 M1A-1，plan source 进可信 matcher 且 steer 独立否决 ... 新增 project-supervisor-plan 常量并加入可信 matcher 启动路径拒绝 plan 与 autonomous-game-build 的组合 steer 用独立于 matcher 的显式否决 补消费点复核与定向回归 同步 Fast GDD 方案、decision-log 与 pitfalls	2026-08-13 13:22:37 +00:00
lhk229	10af1fc377	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-13 12:17:26 +00:00
kdletters	8e78be766e	修复AGC运行与首板版本登记 ... 修复旧模型定价覆盖缺少ElevenLabs音效模型导致启动恢复持续失败 支持对话框回车发送并保留Shift换行和输入法组合态 重试受理后立即清理旧失败投影并展示新Run状态 阻止Windows后台Codex探测反复弹出控制台窗口 首板试玩持久回执通过后幂等登记初始项目版本 补充定价、交互、Windows与版本登记回归测试和文档	2026-08-13 20:11:51 +08:00
lhk229	fd61486525	Merge remote-tracking branch 'web/master' into feat/five_min_design ... 冲突两处，均为两侧独立新增： - provider_tool_plan.rs：本分支的 force_autonomous_owner_artifact_delivery 与 master 的 force_root_goal_contract 是各自独立的 let 绑定，两者都保留。 - provider_request_builders.rs：本分支新增测试 full_dag_pre_code_owner_requests_do_not_advertise_manual_verification， master 把紧随其后的 trusted_root_supervisor_receives_dynamic_goal_control_tools 改名为 trusted_root_supervisor_first_turn_only_receives_goal_contract_tool。 保留本分支新增的测试，共享的那个测试采用 master 的新名（其函数体已随 master 自动合并）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:28:21 +00:00
lhk229	ba04293204	登记立项策划子 Agent 身份，并堵住登记带来的三处静默错分 ... D11 要求策划 Agent 由 Supervisor 通过 agent.delegate 静态委派，因此它必须是 agentCatalog 合法成员。登记方式照 agentCatalog.supervisor：与 supervisor 平级、 不进 groups——build.rs 的 validate_seed_task_catalog 只比对 groups[].roles[] 派生的 specialist_nodes，因此种子 DAG、new_game_creation_app_seed_tasks() 与 build.rs 三者一行不动，「做游戏链路不动」得以成立。 编译期：manifest.json 新增 planning 条目；AgentCatalog 加字段、validate_agent_catalog 纳入校验、render_agent_catalog 生成 PROJECT_PLANNING_* 静态。 运行时修复的是「非 supervisor 即专业组成员」这个二分假设的四个受害点： - prompt.rs 的 game_creator_agent_role_definition 返回 None，而两个调用方都用 .ok_or_else(...)? 转成硬错误——委派第一轮构建 Provider 上下文即中断（blocking） - pass_artifacts.rs 的内存路径解析报「未知 Agent 任务」 - task_start.rs 的 agent 枚举漏收，重启/steer/兜底对账后委派变孤儿任务 - task_ops.rs 的 task.create 在无 group 参数时静默兜底成 Design 组，污染任务审计。 此处只对 project-planning 要求显式传 group，不动 project-supervisor 同样吃这个 兜底的现役行为。 另排除 project-planning 出 agent.spawn_isolated 的合法模板集：它一旦进 catalog 就 天然满足「非 child- 前缀、非 Supervisor 本体」的放行条件，会让任何持该工具的 Agent 都能动态孵生它，属登记带来的隐性扩权。 新增 project_planning_is_a_delegatable_identity_outside_the_seed_dag 钉住四点，其中 「不在任何专业组且不在种子 DAG」直接断言 new_game_creation_app_seed_tasks()。 runtime_adapter 既有 catalog 目录测试同步更新期望集合。 本包只让身份跑通。exact allowlist 工具面、plan.submit_gdd 与 brief 正文属后续块。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 06:53:06 +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
lhk229	13ee128114	测试：钉死静态委派返工深度与澄清轮次的链上推断语义 ... 反转 clarification_continuation_chain_supports_multiple_rounds 的第 3 轮断言： D2 -> D3 从"必须被拒绝"改为"必须成功"，并断言 D3 的澄清轮次推导为 2——这是 WP1 把返工深度与澄清轮次拆成两个独立链上推断维度后的有意行为变更，不是回归。 新增 7 条用例，全部走真实 observe_agent_runtime_agent_delegate 生产路径： - 澄清轮次上限边界（第 4 轮必须被拒绝，且文案是澄清轮次专用文案，不串扰返工深度门） - 交替链钉子测试：返工(depth=1) -> 澄清(depth 仍为 1, round=1) -> 再返工必须被拒绝， 同时证伪"R1 误清零 depth"和"R2 漏加 1"两种失误 - 返工重置澄清轮次预算，重置后 3 轮澄清全部放行 - 验证澄清 continuation 校验器（要求携带匹配的澄清字段）本身就保证了同一原始 delivery 不存在"既澄清又质量返工"的可达状态，并证明澄清跳不会连带占用它 产出的下一节点自己的返工配额 - 历史记录分类：手工构造 #165 之前风格的旧 delivery，验证链上推断把它正确 分类为非澄清、返工正确计入深度 - 跨 run 隔离：换 parent_run_id 引用旧链节点的返工请求必须被拒绝 - source 区分：game-chat source 下澄清上限为 1，非 game-chat 上限为 3 delegation.rs 仅放宽三个既有私有函数（static_delegate_lineage_counters / list_static_delegate_deliveries_at / write_static_delegate_delivery_at）为 pub(crate)，供测试直接断言链上推导出的 (depth, round) 数值；不改变任何行为、 不新增持久字段。 回归防线复核：project_supervisor_static_delegate_repair_is_single_bounded_wave （含"返工的返工必须被拒绝"）、project_supervisor_concurrent_repair_dispatch_ creates_exactly_one_delivery、claimed_needs_user_input_delivery_becomes_one_ supervisor_wait 及其邻近用例均保持通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 04:14:19 +00:00
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>	2026-08-13 03:38:17 +00:00
lhk229	c0d1890b49	Merge remote-tracking branch 'web/master' into feat/five_min_design ... 冲突解法： - 实施计划.md：master 改 Provider 故障展示、本分支改跨轮阶段记录，各取各自较新的一条 - decision-log.md：两侧新增条目不重叠（master 2 条 / 本分支 7 条），全部保留 - agentPresentation.ts、agentRuntimeModel.test.ts：import 取并集 - project-development.suite.ts：保留 master 新增用例，用例标题用本分支 M0B-2 改后的语义 - SupervisorChatOnlyView.tsx：合成两侧。isAgentRuntimeTerminalState 本身已含 needs-reconciliation，master 单独那两行对其自身是冗余的；但本分支的 `|| descendantsStillActive` 会让 needs-reconciliation 的 run 因子 Agent 未收束 而重新判为运行中，正好绕过 master 这次要立的规矩。故保留本分支的 lineage 口径 （projectedRuntime）并补显式 needs-reconciliation 短路。 验证：前端 typecheck 干净；appSurface.test.ts 377 passed；agentRuntimeModel 27 passed； cargo check --all-targets 通过；static delegate 定向 9 passed；clarification 定向 4 passed。 response_stream / runtime_state 有失败，经对照确认不是回归：在纯 web/master 的独立 worktree 上跑同一批为 10 failed，本分支为 6 failed 且是其真子集，两次运行成员还不同。 失败模式统一为 Windows 下 .agent/agent.db 被占用（Os code 32），属本机既有基线。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:01:56 +00:00
lhk229	7754a2f820	测试：实证静态委派澄清 continuation 只能走一跳 ... 新增 clarification_continuation_chain_supports_multiple_rounds，走真实 observe_agent_runtime_agent_delegate 生产路径验证 #165 澄清中转的链长边界： - D1 -> D2 第一跳成功，D2 落盘且 repair_of_delegation_id == Some(D1) - D2 -> D3 第二跳被 delegation.rs:1119 的「静态委派返工深度最多为 1」拒绝 - D3 从未落盘 澄清 continuation 与质量返工共用 repair_of_delegation_id 字段和同一道深度门， 因此一次澄清会同时耗尽该链路唯一一次质量返工额度。本用例把当前行为钉死， 作为后续拆分两个维度时的对照基线。 仅新增测试，未改动任何生产代码。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 02:27:06 +00:00
kdletters	f395a6ed36	稳定Agent失败审计时序测试 ... 等待 Runtime 失败后的审计记录有界落盘 保持 final-reply-failed 审计最终存在的强断言 连续五次验证流式连接中断回归	2026-08-12 22:38:59 +08:00
kdletters	da7c4dc71c	修正Agent失败关闭回归语义 ... 将流式连接中断断言为 Runtime 失败 禁止 transport 错误提交 planning fallback 冒充成功 保留安全失败消息与 final-reply-failed 审计验证	2026-08-12 22:24:17 +08:00
kdletters	fd423770d8	根治Repository checks本地漏检 ... 修复 Agent 失败展示变更中的 import 排序错误 统一 CI 与 master pre-push 的 Repository checks 入口 让 staged JS 和 TS 自动执行 ESLint 修复与 Prettier 补充部分暂存、忽略文件和待推 SHA 回归测试 同步分支保护与本地门禁流程文档	2026-08-12 22:06:35 +08:00
kdletters	794f3d4cf8	修复Agent失败原因丢失与成功误判 ... 解析 Codex app-server 稳定失败分类并生成安全可行动摘要 统一 Runtime 事件、任务、阶段记录和各 Agent 状态面的失败展示 限制自主构建最终回复 fallback，避免鉴权与网络错误被提交为成功 补充失败分类、防泄漏、待核对和 fallback 回归测试 同步技术方案与共享决策记录	2026-08-12 21:35:11 +08:00
kdletters	e04a8310a0	重做AGC智能体设置界面 ... 将常用设置、Agent 模型、连接工具和高级参数分层展示 补充保存中、保存成功和失败状态反馈 更新设置页测试与项目决策记录	2026-08-12 21:04:30 +08:00
lhk229	93d8d0c1cf	Merge remote-tracking branch 'web/master' into feat/five_min_design ... # Conflicts: # apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_request_builders.rs # apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop_tests.rs # docs/project-memory/shared-memory/decision-log.md # docs/project-memory/shared-memory/pitfalls.md	2026-08-12 12:38:03 +00:00
kdletters	82957fe1d4	修复子 Agent 澄清回执中转 (#165) ... Closes #163 实现 child 澄清回执到 Supervisor 的 needs-user-input 中转。 - child 返回结构化问题回执，Runtime fail-closed 校验问题和 SHA-256。 - Supervisor 创建自己的 durable user.input_request，重复唤醒复用同一 action。 - 用户回答沿用 same-run 回灌，后续 continuation 绑定原 delegation。 - 补充 Rust 定向测试、技术方案和共享排障记忆。 验证： - cargo check --tests - cargo test ... claimed_needs_user_input_delivery_becomes_one_supervisor_wait - cargo test ... static_delegate_user_input - git diff --check 注：npm run check:encoding 在当前受限执行环境中因 spawnSync git EPERM 未能运行。 Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/165 Co-authored-by: kdletters <kdletters@qq.com> Co-committed-by: kdletters <kdletters@qq.com>	2026-08-12 20:07:59 +08:00
kdletters	5e16837f3d	恢复游戏创作 External Editor 配置入口 ... 普通 Launcher、开发工作台和独立 game-chat 统一显示 External Editor 配置。 补齐配置可见性、密码输入和持久化回归测试。 同步配置静态门禁、PRD、技术合同与共享决策。	2026-08-12 18:43:55 +08:00