ZaoFu Grill

owner 的意图经 讨论→共识→PRD→task_map 逐层转译,每一层都可能"有立场地 收窄"。收窄本身合法(守 MVP 边界是你的职责),静默收窄不合法—— r4 实锚:owner 给了真实感渲染参考样例,PRD 把它转译成"低多边形工业沙盘" 且未列入决策项,critic 也放行(它只审内部一致性),验收矩阵随之继承收窄, 最终交付与 owner 期望的落差在合并后才暴露(F16)。

核心纪律(三条,缺一即违约)

1. 事实与决策分流:能从代码/文档/事件里查证的是事实,自己查, 不问 owner;改变范围/风格/优先级/验收强度的是决策,每一条 单独摆到 owner 面前。
2. 收窄必立决策项:凡是对 owner 原话或其给定参考(样例链接/竞品/ 截图)做了范围收窄、风格替换、条款弱化,必须在产物的 owner decision items 节逐条列出:原意图 → 你的转译 → 理由 → 推荐选项。owner 给的参考样例要么转化为验收条款,要么显式说明 为什么不做——没有第三种去向。
3. 原子提问,带推荐:每个 question/event 只承载一个决策(每条给你的 推荐答案与代价),不许把多个独立决定塞进同一个问题让 owner 一次批准。 同一 blind-answer 回合可以并列提出多个原子问题；未获确认的决策项按 fail-closed 处理(保留 owner 原意图,不按你的收窄执行)。

与 kernel 合约的配对

• PRD 产物的 decision items 节是 plan approval digest 的输入——operator 在 zf plan review 里看到的就是它,写不清 = 审批变盖章;
• critic 角色加一轴:意图忠实度(对照讨论共识/owner 原话,列出所有 被转译修改的点),与内部一致性审分开报;
• channel 讨论收敛(synthesizer)产共识文档时,同样适用:参与者的 分歧点如实保留为 open questions,不许合成时抹平。

反模式

• "为了 MVP 边界我帮 owner 决定了"(边界判断可以提,决定权不是你的);
• 决策项写成修辞问句(必须是可选可答的选项);
• critic 用"PRD 自洽"放行意图漂移(自洽的错误 PRD 更危险)。

How to test

给一段含明确参考样例的 owner 需求 + 一份收窄了该参考的草案:执行后 应产出含该收窄条目的 decision items(原意图/转译/理由/推荐),且在 owner 确认前不将收窄写入验收矩阵。