land

切勿提交未经验证的工作。

快速路径：差异很小，而且调用已明确指定路径：合并、PR、保留或丢弃。此时跳过选项菜单，直接执行，除非第 4 步移除了该路径。规格说明相关问题不属于快速路径。如果存在规格说明，且调用未说明如何处理，就在此处一并询问。用一行提出问题，并默认保留。

1. 执行任何操作前，先创建一个任务列表，并将这些步骤作为其中的事项。如果任务列表已存在，就将这些步骤添加到列表中。每个步骤各占一个事项。若所选路径跳过某个步骤，就将其标记为已完成，并在其文本中添加 skip: <reason>。
2. 阅读 verify 技能并遵循其要求。如果树哈希未变化，它会复用证据记录。在已声明的阶段内生成的记录仅覆盖该阶段范围。因此，如果在阶段内提交成果，须先运行完整门禁。然后阅读 rubric 技能并遵循其要求。如果工作有位于 docs/specs/<slug>.md 的规格说明，就执行缺陷检查。如果差异修改了 UI、公共接口、名称或文案，也执行品味检查。如果规格说明包含描述质量而非行为的验收标准，也执行品味检查。将需采取行动的发现反馈给 implement 或 debug。修复后的树必须再次通过 verify。未通过验证的工作不得进入选项菜单。
3. 确定环境类型：普通检出、命名分支工作树或分离 HEAD。分离 HEAD 表示该工作区由外部管理。
4. 恰好显示以下四个选项，不作解释：在本地合并到基分支、推送并创建 PR、保留分支或丢弃。分离 HEAD 时，移除合并和丢弃选项，即使调用指定了其中一个也不例外。然后说明该工作区归管理它的对象所有，并显示其他选项。丢弃操作要求用户输入“discard”。
5. 对于合并和 PR 路径，关闭规格说明。先将其中需要长期保留的内容移出。值得保留的决策应按 decision-record.md 的说明写入 ADR。已确定的术语应按 terms.md 的说明写入 CONTEXT.md。系统结构发生变化时，应按 architecture-format.md 的说明更新 ARCHITECTURE.md。如果该文件不存在，就创建它。此项迁移不可省略。只有规格说明文件的去留由用户决定。用一行询问，并在同一行给出默认选项：保留，除非用户另有要求。调用中指定的路径已作出回答，例如“提交：合并，删除规格说明”。保留路径无需询问，直接保留规格说明，因为它仍将指导工作。
6. 根据规格说明撰写 PR 正文和合并提交消息。正文以演示开头。演示即 verify 证据：运行了什么以及结果如何；或者说明如何体验此项更改。然后以目标作为摘要行，以验收标准作为变更列表，并以非目标作为范围说明。无论规格说明文件是否保留，都应将推理记录到 git blame 所指向的永久记录中。
7. 对于合并路径，按以下顺序执行操作：在主检出中合并分支。测试合并后的结果；匹配的证据记录也算通过。移除工作树。然后删除分支。在移除工作树之前删除分支会失败。在工作树内部移除工作树会失败。
8. PR 和保留路径会保留工作树，因为用户还需要继续处理。对于丢弃路径，等用户输入“discard”后再操作。在命名分支工作树中，从主检出移除工作树。如果工作树中有未提交的工作，使用 git worktree remove --force。在普通检出中，使用 git switch --discard-changes <base> 切换到基分支。未跟踪文件会保留，并须告知用户这些文件的名称。两种情况下，之后都使用 git branch -D 删除分支。远程上的分支副本会保留，除非用户另有要求。

规则：

• 绝不强制推送，也绝不修改已发布的提交。不要使用 --no-verify，也不要在工作区有未提交更改时使用 reset --hard，除非用户明确要求。
• 绝不删除用户未要求删除的规范。沉默不代表同意。用户没有回复时，保留该规范。
• 只移除已合并分支对应的工作区。其他工作区一律保留，包括子代理运行时保留的工作区。创建这类工作区的工具负责将其移除。移除后运行 git worktree prune。
• 未经测试，绝不合并。合并后的结果必须运行测试，除非其树哈希与证据记录一致。快进合并与记录一致。分支分歧后再进行的合并绝不与记录一致。
• 按意图逐个代码块解决合并冲突。追溯双方内容的来源。--abort 不算解决方案。