cekura-fixing-prod-issues

本番通話の問題を修正する

一連のワークフロー — まずデバッグし、修正前に再現し、徹底的にテストしてから、PR を作成します。

Phase 1      Phase 2         Phase 3     Phase 4        Phase 5        Phase 6
Debug   →   Reproduce   →   Fix    →   Verify    →   Regression  →   PR
Understand   Confirm bug     Write the   Same eval      Happy paths    All result
root cause   on Cekura       code fix    must PASS      + edge cases   URLs in PR
             BEFORE fix      + commit    now            pass too

6 つのフェーズ

フェーズ	ファイル	内容
1	phase1-debug.md	本番の通話とログを取得し、根本原因を特定して、ユーザーに確認します
2	phase2-reproduce.md	評価器を作成し、メトリクスを設定して実行します — 修正に着手する前に、評価が必ず失敗しなければなりません
3	phase3-fix.md	コードを修正し、ローカルでコミットします
4	phase4-verify.md	同じ評価器を再実行します — 今度は評価が必ず合格しなければなりません
5	phase5-regression.md	影響を受けるすべての正常系とエッジケースをテストします
6	phase6-pr.md	Cekura のすべての結果 URL を添えて PR を作成します

---

厳守ルール — 開始前にお読みください

これらのルールは交渉の余地がありません。ゲートを満たすまでは先に進まないでください。

ルール 0 — 本番の通話と同じ接続方式を使用します。例外はありません。

再現、検証、回帰テストはすべて、エージェントに設定されているものと同じトランスポートを使用し、Cekura 上でエンドツーエンドのシミュレーションとして実施しなければなりません。 エージェントのレコード（GET /test_framework/v1/ai-agents/{id}/）を取得し、トランスポートを確認してください。多くの場合はテレフォニーですが、実際にエージェントに設定されているものに従ってください。

❌ テキストモードで代用することはできません。❌ フェーズ間でトランスポートを切り替えないでください。

問題は実際の通話経路にあります。同じ接続方式を使ったシミュレーションでのみ確認できます。

ルール 1 — フェーズは順番に進めます。飛ばしてはいけません。

各フェーズにはゲートがあります。ゲートを通過したとみなすには、推測ではなく証拠が必要です。この順序が設けられている理由は次のとおりです。

• 根本原因を理解しなければ、適切な修正は書けません（フェーズ 1 のゲート）
• 管理された方法で問題の存在をまず証明しなければ、修正を信頼できません（フェーズ 2 のゲート）
• 修正の検証に合格しなければ、回帰テストに意味があるとは言えません（フェーズ 4 のゲート）

ルール 2 — フェーズ 2 は最も厳しいゲートです。特に注意してください。

問題の再現は最も重要なステップです。Cekura 上でメトリクススコアに失敗が示され、評価が明確に失敗するまで、フェーズ 3 に進んではいけません。 問題を本当に再現できたかどうか少しでも不確かな場合は、作業を止めてユーザーに尋ねてください。推測してはいけません。

ルール 3 — 迷ったら尋ねてください。

使用するメトリクス、根本原因の正しさ、エッジ条件の妥当性、結果の曖昧さについて少しでも不確かな場合は、作業を止めてユーザーに尋ねてください。ここで誤った前提を置くと、ワークフロー全体が無駄になります。

ルール 4 — フェーズ 5 が完了するまで、コードをプッシュしてはいけません。

コミットはフェーズ 3 で行います。プッシュするのは、フェーズ 5 ですべての回帰テストに合格した後だけです。