スパイクタスクは何をしますか？

1つの質問に、スパイクのタイムボックス内で、意思決定ができるだけの十分な回答をします。成果物は意思決定記録であり、マージされたコードではありません。

入力

$ARGUMENTS

チケット、必須: トラッカーキー（例: ENG-130）またはローカルID（例: T-03）。タイプがspikeのチケットであること。スパイクでない場合は停止し、/implement-taskを参照してください。
--tasks <file>: ローカルのタスクファイル。指定されない場合、プロジェクトのローカルでgit管理外のRFCフォルダ（例: .rfcs/）、次にdocs/rfcs/内から、チケットを含む*.tasks.mdファイルを見つけます。
--branch <name>: プロトタイプ用のブランチ名（必要な場合）。それ以外の場合は、/implement-taskと同じ命名ルールに従い、<username>/<project-slug>/spike-<task-branch>とします。
--unattended: オーケストレーターによって開始された場合。誰も質問に答えられません。質問はせず、質問が必要な場合はレポートで説明して停止します。自身のワークツリーで作業します。

チケットが公開されている場合はトラッカーから読み取り（トラッカーが内容の信頼できる情報源です）、それ以外の場合はタスクファイルから読み取ります。ローカルのRFCファイルとタスクファイルはメインプロジェクトフォルダにのみ存在します。ワークツリーにいる場合は、git worktree list（最初のエントリ）を使用してそれを見つけ、絶対パスで読み取ります。メインフォルダ内でファイルを編集したりgitコマンドを実行したりしないでください。ただし、以下に説明する意思決定記録の作成は除きます。

1. 質問を明確にする

情報収集の前に、以下を書き留めます:

質問: 答えが1文で明確になるもの（「PostgresのLISTEN/NOTIFYが私たちのインスタンスサイズで毎秒2000イベントを処理できるか？」であって、「イベント処理について調査する」ではない）。
それが解放する決定: どのチケットがそれに依存しているか。
選択肢: 決定する対象のオプション。「何もしない」や、妥当な場合の最も単純なオプションも含む。
決定基準: 可能な場合はRFCのDRIVEセクションから取得（制約、価値観、必須の成果）。証拠は、チームがすでに重要だと合意した内容に照らして判断されます。
タイムボックス: チケットから取得（デフォルト: 約1日の作業）。「完了」とは、質問に回答されたか、タイムボックスを使い切ったかのいずれか早い方を意味します。

チケットが不明瞭で質問を明確にできない場合は、停止してblockedを報告し、回答が必要な質問を列挙します。

2. 最も安価な方法から証拠を収集する

証拠が質問を解決した時点で停止します。完全性を追求するために調査を続けないでください。

コードベース: 既存のパターン、制約、過去の試行、関連箇所のコメントと履歴（該当パスのgit log）。
一次情報源: 関連するライブラリやサービスの公式ドキュメント、チェンジログ、リリースノート、課題トラッカー。ブログ記事よりもこれらを優先します。deep-researchスキルが利用可能で、広範な外部調査が必要な場合はそれを使用します。
計測: 読むだけでは解決できない場合（パフォーマンス、互換性、「このAPIは本当にこのように動作するのか」）、スパイクブランチ上で、最新のmainブランチから、質問に回答する最小のプロトタイプまたはベンチマークを構築します。これは証拠を生成するために存在します。計測に必要な以上のテストは不要、洗練も不要、マージされることはありません。証拠が再現可能になるようにブランチをプッシュしますが、PRは作成しません。

各情報をどのように知ったかを記録します: 計測済み（実際に実行した）、文書化済み（一次情報源がそう述べている）、推測（推論）。リンクとファイルパスを引用します。

3. 推奨事項を決定する

証拠を使用して、各オプションを決定基準に対してスコアリングします。
信頼度と共に1つのオプションを推奨します: 高（計測済みまたは十分に文書化されている）、中（文書化されているが私たちのコンテキストではテストされていない）、低（ほとんど推測）。
信頼度が低い場合は、最も簡単に元に戻せるオプションを優先し、どのような兆候があれば推奨を変更するかを述べます。
質問に回答する前にタイムボックスが切れた場合は、その旨を明確に述べます。既知の情報を報告し、次に取るべき最小のステップ（より狭いフォローアップスパイク、または進めるための元に戻せるデフォルト）を推奨します。

4. バックログの変更を提案する

決定は通常、計画を変更します。適用はせず、提案のみを行います:

追加するチケット: タスクファイルと同じ形式（タイトル、範囲、ファイル、受け入れ基準、依存関係）。各1ストーリーポイント。
変更するチケット: （範囲、基準、または依存関係）および削除するチケット。それぞれ理由を添えます。
更新が必要なRFCセクション。

5. 記録を作成し報告する

templates/decision.mdを使用して意思決定記録を作成し、メインプロジェクトフォルダ（そこで作成する唯一のファイル）のタスクファイルの隣に<rfc-name>.<ticket-id>.decision.mdとして配置します。RFCと同様に、ローカルで追跡されないファイルです。
チケットが公開されている場合は、トラッカーの課題に短いサマリーを投稿します。質問、推奨事項と信頼度、および主要な証拠を3〜5行で、提案中、承認待ちと明確にマークします。
ユーザーと直接作業している場合は、タスクファイル内のチケットのステータスをdecision-proposedに設定し、推奨事項を説明し、承認、別のオプションの選択、またはスパイクの延長を依頼します。 unattended の場合は、ステータスはオーケストレーターに任せます。
以下のレポートで終了します:

RESULT: decision-proposed | inconclusive | blocked
TICKET: <ローカルID> / <トラッカーキーまたは

スパイクタスク