修复链路上存在的若干阻塞性漏洞 #199
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: GenarrativeAI/Genarrative#199
Reference in New Issue
Block a user
Delete Branch "opt/design_agent"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
用户在审批卡上写的意见此前只落到 `.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>本轮修复问题
基于当前 head
8779018653a1c6390413285b8242f194ec1faf4c的只读复核结果：阻塞：
apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_submit.rs:1767移除了 submit input 与 durable planning session 用户权威的校验。现在 Provider 可以在普通提交中自行构造state="confirmed"、answer_source="user_revision"的新决定；现有测试submit_allows_user_revision_decisions_outside_the_previous_session_snapshot还明确将其视为合法。approval_request_id只是提交关联 ID，不能证明该决定来自用户审批意见，这会让模型伪造用户确认并绕过审批边界。请恢复最小约束：user_revision只能在有对应持久化审批修订事实的 continuation 中出现，普通首轮提交不得凭模型文本声明用户权威。非阻塞：
apps/ai-game-creator-shell/src/features/project-workspace/GddApprovalCard.tsx:441的审批按钮只禁用decisionBusy，没有禁用hydrateBusy。hydrate 期间仍可能基于旧 pending 卡提交决定；建议统一使用hydrateBusy || decisionBusy。验证：
cargo check通过；planning approval 定向测试 4 项通过；git diff --check通过。PR CI 中Project CI / Native shell tests被取消，必需 CI 尚未验证。,请求修改：请先修复评论中的审批权威绕过问题（必须将 user_revision 绑定到持久化用户审批事实，不能由 Provider 自行伪造），并补齐/验证对应回归测试；同时建议修复 hydrateBusy 期间审批按钮仍可提交的竞态。当前必需的 Native shell tests 仍为 cancelled，修复后请重新运行并贴出结果。
关于写入user_revision的问题，已经将最大的可能触发面堵住。质量返工仍可写user_revision。但是用户修改后触发的质量返工在语义上可以判定为修改的后继，写入user_revision判为合法。而无关质量返工虽然在门禁上有可能绕过，但不存在稳定触发点。
基于当前 head
fa3b60777ccbaa835fd1a8f84b0fcc99bc2bb2af复核：上次指出的 hydrateBusy 竞态已修复，当前 CI 也已全绿且无冲突。仍请求修改以下阻塞项：apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_submit.rs:1195-1216的validate_user_revision_requires_approval_decision只判断当前 session 的last_decision_ref.action是revise/reject，没有绑定具体 version、responseId、receiptFingerprint 或审批意见。进入任意 revise/reject continuation 后，Provider 仍可附加任意新的user_revision决定，用户权威范围仍然过宽。请将其绑定到当前审批 receipt/版本，并补充跨版本、跨请求回归测试。当前本地验证：PR head 的 shell/server-rs cargo check 通过，审批相关前端文件 Prettier 通过，git diff --check 通过。,
请求修改：请将 user_revision 决定绑定到当前具体审批 receipt/版本（至少校验 version、responseId、receiptFingerprint 或等价不可伪造关联），并补充跨版本/跨请求回归测试。当前 head 的 CI 已全绿、无冲突，但该用户权威边界仍未收紧，修复前不建议合并。