feat: foto vira conversa (sub-projeto 3)

[lucasjosee]

Sub-projeto 3 de 7 da reformulação: a foto deixa de ser uma tela de resultado e vira a primeira mensagem de uma conversa.

⚠️ Empilhado. Base é feat/motor-de-conversa (#5), que empilha em feat/abandonar-web (#4). Ordem de merge: #4 → #5 → este.

Spec: CropAI-docs/especificacoes/2026-09-12-foto-vira-conversa-design.md
Plano: CropAI-docs/planos/2026-09-12-foto-vira-conversa.md
Registro de execução, com as 12 decisões tomadas e o custo de cada uma se estiver errada: CropAI-docs/historico/execucoes/2026-09-13-foto-vira-conversa-ledger.md

O que muda

O obturador roda a inferência em memória e mostra o veredito para confirmação. Nada é gravado até o produtor tocar em "Analisar" — 3 a 5 tentativas até um bom quadro é o normal em campo, e cada tentativa persistida custaria uma sessão no histórico, um PUT no S3 e uma chamada paga ao modelo. Confirmada a foto, nascem diagnóstico, sessão e primeira mensagem numa operação só, e a tela navega para a conversa.

Na conversa, o diagnóstico é renderizado como card dentro da bolha da foto — a partir do banco, sem depender de modelo de linguagem nenhum. É o que mantém RF01 e RF02 vivos quando o modelo local não está instalado e não há sinal. A segunda opinião do modelo de nuvem roda em paralelo e atualiza o card quando chega; os botões de feedback (RF06) passam a nomear as duas hipóteses quando há divergência. O aviso legal da Lei 7.802 passa a existir na tela de conversa, que até aqui não avisava nada.

app/camera.tsx: 1.995 → 510 linhas. A ponte provisória que o sub-projeto 2 deixou (diagnosticContext), o buildDiagnosticChatContext e o diagnosticDraftService inteiro deixam de existir — os problemas que eles resolviam não existem mais.

Nenhuma migração de banco. O schema do sub-projeto 2 já bastava.

Três defeitos que a execução encontrou

1. A câmera não funcionava em aparelho — e isso é anterior a este PR.
O código chamava nativeCameraRef.current.takePhoto(...), método que não existe na react-native-vision-camera@5.0.11 instalada. Passou pelo typecheck porque o arquivo declarava let NativeCamera: any e useRef<any>, e o require condicional (que existia só para o bundler de web) apagava a checagem daquele caminho. Mesma classe do bug loadModel/loadTensorflowModel registrado no sub-projeto 2. A reescrita corrige: import estático e tipado, captura por usePhotoOutput() + capturePhoto() + saveToTemporaryFileAsync().

2. A compensação não compensava.
chat_sessions.origin_diagnostic_local_id é FK para fila_diagnosticos sem ON DELETE, o banco roda com PRAGMA foreign_keys = ON, e cada execute é autocommit. Apagar o diagnóstico primeiro era recusado pelo SQLite, e o .catch mudo engolia a recusa — sobrava o órfão mais uma conversa vazia apontando para ele, que o JOIN do mapa exibiria como análise real. A limpeza agora vai de filho para pai: mensagens, sessão, diagnóstico.

3. "Um PUT por foto" só valia no caminho concorrente.
Se a resposta do motor falhasse depois de a segunda opinião já ter subido a imagem, a chave nunca chegava ao anexo da mensagem — só o onDone a grava ali. Na abertura seguinte o disparo automático subia a foto de novo: segundo PUT pago, com chave diferente da que o servidor já registrou. O upload passa a ler fila_diagnosticos.image_s3_key antes de mintar URL nova.

Verificação

Frontend	141 → 175 testes verdes, 21 arquivos
Backend	71 verdes, intocado pela branch
Typecheck	limpo nos dois pacotes
Migrações	nenhuma (db/sqlite.ts sem diff)
Código de web em camera.tsx	zero ocorrências

Cada uma das 11 tarefas passou por revisão independente própria; duas tiveram rodadas de correção com re-revisão escopada. A revisão da branch inteira saiu "com correções", e as correções foram aplicadas e re-revisadas.

O que este PR não prova

Nada aqui tocou um aparelho. Como o defeito nº 1 mostra, a captura nunca funcionou em dispositivo, então nenhum dos três sub-projetos foi homologado de fato. Quatro itens ficam para a homologação de campo:

1. Com o .gguf ausente e o aparelho offline, o card aparece completo — doença, severidade, sintomas, defensivo, dosagem, carência e aviso legal — e só a prosa falta. É a afirmação central do desenho.
2. Tocar em "Repetir" cinco vezes não deixa linha nenhuma em fila_diagnosticos nem em chat_sessions.
3. Fechar e reabrir a conversa mostra o mesmo card e não pede o feedback de novo.
4. O painel de debug sob __DEV__ leva a imagem mock até o card, com a segunda opinião em SKIPPED.

Decisões que valem sua revisão

• Trailer dos commits credita "Claude Sonnet 5" (quem escreveu o código), não Opus 5. Cada implementador seguia o reminder da própria sessão; forçar o contrário custaria uma correção por tarefa para creditar um modelo que não escreveu nada.
• A segunda opinião de uma foto capturada offline continua nascendo SKIPPED. Deixá-la pendente para rodar quando o sinal voltasse seria melhor para o produtor, mas o cliente só sincroniza linhas PENDING e o servidor protege o veredito por TERMINAL_CV_STATUSES — o veredito tardio nunca chegaria lá, e cliente e servidor divergiriam em silêncio. Fica para o sub-projeto 4, que constrói o caminho de re-sync.
• Armadilha latente não corrigida: cv.llmDoencaNome é lido dentro de enviar no FeedbackPanel mas não está nas dependências daquele useCallback. Não é bug vivo — onSubmitted é recriado a cada render e força o recompute —, mas acorda se alguém estabilizar aquele prop.

🤖 Generated with Claude Code

https://claude.ai/code/session_015dTz4Z51NvTgHWGrisq2oy