verification-fidelity

name	verification-fidelity
description	宣稱「修好了 / 驗過了」前的驗證忠實度自檢。歸納自一連串「我說修好了 → 真實環境又壞」的教訓：驗證若用了「比較寬鬆的替身」而非「真的會壞的那個東西」，等於沒驗。`60-feedback-loop-priority` 要你先建決定性訊號，本 skill 是另一半——讓那個訊號忠實重現真正的失敗模式。觸發：「驗過了嗎 / 真的修好了嗎」「為什麼 tester / 玩家又找到 bug」「跨環境(OS/locale/碼頁/平台)、跨資料規模、在地化的修正驗證」「UI 座標/縮放/命中判定改動」「重打出貨前最後一關」。

Verification Fidelity（驗證忠實度）

下結論「修好了 / 驗過了」前，逐項自問。任何一項答不出來，你的「驗過」就是假信心 —— 回去補。

• 環境對嗎？ 在「真的會壞」的條件下驗(locale / 碼頁 / OS / 資料 / 路徑 / 時序)，必要時強制設定(registry / env / fixture) 去重現那個精確條件；別用手邊寬鬆的替身。
• artifact 新嗎？ 改碼(尤其 git stash pop)後先重建再量測；懷疑就核對 binary 時間戳，別拿 stale artifact 當證據。
• 是執行期嗎？ 靜態 / 結構檢查 ≠ runtime 行為；validator 若沒模擬真實渲染 / 迴圈 / IO，會放行真 bug。
• 真的互動了嗎？ UI 改動要真的點 / 拖 / 輸入看動作有沒有觸發，不能只截圖；只要改了「畫」的座標，就要同步改 hit-test(相同變換)。
• 戳破隱藏假設了嗎？ 換語言(CJK 無空格 / 寬字 / 非 ASCII 碼頁)、換平台、換資料規模，常觸發為「原假設」寫的 latent bug；驗證要涵蓋這些結構性差異，不是只換輸入。
• 拿 diff 對踩雷清單了嗎？ 「寫下 gotcha」≠「內化 gotcha」——用自己的改動去對自己已知的雷。

心法

builds 綠 + 我自己腳本化的 QA 通過 ≠ 對玩家/使用者可用。最可靠的訊號是走一遍真實使用者旅程(在真環境、用新 build、真的互動)。

When NOT to apply

• 純文件 / 設定字串改動(無 runtime 行為)。
• 已有涵蓋該失敗模式的決定性測試在跑——那就信它。

詳細案例(按需讀)

四個真實踩雷的完整還原(根因 + 為何替身驗不出 + 怎麼正確驗)在 references/cases.md：Wine 預設碼頁 vs 真實 CP950、stale binary 渲染了「修正前」截圖、HD mapY render 卻沒改 hit-test、CJK 折行無空格→無窮迴圈。只有相關時才讀，平時不展開。