コンテンツにスキップ
OmniRoute Docs

言語を選択

現在の言語: 日本語

OmniRoute source

Quality-Gate System — Critical Assessment, Catalog and Replication Playbook (日本語)

パート 1 — 評価と成熟度分類

Section titled “パート 1 — 評価と成熟度分類”

総合評価: A− /「Advanced」。プロジェクトの上位約 5～10%。 このシステムは、業界で明確に名前が付けられている複数のパターンを独自に実装しています。これは最も強い整合性のシグナルです（チェックリストを模倣したのではなく、適切なプラクティスへ独自に収束しました）。

参照フレームワーク 現在の位置付け 評価
OWASP DSOMM（5 レベル、5 次元） 堅実なレベル 3 で、_テスト強度_と_静的解析の深度_ではレベル 4 に到達しつつあります。ほとんどの組織はレベル 1～2 にとどまっています。 L3→L4
OpenSSF Scorecard（18 項目） CI-Tests、Code-Review、Dependency-Update-Tool、Fuzzing、SAST、Signed-Releases（プロベナンス）、Token-Permissions、Vulnerabilities、Dangerous-Workflow に合格しています。ギャップ: main の Branch-Protection が無効。一部のアクションが固定されていません。 ~7–8/10
SLSA（4 レベル） npm publish --provenance + id-token: write + GitHub ホスト型ビルド = L2 で、L3 に近づいています。L3+ に必要な、強化された再現可能なビルダーがありません。 L2→L3
SonarQube「Clean as You Code」 哲学は同一です。ラチェットは_非回帰_（新しいコードによってメトリクスが悪化しないこと）をゲートします。相違点: Sonar は条件を少数にすることを推奨していますが、こちらには約 46 個のゲートがあります（疲弊のリスク）。 整合、ただし留意点あり
Quality-Ratchet パターン 参照実装に相当します: ラチェット + dedicatedGate + tightenSlack + --require-tighten + グレースフルスキップ。公開されている大半の例よりも高度です。 模範的
DORA 2024 _安定性_の軸では非常に強力です。リスクとして、重いゲートが_リードタイム_を増大させる可能性があります。これは高速ゲートの分離によって緩和されていますが、カバレッジのギャップがあります（パート 2 を参照）。 強力（安定性）
OWASP LLM Top 10 (2025) リスク #1（プロンプトインジェクション）を、ランタイムガード + promptfoo（評価）+ garak（レッドチーム）でカバーしています。いずれも業界標準のツールです。 対応済み
ミューテーションテスト Stryker を夜間実行し、しきい値は 70/50、対象は 8 個の重要モジュールです。業界のコンセンサス（既存コード 60% / 新規コード 80%、夜間実行）を上回っています。ギャップ: スコアはまだラチェット化されていません。 あと一歩

パート2 — クリティカル評価（強み + 率直な弱み）

Section titled “パート2 — クリティカル評価（強み + 率直な弱み）”

強み（平均以上の点）

Section titled “強み（平均以上の点）”
  1. マルチメトリクス・ラチェットエンジン。 システムの中核。quality-baseline.json に24個のメトリクス
    • 4つの専用ベースラインがあり、それぞれ方向（up/down）、許容値（eps）、余裕値 （tightenSlack）、dedicatedGate フラグを備えています。一度修正されたものは、修正された状態に維持されます。これは コードベースのエントロピーに対する解毒剤です。
  2. サプライチェーンに対する多層防御。 SAST（CodeQL/Sonar）+ シークレット検出（useDefault を使用するgitleaks）
    • SCA（osv/npm-audit/Trivy/Dependabot）+ ライセンス + ロックファイル + SBOM + SLSA provenance + Scorecard + ワークフローの堅牢化（zizmor）。これほど完全なスタックを備えたコードベースはほとんどありません。
  3. グッドハートの法則への対抗策。 カバレッジを目標にすることは、典型的なアンチパターンです （「測定指標が目標になると、それは良い測定指標ではなくなる」）。本システムには、 それを補う仕組みとして、ミューテーションテスト（単に行が実行されたかではなく、テストがバグを検出できるかを測定）、 check-test-masking（通過させるためにアサーションを弱めることを阻止）、 モジュール単位のカバレッジ下限（簡単な部分だけでなく、リスクの高いコードのテストを強制）、および check-pr-evidence（ハードルール #18）があります。
  4. ハルシネーション防止／整合性ゲート。 希少かつ価値の高いカテゴリです。check-known-symbols、 check-fetch-targets、check-openapi-routes、check-docs-symbols により、ドキュメント、仕様、 文字列によるディスパッチが実在するシンボルを参照していることを保証します。lint/testでは検出できない「腐敗」を捉えます。
  5. アドバイザリ→ブロッキングのライフサイクル。 新しいゲートはアドバイザリとして導入され （成熟するまではマージをブロックしない）、サイクル終了時にブロッキングへ移行します。品質上限を失うことなく摩擦を軽減します。
  6. インフラ欠如時の穏当なスキップ。 スキャナー（--ratchet）は、バイナリ／ネットワークに 問題がある場合、exit 0 で終了します。インフラの欠如によって正当なPRがブロックされることはありません。成熟したエンジニアリングです。
  7. 文化のコード化。 ハードルール + trust-but-verify + stale-allowlist + evidence-gateにより、 規律を自動検証へと変換しています。

