doctor

ステップごとの実行ループ

各ステップで、次の順序を厳守してください。

1. ステップを宣言します。
2. ステップを実行し、成功するまで失敗を修正します。
3. そのステップで行った変更を簡潔に報告します。
4. 次のステップに進みます。

宣言行の例：

Doctor: Step 2/3 - mix check

報告行の例：

Step 2 report: lib/surge/foo.ex - 未使用のエイリアスを削除し、副作用を after コールバック内に移動しました。

---

ステップ 1 - フォーマット

mix format

mix format を1回実行すれば、ツールで適用できるすべてのフォーマットが適用されます。2回目の実行が必要なのは、最初の実行が失敗した場合（たとえば構文エラーがある場合）、またはフォーマット後にファイルを変更した場合だけです。

---

ステップ 2 - mix check

mix check

---

ステップ 3 - コンパイルとテスト

• !!!絶対に厳守する重要ルール!!!： いかなる状況でも、単独の mix test を実行してはいけません。

• 対象範囲のみ： git diff --name-only "$(git merge-base HEAD origin/main)"...HEAD と git status --short で確認できるブランチ変更対象のパスのみです。

• テスト実行形式： 明示した *_test.exs ファイルの引数のみを指定します。ディレクトリは指定しません。リポジトリ全体のテストは実行しません。「念のため」の追加実行も禁止です。

• 対象として許可されるファイルのみ： ブランチの差分に含まれるテストファイル、または変更された lib/... モジュールに直接対応するテストファイル（パスの幹が同じもの）です。兄弟や隣接するテストは対象外です。

• 許可されたファイルがない場合： このステップをスキップします。

• 重要 - 修正対象の範囲はファイル単位ではなくテストケース単位です： 失敗したテストケースを修正できるのは、ブランチで変更されたアプリケーションコードと直接関係がある場合のみです。同じファイル内にあるその他の失敗は無視し、失敗したままにします。

• 対象範囲外の編集は禁止： 無関係なテストケース、無関係なテストファイル、または無関係な失敗を修正するための本番コードは変更しません。

• 編集前の必須確認： テストファイルを変更する前に、修正するテストケースを具体的に宣言し、そのケースに手を加える直接の根拠となるアプリケーションコードのパスとブランチ差分のハンクを示します。先にその根拠を示せない場合は、編集してはいけません。

• 変更したファイルの最終報告要件： 変更したテストケースごとに、失敗したケースの正確な内容、変更したアプリケーションコードの正確なパス、両者の直接的な関係を示す強い根拠を含めます。証明できない場合は編集してはいけません。

mix compile --warnings-as-errors

# optional:
mix test <file path>

---

メモ

• ループから抜け出せない場合や、大規模またはリスクの高い変更が必要な複雑な問題に直面した場合は、作業を中断し、ユーザーに助けを求めてください。
• Doctor は、リポジトリ全体をグリーンにするための実行ではありません。コンパイル、ブランチに関連するテストファイルのみのテスト実行、およびそれらのファイル内のブランチに関連するテストケースのみの編集を行います（同じファイル内のその他のケースは失敗したままでもかまいません）。これより広範な対応は誤りです。
• 再確認： いかなる状況でも、単独の mix test を実行してはいけません。