ticket-up

ticket-up

ticket-up は、Ticket 作成の単一の境界です。文章を整え、規約を適用し、重複を排除して、プロジェクトで設定されている管理先に結果を反映します。

出力する前に references/TICKET_CONVENTION.md を読んでください。ここでは、すべての管理先で維持すべき単位、種別、構成、ライフサイクル、優先度を定義しています。

入力と Ticket の単位を見極める

次のいずれかの入力を受け付けます。

• 完成した Manifest。
• ストアに登録すべき直接の作業依頼。
• 個別に管理する必要がある 1 つ以上の質問。
• ソース Ticket を実行中に見つかった調査結果。その場合はソースを明示します。

明示的な入力がない場合、会話の中ですでに直近の Manifest が意図するソースとして特定されていれば、それを使用します。そうでなければ、何を Ticket にすべきか尋ねてください。

1 つの Ticket は、独立してスケジュールできる 1 つのライフサイクルを表します。1 つの成果を共有し、まとめて割り当て、優先順位を決め、完了できる作業はまとめてください。所有者、優先度、ブロック、完了を分けることに実質的な価値がある場合にのみ、分割します。すべての Deliverable、質問、軽微な調査結果を Ticket にする必要はありません。

分割するかどうかは 1 つの問いです。どこで分割するかは別の問いであり、入力が何であっても同じように判断します。分割によって生成されるすべての Shaped Ticket は、それ単独でエンドツーエンドに実行できる作業単位です。つまり、対象となる状況で実行、読解、その他の方法で評価できる必要があり、単に存在を確認できるだけでは不十分です。「スキーマ」「エンドポイント」「画面」といった実装レイヤーに沿って切り分けられた Ticket には実行できるものがなく、完了条件は何かが存在することの確認に戻ってしまいます。その結果、担当者は作業が役に立ったか判断できません。レイヤーに沿って構成された作業が持ち込まれた場合は、レイヤーをそのまま通すのではなく、作業を切り直してください。レイヤーの名前を変えても、切り直したことにはなりません。また、レイヤーに沿った分割の依頼で決まるのはスコープであって分割位置ではないため、レイヤーを維持するかどうかをユーザーに委ねることはできません。スコープは維持し、レイヤーは切り直してください。Question Ticket はこの対象外です。調査には実行できる作業単位がなく、完了条件は回答が記録されることです。

Manifest が入力の場合、デフォルトでは Manifest 全体を 1 つの Shaped Ticket にします。 その Deliverable は、内部的な実行および検証の構造として維持します。呼び出し側が委任または並行して着手することを明示的に求めた場合にのみ、Deliverable ごとに 1 つの Ticket に分割します。既存の Deliverable 境界が、許可される最小の分割単位です。1 つが大きすぎる場合、またはエンドツーエンドで実行できるものではなくレイヤーである場合は、エンドツーエンドで評価できない単位を出すのではなく、Manifest を修正してください。

質問の入力は、その質問に独自のライフサイクルが必要な場合にのみ、個別の Question Ticket にします。 現在の作業で回答できる質問、または実行上の判断を記録するだけの質問は、含まれる Ticket 内に留めます。まとめて管理する関連質問は、1 つの Question Ticket にします。質問を追跡または委任するという明示的な依頼があれば、独立したライフサイクルを設けます。

フォローアップの入力は、ソースの責務とは別に保ちます。 現在のスコープ内の作業はソース Ticket に残し、その完了条件を妨げる要因はエスカレーションします。まず取り組みの未完了項目を検索し、調査結果が既存の Ticket の対象範囲に含まれていれば、そこにまとめます。新たな調査結果は、Ticket を作成する前に関連するものごとにまとめてください。作成するすべてのフォローアップはソースにリンクし、その調査結果が本当に別の取り組みに属するのでない限り、同じ取り組みへの所属情報を引き継ぎます。

実装ではなく、知見を翻訳する

有用なプロダクトの意図を保ちながら、割り当てと権限を維持します。誰の進捗が重要なのか、どのような状況なのか、代替案とトレードオフは何か、何が観測され、何が想定なのかを保ってください。調査の回答や Manifest を、タスクとチェック項目のリストに矮小化しないでください。

Ticket は、manifest-dev を使っていないかもしれない見知らぬ人との契約です。ソースを抜粋するのではなく、この規約の構成に沿って書き直してください。この Ticket だけを持つ有能な人が、作業の目的と範囲を理解し、落とし穴を避け、完了を判断できるでしょうか。出力する Ticket に Manifest-dev の用語が含まれていると、この基準を満たしません。

