Day 15 留下一條規則：

完成宣稱（Completion Claim）不能超過實際拿到的驗證證據（Verification Evidence）。

但光有證據還不夠。

當下看到一個 PASS，我可能還記得自己剛跑了什麼、在哪個 branch、改了哪些檔案。隔幾天、換一個 Session，甚至換另一個 Agent 接手後，如果畫面上只剩：

PASS

少掉的不是細節，而是判斷這份證據是否仍有效的條件。

要追問的是：

這個 PASS，是對哪一個系統狀態成立？

這就是 Day 16 要處理的問題：證據不只要有結果，還要保留它的來源脈絡。

同一句 PASS，可以來自完全不同的系統狀態

先看最簡單的例子：

npm test
→ PASS

如果下一個 Session 問：

• 當時是哪個 commit？
• worktree 是乾淨的，還是混著尚未提交的修改？
• 跑的是哪一組 test？
• command 有沒有替代或 fallback？
• OS、runtime、dependency 狀態是什麼？
• 有沒有已知 baseline failure？
• Production 根本沒驗，還是驗過但失敗？

只要其中幾個問題答不出來，原本那個 PASS 的有效範圍就會迅速縮小。

我以前比較容易把 Evidence 理解成「結果」。經過幾次長任務與跨 Session handoff 後，較完整的模型變成：

Evidence
=
Result
+ State Identity
+ Method
+ Environment
+ Scope
+ Limitation

其中最容易被漏掉的是狀態識別（State Identity）：這份證據究竟綁在哪一版內容上。

這條規則已經被寫進我的 Verification Skill

Day 16 的主證據直接來自我自己的 Agent governance repository，而非另外設計一套理想化格式。

ap-verification-core v0.5.0 對每一個實際執行的 verification command，都要求留下：

exact command
exit status
material output
affected verification name

下面兩句看似接近，證據強度其實不同：

tests passed

與：

command:
<exact declared command>

exit:
0

material evidence:
<output that supports this check>

verification:
<which contract this command is proving>

第一種只是摘要。

第二種才讓接手者有機會重新判斷「這個 PASS 到底證明了什麼」。

同一份 Skill 還明確限制：

manifest 列出 entry point，不等於 Agent 自動取得執行權限。

因此來源脈絡除了描述「做了什麼」，也必須保留權限邊界。否則離開原 Session 後，很容易把「當時能執行」誤讀成「當時被授權執行」。

State Identity 不能只寫 branch 名稱

如果 provenance record 只寫：

branch: main
test: PASS

仍然不夠。

因為 main 會移動。今天的 main 和三天後的 main 名稱相同，內容可能已經不同。

狀態識別至少要回答：

能不能重新定位到當時被驗證的內容？

依任務不同，可以是：

• commit SHA；
• Git blob SHA；
• changed-file ledger；
• dirty worktree 的已知變更集合；
• canonical / consumer 對應版本；
• release tag 所解析到的 source commit。

這也讓 Day 14 的 start-state ledger 在這裡有了另一個用途。

Day 14 用它回答「哪些既有修改不能碰」；Day 16 則用它回答「這份 Verification Evidence 是在哪個起始與完成 state 上成立」。

同一份 artifact，服務的是不同治理問題。

Baseline 不是一句「本來就壞了」

來源脈絡最容易被忽略的地方，是 failure attribution。

假設 regression 出現紅字，Agent 回：

這是 pre-existing failure。

如果沒有 before / after evidence，這句話只是印象。

ap-verification-core v0.5.0 對既有失敗（PRE_EXISTING_FAILURE）要求保留：

baseline result
current result
diff / source attribution
stable reproduction details
why failure is outside requested scope

而且如果 mutation 前沒有捕捉 baseline，不能因為「看起來很舊」或「這個 diff 好像無關」就補判成 pre-existing，只能標成：

UNKNOWN_ATTRIBUTION

這條規則把一個很常見的工程直覺：

應該不是我改壞的。

改成可驗證的問題：

你有沒有留下足夠的 before / after state，證明它不是這次引入的？

