plan

计划

将缺失的意图收敛为一个可执行的切片，然后停止。变更清晰时可直接推进；只有需要回答某个问题时，才加载专业人员。 优先使用调用方的跟踪工具（如有）；否则使用对话或提供的文本。提供的建议（例如 Idea Genie 作品集或挑战）是需要权衡的证据，而不是决策。

计划需符合以下规则

1. 一个切片，不是路线图。 收敛为范围最窄、能贯穿所涉及的每一层并端到端产生可观察结果的变更。不要分阶段， 不要逐层拆分，不要创建待办列表：后续工作在新证据使其成为下一个切片之前，每项都只保留一条粗略描述。如果有多个切片都可以先做，优先选择最小的可观察路径，以检验方案中风险最高的依赖。各自有用且可单独验证的结果属于不同计划，而非切片：除非请求、跟踪工具或 Navigate 已确定先后顺序，否则提出问题（规则 3），并将其余事项放在“稍后”。提到的提供商、设备或数据源属于同一个结果的覆盖范围；只有不存在能满足指定要求的共享路径时，才将它们分开。如果单独说明某个部分就意味着要猜测它与其他部分共享的行为，则应将这些部分放在一起。标明任何替代项以及它无法证明的内容；使用该替代项进行演示，并不能证明真实集成有效。
2. 先举例，再做任何设计。 至少写一个 Given/When/Then，并包含可观察结果。覆盖出错后难以挽回的边界，例如重复或外部副作用、数据丢失或权限扩大，而不只是理想路径。
3. 查明事实；只询问选择。 阅读代码、文档和跟踪工具，而不是提问。最多向调用方提一个问题，且仅限没有任何来源能回答的选择，并说明你的建议及其权衡。当有多个选择争用提问机会时（哪个结果优先、规则 7 冲突、由谁决定 中记录的决策），提出对切片影响最大的问题，并将其他选择逐项列在“稍后”中，说明各自会改变什么。如果有多个问题会阻碍验收，则通过 Interview 每轮解决一个。
4. 沿用仓库中的用词。 重用代码、术语表或跟踪工具中定义的术语；绝不另造平行名称。
5. 按使用方确定范围。 指明需要修改的所有者、变更行为的所有实际调用方和测试，以及作为一类文件的生成伴随项，并使用相对于仓库的路径模式。范围代表授权，而非预计的文件数量：范围外存在实际使用方时，应向调用方提出精确到文件的范围修订，同时继续独立的范围内工作。
6. 有区分力的检查： 说明当前会失败、完成切片后会通过的检查。
7. 未经请求的机制必须证明其必要性。 只有在契约要求、缺少该机制会导致追踪到的故障无法及时被有能力修复的人发现，或日后添加成本高昂时（例如持久化数据或格式、他人依赖的接口、支付、安全），才能将防护、重试、回退、选项或抽象纳入切片。采用最小形式，并以同样标准评估每项附加内容；拿不准时就先不加，将其列在“稍后”，并说明需要什么证据才能要求添加。如果切片失败后没有任何能够采取行动的人会知情，则让该失败变得可见也是切片的一部分。任何防护措施都不得缩小请求的行为范围；存在真正冲突时，应提出问题。

输出

当请求或现有授权涵盖编辑调用方现有的意图时（对话始终涵盖），将此块写入其中；否则将其作为拟议修订返回。它就是完整计划。

Outcome:  <who observes what, in the repository's terms>
Example:  Given <state>, when <event>, then <observable result>
Slice:    <the one end-to-end change that makes the example true>
Scope:    <owners>; consumers: <live callers and tests>; generated: <class> | none
Check:    <the test or observation that fails now and passes after the slice>
Question: <one caller choice, your recommendation, its tradeoff> | none
Later:    <deferred item and the evidence that would make it next> | none

只有在涉及另一个后果重大的边界时才添加 Example 行；只有在某个事实仅由指定人员掌握时才添加 Open 行（并附上拟定的问题）；只有在能避免合理可预见的范围误解时才添加非目标。

工作流

