claim-ledger

Anspruchs-Ledger

Jeder Punkt des Berichts erhält eine stabile ID. Behauptungen werden in Stapeln überprüft, zuerst die risikoreichsten: jede erhält eine testbare Aussage, was sie falsch machen würde, ihren besten Fall und zitierte Belege. Dann erhält sie ein Urteil. Korrekturen schreiben den Punkt direkt um durch ein Skript, das den Bericht sichert und jede neue Zahl neu ableitet. Das Urteilsprotokoll ist rein anfügend, sodass die Historie dort lebt, nicht im Bericht.

Erstellt auf Basis des ersten Ledgers, für das es verwendet wurde (ein Geschäftsplan-Forschungsbericht, Oktober 2026: 517 Behauptungen, 29 Stapel). Es fand den größten Fehler dieses Berichts zuerst.

L steht im Folgenden für python3 -I ~/.claude/skills/claim-ledger/ledger.py -c <projekt>/ledger.toml.

Einrichtung, einmal pro Bericht

1. Konfiguration. Wählen Sie einen Projektordner für Konfiguration und Daten. Führen Sie L init <bericht.md> aus: Es erstellt ledger.toml und listet die Überschriften des Berichts.

2. Regeln. In der Konfiguration:

   • Wichtigkeit: 3 = eine Entscheidung oder ein Go/No-Go-Test hängt von dem Punkt ab, 2 = Planung und Geld, 1 = der Rest.
   • Arten werden nur geprüft, wenn sie markiert sind: Quellen, Methodenhinweise, die eigenen Entscheidungen des Benutzers, Zusammenfassungen.
   • Schlagwörter, falls der Bericht seine Belege auf andere Weise kennzeichnet.

3. Abbruchregel: den Benutzer einmal fragen; es ist seine Entscheidung. Geben Sie ihm die Zahlen des ersten Ledgers. Die Stapel 1–9 (die risikoreichsten) fanden in 27% der ersten Prüfungen Probleme. Die Stapel 10–29 machten 73% der Arbeit aus und fanden 7%. Bieten Sie drei Optionen an:

   • jeden Punkt prüfen;
   • die niedrig priorisierten Punkte mit veröffentlichten Zahlen mit einer Rate stichprobenartig prüfen;
   • anhalten, wenn die Problemrate der ersten Prüfungen eines Stapels unter einen Schwellenwert fällt.

   Schreiben Sie die Antwort in [tail].

4. Markieren. L sync sichert den Bericht und fügt dann am Ende der ersten Zeile jedes Punktes einen unsichtbaren <!-- cl:ID --> hinzu. Teilen Sie dem Benutzer mit, dass der Bericht nun diese Markierungen trägt; L export clean.md erstellt eine Kopie ohne sie.

5. ÜBERGABE. Geben Sie der HANDOFF.md des Projekts einen Ledger-Abschnitt: den Konfigurationspfad, die Befehle, die Abbruchregel.

Erledigt, wenn: sync die Punkt- und Behauptungsanzahlen meldet, L queue 10 die Punkte anzeigt, von denen Entscheidungen abhängen, und die HANDOFF die Konfiguration benennt.

Jeder Stapel (ca. 20 Punkte)

1. L template. Lesen Sie es zu Beginn jedes Stapels, damit die Regeln nach der Kompaktierung frisch sind. Das Template des ersten Ledgers erodierte ab Stapel 10.
2. L queue 20, dann L show ID....
3. Pro Punkt, in Reihenfolge: statement → wrong_if → best_case → Suche → evidence → Urteil → result.
   • Zuerst extern suchen. Verwenden Sie die Primärquelle: die Einreichung, den Datensatz, die eigene Seite des Herausgebers. Die Notizen des Projekts kommen zuletzt und werden als notes typisiert.
   • Berechnen Sie jede Zahl mit einem Skript in <data>/analysis/, bevor Sie sie irgendwo schreiben.
   • Abhängigkeiten. Wenn sich ein Punkt ändert, findet L find <phrase> die Punkte, die darauf beruhen; listen Sie ihre IDs in flag.
4. Den Stapel schreiben. Die Datensätze werden in <data>/edits/batchNN-records.json gespeichert. Kopieren Sie edit-template.py nach <data>/edits/batchNN.py und füllen Sie aus:
   • E, die Bearbeitungen: jeder Punkt direkt umgeschrieben;
   • QUOTED, die aus einer Quelle kopierten Zahlen;
   • check(), die jede andere hinzugefügte Zahl neu ableitet.
