變更審查
此技能審查的是「變更」而非「畫面」。它會解析變更範圍，將受影響的檔案擴展至其影響的表面，讀取差異的兩側，並對每個發現進行分類。
範圍僅涵蓋其所有權。領域規則屬於 better-* 技能。嚴重性、整合、覆蓋率、上限及結論則屬於 better-interface，此技能會將審查結果移交給它。
正確性、測試、安全性及效能則屬於專案的一般程式碼審查。簡述關切事項一次後即跳過。
審查變更，而非程式碼庫
作者的問題是「我是否讓它變得更糟？」。報告變更所導致的問題，並對變更僅觸及的部分保持沉默。三個既存發現是禮貌；三十個則是完全不同的審查，且沒人要求這樣做。
在形成對變更的意見前，先閱讀變更。陳述的意圖決定了什麼算不完整，而草率瀏覽的 diff 會產生關於程式碼的發現，而這些問題在下一個 hunk 中已經被修復。
核心原則
1. 先解析變更範圍
整個調用即為目標，因此 /interface-review pr 482 會審查 Pull Request 482。範圍解析 包含了接受的目標及其解析方式。
若未提供目標，則按以下順序解析，並在第一個符合條件的條件時停止：
HEAD領先於git merge-base origin/<default-branch> HEAD：該範圍加上任何未提交的變更，並分別說明提交次數及未提交檔案數量。- 工作目錄不乾淨：未提交的變更。
- 兩者皆非：沒有要審查的變更。停止並詢問，詳見若無變更，應詢問而非發明一個。
順序很重要。先檢查工作目錄，一個偶然的格式編輯會掩蓋一個包含十二個提交的分支，而報告仍會聲稱已完全覆蓋。
排除鎖定檔、快照、產生輸出、供應商程式碼及二進位檔，並說明排除的內容。排除後範圍為空，則以另一種方式達到相同結果。
2. 若無變更，應詢問而非發明一個
乾淨的工作樹且沒有領先合併基準的提交，代表使用者要求審查一個不存在的變更。絕不可自行回退到 HEAD~1..HEAD。最後一個提交只是恰好進入的內容，通常是合併提交，且通常是別人的工作，而基於此的報告與使用者意圖的報告無法區分。
陳述你發現的儲存庫事實，然後提供選項並等待。無可審查的內容 包含了應收集的事實：
- 最後一個提交，
HEAD~1..HEAD，以簡短的 SHA 和主旨命名，以便使用者在選擇之前看到他們會得到什麼。 - 他們命名的目標：
pr <n>、一個分支、一個 ref 或一個範圍，按照先解析變更範圍解析。 - 整個儲存庫的介面審查，這不是變更審查。將其作為儲存庫範圍的審查移交給
better-interface，不使用此技能的範圍區塊、狀態或既存章節。若無變更，每個發現都是既存的，且分類無意義。
在詢問之前，檢查當前分支是否有開啟的 Pull Request，並優先提供。一個提交已合併的分支會解析為「無變更」，而其 Pull Request 仍是使用者確切想要的內容。
若排除後範圍變空，則說明哪些檔案被排除，並以相同方式詢問。切勿將空審查報告為 Approve。
3. diff 不是表面
更改的檔案是證據，而非審查主體。它的波及範圍是它渲染到的表面集合；審查那些表面。
預設情況下，擴展一波及範圍：直接匯入者和呼叫者。僅對設計代碼、主題值和共享基元擴展第二波，因為在這些情況下，一行變更會影響整個產品。
最多審查五個消費者，按照範圍解析中的規則排序，然後說明你沒有擴展的數量。無限制的掃描無法支持其聲稱的覆蓋率，而未說明的截止點會被解讀為完整性。
4. 閱讀被刪除的行
回歸在變更後的狀態中是看不見的。根據已移除的信號閱讀每個 hunk 的 - 側。
信號是線索，而非發現。只有當變更中沒有任何東西取代它時，刪除才是回歸，而領域技能擁有該判斷權。將每個未匹配的移除路由給其所有者，僅報告該技能確認的內容，並將其狀態設為 Regression。這會告訴作者他們破壞了原本能用的功能，而非犯了新的錯誤。
5. 對每個發現進行分類
為每個發現指定一個狀態：
Introduced：由變更引入。Regression：變更削弱了原本正確的內容。Pre-existing：存在於被觸及的程式碼中，但非由此變更引起。
根據 diff 觸及的行來分類，而非根據它位於哪個檔案：即使變更從未觸及某行，即使它離 hunk 只有三行，也算 Pre-existing。必要時，根據基礎 ref 進行確認：
git blame -L <line>,<line> "$BASE" -- path/to/file
將每個發現連同其狀態一起上交，讓 better-interface 套用其上限和結論規則。
6. 根據變更的陳述意圖來評判
閱讀 Pull Request 的標題和內文、連結的 Issue 以及提交訊息，然後審查介面是否達成了他們的聲明。
這正是揭示不完整變更的方法。表面審查無法看到它，因為它檢查的是存在的狀態，而這裡的重點是那些缺失的狀態：
- 新的變體、尺寸或主題套用於某些狀態但非全部：懸浮、焦點、啟用、停用、載入、選取。
- 新的使用者面向字串，但專案維護的翻譯目錄中沒有對應條目。
- 新的元件缺少空狀態、載入狀態、錯誤狀態、停用狀態或窄寬度狀態。
- 在某個表面新增的控制項，但沒有新增到已經攜帶其同級項目的兄弟表面。
不要報告範圍蔓延。變更是否做得太多是流程問題，而非介面問題。
7. 將審查移交給 better-interface
將範圍區塊、受影響的表面以及每個發現的狀態移交給 better-interface。它會路由到領域技能、套用嚴重性、整合、強制執行上限並發出結論。
如果 better-interface 不可用，則報告已解析的範圍和檔案清單，將其命名為缺失的技能並停止。不要發明嚴重性等級、上限或結論。
8. 絕不修改工作目錄
變更審查是唯讀的，包括 checkout。擷取 Pull Request 的 refs；絕不 checkout 它們。git fetch 僅寫入 .git 且是允許的。gh pr checkout、git checkout、git switch 和 git stash 會改寫作者已開啟的檔案。它們會對本地編輯失敗或捨棄它們，因此絕不允許。
渲染驗證是選擇加入的。除非專案提供便宜的預覽或用戶要求渲染審查，否則將視覺和執行時期聲明標記為 Not verified。當用戶要求時，使用隔離的工作樹（git worktree add /tmp/review-<n> refs/remotes/pr/<n>）並在完成後移除。
完成前檢查
| 錯誤 | 修正 |
|---|---|
| 審查了一個偶然的格式編輯而非分支 | 在檢查工作目錄之前先檢查 merge-base，並報告兩者計數 |
| 因為沒有變更而審查了最後一個提交 | 陳述事實並提供最後一個提交、命名目標或儲存庫審查 |
| 未審查消費者的 hunk | 擴展一波，代碼和基元擴展兩波，並說明跳過的內容 |
僅閱讀 diff 的 + 側 | 在 - 側搜尋已移除的無障礙性、焦點、動畫和文字信號 |
| 將等效的取代報告為回歸 | 將移除路由給其所有者；僅報告其確認的內容 |
| 將移除報告為新錯誤 | 將其狀態設為 Regression，以便作者知道它原本正常 |
將接近 hunk 的行狀態設為 Introduced | 根據 diff 觸及的行來分類，並使用 git blame 對基礎 ref 進行確認 |
| 為了審查而 checkout 了一個 Pull Request | 擷取 ref 並就地審查 |
| 引用的行號在被審查的 ref 上不存在 | 根據範圍區塊中命名的 head ref 引用 |
| 在此重申嚴重性等級或發現上限 | 交由 better-interface 處理 |
| 在報告中包含正確性、測試或安全性發現 | 簡述關切事項一次，指向專案的程式碼審查並放棄 |
審查輸出格式
以範圍區塊開頭：
| 欄位 | 值 |
|---|---|
| 目標 | branch、working、staged、pr 482 或輸入的範圍 |
| 基礎 ref | origin/main 在 a1b2c3d |
| Head ref | refs/remotes/pr/482 在 e4f5g6h |
| 提交 | 7 個已提交，2 個檔案未提交 |
| 範圍內檔案 | 排除後 12 個 |
| 已排除 | pnpm-lock.yaml、src/__snapshots__/：鎖定檔和快照 |
| 已擴展表面 | CheckoutPage、SettingsPanel；未擴展另外 3 個 Button 消費者 |
接著是覆蓋率表格，保持不變。在變更範圍中沒有證據的領域是 Not reviewed: no evidence in the change scope，這是覆蓋率陳述，而非缺口。
然後是發現，帶有根據對每個發現進行分類的 Status 欄：
| 嚴重性 | 領域 | 狀態 | 位置 | 之前 | 之後 | 原因 |
|---|---|---|---|---|---|---|
| HIGH | 無障礙性 | Regression | src/Dialog.tsx:42 | 此變更移除了 aria-label="Close" | 在僅圖示控制項上恢復 aria-label="Close" | 關閉控制項在此變更之前有一個可存取名稱，現在沒有了 |
若無 Introduced 或 Regression 發現，則省略表格並陳述「在此變更中無可操作的介面發現。」
然後是 Pre-existing 發現，最多三個，優先級最高者優先，並明確說明這不是此變更的責任。若沒有則省略該章節。
| 嚴重性 | 領域 | 位置 | 問題 |
|---|---|---|---|
| MEDIUM | 排版 | src/Toolbar.tsx:7 | 數字徽章使用比例數字；早於此變更 |
上限和結論僅涵蓋 Introduced 和 Regression。Pre-existing 發現位於上限之外，因此觸碰舊檔案不會變成完整的檔案審查。它們也位於結論之外，因此一個僅有既存發現的變更是 Approve。
當任何 HIGH 仍然存在時，以 Block 結尾，否則以 Approve 結尾，將剩餘的發現留在表格中作為待辦事項。當 better-interface 可用時，嚴重性等級和上限來自於它。