Gabriel Salles

Context

Contexto

Rio de Janeiro's city hotel union (HotéisRIO/SindHotéisRIO) and the state hotel association (ABIH-RJ) needed one official digital channel to deliver benefits, communications and support to member hotels under both brands. The first generations (Nov 2025 to Jun 2026) started as Google AI Studio prototypes; the goal became a single maintainable codebase with server-side authorization and an automated release path.

O sindicato da hotelaria carioca (HotéisRIO/SindHotéisRIO) e a associação estadual da indústria de hotéis (ABIH-RJ) precisavam de um canal digital oficial para entregar benefícios, comunicados e apoio aos hotéis associados das duas marcas. As primeiras gerações (nov/2025 a jun/2026) nasceram como protótipos no Google AI Studio; o objetivo passou a ser uma base de código única e sustentável, com autorização no servidor e publicação automatizada.

What he built

O que construiu

• React + TypeScript (Vite) web app serving both brands on 8 production hostnames, deployed to Cloudflare Workers by GitHub Actions on every push to main (migrated from Vercel).
• PHP 8.3 REST API as the only gateway to MySQL: verifies Firebase ID tokens and enforces access with Open Policy Agent policies. Firebase is limited to sign-in and Firestore is set to deny-all (documented architecture decision); an experimental Node runtime was removed so a single implementation carries the authorization controls.
• In-app AI assistant streamed over SSE through the API (no model keys in the browser), with a PII filter and a daily per-profile message quota; reused as a Chrome (Manifest V3) side-panel extension with its own sign-in.
• Push notifications (OneSignal), transactional e-mail endpoints and webhooks, a benefits catalog synced to other systems by a scheduled workflow, and an iOS/Android project via Capacitor (not published in the stores).
• Release gate npm run verify (typecheck, lint, tests, npm audit at high level, build), 30 Node test-runner files covering LGPD and security invariants, and a Playwright smoke test of 24 navigation flows on desktop and mobile.

• Web app em React + TypeScript (Vite) que atende as duas marcas em 8 hostnames de produção, com deploy em Cloudflare Workers pelo GitHub Actions a cada push na main (migrado da Vercel).
• API REST em PHP 8.3 como única porta de acesso ao MySQL: valida o ID token do Firebase e aplica as regras de acesso com políticas em Open Policy Agent. O Firebase ficou restrito ao login e o Firestore em modo deny-all (decisão de arquitetura documentada); um runtime experimental em Node foi removido para que uma só implementação carregue os controles de autorização.
• Assistente de IA dentro do app, com streaming por SSE via API (nenhuma chave de modelo no navegador), filtro de dados pessoais e cota diária de mensagens por perfil; reaproveitado como extensão do Chrome (Manifest V3) em painel lateral, com login próprio.
• Notificações push (OneSignal), endpoints e webhooks de e-mail transacional, catálogo de benefícios sincronizado com outros sistemas por workflow agendado e projeto iOS/Android via Capacitor (não publicado nas lojas).
• Gate de publicação npm run verify (typecheck, lint, testes, npm audit em nível high e build), 30 arquivos de teste no Node test runner cobrindo invariantes de LGPD e de segurança, e smoke test em Playwright com 24 fluxos de navegação em desktop e mobile.

Context

Contexto

Small clinics need one tool for patients, scheduling, clinical records, exams, prescriptions, TISS/TUSS billing codes, inventory and finances, with multi-clinic tenancy and strict control over who can read clinical data, since health records are sensitive personal data under Brazil's LGPD.

Clínicas pequenas precisam de uma única ferramenta para pacientes, agenda, prontuário, exames, prescrições, códigos TISS/TUSS, estoque e financeiro, com várias clínicas isoladas na mesma plataforma e controle rigoroso de quem pode ler dados clínicos, já que prontuário é dado pessoal sensível pela LGPD.

What he built

O que construiu

• Multi-clinic SaaS covering patients, scheduling, structured records, exams, prescriptions, receipts, TISS/TUSS codes, inventory and accounting/fiscal close, plus an importer for official clinical terminologies (CID-10/TUSS) with a mandatory preview step.
• React 19 + Vite PWA over an Express + Prisma/MySQL API; a Firebase ID token is required on every business route, and private files live in Cloudflare R2 with cascade deletion of exam files.
• RBAC with 8 roles and 14 permissions: admin panel with invitations and owner protection, and an LGPD-oriented audit trail that does not store CPF, phone, e-mail or clinical content.
• Security CI gate on pull requests (dependency audit, typecheck, multi-tenant isolation tests) and subscription checkout with Stripe (card, Apple Pay, Google Pay) and Mercado Pago (Pix, boleto).
• MCP server with OAuth 2.1 (dynamic client registration, PKCE, consent, form-urlencoded token exchange) so ChatGPT and Claude can connect as clients, backed by a model fallback chain on OpenRouter; plus an Android app on Google Play.

