tracer-implement

实施

以最小的仓库特定变更交付约定的行为：简短计划并获批 → 实施 → 审查 → 必要时修复 → 验证并报告。在功能分支上停止，不合并、不创建 PR，也不调用其他审查工作流。使用 /tracer-autopilot 完成交付，直到选择结束分支的方式。

范围与简洁性

验收要求和用户明确作出的决定具有约束力。规划器生成的代码、类边界和机制都只是建议：如果现有命令或库能满足相同要求，就应简化方案。记录变更后的做法；只有在变更会影响验收要求、明确决定或重要安全限制时才询问。

在引入用户未明确选择的自定义解析、通用进程运行器、权限评估器、并发保证或持久化恢复机制之前，先说明具体需求和更简单的替代方案，然后再询问。安全重跑本身并不意味着需要并发执行或自动崩溃恢复。保留必要的数据和安全防护；如需权衡，应明确说明，不要悄悄削弱防护。

对于紧密相关的变更，默认使用一个实施上下文，通常由控制器本身承担。多个文件或提交并不意味着需要多个 Agent。仅在某项有明确名称的调查或可独立实施的工作单元所带来的收益超过交接成本时才委派。后续工作复用其上下文。辅助程序只返回结果，不再生成其他 Agent。

1. 工作区与证据计划

1. 检查分支和工作树。留在现有功能分支上。在 main 或 master 上时，遵循 /tracer-worktrees；如果处于分离 HEAD 或所有权不明确的情况，则询问。保留无关变更。
2. 写入工作流产物前，确保 .tracer/ 已被忽略；如果需要新增忽略规则，应先提交该规则，再记录基线。
3. 全新运行时，将起始 SHA 记录到 .tracer/implement/progress.md。恢复运行时，读取该记录，并在继续未完成步骤之前，根据 Git 核实其中的范围、基线、提交、运行中的工作进程和已保存报告。恢复现有工作，不要从头开始。遇到无效基线或无法解释的变更时，应询问。
4. 选择能够证明变更行为和重要失败路径的最少检查。条件允许时，先运行相关现有测试作为基线。无关测试套件失败不是需要处理的任务；应报告该情况。若基线失败导致无法评估本次变更，则需要澄清。

默认进行有针对性的测试。只有在仓库策略要求、用户提出要求或影响足够重大时，才运行完整测试套件或广泛类型检查；并说明这样做的理由。否则应报告，广泛验证将交由 CI 或用户执行。没有现有测试的新功能需要的是失败的验收测试，而不是整个仓库的基线测试。

记录应简洁，包括：范围、不可变基线、已批准计划、实施提交／上下文、审查与修复状态、已检查的 HEAD／工作树、证据、顾虑和结果。委派前标记工作正在进行，并保存工作进程 ID。完成的审查／修复预算在恢复运行和笼统的“继续”消息后仍然有效。

**完成条件：**已知晓工作区、恢复位置、基线和适度的验证方案。

2. 简要计划并获得批准

编写 .tracer/implement/plan.md，通常为每项连贯行为列出几个要点：

# <Feature> Task Plan

**Goal:** observable outcome.
**Source:** request, ticket, or spec.
**Acceptance and limits:** required behavior and material safety boundaries.
**Approach:** existing commands/modules to reuse; proposed new mechanisms.
**Verification:** focused commands and the behavior they establish.

### Task 1: <coherent behavior>
- Files: exact affected paths.
- Change: smallest approach; only interfaces needed to coordinate work.
- Check: observable success and material failure behavior.

一项任务也可以。按连贯行为对任务分组，而不是按框架层划分。实施时再编写代码，不要在计划中预先编写测试和实现。解决会改变验收标准的歧义；普通且可逆的细节留待实施时决定。

说明目标、方案、任务顺序、是否委派以及检查。明确指出自定义基础设施和安全／恢复保障：任务名称本身不代表架构已获批准。说明只进行一次审查，最多进行一次整合修复；若进行了修复，则只进行一次针对修正内容的复查。等待批准并记录。