5. Ausführen. python3 -I batchNN.py --check zuerst; beheben Sie, was abgelehnt wird; dann führen Sie es ohne --check aus.
   • Ein Stapel, der nichts bearbeitet, wird dennoch mit E = [] durch das Skript ausgeführt.
   • Das Skript ist der einzige Weg, wie Bearbeitungen den Bericht erreichen.
6. Bericht. Erstellen Sie jede gerenderte Ansicht des Projekts neu (z. B. eine Karte). Fügen Sie L status in die HANDOFF ein und posten Sie die erste Zeile an den Benutzer.

Erledigt, wenn: das Skript sauber lief, das Protokoll um die Datensätze des Stapels gewachsen ist und die HANDOFF die neue Statuszeile und den Stapelanfang enthält.

Stapel verketten

• Hintereinander ausführen. Sobald der Benutzer grünes Licht gibt, Stapel für Stapel ohne Aufforderung dazwischen ausführen, nach jedem Stapel die Statuszeile posten.
• An der Stopp-Regel anhalten. Wenn queue STOP RULE MET ausgibt, die Raten melden und den Benutzer fragen, ob es weitergehen soll. queue --all fährt fort.
• Für Benutzerentscheidungen anhalten: Geld, Kontaktaufnahme mit jemandem, Entscheidungen, die dem Benutzer obliegen. Auch für echte Blockaden anhalten und diese nennen.
• In der Nähe des Kontextlimits: den aktuellen Stapel beenden, die HANDOFF aktualisieren und mitteilen, dass eine neue Sitzung vom Stapelanfang aus fortgesetzt wird.
• Audit. Führen Sie L audit alle 10 Stapel und am Ende aus.
  • Eine DRIFT-Zeile bedeutet, dass die späteren Urteile dünner sind als die frühen.
  • Bevor Sie das Ledger als abgeschlossen bezeichnen, überprüfen Sie eine Zufallsstichprobe späterer CONFIRMED-Punkte mit dem vollständigen Template.

Punkte umschreiben

• Direkt umschreiben. Der Punkt sagt die richtige Sache klar mit seiner Quelle, als ob er schon immer richtig gewesen wäre. Das Protokoll behält den alten Text, die Belege und das Datum; L show ID gibt die Historie aus.
• Einen Punkt aufteilen: Die ursprüngliche Behauptung im ersten Teil behalten, da die Markierung in der ersten Zeile bleibt. Die neuen Teile erhalten IDs im selben Durchlauf.
• Außerhalb des Skripts vorgenommene Bearbeitungen tauchen dennoch auf. Ein geprüfter Punkt, dessen Text sich ändert, wird als CHANGED zurückgemeldet und benötigt ein neues Urteil.

Selbstprüfung

Dasselbe Modell schreibt den Bericht und prüft ihn. Dies ist die Schwachstelle der Methode, und das Werkzeug macht sie sichtbar, anstatt sie zu verstecken.

• evidence Typ:
  • outside: eine unabhängige Quelle, die für diese Prüfung gelesen wurde;
  • derived: Arithmetik eines Skripts, die die Mathematik, aber nicht ihre Eingaben prüft;
  • notes: eigenes Material des Projekts, das Konsistenz, aber nicht Wahrheit zeigt.
• Nur Notizen. Ein CONFIRMED, das nur auf notes gestützt wird, erscheint überall als CONFIRMED (notes only). Sein result sagt „stimmt mit den Notizen überein; keine externe Quelle gefunden“.
• Am Ende dem Benutzer die Punkte mit Wichtigkeit 3 auflisten, deren Urteil auf Notizen oder abgeleiteten Belegen allein beruht. Diese sind gegen eine Primärquelle selbst zu verifizieren.

Referenz

• Urteile:
  • CONFIRMED: wie geschrieben belegt.
  • CORRECTED: war falsch; der Bericht sagt jetzt das Richtige.
  • EXPANDED: richtig; der Bericht enthält jetzt mehr (einen Bereich, einen Vorbehalt, eine Quelle).
  • CHALLENGED: es steht ein glaubwürdiger Gegenargument; der Bericht sagt dies.
  • UNKNOWN: nicht geklärt; der Bericht sagt, wo man es erfahren kann.
