next-ticket

next-ticket

ストアを見つけて読み、チケットを1件選びます。ストアはチケット規約（../ticket-up/references/TICKET_CONVENTION.md — 規約がすでにコンテキストにない場合は、読んでください）に従います。また、チケットが取り得るすべての状態と、チケットが行うすべての遷移（選択とそのクレームを含む）は、../ticket-up/references/AUTOMATED_EXECUTION.md → Transitions に記載されています。そのセクションも読んでください。

ストアを見つける。 tickets/store-config.md を読みます — ここには、ストアの場所を示すリポジトリ相対の固定パスが記載されています。会場が GitHub である設定の場合、ストアはそのリポジトリの課題のうち、取り組みの追跡課題の配下にあるものです。ファイルを読むのではなく、クエリしてください。ストアを意図的に別の場所に置いているプロジェクトでは、その旨が実行時にすでに読み込まれている独自のコンテキストファイルに記されています。どちらにも該当しない場合は、尋ねる前に探してください。ストアがどこにも存在しない場合は、その旨をはっきり伝え、ストアを作る2つの方法 — 完成したマニフェストに対して ticket-up を実行する方法、または規約に従ってチケットを手動で書く方法 — を提示します。まだ作業が追跡されていないプロジェクトに必要なのはストアであり、どの種類にするかを尋ねることではありません。何か見つかった場合も、ストアの場所を決めつけないでください。目の前に tickets/<effort>/ ディレクトリがあっても同様です。ストアをトラッカーに移したプロジェクトにも、通常それらのディレクトリが残っているためです。見つけたものを示して尋ね、回答しやすくしたうえで、tickets/store-config.md に記録します。こうして、質問は一度だけで済みます。

候補の範囲を定める。 引数なしの呼び出しでは、どの取り組みかを尋ねるのではなく、こちらで判断して回答します。会話がすでに1つの取り組みについてのものであれば、その取り組みに範囲を絞ります。ストアが取り組みの順序を意図的に定めている場合は、その順序を使用します。これは明示的な運用方針であり、既定の順序より優先されます。それ以外の場合は、ストア自体から未完了のチケットがあるすべての取り組みを列挙します — ファイルストアなら tickets/<effort>/、GitHub なら未完了の課題を1回クエリして取り組みラベルを確認します — そのうえで、準備完了のチケットを取り組み横断で比較します。各取り組みに関係するフロントファイルの到達先と優先度の上書きを読み、遅延による損失を、その取り組みが目指すものに照らして判断します。

候補が複数の取り組みにまたがり、プロジェクトに North Star（リポジトリルートの NORTH_STAR.md、またはプロジェクトのコンテキストファイルに記載された場所）がある場合は、その目標と指標、および原則を読みます。つまり、Goal、How we know、Principles セクション、または古い9項目形式の North Star では、Winning, and the number watched と Never フィールドを読みます。目標とその指標は、取り組みの到達先を比較する基準です。これは、フロントファイルだけでは得られない取り組み横断の指標です。また、作業が原則に反する候補は選ばず、その矛盾を明示します。North Star を参照した場合は、その理由を理由行に記します。North Star がない場合、または目標と指標がまだ空の場合は、以下に記載のとおりに比較します。1つの取り組み内では、どちらの場合も変わりません。

どの範囲の選択でも、選ぶたびに戦略上の道しるべを確認します。 プロジェクトの North Star に、現在有効な戦略上の選択肢が道しるべとともに列挙されている場合は — タイトルの後に Revisit when 条件があるもの — それぞれの条件を、指定された情報源で確認します。満たされていると思われる条件があれば、その記録のタイトルとともに、選択肢を再検討してもよいものとして報告します。情報源を読めない条件があれば、その情報源とともに報告します。選択を行っても、戦略の見直しをこちらで引き受けることにはなりません。責任者またはすでに任命された代理人が判断できるよう、根拠を報告し、記録も一覧も変更しません。 遅延損失で選びます。 対象範囲内のオープンセットから候補を取り、Transitions で定義されている ready な Ticket のみを対象にします。各候補を選ぶたびに、延期中の Ticket の Revisit when の情報源を読み取ります。情報源を読めない延期中の Ticket があれば、その Ticket 名と情報源をレポートに記載します。選択によってその行を編集することはありません。変更には、情報源を確認したという事実ではなく、別個の割り当てと適用される権限が必要です。明示的な優先度の上書きで順位付けの根拠として必要な場合に限り、ファイルストアの done/ アーカイブを含む、範囲を限定した最近のクローズ済み履歴を読みます。Ticket とは、その内容だけでなく、保管場所にある関連情報すべてを指します。保管場所の参照先には、それらの情報がある場所が記載されています。すでに有力に見える候補だけでなく、候補をすべて隅々まで読みます。添付されたコンテキストも Ticket の順位付けに影響するため、最有力候補だけを読むと、順位付けそのものが順位付けに使う情報を決めることになります。明示されたストアまたは作業量の優先度上書きが適用される場合はそれに従い、それ以外は規約に定める期待遅延損失のルールを使います。各候補が、もう一方の候補が人間の限られた注意を得るまで待つことで失われるプロジェクト価値を比べます。継続中または期限が迫る損害、後から始まる持続的な利益、実際に最も早く有益な着手時点が後ろ倒しになる後続作業、そして重要な判断を悪化させたり先延ばしにしたりする情報の遅延を含めます。これらを数値化したスコアとして記録してはいけません。

