Plano de Implementação

1. Achado principal: os docs estão defasados em relação ao código

PROJECT_STATUS_COMPLETE.md, MANIFEST.md e DEVELOPER_QUICK_REFERENCE.md — todos datados de 2026-08-13 — descrevem o projeto como "Fase 1.5 completa, pronto para Fase 2" (VM ainda por construir). Mas o código-fonte já contém a Fase 2 inteira (VM, bytecode, compilador) e duas camadas inteiras não documentadas nesses arquivos de status: uma AI Engine e um Research Engine autônomo de pesquisa matemática. Rodei a suíte de testes agora:

Isso importa porque qualquer plano futuro — inclusive um gerado por outra sessão de IA — que parta só da leitura desses três arquivos vai replanejar trabalho que já existe. A primeira coisa a fazer é atualizar os documentos de status, não o código.

2. Inventário do que já existe

3. Gaps concretos encontrados no código

Busquei por TODO, stub, placeholder e not implemented em src/. O que sobrou depois de filtrar comentários cosméticos:

Some-se a isso as duas limitações já autodocumentadas em PHASE_1_5_ANALYSIS.md e nunca fechadas: detecção de equivalência canônica (2^100 == 4^50 não é reconhecido) e crescimento linear de cadeias de operações acima de ~1000 passos.

4. Plano proposto (ordenado por dependência e alavancagem)

Fase A Fechar o gap de documentação — ~1–2h

• Atualizar PROJECT_STATUS_COMPLETE.md, MANIFEST.md e DEVELOPER_QUICK_REFERENCE.md para refletir que VM + AI Engine + Research Engine já estão implementados e com 30/30 testes.
• Transformar os critérios de sucesso da Fase 2 em PHASE_2_SPECIFICATION.md de checklist futuro para registro do que foi feito, e escrever critérios explícitos de "Fase 3".

Fase B Integração real de LLM — ~1–2 dias

• Implementar OpenAIClient / AnthropicClient em llm_client.cpp (cliente HTTP mínimo — libcurl no Linux/VM, WinHTTP no Windows local) lendo a chave de API das env vars já documentadas.
• Fazer ai_engine.cpp escolher o provider por FIR_LLM_PROVIDER em vez de instanciar StubLLMClient direto.
• Esta é a mudança de maior alavancagem: transforma o Research Engine de "gera conjecturas por templates determinísticos" em um assistente de pesquisa matemática de fato apoiado por um modelo real.

Fase C Fechar lacunas de corretude — ~2–4h cada

• Detecção de equivalência canônica (2^100 == 4^50) no canonicalizer.
• Achatamento de cadeias de operação acima de 1000 passos.
• Implementar MEXPAND_PARTIAL — necessário para qualquer CLI/UI que queira pré-visualizar valores estruturais grandes sem expansão total.

Fase D Completar o compilador

• Resolver os placeholders de LOG e MU_REFERENCE em vm/compiler.cpp para que programas DSL usando log() ou referências entre MUs compilem para bytecode real.

Fase E Higiene de infraestrutura

• O drive C: da máquina de desenvolvimento está em 0 bytes livres — já quebrou chamadas de shell durante esta análise. Vai travar builds/IDE em algum momento próximo se não for liberado espaço.
• Não há repositório git em e:\fractionengine. Para um projeto de ~90 arquivos em evolução ativa (builds novos todo dia), a ausência de controle de versão é o maior risco de perda de trabalho — mesmo padrão observado do lado da VM, onde o histórico do Caddyfile é mantido por cópias manuais (Caddyfile.bak-*) em vez de git.

5. Por que essa ordem

Fase A vem antes de tudo porque qualquer trabalho novo — feito por você ou por outra sessão de IA — que ignore o estado real do código vai perder tempo replanejando o que já existe. Fase B é a de maior valor novo (é o que realmente diferencia o Research Engine). Fases C e D são endurecimento de corretude sobre o que já está construído. Fase E não é urgente, mas é relógio correndo: disco cheio e ausência de git são os dois jeitos mais prováveis de perder trabalho por acidente.