跳到內容
OmniRoute Docs

選擇語言

目前語言: 繁體中文

OmniRoute source

Quality-Gate System — Critical Assessment, Catalog and Replication Playbook (中文 (繁體))

第 1 部分 — 結論與成熟度分類

Section titled “第 1 部分 — 結論與成熟度分類”

整體評級：A−／「進階」。位居所有專案前約 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 已關閉；部分 actions 未鎖定版本。 ~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) 我們透過執行階段防護 + promptfoo（評估）+ garak（紅隊測試）涵蓋風險 #1（提示注入）。這些都是業界標準工具。 已涵蓋
突變測試 每晚執行 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 來源證明 + Scorecard + 工作流程強化（zizmor）。鮮少有程式碼庫具備如此完整的技術堆疊。
  3. 對抗古德哈特定律的解方。 將覆蓋率作為目標是一種經典的反模式 （「當衡量指標成為目標時，它就不再是好的衡量指標」）。我們設有以下制衡機制： 突變測試（衡量測試是否能捕捉錯誤，而不只是是否執行了該行程式碼）、 check-test-masking（阻止藉由弱化斷言來通過檢查）、 各模組的最低覆蓋率門檻（強制測試高風險程式碼，而不只是容易測試的部分），以及 check-pr-evidence（硬性規則 #18）。
  4. 反幻覺／一致性閘門。 這是少見且極具價值的類別：check-known-symbols、 check-fetch-targets、check-openapi-routes、check-docs-symbols 可確保文件、規格與 字串分派指向仍然存在的符號。能捕捉 lint／測試無法發現的「腐化」。
  5. 從建議性到阻擋性的生命週期。 新閘門先以建議性質導入（在成熟前不阻擋合併）， 接著於週期結束時轉為阻擋性質。既降低摩擦，又不犧牲品質上限。
  6. 基礎設施缺失時可優雅略過。 掃描器（--ratchet）在二進位檔／網路失敗時會以 exit 0 結束——基礎設施缺失絕不會阻擋合法的 PR。這是成熟的工程實務。
  7. 將文化規範化。 硬性規則 + trust-but-verify + 過期允許清單 + 證據閘門， 將紀律轉化為自動化驗證。

坦誠的弱點（實際缺口）