このピッカーが割り当てるのは、人間と AI によるセッションであり、人間だけで実装する作業ではありません。人間に依存する不確実性、判断の好み、または権限の問題が解決するまでに必要な、人間の対話的な注意だけを見積もります。その後 AI が継続できる定型的な実装作業は、見積もりに含めません。従来の機能規模から日数を推測したり、固定のエージェント速度倍率を適用したりしてはいけません。妥当な所要時間が十分に短く、時間差が遅延損失を実質的に変えない場合は、同等として扱います。作業時間の短さはタイブレーカーに限ります。すでに進行中の作業との継続性も、タイブレーカーに限ります。

Auto は本質的な優先度ではありません。プロジェクトのコンテキストまたは設定済みの自動化によって、無人の処理能力が近いうちに実際に利用可能となり、その Ticket を引き受けられることが確認できる場合にのみ重要です。その場合、人間とのやり取りが必要な同程度の価値の作業は、無人ランナーが引き受けられる Auto の作業より優先されることがあります。ただし、Auto でないことが絶対的な優先条件になることはなく、遅延損失が大きければ Auto の Ticket が優先されます。Auto だけで証明されるのは権限の有無であり、ランナーが存在することではありません。Type を選択の判断材料にしてはいけません。

最上位の Ticket を1件だけ選び、そのタイトル、kind（shaped は実装するもの、question はまず調査するもの）、Auto の許可を持つかどうか（許可ありなら無人の自動化で最初から最後まで対応でき、許可なしなら自動化は ready なプルリクエストまでしか作業できず、人が完了させてマージします）、許可を持つ場合はその type（持たない場合は、type がないことを明記）、そしてそれを最上位にした具体的な遅延損失または明示的な上書きに基づく「これを選んだ理由」を1行で示します。選択を正当化するために、数値スコアを捏造してはいけません。 取得してから提示します。 対象を選んだことを示すために、Claimed by: 行、担当者、またはその場に相当する方法で取得を記録し、まず尋ねるのではなく、完了したものとして報告してください。この記録こそが、2つのセッションで異なる Ticket が選ばれる理由です。準備状況のルールでは、取得済みの Ticket はすでに取得されたものとして扱われるため、選択した記録が残らなければ、このストアを読む全員が同じ Ticket を選ぶことになります。取得を遠くまで維持できない場所であっても、すべての場所で取得し、場所でできないことを除外できるかのように示唆せず、たった今どのように取得したかを述べてください。共有トラッカーでは取得が全員に対して有効ですが、ファイルストアでは、次にこのチェックアウトを読む人に向けて意図を記録するだけで、別の場所で作業している人には伝わりません。Transitions の行 Pick のとおりに取得を記録してください。ストア設定の自動化アイデンティティ、つまり無人実行が取得に使うアカウントで取得を記録すると、中断された無人実行の試みとして扱われ、無人作業はその人が取り組んでいる Ticket で再開されます。この行で Ticket が未取得のままになっている場合は、その理由を述べてください。添付コンテキストも含め、Ticket 全体を提示してください。以前の試みの記録、コメントに残された修正、すでに進行中のリンク先の作業などです。このコンテキストも、担当者が引き継ぐ内容の一部です。本文だけを渡す選択担当者では、スクロールして探すか、あるいはまったく見つけられず、担当者自身がそれを発見することになります。ユーザーが希望した Ticket ではなかった場合に限り、取得を解除すると申し出てください。ユーザーに代わって実行したり、run-ticket を呼び出したり、ワークフローを選択したりしないでください。選択と実行は別の操作です。

整理パスで指定された項目を明記します。 オープンな項目を確認する際、../ticket-up/references/TICKET_CONVENTION.md → Tidy pass が、ストアの読者が明記するよう求めている内容を報告に記載し、指示どおり、プルリクエストがマージされた各 Ticket を記録してクローズしてください。どちらも選択を待つものではなく、選択でもありません。

準備ができたものがない場合は、報告する前に、対象範囲内のすべての取り組みを確認してください。その理由を正確に述べてください。オープンな Ticket がすべてブロックされている場合はブロックしている依存関係を、延期されている場合は各条件とその情報源の読み取り方を、取得済みの場合は取得者を、それぞれ明記してください。または、ストアが空であることを述べてください。ブロックされている項目しかないストアでは通常、すでに進行中の作業を完了または整理するのが有効な対応です。依存する項目の数が最大のものだけでなく、クローズすると下流の遅延損失の期待値を最も大きく低減する項目を述べてください。

注意点

• 放置されたように見える取得済みチケット（「X が取得済み、未着手。整理パスで取得を解除できる可能性あり」）を見つけて伝え、解除は人に任せてください（Transitions の行 Release a stale claim）。