**完成标准：**用户已批准实际方案和验证范围，而不只是任务数量。

3. 实施

在同一上下文中按计划开展工作。针对新增或修正的行为，使用聚焦的红／绿测试，并酌情运行现有检查；仅涉及文档的更改需要相关验证，无需凭空设计运行时测试。测试可观察到的要求和重要失败路径，而不是每一种推测出来的变体。如果能以较低成本覆盖确实不同的行为，可添加参数化用例。

优先使用现有设施，而不是引入新的抽象。如果方案开始需要远超已批准范围的配套机制，请先停下来并提出更精简的替代方案，再继续构建。不要做完过度设计后才报告顾虑。

按照仓库惯例提交连贯的更改。自行检查一次更改后的行为和范围；修复重要缺陷，并将可选的强化措施记录为关注事项。在台账中保存提交记录和聚焦检查结果。

如果确有委派的理由，使用 scripts/task-brief 提取相关任务，并使用 implementer-prompt.md。除任务简报外，还要一并传达原始验收要求和限制。核验返回的差异、提交和证据；仅有报告并不能证明工作已完成。划分任务边界不代表必须启用新 Agent。

**完成标准：**已实现约定的行为，聚焦检查均通过，且已记录实施证据。

4. 审查和可选修复

固定当前 HEAD，并针对完整的已约定范围运行一次 scripts/review-package BASE HEAD。使用 ticket-reviewer-prompt.md 进行一次审查，最好由一位独立的只读审查者完成；如果无法委派或委派不合适，则在内部审查。

只有在存在可触发条件、违反的要求和当前后果时，才接受问题：行为不正确、安全问题／数据丢失、静默失败，或测试无法发现所需行为已损坏。将润色和推测性加固记录为关注事项，而非工作任务。对于与已约定要求存在重大冲突的情况，请提出询问。将审查结果和处置记录保存到 .tracer/implement/review-1.md。

• **没有接受的修复：**完成验证并汇报。无需进行第二次审查，也无需收尾验证 Agent。
• **有接受的修复：**使用 fixer-prompt.md 在一次修复过程中更正完整的已接受问题清单，最好在现有实现上下文中完成。将问题 ID、改动和针对性结果保存到 .tracer/implement/repair-report.md。如果代码有改动，仅重新检查修正和受影响的行为，最好在原审查者的上下文中完成，并将结果保存到 .tracer/implement/review-2.md。如果所有修复均受阻且没有任何改动，则汇报“需要关注”，不必进行形式化复查。

预算涵盖完整的已约定范围，包括委派和内部工作：一次初始审查、最多一次修复，以及在进行修复后一次仅检查修正内容的复查。协助者不得启动审查或修复流程。复查后，汇报未解决的工作并停止；只有用户明确授权，才能扩大预算。关注事项不会转变为新的实现任务。

**完成条件：**审查问题均已处置，且任何修复都已进行仅针对修正内容的复查；或者已记录未解决的工作。

5. 最终证据和报告

针对最终 HEAD 和已跟踪的树状态验证已约定的检查。如果状态未变，复用已完成的证据；发生改动后，重新运行受影响的检查。记录命令、实际结果和无法进行的检查。针对性测试通过，不代表完整测试套件已运行。

报告目标、提交、审查结果（以及复查或跳过状态）、修正内容、推迟处理的关注事项、验证限制，以及保留的分支。使用以下状态：

• **已实现：**所需行为已通过验证，且不再有可采取行动的问题或关注事项。
• **已实现，但存在关注事项：**所需行为已通过验证；仅剩非阻塞的关注事项。
• **需要关注：**仍有任务、必要检查、可采取行动的问题或重大范围决策受阻或未验证。

将结果保存到台账并结束。不意味着需要进行其他审计、证明流程或分支收尾。