claim-ledger

Ledger de verificação

Cada ponto do relatório recebe um ID estável. As reivindicações são verificadas em lotes, os mais arriscados primeiro: cada uma recebe uma declaração testável, o que a tornaria errada, seu melhor caso, e evidências citadas. Em seguida, recebe um veredito. As correções reescrevem o ponto no local através de um script que faz backup do relatório e recalcula cada novo número. O registro de veredito é somente de acréscimo, então o histórico vive lá, não no relatório.

Construído a partir do primeiro ledger em que foi usado (um relatório de pesquisa de plano de negócios, outubro de 2026: 517 reivindicações, 29 lotes). Ele encontrou o maior erro desse relatório primeiro.

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

Configuração, uma vez por relatório

1. Config. Escolha uma pasta de projeto para a configuração e os dados. Execute L init <relatório.md>: ele cria ledger.toml e lista os cabeçalhos do relatório.

2. Regras. Na configuração:

   • Importância: 3 = uma decisão ou teste de prosseguir/parar depende do ponto, 2 = plano e dinheiro, 1 = o resto.
   • Tipos verificados apenas quando sinalizados: fontes, notas de método, as próprias decisões do usuário, resumos.
   • Palavras de marcação, se o relatório marcar suas evidências de outra forma.

3. Regra de cauda: pergunte ao usuário uma vez; é decisão dele. Forneça a ele os números do primeiro ledger. Os lotes 1–9 (os mais arriscados) encontraram problemas em 27% das primeiras verificações. Os lotes 10–29 foram 73% do trabalho e encontraram 7%. Ofereça três opções:

   • verificar cada ponto;
   • amostrar os pontos de figura publicada de baixa prioridade a uma taxa;
   • parar quando a taxa de problema da primeira verificação de um lote cair abaixo de um limite.

   Escreva a resposta em [tail].

4. Marcar. L sync faz backup do relatório e adiciona um invisível <!-- cl:ID --> ao final da primeira linha de cada ponto. Informe ao usuário que o relatório agora carrega esses marcadores; L export clean.md escreve uma cópia sem eles.

5. HANDOFF. Dê ao HANDOFF.md do projeto uma seção do ledger: o caminho da configuração, os comandos, a regra de cauda.

Concluído quando: sync relata as contagens de pontos e reivindicações, L queue 10 mostra os pontos dos quais as decisões dependem, e o HANDOFF nomeia a configuração.

Cada lote (cerca de 20 pontos)

1. L template. Leia-o no início de cada lote, para que as regras estejam frescas após a compactação. O template do primeiro ledger se desgastou a partir do lote 10.
2. L queue 20, depois L show ID....
3. Por ponto, em ordem: statement → wrong_if → best_case → pesquisa → evidence → veredito → result.
   • Pesquise primeiro fora. Use a fonte primária: o arquivo, o conjunto de dados, a página do próprio editor. As notas do projeto vêm por último e são digitadas como notes.
   • Calcule cada número com um script em <data>/analysis/ antes de escrevê-lo em qualquer lugar.
   • Dependentes. Quando um ponto muda, L find <frase> encontra os pontos que dependem dele; liste seus IDs em flag.
4. Escreva o lote. Os registros vão para <data>/edits/batchNN-records.json. Copie edit-template.py para <data>/edits/batchNN.py e preencha:
   • E, as edições: cada ponto reescrito no local;
   • QUOTED, as figuras copiadas de uma fonte;
   • check(), que recalcula cada outro número adicionado.
5. Execute-o. python3 -I batchNN.py --check primeiro; corrija o que ele rejeitar; depois execute-o sem --check.
   • Um lote que edita nada ainda passa pelo script com E = [].
   • O script é a única maneira de as edições chegarem ao relatório.
6. Relate. Reconstrua qualquer visualização renderizada que o projeto tenha (um mapa, por exemplo). Cole L status no HANDOFF e poste sua primeira linha para o usuário.

Concluído quando: o script rodou limpo, o log cresceu com os registros do lote, e o HANDOFF carrega a nova linha de status e o cabeçalho da fila.

Encadeando lotes

• Execute consecutivamente. Assim que o usuário dispara, execute lote após lote sem um prompt entre eles, postando a linha de status após cada um.
• Pare na regra de parada. Quando queue imprimir STOP RULE MET, relate as taxas e pergunte ao usuário se deve continuar. queue --all continua.
• Pare para as chamadas do usuário: dinheiro, contatar alguém, decisões que são deles. Pare também para bloqueadores reais, e diga quais.
• Próximo do limite de contexto: termine o lote em andamento, atualize o HANDOFF e diga que uma nova sessão continua a partir do cabeçalho da fila.
• Auditoria. Execute L audit a cada 10 lotes e no final.
  • Uma linha DRIFT significa que os vereditos tardios são mais finos que os iniciais.
  • Antes de declarar o ledger concluído, verifique novamente uma amostra aleatória de pontos CONFIRMED tardios com o template completo.

