end-acceptance

受け入れテストの完了

docs/acceptances/ATTENTION.md は、形作り、計画、構築、レビューを行うすべてのスキルが最初に読みます。ここに書かれている内容がすべて実際のパターンであり、適切な段階にいるエージェントが何を確認すべきか分かるほど正確に記述されている間だけ、役に立ちます。そのため、受け入れセッション中にこのファイルへ書き込むことはありません。候補は docs/acceptances/ATTENTION.<feature>.md に保留し、ここで言葉選びも含めて、ユーザーと一つずつ決定します。

決めるのはユーザーであり、言葉を選ぶのもユーザーです。 あなたは提案しますが、自分の言葉で候補を昇格させることはありません。ユーザーが途中で離れた場合、未決定の候補は、あなたの提案を添えてフィーチャーファイルに残し、セッションはそこで終了します。

未処理の候補を確認する

1. docs/acceptances/ATTENTION.*.md を一覧表示します。すべての未処理候補ファイル、またはユーザーが指定したファイルを確認します。該当するものがなければ、その旨を伝えて終了します。
2. 各ファイルについて、どのフィーチャーのものか、候補がいつ記録されたか、そのフィーチャーの受け入れが完了しているかを伝えます。docs/<feature>/ACCEPTANCE.md のチェック項目の横にある結果を読みます。チェックがまだ実行されていない場合は、その旨を伝え、候補を今決めるか、セッションの残りの間はファイルを未処理のままにするか尋ねます。
3. 存在する場合は、まず ATTENTION.md を最初から最後まで読みます。既存の内容との照合が必要であり、新しい項目も同じグループ分けと文体にする必要があります。まだ存在しない場合は、2 行のヘッダーを付けて作成します。内容は、このファイルの役割と、形作り、計画、構築、レビューを行うすべてのスキルが読むことです。

テスト一式を一度実行する

受け入れセッションではテストスイートを実行していません。人を待たせながら実行するには遅すぎるためです。そのため、セッション終了時点のツリーは未検証です。何かを決定する前に、今すぐプロジェクトのテストスイート全体、リント、型チェックを一度実行します。失敗は発見事項です。原因が小さく明確な場合は fix-bug で修正し、それ以外の場合は、確認できた内容とともに質問ログまたは V2 の改訂に引き継ぎます。レポートには実行した内容と結果を記載します。また、テストが失敗しているツリー上で教訓を昇格させる場合は、レポートにも失敗していることを記載します。

比較する

何かを尋ねる前に、すべての候補を確認し、それぞれを次の 3 つのいずれかに分類します。質問を始める前に、セッション全体の概要がユーザーに分かるよう、1 行ずつ 1 つの表にまとめます。

• すでに網羅済み — 既存の項目に記載されています。その項目の 確認箇所 を増やします。候補によって項目の表現を明確にできる場合は、それを提案します。
• 新規 — ATTENTION.md に該当する内容がありません。候補がどの体系的テストを通過するか（以前にも発生した、複数の箇所で発生した、個別の事例ではなく一連のケースである、ある段階で見逃された）と、どの段階で検出すべきかを伝えます。
• 体系的ではないと考える — パターンではなく、個別の事象です。その理由も伝えます。ユーザーが異なる見解を示すこともあります。

「新規」とする前に検索してください。同じ教訓が別の表現ですでに記載されていることはよくあります。同じパターンの項目が 2 つあると、ファイルが読まれなくなります。

一度に 1 つずつ尋ねる

新規または体系的ではない候補ごとに、また、表現を変更したいすでに網羅済みの候補ごとに、質問を 1 つします。

• 記録内の言葉で候補を示し、該当するチェック ID を伝えます。
• 体系的に見える理由、またはそうでない理由を伝えます。
• まず、あなたの推奨を示します。昇格、既存項目への追加、または削除のいずれかです。
• ATTENTION.md に記載する場合の正確な文言を示します。該当する段階、パターンを示す見出し、代わりに何をするかを 1～2 文で記し、確認箇所も含めます。

ユーザーが文言を承認するか、変更します。決定した内容を、一語一句そのまま記載します。言い換えてはいけません。質問 1 つにつき決定 1 つです。未解決の質問を残したまま先に進んではいけません。既存の項目の文言を変えずに 確認箇所 だけ増やす場合は、質問する必要はありません。追加したことを伝えます。

記述と廃止

• ATTENTION.md を更新する：新しい項目は該当する段階の下に追加し、既存の項目はその場で拡張します。統合し、重複させないでください。セッションで項目が古くなったと分かった場合（原則、スキルチェック、またはテストになった場合や、長い間問題を起こしていない場合）は、独立した質問として廃止を提案してください。
• そのファイル内のすべての候補が決着したら、ATTENTION.<feature>.md を削除する。Git が保持します。取り下げた候補はほかの場所に引き継がれません。チェックの横にある判定にすでに記録されているためです。未決定の候補が残っている場合は、そのファイルを残し、提案内容を添えたその候補だけを記載します。
• commit-changes を使ってコミットする：昇格、拡張、取り下げ、廃止した内容と、クローズした機能ファイルを記載します。コミットメッセージを提示し、承認を得てからコミットしてください。プッシュはしないでください。
• 1 画面に収まる形で報告します。機能ファイルごとに、各候補とその結果、および以前にはなかった内容として現在 ATTENTION.md に記載されているものを示してください。