Section titled “坦誠的弱點（實際缺口）”
  1. 🔴 快速閘門的拆分仍留有結構性缺口。 quality.yml（PR→release/**） 現在會針對程式碼 PR 執行類型檢查、快速且具確定性的測試，以及建議性質的正式環境建置， 但仍未執行 ci.yml 中完整的發行 PR 檢查範圍（覆蓋率棘輪、 套件成品、整合測試、E2E、SonarQube）。其動機（速度）合理，但閘門 應設於實際合併發生之處（左移）。目前待處理的最大結構性修正。
  2. 🟠 閘門蔓延／疲勞風險。 約 46 個閘門 + 25 個作業，數量非常龐大。Sonar 本身也警告： 過多條件會導致「閘門疲勞」和優先級爭議，並可能造成閘門遭到忽視。 DORA 則警告繁重的閘門會增加前置時間。我們透過建議性層級與非絕對棘輪來降低風險， 但目前缺少針對每個閘門的定期投資報酬率審查（部分用於文件同步的微型閘門可以整併）。
  3. 🟠 突變分數尚未成為棘輪。 對抗覆蓋率操弄最強而有力的手段目前仍是 建議性質。這是價值最高的待辦項目（且已完成 90%）。
  4. 🟡 應改為阻擋性質的建議項目（在範圍適當的前提下）。 osv（vulnCount）和 oasdiff 儘管已有凍結的基準線，仍屬建議性質。osv 採建議性質有其道理（舊相依套件中新發現的 CVE 可能會阻擋 不相關的 PR）——但仍有折衷方案（僅阻擋嚴重性為 CRITICAL 以上且可修復的項目，如同 我們對 Trivy 採取的做法）。oasdiff 採建議性質，意味著破壞契約的變更仍可能通過。
  5. 🟡 執行階段安全檢查僅於夜間執行。 schemathesis/garak/promptfoo/chaos/k6 於夜間執行。 這是正確的決定（執行緩慢且需要運作中的伺服器），但 PR 可能引入注入防護的退步， 而要到隔天夜間才會被發現。
  6. 🟡 main 的分支保護目前為關閉狀態。 BRANCH_LOCK_TOKEN 會鎖定 release 分支，但 main 本身未受保護。這會在 Scorecard／DSOMM 中被扣分。需要擁有者採取行動。
  7. 🟡 CodeQL 使用預設設定；semgrep 尚未規範化。 預設設定可正常運作（0 個警示），但提交 codeql.yml 可提供更多控制能力；semgrep 則透過外部雲端平台執行，未在儲存庫中進行 版本控制。

第 3 部分 — 完整品質檢查點目錄（可移植）

Section titled “第 3 部分 — 完整品質檢查點目錄（可移植）”

以下 12 個類別是可重複使用形式的「品質系統」。每個類別都列出要保護的目標、我們使用的工具，以及可在任何技術堆疊上重現的工具無關等效方案。

1. 樣式與格式（確定性、快速）

Section titled “1. 樣式與格式（確定性、快速）”
  • **OmniRoute：**透過 lint-staged（pre-commit）執行 Prettier + ESLint，採用 2 個空格／雙引號／100 欄。
  • **通用方案：**一個可自動修正的格式化工具 + 一個 linter，於 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 個逐模組最低門檻 + 每晚屬性測試 + 每晚執行突變測試。
  • 通用方案：測試執行器 + 絕對覆蓋率最低門檻（防止歸零）+ 覆蓋率棘輪機制（防止退步）+ 高風險程式碼的逐模組最低門檻（防止 Goodhart 定律效應）+ 對純邏輯進行屬性測試 + 每晚執行突變測試，將其作為衡量測試品質的真正指標。

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（允許清單 + 套件存在時間 ≥72h）。
  • **通用方案：**多來源 SCA + 授權條款允許清單 + lockfile 完整性檢查 + 具備套件存在時間／typosquatting 檢查的相依套件允許清單 + 分組更新機器人。

8. 供應鏈（建置與發布）

Section titled “8. 供應鏈（建置與發布）”
  • **OmniRoute：**SBOM（CycloneDX + syft）、SLSA 溯源證明（--provenance）、OpenSSF Scorecard（每週）、工作流程強化（zizmor：artipacked→persist-credentials:false、快取污染、權杖權限）。
  • **通用方案：**發布時產生 SBOM + 經簽署的溯源證明（SLSA L2+）+ 排程執行 Scorecard + 強化所有工作流程（最小權限權杖、非推送者的 checkout 不保留憑證、actions 以 SHA 固定版本）。

9. 契約與 API

Section titled “9. 契約與 API”
  • **OmniRoute：**oasdiff（OpenAPI 破壞性變更）、schemathesis（每晚執行契約模糊測試）、openapi-coverage（已文件化路由百分比，棘輪值 38.3%）、openapi-security-tiers（規格與路由防護）。
  • **通用方案：**破壞性變更契約差異比對（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。
  • **通用方案：**針對每個「重複的真實來源」（registry、字串分派、跨層參照），建立能證明雙方相符的閘門。藉此捕捉類型檢查／測試無法發現的腐化。

12. 韌性與領域（產品特定）

Section titled “12. 韌性與領域（產品特定）”
  • **OmniRoute：**chaos（故障注入）、heap-growth（記憶體洩漏）、k6（長時間負載測試）、promptfoo+garak（LLM 紅隊測試 OWASP LLM Top 10）、3 項韌性法則（斷路器／冷卻期／鎖定）。
  • 通用方案：找出你的領域所面臨的失效模式，並為每一種模式設置閘門（即使只在每晚執行）。對 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 警示、套件大小、突變分數……）都只需在基準線中新增一行。

階段 0 — 基礎建設（第 1 週）

Section titled “階段 0 — 基礎建設（第 1 週）”

建立 CI；設定格式化工具 + linter + 類型檢查 + 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：最小權限 token、不保留憑證、固定 action 版本）。產出：可追溯且防竄改的發行版本。

階段 4 — 測試強度（第 5–6 週）

Section titled “階段 4 — 測試強度（第 5–6 週）”

若有幫助，加入第 2 個測試執行器；為關鍵模組設定個別的覆蓋率下限（反 Goodhart）； 對純邏輯使用屬性測試；每晚執行突變測試 → 首次取得分數後，將 mutationScore 設為棘輪指標。產出：覆蓋率不再只是虛榮指標；測試能被證明確實可捕捉錯誤。

階段 5 — 契約與動態測試（第 7 週）

Section titled “階段 5 — 契約與動態測試（第 7 週）”

若有公開 API：使用 oasdiff（破壞性變更，阻擋性）+ schemathesis（每晚模糊測試）。 依領域需要，每晚執行 DAST／紅隊測試。產出：契約不會在無人察覺的情況下遭到破壞。

階段 6 — 反幻覺與領域檢查（第 8 週）

Section titled “階段 6 — 反幻覺與領域檢查（第 8 週）”

針對專案中的每個「重複事實來源」設定一個一致性閘門。建立領域特定的失敗模式 閘門（針對 AI：提示詞注入紅隊測試）。產出：結構性腐化與領域失敗都有安全網。

階段 7 — 治理（持續進行）

Section titled “階段 7 — 治理（持續進行）”
  • 每個新閘門都採用建議性→阻擋性的轉換週期。
  • stale-allowlist：每個抑制項目都必須附有理由 + issue；過時的抑制項目會被偵測出來。
  • evidence-gate：PR 中的成功宣稱必須有證據（測試或持續有效的測試）。
  • 每季審查各閘門的 ROI（移除／停止投入無法帶來回報的閘門 — 避免疲勞）。
  • 將專案的強制規則轉化為可執行的閘門。

橫跨各階段的原則（不可妥協）

Section titled “橫跨各階段的原則（不可妥協）”
  • 使用棘輪，而非絕對值。 閘門應檢查是否_退步_，而非固定數值（防止歸零的下限除外）。
  • 絕對下限與棘輪並用。 下限可防止崩塌；棘輪可防止緩慢惡化。
  • 從設計上反制 Goodhart。 每個目標指標都需要制衡指標（覆蓋率 ⇒ 突變測試 + 防掩飾機制；個別模組下限可強制測試難以測試的程式碼）。
  • 正常略過。 基礎設施缺失絕不阻擋；只有真正的退步才會阻擋。
  • 昂貴指標使用 dedicatedGate。 需要外部二進位檔的指標應使用各自的指令碼（支援略過），並置於同步中央棘輪之外。
  • 在實際合併處設置閘門。 不要在快速閘門與實際合併之間留下缺口（這是從快速閘門分拆中學到的教訓）。
  • 阻擋性閘門要少而精。 Sonar/DORA：條件過多 = 疲勞。相較於大量阻擋性閘門，應優先採用建議性模式 + 棘輪。

第 5 部分 — 建議的改善項目（依優先順序排列、彼此相容）

Section titled “第 5 部分 — 建議的改善項目（依優先順序排列、彼此相容）”

P0 — 投資報酬率最高，幾乎就緒

  1. 突變分數棘輪機制（在第 1 次每夜 Stryker 執行產生數值後）。對抗覆蓋率 Goodhart 效應的關鍵手段；已完成約 90%。
  2. 填補剩餘的快速閘門缺口 — 在 quality.yml 的正式環境建置經過一週觀察期後，將其提升為阻擋性閘門，並持續將僅限確定性發布 PR 的檢查移入 PR→release 路徑。
  3. 在 main 上設定分支保護（擁有者設定）— 提升 Scorecard，填補 DSOMM 缺口。

P1 — 有價值 4. osv/oasdiff → 在正確範圍內改為阻擋性閘門 — osv 僅阻擋 CRITICAL 且可修復的問題（採用與 Trivy 類似的兩步驟方式）；oasdiff 阻擋破壞性變更。 5. require-tighten → 改為阻擋性閘門（週期結束時）— 鎖定指標改善成果。 6. 在 ci-summary 中逐一檢視各閘門的投資報酬率／執行時間 — 找出並移除緩慢／低價值的閘門。

P2 — 報酬遞減 7. SLSA L3 — 如果想從 L2 升級，請使用密封式／可重現的建置器（GitHub SLSA generator）。 8. 提交至儲存庫的 CodeQL 設定 + 版本固定的 semgrep — 提供更高的控制力／可重現性。 9. 每個 PR 的 DAST 冒煙測試 — 對最高風險的端點執行 schemathesis/promptfoo 的快速子集（而非僅於每夜執行）。 10. 不穩定性儀表板 + DORA 指標 — 確保閘門不會侵蝕交付速度。

第 6 部分 — 具體的發布經驗（第 9 階段要新增的閘門）

Section titled “第 6 部分 — 具體的發布經驗（第 9 階段要新增的閘門）”

本節記錄在發布收尾期間，因為缺少閘門而發生的真實事件， 並提供具體證據與建議的閘門。每個項目都是第 5 部分的候選項目。

v3.8.27 的經驗（2026-06-17）—「快速閘門缺口」讓確定性迴歸問題一路進入發布日

Section titled “v3.8.27 的經驗（2026-06-17）—「快速閘門缺口」讓確定性迴歸問題一路進入發布日”

發生了什麼事。 在 v3.8.27 的 /generate-release 期間，發布 PR（release/v3.8.27 → main） 是整合週期中第一次執行完整的 ci.yml 矩陣。結果：同時出現 12 個失敗 — 3 個確定性測試 + 約 9 個不穩定／環境問題。這些都不是線上產品迴歸問題，但 全部都未被察覺，因為週期 PR 是透過**快速 QG （quality.yml）**進入 release/**，而它不會執行完整的單元測試套件、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 — 真正填補快速閘門缺口（擴充 P0 #2）。 在 quality.yml（PR→release/**）中， 除了類型檢查 + 受影響的測試之外，還要執行 pr-test-policy（測試遮蔽檢查）+ 完整的確定性 單元測試套件（或至少執行靜態／一致性測試檔案；這些測試快速且穩定）。 如此一來，過時的測試與被移除的斷言就能在引入它們的 PR 中被發現，而不是等到 發布日。整合／e2e 測試可排除在外（緩慢／不穩定），但確定性測試層絕不能只存在於 PR→main。
  • G2 — 模組化一致性閘門（新增，目前尚未涵蓋）。 對於模組化 barrel（src/shared/validation/schemas/*、providerRegistry 模組等）重新匯出的每個符號，比較其與規範來源的結構（z.object 鍵、登錄項目），並在 出現分歧時失敗（遺漏／多餘欄位）。這本可在 #3988 的 PR 中直接發現該次 40 個欄位的 遺漏。此閘門將手寫的一致性測試泛化（目前只有在有人記得撰寫時才會存在）。 成本低廉：匯入兩者並比對 Object.keys(shape)。
  • G3 — 確定性的不穩定測試分流（支援項目）。 LiveWS-startup 和 integration-combo/breaker 測試會因 CI 中的伺服器逾時／連鎖失敗（環境問題）而失敗，而非邏輯問題。將這些測試標記為 known-flaky（隔離並建立 issue），如此發布 PR 的紅燈就會只反映真實訊號，而非由雜訊 掩蓋夾雜其中的確定性迴歸問題。

原則： 閘門必須在合併發生之處執行（已列於「跨領域原則」中）。v3.8.27 事件顯示，這也適用於確定性測試層，而不只是 lint／類型檢查 — 否則，過時測試 + 有損模組化所累積的技術債，只會在 PR→main 時以批次形式出現，而且是在 最糟糕的時機。

來源（業界最佳實務）

Section titled “來源（業界最佳實務）”

OmniRoute 原始碼 (a58000c7685f)

HagiCode

HagiCode 是智慧代理程式開發工作台，結合結構化工作流程、多代理程式執行與 Hero Dungeon 介面，將想法化為交付成果。

以更聰明、更快速且更有趣的智慧代理程式工作流程，打造實用的軟體。

HagiCode 淺色主題介面畫面
  • Smart結構化流程將意圖轉化為從構想到交付的可執行步驟。
  • Efficient多代理程式工作流程讓研究、實作與審查並行進行。
  • FunHero Dungeon 讓長時間的程式協作更直覺、更有參與感。
造訪 HagiCode