claim-ledger

Libro de reclamaciones (Claim Ledger)

Cada punto del informe recibe un ID estable. Los reclamos se verifican en lotes, primero los más riesgosos: cada uno obtiene una declaración comprobable, qué lo haría incorrecto, su mejor caso y evidencia citada. Luego recibe un veredicto. Las correcciones reescriben el punto en su lugar mediante un script que respalda el informe y recalcula cada nuevo número. El registro de veredictos es de solo adición, por lo que la historia vive allí, no en el informe.

Construido a partir del primer libro en el que se usó (un informe de investigación de plan de negocios, octubre de 2026: 517 reclamos, 29 lotes). Encontró el error más grande de ese informe primero.

L abajo significa python3 -I ~/.claude/skills/claim-ledger/ledger.py -c <proyecto>/ledger.toml.

Configuración, una vez por informe

1. Config. Elige una carpeta de proyecto para la configuración y los datos. Ejecuta L init <informe.md>: escribe ledger.toml y lista los encabezados del informe.

2. Reglas. En la configuración:

   • Importancia: 3 = una decisión o prueba de viabilidad depende del punto, 2 = plan y dinero, 1 = el resto.
   • Tipos solo se verifican cuando se marcan: fuentes, notas de método, las decisiones del usuario, resúmenes.
   • Palabras de etiqueta, si el informe marca su evidencia de otra manera.

3. Regla de cola: pregúntale al usuario una vez; es su decisión. Dale al usuario los números del primer libro. Los lotes 1–9 (los más riesgosos) encontraron problemas en el 27% de las primeras verificaciones. Los lotes 10–29 fueron el 73% del trabajo y encontraron el 7%. Ofrece tres opciones:

   • verificar cada punto;
   • muestrear los puntos de baja prioridad con cifras publicadas a una tasa;
   • detenerse cuando la tasa de problemas de la primera verificación de un lote caiga por debajo de un umbral.

   Escribe la respuesta en [tail].

4. Marcado. L sync respalda el informe, luego agrega un <!-- cl:ID --> invisible al final de la primera línea de cada punto. Dile al usuario que el informe ahora lleva estos marcadores; L export clean.md escribe una copia sin ellos.

5. TRASPASO (HANDOFF). Dale al HANDOFF.md del proyecto una sección del libro: la ruta de configuración, los comandos, la regla de cola.

Listo cuando: sync informe los conteos de puntos y reclamos, L queue 10 muestra los puntos de los que dependen las decisiones, y el HANDOFF nombra la configuración.

Cada lote (alrededor de 20 puntos)

1. L template. Léelo al inicio de cada lote, para que las reglas estén frescas después de la compactación. El template del primer libro se erosionó a partir del lote 10.
2. L queue 20, luego L show ID....
3. Por punto, en orden: statement → wrong_if → best_case → búsqueda → evidence → veredicto → result.
   • Busca fuera primero. Usa la fuente primaria: el archivo, el conjunto de datos, la página del editor. Las notas del proyecto van al final y se escriben como notes.
   • Calcula cada número con un script en <data>/analysis/ antes de escribirlo en cualquier lugar.
   • Dependencias. Cuando un punto cambia, L find <frase> encuentra los puntos que dependen de él; lista sus IDs en flag.
4. Escribe el lote. Los registros van en <data>/edits/batchNN-records.json. Copia edit-template.py a <data>/edits/batchNN.py y completa:
   • E, las ediciones: cada punto reescrito en su lugar;
   • QUOTED, las cifras copiadas de una fuente;
   • check(), que recalcula cada otro número agregado.
5. Ejecútalo. python3 -I batchNN.py --check primero; corrige lo que rechace; luego ejecútalo sin --check.
   • Un lote que no edita nada igual se ejecuta a través del script con E = [].
   • El script es la única forma en que las ediciones llegan al informe.
6. Reporte. Reconstruye cualquier vista renderizada que tenga el proyecto (un mapa, por ejemplo). Pega L status en el HANDOFF y publica su primera línea al usuario.

Listo cuando: el script se ejecutó limpio, el registro creció con los registros del lote, y el HANDOFF lleva la nueva línea de estado y la cabeza de la cola.

Encadenar lotes

• Ejecuta uno tras otro. Una vez que el usuario diga adelante, ejecuta lote tras lote sin un aviso entre ellos, publicando la línea de estado después de cada uno.
• Detente en la regla de parada. Cuando queue imprima STOP RULE MET, informa las tasas y pregunta al usuario si continuar. queue --all continúa.
• Detente para las decisiones del usuario: dinero, contactar a alguien, decisiones que son suyas. Detente también para bloqueadores reales, y di cuáles.
• Cerca del límite de contexto: termina el lote en curso, actualiza el HANDOFF, y di que una sesión nueva continúa desde la cabeza de la cola.
• Auditoría. Ejecuta L audit cada 10 lotes y al final.
  • Una línea DRIFT significa que los veredictos tardíos son más endebles que los tempranos.
  • Antes de dar por terminado el libro, vuelve a verificar una muestra aleatoria de puntos CONFIRMED tardíos con el template completo.