率直な弱み（実在するギャップ）

Section titled “率直な弱み（実在するギャップ）”
  1. 🔴 fast-gatesの分割には、依然として構造的な穴があります。 quality.yml（PR→release/**）では現在、 コードPRに対してtypecheck、高速な決定論的テスト、およびアドバイザリの本番ビルドを実行していますが、 ci.yml のrelease PR向け検証全体（カバレッジ・ラチェット、パッケージ成果物、インテグレーション、 E2E、SonarQube）は依然として実行されません。動機（速度）は妥当ですが、ゲートはマージが行われる場所に 設けるべきです（シフトレフト）。未解決の構造的修正として最大の課題です。
  2. 🟠 ゲートの乱立／疲弊リスク。 約46個のゲート + 25個のジョブは、非常に多いです。Sonar自身も、 条件が多すぎると「ゲート疲れ」や優先順位を巡る議論が生じ、ゲートが無視されるリスクがあると警告しています。 DORAも、重いゲートはリードタイムを悪化させると警告しています。アドバイザリ階層と絶対値ではないラチェットによって 緩和していますが、ゲートごとの定期的なROIレビューが欠けています（ドキュメント同期用の一部の小規模ゲートは統合可能です）。
  3. 🟠 ミューテーションスコアは、まだラチェット化されていません。 カバレッジのゲーミングに対する最も強力な対抗策が アドバイザリのままです。これは最も価値の高い未完了項目です（すでに90%完成しています）。
  4. 🟡 ブロッキングにすべきアドバイザリ（適切なスコープ設定が前提）。 osv（vulnCount）とoasdiffは、 ベースラインが固定されているにもかかわらずアドバイザリです。osvをアドバイザリにすることには合理性があります （古い依存関係に新しいCVEが見つかると、無関係なPRまでブロックされるため）が、中間的な選択肢もあります （Trivyで行ったように、CRITICAL以上かつ修正可能なものだけをブロックする）。oasdiffがアドバイザリであるため、 コントラクトを破壊する変更が通過する可能性があります。
  5. 🟡 ランタイムセキュリティは夜間実行のみです。 schemathesis/garak/promptfoo/chaos/k6は夜間に実行されます。 これは正しい判断です（低速で、稼働中のサーバーが必要）が、PRによってインジェクション防御のリグレッションが 混入し、翌晩になって初めて検出される可能性があります。
  6. 🟡 main のブランチ保護が無効です。 BRANCH_LOCK_TOKEN は_release_ブランチをロックしますが、 main 自体は保護されていません。Scorecard/DSOMMで減点されます。オーナーによる対応が必要です。
  7. 🟡 CodeQLはdefault-setupで、semgrepはコード化されていません。 default-setupは機能しています （アラート0件）が、コミットされたcodeql.ymlがあれば、より詳細に制御できます。semgrepはリポジトリ内で バージョン管理されておらず、外部クラウドプラットフォーム経由で実行されています。

パート3 — 品質チェックポイントの完全なカタログ（移植可能）

Section titled “パート3 — 品質チェックポイントの完全なカタログ（移植可能）”

以下の12カテゴリは、再利用可能な形に整理した「品質システム」です。それぞれに、 目的（何を守るか）、使用するツール、そして任意の技術スタックで再現するためのツール非依存の同等手法 を示します。

1. スタイルとフォーマット（決定的・高速）

Section titled “1. スタイルとフォーマット（決定的・高速）”
  • OmniRoute: lint-staged（pre-commit）経由のPrettier + ESLint、スペース2個／ダブルクォート／100col。
  • 汎用: 自動修正可能なフォーマッター1つ + リンター1つを、pre-commitでステージ済みファイルに対して実行する。

2. 型

Section titled “2. 型”
  • OmniRoute: typecheck:core（ブロッキング）+ typecheck:noimplicit:core（助言的）+ type-coverageのラチェット92.17% + ファイル単位のany予算。
  • 汎用: CIでの厳格な型チェック + ラチェット式の型カバレッジ指標 + ファイル単位のany／エスケープハッチ予算。

3. テスト（強度）

Section titled “3. テスト（強度）”
  • OmniRoute: 重複しない2つのランナー（Nodeネイティブ + vitest）、8シャード、全体カバレッジ60/60/60/60 + 約76%のラチェット + 重要モジュール向けのモジュール単位の下限8個 + 夜間のプロパティテスト + 夜間のミューテーションテスト。
  • 汎用: テストランナー + 絶対的なカバレッジ下限（ゼロ対策）+ カバレッジのラチェット（リグレッション対策）+ 高リスクコード向けのモジュール単位の下限（グッドハートの法則対策）+ 純粋ロジック向けのプロパティベーステスト + テスト品質の真の尺度として夜間に実行するミューテーションテスト。

4. テストポリシー（不正回避対策）

Section titled “4. テストポリシー（不正回避対策）”
  • OmniRoute: pr-test-policy（本番コードにはテストを必須化）、check-test-masking（弱体化されたアサーションをブロック）、pr-evidence（成功を主張する場合はエビデンスブロックを必須化）、test-discovery（すべてのテストがいずれかのランナーによって収集されることを保証）。
  • 汎用: 「新しいコード ⇒ 新しいテスト」ゲート + アサーション削除／恒真条件の検出器 + エビデンス要件（TDDまたは現行仕様を表すテスト）+ globの対象外に孤立したテストが存在しないことの保証。

5. 複雑度とコード健全性（ラチェット）

Section titled “5. 複雑度とコード健全性（ラチェット）”
  • OmniRoute: ESLint警告（3769↓）、jscpd重複率（5.72%↓）、循環的複雑度 + 最大行数（1800↓）、sonarjsによる認知的複雑度（753↓）、knipによるデッドコード／未使用エクスポート（339↓）、ファイル単位のファイルサイズ（固定、縮小のみ）、循環依存（カスタムTarjan、ブロッキング）。
  • 汎用: すべての健全性指標（警告、重複、循環的および認知的複雑度、デッドコード、ファイルサイズ、インポート循環）をラチェット化する。方向性は常に「悪化させない」。

6. 静的セキュリティ（SAST + シークレット）

Section titled “6. 静的セキュリティ（SAST + シークレット）”
  • OmniRoute: CodeQL（アラートのラチェット = 0）、gitleaks（[extend] useDefault=true — 極めて重要！）、SonarQube、カスタムセキュリティルール（public-creds、error-helper、route-guard-membership、route-validation）。
  • 汎用: アラートをラチェット化したSAST（CodeQL/Sonar/semgrep）+ 継承されたデフォルトルールセットを使用するシークレットスキャナー（デフォルトを上書きするカスタム設定は死角を生む）+ プロジェクト固有のHard Ruleセキュリティゲート。

7. サプライチェーン（依存関係）

Section titled “7. サプライチェーン（依存関係）”
  • OmniRoute: osv-scanner + npm-audit + Trivy + Dependabot（SCA）、license-checker（SPDX許可リスト）、lockfile-lint（HTTPS+sha512+registry）、check-depsによるslopsquatting対策（許可リスト + 公開後72時間以上）。
  • 汎用: 複数ソースのSCA + ライセンス許可リスト + lockfileの完全性チェック + パッケージの経過時間／typosquattingチェックを伴う依存関係許可リスト + 更新をグループ化するbot。

8. サプライチェーン（ビルドとリリース）

Section titled “8. サプライチェーン（ビルドとリリース）”
  • OmniRoute: SBOM（CycloneDX + syft）、SLSA provenance（--provenance）、OpenSSF Scorecard（毎週）、ワークフローの強化（zizmor: artipacked→persist-credentials:false、cache-poisoning、token-permissions）。
  • 汎用: 公開時にSBOMを生成 + 署名付きprovenance（SLSA L2+）+ 定期実行のScorecard + すべてのワークフローを強化（最小権限トークン、プッシュしないcheckoutでは認証情報を永続化しない、actionsをSHAで固定）。

9. コントラクトとAPI

Section titled “9. コントラクトとAPI”
  • OmniRoute: oasdiff（OpenAPIの破壊的変更）、schemathesis（夜間のコントラクトファジング）、openapi-coverage（文書化されたルートの割合、ラチェット38.3%）、openapi-security-tiers（仕様とroute-guardの比較）。
  • 汎用: 破壊的変更を検出するコントラクト差分（oasdiff/buf）+ 仕様に対するプロパティベースのファジング（schemathesis）+ ラチェット式のドキュメントカバレッジ + 仕様↔コードの整合性。

10. ドキュメントとi18n（陳腐化対策）

Section titled “10. ドキュメントとi18n（陳腐化対策）”
  • OmniRoute: docs-sync（ミラーされたバージョン）、docs-counts-sync（ドキュメントとコード内の数値）、env-doc-sync、doc-links、fabricated-docs、cli-i18n、i18n-ui-coverage（--threshold=65 + ラチェット80.1%）。
  • 汎用: ドキュメントとコード間でバージョン／件数／環境変数を同期（信頼に頼らずゲート化）+ 内部リンクの検証 + ラチェット式のi18nカバレッジ。

11. ハルシネーション対策／整合性（希少なカテゴリ）

Section titled “11. ハルシネーション対策／整合性（希少なカテゴリ）”
  • OmniRoute: known-symbols（文字列ディスパッチ ⇒ 実在するシンボル）、provider-consistency、fetch-targets（クライアントのfetch ⇒ 実在するルート）、docs-symbols、db-rules（Hard Rules #2/#5）、migration-numbering。
  • 汎用: 「重複した信頼できる情報源」（レジストリ、文字列ディスパッチ、レイヤー間参照）ごとに、両者の一致を証明するゲートを設ける。型チェックやテストでは検出できない陳腐化を捉える。

12. レジリエンスとドメイン（製品固有）

Section titled “12. レジリエンスとドメイン（製品固有）”
  • OmniRoute: chaos（障害注入）、heap-growth（リーク）、k6（ソーク）、promptfoo+garak（LLMレッドチーム、OWASP LLM Top 10）、3つのレジリエンス法則（circuit-breaker/cooldown/lockout）。
  • 汎用: 自分たちのドメインの障害モードを特定し、それぞれに対するゲートを設ける（夜間実行でも可）。AIアプリではインジェクションに対するレッドチームテスト。分散システムではカオス + リーク + ソーク。

パート4 — あらゆるプロジェクトに適用できる導入計画

Section titled “パート4 — あらゆるプロジェクトに適用できる導入計画”

フェーズごとに構築し、それぞれのフェーズ単独でも価値を提供できるようにします。12カテゴリーすべてを一度に導入しようとしてはいけません — それはまさにパート2で警告したゲート疲れを引き起こします。すべての新しいゲートはまず勧告扱いで導入し、 安定した時点でブロッキングに移行します。

再利用可能な中核要素：「ラチェットゲートの構造」

Section titled “再利用可能な中核要素：「ラチェットゲートの構造」”

システム全体は、次の3ファイルのパターンを中心に構成されます。まずこれをコピーしてください：

  1. baseline.json — 固定されたメトリクス値 + direction（up/down）+ eps（フレーク防止）+ tightenSlack + dedicatedGate。
  2. collect-metrics.<ext> — ツールを実行して数値を抽出し、metrics.json に書き込みます。
  3. check-ratchet.<ext> — metrics.json と baseline.json を比較します。eps を超えて悪化した場合のみ exit 1。ツールやインフラが存在しなかった場合は exit 0（グレースフルスキップ）。--require-tighten を指定した場合、ベースラインを更新せずに値が改善すると exit 1 になります（改善結果を固定化します）。

これを導入すれば、あらゆる新しいメトリクス（カバレッジ、複雑度、警告、SASTアラート、バンドルサイズ、ミューテーションスコアなど）は、ベースラインに1行追加するだけで扱えます。

フェーズ0 — 基盤（第1週）

Section titled “フェーズ0 — 基盤（第1週）”

CIを用意し、フォーマッター + リンター + 型チェック + 1つのテストランナー + 絶対的なカバレッジ下限 （例：60%）を導入します。pre-commitでは、高速で自動修正可能なチェックを実行します。成果：どのPRも基本的な品質を壊さない。

フェーズ1 — ラチェットエンジン（第2週）— すべての基盤

Section titled “フェーズ1 — ラチェットエンジン（第2週）— すべての基盤”

上記の3ファイルを実装します。警告、カバレッジ、複雑度、重複、 デッドコード、ファイルサイズのベースラインを固定します。成果：以後、コードベースは改善することしかできない。

フェーズ2 — 静的解析の深化（第3週）

Section titled “フェーズ2 — 静的解析の深化（第3週）”

SAST（CodeQL/Sonar/semgrep）とアラートのラチェット、シークレットスキャナー（デフォルトのルールセットを継承）、 SCA（osv/Dependabot）+ ライセンス許可リスト + lockfile-lintを導入します。成果：既知の脆弱性や 漏洩したシークレットを通過させない。

フェーズ3 — ビルドのサプライチェーン（第4週）

Section titled “フェーズ3 — ビルドのサプライチェーン（第4週）”

公開時のSBOM + 署名付きプロベナンス（SLSA L2）+ 定期実行のScorecard + ワークフローの堅牢化 （zizmor：最小限のトークン、認証情報を永続化しない、アクションを固定）。成果：追跡可能で 改ざん防止されたリリース。

フェーズ4 — テスト強度（第5～6週）

Section titled “フェーズ4 — テスト強度（第5～6週）”

有用であれば2つ目のランナーを導入します。重要なモジュールにはモジュール単位のカバレッジ下限（反グッドハート）を設定し、 純粋なロジックにはプロパティベーステストを導入します。ミューテーションテストを毎晩実行し、最初のスコアが得られたら mutationScore をラチェット化します。成果：カバレッジは見栄えだけの指標ではなくなり、テストが実際にバグを検出できることを証明できる。

フェーズ5 — コントラクトと動的テスト（第7週）

Section titled “フェーズ5 — コントラクトと動的テスト（第7週）”

公開APIがある場合：oasdiff（破壊的変更、ブロッキング）+ schemathesis（毎晩のファズテスト）。 ドメインに応じて、DAST／レッドチームテストを毎晩実行します。成果：コントラクトが気づかれないまま壊れることを防ぐ。

フェーズ6 — ハルシネーション対策とドメイン固有対策（第8週）

Section titled “フェーズ6 — ハルシネーション対策とドメイン固有対策（第8週）”

プロジェクト内の「重複した真実」ごとに、一貫性ゲートを1つ設けます。ドメイン固有の障害モードに対応する ゲートも導入します（AIの場合：インジェクションに対するレッドチームテスト）。成果：構造的な劣化とドメイン固有の障害に対するセーフティネットを得る。

フェーズ7 — ガバナンス（継続）

Section titled “フェーズ7 — ガバナンス（継続）”
  • すべての新しいゲートに、勧告扱い→ブロッキングのサイクルを適用します。
  • stale-allowlist：すべての抑制に根拠とissueを付け、不要になった抑制を検出します。
  • evidence-gate：PRで成功を主張するには、証拠（テストまたは継続的に保守されるテスト）を必須とします。
  • ゲートごとに四半期単位でROIをレビューします（効果に見合わないものは廃止／予算削減し、疲弊を防ぎます）。
  • プロジェクトのハードルールを、実行可能なゲートへ昇格させます。

横断的な原則（妥協不可）

Section titled “横断的な原則（妥協不可）”
  • 絶対値ではなく、ラチェット。 固定値ではなく、_非退行_をゲートします（ゼロ化防止の下限を除く）。
  • 絶対的な下限とラチェットを併用。 下限は崩壊を防ぎ、ラチェットは緩やかな劣化を防ぎます。
  • 設計段階から反グッドハートを組み込む。 すべての目標メトリクスに対抗指標が必要です（カバレッジ ⇒ ミューテーション + マスキング防止、難しいコードを確実にテストさせるためのモジュール単位の下限）。
  • グレースフルスキップ。 インフラの欠落では決してブロックせず、実際の悪化だけをブロックします。
  • 高コストなメトリクスには dedicatedGate。 外部バイナリを必要とするメトリクスは、同期的な中央ラチェットの外側に独自のスクリプト（スキップ機能付き）を設けます。
  • マージが行われる場所にゲートを設置。 高速ゲートと実際のマージの間に隙間を残してはいけません（高速ゲート分離から得られた教訓）。
  • ブロッキングゲートは少数精鋭に。 Sonar/DORA：条件が多すぎると疲弊を招きます。ブロッキングゲートの壁よりも、勧告扱い + ラチェットを優先します。

パート 5 — 推奨される改善事項（優先順位順、互換性あり）

Section titled “パート 5 — 推奨される改善事項（優先順位順、互換性あり）”

P0 — ROI が最も高く、ほぼ準備完了

  1. ミューテーションスコアのラチェット（最初の nightly Stryker で値が得られた後）。カバレッジに関するグッドハートの法則への主要な対策。約 90% 完了。
  2. 残っている fast-gates の穴を塞ぐ — quality.yml の本番ビルドを、その 助言期間の終了後に昇格させ、決定論的な release-PR 専用チェックを PR→release パスへ引き続き移行する。
  3. main のブランチ保護（オーナー設定）— Scorecard を向上させ、DSOMM のギャップを解消する。

P1 — 価値が高い 4. osv/oasdiff → 適切なスコープでブロッキング化 — osv は CRITICAL かつ修正可能なもののみ（Trivy のような 2 段階方式）。oasdiff は破壊的変更をブロックする。 5. require-tighten → ブロッキング化（サイクル終了時）— メトリクスの改善を固定する。 6. ci-summary でゲートごとの ROI/所要時間をレビュー — 遅い、または価値の低いゲートを特定して削除する。

P2 — 限界効用が低い 7. SLSA L3 — L2 から上げたい場合は、ハーメチックで再現可能なビルダー（GitHub SLSA generator）を導入する。 8. コミット済みの CodeQL 設定 + バージョン固定された semgrep — 制御性と再現性を高める。 9. PR ごとの DAST スモークテスト — 最もリスクの高いエンドポイントで schemathesis/promptfoo の高速なサブセットを実行する（nightly だけではなく）。 10. 不安定性ダッシュボード + DORA メトリクス — ゲートによって速度が損なわれていないことを確認する。

パート 6 — 具体的なリリース上の教訓（フェーズ 9 で追加するゲート）

Section titled “パート 6 — 具体的なリリース上の教訓（フェーズ 9 で追加するゲート）”

このセクションでは、リリースのクローズ時にゲートが欠けていた実際のインシデントを、 具体的な証拠および提案するゲートとともに記録する。各項目はパート 5 の候補である。

v3.8.27 の教訓（2026-06-17）— 「fast-gates の穴」により決定論的なリグレッションがリリース日まで到達する

Section titled “v3.8.27 の教訓（2026-06-17）— 「fast-gates の穴」により決定論的なリグレッションがリリース日まで到達する”

何が起きたか。 v3.8.27 の /generate-release 中、リリース PR（release/v3.8.27 → main） で、統合サイクルにおける完全な ci.yml マトリクスが初めて実行された。その結果、同時に 12 件が失敗した — 決定論的テスト 3 件 + 約 9 件のフレーク/環境起因の失敗。いずれも実際のプロダクトのリグレッションではなかったが、 すべて見過ごされていた。これは、サイクル PR が **Fast QG （quality.yml）**経由で release/** に入る一方、Fast QG では完全なユニットスイートも、pr-test-policy（テストのマスキング）も、 完全な統合スイートも、スキーマの同等性チェックも実行されないためである。決定論的な 3 件は以下のとおり：

  1. UI 変更によってテストが古くなった — permissions modal switch buttons declare button type： #4034 で 4 つ目のスイッチが追加された（a11y の type="button" は維持）。テストの === 3 というカウントが 古くなった。静的解析によって #4034 の PR で検出されるべきだった。
  2. パッケージング変更によってテストが古くなった — findMissingArtifactPaths ... root runtime files： dist/http-method-guard.cjs が正当な必須パスになったため、テストの期待リストが 古くなった。
  3. 非可逆なモジュール化による不一致（最も深刻） — settings schemas accept ... unprefixed toggle：モジュール化された updateSettingsSchema（schemas/settings.ts、#3988 で作成）が、 正規版（settingsSchemas.ts）から乖離していた：45 フィールド対 85 フィールド — 40 件が欠落 + 6 件が不一致（qdrant*）。これは デッドコード（ランタイムでは正規版を使用）だったため実際の影響はなかったが、手書きの同等性 テストだけが検出した。#4030 では #3988/#3993 による類似の欠落 16 件を復元したが、これはすり抜けた。

提案するゲート（フェーズ 9）：

  • G1 — fast-gates の穴を実際に塞ぐ（P0 #2 の拡張）。 quality.yml（PR→release/**）で、 typecheck + 影響範囲のテストに加えて、pr-test-policy（テストのマスキング）+ 完全な決定論的 ユニットスイート（または少なくとも、高速でフレークしない静的/同等性ファイル）を実行する。 これにより、古くなったテストやアサーションの削除を、それらが導入された PR で検出できる — リリース日まで待つ必要がない。integration/e2e は除外したままにする（遅い/不安定）が、決定論的レイヤーを PR→main にだけ残してはならない。
  • G2 — モジュール化の同等性ゲート（新規、現時点では未対応）。 モジュール化された barrel（src/shared/validation/schemas/*、providerRegistry モジュールなど）によって再エクスポートされる各シンボルについて、形状（z.object のキー、レジストリエントリ）を正規 ソースと比較し、不一致（フィールドの欠落/余分）があれば失敗させるチェック。これがあれば、#3988 による 40 フィールドの欠落を その PR 自体で検出できていた。手書きの同等性テスト（誰かが書くことを思い出した箇所にしか存在しない）を 一般化する。低コスト：両方をインポートし、Object.keys(shape) の差分を取る。
  • G3 — 決定論的なフレークのトリアージ（支援）。 LiveWS-startup と integration-combo/breaker のテストは、ロジックではなく CI 上のサーバータイムアウト/連鎖障害（環境）が原因で失敗する。これらを known-flaky（issue 付きで隔離）としてマークし、リリース PR の赤表示が、決定論的なリグレッションを途中で覆い隠すノイズではなく、実際のシグナルだけを示すようにする。

原則： ゲートはマージが行われる場所で実行しなければならない（「横断的な原則」に既出）。 v3.8.27 のインシデントは、これが lint/typecheck だけでなく決定論的テストレイヤーにも適用されることを示している — そうしなければ、古くなったテスト + 非可逆なモジュール化による負債が、PR→main でまとめて、しかも 最悪のタイミングになって初めて現れる。

出典（業界のベストプラクティス）

Section titled “出典（業界のベストプラクティス）”

OmniRoute ソースコード (a58000c7685f)

HagiCode

HagiCode は構造化ワークフロー、マルチエージェント実行、Hero Dungeon ビューを備えたエージェント型コーディングワークスペースです。

よりスマートで速く、楽しいエージェント型ワークフローで、使いやすいソフトウェアを形にします。

HagiCode ライトテーマのメイン画面
  • Smart構造化ワークフローは意図をアイデアから変更のリリースまで実行可能な道筋にします。
  • Efficientマルチエージェントのワークフローで調査、実装、レビューを並行して進めます。
  • FunHero Dungeon により長時間のコーディングを視覚的で協力的な体験にします。
HagiCode を見る