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. 指摘事項を分類します。機械的な指摘は、欠陥または規約違反を指摘し、明確な修正方法が 1 つあるものです。修正を適用してください。判断が必要な指摘は、トレードオフまたはスタイル上の判断に関するものです。コードはそのままにし、理由を 1 行で記載してください。
4. テストスイート全体を 1 回実行します。
5. 修正と、コミットメッセージ本文の最後のセクションとしてのコードレビュー記録を含めるようにコミットを amend します。ブランチはまだ push されていないため、共有済みのものを書き換えることはありません。

記録はレビューの唯一の情報源です。終了メッセージにその内容を再掲し、open-pr が PR にコピーします。形式と文字数上限は同じです。指摘ごとに 1 行で、file:line を記載し、72 文字で折り返します。見出しは Code review の 1 行だけにします。コミットのクリーンアップで # から始まる行が削除される場合があるためです。

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 と記載します。

実行を終える際は、次の 4 部構成の自己完結したメッセージを、この順序で 1 つ作成します。コミット済みのコードレビュー記録、手動テストスクリプト、Next actions、Least confident です。読者に必要な情報をすべて、メッセージ内に書き出してください。レビューの実行中など、実行の早い段階で作成したスクリプトがあれば、ここでも全文を書き出してください。

手動テストスクリプトは、アプリを片手に、1 行を読んで実行し、結果を確認して次へ進める形式にします。読者が実行する各行にはアクションを 1 つだけ記載します。実行前に行を分割する必要があってはいけません。

• 開始画面に到達するための操作を、1 つの箇条書きにつき 1 操作で記載した Setup リストから始めます。
• すべての手順に番号を付けます。各手順は、単独で実行できる操作を 1 行に記載し、その下に、成功を示す確認可能な結果を記載したインデント付きの Expect: 行を続けます。動詞が 2 つある行、then を含む行、または and で操作をつないでいる行は 2 行に分けます。これは Setup の箇条書きにも適用されます。
• 1 つの操作によって複数の変更が起きる場合は、操作は 1 つのままにして、それぞれの結果を個別の 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

Next actions には、変更を機能させるためにユーザーが今、自分で行う必要のある作業を記載します。設定するシークレット、追加する環境変数、実行するマイグレーション、インストールする依存関係、再起動するサービス、作成またはマージする PR などです。場所と正確な値またはコマンドを明記し、番号付きの各行には操作を 1 つだけ記載します。ユーザー側で必要な作業がない場合は、確認を省略したのではなく一覧を確認済みだと分かるよう、セクションを Next actions: none とします。 最も確信が低い点には、最も信頼できない作業部分を記載します。テストでカバーされていないエッジケース、仕様に記載がなくコードから推測した挙動、型チェッカーでしか検証されていない変更などです。番号付きの行ごとに1項目を記載し、何か、確信度が低い理由、ユーザーが確認する方法を述べます。誤っていた場合に最も影響が大きいものを先に並べます。すべての作業には最も弱い部分があるため、このセクションには必ず1項目以上記載します。

形式：

## 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 のマークが付いていること、締めくくりのメッセージに4つすべての要素が含まれていること、ユーザーに表示されるすべての変更に見出しがあること、対応した各行（Setup の箇条書きを含む）に動詞が1つだけあること、各ステップに独自の Expect: 行があること、そして 最も確信が低い点に少なくとも1項目が記載されていることをもって完了とします。