Ai Quality Gate

AI 品質ゲート

AI によるコード品質自動化のための MCP サーバー。

---

できること

AI がコードを書く → quality_fix を呼び出す → サーバーが修正可能な箇所を修正する → 残った問題を AI に報告する。

ハイブリッドアプローチ:

• フェーズ 1: ESLint + 627 ルール + Prettier(約 2〜8 秒、常に実行)
• フェーズ 2: SonarQube サーバー(約 30〜60 秒、任意)

重要: ESLint と Prettier の違い

ツール	ソース	設定
ESLint	プロジェクトの設定(存在する場合)または MCP の組み込み設定	.eslintrc.* / eslint.config.* / MCP 組み込み設定
Prettier	プロジェクト自身の設定	プロジェクトの prettier.config.mjs

ESLint のルールは、一貫した品質ゲートのために MCP が制御します。 Prettier はプロジェクトの設定を使用するため、フォーマットはプロジェクトの好みに一致します。

フェーズ 1 のルールカバレッジ:

プラグイン	ルール	説明
SonarJS	201	セキュリティ、バグ、コードスメル
Unicorn	127	モダン JS のベストプラクティス
ESLint Core	108	JavaScript の基礎
TypeScript-ESLint	99	TypeScript 固有のルール
RegExp	60	正規表現のベストプラクティス
Import	11	import/export ルール
Promise	10	async/await のベストプラクティス
Node.js (n)	9	Node.js 固有のルール
Unused Imports	2	未使用の import を自動削除
合計	627

---

インストール

前提条件

• PATH 上に Node.js 20.10+ または 21.1+ があること(node -v)。
• MCP が有効な Cursor、Antigravity、OpenCode(またはその他の MCP 対応エディタ)。

PROJECT_ROOT を省略した場合、プロジェクトルートは 自動検出 されます。サーバーは MCP プロセスの作業ディレクトリから上方向にたどり、package.json または tsconfig.json を見つけるまで探索します。推論されたルートとは異なるツリーを解析する場合にのみ、env で PROJECT_ROOT を設定してください。

---

MCP の設定(Cursor)

Settings → Tools & MCP → Edit(ユーザーの mcp.json)を開きます。サーバーブロックを 1 つだけ 追加してください。以下の例は .cursor/mcp.json.example に対応しています(コメント付きの JSONC — エディタがコメントを拒否する場合は、以下の JSON ブロックのみをコピーしてください)。

サーバー名とツール名: mcpServers 配下のキー(例: "ai-quality-gate")は、Cursor におけるその接続のラベルにすぎません。エージェントが呼び出す MCP の ツール は常に quality_fix です — この名前は本パッケージによって固定されており、サーバーキーや ai-quality-gate とは別のものです。

A) 推奨: npx(グローバルインストール不要)

常に公開されているパッケージを実行します。チームや CI 的なセットアップに適しています。

{
  "mcpServers": {
    "ai-quality-gate": {
      "command": "npx",
      "args": ["-y", "ai-quality-gate"]
    }
  }
}

B) 任意: グローバル npm インストール

npm i -g ai-quality-gate の後、ai-quality-gate バイナリが PATH 上にあります:

{
  "mcpServers": {
    "ai-quality-gate": {
      "command": "ai-quality-gate",
      "args": []
    }
  }
}

C) SonarQube(フェーズ 2)

実行中の SonarQube インスタンスと、利用可能な sonar-scanner(SonarQube のセットアップを参照)、および以下 3 つの変数すべてが必要です。フェーズ 1 は依然として最初に実行されます。

{
  "mcpServers": {
    "ai-quality-gate": {
      "command": "npx",
      "args": ["-y", "ai-quality-gate"],
      "env": {
        "SONAR_HOST_URL": "http://localhost:9000",
        "SONAR_TOKEN": "your_sonar_token",
        "SONAR_PROJECT_KEY": "your_project_key"
      }
    }
  }
}

D) 任意の環境変数（すべてのサーバー共通）

上書きが必要な場合は "env" オブジェクトを追加します。設定のマージ順は デフォルト → .quality-gate.yaml / .quality-gate.json → 環境変数 です。

