2967 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
lhk229	ddb8eaec37	澄清转述 pending 不再被自己的任务身份校验判成 needs-reconciliation ... D11 里 Runtime 代 Supervisor 汇总子 Agent 澄清问题时，pending 动作的 task 字段 存的不是本 run 的任务，而是一段 Runtime 生成的转述指令（provider_recovery.rs 的「子 Agent 需要用户澄清后才能继续。delegationId=…」），delegationId 就编码在 前缀之后，另有四处按这个前缀反解绑定关系。 但 validate_agent_runtime_pending_context 会拿 pending.task 与 runtime .current_task 做相等比较，而落等待态的 persist_game_creator_agent_user_input_ wait 只改 status/phase/waiting_on，从不同步 current_task。其余五个 pending 创建 点传的都是 run 的真实 task，相等断言对它们成立；转述这一处永不可能成立。 后果是必现而非抖动：用户答完问题、观察已落盘（status=observed-approved）后， resume 立刻被判 needs-reconciliation，整条立项策划链在第一次澄清就断。 实测证据（run 14）： runtime.currentTask = 做个横版像素解谜小游戏，主角是个能操控自己影子的小机器人。（29 字符） pending.task = 子 Agent 需要用户澄清后才能继续。delegationId=delegation-ec059abd…（355 字符） 任务日志 27 条全部是前者；plan 根没有 autonomous completion contract， autonomous_effective_root_task_at 两侧都走 fallback，比较退化成裸文本相等。 这条路径此前从未执行过——澄清信封在 run 11/12/13 一次都没触发，缺陷因此一直 藏在 0 轮问询后面。 只豁免文本相等这一条。agent/task_id/session/run/source 五项身份检查在它之前已 全部通过，轮次检查在它之后继续执行，转述 pending 本身也只能由 Runtime 在本 run 内生成，所以不放开任何跨 run 或跨身份的重放面。没有选择改 pending 的持久格式： task 字段被当载荷用是既成事实，四处反解加在途 pending 迁移，风险与收益不成比例。 顺带把散落五处的同一段 strip_prefix 链收成 user_input.rs 的一个共用判据。抄本 之间一旦漂移，转述路径会静默失去与原 delivery 的绑定，那是比本次更难查的故障。 回归测试双向变异验证：恢复严格比较则转述被拒（红），整条删掉则被改写 task 的 pending 不再被拒（红）。受影响测试组单线程 124 passed / 0 failed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 05:19:34 +00:00
lhk229	7a01f944dd	立项策划根 run 改用专用 Supervisor prompt，不再是通用合同的差集 ... 原型系统几分钟就能跑完同一条链路且全程有澄清问答，生产链路 run 11/12/13 三次 澄清轮数都是 0。拓扑不是差异来源——两边都是 D11。差的是 Supervisor 读到的 东西：原型给它一份 1.4k 的专用提示词，明写「你不生产策划内容」和固定动作序列； 生产给它的是 13.5k 的通用总控合同，预设手里有 43 个工具、六个专业组、isolated child、正式任务图和视觉产物合同，而 plan 根一个都没有。 此前的做法是在通用合同上逐段做减法（$visualContract、supervisorIntro、 isolatedTemplateCatalogIntro、$isolatedAgentTemplates 四个 `if plan_root` 分支）。这个形状本身在漏：模板目录那一段就是漏到第三轮才发现的，而每漏一段 都是一次已实测的偏航。现在整份换成 manifest 里的 supervisorPlan composition， plan 根的段落清单一眼可读，不再散落在两个函数的四个否定分支里。 保留的三段各有硬理由： - isolatedAgentContract —— expectedArtifacts 合同，agent.delegate 同样要用。 - supervisorRepair —— 返工必须用原 delegationId 重读 claimedDelegateContract 并逐字继承 acceptanceCriteria/expectedArtifacts。run 12 连撞两次的就是这条。 - planCommon —— common.md 的子集副本，见下。 替换的两段： - planSupervisorIdentity 取代 supervisorIdentityContract。后者的「用验收标准和 预期产物把边界清晰的任务委派给合适的专业 Agent」正是替用户预先裁定的压力源， 且 plan 根只有一个可委派目标；末句的黑板与 Agent 记忆在收窄后的工具面上是 死文本。 - planSupervisorPlaybook 取代 supervisorPlaybook。后者首段讲 spawn_isolated 批次与 manifest DAG、末段要求「manifest 正式任务图已完成」，在本链路都不可 执行。新段落照原型形状写死六步动作顺序，并补上生产此前完全没有的转述保真 规则：`[已确认] {header} → 用户答：{原文}` 逐条列出，任务接近长度上限时压缩 自己的说明而不是压缩用户答案。 删掉的三段： - common.md 有 43% 是 plan 根执行不了的内容（改码流程、git 提交、联网检索、 整段「作为被委派的专业 Agent 时」的身份错位），其中「最后一次修改后必须成功 执行 project.verify 才能 respond_to_user」还是一道 plan 根永远满足不了的假 门禁。但同一段压着这条链路唯一的原创性红线、user.input_request 协议和静态 委派协议——D11 的协议正文在这里，不在 playbook。所以 planCommon 逐字复制这 三段，并用 tripwire 断言反向钉住：planCommon 的每段都必须能在 common.md 里 逐字找到。 - supervisorClaimGate 讲 minIsolatedGroupsBeforeClaim，无 isolated group 时恒 不触发。 - $platform 整段是 command.start/exec/poll/stdin/terminate 的用法合同，plan 根 一个 command 工具都没有。GDD 里的平台事实由 Runtime 另行注入，与这段无关。 提示词头部改用上一笔提交的 allowlist 拼工具清单，与 Provider 请求实际广告的 函数目录共用同一份事实。两边各自维护一份就会退回「合同说有 43 个、请求里只有 9 个」的自相矛盾，而那正是收窄工具面本身要消灭的东西；这一致性单独钉了一条 断言。 supervisor/playbook.md 里的反预先裁定段落保留。执行层只单向拦住 plan 根， agent.delegate 的 agentId 是自由字符串，gui/cli Supervisor 委派 project-planning 并未被禁，那段在通用 lane 不是死文本。两份逐字相同，另有一条 tripwire 钉住。 plan 根实际拼到的提示词从 13531 字节降到 9049 字节，但重点不是体积——是被删的 全部执行不了、补上的固定动作序列此前完全缺失。 已变异验证四条新断言。全量 2238 passed / 10 failed，逐条单线程复跑后 7 条转绿 （并行噪声），剩余 3 条是本机缺 rg 与 CRLF，与本次改动无关。 尚未验证的是这些文字是否真的改变模型行为——单测只能证明它进了提示词。判据是 下一次 E2E 能否触发 AGC_NEEDS_USER_INPUT_V1 信封。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 04:50:37 +00:00
lhk229	2e6c0e7ac2	立项策划根 run 的工具面收窄成 7 个原生工具的 exact allowlist ... plan 根 Supervisor 此前拿到的是未按身份收窄的全量注册表：43 个原生工具外加 项目 MCP 目录。其中约 36 个在这条链路上根本执行不了——写入、补丁、删除、 命令、预览、画布、任务图、记忆、黑板、agent.spawn_isolated、 agent.route_manifest、agent.schedule_ready 都会被执行层拒绝。 广告一个执行不了的工具不是中性的。M1A-4 已经实测到同类后果：上下文里残留的 专业角色目录让 Supervisor 照着发起 agent.delegate，被拒后再没能自行改回 project-planning，整个 run 空转到预算耗尽。工具面同理——本链路的策划内容全部 由 project-planning 子 Agent 生产，Supervisor 手里多一个写文件或跑命令的入口， 就多一条它自己下场干活的诱导路径。 allowlist 定为 user.input_request、file.read、agent.delegate、 agent.goal_contract、agent.acceptance_update、agent.action_history、 agent.run_status，加上两个协议控制函数。后三个原生工具只为 §13.0 的审批前置 取证门存在（分页读 game/fast_gdd.md 并列出全部分页 actionId）；file.list 一并 砍掉，取证路径是固定的，不需要列目录。 实现沿用 restrict_plan_root_goal_contract_schema 已有的后置收窄形状，而不是给 build_agent_runtime_native_function_tools_for_agent 加参数：两处调用点本来就在 `if plan_root` 里，改动面更小，也不会波及其它 lane 的目录构建。 收窄写成交集而非断言。协议修复路径会先整份重建目录再按场景收窄，其中 restrict_agent_runtime_supervisor_collaboration_repair_tools 硬要求目录里存在 agent.spawn_isolated；plan 根这一遍必须排在所有分支收窄之后取交集，早于分支 会让那条检查失败，晚于分支才能保证任何修复轮都不把被裁掉的 36 个工具重新广告 回去。 回归断言写成精确集合而不是「不包含某几个」，将来往注册表加工具不会静默漏进 plan 根；同时断言 MCP 前缀工具不残留、收窄确实裁掉了东西（否则测试是空跑）。 已变异验证。 本次只改广告目录。提示词头部仍按全量注册表拼工具清单，二者的一致性由紧随其后 的 prompt 提交收口——单独看这一笔存在「合同说有、请求里没有」的过渡态。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 04:49:48 +00:00
lhk229	4f2136c919	立项策划 brief 补回被工具面收窄连带切掉的原创性红线 ... common.md 的原创性条款（2026-07-27 `427a8c151` 为做游戏链路引入， 2026-08-03 `e2b5056af` 抽进 common.md，两者都早于本分支）随 $base 分发给 每个专业 Agent。策划子 Agent 在 M1A-2 改成 exact allowlist 后走专用小 prompt、不拼 $base，该条款随之丢失。 不拼 $base 是对的——common.md 大量内容讲写文件、跑命令、起预览、再委派， 策划子 Agent 一个都没有，塞进去会让广告工具面与文字合同打架（理由已记在 game_creator_project_planning_tool_plan_system_prompt 的注释里）。但原创性 不属于工具面，是内容约束，跟着一起被切是连带损伤。 后果是缺口而非退化：GDD 是整条产线的上游，策划稿里落进受保护名称，下游做 游戏的 Agent 即便个个守规也已经晚了。实测中原创性由用户需求原文自带，产品 侧没有任何一层兜底。 补进 roles/project-planning.md，措辞按本 Agent 实际产出收敛（GDD 正文、决定 台账、原型验证项、targetUsers.referenceGames），不涉及它无权写的代码与图片。 回归断言的是「策划子 Agent 实际收到的完整 prompt」而非某一层，将来若把 common.md 拆成工具面与内容红线两段再正常合成同样成立；并以 common.md 原文 作对照基线，那边被改写时一并报警。已变异验证。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 03:10:34 +00:00
lhk229	db740d8ae6	台账逐项比对失败改判为可回灌的输入错误 ... plan.submit_gdd 的 session_decisions_match_input 校验此前与三条真 CAS 判据 （sessionRevision 溢出、session 已被其它动作推进、Runtime source revision/fingerprint 无效）共用 PLAN_SESSION_CAS_CONFLICT，因此被 plan_submit_error_is_business_rejection 漏掉，一次不匹配就 needs-reconciliation 硬阻断整个策划子 Agent。 两者性质不同：真 CAS 说明 durable 权威已变或已坏，重交同一份 input 不可能成功； 台账不匹配时权威完好，错的是本次 Provider input——子 Agent 把决策摘要抄漏、抄错， 或多追加了一条非 default_pending 决定。按第 12 节自己的判据，后者属于「本次 Provider input」，该走 rejected observation 回灌并受既有 5 次预算约束。 拆出 PLAN_SESSION_DECISIONS_MISMATCH 并纳入 business rejection，真 CAS 三支 原样保留 reconciliation。不变量未放松：不匹配照样拒、照样不产生任何事实， 伪造用户确认仍然不可行，只是拒绝的后果从叫人变成让它改稿。 实测触发：子 Agent 连撞三次形状层（PLAN_INVALID_REQUEST），每次都按回灌理由 改对一部分，机制运转正常；第四次形状合法后随即撞上台账比对，直接阻断， 整条链路零产物。即越接近提交成功越容易撞上不给重试的门。 覆盖：改写既有决定正文 → 新码；同一份 input 只改陈旧 revision → 仍是 CAS； 追加伪造 confirmed 决定 → 新码且不落任何事实；分类器两向断言。分类器一条 已变异验证。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 02:45:37 +00:00
lhk229	d284639903	立项策划根 run 的上下文层不再列出专业角色目录 ... 共享 runtime 合同里的「agent.spawn_isolated 合法 templateAgentId」静态模板目录 会把 design-director 等全部专业角色名拼进 plan 根 Supervisor 的 system prompt。 plan 根的 agent.spawn_isolated 已被 M1A-4 无条件拒绝，这份目录因此没有任何可执行 语义，此前按「死文本」处理。 实测证伪了这个判断：目录第一个名字就是 design-director，Supervisor 首轮据此发起 agent.delegate，被执行层以 plan-root-child-target-unsupported 拒绝后未能自行改回 project-planning，整个 run 空转到 loop 预算耗尽、零产物。漏掉的推理是目录虽为 spawn 而设，模型会把里面的名字挪去当 delegate 目标。 改为在上下文层删掉目录本身，即第 19 节第 2 条要求的第二层，不替代执行层硬拒。 只删 spawn_isolated 专属的两段；isolatedAgentContract 讲的是 expectedArtifacts 与 writeScopes，agent.delegate 同样要用，逐字保留。 覆盖：plan 根 prompt 遍历 GAME_CREATOR_AGENT_GROUP_DEFINITIONS 断言不含任何角色 task_id（新增角色自动进覆盖范围）；非 plan source 与其余 agent 逐字等于未收窄的 合成结果且目录完整。前者已变异验证。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 17:33:43 +00:00
lhk229	938b7ce654	手动提交：修复CI失败	2026-08-20 13:40:30 +00:00
lhk229	c1dba09049	让 static-smoke 夹具满足收紧后的入口合同 ... 9a7a79951 给 finish_agent_runtime_project_verification_locked 加了一道复核：记录 game.static_smoke 通过时，按当前磁盘内容重跑 validate_game_html_smoke。五个夹具 仍停在收紧前的形状——它们各自只为视觉门、模块可达性或 owner 产物判据构造入口页， 没有目标说明、主循环或输入监听，于是伪造的 smoke 通过一律被拒，用例从未绿过。 生产代码不动：draft_validation.rs 与 master 逐字一致，project_gates.rs 里那段复核 逻辑也和 master 相同。只把夹具补到合同要求的形状： - 数值常量作用域、内联/外部模块图集三处改用仓库已有的 with_static_smoke_contract 包一层，被探测的常量引用与模块结构原样保留； - 终态投影用例的入口页原本只有一个空实现回调，空回调本身触发另一条判据，去掉后 同样包上合同层，写入次数不变、revision 断言不受影响； - owner 产物用例是真实新项目，入口是无画布占位页。它在断言过「占位页过不了真实 smoke」之后才需要一份过期 smoke 凭证，故在 owner 产物之前先落一份合规入口， verified_revision 仍取最后一次 owner 产物； - 自主 manifest 用例只写了 package.json，直接用普通文件写入落一份合规入口，不触碰 revision 记账。 顺带修一处仿造 gate：清 static_smoke_verified_revision 时必须同时清入口摘要， 两者是一对，否则 gate 自身的一致性校验会先于被测行为拒收。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 13:00:09 +00:00
lhk229	e54ebb8227	补齐 master 带入代码的 rustfmt 输出 ... 合并 master 后 cargo fmt --check 在 ui_editor/layout/node.rs 报差异（枚举变体的 行尾注释未对齐）。只是 rustfmt 的既定输出，无语义变化。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 12:29:26 +00:00
lhk229	0bd41112b4	瞬态重试恢复不再被策划用量折叠边界判成自杀 ... 策划子 Run 第一次 tool-plan 请求撞上 HTTP 524，通用重试机制留下 retry sidecar 并 唤醒同一个 run；该 run 重新走到新请求边界时，fold_plan_provider_usage_before_new_request 把「本 run 自己那条未收口的 exchange」判成 PLAN_PROVIDER_USAGE_DEFERRED 硬失败。 于是子 Run 直接 failed，回执退化为 needs-repair，逼总控走完整的查状态→认领→返工 委派流程，一轮实测白烧四轮 Provider 请求。等于策划子 Run 撞上任何一次 502/524 都必定自杀。 延期判据本身没错——它的第一条就是「该 run 存在 retry sidecar」，而这恰恰是重试 恢复的必经状态。折叠是记账动作：exchange 没收口时本来就不该计入 session，跳过一 次是正确的，收口后的下一个边界会补上；真正裁决重放还是重发的是下游 retry / handoff 身份比对，它本来就预期 sidecar 还在。 边界函数改为接收本次请求所属的 run，只豁免「延期完全由该 run 自己造成」这一种。 三个 runtime_actions 边界传当前身份；planning_coordinator 三处在派生后继 session， 子 Run 的在途 exchange 对它们仍是硬阻塞，传 None，行为不变。内部折叠额外返回延期 来源，公开枚举与既有调用方签名不动。 用例覆盖四个方向：本 run 放行、别的 run 仍硬失败、None 调用方行为不变，以及收口 后用量仍如数折叠进 session（豁免是延后记账，不是丢账）。已实测关掉豁免后该用例 复现线上原话。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 12:29:11 +00:00
lhk229	19f4b6276c	合并 master（0797410ee） ... 三处冲突： - decision-log.md / pitfalls.md：双方各自追加条目，两边都保留；决策记录是新在 前的日志，master 的 2026-08-20 条目排在本分支 2026-08-19 之前。 - panels.tsx：canRetrySupervisor 两侧逻辑逐字相同，只差续行缩进。实测本分支版本 过 prettier、master 版本不过，故取本分支缩进；顺带把 master 一并带进来的相邻 needsSupervisorReconciliation 块补成 prettier 输出。解析结果与合并前该文件逐字 一致，没有语义改动。 已逐项核对本分支 11 个提交的关键标记在合并后仍在树上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:48:29 +00:00
lhk229	802f06d59d	全局异步 runtime 的 worker 用上 Runtime 自己的栈预算 ... Agent Runner 在父 run 认领委派回执那一刻整进程消失，调用方只看到 connect 超时， runner 日志里两行 stderr 又被日志泵按「非诊断输出」抹掉。放开原始 stderr 后拿到 真相：thread 'tokio-rt-worker' has overflowed its stack。 Runtime 的 agent turn 调用链本来就深，task_queue 早就给自己起的后台线程配了 AGENT_RUNTIME_BACKGROUND_WORKER_STACK_BYTES；但静态委派的父 run 唤醒走的是 tauri::async_runtime::spawn，落在 Tauri 全局 runtime 的 worker 上——那个 runtime 由 TokioRuntime::new() 建出，worker 吃 tokio 默认栈（tokio 1.52 起该线程名就叫 tokio-rt-worker）。同一段代码在自家 16 MiB 线程上天天跑完整轮次，换到默认栈就爆， 所以不是无限递归，是那条链从来没被这个线程池的尺寸覆盖过。 进程入口在任何异步派发之前用同一个常量建 runtime 并 async_runtime::set 装上； handle 要求底层 Runtime 常驻，故刻意泄漏。这样十余处 async_runtime::spawn 一次 性都拿到同一份栈预算，而不是逐个改调用点。 回归用例在自建 runtime 上 spawn 一条 3 MiB 深的调用链。注意它的失败形态是整个 测试进程被 abort 而不是断言失败——已实测拿掉 thread_stack_size 后复现的正是线上 那行 tokio-rt-worker has overflowed its stack。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:41:20 +00:00
lhk229	5c2d722b12	立项策划 role brief 按解析器真实线格描述澄清信封 ... brief 只写「下一行给出严格 JSON 的单题问题」，模型据此输出裸的单题对象，还自创 了一个 answerFormat 字段： {"header":...,"prompt":...,"options":[...],"answerFormat":"回复 A、B..."} 解析器要的是 {"questions":[{id,header,question,options}]} 且 deny_unknown_fields， 于是父 run 收到 unknown field `answerFormat`, expected `questions`。此时子 Run 已经终止，信封没有修复通道，整条委派直接停在 needs-reconciliation。模型其余部分 （第N轮·关键决定、A/B/需要原型验证 三项合同）都严格照 brief 执行，说明它跟的就是 brief——两份 prompt 描述了两种形状时，模型跟更具体的那份。 brief 改为逐字给出外壳、四个允许字段、id 的 snake_case 规则和各字段字符上限，并 点名 answerFormat 这个真实踩过的坑。上限数字全部来自 schema 常量，新增用例用 format! 把两边钉在一起，任一边先改都会红；为此把相关常量放宽到 pub(crate)。 这一条只改立项策划自己的 role brief，其它 Agent 的 overlay 不受影响。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:08:44 +00:00
k88936	0797410eef	Feat/UI自动识别和布局编辑器简化版 (#170) ... * 支持从项目, 本地电脑, 主站导入/引用素材. * 页面复杂, 需要足够空间, 作为资源打开时会占满右侧 * 编辑结果作为一种新的美术资源. * 新增素材按钮现在是空的实现, 临时在旁边加了一个新增UI设计的按钮 临时入口:  简化: * 组件实现了最基本的图片和文本 * 容器式布局未接入llm编辑 * 不同阶段统一维护一个状态State, 任何阶段都可以人工调整, 不设单独的步骤 * 多图的UI合并功能暂时不要求, 隐藏入口 * 因为生成工具尚未从主站迁移, 主站地图子画布未实现, 以tab栏的形式容纳素材的子画布需求搁置 * 未实现llm绑定字体功能 * 识别会替换现有UI树, 暂时不是增量的 Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/170 Co-authored-by: 王德宇 <kvtodev@outlook.com> Co-committed-by: 王德宇 <kvtodev@outlook.com>	2026-08-20 19:07:25 +08:00
lhk229	3bae4cdbb0	澄清信封在整条回执通道上不再按自由文本盲切 ... 上一轮只堵了通道末端，父 run 仍然停在 needs-reconciliation：子 Agent 输出 518 字符的合法问询，在源头 last_response 处就被切成 501 字符，剥掉信封首行后 正好 1120 字节，父 run 解析时在字符串中途 EOF。 信封是结构化协议载荷，只是恰好借用了「子 Agent 自由回复」这条文本通道。定界 本身要保的三件事——状态快照与只增审计日志不被自由文本撑爆、子 Agent 文本不无 限量灌进父 Agent 上下文、摘要行只占一行——对信封都已由问询 schema 逐字段硬性 校验保住，再叠一层盲切只会砍断 JSON。 改为共有一条上限规则 static_delegate_result_detail_max_chars：字面以信封首行 开头时取 schema 推导的上限，否则原样走各自的 500/600/240。通道上四处定界全部 接上——last_response、terminal_detail、回执发布、复用既有终态时的摘要，其中 后者把「给人看的摘要」和「给解析的明细」拆成两个值，不再让一行摘要的长度决定 结构化载荷能不能被解析。last_response 与 terminal_detail 必须同源，两者逐字 相等是 finalization 幂等校验的不变式。 非信封文本走的分支与改动前完全一致，做游戏链路（含 codex）不产出该信封，行为 不变。 回归用例覆盖源头与通道两端，并钉住「普通自由回复仍被截到 500 字符」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 09:55:56 +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	e45c6760b6	做方案无头入口不再把起 Run 的判定交给模型 ... GUI 的「做方案」是一个按钮：直接起 plan 根 Run，没有「直接回复还是调用持久能力」 这一步。而 swarm CLI 有个交互内核会让模型自己判定 reply / execute，无头入口原样 复用了它，于是同一句需求有时起 Run、有时只回一段口头建议——交付物落不了盘，还得 靠用户在措辞里补一句"产出 Fast GDD"把模型推向 execute。判定权不该交给措辞。 plan source 直接短路交互内核，与 GUI 按钮同构。做游戏与做素材继续走交互内核，用 例对这两种 source 断言的是"与原函数返回值相等"，等于把"不许顺手改这两条链路"也 锁进测试。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:37 +00:00
lhk229	7df033fcde	修复澄清回执通道容不下一次正常问询 ... 子 Agent 的澄清信封走的是 error 文本通道，两处把它当普通错误消息处理： 一是中转通道的字符上限写死 500，而它承载的问询 schema 允许 3 个问题、每题 400 字符、每题 2-3 个选项（label 60 + description 240）——单个 schema 合法的问题光内 容就有 1376 字符，通道连一个满格的合法问题都装不下。现场一问三选的正常中文问询 501 字符，正好被拒收。改成由 schema 自己的上限推导，推导常量放在 schema 所在的 user_input.rs；顺带把内联的 options.len() < 2 || > 3 换成具名常量，让推导有据。 二是父 run 认领回执时按错误消息截到 500 字符再补省略号。现场子 Agent 的真实输出 521 字符，截断后 501 字符，JSON 拦腰断在末尾，父 run 解析失败停在 needs-reconciliation。只放宽上限治不了这一处：载荷在到达解析器之前就已经被切了。 识别信封前缀时按信封通道上限放行，其余错误消息仍是 500。 两处都得对，少一处这条链路就断。上限是沿用 master 的（82957fe1d，2026-08-12）， 本分支没改过；做游戏链路的专业 Agent 很少提带选项的澄清，所以此前没暴露，而 M1 策划把"先问清楚再出 GDD"做成了必经步骤。 放宽上限不会让原本通过的载荷失败，逐字段复核仍在 parse_game_creator_agent_user_input_questions。新增三条用例：schema 允许的最大合法 问询必须能过通道、现场那条普通中文问询必须能过、同一条信封被截断后必然解析失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:12 +00:00
lhk229	7ca7e9704b	修复立项策划子 Run 持锁自锁导致的静默停摆 ... Provider 请求启动路径持有项目写锁时会追加 lifecycle "started"，其中策划专属分支 要重新校验冻结的 planning session；而那道校验走的是不持锁版本，会自己再去抢同一 把项目写锁。持锁上下文里必然抢不到，错误又被包成 RECONCILIATION 前缀，主循环见 到该前缀直接静默返回：不写失败态、不发事件、不置 error。结果是策划子 Run 永远停 在 running/planning，父 Run 等一个永远不会来的委派回执。 打点实测整段 prelude 只花 300 毫秒，卡点就在这一行，锁本身 1 毫秒就能拿到——不是 锁竞争，是同一路径自锁。只有做方案会中招：只有 planning 请求带 session binding， 做游戏与做素材进不了这条分支。codex 与 provider 两种模式表现一致，因为这段在模式 分发之前。 按仓内既有 `_at_locked` 惯例补上持锁变体，校验体抽成私有函数供两者共用；生产里唯 一持锁调用点改用新变体。既有用例都在 append 之前就 drop 了锁，持锁形态从来没有被 覆盖过，而且断言的是 error.contains("reconciliation")——真踩了自锁也会因错误恰好 带这个前缀而"通过"。新增用例先断言不持锁版本在持锁上下文里必然失败且带该前缀，把 bug 的形状写进测试，再断言持锁版本成功并真的落了 lifecycle 记录。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:48:41 +00:00
kdletters	4bf6c50a56	修复AGC开发者凭据目录权限初始化 ... 允许客户端自动收紧当前用户持有目录的继承 ACL 保留 foreign owner 与异常路径的失败关闭边界 补充 Windows 回归测试并同步实施决策文档	2026-08-20 14:11:59 +08: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	998b9e6c57	掐断结构化计划空转活锁 ... apply_agent_runtime_plan_update 把计划解释算进「有变化」判据里，模型每轮重写 一遍解释就返回「计划有进展」，Runtime 还发一个新 planRevision 替它背书。观察 detail 里那句「只有步骤或状态真实变化时才调用 update_agent_plan」是 prompt， 不是门禁，于是总控可以只改解释、不落地任何动作地无限循环，每轮烧一次 Provider 请求。现场实测四分钟走了八轮，planRevision 到 4 而步骤状态一格没动。 判据拆成三态：解释照旧落盘，但只改解释既不算进展也不再 bump planRevision， 事件改发 plan_update.explanation_only。计数落在持久 Runtime state 上（照 plan_submit_gdd_rejection_count 的先例），进程重启不能把一次活锁洗成新的无限 开销；只在「本轮没有任何动作、且未完成原因就是计划自己」这一支累加——等委派 回执、等 provider 批次、等用户问询走的是别的 blocker 类型，不会被误判成空转。 连续 2 轮把 update_agent_plan 从工具目录里摘掉逼模型自愈，只摘这一个工具，其 余工具面原样保留；连续 4 轮以 plan-update-idle-rounds-exhausted 收束。摘工具 的阈值严格小于收束限额，由单测守住，否则 run 会在从没被逼过一次真动作的情况 下直接失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 05:36:01 +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
lhk229	400595756b	修复普通 action 批次带 plan update 时预检自相矛盾 ... 批次预检对每个成员要求 provider_batch_plan_update 等于 batch.plan.plan_update， 而同一函数的另一条规则又要求非 planning 批次成员不得携带该字段；创建侧只为 plan.submit_gdd 填值，其余动作保持 None。于是「同一轮既调 update_agent_plan 又调工具」的普通批次同时踩中两条互斥规则，报「批次成员身份或顺序不匹配」。 该字段随 M1B-2 引入，master 无此标识符，做游戏路径同样中招。 预检期望值改为按批次类型分叉：planning v4 保持相等（:241 已对 actions[0] 校验过一次），非 planning 期望 None。创建侧与非 planning 分支语义本自洽，不动。 补一条走完 prepare 到读回的回归用例；去掉修复后可复现线上同一条错误串。 顺带 cargo fmt 掉上次 master 合并带进来的一处未格式化代码，并补一份第三方 Provider 兼容性缺陷说明。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 03:47:14 +00:00
lhk229	c2d5273873	重做 master 合并，找回上次合并丢失的分支工作 ... 上次合并 3d8abac33 把 24 个双边改动文件里的 7 个整份取了 master，另有数个 实质取了 master 版本，静默回滚了分支工作；其中 main_loop.rs 保留 master 的 调用点、provider_recovery.rs 保留分支的 cfg(test) 门，导致非测试构建编译失败。 本次从 ca6a3cd4c 对最新 master(341761ee3) 重做，逐个人工解析 38 处冲突： - 澄清等待态：保留分支的 lane 外 parent-wake 设计与锁守卫，套上 master 新增的 parent task 身份校验与 game-chat 安全默认返工；`_locked` 两种 false 语义在 delivery.rs 按 trusted_game_chat_autonomous_parent_chain_at 区分。 - decision-log：按日期把 master 三条插进分支条目之间，57 处 M1 记录全部保留。 - manifest.rs：采用 master 的 windows_sys 绑定，保留分支的目录/reparse point 拒绝。 - 做方案入口按 master 的提交重构改造：resolveProjectSupervisorRuntimeSubmission 新增 planningEntry，startMode 经 launcher context 传到 App；并把策划入口从 direct-codex 产品默认中摘出，做游戏与做素材保持 master 新默认。 - 首页两条入口用例按 master 已改的创建流程更新；非空目录确认用例因该流程 在首页入口不再可达而移除。 验证：cargo check --all-targets 通过；agc typecheck 通过；appSurface 395 passed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 13:15:16 +00:00
kdletters	341761ee3b	同步AGC单窗口原生门禁 ... 禁止普通启动自动打开开发窗口	2026-08-19 19:03:54 +08:00
lhk229	ca6a3cd4cd	修复M1策划链路可靠性 ... 阻止人工核对中的策划根写入审批回执 在投影恢复前校验项目身份并使用唯一项目ID 增加策划能力停用门禁与既有sidecar只读行为 拒绝非法plan与自主构建档位组合并收紧消费者 补齐前后端回归测试与M1技术决策记录	2026-08-19 09:13:43 +00:00
kdletters	4ba1859f10	修复AGC原生HTTP能力门禁 ... 同步登录服务器切换后的受控HTTP allowlist 记录Native门禁的现役能力边界	2026-08-19 16:56:16 +08:00
kdletters	925aefd934	修复AGC Native测试夹具 ... 固定普通 JSON Provider mock 为非流式 为平台账号画布与视觉门禁测试安装隔离会话 同步现役路由、默认配置与提示词断言	2026-08-19 14:42:41 +08:00
lhk229	c497a221fd	移除无关流程图脚本 ... 删除未被本分支使用的 draw-agent-loop-flow 脚本	2026-08-19 06:32:55 +00:00
lhk229	e0dc87b21c	修复M0A-2给做游戏路径引入的两处收束死路 ... design-foundation 在非 scheduler 路径上恢复 command.run_limited。内部产物验证只在 agent-ready-task-scheduler + Supervisor parent + gui/cli 根的可信 DAG 上发放，而 policy.rs 按 agent_id 单判就拒掉手动验证，委派路径两头落空、无从收束；master 的 白名单含该工具且自身用例断言不拦。判据只对 design-foundation 读绑定，其余三个固定 owner 的委派路径未经核实，维持现状不一并放宽。 game-chat 美术回执去掉本人 canvas.asset_generate 证据等三条必要条件。提示词要求 已有有效同路径资产时不得重复生成，而缺口判据只看非返工那一轮，合法的幂等复用会被 判成尚未交付。 测试恢复 master 断言并删去分支追加的钉桩段，未新增用例。policy 143、 design_foundation 6 全通过，cargo fmt --check 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 06:31:21 +00:00
lhk229	6d5afd9f6d	修正M1首页立项入口 ... 仅让首页做方案进入立项策划 恢复做游戏和做素材的直接构建路径 同步入口合同与回归测试	2026-08-19 05:27:53 +00:00
kdletters	9fe800da80	修复AGC Native测试认证与阻断 ... - 为画布与资源编辑 loopback fixture 增加 task-local External Editor 凭据 - 为平台账号语义测试安装隔离会话并修正资源编辑错误分类断言 - 为 Windows mock listener 增加有界 accept 与 blocking stream 恢复 - 同步 autonomous main-loop、completion fixture 与项目决策记录	2026-08-19 03:24:29 +08:00
kdletters	0fc69c620a	修复Gitea仓库门禁依赖安装 ... - Repository checks 在运行 AGC AppSurface 前安装子包依赖 - 补充工作流依赖准备契约测试	2026-08-18 22:35:36 +08:00
lhk229	7eee259cea	Merge branch 'feat/five_min_design' into codex/genarrative-isolated	2026-08-18 14:22:00 +00:00
lhk229	e3d318bf45	完成M1E提交拒绝有界收束 ... 为 Fast GDD 提交拒绝新增持久化次数上限与恢复收束。 将既有权威事实的超限和版本边界转入 reconciliation。 同步 M1E 技术方案与项目决策记录。	2026-08-18 14:20:23 +00:00
kdletters	b8dc3fe1b1	修复AGC登录网络错误与构建门禁 ... - 登录页归一网络错误并避免暴露底层 transport 文本 - 补充拒绝连接提示与错误信息脱敏回归测试 - master 推送门禁增加 AGC AppSurface 验证	2026-08-18 22:15:49 +08:00
kdletters	fe69a49a9c	修正AGC主分支门禁 ... - 修正直连 Codex 烟测脚本导入排序 - 修正播放请求回调依赖并稳定调用最新动作	2026-08-18 21:18:39 +08:00
kdletters	3cda3f3e33	合并AGC直连运行时可靠性修复 ... - 合并登录服务器切换与本地资源请求修复 - 合并已有游戏意图分流与同线程试玩链路 - 合并直连运行时素材验收与真实浏览器证据改进	2026-08-18 20:58:14 +08:00
kdletters	64310b3719	Merge remote-tracking branch 'origin/master' into codex/agc-runtime-generation-reliability	2026-08-18 20:54:01 +08:00
kdletters	f9ee0d5ac7	恢复直连已有游戏意图分流 ... - 已有游戏默认进入同一 Codex thread 编辑与试玩链路 - 仅明确新建或重做美术请求触发平台素材准备 - 补充已有游戏编辑与外部美术生成意图分流测试	2026-08-18 20:53:13 +08:00
lhk229	4687807dc1	在hydrate调用点写明投影修复先于身份校验的前提 ... 裁决为不修，并把改动前提与非重入锁陷阱留在代码旁 第 18.3 节要求身份校验（第 3 步）先于 session 前滚（第 5 步）与 index/pending 重建（第 6 步），而 hydrate 的实际顺序相反。本次裁决为不修，理由与前提写进注释： 现在没有后果，是因为那道比对恒过——App 的全部 init/import 调用点都传同一个常量 seedManifest.projectId（local-project-draft），本机每个项目的 manifest 写的都是它， projectId 分辨不出任意两个项目。该常量不属本工作包管辖。 触发后的后果也已复核为可忽略：命令仍正确返回 PLAN_PROJECT_ID_MISMATCH，前端拿不 到错数据；报错前写入的 pending/session/index 均为幂等或可重建投影，usage fold 有 按 fact 比对的幂等守卫，session.previous.json 是改名而非删除且只在 primary 缺失时 发生（即本来就该做的恢复）。 一旦 projectId 改成每项目唯一，这道校验才真正开始工作，届时顺序必须一起改，否则 hydrate 会先对一棵属于别的项目的 planning 树做完投影修复才发现认错人。注释里连同 陷阱一并写明：不能把 reconcile 直接挪到 hydrate 取锁之后——它自取项目锁，而 .agent/project.lock 是 create_new(true) 非重入的，调用方持锁再进去会死等满重试预算 然后失败；可行路径是锁外 projectId 预检，或把 reconcile 拆成薄壳 + _at_locked 由 hydrate 在自己的锁内调用（同型拆法见 observe_agent_runtime_agent_delegate）。 把提醒放在代码旁而不是只留在 decision-log，是因为真正会改 projectId 方案的人不在 本领域，不会来读这份文档。 cargo fmt --check、check:encoding 通过；纯注释与文档，无行为改动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:45:46 +00:00
lhk229	d44f930d1f	收口design组展示名，改为设计实现Agent ... 分组字典、manifest默认名与分组头像字一并改掉 个体Agent名兜底跟进，玩法策划Agent与内部id不动 跟改16处由label派生的断言 第 18.2 节要求 design 组用户名称改为「设计实现组」，与新阶段「立项策划」区分。 bf2185fba 只改了 taskGroupLabels 一本字典，另两本同概念字典没动，于是同一个 design 组在开发者面板/文本汇总里叫「设计实现组」、在工作台状态栏里叫 「策划 Agent」——这个语义不一致是该提交引进来的。 先更正一条此前的判断：曾把这条的严重度建立在「新项目默认主路径上『立项策划』 与『策划 Agent』同屏共存」上。该说法未经验证且不成立——用 appSurface harness 实测策划路径，子 Agent 状态栏根本不渲染，策划 Agent 出现 0 次。结构上二者确在 launcherView === 'project-development' 分支的同一棵树里，但未能把用例驱动到该 分支，故不作为事实主张。若真会撞，也是批准后进入完整制作那一段，比原描述窄 得多。改这条的理由与撞不撞名无关，只是第 18.2 节的要求 + 上述不一致。 口径取最小方案：保持兄弟项的「X Agent」体系，design 取「设计实现 Agent」。 不把 taskGroupLabels 直接塞进 groupConfigs——两本字典命名体系不同（「X组」对 「X Agent」，且音乐组/音频 Agent、运营组/发布 Agent 连词都不一样），直接替换 会连带改掉另外五个分组名；消灭重复字典属视觉改版，单独立项。 改动：agentPresentation.ts 的 groupConfigs、view/project-development/index.tsx 的 summarizeAgent 默认名与同文件分组头像字（策→设）、model.ts 中 agentId.includes('design') 的个体名兜底（design-director 走这里）。 design-foundation 的「玩法策划 Agent」单列在前，不变；内部 agent id 与 design 分组键均未动。 测试量原估「3 处断言」严重低估，实跑发现 project-development.suite.ts 有 16 处 派生断言需跟改——「X 文本回执」由 App.tsx 的 `${candidate.label} 文本回执` 拼出、 「历史成果 · X」由 resourceProjectionModel.ts 拼出、dock 的 article accessible name 亦然。替换用后行否定守住「玩法策划 Agent」（它含「策划 Agent」子串）， 替换前后该串恒为 6 处。agentRuntimeModel.test.ts 与 projectResourceProjectionModel.test.ts 里剩余 4 处是测试自造的输入 fixture、 不由字典派生，保持不动。 验证：appSurface.test.ts 383 passed / 0 failed；agentRuntimeModel、 agentTraceSummary、projectResourceProjectionModel、projectResourceLiveUpdateModel 合计 39 passed；agc:typecheck、ESLint --max-warnings 0、check:encoding、 git diff --check 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:20:01 +00:00
lhk229	7ca82ba7aa	修复M1D审查发现的锁错误脱敏与澄清轮次口径 ... 审批卡链路的三处项目锁错误改为脱敏后再进typed错误 阶段进度按等待状态显示真实轮次，不再透传0-indexed值 去掉reconcile错误的重复code拼接 补一条Rust脱敏回归与两条前端轮次回归 锁错误脱敏（方案 §18.3「返回值不包含绝对路径……或内部诊断」）： acquire_project_write_lock 的 Err 内嵌 .agent/project.lock 真实绝对路径。补 redact_agent_runtime_project_paths 的三处是前端审批卡真正会显示的那条链—— reconcile_plan_gdd_approval_projections_at（hydrate 在取自己的锁之前调它）、 hydrate 自己的锁、decide_plan_gdd_at（其错误与 hydrate 的错误渲染在同一个 错误区）。planning 另有 14 个取锁点沿用未脱敏写法，属 M1B/M1C 既有模式， 本次不扩面。脱敏不破坏「项目正在被其他写操作占用：」前缀，project_gates.rs 与 provider_recovery.rs 两处按前缀分类的判据不受影响。 澄清轮次口径：clarificationRound 与 awaitingAnswerFor.round 都由 static_delegate_lineage_counters 派生，该函数排除目标自身，是 0-indexed 的 「已答轮数」；后端判上限用的是 current_round + 1。原样渲染成「轮次 X/3」 整体差一格——问最后一轮时显示「轮次 2/3」，字面暗示还剩一轮。只改前端 文案、不动 DTO 语义：等待回答时显示「第 N+1 轮 / 共 3 轮」（此时 latestDelegationId 就是当前 delivery，+1 恰好等于后端校验用的轮次）， 其余状态退回「已完成 N/3 轮澄清」，不猜当前轮。 顺带：planning_hydrate.rs 里 reconcile 的错误原本用同一 code 把 to_string() 当 detail 重包一层，而 PlanningStorageError 的 Display 已是「{code}: {detail}」， 渲染出 CODE: CODE: detail；code 与 detail 均无变化，改为直接 ? 传播，并把 「不重复拼 code」钉进回归。 测试陷阱：写「占住项目锁」的 fixture 必须给锁 JSON 填真实 createdAt。失效锁 回收的年龄判定读的是该 JSON 字段而不是文件 mtime，填 0 会让锁显得约 1.7e9 秒 老、越过 600 秒阈值被当场回收删除，hydrate 反而成功。第一版 fixture 正是这样 自证失败的，注释已写明。 验证：Rust planning_ 组 155 passed / 0 failed（原 154 + 本次 1 条）； appSurface.test.ts 383 passed / 0 failed（378 原有 + 5 条新增）；三条新回归均经 变异验证，逆转对应修复即变红。cargo fmt --check、agc:typecheck、ESLint --max-warnings 0、check:encoding、git diff --check 通过。 撤回一条此前的审查发现：曾判定 hydrate 读 manifest 缺符号链接判定。复核后不 成立——read_manifest 自身在 is_symlink 处即拒，防护在另一层；.agent 目录本身 为符号链接的残差也无窗口，紧随其后的 resolve_planning_path 同样逐段判定。 未据此改动代码。 新记一条既有问题（非 M1D 引入）：seedManifest.projectId 是常量 local-project-draft，App 的 5 个 init/import 调用点全传它，因此本机所有项目 projectId 相同。§18.3 第 1 步依赖的 projectId 校验因此分辨不出任意两个项目， 该门当前近乎恒真，须单独立项。 仍未修：hydrate 身份校验排在落盘投影修复之后（修它须注意 reconcile 自取项目 锁、.agent/project.lock 不可重入，不能把检查直接挪到 hydrate 取锁之后）； design 组展示名剩两处硬编码，且与 taskGroupLabels 命名体系不同，需先定口径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:50:43 +00:00
lhk229	abcc393fde	修复M1D审查发现的审批决定失败路径 ... 决定失败也重灌权威状态，顺序钉死为先hydrate后写错误 responseId复用键纳入comment，改写修改意见时换新ID 恢复期门控扩到已打开的评论弹层，保留已输入内容 补appSurface harness的策划command分发与三条变异验证过的回归 审查基线为 14c00017c..bf2185fba（技术方案第 13、18 节）。其后分支已前进到 c6a08ef98，4624fd795 与 c6a08ef98 都不动 src/**，审查结论不受影响。 三条缺陷： 1. decidePlanGdd 只在成功分支 hydrate。后端 decide_plan_gdd_at 有多条真实 PLAN_STALE_APPROVAL 分支（GDD 不在当前 lineage、identity 不符、版本被取代、 pending 丢失），命中后卡片停在已失效的 pending 身份上、三个决定按钮仍可点， 且 recoveryPending 永不翻真导致「重试恢复」入口不渲染，卡内没有恢复路径。 现按第 18.3 节在失败分支同样 hydrate——该句不区分成功与失败。两句顺序不能反： hydratePlanGddState 入口会 setPlanGddError(null)，先写错误再 hydrate 会把错误 擦掉；回归钉死了这个顺序。 2. responseId 复用键为 approvalRequestId:action，不含 comment，违反第 13.2 节 「改变 action/comment 必须生成新 responseId」。在第 14 节承认的「receipt 已提交 但 response 丢失」构造下，改写修改意见后重提会带旧 ID，命中后端「同 responseId 的审批意图不一致」硬拒，改写后的原因永远落不了盘。现按 approvalRequestId 存 {action, comment, responseId} 全量意图。判据方向为宁可多换不可少换：多换的最坏 后果是 replayed 降级成 already-decided（都是 Ok，且 already-decided 正是第 18.2 节要求的刷新态），少换是硬错误。 3. 第 18.2 节「recoveryPending 时不允许提交决定」原来只作用于三个触发按钮，而弹层 是打开之后才可能被后台 hydrate 翻掉资格的，其提交按钮只看 busy 与非空。现在 submitComment 与该按钮都判 canDecide。刻意不自动关弹层，否则会丢掉用户已经写好 的修改意见。 测试：harness 新增 hydrate_game_creator_plan_gdd_state 与 decide_game_creator_plan_gdd 分发分支及 createPlanGddStateView fixture；未配置策划 状态时 hydrate 与接入前一样抛出，既有 378 条行为不变。新增 plan-gdd.suite.ts 三条 回归并逐条变异验证——逆转对应修复后三条各自以自己的断言变红；修复二的变异是部分 逆转（保留新 Map 结构、只删 comment 比对），因此钉住的是 comment 这一维本身。 验证：appSurface.test.ts 381 passed / 0 failed；agentTraceSummary 与 rememberCommand （另两个 import src/App 的用例文件）13 passed；agc:typecheck 通过；6 个改动文件 ESLint --max-warnings 0 通过；check:encoding 5409 文件通过；git diff --check 干净。 不改 Rust——三条全在前端，后端语义已经正确。 文档：更正第 23.8 节 M1D-1 行误引的合入提交（5b11a0530 是 ESLint 修正，落地是 0052a80da），并补 M1D 审查修复快照。同时更正既有记录里「Shell typecheck / appSurface 受仓库依赖缺失阻断」的说法——在原分支主工作树上两道门都干净，实际是 bf2185fba 改名 taskGroupLabels.design 后自己把 8 个用例文件断言改红，由 c6a08ef98 补修。 未并入的四条审查发现：hydrate 身份校验排在落盘投影修复之后（第 18.3 节固定顺序， session.previous.json 提升+删除不可逆）；锁竞争错误回传项目绝对路径（第 18.3 节）； design 组展示名剩两处字典未改（第 18.2 节）；阶段进度轮次差一格。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:11:18 +00:00
kdletters	9070c0760b	修复登录服务器切换与本地资源请求 ... - 允许 release 客户端安全访问 custom HTTPS 与本机 loopback HTTP - 修复 Tauri WebView 请求传输与无效 URLPattern - 按服务器 origin 隔离本机 External Editor 凭据 - 保留登录请求底层错误并补充路由与凭据隔离测试	2026-08-18 18:32:49 +08:00
lhk229	c6a08ef98f	修复M1D前端文案回归断言 ... 同步立项入口与设计实现组展示文案的测试期望 恢复Frontend tests与Native shell tests中的前端测试覆盖	2026-08-18 09:35:28 +00:00
lhk229	4624fd7953	同步M1D合入状态记录 ... 更新M1D-1与M1D-2的合入提交和自审结论 保留M1E端到端与故障注入后续范围	2026-08-18 09:21:58 +00:00
lhk229	bf2185fba0	完成M1D-2入口分流与阶段进度 ... 游戏新项目默认进入立项策划并保留直接开建路径 项目总控页面挂载GDD审批卡与阶段进度 同步策划展示名称、定向测试与开发日志	2026-08-18 09:11:38 +00:00
lhk229	9bad7121b5	修复 Native shell tests 既存红：委派用例改调 _at_locked ... CI task 3784 的 Native shell tests 报 2121 passed / 3 failed，三条同因： agent.delegate -> failed, "无法取得一致项目快照" 项目正在被其他写操作占用：$PROJECT_ROOT/.agent/project.lock - autonomous_direct_child_collaboration_mutations_require_the_current_root - autonomous_delegate_descendant_inherits_and_enforces_the_current_root_guard - standard_delegate_collaboration_mutations_remain_compatible 根因是又一次「把动作挪到调用链更前面，改变的不是严格度而是作用范围」。 bc1fe7d8f 写这几个用例时，观察点是「测试先持项目写锁、再调 observe_agent_runtime_agent_delegate」，当时无害：老薄壳压根不碰项目锁，它调的 start_..._with_link_at 只对 planning 身份取锁，其余身份走 ..._with_project_lock_at(..., None)。 152cc40c7（完成 M1C-2b 策划澄清与预算接线）为了让 planning 子 session 的投影按 project -> session 取锁，把锁的所有权上提，拆出 observe_agent_runtime_agent_delegate_at_locked，并让同名薄壳在入口无条件取项目写锁。 而 .agent/project.lock 是 create_new(true) 的文件锁、不可重入：调用方已持锁再进薄壳 就死等满 2000x5ms 预算再失败。确定性红，不是抖动——本机复现逐字一致。 这不是生产漏洞。生产侧调 agent.delegate 的只有 action_execution.rs:436 和 pending_recovery.rs:162，两处都持锁后调 _at_locked；取锁的薄壳如今零生产调用方， 只剩测试在用（main_loop_tests、autonomous_completion_contract_tests 那些都不持锁， 所以一直是绿的）。所以改测试面，生产代码零行改动。 - delegation.rs 四处（2515/2584/2678/2740）改调 _at_locked 并传入已持有的 &project_lock。这不是迁就实现：_at_locked 才是生产唯一的调用形状，改完这三个用例 覆盖的是真实路径。首处留注释说明为何必须绕开同名薄壳——否则下次「顺手统一」回去 会复发，而症状是 10s 静默卡顿，很难往锁不可重入上想 - runtime_tools.rs 补一条 #[cfg(test)] pub(crate) 再导出。生产侧靠 pub(in crate::agent) 的 glob 即可见，测试模块在 crate::agent 之外需单独放行； 沿用旁边 #[cfg(test)] pub(crate) use delivery::{...} 的既有写法，不动生产可见面 验证：tests::collaboration::delegation 改前 22 passed / 3 failed（18.68s），改后 25 passed / 0 failed（5.54s）。少掉的 13 秒正是三条各自空等 10s 锁预算的量——那三次 等待没再发生，不是断言被放宽。cargo fmt --check 干净。 另记一条前提更正：AGC shell crate 是有 CI 的。project-ci.yml 的 native-shell-tests job 跑 npm run check:native-shells，本次覆盖 2124 条。此前「这个 crate 在 CI 里从不 编译也不测试」的判断是错的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:35:27 +00:00