implement-copy

实施用户在规格或工单中描述的工作。

编写代码前，从基准分支创建分支：即这项工作将合并到的分支。docs/agents/branching.md 会说明基准分支及分支命名模式，例如 <type>/<slug> 或 feature/<ticket>-<slug>。根据当前工作填入该模式。

如果该文件不存在，运行 git branch -r 查看可能的集成分支以及现有的命名方式，然后请用户确认基准分支和命名模式，并提出你发现的情况：包含 origin/staging 的仓库通常通过 staging 集成；只有 origin/main 的仓库通常通过 main 集成。将两项信息都写入 docs/agents/branching.md，以便后续运行时读取，而无需再次询问。

git fetch origin
git switch <base> && git pull
git switch -c <the pattern, filled in>

只有在 git status 显示新分支上的工作区干净，且 git merge-base --is-ancestor origin/<base> HEAD 以 0 退出时，才开始编写代码。

尽可能在预先商定的切入点使用 /tdd。

定期运行类型检查和单个测试文件。

code-review 会读取已提交的工作，因此审查前先提交：

1. 将工作提交到当前分支。
2. 以 origin/<base> 为固定点运行 /code-review。
3. 对审查发现进行分类。机械性发现会指出一处缺陷或违规之处，并且有一个明确的修复方案：应用修复。判断性发现涉及权衡或风格选择：保持代码不变，并给出一句理由。
4. 完整运行一次测试套件。
5. 修改提交，使其包含修复，并将代码审查记录作为提交说明的最后一节。该分支尚未推送，因此修改提交不会改写任何共享内容。

审查记录是审查内容的唯一来源：结束消息会重复该记录，open-pr 会将其复制到 PR 中。记录的格式同时限制了长度：每条发现占一行，注明 file:line，每行最多 72 个字符。标题使用普通的 Code review，因为清理提交时可能会删除以 # 开头的行。

Code review

Standards:
- src/timebox/lane.ts:42 — possible Feature Envy in routeEntry — left:
  it reads the tag once; moving it would split the reducer
- src/timebox/lane.ts:80 — Mysterious Name `fn2` — fixed
Spec:
- no findings

Standards: 2 findings, 1 left.
Spec: 0 findings.

每条发现的格式为 file:line — finding — fixed 或 file:line — finding — left: <reason>；每个审查维度都以一行总数结尾。如果审查跳过了 Spec 维度，该维度的列表和总数行都写 no spec available。

运行结束时，用一条自包含的消息按以下顺序包含四个部分：已提交的代码审查记录、手动测试脚本、后续操作和最不确定之处。读者所需的所有信息都要在这条消息中写明。运行过程中较早拟定的脚本（例如审查仍在进行时拟定的脚本）要在此处完整重写。

手动测试脚本要让读者能一边使用应用一边逐行执行：读一行、照做、检查结果，再继续。读者需要执行的每一行都只能包含一个操作，确保无需拆分就能照做。

• 以 Setup 列表开头：列出到达起始屏幕所需的操作，每个项目一个操作。
• 为每个步骤编号。每个步骤独占一行，只包含一个操作；其后缩进一行 Expect:，写明能证明操作成功的可观察结果。含有两个动词、then 或连接操作的 and 的行都应拆成两行；这条要求同样适用于 Setup 项目。
• 当一个操作会改变多项内容时，保留该单一操作，并将每项结果分别列为 Expect: 项目。
• 屏幕上的目标名称应与界面显示完全一致，并加粗；用户输入的文本放在反引号中。
• 为工作中每项面向用户的变更设置标题，让读者能看出一组步骤验证了哪种行为。

格式：

### Routing a Timebox by Tag

Setup:
- Run `npm start`.
- Open the dev client.
- Open the **Session** tab.

1. Tap **Add Cycle**.
   Expect: the **New Cycle** sheet opens.
2. Type `Routed` in the name field.
   Expect: **Save Cycle** is enabled.
3. Tap **Skip Timebox**.
   Expect: a confirmation dialog appears.
4. Tap **Confirm**.
   Expect:
   - the Timebox reads **Ready** with no funnel icon
   - the lane shows every open entry, including untagged ones

后续操作列出用户现在必须手动完成、才能使变更生效的事项：设置密钥、添加环境变量、运行迁移、安装依赖、重启服务、打开或合并 PR。每个编号行只包含一个操作，并注明操作位置以及准确的值或命令。如果无需用户采取任何操作，该部分应写为 Next actions: none，让读者知道列表已经核查过，而不是被跳过。 最不确定项列出你最不信任的工作部分：没有测试覆盖的边缘情况、根据代码推断而规范未明确说明的行为，或仅通过类型检查器验证的更改。每个编号行列出一项，说明具体内容、信心为何较低，以及用户如何检查。按错误时的影响大小排序，影响最大的放在最前。每项工作都有最薄弱的一环，因此此部分至少要有一项。

格式：

## Next actions

1. Add `TIMEBOX_ROUTING_ENABLED=true` to `.env.local`.
2. Run `npm run db:migrate` against the dev database.

## Least confident

1. Untagged entries landing in the lane: inferred from the reducer, the spec is silent; run step 4 with an entry that has no tag.

满足以下条件即算完成：提交说明以代码审查记录结尾，且其中的每项发现都标记为 fixed 或 left；结束消息包含全部四个部分；每项面向用户的更改都有标题；每行已执行的内容（包括 Setup 条目）都只有一个动词；每个步骤都有单独的 Expect: 行；并且 最不确定项 至少列出一项。