ship

ランタイムに関する注意事項

• ワークフローで入力を求めて停止するよう指定されている場合は、ユーザーに直接尋ねてください。
• リポジトリ固有の指示が記載されている可能性が高いファイルとして、AGENTS.md、TODO.md、TODOS.mdを扱ってください。
• ワークフローの意図を保ちつつ、環境固有の表現は現在のツールセットに合わせて翻訳してください。

Ship：完全自動のShipワークフロー

shipワークフローを実行しています。これは非対話型の完全自動ワークフローです。どの手順でも確認を求めてはいけません。ユーザーがshipと言ったのは、実行するという意味です。最後まで続けて、最後にPRのURLを出力してください。

停止するのは次の場合のみです：

• mainブランチ上にいる（中止）
• 自動で解決できないマージコンフリクトがある（停止してコンフリクトを表示）
• テストが失敗する（停止して失敗内容を表示）
• リリース前レビューでCRITICALな問題が見つかり、ユーザーが修正を選択する（承認やスキップではない）
• MINORまたはMAJORのバージョン更新が必要（尋ねる — ステップ4を参照）

決して停止しないこと：

• 未コミットの変更（必ず含める）
• バージョン更新の選択（MICROまたはPATCHを自動選択 — ステップ4を参照）
• CHANGELOGの内容（差分から自動生成）
• コミットメッセージの承認（自動コミット）
• 複数ファイルにまたがる変更セット（バイセクト可能なコミットに自動分割）

---

ステップ1：事前確認

1. 現在のブランチを確認します。main上にいる場合は中止します：「main上にいます。フィーチャーブランチからShipしてください。」

2. git statusを実行します（-uallは決して使用しないでください）。未コミットの変更は必ず含めます。尋ねる必要はありません。

3. git diff main...HEAD --statとgit log main..HEAD --onelineを実行し、Shipする内容を把握します。

---

ステップ2：origin/mainをマージする（テストの前に実行）

テストがマージ後の状態で実行されるよう、origin/mainをフィーチャーブランチにフェッチしてマージします：

git fetch origin main && git merge origin/main --no-edit

マージコンフリクトがある場合： 単純なもの（VERSION、schema.rb、CHANGELOGの順序）は自動解決を試みます。複雑または曖昧なコンフリクトの場合は、停止して内容を表示します。

すでに最新の場合： 何も表示せず続行します。

---

ステップ3：テストを実行する（マージ後のコードで）

RAILS_ENV=test bin/rails db:migrateは実行しないでください — bin/test-laneは内部ですでに db:test:prepareを呼び出し、正しいレーンのデータベースにスキーマを読み込みます。 INSTANCEを指定せずにテスト用マイグレーションを直接実行すると、孤立したDBに接続され、structure.sqlが破損します。

両方のテストスイートを並行して実行します：

bin/test-lane 2>&1 | tee /tmp/ship_tests.txt &
npm run test 2>&1 | tee /tmp/ship_vitest.txt &
wait

両方が完了したら、出力ファイルを読み込んで合否を確認します。

テストが1つでも失敗した場合： 失敗内容を表示して停止します。先に進まないでください。

すべて成功した場合： 件数を簡潔に記録するだけで、何も表示せず続行します。

---

ステップ 3.25：評価スイート（条件付き）

プロンプト関連のファイルを変更した場合、評価は必須です。差分にプロンプトファイルが含まれていない場合は、このステップを完全にスキップしてください。

1. 差分にプロンプト関連のファイルが含まれているか確認します：

git diff origin/main --name-only

次のパターン（AGENTS.md またはリポジトリ内の近くにある指示から取得）と照合します：

• app/services/*_prompt_builder.rb
• app/services/*_generation_service.rb、*_writer_service.rb、*_designer_service.rb
• app/services/*_evaluator.rb、*_scorer.rb、*_classifier_service.rb、*_analyzer.rb
• app/services/concerns/*voice*.rb、*writing*.rb、*prompt*.rb、*token*.rb
• app/services/chat_tools/*.rb、app/services/x_thread_tools/*.rb
• config/system_prompts/*.txt
• test/evals/**/*（評価インフラの変更はすべてのスイートに影響します）

一致するものがない場合：「No prompt-related files changed — skipping evals.」と出力して、ステップ 3.5 に進みます。

2. 影響を受ける評価スイートを特定します：