変数	設定するタイミング
QUALITY_GATE_CONFIG	特定の .quality-gate.yaml または .quality-gate.json への絶対パス（ディレクトリの探索をスキップします）。
PROJECT_ROOT	自動検出があなたのレイアウトに合わない場合に、プロジェクトルートを強制指定します。
SONAR_HOST_URL	SonarQube サーバーの URL（フェーズ 2 と併用）。
SONAR_TOKEN	SonarQube トークン（フェーズ 2 と併用）。
SONAR_PROJECT_KEY	SonarQube プロジェクトキー（フェーズ 2 と併用）。
SONAR_SCANNER_PATH	sonar-scanner が PATH にない場合のフルパス。
PHASE1_TIMEOUT	フェーズ 1 のタイムアウト（ミリ秒）。デフォルトは 30000。
PHASE2_TIMEOUT	フェーズ 2 のタイムアウト（ミリ秒）。デフォルトは 300000。
ENABLE_I18N_RULES	true / false — i18n プロジェクト向けのより厳格な JSX リテラルチェック。

---

MCP の設定

Cursor、Antigravity など

{
  "mcpServers": {
    "ai-quality-gate": {
      "command": "npx",
      "args": ["-y", "ai-quality-gate"]
    }
  }
}

（OpenCode）

OpenCode の設定（通常は ~/.config/opencode/opencode.json またはプロジェクトレベルの設定）を作成または編集します：

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-quality-gate": {
      "type": "local",
      "enabled": true,
      "command": ["npx", "-y", "ai-quality-gate"]
    }
  }
}

必要に応じて、サーバー設定の下に環境変数を追加できます（上記の C) SonarQube（フェーズ 2） を参照してください）。

---

ローカル開発（このリポジトリ）

ドッグフーディングまたはコントリビュートするには：

1. yarn build — dist/server.js を生成します。
2. MCP をビルド済みファイル（絶対パス）に向けます：

{
  "mcpServers": {
    "ai-quality-gate-dev": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/ai-quality-gate/dist/server.js"]
    }
  }
}

3. MCP をリロードします。解析対象のリポジトリが推論されたルートと異なる場合にのみ env.PROJECT_ROOT を使用してください。

---

2. AI ルールを追加する

Settings → Rules and Commands → Add Rule：

After every code change, before telling the user "done",
AI must call the quality_fix MCP tool. This is mandatory.

3. 使ってみる

AI writes code → calls quality_fix → Fixes errors → "Done ✅"

---

コマンドライン: 対話形式の設定（--setup）

対話形式のウィザードは、手で編集することなく .quality-gate.yaml を作成または更新します。プロジェクトルート、任意の SonarQube（ホスト URL + プロジェクトキー。トークンはディスクに保存されません — 環境で SONAR_TOKEN を使用してください）、有効にするフェーズ 1 のツール（ESLint、波括弧 / アロー AST の修正ツール、Prettier、JSON バリデータ）、タイムアウト、i18n ルールについて順に案内します。生成されたファイルには、後から調整できる fixers: ブロックが含まれます。

yarn build の後（または npm からのインストール後）、対象プロジェクト（またはその配下の任意のパス）から実行します：

node dist/server.js --setup

PROJECT_ROOT は未設定の場合に推論されます（MCP の設定 を参照してください）。MCP サーバーと同じエントリポイント（node dist/server.js または npx ai-quality-gate）を使用してください。ウィザードモードに切り替わるのは --setup フラグだけです。プロンプトにはターミナルで回答します。成功すると、プロジェクトルートの隣にすぐに使える設定が得られます。

その他のコマンドラインモード： --check（読み取り専用のフェーズ 1）、--fix（コマンドラインの品質実行を使用する際のデフォルトの動作）、--phase1-only、--phase2-only — docs/DEVELOPMENT.md を参照してください。

---

任意: SonarQube サーバー（フェーズ 2）

上記の C) SonarQube（フェーズ 2） のように MCP で Sonar の環境変数を設定するか、.cursor/mcp.json.example からコピーしてください。解析にはマシンに sonar-scanner が必要です（以下を参照してください）。

SonarQube のセットアップ

Docker（推奨）

# Start SonarQube
docker run -d --name sonarqube -p 9000:9000 sonarqube:community

# First login: admin/admin → change password
# http://localhost:9000

Docker Compose

# docker-compose.yml
version: '3'
services:
  sonarqube:
    image: sonarqube:community
    ports:
      - '9000:9000'
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_logs:/opt/sonarqube/logs
      - sonarqube_extensions:/opt/sonarqube/extensions

