用途
Goal Tree 用于把目标表达为一棵思维导图式的树，其节点之间的关系是“服务于（serves）”，而不是“支持（supports）”。根节点是目标，每个节点的子节点是达成它所需的工作，递归向下直到可直接执行的叶子。它适用于需要表达目标结构的场合，例如撰写 issue 描述、方案方向、目标终态等。
主要能力
- 树形结构：根为目标，子节点为达成父节点所需的工作，逐层分解到可执行叶子。
- 关系约束：每个节点的子节点必须是“达成”它的工作，而不是“论证”它的证据；若子节点是在论证而非达成，则属于论证树（argument tree），应参考 chalk:mindmap。
- 充分性检验：在每个节点上假设所有子节点都已完成，然后追问父节点是否因此达成。检验不是“这些看起来和父节点相关吗”，而是“这些加上我们已知的系统情况，能否让我们到达那里”。领域知识是检验的一部分，必须明确说出来，而不是默默依赖。
- 显式标记：每个节点都必须显式检验充分性，不能默认成立；子节点明显不充分的节点必须标记为 check:，而不能让它读起来像已定论。
- 缺口发现：要找出缺失的子节点，应问“什么会阻止父节点”，而不是“什么会达成父节点”。
- 叶子分类：每个叶子必须声明属于三类之一（在不明显处必须声明）：我们要做的事；对他人或他物的期望（用户、CI、其他团队、上游库、既有行为）；我们所依赖的关于世界的客观事实。对他人的期望不得写成像是我们自己的任务，否则会看起来已被覆盖、像工作一样留在树里，直到有人发现它从未被指派。assumption: 覆盖叶子是否已被验证，而“谁负责”是另一个问题；一个叶子可以两者兼具——关于上游库的已验证事实仍然需要别人来保持其为真。
- 缺口处理：任何地方的缺口都会使其上方的一切失效。缺口必须被暴露，而不是被掩盖。关闭缺口必须是从以下命名动作中做出的有意选择，而不是反射性地加一个任务：换一种方式达成父节点；改派给不会那样失败的人或物；增加一个防止它的步骤；降低其发生概率但不消除；让它发生并在事后恢复；让它发生并限制损害；弱化目标使缺口不再重要；接受风险并继续。“弱化目标”和“接受风险”是真实答案，两者都必须记录在 Out of scope 或 Decision rationale 中——它们是两个在树本身中不留痕迹的动作。被有意削减的范围是某人日后会想要其理由的决定；而悄悄消失的范围读起来像疏忽，读者无法区分两者。
使用方式
- 先加载 chalk:mindmap——主题行、加粗、浅层嵌套、标签和类型化 ID 都同样适用。
- 在 issue 描述中：issue 的目标树比计划的目标树位置更高。issue 回答“要完成这件事，什么必须为真”；计划回答“按什么顺序碰哪些文件”。细粒度的执行（下一个子任务是什么、尝试过什么）留在 chalk 注释中。
- 子节点可以是指向拥有该部分的另一个 issue 的链接，例如：
- [ ] Secondaries serve stale reads without blocking the primary — #412。如果子节点在做真正的工作，它可能应该成为一个子 issue。这样树就是子 issue 图的可读地图，而不是会漂移的第二份副本。要连接关系，而不只是写链接——参见 chalk:issue。 - 调色板位置：Implementation 用于方向，Future state 用于目标终态——以及任何其他需要表达目标结构的章节。
- 提出解决方案的目标树不得写入本次会话没有挣得的 issue。当会话确实推进了方向时包含它；当会话只是注意到问题时省略它。推测性的树读起来像下一个无法与已定论区分开的决定——规则见 chalk:issue。
## Progress checklist不是目标树，目标树不得写入或合并进它。它是 chalk 对工作项及其状态的扁平记录。
适用场景
- 撰写需要表达目标结构的 issue 描述。
- 表达方案方向（Implementation）与目标终态（Future state）。
- 需要把目标分解为可执行叶子并检验充分性的场合。
限制
- 必须先加载 chalk:mindmap。
- 每个节点必须显式检验充分性，不充分的节点必须标记 check:。
- 叶子必须声明三类之一，对他人的期望不得写成自己的任务。
- 缺口必须显式暴露，关闭缺口必须从命名动作中选择并记录。
- 不得写入或合并进
## Progress checklist。 - 提出解决方案的目标树不得写入本次会话没有挣得的 issue。
- 关于收费、价格、平台支持等信息，资料中暂未提供。