grill

name	grill
description	在 Shape 已经形成候选方向，或用户带着现有计划、设计、提案和决定，要求拷问、挑战、压力测试、补齐隐含决定或确认是否足以继续时使用。把对象展开成有依赖关系的决策树，按当前前沿分轮提出多个问题，让用户对推荐选项作出裁决。开放探索和生成方向由 shape 负责；所有者缺席时对成文产物做独立检查由 review 负责。

grill

把已经成形的方向放到用户面前经受压力。Grill 不替用户发明目标，也不审批方案；它让尚未说出口的决定、假设和代价显形，直到双方对准备继续的对象有共同理解。

先确定被拷问的对象

输入必须是一个已经能描述的方向、计划、设计、提案或决定。只有模糊意图、还没有候选形状时，先交给 shape；有成文产物但所有者不参与回答时，交给 review。

先读取相关代码、文档、运行证据和当前 Active Task。能够自行查到的事实先查，不把项目功课问回用户。Grill 只向用户追问价值、偏好、风险接受、授权和其他必须由责任人裁决的事项。

建立决策树

在内部把对象展开成决策树：一个决定下面只挂真正依赖它的后续决定。只纳入会改变目标、范围、可观察行为、完成证据、不可逆代价或重要取舍的分支，不为理论上的所有可能制造问卷。

当前前沿是所有前提已经确定、现在可以在不猜测其他答案的情况下裁决的节点。事实调查尚未完成时，只有依赖该事实的分支等待；其他已经成熟的前沿问题继续推进。

按前沿分轮提问

每一轮提出当前前沿中能够一起回答的问题，而不是机械地一次一问，也不是把整棵树一次倒完。问题很多时按同一父决定拆成容易回答的组；互相依赖的问题绝不放在同一轮。

每个问题都要：

• 编号，并说清它现在决定什么；
• 给出 2–3 个具体选项及主要代价，适合时允许用户补充自己的答案；
• 明确推荐一个选项和理由，让用户能够反应，而不是从空白开始组合；
• 使用宿主已有的结构化提问界面；没有时用简洁的编号列表。

等用户回答后，把答案折回决策树，说明它确定了什么、暴露了什么，再重新计算下一轮前沿。用户只回答一部分时先吸收已回答项，其余保持开放，不把推荐当成默认同意。

用户提出问题或表示没看懂时先解释；问题本身不是答案，只有明确选择才折回决策树。

区分回答和决定。用户明确选择、且该选择会约束后续价值、范围、风险或取舍时，把它记为 UD candidate；普通反馈、追问和暂时倾向不升级。候选与当前 Active Task 的 UD-* 冲突时，单独指出“保留旧决定”和“用新决定替换”的后果，明确询问是否 supersede，不能用新回答默默覆盖旧决定。

压力应落在当前最薄弱的地方，例如：目标是否真实、成功怎样观察、哪个相邻问题明确不做、哪个事实为假会推翻方向、有没有更小的办法、失败是否可撤销、依赖和验证是否成立。不要为了显得严谨把这些角度全部问一遍。

“我不知道”是一条有效发现。把它变成有名字的未知，并给出取得证据、做低成本实验、接受显式假设或返回 Shape 的具体路径。

收敛与交回

当前沿为空、剩余问题不再改变承诺，或用户要求停止时，交回一份简洁结论：

• 已确认的决定，以及被拒绝选项中值得保留的理由；
• 仍未成立的假设和缺失证据；
• 当前对象是否足以进入下一项工作；
• 哪些 UD candidate 应交给 shape 写入 Task Context，以及它们是否替换现有 UD-*；
• 哪些变化必须回到 shape 修订方向或 Task Context。

Grill 默认只交付对话和这份结论，不另建平行状态文件。已有 Active Task 时，UD candidate、范围或承诺变化仍由 shape 在用户同意后通过 longrein task context --decision 写入 Runtime；Grill 不分配正式 UD-*，不直接编辑 task.md，也不能自行增加 scope_revision。用户确认达到共同理解前，不依据被拷问的对象开始实现。

边界

Shape 让可能的方向显形；Grill 让一个已有方向经受所有者当场裁决；Review 在不依赖作者回答的情况下独立检查产物。Grill 不是每个任务的固定阶段，也不能用一场顺利访谈代替设计、评审、测试或批准。