to-spec

To Spec

担当範囲：仕様の枠組み、決定事項、制約、実装の意図です。チケットのシリアライズ、作業のスケジュール設定、コードの実装、検証結果の判断は行いません。

デフォルト

ユーザーまたは出力先から互換性が明示的に求められない限り、クリーンな目標状態を仕様として定めます。推測に基づいて、レガシーエイリアス、並行形式、シム、移行作業を追加してはいけません。ただし、破壊的なデータ変更、外部契約の破壊、取り消せない操作は明示してください。

ユーザーがパスを指定しない限り、docs/specs/<slug>.md に保存します。一致する既存の仕様がある場合は、重複して作成せず、その仕様を更新してください。

保存する各仕様には、安定した Artifact ID、Role: spec、および Standalone: true または1つの Parent を記載した ## Artifact Graph セクションを1つ含めます。所有者がいる仕様の場合は、同じ変更内で所有者側の対応する Children または Produces リンクも更新してください。

保存する各仕様には、作業開始前に確定させた ## Gates セクションも1つ含めます。まず、作業を止める可能性のある制限（バージョン固定、累積予算、承認チェックなど）をコード、設定、ポリシーで検索してください。各ゲートには、ユーザーの指示または検索結果に基づいて記入し、いずれにも該当しない場合は質問せず、次のデフォルトを記載します。

• 試行：引き継ぎまでの作業
• 予算、時間、最大試行回数：設定なし
• 承認：すでに得られているもののみ。作業に必要だが得られていない承認（マージ、デプロイ、公開、外部支出）は open
• 正確なバージョン：ユーザーが指定しない限りなし
• 見つかった既存のブロック条件、または「見つからなかった」と検索対象

ユーザーへの質問は、作業に必要な open の承認、または依頼と矛盾する、見つかったブロック条件についてのみ、一度だけ行ってください。ローカルでの編集やテストに承認は不要です。

エージェントが独自に設定した制限はゲートではありません。その制限を理由に作業を止めたり、延長を求めたりしてはいけません。open のゲートがブロックするのは、それに依存する作業のみです。新しい試行は予算と時間を全量使って開始し、以前の試行は記録に残しますが、その予算を消費しません。権限が及ぶのは作業であり、バージョンではありません。

プロセス

1. 最も適した種類のうち、最小のものを選びます。
   • feature：望ましい動作と製品の境界
   • decision：選択肢、決定、トレードオフ、結果
   • diagnostic：証拠、仮説、根本原因、修正方針
   • architecture：コンポーネント、契約、状態、ロールアウト
   • bug analysis：観測された動作と期待される動作、再現方法、原因、受け入れ条件
2. ユーザーの決定、コード、現行ドキュメント、過去の仕様、チケット、証拠から既知のコンテキストを再構築します。外部ライブラリ、API、CLI、クラウドの契約が関わる場合は、最新の一次ドキュメントを取得してください。
3. 事実、決定、仮定、未解決の質問を切り分けます。目標を大きく左右する決定が欠けている場合に限り、質問してください。
4. 種類に応じて、簡潔なセクションを作成します。該当する場合は、目標、対象外、現状と目標の動作、意味上の不変条件、外部契約、障害モード、セキュリティやデータに関する懸念、代替案、実装の段階、検証方針を含めます。
5. プロジェクトのドメイン用語を一貫して使い、大量のソースをそのまま貼り付けず、証拠へのリンクを記載します。

品質チェック

• 受け入れ結果を観測可能な形で定義します。
• 重要な外部動作はすべて維持するか、変更内容を明示します。
• 不明点と人間による判断を明示します。
• ## Gates で各ゲートに回答するか open とし、作業開始後に初めて見つかるゲートがないようにします。
• 実装計画は順序立てますが、脆弱な行番号には依存させません。
• 実施したと断定せず、単体、統合、システム、ライブ、手動の各テストの必要性を区別します。
• 互換性と移行に関する義務は、前提とせず明示します。

引き継ぎ

実行可能なチケットを求められた場合は、仕様のパスと段階のデフォルトを to-tickets に渡してください。YAML やフロントマターを自分で出力してはいけません。

仕様のパス、種類、主な決定事項、未解決の質問、推奨する次のステップを報告してください。