Ship

目標: リクエストされた変更を安全にマージする。証拠を示し、CI が green になった後にのみマージします。

このスキルは specs/shipping.md を実装しています。運用ガイダンスはここに保持してください。シッピング成功基準と制約は仕様で確認してください。

このスキルは結果志向です。機械的に固定チェックリストを歩まないでください。目標と変更されたリスク表面から始まり、変更がマージ準備完了であることを証明する最小限のパスを選択してください。

使用するタイミング

以下のようなユーザーのリクエストがある場合、このスキルを使用してください:

• 変更をシップする、または fix and ship する
• PR 作成、CI、マージを通じて作業を進める
• ブランチがマージ可能であることを証明する

必須アウトカム

以下のアウトカムはすべて必須です。提案ではなく、要件をスキップまたは弱めないでください。

1. ブランチの状態は安全です。
   • main または master からシップしないでください。
   • 最終プッシュ前に、ワーキングツリーがクリーンであることを確認してください。
   • マージ前に最新の origin/main に rebase してください。
   • rebase 後、bash scripts/lib/check-migration-ordering.sh を実行して crates/server/migrations/ の番号が厳密に連続していることを確認してください。マイグレーションは最も一般的なコンフリクト源です — 複数ブランチが同じ次番号を追加することが多く、rebase は両方をサイレントに保持します。チェックが失敗した場合、マイグレーションを次の利用可能な番号に付け直してください。
   • gh pr merge の直前（CI が green でレビュースレッドが解決した後）、bash scripts/lib/check-migration-ordering.sh を再度実行してください。他の PR があなたのレビュー中に同じ番号をマージしている可能性があります。
2. リクエストされた目標は証拠で達成されています。
   • git diff origin/main...HEAD と git log origin/main..HEAD でデルタをレビューしてください。
   • リクエストされた動作が実際に実装されていることを確認してください。
   • バリデーションはリスクと対応していなければなりません。バグの場合、実用的であれば失敗テストを優先してください。
3. 変更されたコードはマージに適しています。
   • 明らかな重複または偶然の複雑性を簡潔にしてください。
   • 構造化されたセキュリティレビューを実施してください（下記のセキュリティレビューセクション参照）。
   • 見つけた問題を修正し、証拠を更新してください。
4. 関連アーティファクトは同期を保ちます。
   • 変更の影響を受けるアーティファクトのみを更新してください: specs/、specs/threat-model.md、AGENTS.md、test_cases/、apps/docs/、および適用可能な場合は OpenAPI エクスポート。
5. 影響を受ける機能をスモークテストします。
   • 変更の影響を受けるフローは常にエンドツーエンドでスモークテストしてください。これはリスク評価の条件ではなく、必須です。
   • 高速チェック用に just start-dev --no-watch を優先してください。
   • データベース、マイグレーション、インフラ、または API 統合リスクが存在する場合は just start-all --no-watch を使用してください。
   • 起動したすべてのサーバーを停止してください。
   • ドキュメントのみまたは設定のみの変更でランタイム動作に影響しない場合、明示的な正当化によりスモークテストをスキップできます。
6. フォローアップは表示され、サイレントに削除されません。
   • デフォルトではマージ前にスコープ内のすべてを実装してください。 単に PR が「十分な大きさ」だからといって作業を延期しないでください。
   • diff レビュー、セキュリティレビュー、スモークテスト、およびレビューコメント対応中に、以下を積極的に探してください: 追加した TODO、部分的な修正、テストでカバーされていない既知のエッジケース、適用しないことを選択した提案、気づいた関連バグ、修正しなかった仕様/ドキュメント乖離、および別の変更を保証する脅威モデル項目。
   • 各候補について明確に決定してください: 今すぐ実装（推奨）または延期。作業が小さい、スコープ内で明確、または正確さに必要な場合、今すぐ実装することを優先してください。
   • 延期したもののために、PR 本文にフォローアップセクションをリストして、項目ごとに 1 行の理由（延期が安全な理由と後で何が起こるべきか）を記載してください。重要でないフォローアップについては、必要に応じて Linear イシューを作成してください（OSS プロジェクト、EVE チーム）。
   • フォローアップがない場合、PR 本文に「No follow-ups.」と記載してください。沈黙は受け入れられません — 読者は「完了したもの」と「エージェントが忘れたもの」を区別できなければなりません。
7. PR はマージ可能で、安全にマージされます。
   • ブランチをプッシュしてください。
   • .github/pull_request_template.md で PR を作成または更新してください。
   • すべてのレビュアー（ボットを含む）からの PR 会話、レビュースレッド、およびレビュー状態をチェックしてください。
   • 各プッシュ後および CI が green になった後、非同期レビュアーボットが完了するまで少なくとも 2 分待機してから、マージ前に新しいコメントを再チェックしてください。
   • すべてのレビューコメントに対応してください — 低信頼度の提案、細かい指摘、ブロッキングではないコメント（COMMENTED 状態）、およびボット提案を含めて。ブロッキングではないコメントはしばしば有効な改善を含みます（UX、堅牢性、ドキュメント明確性）。各コメント: 懸念を分析し、コード変更が正当であるかを推論し、修正を適用するか、現在のコードが正しい理由について明確な説明で返信してください。推論なしにコメントを却下しないでください。
   • 常にコメントに返信して何をしたかを記載してください: 行ったコード変更、または現在のコードが正しい理由。その後スレッドを解決済みとしてマークしてください。対応されたすべてのコメントは、マージ前に返信と解決済みステータスの両方を持つ必要があります。
   • 未解決のレビューコメントがある間はマージしないでください。すべてのスレッドはマージ前に明示的に対応される必要があります（コード変更または書面による解決）。
   • CI が green になるまで待機してください。
   • CI が green で、すべてのレビュースレッドが解決され、上記の最終レビュー/コメント確認がクリーンな後、squash でのみマージしてください。

