AITM 如何将完成的工作合并到 dev，如何对合并后的测试失败进行向前修复而不是回滚，以及如何验证 Task 只触及了它应当触及的内容。

合并、合并后修复与 Scope Gate

合并的工作方式

每个 Task 都在自己的 git 分支/Worktree 中运行。当 Pipeline 完成（实现、 审查、测试全部通过）后，Task 会进入 AITM 的 Merge queue—一个串行化的 队列，使并发的 Task 绝不会同时合并到 dev 而相互 覆盖对方的更改。

  • 自动合并触发。启用了 autoMergeDev 的 Task 在其 Pipeline 完成后 会自动合并到 dev—没有手动批准步骤，因此 完成的工作会持续落地，而不是堆积着等待人来点击合并。
  • 合并前构建关卡。Task 的分支会先与当前的 dev 同步，然后按合并之后的样子进行构建和类型检查。如果检查为红，修复 Agent 有有限次数的尝试机会；dev 上已有的错误不会算到该 Task 头上。如果关卡仍为红，该 Task 不会被合并，并以 conflict 结束，同时附上构建输出。
  • 冲突处理。如果 Task 的分支与已经落地到 dev 的内容冲突，AITM 会用不同的策略重试合并，然后将冲突文件交给 AI 冲突解决器，由它合并双方的更改并重新运行构建关卡。处于 conflict 状态等待的 Task 会被自动重新检查；如果原因在此期间已经消失，它会自我修复并继续进行合并。
  • 受控地合并到 dev。合并从队列中逐个进行， 因此 dev 绝不会处于合并到一半的状态。合并不是一个 Pipeline 步骤：Task 会显示为 finished 并带有 Finalizing… 标记，待合并落地后变为 archived。当某个 Task 停留在 conflict 状态时，同一标签页中排队的其他 Task 会在其后等待—因此值得尽快解决。
一个已完成的 Task 正在被收尾并合并
一个已完成的 Task 正在被收尾并合并到 dev。

合并后的错误检测与修复

Task 的分支合并到 dev 之后，AITM 会针对 dev 的新状态重新运行受影响的测试。 如果这些测试现在失败，默认的处理方式 是不回滚该合并。

示例：某个 Task 向共享模型添加了一个新字段。它顺利合并， 其自身的测试也通过了。但另一个已在不同分支上进行中的 Task 依赖于 该模型原有的结构—两者都落地之后，一个共享的集成测试开始失败。AITM 不会回滚 任何一次合并（那样也会丢掉每项更改中互不相关的、正常工作的那一半），而是：

  1. 找出究竟哪些文件/测试在失败，以及是哪个 Task 的 更改造成的。
  2. 在分支上向前修复—创建一个纠正性 Task，仅针对 失败的区域，基于 dev 的当前状态工作（而不是基于任何一个 原始 Task 的 diff）。
  3. 在该修复被允许再次接近 dev 之前，对其进行独立地重新测试。
  4. 通过与其他 Task 相同的队列合并该修复。

这种“向前修复”的理念避免了连锁性破坏：在其他工作已经建立在某次合并之上后再回滚它， 会迫使一连串进一步的回滚。在其自己的分支上就地修复实际的故障， 可将影响范围限制在所发现的那一个问题上。

Task 范围评估（Business Scope Gate）

每个 Task 都会预先声明它计划触及哪些文件。Task 完成时， Business Scope Gate 会将它实际更改的文件与该声明进行比较。

  • 超出 Scope是指被更改的文件从未被声明，且与 Task 所述目标 没有合理的关联—例如，一个关于结账页面的 Task 同时编辑了不相关的管理设置文件。
  • Scope 修订。有时触及未声明的文件是合理的 —某个共享类型必须更改，或某个常量位于相邻的文件中。这种情况下， Task 会为额外的文件记录一份简短而明确的理由（“scope amendment”）， 而不是悄悄越界。有正当理由的修订会被接受；没有说明的 额外文件则不会。
  • 阻断性与建议性违规。并非每个未声明的文件都以相同方式对待：
    • 阻断性—被更改的文件与该 Task 确实无关 （属于不同的功能区域、没有共享依赖、也没有给出理由）。这会阻止 合并，直到问题解决。
    • 建议性—被更改的文件与声明的 Scope 位于同一目录/模块， 且有合理的关联（例如同一功能文件夹中的同级文件）。这会被标记以供审查，但本身 不会阻止合并。

