quality-enforcement

品質の強制

概要

品質の強制は自動化するものであり、努力目標ではありません。機械でチェックできるものは、すべてチェックする必要があります。

基本原則： CI で強制されない品質チェックは、存在しないも同然です。

例外なし。回避策なし。近道なし。

最優先の指針

NO CODE LANDS WITHOUT ALL QUALITY CHECKS PASSING

チェックに失敗したら、コードを修正してください。チェックを無効にしてはいけません。CI を回避してはいけません。

使用するタイミング

必ず次の前に実施してください：

• コードをコミットする
• プルリクエストを作成する
• trunk にマージする
• 本番環境にリリースする

特に次のような場合：

• 「今回だけリンターを抑制しよう」（絶対にしない）
• 「CI が遅すぎるので、手動でマージしよう」（CI を修正し、スキップしない）
• 「型エラーはあるけれど、実行時には動く」（型を修正する）
• 「重要な経路はテストされているので、カバレッジが下がってもよい」（カバレッジを回復する）

実行プロトコル

BEFORE any PR or merge:

1. LINT: Zero errors, zero warnings
2. TYPES: Zero type errors (strict mode)
3. TESTS: All passing, coverage meets threshold
4. BUILD: Clean build, no warnings
5. SIZE: Bundle/binary within budget (if applicable)
6. DEPS: No known vulnerabilities (critical/high)
7. COMPLEXITY: No functions exceeding complexity threshold

Any check fails = code is not ready. Fix before advancing.

品質チェックのリファレンス

チェック 1：リンティング

Standard: Zero errors AND zero warnings

設定	値	理由
エラー	0	譲れない基準
警告	0	警告は、無視することに慣れてしまうエラーになります
設定をコミットする	はい	すべてのコントリビューター間で一貫性を保つため
CI で強制する	はい	ローカルでの上書きは関係ありません

警告はいずれエラーになります。 修正するか、ルールを調整してください。警告を放置してはいけません。

ルールを無効にする場合： チームが、そのルールはこのプロジェクトに適さないと明示的に合意した場合に限ります。理由を設定ファイルに記録してください。便宜上、インラインで無効にしてはいけません。

チェック 2：型安全性

Standard: Zero type errors, strict mode enabled

TypeScript：

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "forceConsistentCasingInFileNames": true
  }
}

Python： strict モードで mypy または pyright を使用します。

アンチパターン	問題	修正
any 型	型チェックが無効になる	具体的な型またはジェネリクスを使用する
// @ts-ignore	実際のエラーが隠される	型エラーを修正する
# type: ignore	同じ問題	型エラーを修正する
strict ではないモード	安全だという誤った安心感	最初から strict を有効にする

any は、解決しないと自分で選んだ型エラーです。 any を使うたびに、その影響を受けるすべてのものについて型システムが弱まります。

チェック 3：テストカバレッジ

Standard: Coverage threshold that never decreases

指標	下限	目標
行カバレッジ	80%	90%+
分岐カバレッジ	70%	85%+
新規コードのカバレッジ	90%	100%（目指す値）

カバレッジのしきい値は、引き上げていくものです。 引き上げることはあっても、引き下げてはいけません。カバレッジが現在の水準を下回ったら CI が失敗するように設定してください。

カバレッジは必要ですが、それだけでは十分ではありません。アサーションが不十分な 100% のカバレッジは、厳密なアサーションを伴う 70% のカバレッジよりも質が低いです。カバレッジチェックは TDD の規律（godmode:test-first）と組み合わせてください。

チェック 4：ビルド

Standard: Clean build, zero warnings

• ビルドが正常に完了すること
• コンパイラー／ビルドの警告がゼロであること
• 出力が期待される構造と一致すること
• ビルド時に依存関係が不足していないこと

チェック 5：バンドルサイズの予算（フロントエンド）

Standard: Total bundle size within defined budget

対象	予算	ツール
初期 JS（圧縮後）	<200KB	webpack-bundle-analyzer
CSS	<50KB	PurgeCSS check
画像	最適化済み、WebP/AVIF	imagemin
ページ全体の容量	<1MB	Lighthouse

予算を設定し、CI で強制してください。 予算を超過したら、バンドルの内容を分析し、削除するか分割してください。

