CIME

CIME is split into four layers that hand a request off in sequence — from the people using it, through the AI and the API, down to the database.

• Clients — two entry points: a Next.js / React dashboard for managers, and WhatsApp itself for drivers and mechanics in the field, so there’s no app to install.
• AI & Integrations — WhatsApp text and voice flow through a Node + Baileys bot on Fly.io, which uses OpenAI to turn natural language into structured commands.
• Backend · Fly.io — an Express + TypeScript API with JWT / CORS middleware, REST routes, and controllers / services that hold the business logic.
• Data · Supabase — Prisma gives type-safe access to a Supabase-managed PostgreSQL database, the single source of truth for fleet and maintenance data.

O CIME é dividido em quatro camadas que repassam a requisição em sequência — das pessoas que usam, passando pela IA e pela API, até o banco de dados.

• Clientes — dois pontos de entrada: um painel em Next.js / React para gestores e o próprio WhatsApp para motoristas e mecânicos em campo, sem app para instalar.
• IA & Integrações — texto e áudio do WhatsApp passam por um bot Node + Baileys na Fly.io, que usa a OpenAI para transformar linguagem natural em comandos estruturados.
• Backend · Fly.io — uma API Express + TypeScript com middleware de JWT / CORS, rotas REST e controllers / services que concentram a regra de negócio.
• Dados · Supabase — o Prisma dá acesso tipado a um PostgreSQL gerenciado pelo Supabase, a fonte única de verdade dos dados de frota e manutenção.

Every request flows through five layers before reaching the database. The language model understands the request, but every operation is executed by deterministic backend services.

• AI Reasoning — GPT-4 reads the text or voice message, classifies the intent, plans the steps, and emits structured calls through OpenAI function calling.
• AI Orchestration — a tool registry dispatches each call to the right tool, while conversation memory feeds earlier context back into the model.
• Available Tools — a typed surface for vehicles, maintenance, work orders, inspections, and reporting: the only actions the model is allowed to take.
• Domain Layer — domain services apply authorization, tenant isolation, and business rules, so every request is scoped to the user’s company.
• Persistence — Prisma writes to PostgreSQL with type-safe queries, the same store the dashboard reads from.

Toda requisição atravessa cinco camadas antes de chegar ao banco. O modelo de linguagem entende o pedido, mas cada operação é executada por serviços determinísticos do backend.

• Raciocínio da IA — o GPT-4 lê a mensagem de texto ou voz, classifica a intenção, planeja os passos e emite chamadas estruturadas via function calling da OpenAI.
• Orquestração da IA — um registro de ferramentas despacha cada chamada para a ferramenta certa, enquanto a memória da conversa devolve o contexto anterior ao modelo.
• Ferramentas disponíveis — uma superfície tipada para veículos, manutenção, ordens de serviço, inspeções e relatórios: as únicas ações que o modelo pode tomar.
• Camada de domínio — os serviços de domínio aplicam autorização, isolamento por tenant e regras de negócio, então toda requisição fica restrita à empresa do usuário.
• Persistência — o Prisma escreve no PostgreSQL com queries tipadas, o mesmo banco que o painel lê.

The diagrams above show the components, not the execution loop. Two forks decide what a message costs: known phrasings never reach the model at all, and the ones that do fork again on what the model asked for — a read stays inside a read-only transaction, a write goes through the REST API and Prisma.

Os diagramas acima mostram os componentes, não o laço de execução. Duas bifurcações definem quanto custa uma mensagem: frases já conhecidas nunca chegam ao modelo, e as que chegam se dividem de novo conforme o que o modelo pediu — uma leitura fica dentro de uma transação somente-leitura, uma escrita passa pela API REST e pelo Prisma.

The model decides what to ask for, never how it runs: both branches end in the same deterministic services the web dashboard uses, and the reply is written only after the result comes back.

O modelo decide o que pedir, nunca como aquilo roda: os dois caminhos terminam nos mesmos serviços determinísticos que o painel web usa, e a resposta só é escrita depois que o resultado volta.

The model never gets a database connection or arbitrary backend code. It can call exactly three typed functions — one that reports, one that reads, one that writes:

O modelo nunca recebe conexão com o banco nem código arbitrário do backend. Ele pode chamar exatamente três funções tipadas — uma que gera relatório, uma que lê e uma que escreve:

run_report({
  metric: "orders"
  agg: "count" | "list"
  time: { preset: "today" | "this_week" | "last_7d"
                 | "this_month" | "all" | "custom" }
  group_by: "status" | "plate" | "author" | "day" | "week"
  filters: { plate?, status_in?, type?, search? }
  limit: 1..500
})

run_sql({
  query: string   // a single SELECT, nothing else
})

create_order({
  plate: string
  title: string
})

Preferring run_report is the point: the model sends a semantic plan — metric, period, filters — and the backend composes the SQL, so the common case never has the model writing queries at all. Whichever it picks, the backend still validates the arguments, resolves the company from the authenticated phone number, injects the tenant filter, and executes.

Preferir o run_report é justamente o ponto: o modelo envia um plano semântico — métrica, período, filtros — e o backend monta o SQL, de modo que no caso comum o modelo nunca escreve query nenhuma. Escolha o que escolher, o backend ainda valida os argumentos, resolve a empresa a partir do telefone autenticado, injeta o filtro de tenant e executa.