• SaaS multi-clínica com pacientes, agenda, prontuário estruturado, exames, prescrições, recibos, códigos TISS/TUSS, estoque e fechamento contábil e fiscal, além de importador de terminologias clínicas oficiais (CID-10/TUSS) com etapa obrigatória de prévia.
• PWA em React 19 + Vite sobre API em Express + Prisma/MySQL; o ID token do Firebase é obrigatório em toda rota de negócio, e os arquivos privados ficam no Cloudflare R2, com exclusão em cascata dos arquivos de exames.
• RBAC com 8 papéis e 14 permissões: painel administrativo com convites e proteção do titular, e trilha de auditoria orientada à LGPD que não guarda CPF, telefone, e-mail nem conteúdo clínico.
• Gate de CI de segurança nos pull requests (auditoria de dependências, typecheck, testes de isolamento multi-tenant) e checkout de assinatura com Stripe (cartão, Apple Pay, Google Pay) e Mercado Pago (Pix, boleto).
• Servidor MCP com OAuth 2.1 (registro dinâmico de clientes, PKCE, consentimento e troca de código em form-urlencoded) para que ChatGPT e Claude se conectem como clientes, com cadeia de modelos de reserva no OpenRouter; e app Android na Google Play.

Context

Contexto

The associations needed one relationship base for member hotels and prospects that marketing could use for institutional campaigns, public sign-up forms landing directly in the CRM, and a reliable, auditable link to e-mail marketing. The work started as about 13 prototype iterations (Google AI Studio and Firebase) that had to be consolidated into one production system.

As entidades precisavam de uma base única de relacionamento com hotéis associados e prospects, que o marketing pudesse usar em campanhas institucionais, com formulários públicos de cadastro caindo direto no CRM e uma ligação confiável e auditável com o e-mail marketing. O trabalho começou com cerca de 13 iterações de protótipos (Google AI Studio e Firebase) que precisavam virar um único sistema de produção.

What he built

O que construiu

• Split system of record: contacts live in Zoho CRM, while Cloudflare D1 holds only technical metadata, webhook idempotency keys and a webhook audit log.
• React + TypeScript front end with Cloudflare Pages Functions as the API layer; native public forms feeding Zoho CRM through webhooks, plus Google Apps Script automations.
• Zoho Campaigns integration via API (campaign creation and dispatch, list sync, CRM tagging), with undocumented request formats and limits written up as team runbooks, such as camelCase-only endpoints, the 25-character tag limit and token-based pagination above 2,000 records.
• Spec-driven development with Spec-Kit and an AGENTS.md, so coding agents work inside documented specifications.
• Migrated the marketing CRM host from Vercel to Cloudflare Pages + D1 on 2026-09-01, replacing a double hop (HTML on Vercel plus /api rewrites to Pages) with a single origin; DNS stayed at the registrar and the custom domain was re-provisioned after the cutover.

• Sistema de registro dividido: os contatos ficam no Zoho CRM e o Cloudflare D1 guarda apenas metadados técnicos, chaves de idempotência de webhooks e o log de auditoria dos webhooks.
• Front-end em React + TypeScript com Cloudflare Pages Functions como camada de API; formulários públicos nativos que alimentam o Zoho CRM por webhook, além de automações em Google Apps Script.
• Integração com o Zoho Campaigns via API (criação e disparo de campanhas, sincronização de listas e tags no CRM), com os formatos e limites não documentados registrados em runbooks para a equipe, como endpoints que só aceitam camelCase, o limite de 25 caracteres por tag e a paginação por token acima de 2.000 registros.
• Desenvolvimento orientado a especificação com Spec-Kit e um AGENTS.md, para que os agentes de código trabalhem dentro de especificações documentadas.
• Migração do host do CRM de marketing da Vercel para Cloudflare Pages + D1 em 01/09/2026, trocando um salto duplo (HTML na Vercel e rewrite de /api para o Pages) por uma origem única; o DNS continuou no registrador e o domínio customizado foi reprovisionado após a virada.

Context

Contexto

Small restaurants need one system for their own online storefront, counter and table sales, kitchen and delivery, with marketplace (iFood) orders in the same queue. The first version started from a Google AI Studio scaffold on Firestore; turning it into a multi-tenant product required a server-side API where roles, prices and plan limits are enforced.

