synthetics/phd-lab/harry-projects/<project-id>/

O ID do projeto é um identificador opaco e seguro para filesystem, derivado do título, timestamp e um sufixo aleatório. Comandos da UI precisam passar esse ID exato em vez de reconstruir caminhos a
partir de um título. Isso evita um modo comum de falha em sistemas de agentes de longa duração: dois prompts parecidos se fundindo silenciosamente no mesmo workspace ou estado antigo do navegador
lançando o projeto errado.

Uma pasta de projeto mantém o registro operacional:

state.json
ledger.jsonl
sources.json
claims.jsonl
claims-index.json
evidence-needed.jsonl
logs/harry.log
notebook/thinking.jsonl
learning/self-improvement.json
paper/main.tex
paper/main.pdf
paper/unsupported-claims.md
papers/fundamental/
papers/text/

Esse layout importa porque Harry é reiniciável. O runner não depende de histórico escondido de chat como fonte da verdade. Estado, evidências, logs de execução, experimentos gerados, rascunhos de
manuscrito e decisões sobre claims são arquivos simples dentro do diretório do projeto.

## A Máquina De Estágios

Harry passa por um conjunto finito de fases:

literature_search
open_question_map
hypothesis
experiment_design
code_experiment
run_experiment
analyze_result
claim_audit
draft_paper
render_paper

As fases não são uma cascata rígida. O modelo pode propor a próxima fase, e o controlador pode sobrescrevê-la quando pressão de orçamento, claims sem suporte ou loops sem progresso tornam a proposta
insegura. Por exemplo, uma claim sem suporte no artigo pode forçar um claim_audit, enquanto estágios repetidos sem progresso durável podem empurrar a execução para fora da fase atual.

O contrato de orçamento é deliberadamente grande: projetos Harry rodam com mínimo de 1000 estágios e máximo de 5000 estágios. Isso parece extremo até você tratar o alvo como um artigo, não como uma
resposta. O orçamento também evita outro modo de falha: declarar vitória depois de alguns parágrafos plausíveis. Espera-se que Harry gaste estágios em deltas duráveis, como novas fontes, experimentos,
resultados ou claims sustentadas.

## Evidência Antes De Achados

O mecanismo de segurança mais importante de Harry é a escassez de claims. Apenas fases específicas podem registrar claims de pesquisa: analyze_result, claim_audit, draft_paper e render_paper. Mesmo
assim, um estágio só pode registrar um pequeno número de claims candidatas ou claims de artigo.

Material sem suporte é rebaixado em vez de promovido. Observações prematuras, hipóteses vagas, passagens ausentes, suporte fraco ou claims vindas de fases que não deveriam produzir claims vão para:

evidence-needed.jsonl

Claims sem suporte no artigo são colocadas em quarentena em:

paper/unsupported-claims.md

Apenas registros paper_claim sustentados podem entrar na seção de achados do manuscrito. Essa é a disciplina central do sistema: o artigo não pode virar um depósito para toda frase interessante que o
modelo gerou.

## Literatura E PDFs

Harry pode buscar fontes científicas por Semantic Scholar e recuperação em estilo arXiv. O ranking de fontes prefere artigos recentes quando a pergunta envolve claims de fronteira, desenho
experimental ou atualização de manuscrito, ainda permitindo que trabalhos canônicos mais antigos fundamentem a base.

Quando um artigo é fundamental, canônico ou indispensável, Harry pode pedir o PDF ao usuário. Esse pedido não bloqueia o loop. A pesquisa não pausa enquanto espera o anexo. Se um PDF for anexado
depois pela aba Harry, o projeto o registra em papers/fundamental/, extrai texto em melhor esforço para papers/text/, atualiza o registro local e o conecta de volta em sources.json.

A identidade do anexo é baseada em título, não em nome de arquivo. Esse detalhe é mais importante do que parece. PDFs acadêmicos muitas vezes chegam com nomes como 2572459.pdf, então Harry tenta
inferir o título real do artigo a partir de metadados ou texto extraído e cruzar isso com pedidos abertos de artigos fundamentais.

## Experimentos Como Artefatos

Harry pode gerar e rodar experimentos locais em Python durante as fases code_experiment e run_experiment. O controlador verifica o código gerado antes da execução e escreve arquivos de experimento,
logs e saídas de volta no workspace do projeto.

Isso mantém claims computacionais inspecionáveis. Um modelo dizendo "o experimento mostra X" é evidência fraca. Uma pasta de projeto contendo o código gerado, o log de execução, o artefato de
resultado, a linha correspondente no ledger de estágio e a trilha de auditoria da claim é muito melhor. Ainda precisa de revisão humana, mas dá ao revisor algo concreto para auditar.

## Geração Do Manuscrito