1. 阅读已接受的意图、任何现有计划或原生交接，以及相关源代码负责人和当前约束。复用对话或 bead 中已提供的验收标准；只有在有事项妨碍行动或判断时才请求澄清。若要恢复工作、移交一个切片，或将代码配对与回顾或快照意图结合，请参阅恢复与交接。
2. 只处理可能改变切片的不确定性（见下表）。如果接口选择会影响该不确定性，在确定边界前，请有条件地使用从调用方角度比较设计方案。
3. 填写此区块。如果保持行为不变的重构能显著缩小切片，请在 Slice 行中将其列为前置条件，通过 Refactor 执行，并单独列出重构前后的检查项，不要将其纳入切片的差异中。无法逐个切片保持可用状态的机械式跨领域迁移，应采用扩展、迁移、收缩的方式，并说明需要在哪里进行集成。如果记录的证据（评分卡、固定装置）绑定到切片将更改的文件，则应计划重新采集；使用插件未附带的 ao CLI 时，ao provenance evidence-orphans --root <repo-root> --changed <path> 会列出这些绑定。在一个 epic 中，Navigate 选择下一个 bead；Plan 负责梳理该 bead。
4. 当证据否定某种方案时，在现有意图中保留失败的假设、相关证据和修订后的检查项，其权限级别与下文 Output 写入相同。在已接受的结果和范围内更换方案无需新的许可；验收或扩大范围则需要调用方同意。切勿将未通过的验收条件重新标记为注意事项以获得通过。

只要实现者能够着手执行，验证者能够作出判断，就停止规划。进一步的研究、拆分或评审必须能解决明确指出的剩余不确定性；应为实现、集成和修复留出容量。

处理不确定性

不确定性	后续操作
源代码可以回答的事实	检查范围最小且权威的源，并注明出处。Research 负责深入追踪；Domain 负责有争议的术语。绝不要让调用方复述这些信息。
调用方的选择	先找回现有授权。剩下的就是那个问题，并说明具体的权衡；Agent 无法代替调用方作答。
只有指定的其他人掌握的事实	指明此人，并草拟解决该信息缺口所需的少量问题，按重要性从高到低排序，每个问题只包含一个要点，并提供足够的背景以便回答；将问题随计划一并返回，由调用方决定是否发送以及如何发送。回答前，此事项保持未解决；绝不要猜测答案或将其重新表述为调用方的选择。
只能通过观察确定的假设	说明相互竞争的预测，以及能区分它们的最小观察，可使用可选的探测或原型。有说服力的设计或 Agent 投票都无法确定尚未观察到的行为。
可安全延期的事项	将其列入 Later，并注明使其变得相关的事件或证据。延期不能掩盖尚未回答的验收条件。

在已接受范围内解决可逆的实现细节。标明推断和尚缺的证据；绝不要将二者提升为源事实或已确定的调用方选择。对于经过源代码检查和观察后仍存在的重大不确定性，可选择使用质疑，以获取建议或下一步判别方法，而非许可或验收。 Memory recall 仅在既往证据可能改变下一步行动时才有帮助。

由谁决定

根据实际撤销成本、受影响用户和现有权限作决定。超出该权限范围且会造成重大、不可逆影响的选择，应交由调用方决定；如果某个切片会违背已记录的决定（例如 ADR、已发布的契约或声明的非目标），也应如此：将该决定以及重新审议它的证据列为问题，并在调用方答复前确保切片遵循该决定。先前的授权仍然有效。评审者达成一致是证据，而不是取代调用方意图的许可：对于会造成重大影响的分歧，应说明分歧及其依据，而不是悄然改变验收标准。拟议的流程产物必须有明确的使用者、它所把关的决定、已观察到的缺陷以及退役条件；否则应省略。

示例

示例可以是纯文本；BDD 不需要 .feature 文件或访谈。在一个将排队的工作称为 Job 的代码库中（写“Job”，不要写“task item”）：

Given 一个 Job 已经完成，当 worker 再次收到它时， then 返回其已完成的结果，并且不重复执行其副作用。

编码后添加的测试可以补充已接受的示例，但不能重新定义已承诺的内容。