修复链路上存在的若干阻塞性漏洞 #199

Merged

kdletters merged 22 commits from opt/design_agent into master 2026-08-28 17:09:03 +08:00

Conversation 6 Commits 22 Files Changed 50

+5118 -1658

22 Commits

Author	SHA1	Message	Date
lhk229	daf86c9c26	Merge remote-tracking branch 'origin/master' into opt/design_agent	2026-08-28 07:48:15 +00:00
lhk229	52894d2e8a	收紧策划 continuation 游标防止旧 delivery 越权 ... 新增 planning session latestDelegationId 直接后继校验，阻止旧 delivery 另起分支 保留用户修订周期内质量返工的 user_revision 语义并更新提交门注释 补充 continuation 边界回归与 Fast GDD 技术决策文档	2026-08-28 07:46:32 +00:00
lhk229	fa3b60777c	修复生产运维门禁格式误报 ... 生产运维门禁对备份安全片段启用空白与尾逗号容错匹配 补充开发运维文档中的门禁匹配规则说明	2026-08-28 04:11:15 +00:00
lhk229	f4819e9a42	修复审批回执重放的会话归属 ... 按原 Supervisor task 会话恢复审批修改意见 允许归档会话中已有幂等消息安全重放 同步审批恢复的长期决策记录	2026-08-28 03:47:31 +00:00
lhk229	f4776637c6	合并最新master到设计代理分支 ... 同步 master 的退款 outbox、认证投影与外部生成历史清理改动 保留 GDD 审批修复及双方决策记录	2026-08-28 03:00:51 +00:00
lhk229	1bbecfd87b	修复GDD审批同步期间提交竞态 ... 审批按钮在 hydrate 期间统一禁用 修改和退回弹窗提交复用同一忙碌状态门禁 提交处理函数同步阻止过期 pending 决定	2026-08-28 02:30:03 +00:00
lhk229	168a86c73f	修复持锁 Provider 构建的二次取项目锁 ... Provider tool-plan 持锁路径改用 locked 阶段判定入口 保留未持锁调用方的单次加锁包装入口 修复澄清回答恢复 continuation 因非重入项目锁卡死	2026-08-27 14:01:21 +00:00
lhk229	bca595a554	拒绝无审批决定的 user_revision 提交 ... plan.submit_gdd 新版本仅在 session 已有 revise/reject lastDecisionRef 时接受 user_revision 首次 collecting 伪造 user_revision 改为拒绝且不落 GDD 同步 Fast GDD 技术方案与 decision-log	2026-08-27 13:41:57 +00:00
lhk229	8779018653	合并最新master并保留GDD审批修复 ... 合入 origin/master 的 SpacetimeDB 2.8.3 与 Runtime 更新 保留 GDD 审批忙碌状态拆分和同步提示修复 解决策划 Prompt 与排障记忆的合并冲突	2026-08-27 12:30:32 +00:00
lhk229	f35c86d996	调整GDD审批投影同步提示 ... 将恢复文案改为中性的审批状态同步提示 保留同步期间的重复提交阻止与重试入口 同步更新现有界面断言与代码注释	2026-08-27 12:01:29 +00:00
lhk229	b70cc79f80	拆分GDD审批与状态同步忙碌状态 ... 审批决定按钮仅反映用户决定提交状态 恢复按钮仅反映策划状态同步状态 贯通总控视图与工作台的独立状态参数	2026-08-27 11:51:51 +00:00
lhk229	c5a0705eff	收窄 Provider handoff 绝对路径校验边界 ... 按已知工具参数语义检查可执行路径字段 允许 plan.submit_gdd 的 GDD 与决定内容包含普通斜杠文本 移除未知字段绝对路径的过宽旧测试断言 补充路径校验边界排障记忆	2026-08-27 11:17:31 +00:00
lhk229	a69e0bc68f	增加 Provider 交接失败本地诊断 ... 成功 handoff 失败时保存应用私有 Provider 响应诊断 在项目状态和 Agent DB 中记录本地诊断相对引用 补充 Runtime 技术方案与排障记录 增加私有诊断落盘和引用校验测试	2026-08-27 10:32:50 +00:00
lhk229	b767a6bc82	修复立项策划审批修订提交链路 ... 新增 user_revision 来源并允许审批修订更新当前 GDD 决定快照 移除 planning submit 对历史 session 决定内容的逐项门禁与自动覆盖 修复历史审批回执污染当前 approval pending 恢复投影 更新策划 Prompt、技术方案、原型说明和必要回归测试	2026-08-27 09:22:27 +00:00
lhk229	41228b0cda	修复 GDD 修订后的审批取证链路 ... 新增 plan Supervisor 的 AwaitingAcceptanceEvidence 阶段与无副作用 durable 状态判定 在证据不足时收窄工具面，阻止重复 agent.delegate 并保留 file.read、acceptance_update、run_status 补充一条阶段工具面回归及项目排障记录	2026-08-26 13:18:12 +00:00
lhk229	0e84ea1ed9	补齐策划会话投影失败任务的 phase 白名单 ... 统一 planning-session-projection-failed 的写入与读取常量 补充稀有持久化 phase 的 Runtime task journal 回归测试	2026-08-26 11:36:23 +00:00
lhk229	15c0d6f028	修通澄清信封被收束门禁拦死的活锁，并给最终回复重试加兜底 ... 策划子 Agent 每轮都在正确地吐 AGC_NEEDS_USER_INPUT_V1 信封（header 带主题、 三选项齐全），却被拒了 26 次，一条生产 run 空转 65 轮直到人工介入。 信封是通过 respond_to_user 交付的，走最终回复通道，于是撞上两道「计划必须全部 完成」的判据： - runtime_state.rs 收束链首位的 structured_plan_completion_blocker - runtime_protocol/finalization.rs 上「finalization 必须绑定已全部完成的计划 快照」这条 journal 持久不变量（第二道，是上面那条测试逼出来的） 而计划里「按用户决定收敛并提交」那一步在用户答之前永远不可能 completed：想问 用户就得先 respond_to_user，问不出去就答不了。对任何含「答完之后再做 X」步骤的 计划，这条判据都不可满足。 以前没炸靠两件偶然：策划子 Agent 不提交结构化计划（判据第一行就跳过），或者 提交了之后肯把没做的步骤标成 completed。翻了同机全部历史 run：4 条没提交计划、 2 条首版 3/4 改成 4/4 放行、这条首版 1/4 之后再没改过——就死了。 修法是判据豁免而不是代填步骤状态：澄清信封是本 run 挂起等用户答，剩余步骤归 用户答复后的 continuation run，把它们标成 completed 是伪造进度。豁免只放行 「计划未完成」这一件事，快照自身的结构合法性仍然逐项校验，其余 blocker 照常。 第二件：最终回复被拦下后 run 原地续跑重试，此前没有任何上限。空转闸只认裸 update_agent_plan，而这里模型每轮都在认真调 respond_to_user，没有任何计数器会 累加。新增 stale_finalization_rounds（持久 Runtime state，与 plan_submit_gdd_rejection_count / plan_update_idle_rounds 同一模式，重启不能把 活锁洗成新的无限 Provider 开销），上限 32——刻意留在两道软闸之上，让自愈路径 先有机会起作用。真实推进后清零。 守门两条： - 同一份未完成计划，普通交付收束必须被拦（blocker.tool=runtime.plan_update）、 澄清信封必须放行。两半都实测非空转：撤掉任一处豁免，对应那半立刻红。 - 兜底额度必须高于两道软闸，防止有人把它调到软闸以下抢跑自愈。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 10:08:44 +00:00
lhk229	92e571e1dc	无头链路能跑审批的修改/退回，不再只能投 approve ... `agent-swarm-test-chat.mjs --plan` 的自动审批把动作写死成 approve，原注释让人 「要跑那两条分支就手工调 --plan-gdd-decide」。但那条路走不通：decide 要求 plan 根 run 仍是当前唯一 active 的，而它恰好是本进程持有的 CLI 子进程——CLI 一死， 再 decide 就是 PLAN_STALE_APPROVAL，实测过。于是 revise/reject 在无头侧没有任何 入口，e43133875 / 9e2648893 / b27ffce9b 三条修复都只能靠单测。 加 AGC_PLAN_GDD_DECISION + AGC_PLAN_GDD_COMMENT 两个环境变量，默认仍是 approve， 既有调用行为一字不变。原注释那条约束保留并落成断言：非 approve 时缺意见直接抛， 不给机器编一段的机会——意见必须由跑的人自己给。`runCapturedCargo` 顺带支持 stdin， 决定报告从写死的「已批准」改成打印实际动作。 用它跑通了一条完整真链路（两轮澄清 → 出稿 → 修改 → 返工 → v2）： - session successor 与 gdd.v2.json 同一秒落盘，phase=awaiting_gdd_approval、 latestSubmittedRef=v2、activeRunId 已清空，不再 PLAN_SESSION_RECOVERY_REQUIRED - 意见原文进了 Supervisor 会话，也进了返工委派正文 - 标题「脉冲避航：微型核心危局」→「エネルギー・ランナー」，意见是「改成日文」 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 09:04:30 +00:00
lhk229	b27ffce9b4	把审批卡的修改/退回意见原文送进 Supervisor 会话 ... 用户在审批卡上写的意见此前只落到 `.agent/planning/approvals/v{n}.json` 就断了。 Supervisor 唯一的信息源是 `agent.run_status` 返回的 claimedDelegateContract， 那里面只有 contractStatus=user-revision-requested，没有承载原文的字段。于是它 按 playbook 第 6 条「把用户原话完整附在 task 里」写了句占位「请按审批卡上用户 提交的修改意见…」，子 Agent 收到的是空指令，只能自由发挥——实测用户写「把游戏 名称改成日本语」，产出的 v2 把标题从《裂隙脉冲》改成《裂潮航印》，仍是中文。 通道本来就有：决策卡的答案早就是这么送的——`append_user_input_answer_message` 把用户选择渲成一句 role=user 消息追加到 Supervisor 会话，下一轮 prompt 由 `prompt_history_sources` 现读现取。审批决定接上同一条通道即可。 因此不动 delivery schema，也不动 playbook： - schema 加字段要连带改 validator、run_status 投影，还得让 e43133875 的 `static_delegate_structured_result_follows_claim_snapshot` 跟着 rebase 新字段， 否则 claim 重放冲突原样复发——多一处必须手工同步的地方。 - playbook 第 6 条的规则本来就在，缺的是原文本身，不是规则。 落点用 Supervisor 的**当前活动会话**（sessionId 传 None），不用 delivery 上的 parentSessionId——那是委派发出时的快照，不保证仍是可写的活动会话。 messageId 用 responseId 派生：`project_receipt_locked` 会被 `reconcile_plan_gdd_approval_projections_locked` 在每次 hydrate 重跑，不幂等就 每刷新一次多一条。 守门一条，两个断言都验过非空转：去掉追加，第一条断言红；换成非幂等 append， 重放后消息数 2 vs 1，第二条断言红。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 08:42:42 +00:00
lhk229	9e2648893b	修通修订轮出稿：投影守卫不再假设「一条 lineage 只提交一次」 ... 审批卡点「修改/退回」后，策划子 Agent 能提交 v2、GDD 也落盘了，但 `project_submit_successors_locked` 拒绝写 session successor，返回 recoveryPending=true。Runtime 把这次工具动作标成 needs-reconciliation， hydrate 再看到「未审批的 v2 vs session 还指着 v1」，抛 PLAN_SESSION_RECOVERY_REQUIRED。UI 上「重试恢复」走的是同一个投影守卫， 永远清不掉；「结束旧任务」不重写 session，同样清不掉——项目就此砖掉。 根因是 source_session_matches_gdd 里的 latest_submitted_ref.is_none()。 它不是安全判据：相邻的 sessionRevision + sessionFingerprint 已经是全内容 CAS——读取路径 parse_plan_session_bytes → validate_plan_session 会重算指纹 并拒绝不自洽的 session，所以指纹相等即意味着 session 与出稿时的快照逐字段 相等。那一条只是「一条 lineage 只提交一次」的残留假设，而同文件的提交闸 validate_current_session_cas 早在 §M1C-2b 那段注释里宣布该假设作废。删掉 之后，投影守卫的判据集与提交闸逐条相同——本来就该是这个关系。 顺带：已经砖掉的项目重放时命中同一条路径补写 successor，点一次「重试恢复」 即可自愈，不需要迁移。 守门扩在既有的 rejected_session_needs_a_collecting_continuation_not_a_wider_submit_gate 上。那条测试本来就构造出了这个 session 形状（带 v1 的 latestSubmittedRef 和 reject 的 lastDecisionRef），却只断言提交闸放行就收尾，差一步没走到。补上真正 提交 v2 并断言 !recovery_pending；把 is_none() 加回去这条会红，已验证非空转。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 08:13:40 +00:00
lhk229	e43133875a	修通审批卡「修改/退回」路线：claim 重放冲突、park 死锁、返工额度串用 ... 生产实测：出 GDD 后点「修改」而不是「批准」，修订委派从头到尾建不出来。盘上现场 （gameagent-c6948da6 / gameagent-347c9786）逐层剥出三个独立缺陷，前两个叠在一起， 修掉上层才露出下层。 1. claim 快照与 delivery 全等比较 claim 的 structuredResult 是「父 Agent 当时观察到了什么」的冻结快照；审批把 delivery 从 EvidenceReady 原地改写成 UserRevisionRequested 后，快照仍停在 EvidenceReady。claim 提交（含幂等重放）按全等判，于是 agent.run_status 每次 重放都 failed，Supervisor 永远拿不到回执。实测空转 43 轮，报「静态委派 claim 与 delivery 身份或结果冲突」。 改为「delivery 是不是 receipt 的合法后继」：除 contractStatus 外每字段逐字 不变、且方向唯一（EvidenceReady → UserRevisionRequested）才放行。原型没有 claim 这层快照，单一真相就地改，结构上不存在这个冲突。 2. park 死锁（被 1 掩盖） 修掉 1 之后 barrier 能正常求值了，userRevisionPending=1 却被 has_waiting() 计成「有在等的委派」，main_loop 于是 park 成「等待专业 Agent 委派回执 / 回执全部 ready 后自动唤醒当前父 run」——那条回执只能来自本 run 自己要创建的修订委派，等的是自己。实测 8 分钟零事件。 has_waiting() 里那个计数是承重的：三处自动恢复路径靠它挡住自动唤醒， runtime_tools/delivery.rs 现场还有 debug_assert 钉着这份依赖。所以不动它， 另加 has_external_wait()（只计 waitingDelegations / unknownContractStatus）， 两处 park 决策点改用它。两个谓词问的是相反的问题：自动恢复该不该收手 vs 当前这轮该不该 park。落进 main_loop 本来就写好的 user_revision_pending 分支 （phase=planning、next_step=调用 agent.delegate）即可。 3. 用户修订与质量返工共用「唯一返工轮」文案 用户修订跳带 repairOfDelegationId 但不是澄清续跑，落进 Repair 分支拿到 「这是对已认领委派 X 的唯一返工轮」——用户第一次点修改就被告知只能改这一次。 counter 层早就正确（lineage_counters 对该跳原样继承 depth/round），错的只有 这句话。新增 StaticDelegateHopNote::UserRevision，判据是原 delivery 的 contractStatus，并同澄清分支一样加 target == project-planning 门，做游戏 / 做素材的返工跳逐字保持 Repair——那句话是它们 replaceExisting=true 的唯一授权 信号。playbook 第 6 条同步改成「约束的是单条 delivery 不是整条链」。 原型对应的是 USER_REVISION_SOFT_LIMIT = 16，且超过只提示不拒绝。 守门三条，都验过非空转： - revise 端到端补上此前缺失的那一步——mark 与 dispatch 之间的 claim 重放，正是 生产上唯一会失败的地方；并断言 !is_clear() && !has_external_wait() && has_waiting() 三者同时成立。把比较改回全等即复现生产原文错误。 - 128 种计数组合的 detail↔barrier 等价性测试里写死两个谓词的分叉点，合并回一个 就会炸。 - user_revision hop note 不得含「唯一返工轮」，须含「不消耗返工深度」「不是最后一轮」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 06:58:27 +00:00
lhk229	f2245fb23d	策划澄清链路按原型拉齐：header 带主题、放开提问面、统一选项形状 ... 对照 local-scripts/deisgn_agent 原型逐条比对后拉回五处分歧。原型 38 条 run 里 22 条走满 3 轮澄清，本仓库 GUI 实测一次都没到过第 3 轮。 1. header 从固定 8 字的轮号计数器「第N轮·关键决定」改回带主题的 「第N轮·当前要决定：<主题>」，决定台账的 topic 改从 header 取。12 字上限是 三条泳道共用的通用 user.input_request 常量，按 header 形状开策划分支——通用 问询今天能过的明天逐字照过，做游戏 / 做素材拿到的仍是 12 字。 2. 提问名额判据恢复原型三分法：「且影响首个可玩闭环」从「空白」的定义挪回提问 优先级，并恢复「空白或存疑」。此前的定义把「无从判断但不影响闭环」的字段整个 排除在空白之外，可问集合被闭合成 pillars + coreLoop 两项。 3. 有默认建议的字段从「一律先用默认建议，不占轮次」改回「优先用默认建议而不是 提问」——有默认不等于不能问。 4. 默认建议清单换回原型那五条（局长偏好、美术、成长、探索、构建）。摘掉 genre.fusion / targetUsers.coreUsers|preferences|referenceGames / outOfScope： 它们进清单等于把第三顺位「制作边界与 MVP」整条轴默认掉，出稿触发器③「剩余 空白都能由默认建议覆盖」随之在第 3 轮恒真。反幻觉那句按原型结构移到「低幻觉 与 GDD 约束」段，outOfScope 的兜底内容与该段已有的 MVP 范围句逐字重复。 5. 选项数 brief 写「2～3 个」（照通用常量生成）、Runtime 硬校验恰好 3、brief 下文 又写「固定三个选项」，三方打架。统一为恰好 3，裸 3 提成 PLAN_CLARIFICATION_OPTION_COUNT 让 brief 与解析器同源。label 分隔符集合按原型 ^A\s*[·•・:：.．\-] 从 4 个扩到 8 个，两处都只放宽不收紧。 守门两条：策划 header 的放宽只对「第N轮·」形状生效、同长度的通用 header 仍被 12 字 挡下；分隔符集合对着一份逐字来自原型正则的显式清单断言——遍历集合本身是空转的， 删一个就少测一个。 未动分歧 5/6/7（轴级封锁、内容级禁问、oneLiner 禁问）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 03:36:29 +00:00