Agent 做完一個任務後，最容易讓人鬆一口氣的句子，大概就是：

Implemented successfully.

問題是，這句話幾乎沒有告訴我「到底證明了什麼」。

它可能代表 patch 已寫完，也可能代表 build 沒報錯；可能跑過 targeted test，也可能只是 Agent 看完 diff，覺得邏輯應該成立。

當任務只改一小段文件時，這種模糊感不一定會立刻出事。

但一旦開始碰跨檔案邏輯、身份權限、部署或資料一致性，「完成」如果沒有對應 Evidence，就很容易從一句摘要變成一個過度承諾。

Day 14 處理的是另一個問題：進入已有變更的 workspace 後，哪些地方要 STOP / AVOID / PROCEED，以及什麼時候不能再走 FAST。那是在回答「這次能不能安全地改」。

到了 Day 15，問題換成：

改完之後，你實際證明到哪裡？

最危險的不是 FAIL，而是把局部 PASS 說成全部完成

我原本以為 Verification 的重點，是讓 Agent 多跑一點 test。

讓做法改變的，不是 test 數量，而是一種更難察覺的情況。

假設 Agent 只跑了：

targeted auth test
→ PASS

最後卻回：

All tests pass.

這裡沒有任何一個 test 失敗。

問題在於 Claim 比 Evidence 大。

同樣地：

build
→ PASS

只能說明這次 build path 通過。

它不能自動推出：

runtime behavior verified
production ready
deployment safe

這幾句話看起來只差一點語氣，實際上跨了完全不同的證明邊界。

Verification Core 可以先收斂成一句規則：

Completion Claim 不得超過實際取得的 Verification Evidence。

這比「一定要跑很多測試」更重要。

這條規則已經不是文章裡的口號

在 agent-platform 裡，ap-verification-core 已經把結果語意固定下來。

ap-verification-core v0.5.0 要求，每一個列入報告的 verification check 都必須明確落在四種狀態：

這份 contract 明確要防的一個 failure mode，是「沒跑的檢查從報告裡消失」。如果 completion report 只留下幾個綠色 PASS，接手者很容易把它理解成整體已驗證；因此 Skill 要求把缺口保留下來。

PASS
命令成功完成，而且輸出足以支撐這個 check

FAIL
命令失敗，或 check 找到失敗

NOT RUN
這個 check 沒有實際執行；可能是命令無法啟動，也可能是依 verification profile 明確排除，必須保留原因

NOT VERIFIED
這個 check 需要人工、裝置、外部服務或 Production Evidence，
但這次沒有實際執行

這四個狀態解決的是一個很具體的模糊地帶：

沒有跑
≠
沒有發現問題

NOT RUN 與 NOT VERIFIED 都不是 PASS。需要手機、外部服務或 Production 才能確認的行為，如果這次沒有取得對應 Evidence，正確的結論只有：

這一層還沒有被證明。

Verification Core 第一件事：先把「沒驗證」保留下來

這個差異在 governance-only 的任務特別明顯。

ap-verification-core 會先看這次改了哪些檔案，以及有哪些已知風險。這些資訊會形成 changed-file ledger（變更檔案清單）與 risk evidence（風險證據），再用來決定 verification depth（驗證深度）。

它的預設分類是：

GOVERNANCE_ONLY（治理文件、Skill、規則類變更）
→ FAST

FRONTEND（前端程式）
→ STANDARD

BACKEND_GAS（Google Apps Script 後端）
→ STANDARD

IDENTITY_AUTH_HIGH_RISK（身份、權限、資料完整性等高風險變更）
→ HIGH_RISK

UNKNOWN_MIXED（範圍不明，或治理與執行變更混在一起）
→ 至少 STANDARD，必要時 HIGH_RISK

FAST 不是「比較隨便」，而是：Evidence 已足以證明這是一個範圍受限、沒有 runtime impact 的治理變更，因此只跑與風險相符的檢查。

例如 governance-only / FAST 不會硬跑前端完整測試、裝置／登入流程或 Production checks；被 profile 排除的檢查仍必須明確回報：

NOT RUN
→ GOVERNANCE_ONLY / FAST
→ no runtime-impact evidence

如果 completion report 只留下幾個綠色 PASS，接手者很容易腦補成「全部都驗過了」。把「這次沒有必要跑」也留下來，報告才不會比 Evidence 看起來更完整。

FAST、STANDARD、HIGH_RISK 不是三種「完成程度」

Day 14 已經提過 FAST → STANDARD → HIGH_RISK，這裡需要再把它放回正確位置。

它回答的是：

這次變更需要多深的執行、Verification 與 Review？

不是：

這次到底完成了百分之多少？

例如一個 governance-only 變更可以合法停在 FAST，而且完整通過它應有的 checks。

