自動バグハンティング
微妙なバグの根本原因を素早く特定し、検証済みの修正を適用します。OpenCode はスタックトレースを読み、実行パスを追跡し、的を絞った変更を提案します。
このレシピを使う場面
- スタックトレースや失敗したテストはあるが、原因がはっきりしないとき。
- バグが断続的、あるいは並行処理に関わるとき。
- 推測ではなく、説明付きの修正が欲しいとき。
前提条件
- 失敗したテストケース、または信頼できる再現手順。
- プロジェクトで OpenCode を設定し、LSP を有効化済み。
手順
-
失敗シグナルを提供する
スタックトレースや失敗したテストコマンドをセッションに貼り付けます。
FAIL src/workers/queue.test.ts > Timeout: message processed twice under load -
根本原因分析を求める
このテストは負荷下で断続的に失敗します。プロデューサーからコンシューマーへのメッセージフローを追跡し、なぜメッセージが 2 回処理されるのかを見つけてください。
-
追跡結果を確認する
OpenCode はコールパスをたどり、正確な競合状態(例えば共有チャネル周りのミューテックス欠落)を指摘します。
-
修正を適用する
提案された変更(例:ロックの追加)を確認し、OpenCode に実装させます。
-
再現で検証する
負荷下でテストを再実行し、修正が有効か確認します。
npm test -- --grep queue
主要なプロンプト
これがスタックトレースです:[貼り付け]。コード内の実行パスを追跡し、根本原因を特定してください。副作用を伴わず、問題を解決する最小限の修正を提案してください。
よくある落とし穴
- 対症療法:まず根本原因を OpenCode に求めてください。表面的なパッチは別の場所のバグを隠す可能性があります。
- 並行処理のバグ:テストを何度も再実行してください——1 回の成功は競合が消えたことを証明しません。
- 環境固有のバグ:再現できない場合は、ログとタイミングの詳細を共有し、OpenCode がパスを推論できるようにします。
関連ドキュメント
- トラブルシューティング — OpenCode の一般的な問題と解決方法
- LSP 統合 — OpenCode が Language Server Protocol でコードを理解する仕組み
関連レシピ
- refactor-codebase —
reason.bug-hunting.to-refactor - remote-server-troubleshoot —
reason.bug-hunting.to-remote - git-commit-workflow —
reason.bug-hunting.to-git
関連ドキュメント
次のステップ
- remote-server-troubleshoot —
next.bug-hunting.to-remote