各評価ランナー（test/evals/*_eval_runner.rb）には、影響するソースファイルを示す PROMPT_SOURCE_FILES が定義されています。これらを grep して、変更されたファイルに該当するスイートを見つけます：

grep -l "changed_file_basename" test/evals/*_eval_runner.rb

ランナーをテストファイルに対応付けます：post_generation_eval_runner.rb → post_generation_eval_test.rb。

特別なケース：

• test/evals/judges/*.rb、test/evals/support/*.rb、または test/evals/fixtures/ の変更は、これらの judge/support ファイルを使用するすべてのスイートに影響します。評価テストファイル内のインポートを確認して、対象を特定してください。
• config/system_prompts/*.txt の変更 — 評価ランナーでプロンプトのファイル名を grep し、影響を受けるスイートを見つけてください。
• 影響を受けるスイートが不明な場合は、影響を受ける可能性があるすべてのスイートを実行してください。回帰を見逃すより、テストを多く実行するほうが適切です。

3. 影響を受けるスイートを EVAL_JUDGE_TIER=full で実行します：

ship はマージ前のゲートであるため、常に full tier（Sonnet 構造判定＋Opus ペルソナ判定）を使用してください。

EVAL_JUDGE_TIER=full EVAL_VERBOSE=1 bin/test-lane --eval test/evals/<suite>_eval_test.rb 2>&1 | tee /tmp/ship_evals.txt

複数のスイートを実行する必要がある場合は、順番に実行してください（それぞれにテストレーンが必要です）。最初のスイートが失敗した場合は、すぐに停止してください。残りのスイートで API コストを消費しないでください。

4. 結果を確認します：

• **評価がひとつでも失敗した場合：**失敗内容とコストダッシュボードを表示して、停止してください。先に進まないでください。
• **すべて成功した場合：**成功数とコストを記録して、ステップ 3.5 に進みます。

5. 評価出力を保存します — 評価結果とコストダッシュボードを PR 本文に含めます（ステップ 8）。

ティアの参照（参考 — /ship では常に full を使用）：

ティア	用途	速度（キャッシュ使用時）	コスト
fast（Haiku）	開発時の反復、スモークテスト	~5s（14 倍高速）	~$0.07/run
standard（Sonnet）	開発時のデフォルト、bin/test-lane --eval	~17s（4 倍高速）	~$0.37/run
full（Opus persona）	ship とマージ前	~72s（ベースライン）	~$1.27/run

---

ステップ 3.5：マージ前レビュー

テストでは検出できない構造上の問題がないか、差分をレビューします。

1. references/review-checklist.md を読みます。ファイルを読み込めない場合は、停止してエラーを報告します。

2. git diff origin/main を実行し、差分全体を取得します（最新のリモート main に対する機能変更に範囲を絞ります）。

3. レビューチェックリストを2段階で適用します。

   • パス 1（重大）： SQL とデータの安全性、LLM 出力の信頼境界
   • パス 2（参考情報）： 残りすべてのカテゴリ

4. 必ずすべての指摘事項を出力します（重大なものも参考情報も含みます）。ユーザーには見つかったすべての問題を提示する必要があります。

5. 次の概要ヘッダーを出力します：Pre-Landing Review: N issues (X critical, Y informational)

6. 重大な問題が見つかった場合： 重大な問題ごとに、次の内容を含めて、別々のメッセージでユーザーに直接確認します。

   • 問題（file:line + 説明）
   • 推奨する修正
   • 選択肢：A）今すぐ修正する（推奨）、B）承知のうえでそのまま出荷する、C）誤検知なのでスキップする 重大な問題をすべて解決した後、ユーザーがいずれかの問題で A（修正）を選んだ場合は、推奨する修正を適用し、修正したファイルのみを指定してコミットします（git add <fixed-files> && git commit -m "fix: apply pre-landing review fixes"）。その後、停止して、修正を適用した状態で再テストするため、もう一度 ship を実行するようユーザーに伝えます。すべての問題について、ユーザーが B（承知）または C（誤検知）のみを選んだ場合は、ステップ 4 に進みます。

7. 重大ではない問題のみが見つかった場合： 問題を出力して続行します。これらはステップ 8 で PR 本文に含めます。

8. 問題が見つからなかった場合： Pre-Landing Review: No issues found. を出力して続行します。

レビュー結果を保存します。ステップ 8 の PR 本文に使用します。

---

ステップ 4：バージョン更新（自動判定）

1. 現在の VERSION ファイルを読みます（4桁形式：MAJOR.MINOR.PATCH.MICRO）。

2. 差分に基づいて更新レベルを自動判定します。

   • 変更行数を数えます（git diff origin/main...HEAD --stat | tail -1）
   • MICRO（4桁目）：変更が50行未満、軽微な調整、誤字、設定
   • PATCH（3桁目）：変更が50行以上、バグ修正、小〜中規模の機能
   • MINOR（2桁目）：ユーザーに確認します。大規模な機能または重要なアーキテクチャ変更の場合に限ります
   • MAJOR（1桁目）：ユーザーに確認します。マイルストーンまたは後方互換性を損なう変更の場合に限ります

3. 新しいバージョンを計算します。

   • 桁を更新する場合、その右側の桁はすべて0にリセットします
   • 例：0.19.1.0 + PATCH → 0.19.2.0

4. 新しいバージョンを VERSION ファイルに書き込みます。

---

ステップ 5：CHANGELOG（自動生成）

1. 形式を確認するため、CHANGELOG.md のヘッダーを読みます。

2. ブランチ上のすべてのコミット（直近のコミットだけではありません）からエントリーを自動生成します。

   • 出荷対象のすべてのコミットを確認するには、git log main..HEAD --oneline を使用します
   • main との差分全体を確認するには、git diff main...HEAD を使用します
   • CHANGELOG エントリーには、PR に含まれるすべての変更を漏れなく記載する必要があります
   • ブランチ上の既存の CHANGELOG エントリーが一部のコミットをすでに網羅している場合は、それらを新バージョン用の統合エントリー1件に置き換えます
   • 該当するセクションに変更を分類します。
     • ### Added — 新機能
     • ### Changed — 既存機能の変更
     • ### Fixed — バグ修正
     • ### Removed — 削除された機能
   • 簡潔で内容が分かる箇条書きを記述します
   • ファイルヘッダーの後（5行目）に、今日の日付で挿入します
   • 形式：## [X.Y.Z.W] - YYYY-MM-DD

変更内容をユーザーに説明してもらわないでください。 差分とコミット履歴から判断します。

---

ステップ 6：コミット（git bisect しやすい単位）

目標： git bisect で適切に動作し、LLM が変更内容を理解しやすい、小さく論理的なコミットを作成します。

1. 差分を分析し、変更を論理的なコミットにまとめます。各コミットは一貫性のある変更を表すものにします。ファイル単位ではなく、論理的な単位でまとめてください。

2. コミットの順序（先に行うものから）：

   • インフラストラクチャ： マイグレーション、設定変更、ルートの追加
   • モデルとサービス： 新しいモデル、サービス、concern（テストを含む）
   • コントローラーとビュー： コントローラー、ビュー、JS／React コンポーネント（テストを含む）
   • VERSION と CHANGELOG： 必ず最後のコミットに含めます

3. 分割のルール：

   • モデルとそのテストファイルは同じコミットに含めます
   • サービスとそのテストファイルは同じコミットに含めます
   • コントローラー、そのビュー、テストは同じコミットに含めます
   • マイグレーションは独立したコミットにします（または、それを必要とするモデルとまとめます）
   • 設定／ルートの変更は、それを有効にする機能とまとめられます
   • 差分全体が小さい場合（4 ファイル未満にわたる 50 行未満）は、単一のコミットで構いません

4. 各コミットは単独で有効でなければなりません。壊れたインポートや、まだ存在しないコードへの参照を残してはいけません。依存関係が先に来るようにコミットを並べてください。

5. 各コミットメッセージを作成します：

   • 1 行目：<type>: <summary>（type = feat/fix/chore/refactor/docs）
   • 本文：そのコミットに含まれる内容の簡潔な説明
   • バージョンタグと共同作成者のトレーラーを含めるのは、最後のコミット（VERSION と CHANGELOG）のみです：

git commit -m "$(cat <<'EOF'
chore: bump version and changelog (vX.Y.Z.W)

Co-Authored-By: Codex Opus 4.6 <[email protected]>
EOF
)"

---

ステップ 7：プッシュ

上流の追跡設定を行ってリモートにプッシュします：

git push -u origin <branch-name>

---

ステップ 8：PR を作成

gh を使ってプルリクエストを作成します：

gh pr create --title "<type>: <summary>" --body "$(cat <<'EOF'
## Summary
<bullet points from CHANGELOG>

## Pre-Landing Review
<findings from Step 3.5, or "No issues found.">

## Eval Results
<If evals ran: suite names, pass/fail counts, cost dashboard summary. If skipped: "No prompt-related files changed — evals skipped.">

## Test plan
- [x] All Rails tests pass (N runs, 0 failures)
- [x] All Vitest tests pass (N tests)

EOF
)"

PR の URL を出力してください。これをユーザーが最後に目にする出力にします。

---

重要なルール

• テストを絶対に省略しないでください。 テストに失敗した場合は停止します。
• リリース前レビューを絶対に省略しないでください。 checklist.md が読み取れない場合は停止します。
• 強制プッシュは絶対にしないでください。 通常の git push のみを使用します。
• 確認を求めてはいけません。ただし、MINOR／MAJOR のバージョン更新、および CRITICAL なレビュー指摘については例外です（重大な指摘ごとに、修正案を添えてユーザーに直接質問を 1 つ行います）。
• 常に VERSION ファイルの 4 桁のバージョン形式を使用してください。
• CHANGELOG の日付形式： YYYY-MM-DD
• コミットは bisect しやすい単位に分割してください。各コミットは論理的な変更 1 つとします。
• 目標：ユーザーが ship と入力したら、次に目にするのはレビューと PR の URL です。