Sistemas que já projetei e construí

A POC é um pipeline em Python com etapas desacopladas, cada uma lendo e escrevendo JSON. O pedido gera um prompt estruturado para um LLM, que devolve apenas a especificação — o modelo não faz nenhum cálculo. O dimensionamento é determinístico: regras de capacidade definem quantas linhas de produção e quantos equipamentos de cada tipo a demanda exige. A fábrica é modelada como uma matriz 3D discreta de células; cada equipamento ocupa um bloco de células conforme suas dimensões e declara entradas e saídas tipadas em faces específicas, como peças de Lego — mesmo tipo em faces opostas significa conexão compatível.

O posicionamento é resolvido com o CP-SAT do Google OR-Tools: variáveis de célula e de rotação (0°, 90°, 180°, 270°) para cada equipamento, restrições de não sobreposição, de limites do terreno e de conectividade obrigatória de cada porta a uma porta compatível de outro equipamento; quando não existe arranjo possível, o solver prova a inviabilidade. Nesta versão o objetivo é só viabilidade — minimizar área, distâncias e custo fica para a próxima etapa. A interface web em Three.js permite revisar e ajustar o layout com encaixe magnético e validação de portas, e exportadores geram um script Ruby para a API do SketchUp e um arquivo STL.

O CogniFox separa motor e interface: todas as entidades são documentos JSON com contrato em Pydantic (validação estrutural) e regras de negócio em validadores próprios (validação semântica) — SQL restrito a leitura, paleta fechada de nós e detecção de ciclos por DFS, o mesmo algoritmo reaproveitado em pipelines, nos sinais entre widgets e na dependência entre pipelines. Pipelines são grafos executados pelo Ibis sobre DuckDB, com propagação estática de schema nó a nó, que alimenta o autocomplete do editor visual. Todo dataset é materializado, a versão anterior vira backup e o status de saúde (OK, BACKUP, FALHA) se propaga pela cadeia; um orquestrador infere a ordem de execução pela dependência de dados e o APScheduler dispara por cron.

A camada web é Flask, com projetos e arquivos no MinIO e fontes em MySQL, PostgreSQL, SQLite, CSV ou GeoJSON. Os dashboards usam Gridstack, ECharts e Leaflet, com sinais entre widgets que recalculam só o que foi afetado, e podem ser embutidos em outro sistema por um Web Component com Shadow DOM e tokens JWT escopados e revogáveis. O assistente de IA (LiteLLM, independente de provedor) gera entidades a partir do schema real da fonte; a resposta passa pelos mesmos validadores do editor visual e, se falhar, o erro exato volta ao modelo em até três tentativas — e o resultado entra sempre como rascunho, sujeito à mesma aprovação humana. Código customizado só entra como Script catalogado e aprovado, e pipelines podem ser cobertos por casos de teste em JSON, sem escrever Python.

O Patas é uma aplicação Django sobre PostgreSQL com PostGIS, para consultas geográficas como distância entre avistamentos, e pgvector, para busca por similaridade entre descrições. Fotos ficam em armazenamento compatível com S3 (MinIO, via django-storages); o processamento pesado roda em segundo plano com Celery e Redis, e o celery-beat agenda as varreduras periódicas de correspondências. Login com Google (django-allauth), bot do Telegram com webhook para voluntários que relatam pelo celular, papéis hierárquicos de Nível 0 a 5, trilha de auditoria, pontuação de voluntários e implantação com Docker Compose e integração contínua no GitHub Actions.

O pipeline de IA usa um modelo de visão via LiteLLM — compatível com modelos locais servidos pelo Ollama — para avaliar se a foto é adequada e gerar uma descrição voltada à identificação. Cor e porte são extraídos com vocabulário controlado e um parser de dependência do spaCy em português, que distingue, por exemplo, a cor da pelagem da cor dos olhos. A descrição vira um embedding, e o matching combina similaridade de cosseno, proximidade geográfica, proximidade no tempo e sobreposição de características (Jaccard) num score ponderado, cujo detalhamento é guardado para calibrar os pesos com dados reais. Pessoas validam cada etapa: o Nível 3 revisa as descrições, o Nível 4 confirma o match e verifica a identidade por telefone antes de liberar o contato, e o mapa público mostra só uma área aproximada.

O GeoProcess é um framework distribuído baseado no conceito de perguntas e respostas, dividido em três módulos desacoplados: o Portal (Django, com front-end em Bootstrap/AdminLTE, Plotly e OpenLayers), o Gateway (FastAPI sobre Uvicorn) e os Consumers, serviços Python que efetivamente respondem às perguntas. Portal e Gateway conversam por API web; Gateway e Consumers trocam mensagens JSON via RabbitMQ (AMQP), em fluxos independentes e assíncronos. Cada consumer se registra no Gateway anunciando seu projeto, suas perguntas e seus parâmetros — novas análises entram no sistema sem alterar o Portal, e várias instâncias do mesmo consumer podem rodar em paralelo, o que garante escalabilidade horizontal.

O Gateway concentra segurança e rastreabilidade: o usuário se autentica por Single Sign-On (OIDC), o Portal repassa o token JWT e o Gateway decide quais projetos e perguntas cada perfil enxerga, registrando toda requisição e resposta no PostgreSQL — daí vem o histórico. Uma biblioteca comum oferece a classe base dos consumers e um contrato de resposta que abstrai mapas, gráficos, tabelas e mensagens; o desenvolvedor escreve só a consulta e a montagem do resultado, enquanto distribuição, formatação e controle de acesso ficam com a plataforma. Alertas são perguntas agendadas que só notificam quando a resposta não é vazia, e um Visual Builder permite prototipar a tela de resposta com o cliente (técnica do Mágico de Oz) e gerar o esqueleto do consumer em Python. Dados espaciais ficam em PostGIS e GeoServer, e a operação é monitorada com Prometheus e Grafana.