Manifest を入力とする場合、まとまりのある成果全体を 1 つの Ticket に翻訳します。Problem と Goal は Why に、Appetite と Out of bounds は Scope に、該当するすべての Global Invariants は守るべき平易な Rules に、リスクと前提は Watch out for に変換します。Initial Approach は任意の助言として残します。すべての Deliverable と gate を、平易な文章による 1 つの Definition of done に反映します。Gate の種類、コード、評価者への指示は表に出しません。

明示的な分割モードでは、各 Deliverable に同じ翻訳を適用し、該当するすべての Global Invariant を各 Ticket に記載します。エンドツーエンドで実行できるものではなく、単なるレイヤーである Deliverable は、上記の分割ルールに従い、まず Manifest で修正します。Manifest の上限を示す invariant はルールとして出力しないでください。その内容は、すでに各 Ticket の Scope に含まれています。

Auto grant

この割り当ての完了に必要なすべての判断が確定済み、または委任済みであり、grantor が無人での実行を信頼することを選んでいる場合に、規約の Auto 基準を適用します。受け入れ判断が残っている場合、方針と実装の判断が委任されていても Auto はオフのままです。

grantor は 2 種類あります。人間による grant は、この場で直接作成する場合、またはこの場で Ticket を明示的にレビューして Auto を承認する場合に行われます。orchestrate --autonomous も grant します。これはエージェントが作成した Ticket（エージェントが作成した負債 Ticket、または実行中に作成したフォローアップ）に対してこのスキルを呼び出し、上記の基準を満たす場合に限って grant します。人間が orchestrate による grant と自分による grant を見分けて取り消せるよう、実行環境の表示方法に従って grantor を記録します。

フォローアップが Auto を得られるのは、この境界で行われたこれらの grant のいずれかからのみです。該当する grant がなければ、ソースに Auto が付いていても、フォローアップには Auto が付きません。作業を見つけた実行自体は grant しません。また、ソースに対して手動で run-ticket を呼び出すだけでは、その実行中に見つかったフォローアップへの grant になりません。作成時に整形されていることから Auto が暗黙に付与されることはありません。

種類、依存関係、延期

適合するものがあれば、ストアの語彙から各 Ticket に種類を 1 つ付与します。適合するものがなければ、何も付与しません。Manifest を 1 つの Ticket にするモードでは、作業全体の主な性質を基準にします。明示的な分割モードでは、各 Deliverable に個別に種類を付与します。種類によって実行権限が付与されることはありません。

ある Ticket の成果が別の Ticket の実行または判断に必要な場合に限り、Depends on: を記載します。推奨順序は依存関係ではありません。関連があるだけのフォローアップは、ブロックせずにソースへリンクします。構造上の必要性がある場合にのみ、依存関係を追加してください。

別の Ticket が完了するまでではなく、世界の状況が変わるまで（数値が基準を超える、リリースが出荷される、日付が過ぎるなど）作業を待つ場合は、規約の Revisit when 行を記載します。条件と、それを実行環境がどのように対応付けるかを示す確認先を記述します。ダッシュボード、ファイル、リリースページ、日付など、ピッカーが確認できる情報源を指定してください。ピッカーが確認できない条件の場合、Ticket は選択のたびに人の目に触れる状態のままになります。延期は Depends on: の項目ではなく、推奨順序も延期ではありません。

実行環境を選択して出力する

references/STORE_CONFIG.md を読み、既存の選択を再利用して実行環境を決定します。次に、その実行環境のリファレンスを読み、対応付けに従って Ticket を出力します。設定だけでは作業は作成されません。この呼び出しにおける作成割り当てが、スコープを決定します。

レポート

作成した内容を簡潔な表で提示します。列には ID、タイトル、種類、タイプ、Auto とその付与者、依存関係、Revisit when の条件を含め、各チケットの行き先も示します。マニフェストモードでは、デフォルトの一貫した単位を使用したか、明示的な Deliverable 分割を使用したかを記載します。フォローアップモードでは、ソースへのリンクと、どの調査結果をグループ化または重複排除したかを含めます。

注意点

• ゲートに、部外者には利用できない評価の仕組みが記されている場合があります。その内容を、観察可能な完了条件を示す文章に置き換えてください。
• 小さな質問の一覧が、そのまま Question チケットの一覧になるとは限りません。まずライフサイクルの判定を行ってください。