id: CASE·META-134
title: "指紋退場——當驗不到東西的數字被當成根據"
subtitle: "從一次 MCP 修復，走到 269 個雜湊欄位的退場與「語義在指紋之前」"
category: Case / Meta / Provenance / Tooling / Governance Correction
version: v1.0
status: Active / Case Layer / Engineering-Decision-Executed / Not Doctrine
date: 2026-09-20
updated: 2026-09-20
date_basis: 本 session 環境日期。

epistemic_status: |
  本案記錄一次已執行的工程決定與它的理由。
  「指紋只在存在第二份可供比對時才做事」是本案的核心判斷，
  它是關於驗證條件的分析，不是關於資料完整性或密碼學的普遍命題；
  也不主張 git 保證來源的真實性——它只保證入庫之後沒有被無聲修改。

case_type:
  - engineering_decision_case
  - governance_correction_case
  - tooling_retirement_case

source:
  type: in-session engineering record
  form: 本案不由外部對話催生，事件全部發生在本 session 的工作樹與 git 操作中，
    可由 commit 序列逐步重建，因此不另存來源檔。
  preservation: 決定、實測數字與兩次自我更正均在下文逐項記錄。

read_basis: 80edbf60faa3152fb110f11b90925ecaf0fb9da5
anchor_authorization: Darren 於本 session 逐步裁定——先「語義沒問題就補上新的指紋」，
  再「連原始檔案的指紋都沒必要留」，最後「那就一起退場吧」。施工由 Claude Opus 5 承擔。

authors:
  - Ta-loom / Darren（核心判斷：語義在指紋之前；指紋唯一的意義是看語義有沒有被改）
  - Claude Opus 5（實測、判讀、施工、兩次自我更正）

related:
  - CASE·META-132（保真治理沉積成修改地形；本案是它的反向個案）
  - CASE·META-133（前一案；其來源檔是本次 14 筆落差之一）
  - CASE·META-122（量尺型別帳；公式不得代簽主權與判定）
  - EPOCH-019 v0.2-draft（止的本體論；工程退居為生成條件）
  - SPEC·999（謙遜條款）

scope:
  included:
    - 記錄「指紋只在存在第二份可供比對時才做事」這個判準
    - 記錄 14 筆落差的逐筆語義判讀與其方法
    - 記錄退場範圍、保留項目與已知代價
    - 記錄施工者在本輪的兩次自我更正
  excluded:
    - 主張雜湊或簽章在一般情境下無用
    - 主張 git 能證明來源檔忠於當初的對話
    - 為既有 CASE 的正文判讀背書

CASE·META-134

指紋退場——當驗不到東西的數字被當成根據

0. 案例一句話

本庫為來源檔記了 269 個 bytes 與 SHA-256 欄位，第一次真的去驗，報出 14 筆落差， 逐筆讀完未發現任何入庫後的語義改動；追下去發現這些數字從來沒有第二份可比對， 連「入庫前是否忠於原對話」都驗不了，於是整批退場，並把「語義在指紋之前」立為規矩。

1. 事件次序

1. trp-public MCP 在遠端 session 啟動即斷線。原因是 node_modules 被 gitignore， 新容器沒有跑過 npm ci。加上 SessionStart hook 後修復。
2. 修復後實測 MCP，順帶發現 crosscheck.py 整份沒有 sha256 字樣， 而 MCP 看不到 DOCS/sources——那些指紋寫下來之後，沒有任何程式讀過。
3. 補上 --only integrity。第一次實跑：49 筆宣告中 35 筆相符、10 筆 CRLF 落差、4 筆不符。
4. 錨點裁定：「指紋對不上無妨，只要回去讀文件看看語義有沒有跑掉就好。 這是語義庫，不是指紋庫。」依此逐筆判讀，全部判定語義保存，補記現況指紋，49 筆全相符。
5. 錨點續問：「在 git 裡面給文件上指紋有實質意義嗎？反正 git history 都看得到。」
6. 施工者答：庫內副本的指紋確實與 git 重複，但原件的指紋記的是 git 管不到的跨界事實。
7. 錨點推翻：「我甚至覺得連原始檔案的指紋都沒必要留，原始檔案本來就是我跟 AI 聊天生成的東西， 沒有指紋才正常。」——這個反駁成立，見 §2。
8. 整批退場。

2. 指紋在什麼條件下才做事

指紋是比對工具，不是保存工具。它只在存在第二份可供比對時產生資訊。

本庫的來源檔是 Darren 與 AI 的可見對話。第二份在哪裡？

