claim-ledger

クレーム台帳

レポートのすべてのポイントに安定したIDが割り当てられます。クレームはバッチでチェックされ、リスクが高い順に処理されます。各クレームには、検証可能なステートメント、誤りとみなす条件、最善のケース、引用エビデンスが与えられ、その後判定が下されます。修正は、レポートをバックアップし、すべての新しい数値を再導出するスクリプトを通じてその場でポイントを書き換えます。判定ログは追加専用であるため、履歴はレポートではなくログに残ります。

最初の台帳として使用された（2026年10月の事業計画調査レポート、517のクレーム、29バッチ）に基づいて構築されました。そのレポートの最大の誤りを最初に見つけました。

L は以下のコマンドを意味します: python3 -I ~/.claude/skills/claim-ledger/ledger.py -c <project>/ledger.toml

セットアップ（レポートごとに1回）

1. 設定。 設定とデータ用のプロジェクトフォルダを選択します。L init <report.md> を実行すると、ledger.toml が作成され、レポートの見出しが一覧表示されます。

2. ルール。 設定内:

   • 重要度: 3 = 決定やGo/No-Goテストがそのポイントに依存する、2 = 計画と資金、1 = その他。
   • 種類 はフラグが立った場合のみチェック: ソース、方法ノート、ユーザー自身の決定、サマリー。
   • タグワード（レポートがエビデンスを別の方法でマークしている場合）。

3. テールルール: ユーザーに一度確認すること; それはユーザーの判断です。 最初の台帳の数値をユーザーに示します。バッチ1～9（最もリスクが高い）では、最初のチェックで27%に問題が見つかりました。バッチ10～29は作業の73%を占め、7%の問題が見つかりました。3つのオプションを提供します:

   • すべてのポイントをチェックする;
   • 低優先度の公開数値ポイントを一定の割合でサンプリングする;
   • バッチの最初のチェック問題率がしきい値を下回ったら停止する。

   答えを [tail] に書き込みます。

4. マーク。 L sync はレポートをバックアップし、各ポイントの最初の行の最後に非表示の <!-- cl:ID --> を追加します。レポートにこれらのマーカーが含まれることをユーザーに伝えます。L export clean.md はマーカーなしのコピーを書き出します。

5. ハンドオフ。 プロジェクトの HANDOFF.md に台帳セクションを追加します: 設定パス、コマンド、テールルール。

完了条件: sync がポイント数とクレーム数を報告し、L queue 10 が決定に依存するポイントを表示し、HANDOFF が設定を指定していること。

各バッチ（約20ポイント）

1. L template。 各バッチの開始時に読み取り、コンパクション後もルールを新鮮に保ちます。最初の台帳のテンプレートはバッチ10以降で劣化しました。
2. L queue 20、次に L show ID...。
3. ポイントごとに順番に: statement → wrong_if → best_case → 検索 → evidence → 判定 → result。
   • 最初に外部を検索。一次情報源（提出書類、データセット、発行元のページ）を使用します。プロジェクトのノートは最後に使用し、notes とタイプします。
   • すべての数値を計算 するには、どこかに書き込む前に <data>/analysis/ 内のスクリプトを使用します。
   • 依存関係。 ポイントが変更された場合、L find <phrase> でそのポイントに依存するポイントを見つけます。それらのIDを flag にリストします。
4. バッチを書き込みます。 レコードは <data>/edits/batchNN-records.json に保存されます。edit-template.py を <data>/edits/batchNN.py にコピーし、以下を記入します:
   • E（編集内容）: 各ポイントをその場で書き換え;
   • QUOTED（引用）: ソースからコピーされた数値;
   • check(): 追加された他のすべての数値を再導出します。
5. 実行します。 python3 -I batchNN.py --check を最初に実行し、拒否されたものを修正してから、--check なしで実行します。
   • 何も編集しないバッチでも、E = [] でスクリプトを実行します。
   • スクリプットのみがレポートに編集を適用できます。
6. 報告。 プロジェクトが持つレンダリングビュー（マップなど）を再構築します。L status の出力をHANDOFFに貼り付け、その最初の行をユーザーに投稿します。

完了条件: スクリプトが正常に実行され、ログがバッチのレコード数だけ増加し、HANDOFFに新しいステータス行とキューヘッドが含まれていること。