volumes:
  sonarqube_data:
  sonarqube_logs:
  sonarqube_extensions:

docker-compose up -d

SonarQube トークンの作成

1. http://localhost:9000 → ログイン (admin)
2. My Account → Security → Generate Tokens
3. トークンタイプを選択: Global Analysis Token
4. トークンをコピー → SONAR_TOKEN として使用します

sonar-scanner のインストール

プラットフォーム	方法	コマンド
Windows	npm (グローバル)	npm install -g sonarqube-scanner
Windows	Chocolatey	choco install sonar-scanner
macOS	npm (グローバル)	npm install -g sonarqube-scanner
macOS	Homebrew	brew install sonar-scanner
Linux	npm (グローバル)	npm install -g sonarqube-scanner
Docker	コンテナ	docker run sonarsource/sonar-scanner-cli

カスタムパスの場合: SONAR_SCANNER_PATH 環境変数

---

設定

オプションのファイル (推測されたプロジェクトルートから上方向にたどって検出されます — package.json / tsconfig.json と同じアルゴリズム — または PROJECT_ROOT が設定されている場合はそこから): .quality-gate.yaml (推奨) または .quality-gate.json。環境変数と同じフィールド (camelCase) を持ちます。Sonar の設定は sonar: { hostUrl, token, projectKey, scannerPath } の下にネストできます。

マージ順序: デフォルト → 設定ファイル → 環境変数 (競合時は環境変数が優先されます)。

検出をスキップするには、QUALITY_GATE_CONFIG に明示的なパスを設定します。

カスタムルール (customRules)

リント可能なファイルに対するオプションの 行ベースの正規表現 チェック (フェーズ 1)。各マッチは、rule を custom:<id> に設定した問題として報告されます (quality_fix の remaining にも含まれます)。例:

customRules:
  - id: no-console
    message: 'Console.log is not allowed'
    pattern: 'console\\.log\\('
    severity: error
  - id: no-debugger
    message: 'Debugger statement found'
    pattern: 'debugger'
    severity: warning

パターンは JavaScript の RegExp ソースを使用します (YAML 文字列と同様にバックスラッシュをエスケープしてください)。無効なパターンはスキップされ、その旨が warnings に表示されます。

JSON バリデータと i18n ロケールファイル

fixers.jsonValidator が有効で、ロケールパターン (たとえば locales/en.json / locales/tr.json) に一致する JSON パスを渡すと、ツールはそれらのファイル間でキーを比較します。

• 構文エラー、無効な UTF-8 BOM など → issues として報告され、修正されるまでフェーズ 1 / quality_fix は 失敗 します。
• ロケールファイル間でキーの不足または余分 → バリデータ結果の i18nIssues として収集され、フェーズ 1 中に stderr の警告 として出力されます。これらは passed: false を設定せず、ゲートをブロックしません。

独自の CI チェックを追加しない限り、i18nIssues は参考情報として扱ってください。

---

環境変数

すべての変数は任意です。ただし、フェーズ 2 を使用する場合は例外で、SONAR_HOST_URL、SONAR_TOKEN、SONAR_PROJECT_KEY を一緒に指定する必要があります。

変数	説明	例
QUALITY_GATE_CONFIG	.quality-gate.yaml または .quality-gate.json ファイルへの絶対パス。設定探索のために親ディレクトリをたどる処理をスキップします。	/app/ci/quality-gate.yaml
PROJECT_ROOT	検出されたプロジェクトルートを上書きします。デフォルト: プロセスの cwd から親ディレクトリへさかのぼり、package.json または tsconfig.json が見つかるまで探索します。	/Users/me/my-repo
SONAR_HOST_URL	SonarQube サーバーのベース URL (フェーズ 2)。	http://localhost:9000
SONAR_TOKEN	SonarQube 認証トークン (フェーズ 2)。環境変数やシークレットストアを優先し、コミットは避けてください。	sqa_xxx...
SONAR_PROJECT_KEY	SonarQube プロジェクトキー (フェーズ 2)。	my-project
SONAR_SCANNER_PATH	sonar-scanner 実行ファイルが PATH 上にない場合のフルパス。	/opt/sonar-scanner/bin/sonar-scanner
PHASE1_TIMEOUT	フェーズ 1 のサブプロセスタイムアウト (ミリ秒)。	30000 (デフォルト)
PHASE2_TIMEOUT	フェーズ 2 (Sonar) のタイムアウト (ミリ秒)。	300000 (デフォルト)
ENABLE_I18N_RULES	true に設定すると、JSX 内の生の文字列リテラルを検出する ESLint ルールを有効にします (i18n を多用するアプリ向け)。	false (デフォルト)

