implement-task

实现任务

从 Spec 文件夹中准确构建一个 Task。Task 文件定义了工作切片、验收标准和 Verification 契约。独立执行负责完整生命周期；由 Roundfix Daemon 分配的工作轮次则交付可直接实现的工作，供 Daemon 执行 Verification 并完成结算。

用户、循环或 Daemon 分配 Task，即表示已授权开始。 立即开始：不要问候、不要询问是否批准计划，也不要等待“开始”指令。只有需求相互矛盾，或独立执行中的 in_progress 状态已过时，才应在实现前暂停。

执行模式

独立执行和 Roundfix Daemon 分配的工作轮次共用相同的 Task 工作切片、Result 和证据要求，但结算责任方不同。

• 在独立执行中，Agent 更新 Task 状态，运行 ## Verification 中的所有命令，根据最新证据结算 Task，并且仅在用户已授权提交时才进行提交。
• 在 Roundfix Daemon 分配的工作轮次中，Daemon 是唯一可以写入 Task 状态的一方。Agent 不得编辑状态、运行声明的 ## Verification 命令、宣称终态判定或提交。Agent 可以运行有针对性的检查，在 ## Result 中记录实现和定向检查证据，并交付可直接实现的工作。随后，Daemon 会在结算前逐字运行完整的声明 Verification。
• 如果 Daemon Verification 命令失败，则在同一 Agent Session 中释放 Verification Capacity，然后进行一轮 Verification Feedback 修复。Agent 修复实现、更新 ## Result，并在适用时运行有针对性的检查，然后再次交付，不得运行声明的 Verification 或结算状态。

对于以 in_progress 状态到达的 Daemon 分配任务，从头开始处理 Task。工作目标锁证明没有 Agent 正在处理该任务。不要询问如何恢复，也不要规范化或结算其状态。

1. 加载

阅读指定的 task_NN.md，然后在独立执行中将任务状态改为 in_progress 之前，运行项目约束预检：

1. 已完成或已归档的旧版 Spec 无需强制补全约束。保持其产物逐字节不变，并停止执行，不要重新执行或改写。
2. 对于活动 Spec，PRD 和所有现有 TechSpec 都必须包含完整的 Project Constraints 章节。每个章节都必须说明标识符策略、身份验证和 HTTP、当前有效 ADR 的义务以及工具授权方，并注明适用或不适用及理由；每一项都必须提供可执行的 docs/agents/ 来源路径。缺少任何条目、理由或来源时，停止执行，且不要更改任务状态。
3. 确定指定任务是否会创建、编辑、重命名、移动或删除仓库工具配置、脚本、忽略文件、插件声明或版本固定项。任务分配、设置审批或通用实现请求均不代表已获得工具授权。
4. 工具任务开始前，必须获得维护者的明确授权，并在 PRD 和所有现有 TechSpec 中列出精确且范围有限的仓库相对文件清单。变更允许列表仅包括这些精确路径以及指定的任务文件本身。若授权缺失或相互冲突，则任务保持待处理状态并停止执行。
5. 在开始工作前运行 git status --short，并记录已有的更改路径。这些路径归用户所有，不能计为本任务的更改。

预检完成后，独立执行时检查 status：

• pending → 将 status: in_progress，然后继续。
• in_progress → 之前的会话可能在任务中途终止。检查工作树和 git 日志中的部分工作，报告检查结果，并询问如何继续，避免重复构建。
• completed / failed → 停止并报告；重新运行需要明确的人为决定。

在 Daemon 分配的轮次中，状态由 Daemon 管理，应继续执行，不要编辑状态。

• 阅读任务 References 中指定的 _prd.md 和 _techspec.md 章节，以及 CONTEXT.md（在代码名称和测试名称中使用其中的词汇）和所有引用的 ADR。
• 如果要求相互矛盾——任务与规范之间，或规范与 ADR 之间——则停止并报告冲突。猜测会把规范缺陷掩盖在实现中。

2. 计划

• 根据 Requirements + Acceptance Criteria 制定检查清单。

• 记录变更前的信号，以证明任务尚未完成——失败的测试、缺失的行为或 404。没有红色起点，就无法证明是你的更改让结果变绿。

• 特征描述任务必须在任务声明的范围内使用真实边界。 当指定任务是特征描述任务时，应测试指定的外部接口，并记录真实对象的实际行为。不要替换成伪造对象、模拟对象、固定数据或推断行为；该记录是下游任务可依赖的边界证据。

  接触边界之前，先确认任务说明了要访问的目标，并确认你访问的正是该目标。只读，不写入；或者使用任务创建的隔离实例。仅使用任务为该目标指定的凭据，遵守取消操作，并且即使任务失败，也要清除你创建的内容。只有任务明确授权相应写入时，才可写入真实边界——记录边界的行为并不意味着有权更改它；无论未授权写入能证明什么，它都不在任务范围内。如果任务未指定目标或边界，停止执行并报告，不要自行选择。

3. 实现