• Warteschlangenreihenfolge:
  1. RE-CHECK, Punkte, die von einem neueren Datensatz markiert wurden;
  2. CHANGED;
  3. offene Behauptungen nach Priorität, die Wichtigkeit × Schwäche ist; Gleichstände in Berichtsreihenfolge.
• Dateien in <data>:
  • points.json: das Register, einschließlich des Originaltexts jedes Punktes;
  • verdicts.jsonl: das reine Anhänge-Protokoll; anhängen, niemals eine Zeile bearbeiten;
  • edits/, analysis/, backups/ und view.md, die menschliche Ansicht.
• Was record und das Bearbeitungsskript ablehnen: L template gibt die vollständige Liste aus. Der gesamte Stapel wird abgelehnt und nichts geschrieben.
• Selbsttest: python3 -I ~/.claude/skills/claim-ledger/selftest.py gibt 27 PASS-Zeilen aus.

Designentscheidungen

• ID-Markierungen stehen am Ende der ersten Zeile eines Punktes. Ein Kommentar am Zeilenanfang öffnet in CommonMark einen rohen HTML-Block, sodass der Rest der Markdown dieser Zeile nicht mehr gerendert würde.
• Was als Punkt zählt: Listenblattelemente, Absätze, Tabellenzeilen und übergeordnete Elemente mit 12 oder mehr eigenen Wörtern. Allgemeine Berichte enthalten Behauptungen in Fließtext und Tabellen, nicht nur in Aufzählungen.
• Das Template wird im Code durchgesetzt, und ein schlechter Datensatz lehnt den gesamten Stapel ab. Im ersten Ledger fiel best_case auf 0 von 28 Korrekturen und wrong_if auf 57%, sobald die Regeln nur noch im Gespräch lebten.
• Ein anderes Urteil als CONFIRMED erfordert, dass sich der Text des Punktes geändert hat (oder elsewhere: IDs). CORRECTED bedeutet, dass der Bericht jetzt das Richtige sagt, also prüft das Werkzeug, dass dies der Fall ist.
• Jede hinzugefügte Zahl wird in check() neu abgeleitet oder in QUOTED mit ihrer Quelle deklariert. Dies macht die Stapel-3-Regel des ersten Ledgers („jede Zahl berechnen, bevor sie irgendwo geschrieben wird“) mechanisch.
• Bearbeitete Behauptungen, die bereits ein Urteil haben, müssen im selben Stapel aufgezeichnet oder markiert werden, damit kein Urteil stillschweigend veraltet.
• Ein Skript pro Stapel führt Prüfung, Anwendung und Aufzeichnung gemeinsam aus. Ein halb angewandter Stapel kann nicht auftreten.
• Die Abbruchregel wird ausgelagert. Ihr Umfang und ihre Kosten sind die Entscheidung des Benutzers.
• Die Stopp-Regel zählt nur erste Prüfungen, wobei CORRECTED und CHALLENGED als Probleme gewertet werden. Im ersten Ledger kamen 42 der 66 frühen Probleme von Nachprüfungen, was die frühe Rate überhöhte.
• Die Stichprobenziehung ist deterministisch (ein Hash von Seed und ID), sodass die Stichprobe über Läufe und beim Hinzufügen von Punkten gleich bleibt. Die Warteschlange gibt auch die geschätzten verbleibenden Probleme aus, mit einer 95%-Obergrenze.
• Belegzitate sind auf 14 Wörter begrenzt, um unter 15 zu bleiben. Das Limit wird durch max_quote_words gesetzt.
• Die Konfiguration ist TOML, weil sie Kommentare erlaubt und Python sie nativ liest.
• Das Audit wird gegen das erste Ledger geprüft. Die Wiedergabe seiner 546 Datensätze reproduziert das Audit vom 13. Oktober: 24 von 89 ersten Prüfungen waren Probleme in den Stapeln 1–9 und 28 von 393 in den Stapeln 10–29. Es zeigt die Drift: wrong_if 99% → 55%, best_case bei Problemen 80% → 0%, Belege pro Datensatz 1,71 → 1,20. Alte Protokolle haben keinen evidence Typ, daher werden sie als nur Notizen gelesen.