什么会成为 Bug，什么会成为新 Task

当审查步骤发现了超出当前 diff 的问题时，AITM 会在两种 结果之间作出决定：

  • 当发现的问题是阻断性的 Scope 违规， 或是与 Task 本应完成的工作无关的真实缺陷时，它成为 Bug—即 已经存在的故障，需要独立于当前 Task 结果的、自己的修复周期。
  • 当发现的问题是一项改进、一个锦上添花的优化，或是在处理 其他事情时浮现的、合理但超出 Scope 的想法时，它成为新的（后续）Task— 它会以自己的方式进入队列，而不是扩大当前 Task 的 Scope。

这种划分使每个 Task 的 diff 始终专注于被要求完成的事情，同时 仍然记录审查者沿途注意到的一切—审查期间观察到的内容 不会被悄悄丢弃，也不会被夹带进一个不相关的更改中。

Task 失败并需要人工介入时

并非每种失败都能自动恢复。AITM 的 Watchdog 和自我修复机制可以自行处理 基础设施方面的小故障以及常规的编译/测试失败，但有些错误是 终结性的—它们需要人来决定，而不是再重试一次。在以下情况下，Task 会以 终结性的 failed 状态结束：

  • 配置有误。无效的 API 密钥、错误的设置、格式错误的 JSON—代码无法修复一个损坏的环境。
  • AI 缺少数据。Task 的提示词不完整或含糊不清， 未提供必要的上下文，或需求不够明确。
  • 存在只有用户才能解决的根本性障碍。架构 需要澄清、Scope 存在争议，或第三方服务宕机，需要 明确确认之后才能继续工作。

示例：假设某个 Task 因需求与现有 架构冲突而失败。AITM 无法猜测哪种设计是正确的—需要人来澄清。此时：

  1. 该 Task 被标记为 failed。
  2. 您（与 Claude）在 Chat 或 Brainstorm 中讨论根本原因。
  3. 由您决定：以更清晰的 Scope 重新排队？先提交一个单独的架构设计 Task？ 调整方案？
  4. 然后根据更明确的理解创建新的 Task，或使用更新后的 提示词重新排队。

并非所有失败都是 Bug—许多失败在没有人工 输入的情况下确实无法解决。失败不等于白费功夫—失败运行留下的诊断信息和日志 仍然能准确告诉您问题出在哪里。而且当 Task 失败时，它是 您与 AITM 之间的一个交流点，而不是死胡同。

分支模型

每个由 AITM 管理的项目都遵循相同的双分支发布模型。

  • dev 是默认/集成分支。每个 Pipeline Task 都合并到 dev—完成并通过测试的工作在这里持续落地 （参见上文的 Merge queue）。
  • main 是稳定的发布分支。它只在发布时通过 dev → main 合并进行更新，而不会由单个 Task 更新。
  • 不存在 master 分支。AITM 从不创建也不期待它。
  • 导入的项目可以保留自己的集成分支。如果您接入的项目 已经为其集成分支使用了不同的名称，请通过项目 设置中的 Integration branch 设置（defaultBranch）进行设置，并使用其中的 Verify remote 检查， 确认它能在实际的 git 远程仓库中解析。
  • Docker 发布版中内置的 Gitea 创建的演示仓库以 dev 作为默认分支，开箱即与同一模型保持一致。

如果某个 Task 所在的项目没有可用的 git 远程仓库，Task 会停止并给出可操作的提示， 引导您前往 Project settings → Verify remote，而不是显示 原始的 git 错误。