根據票證審查拉取請求

拉取請求準備就緒前的最後一道關卡。它回答一個問題——這個 diff 是否在架構範圍內交付了票證？——並且依據兩個比審查者個人品味更權威的來源來回答：驗收標準，以及參考架構。

本次審查是閱讀與報告。它不進行編輯：一個邊審邊改的審查會破壞問題的證據，而且沒有人會學到模式。

三個階段中的最後一個，接續在 TICKET-ANALYSIS.md 與 IMPLEMENTATION-PHASE.md 之後。WORKFLOW.md 說明它們如何組合在一起以及如何安裝。

1. 確認實際審查的內容

將分支與儲存庫的實際基礎分支進行 diff，而不是基於假設。審查每一個變更的檔案；一個因為看起來無趣而被跳過的檔案，正是設定變更隱藏的地方。

記錄 diff 觸及但票證未提及的內容。這份清單是 §2 和 §5 的輸入，尚不構成發現事項。

逐一檢視驗收標準，並針對每一項標準，指出滿足該標準的程式碼以及證明該標準的測試。兩者都必須存在，否則該標準未被滿足。

反過來說：沒有對應驗收標準的變更。有些是合理的——在正在變更的程式碼內部的修正（IMPLEMENTATION-PHASE.md §2）。其餘的就是範圍蔓延，在此處指明比在發佈後再解釋更為經濟。

針對 diff 觸及的每一層，逐一核對合規檢查清單。最具價值的發現事項是那些通過建置也無法顯示的問題：

P2 — 任何領域相關的新增被加入到共享核心中：實體、DTO、列舉、種子資料集、定價常數、使用者可見字串。
P3 — 跨上下文的讀取或寫入；第二個服務存取擁有該資料庫的服務的資料庫。
P4 — 未伴隨遷移而變更的 schema，或者不具備提供者可攜性的遷移。
P5 — 原始碼、設定檔或註解中存在機密、金鑰或連線字串；從環境變數以外的地方讀取設定。
P8 — 啟動時會直接失敗而非降級運作的新相依項，或者未出現在健康檢查端點和啟動橫幅中的相依項。
P9 / P10 — 在 Program.cs 中內嵌的接線；新增的擴充點是基底類別而非在 DI 中註冊的介面。
P11 — 未經轉譯的外部形狀直接觸及領域。
P15 — 新增的路徑沒有任何追蹤、指標或日誌。
SERVICE-API-PATTERNS.md — 端點落在信任群組之外、未限制大小的列表、不一致的錯誤回應體、沒有明確逾時的對外呼叫、重試不確定寫入。
安全性 — 任何新公開暴露的內容在出貨前都必須經過 SECURITY-REVIEW.md 審查，而非之後。

一個拉取請求中記錄為帶有理由的決策的偏差不構成發現事項。同樣的偏差，如果保持沉默，則是一個發現事項——這就是 P14 的作用。

閱讀測試主體。測試數量、檔案數量與資料夾結構無法證明任何事情；在 2026-08-14 對 447 個測試套件的稽核中，發現大約 45% 是佔位符或被保護起來而從未實際斷言任何東西，而這些從外部完全看不出來（P13）。

為每個發現事項排名，並且根據其後果而非描述起來的容易程度來排名：

等級	含義
阻擋	驗收標準未滿足或未經驗證；某項原則被違反且沒有記錄決策；機密被暴露；測試被削弱或刪除以換取綠燈
應修正	正確但偏離模式：錯誤的測試層級、缺少回歸覆蓋率、未記錄的假設、因變更而使文件變得不正確
可考慮	真正可選的。保持此部分簡短——過長的清單會埋沒前兩者

以明確的語言陳述圖表閘門所需的結論：這個拉取請求是否交付了票證，並且是否在架構範圍內？ 三個答案之一——已驗證；已驗證，附帶所列的非阻擋發現事項；或未驗證，並列出阻擋發現事項。「看起來不錯，有些意見」不是一個結論。

症狀	原因
審查批准了遺漏需求的 diff	審查從程式碼開始，而不是從驗收標準開始
審查是一串風格意見列表	因為建置是綠燈而跳過了架構和測試審查——而這正是它們要檢查的
綠燈的測試套件被視為證據	從未閱讀測試主體；信任了數量和結構
所有發現事項以相同權重報告	未進行嚴重性排名，因此阻擋發現事項被隱藏在命名挑剔之下
同樣的違規在多次拉取請求中重複出現	審查者直接修正了發現事項而非報告它們，因此模式從未被學習
報告了作者已經證明合理的偏差	在審查之前未閱讀拉取請求中記錄的決策

由 scripts/build-marketplace.mjs 從 docs/delivery/PR-REVIEW.md 產生。請勿編輯此檔案：請變更來源文件，或其在 catalog/marketplace.catalog.json 中的條目，然後重新執行產生器。