---

自動修正

フェーズ 1 では、以下の問題を自動的に修正します。

ESLint 自動修正 (~100 以上のルール)

// var → const/let
var x = 1        →  const x = 1

// forEach → for...of (unicorn/no-array-for-each)
arr.forEach(x => f(x))  →  for (const x of arr) f(x)

// Nested ternary → extracted (unicorn/no-nested-ternary)
a ? b : c ? d : e  →  const temp = c ? d : e; a ? b : temp

// Unused imports removed
import { unused } from 'x'  →  (removed)

// Type imports (consistent-type-imports)
import { Type } from 'x'  →  import type { Type } from 'x'

// Optional chain (prefer-optional-chain)
a && a.b && a.b.c  →  a?.b?.c

// Regex optimization (regexp/*)
/[0-9]/  →  /\d/

AST 自動修正

// Remove unnecessary curly braces (single-line if)
if (x) { return true }  →  if (x) return true

Prettier フォーマット

ESLint の修正後、一貫したフォーマットを確保するために Prettier が実行されます。

// ESLint removes braces but leaves awkward format:
if (x) return true

// Prettier fixes to single line:
if (x) return true

Note: Prettier は MCP の設定ではなく、プロジェクトの設定を使用します。

それ以外: AI に報告され、AI が修正します。

---

API

ツール: quality_fix

// Input
{
  files: string[] // File paths to check
}

// Output
{
  phase: "local" | "server" | "complete",
  success: boolean,
  message: string,
  fixed: {                 // a FixSummary: edits on disk, kept even when findings remain
    eslint: number,          // ESLint auto-fixes
    curlyBraces: number,   // AST: single-statement if braces
    singleLineArrow: number, // AST: arrow body style
    prettier: number,      // Prettier formatting
    json: number           // JSON files validated (not an edit, so not part of fixedCount)
  },
  fixedCount: number,      // Edits on disk: the sum of `fixed`, without `json`
  attempted?: FixSummary,  // same fields as `fixed`: edits tried before a rollback, not on disk after a successful one
  attemptedCount?: number, // The sum of `attempted`
  warnings?: string[],     // Things the gate could not do that do not fail the run (a file a fixer skipped, a custom rule it could not apply)
  remaining: Issue[],      // Findings left to fix by hand. Line numbers refer to the files as they are now (line 0 = location unknown)
  remainingCount: number,  // remaining.length
  totalIssues: number,     // fixedCount + remainingCount
  error?: {                // Set when the run could not finish: e.g. ROLLBACK_FAILED, SONAR_API_ERROR, PERSISTENT_FAILURE
    code: string,
    message: string,
    details?: object       // ROLLBACK_FAILED: { unrestoredFiles, restoredFiles }
  },
  checks?: object,         // Raw typecheck and lint results, in read-only check mode
  timing: {
    phase1: string,
    phase2?: string,
    total: string
  }
}

失敗した実行がディスクに残すもの。 ゲートは適用できるすべての修正を適用し、それらを保持します。修正できない検出事項 (リントルール、カスタムルール、変更しても安全であると証明できない ==) は remaining に success: false とともに返されます。 保持された修正は fixed にカウントされます。実行がロールバックされるのは、修正ツール自体が何かを壊した場合のみです。 修正後の型エラー、コンパイラが拒否する Vue ファイル、ESLint や Prettier の実行失敗などです。その場合、 fixed はゼロになり、試行された編集は attempted にリストされます。そのロールバック自体が失敗した場合、レスポンスは ROLLBACK_FAILED になります。error.details.unrestoredFiles には編集がまだ残っている可能性のあるファイルがリストされ、phase は失敗したフェーズ、remaining は場所を含まない失敗内容です。SonarQube (フェーズ 2) の検出事項、または 到達不能なサーバーも、検証済みのフェーズ 1 の編集を元に戻すことはありません。それらは保持され、検出事項は remaining に返されます。

