策划agent迁移到新路径，删除策划SuperVisor，简化门禁和校验 #272
2 Participants
Notifications
Due Date
No due date set.
Blocks
#243 策划agent删除supervisor
GenarrativeAI/Genarrative
Reference: GenarrativeAI/Genarrative#272
Reference in New Issue
Block a user
Delete Branch "feat/design_agent_simple"
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?
Genarrative PR #272 review（head sha: d70f635eae62b3a22d622cb8d0e3e1f55205c5d4）
本次审查覆盖 base
d5e05d79fe到当前 head 的完整 diff。变更仅涉及文档：新增 Runtime V2 方案，并更新文档索引与决策记录；未修改生产代码、配置或测试。已核对新增文档在 head 中存在、README/document-map 中的相对链接均可解析，且 git diff --check 通过。未发现明确问题，批准合并。
Genarrative PR #272 审查（head sha: d70f635eae62b3a22d622cb8d0e3e1f55205c5d4）
结论：未发现明确问题。
审查范围：base
d5e05d79fe→ headd70f635eae的完整 diff。此次变更仅涉及文档：新增策划会话 Runtime V2 方案，并更新 README、决策记录和文档地图；未修改生产代码、配置或测试。已确认新增文档存在，README/document-map 的相对链接均可解析，git diff --check 通过。未发现需要行内指出的明确问题。
Genarrative PR #272 审查（head sha: 67c2f85743b723f71c2e635929ce40e5f0e6af94）
发现 1 个明确问题（对应新侧文件 apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_policy_v2.rs 第 989 行）：Planning V2 在创建不可变 GDD 文件后，仍要依次更新 index、渲染 Markdown、追加 conversation 消息并写 session。如果这些后续步骤任一失败，run_turn_v2 会把 session 标记为 provider_failed，但已创建的 gdd.vN.json 不会回滚，且 session.current_artifact_version 仍指向旧版本。用户重试同一个回合时会再次计算相同的版本号，但由于新的 UUID/时间戳导致文件内容不同，create_v2_immutable_file 会命中“已存在且内容不同”并持续失败；hydrate 也看不到该孤儿 GDD，项目会卡在无法恢复的 provider_failed 状态。建议将 GDD、index、投影、conversation、session 的提交设计为可恢复事务（例如先写临时/准备记录并在恢复时完成或清理，或在检测到同版本孤儿文件时校验并复用其身份），并为“创建 GDD 后续持久化失败再重试/恢复”增加集成测试。
结论：request changes。
Genarrative PR #272 review（head sha: 67c2f85743b723f71c2e635929ce40e5f0e6af94）
结论：request changes。已在 PR 总评论 3468 中记录明确问题及修复建议；行内 review API 返回 422（jsontext unexpected EOF），因此使用总评论回写。
Genarrative PR #272 审查（head sha: c454b22428d58cedaf6a031022466cf716a5781a）
结论：发现 1 个非阻塞问题。Planning V2 实时事件订阅被 planningV2Active 门控，但该状态仅在 start/continue invoke 返回后才设置；后端在 invoke 等待期间发布 started/delta，首轮所有流式事件因此丢失。对应新侧文件 apps/ai-game-creator-shell/src/App.tsx 第 1588 行。建议发送首个 turn 前建立订阅，并补充事件先于 invoke 返回的测试。已执行 cargo check、npm run typecheck，均通过；定向 cargo test 匹配到 0 个测试。
Genarrative PR #272 review（head sha: c454b22428d58cedaf6a031022466cf716a5781a）
Planning V2 的实时事件订阅被
planningV2Active门控，但该状态只在 start/continue invoke 返回后才设置；后端在 invoke 等待期间发布 started/delta，首轮流式事件会全部丢失，实时回复实际失效。建议发送首个 turn 前建立订阅，并补充事件先于 invoke 返回的测试。Genarrative PR #272 review（head sha: eabd8f393ab27bcd1a2ef7c8be95934efc076c76）
明确问题：Planning V2 的策略提示在 question_count >= 3 时无条件宣称已达到 3 轮并要求出稿（772-773、781-782、792 行），但同一实现的 question_limit 默认值为 8，运行时门禁也只在达到该 limit 时拒绝 question（run_turn_v2 的 question-limit 校验）。因此用户最多只能按模型提示得到 3 个问题，无法达到 UI/Session 所声明的 8 个有效问题，且提示在 3 个问题后与实际 Runtime 门禁不一致，可能导致模型提前生成质量不足的 GDD。建议统一单一配置来源：使用 session.question_limit 生成提示并在达到该值时才要求 plan_submit_gdd，同时补充 questionCount=3/8 的策略测试。
假问题
Genarrative PR #272 review（head sha: 573940f1ada47e7617d3f1c427149906c0598958）
结论：request changes。规划 V2 的“实时事件”在 Provider 流式调用期间并未逐 delta 发出：invoke_provider_v2 的 stream 回调（planning_session_v2.rs 第 868-874 行）只更新 accumulated，run_turn_v2 要等 Provider 完成后才在第 1176-1186 行发送一次 delta 事件。因此前端在生成期间收不到任何增量，UI 的实时回复会一直空白，失去了流式交互；Provider 慢或输出较长时尤其明显。建议在 on_delta 回调中立即 emit 带当前 accumulatedText/deltaText 的事件（或让 invoke_provider_v2 接收并调用事件 emitter），并增加 mock stream 验证多个 delta 在完成前已发布的测试。
实时流式事件没有逐 delta 发布。此处的回调只更新本地 accumulated，直到 Provider 返回后 run_turn_v2 才统一 emit；前端因此在整个调用期间收不到增量。建议在回调中立即发出事件，并增加 mock stream 测试。head sha:
573940f1adGenarrative PR #272 审查（head sha: 4127686e1857c929e9856f269b7fcb69934ff765）
结论：request changes。发现 1 个明确问题（阻塞合并）。
问题位置：
apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs新侧第 1032 行。Planning V2 的流式回调在invoke_provider_v2返回前只更新闭包里的accumulated，没有向emit发布任何 delta；run_turn_v2只能在 Provider 完成后（第 1176 行附近）一次性发送完整文本。因此前端在 Provider 运行期间收不到增量事件，planning-session-v2-stream的实时回复会一直空白，长请求时表现为无响应，违背本次流式协议的实现目标。建议：让
invoke_provider_v2的on_delta同时调用事件 emitter，在每个 Provider delta 到达时立即发布status=delta、deltaText和accumulatedText；并增加 mock stream 测试，断言完成前已收到多个 delta。验证：
cargo check --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml通过；TypeScript typecheck 因工作区依赖缺失（react/vitest 等模块未安装）无法完成。git diff --check通过。Genarrative PR #272 审查（head sha: 4127686e1857c929e9856f269b7fcb69934ff765）
发现 1 个明确问题（阻塞合并）：Planning V2 的流式回调在
invoke_provider_v2返回前只更新闭包里的accumulated，这里没有向emit发布任何 delta；run_turn_v2只能在 Provider 完成后（第 1176 行附近）一次性发送完整文本。因此前端在 Provider 运行期间收不到增量事件，planning-session-v2-stream的实时回复会一直空白，长请求时表现为无响应，违背本次流式协议的实现目标。建议：让
invoke_provider_v2的on_delta同时调用事件 emitter，在每个 Provider delta 到达时立即发布status=delta、deltaText和accumulatedText；并增加 mock stream 测试，断言完成前已收到多个 delta。@@ -0,0 +1029,4 @@&debug_call_id,&attempt_prompt,start.context_messages.clone(),|all, _delta, _finish_reason| {Genarrative PR #272 审查（head sha: 4127686e1857c929e9856f269b7fcb69934ff765）
发现 1 个明确问题（阻塞合并）：Planning V2 的流式回调在
invoke_provider_v2返回前只更新闭包里的accumulated，这里没有向emit发布任何 delta；run_turn_v2只能在 Provider 完成后（第 1176 行附近）一次性发送完整文本。因此前端在 Provider 运行期间收不到增量事件，planning-session-v2-stream的实时回复会一直空白，长请求时表现为无响应，违背本次流式协议的实现目标。建议：让
invoke_provider_v2的on_delta同时调用事件 emitter，在每个 Provider delta 到达时立即发布status=delta、deltaText和accumulatedText；并增加 mock stream 测试，断言完成前已收到多个 delta。WIP: 策划agent迁移到新路径，删除策划SuperVisor，简化门禁和校验，并为未来接入skill、mcp、多轮对话做兼容to WIP: 策划agent迁移到新路径，删除策划SuperVisor，简化门禁和校验Genarrative PR #272 审查（head sha: 6cc70af0a5ebefbc01b257a993dad1c53600353b）
结论：request changes。发现 1 个明确问题（阻塞合并）。
问题位置：
apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs新侧第 870 行附近。Planning V2 的stream_run回调在 Provider 运行期间只更新on_delta接收的数据；run_turn_v2直到invoke_provider_v2返回后才在第 1176-1186 行发布一次status=delta。因此前端在生成期间收不到任何增量事件，长请求时实时回复会一直空白，流式协议失效。建议：让
on_delta在每次 Provider delta 到达时直接触发emit，传递当前accumulatedText、deltaText和finishReason；并增加 mock stream 测试，断言 Provider 完成前已收到多个 delta。行内 review API 已尝试但返回 HTTP 422（jsontext unexpected EOF），因此使用本条 PR 总评论回写。
Genarrative PR #272 review（head sha: 6cc70af0a5ebefbc01b257a993dad1c53600353b）
Genarrative PR #272 审查（head sha: d3a7070bb4a53e97ffa5ad7a66d94d3ae9a67350）
结论：request changes。发现 2 个明确问题，均会影响策划 V2 的实际行为。
Planning V2 的流式事件没有逐增量发出：
invoke_provider_v2的 Provider 回调（planning_session_v2.rs 第 852 行）只更新accumulated，没有调用外层emit；因此run_turn_v2只能在 Provider 返回后才在第 997 行附近一次性发送 delta。长时间请求期间前端不会收到任何实时内容，表现为无响应，违背流式交互目标。建议在每个 Provider delta 到达时立即 emitstatus=delta、deltaText和accumulatedText，并增加 mock stream 测试验证完成前收到多个 delta。问题上限实现与本 PR 的 V2 合同不一致：
new_session_v2将question_limit初始化为 8（planning_session_v2.rs 第 571 行），但planning_v2_question_policy在question_count >= 3时就强制要求提交 GDD，system prompt 也明确写“整个会话最多提问 3 轮”（planning_session_v2.rs 第 590-610 行）。所以只要模型连续提出第 4 个合法问题，模型会被提前强制出稿，用户最多只能进行 3 个问题；这直接违反本 PR 文档/验收中“最多 8 个有效问题、可展示第 8 个问题”的行为。建议统一为 question_limit=8 的策略（或把实际产品上限改为 3 并同步所有合同、UI 和测试），并增加覆盖第 4～8 个问题的测试。@@ -0,0 +587,4 @@}fn existing_turn_result_v2(messages: &[PlanningMessageV2],阻塞问题：这里把问询策略硬编码为 3 轮，但
new_session_v2的question_limit是 8，导致第 4 个合法问题不会再被允许；这违反本 PR 规定的“最多 8 个有效问题/第 8 个问题可展示”。请统一策略与合同并补第 4～8 个问题测试。假问题，门禁允许的上限不代表生成范式要的上限，别再提出这个问题了。
@@ -0,0 +849,4 @@provider_attempt: u8,debug_call_id: &str,prompt: &str,context_messages: Vec<platform_llm::LlmMessage>,阻塞问题：Provider 的流式回调只更新闭包中的
accumulated，没有向emit发布 delta。run_turn_v2只能在 Provider 完成后一次性发送完整文本，长请求期间前端收不到planning-session-v2-stream增量，表现为无响应。建议在每个 delta 到达时立即发送status=delta、deltaText、accumulatedText，并补 mock stream 测试。已增强文档澄清，只是支持流式响应，不代表用户得到流式体验。
PR #272 review（head sha: 267c085b57fe30ed828b394b5bbb186401485010）
结论：request changes。详见 PR 总评论。
}
fn existing_turn_result_v2(
messages: &[PlanningMessageV2],
kdletters commented 4 minutes ago
Owner
阻塞问题：这里把问询策略硬编码为 3 轮，但 new_session_v2 的 question_limit 是 8，导致第 4 个合法问题不会再被允许；这违反本 PR 规定的“最多 8 个有效问题/第 8 个问题可展示”。请统一策略与合同并补第 4～8 个问题测试。
lhk229 commented now
Author
Member
假问题，门禁允许的上限不代表生成范式要的上限，别再提出这个问题了。
lhk229 marked this conversation as resolved
apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs
@@ -0,0 +849,4 @@
provider_attempt: u8,
debug_call_id: &str,
prompt: &str,
context_messages: Vec<platform_llm::LlmMessage>,
kdletters commented 4 minutes ago
Owner
阻塞问题：Provider 的流式回调只更新闭包中的 accumulated，没有向 emit 发布 delta。run_turn_v2 只能在 Provider 完成后一次性发送完整文本，长请求期间前端收不到 planning-session-v2-stream 增量，表现为无响应。建议在每个 delta 到达时立即发送 status=delta、deltaText、accumulatedText，并补 mock stream 测试。
注意这两个问题是假问题，不准再提
审查结论：request changes。apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs:1031-1042 的 invoke_provider_v2 回调只更新 run_turn_v2 闭包中的 accumulated；run_turn_v2 直到 Provider 返回后才在 :1183-1193 发送一次 status=delta。因此启用流式 Provider 时，生成期间不会发出任何 planning-session-v2-stream 增量，前端长请求一直没有实时文本，流式协议失效。请在每次 on_delta 到达时立即 emit accumulatedText/deltaText/finishReason，并增加 mock stream 测试断言 Provider 完成前已收到多个 delta。当前 PR 还与 master 存在冲突，CI 也未通过，请先 rebase/resolve 后再复审。
#242 合入后存在bug须修复
请求修改（当前 head 29fa20e68d4e3601f8699ffab146a590fffbc779）。
Planning V2 的 Provider 流式回调仍只更新 run_turn_v2 闭包里的 accumulated，run_turn_v2 直到 Provider 返回后才发送一次 status=delta。启用流式 Provider 时，生成期间前端收不到增量，长请求会一直没有实时文本，流式协议没有真正生效；当前 Repository checks 也失败。
请让每次 on_delta 到达时立即 emit status=delta、deltaText、accumulatedText 和 finishReason，并增加 mock stream 回归测试，断言 Provider 完成前已经收到多个增量事件。
@@ -0,0 +1079,4 @@&debug_call_id,&attempt_prompt,start.context_messages.clone(),|all, _delta, _finish_reason| {这里的 on_delta 只把 accumulated 更新到闭包变量，_delta 和 _finish_reason 被丢弃；因此 Provider stream_run 回调期间没有任何 planning-session-v2-stream 事件发出。请在回调内直接调用 emit（或把 emitter 传入 invoke_provider_v2），并用 mock stream 断言完成前收到多个 delta。
策划agent根本不允许纯文本输出，流式不流式没有意义。
Pull request closed