2835 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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	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	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	84f6e6ec20	合入原分支最新改动	2026-08-13 14:16:25 +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	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	7052d3e692	修复Windows维护页门禁执行 ... 转换WSL bash所需的脚本、参数和环境路径 在POSIX平台校验实际0644权限并在Windows校验安装源码契约 保留维护页原子替换与符号链接防护测试	2026-08-13 14:01:34 +08: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
kdletters	1b4cb3c45e	修复Windows下Git钩子回归测试 ... 统一比较Git恢复文件时的换行符 将WSL bash测试使用的临时工具路径转换为可执行路径 确保master推送门禁在Windows与Unix环境下均可重复验证	2026-08-13 13:50:27 +08:00
lhk229	62fc86e7db	文档：D11 条目同步 WP1 已落地，旧上限改为改造前对照 ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:44:12 +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	21137f676b	修复issue160 (#166) ... #160 --------- Co-authored-by: kdletters <kdletters@qq.com> Co-authored-by: 段舒康 <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/166 Co-authored-by: Linghong <ink29535@proton.me> Co-committed-by: Linghong <ink29535@proton.me>	2026-08-13 13:28:45 +08:00
lhk229	8c4b64c259	文档：执行计划入档，并修正 WP1/WP2 已完成后的过时陈述 ... 新增第 23.5 节记录 WP1/WP2（静态委派澄清轮次与返工深度拆分）的问题陈述、 定稿语义、门禁与完成状态；新增第 23.6 节记录五步执行计划、M1 开工前必须 处置的两类事项，以及四项明确后置、不阻塞任何一步的工作。 修正两处已过时的表述：文首状态行与第 1.1 节第 5 条在 WP1/WP2 已合入本分支后， 仍写着「WP1 落地前问询上限仍是 1 轮」「正在另一个 worktree 并行实现」。 第 1.1 节另补记批一执行状态，M0A-3 的剩余工作只有批二。 此前会话中一度使用过的 WP0/WP3/WP4/WP5 编号从未落进仓库，本次不引入， 其余内容按性质归入第 23.6 节的两类清单，避免出现两套不一致的工作包编号。 仅文档改动，无任何代码变更。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:20:09 +00:00
lhk229	146b7a215f	文档：对抗性复核修正 project-planning 登记机制记录 ... 复核结论：build.rs/specialist_nodes/validate_agent_catalog 等核心机制主张 逐行核对代码原文，全部准确（含所有 file:line 引用）。修正两处问题： 1. decision-log.md 声称 provider_request_builders.rs:536-539 与 prompt.rs:416-417 报同一错误字符串「未知 Agent 模板：project-planning」， 逐行核对后两处错误文案实际不同（后者是「未知 Agent：project-planning」， 没有「模板」二字）。已改为分别引用真实文案。 2. 独立扫描 GAME_CREATOR_AGENT_GROUP_DEFINITIONS 遍历模式，发现一个 R1 调研遗漏的 needs_change：task_start.rs 的 collect_game_creator_agent_runtime_agent_ids 与 game_creator_agent_role_definition 是同构的二分硬编码，是核心恢复驱动 read_game_creator_agent_runtimes_at 与三处安全网（崩溃恢复扫描、steer 级联取消、委派回执兜底对账）的枚举来源，project-planning 登记后不会 被这三处发现。已追踪 agent.delegate 派发路径确认委派首轮任务同步起跑、 不受影响，故定级 needs_change 而非 blocking。同时补记 runtime_adapter.rs 里断言 catalog 精确集合的既有测试需要同步更新。 git diff 核对确认本轮及此前一轮均未改动任何 .rs 或 manifest.json。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:08:25 +00:00
lhk229	d3d0ae95e5	文档：定稿 project-planning 的 agentCatalog 登记机制（与 supervisor 平级、不进 groups） ... 在技术方案第 3 节新增 3.1 小节：project-planning 登记为 agentCatalog 下与 supervisor 平级、不属于任何 group 的独立条目，使 specialist_nodes（只读 groups[].roles[]）、build.rs 的 validate_seed_task_catalog 与 16 任务种子 DAG 均不需要改动；给出 descriptor 元数据取值（groupId 自引用、不设 groupLabel、toolId 走 agent.runtime.* 命名族、capabilityAuthority 沿用 现有常量）与编译链路要改的确切位置清单。同时如实记录调研发现的新缺口： 仅做 catalog 登记不足以让 D11 静态委派可执行——prompt.rs 的 game_creator_agent_role_definition 硬编码「非 supervisor 即 group 角色」 二分，需 M1 补一个平行分支；另有 task_ops.rs 误分类兜底、 delegation.rs 的 agent.spawn_isolated 放行面扩权两处 needs_change。 同步更新第 23.1 节待裁决项（登记方式已定稿，代码留给 M1，真正的前置 是 prompt.rs 角色身份合成缺口）、第 1.1/2 节里因此过时的「待裁决」措辞 （避免与新结论自相矛盾），并在 decision-log.md 顶部补记本次定稿与 「做游戏链路一行不动」的机制依据。本轮仅涉及文档，不改任何 manifest.json 或 .rs 源码，注册代码留给 M1。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 04:56:13 +00:00
lhk229	d09307fd64	Merge branch 'feat/clarification-round-split' into feat/five_min_design	2026-08-13 04:26:39 +00: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	0ca52d85f0	文档：补记 D11 新拓扑与静态委派澄清轮次/返工深度拆分（WP1）决策 ... 新增 2026-08-13 决策记录条目： - D9 二次作废、D10 作废，立项策划改为 Project Supervisor 静态委派子 Agent（D11），复用 PR #165 澄清中转链路，命名裁决冻结（agentId=project-planning，source=project-supervisor-plan）。 - WP1：clarification_round 与 repair_depth 两个运行时派生维度拆分定稿——分类判据、传播规则（澄清跳不重置 depth、返工跳重置 round）、上限按 source 区分（game-chat 取 1，其余取 3）、总跳数上界 1+(1+1)x3=7 跳/8 条 delivery 记录的推导（并说明常见漏算为 6 的原因）、以及不得新增持久字段（fail-open 风险）与最脆弱回归点（返工跳漏掉 depth+1）。 - 推翻 2026-08-12"子 Agent 澄清回执由 Supervisor 中转（Issue #163）"条中"随后最多创建一次 continuation"的结论。 - 记录新增待裁决项：project-planning 的编译期 agentCatalog 登记方式与 build.rs 一致性校验。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:32:04 +00:00
lhk229	8d701e750c	文档：D9 二次作废、D10 作废，立项策划改为 Supervisor 静态委派子 Agent（D11） ... - 第 2 节决定表：D9 标注二次作废（保留原文，说明哪些结论被 D11 继承、哪些被推翻）；D10 一并作废（其存在前提"ready-task 节点无 parent、Runtime 拦不住"在新拓扑下不成立）；新增 D11，表头改为 D1～D11。 - 第 1.1 节新增"D11 新拓扑"小节：立项策划节点改为 Project Supervisor 通过 agent.delegate 发起的静态委派子 Agent（agentId=project-planning），问询复用 PR #165 中转链路；列出六条已验证支撑事实（均带 file:line），并注明 D11 依赖 WP1（澄清轮次/返工深度拆分）为强制前置。同步标注旧"新拓扑（替代 D6）"小节已被取代，更新"分两批执行"：命名裁决已完成，批二改由 build.rs agentCatalog 一致性裁决阻塞。 - 第 19 节第 2 条、第 24 节第 8 条：改写为"执行层由 Runtime 兜底拒绝、广告层仍可见"的准确表述，替换失效的"排除是产品自律"旧表述。 - 第 4.3 节：修正与第 19 节第 2 条矛盾的 plan source 四工具清单（其中列着 user.input_request）。 - 第 23.1 节：策划节点命名裁决标记已冻结；新增 project-planning 的 build.rs 一致性待裁决项；plan run steer 待裁决项按 D11 拓扑更新。 - 文首状态行、第 1 节开篇段同步更新为 D11 现状。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:31:49 +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
lhk229	331441534d	文档：冻结策划节点身份常量并更正提问权限判据 ... 裁定策划节点 agentId 为 project-planning、Supervisor 做方案入口 source 为 project-supervisor-plan（旧预留值 project-supervisor-plan-chat 作废， 避免字面未变而语义已改导致接错代码路径）。据此更新第 3 节注册表与第 4 节 拓扑图。 更正一处此前判断错误：standard 的 ready-task 调度器 start_game_creator_agent_background_task_with_source_at 向 _with_link_at 传 task_link = None，节点无 parent，source 也不在黑名单，因此 validate_user_input_action_owner 会放行它调用 user.input_request。 只有 autonomous 那个调度器才显式写 parent。所以策划节点不得直接提问是 产品约束的自律要求（否则问答会落进它自己的会话、Supervisor 上下文里 没有内容），必须由 exact allowlist 主动排除并以回归钉死，不能指望 Runtime 兜底。第 1.1 节、D10 与第 19 节第 2 条同步更正。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 12:29:16 +00:00
lhk229	6119060dc0	文档：作废 D6，立项策划改为 Supervisor 下游工作流节点 ... 产品侧确定「做方案」入口独立成链后复核代码，D6 的前提逐条不成立： autonomous-game-build 对 user.input_request 的禁令按 run profile 生效、 父子皆不可提问；硬闯会把 runtime.status 写成 failed，而根活跃判定不认 failed，导致整条 16 节点工作流永久瘫痪；子 Run 又不能切换父 Run 的 profile；作为下游的策划节点带 parent，也不能自己提问。 新增 D9 / D10 取代 D6：策划是独立 agentId 的下游工作流节点，父子同为 standard；问询走 Runtime 直投——策划节点提交结构化决策字段，Runtime 创建 owner 为 Supervisor 的 pending。这不是新造机制，现役 AgentRuntimeUserInputRecord 本就两路投影（会话消息 + observation）， 直投只是让两路分别落到 Supervisor 与策划节点，从而满足「用户侧只有一个 对话对象」与「对话内容必须物理存在于 Supervisor 会话」两条产品约束。 新增第 1.1 节承载变更说明与 M0 修订计划（工作包 M0A-3），按是否被 agentId/source 命名裁决阻塞分两批。三个代码工作包零回退——无一行按 D6 编写；但 M0A-2 的 owner 验证四重绑死且要求 parent，standard 路径必须 另建物理独立实现，不可扩展。 Goal Contract 四方案随之作废，替换为三条实测约束，其中「验收 evidence 锚 game/fast_gdd.md、不得指向 .agent/planning」是为了避开 reject_agent_runtime_private_control_path 不区分读写的陷阱。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 12:13:04 +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