再試行。 同じ失敗が 3 回連続で変わらずに返ってきた場合 (同じファイル、同じ内容、同じ 検出事項)、MCP サーバーは error.code: "PERSISTENT_FAILURE" で応答し、呼び出し元に再試行をやめて 人間に尋ねるよう伝えます。ファイルを変更するか、検出事項が変わると、カウントは最初から始まります。fixedCount は編集のみをカウントします。JSON 検証パスは fixed.json にあり、修正には含まれません。

重複する呼び出し。 MCP サーバーは、ファイルセットが重複する quality_fix 呼び出しを、到着した順に 次々に実行するため、ある呼び出しのロールバックが別の呼び出しの保持された編集を古いコピーで上書きすることは決してありません。異なる ファイルに対する呼び出しは、引き続き並行して実行されます。

---

フィーチャーフラグ

ENABLE_I18N_RULES

国際化 (i18n) を行うプロジェクト向けに、リテラル文字列の検出を有効にします:

{
  "env": {
    "ENABLE_I18N_RULES": "true"
  }
}

有効にすると:

// ⚠️ Warning
<h1>Hello World</h1>

// ✅ OK
<h1>{t('hello')}</h1>

---

トラブルシューティング

MCP: quality_fix が表示されない

1. Node.js 20.10+ または 21.1+ — node -v と npx --version を実行してください。
2. mcp.json を編集した後、Cursor をリロードしてください (または MCP の更新コントロールを使用してください)。
3. JSON — ファイルは有効な JSON である必要があります (末尾のカンマは不可)。不明な場合は MCP 設定 セクションからコピーしてください。
4. グローバルインストール — "command": "ai-quality-gate" を使用する場合は、バイナリが存在するように npm i -g ai-quality-gate を一度実行してください。

Windows

「npx not found」エラー:

# Node.js must be in PATH
# Check in PowerShell:
where.exe npx

Permission denied:

# Run PowerShell as Administrator

macOS / Linux

「Permission denied」エラー:

# Fix npm global directory
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

「sonar-scanner not found」エラー:

# Install via Homebrew
brew install sonar-scanner

# Or via npm
npm install -g sonarqube-scanner

SonarQube

「Insufficient privileges」エラー:

• SonarQube → Administration → Security → Global Permissions
• Anyone グループに Browse および Execute Analysis 権限を付与してください

「Project not found」エラー:

• 最初の解析のためにプロジェクトを手動で作成してください: Projects → Create Project → Manually

---

クローンとビルド (コントリビューター向け)

git clone https://github.com/mustafacagri/ai-quality-gate.git
cd ai-quality-gate
yarn install
yarn build

dist/server.js を指す MCP には ローカル開発 (このリポジトリ) を使用してください。

---

ドキュメント

• SETUP.md — ローカルセットアップ (ツリーに含まれている場合)
• AGREEMENTS.md、docs/ARCHITECTURE.md など — 任意。最小限のクローンでは一部のファイルが省略されている場合があります。公開パッケージを実行するには README + .cursor/mcp.json.example で十分です。

---

原則

• ✅ 627 個の ESLint ルール (SonarJS、Unicorn、TypeScript-ESLint など)
• ✅ Prettier 統合 (プロジェクトの設定を使用)
• ✅ AST ベースの変換 (正規表現なし)
• ✅ 各修正後の検証
• ✅ エラー時のロールバック
• ✅ ESLint 設定の検出 (利用可能な場合はプロジェクト設定を使用、そうでなければ組み込み)
• ✅ ワークアラウンドゼロ
• ✅ プリンシパルレベル

---

ライセンス

MIT © Mustafa Çağrı Güven

---

v0.0.1 — 初回リリース! MCP quality_fix、フェーズ 1/2 パイプライン、CLI、設定ファイル、カスタムルール (CHANGELOG を参照)

読み取り専用のローカル検証