チェック 6：依存関係の監査

Standard: Zero critical or high vulnerabilities

言語	コマンド	CI との統合
JavaScript	npm audit --audit-level=high	high 以上で失敗
Python	pip-audit または safety check	high 以上で失敗
Go	govulncheck ./...	いずれかの検出で失敗
Rust	cargo audit	いずれかの検出で失敗

次の点も確認してください：

• 不要な依存関係がないこと（各依存関係は実際に使われていますか？）
• 重複する依存関係がないこと（同じパッケージの異なるバージョン）
• 依存関係が保守されていること（最終更新が 12 か月以内）

チェック 7：複雑度メトリクス

Standard: No function exceeds complexity threshold

メトリクス	しきい値	ツール
循環的複雑度	関数あたり <10	ESLint（complexity ルール）、radon、gocyclo
関数の長さ	<50 行	リンターのルール
ファイルの長さ	<400 行	リンターのルール
パラメーター数	関数あたり <5	リンターのルール

複雑度がしきい値を超えた場合： リファクタリングします。関数を切り出します。条件分岐を簡素化します。しきい値を引き上げてはいけません。

チェック 8：デッドコード

Standard: No unused exports, variables, or dependencies

対象	ツール
未使用のエクスポート	ts-prune、knip
未使用の依存関係	depcheck、knip
未使用の変数	リンター（no-unused-vars）
到達不能なコード	リンター、型チェッカー

デッドコードは誤解を招くコードです。何かが依存しているように見せてしまいます。削除してください。

CI パイプラインテンプレート

# Minimum quality enforcement pipeline
quality-checks:
  steps:
    - name: Lint
      run: npm run lint
    - name: Type Check
      run: npm run typecheck
    - name: Test
      run: npm test -- --coverage
    - name: Coverage Check
      run: check-coverage --threshold 80
    - name: Build
      run: npm run build
    - name: Bundle Size
      run: bundlesize
    - name: Audit
      run: npm audit --audit-level=high

すべてのチェックを、すべての PR で実行します。マージする前に、すべて合格する必要があります。

認知の落とし穴

合理化	実際
「ただのリンター警告で、エラーではない」	無視した警告が、見逃すエラーになります。
「型エラーだが、実行時には動く」	型があれば、まだ遭遇していない実行時エラーを防げます。
「カバレッジが 1％下がっただけで、大したことではない」	PR ごとに 1％下がると、1 年で 50％になります。ラチェットは下がりません。
「CI をスキップしても、ローカルでテストした」	ローカル環境は CI と異なります。だから CI があるのです。
「機能を追加したから、バンドルサイズが増えた」	機能は追加するだけでなく、置き換えるか分割するべきです。
「脆弱性は開発用依存関係にある」	開発用依存関係は CI で実行されます。CI にはシークレットがあります。それでもリスクです。
「関数は複雑だが、読みやすい」	読みやすさは主観的だからこそ、複雑度の上限があるのです。
「デッドコードは後で必要になるかもしれない」	Git が記録しています。削除してください。必要なら履歴から復元できます。

ガードレール — HALT して修正

• 根拠を文書化せずに、リンターのルールをインラインで無効にする
• 関連する課題を添えずに @ts-ignore または # type: ignore を使う
• 設定ファイルでカバレッジのしきい値を下げる
• マージのために CI をスキップまたは回避する
• any 型がコードベース全体に広がる
• 調査せずにバンドルサイズが増加する
• 警告を許容可能なものとして扱う
• 「開発用依存関係だから」という理由で監査の失敗を退ける

これらはすべて、チェックが壊れていることを意味します。コードをさらに書く前に、チェックを修正してください。

統合

相互補完：

• godmode:test-first — テストは数あるチェックの 1 つです
• godmode:completion-gate — 品質チェックは検証の証拠です
• godmode:project-bootstrap — プロジェクトのセットアップ時にチェックを設定します
• godmode:security-protocol — 依存関係の監査はセキュリティチェックです
• godmode:performance-tuning — バンドルサイズはパフォーマンスチェックです

要点

Every quality check automated in CI. Every check passing before merge. No exceptions.

チェックを回避できるなら、いずれ回避されます。回避できないようにしてください。