claim-ledger

索赔分类账（Claim Ledger）

报告中的每个点都有一个稳定ID。索赔按批次检查，风险最高的优先：每个点都有一个可测试的陈述、什么会使它错误、最佳情况以及引用的证据。然后给出一个裁决。修正通过一个脚本原地重写该点，该脚本会备份报告并重新推导每个新数字。裁决日志是仅追加的，因此历史记录保存在那里，而非报告中。

根据其首次使用的分类账（一份商业计划研究报告，2026年10月：517个索赔，29个批次）构建而成。它首先发现了那份报告中最大的错误。

L 下面表示 python3 -I ~/.claude/skills/claim-ledger/ledger.py -c <project>/ledger.toml。

每份报告设置一次

1. 配置。 为配置和数据选择一个项目文件夹。运行 L init <report.md>：它会写入 ledger.toml 并列出报告的标题。

2. 规则。 在配置中：

   • 重要性： 3 = 决策或开/关测试依赖于该点，2 = 计划和资金，1 = 其他。
   • 仅在标记时才检查的类型： 来源、方法说明、用户自己的决策、摘要。
   • 标签词，如果报告以其他方式标记其证据。

3. 尾部规则：询问用户一次；这是他们的决定。 给他们第一个分类账的数字。批次1-9（风险最高）在27%的首次检查中发现了问题。批次10-29占工作量的73%，发现了7%的问题。提供三个选项：

   • 检查每个点；
   • 以一定比率对低优先级的公开数字点进行抽样；
   • 当某个批次的首次检查问题率低于某个阈值时停止。

   将答案写入 [tail]。

4. 标记。 L sync 备份报告，然后在每个点第一行的末尾添加一个不可见的 <!-- cl:ID -->。告诉用户报告现在带有这些标记；L export clean.md 会写入一个没有这些标记的副本。

5. 交接（HANDOFF）。 给项目的 HANDOFF.md 添加一个分类账部分：配置路径、命令、尾部规则。

完成条件： 同步报告了点和索赔的数量，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> 查找依赖于它的点；在 flag 中列出它们的ID。
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带有新的状态行和队列头部。

链接批次

• 连续运行。 一旦用户说“开始”，就在它们之间没有提示的情况下一个接一个地运行批次，每次后发布状态行。
• 在停止规则处停止。 当 queue 打印 STOP RULE MET 时，报告比率并询问用户是否继续。queue --all 继续。
• 为用户的决定停止： 金钱、联系任何人、他们的决策。对于真正的障碍也要停止，并说明原因。
• 接近上下文限制时： 完成当前批次，更新HANDOFF，并说明新会话从队列头部继续。
• 审计。 每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：未解决；报告说明了在哪里可以找到答案。
• 队列顺序：
  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个或更多单词的父项目。通用报告在散文和表格中携带索赔，而不仅仅是在项目符号中。
• 模板在代码中强制执行，一条错误记录会拒绝整个批次。 一旦规则仅存在于对话中，第一个分类账的 best_case 在28个修正中降至0，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，因此它们被读作仅限笔记。