Restaurantes pequenos precisam de um único sistema para a própria loja online, as vendas no balcão e na mesa, a cozinha e a entrega, com os pedidos do marketplace (iFood) na mesma fila. A primeira versão nasceu de um scaffold do Google AI Studio sobre Firestore; transformá-la em produto multi-tenant exigiu uma API no servidor que aplica papéis, preços e limites de plano.

What he built

O que construiu

• Multi-tenant SaaS: public storefront per restaurant (two-step cart, search, coupons), POS with tables and cashier, kitchen display (KDS), deliveries with a courier role, live order board, per-channel reports and an installable PWA whose service worker deliberately never caches the API.
• Migrated from Firestore to Cloudflare D1 with a Hono API on Pages Functions (2026-09-13); Firebase kept only for authentication, with token verification moved to the official JWKS, and a separate TypeScript project so the API is type-checked on its own.
• Server-side authorization and pricing: 30 routes gated by role groups (counter, kitchen, delivery), order prices re-read from the catalog on the server, and plan limits enforced by middleware (the monthly order quota returns HTTP 402).
• iFood integration for a distributed app: per-store OAuth (user code, authorization code, refresh token), order polling with acknowledgment and no duplicates, and status updates sent back to iFood; pending homologation.
• Subscription billing with Mercado Pago preapproval, where only the webhook, after re-querying Mercado Pago, can change a tenant's plan; the always-polling live screens became paid-plan features, because a store with all three screens open makes about 12,000 requests a day against the Workers free-tier ceiling of 100,000.

• SaaS multi-tenant: loja pública por restaurante (sacola em duas etapas, busca, cupons), PDV com mesas e caixa, tela de cozinha (KDS), entregas com perfil de entregador, painel de pedidos ao vivo, relatórios por canal e PWA instalável, cujo service worker nunca guarda a API em cache, de propósito.
• Migração do Firestore para o Cloudflare D1 com API em Hono nas Pages Functions (13/09/2026); o Firebase ficou só para autenticação, a validação de token passou a usar o JWKS oficial e um projeto TypeScript separado passou a checar os tipos da API.
• Autorização e preço no servidor: 30 rotas protegidas por grupos de papéis (balcão, cozinha, entrega), preço do pedido relido do catálogo no servidor e limites de plano aplicados por middleware (a cota mensal de pedidos devolve HTTP 402).
• Integração com o iFood para app distribuído: OAuth por loja (user code, authorization code, refresh token), polling de pedidos com confirmação e sem duplicidade, e atualização de status devolvida ao iFood; pendente de homologação.
• Cobrança de assinatura com preapproval do Mercado Pago, em que só o webhook, depois de reconsultar o Mercado Pago, pode mudar o plano da loja; as telas ao vivo, que consultam o servidor o tempo todo, viraram recurso de plano pago, porque uma loja com as três telas abertas faz cerca de 12 mil requisições por dia, contra o teto de 100 mil do plano gratuito do Workers.

Context

Contexto

The team and partners wanted to query member benefits, events, job openings, legal guidance and other institutional content directly from AI assistants (Claude.ai, Claude Code, Cursor) without pasting data into prompts, and without exposing personal data held in the CRM, the job board or member records.

A equipe e os parceiros queriam consultar benefícios, eventos, vagas, orientações jurídicas e outros conteúdos institucionais direto em assistentes de IA (Claude.ai, Claude Code, Cursor), sem colar dados em prompts e sem expor os dados pessoais guardados no CRM, no Banco de Talentos ou nos cadastros de associados.

What he built

O que construiu

• Universal MCP hub on Cloudflare Workers (Streamable HTTP transport): 27 tools across 17 institutional domains, such as benefits, events, holidays, wine and cheese routes, job openings, laws and decrees, the collective labor agreement, courses, maintenance SOPs and official communications; write tools refuse to act without authentication.
• Two deliberately separate auth paths: OAuth 2.1 with PKCE (S256), Dynamic Client Registration and RFC 8414 / RFC 9728 discovery for Claude.ai, with sign-in delegated to the Member Portal identity (Google or e-mail and password); and Bearer tokens (Portal ID token or service token) for local agents. Roles map to public, associate, board and agent.
• Benefits hub: a Cloudflare D1 read model fed by sync adapters from the source systems and exposed as REST (/v1) and MCP. Beyond each adapter's sanitization, a final barrier strips CRM, authentication, contact and personal identifiers from every response.
• Read-only MCP server for aggregate lodging-market data (no establishment-level records), plus an SSE chat backend with a daily quota per device and IP.
• CI with typecheck, Vitest suites and versioned D1 migrations, plus dedicated test scripts for OAuth, the HTTP MCP transport and AI output.

