Motor de conversa e persistência (sub-projeto 2 da reformulação)

[lucasjosee]

Segunda branch do sub-projeto. Empilha sobre o PR #4 (abandonar o target web) — mergear o #4 primeiro.

Entrega o núcleo da reformulação: um único motor de conversa com duas implementações, de forma que nenhuma tela saiba qual está ativo, e conversas que persistem no SQLite em vez de morrerem ao fechar o app.

O desenho

tela  →  engineRouter.respond()
            ├─ FIELD ................ LocalEngine  (SLM, janela de 10)
            ├─ ONLINE / DEGRADED .... CloudEngine  (LLM multimodal, janela de 20)
            └─ falhou antes do 1º token? → local assume em silêncio

EngineRouter é o único módulo do app que conhece os dois motores. A tela grava o source da mensagem a partir de EngineDoneMeta.kind — o motor que efetivamente respondeu, inclusive depois de um fallback.

O fallback por requisição passa a existir. A documentação do projeto o descrevia como o mecanismo mais importante para a experiência do produtor (10s sem token e a SLM assume), mas ele nunca esteve no código — o serviço antigo só disparava timeout e parava.

O que muda

Tabelas chat_sessions e chat_messages (migração v7)	conversas sobrevivem ao fechamento do app; sessões antigas de fila_slm_logs são migradas
lib/engine/	ConversationEngine + LocalEngine + CloudEngine + EngineRouter
lib/chatRepository.ts	única porta para as tabelas de conversa — nenhuma tela executa SQL
lib/catalogContext.ts	um construtor de contexto, por doenca_id, idêntico para os dois motores
app/chat/[sessionId].tsx	a conversa; sem if (isField)
/chat/stream	recebe catalog_context pronto; o servidor deixa de consultar o banco

Três dívidas fechadas de brinde

Contexto por nome virou contexto por id. O servidor buscava a doença pelo nome_comum vindo do cliente e, ao não encontrar, respondia sem embasamento nenhum, em silêncio. Agora o contexto é construído por doenca_id no cliente e enviado pronto — os dois motores recebem grounding idêntico.

As duas stacks HTTP viraram uma. O chat lia o token direto do SecureStore e não renovava em 401. O CloudEngine usa o mesmo mutex de refreshAccessToken do axios — dois refreshes concorrentes apresentariam o mesmo token e o servidor revogaria todas as sessões do usuário.

A bula entrou no contexto. O construtor antigo ignorava modo_de_acao e epoca_aplicacao, que já estavam no aparelho. Agora entram, dentro de um orçamento verificado por teste (≤ 2.000 caracteres, contra o n_ctx: 2048 da SLM).

Bugs encontrados pelas revisões

Cada tarefa teve implementador e revisor independentes. Seis precisaram de rodada de correção, e vários achados eram defeitos do plano, transcritos fielmente:

• Migração v7 abortava com interactions_json válido mas não-array ("{}", "null") — o aparelho ficava na v6, sem as tabelas de conversa, permanentemente.
• Corrida no CloudEngine: um abort() durante o refresh de 401 abria uma conexão nova para um fluxo já cancelado, sem nunca reportar ABORTED.
• Orçamento de contexto errado por 70%: 3 defensivos × 300 caracteres davam ~2.600, não os ~1.500 estimados. Campos truncados em 200 e o teto virou propriedade asserida por teste.
• Teste que custava dinheiro: um teste de rota alcançava o LLM real a cada npm test local. Trocado por verificação do schema — cobertura maior, sem rede.
• Mensagem que mentia: ao falhar a gravação, a tela dizia que a resposta sumiria "ao sair da tela", mas ela sumia na hora. Agora fica visível, rotulada "não salva".

Verificação

	Antes	Depois
Testes frontend	54	141
Testes backend	65	71
Typecheck	limpo	limpo

Critérios de aceite da spec §8 conferidos por varredura: nenhuma tela contém if (isField); os 8 símbolos do §7 não existem mais; mensagem enviada offline fica PENDING; a mesma chamada respond() cai em motor diferente conforme o modo.

Nota de processo

A re-revisão escopada da última onda de correção não foi feita por um revisor independente — o subagente bateu no limite de sessão. Verifiquei os quatro itens eu mesmo (renomeação sem chamadores órfãos, tela disparando só para foto, teste do mutex provando liberação-e-nova-tentativa, suítes e typecheck). O diff dessa onda tem 14 KB e é o commit af92e63; vale um olhar seu.

Fora de escopo, por desenho

app/camera.tsx não foi reescrito — é o sub-projeto 3. Por isso nada ainda cria uma mensagem com foto, e o disparo automático não tem quem o acione no fluxo atual. fila_slm_logs permanece até o sub-projeto 4; a migração copiou as linhas para as tabelas novas e deixou as originais, então o sub-projeto 4 precisa evitar subida dupla.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Pmgii3S5sfMZghFqQXhbkH