lint-fix

Lint と検証のパイプライン

プロジェクト内のすべての lint、フォーマット、検証ツールを検出し、 実行順序を定めたパイプラインを構築して、エラーがゼロになるまで すべてを実行し、問題を個別に修正します。

Step 1: プロジェクトのツールを検出する

プロジェクトのルートをスキャンし、設定ファイル、 Makefile のターゲット、パッケージマネージャーのスクリプトから 利用可能なツールを特定します。

次の順序で確認します。

1. Makefile — lint、test、validate、format、 gen、build、check、vet の各ターゲットを確認します
2. package.json — lint、test、format、 prettier、eslint、build、typecheck の各スクリプトを確認します
3. go.mod — golangci-lint、gofmt、go vet、go test を確認します
4. pyproject.toml / setup.py — ruff、black、flake8、 mypy、pytest を確認します
5. .csproj / .sln — dotnet format、build、test を確認します
6. Cargo.toml — cargo clippy、fmt、test を確認します
7. 単独の設定ファイル — .eslintrc*、.prettierrc*、biome.json、 .golangci.yml、.markdownlint* を確認します

エコシステムごとの詳しい検出コマンドについては、 references/tool-detection.md を参照してください。

ツールが検出されなかった場合は、ユーザーに報告し、lint の セットアップを支援できることを伝えます。空のパイプラインで 先に進んではいけません。

Step 2: コード生成を確認する

make gen、make generate、または同等のコード生成コマンドが 検出された場合は、lint を実行する前に実行します。

生成されたコードによって手動の修正が上書きされる場合があります。 必ず最初に生成してください。

make gen 2>&1

生成に失敗した場合は、lint に進む前に停止し、生成の問題を 修正してください。

Step 3: 実行順序を定めたパイプラインを構築する

検出したツールを、次の実行順序に並べます。

1. 生成（make gen、コードジェネレーター）
2. フォーマット（prettier、black、gofmt、rustfmt、dotnet format）
3. lint（eslint、golangci-lint、ruff、clippy、markdownlint）
4. 型チェック（tsc --noEmit、mypy）
5. 検証（make validate、スキーマチェック）
6. テスト（go test、pytest、jest、cargo test、dotnet test）
7. ビルド（go build、cargo build、dotnet build）

実行前に、検出したパイプラインをユーザーに提示します。

Detected validation pipeline:
  1. make gen
  2. gofmt -s -l .
  3. golangci-lint run
  4. markdownlint '**/*.md'
  5. go test ./...
  6. go build ./...

Proceed? (y/n)

ユーザーがコマンドの追加、削除、並べ替えを希望する場合は、 それに応じてパイプラインを調整します。

Step 4: パイプラインを実行する

各コマンドを順番に実行します。最初に失敗した時点で停止します。

# Run each command, stop on failure
for cmd in "${PIPELINE[@]}"; do
    echo "Running: $cmd"
    eval "$cmd" 2>&1
    if [ $? -ne 0 ]; then
        echo "FAILED: $cmd"
        # Proceed to atomic fix protocol for this command
        break
    fi
    echo "PASSED: $cmd"
done

修正に必要なファイルパス、行番号、ルール名、エラーメッセージを 含め、失敗したコマンドの出力全体を取得します。

Step 5: 問題を個別に修正する手順

失敗したコマンドで検出された問題を、一度に1つずつ修正します。 こうすることで、ある問題の修正によって別の問題が発生する 連鎖的な失敗を防げます。

問題ごとに、次の手順を実行します。

1. 問題を1つだけ修正します（変更は最小限にします）
2. 直ちに失敗したコマンドを再実行します
3. 確認します：問題が解決し、新たな問題が発生していないこと
4. 修正によって新たな問題が発生した場合は、元に戻して別の方法を試します
5. 修正に問題がなければ、次の問題に進みます

失敗したコマンドのすべての問題を解決したら、次のコマンドから パイプラインを続行します。

詳しい手順、ロールバック方法、特殊なケースについては、 references/fix-protocol.md を参照してください。

Step 6: 最終検証

すべてのコマンドが個別に成功したら、パイプライン全体を 1つの連続した実行として最初から最後まで実行します。

cmd1 && cmd2 && cmd3 && ... && echo "PASS" || echo "FAIL"

すべてのコマンドが順番に成功する必要があります。最終実行で コマンドが失敗した場合は、そのコマンドについて Step 5 に戻ります。

最終結果を提示します。

Validation pipeline: ALL PASSED

  1. make gen           PASS
  2. gofmt -s -l .      PASS
  3. golangci-lint run   PASS
  4. markdownlint        PASS
  5. go test ./...       PASS
  6. go build ./...      PASS

Zero errors across all validation tools.

よくある修正パターン

フォーマットの問題：--check の代わりに --write または -w フラグを 指定してフォーマッターを実行します。ほとんどのフォーマッターには 自動修正モードがあります。

インポート順序：ほとんどのリンターには、インポート順序を 自動修正する機能があります。--fix フラグがあるか確認してください。

末尾の空白／ファイル末尾の改行：エディターの設定で修正するか、 sed -i 's/[[:space:]]*$//' file を実行します。

型エラー：通常、自動修正ではなくコードの変更が必要です。 エラーを注意深く読み、根本原因を修正してください。

テストの失敗：失敗の原因を調査します。変更によって新たに 発生した実際のバグでしょうか、それとも以前からある不安定なテストでしょうか。