• Hub MCP universal em Cloudflare Workers (transporte Streamable HTTP): 27 ferramentas em 17 domínios institucionais, como benefícios, eventos, feriados, rotas do vinho e do queijo, vagas, leis e decretos, convenção coletiva, cursos, POPs de manutenção e comunicados oficiais; as ferramentas de escrita recusam a ação sem autenticação.
• Dois caminhos de autenticação separados de propósito: OAuth 2.1 com PKCE (S256), registro dinâmico de clientes e descoberta pelas RFC 8414 e RFC 9728 para o Claude.ai, com o login delegado à identidade do Portal do Associado (Google ou e-mail e senha); e tokens Bearer (ID token do Portal ou token de serviço) para agentes locais. Os papéis são público, associado, diretoria e agente.
• Hub de benefícios: modelo de leitura em Cloudflare D1 alimentado por adaptadores de sincronização a partir dos sistemas de origem e exposto em REST (/v1) e MCP. Além da sanitização de cada adaptador, uma barreira final remove campos de CRM, de autenticação, de contato e identificadores pessoais de toda resposta.
• Servidor MCP somente leitura com dados agregados do mercado de hospedagens (sem registros por estabelecimento), com backend de chat por SSE e cota diária por dispositivo e IP.
• CI com typecheck, suítes em Vitest e migrations versionadas do D1, além de scripts de teste dedicados a OAuth, ao transporte MCP por HTTP e à saída da IA.

Context

Contexto

Rio de Janeiro state and municipal legislation lives in legacy government systems (a Lotus Notes database at the state legislature, SAPL portals at city councils) that are hard to search and barely indexable. The aggregator used at first (LexML) started answering every automated request with an anti-bot challenge in Aug 2026. LegiRJ is a search-friendly portal, prepared for ad monetization, that republishes official texts with their source.

A legislação estadual e municipal do Rio de Janeiro fica em sistemas públicos antigos (uma base Lotus Notes na ALERJ, portais SAPL nas Câmaras Municipais), difíceis de pesquisar e quase nada indexáveis. O agregador usado no início (LexML) passou a responder a toda requisição automatizada com um desafio anti-bot em ago/2026. O LegiRJ é um portal pensado para busca e preparado para monetização por anúncios, que republica os textos oficiais com a fonte de cada um.

What he built

O que construiu

• Static PWA (service worker, offline page, manifest) with search and filters by type, category and year, generated by a Node.js pipeline: merge raw CSVs → law pages → category, city and sector hubs → ad configuration → sitemap and a JSON API.
• Python collector for the state legislature's Lotus Notes views that works around a WAF dropping any paginated request, latin-1 responses without a declared charset, all-caps summaries converted to sentence case and dates that alternate between DD/MM and MM/DD.
• Weekly GitHub Actions refresh with a 30-second source health probe, per-source failure isolation and a guardrail that aborts the commit if the generated base drops below 900 laws.
• Municipal expansion (07/09/2026): 300 laws from three city councils' SAPL systems and full text for Rio's city council, with SHA-256 provenance per document, identity checks before rendering, polite collection that honors HTTP 429/Retry-After, and quarantine of unverified legacy records.
• Trust and monetization: a government non-affiliation notice on every generated page plus an official-sources page (added after a Google Play policy notice), a privacy policy, AdSense tag and ads.txt, and a WordPress blog on a subdomain.

• PWA estática (service worker, página offline, manifesto) com busca e filtros por tipo, categoria e ano, gerada por um pipeline em Node.js: consolidação dos CSVs brutos → páginas das normas → hubs por categoria, cidade e setor → configuração de anúncios → sitemap e API JSON.
• Coletor em Python para as views Lotus Notes da ALERJ que contorna um WAF que derruba qualquer requisição paginada, respostas em latin-1 sem charset declarado, ementas em caixa alta convertidas para caixa de frase e datas que alternam entre DD/MM e MM/DD.
• Atualização semanal no GitHub Actions com sonda de saúde da fonte em 30 segundos, isolamento de falha por fonte e uma trava que aborta o commit se a base gerada cair abaixo de 900 leis.
• Expansão municipal (07/09/2026): 300 leis dos sistemas SAPL de três Câmaras Municipais e texto integral da Câmara do Rio, com proveniência por SHA-256 em cada documento, conferência de identidade antes de renderizar, coleta respeitosa que obedece ao HTTP 429/Retry-After e quarentena de registros antigos não verificados.
• Confiança e monetização: aviso de não afiliação governamental em todas as páginas geradas e página de fontes oficiais (criados após uma notificação de política do Google Play), política de privacidade, tag do AdSense e ads.txt, e um blog WordPress num subdomínio.

Context

Contexto