バッチの連鎖

• 連続実行。 ユーザーがGoと言ったら、バッチを続けて実行し、各バッチ後にステータス行を投稿します。プロンプトは挿入しません。
• 停止ルールで停止。 queue が STOP RULE MET と出力したら、率を報告し、ユーザーに続行するかどうかを尋ねます。queue --all は続行します。
• ユーザーの判断が必要な場合に停止: 金銭、連絡、ユーザーの決定。実際のブロッカーでも停止し、その理由を伝えます。
• コンテキスト制限が近い場合: 現在のバッチを完了し、HANDOFFを更新し、新しいセッションでキューヘッドから続行することを伝えます。
• 監査。 10バッチごとおよび最後に L audit を実行します。
  • DRIFT 行は、後半の判定が前半よりも薄いことを意味します。
  • 台帳完了前に、後半の CONFIRMED ポイントのランダムサンプルを完全なテンプレートで再チェックします。

ポイントの書き換え

• その場で書き換えます。 ポイントは、ソースとともに正しいことを平易に述べ、最初から正しかったかのように見えます。ログは古いテキスト、エビデンス、日付を保持します。L show ID で履歴を表示します。
• ポイントの分割: 元のクレームは最初の部分に保持します。マーカーは最初の行に残るためです。新しい部分には同じランのIDが割り当てられます。
• スクリプト外で行われた編集 も表面化します。テキストが変更されたチェック済みクレームは CHANGED として戻され、新しい判定が必要です。

自己チェック

同じモデルがレポートを書き、チェックします。これがこの手法の弱点であり、ツールはそれを隠すのではなく可視化します。

• エビデンス type:
  • outside: このチェックのために読まれた独立したソース;
  • derived: スクリプトの算術。計算はチェックするが、その入力はチェックしない;
  • notes: プロジェクト自身の資料。一貫性を示すが、真実ではない。
• Notesのみ。 notes のみでバックアップされた CONFIRMED は、どこでも CONFIRMED (notes only) と表示されます。その result は「ノートと一致する; 外部ソースは見つからなかった」となります。
• 最後に、 重要度3のポイントで、判定が notes または derived エビデンスのみに依存しているものをユーザーにリストします。これらはユーザー自身が一次情報源に対して検証する必要があります。

リファレンス

• 判定:
  • CONFIRMED: 記述どおりに裏付けられている。
  • CORRECTED: 間違っていた; レポートは現在正しいことを述べている。
  • EXPANDED: 正しい; レポートは現在より多くの情報（範囲、注意点、出典）を含んでいる。
  • CHALLENGED: 反論する信頼できるケースが存在する; レポートはその旨を述べている。
  • UNKNOWN: 未解決; レポートはどこで調べるかを示している。
• キュー順序:
  1. RE-CHECK（新しいレコードによってフラグが立てられたポイント）;
  2. CHANGED;
  3. 優先度（重要度×弱点、同順位はレポート順）による未解決クレーム。
• <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語以上を含む親アイテム。一般的なレポートでは、主張は箇条書きだけでなく、散文やテーブルにも含まれます。
• テンプレートはコードで強制され、1つの不良レコードがバッチ全体を拒否します。 最初の台帳では、ルールが会話のみに存在した後、best_case は28件の修正中0に低下し、wrong_if は57%に低下しました。
• CONFIRMED 以外の判定は、ポイントのテキストが変更されている必要があります（または elsewhere: IDs）。CORRECTED はレポートが現在正しいことを述べていることを意味するため、ツールはそれをチェックします。
• 追加されたすべての数値は check() で再導出されるか、QUOTED でソースとともに宣言されます。 これにより、最初の台帳のバッチ3のルール（「数値をどこかに書き込む前に計算する」）が機械的になります。
• すでに判定がある編集済みクレームは、同じバッチで記録またはフラグが立てられなければなりません。 これにより、判定がサイレントに古くなることを防ぎます。
• バッチごとに1つのスクリプトがチェック、適用、記録を一緒に実行します。 中途半端に適用されたバッチは発生しません。
• テールルールはユーザーに委ねられます。 その範囲とコストはユーザーの判断です。
• 停止ルールは最初のチェックのみをカウントし、 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 がないため、notesのみとして読み取られます。