Day 16 把 Verification Evidence 綁回可追溯的 State、Method、Environment、Scope 與 Limitation。

接著會遇到另一個更實際的問題：

已經有測試結果了，還要跑到什麼程度才算夠？

很容易把答案變成「多跑一點」。

但在真實 Repo 裡，測試數量不是最好用的判斷方式。不同 Verification 本來就在回答不同風險。

Targeted、Regression、Smoke 的差異，不是大小，而是它們分別證明「這次改動」、「既有行為」與「部署後實際路徑」到哪裡成立。

同一個 Repo 裡，三種 Evidence 本來就不是同一件事

便當系統的 Worker backend 已經把三種責任拆成不同入口。

package.json 裡同時存在：

test:delegated
→ 只跑 delegated ordering 的 targeted suite

test
→ 跑完整 Worker test suite

smoke:cors
→ 對已部署 Worker 執行 remote CORS smoke

這不是三個名字不同的「測試按鈕」。

它們觀察的是三種不同問題：

• Targeted（針對性測試）：這次修改直接碰到的 contract 是否成立？
• Regression（回歸測試）：原本已成立的行為，有沒有被這次修改破壞？
• Smoke（冒煙測試）：部署後最基本的真實 runtime path 是否可達？

這裡要特別區分「Repo 裡存在這些 verification path」與「這次已實際跑完」。

本文討論的是三種 Evidence 的用途與邊界，不把程式碼裡存在的測試誤寫成某次執行結果。

Targeted：先證明這次改動本身

Targeted test 最接近這次 mutation。

例如 delegated ordering 的 targeted suite 會直接檢查：

• 一般使用者偽造 targetUserId 必須被拒絕；
• 不符合資格的 target 不可被代訂；
• target discovery 必須受 role 約束；
• delegated create / read / cancel 要遵守同一套 target eligibility。

這種測試的優勢不是「跑得少」，而是 failure 很容易回到這次改動。

若修改 delegated ordering，先跑這組 targeted test，可以快速回答：

我剛改的 contract 還成立嗎？

它不能回答另一個問題：

旁邊那些沒有直接修改的行為，有沒有被連帶破壞？

因此 Targeted PASS 的有效邊界只到「這次 mutation 的直接 contract」。

Regression：確認既有行為沒有跟著退化

完整 Worker test suite 不只包含 delegated ordering。

它還涵蓋 auth、permissions、orders、ledger、calendar、CORS 等既有 contract，也保留過去曾發生問題後留下的 regression tests。

這一類 Evidence 想回答的是：

局部修改完成後，原本已成立的行為還成立嗎？

Agent 很容易跨檔案修改 projection、route、authorization 或 ledger logic。局部 diff 看起來合理，不代表其他路徑沒有被影響。

因此 Regression 會補上另一類 Completion Claim：

Targeted PASS
→ 這次 mutation 的直接 contract 有證據

Regression PASS
→ 已知既有 contract 沒有在這次修改後退化

但這兩類 Evidence 仍然可能只發生在 local test environment。

它們不能自動證明部署後的 runtime 也一樣。

Smoke：本機都對，不代表部署後真的可用

Worker repo 的 smoke:cors 做的是另一件事。

它要求一個實際的 Worker base URL，然後直接向部署後的 /api/me 發 request。

它檢查：

• localhost origin 的 preflight；
• 127.0.0.1 origin；
• temporary remote origin；
• Authorization header 是否被 CORS 允許；
• unauthenticated GET 是否得到預期的 401 AUTH_REQUIRED；
• 未允許 origin 不得取得 Access-Control-Allow-Origin。

這些條件不是多寫幾支 local unit test 就能等價取代。

Smoke 想確認的是：

已部署的 runtime，最基本的真實路徑是否仍可達，而且部署後的 route / config / CORS contract 沒有失真？

所以 Smoke PASS 也有清楚限制。

它不代表所有 business logic 正確，更不代表完整 Regression 已跑完。

它只把 Evidence Boundary 延伸到「remote runtime 的這條路徑」。

三類不是固定套餐，而是三個不同問題

把三種 Verification 放回風險，可以得到一個更實用的判斷表：

因此「三個都跑」不是永遠正確。

純文件變更不需要 remote smoke。

局部 utility 修改也未必值得跑完整 production-oriented checks。

相反地，如果改動已跨到 deploy boundary，只跑 Targeted 再回報「verified」，就會把 Claim 寫得比 Evidence 更大。

Day 15 講過 Completion Claim 不能超過 Evidence；Day 17 再把這條規則落到 test purpose：

不是測試越多，Claim 就越強；而是每一個 Claim，都要知道是哪一類 Evidence 在支撐。

Agent 最需要的不是「多跑」，而是先判斷缺哪一類 Evidence

當 Agent 決定 Verification depth 時，可以先回答三個問題：

1. 這次 mutation 的直接 contract 是什麼？
2. 哪些既有 contract 可能被波及？
3. 是否已跨到需要 remote/runtime evidence 的邊界？

回答完，再決定跑哪些 Verification。

這比固定要求「每次都 full test + smoke」更能控制成本，也比只挑一支看起來相關的 test 更可信。

回報同樣要保留 Evidence Boundary：

Targeted: PASS
Regression: NOT RUN
Remote smoke: NOT RUN

這份結果不是失敗。

它只是在說明：目前證明到哪裡，以及還沒有證明什麼。

小結

Targeted、Regression、Smoke 最容易被誤解成「小測試、中測試、大測試」。

更準確的理解是：

• Targeted：證明這次 mutation 的直接 contract；
• Regression：證明已知 contract 沒有因這次 mutation 退化；
• Smoke：證明部署後特定 runtime path 真的可達。

三者可以一起出現，也可以只出現其中一部分。

判斷標準不是儀式，而是本次 Claim 需要哪些 Evidence。

下一篇要再多加一個變數：即使 Method 與 test scope 都一樣，換了 OS、runtime 或 toolchain，Verification 結果仍可能改變。那時候需要辨識的，就不只是 test type，而是 Execution Environment Identity。