運用モデル

• チェックリスト順序ではなく、目標とリスク表面から始めてください。
• 最高信号パスを優先してください: 対象デルタレビュー、焦点を絞ったテスト、関連ビルド、その後ギャップが残る場合はスモークテスト。
• 「fix and ship」は実装を最初に行い、その後シッピングモードに切り替えることです。
• ドキュメントまたは設定のみの変更は、理由を説明し、関連ドキュメント、lint、またはビルド証拠を実行する場合、コードテストをスキップできます。
• オートマージや gh pr merge --auto を使用しないでください。最終レビュー確認がクリーンな後のみ手動でマージしてください。非同期レビュアーボットは最後のプッシュ後または CI が green になった後にポストできるためです。
• フォーマットチェックの失敗を just fmt で自動修正できる場合、一度使用して再試行してください。
• 単独では安全に解決できないブロッカーでのみ停止: マージコンフリクト、不足している認証情報、曖昧な製品意図、または再現または修正できない CI 失敗。

セキュリティレビュー

これはコード、構成、またはインフラに触れるすべての変更に対する必須ステップです。オプションではなく、認識された低リスクに基づいてスキップされてはなりません。

シップされるすべての変更について、明示的に以下のステップを実施してください:

1. 脅威表面を特定してください。 git diff origin/main...HEAD を読み、変更が specs/threat-model.md からどの脅威モデルカテゴリに触れているかを判定してください。一般的なカテゴリ:

   • TM-AUTH — 認証変更、セッション処理、トークン生成
   • TM-AUTHZ — 権限チェック、ポリシー適用、ロール変更
   • TM-API — 新規/変更されたエンドポイント、入力解析、クエリパラメータ
   • TM-TOOL — ツール登録、MCP サーバー、ツール実行パス
   • TM-LLM — プロンプト構築、API キー処理、モデルパラメータ
   • TM-TENANT — データクエリ、org スコーピング、テナント間境界
   • TM-FS — ファイルパス、サンドボックス境界
   • TM-SQL — データベースクエリ、サンドボックス境界
   • TM-BASH — サンドボックス設定、コマンド実行
   • TM-WEB — フロントエンドレンダリング、CORS、CSP、クッキー処理
   • TM-DOS — 無制限入力、欠落ページング、リソース制限

2. 各タッチされたカテゴリをレビューしてください。 すべての関連カテゴリについて、以下の diff をチェックしてください:

   • インジェクション — SQL、コマンド、プロンプト、XSS、パストラバーサル
   • 認証/認可バイパス — 欠落認証チェック、破損したアクセス制御
   • データ露出 — ログ、レスポンス、エラー、またはトレースの機密データ
   • 入力バリデーション — トラスト境界での欠落または不十分なバリデーション
   • 依存リスク — 新規依存、バージョン変更、サプライチェーン
   • リソース枯渇 — 無制限ループ、欠落制限、大規模割り当て

3. THREAT コメントをチェックしてください。 変更が既存の // THREAT[TM-XXX-NNN] コメント近くのコードを変更する場合、緩和策が保持されていることを確認してください。変更が新しい脅威表面を導入する場合、適切な THREAT コメントを追加してください。

4. 脅威モデルを更新してください。 変更が本当に新しい脅威を導入するか、既存の緩和策を実質的に変更する場合、新しいエントリまたは改訂された緩和策で specs/threat-model.md を更新してください。「小さい」変更でもこれをスキップしないでください — トラスト境界での小さい変更は外部の影響を持つことができます。

5. レビューをドキュメント化してください。 PR 本文にセキュリティセクションを含め、以下をリストしてください:

   • どの脅威カテゴリがレビューされたか
   • 見つかった結果とそれがどう対処されたか
   • セキュリティに関連した表面がタッチされなかった場合の明示的なステートメント（推論付き）

純粋にドキュメント、コメント、仕様、またはテストのみの変更は、完全なレビューの代わりに「No security-relevant code changes」と 1 行の正当化で述べることができます。

一般的な証拠コマンド

変更された表面に一致するものだけを選択してください:

• just pre-push
• just pre-pr
• cargo fmt --check
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test --all-features
• cargo fetch --locked
• cd apps/ui && npm run format:check && npm run lint && npm run build
• ./scripts/export-openapi.sh
• cd apps/docs && npm run check && npm run build
• bash scripts/lib/check-migration-ordering.sh (マイグレーション順序チェック、~即座)

PR とマージ

• conventional-commit スタイルの PR タイトルを使用してください。
• PR 本文で、何が変わったか、なぜ変わったか、どうバリデーションされたか、注目すべきリスク、および明示的なフォローアップセクション（またはフォローアップがない場合は「No follow-ups.」）を説明してください。この PR でフォローアップを実装することを優先し、作業が本当にスコア外または大きすぎる場合のみ延期し、項目ごとにそう述べてください。
• gh pr view --json url を使用して既存 PR を検出してください。
• 必要に応じて gh pr create で PR を作成してください。
• gh pr view --comments を使用して、ボットコメントを含む PR 会話を検査してください。
• gh pr view --json reviews,latestReviews を使用してレビュアーの状態を検査してください。
• レビュースレッドの状態が不明確な場合、マージ前に GitHub UI で、または gh api graphql でレビュースレッドを検査してください。
• 最終プッシュ後および CI が green になった後、非同期レビュアーボット用に少なくとも 2 分待機し、マージ前に最後のコメント確認を行ってください。
• gh pr checks を使用して CI を監視してください。
• CI が green で最終レビュー確認がクリーンな後、gh pr merge --squash でのみマージしてください。