start-acceptance

受け入れテストを開始する

ユーザーが作業を試そうとしています。あなたには、確認してもらうためのチェックリストと、今回のセッションが終わっても残る、ユーザーが見つけたことの記録という2つのものを用意する責任があります。 チェックリストは docs/<feature>/ACCEPTANCE.md です。記録は、異なるフィルターを適用する2か所に残します。チェック項目の横に記載する判定にはすべてを残し、docs/acceptances/ATTENTION.<feature>.md には、体系的な問題かもしれないものだけを残します。2つ目のファイルは一時保管場所です。その候補をユーザーとともに、ユーザー自身の言葉で docs/acceptances/ATTENTION.md に昇格させるのは、end-acceptance の役割です。これは、構想、計画、実装、レビューを行うすべてのスキルが読む、プロジェクト全体の注意事項リストです。このセッションから ATTENTION.md に書き込むことは絶対にしないでください。

決めるのはユーザーです。 受け入れを判断するのはユーザーです。修正は、決着をつけるべき意見の相違ではありません。計画または実装についての証拠であり、あなたの役目はどちらなのかを見極めることです。推奨し、記録したうえで、今すぐ修正するか、先送りするか、取り下げるかはユーザーに選んでもらいます。

チェックリストを見つけるか、作成する

1. 対象の機能を特定します。 引数、ブランチ、最新の EXECUTION.md、または計画用フォルダー（プロジェクトで別の場所を使っていない限り docs/<feature>/）から判断します。明らかでなければ、最有力の推測を先に示して、質問を1つだけします。
2. ACCEPTANCE.md がある場合は、 読んで、ツリーと照らし合わせて確認します。作成時点以降の git log を確認してください。その後にマージされた作業はチェックリストで扱われていない可能性があります。影響を受けるチェック項目を伝え、すでに確認した内容を書き換えるのではなく、セクションを追加します。その後、ユーザーにチェックリストを案内します。各セクションにつき1行で所要時間を示し、どこから始めるかを伝えてください。
3. 存在しない場合は、 write-acceptance を使って、実際に変更された内容から作成します。ブランチの git log とメインの統合ブランチとの差分（またはリリース、あるいはユーザーが指定したコミット以降の差分）、EXECUTION.md、最終ドキュメントがあればそれらを確認してください。冒頭では、対象範囲についてのあなたの見立て、つまり、これまでできなかったことで今できるようになったことと、そのテスト方法を伝え、ユーザーが始める前に対象範囲を確認してもらいます。対象範囲を間違えたチェックリストは、ユーザーのセッションを無駄にします。正確さを保てる範囲で、できるだけ短くしてください。
4. 存在する場合は docs/acceptances/ATTENTION.md を読み、以前の機能から未解決の ATTENTION.<other>.md も確認します。この機能に該当する項目はすべて、チェックリストに同じ項目がまだなければ、追加すべきチェックです。受け入れテストで以前に見つかった問題は、最初に再確認すべき項目です。
5. 準備ができたことを伝えます。ユーザーには、作業を進めながらメモ、スクリーンショット、修正内容を送ってもらいます。記録はあなたが保持します。

記録 — チェック項目の隣に

判定結果は、ACCEPTANCE.md 自体の、日付付きの ## Results 見出しの下に記録してください（プロジェクトのチェックリストに結果欄がある場合は、その欄に記録してください）。そうすれば、終了時のスキルで各判定結果を対応するチェック項目の隣から確認できます。ユーザーから何か送られてきたら、次のように対応してください。

