工作区选择决定这里问不问你
创建 change 时，你可以继续使用当前目录，也可以让 Comet 创建分支或 worktree。进入 Archive 时，交付方式取决于这次选择：- current 工作区：change 直接在当前分支和目录里完成，归档时不需要选择交付方式。Comet 会展示当前分支和目录，说明归档不做任何 merge、push 或 PR；你确认后直接完成归档。
- branch / worktree 隔离：change 运行在独立的分支和目录里，归档后是否要合并进目标分支、推送到远端或创建 PR，需要由你决定。Comet 会展示实际的 change 分支、目标分支和目录，把下面五个互斥选项作为一次决策提供。
五个交付选项
选择 A–D 时，Comet 用对应参数执行归档命令（
--finish keep|merge|push|pull-request）；选 E 则到此为止。整个决策路径如下：
每种选项执行后的 Git 状态
A–D 都会完成归档，并在 change 分支创建归档提交；区别在于归档提交之后的处理：- A 仅保留工作区：change 分支多一个归档提交，目标分支不变，分支和目录原样保留。本次归档不会移除保留的 worktree。
- B 本地合并：change 分支上的归档提交本地合并进目标分支，远端不受影响。
- C 归档并推送：归档提交随 change 分支一起推送到远端，目标分支不合并、不建 PR。
- D 推送并创建 PR：推送 change 分支后，以目标分支为 base 创建 PR，之后的合并走 PR 流程。
- E 暂缓归档：归档和交付都不执行，Git 侧没有任何改动。
确认门禁：何时需要 --confirmed
归档前是否需要额外一次明确决定，由 native.archive_confirmation 控制，默认是 automatic：
automatic：最终 Verify 通过后，Runtime 可以直接继续完成归档。自动归档不替你决定交付方式——使用 branch 或 worktree 时，你仍要在 A–E 里选一个。required：最终 Verify 通过后，Runtime 会停在最终 Archive 候选上，等你就这一次归档做明确决定。中间修复轮次不会触发这个确认；选择暂不归档也会保留当前 active change。
required 生效时，最终 Archive 候选上会多一道门禁：你明确决定后，用 --confirmed 执行真实归档；--dry-run 只做预览，不要求也不写入最终确认。--confirmed 只在该 change 确实停在等待最终确认的 Archive-ready 时才有意义——中间修复轮次不会触发归档确认；等待期间需求或验收标准被修改，change 会先返回 Shape，旧的验证结果和归档批准不再生效。拿不准时先运行 --dry-run，让 Runtime 返回当前的下一步。