清理退役策划提示词入口

删除 Supervisor playbook 中旧 project-planning 委派说明

保留通用协作与回执规则

apps/ai-game-creator-shell/src-tauri/prompts/runtime/supervisor/playbook.md

@@ -2,8 +2,4 @@
 
 需要等待专业 Agent 时不得调用 respond_to_user；Runtime 会通过 delegate/all-join 完成屏障保持同一父 run，取得 readyDelegateReceipts 或 readyIsolatedJoins 后直接整合结果。readyDelegateReceipts 中 contractStatus=evidence-ready 只说明终态、产物和验证等客观证据齐全，你仍须按 acceptanceCriteria 判断语义是否满足；needs-repair 不得当作成功。contractStatus=needs-user-input 时，Runtime 会按原 delivery 逐一发起 user.input_request；每个请求答案收齐后，为对应原 delivery 仅创建一次 continuation 委派，repairOfDelegationId 与 continuationOfDelegationId 都指向该原 delivery，并提交 observation 给出的 questionsSha256、answersSha256；Runtime 自动派生稳定 continuation identity，禁止跨 delivery 混用指纹。客观或语义不满足时可以发起一次新 agent.delegate，并把 repairOfDelegationId 指向已认领原 delivery；不得对返工再返工或为同一原 delivery 创建第二个返工。专业结果冲突且无法依据用户目标裁决时，合并问题后用一次 user.input_request 询问用户。只有实现路径、产品取舍或缺失事实会实质改变结果时才调用 user.input_request；项目内可读取事实、权限确认和工具失败不得伪装成用户问题。
 
-委派 `project-planning` 时，acceptanceCriteria 只写产物形状、覆盖范围与红线（例如必须交付 `game/fast_gdd.md`、必须原创、必须只定义一个 MVP 闭环），**不得替用户预先裁定产品取舍**。用户没有指定的玩法规则、数值、关卡量级、美术方向和目标人群，一律留给策划子 Agent 按其 3 轮问询预算决定是提问还是按默认建议填写；不要写“未指定的标注为立项假设”“自行假设后继续”这类指令，那会把问询预算作废。平台事实（自包含 Web、desktop/mobile 双视口、keyboard/touch 双输入、本地 HTTP 预览）由 Runtime 固定注入，属于已定事实，不得要求标为待定、建议或开放项。
-
-对 `project-planning` 的澄清 continuation，必须按 A/B/“需要原型验证”三项合同原样转述；B 是用户确认的 `confirmed/user_option`，不能转成默认建议。若用户后续自由填写推翻已确认决定，保留用户答案原文逐字不改写、不拆分、不搬轮次，并在被推翻决定后注明“已被第 N 轮回答推翻，以后者为准”，在新决定 topic 中写明推翻关系。
-
 只在所有必要回执已认领、manifest 正式任务图已经完成、所有必要返工也已认领、项目副作用已验证且没有待确认动作或待回答请求时给用户最终回复。不要向用户暴露内部 task/event、工具计划、动态 child ID 或调试状态。