Reescrevendo pontos

• Reescreva no local. O ponto diz a coisa certa de forma clara, com sua fonte, como se sempre estivesse correto. O log mantém o texto antigo, a evidência e a data; L show ID imprime o histórico.
• Dividindo um ponto: mantenha a reivindicação original na primeira peça, porque o marcador permanece na primeira linha. As novas peças recebem IDs na mesma execução.
• Edições feitas fora do script ainda surgem. Uma reivindicação verificada cujo texto muda retorna como CHANGED e precisa de um novo veredito.

Auto-verificação

O mesmo modelo escreve o relatório e o verifica. Este é o ponto fraco do método, e a ferramenta o torna visível em vez de escondê-lo.

• type de evidência:
  • outside: uma fonte independente lida para esta verificação;
  • derived: a aritmética de um script, que verifica a matemática, mas não suas entradas;
  • notes: o material do próprio projeto, que mostra consistência, não verdade.
• Apenas notas. Um CONFIRMED apoiado apenas por notes aparece em todos os lugares como CONFIRMED (apenas notas). Seu result diz "corresponde às notas; nenhuma fonte externa encontrada".
• No final, liste para o usuário os pontos de importância 3 cujo veredito depende apenas de notas ou evidências derivadas. Esses são os que devem ser verificados contra uma fonte primária por ele mesmo.

Referência

• Vereditos:
  • CONFIRMED: corroborado como escrito.
  • CORRECTED: estava errado; o relatório agora diz a coisa certa.
  • EXPANDED: correto; o relatório agora carrega mais (um intervalo, uma ressalva, uma fonte).
  • CHALLENGED: um caso crível contra ele permanece; o relatório diz isso.
  • UNKNOWN: não resolvido; o relatório diz onde descobrir.
• Ordem da fila:
  1. RE-CHECK, pontos sinalizados por um registro mais novo;
  2. CHANGED;
  3. reivindicações abertas por prioridade, que é importância × fraqueza, empates na ordem do relatório.
• Arquivos em <data>:
  • points.json: o registro, incluindo o texto original de cada ponto;
  • verdicts.jsonl: o log somente de acréscimo; anexe, nunca edite uma linha;
  • edits/, analysis/, backups/ e view.md, a visão humana.
• O que record e o script de edição rejeitam: L template imprime a lista completa. Todo o lote é rejeitado e nada é escrito.
• Auto-teste: python3 -I ~/.claude/skills/claim-ledger/selftest.py imprime 27 linhas PASS.

Decisões de design

• Os marcadores de ID ficam no final da primeira linha de um ponto. Um comentário no início de uma linha abre um bloco HTML bruto em CommonMark, então o resto do Markdown dessa linha pararia de renderizar.
• O que conta como ponto: itens de lista folha, parágrafos, linhas de tabela e itens pai com 12 ou mais palavras próprias. Relatórios gerais carregam reivindicações em prosa e tabelas, não apenas em marcadores.
• O template é imposto no código, e um registro ruim rejeita todo o lote. O best_case do primeiro ledger caiu para 0 de 28 correções, e wrong_if para 57%, quando as regras viviam apenas na conversa.
• Um veredito diferente de CONFIRMED precisa que o texto do ponto tenha mudado (ou elsewhere: IDs). CORRECTED significa que o relatório agora diz a coisa certa, então a ferramenta verifica que sim.
• Cada número adicionado é recalculado em check() ou declarado em QUOTED com sua fonte. Isso torna mecânica a regra do lote 3 do primeiro ledger ("calcule cada número antes de escrevê-lo").
• Reivindicações editadas que já têm um veredito devem ser registradas ou sinalizadas no mesmo lote, para que nenhum veredito fique silenciosamente obsoleto.
• Um script por lote executa check, apply e record juntos. Um lote meio aplicado não pode acontecer.
• A regra de cauda é enviada. Seu escopo e custo são decisão do usuário.
• A regra de parada conta apenas as primeiras verificações, com CORRECTED e CHALLENGED como problemas. No primeiro ledger, 42 dos 66 problemas iniciais vieram de re-verificações, que inflaram a taxa inicial.
• A amostragem é determinística (um hash da semente e do ID), então a amostra permanece a mesma entre execuções e conforme os pontos são adicionados. A fila também imprime os problemas estimados restantes, com um limite superior de 95%.
• As citações de evidência são limitadas a 14 palavras, para ficar abaixo de 15. O limite é definido por max_quote_words.
• A configuração é TOML, porque permite comentários e Python a lê nativamente.
• A auditoria é verificada contra o primeiro ledger. Reproduzir seus 546 registros reproduz a auditoria de 13 de outubro: 24 de 89 primeiras verificações eram problemas nos lotes 1–9, e 28 de 393 nos lotes 10–29. Ele sinaliza o desvio: wrong_if 99% → 55%, best_case em problemas 80% → 0%, evidência por registro 1,71 → 1,20. Logs antigos não têm type de evidência, então são lidos como apenas notas.