• 严格限定在当前任务范围内。PRD 的非目标和任务范围是边界，而非建议——属于其他任务的工作应记入后续事项，不应纳入此差异。
• 需求中指定的命令（例如生成器或已归属技能的记录命令）属于工作内容，即使验证会运行相同的测试也是如此；不得手动编写其输出。
• 先在 TechSpec 指定的接缝处编写测试（这些接缝已预先约定；新增接缝需获得用户批准）。频繁进行类型检查并运行针对性测试；完整测试套件留到最终检查时运行。
• 只修复根本原因——不得抑制 lint 或类型检查错误、吞掉错误或使用计时技巧。使用变通方案会关闭当前任务并产生一个缺陷。
• 对于获准的工具类任务，每次修改前都要将目标路径与变更许可列表进行比对。绝不编辑 _tasks.md 或任何其他 Task 文件。如果必需路径不在授权范围内，请停止并申请修订 Spec，而不是扩大列表。

4. 独立验证——最终检查

独立执行时，先收集证据，再按以下顺序确定最终状态：

1. 原样运行 Task ## Verification 部分中的每条命令。
2. 当当前执行模式要求提供本地完成证据时，运行仓库的验证流水线（make verify，或本仓库文档中说明的构建、lint、类型检查和测试等效命令）。
3. 逐项检查验收标准：每项都需要本次会话中的最新证据——命令输出、通过的测试名称或观察到的行为。通过的测试套件不能作为其未覆盖标准的证据。

对于每个获准的工具类任务，都要在最后一次编辑后执行一次变更文件后置检查。将已记录的基线与 git status --short 和 git diff --name-only 进行比对，并计入已暂存、未暂存和未跟踪的路径。每个新增变更路径都必须是一个精确授权的路径，或分配给该任务的 Task 文件。如果出现其他路径，不得继续修改；将 status 设为 failed，在 ## Result 中记录范围外路径，并保持工作区不变以便恢复。

范围狭窄的验证不能支撑宽泛的声明。如果诚实地尝试修复根本原因后，任何独立检查仍失败：将 status 设为 failed，在 ## Result 中记录尝试过的内容，并报告失败——调度器可以重试的明确失败，胜过悄无声息的“基本完成”。

5. 独立记录

在任务文件中追加 ## Result 部分：说明发生了哪些变化（描述行为，而非文件列表）、运行的命令及结果、每项验收标准的证据，以及发现的后续事项。勾选证据所支持的子任务和验收标准复选框。将 status 设为 completed。

绝不修改 _tasks.md——它管理的是依赖图结构，而非进度。

6. 独立提交

• 仅当用户明确授权时才提交。
• 仅暂存此任务的文件（先运行 git status --short；无关变更不得纳入）。
• 每个任务仅提交一次，遵循 Conventional Commits 格式，并在提交正文中写入任务 ID 以便追溯（spec: <slug> / task_02）。
• 绝不推送，也绝不从任务中创建 PR——发布是单独且明确授权的操作。

7. Daemon 分配的任务移交

1. 编辑前，阅读已分配的 Task、PRD、TechSpec、CONTEXT.md、当前有效的 ADR，以及限定范围内的上下文路径。
2. 仅实现分配的部分。切勿编辑 _tasks.md、其他 Task 文件，或授权工具白名单之外的路径。
3. 工作期间可按需运行针对性的实现检查，但范围仅限变更涉及的包。不要运行 Task 的 ## Verification 部分、仓库选定的 Verification、增量 Verification 或完整测试套件中的任何命令：Daemon 会在结项时运行已声明的 Verification 和仓库 Verification。
4. 为每项验收标准，在 ## Result 中追加或更新实现内容和针对性检查的证据。不要使用尚未运行的 Daemon Verification 证据。
5. 移交可供后续实现的工作，不要编辑 Task 状态，也不要声称工作已 completed、failed、Verification 已通过、已可提交或已交付。
6. 切勿提交、推送或创建拉取请求。Daemon 会运行已声明的 Verification、写入 Task 的最终状态，并负责提交 Task。

反模式

• 仅凭“应该能用”就标记为 completed——机器会读取状态字段，而不会再次核实。
• 为了通过测试而弱化、跳过或删除失败的测试。
• 顺手修复过程中发现的“其他问题”——那属于后续任务，不在当前范围内。
• 使用本轮会话中较早的陈旧输出重新验证；证据必须晚于最后一次编辑。
• 编辑其他任务的文件或状态。
• 在 Daemon 分配的轮次中运行已声明的 Verification、编辑 Task 状态、声称最终结论或提交。

固定值

credential-assignment Secret Pattern 匹配满足以下条件的值：名称为大写且以 API_KEY、TOKEN、SECRET 或 PASSWORD 结尾；后接赋值符号；值至少包含 20 个字符，且同时包含字母和数字。仅由字母组成或少于 20 个字符的固定值不匹配此模式。 其他 Secret Patterns 仍然适用；测试文件不享有豁免。