• チェック項目と照合します。 該当する項目がなければ、それはリストに関する指摘です。チェック項目を追加してから、その項目に対する判定結果を記録します。
• スクリーンショットは自分で確認します。 期待される観察結果と照らし合わせて、見えたものを伝えます。ユーザーが今見せてくれたものを説明するよう求めてはいけません。
• 分類します。 記録を振り分けられるよう、次のいずれか一語で記録します。pass（合格）、bug（計画どおりに実装されたが、動作しない）、missed requirement（誰も計画していなかったが、ユーザーが期待している）、design error（計画どおりに実装されたが、計画自体が間違っていた）、polish（文言、余白、デフォルト設定）、question（ユーザーにしか判断できない）。
• 記録します。 チェック項目 ID、判定結果、ユーザーの言葉、自分の解釈、確認したプラットフォームまたはデバイス、対応内容を記録します。
• 対応します。 原因が明確な小さなバグは、fix-bug を使って今すぐ修正し、その旨を伝えて、コミットハッシュを記録に記載します。製品としての判断が必要なものや、影響範囲が広いものは、まず推奨案を示して質問を一つだけ投げかけます。セッション中に判断してはいけません。セッションの範囲を超えるものは、終了時のスキルが記録する質問ログまたは V2 の改訂に、時間を置いてからでも再開できるだけの情報を添えて引き継ぎます。チャットだけに残してはいけません。
• 訂正に反論して退けてはいけません。 ユーザーにとって間違っているなら、それは間違いです。なぜ見逃されたのか、設計、計画、実装、レビューのどの段階に原因があったのかを特定します。それが候補ファイルに必要な情報です。
• テストスイートを実行してはいけません。 時間がかかりすぎますし、ユーザーはアプリを開いた状態で待っています。セッション中に修正した場合は、対象を絞ったテストを一つだけ実行してください。実行に数秒しかかからない場合に限ります。それ以上は実行しません。フルテストスイート、lint、型チェックは、end-acceptance で一度だけ実行します。修正がそれ以上検証されていないことを記録に明記し、テスト済みだと誤解されないようにしてください。

候補 — docs/acceptances/ATTENTION.<feature>.md

どんな小さなことも、対応するチェック項目の隣に記録してください。このファイルには、次の機能にも影響する可能性があるものを記録します。個別の事例ではなく、パターンです。 指摘がパターンかもしれないと判断したら、セッションの終了まで待たず、すぐに候補として記録してください。終了時には判断に至った経緯が失われているからです。次のいずれかに当てはまる指摘は候補です。

• 過去にも発生している — 判断する前に、この機能と以前の機能の記録を検索します。
• この機能の複数箇所で発生している。
• 個別の事例ではなく、ある種の事例全般に当てはまる。「空の状態が仕様化されていない」「2 台目のデバイスのケースがテストされていない」「ショートカットが Windows 向けの表記になっている」などです。「保存ボタンがグレーだった」のような個別の事例は該当しません。
• いずれかの段階で何かが省略されたため、見逃された。設計時に失敗ケースが扱われていなかった、計画に受け入れ条件がなかった、レビューで確認されなかった、などです。

判断に迷ったら、疑問点を明記したうえで候補として記録してください。終了時に候補を一つ削除するのは簡単ですが、教訓が失われると取り戻すのは困難です。

候補はそれぞれ、短い項目として記録します。見出しにはパターンを一行で記載し、上記のどの基準に該当するかを一文で説明し、該当したチェック項目 ID と日付、見逃しを防ぐべきだった段階（設計方針の策定、設計、計画、実装、レビュー、受け入れ確認）、そして 代わりに何をするか の草案を記載します。何をすれば検出できるか、そのチェック項目または質問を記載してください。10 行を超える長さにはしません。最初の候補ができたらファイルを作成し、この機能の候補リストであり、終了時の受け入れ確認で整理されることを一行で明記します。

既存の ATTENTION.md の項目に該当する候補もここに記録し、「extends: 」と明記します。そうすれば、終了時の受け入れ確認でその項目の記録を拡充できます。

セッションの終了

ユーザーが完了したと伝えた場合、またはメッセージの送信をやめた場合：

• 1画面に収まるように、合格・不合格・未実行のチェック、コミットした修正とそのハッシュ、引き継いだものとその場所、作成した候補を報告します。
• 未実行のチェックも一覧に残し、未実行であることを明記します。 close-plan と close-roadmap ではチェックを1つずつ確認して一覧から除外します。この段階では除外しません。
• テストスイートは実行されていません。そのことを伝えます。end-acceptance で実行します。
• commit-changes を使って記録と候補ファイルをコミットします。コミットメッセージを提示し、承認を得てからコミットします。プッシュは決して行いません。
• 次のステップは end-acceptance であると伝え、ユーザーに時間があれば今すぐ実行することを提案します。候補は、実行されるまでは教訓ではありません。