seda-ticket

チケットを作成

提供された作業を、初めて担当するデリバリーオーナーが親の説明を再構成せずに理解し、完了できる、確認済みのチケット一式にします。担当範囲は、分解、依存関係と着手可能性の意味づけ、チケットの最終的な処遇に限ります。グループ化、保存、公開、実行、レビューの進捗管理、担当者からの結果に基づく調整は、呼び出し元が担当します。

実質的な分析、調査、専門的な作業はサブエージェントに委任し、メインコンテキストを簡潔に保てるよう、簡潔な調査結果と根拠へのリンクを返します。

1. 作業を理解する

すでに提供されているコンテキストを使用します。参照先のソースが作業の指針となる場合は、全文を読みます。既存の動作、用語、制約、または正確なチケットの境界を把握する必要がある場合に限り、現在のプロジェクトやシステムを調査します。ソフトウェア開発ではコードベースを調査する場合がありますが、常に必要というわけではありません。

重要な要件を捏造しないでください。分解する権限がない場合や、粒度または依存関係の構造が曖昧な場合は、確認を求めます。呼び出し元から、すでに確認済みの内訳が提供されることもあります。

必要に応じて seda-spec を使用します。分解にあたっては、指針となる契約の識別情報と要件を維持します。

2. 成果を完結させる垂直チケットを優先する

各チケットは、特段の理由がない限り、次の条件を満たす、範囲の狭い成果完結型の垂直スライスとします。

• ユーザー、運用担当者、ステークホルダー、またはシステムに対し、個別に検証可能な成果をもたらす。
• その成果に必要な機能やレイヤーのみをまたぐ。
• 新たに担当するデリバリー責任者やレビュー担当者が自己完結して理解できる一方、候補、コミット、ブランチ、PR/MR、文書、証拠ファイル、エージェントのセッションの境界を指定しない。
• 親チケットの説明をコピーしたり、実装の詳細を推測したりしなくても有効であり続ける。

組織上の機能、技術レイヤー、成果物の種類、または証明作業だけを理由に、1つの成果を分割しないでください。垂直型ではないチケットを使うのは、後続作業を実際に阻む、個別に検証可能な準備機能の場合、または成果完結型のスライスを有効な状態で統合できない場合に限ります。その例外と、それによって可能になる統合／受け入れの境界を記録してください。

垂直スライスのままでは正常な状態を保てない、ソフトウェア／システム全体の移行または機械的なリファクタリングでは、拡張－移行－縮小の順序が適切な場合があります。互換性のある形式を追加し、範囲を限定したグループを移行してから、移行対象一式の完了後に旧形式を削除します。これはソフトウェアに固有の例外であり、普遍的なチケットのパターンではありません。

各チケットには次を含めます。

• タイトル — 現在のプロジェクト／ドメインの語彙を使った、成果を端的に表すタイトル。
• 提供内容 — エンドツーエンドの動作／結果とその価値。
• コンテキスト — 必須の安定した事実、制約、または参照元のみ。
• 受け入れ条件と証明 — 観察可能な完了条件、該当する場合は適用される仕様の動作識別子、また重要な場合は証明／証拠の要件または安定した接点。実行／証明の担当者が手段を選びます。
• 依存関係 — Done でなければならない正確なドラフト番号または提示されたチケット識別子、あるいは None。
• 外部前提条件 — チケットではない、明示された事実／権限／リソースが着手を妨げる場合のみ記載し、判明していれば担当者／発生条件も含めます。
• 境界 — もっともらしい誤った成果物を防ぐために除外事項が必要な場合のみ記載します。
• 状態 — Open、Done、または Cancelled。
• 完了時の証拠 — Done の場合は受け入れ／証明の結果、Cancelled の場合はキャンセルの権限者／理由。

ドラフト中は一時的な番号を使用し、呼び出し元から提供された識別子はそのまま維持します。呼び出し元がグループ分けを指定しない限り、グループ化せず、依存関係の順に並べた一式を返します。合成的な親チケットを作成したり、永続的なID、ライフサイクルの永続化、実行／レビュー状態、状態遷移履歴、担当者、タイムスタンプ、系譜、または調整を独自に管理したりしないでください。

チケットの識別は意味上のものであり、運用上のものではありません。チケットの境界は、コミット、候補、ブランチ、PR/MR、文書、証拠ファイル、デプロイ単位、またはエージェントのセッションの境界を意味しません。デリバリーの呼び出し元が、統合、レビュー、ロールバック／復旧、所有権、リリース、証拠のニーズに応じて、運用上のコンテナを個別に選択します。

推測したファイル／成果物のパス、長いコード片、汎用的な実装チェックリスト、重複するプロジェクトルール、人為的な依存関係は避けてください。必要な場合は、正確で安定した参照を含めます。文章では確定した判断を保持できない場合に限り、プロトタイプから得られた短いコード片を含め、その出典を明記します。

着手可能性と終端状態

チケットの状態は、意図的に実行進捗を表す状態機械ではありません。

状態	意味	必要な証拠
Open	提供が未完了です	なし
Done	現在の担当者の証拠により、チケットの受け入れ／証明が立証されています	受け入れと証明の結果
Cancelled	チケットが必要な提供対象から意図的に除外されています	キャンセルの権限と理由

Open チケットの着手可能性を次のように判定します。

• STARTABLE — すべてのチケット依存関係が Done であり、有効な外部前提条件がありません。
• BLOCKED — 少なくとも 1 つのチケット依存関係または名前が明示された外部前提条件が未解決です。

チケット依存関係を解消できるのは Done のみです。依存先が Cancelled の場合、後続チケットのブロックを黙って解除するのではなく、再計画が必要です。

In Progress、In Review、または実行時の Blocked チケット状態を追加しないでください。実行中の作業、証明、レビュー、実行時のブロッカー、候補／結果の識別、復旧はチケットの状態の範囲外であり、アクティブな実行／レビュー担当者が管理します。呼び出し元は、別の担当者のライフサイクルをチケット契約に取り込むことなく、担当者からの最新かつ正確な結果に基づいて Open → Done | Cancelled を反映できます。

着手可能なフロンティアとは、現在の判定で STARTABLE となっているすべての Open チケットです。

3. 確認して返す

すべてのチケットが個別に検証可能であること、依存関係が実在し循環していないこと、外部前提条件が実在すること、受け入れが観測可能であること、提供された範囲／適用される仕様全体が重複なく網羅されていることを確認してください。垂直方向のチケットではないものについてはすべて、その例外が必要で、個別に検証可能であり、名前が明示された統合／受け入れの境界と結び付いていることを確認してください。

確認が必要な場合は、ドラフトを提示し、粒度と依存関係が適切かどうかを尋ねてください。確認が取れるまで反復してください。

確認済みのチケットを依存関係の順に、ブロック中の前提条件を先にして、着手可能なフロンティアとともに返してください。返すのはチケットのみです。永続化／公開、Git／プロバイダーの状態操作、実行、実行／レビューの進捗判断は行わないでください。