The associations run a recruiting channel for Rio de Janeiro's hotel industry. Version 1 (Jan 2026) was a Firebase/Firestore PWA on Vercel. Because the product stores candidates' résumés and personal data for candidates, recruiters and staff, the rewrite needed a relational source of truth, private file storage, roles enforced on the server and traceable AI features.

As entidades mantêm um canal de recrutamento para a hotelaria do Rio de Janeiro. A versão 1 (jan/2026) era um PWA em Firebase/Firestore na Vercel. Como o produto guarda currículos e dados pessoais de candidatos, recrutadores e equipe, a reescrita precisava de uma fonte de verdade relacional, armazenamento privado de arquivos, papéis aplicados no servidor e recursos de IA rastreáveis.

What he built

O que construiu

• Version 1 (Jan 2026): React PWA on Firebase/Firestore evolved from a Google AI Studio scaffold, with an Android TWA project (Bubblewrap, not published), technical SEO (clean URLs, sitemap, robots.txt) and embedding inside the Member Portal.
• Version 2 (Jul to Aug 2026): React + Express on Azure App Service (Brazil South), with Azure PostgreSQL as the single source of profiles, roles and audit, and résumés in a private Azure Blob container, both reached through managed identity instead of static keys; secrets referenced from Key Vault.
• Server-side authorization: roles come only from the PostgreSQL users table, public sign-up always creates a candidate, staff accounts are created by an admin, and sessions are revocable HttpOnly, Secure, SameSite=Strict cookies; Firebase Auth remains only as the password provider during the transition.
• Restricted résumé analysis with Azure OpenAI (store: false), with Langfuse tracing of prompts and LLM calls.
• Daily job-feed script that publishes open hospitality roles in Rio (from a public ATS API) as JSON for the portal and the MCP hub; a npm run gate step runs tests, typecheck, builds, dependency audit and a redacted secret scan before release.

• Versão 1 (jan/2026): PWA em React sobre Firebase/Firestore, evoluído a partir de um scaffold do Google AI Studio, com projeto Android TWA (Bubblewrap, não publicado), SEO técnico (URLs limpas, sitemap, robots.txt) e incorporação dentro do Portal do Associado.
• Versão 2 (jul a ago/2026): React + Express no Azure App Service (Brazil South), com Azure PostgreSQL como fonte única de perfis, papéis e auditoria e currículos em contêiner privado do Azure Blob, ambos acessados por identidade gerenciada em vez de chave estática; segredos referenciados no Key Vault.
• Autorização no servidor: o papel vem só da tabela users do PostgreSQL, o cadastro público sempre cria um candidato, contas da equipe são criadas por um administrador e a sessão é um cookie revogável HttpOnly, Secure e SameSite=Strict; o Firebase Auth ficou apenas como provedor de senha durante a transição.
• Análise restrita de currículos com Azure OpenAI (store: false) e rastreamento de prompts e chamadas de LLM no Langfuse.
• Script diário de vagas que publica em JSON as vagas abertas de hotelaria no Rio (a partir da API pública de um ATS) para o portal e para o hub MCP; a etapa npm run gate roda testes, typecheck, builds, auditoria de dependências e varredura redigida de segredos antes de cada publicação.

Context

Contexto

EA SPORTS FC Clubs shows club, roster and match stats on public web pages but has no community layer for discovering clubs, recruiting players or arranging friendlies with results people can trust. Pro Clubs America is an independent, non-affiliated community PWA for South American players, built on that public data.

O EA SPORTS FC Clubs mostra estatísticas de clubes, elencos e partidas em páginas públicas, mas não tem uma camada de comunidade para descobrir clubes, recrutar jogadores ou marcar amistosos com resultado confiável. O Pro Clubs America é uma PWA comunitária independente, sem afiliação com a EA, feita para jogadores da América do Sul sobre esses dados públicos.

What he built

O que construiu

• Next.js 16 / React 19 PWA with club and player directories, global search, club and player rankings by metric, a transfer market (open spots and free agents), a friendlies board with invites and open challenges, and regional communities in Portuguese, Spanish and English.
• API on Cloudflare Pages Functions that validates the Firebase Auth token and only then reads or writes Supabase PostgreSQL with the service role; 24 tables have RLS enabled and no client policies by design, so the browser never reaches the database.
• Friendly scores cannot be typed in: completed matches are checked against EA's public match data, stored as deduplicated snapshots through a signed internal endpoint, and confirmed by a PL/pgSQL reconciliation function.
• Tournaments with an approval workflow (club owners propose, admins approve and referee) and an admin overview panel; schema migrations applied through the Supabase MCP server and followed by the Supabase advisors check.
• iOS wrapper (PWABuilder WKWebView) versioned in the repository with fixes for three App Store blockers in the generated template (missing privacy manifest, 32-bit armv7 capability, macOS sandbox entitlements) and arbitrary network loads disabled; a GitHub Actions workflow on a macOS runner builds the unsigned .ipa.