O pipeline de manuscrito é LaTeX-first. Harry escreve:

paper/main.tex

e tenta renderizar:

paper/main.pdf

O renderer é endurecido para pdflatex: o texto gerado é empurrado para LaTeX seguro em ASCII, tokens matemáticos contextuais são normalizados, e claims sem suporte são excluídas dos achados. A
estrutura do rascunho mira um artigo quantitativo real: pergunta de pesquisa, claims controladas por evidência, fontes lidas, experimentos e resultados, limitações e conclusões.

Renderizar não é apenas cosmético. Um PDF bem-sucedido é um checkpoint operacional útil: o artigo pode ser aberto, lido e criticado como documento, não como saída dispersa de agente.

Screenshot 2026-05-12 at 16

## Plano De Controle Visível

A UI do Harry faz parte do design, não é só um wrapper. A aba Lab expõe criação de projeto, seleção exata de projeto, controles de orçamento de estágio, anexo de PDF, progresso, contagem de fases,
renderização do artigo, notebook de pesquisa, log de heartbeat em runtime e PDF final.

Ela também tem controles de ciclo de vida:

- pause deixa o estágio atual terminar e pula o próximo.
- continue retoma do mesmo limite de estágio concluído depois de uma pausa ou erro de rota.
- recover + continue limpa estado stopped, paused ou error e lança um novo lote limitado para o projeto selecionado.
- stop Harry encerra metadados ou processos de execução ativos e escreve um marcador local de parada no projeto.

Esses controles existem porque agentes de longa duração falham de maneiras mundanas: estado antigo do navegador, timeouts de rota, rascunhos duplicados de projeto, execução do projeto errado,
incompatibilidades de identidade de PDF, loops repetidos sem progresso e falhas de renderização em LaTeX. O plano de controle de Harry é uma resposta a essas falhas.

## Política Aprendida, Mas Sem Autoridade Oculta

Harry mantém uma política visível de autoaperfeiçoamento em:

learning/self-improvement.json

A política pontua fases e transições com um sinal simples de recompensa: claims sustentadas, experimentos bem-sucedidos, fontes recentes, renders com falha, claims sem suporte e estágios desperdiçados
afetam a escolha futura de fase. Isso toma emprestado o sabor de Reflexion, Self-Refine, memória de política em estilo Voyager e otimização guiada por métricas, mas a parte importante é operacional: a
memória de política é visível e local ao projeto.

O modelo pode sugerir um movimento, mas o controlador Python possui os invariantes. Orçamentos de estágio, nomes de fase, gates de claims, tratamento de duplicatas, comportamento do registro de PDFs e
limites de renderização são determinísticos o bastante para serem inspecionados e reparados.

## Por Que Isso É Diferente De Um Chatbot

Um chatbot otimiza para uma resposta útil agora. Harry otimiza para uma trilha de pesquisa auditável ao longo de muitos estágios. Essa diferença aparece na arquitetura:

- Histórico de chat não é o banco de dados; arquivos de projeto são.
- Claims não são confiadas por padrão; elas são sustentadas, colocadas em quarentena ou rebaixadas.
- Fontes não são apenas citadas em prosa; elas são armazenadas e ranqueadas.
- Experimentos não são descritos abstratamente; código e logs viram artefatos.
- Manuscritos não são resumos; eles são saídas LaTeX renderizadas com filtros de claims.
- Recuperação não é adivinhação manual; pause, continue, recover e stop são controles escopados por projeto.

O tradeoff é complexidade. Harry precisa de mais escrituração do que um assistente normal. Ele ainda pode falhar, especialmente quando a busca externa é fraca, os experimentos gerados não são
significativos ou o renderer do manuscrito encontra casos extremos. Mas as falhas aparecem principalmente como arquivos, contadores, logs e lacunas, em vez de desaparecerem dentro de uma conversa
opaca.

## A Aposta De Engenharia

A aposta de engenharia de Harry é que pesquisa autônoma precisa de menos agência teatral e mais prestação de contas durável. O agente deve poder explorar, mas não deve poder esquecer por onde passou.
Deve propor claims, mas não contrabandeá-las para o artigo final sem suporte. Deve rodar por muitos estágios, mas cada estágio deve gastar orçamento em algo que sobreviva à inspeção.

Isso torna Harry menos parecido com um assistente geral e mais parecido com um loop operacional de pesquisa: um controlador, um filesystem de projeto, recuperação de fontes, execução de experimentos,
gates de evidência, memória de aprendizado visível e um compilador de manuscrito. O nome é amigável, mas o contrato é estrito: se uma claim não pode ser rastreada até evidência, ela não pertence ao
artigo.

Ainda está em beta.

Pretendo torná-lo open-source assim que possível.