1194 Commits

Author	SHA1	Message	Date
lhk229	a60f95b554	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-17 04:30:42 +00:00
kdletters	abb3912530	增加分支与提交搜索校验 ... 增加分支和 commit 的输入搜索下拉构建前复核固定仓库中的分支与 commit 归属补充预览控制面接口合同、配置和测试	2026-08-17 12:04:31 +08: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
kdletters	c75fcbf023	修复预览构建状态解析与工作进程恢复 ... 限制 Jenkins 状态接口只返回监控所需字段 避免完整构建 JSON 触发反序列化递归深度限制 让预览外部生成工作进程在身份初始化后自动重启 补充定向测试、防回归检查和技术说明	2026-08-15 18:52:10 +08:00
kdletters	cf5eac1c63	修复Jenkins成功收尾状态竞态 ... 为队列、构建状态和部署产物查询增加有限重试 避免 Jenkins 瞬态无效响应永久覆盖成功部署状态 增加构建收尾竞态回归测试和技术说明	2026-08-15 18:38:59 +08:00
kdletters	ea81d8ebb5	修复预览数据库容器内存不足 ... 将分支预览 SpacetimeDB 内存上限覆盖为 2 GiB 保留生产与压测 Compose 的原有资源基线 增加预览内存覆盖防回归检查和故障说明	2026-08-15 18:33:30 +08:00
kdletters	d0a8f254b3	修复预览环境非交互发布 ... 允许 SpacetimeDB 向受控容器网络地址非交互发布 固定预览结果使用内网主机地址 补充发布参数与内网地址防回归检查和文档	2026-08-15 18:30:08 +08:00
kdletters	7cd8b39593	Revert "修复预览部署可选提交参数" ... This reverts commit d2366bc40a.	2026-08-15 18:09:04 +08:00
kdletters	5e7ff450b6	Revert "修复预览部署脚本执行方式" ... This reverts commit 7fc739fad0.	2026-08-15 18:09:04 +08:00
kdletters	7fc739fad0	修复预览部署脚本执行方式 ... 通过 bash 显式调用 Jenkins 源码检出脚本 增加脚本执行方式防回归门禁 同步预览部署执行合同文档	2026-08-15 18:03:49 +08:00
kdletters	d2366bc40a	修复预览部署可选提交参数 ... 修复 Checkout 阶段在严格 shell 下展开未定义 COMMIT_HASH 的失败 增加预览流水线参数归一化防回归门禁 同步预览部署参数合同与项目决策文档	2026-08-15 18:00:05 +08: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	89bbfd135a	M1C-0b：补齐静态委派状态前向兼容 ... - 未知 contractStatus 保留为 Unknown(raw) 并接入完成屏障、等待、返工与谱系门禁 - 补齐 planning Provider、自治 liveness 与终态扫描的 fail-closed 消费路径及回归 - 保持已知状态和损坏 sidecar 行为不变，更新技术方案与共享决策记录	2026-08-15 07:04:40 +00:00
lhk229	deae1e08ce	立项策划：裁决 M1C-1 三条开工前置，前向兼容粒度另拆 M1C-0b ... 对 2026-08-14「M1C-0 合入复核」留下的三条前置逐条读实代码后定稿： ① barrier：补，且必须是独立的第六个计数 user_revision_pending_count。 不能并进 repair_required_count——它带 repair_of_delegation_id.is_none() 只算原始委派，而用户第 2 次修订的父节点自身就是 repair 节点，并进去会让 第 2 次及以后的修订全部不阻塞。判据形状照 user_input_required_count。 另有四处逐字段读 barrier 的调用点不走 is_clear()，加字段不会自动传播。 ② 正向一致性：复用 EvidenceReady 的三条客观证据约束，并把该处 if/else-if 链改成穷尽 match；但不得更严——该函数在每次读取时都跑，过严会把写入方的 一个 bug 变成 delivery 永久读不出来。同时订正：这不是既有漏洞，唯一派生点 产不出该变体，约束的是 M1C-1 引入的第二个写入方。 ③ 前向兼容粒度：订正 08-14 自己写的「二选一」——「单条跳过并告警」不安全， barrier 是计数，跳过一条损坏的 Dispatched 记录会让 Supervisor 在仍有未完成 委派时收束，把可用性故障换成正确性故障。改走第三条路（损坏仍整体锁死， 前向不兼容解析进显式 Unknown 并最大化阻塞），并另开 M1C-0b 承接——该改动 触及 master 已发布机制的所有读路径，不得塞进 M1C-1 的 diff。 另记两条比 08-14 更糟的事实：锁死半径是整个项目目录而非单个 run； .json.previous 备份只在 primary NotFound 时回退，损坏但存在的 primary 不回退。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:57:12 +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
lhk229	8c4acaaad5	文档：记录 M1B-2 已合入原分支 ... 更新 Fast GDD 技术方案与 decision-log 的工作包状态和验收快照	2026-08-15 04:42:21 +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
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	ad3c460a28	文档：补齐 M1B-1 验收表提交状态 ... - 将 M1B-1 工作包表格同步为已提交于隔离分支 f453c2ca2。 - 保留待合回原分支及 M1B-2 后续边界。	2026-08-14 06:50:56 +00:00
lhk229	56e0a73ca4	文档：记录 M1B-1 隔离分支提交状态 ... - 将 M1B-1 的验收记录更新为已提交于隔离分支 f453c2ca2。 - 明确原分支仍待后续合回，保留 plan.submit_gdd 与审批闭环的后续边界。	2026-08-14 06:49:20 +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	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	fa42d4e490	文档：订正 M1A-1 的 retry 复核结论，plan 根 run 保源单列为 M1A-3 ... M1A-1 把 resolve_game_creator_agent_runtime_retry_configuration_at 判成 「已被 profile 挡住、本包不改函数」。该结论只对了一半：它确实不会让 plan 误得 autonomous 语义，但复核模板只问了「plan 进 matcher 后会不会误得不该 有的语义」，没问「plan 落到通用兜底后会不会丢掉该有的语义」。这个调用点 既是判据也是 run 构造器，两个方向都要问。 缺陷：plan 根 run 是 standard + 顶层无 parent，两个特例分支都不命中，落 agent-background-task 兜底。run_profile 由 agent_runtime_run_profile_identity_at 原样返回，实际只丢 source——第 22 节证据表原写「保留 source/profile」会 误导实现者去修一个没坏的东西，一并订正。 降级无声：retry 走 start_game_creator_agent_background_task_with_link_in_ session_lane_at，该路径对 source 无门禁；validate_agent_runtime_run_profile_ binding_record 也只在 autonomous-game-build 档要求可信 source。于是造出一个 正规启动路径造不出来的状态。 后果分两类。放行类：reject_supervisor_plan_root_steer 只认精确 source， 重试后不再命中，steer 重新放开，违反第 4.1 / 23.1 节裁决。死路类： root_control_authority 转 false 后广告层删掉 agent.goal_contract 与 agent.acceptance_update，validate_goal_contract_record 也拒绝建约，重试后 的根 run 建不出 Goal Contract，第 13.0 节审批前置门的取证永远收敛不了。 agent.delegate 不受该权限影响、委派照发，所以故障要到审批那一步才暴露。 处置：不回改已合入的 M1A-1，第 23.8 节新列 M1A-3，一并交付第 4.1 节要求的 强判据函数与 generic fallback 前的 exact plan root 分支；M1C-2a 依赖随之改为 M1C-1、M1A-3。修法边界写死：gui/cli 根 run 的现役降级行为不在范围，只能在 兜底之前插分支、不得改兜底默认值。 decision-log 原条目对应半句加删除线并挂指针，避免后续 PR 沿用旧结论。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 13:50:24 +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	91888bfd9e	文档：传导拆包与广告层更正，修四处自相矛盾 ... 均为上一轮拆包与第 19 节改写后未传导到位所致。 第 23.7 节：原写「变体、判据、receipt 写入必须同一个 PR」，与第 23.8 节 拆出 M1C-0 矛盾。改为判据在 M1C-0（惰性、无写入方、行为零变化）， 写入方与 receipt 在 M1C-1 同进同退；这样拆全程不产生半状态。 第 24 节第 8 条：不变量摘要仍写「广告层仍可见」，而第 19 节第 2 条已改为 目标态两层都拒。第 24 节是终态合同，留旧目标态会把 M1A-2 带偏。 第 23.8 节：审批前置门的门禁原挂在 M1C-1，但取证顺序是协议时序问题， 归 M1C-2a；M1C-1 只做 receipt。门禁随之对调。 第 12 节：原写 submit 分支「随后把顶层 run 投影为 waiting-for-user-input」， 与第 13.0 节冲突。这是 D9/D10 单 run 拓扑残留——D11 下调用 submit 的是 策划子 run，提交完即终态结束；审批等待属 Supervisor 根 run 且必须等 取证通过后才创建。提交分支现只负责校验、定版、写 GDD、追加 index、渲染。 第 4.3 节与 D10 作废条目的「广告层仍放行」保留但标注为 M1A-2 之前的现状。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:46:50 +00:00
lhk229	9605f31440	文档：对齐 M1 开工前的四处口径，并把 PR 结构冻结进方案 ... 第 19 节第 2 条改写：原文要求回归钉死「执行层拒绝」与「广告层仍放行」 两半，与第 4.3 节「allowlist 的作用是让它在广告层就消失」直接冲突， 且两节互相引用却结论相反。更正为：那段描述的是 M1 之前的现状不是目标态； 目标态两层都拒，回归第二半从「仍放行」翻为「不再出现」，纵深防御纪律保留。 第 23.8 节新增 M1 的 PR 结构与合入门禁：11 个 PR、依赖顺序与各自门禁。 PR 划分属工程流程契约，须团队可见——PR 描述不得引用个人工作稿， 原第 23.6 步骤五只有一句「未开始」，并行开工时无可引用的 DAG。 其中 M1C-0 与 M1C-1 拆开，因两者风险类别不同：前者改 master 已发布的 静态委派机制，后者是新增功能；合并会让「做游戏返工额度未被误放宽」 这条关键回归淹没在审批闭环 diff 里。M1C-2 拆 a/b，因失败模式无关。 第 23.6 步骤三订正：身份登记的代码已于 2026-08-13 合入， 原文仍写「代码落地属 M1」，进度过期。 第 23.1 订正：steer 资格判据在 goal_contract_root_steer_task_at (steering.rs:747，判据 763 行)，原文误记为同文件 714 行的 goal_contract_root_steer_replacement_run_id——行号对但函数名错。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:38:58 +00:00
lhk229	10af1fc377	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-13 12:17:26 +00:00
lhk229	eebe511a25	文档：裁决 Supervisor 自行提问维持 Prompt 兜底，不做成机制约束 ... 第 23.6 节待执行项中该条关闭。理由：本链路上 Supervisor 是自家 Prompt 驱动的受控角色而非外部输入，失效后果（问题被改写、答案转述失真）属产出 质量问题，由用户在审批卡上兜底，不是安全边界被突破；为它单独接一道 等价校验的成本落在 standard 全链路，与收益不成比例。 同时写明本裁决的纪律：第 4.3 与 5.2 节现有的如实记录必须原样保留， 不得因已裁决就改写成「已保证」——它记的是事实（standard 下 static_delegate_clarification_pending_matches_delivery_at 不触发）， 事实没变；M1 回归也不得断言「Supervisor 无法自行提问」。 并记录重新裁决的触发条件：若未来允许非自家 Prompt 驱动的 Supervisor。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:16:26 +00:00
kdletters	8e78be766e	修复AGC运行与首板版本登记 ... 修复旧模型定价覆盖缺少ElevenLabs音效模型导致启动恢复持续失败 支持对话框回车发送并保留Shift换行和输入法组合态 重试受理后立即清理旧失败投影并展示新Run状态 阻止Windows后台Codex探测反复弹出控制台窗口 首板试玩持久回执通过后幂等登记初始项目版本 补充定价、交互、Windows与版本登记回归测试和文档	2026-08-13 20:11:51 +08:00
lhk229	8a349c633e	文档：补审批前置门与用户修订不计返工两处空白 ... 第 13.0 节（新增）审批前置门：原文只规定「取证必须在 GDD 落盘之后」， 未规定相对用户审批的先后，第 13.3 节投影顺序里也没有验收图。 反序会产生无回退路径的死角——用户已批、receipt 不可回滚、根 run 却因 验收图未收敛完不成，GDD 状态是 approved 但流程卡死。 固定为：取证通过才允许暴露审批卡；未通过则不建审批卡，改发返工委派。 并列出三道门各自的失败路径：schema 不过不分配版本号、验收不过走返工 不惊动用户、用户不满意走修订。第 1.1 与 23.1 节的第 3 条约束同步补全。 第 23.7 节（新增）用户修订不计入 repair_depth：给 StaticDelegateContractStatus 增加第四个变体 UserRevisionRequested。 repair_depth 防的是 runaway agent，而用户点修改每轮都由人触发、 人本身就是循环边界，两者不应共用计数。本裁决不推翻 WP1 的 depth<=1，也不需要按 source 分流——做游戏链路不会出现该变体。 如实记录「无限修订」兑现不了：链上推断有 32 跳硬上限、版本链 128 上限， 产品阈值定 16 次软提示。反序列化须 fail closed，不得降级为 NeedsRepair。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:06:39 +00:00
lhk229	fa86b23248	文档：M0A-3 四之余收口，schema 与 golden vector 按 D11 重算 ... 第 5.2 节后半整段重写：决策卡改由 AGC_NEEDS_USER_INPUT_V1 终态信封承载， 线性化点由 session CAS 改为答案绑回 delivery，删除 Runtime 直投状态机。 第 8.3/8.4/8.6/12 节 identity 块补 agentId/rootAgentId/rootRunId/delegationId； source 按层区分：提交侧 agent-delegate，审批侧 project-supervisor-plan。 第 8.6 节删除 activeQuestion、roundsUsed 与 supersededCheckpointHandoffs， appliedAnswers 收窄并改挂 delegationId/continuationDelegationId。 第 9 节删除 checkpoint domain 与 supersededCheckpointProviderRequestIds。 第 9.1 节 golden vector 由代码重新生成：3857 bytes、a59856de7e…； 生成前先用旧 3707 bytes 重算得到旧值 d85c85dae3…，证明方法本身成立。 第 12 节重写消费证明三项与 stale 状态机，删除 checkpoint 整段。 第 14 节删除十行 checkpoint/activeQuestion 恢复语义，另立四行 D11 语义， 并把随之丢失的通用 handoff 安全边界单列一行保留。 第 6 节 Prompt 权威稿改为策划子 Agent 角色 brief 基线，提问改终态信封。 第 18.3 节 hydrate read model 改为 clarificationRound/repairDepth/awaitingAnswerFor。 第 21 节补六类 D11 必测项，含交替链与转述保真。 第 23.4/23.6 节状态更新：M0A-3 收口，M0 全部完成。 订正此前判断：四之余并非必须等 M1 strict schema。字段声明顺序本就由 第 8.3 节冻结、canonical bytes 本就在第 9.1 节，改字段等于改字节再重算。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 10:49:02 +00:00
lhk229	89b7a65171	文档：清除第 3.1 节一处行尾空白 ... Repository checks 的 git diff --check 门禁失败：文档第 260 行是一条只含两个空格 的空行。改为真正的空行。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:54:00 +00:00
lhk229	e5bc593afc	文档：更新 M1 计划中已过时的内容 ... 第 22 节「当前代码证据与 M1 接入点」逐行核过，改九处： - trusted source / matcher 消费者：plan source 进 matcher 已裁决，硬门解除； 但落地前须逐点复核 19 处消费点，steer 门须实现为独立于该 matcher 的显式拒绝 - Prompt Bundle：supervisorPlanChat / SupervisorPlanChat 随 D6 作废，不新增 composition 也不新增编译期 source kind；实际改动是 agentCatalog 新增 planning 平级条目，已落地 - Prompt 请求/收尾：D11 下不按 source 分流 composition - Supervisor collaboration：原「plan 跳过强制委派」方向反转，Supervisor 的主动作 就是委派 - user.input_request / decision checkpoint：后半段的 checkpoint turn 与 handoff 随 D10 作废 - completion blocker：收窄为只对策划子 Agent 不适用，根 run 不再整体豁免 - standard 路径 owner 产物验证：范围收窄，存在性证据已被静态委派 expectedArtifacts 覆盖，缺的是语义级校验，且内容正确性本就归 plan.submit_gdd 的 strict schema - Goal Contract：M1 待裁决项已全部关闭 新增一行记录已落地的 project-planning 身份登记。 第 21 节测试矩阵挂作废横幅：schema / session / Provider binding 三行中涉及 decision checkpoint、activeQuestion、checkpoint handoff、superseded 数组的必测项 随 D10 作废，不再是 M1 的测试义务；并列出 D11 新增的五项必测。 第 23.4 节同步：M1 入口前置决策已归零。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:49:41 +00: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	680bb200a8	文档：checkpoint handoff 私有持久化随 D10 作废，M1 入口前置决策归零 ... 该待裁决项待的是 plan-decision-checkpoint 专用请求 kind 的 handoff 契约，而该 kind 是 D10「Runtime 直投」的组成部分。D11 下策划子 Agent 以终态信封退出来提问、 run 随即结束，解释与下一步由 continuation 子 Agent 的第一个普通 tool-plan turn 完成，专用 kind 不存在，其专用 handoff 也不需要。 两条核实依据：现役 tool_plan_handoff::lookup_at 按 (agentId, runId) 寻址、与 agent 身份无关，已覆盖任何 Agent 的普通 tool-plan 响应；第 8.6 节预留的 supersededCheckpointHandoffs 全仓库零代码引用，作废无迁移成本。 通用 handoff 安全边界不受影响，策划链路照用现役机制。 M1 入口前置决策至此归零，剩余全部为待执行项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:22:42 +00:00
lhk229	ff9c2f8242	文档：裁决 plan source 进可信 matcher，验收图取自固定 Fast GDD 合格标准 ... 裁决一：project-supervisor-plan 进 agent_runtime_supervisor_source_is_trusted， 做方案链路正常参与 Goal Contract 协议。原阻塞理由（策划 Agent 无证据工具、 必然留下永不 passed 的节点）写于 D6/D9 拓扑，D11 拆两层后失效：策划子 Agent 的 allowlist 含 file.read/file.list，且 validate_acceptance_evidence_identity_at 只要求 证据属于同一根任务树、不要求是根 Agent 自己的回执。原「依赖 plan source 可信身份 的 M1 代码不得合入」硬门解除。落地前须逐点复核该 matcher 约 19 处消费点。 裁决二：验收图取自固定的 Fast GDD 合格标准，不由 Supervisor 每轮自由发挥。 GDD 是否合格与它描述的是什么游戏无关，因此「验收标准须在产物不存在的 turn 1 冻结且不可改」不构成矛盾。plan.submit_gdd 的 strict schema 承担字段与约束硬校验； Goal Contract 验收图承担「产物确实服务了本次意图」。Goal Contract 中按项目变化的 只有 outcome/nonNegotiables/forbiddenAssumptions/openQuestions 四项。 不改变 D1（支柱 2～4 条按项目生成）与 D8（不含引擎字段）已冻结的口径。 同批更正第 4.3 节一处失真：此前称「Supervisor 不得自行提问」靠机制保证，实为 不成立——该校验唯一生产调用点外层套着 run_profile == autonomous-game-build， 做方案链路跑 standard，不触发。改为如实记录为产品约束、缺机制兜底。 M1 入口前置决策至此剩 checkpoint handoff 私有持久化一项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:16:55 +00:00
lhk229	4d0f3e358c	文档：裁决 plan 根 run 不允许 steer ... 理由不是交互未验证，而是确定性的能力损失：D11 把问询轮次预算挂在委派链上， clarification_round 沿 repair_of_delegation_id 上溯且每跳强制 parent_run_id 等于 当前根 run；steer 换根后旧链 continuation 会被跨 run 隔离判据拒绝，该策划链路 剩余轮次全部作废、已回答内容无法续接。 实现约束：steering.rs:763 的资格判据 agent_runtime_supervisor_source_is_trusted 同时是 Goal Contract 创建权限的判据，因此不得靠「不把 project-supervisor-plan 加进该 matcher」来实现本裁决，必须是独立于可信 source 判定的显式否决，回归须 覆盖该 source 在/不在 matcher 内两种情形。 M1 入口前置决策至此剩两项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 07:32:26 +00:00
lhk229	0eca4c215f	文档：M0A-3 批二拓扑与工具面部分按 D11 重写 ... 已完成部分： - 第 3 节注册表：策划子 Agent durable source 由 agent-ready-task-scheduler 改为 agent-delegate；删除随 D10 作废的 plan.request_decision；Prompt composition 由 冻结值 projectPlanning 改为「不新增、复用现役」，消解与第 3.1 节的自相矛盾； run profile 成立理由改为委派父子继承；新增问询载体行。 - 第 4 节拓扑图重画为 D11 的委派 + #165 中转链路。 - 第 4.1 节整节重写为「Supervisor 根 run + 策划子 run」两层身份，并给出 「同一条策划链路」必须沿 delegation 链判定、不能只看 agentId 的理由。 - 第 4.2 节整节重写，supervisorPlanChat / SupervisorPlanChat 一并作废。 - 第 4.3 节整节按两层工具面重写。此处修正了一个方向性冲突：原文「明确禁止 agent.delegate」「跳过 collaboration 强制委派」，而 D11 下 Supervisor 在做方案 链路的主动作恰恰就是委派。 - 第 5.1 节对话循环四条按 D11 重写：问题落 delivery 而非 activeQuestion，线性化点 是答案绑定而非新 session primary，解释与下一步由 continuation 子 Agent 的第一个 普通 turn 完成，plan-decision-checkpoint 请求 kind 不再需要。 - 第 18.1 节前端入口 source、第 22 节 Prompt 行更正。 未完成部分（第 5.2 节后半与第 8.3～8.6 / 9.1 / 12 / 13 / 14 节）：这些与 golden vector 强耦合，改 schema 必须同步重算第 9.1 节 typed 指纹，而指纹必须由代码生成、 不得手写，M1 strict schema 尚未实现。逐段修补会产生「schema 已改、vector 未换」的 中间态，比暂时保留旧文更危险。已加作废横幅说明其只作为 D10 时代历史记录、不得作为 实现依据，并在第 23.6 节把它拆成独立的「四之余」步骤登记。 仅文档改动，无任何代码变更。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:58:12 +00:00