weberwang Unity 游戏拷问
在执行不可逆、昂贵或会改变批准边界的工作前，先以证据消除事实问题，再逐项取得用户决策。拷问不能被代理审查、默认值或一次含糊的“继续”替代。
严格触发
出现下列任一条件时必须进入拷问：
- 新建模块、模块首次实现，或改变职责、非目标、公开输入输出、状态所有权、依赖方向、失败边界。
- 新建场景，或改变场景职责、进入退出条件、共享状态、加载关系、持久化边界。
- 请求批准全局 Visual Bible、P0 低保真结构、P1 高保真候选、P3 资产地图、3D 模型/贴图目标、研发期 Editor 实现视觉，以及仅在 G2
PASS后出现的最终实机视觉。 - 范围、优先级、成本、风险接受度、验收证据、授权、隐私、发布资格或 Windows 交付方式不明确或相互冲突。
其余事项只有在仓库、文档和证据无法消除未知项，且继续确实需要人工取舍时才触发。不得重复询问已有、有效且绑定当前版本的结论。
执行顺序
- 读取当前计划、GDD/TDD、场景与资源契约、Visual Bible、质量门、验证证据和既有批准。先输出证据清单，每项事实附项目相对路径、对象版本或来源修订；没有证据时只能标记为假设或未知，不得推断为事实。把内容分成已核实事实、假设、未知项和必须由用户选择的决策。
- 先通过只读检查消除可验证问题。禁止把可由仓库、Unity Editor、构建报告或现有证据回答的问题转给用户。
- 按依赖和影响排序决策。低风险、互不依赖且推荐相同默认策略的事项可组成一个决策包；高影响、相互依赖、冲突或会使下游批准失效的问题一次只问一个。
- 每次提问都说明：已核实事实、唯一待决策问题、对范围/成本/风险/返工/门禁的影响、二至三个互斥选项、推荐项及理由。不得把推荐写成事实或把沉默视为同意。
- 记录用户回答并检查它与已批准边界、Unity 6/URP/UI Toolkit/Windows 约束及上游证据是否冲突。回答含糊、对象或版本不明时，继续追问当前问题，不得擅自解释为批准。
- 所有阻断项关闭后，提交一份版本化决策摘要，明确批准对象、范围、非目标、拒绝项、风险接受、验收证据、失效影响与下一步，并请求用户明确批准该摘要。
- 批准后更新控制面和机器记录，验证引用、版本、SHA-256 与状态一致，再把受影响任务交还总控。用户要求修改时生成新版本并回到最早受影响问题，旧记录只作为历史。
拷问范围
- 产品：目标用户、核心问题、首次价值、核心循环、MVP、非目标、成功指标、优先级、商业和时间约束。
- 体验：关键流程、操作反馈、失败/重试/退出、暂停和存档、教程、可读性、无障碍、输入设备与体验验收。
- 技术：Unity 6 版本、URP、UI Toolkit、Windows、架构、数据生命周期、存档兼容、安全/隐私、性能预算、第三方依赖和能力降级。
- 模块与场景：存在必要性、职责与非目标、状态所有权、公开契约、依赖方向、加载/卸载、失败隔离、共享服务、实现顺序、测试和完成定义。
- 视觉资源：全局视觉语言、参考图允许用途、授权与生成方式、P0-P5 批准点、2D 适配与无黑边背景、字体/UI/动效、成本、资源地图和发布资格。截图只可辅助内容、构图和信息层级判断，不能批准为成品风格或裁切素材来源。
- 3D：比例与单位、轮廓、拓扑、模块化、坐标轴/Pivot、UV、材质槽、贴图集、骨骼/动画、LOD、Collider、性能预算、DCC/MCP 能力边界和源文件交付。
- 质量：可验证验收、测试层级、画面与交互审查、目标帧率、内存/包体预算、支持分辨率、P0/P1 缺陷策略和证据保留。
- 发布：版本、构建配置、许可清单、存档/升级风险、回滚、签名与分发、发布阻断、最终风险接受和用户放行。
写入边界
用户明确批准当前决策摘要前，只允许只读调查、候选方案、问题记录和不依赖该决策的工作。禁止对直接受影响的内容执行：
- Unity MCP 写入，Scene/Prefab/资源导入，以及任何直接受影响的代码、测试、生成代码、配置或工程文件修改。
- 批量图片、模型、贴图、材质或动画生产，以及替换已批准视觉资源。
- 改写批准范围、模块/场景边界、验收、风险状态、质量门或发布状态。
- 让子代理在未批准边界内先行实现，或以代理审查代替用户批准。
批准前的候选方案与问题记录只能保存在对话或明确隔离的非生产草稿区，禁止写入 Unity 项目的 Assets/、Packages/、ProjectSettings/ 或受影响模块源码目录。截图授权、允许参考维度和禁止用途必须在任何视觉候选生成前单独确认；提供截图不代表用户已批准其版权状态、风格复刻或批量生产范围。
用户批准只解除其明确覆盖的对象和版本。任何上游内容、版本、哈希、来源修订或批准范围变化，都必须使受影响下游结论失效并重新拷问。
本地 approval 文件和哈希只用于内容完整性，不是用户身份凭证。代理不得自行创建、修改或补签用户批准原件；必须以当前宿主对话中的真实用户批准事件，或宿主提供的只读/签名收据为身份来源。宿主不能提供可验证批准事件时，记录必须明确身份尚未机器验证；外部供应商、付费、签名、上传、发布和覆盖稳定制品继续保持 BLOCKED，不得把本地 YAML/文本记录解释为授权。
决策记录
将当前决策摘要写入 docs/control-plane.md 的“待人工决策”“有效变更”或相应门禁索引，并为每次拷问生成符合总控目录现行 grilling-record Schema 的机器记录。若契约不存在、校验失败或无法绑定当前主体与版本，则保持 BLOCKED，不得自创替代格式后继续。
机器记录至少表达：记录 ID/版本和来源修订、触发原因、批准主体及其 ID/版本/SHA-256、已核实事实、假设与未知项、逐题选项/影响/推荐/用户回答、最终范围与非目标、拒绝项、接受风险、验收证据、受影响门禁与交付物、失效关系、批准权限与时间、结论和下一步。禁止记录凭据、个人数据或受限合同全文。
完成前运行契约校验，并确认控制面摘要与机器记录指向同一批准对象和版本。缺失回答、模糊批准、代理代批、证据失效或记录不一致一律不得标记为已批准。
完成条件
- 强制触发范围全部覆盖，高影响问题均逐项取得明确回答。
- 用户明确批准版本化摘要，且批准绑定精确对象、版本、SHA-256、来源修订与结论范围。
docs/control-plane.md与grilling-record均已更新并通过校验。- 受影响任务、门禁、下游失效项和下一步均明确；未决项保持阻断，不伪报完成。