• PWA em Next.js 16 / React 19 com diretórios de clubes e jogadores, busca global, rankings de clubes e de jogadores por métrica, mercado de transferências (vagas abertas e jogadores sem time), mural de amistosos com convites e desafios abertos, e comunidades regionais em português, espanhol e inglês.
• API em Cloudflare Pages Functions que valida o token do Firebase Auth e só então lê ou grava no Supabase PostgreSQL com a service role; as 24 tabelas têm RLS ligada e nenhuma policy para o cliente, por design, então o navegador nunca acessa o banco.
• Placar de amistoso não pode ser digitado: partidas concluídas são conferidas com os dados públicos de partidas da EA, gravadas como snapshots deduplicados por um endpoint interno assinado e confirmadas por uma função PL/pgSQL de conciliação.
• Campeonatos com fluxo de aprovação (dono de clube propõe, admin aprova e arbitra) e painel administrativo; migrações de schema aplicadas pelo servidor MCP do Supabase e seguidas da checagem dos advisors do Supabase.
• Wrapper iOS (WKWebView do PWABuilder) versionado no repositório, com correção de três bloqueios de App Store do template gerado (manifesto de privacidade ausente, capacidade armv7 de 32 bits, entitlements de sandbox do macOS) e carregamento arbitrário de rede desativado; um workflow do GitHub Actions em runner macOS compila o .ipa sem assinatura.

Context

Contexto

Small teams run sales and support on WhatsApp without a shared inbox, a pipeline or AI help, and most cloud tools require a server or the official Business API. Zap Mágico tests a local-first alternative: a Windows desktop app that connects by QR code, keeps data on the user's machine and, in a later phase, lets AI agents (Claude, ChatGPT, Cursor, n8n) use WhatsApp under explicit guardrails.

Equipes pequenas vendem e atendem pelo WhatsApp sem caixa de entrada compartilhada, sem funil e sem apoio de IA, e a maioria das ferramentas em nuvem exige servidor ou a API oficial do WhatsApp Business. O Zap Mágico testa uma alternativa local-first: um app desktop para Windows que conecta por QR Code, mantém os dados na máquina do usuário e, numa segunda fase, permite que agentes de IA (Claude, ChatGPT, Cursor, n8n) usem o WhatsApp sob guardrails explícitos.

What he built

O que construiu

• Electron + React desktop app with multiple WhatsApp accounts via QR code, isolated per-account sessions stored encrypted in a local SQL database, a real-time inbox with tags, priority and internal notes, and a CRM pipeline with stages, owner and deal value.
• AI reply suggestions with a manual-review editor, four optional providers (OpenRouter, Gemini, OpenAI, DeepSeek), a searchable model catalog with price filters, a per-account prompt and knowledge base (PDF, DOCX, XLSX and more), audio transcription and text-to-speech delivered as WhatsApp voice notes.
• Authenticated local REST API bound to 127.0.0.1 for agents and n8n, plus a Node.js MCP server with 12 tools over stdio and stateless Streamable HTTP, bundled into the Windows installer by electron-builder.
• MCP guardrails: token read only from the environment and never logged, phone normalization to international format, connection check before every send, per-minute send rate limit (default 10), optional recipient allowlist, and server instructions that treat inbox messages as data, not instructions (prompt-injection defense).
• Go-to-market pieces: a Chrome (Manifest V3) companion extension that adds AI actions to WhatsApp Web through the local API, a marketing landing page with Mercado Pago checkout, and a multi-tenant SaaS variant on Evolution API, PostgreSQL and Redis (beta).

• App desktop em Electron + React com várias contas de WhatsApp por QR Code, sessões isoladas por conta e gravadas de forma criptografada num banco SQL local, caixa de entrada em tempo real com etiquetas, prioridade e notas internas, e funil de CRM com etapas, responsável e valor da oportunidade.
• Sugestão de resposta por IA com editor para revisão manual, quatro provedores opcionais (OpenRouter, Gemini, OpenAI, DeepSeek), catálogo pesquisável de modelos com filtro de preço, prompt e base de conhecimento por conta (PDF, DOCX, XLSX e outros), transcrição de áudio e voz sintetizada entregue como nota de voz do WhatsApp.
• API REST local autenticada, restrita a 127.0.0.1, para agentes e n8n, e um servidor MCP em Node.js com 12 ferramentas via stdio e Streamable HTTP sem estado, empacotado no instalador do Windows pelo electron-builder.
• Guardrails do MCP: token lido só do ambiente e nunca registrado em log, normalização do telefone para o formato internacional, checagem da conexão antes de cada envio, limite de envios por minuto (padrão de 10), allowlist opcional de destinatários e instruções do servidor que tratam as mensagens da caixa de entrada como dados, nunca como instruções (defesa contra prompt injection).
• Peças de go-to-market: extensão companion para Chrome (Manifest V3) que acrescenta ações de IA ao WhatsApp Web pela API local, landing page com checkout Mercado Pago e uma variante SaaS multi-tenant sobre Evolution API, PostgreSQL e Redis (beta).

