Native 把“结果由用户决定、方法由强模型决定”作为核心边界。它不会用更少阶段换取模糊需求，也不会把行业惯例或现有代码默认值当成用户授权。
哪些必须由用户决定
任何会改变以下内容的未解决分支都属于用户决定：
- 用户可见输出、默认行为或错误结果；
- 兼容性、范围与风险承担；
- 数据删除、迁移或其他不可逆结果；
- 一个新能力在边界条件下的可观察语义。
实现结构、库选择、内部算法和测试组织方式，如果不改变上述结果，则由模型自主选择。
问题如何排序
Shape 会把关键动作写成输入→输出或触发→结果示例，再检查默认值、边界、失败路径和兼容性。一个反例能够区分两种合理解释，就说明共享理解尚未形成。
发现多个问题时，Native 不发固定问卷，而是先确定问题的前置决定和所需仓库事实。默认的 sequential 模式每轮询问一个最上游问题；batch 模式则一次提出所有前置条件已确定、且彼此不依赖的问题。每道问题都包含：
- 问题：需要用户确定的可观察行为；
- 推荐：基于目标和权衡给出的建议；
- 影响：各选项会怎样改变结果。
问题写入 brief.md 的 [blocking] 项。用户回答前，模型可以调查仓库或创建 change，但不能把某个选项写成既定规格、修改项目实现或推进到 Build。
什么时候不需要确认
当本轮已没有可回答问题，且另一个没有当前聊天记录的强模型仅凭 brief、完整目标规格、仓库事实和项目规则就能实现并验收时，共享理解已经成立。Sequential 模式会直接继续，不额外询问通用确认；Batch 模式会先给出一次最终共享理解摘要，只有用户明确确认后才进入 Build。
--confirmed 只用于记录用户刚刚回答了先前的阻塞问题。用户最初提出功能并不自动等于一次确认，也不能通过手工修改 approval 绕过需求澄清协议。
“保持现有行为”只能保护已经存在的结果，不能替一个全新的行为自动定义语义。相邻功能、依赖库默认值和最小改动原则只能帮助形成推荐，不能代替用户答案。
