2958 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
lhk229	5b11a05303	修复 M1D-1 带进的 eslint 红：import 排序与 hook 依赖判据 ... CI task 3777 的 Repository checks 停在 lint:eslint，前面的 encoding / git-hooks / rustfmt / spacetime schema / production-ops / preview-deployer / maintenance-page 全绿。三条问题全在 0052a80da 自己动的两个前端文件里。 - simple-import-sort：新加的 PlanGddDecisionAction / PlanGddStateViewV1 插在了 PendingCommand 前面（ASCII 序 Pending < PlanGdd），ProjectWorkspaceChatPane 里 GddApprovalCard 也落在同目录组末尾。autofix 修正 - react-hooks/exhaustive-deps 是 warning，但 lint 脚本带 --max-warnings 0，一样退 1。 这条不能靠补依赖解决：该 effect 的依赖只挖 phase/status/updatedAt 三个标量，正是 为了避开轮询每轮新建对象的身份变化；把 projectSupervisorRuntime 本体写进依赖会让 每个 tick 都触发一次 hydrate。改的是判据侧——存在性从整个对象换成必选字段 status（AgentRuntimeState.status: string 必选，为 undefined 当且仅当 runtime 为 null），语义等价且不再引用裸对象 本地 npm run lint:eslint（全仓，--max-warnings 0）、npm run typecheck、 npm run check:encoding 均通过。typecheck 是 CI 未走到的下一步。 另记一笔：.husky/pre-commit -> lint-staged -> scripts/lint-staged-eslint.mjs 会拦这 两类（自动修 import，且 errorCount 或 warningCount 非零即置退出码），本 worktree 的 core.hooksPath 也确实指向 .husky/_。这三条能进库说明 0052a80da 绕过了钩子。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:08:57 +00:00
lhk229	0052a80dad	完成M1D-1策划状态与审批卡 ... 新增严格输入的策划状态 hydrate command 与 plan-gdd-state-view.v1 read model 接入 GDD 审批卡、正文详情弹层、决定幂等与恢复重试 补充 M1D-1 开发日志和技术方案状态	2026-08-18 07:56:20 +00:00
lhk229	14c00017c6	同步M1C-2c合并状态 ... 更新项目决策日志中的合并提交信息 同步技术方案的M1C-2c完成状态	2026-08-18 06:20:49 +00:00
lhk229	c85452795d	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-18 06:16:47 +00:00
lhk229	0abdc41c3c	M1C-2c 收口：分隔符集合补全角冒号，并钉住 label 与回答的同尺比对 ... 分隔符集合原本只有 `·`/`:`/`-`。prompt 全中文、实测用的是 DeepSeek 系模型，在中文 语境下写 `A：方案名` 是高频输出；漏掉全角冒号的后果不是判错，而是合法信封被判形状 错误、回灌重试，白吃一个未推进回合预算——而第 23.9 节自己就记着无界重试把单次 prompt 撑到 15 万 token 的实测。 - PLAN_OPTION_LABEL_DELIMITERS 补 `：`；prompt 的 label 说明与技术方案 §5.1、§5.2、 §23.9 三处分隔符合同同步改口，避免两侧各写一份 - 回归 planning_clarification_accepts_fullwidth_colon_option_labels。变异验证： 去掉 `：` 后该用例立刻红 另外收回一条误报。此前判断「答案走 normalize_plan_text 被 trim、label 是信封原文没 trim，模型吐带尾随空白的 label 会让用户点选 A/B 掉进自由填写分支、台账记成 user_freeform」。写完测试做变异验证时把改动回退，用例照样绿；查下去发现 user_input.rs 的 normalize_single_line_user_input_text 在信封严格解析时就已经 trim 过 label（并拒掉含换行的 label）。两边本来就是同一把尺子，不对称不存在。 - 生产侧只把比较抽成具名函数并在原地写清它依赖的是解析侧那条 trim，不做多余的重复 规范化——那会把一个不存在的风险写进代码 - 保留 planning_clarification_option_pick_survives_untrimmed_label，它钉的是上游那条 不变量：解析侧哪天不 trim 了，这条会红 - 测试脚手架加 *_with_labels 变体，让用例能注入自定义 label；原有 helper 转为薄包装 planning_clarification_ 16/0、plan_ 160/0、recovery 107/0，fmt 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:15:25 +00:00
lhk229	6234b420fc	修复 HEAD 既存红：策划恢复门用例改建可达状态 ... planning_recovery_contains_session_identity_conflict_before_provider 自 M1C-2b （152cc40c7）写下起一天都没绿过：它伪造一个 source=agent-background-task、且没有 Run Profile 绑定的策划任务，而 agent_runtime_tool_policy_snapshot_for_run_at 早在 M1A-2（09c7d7af8，152cc40c7 的祖先，已核对该门在 152cc40c7 当时就一模一样）就按 agent 身份挡死了这种 run。被告造不出来，庭开不了。当时的定向门禁过滤器 planning_clarification_* 恰好匹配不到它的名字，加上本 crate 不在 CI 里编译，两层 网都没接住。 那道创建门不能放宽：放宽后伪造的策划 run 就能拿到默认宽工具面，正是 M1A-2 关掉的 洞。所以改测试而不是改生产代码。 也不删：该用例第四条断言「身份门必须早于任何 Provider lifecycle」是全 crate 唯一 一处该不变量的否定断言（AGENT_RUNTIME_PROVIDER_REQUEST_LIFECYCLE_RECORD_TYPE 共 22 处引用，否定断言仅此一处），且 plan_session_recovery_gate_tests 模块只有这一条 用例，删掉等于整个门失去覆盖。 先试了更贴现实的「事后删父绑定」，实测走不到本门：entrypoints 的 tool policy 收容 （currentAction=Run Profile 工具策略需要人工核对）先把 run 打成 failed， read_recoverable_... 随即不再认它，审计里只有 agent.runtime.turn。也就是说绑定层的 破坏到不了 session 门；能到这里的只有「绑定完好、task record 自身不满足 D11 契约」 这一类持久不一致——这正是本门存在的理由。 - 改成：supervisor plan 根与 planning child 绑定都合法（创建门放行），但裸 start 不带 task link，task record 上没有 parentAgentId/delegationId - 四条断言原样保留：resume 必须 Ok（收容不外溢）、该 run failed/needs-reconciliation 且 error 含 PLAN_SOURCE_PROFILE_MISMATCH、审计有 plan.session_recovery. needs_reconciliation、且没有任何 Provider lifecycle 记录 - 断言失败信息带上实际审计记录类型与 currentAction，下次判因不用再加探针 - 变异验证：把 exact_plan_child_identity_at 的策划识别翻成直接 Ok(None)，用例报出 "PLAN_NEEDS_RECONCILIATION: project-planning 恢复任务未命中 planning session 协调器" ——证明它确实在考这道门，而不是碰巧绿 - recovery 107/0、planning_ 151/0、session 88/0、plan_ 160/0、approval 11/0 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:02:33 +00:00
lhk229	73816bd512	修复 HEAD 既存红：planning session 恢复块给双锚缺失诊断让路 ... committed_plan_submit_without_either_anchor_is_publicly_recoverable_and_fails_closed 在 HEAD 上确定性失败（Windows 与 WSL 干净基线一致，与本轮审查修复无关）： phase 确实是 needs-reconciliation，但 error 不是「恢复锚点同时缺失」。 M1C-2b 把 planning session 恢复块插进了同一个循环，位置在 reconcile_missing_plan_submit_anchors_at 之前。该 fixture 用裸 start_game_creator_agent_runtime_task_at 建策划任务，task record 上没有 parentAgentId/delegationId，于是 exact_plan_child_identity_at 判定身份不符、 返回类型化 Err，session 块随即落 needs-reconciliation 并 continue，更具体的双锚 缺失诊断永远轮不到跑。两条都写 needs-reconciliation，谁先写谁赢，而先写的恰恰是 信息量更少的那条。 不是判错，是插在前面的门改变了哪条诊断胜出——与 M1C-1 那五条 CI 失败、与 P4 同一形状。 - session 恢复块加让路条件：该 run 是双锚缺失候选时跳过。本块只服务「将要继续」的 continuation，而双锚缺失的 run 根本不会继续，修投影没有意义 - 选让路而不是调换两块顺序：调换会让锚点探测对所有 Agent 提前，正是「前移改作用域」 那个坑本身。探测器只对 project-planning + agent-delegate + standard 返回 Some， 且对已按双锚缺失收敛过的状态返回 None，因此这道让路既窄又幂等 - recovery 族 105 passed/2 failed -> 106 passed/1 failed，planning_ 150/1、 session 87/1；剩下的唯一红是 planning_recovery_contains_session_identity_conflict _before_provider（另一条既存红，下一个提交处理） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:02:05 +00:00
kdletters	1e9d74fa4a	增加登录服务器选择 ... - 登录页支持 release、dev 和 custom 服务器 - 持久化服务器选择并统一登录与平台会话请求地址 - 校验自定义服务器 origin 与 HTTPS 安全边界 - 补充前端、AppSurface 和 Rust 平台会话测试	2026-08-18 13:46:03 +08:00
lhk229	c1a70cb37d	审查发现2：验收前置门先识别 Fast GDD 再走绑定父链 ... ensure_plan_gdd_approval_pending_after_acceptance_locked 先用会遍历并校验整条 祖先链的 read_..._run_profile_binding 读绑定，再检查 binding.source 是否为 project-supervisor-plan。顺序反了：任何祖先绑定的毛病都抢先变成 Err，连「这根本 不是策划根」都来不及说，于是别人的坏链变成了这道门的失败。 这正是 P4（cb5af31e7）在同文件 plan_root_completion_identity_at 修过的形状，当时 漏了这个姊妹函数。而它比完成门更容易被踩到：agent.run_status 每次 status observation 都会重跑本门（见 runtime_tools/run_status.rs 的 「Re-run the locked gate on every plan-root status observation」），那条路径上没有 任何上游守卫先把带父链的 run 挡掉，适用性完全交给门自己判。 - 识别改用 _once，只看 run 自己那条绑定记录；确认是策划根之后才走完整父链， 严格度一点没降，只是不再作用到别人身上 - 回归 broken_ancestor_binding_must_not_fail_the_acceptance_gate_for_a_non_plan_supervisor_run： 复用 P4 的构造（supervisor 的 isolated-join 子 run，删掉父绑定），断言门只能判 NotApplicable。变异验证：换回链走优先后该用例报出 Err("Agent Runtime Run Profile 父绑定缺失") Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 05:33:52 +00:00