索賠分類帳（Claim Ledger）
報告中的每個要點都有一個穩定的 ID。索賠會分批檢查，風險最高的優先：每個索賠都會得到一個可測試的陳述、使其錯誤的條件、最佳案例以及引用證據。然後做出判決。修正會透過一個腳本就地重寫該要點，該腳本會備份報告並重新推導每個新數字。判決日誌是唯追加的，因此歷史記錄保存在那裡，而不是報告中。
此工具基於其首次使用的分類帳（一份商業計畫研究報告，2026 年 10 月：517 個索賠，29 個批次）構建。它第一個就找到了該報告的最大錯誤。
下面的 L 表示 python3 -I ~/.claude/skills/claim-ledger/ledger.py -c <project>/ledger.toml。
每個報告的設定，一次完成
-
設定檔。 為設定檔和資料挑選一個專案資料夾。執行
L init <report.md>：它會寫入ledger.toml並列出報告的標題。 -
規則。 在設定檔中：
- 重要性： 3 = 某個決策或通過/不通過測試取決於該要點，2 = 計畫和金錢，1 = 其餘部分。
- 僅在標記時檢查的類型： 來源、方法說明、使用者自己的決策、摘要。
- 標籤關鍵字， 如果報告以其他方式標記其證據。
-
尾端規則：詢問使用者一次；這是他們的決定。 給他們第一個分類帳的數字。第 1-9 批次（風險最高）在 27% 的首次檢查中發現了問題。第 10-29 批次佔了 73% 的工作量，僅發現了 7% 的問題。提供三個選項：
- 檢查每個要點；
- 以某個比率抽樣檢查低優先級已發佈數據的要點；
- 當某個批次的首次檢查問題率低於某個閾值時停止。
將答案寫入
[tail]。 -
標記。
L sync會備份報告，然後在每個要點第一行的末尾添加一個不可見的<!-- cl:ID -->。告訴使用者報告現在帶有這些標記；L export clean.md會寫出一個不含這些標記的副本。 -
交接。 在專案的
HANDOFF.md中加入一個分類帳章節：設定檔路徑、命令、尾端規則。
完成條件： 同步程序報告了要點和索賠的數量，L queue 10 顯示了依賴於哪些要點進行決策，並且交接文件命名了設定檔。
每個批次（約 20 個要點）
L template。 在每個批次開始時閱讀它，以便在壓縮後規則仍然是新的。第一個分類帳的模板從第 10 批次開始退化。L queue 20，然後L show ID...。- 按順序，每個要點：
statement→wrong_if→best_case→ 搜尋 →evidence→ 判決 →result。- 首先在外部搜尋。 使用主要來源：文件、數據集、發布者自己的頁面。專案的筆記最後使用，並標記為
notes。 - 在寫入任何數字之前， 使用
<data>/analysis/中的腳本計算每個數字。 - 依賴項。 當一個要點變更時，
L find <phrase>會找到依賴於它的要點；在flag中列出它們的 ID。
- 首先在外部搜尋。 使用主要來源：文件、數據集、發布者自己的頁面。專案的筆記最後使用，並標記為
- 撰寫批次。 記錄存放在
<data>/edits/batchNN-records.json。複製edit-template.py到<data>/edits/batchNN.py並填入：E，編輯：每個要點就地重寫；QUOTED，從來源複製的數字；check()，它會重新推導每個其他添加的數字。
- 執行它。 先執行
python3 -I batchNN.py --check；修正它拒絕的所有內容；然後不帶--check執行它。- 一個不編輯任何內容的批次仍然會通過
E = []的腳本執行。 - 腳本是編輯到達報告的唯一途徑。
- 一個不編輯任何內容的批次仍然會通過
- 報告。 重建專案擁有的任何渲染視圖（例如地圖）。將
L status的內容貼到交接文件中，並將其第一行發布給使用者。
完成條件： 腳本執行乾淨，日誌增加了該批次的記錄，並且交接文件包含了新的狀態行和佇列頭。
鏈接批次
- 連續執行。 一旦使用者說「開始」，就連續執行批次，之間無需提示，每次執行後發布狀態行。
- 在停止規則處停止。 當
queue印出 STOP RULE MET 時，回報比率並詢問使用者是否繼續。queue --all會繼續。 - 因使用者決策而停止： 金錢、聯繫任何人、由他們決定的決策。也為真正的障礙而停止，並說明原因。
- 接近上下文限制時： 完成正在處理的批次，更新交接文件，並說明新的對話將從佇列頭繼續。
- 稽核。 每 10 個批次和最後執行
L audit。- DRIFT 行表示後期的判決比早期的更薄弱。
- 在呼叫分類帳完成之前，使用完整模板重新檢查後期 CONFIRMED 要點的隨機樣本。
重寫要點
- 就地重寫。 該要點以清晰的方式說明正確的內容，附帶其來源，就好像它一直都是正確的一樣。日誌保留舊文字、證據和日期；
L show ID會列印歷史記錄。 - 拆分要點： 將原始索賠保留在第一個片段中，因為標記停留在第一行。新的片段在相同運行中獲得 ID。
- 在腳本外部進行的編輯 仍然會浮現。已檢查過但文字變更的索賠會以 CHANGED 狀態返回，需要新的判決。
自我檢查
同一個模型撰寫報告並檢查它。這是該方法的弱點，而此工具使其可見，而不是隱藏它。
- 證據
type：outside：為此檢查而讀取的獨立來源；derived：腳本的算術運算，它會檢查數學但不會檢查其輸入；notes：專案自己的材料，它顯示一致性，而非真相。
- 僅限筆記。 僅以
notes支持的 CONFIRMED 判決在顯示時會顯示為 CONFIRMED (notes only)。其result會顯示「與筆記相符；未找到外部來源」。 - 最後， 為使用者列出重要性為 3 且其判決僅依賴於筆記或衍生證據的要點。這些是要他們自己對主要來源進行驗證的要點。
參考
- 判決：
- CONFIRMED：按原樣支持。
- CORRECTED：曾經錯誤；報告現在說的是正確的。
- EXPANDED：正確；報告現在包含了更多內容（範圍、警告、來源）。
- CHALLENGED：存在一個可信的反對理由；報告說明了這一點。
- UNKNOWN：尚未解決；報告說明了在哪裡可以找到答案。
- 佇列順序：
- RE-CHECK，由較新記錄標記的要點；
- CHANGED；
- 按優先級排列的未決索賠，優先級 = 重要性 × 薄弱程度，相同時按報告順序。
- **
<data>中的檔案：points.json：註冊表，包括每個要點的原始文字；verdicts.jsonl：唯追加的日誌；追加，切勿編輯任何一行；edits/、analysis/、backups/和view.md，人類可讀的視圖。
record和編輯腳本拒絕的內容：L template會列印完整清單。整個批次會被拒絕，不會寫入任何內容。- 自我測試：
python3 -I ~/.claude/skills/claim-ledger/selftest.py會印出 27 個 PASS 行。
設計決策
- ID 標記位於要點第一行的末尾。 行首的註解會在 CommonMark 中開啟一個原始 HTML 區塊，因此該行其餘部分的 Markdown 將停止渲染。
- 什麼算作一個要點： 葉級列表項、段落、表格行，以及擁有 12 個或更多自身單字的父級項目。一般報告在散文和表格中包含索賠，而不僅僅是項目符號。
- 模板在程式碼中強制執行，一個錯誤的記錄會拒絕整個批次。 第一個分類帳的
best_case在規則僅存在於對話中時，降至 0/28 的修正，而wrong_if降至 57%。 - 除了 CONFIRMED 之外的判決需要要點的文字已變更（或
elsewhere: IDs）。CORRECTED 表示報告現在說的是正確的，因此工具會檢查它是否如此。 - 每個添加的數字都必須在
check()中重新推導，或在QUOTED中宣告並附帶其來源。 這使得第一個分類帳的第 3 批次規則（「在寫入每個數字之前計算它」）變得機械化。 - 已編輯且已有判決的索賠 必須在同一批次中記錄或標記，因此沒有判決會默默失效。
- 每個批次只有一個腳本，同時執行檢查、應用和記錄。 不可能發生半應用的批次。
- 尾端規則已交付。 其範圍和成本由使用者決定。
- 停止規則僅計算首次檢查，將 CORRECTED 和 CHALLENGED 視為問題。在第一個分類帳中，66 個早期問題中的 42 個來自重新檢查，這誇大了早期的比率。
- 抽樣是確定性的（種子和 ID 的雜湊值），因此樣本在多次運行以及添加要點時保持不變。佇列也會印出估計的剩餘問題，附帶 95% 的上限。
- 證據引用上限為 14 個單字，以保持在 15 以下。上限由
max_quote_words設定。 - 設定檔是 TOML，因為它允許註解並且 Python 原生讀取它。
- 稽核已根據第一個分類帳進行檢查。 重播其 546 條記錄會重現 10 月 13 日的稽核結果：在批次 1-9 中，89 個首次檢查中有 24 個是問題，在批次 10-29 中，393 個中有 28 個是問題。它會標記漂移：
wrong_if從 99% 降至 55%，問題的best_case從 80% 降至 0%，每個記錄的證據從 1.71 降至 1.20。舊日誌沒有證據type，因此它們被視為僅有筆記。