反過來，一個 identity / auth 變更即使 targeted tests 都 PASS，也不代表它可以硬壓回 FAST。

在 ap-verification-core 裡，FAST 必須同時滿足多個 gate：

• start-state ledger 完整；
• 沒有 target collision；
• 沒有 unrelated changed file；
• 沒有 unowned change；
• scope 是 GOVERNANCE_ONLY；
• 沒有 runtime-impact evidence；
• 沒有 high-risk signal；
• capability 與前序 verification 沒有 unresolved unknown。

只要 gate 不成立，就必須記錄原因，從 FAST 升到 STANDARD；若出現 high-risk evidence，再升到 HIGH_RISK。

Depth 是 風險決策。

而 PASS / FAIL / NOT RUN / NOT VERIFIED 是 證據結果。

兩條軸不能混在一起。

Completion Contract 應該約束什麼

這裡不需要再發明一套「完成五級制」。層級一多，Agent 很容易開始填滿表格，反而忘了回答這次任務真正需要證明什麼。

更重要的是這條鏈：

本次 Acceptance Criteria
↓
這次最可能失敗在哪裡
↓
選擇對應的 verification
↓
每個結果保留 PASS / FAIL / NOT RUN / NOT VERIFIED
↓
最後的 completion claim 只能停在 Evidence 已到達的位置

例如：

What changed
→ verification profile selection

What was verified
→ declared static / Git / Skill checks PASS

What was not run
→ frontend runtime checks NOT RUN

What was not verified
→ production behavior NOT VERIFIED

最後可以說：

Governance verification passed for the declared FAST profile.

卻不能直接把它擴張成：

Everything is verified.

後者把「本次適用範圍內通過」偷換成「所有可能風險都已被證明」。這正是 Completion Contract 要阻止的越界。

Verification 也不能自己決定權限

還有一個我以前很容易混在一起的地方。

ap-verification-core 的 Skill 第一段就明確寫：

manifest lists an entry point; it does not grant permission.

換句話說：

agent.yaml 有這個 command
≠
Agent 就有權執行

Verification 能做到某件事
≠
這次任務就被授權做那件事

Skill 也明確禁止把 Verification 當成 deploy、commit 或 push 的授權來源。

Day 12–14 先回答「這次被允許改什麼、在哪裡改、遇到既有 mutation 怎麼處理」；Day 15 才回答「改完後，能拿出什麼證據支持完成」。

如果兩層混在一起，Agent 可能因為「需要驗證」就自行多做 deploy，反而跨過原本的 permission boundary。

Code Review 也不能被 PASS 吃掉

ap-verification-core 還刻意把 Verification 與 independent review 分開。

因為自動化 checks 回答的是：

已宣告、可執行的 Evidence 有沒有通過？

獨立 Review 回答的則是另一組問題：

• requirement 有沒有理解錯；
• architecture / contract 有沒有 drift；
• auth 或 security boundary 有沒有漏掉；
• 有沒有 hidden edge case；
• tests 本身是不是漏驗了一個風險；
• 是否增加了不必要的 complexity。

可以直接寫成：

tests PASS
≠
review complete

對 Agent 而言，這個切割尤其重要：模型很容易把「剛剛跑的 checks 都是綠的」延伸成「實作應該沒問題」。Verification Core 要把這個推論截斷。

Handoff 不該只剩「Done」

ap-verification-core 最後要求 completion handoff 分開交代：

Status / outcome
Changed files
Verification evidence
Independent review
Pre-existing changes / collisions
Commit status
Push status
Deploy status
Remaining follow-up / debt

這個格式的價值不在欄位多，而在於把一句「完成」裡常被揉在一起的狀態拆開。

例如：

Implementation complete
Verification PASS for declared checks
Independent review not performed
Push not performed
Deploy not performed
Production behavior NOT VERIFIED

它沒有 Implemented successfully 那麼乾脆，卻更接近接手者真正需要的資訊：不用再猜這個「successfully」究竟包含了哪些 Evidence。

Day 15 留下的規則

核心只有一句：

可以少驗證，但不能多宣稱。

具體落成四個判斷：

1. verification depth 由風險決定，不是完成百分比。
2. PASS / FAIL / NOT RUN / NOT VERIFIED 必須保留差異，缺口不能被綠色結果吃掉。
3. completion claim 只能停在實際 Evidence 已到達的位置。
4. Verification 不會自動取得 deploy、commit、push 或取代 independent review 的權限。

Verification Core 的目的不是讓報告看起來更完整，而是讓「完成」重新和 Evidence 綁在一起。

Day 16 再處理下一個問題：

今天這個 PASS 有證據，但隔幾天、換一個 Session、換一個 Agent 之後，還能不能知道它當時為什麼成立？