grilling

Grilling

全局控制接入

控制面边界：可提议、可审查、可在当前 Work Item 任务范围内记录决定，且必须回到 $phaser4-game-workflow-control 风险门；高影响外部操作的批准仍由控制面处理。

Grilling 只形成 USER_DECISION 澄清记录。把用户选择回写到 Work Item、需求/架构/视觉等权威工件或独立决策记录，并清除对应未决标志；不得写 Approval Ledger，也不得使用批准、审批、pending、handoff 或 approve 描述产品选择。

只让用户决定不能从代码库、配置、现有权威工件或确定性执行确认的事项。不要阻塞纯事实查询、专业可判定缺陷或已确认的低风险执行。

进入方式

1. 读取当前阶段的计划、设计、技术方案、验收、实现和已确认决定，区分事实缺口、专业问题与用户取舍。
2. 先通过代码、配置、现有文档和实际执行关闭事实；专业质量交给独立审核。只有仍存在会实质改变范围、优先级、体验、架构、风险、验收、依赖、视觉方向、成本或发布授权的用户决定时才进入 grilling。
3. 首次模块或边界变化先检查代码、配置、契约和证据；仅当仍存在实质用户取舍时进入 grilling。记录必须绑定 Work Item、当前门、基线与失效条件，不得虚构候选身份。
4. 无产品定义时从目标用户、首次价值、范围、商业约束和风险开始；已有定义时只追问缺口、冲突、假设或依赖，不重复已有结论。
5. 新阶段、新页面、首次模块或边界变化本身都不是触发器。
6. 视觉方向、预算、签名强度或实现/资产成本仍需取舍时才做开放式视觉拷问。已有明确适用基线时不重复确认。
7. V1/V2 已有明确需求或冻结基线，且候选不存在产品方向、玩法语义或上游结构取舍时不提问。指定效果图忠实还原默认使用 visual_validation.mode=usability，小幅位置、尺寸、边距和换行差异可直接修复并重验；只有产品方向、玩法语义、上游结构变化或明确 exact 需求时，才说明影响与候选方案并请求一次确认。发布仍按 A5/A6 记录。
8. 不存在用户决定时直接继续原任务，不生成占位记录。

对话规则

• 一次只问一个问题；每个问题说明影响、推荐答案及理由。
• 从根决定到依赖决定逐层推进，只展开当前范围相关分支。
• 回答暴露冲突或新依赖时先处理冲突，再回到原分支。
• 不把推荐伪装成事实，也不把未回答或沉默视为同意。
• 用户对所问取舍作出明确、无冲突的回答，即满足该问题的确认要求，无需另行确认复述。只有回答仍存在实质歧义时继续澄清；未获得必要回答前暂停直接受影响工作，无依赖工作继续。沉默不构成回答或批准。

范围分支

• 产品与范围：目标用户、首次价值、成功标准、MVP、非目标、优先级和依赖。
• 体验与信任：关键流程、失败恢复、权限、隐私、付费、反馈、无障碍和可撤销性。
• 技术与交付：不可逆架构取舍、平台、能力开关、API/数据边界、验收、证据、质量指标和风险。
• 视觉与资源：方向、信息层级、表达预算、授权、成本、发布资格和可验证质量标准。
• 发布：候选范围、剩余风险、回滚条件和外部放行授权。

完成与记录

用户明确回答后，汇总实际决定、未决项、依赖、拒绝项和下一步，更新权威工件并恢复原任务中已解除阻塞的工作，不以汇总或交接说明替代执行。只有高影响外部操作的显式批准写入 .workflow-control/approvals/ledger.json；普通任务不建立授权记录。不得记录凭据、个人数据或受限合同全文。AUTO 与视觉人工确认的区别统一遵循控制面不可绕过约束。

禁止事项

• 不询问可从代码、配置、文档或执行证据确认的事实。
• 不把实现缺陷、缺证或专业审美问题交给用户承担风险。
• 不因阶段推进、模块存在或边界变化机械触发或重复提问。
• 不在仍有未决范围、风险或验收取舍时推进直接受影响的正式实现或资源生产。