ledger-de-réclamations

Ledger de réclamations

Chaque point du rapport obtient un identifiant stable. Les réclamations sont vérifiées par lots, du plus risqué au moins risqué : chacune reçoit un énoncé vérifiable, ce qui la rendrait fausse, son meilleur cas, et des preuves citées. Ensuite, elle reçoit un verdict. Les corrections réécrivent le point sur place via un script qui sauvegarde le rapport et recalcule chaque nouveau nombre. Le journal des verdicts est en ajout seul, donc l'historique y réside, pas dans le rapport.

Construit à partir du premier ledger sur lequel il a été utilisé (un rapport de recherche de plan d'affaires, octobre 2026 : 517 réclamations, 29 lots). Il a trouvé la plus grosse erreur de ce rapport en premier.

L ci-dessous signifie python3 -I ~/.claude/skills/claim-ledger/ledger.py -c <projet>/ledger.toml.

Configuration, une fois par rapport

1. Config. Choisissez un dossier de projet pour la configuration et les données. Exécutez L init <rapport.md> : il écrit ledger.toml et liste les titres du rapport.

2. Règles. Dans la configuration :

   • Importance : 3 = une décision ou un test de go/no-go repose sur le point, 2 = plan et argent, 1 = le reste.
   • Types vérifiés uniquement quand signalés : sources, notes de méthode, les propres décisions de l'utilisateur, résumés.
   • Mots-clés, si le rapport marque ses preuves d'une autre manière.

3. Règle de queue : demander à l'utilisateur une fois ; c'est son choix. Donnez-leur les chiffres du premier ledger. Les lots 1 à 9 (les plus risqués) ont trouvé des problèmes dans 27 % des premières vérifications. Les lots 10 à 29 représentaient 73 % du travail et ont trouvé 7 %. Proposez trois options :

   • vérifier chaque point ;
   • échantillonner les points de faible priorité avec des chiffres publiés à un certain taux ;
   • arrêter quand le taux de problèmes lors de la première vérification d'un lot tombe en dessous d'un seuil.

   Écrivez la réponse dans [tail].

4. Marquer. L sync sauvegarde le rapport, puis ajoute un <!-- cl:ID --> invisible à la fin de la première ligne de chaque point. Dites à l'utilisateur que le rapport porte maintenant ces marqueurs ; L export clean.md en écrit une copie sans eux.

5. TRANSMISSION. Donnez au HANDOFF.md du projet une section ledger : le chemin de configuration, les commandes, la règle de queue.

Terminé quand : sync rapporte les nombres de points et de réclamations, L queue 10 montre les points sur lesquels les décisions reposent, et le HANDOFF nomme la configuration.

Chaque lot (environ 20 points)

1. L template. Lisez-le au début de chaque lot, pour que les règles soient fraîches après compaction. Le template du premier ledger s'est dégradé à partir du lot 10.
2. L queue 20, puis L show ID....
3. Par point, dans l'ordre : statement → wrong_if → best_case → recherche → evidence → verdict → result.
   • Cherchez d'abord en dehors. Utilisez la source primaire : le dossier, le jeu de données, la page de l'éditeur. Les notes du projet viennent en dernier et sont typées notes.
   • Calculez chaque nombre avec un script dans <data>/analysis/ avant de l'écrire où que ce soit.
   • Dépendants. Quand un point change, L find <phrase> trouve les points qui en dépendent ; listez leurs identifiants dans flag.
4. Écrivez le lot. Les enregistrements vont dans <data>/edits/batchNN-records.json. Copiez edit-template.py dans <data>/edits/batchNN.py et remplissez :
   • E, les modifications : chaque point réécrit sur place ;
   • QUOTED, les chiffres copiés d'une source ;
   • check(), qui recalcule chaque autre nombre ajouté.
5. Exécutez-le. python3 -I batchNN.py --check d'abord ; corrigez ce qu'il rejette ; puis exécutez-le sans --check.
   • Un lot qui ne modifie rien passe quand même par le script avec E = [].
   • Le script est le seul moyen par lequel les modifications atteignent le rapport.
6. Rapport. Reconstruisez toute vue rendue que le projet possède (une carte, par exemple). Collez L status dans le HANDOFF et postez sa première ligne à l'utilisateur.

Terminé quand : le script s'est exécuté proprement, le journal a grandi des enregistrements du lot, et le HANDOFF porte la nouvelle ligne de statut et la tête de file.

Enchaînement des lots

• Exécutez l'un après l'autre. Une fois que l'utilisateur dit go, exécutez lot après lot sans invite entre eux, en postant la ligne de statut après chacun.
• Arrêtez-vous à la règle d'arrêt. Quand queue affiche RÈGLE D'ARRÊT ATTEINTE, rapportez les taux et demandez à l'utilisateur s'il faut continuer. queue --all continue.
• Arrêtez-vous pour les décisions de l'utilisateur : argent, contact avec quiconque, décisions qui leur appartiennent. Arrêtez-vous aussi pour les vrais blocages, et dites lesquels.
• Proche de la limite de contexte : terminez le lot en cours, mettez à jour le HANDOFF, et dites qu'une nouvelle session continue depuis la tête de file.
• Audit. Exécutez L audit tous les 10 lots et à la fin.
  • Une ligne DÉRIVE signifie que les verdicts tardifs sont plus superficiels que les premiers.
  • Avant de déclarer le ledger terminé, revérifiez un échantillon aléatoire des derniers points CONFIRMÉS avec le template complet.

Réécriture des points

• Réécrivez sur place. Le point dit la bonne chose clairement, avec sa source, comme s'il avait toujours été correct. Le journal conserve l'ancien texte, les preuves et la date ; L show ID affiche l'historique.
• Diviser un point : gardez la réclamation originale dans la première partie, car le marqueur reste sur la première ligne. Les nouvelles pièces reçoivent des identifiants dans la même exécution.
• Les modifications faites en dehors du script remontent quand même. Une réclamation vérifiée dont le texte change revient comme CHANGÉE et nécessite un nouveau verdict.

Auto-vérification

Le même modèle écrit le rapport et le vérifie. C'est le point faible de la méthode, et l'outil le rend visible au lieu de le cacher.

• type de preuve :
  • outside : une source indépendante lue pour cette vérification ;
  • derived : l'arithmétique d'un script, qui vérifie le calcul mais pas ses entrées ;
  • notes : le propre matériel du projet, qui montre la cohérence, pas la vérité.
• Notes seulement. Un CONFIRMÉ soutenu uniquement par notes apparaît partout comme CONFIRMÉ (notes seulement). Son result dit « correspond aux notes ; aucune source externe trouvée ».
• À la fin, listez pour l'utilisateur les points d'importance 3 dont le verdict repose uniquement sur des notes ou des preuves dérivées. Ce sont ceux à vérifier eux-mêmes par rapport à une source primaire.

Référence

• Verdicts :
  • CONFIRMÉ : soutenu tel qu'écrit.
  • CORRIGÉ : était faux ; le rapport dit maintenant la bonne chose.
  • DÉVELOPPÉ : juste ; le rapport porte maintenant plus (une fourchette, une réserve, une source).
  • CONTESTÉ : un argument crédible contre lui existe ; le rapport le dit.
  • INCONNU : non résolu ; le rapport dit où trouver l'information.
• Ordre de file :
  1. RE-VÉRIFICATION, points signalés par un enregistrement plus récent ;
  2. CHANGÉ ;
  3. réclamations ouvertes par priorité, qui est importance × faiblesse, en cas d'égalité dans l'ordre du rapport.
• Fichiers dans <data> :
  • points.json : le registre, incluant le texte original de chaque point ;
  • verdicts.jsonl : le journal en ajout seul ; ajoutez, ne modifiez jamais une ligne ;
  • edits/, analysis/, backups/ et view.md, la vue humaine.
• Ce que record et le script de modification rejettent : L template affiche la liste complète. Tout le lot est rejeté et rien n'est écrit.
• Auto-test : python3 -I ~/.claude/skills/claim-ledger/selftest.py affiche 27 lignes PASS.

Décisions de conception

• Les marqueurs d'identifiant se trouvent à la fin de la première ligne d'un point. Un commentaire au début d'une ligne ouvre un bloc HTML brut en CommonMark, donc le reste du Markdown de cette ligne cesserait de s'afficher.
• Ce qui compte comme un point : éléments de liste feuille, paragraphes, lignes de tableau, et éléments parents avec 12 mots ou plus à eux seuls. Les rapports généraux portent des réclamations en prose et en tableaux, pas seulement en puces.
• Le template est appliqué en code, et un mauvais enregistrement rejette tout le lot. Le best_case du premier ledger est tombé à 0 sur 28 corrections, et wrong_if à 57 %, une fois que les règles ne vivaient que dans la conversation.
• Un verdict autre que CONFIRMÉ nécessite que le texte du point ait changé (ou elsewhere: IDs). CORRIGÉ signifie que le rapport dit maintenant la bonne chose, donc l'outil vérifie qu'il le fait.
• Chaque nombre ajouté est recalculé dans check() ou déclaré dans QUOTED avec sa source. Cela rend la règle du lot 3 du premier ledger (« calculer chaque nombre avant de l'écrire ») mécanique.
• Les réclamations modifiées qui ont déjà un verdict doivent être enregistrées ou signalées dans le même lot, pour qu'aucun verdict ne devienne silencieusement obsolète.
• Un script par lot exécute la vérification, l'application et l'enregistrement ensemble. Un lot à moitié appliqué ne peut pas arriver.
• La règle de queue est renvoyée. Sa portée et son coût sont du ressort de l'utilisateur.
• La règle d'arrêt compte uniquement les premières vérifications, avec CORRIGÉ et CONTESTÉ comme problèmes. Dans le premier ledger, 42 des 66 problèmes précoces provenaient de re-vérifications, ce qui a gonflé le taux précoce.
• L'échantillonnage est déterministe (un hash du seed et de l'identifiant), donc l'échantillon reste le même entre les exécutions et à mesure que des points sont ajoutés. La file imprime aussi le nombre estimé de problèmes restants, avec une borne supérieure à 95 %.
• Les citations de preuves sont limitées à 14 mots, pour rester en dessous de 15. La limite est définie par max_quote_words.
• La configuration est en TOML, car elle permet les commentaires et Python la lit nativement.
• L'audit est vérifié par rapport au premier ledger. Rejouer ses 546 enregistrements reproduit l'audit du 13 octobre : 24 des 89 premières vérifications étaient des problèmes dans les lots 1 à 9, et 28 des 393 dans les lots 10 à 29. Il signale la dérive : wrong_if 99 % → 55 %, best_case sur les problèmes 80 % → 0 %, preuves par enregistrement 1,71 → 1,20. Les anciens journaux n'ont pas de type de preuve, donc ils sont lus comme notes seulement.