O Atena é uma aplicação Django com MySQL/MariaDB, servida por Gunicorn atrás do Nginx e autenticada pelo CAS da universidade. O modelo de dados é orientado a objetos de aprendizagem: textos, vídeos, slides, notebooks, mapas de imagem, questões e problemas herdam de um mesmo tipo base, e cada trilha é um grafo em que cada nó aponta para o próximo conforme o resultado da resposta — correta, parcial, incorreta ou o caminho escolhido numa questão. As trilhas podem ser desenhadas num editor visual e são validadas antes da publicação. Os problemas aceitam Python, Java, C e C++ e rodam em três modos: no navegador com Pyodide, em blocos com Blockly ou no servidor, numa sandbox confinada por AppArmor, com pool de execução controlado por locks e limite de tempo.

As atividades avaliativas comparam a saída com os casos de teste — com algoritmos de similaridade como Levenshtein e Smith-Waterman — e analisam a árvore sintática do código para exigir funções e parâmetros; provas podem ser restritas por IP e liberadas por código TOTP. O Atena Tutor é um serviço separado (Flask, SQLAlchemy/Alembic, PostgreSQL, Docker), com login federado por JWT assinado. Um LLM gera soluções de referência que só são aceitas depois de passar nos casos de teste, com nova tentativa a partir do erro detalhado; o fluxograma é derivado do AST, sem IA, e o LLM apenas rotula blocos já delimitados pelo parser — nunca reescreve o código. A checagem de compreensão compara a resposta do aluno por embeddings locais, as dicas são liberadas por tentativa e por tempo, e os painéis analíticos são integrados ao CogniFox.

Os dispositivos da casa — lâmpadas, tomadas e aparelhos — são acionados por microcontroladores ESP8266 que se comunicam por MQTT com um broker central, um protocolo publish/subscribe leve, adequado a redes domésticas. Todas as interfaces publicam comandos no mesmo padrão de tópicos, então novas formas de interação entram sem mexer nos dispositivos. A primeira versão é uma aplicação web em Java (JSP), com páginas por cômodo pensadas para leitores de tela; a versão mais recente foi reescrita em Python com Django.

A programação pelo usuário final usa o Blockly, com blocos próprios de gatilhos (horário, sensores, estado dos aparelhos) e ações, traduzidos em regras que a central executa. A luva combina um ESP8266 com o acelerômetro e giroscópio MPU-6050 para reconhecer gestos da mão; o controle pela câmera usa TensorFlow.js com transfer learning sobre uma rede pré-treinada, treinada no próprio navegador com poucos exemplos do usuário; e os comandos de voz passam pelo CoGrOO, analisador de português, que extrai a ação e o dispositivo da frase antes de virar uma mensagem MQTT. Para pessoas com limitações motoras severas, um headset de EEG Emotiv EPOC+ (14 canais, via Bluetooth) captura comandos mentais treinados por usuário, que viram ações da casa pelo mesmo barramento MQTT; a usabilidade foi avaliada com 30 participantes, com protocolo de pensar em voz alta e análise de vídeo.

Cada coleira tem um microcontrolador ESP8266 com o acelerômetro e giroscópio MPU-6050, que mede ângulos e acelerações em três eixos; um filtro de Kalman combina as duas leituras para estimar a inclinação com menos ruído. As coleiras trocam mensagens pelo ESP-NOW, protocolo ponto a ponto que dispensa roteador Wi-Fi, e um nó coletor repassa os dados por MQTT ou pela serial para uma estação com Raspberry Pi. Também foram testadas a comunicação por Bluetooth e a coleta direto no celular, com um aplicativo em Flutter usado para rotular o comportamento observado em campo.

Na classificação, cada amostra é uma janela com 100 leituras de cada sinal; os atributos são normalizados e reduzidos com PCA e LDA, e foram comparados regressão logística, SVM linear e com kernel RBF, árvore de decisão, Random Forest e KNN, com validação cruzada e busca de hiperparâmetros em pipelines do scikit-learn. Nos testes com cães, os melhores modelos chegaram a cerca de 77% de acerto no conjunto de teste, numa base ainda pequena. Um painel em Streamlit lê os dados em tempo real e ajusta curvas por regressão polinomial para visualizar cada movimento.

Em cada veículo, um celular Android fornece a posição de GPS a um nó com microcontrolador ESP8266, que se comunica com os demais pelo ESP-NOW, protocolo ponto a ponto de baixa latência que dispensa roteador. Os nós trocam periodicamente posição, velocidade e um índice de confiança sobre cada vizinho, e retransmitem mensagens com controle de número de saltos e de reenvios, com regras para disseminar alertas de acidente sem inundar a rede. O firmware também implementa um modo que segue o padrão europeu ETSI para mensagens veiculares cooperativas, usado como referência de comparação.

Uma aplicação desktop em Java recebe os dados dos nós por socket, mostra os veículos no mapa, gera relatórios e pode emular nós, e se integra ao simulador de tráfego SUMO para testar o protocolo com fluxos de veículos em rotas e velocidades de 20 a 60 km/h. Nos testes de campo, cada nó registra em JSON as posições próprias e as recebidas dos vizinhos; scripts em Python comparam o que cada carro sabia sobre os outros com a posição real, calculam erro e confiança por par de nós e exportam GeoJSON e KML para visualização. Há ainda aplicativos Android e Flutter para acompanhar os nós no celular.