這已經不是保存 log，而是在保存因果歸因所需的證據。

Environment 要記，但 Day 16 不把它講完

另一個真實例子是 Windows 上的 Gradle。

Verification Core 對 GRADLE_USER_HOME 有明確規則：原本有值就保留；沒有時才從 USERPROFILE 推導，而且 Gradle 必須在同一個 PowerShell process 中執行。

最後還要記錄：

final GRADLE_USER_HOME
preserved or derived

原因很直接：

./gradlew test
→ PASS

如果換了 process environment、cache root 或 toolchain 後不再成立，原本的 PASS 就只能代表「在那個 execution environment 下成立」。

Day 18 會專門處理 Environment Identity，所以這裡只保留邊界：

Day 16 要求 Evidence 記得環境；Day 18 才討論如何判斷兩個執行環境是不是同一個。

最小 Provenance Record，不需要保存整個 Terminal

來源脈絡不等於 log dump。

幾百行 terminal output，不一定比十行結構化紀錄更有用。

對長任務來說，最小紀錄可以長成：

TARGET
這次要證明什麼

STATE IDENTITY
commit / blob / changed-file state

METHOD
exact command / observation

ENVIRONMENT
影響結果的 runtime / process / target context

RESULT
PASS / FAIL / NOT RUN / NOT VERIFIED

BASELINE
若涉及 failure，before / current 如何歸因

LIMITATION
這份 Evidence 沒有證明什麼

判斷某一欄要不要留，只需要問：

拿掉之後，未來的人還能不能正確判斷這份 Evidence 的有效範圍？

能，就不必為了完整而保存。

不能，它就不是多餘 metadata。

Evidence 要靠近它所證明的 State Change

最容易失去 provenance 的工作流通常長這樣：

修改
→ 繼續修改
→ 換 Session
→ 再補測試
→ 最後一起寫「都通過」

到最後，連執行者都可能回答不了：

這個 PASS 到底對應哪一版？

比較安全的順序是：

Known state
→ Mutation
→ Verification
→ Evidence record
→ Commit / PR / Handoff

這不代表每次 mutation 都必須立刻 commit。

重點是 Verification 與它所證明的 state 不能離得太遠。中間如果又混入新的 mutation，舊 Evidence 至少要重新判斷：

still applicable
or
stale

長任務要維持連續性，不能只靠記憶；state relationship 必須能留給下一個 Session。

Handoff 的價值，是讓接手者先判斷 Evidence 還能不能用

Verification Core 的 handoff 要求分開回報：

• selected profile / depth；
• changed-file 與 risk summary；
• fast-path gates；
• exact capability probe command、exit status 與 concise output；
• 實際跑過的 checks；
• 被 profile 排除而 NOT RUN 的 checks；
• escalation reason；
• commit / push / deploy status；
• remaining limitation。

這比一句 Done 麻煩，但換來的是一個更重要的能力：

接手者可以先判斷「當前 state 是否仍符合前一份 Evidence 的適用條件」。

如果 state、environment 或 verification scope 已經改變，舊 Evidence 不能直接沿用。

如果關鍵條件仍一致，它至少可以成為重新驗證時的可信起點。

這裡不能把 Provenance 說成「可以不用重跑」。它減少的是盲目重跑與重新猜測；需要 re-verification 時，仍然要重新驗。

Day 16 留下的規則

Day 15 解決的是：

Claim
不能超過
Evidence

Day 16 再加一層：

Evidence
不能脫離
State / Method / Environment / Scope

證據來源脈絡的重點，不在新增一份表格，而在保留一條可追溯關係：

這個結果，是在什麼 state、用什麼方法、於什麼環境、針對哪個範圍取得，而且有哪些沒有被證明。

只要這條關係還在，隔幾天、換 Session、換 Agent，接手者就還能判斷這份 PASS 值不值得相信。

下一個問題則不同。

同樣都是 Verification，Targeted、Regression、Smoke 本來就在回答不同風險。

Day 17 再把這三種 Evidence 各自能證明什麼拆開來看。