Context

Contexto

Hotels across the 92 municipalities of Rio de Janeiro state need to plan occupancy and rates around local events, but official calendars are scattered across city halls, tourism secretariats and official gazettes, and most municipalities publish none. ABIH-RJ, the state hotel association, needed one reference in which every event cites its official source.

Os hotéis dos 92 municípios do estado do Rio de Janeiro precisam planejar ocupação e tarifa em torno dos eventos locais, mas os calendários oficiais estão espalhados entre prefeituras, secretarias de turismo e diários oficiais, e a maioria dos municípios não publica nenhum. A ABIH-RJ precisava de uma referência única em que cada evento cite a sua fonte oficial.

What he built

O que construiu

• Collection pipeline with one research file per municipality (official source in the header, one line per event) → JSON → SQL seed → Cloudflare D1, plus Python probes that check each municipality's official portal.
• Static site generated from the data: home, 92 municipality pages, 8 tourist-region pages based on the state tourism map, one page per event, monthly and category hubs, schema.org markup and sitemap, with titles and descriptions kept within search-result limits.
• Public REST API over D1 (events filterable by municipality, category and date; municipalities with their official source and event count) and token-protected write endpoints; CI deploys to Pages on every push to main.
• Hotel quote-request form (Zoho Forms) on event pages with mandatory LGPD consent, Excel/CSV export of the base, and HTML launch and monthly-agenda e-mails in the association's template.
• Source rules enforced in the data: official sources only, events without a confirmed day left out, no event inferred from past editions, a source link on every page, and 17 dates corrected against the official publication.

• Pipeline de coleta com um arquivo de pesquisa por município (fonte oficial no cabeçalho, uma linha por evento) → JSON → seed SQL → Cloudflare D1, e sondas em Python que conferem o portal oficial de cada município.
• Site estático gerado a partir dos dados: home, 92 páginas de município, 8 páginas de região turística com base no mapa da Setur, uma página por evento, hubs por mês e por categoria, marcação schema.org e sitemap, com títulos e descrições dentro do limite da página de resultados.
• API REST pública sobre o D1 (eventos filtráveis por município, categoria e data; municípios com fonte oficial e contagem de eventos) e rotas de escrita protegidas por token; o CI publica no Pages a cada push na main.
• Formulário de cotação de hospedagem (Zoho Forms) nas páginas de evento com consentimento LGPD obrigatório, exportação da base em Excel/CSV, e e-mails HTML de lançamento e de agenda mensal no padrão da entidade.
• Regras de fonte aplicadas nos dados: só fonte oficial, eventos sem dia confirmado ficam de fora, nenhum evento deduzido de edições anteriores, link da fonte em toda página e 17 datas corrigidas conforme a publicação oficial.

Context

Contexto

HotéisRIO and ABIH-RJ run a recurring hotel occupancy survey on Zoho Forms (responses on file since Dec 2020) whose results the associations publish and national press has cited (context). Years of CSV exports sat in Downloads folders and SharePoint with 261 different header layouts, so basic questions such as 'is participation falling?' or 'who actually responds?' had no reliable answer, and reading only part of the files (36 of 340) suggested a 94% drop that the full base later disproved.

A HotéisRIO e a ABIH-RJ fazem uma pesquisa recorrente de ocupação hoteleira no Zoho Forms (respostas arquivadas desde dez/2020), cujos resultados as entidades divulgam e a imprensa nacional já citou (contexto). Anos de exportações em CSV estavam espalhados em pastas de Downloads e no SharePoint, com 261 formatos de cabeçalho diferentes, então perguntas básicas como 'a participação está caindo?' ou 'quem de fato responde?' não tinham resposta confiável, e ler só parte dos arquivos (36 de 340) sugeria uma queda de 94% que a base completa depois desmentiu.

What he built

O que construiu