• 平台不保留可雜湊的正本；
• 交付當下的工作檔早已不存在；
• 庫內那一份就是唯一的一份。

於是那串雜湊只能驗它自己。它是一個永遠無法被否證的數字： 對得上不增加任何信心（本來就是同一份），對不上也無法斷定是竄改、 正規化、還是當初記錯——這三者在缺少第二份時無法區分。

施工者一度主張 original_sha256 例外，理由是它記錄「進庫之前長什麼樣」。 但這只是把同一個問題往前推一格：進庫之前那一份同樣不存在於任何地方。 記錄一個無法被比對的狀態，不等於保全了它。

upstream_attachment_sha256 也不例外。實查四處，記的都是錨點當初貼回的附件檔， 那份附件同樣已不存在。

3. 這次實測：14 筆落差，未發現入庫後的語義改動

這張表能支持的與不能支持的，必須分開講。 下列四步都在庫內進行，支持的結論是「未發現入庫後的語義改動」； 它們無法驗證入庫前是否忠於原對話——那需要第二份，而第二份不存在（§2）。 把這兩件事講成同一件，正是本案要退場的那種錯覺。

判讀方法，依序：

1. git 歷史。 14 個來源檔全部只有一個 commit，加入後從未被修改， 工作樹與 blob 一致。語義不可能在庫內跑掉。
2. 行數。 全部與宣告吻合（差 1 者為「可見行」與末行換行的計法差異）。
3. 「只移除 CR」的特徵。 位元組差必須不大於行數。13 筆通過， 其中 10 筆差值正好等於行數（全檔 CRLF），3 筆略小（混合行尾）。 移除 CR 不改變任何有意義的字元。
4. 實讀。 唯一不符特徵的是 META-118——它宣告 LF，檔案卻反而多 59 bytes。 讀進去，答案在來源檔自己的第 8 行：「v1.2 僅泛化遮罩標籤，不改其餘對話文字」。 那是依 INDEX·META-110-119 F54 對敏感個人史所做的隱私遮罩泛化， 對話正文一字未動，且方向是降低可識別性。

給出答案的是 git 歷史、行數與實讀。指紋一次都沒有真的驗到東西， 它只負責製造了 14 個警報。

4. 為什麼「正典」也不需要

錨點提出「比較可能需要指紋的是正典」。分析後，正典同樣不需要，理由不同：

git 的每個物件本身就是內容雜湊——blob 的 ID 由內容算出，這是 git 的定址方式， 不是附加功能。改一個位元組 ID 就不同，git log -p 逐次可見； 不改寫歷史就無法無聲修改，而改寫歷史會把寫在 CASE 裡的那串指紋一起改掉， 所以手抄指紋也防不了那件事。

要釘住「我是讀著哪個狀態寫的」，read_basis: <commit> 嚴格更好： 它一次釘住整個庫，同時交代了當時其他文件是哪一版； 單檔指紋回答不了這個問題。本案自身即以 read_basis 釘住。

5. 退場範圍

保留：