Reescribir puntos

• Reescribe en el lugar. El punto dice lo correcto de forma clara, con su fuente, como si siempre hubiera sido correcto. El registro conserva el texto antiguo, la evidencia y la fecha; L show ID imprime el historial.
• Dividir un punto: conserva el reclamo original en la primera parte, porque el marcador permanece en la primera línea. Las nuevas piezas reciben IDs en la misma ejecución.
• Las ediciones hechas fuera del script aún salen a la superficie. Un reclamo verificado cuyo texto cambia vuelve como CHANGED y necesita un nuevo veredicto.

Autoverificación

El mismo modelo escribe el informe y lo verifica. Este es el punto débil del método, y la herramienta lo hace visible en lugar de ocultarlo.

• Tipo de evidencia type:
  • outside: una fuente independiente leída para esta verificación;
  • derived: la aritmética de un script, que verifica el cálculo pero no sus entradas;
  • notes: el material del propio proyecto, que muestra consistencia, no verdad.
• Solo notas. Un CONFIRMED respaldado solo por notes se muestra en todas partes como CONFIRMED (solo notas). Su result dice "coincide con las notas; no se encontró una fuente externa".
• Al final, lista para el usuario los puntos de importancia 3 cuyo veredicto se basa solo en notas o evidencia derivada. Esos son los que debe verificar contra una fuente primaria por sí mismo.

Referencia

• Veredictos:
  • CONFIRMED: respaldado tal como está escrito.
  • CORRECTED: estaba mal; el informe ahora dice lo correcto.
  • EXPANDED: correcto; el informe ahora contiene más (un rango, una advertencia, una fuente).
  • CHALLENGED: hay un caso creíble en contra; el informe lo dice.
  • UNKNOWN: no resuelto; el informe dice dónde averiguar.
• Orden de cola:
  1. RE-CHECK, puntos marcados por un registro más nuevo;
  2. CHANGED;
  3. reclamos abiertos por prioridad, que es importancia × debilidad, empates en orden del informe.
• Archivos en <data>:
  • points.json: el registro, incluyendo el texto original de cada punto;
  • verdicts.jsonl: el registro de solo adición; añade, nunca edites una línea;
  • edits/, analysis/, backups/ y view.md, la vista humana.
• Lo que record y el script de edición rechazan: L template imprime la lista completa. Todo el lote se rechaza y no se escribe nada.
• Autoprueba: python3 -I ~/.claude/skills/claim-ledger/selftest.py imprime 27 líneas PASS.

Decisiones de diseño

• Los marcadores de ID están al final de la primera línea de un punto. Un comentario al inicio de una línea abre un bloque HTML en CommonMark, por lo que el resto del Markdown de esa línea dejaría de renderizarse.
• Qué cuenta como punto: elementos de lista hoja, párrafos, filas de tabla, e items padres con 12 o más palabras propias. Los informes generales llevan reclamos en prosa y tablas, no solo en viñetas.
• El template se aplica en código, y un solo registro malo rechaza todo el lote. En el primer libro, best_case cayó a 0 de 28 correcciones, y wrong_if a 57%, una vez que las reglas vivieron solo en la conversación.
• Un veredicto distinto de CONFIRMED necesita que el texto del punto haya cambiado (o elsewhere: IDs). CORRECTED significa que el informe ahora dice lo correcto, por lo que la herramienta verifica que así sea.
• Cada número agregado se recalcula en check() o se declara en QUOTED con su fuente. Esto hace que la regla del lote 3 del primer libro ("calcula cada número antes de escribirlo") sea mecánica.
• Los reclamos editados que ya tienen un veredicto deben registrarse o marcarse en el mismo lote, para que ningún veredicto quede obsoleto en silencio.
• Un script por lote ejecuta check, apply y record juntos. No puede ocurrir un lote medio aplicado.
• La regla de cola se delega. Su alcance y costo son decisión del usuario.
• La regla de parada cuenta solo las primeras verificaciones, con CORRECTED y CHALLENGED como problemas. En el primer libro, 42 de los 66 problemas tempranos provinieron de verificaciones repetidas, lo que infló la tasa temprana.
• El muestreo es determinista (un hash de la semilla y el ID), por lo que la muestra permanece igual entre ejecuciones y a medida que se agregan puntos. La cola también imprime los problemas estimados restantes, con un límite superior del 95%.
• Las citas de evidencia están limitadas a 14 palabras, para mantenerse por debajo de 15. El límite se establece mediante max_quote_words.
• La configuración es TOML, porque permite comentarios y Python la lee de forma nativa.
• La auditoría se verifica contra el primer libro. Reproducir sus 546 registros reproduce la auditoría del 13 de octubre: 24 de 89 primeras verificaciones fueron problemas en los lotes 1–9, y 28 de 393 en los lotes 10–29. Marca la deriva: wrong_if 99% → 55%, best_case en problemas 80% → 0%, evidencia por registro 1.71 → 1.20. Los registros antiguos no tienen tipo de evidencia, por lo que se leen como solo notas.