• Private versioned repository of 340 original CSV exports (296 unique by SHA-256) with a per-file integrity manifest, synced from SharePoint through Microsoft 365 CLI scripts in PowerShell.
• Parser that maps 261 header variants by column-name heuristics instead of position, recovers the month from header dates in the 83 files that have no date column, and deduplicates by content hash.
• Canonicalization of free-text fields: 89 municipality spellings collapsed into 26 real municipalities and 536 hotel spellings into 385 hotels, using accent-insensitive, sorted-token keys.
• Aggregate-only dashboard (React + Vite on Cloudflare Pages) with filters and a Zoho vs SharePoint comparison view; raw files, archived e-mails and personal data never enter the public build.
• Recency × frequency segmentation of respondents for re-engagement (role and region were empty in most records, so those cuts were not viable), plus a Christmas 2025 occupancy dashboard in Recharts.

• Repositório privado e versionado com 340 exportações CSV originais (296 únicas por SHA-256) e manifesto de integridade por arquivo, sincronizado a partir do SharePoint por scripts em PowerShell com o Microsoft 365 CLI.
• Parser que mapeia 261 variações de cabeçalho por heurística de nome de coluna, e não por posição, recupera o mês pelas datas do cabeçalho nos 83 arquivos sem coluna de data e deduplica por hash de conteúdo.
• Canonicalização de campos de texto livre: 89 grafias de município reduzidas a 26 municípios reais e 536 grafias de hotel a 385 hotéis, com chaves sem acento e de tokens ordenados.
• Dashboard só com dados agregados (React + Vite no Cloudflare Pages), com filtros e uma visão comparativa Zoho x SharePoint; arquivos brutos, e-mails arquivados e dados pessoais nunca entram no build público.
• Segmentação dos respondentes por recência × frequência para reengajamento (cargo e região estavam vazios na maior parte dos registros, então esses recortes não serviam) e um dashboard de ocupação do Natal 2025 em Recharts.

Context

Contexto

AgenciAR, his digital marketing agency in Rio de Janeiro, depends on being found by local businesses that search for a service in their neighborhood or niche. A brochure site cannot rank for thousands of 'service + location' and 'service + niche' long-tail queries, and scaling pages without controls creates duplicate metadata, canonical errors and thin content.

A AgenciAR, agência de marketing digital dele no Rio de Janeiro, depende de ser encontrada por negócios locais que buscam um serviço no próprio bairro ou nicho. Um site institucional simples não ranqueia para milhares de buscas de cauda longa do tipo 'serviço + local' e 'serviço + nicho', e escalar páginas sem controle gera metadados duplicados, erros de canonical e conteúdo raso.

What he built

O que construiu

• React + TypeScript + Vite site whose build chains sitemap generation, the Vite build and per-route static SEO HTML (canonical, robots, schema.org), guarded by an automated SEO contract check and a route-metadata audit.
• Programmatic regional SEO: 1,917 canonical static URLs, including 156 neighborhood and city pages, 936 service × location, 50 service × niche and 750 service × niche × location pages for 15 priority regions, each with diagnosis, action plan, local context and FAQ blocks, and areaServed markup that makes clear the regions are served, not branch offices.
• Duplicate control: 2 exact city duplicates and 12 service-derived duplicates consolidated with 301 redirects; titles kept at 30 to 60 characters and descriptions at 121 to 160.
• Built-in CRM on Supabase, local e-mail and WhatsApp API servers used by the agency, Three.js visual elements, and a mobile layout validated at 320 px and 1440 px without horizontal overflow.
• Read-only readiness audit across Search Console, GA4 and every sitemap URL, with a reproducible script, documenting what is and is not measured yet.

• Site em React + TypeScript + Vite cujo build encadeia a geração do sitemap, o build do Vite e o HTML estático de SEO por rota (canonical, robots, schema.org), protegido por uma checagem automática de contrato de SEO e uma auditoria de metadados por rota.
• SEO regional programático: 1.917 URLs canônicas e estáticas, entre elas 156 páginas de bairro e cidade, 936 de serviço × local, 50 de serviço × nicho e 750 de serviço × nicho × local para 15 regiões prioritárias, cada uma com blocos de diagnóstico, plano de ação, contexto local e FAQ, e marcação areaServed deixando claro que a região é atendida, não uma filial.
• Controle de duplicação: 2 duplicações exatas de cidade e 12 derivadas de serviço consolidadas por redirect 301; títulos entre 30 e 60 caracteres e descrições entre 121 e 160.
• CRM próprio no Supabase, servidores locais de API de e-mail e de WhatsApp usados pela agência, elementos visuais em Three.js e layout mobile validado em 320 px e 1440 px sem rolagem horizontal.
• Auditoria de prontidão somente leitura no Search Console, no GA4 e em todas as URLs do sitemap, com script reproduzível, documentando o que já é medido e o que ainda não é.