• .gitattributes（DOCS/sources/** -text）。它與指紋無關，作用是不讓 git 在 commit 當下靜默改寫存檔的對話內容。行尾不是語義，但不被動手仍然較好。
• 所有舊值都在 git 歷史裡，一個都沒有消失。
• normalization_note、preservation、capture_scope 等語義欄位全部保留—— 它們記的是「這份檔案被怎麼處理過」，那是判讀，不是計數。

6. 已知代價

退場之後，本庫不再有任何記錄聲稱來源檔忠於當初的對話。

這必須明說，不能含混：git 保證的是「入庫之後沒有被無聲修改」， 不是「入庫的就是當初收到的」。後者從來沒有被任何機制保證過—— 指紋給人一種它被保證了的錯覺，而那正是退場的理由，不是反對退場的理由。

真正承擔這件事的，是 capture_scope 與 preservation 裡的具名陳述， 以及歸檔者的署名。那是人的承擔，不是數字的承擔。

7. 施工者的兩次自我更正

一併記錄，因為兩次都改變了後續判斷：

1. 把已知的事講成新發現。 施工者將 CRLF 正規化呈現為本輪發現。 實則 DOCS/sources/conversations/README.md 有一則 2026-09-17 的註記 （Claude Opus 5），已精確診斷 core.autocrlf=true 加無 .gitattributes， 量了三組抽樣，並明列 .gitattributes 為待決的 repository 級變更。 本輪做的是接下那個決定，不是發現那件事。
2. 兩次數字錯誤。 施工者先以 grep 概估「50 處可退場、留 4 處」， 實際清點為 86 個雜湊欄位、十種鍵名，且不存在「真的還有第二份可比對」的殘留集合； 更正後才由錨點重新裁定範圍。另一次是移除欄位的正則要求鍵名以 sha256 結尾， 漏掉 original_sha256_before_repository_rename 等帶後綴者。

另有兩次施工事故，都由施工後的獨立比對抓到，而不是由施工當下的檢查抓到：

1. 補記指紋時所用的正則以 \s*$ 收尾，而 \s 含換行，在區塊末行吃掉換行， 使下一個頂層鍵被併入前一行，改壞了兩個 CASE 的 YAML。 以「與 HEAD 逐檔比對解析狀態」抓到，14 檔全部還原重做。 --only integrity 當時仍回報「全部相符」—— 能驗的東西驗過了，不代表沒弄壞別的。
2. 批次移除欄位時以鍵名判斷，於是把 EPOCH/reviews 四份審讀帳裡的 integrity: 一併刪掉——但那不是計數，是治理條款： 「既有事件不可改寫；更正另立事件並回指。」 逐條檢視刪除行時抓到，該目錄還原後改以值的形態判斷再重跑。 鍵名相同不代表是同一種東西；批次操作必須看值。

8. 本案提出的候選命題

1. 指紋是比對工具，不是保存工具。在沒有第二份可供比對的條件下，它不產生 可否證的資訊。這是條件式命題，不是「雜湊無用」的通則——條件成立與否要逐案判斷。
2. 在內容定址的版本控制系統內，對系統內檔案手抄指紋與系統本身重複。
3. 釘住閱讀狀態，commit 比單檔指紋嚴格，因為它同時交代了周邊文件的版本。
4. 保全語義的承擔在具名陳述與署名，不在數字。
5. 一個永遠無法被否證的檢查，其產出全部是假警報——它的成本是真的，收益是零。

9. 競爭解釋與可推翻位置

• 「留著又不佔空間。」 不成立。本輪實測：它佔的是注意力與算力， 一次重驗製造 14 個需要人判讀的警報，逐筆讀完未發現任何入庫後的語義改動；並且它讓人誤以為 來源真實性已被保證（§6）。
• 「哪天需要跨庫比對呢？」 屆時第二份才存在，屆時再算即可—— 雜湊是可隨時重算的函數，不是必須事先保存的資料。這是退場成立的關鍵。
• 可推翻位置：若出現一份來源檔，庫外確實另有可比對的副本 （正式發布本、對造自行留存的回流件、第三方存證），則為該筆記錄指紋重新成立。 規矩留了這個例外。

10. 失效條款

F1: 若以本案主張雜湊、簽章或內容定址在一般情境下無用 → 失效；
    本案只處理「不存在第二份可比對」這一種條件。
F2: 若以本案主張 git 能證明來源檔忠於當初的對話 → 失效；見 §6。
F3: 若以本案為由刪除 normalization_note、preservation、capture_scope
    等語義欄位 → 失效；退場的是計數與指紋，不是判讀。
F4: 若以本案為由改寫 git 歷史以「清掉」舊指紋 → 失效；
    舊值留在歷史裡正是本案成立的前提之一。
F5: 若庫外確實存在可比對的第二份副本，仍以本案拒絕記錄指紋 → 失效；見 §9。

11. 核心壓縮

這是語義庫，不是指紋庫。 指紋唯一的意義，是看看語義有沒有被修改；它自己不是被保護的對象。 當它連這件事都做不到的時候，它就只是一個需要被維護的數字。

12. 開放問題

1. read_basis 目前只有 8 處使用。要不要成為新 CASE 的必填欄位？
2. 既有正文中有 5 處以文字引用已退場的欄位名（如「與本 CASE 登錄的 repository_copy_sha256 逐字元吻合」）。那是當時確實做過的查核紀錄， 陳述為真但已無法就地解析。本輪在 CASE·EPOCH-012 與 CASE·META-093 的 4 處加註指向本案，原句不改；第 5 處位於已封口的 INDEX-META-090-099， 屬記錄層，預設不動，未加註。是否進一步處理留待具名治理位置。
3. EPOCH/reviews 的審讀帳本輪一併移除了 3 檔中的計數欄位， 但其 integrity: 治理條款完整保留（見 §7）。審讀帳所引的 sealed source 與 frozen snapshot 機制未在本輪檢視， 是否同受本案判準影響，留待具名治理位置。