読み取り専用のローカル検証には ai-quality-gate --check --phase1-only <selected-file ...> を実行してください。ESLint は明示的に選択された実際の .js、.jsx、.mjs、.cjs、.ts、.tsx、.mts、.cts、.vue パスのみをチェックします。これには実行可能な JS 設定ファイルや TS 宣言も含まれます。インポートを通じて lint の対象範囲を拡大することはありません。 .vue ファイルはその場で lint されます。vue-eslint-parser は <script> および <script setup> にのみ script ルールを適用します。テンプレートとスタイルは JavaScript ではないため、抽出された script ファイルは書き出されません。@vue/compiler-sfc の parse() および compileScript() の失敗は診断として扱われます。構造的に不正な SFC は ESLint より前に失敗するため、終了タグの欠落が未使用バインディングとして報告されることはありません。 AST 編集はアロー関数のシグネチャを維持し、ブレースのない if をセミコロンで終端します。Prettier が有効な場合、SFC 全体をフォーマットします。削除されたエンドポイントと古いリネームエンドポイントは、呼び出し元がまずそれらのベースコンテンツとエンドポイントの同一性を保持したうえで、分離されたスナップショット内に実ファイルとして具体化する必要があります。

TypeScript は --noEmit を指定して、最も近い tsconfig.json のプロジェクトコンテキスト全体をチェックします。これにはインポートやその他のプロジェクトファイルが含まれる場合があり、ESLint の選択範囲を拡大することはありません。TypeScript スクリプト（lang="ts" または tsx）を持つ .vue ファイルは vue-tsc でチェックされ、そのテンプレート式もチェックされます。.vue ファイルをコンパイルするプロジェクトは、その .ts ファイルにも vue-tsc を使用するため、それらは .vue モジュールをインポートできます。プロジェクトが .vue ファイルをコンパイルするものと見なされるのは、その include がいずれかに一致する場合、または最も近い package.json が vue に依存している場合です。プロジェクトとは、そのファイルを含む tsconfig のことです。references のみを列挙する create-vue スタイルのルート設定の場合、それは参照先のプロジェクトであり、どのプロジェクトにも列挙されていないが参照先のプロジェクトがインポートしている共有ヘルパーなどのファイルは、そのプロジェクトでチェックされます。どの tsconfig にも含まれない .vue ファイルは、未チェックのまま通るのではなく失敗します。プレーンな JavaScript の .vue ファイルは、.js ファイルと同様に型チェックされません。これは .ts ファイルにも当てはまります。どの tsconfig にも直接的またはインポートを通じて含まれないファイルは、未チェックのまま通るのではなく「Not included by 」で失敗します。プログラム内のどこかで型エラーが発生するとチェックは失敗し、それらはすべて報告されます（選択されたファイル内のものが最初に、最大 50 件）。プレーンな JavaScript の <script> は .js ファイルに適用されるルールで lint され、lang="ts" のものは TypeScript ルールで lint されます。型認識 ESLint ルール（no-floating-promises など）は .vue ファイルには適用されません。これは意図的な選択であり、パーサーの制約ではありません。TypeScript の増分メタデータはプロジェクト外の一時フォルダーにリダイレクトされ、チェック後に削除されます。チェックモードによってソース、設定、ロックファイル、制御ファイルが書き換えられることはありません。MCP の quality_fix ツールは引き続き変更操作です。読み取り専用の作業には CLI チェックインターフェースを使用してください。

埋め込み設定は TS ソースに対して typescript-eslint の recommendedTypeChecked と projectService を使用します。TS ファイルは実際の tsconfig プロジェクトに属している必要があります。JavaScript ファイルは非型付き lint プロファイルを使用します。型エイリアスを含む名前付きインポートのエイリアスは AST ルールでチェックされ、変更されていない名前付きインポートは許可されます。警告は厳格な検証（--max-warnings 0）で失敗します。ローカルチェックの JSON には checks.typecheck が含まれ、到達した場合は checks.lint も含まれ、PASS/FAIL/ERROR ステータス、チェックされたプロジェクト、実際の lint 結果パスが示されます。既存のフェイルファストパイプラインは、型チェックまたはカスタムルールの失敗後、lint の前に停止できます。 終了コード 0 は到達したすべてのチェックが成功したことを意味し、終了コード 1 は実際のコード上の指摘を報告し、 終了コード 2 は設定、プロセス、パーサー、またはカバレッジのエラーを報告します。lint 出力が空または不正な形式、 選択したファイルの欠落、予期しない/重複した結果パス、致命的なパーサー障害、および失敗したサブプロセスは、 成功したチェックにはなれません。 インストールされたパッケージには、埋め込みのパーサー、lint プラグイン/リゾルバー、および TypeScript ランタイム依存関係が含まれています。対応する Node のバージョンは ^20.10.0 || >=21.1.0 であり、 維持されている lint 依存関係のベースラインが要求する共通部分です。