Resumo
O ThermoClaw foi construído com FastAPI + React antes do core Python estar maduro. Isso gerou acoplamento prematuro, dificuldade de reutilização e ilusão de progresso (~85% declarado vs ~15% real). A lição: em vibe coding médico, o valor está no core de processamento, não na interface.
Insight
A armadilha do “framework first” é especialmente perigosa em projetos de diagnóstico computacional. O core — funções Python puras que transformam dados brutos (matriz térmica 160x120) em variáveis clínicas — é onde mora o IP. API, dashboard e agentes são adapters descartáveis.
O status report declarava “9 extratores fisiológicos validados” quando na realidade apenas a Fase 0 (aquisição via exiftool + OpenCV) existia no código. Os módulos processing/, physiology/, ai/, storage/ listados como “existentes” nunca foram escritos. Confundir planejamento com implementação é erro que se amplifica em projetos solo.
A renomeação ThermoClaw → TermoVital também reflete a lição: nomes que remetem a tech/AI (Claw, agentes) prejudicam credibilidade em contexto médico. “TermoVital” conecta termodinâmica com sinais vitais, é português, e funciona em clínica e SaaS.
Evidência
Experiência direta (N=1): 3 commits no repo ThermoClaw, código de aquisição funcional, resto vazio.
Translação
Nenhum item de translação identificado.
Questões Abertas
- Qual a melhor estrutura de monorepo para core + adapters em Python médico?
- Como separar “spec maduro” de “código existente” em documentação de projetos solo?
Notas Relacionadas
- IRT como proxy de BAT: viável vs PET/CT mas limitado por sinal fraco em câmeras portáteis
- Radiomics termográfica atinge AUC 0.91 para síndrome metabólica em 5 min