rails-bug-triage

Rails のバグトリアージ

バグ報告はあるものの、適切な再現手順と修正の順序がまだ明確でない場合に、このスキルを使用します。

基本原則： 修正を推測で決めないでください。バグを再現し、適切な失敗するスペックを選んでから、最小限で安全な修正を計画します。

プロセス

1. 報告内容を整理する： 期待される動作、実際の動作、再現手順を言い換えて明確にします。
2. 範囲を絞る： 問題がリクエスト処理、ドメインロジック、ジョブ、エンジン統合、外部依存関係のどこに現れているかを特定します。
3. 現時点の根拠を集める： ログ、エラーメッセージ、境界値入力、最近の変更、ガードの不足などを確認します。
4. 最初に失敗するスペックを選ぶ： ユーザーまたは運用担当者がバグを確認できる境界を選びます。
5. 最小限の修正手順を定める： 該当しそうなファイルと、スペックを通すために必要な最小限の動作変更を示します。
6. 引き継ぐ： rails-tdd-slices → rspec-best-practices → 実装スキルの順に進めます。

トリアージの出力

次の形式で調査結果を返します。

1. 確認された動作
2. 期待される動作
3. 可能性の高い境界
4. 追加すべき最初の失敗するスペック
5. 最小限で安全な修正手順
6. 後続のスキル

例（ステータスコードの誤り）：

1. Observed:  POST /orders returns 500 when product is out of stock
2. Expected:  Returns 422 with { error: "Out of stock" }
3. Boundary:  Request layer — visible in HTTP contract
4. First spec: spec/requests/orders/create_spec.rb
5. Fix path:  Orders::CreateOrder should return { success: false, error: "Out of stock" }
              when inventory check fails; controller renders 422
6. Next:      rails-tdd-slices → write request spec → rspec-best-practices → fix

失敗するスペックのひな形：

# spec/requests/orders/create_spec.rb
RSpec.describe "POST /orders", type: :request do
  context "when product is out of stock" do
    let(:product) { create(:product, stock: 0) }

    it "returns 422 with an error message" do
      post orders_path, params: { order: { product_id: product.id, quantity: 1 } }, as: :json
      expect(response).to have_http_status(:unprocessable_entity)
      expect(response.parsed_body["error"]).to eq("Out of stock")
    end
  end
end

修正を実装する前に実行します：bundle exec rspec spec/requests/orders/create_spec.rb

境界のガイド

バグの種類からスペックの種類への対応関係と、レイヤーの診断に関するヒントについては、BOUNDARY_GUIDE.md を参照してください。

クイックリファレンス：

バグの種類	最初に作成する可能性が高いスペック
HTTP の症状（ステータス、JSON、リダイレクト）	リクエストスペック
データの症状（値の誤り、バリデーション）	モデルまたはサービスのスペック
タイミングの症状（ジョブ、メールの未送信）	ジョブスペック
エンジンのルーティング／ジェネレーターのリグレッション	ダミーアプリ内のエンジンスペック

注意点

注意点	対応方法
リクエストレベルで見えるバグに対してユニットスペックを使う	実際に障害が確認される箇所から始めます
再現、リファクタリング、新機能をまとめて扱う	最小限で安全な範囲だけでバグを修正します
不安定な根拠を修正のゴーサインとみなす	コードに手を加える前に、再現を安定させます
説明に「おそらく」や「たぶん」が含まれる	曖昧さが残るなら、再現手順がまだ完了していません

統合

スキル	次に使うタイミング
rails-tdd-slices	バグに対して最も有効な最初の失敗するスペックを選ぶとき
rspec-best-practices	スペックを選んだ後、TDD のループを正しく実行するとき
refactor-safely	バグがリスクの高いリファクタリング領域にあり、まず動作を維持する必要があるとき
rails-code-review	最終的なバグ修正にリグレッションやカバレッジ不足がないかレビューするとき
rails-architecture-review	バグから、より深い境界やオーケストレーションの問題が示唆されるとき

アセット

• assets/examples.md