{
  "version": "1.0",
  "generated": "2026-08-25T00:49:50.872Z",
  "site": {
    "title": "HDRX — Agent-Ready Web Products",
    "description": "Full-Stack Product Engineer building AI products, high-concurrency systems, and agent-ready infrastructures.",
    "url": "https://hdrx.com.br"
  },
  "entries": [
    {
      "id": "00d4d12873ca9755",
      "url": "https://hdrx.com.br/pt-BR/projetos/wop",
      "title": "WOP - Plataforma de Operações Web — Estudo de caso · Hendrix Garcia (Part 2)",
      "content": "HDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Plataforma operacional para agências: inventário, uptime, incidentes e manutenção de sites.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "sites",
        "manutenção",
        "disponibilidade",
        "conectar",
        "perfil",
        "sistema",
        "são"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/wop"
      }
    },
    {
      "id": "03102dd34edcf638",
      "url": "https://hdrx.com.br/pt-BR/blog/astropress-wordpress-headless-com-astro",
      "title": "AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente — Hendrix Garcia (Part 2)",
      "content": "O WordPress headless remove o PHP do caminho de requisição das páginas de conteúdo por completo. O WordPress vira uma fonte de dados consumida em tempo de build (ou via SSR sob demanda para os poucos casos que realmente precisam, como o preview de rascunho); a página que o visitante carrega de fato é HTML estático servido pelo edge, sem ida ao banco de dados por requisição. O trade-off é real: você abre mão da ergonomia “instalou o plugin, ganhou a funcionalidade” de um tema WordPress monolítico, em troca de uma performance de renderização que não degrada sob tráfego.\n\n## Arquitetura: Camada de Conteúdo, Não Só uma Chamada de API\n\nO docs/architecture.md do AstroPress documenta o fluxo de dados assim: WordPress → REST API (/wp-json/wp/v2/*) → um cliente WordPress (client.ts) → JSON bruto → uma camada de conteúdo** (src/lib/wordpress/) que normaliza o payload → dados tipados e normalizados consumidos por rotas e componentes do Astro → HTML estático (ou a rota de preview sob demanda).\n\nA camada de conteúdo é a parte que importa arquiteturalmente. Em vez de deixar o formato da resposta REST do WordPress vazar para cada componente de página — nomes de campo, objetos de taxonomia aninhados, peculiaridades específicas do WordPress —, a camada de normalização isola isso completamente. Os componentes consomem um formato tipado e definido pelo próprio projeto; se a resposta da API do WordPress mudar, ou você trocar um plugin que altera o payload, o ajuste é feito num único lugar, em vez de caçar cada template que tocava post.acf.algum_campo diretamente.",
      "description": "Como o AstroPress desacopla o WordPress como backend editorial puro de um frontend estático em Astro — a camada de conteúdo, a cascata de SEO em 4 níveis, preview de rascunho em tempo real e os orçamentos de performance aplicados em CI.",
      "keywords": [
        "wordpress",
        "para",
        "não",
        "conteúdo",
        "astropress",
        "como",
        "plugin",
        "astro",
        "preview",
        "performance"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/astropress-wordpress-headless-com-astro"
      }
    },
    {
      "id": "037e9a27ccac2d0c",
      "url": "https://hdrx.com.br/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce",
      "title": "Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms — Hendrix Garcia (Part 4)",
      "content": "### O que um object cache persistente realmente corrige?\n\nEle converte leituras MySQL repetidas (options, transients, meta de produtos, relacionamentos de termos) em lookups Redis abaixo de milissegundo compartilhados por todos os workers PHP-FPM. É a mudança de maior alavancagem na maioria das instalações WooCommerce, porque core WordPress e WooCommerce já chamam extensivamente wp_cache_get()/wp_cache_set(); basta colocar backend persistente por trás dessas chamadas.\n\nConfiguração com o drop-in redis-cache:\n\nwp plugin install redis-cache --activate\nwp redis enable\n// wp-config.php\ndefine('WP_REDIS_HOST', '127.0.0.1');\ndefine('WP_REDIS_PORT', 6379);\ndefine('WP_REDIS_TIMEOUT', 1);\ndefine('WP_REDIS_READ_TIMEOUT', 1);\ndefine('WP_REDIS_DATABASE', 0);\ndefine('WP_CACHE', true);\nConfirme que ele está conectado de verdade, não caindo silenciosamente no cache não persistente:\n\nwp redis status\n\n### Redis vs. Memcached no WooCommerce — qual usar?\n\n- **Redis** suporta persistência, introspecção de expiração de chaves e, de modo decisivo para WooCommerce, **grupos de cache com flush por padrão**, importante quando um plugin precisa invalidar todas as chaves de produto após atualização de estoque sem limpar o cache inteiro. Por isso é o padrão de facto para object cache em WooCommerce.\n\n- **Memcached** pode ser marginalmente mais rápido em alguns benchmarks de gets puros de chave-valor, mas não tem persistência e possui ferramentas de introspecção mais fracas. Use-o apenas se Redis não estiver disponível no hosting.\n\n### A armadilha da sessão WooCommerce",
      "description": "Um guia técnico aprofundado para Time to First Byte no WooCommerce: cache de objetos Redis, HPOS, gargalos do Action Scheduler, opções autocarregadas, ajuste de PHP-FPM e cache edge para lojas de alto tráfego.",
      "keywords": [
        "cache",
        "não",
        "woocommerce",
        "redis",
        "para",
        "ttfb",
        "object",
        "query",
        "time",
        "páginas"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce"
      }
    },
    {
      "id": "040f0c2b6fe0d8a2",
      "url": "https://hdrx.com.br",
      "title": "Hendrix Garcia — Full-Stack Product Engineer (Part 1)",
      "content": "Full-Stack Developer & Product Engineer\n\n## Hendrix GarciaHendrix Garcia\n\nType 'help' to see what I can do.\n\nguest@hdrx:~$\n\n█\n\nOpen to full-time roles— Available to start immediately. Remote preferred worldwide.\n\n## What I can help you ship\n\nFrom a focused delivery to an ongoing engineering partnership, the work starts with the business problem and ends in a reliable production system.\n\n[Discuss this work →](/contact)\n\n-\n\n### Web products & full-stack systems\n\nBuild or evolve a web product with a modern frontend, backend integrations, and a production-ready foundation.\n\n-\n\n### WordPress & WooCommerce operations\n\nCreate, customize, migrate, optimize, and maintain WordPress or commerce environments that need to keep working.\n\n-\n\n### AI integrations & automation\n\nConnect APIs, webhooks, AI tools, and business workflows into systems that reduce manual work and stay observable.\n\n// Systems\n\n## Featured Projects\n\n[View All Catalog →](/projects)\n\n### Agent-Ready Portfolio\n\nAn agent-ready portfolio with MCP, llms.txt, and an interactive terminal for AI assistants.\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n[View project](/projects/agent-ready-portfolio)\n\n### WOP - Web Operations Platform\n\nOperations platform for agencies: site inventory, uptime monitoring, incidents, and maintenance.\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n[View project](/projects/wop)\n\n### Prompt Pocket\n\nPrivacy-first Chrome extension to save, organize, and instantly reuse AI prompts across tools.",
      "description": "Full-Stack Product Engineer building fast, reliable web products and AI-enabled systems.",
      "keywords": [
        "wordpress",
        "typescript",
        "hendrix",
        "projects",
        "react",
        "developer",
        "work",
        "with",
        "connect",
        "tailwind"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 4,
        "sourcePath": "/"
      }
    },
    {
      "id": "053376a4def66c19",
      "url": "https://hdrx.com.br/blog/woocommerce-performance-ttfb",
      "title": "WooCommerce TTFB Optimization: The Complete Guide to Sub-300ms Stores — Hendrix Garcia (Part 5)",
      "content": "By default, WooCommerce stores customer sessions in wp_woocommerce_sessions, a database table, not in the object cache. Under concurrent cart activity this table takes constant writes (every cart mutation triggers a session update), and it’s a common source of write contention that Redis object caching alone doesn’t fix, because sessions bypass the object cache path unless explicitly configured. If your host’s WC_Session_Handler implementation supports it, route sessions through Redis directly rather than relying solely on database session storage, and audit woocommerce_cookie_expiration and session cleanup cron intervals so stale sessions aren’t accumulating.\n\n## Pillar 2: Database Architecture — Indexing, N+1 Queries, and Autoloaded Bloat\n\nObject caching hides",
      "description": "A deep technical guide to WooCommerce Time to First Byte: Redis object caching, HPOS, Action Scheduler bottlenecks, autoloaded options, PHP-FPM tuning, and edge caching for high-traffic stores.",
      "keywords": [
        "woocommerce",
        "cache",
        "redis",
        "object",
        "caching",
        "time",
        "this",
        "cart",
        "queries",
        "query"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/blog/woocommerce-performance-ttfb"
      }
    },
    {
      "id": "06d3da53224752d4",
      "url": "https://hdrx.com.br/blog/woocommerce-performance-ttfb",
      "title": "WooCommerce TTFB Optimization: The Complete Guide to Sub-300ms Stores — Hendrix Garcia (Part 1)",
      "content": "[← Back to all articles](/blog)**\n\nAugust 8, 2026• 17 min read\nWordPressWooCommercePerformanceTTFBRedisPHP-FPMCore Web Vitals\n\n## WooCommerce TTFB Optimization: The Complete Guide to Sub-300ms Stores\n\nA deep technical guide to WooCommerce Time to First Byte: Redis object caching, HPOS, Action Scheduler bottlenecks, autoloaded options, PHP-FPM tuning, and edge caching for high-traffic stores.\n\nWooCommerce stores lose conversions during traffic spikes — Black Friday, a viral product, a paid campaign landing all at once — and in most audits I run, the failure point isn’t the frontend bundle or image weight. It’s server-side: a high Time to First Byte (TTFB)** driven by synchronous PHP execution, uncached database round-trips, and cart/session logic that WordPress was never architected to handle at scale.\n\nTTFB is the time between the browser’s request and the first byte of the response arriving. For a WooCommerce page that means: PHP-FPM must accept the request, WordPress must bootstrap, plugins must hook into init and wp_loaded, WooCommerce must resolve the customer session and cart, any dynamic queries (stock, price rules, shipping zones) must hit MySQL, and only then does the server start streaming HTML. Every one of those steps is a candidate for a full-table scan, a cache miss, or a blocking external call. This guide covers the mechanisms behind each bottleneck and the concrete fixes, from cheapest to most invasive.\n\n## Why WooCommerce TTFB Is Structurally Different From WordPress TTFB\n\nA static blog post can be served entirely from page cache — Varnish, Nginx FastCGI cache, or a CDN edge node returns the HTML without touching PHP or MySQL at all. WooCommerce breaks that model on three page types by design:\n\n- **Cart and checkout pages** must reflect real-time state (cart contents, shipping cost, coupon validity), so full-page caching them is unsafe out of the box.\n\n- **My Account pages** are inherently per-user and cannot be cached publicly.",
      "description": "A deep technical guide to WooCommerce Time to First Byte: Redis object caching, HPOS, Action Scheduler bottlenecks, autoloaded options, PHP-FPM tuning, and edge caching for high-traffic stores.",
      "keywords": [
        "woocommerce",
        "cache",
        "redis",
        "object",
        "caching",
        "time",
        "this",
        "cart",
        "queries",
        "query"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/blog/woocommerce-performance-ttfb"
      }
    },
    {
      "id": "06e40bfc70875cd4",
      "url": "https://hdrx.com.br/blog",
      "title": "Blog and articles — Hendrix Garcia",
      "content": "Technical Writing\n\n## Articles & NotesArticles & Notes\n\nDeep dives on agent engineering, Model Context Protocol, WordPress performance tuning, and scalable full-stack web architecture.\n\n[Aug 24, 2026 • 12 min read Astro WordPress Headless CMS Open Source Performance AstroPress: A Headless WordPress + Astro](/blog/astropress-headless-wordpress-astro)\n\n[Aug 24, 2026 • 8 min read Web Development Landing Page Business Websites SEO Professional Website Development: The Techn](/blog/professional-website-development)\n\n[Aug 10, 2026 • 14 min read AI MCP Architecture Edge Functions Serverless JSON-RPC Stateless MCP on Edge Functions: Archi](/blog/mcp-stateless-edge-functions)\n\n[Aug 8, 2026 • 17 min read WordPress WooCommerce Performance TTFB Redis PHP-FPM Core Web Vitals WooCommerce TTFB Optimiza](/blog/woocommerce-performance-ttfb)\n\n[Aug 5, 2026 • 16 min read AI Prompt Engineering LLM TypeScript Next.js CI/CD Eval Prompt Engineering as Code: Versioning](/blog/prompt-engineering-as-code)\n\n[Aug 1, 2026 • 14 min read AEO MCP Product Engineering Structured Data Astro Agent-Ready Portfolios: Building Developer S](/blog/agent-ready-portfolios)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Writing on agent engineering, web performance, and product development.",
      "keywords": [
        "2026",
        "blog",
        "read",
        "engineering",
        "wordpress",
        "astro",
        "connect",
        "profile",
        "performance",
        "developer"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 1,
        "sourcePath": "/blog"
      }
    },
    {
      "id": "0b90553d8f64f395",
      "url": "https://hdrx.com.br/about",
      "title": "About Hendrix Garcia (Part 3)",
      "content": "WordPressWooCommerceElementorPHP hooksCustom Post Types\n\n### // AI & Automation\n\nClaude APIMCPn8nMakeAI AgentsWebhooks\n\n### // Infrastructure\n\nDockerVercelGitCloudflareSSLLinux VPS\n\n[03]\n\n## Education & Specialization\n\nJan 2025 – Jan 2026\n\n### Postgraduate: Marketing, Strategy, Digital Business, and Customer Experience\n\nPUC-PR\n\n2021 – 2023\n\n### Systems Analysis and Development\n\nUNINTER\n\n### Want an AI Agent to evaluate Hendrix's background?\n\nThis portfolio provides a public stateless Model Context Protocol (MCP) server for Claude, Cursor, and ChatGPT.\n\n[View MCP Instructions →](/connect)[Get in Touch](/contact)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Professional background, technical capabilities, and approach to product engineering.",
      "keywords": [
        "wordpress",
        "with",
        "woocommerce",
        "react",
        "javascript",
        "laravel",
        "elementor",
        "apis",
        "developer",
        "development"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 3,
        "sourcePath": "/about"
      }
    },
    {
      "id": "11082bf7bab0b1f0",
      "url": "https://hdrx.com.br/pt-BR/contato",
      "title": "Contato — Hendrix Garcia",
      "content": "OPEN*TO*WORK*\n\nCanal direto\n\n## Vamos construir o futuro!Vamos construir o futuro!\n\nNo momento aberto a oportunidades em tempo integral. Se você tem uma vaga aberta, um produto de IA para arquitetar ou uma operação WordPress para otimizar, envie um resumo abaixo.\n\nSeu nome / organização *\n\nE-mail ou perfil do LinkedIn *\n\nTipo de contato\nRecrutamentoCotação de projetoConsultoria\n\nResumo do projeto / detalhes da vaga *\n\nEnviar resumo →Endpoint com limite de requisições • entrega direta via Resend\n\n[01 // E-mail direto hdrxgarcia@gmail.com Caixa de entrada direta • Resposta em < 24h](mailto:hdrxgarcia@gmail.com)\n\n[02 // Perfil do LinkedIn ↗ Perfil do LinkedIn ↗ Histórico profissional e recomendações](https://linkedin.com/in/hendrixgarcia)\n\n[03 // Conexão MCP ↗ Conexão MCP ↗ Conecte seu agente de IA pelo Model Context Protocol](/pt-BR/conectar)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Entre em contato com Hendrix Garcia sobre vagas CLT, contratos e engenharia de produto.",
      "keywords": [
        "pt-br",
        "perfil",
        "linkedin",
        "gmail",
        "conectar",
        "para",
        "hdrxgarcia",
        "resumo",
        "https",
        "github"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 1,
        "sourcePath": "/pt-BR/contato"
      }
    },
    {
      "id": "139fdfb8878365cb",
      "url": "https://hdrx.com.br/projects/jumbox",
      "title": "Jumbox — Case Study · Hendrix Garcia (Part 1)",
      "content": "[← Back to all projects](/projects)\n\n// fullstack Featured System\n\n## Jumbox\n\nPrivate, local-first file transfer system with resumable streaming and end-to-end integrity.\n\n[Source Code ↗](https://github.com/hd-rx8/jumbox)[Discuss Similar Project](/contact)\n\n[01] Problem Statement & Context\n\n## The Challenge\n\nSharing files across the same LAN or Wi-Fi still usually means routing them through a third-party cloud service, and once a large transfer starts, a dropped connection means starting over from zero — there's no direct, private way to just push files from one machine on the network to another with resilience built in.\n\n[02] Technical Architecture & Solution\n\n## Engineering Delivery\n\nBuilt Jumbox as a self-hosted FastAPI service with a layered domain model (a TransferSession aggregate managing TransferItem entities), exposing multi-file transfer sessions under an 8-digit share code or QR code that other devices on the LAN can pick up. Uploads use a resumable chunk protocol (PATCH .../chunks with Upload-Offset probing) that survives network drops without retransmitting already-accepted bytes, backed by automatic retries with exponential backoff. Every transfer is verified end-to-end via SHA-256 with checksum and ETag headers, downloads stream directly to disk with Accept-Ranges support to avoid buffering large files in memory, and an optional ephemeral mode purges files from disk the moment the recipient downloads them. Runs zero-config on SQLite for standalone use or Postgres via Docker Compose for a production stack, with SQLAlchemy 2.0 and Alembic migrations underneath.\n\n[03] Technology Stack & Utilities\n\nPythonFastAPISQLAlchemy 2.0AlembicSQLite / PostgreSQLDocker Compose\n\n[← Previous SystemPrompt Pocket](/projects/prompt-pocket)[Next System →AstroPress](/projects/astropress)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation",
      "description": "Private, local-first file transfer system with resumable streaming and end-to-end integrity.",
      "keywords": [
        "with",
        "projects",
        "transfer",
        "github",
        "files",
        "connect",
        "profile",
        "system",
        "jumbox",
        "code"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects/jumbox"
      }
    },
    {
      "id": "13bd3c7c8bb2fcaf",
      "url": "https://hdrx.com.br/pt-BR/projetos/agent-ready-portfolio",
      "title": "Portfólio Preparado para Agentes — Estudo de caso · Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os projetos](/pt-BR/projetos)\n\n// mcp Sistema em destaque\n\n## Portfólio Preparado para Agentes\n\nPortfólio pronto para agentes, com MCP, llms.txt e terminal interativo para assistentes de IA.\n\n[Em produção ↗](https://hdrx.com.br)[Código-fonte ↗](#)[Falar sobre projeto semelhante](/pt-BR/contato)\n\n[01] Declaração do problema e contexto\n\n## O desafio\n\nRecrutadores e ferramentas de contratação usam cada vez mais agentes de IA para avaliar candidatos antes mesmo de uma pessoa abrir um currículo, mas quase todo portfólio de desenvolvedor é construído apenas para olhos humanos — HTML plano que um agente precisa raspar e interpretar, sem uma forma confiável de fazer uma pergunta direta e receber uma resposta estruturada.\n\n[02] Arquitetura técnica e solução\n\n## Entrega de engenharia\n\nO próprio portfólio foi construído como prova: duas camadas paralelas leem dos mesmos dados de fonte única da verdade. A camada humana é um site em Astro 5 + React 19 com um terminal no hero que executa comandos reais (incluindo um easter egg narrativo oculto em múltiplos capítulos) com revelação em máquina de escrever. A camada de agentes é um servidor MCP sem estado que fala JSON-RPC 2.0 sobre HTTP em /api/mcp, expondo ferramentas somente de leitura (currículo, projetos, capacidades, disponibilidade e o manifesto oculto) mais uma ferramenta com efeito colateral (contato por e-mail via Resend). Qualquer cliente compatível com MCP — Claude, Cursor, ChatGPT — conecta-se diretamente e consulta exatamente os mesmos dados que o site humano renderiza, sem nenhuma raspagem.\n\n[03] Stack de tecnologia e utilitários\n\nAstro 5React 19TypeScriptTailwind CSS v4MCP · JSON-RPC 2.0Vercel Edge FunctionsResend\n\n[← Sistema anteriorWeb Ready](/pt-BR/projetos/web-ready)[Próximo sistema →WOP - Plataforma de Operações Web](/pt-BR/projetos/wop)",
      "description": "Portfólio pronto para agentes, com MCP, llms.txt e terminal interativo para assistentes de IA.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "agentes",
        "portfólio",
        "conectar",
        "perfil",
        "sistema",
        "https",
        "sobre"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/agent-ready-portfolio"
      }
    },
    {
      "id": "17a379886af2e742",
      "url": "https://hdrx.com.br/pt-BR/sobre",
      "title": "Sobre Hendrix Garcia (Part 2)",
      "content": "- ▸Fundou e opera uma agência de desenvolvimento web, entregando mais de 60 projetos para múltiplos segmentos de clientes\n- ▸Desenvolvimento de sites, landing pages, blogs e lojas virtuais\n- ▸Customização de temas WordPress, plugins, Elementor, formulários e hooks\n- ▸Desenvolvimento de interfaces com React, TypeScript, Next.js e Tailwind CSS\n- ▸Implementação de backend com PHP, Laravel, Supabase, SQL e APIs REST\n- ▸Integrações com CRM, WhatsApp, gateways de pagamento, analytics e webhooks\n- ▸Automação com n8n, Make e ferramentas de IA\n- ▸Hospedagem, domínios, SSL, Docker, Cloudflare e configuração de produção\n- ▸Gestão de escopo, relacionamento com clientes e documentação\n\n- WordPress\n- WooCommerce\n- PHP\n- JavaScript\n- TypeScript\n- React\n- Next.js\n- Astro\n- Laravel\n- Supabase\n- MySQL\n- PostgreSQL\n- Docker\n- Git\n- REST APIs\n- n8n\n- Make\n- GA4\n- GTM\n\n- WordPress\n- WooCommerce\n- PHP\n- JavaScript\n- TypeScript\n- React\n- Next.js\n- Astro\n- Laravel\n- Supabase\n- MySQL\n- PostgreSQL\n- Docker\n- Git\n- REST APIs\n- n8n\n- Make\n- GA4\n- GTM\n\n### Desenvolvedor WordPress Freelancer e Web Designer @ Workana\n\njul. de 2019 – out. de 2022\n\n- ▸Mais de 80 projetos entregues: sites institucionais, landing pages, lojas virtuais e soluções personalizadas\n- ▸Customização de WordPress, WooCommerce e Elementor\n- ▸Desenvolvimento frontend com HTML, CSS, JavaScript e React\n- ▸Backend e integrações com PHP, Laravel, SQL e APIs REST\n- ▸Configuração de hospedagem, domínio e SSL para ambientes de produção\n- ▸Migração, manutenção e correção de bugs em sites\n- ▸Otimização de performance, SEO técnico e melhorias no tempo de carregamento\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- Laravel\n- JavaScript\n- React\n- HTML\n- CSS\n- MySQL\n- SQL\n- Git\n- REST APIs\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- Laravel\n- JavaScript\n- React\n- HTML\n- CSS\n- MySQL\n- SQL\n- Git\n- REST APIs\n\n[02]\n\n## Matriz de capacidades técnicas\n\n### // Frontend\n\nReactNext.jsAstroTypeScriptTailwind CSSHTMLCSS\n\n### // Backend",
      "description": "Trajetória profissional, capacidades técnicas e abordagem de engenharia de produto.",
      "keywords": [
        "wordpress",
        "woocommerce",
        "pt-br",
        "react",
        "javascript",
        "laravel",
        "elementor",
        "rest",
        "para",
        "desenvolvimento"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/sobre"
      }
    },
    {
      "id": "1a92b8785000d427",
      "url": "https://hdrx.com.br/pt-BR/conectar",
      "title": "Conectar via MCP — Hendrix Garcia (Part 2)",
      "content": "## Core Skills\n\nWordPress · WooCommerce · PHP · TypeScript · React · Next.js · Node.js ·\nAstro · Laravel · Supabase · Docker · REST APIs · n8n · Make · AI Agents · MCP\n\nResponse within 24h.\n\n## Experimente perguntar ao seu agente\n\nPara quais tipos de trabalho posso contratar o Hendrix?Hendrix está aberto a trabalhos full-time e contract como Desenvolvedor Full-Stack, Engenheiro de Produto, Desenvolvedor WordPress. As especialidades atuais incluem WordPress e WooCommerce, React e Next.js, TypeScript, Performance Web, Integrações de IA, Automação (n8n, Make). Aberto a oportunidades em tempo integral.\n\nO Hendrix pode criar ou evoluir um site em WordPress ou WooCommerce?Sim. A experiência documentada de Hendrix com WordPress inclui Desenvolvedor WordPress e WooCommerce na HempHealthOnline (mar. de 2026 – Presente); Fundador e Desenvolvedor Web Full-Stack na CONEX.HUB (jan. de 2022 – Presente); Desenvolvedor WordPress Freelancer e Web Designer na Workana (jul. de 2019 – out. de 2022). Isso abrange desenvolvimento, customização, manutenção, migração e troubleshooting em WordPress e WooCommerce.\n\nO Hendrix pode trabalhar em um produto full-stack ou aplicação web?Sim. A stack documentada inclui React, Next.js, Astro, TypeScript, Tailwind CSS, HTML, CSS no frontend e Node.js, PHP, Laravel, Supabase, MySQL, PostgreSQL, APIs REST no backend. Sistemas relevantes no portfólio incluem Portfólio Preparado para Agentes e WOP - Plataforma de Operações Web e Prompt Pocket e Jumbox e Web Ready.\n\nO Hendrix integra IA, automação ou serviços de terceiros?Sim. Hendrix trabalha com API Claude, MCP, n8n, Make, Agentes de IA, Webhooks e tem integrações documentadas com CRM, WhatsApp, gateways de pagamento, analytics e webhooks. Sistemas relevantes no portfólio incluem Portfólio Preparado para Agentes e Prompt Pocket e Web Ready.",
      "description": "Conecte um agente de IA ao portfólio de Hendrix Garcia por MCP e APIs estruturadas.",
      "keywords": [
        "hendrix",
        "wordpress",
        "endpoint",
        "desenvolvedor",
        "para",
        "portfólio",
        "agents",
        "contact",
        "woocommerce",
        "pode"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/conectar"
      }
    },
    {
      "id": "1db2a2d6661e5913",
      "url": "https://hdrx.com.br/blog/prompt-engineering-as-code",
      "title": "Prompt Engineering as Code: Versioning, Testing, and CI/CD for LLM Prompts — Hendrix Garcia (Part 1)",
      "content": "[← Back to all articles](/blog)**\n\nAugust 5, 2026• 16 min read\nAIPrompt EngineeringLLMTypeScriptNext.jsCI/CDEval\n\n## Prompt Engineering as Code: Versioning, Testing, and CI/CD for LLM Prompts\n\nA practical framework for treating prompts as software artifacts — semantic versioning, Zod-validated structured output, regression eval suites, and CI/CD gating, built from the Prompt Pocket architecture.\n\nMost teams running LLMs in production still manage prompts as loose strings — inline in application code, scattered across .env files, or edited directly in a vendor dashboard with no diff, no review, and no test suite. This works until it doesn’t: a “small copy tweak” silently breaks structured output parsing, a model version bump changes tone or format without anyone noticing, or a support agent discovers a jailbreak three weeks before engineering does.\n\nPrompt Engineering as Code (PEaC)** treats the prompt as a versioned, testable, reviewable software artifact — subject to the same discipline as any other code that ships to production: schema contracts, regression suites, code review, and CI/CD gates. This is the architecture built for the **Prompt Pocket** project, and the rest of this post breaks down the reasoning, the failure modes it prevents, and the implementation details that matter once you go past a toy prototype.\n\n## Why Prompts Need Software Engineering Discipline\n\n### What breaks when prompts are treated as strings, not artifacts?\n\nFour failure modes show up consistently in production LLM systems that skip prompt engineering discipline:\n\n- **Silent behavioral drift** — a prompt edited in a dashboard changes downstream behavior with no code review, no diff visible to reviewers, and no automated check that output shape or quality held steady.",
      "description": "A practical framework for treating prompts as software artifacts — semantic versioning, Zod-validated structured output, regression eval suites, and CI/CD gating, built from the Prompt Pocket architecture.",
      "keywords": [
        "prompt",
        "output",
        "with",
        "model",
        "schema",
        "this",
        "that",
        "code",
        "validation",
        "from"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/blog/prompt-engineering-as-code"
      }
    },
    {
      "id": "202655cb29f0b774",
      "url": "https://hdrx.com.br/pt-BR/blog/engenharia-de-prompts-como-codigo",
      "title": "Engenharia de prompts como código: versionamento, testes e CI/CD para prompts de LLMs — Hendrix Garcia (Part 5)",
      "content": "- **Faça novo prompt com o erro de validação anexado** — forneça a mensagem Zod/Pydantic ao modelo como contexto (your previous response failed validation: findings[0].severity must be one of critical/important/minor, got 'high') e peça resposta corrigida. Isso resolve a maioria das falhas transitórias de formato porque o modelo consegue se autocorrigir com feedback específico.\n\n- **Use fallback para um prompt de extração mais estrito** — se o retry #1 falhar, reduza para um prompt estreito e de propósito único, cujo trabalho",
      "description": "Um framework prático para tratar prompts como artefatos de software — versionamento semântico, saída estruturada validada por Zod, suítes de eval de regressão e gates de CI/CD, a partir da arquitetura do Prompt Pocket.",
      "keywords": [
        "prompt",
        "não",
        "para",
        "saída",
        "modelo",
        "schema",
        "como",
        "validação",
        "json",
        "versão"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/engenharia-de-prompts-como-codigo"
      }
    },
    {
      "id": "22da79cfe3485340",
      "url": "https://hdrx.com.br/pt-BR/blog",
      "title": "Blog e artigos — Hendrix Garcia (Part 2)",
      "content": "Desenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Textos sobre engenharia de agentes, performance web e desenvolvimento de produtos.",
      "keywords": [
        "pt-br",
        "2026",
        "blog",
        "leitura",
        "para",
        "conectar",
        "perfil",
        "performance",
        "wordpress",
        "astro"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/blog"
      }
    },
    {
      "id": "23112dad395f96e6",
      "url": "https://hdrx.com.br",
      "title": "Hendrix Garcia — Full-Stack Product Engineer (Part 3)",
      "content": "Can Hendrix build or improve a WordPress or WooCommerce site?Yes. Hendrix's documented WordPress experience includes WordPress & WooCommerce Developer at HempHealthOnline (Mar 2026 – Present); Founder & Full-Stack Web Developer at CONEX.HUB (Jan 2022 – Present); Freelance WordPress Developer & Web Designer at Workana (Jul 2019 – Oct 2022). This covers WordPress and WooCommerce development, customization, maintenance, migration, and troubleshooting.\n\nCan Hendrix work on a full-stack product or web application?Yes. The documented stack includes React, Next.js, Astro, TypeScript, Tailwind CSS, HTML, CSS on the frontend and Node.js, PHP, Laravel, Supabase, MySQL, PostgreSQL, REST APIs on the backend. Relevant portfolio systems include Agent-Ready Portfolio and WOP - Web Operations Platform and Prompt Pocket and Jumbox and Web Ready.\n\nCan Hendrix integrate AI, automation, or third-party services?Yes. Hendrix works with Claude API, MCP, n8n, Make, AI Agents, Webhooks and has documented integrations with CRM, WhatsApp, payment gateways, analytics, and webhooks. Relevant portfolio systems include Agent-Ready Portfolio and Prompt Pocket and Web Ready.\n\nCan Hendrix help with performance, migrations, or production issues?Yes. Documented work includes performance optimization, Core Web Vitals, technical SEO, site replication, migration, deployment, and troubleshooting across plugins, themes, databases, URLs, and redirects.\n\nWhat should I include when I get in touch?Share the problem or role, the scope you want to discuss, the current stack or environment, and any relevant timeline. The contact form supports full-time recruiting, consulting or contract work, and engineering conversations.\n\n// Autonomous Agent Layer\n\n### This site speaks MCP\n(Model Context Protocol)\n\nClaude, Cursor, or ChatGPT can connect directly to /api/mcp to query resume data, search capabilities, and verify availability.\n\n[Connect Your Agent →](/connect)",
      "description": "Full-Stack Product Engineer building fast, reliable web products and AI-enabled systems.",
      "keywords": [
        "wordpress",
        "typescript",
        "hendrix",
        "projects",
        "react",
        "developer",
        "work",
        "with",
        "connect",
        "tailwind"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 4,
        "sourcePath": "/"
      }
    },
    {
      "id": "26e8bec88facc900",
      "url": "https://hdrx.com.br/blog/mcp-stateless-edge-functions",
      "title": "Stateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation — Hendrix Garcia (Part 1)",
      "content": "[← Back to all articles](/blog)**\n\nAugust 10, 2026• 14 min read\nAIMCPArchitectureEdge FunctionsServerlessJSON-RPC\n\n## Stateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation\n\nA deep technical guide to building a stateless Model Context Protocol server on Vercel Edge Functions — JSON-RPC 2.0 design, the 2026-07-28 spec change, auth and rate limiting without sessions, and headless testing with curl.\n\nThe Model Context Protocol (MCP)** was designed around a session model borrowed from stdio-based local tooling: a client spawns a process, performs an initialize handshake, receives a notifications/initialized acknowledgment, and keeps that process — and its in-memory state — alive for the life of the conversation. That model maps cleanly onto a desktop app talking to a subprocess. It maps badly onto a Vercel Edge Function that may run on a different isolate for every single request.\n\nThe 2026-07-28 revision of the MCP spec formalized a **stateless HTTP transport** that removes the handshake as a hard prerequisite and lets a server answer tools/call and tools/list as pure, self-contained request/response pairs. This post covers what changed, why the previous session-oriented design was actively hostile to edge runtimes, and how to implement a compliant stateless MCP server on Vercel Edge Functions — including the parts most write-ups skip: auth without server-side session state, rate limiting at the edge, JSON-RPC error code conventions, and headless testing with curl.\n\nThis portfolio runs exactly this architecture in production at /api/mcp — a single Edge Function handling get_resume, get_projects, get_capabilities, check_availability, get_manifest, and the one side-effecting tool, contact.\n\n## Why stdio-Style Sessions Don’t Map to Serverless\n\nMCP’s original transport assumption is a long-lived, single-tenant process. Three properties of that model break the moment you move to serverless or edge compute:",
      "description": "A deep technical guide to building a stateless Model Context Protocol server on Vercel Edge Functions — JSON-RPC 2.0 design, the 2026-07-28 spec change, auth and rate limiting without sessions, and headless testing with curl.",
      "keywords": [
        "edge",
        "server",
        "tools",
        "that",
        "session",
        "request",
        "call",
        "stateless",
        "with",
        "node"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/blog/mcp-stateless-edge-functions"
      }
    },
    {
      "id": "2876b08ddf0447a4",
      "url": "https://hdrx.com.br/connect",
      "title": "Connect — Hendrix Garcia (Part 2)",
      "content": "WordPress · WooCommerce · PHP · TypeScript · React · Next.js · Node.js ·\nAstro · Laravel · Supabase · Docker · REST APIs · n8n · Make · AI Agents · MCP\n\nResponse within 24h.\n\n## Try asking your agent\n\nWhat kinds of work can I hire Hendrix for?Hendrix is open to full-time and contract work as a Full-Stack Developer, Product Engineer, WordPress Developer. Current specialties include WordPress & WooCommerce, React & Next.js, TypeScript, Web Performance, AI Integrations, Automation (n8n, Make). Open to full-time roles.\n\nCan Hendrix build or improve a WordPress or WooCommerce site?Yes. Hendrix's documented WordPress experience includes WordPress & WooCommerce Developer at HempHealthOnline (Mar 2026 – Present); Founder & Full-Stack Web Developer at CONEX.HUB (Jan 2022 – Present); Freelance WordPress Developer & Web Designer at Workana (Jul 2019 – Oct 2022). This covers WordPress and WooCommerce development, customization, maintenance, migration, and troubleshooting.\n\nCan Hendrix work on a full-stack product or web application?Yes. The documented stack includes React, Next.js, Astro, TypeScript, Tailwind CSS, HTML, CSS on the frontend and Node.js, PHP, Laravel, Supabase, MySQL, PostgreSQL, REST APIs on the backend. Relevant portfolio systems include Agent-Ready Portfolio and WOP - Web Operations Platform and Prompt Pocket and Jumbox and Web Ready.\n\nCan Hendrix integrate AI, automation, or third-party services?Yes. Hendrix works with Claude API, MCP, n8n, Make, AI Agents, Webhooks and has documented integrations with CRM, WhatsApp, payment gateways, analytics, and webhooks. Relevant portfolio systems include Agent-Ready Portfolio and Prompt Pocket and Web Ready.\n\nCan Hendrix help with performance, migrations, or production issues?Yes. Documented work includes performance optimization, Core Web Vitals, technical SEO, site replication, migration, deployment, and troubleshooting across plugins, themes, databases, URLs, and redirects.",
      "description": "Connect an AI agent to Hendrix Garcia",
      "keywords": [
        "hendrix",
        "wordpress",
        "contact",
        "developer",
        "endpoint",
        "agents",
        "portfolio",
        "woocommerce",
        "work",
        "this"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 3,
        "sourcePath": "/connect"
      }
    },
    {
      "id": "2a9d3de1604cf04f",
      "url": "https://hdrx.com.br/blog/woocommerce-performance-ttfb",
      "title": "WooCommerce TTFB Optimization: The Complete Guide to Sub-300ms Stores — Hendrix Garcia (Part 3)",
      "content": "For production, avoid running Query Monitor live; instead enable MySQL’s slow query log temporarily and correlate against WooCommerce’s REST API and storefront traffic.\n\n# my.cnf — temporary diagnostic window only\nslow_query_log = 1\nslow_query_log_file = /var/log/mysql/slow.log\nlong_query_time = 0.2\nlog_queries_not_using_indexes = 1\n\n## Pillar 1: Object Caching With Redis (Not Just Page Caching)\n\nPage caching and object caching solve different problems, and conflating them is the most common architectural mistake in WooCommerce performance work.\n\nLayer\n\nWhat it caches\n\nSolves\n\nDoesn’t solve\n\n**Page cache** (Varnish, FastCGI cache, edge CDN)\n\nFull rendered HTML response\n\nRepeated identical requests to static/catalog pages\n\nCart, checkout, logged-in, per-user content\n\n**Object cache** (Redis/Memcached)\n\nPHP objects, query results, transients\n\nRepeated expensive queries and computations *inside* a single or across multiple PHP requests\n\nNothing if the underlying query pattern is itself the bottleneck (bad indexes, N+1)\n\n**OPcache**\n\nCompiled PHP opcode\n\nRe-parsing/re-compiling PHP source on every request\n\nDatabase-bound work — this is CPU-bound relief, not I/O relief\n\n**CDN edge cache**\n\nStatic assets + cacheable dynamic HTML at PoPs close to the visitor\n\nNetwork latency, origin load for cacheable page types\n\nUncacheable pages (cart/checkout)\n\nBy default, WordPress’s object cache is **non-persistent**: it lives only for the duration of a single request and is thrown away. Every new request rebuilds the same option lookups, term queries, and meta lookups from scratch. In a store with concurrent traffic, this means MySQL sees the same wp_options and wp_postmeta reads thousands of times per minute with zero cross-request reuse.\n\n### What does a persistent object cache actually fix?",
      "description": "A deep technical guide to WooCommerce Time to First Byte: Redis object caching, HPOS, Action Scheduler bottlenecks, autoloaded options, PHP-FPM tuning, and edge caching for high-traffic stores.",
      "keywords": [
        "woocommerce",
        "cache",
        "redis",
        "object",
        "caching",
        "time",
        "this",
        "cart",
        "queries",
        "query"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/blog/woocommerce-performance-ttfb"
      }
    },
    {
      "id": "2d5b196207074c9c",
      "url": "https://hdrx.com.br/blog/mcp-stateless-edge-functions",
      "title": "Stateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation — Hendrix Garcia (Part 5)",
      "content": "This is the part the spec change doesn’t solve for you. Removing the handshake removes the place where a traditional server would have established an auth context and a session-scoped rate-limit bucket. A stateless MCP server has to re-derive both on every single request.\n\n### How do you authenticate a stateless MCP server without",
      "description": "A deep technical guide to building a stateless Model Context Protocol server on Vercel Edge Functions — JSON-RPC 2.0 design, the 2026-07-28 spec change, auth and rate limiting without sessions, and headless testing with curl.",
      "keywords": [
        "edge",
        "server",
        "tools",
        "that",
        "session",
        "request",
        "call",
        "stateless",
        "with",
        "node"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/blog/mcp-stateless-edge-functions"
      }
    },
    {
      "id": "32be29375edc185e",
      "url": "https://hdrx.com.br/projects/agent-ready-portfolio",
      "title": "Agent-Ready Portfolio — Case Study · Hendrix Garcia (Part 2)",
      "content": "- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "An agent-ready portfolio with MCP, llms.txt, and an interactive terminal for AI assistants.",
      "keywords": [
        "with",
        "projects",
        "portfolio",
        "human",
        "connect",
        "profile",
        "agent-ready",
        "https",
        "contact",
        "tools"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects/agent-ready-portfolio"
      }
    },
    {
      "id": "32d95a918e93f830",
      "url": "https://hdrx.com.br/pt-BR/projetos",
      "title": "Projetos — Hendrix Garcia (Part 1)",
      "content": "Portfólio de engenharia\n\n## Sistemas e produtosSistemas e produtos\n\nSistemas selecionados, produtos web e estudos de caso de engenharia de Hendrix Garcia.\n\nTodos os projetos(6)IA e agentes(3)Full-stack(6)WordPress e performance(1)\n\nmcp Em destaque\n\n### [Portfólio Preparado para Agentes](/pt-BR/projetos/agent-ready-portfolio)\n\nPortfólio pronto para agentes, com MCP, llms.txt e terminal interativo para assistentes de IA.\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n[Estudo de caso →](/pt-BR/projetos/agent-ready-portfolio)\n[Código-fonte ↗](#)[Em produção ↗](https://hdrx.com.br)\n\nfullstack Em destaque\n\n### [WOP - Plataforma de Operações Web](/pt-BR/projetos/wop)\n\nPlataforma operacional para agências: inventário, uptime, incidentes e manutenção de sites.\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n[Estudo de caso →](/pt-BR/projetos/wop)\n[Código-fonte ↗](#)\n\nai Em destaque\n\n### [Prompt Pocket](/pt-BR/projetos/prompt-pocket)\n\nExtensão Chrome privada para salvar, organizar e reutilizar prompts de IA entre ferramentas.\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n[Estudo de caso →](/pt-BR/projetos/prompt-pocket)\n[Código-fonte ↗](#)\n\nfullstack Em destaque\n\n### [Jumbox](/pt-BR/projetos/jumbox)\n\nSistema privado e local-first de transferência de arquivos, com streaming retomável e integridade ponta a ponta.",
      "description": "Um catálogo estruturado de software em produção, integrações de agentes de IA e infraestrutura de alta performance projetados para gerar impacto mensurável nos negócios.",
      "keywords": [
        "pt-br",
        "projetos",
        "typescript",
        "para",
        "github",
        "caso",
        "react",
        "tailwind",
        "https",
        "destaque"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/projetos"
      }
    },
    {
      "id": "34ff26fc4c54c41e",
      "url": "https://hdrx.com.br/connect",
      "title": "Connect — Hendrix Garcia (Part 1)",
      "content": "## This site speaks MCP.This site speaks MCP.\n\nYour AI agent can interview me, check my availability, browse my projects, read the manifesto, and find the human-confirmed contact path — all through a standard MCP endpoint.\n\n## Endpoint\n\nhttps://hdrx.com.br/api/mcpStreamable HTTP\n\n## Setup by Client\n\nClaude DesktopSettings → Connectors → Add custom connector → paste the endpoint URL.\n\nCursorMCP Settings → Add Streamable HTTP server → paste the endpoint URL.\n\nChatGPTSettings → Apps → Developer mode → add the endpoint URL.\n\nTerminal (curl)curl -s https://hdrx.com.br/api/resume | jq .\n\n## Available Tools\n\nget_resumeFull professional profile\n\nget_projectsPortfolio projects (filterable by tags, featured)\n\nget_capabilitiesTechnical skills and areas of expertise\n\ncheck_availabilityCurrent availability status\n\nget_manifestA hidden philosophical narrative on time, memory, and AI — optionally filtered by chapter\n\ncontactRead-only handoff to the human contact page or terminal\n\n## AGENTS.md\n\nCopy this snippet to your project's AGENTS.md to let your AI agent know how to reach Hendrix.\n\nCopy# AGENTS.md — Hendrix Garcia\n\nSenior Full-Stack Developer & Product Engineer | AI Agents · TypeScript · WordPress\nBrazil · Remote Worldwide\n\n## How to reach Hendrix\n\nContact submission requires an explicit human action. Direct the visitor to\n`https://hdrx.com.br/contact` or ask them to run `contact` in the website terminal.\n\n### MCP (recommended)\n\nEndpoint: `https://hdrx.com.br/api/mcp`\n\nTools:\n- `get_resume` — Full professional profile\n- `get_projects` — Portfolio projects (filterable)\n- `get_capabilities` — Technical skills and expertise\n- `check_availability` — Current availability status\n- `get_manifest` — Hidden philosophical narrative (optional chapter filter)\n- `contact` — Read-only handoff to the human contact surfaces; never sends a message\n\n## Core Skills",
      "description": "Connect an AI agent to Hendrix Garcia",
      "keywords": [
        "hendrix",
        "wordpress",
        "contact",
        "developer",
        "endpoint",
        "agents",
        "portfolio",
        "woocommerce",
        "work",
        "this"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 3,
        "sourcePath": "/connect"
      }
    },
    {
      "id": "3549f8614dc7b7d6",
      "url": "https://hdrx.com.br/pt-BR/blog/portfolios-prontos-para-agentes",
      "title": "Portfólios preparados para agentes: criando sites de desenvolvedores para MCP, LLMs e mecanismos de resposta — Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os artigos](/pt-BR/blog)**\n\n1 de agosto de 2026• 14 min de leitura\nAEOMCPProduct EngineeringStructured DataAstro\n\n## Portfólios preparados para agentes: criando sites de desenvolvedores para MCP, LLMs e mecanismos de resposta\n\nUm guia técnico para a arquitetura de portfólio em duas camadas: servidores MCP, llms.txt, agents.md e APIs estruturadas que tornam seu site legível para agentes de IA e mecanismos de resposta, e não apenas para visitantes humanos.\n\nUma parcela crescente do tráfego que chega aos portfólios de desenvolvedores não é de um recrutador rolando a página no celular — é de um agente. O Cursor consultando o site para verificar uma afirmação. Uma ferramenta de recrutamento usando Claude ou GPT-4 para classificar candidatos diante de uma descrição de vaga. O Perplexity ou o ChatGPT respondendo, em nome de uma pessoa, “quem é esta pessoa e o que ela construiu”, sem jamais renderizar seu CSS.\n\nA maioria dos portfólios é construída exclusivamente para o primeiro tipo de visitante. Este post cobre a arquitetura para o segundo — os mecanismos concretos (MCP, llms.txt, agents.md, JSON-LD, endpoints REST estruturados) que tornam um site legível para máquinas, por que cada um existe e onde os trade-offs realmente pesam.\n\n## Por que a legibilidade por agentes é um problema de engenharia distinto\n\nO SEO tradicional é otimizado para um crawler que busca HTML, extrai texto e links e o indexa para uma lista ranqueada de resultados que uma pessoa então acessa. O rastreamento agêntico** tem um modelo de consumo inteiramente diferente:\n\n- O agente frequentemente tem um **orçamento** — um número fixo de chamadas de ferramenta, tokens ou carregamentos de página antes de precisar produzir uma resposta. Uma estrutura de página ineficiente custa diretamente tempo ao agente (e à pessoa esperando por ele).",
      "description": "Um guia técnico para a arquitetura de portfólio em duas camadas: servidores MCP, llms.txt, agents.md e APIs estruturadas que tornam seu site legível para agentes de IA e mecanismos de resposta, e não apenas para visitantes humanos.",
      "keywords": [
        "para",
        "não",
        "agentes",
        "agente",
        "site",
        "llms",
        "agents",
        "como",
        "resposta",
        "ferramentas"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/portfolios-prontos-para-agentes"
      }
    },
    {
      "id": "39ddd82cb370aa7e",
      "url": "https://hdrx.com.br",
      "title": "Hendrix Garcia — Full-Stack Product Engineer (Part 2)",
      "content": "- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n[View project](/projects/prompt-pocket)\n\n### Jumbox\n\nPrivate, local-first file transfer system with resumable streaming and end-to-end integrity.\n\n- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n[View project](/projects/jumbox)\n\n### AstroPress\n\nPerformance-first WordPress headless starter for Astro 5 — zero client-side JavaScript by default.\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n[View project](/projects/astropress)\n\n### Web Ready\n\nAn open-source website auditor for Technical SEO, AI readiness, and fundamental web health.\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n[View project](/projects/web-ready)\n\n## Frequently Asked Questions\n\nWhat kinds of work can I hire Hendrix for?Hendrix is open to full-time and contract work as a Full-Stack Developer, Product Engineer, WordPress Developer. Current specialties include WordPress & WooCommerce, React & Next.js, TypeScript, Web Performance, AI Integrations, Automation (n8n, Make). Open to full-time roles.",
      "description": "Full-Stack Product Engineer building fast, reliable web products and AI-enabled systems.",
      "keywords": [
        "wordpress",
        "typescript",
        "hendrix",
        "projects",
        "react",
        "developer",
        "work",
        "with",
        "connect",
        "tailwind"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 4,
        "sourcePath": "/"
      }
    },
    {
      "id": "3bad9e0c71093495",
      "url": "https://hdrx.com.br/pt-BR/projetos/jumbox",
      "title": "Jumbox — Estudo de caso · Hendrix Garcia (Part 2)",
      "content": "HDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Sistema privado e local-first de transferência de arquivos, com streaming retomável e integridade ponta a ponta.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "arquivos",
        "sistema",
        "transferência",
        "ponta",
        "github",
        "rede",
        "conectar"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/jumbox"
      }
    },
    {
      "id": "3ea4bea69e0fb197",
      "url": "https://hdrx.com.br/pt-BR/conectar",
      "title": "Conectar via MCP — Hendrix Garcia (Part 1)",
      "content": "## Este site fala MCP.Este site fala MCP.\n\nSeu agente de IA pode me entrevistar, verificar minha disponibilidade, explorar meus projetos, ler o manifesto e encontrar o caminho de contato confirmado por uma pessoa — tudo por um endpoint MCP padrão.\n\n## Endpoint\n\nhttps://hdrx.com.br/api/mcpStreamable HTTP\n\n## Configuração por cliente\n\nClaude DesktopConfigurações → Conectores → Adicionar conector personalizado → cole a URL do endpoint.\n\nCursorConfigurações de MCP → Adicionar servidor Streamable HTTP → cole a URL do endpoint.\n\nChatGPTConfigurações → Apps → Modo desenvolvedor → adicione a URL do endpoint.\n\nTerminal (curl)curl -s https://hdrx.com.br/api/resume | jq .\n\n## Ferramentas disponíveis\n\nget_resumePerfil profissional completo\n\nget_projectsProjetos do portfólio (filtráveis por tags e destaque)\n\nget_capabilitiesCompetências técnicas e áreas de especialidade\n\ncheck_availabilityStatus atual de disponibilidade\n\nget_manifestUma narrativa filosófica oculta sobre tempo, memória e IA — opcionalmente filtrada por capítulo\n\ncontactEncaminhamento somente leitura para a página de contato humana ou terminal\n\n## AGENTS.md\n\nCopie este trecho para o AGENTS.md do seu projeto para que seu agente de IA saiba como falar com Hendrix.\n\nCopiar# AGENTS.md — Hendrix Garcia\n\nSenior Full-Stack Developer & Product Engineer | AI Agents · TypeScript · WordPress\nBrazil · Remote Worldwide\n\n## How to reach Hendrix\n\nContact submission requires an explicit human action. Direct the visitor to\n`https://hdrx.com.br/contact` or ask them to run `contact` in the website terminal.\n\n### MCP (recommended)\n\nEndpoint: `https://hdrx.com.br/api/mcp`\n\nTools:\n- `get_resume` — Full professional profile\n- `get_projects` — Portfolio projects (filterable)\n- `get_capabilities` — Technical skills and expertise\n- `check_availability` — Current availability status\n- `get_manifest` — Hidden philosophical narrative (optional chapter filter)\n- `contact` — Read-only handoff to the human contact surfaces; never sends a message",
      "description": "Conecte um agente de IA ao portfólio de Hendrix Garcia por MCP e APIs estruturadas.",
      "keywords": [
        "hendrix",
        "wordpress",
        "endpoint",
        "desenvolvedor",
        "para",
        "portfólio",
        "agents",
        "contact",
        "woocommerce",
        "pode"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/conectar"
      }
    },
    {
      "id": "3f4b1f5884b9f0ae",
      "url": "https://hdrx.com.br/pt-BR/blog/engenharia-de-prompts-como-codigo",
      "title": "Engenharia de prompts como código: versionamento, testes e CI/CD para prompts de LLMs — Hendrix Garcia (Part 2)",
      "content": "- **Quebra de schema sem stack trace** — o modelo devolve prosa em vez de JSON, omite campo obrigatório ou alucina um valor de enum fora do conjunto permitido. Sem validação em runtime, isso falha silenciosamente downstream ou quebra profundamente na lógica de negócio, longe da causa real.\n\n- **Regressões na troca de modelo** — atualizar uma versão de modelo ou trocar de provedor muda hábitos de formatação, verbosidade ou fidelidade a instruções de modos que QA manual não detecta antes de um cliente reclamar.\n\n- **Ausência de controle de blast radius** — uma mudança ruim no prompt chega direto a 100% do tráfego porque não existe gate de staging, suíte de eval ou caminho de rollback separado de um deploy completo.\n\nPrompt-as-code fecha essas lacunas com os mesmos guardrails usados para código de aplicação: controle de versão, contratos tipados, testes automatizados de regressão e rollout em estágios.\n\n### Prompt-as-Code vs. prompting ad hoc: comparação direta\n\nDimensão\n\nPrompting ad hoc\n\nPrompt-as-code (PEaC)\n\nArmazenamento\n\nStrings inline, UI de dashboard, .env\n\nArquivos versionados em git, revisados via PR\n\nRastreamento de mudança\n\nNenhum, ou mensagem informal no Slack\n\nDiff git + incremento de versão semântica\n\nContrato de saída\n\nImplícito, parseado com regex/esperança\n\nSchema explícito (Zod/Pydantic/JSON Schema), validado em runtime\n\nDetecção de regressão\n\nChecagem manual pontual, se houver\n\nSuíte de eval automatizada no CI contra dataset golden\n\nRollback\n\nRedeploy da versão anterior do app\n\nApontar para versão anterior do prompt, sem deploy do app\n\nAtualização de modelos\n\n“Teste e veja”\n\nSuíte de eval reexecutada contra novo modelo, comparada ao baseline\n\nEntrada adversarial\n\nDescoberta em produção\n\nTestada contra conjunto adversarial/red-team antes do merge\n\nResponsabilidade\n\nQuem editou por último o dashboard\n\nCode owners via CODEOWNERS, revisão de PR obrigatória\n\n## Princípio central 1: schemas estritos para saída estruturada",
      "description": "Um framework prático para tratar prompts como artefatos de software — versionamento semântico, saída estruturada validada por Zod, suítes de eval de regressão e gates de CI/CD, a partir da arquitetura do Prompt Pocket.",
      "keywords": [
        "prompt",
        "não",
        "para",
        "saída",
        "modelo",
        "schema",
        "como",
        "validação",
        "json",
        "versão"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/engenharia-de-prompts-como-codigo"
      }
    },
    {
      "id": "3fe6cb117fc0a132",
      "url": "https://hdrx.com.br/pt-BR/projetos/astropress",
      "title": "AstroPress — Estudo de caso · Hendrix Garcia (Part 2)",
      "content": "O AstroPress desacopla o WordPress como um backend editorial puro (Gutenberg, taxonomias, biblioteca de mídia) de uma camada Astro 5 que consulta a REST API do WordPress inteiramente em tempo de build e compila HTML/CSS estáticos para o edge, enviando 0 KB de JavaScript no cliente por padrão. Uma camada de normalização isola os payloads da REST API do WordPress do resto do código, uma cascata de SEO em 4 níveis (Yoast SEO, Rank Math, campos nativos do WP e por fim os padrões do site) alimenta grafos JSON-LD de Schema.org, e um pipeline de imagens via astro:assets compila mídia remota do WordPress em WebP/AVIF responsivos com dimensões explícitas para manter o layout shift em zero. Um plugin conector para WordPress habilita preview de rascunho em tempo real por meio de uma rota SSR sob demanda com handshake tokenizado, sem exigir rebuild completo, e um diagnóstico 'Headless Doctor' de 7 categorias (CLI e dashboard em /doctor) verifica ambiente, conectividade, endpoints REST, permalinks, o plugin conector, SEO e o preview de rascunho de ponta a ponta. Distribuído como uma stack Docker Compose completa, pré-carregada com WordPress, MySQL e conteúdo de demonstração, com orçamentos de performance aplicados no CI.\n\n[03] Stack de tecnologia e utilitários\n\nAstro 5TypeScriptWordPress REST APIPHPDocker ComposeVitest\n\n[← Sistema anteriorJumbox](/pt-BR/projetos/jumbox)[Próximo sistema →Web Ready](/pt-BR/projetos/web-ready)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links",
      "description": "Starter headless de WordPress com Astro 5 focado em performance — zero JavaScript no cliente por padrão.",
      "keywords": [
        "pt-br",
        "wordpress",
        "para",
        "projetos",
        "astro",
        "github",
        "rest",
        "conectar",
        "perfil",
        "sistema"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/projetos/astropress"
      }
    },
    {
      "id": "401a92f5b04bd7de",
      "url": "https://hdrx.com.br/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce",
      "title": "Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms — Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os artigos](/pt-BR/blog)**\n\n8 de agosto de 2026• 17 min de leitura\nWordPressWooCommercePerformanceTTFBRedisPHP-FPMCore Web Vitals\n\n## Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms\n\nUm guia técnico aprofundado para Time to First Byte no WooCommerce: cache de objetos Redis, HPOS, gargalos do Action Scheduler, opções autocarregadas, ajuste de PHP-FPM e cache edge para lojas de alto tráfego.\n\nLojas WooCommerce perdem conversões durante picos de tráfego — Black Friday, produto viral, campanha paga chegando de uma vez — e, na maioria das auditorias que faço, o ponto de falha não é o bundle de frontend nem o peso das imagens. Ele está no servidor: Time to First Byte (TTFB)** alto, provocado por execução PHP síncrona, idas não cacheadas ao banco e lógica de carrinho/sessão que o WordPress nunca foi arquitetado para atender em escala.\n\nTTFB é o tempo entre a requisição do navegador e a chegada do primeiro byte da resposta. Numa página WooCommerce, PHP-FPM aceita a requisição, WordPress inicializa, plugins se conectam a init e wp_loaded, WooCommerce resolve sessão e carrinho, consultas dinâmicas (estoque, regras de preço, zonas de entrega) chegam ao MySQL e só então o servidor começa a transmitir HTML. Cada passo pode conter full-table scan, cache miss ou chamada externa bloqueante. Este guia cobre os mecanismos por trás de cada gargalo e correções concretas, da mais barata à mais invasiva.\n\n## Por que o TTFB do WooCommerce é estruturalmente diferente do TTFB do WordPress\n\nUm post estático de blog pode ser servido inteiro do page cache — Varnish, cache FastCGI do Nginx ou um nó edge de CDN devolvem HTML sem tocar PHP ou MySQL. O WooCommerce quebra esse modelo, por desenho, em três tipos de página:\n\n- Páginas de **carrinho e checkout** precisam refletir estado em tempo real (itens, frete, validade de cupom), portanto cache de página inteiro é inseguro por padrão.",
      "description": "Um guia técnico aprofundado para Time to First Byte no WooCommerce: cache de objetos Redis, HPOS, gargalos do Action Scheduler, opções autocarregadas, ajuste de PHP-FPM e cache edge para lojas de alto tráfego.",
      "keywords": [
        "cache",
        "não",
        "woocommerce",
        "redis",
        "para",
        "ttfb",
        "object",
        "query",
        "time",
        "páginas"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce"
      }
    },
    {
      "id": "4173a9db90f151e4",
      "url": "https://hdrx.com.br/pt-BR/blog/astropress-wordpress-headless-com-astro",
      "title": "AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente — Hendrix Garcia (Part 5)",
      "content": "O AstroPress declara orçamentos de performance num arquivo budget.json e os aplica via npm run audit:perf no CI — segundo o README, bloqueando inchaço de CSS acima de aproximadamente 25 KB e qualquer JavaScript de cliente acidental em páginas editoriais. A distinção que importa aqui: um orçamento de performance que existe só como afirmação num README não é um orçamento de performance, é uma esperança. Aplicá-lo como um gate de CI significa que um pull request que regride o payload de CSS ou hidrata acidentalmente um componente que deveria ser estático de fato falha o build, em vez de ser publicado e só ser pego (ou não) depois, por quem eventualmente rodar o Lighthouse manualmente.\n\nA suíte de testes do projeto reforça isso com mais de 130 testes via Vitest, segundo a tabela de referência de CLI do README, cobrindo a lógica de normalização de conteúdo e da cascata de",
      "description": "Como o AstroPress desacopla o WordPress como backend editorial puro de um frontend estático em Astro — a camada de conteúdo, a cascata de SEO em 4 níveis, preview de rascunho em tempo real e os orçamentos de performance aplicados em CI.",
      "keywords": [
        "wordpress",
        "para",
        "não",
        "conteúdo",
        "astropress",
        "como",
        "plugin",
        "astro",
        "preview",
        "performance"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/astropress-wordpress-headless-com-astro"
      }
    },
    {
      "id": "42e9607818fba970",
      "url": "https://hdrx.com.br/pt-BR/blog",
      "title": "Blog e artigos — Hendrix Garcia (Part 1)",
      "content": "Textos técnicos\n\n## Artigos e notasArtigos e notas\n\nAnálises sobre engenharia de agentes, Model Context Protocol, performance em WordPress e arquitetura full-stack escalável.\n\n[24 de ago. de 2026 • 12 min de leitura Astro WordPress Headless CMS Open Source Performance AstroPress: Um Starter WordP](/pt-BR/blog/astropress-wordpress-headless-com-astro)\n\n[24 de ago. de 2026 • 8 min de leitura Criação de Sites Landing Page Sites para Empresas SEO Criação de Sites Profissiona](/pt-BR/blog/criacao-de-sites-profissionais)\n\n[10 de ago. de 2026 • 14 min de leitura AI MCP Architecture Edge Functions Serverless JSON-RPC MCP stateless em funções e](/pt-BR/blog/mcp-stateless-em-funcoes-edge)\n\n[8 de ago. de 2026 • 17 min de leitura WordPress WooCommerce Performance TTFB Redis PHP-FPM Core Web Vitals Otimização de](/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce)\n\n[5 de ago. de 2026 • 16 min de leitura AI Prompt Engineering LLM TypeScript Next.js CI/CD Eval Engenharia de prompts como](/pt-BR/blog/engenharia-de-prompts-como-codigo)\n\n[1 de ago. de 2026 • 14 min de leitura AEO MCP Product Engineering Structured Data Astro Portfólios preparados para agent](/pt-BR/blog/portfolios-prontos-para-agentes)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.",
      "description": "Textos sobre engenharia de agentes, performance web e desenvolvimento de produtos.",
      "keywords": [
        "pt-br",
        "2026",
        "blog",
        "leitura",
        "para",
        "conectar",
        "perfil",
        "performance",
        "wordpress",
        "astro"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/blog"
      }
    },
    {
      "id": "45868487e98b5e9a",
      "url": "https://hdrx.com.br/pt-BR/blog/mcp-stateless-em-funcoes-edge",
      "title": "MCP stateless em funções edge: arquitetura, trade-offs e implementação — Hendrix Garcia (Part 4)",
      "content": "Maior — processo Node.js completo + inicialização do grafo de módulos\n\nAPIs disponíveis\n\nApenas padrões web (fetch, Request, Response, Web Crypto) — sem fs, módulos Node nativos\n\nSuperfície completa da API Node.js, incluindo fs, addons nativos e a maioria dos pacotes npm\n\nLimites de execução\n\nCurtos, teto rígido (dependente da plataforma, em geral dezenas de segundos)\n\nTetos maiores, configuráveis por plano\n\nMemória\n\nRestrita, orçamento compartilhado do isolate\n\nMaior, memória dedicada por invocação\n\nDistribuição geográfica\n\nExecuta por padrão em PoPs próximos de quem solicita\n\nExecuta numa região fixa, salvo configuração multi-região\n\nAcesso TCP/raw socket\n\nIndisponível\n\nDisponível — necessário para alguns drivers de DB, SMTP raw etc.\n\nCompatibilidade npm\n\nParcial — pacotes que dependem de built-ins Node falham no build ou runtime\n\nCompleta\n\nMelhor encaixe para MCP\n\nFerramentas stateless, intensivas em leitura, com dependências apenas HTTP (fetch para Resend, API REST, módulo de dados estático)\n\nFerramentas que precisam de driver de DB nativo, sistema de arquivos ou computação longa\n\nA implicação concreta para um servidor MCP: **todo handler de ferramenta deve ser alcançável por I/O compatível com fetch.** Para a implementação deste portfólio, isso é trivial — a fonte de dados é um conjunto de módulos TypeScript empacotados com a função (src/data/*.ts), e a única chamada de rede (contact, via Resend) é um POST HTTP comum. Se uma ferramenta precisasse de conexão PostgreSQL direta por TCP ou uma biblioteca de geração de PDF exclusiva de Node, ela precisaria rodar no runtime Node.js — Edge não é substituto universal; é a ferramenta certa para um perfil de I/O específico.",
      "description": "Um guia técnico aprofundado para construir um servidor Model Context Protocol stateless em Vercel Edge Functions — desenho JSON-RPC 2.0, a mudança do spec 2026-07-28, autenticação e rate limiting sem sessões e testes headless com curl.",
      "keywords": [
        "para",
        "edge",
        "não",
        "sessão",
        "tools",
        "servidor",
        "node",
        "stateless",
        "requisição",
        "call"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/mcp-stateless-em-funcoes-edge"
      }
    },
    {
      "id": "45a8e152d7aaf92f",
      "url": "https://hdrx.com.br",
      "title": "Hendrix Garcia — Full-Stack Product Engineer (Part 4)",
      "content": "HDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Full-Stack Product Engineer building fast, reliable web products and AI-enabled systems.",
      "keywords": [
        "wordpress",
        "typescript",
        "hendrix",
        "projects",
        "react",
        "developer",
        "work",
        "with",
        "connect",
        "tailwind"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 4,
        "sourcePath": "/"
      }
    },
    {
      "id": "45be9b60b0831460",
      "url": "https://hdrx.com.br/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce",
      "title": "Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms — Hendrix Garcia (Part 5)",
      "content": "Por padrão, WooCommerce guarda sessões de clientes em wp_woocommerce_sessions, uma tabela de banco, não no object cache. Com atividade concorrente de carrinho, ela recebe escritas constantes — cada mutação atualiza sessão — e é fonte comum de contenção de escrita que o object cache Redis sozinho não resolve, porque sessões ignoram o caminho do cache salvo configuração explícita. Se a implementação de WC_Session_Handler do host suportar, direcione sessões diretamente ao Redis e audite woocommerce_cookie_expiration e intervalos de cron de limpeza, evitando o acúmulo de sessões obsoletas.\n\n## Pilar 2: arquitetura de banco — índices, queries",
      "description": "Um guia técnico aprofundado para Time to First Byte no WooCommerce: cache de objetos Redis, HPOS, gargalos do Action Scheduler, opções autocarregadas, ajuste de PHP-FPM e cache edge para lojas de alto tráfego.",
      "keywords": [
        "cache",
        "não",
        "woocommerce",
        "redis",
        "para",
        "ttfb",
        "object",
        "query",
        "time",
        "páginas"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce"
      }
    },
    {
      "id": "47848c35862f1c07",
      "url": "https://hdrx.com.br/pt-BR/blog/portfolios-prontos-para-agentes",
      "title": "Portfólios preparados para agentes: criando sites de desenvolvedores para MCP, LLMs e mecanismos de resposta — Hendrix Garcia (Part 4)",
      "content": "### O que o llms.txt realmente faz?\n\nllms.txt é uma convenção proposta — não um padrão W3C ou IETF e não universalmente respeitada — para um arquivo Markdown simples na raiz do site que dá a um LLM um resumo curado e de alto sinal do site: o que ele é, as páginas principais e links para mais detalhes. É o análogo legível por máquina de um sitemap, mas escrito como prosa/Markdown para um modelo consumir diretamente, em vez de XML para um crawler enumerar.\n\nSua utilidade real hoje é mista, e vale ser honesto sobre isso:\n\nAspecto\n\nRealidade\n\nAdoção por grandes produtos de IA\n\nInconsistente — alguns crawlers o buscam; a maior parte dos mecanismos gerais de busca/resposta ainda não o prioriza como robots.txt ou sitemaps\n\nCusto de implementação\n\nQuase zero — um arquivo Markdown estático\n\nModo de falha se estiver incorreto\n\nSilencioso — nenhum consumidor impõe schema, então um arquivo desatualizado apenas engana discretamente o agente que o ler\n\nMelhor caso de uso atual\n\nFerramentas de agentes que o verificam explicitamente (agentes de código, clientes MCP, integrações de ferramentas de desenvolvimento), e não a busca de IA voltada ao consumidor\n\nDado o baixo custo e a opcionalidade, vale publicar — mas não o trate como canal de descoberta garantido. É uma proteção, não infraestrutura.\n\n### agents.md — o README voltado para máquinas\n\nagents.md (também visto como AGENTS.md) tem melhor adesão no mundo real porque agentes de programação (Claude Code, Cursor, Copilot Workspace etc.) procuram ativamente por ele como arquivo de instruções ao operar em um repositório ou projeto. Em um portfólio, seu papel é mais estreito que o da convenção no repositório: documentar **como um agente deve interagir com a camada de agentes do site** — URL do endpoint MCP, nomes das ferramentas e schemas de entrada, limites de taxa e operações com efeitos colaterais que exigem cuidado.\n\nConteúdo prático que vale incluir:\n\n- O endpoint de transporte MCP e a versão do protocolo.",
      "description": "Um guia técnico para a arquitetura de portfólio em duas camadas: servidores MCP, llms.txt, agents.md e APIs estruturadas que tornam seu site legível para agentes de IA e mecanismos de resposta, e não apenas para visitantes humanos.",
      "keywords": [
        "para",
        "não",
        "agentes",
        "agente",
        "site",
        "llms",
        "agents",
        "como",
        "resposta",
        "ferramentas"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/portfolios-prontos-para-agentes"
      }
    },
    {
      "id": "4b02d85c1a945945",
      "url": "https://hdrx.com.br/blog/mcp-stateless-edge-functions",
      "title": "Stateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation — Hendrix Garcia (Part 3)",
      "content": "- **Protocol negotiation moves into headers, not session state.** Version and method routing information travels on every request instead of being negotiated once and remembered:\n\nMcp-Protocol-Version — e.g. 2026-07-28\n\n- Mcp-Method — e.g. tools/call or tools/list\n\n- Mcp-Name — the tool name, when the method is an execution call\n\nThe result is that **every request is independently interpretable.** A load balancer, edge cache, or WAF can inspect a single request and know exactly what it’s looking at without correlating it to prior traffic. That property — not just “no handshake” — is the actual architectural win, because it’s what makes the protocol compatible with stateless horizontal scaling.\n\nPOST /api/mcp HTTP/1.1\nHost: hdrx.com.br\nContent-Type: application/json\nMcp-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: check_availability\n\n{\n\"jsonrpc\": \"2.0\",\n\"id\": \"req-001\",\n\"method\": \"tools/call\",\n\"params\": {\n\"name\": \"check_availability\",\n\"arguments\": {}\n}\n}\nA conformant response for a read-only tool call:\n\n{\n\"jsonrpc\": \"2.0\",\n\"id\": \"req-001\",\n\"result\": {\n\"content\": [{\n\"type\": \"text\",\n\"text\": \"{\\\"status\\\":\\\"open\\\",\\\"label\\\":\\\"Open to full-time roles\\\"}\"\n}],\n\"isError\": false\n}\n}\n\n## Edge Runtime vs. Node.js Runtime: What Actually Constrains an MCP Server\n\nChoosing Edge over a traditional Node.js serverless function is not free. The stateless MCP model happens to fit the edge runtime’s constraints well, but you need to know exactly what those constraints are before you commit an MCP implementation to it.\n\nConstraint\n\nEdge Runtime (V8 isolate)\n\nNode.js Serverless Function\n\nCold start\n\nLow, typically sub-second — no container boot\n\nHigher — full Node.js process + module graph init\n\nAvailable APIs\n\nWeb-standard only (fetch, Request, Response, Web Crypto) — no fs, no native Node modules\n\nFull Node.js API surface, including fs, native addons, most npm packages\n\nExecution time limits\n\nShort, hard ceiling (platform-dependent, typically tens of seconds)",
      "description": "A deep technical guide to building a stateless Model Context Protocol server on Vercel Edge Functions — JSON-RPC 2.0 design, the 2026-07-28 spec change, auth and rate limiting without sessions, and headless testing with curl.",
      "keywords": [
        "edge",
        "server",
        "tools",
        "that",
        "session",
        "request",
        "call",
        "stateless",
        "with",
        "node"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/blog/mcp-stateless-edge-functions"
      }
    },
    {
      "id": "4b42054159c22b28",
      "url": "https://hdrx.com.br/projects/prompt-pocket",
      "title": "Prompt Pocket — Case Study · Hendrix Garcia (Part 2)",
      "content": "HDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Privacy-first Chrome extension to save, organize, and instantly reuse AI prompts across tools.",
      "keywords": [
        "projects",
        "prompt",
        "chrome",
        "extension",
        "server",
        "with",
        "connect",
        "profile",
        "prompts",
        "across"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects/prompt-pocket"
      }
    },
    {
      "id": "4bcf1bacf9b05e47",
      "url": "https://hdrx.com.br/pt-BR/sobre",
      "title": "Sobre Hendrix Garcia (Part 1)",
      "content": "Perfil de engenharia\n\n## Sobre e experiênciaSobre e experiência\n\nDesenvolvedor full-stack com mais de 7 anos construindo para a web, combinando trabalho freelancer pela Workana com a fundação da CONEX.HUB em 2022. Especialista em WordPress/WooCommerce em ambientes de produção — desenvolvimento, migração, performance e resolução de problemas — com apoio de uma stack moderna (TypeScript, React, Next.js, Supabase, Astro, Laravel). Combina execução técnica com pensamento de produto e automação, entendendo o problema de negócio antes de propor uma solução técnica.\n\n[01]\n\n## Trajetória profissional e entregas\n\n### Desenvolvedor WordPress e WooCommerce @ HempHealthOnline\n\nmar. de 2026 – Presente\n\n- ▸Manutenção contínua de múltiplos sites WordPress em produção\n- ▸Customização com Elementor, PHP, JavaScript, HTML e CSS\n- ▸Administração de múltiplos ambientes WordPress em infraestrutura Docker\n- ▸Replicação, migração e deploy de sites em diferentes servidores\n- ▸Resolução de problemas em plugins, temas, bancos de dados, URLs e redirecionamentos\n- ▸Otimização de performance, Core Web Vitals e SEO técnico\n- ▸Controle de versão com Git e documentação técnica\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- JavaScript\n- HTML\n- CSS\n- MySQL\n- Docker\n- Git\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- JavaScript\n- HTML\n- CSS\n- MySQL\n- Docker\n- Git\n\n### Fundador e Desenvolvedor Web Full-Stack @ CONEX.HUB\n\njan. de 2022 – Presente",
      "description": "Trajetória profissional, capacidades técnicas e abordagem de engenharia de produto.",
      "keywords": [
        "wordpress",
        "woocommerce",
        "pt-br",
        "react",
        "javascript",
        "laravel",
        "elementor",
        "rest",
        "para",
        "desenvolvimento"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/sobre"
      }
    },
    {
      "id": "50264ef9001175ef",
      "url": "https://hdrx.com.br/pt-BR/projetos/astropress",
      "title": "AstroPress — Estudo de caso · Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os projetos](/pt-BR/projetos)\n\n// wordpress Sistema em destaque\n\n## AstroPress\n\nStarter headless de WordPress com Astro 5 focado em performance — zero JavaScript no cliente por padrão.\n\n[Código-fonte ↗](https://github.com/hd-rx8/AstroPress)[Falar sobre projeto semelhante](/pt-BR/contato)\n\n[01] Declaração do problema e contexto\n\n## O desafio\n\nAcoplar a renderização PHP do próprio WordPress ao frontend significa que cada requisição de visitante reexecuta templating do Gutenberg e consultas ao banco, e mesmo um setup headless normalmente ainda envia um bundle de framework no cliente para o que, na prática, é conteúdo editorial estático — deixando performance na mesa para um caso de uso que não tem a interatividade que justificaria isso.\n\n[02] Arquitetura técnica e solução\n\n## Entrega de engenharia",
      "description": "Starter headless de WordPress com Astro 5 focado em performance — zero JavaScript no cliente por padrão.",
      "keywords": [
        "pt-br",
        "wordpress",
        "para",
        "projetos",
        "astro",
        "github",
        "rest",
        "conectar",
        "perfil",
        "sistema"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/projetos/astropress"
      }
    },
    {
      "id": "50dfce255b1b145f",
      "url": "https://hdrx.com.br/pt-BR/blog/mcp-stateless-em-funcoes-edge",
      "title": "MCP stateless em funções edge: arquitetura, trade-offs e implementação — Hendrix Garcia (Part 3)",
      "content": "- **server/discover como rota direta de capacidades.** Em vez de exigir uma sessão para conhecer capabilities, identidade do servidor e versão de protocolo, clientes podem chamar server/discover diretamente e obter uma resposta completa e cacheável em uma ida e volta.\n\n- **A negociação de protocolo vai para headers, não para estado de sessão.** Informações de versão e roteamento de método viajam em cada requisição, em vez de serem negociadas uma vez e lembradas:\n\nMcp-Protocol-Version — por exemplo, 2026-07-28\n\n- Mcp-Method — por exemplo, tools/call ou tools/list\n\n- Mcp-Name — o nome da ferramenta quando o método é uma chamada de execução\n\nO resultado é que **toda requisição é interpretável independentemente.** Um load balancer, cache edge ou WAF pode inspecionar uma única requisição e saber exatamente o que está vendo sem correlacioná-la ao tráfego anterior. Essa propriedade — não apenas “sem handshake” — é o ganho arquitetural real, pois torna o protocolo compatível com escala horizontal stateless.\n\nPOST /api/mcp HTTP/1.1\nHost: hdrx.com.br\nContent-Type: application/json\nMcp-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: check_availability\n\n{\n\"jsonrpc\": \"2.0\",\n\"id\": \"req-001\",\n\"method\": \"tools/call\",\n\"params\": {\n\"name\": \"check_availability\",\n\"arguments\": {}\n}\n}\nUma resposta compatível para uma chamada de ferramenta somente leitura:\n\n{\n\"jsonrpc\": \"2.0\",\n\"id\": \"req-001\",\n\"result\": {\n\"content\": [{\n\"type\": \"text\",\n\"text\": \"{\\\"status\\\":\\\"open\\\",\\\"label\\\":\\\"Open to full-time roles\\\"}\"\n}],\n\"isError\": false\n}\n}\n\n## Runtime Edge vs. runtime Node.js: o que de fato limita um servidor MCP\n\nEscolher Edge em vez de uma função serverless tradicional de Node.js não é gratuito. O modelo MCP stateless se ajusta bem às restrições do runtime edge, mas você precisa conhecê-las antes de comprometer uma implementação MCP com ele.\n\nRestrição\n\nRuntime Edge (V8 isolate)\n\nFunção serverless Node.js\n\nCold start\n\nBaixo, em geral abaixo de um segundo — sem boot de container",
      "description": "Um guia técnico aprofundado para construir um servidor Model Context Protocol stateless em Vercel Edge Functions — desenho JSON-RPC 2.0, a mudança do spec 2026-07-28, autenticação e rate limiting sem sessões e testes headless com curl.",
      "keywords": [
        "para",
        "edge",
        "não",
        "sessão",
        "tools",
        "servidor",
        "node",
        "stateless",
        "requisição",
        "call"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/mcp-stateless-em-funcoes-edge"
      }
    },
    {
      "id": "516a7761e6ab8e63",
      "url": "https://hdrx.com.br/projects/astropress",
      "title": "AstroPress — Case Study · Hendrix Garcia (Part 2)",
      "content": "[← Previous SystemJumbox](/projects/jumbox)[Next System →Web Ready](/projects/web-ready)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Performance-first WordPress headless starter for Astro 5 — zero client-side JavaScript by default.",
      "keywords": [
        "wordpress",
        "projects",
        "astro",
        "rest",
        "github",
        "with",
        "connect",
        "profile",
        "astropress",
        "headless"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects/astropress"
      }
    },
    {
      "id": "51b915f957e3f1f3",
      "url": "https://hdrx.com.br/pt-BR/blog/mcp-stateless-em-funcoes-edge",
      "title": "MCP stateless em funções edge: arquitetura, trade-offs e implementação — Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os artigos](/pt-BR/blog)**\n\n10 de agosto de 2026• 14 min de leitura\nAIMCPArchitectureEdge FunctionsServerlessJSON-RPC\n\n## MCP stateless em funções edge: arquitetura, trade-offs e implementação\n\nUm guia técnico aprofundado para construir um servidor Model Context Protocol stateless em Vercel Edge Functions — desenho JSON-RPC 2.0, a mudança do spec 2026-07-28, autenticação e rate limiting sem sessões e testes headless com curl.\n\nO Model Context Protocol (MCP)** foi concebido em torno de um modelo de sessão herdado de ferramentas locais baseadas em stdio: um cliente inicia um processo, faz um handshake initialize, recebe o reconhecimento notifications/initialized e mantém esse processo — e seu estado em memória — ativo durante toda a conversa. Esse modelo se encaixa bem em um app desktop falando com um subprocesso. Ele se encaixa mal em uma Vercel Edge Function que pode executar em um isolate diferente a cada requisição.\n\nA revisão 2026-07-28 do spec MCP formalizou um **transporte HTTP stateless** que remove o handshake como pré-requisito obrigatório e permite a um servidor responder a tools/call e tools/list como pares puros, autossuficientes de requisição/resposta. Este post cobre o que mudou, por que o desenho anterior orientado a sessão era ativamente hostil a runtimes edge e como implementar um servidor MCP stateless compatível em Vercel Edge Functions — incluindo as partes que a maioria dos textos omite: autenticação sem estado de sessão no servidor, rate limiting na edge, convenções de códigos de erro JSON-RPC e testes headless com curl.\n\nEste portfólio executa exatamente essa arquitetura em produção em /api/mcp — uma única Edge Function que trata get_resume, get_projects, get_capabilities, check_availability, get_manifest e a única ferramenta com efeito colateral, contact.\n\n## Por que sessões no estilo stdio não se encaixam em serverless",
      "description": "Um guia técnico aprofundado para construir um servidor Model Context Protocol stateless em Vercel Edge Functions — desenho JSON-RPC 2.0, a mudança do spec 2026-07-28, autenticação e rate limiting sem sessões e testes headless com curl.",
      "keywords": [
        "para",
        "edge",
        "não",
        "sessão",
        "tools",
        "servidor",
        "node",
        "stateless",
        "requisição",
        "call"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/mcp-stateless-em-funcoes-edge"
      }
    },
    {
      "id": "541f0be1fed04503",
      "url": "https://hdrx.com.br/blog/agent-ready-portfolios",
      "title": "Agent-Ready Portfolios: Building Developer Sites for MCP, LLMs, and Answer Engines — Hendrix Garcia (Part 2)",
      "content": "- Some agents **execute JavaScript and render the DOM** (browser-use style agents); others **do not** and only fetch raw HTML or hit declared endpoints (most WebFetch-style tools, and virtually all crawlers behind chat products at scale, for cost reasons). Betting your discoverability entirely on client-side rendering excludes the second group outright.\n\n- Agents increasingly prefer **calling a declared tool over parsing prose** when one is available, because tool outputs are structured and typed, which removes an entire class of extraction error. This is the actual argument for exposing an MCP server instead of relying on the agent to scrape your About page.\n\nThe practical implication: a portfolio’s agent-readability isn’t a single artifact (like adding robots.txt) — it’s an architectural decision that spans rendering strategy, API design, and structured markup.\n\n## The Dual-Layer Architecture\n\nThis site implements what I call a **Dual-Layer Architecture**: one rendering path optimized for human perception and interaction, one path optimized for machine consumption, both backed by a single source of truth.",
      "description": "A technical guide to dual-layer portfolio architecture: MCP servers, llms.txt, agents.md, and structured APIs that make your site legible to AI agents and answer engines, not just human visitors.",
      "keywords": [
        "that",
        "agent",
        "agents",
        "llms",
        "site",
        "your",
        "tool",
        "this",
        "tools",
        "content"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/blog/agent-ready-portfolios"
      }
    },
    {
      "id": "571d718659ef504f",
      "url": "https://hdrx.com.br/blog/woocommerce-performance-ttfb",
      "title": "WooCommerce TTFB Optimization: The Complete Guide to Sub-300ms Stores — Hendrix Garcia (Part 2)",
      "content": "- **Catalog pages with dynamic pricing** (role-based pricing, flash sales, stock-dependent messaging) invalidate naive cache rules.\n\nThis is why lifting-and-shifting a generic WordPress caching setup onto a WooCommerce store produces broken carts or stale prices, not just missed performance gains. Every optimization below has to account for this cacheable/uncacheable split.\n\n## Diagnosing TTFB Before Optimizing It\n\nDo not guess. Optimizing blind wastes engineering time on the wrong layer.\n\n### How do I measure where TTFB is actually being spent?\n\nAdd **Server-Timing** headers at each stage of the bootstrap (database, object cache, template render) and read them in the browser’s Network tab or via curl -w:\n\n// mu-plugins/server-timing.php\nadd_action('plugins_loaded', function () {\n$GLOBALS['__ts_start'] = microtime(true);\n});\n\nadd_action('shutdown', function () {\nif (!headers_sent() && isset($GLOBALS['__ts_start'])) {\n$elapsed = (microtime(true) - $GLOBALS['__ts_start']) * 1000;\nheader(sprintf('Server-Timing: wp-total;dur=%.2f', $elapsed));\n}\n});\nFor a quick CLI check without browser overhead:\n\ncurl -o /dev/null -s -w \"DNS: %{time_namelookup}s | TCP: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\\n\" https://store.example.com/cart/\n\n### How do I find which plugin or query is slow?\n\nInstall **Query Monitor** on a staging environment with production-like data volume (not a fresh install with 10 test products — indexing and cache-hit behavior only reveals itself at realistic scale). Look at:\n\n- The **Queries** panel, sorted by time, filtered by component — this attributes slow queries to the specific plugin or theme function that fired them.\n\n- The **Hooks & Actions** panel for init, wp, and template_redirect — this is where poorly written plugins run expensive logic unconditionally on every request, including bots and uncacheable pages.\n\n- The **Database Queries → Duplicate Queries** count — a strong signal of N+1 patterns (see below).",
      "description": "A deep technical guide to WooCommerce Time to First Byte: Redis object caching, HPOS, Action Scheduler bottlenecks, autoloaded options, PHP-FPM tuning, and edge caching for high-traffic stores.",
      "keywords": [
        "woocommerce",
        "cache",
        "redis",
        "object",
        "caching",
        "time",
        "this",
        "cart",
        "queries",
        "query"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/blog/woocommerce-performance-ttfb"
      }
    },
    {
      "id": "5acd1e5b378292cd",
      "url": "https://hdrx.com.br/pt-BR/blog/criacao-de-sites-profissionais",
      "title": "Criação de Sites Profissionais: A Base Técnica Que Faz o Site Vender — Hendrix Garcia (Part 4)",
      "content": "Eu crio sites de diversos tipos, personalizados para a necessidade do seu negócio — institucional, landing page, loja virtual, blog ou sistema com integrações. [Entre em contato](/pt-BR/contato) e me conta o que você precisa: eu te respondo com um caminho claro e um prazo real para o seu projeto.\n\n## Dúvidas ou ideias de projeto?\n\nEntre em contato para falar sobre arquitetura, otimização ou agentes de IA.\n\n[Entrar em contato →](/pt-BR/contato)\n[← Artigo anteriorMCP stateless em funções edge: arquitetura, trade-offs e implementação](/pt-BR/blog/mcp-stateless-em-funcoes-edge)[Próximo artigo →AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente](/pt-BR/blog/astropress-wordpress-headless-com-astro)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "O que diferencia um site profissional de um site montado às pressas em 2026 — performance real, presença no Google e nas buscas por IA, explicado sem jargão técnico excessivo.",
      "keywords": [
        "para",
        "site",
        "não",
        "pt-br",
        "mais",
        "rápido",
        "contato",
        "google",
        "isso",
        "negócio"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 4,
        "sourcePath": "/pt-BR/blog/criacao-de-sites-profissionais"
      }
    },
    {
      "id": "5c36cab1f59a411c",
      "url": "https://hdrx.com.br/pt-BR/blog/engenharia-de-prompts-como-codigo",
      "title": "Engenharia de prompts como código: versionamento, testes e CI/CD para prompts de LLMs — Hendrix Garcia (Part 4)",
      "content": "- **Um contrato que pode ser testado sem chamar o modelo.** Testes unitários verificam o comportamento do schema sobre fixtures de modo instantâneo e gratuito, separado dos testes de integração lentos, não determinísticos e caros que chamam o LLM.\n\n- **Um caminho de migração quando o contrato muda.** Alterações de schema se tornam diffs explícitos revisáveis em PR, não renegociações implícitas entre texto do prompt e código downstream que por acaso ainda funcionam.\n\n### Saída estruturada: modo tool-calling vs. prompt de sistema em JSON mode\n\nHá duas formas de obter saída estruturada, com perfis distintos de confiabilidade:\n\n- **Tool/function calling nativo** (tool use do Claude, function calling da OpenAI) — o modelo é direcionado a um schema no nível da API. Tem maior aderência, funciona bem para schemas aninhados e enums estritos e se integra naturalmente a Zod quando você gera a definição de ferramenta a partir do mesmo schema usado para validar.\n\n- **JSON mode por instrução no prompt de sistema** (“responda apenas com JSON válido nesta forma”) — menos confiável, mais sujeito a vazamento de prosa ou colchetes malformados, mas necessário quando o workflow não cabe no formato de chamada de ferramenta (por exemplo, a “ferramenta” *é* a resposta final). Sempre combine-o a validação runtime e retry com feedback de erro, nunca a confiança cega.\n\nPrefira tool-calling para qualquer coisa com schema estrito e baixa tolerância a falhas; reserve JSON mode para casos em que a semântica de tool-calling não se encaixa bem na tarefa.\n\n### Lidando com falhas de validação: estratégia de retry\n\nUma falha de validação não é necessariamente terminal. Uma escada pragmática de retry:",
      "description": "Um framework prático para tratar prompts como artefatos de software — versionamento semântico, saída estruturada validada por Zod, suítes de eval de regressão e gates de CI/CD, a partir da arquitetura do Prompt Pocket.",
      "keywords": [
        "prompt",
        "não",
        "para",
        "saída",
        "modelo",
        "schema",
        "como",
        "validação",
        "json",
        "versão"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/engenharia-de-prompts-como-codigo"
      }
    },
    {
      "id": "60cfcaffd2e1bc8c",
      "url": "https://hdrx.com.br/pt-BR/blog/astropress-wordpress-headless-com-astro",
      "title": "AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente — Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os artigos](/pt-BR/blog)**\n\n24 de agosto de 2026• 12 min de leitura\nAstroWordPressHeadless CMSOpen SourcePerformance\n\n## AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente\n\nComo o AstroPress desacopla o WordPress como backend editorial puro de um frontend estático em Astro — a camada de conteúdo, a cascata de SEO em 4 níveis, preview de rascunho em tempo real e os orçamentos de performance aplicados em CI.\n\nO AstroPress é um starter open-source que desacopla o WordPress da renderização de páginas: o WordPress permanece como backend editorial puro — Gutenberg, taxonomias, biblioteca de mídia — enquanto o Astro consulta a REST API do WordPress inteiramente em tempo de build e compila HTML/CSS estático para o edge, enviando 0 KB de JavaScript no cliente por padrão nas páginas editoriais. O projeto está [no GitHub](https://github.com/hd-rx8/AstroPress) sob licença MIT.\n\nO problema que ele resolve é específico e comum: o WordPress é genuinamente bom como experiência de edição de conteúdo para autores não técnicos, e genuinamente ruim como runtime de renderização de página quando tráfego ou requisitos de performance ficam sérios. A maioria dos tutoriais de “WordPress headless” para no “chame a REST API a partir do seu frontend”. O AstroPress vai além — é uma stack opinativa e completa, com uma camada real de normalização de conteúdo, um plugin WordPress complementar para preview autenticado de rascunho, orçamentos de performance aplicados em CI e uma ferramenta de diagnóstico que verifica todo o pipeline de ponta a ponta.\n\n## Por Que Desacoplar o WordPress da Renderização\n\nUm tema WordPress convencional executa PHP em cada requisição: inicializa o WordPress, roda os hooks de cada plugin ativo, consulta o MySQL pelo post e seus metadados, renderiza um template e só então envia o HTML. Sob carga, ou com uma pilha pesada de plugins, é nesse caminho que nascem a maioria dos problemas de performance do WordPress — não no frontend.",
      "description": "Como o AstroPress desacopla o WordPress como backend editorial puro de um frontend estático em Astro — a camada de conteúdo, a cascata de SEO em 4 níveis, preview de rascunho em tempo real e os orçamentos de performance aplicados em CI.",
      "keywords": [
        "wordpress",
        "para",
        "não",
        "conteúdo",
        "astropress",
        "como",
        "plugin",
        "astro",
        "preview",
        "performance"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/astropress-wordpress-headless-com-astro"
      }
    },
    {
      "id": "62514455c99f6245",
      "url": "https://hdrx.com.br/pt-BR/blog/mcp-stateless-em-funcoes-edge",
      "title": "MCP stateless em funções edge: arquitetura, trade-offs e implementação — Hendrix Garcia (Part 2)",
      "content": "A premissa de transporte original do MCP é um processo único e de longa duração. Três propriedades desse modelo quebram assim que você migra para computação serverless ou edge:\n\n- **Não há processo persistente.** Um servidor stdio possui um processo durante a sessão. Uma invocação de Edge Function dura apenas um ciclo de requisição — não há garantia de que a próxima requisição do mesmo cliente chegue ao mesmo isolate, e a maioria das plataformas explicitamente não oferece essa garantia.\n\n- **Não existe memória compartilhada entre invocações.** Qualquer valor guardado em variável de nível de módulo para representar “estado de sessão” (versão de protocolo negociada, lista de ferramentas listadas antes, contexto de autenticação criado durante initialize) é invisível para a próxima invocação, a menos que seja externalizado para banco, KV store ou a própria requisição.\n\n- **Handshake como pré-requisito conflita com cold starts.** Se tools/call só é válido depois de um initialize bem-sucedido na mesma sessão e a plataforma não pode garantir continuidade da sessão, todo isolate frio precisa repetir o handshake ou rejeitar requisições que deveria conseguir atender.\n\nO modo prático de falha antes da atualização 2026-07-28: equipes construíam servidores MCP em Lambda ou Vercel Functions e tentavam simular continuidade de sessão com roteamento sticky, stores de sessão externas chaveadas por um ID gerado no cliente ou, pior, aceitavam tools/call sem initialize torcendo para que os clientes não aplicassem a sequência com rigor. Os três são contornos para uma premissa de protocolo que não existe no runtime-alvo — não são soluções.\n\n## O que o spec stateless realmente mudou\n\n- **Eliminação do handshake como requisito rígido.** initialize deixou de ser um pré-requisito stateful que bloqueia todo método seguinte. Um servidor pode aceitar um tools/call ou tools/list autossuficiente sem contexto de sessão prévio e responder corretamente.",
      "description": "Um guia técnico aprofundado para construir um servidor Model Context Protocol stateless em Vercel Edge Functions — desenho JSON-RPC 2.0, a mudança do spec 2026-07-28, autenticação e rate limiting sem sessões e testes headless com curl.",
      "keywords": [
        "para",
        "edge",
        "não",
        "sessão",
        "tools",
        "servidor",
        "node",
        "stateless",
        "requisição",
        "call"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/mcp-stateless-em-funcoes-edge"
      }
    },
    {
      "id": "646abd0f8828fd7a",
      "url": "https://hdrx.com.br/blog/astropress-headless-wordpress-astro",
      "title": "AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS — Hendrix Garcia (Part 5)",
      "content": "git clone https://github.com/hd-rx8/AstroPress-Headless-Starter.git\ncd AstroPress-Headless-Starter\nnpm install\ndocker compose up -d # WordPress 6 + MySQL 8.4, pre-seeded with demo content\nnpm run doctor # verify the full pipeline before starting dev\nnpm run dev # http://localhost:4321\nWordPress admin is reachable at http://localhost:8080/wp-admin, and the diagnostics dashboard at /doctor. Configuration lives in .env, requiring WORDPRESS_URL, SITE_URL, and ASTROPRESS_PREVIEW_SECRET (the shared secret used by the draft-preview token handshake). The stack is built on Astro —",
      "description": "How AstroPress decouples WordPress as a pure editorial backend from an Astro static frontend — the content layer, the 4-tier SEO cascade, real-time draft preview, and the CI performance budgets that enforce it.",
      "keywords": [
        "wordpress",
        "that",
        "astropress",
        "plugin",
        "astro",
        "with",
        "from",
        "content",
        "static",
        "preview"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/blog/astropress-headless-wordpress-astro"
      }
    },
    {
      "id": "6498a5bb3fb42407",
      "url": "https://hdrx.com.br/pt-BR/blog/portfolios-prontos-para-agentes",
      "title": "Portfólios preparados para agentes: criando sites de desenvolvedores para MCP, LLMs e mecanismos de resposta — Hendrix Garcia (Part 3)",
      "content": "┌────────────────────────┐\n│ Domínio público │\n└────────────┬─────────────┘\n│\n┌────────────────────┴────────────────────┐\n▼ ▼\n[Camada humana] [Camada de agentes]\n• Astro 5 SSG/SSR híbrido • Servidor MCP stateless (/api/mcp)\n• Navegação com sensação de SPA • Arquivo de descoberta /llms.txt\n• HTML semântico + JSON-LD • Guia de contribuição /agents.md\n• Sistema de design, motion, imagens • Endpoints REST (/api/resume, /api/projects)\n│ │\n└────────────────────┬─────────────────────┘\n▼\n/src/data/*.ts (fonte única da verdade)\nA restrição crítica que mantém isso sustentável: **as duas camadas leem do mesmo módulo de dados tipado.** A ferramenta get_projects do servidor MCP e o componente da página /projects usam o mesmo array projects.ts. Não há um “conteúdo para bots” separado que possa se desalinhar do “conteúdo para humanos” — uma falha comum em sites que acoplam um llms.txt como reflexão tardia e depois deixam de atualizá-lo quando o site visível muda.\n\n### Por que o modelo de saída híbrido do Astro importa aqui\n\nO Astro entrega zero JavaScript por padrão e renderiza HTML estático em tempo de build, com a opção de incluir rotas específicas em renderização de servidor (output: \"hybrid\" com export const prerender = false por rota). Para a legibilidade por agentes isso importa por uma razão simples, mas decisiva: **o conteúdo que existe na resposta HTML inicial é visível a todo consumidor, independentemente de executar JavaScript.** Uma SPA React que monta conteúdo no cliente é invisível para qualquer agente que faça um fetch() simples — que, por razões de custo e latência, é a maioria deles.\n\nAs ilhas React (client:load, client:visible) são usadas aqui apenas para interatividade real — o filtro de projetos e o widget de chat — nunca para conteúdo que precisa ser descoberto. Isso não é antes de tudo uma otimização de performance; é uma decisão de arquitetura da informação que também melhora os Core Web Vitals.\n\n## Arquivos de descoberta: llms.txt e agents.md",
      "description": "Um guia técnico para a arquitetura de portfólio em duas camadas: servidores MCP, llms.txt, agents.md e APIs estruturadas que tornam seu site legível para agentes de IA e mecanismos de resposta, e não apenas para visitantes humanos.",
      "keywords": [
        "para",
        "não",
        "agentes",
        "agente",
        "site",
        "llms",
        "agents",
        "como",
        "resposta",
        "ferramentas"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/portfolios-prontos-para-agentes"
      }
    },
    {
      "id": "682bfd17c94ce1b3",
      "url": "https://hdrx.com.br/blog/prompt-engineering-as-code",
      "title": "Prompt Engineering as Code: Versioning, Testing, and CI/CD for LLM Prompts — Hendrix Garcia (Part 3)",
      "content": "Because LLMs are non-deterministic text generators, not typed function calls — even with low temperature, output format drifts (a stray markdown fence, an extra sentence before the JSON, a field renamed by the model’s own “helpful” instinct). Any pipeline that consumes this output downstream needs a validation boundary, exactly like you’d validate an external API response you don’t control.\n\nThe pattern: define the contract with a schema library (Zod in TypeScript, Pydantic in Python), request structured output from the model (tool-calling / function-calling mode where available, or a JSON-mode system prompt as fallback), and **parse-and-validate before any business logic runs**:\n\nimport { z } from \"zod\"\n\nexport const CodeReviewOutputSchema = z.object({\nstatus: z.enum([\"approved\", \"changes_requested\"]),\nfindings: z.array(\nz.object({\nseverity: z.enum([\"critical\", \"important\", \"minor\"]),\nfile: z.string(),\ndescription: z.string(),\n})\n),\n})\n\nexport type CodeReviewOutput = z.infer<typeof CodeReviewOutputSchema>\n\n// At the API boundary — fail loud, fail typed, not silently downstream\nconst result = CodeReviewOutputSchema.safeParse(rawModelOutput)\nif (!result.success) {\n// Never let malformed model output reach business logic.\n// Log the validation error, the raw output, and the prompt version\n// that produced it — this triple is your debugging surface.\nthrow new StructuredOutputValidationError(result.error, promptVersion)\n}\nThe three things this buys you that regex-parsing or “just ask nicely” doesn’t:\n\n- **A single point of failure that’s observable.** When output shape breaks, you get a typed validation error tied to a specific prompt version — not a TypeError: undefined is not a function three layers deep in your app.\n\n- **A contract you can test against without calling the model.** Unit tests can assert schema behavior on fixture data instantly and for free, separate from the (slow, non-deterministic, costly) integration tests that actually call the LLM.",
      "description": "A practical framework for treating prompts as software artifacts — semantic versioning, Zod-validated structured output, regression eval suites, and CI/CD gating, built from the Prompt Pocket architecture.",
      "keywords": [
        "prompt",
        "output",
        "with",
        "model",
        "schema",
        "this",
        "that",
        "code",
        "validation",
        "from"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/blog/prompt-engineering-as-code"
      }
    },
    {
      "id": "6e03e24e5d36cbcd",
      "url": "https://hdrx.com.br/pt-BR",
      "title": "Hendrix Garcia — Engenheiro de Produto Full-Stack (Part 1)",
      "content": "Desenvolvedor Full-Stack e Engenheiro de Produto\n\n## Hendrix GarciaHendrix Garcia\n\nDigite &#x27;ajuda&#x27; para ver os comandos disponíveis.\n\nguest@hdrx:~$\n\n█\n\nAberto a oportunidades em tempo integral— Disponível para início imediato. Preferência por trabalho remoto global.\n\n## No que posso ajudar você a entregar\n\nDe uma entrega pontual a uma parceria de engenharia contínua, o trabalho começa pelo problema de negócio e termina em um sistema confiável em produção.\n\n[Falar sobre este trabalho →](/pt-BR/contato)\n\n-\n\n### Produtos web e sistemas full-stack\n\nCriar ou evoluir um produto web com frontend moderno, integrações de backend e uma base pronta para produção.\n\n-\n\n### Operação WordPress e WooCommerce\n\nCriar, customizar, migrar, otimizar e manter ambientes WordPress ou de e-commerce que precisam continuar funcionando.\n\n-\n\n### Integrações de IA e automação\n\nConectar APIs, webhooks, ferramentas de IA e fluxos de negócio em sistemas que reduzem trabalho manual e permanecem observáveis.\n\n// Sistemas\n\n## Projetos em destaque\n\n[Ver catálogo completo →](/pt-BR/projetos)\n\n### Portfólio Preparado para Agentes\n\nPortfólio pronto para agentes, com MCP, llms.txt e terminal interativo para assistentes de IA.\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n[Ver projeto](/pt-BR/projetos/agent-ready-portfolio)\n\n### WOP - Plataforma de Operações Web\n\nPlataforma operacional para agências: inventário, uptime, incidentes e manutenção de sites.\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n[Ver projeto](/pt-BR/projetos/wop)\n\n### Prompt Pocket",
      "description": "Engenheiro de Produto Full-Stack que desenvolve produtos web rápidos, confiáveis e sistemas com IA.",
      "keywords": [
        "para",
        "pt-br",
        "wordpress",
        "typescript",
        "hendrix",
        "projetos",
        "react",
        "tailwind",
        "desenvolvedor",
        "conectar"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 4,
        "sourcePath": "/pt-BR"
      }
    },
    {
      "id": "6e245d87ae4a581d",
      "url": "https://hdrx.com.br/pt-BR/projetos/astropress",
      "title": "AstroPress — Estudo de caso · Hendrix Garcia (Part 3)",
      "content": "- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Starter headless de WordPress com Astro 5 focado em performance — zero JavaScript no cliente por padrão.",
      "keywords": [
        "pt-br",
        "wordpress",
        "para",
        "projetos",
        "astro",
        "github",
        "rest",
        "conectar",
        "perfil",
        "sistema"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/projetos/astropress"
      }
    },
    {
      "id": "77c209e2f5ebd7fc",
      "url": "https://hdrx.com.br/contact",
      "title": "Contact — Hendrix Garcia",
      "content": "OPEN*TO*WORK*\n\nDirect Channel\n\n## Let&#x27;s build the future!Let&#x27;s build the future!\n\nCurrently open to full-time roles. Whether you have an open role, an AI product to architect, or a WordPress fleet to optimize, send a brief below.\n\nYour Name / Organization *\n\nEmail or LinkedIn Profile *\n\nInquiry Type\nRecruitmentProject QuoteConsulting\n\nProject Brief / Role Details *\n\nDispatch Brief →Rate-limited endpoint • Resend direct delivery\n\n[01 // Direct Email hdrxgarcia@gmail.com Direct inbox • Response in < 24h](mailto:hdrxgarcia@gmail.com)\n\n[02 // LinkedIn Profile ↗ LinkedIn Profile ↗ Career history & recommendations](https://linkedin.com/in/hendrixgarcia)\n\n[03 // MCP Connection ↗ MCP Connection ↗ Connect your AI agent via Model Context Protocol](/connect)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Contact Hendrix Garcia about full-time roles, contracts, and product engineering work.",
      "keywords": [
        "linkedin",
        "profile",
        "connect",
        "gmail",
        "open",
        "direct",
        "hdrxgarcia",
        "brief",
        "https",
        "github"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 1,
        "sourcePath": "/contact"
      }
    },
    {
      "id": "77d4482033ae363f",
      "url": "https://hdrx.com.br/pt-BR/blog/portfolios-prontos-para-agentes",
      "title": "Portfólios preparados para agentes: criando sites de desenvolvedores para MCP, LLMs e mecanismos de resposta — Hendrix Garcia (Part 2)",
      "content": "- O agente com frequência precisa **sintetizar uma resposta**, não apenas apontar para uma fonte. Se seus dados não puderem ser extraídos de forma limpa, ele alucina um resumo ou simplesmente ignora você.\n\n- Alguns agentes **executam JavaScript e renderizam o DOM** (agentes no estilo browser-use); outros **não** e apenas buscam HTML bruto ou chamam endpoints declarados (a maioria das ferramentas no estilo WebFetch e praticamente todos os crawlers por trás de produtos de chat em escala, por razões de custo). Apostar toda a sua encontrabilidade em renderização client-side exclui completamente o segundo grupo.\n\n- Agentes preferem cada vez mais **chamar uma ferramenta declarada em vez de analisar prosa** quando ela está disponível, porque saídas de ferramentas são estruturadas e tipadas, removendo toda uma classe de erros de extração. Esse é o verdadeiro argumento para expor um servidor MCP em vez de depender de o agente raspar sua página Sobre.\n\nA implicação prática: a legibilidade de um portfólio por agentes não é um único artefato (como adicionar robots.txt) — é uma decisão arquitetural que atravessa estratégia de renderização, desenho de API e marcação estruturada.\n\n## A arquitetura em duas camadas\n\nEste site implementa o que chamo de **Arquitetura em Duas Camadas**: um caminho de renderização otimizado para percepção e interação humanas, outro otimizado para consumo por máquinas, ambos sustentados por uma única fonte da verdade.",
      "description": "Um guia técnico para a arquitetura de portfólio em duas camadas: servidores MCP, llms.txt, agents.md e APIs estruturadas que tornam seu site legível para agentes de IA e mecanismos de resposta, e não apenas para visitantes humanos.",
      "keywords": [
        "para",
        "não",
        "agentes",
        "agente",
        "site",
        "llms",
        "agents",
        "como",
        "resposta",
        "ferramentas"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/portfolios-prontos-para-agentes"
      }
    },
    {
      "id": "7c83150a94627ea8",
      "url": "https://hdrx.com.br/blog/agent-ready-portfolios",
      "title": "Agent-Ready Portfolios: Building Developer Sites for MCP, LLMs, and Answer Engines — Hendrix Garcia (Part 1)",
      "content": "[← Back to all articles](/blog)**\n\nAugust 1, 2026• 14 min read\nAEOMCPProduct EngineeringStructured DataAstro\n\n## Agent-Ready Portfolios: Building Developer Sites for MCP, LLMs, and Answer Engines\n\nA technical guide to dual-layer portfolio architecture: MCP servers, llms.txt, agents.md, and structured APIs that make your site legible to AI agents and answer engines, not just human visitors.\n\nA growing share of the traffic hitting developer portfolios isn’t a recruiter scrolling on a phone — it’s an agent. Cursor calling out to verify a claim. A recruiting tool running Claude or GPT-4 to triage candidates against a job description. Perplexity or ChatGPT answering “who is this person and what have they built” on a user’s behalf, without ever rendering your CSS.\n\nMost portfolios are built exclusively for the first kind of visitor. This post covers the architecture for the second — the concrete mechanisms (MCP, llms.txt, agents.md, JSON-LD, structured REST endpoints) that make a site legible to machines, why each one exists, and where the tradeoffs actually bite.\n\n## Why Agent-Readability Is a Distinct Engineering Problem\n\nTraditional SEO optimizes for a crawler that fetches HTML, extracts text and links, and indexes it for a ranked list of results a human then clicks through. Agentic crawling** is a different consumption model entirely:\n\n- The agent often has a **budget** — a fixed number of tool calls, tokens, or page loads before it must produce an answer. Inefficient page structure directly costs the agent (and the user waiting on it) time.\n\n- The agent frequently needs to **synthesize an answer**, not just link to a source. If your data isn’t extractable cleanly, the agent either hallucinates a summary or skips you.",
      "description": "A technical guide to dual-layer portfolio architecture: MCP servers, llms.txt, agents.md, and structured APIs that make your site legible to AI agents and answer engines, not just human visitors.",
      "keywords": [
        "that",
        "agent",
        "agents",
        "llms",
        "site",
        "your",
        "tool",
        "this",
        "tools",
        "content"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/blog/agent-ready-portfolios"
      }
    },
    {
      "id": "80c1617f8c275de3",
      "url": "https://hdrx.com.br/pt-BR/blog/astropress-wordpress-headless-com-astro",
      "title": "AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente — Hendrix Garcia (Part 3)",
      "content": "O projeto também documenta **limites explícitos de JavaScript**: fetches ou hidratação no lado do cliente são proibidos para conteúdo já conhecido em tempo de build — é exatamente para isso que existem a camada de conteúdo e a geração estática. Ilhas do Astro só são permitidas para interatividade de escopo estreito que genuinamente não pode ser estática, como uma caixa de busca no cliente. É a mesma disciplina que impede uma arquitetura “static-first” de regredir silenciosamente para uma aplicação renderizada no cliente, um client:load conveniente de cada vez.\n\n## A Cascata de SEO em 4 Níveis\n\nSites WordPress reais acumulam metadados de SEO vindos de múltiplas fontes, muitas vezes conflitantes: um plugin de SEO dedicado, campos nativos do WordPress e padrões do site, nem sempre sincronizados entre si. O README do AstroPress descreve uma “cascata inteligente de metadados” que resolve isso de forma determinística: **Yoast SEO → Rank Math → campos nativos do WP → padrões do site**, avançando para a próxima fonte apenas quando a atual não tem nada definido, e alimentando o resultado em grafos JSON-LD de Schema.org (BlogPosting, BreadcrumbList, WebSite).\n\nO benefício prático é que migrar entre plugins de SEO, ou rodar um site que começou com campos nativos do WP e depois adicionou o Yoast, não produz metadados silenciosamente ausentes — a cascata sempre resolve para *algo*, numa ordem de prioridade previsível, em vez de exigir que cada template trate manualmente qual plugin está ativo no momento.\n\n## Pipeline de Imagens e Preview de Rascunho\n\nMídia remota vinda do WordPress é compilada através do pipeline astro:assets do Astro em WebP/AVIF responsivos em tempo de build, com atributos explícitos de largura e altura definidos para que o navegador reserve o espaço de layout antes da imagem carregar — o mecanismo direto para manter o Cumulative Layout Shift em zero, em vez de depender só de lazy-loading para mascarar o problema.",
      "description": "Como o AstroPress desacopla o WordPress como backend editorial puro de um frontend estático em Astro — a camada de conteúdo, a cascata de SEO em 4 níveis, preview de rascunho em tempo real e os orçamentos de performance aplicados em CI.",
      "keywords": [
        "wordpress",
        "para",
        "não",
        "conteúdo",
        "astropress",
        "como",
        "plugin",
        "astro",
        "preview",
        "performance"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/astropress-wordpress-headless-com-astro"
      }
    },
    {
      "id": "81762da4d0538735",
      "url": "https://hdrx.com.br/pt-BR",
      "title": "Hendrix Garcia — Engenheiro de Produto Full-Stack (Part 4)",
      "content": "Claude, Cursor ou ChatGPT podem se conectar diretamente a /api/mcp para consultar dados do currículo, pesquisar capacidades e verificar disponibilidade.\n\n[Conecte seu agente →](/pt-BR/conectar)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Engenheiro de Produto Full-Stack que desenvolve produtos web rápidos, confiáveis e sistemas com IA.",
      "keywords": [
        "para",
        "pt-br",
        "wordpress",
        "typescript",
        "hendrix",
        "projetos",
        "react",
        "tailwind",
        "desenvolvedor",
        "conectar"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 4,
        "sourcePath": "/pt-BR"
      }
    },
    {
      "id": "825e25d5276f1da7",
      "url": "https://hdrx.com.br/pt-BR",
      "title": "Hendrix Garcia — Engenheiro de Produto Full-Stack (Part 2)",
      "content": "Extensão Chrome privada para salvar, organizar e reutilizar prompts de IA entre ferramentas.\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n[Ver projeto](/pt-BR/projetos/prompt-pocket)\n\n### Jumbox\n\nSistema privado e local-first de transferência de arquivos, com streaming retomável e integridade ponta a ponta.\n\n- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n[Ver projeto](/pt-BR/projetos/jumbox)\n\n### AstroPress\n\nStarter headless de WordPress com Astro 5 focado em performance — zero JavaScript no cliente por padrão.\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n[Ver projeto](/pt-BR/projetos/astropress)\n\n### Web Ready\n\nUma ferramenta open-source para auditoria técnica de sites em SEO Técnico, prontidão para IA e saúde básica da web.\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n[Ver projeto](/pt-BR/projetos/web-ready)\n\n## Perguntas frequentes\n\nPara quais tipos de trabalho posso contratar o Hendrix?Hendrix está aberto a trabalhos full-time e contract como Desenvolvedor Full-Stack, Engenheiro de Produto, Desenvolvedor WordPress. As especialidades atuais incluem WordPress e WooCommerce, React e Next.js, TypeScript, Performance Web, Integrações de IA, Automação (n8n, Make). Aberto a oportunidades em tempo integral.",
      "description": "Engenheiro de Produto Full-Stack que desenvolve produtos web rápidos, confiáveis e sistemas com IA.",
      "keywords": [
        "para",
        "pt-br",
        "wordpress",
        "typescript",
        "hendrix",
        "projetos",
        "react",
        "tailwind",
        "desenvolvedor",
        "conectar"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 4,
        "sourcePath": "/pt-BR"
      }
    },
    {
      "id": "84a04f10c0b2d73e",
      "url": "https://hdrx.com.br/blog/professional-website-development",
      "title": "Professional Website Development: The Technical Base That Makes a Site Sell — Hendrix Garcia (Part 4)",
      "content": "I build sites of different kinds, customized to your business’s needs — institutional, landing page, online store, blog, or a system with integrations. [Get in touch](/contact) and tell me what you need: I’ll come back with a clear path and a real timeline for your project.\n\n## Questions or project ideas?\n\nReach out directly to discuss architecture, optimization, or AI agents.\n\n[Get in Touch →](/contact)\n[← Previous articleStateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation](/blog/mcp-stateless-edge-functions)[Next article →AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS](/blog/astropress-headless-wordpress-astro)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "What separates a professional website from a site thrown together in a hurry in 2026 — real performance, presence in Google and in AI search, explained without excessive technical jargon.",
      "keywords": [
        "that",
        "site",
        "with",
        "what",
        "business",
        "google",
        "page",
        "project",
        "technical",
        "search"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 4,
        "sourcePath": "/blog/professional-website-development"
      }
    },
    {
      "id": "85370f13b2868c57",
      "url": "https://hdrx.com.br/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce",
      "title": "Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms — Hendrix Garcia (Part 3)",
      "content": "- O painel **Hooks & Actions** em init, wp e template_redirect: plugins mal escritos costumam executar lógica cara incondicionalmente em toda requisição, inclusive para bots e páginas não cacheáveis.\n\n- A contagem **Database Queries → Duplicate Queries**, forte sinal de padrões N+1.\n\nEm produção, evite Query Monitor ao vivo; habilite temporariamente o slow query log do MySQL e correlacione com tráfego da REST API e storefront.\n\n# my.cnf — apenas para janela temporária de diagnóstico\nslow_query_log = 1\nslow_query_log_file = /var/log/mysql/slow.log\nlong_query_time = 0.2\nlog_queries_not_using_indexes = 1\n\n## Pilar 1: cache de objetos com Redis (não apenas page cache)\n\nPage cache e object cache resolvem problemas distintos; confundi-los é o erro arquitetural mais comum em performance WooCommerce.\n\nCamada\n\nO que cacheia\n\nResolve\n\nNão resolve\n\n**Page cache** (Varnish, FastCGI cache, CDN edge)\n\nResposta HTML renderizada inteira\n\nRequisições idênticas repetidas a páginas estáticas/de catálogo\n\nCarrinho, checkout, conteúdo logado ou por usuário\n\n**Object cache** (Redis/Memcached)\n\nObjetos PHP, resultados de consultas, transients\n\nConsultas e cálculos caros repetidos dentro ou entre requisições PHP\n\nNada se o padrão de query subjacente for o gargalo (índices ruins, N+1)\n\n**OPcache**\n\nOpcode PHP compilado\n\nReparse/recompilação de fontes PHP a cada requisição\n\nTrabalho preso ao banco; é alívio de CPU, não de I/O\n\n**CDN edge cache**\n\nAssets estáticos + HTML dinâmico cacheável em PoPs próximos\n\nLatência de rede e carga de origem para páginas cacheáveis\n\nPáginas não cacheáveis (carrinho/checkout)\n\nPor padrão, o object cache do WordPress é **não persistente**: vive apenas durante uma requisição e é descartado. Cada nova requisição reconstrói do zero as mesmas buscas de options, termos e meta. Em uma loja com tráfego concorrente, isso significa MySQL recebendo as mesmas leituras de wp_options e wp_postmeta milhares de vezes por minuto, sem reutilização entre requests.",
      "description": "Um guia técnico aprofundado para Time to First Byte no WooCommerce: cache de objetos Redis, HPOS, gargalos do Action Scheduler, opções autocarregadas, ajuste de PHP-FPM e cache edge para lojas de alto tráfego.",
      "keywords": [
        "cache",
        "não",
        "woocommerce",
        "redis",
        "para",
        "ttfb",
        "object",
        "query",
        "time",
        "páginas"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce"
      }
    },
    {
      "id": "8bbccd95d7dad65d",
      "url": "https://hdrx.com.br/pt-BR/sobre",
      "title": "Sobre Hendrix Garcia (Part 3)",
      "content": "Node.jsPHPLaravelSupabaseMySQLPostgreSQLAPIs REST\n\n### // CMS e e-commerce\n\nWordPressWooCommerceElementorhooks de PHPTipos de postagem personalizados\n\n### // IA e automação\n\nAPI ClaudeMCPn8nMakeAgentes de IAWebhooks\n\n### // Infraestrutura\n\nDockerVercelGitCloudflareSSLLinux VPS\n\n[03]\n\n## Formação e especialização\n\njan. de 2025 – jan. de 2026\n\n### Pós-graduação: Marketing, Estratégia, Negócios Digitais e Experiência do Cliente\n\nPUC-PR\n\n2021 – 2023\n\n### Análise e Desenvolvimento de Sistemas\n\nUNINTER\n\n### Quer que um agente de IA avalie a trajetória do Hendrix?\n\nEste portfólio disponibiliza um servidor público e sem estado de Model Context Protocol (MCP) para Claude, Cursor e ChatGPT.\n\n[Ver instruções de MCP →](/pt-BR/conectar)[Entrar em contato](/pt-BR/contato)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Trajetória profissional, capacidades técnicas e abordagem de engenharia de produto.",
      "keywords": [
        "wordpress",
        "woocommerce",
        "pt-br",
        "react",
        "javascript",
        "laravel",
        "elementor",
        "rest",
        "para",
        "desenvolvimento"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/sobre"
      }
    },
    {
      "id": "8be3ad0eebb82749",
      "url": "https://hdrx.com.br/pt-BR/projetos",
      "title": "Projetos — Hendrix Garcia (Part 2)",
      "content": "- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n[Estudo de caso →](/pt-BR/projetos/jumbox)\n[Código-fonte ↗](https://github.com/hd-rx8/jumbox)\n\nwordpress Em destaque\n\n### [AstroPress](/pt-BR/projetos/astropress)\n\nStarter headless de WordPress com Astro 5 focado em performance — zero JavaScript no cliente por padrão.\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n[Estudo de caso →](/pt-BR/projetos/astropress)\n[Código-fonte ↗](https://github.com/hd-rx8/AstroPress)\n\ndev tool Em destaque\n\n### [Web Ready](/pt-BR/projetos/web-ready)\n\nUma ferramenta open-source para auditoria técnica de sites em SEO Técnico, prontidão para IA e saúde básica da web.\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n[Estudo de caso →](/pt-BR/projetos/web-ready)\n[Código-fonte ↗](https://github.com/hd-rx8/web-ready)[Em produção ↗](https://web-ready-go.vercel.app/)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links",
      "description": "Um catálogo estruturado de software em produção, integrações de agentes de IA e infraestrutura de alta performance projetados para gerar impacto mensurável nos negócios.",
      "keywords": [
        "pt-br",
        "projetos",
        "typescript",
        "para",
        "github",
        "caso",
        "react",
        "tailwind",
        "https",
        "destaque"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/projetos"
      }
    },
    {
      "id": "8e97a46ced7c5906",
      "url": "https://hdrx.com.br/pt-BR/blog/mcp-stateless-em-funcoes-edge",
      "title": "MCP stateless em funções edge: arquitetura, trade-offs e implementação — Hendrix Garcia (Part 5)",
      "content": "Uma segunda restrição, menos óbvia: **não há cache em memória entre invocações em que você possa confiar.** Algumas plataformas Edge mantêm um isolate aquecido por pouco tempo e um Map em nível de módulo pode sobreviver a algumas requisições na prática, mas isso é detalhe de implementação do warm pool, não contrato garantido. Lógica de ferramenta que dependa silenciosamente disso (por exemplo, contador de rate limit em memória) passa em testes locais",
      "description": "Um guia técnico aprofundado para construir um servidor Model Context Protocol stateless em Vercel Edge Functions — desenho JSON-RPC 2.0, a mudança do spec 2026-07-28, autenticação e rate limiting sem sessões e testes headless com curl.",
      "keywords": [
        "para",
        "edge",
        "não",
        "sessão",
        "tools",
        "servidor",
        "node",
        "stateless",
        "requisição",
        "call"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/mcp-stateless-em-funcoes-edge"
      }
    },
    {
      "id": "8fb09769ce7e3bbe",
      "url": "https://hdrx.com.br/blog/mcp-stateless-edge-functions",
      "title": "Stateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation — Hendrix Garcia (Part 4)",
      "content": "Longer ceilings, configurable per plan\n\nMemory\n\nConstrained, shared isolate budget\n\nHigher, dedicated per-invocation memory\n\nGeographic distribution\n\nRuns at PoPs close to the requester by default\n\nRuns in a fixed region unless explicitly multi-region\n\nTCP/raw socket access\n\nNot available\n\nAvailable — needed for some DB drivers, raw SMTP, etc.\n\nnpm compatibility\n\nPartial — packages relying on Node built-ins fail at build or runtime\n\nFull\n\nBest fit for MCP\n\nStateless, read-heavy tools with HTTP-only dependencies (fetch to Resend, a REST API, a static data module)\n\nTools needing a native DB driver, filesystem access, or long-running computation\n\nThe concrete implication for an MCP server: **every tool handler must be reachable through fetch-compatible I/O.** For this portfolio’s implementation, that’s trivial — the data source is a set of TypeScript modules bundled with the function (src/data/*.ts), and the one network call (contact, via Resend) is a plain HTTP POST. If a tool needed a direct PostgreSQL connection over TCP, or a Node-only PDF-generation library, it would need to run on the Node.js runtime instead — Edge is not a universal substitute, it’s the right tool for a specific I/O profile.\n\nA second, less obvious constraint: **no in-memory caching across invocations that you can rely on.** Some Edge platforms do keep an isolate warm briefly and a module-level Map will survive a handful of requests in practice, but this is an implementation detail of the platform’s warm-pool behavior, not a guaranteed contract. Building tool logic that silently depends on it (e.g., an in-memory rate-limit counter) will pass local testing and then fail intermittently in production once traffic spreads across isolates.\n\n## Handling Auth and Rate Limiting Without Server-Side Sessions",
      "description": "A deep technical guide to building a stateless Model Context Protocol server on Vercel Edge Functions — JSON-RPC 2.0 design, the 2026-07-28 spec change, auth and rate limiting without sessions, and headless testing with curl.",
      "keywords": [
        "edge",
        "server",
        "tools",
        "that",
        "session",
        "request",
        "call",
        "stateless",
        "with",
        "node"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/blog/mcp-stateless-edge-functions"
      }
    },
    {
      "id": "92d7f447e89eb237",
      "url": "https://hdrx.com.br/blog/astropress-headless-wordpress-astro",
      "title": "AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS — Hendrix Garcia (Part 4)",
      "content": "Headless setups fail in ways that are hard to localize — is it WordPress, the REST connector, permalinks, the preview plugin, or Astro’s build? AstroPress ships a diagnostic tool, run via npm run doctor (CLI) or the /doctor dashboard (web), that checks seven categories end to end: environment configuration, WordPress connectivity, REST endpoint availability, permalink structure, the connector plugin’s installation state, SEO plugin detection, and the draft-preview handshake.\n\nThis is the kind of tooling that’s easy to skip in a minimal headless-WordPress tutorial and expensive to be missing once something breaks in a real deployment — a diagnostic that tells you *which* of the seven moving parts failed saves the alternative of manually checking each one under time pressure.\n\n## Performance Budgets Enforced in CI, Not Just Documented\n\nAstroPress declares performance budgets in a budget.json file and enforces them via npm run audit:perf in CI — per the README, blocking CSS bloat above roughly 25 KB and any accidental client-side JavaScript on editorial pages. The distinction that matters here: a performance budget that’s only a claim in a README is not a performance budget, it’s a hope. Enforcing it as a CI gate means a pull request that regresses the CSS payload or accidentally hydrates a component that should be static actually fails the build, instead of shipping and being caught (or not) later by whoever happens to run Lighthouse manually.\n\nThe project’s test suite backs this with 130+ tests via Vitest, per the README’s CLI reference table, covering the content-normalization and SEO-cascade logic that would otherwise be the most likely place for silent regressions.\n\n## Getting Started\n\nThe documented quickstart:",
      "description": "How AstroPress decouples WordPress as a pure editorial backend from an Astro static frontend — the content layer, the 4-tier SEO cascade, real-time draft preview, and the CI performance budgets that enforce it.",
      "keywords": [
        "wordpress",
        "that",
        "astropress",
        "plugin",
        "astro",
        "with",
        "from",
        "content",
        "static",
        "preview"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/blog/astropress-headless-wordpress-astro"
      }
    },
    {
      "id": "933d78b2dbd981cb",
      "url": "https://hdrx.com.br/blog/professional-website-development",
      "title": "Professional Website Development: The Technical Base That Makes a Site Sell — Hendrix Garcia (Part 1)",
      "content": "[← Back to all articles](/blog)**\n\nAugust 24, 2026• 8 min read\nWeb DevelopmentLanding PageBusiness WebsitesSEO\n\n## Professional Website Development: The Technical Base That Makes a Site Sell\n\nWhat separates a professional website from a site thrown together in a hurry in 2026 — real performance, presence in Google and in AI search, explained without excessive technical jargon.\n\nA professional website in 2026 needs to solve three things at once: actually load fast (not just “feel fast”), be findable both in Google and in the AI tools a growing number of people now use to search, and guide whoever lands on it toward a contact or a sale. Good design is part of that, but it’s the easiest part to get right — and the part that separates a site that converts the least from one that just exists.\n\nThis post explains, without forcing unnecessary technical terms, what actually goes into a well-built site today, why it matters for business outcomes, and where most sites — even the “pretty” ones — still leave money on the table.\n\n## Performance Isn’t an Opinion, It’s Measured\n\n“My site is fast” is a sentence anyone can say. Google measures it for real, with specific metrics — called Core Web Vitals — and uses that result both to judge the visitor’s experience and to rank the site in search. In practice, that boils down to a few things anyone can understand:\n\n- The page has to appear on screen quickly**, ideally under 2.5 seconds, even on an average mobile connection — not just on the fast office wi-fi the site was built on.\n\n- **Nothing should “jump” while it loads** — a button that shifts position, an image that pushes text around. It annoys the visitor, and Google penalizes it.\n\n- **The site has to respond quickly to touch**, without that half-second lag before a menu opens.",
      "description": "What separates a professional website from a site thrown together in a hurry in 2026 — real performance, presence in Google and in AI search, explained without excessive technical jargon.",
      "keywords": [
        "that",
        "site",
        "with",
        "what",
        "business",
        "google",
        "page",
        "project",
        "technical",
        "search"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 4,
        "sourcePath": "/blog/professional-website-development"
      }
    },
    {
      "id": "979d25c8acccb180",
      "url": "https://hdrx.com.br/pt-BR/projetos/prompt-pocket",
      "title": "Prompt Pocket — Estudo de caso · Hendrix Garcia (Part 2)",
      "content": "React 19TypeScriptVite 8@crxjs/vite-pluginTailwind CSSZodVitestChrome Extension · Manifest V3\n\n[← Sistema anteriorWOP - Plataforma de Operações Web](/pt-BR/projetos/wop)[Próximo sistema →Jumbox](/pt-BR/projetos/jumbox)\n\nHDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Extensão Chrome privada para salvar, organizar e reutilizar prompts de IA entre ferramentas.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "prompt",
        "chrome",
        "prompts",
        "servidor",
        "conectar",
        "perfil",
        "todos"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/prompt-pocket"
      }
    },
    {
      "id": "988935294089e365",
      "url": "https://hdrx.com.br/pt-BR/conectar",
      "title": "Conectar via MCP — Hendrix Garcia (Part 3)",
      "content": "O Hendrix pode ajudar com performance, migrações ou problemas em produção?Sim. O trabalho documentado inclui otimização de performance, Core Web Vitals, SEO técnico, replicação de sites, migração, deploy e troubleshooting de plugins, temas, bancos de dados, URLs e redirecionamentos.\n\nO que devo incluir ao entrar em contato?Envie o problema ou a vaga, o escopo que quer discutir, a stack ou ambiente atual e qualquer prazo relevante. O formulário aceita contatos de recrutamento em tempo integral, consultoria ou contrato e conversas de engenharia.",
      "description": "Conecte um agente de IA ao portfólio de Hendrix Garcia por MCP e APIs estruturadas.",
      "keywords": [
        "hendrix",
        "wordpress",
        "endpoint",
        "desenvolvedor",
        "para",
        "portfólio",
        "agents",
        "contact",
        "woocommerce",
        "pode"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/conectar"
      }
    },
    {
      "id": "9c1a1c7f09f71b31",
      "url": "https://hdrx.com.br/pt-BR/blog/criacao-de-sites-profissionais",
      "title": "Criação de Sites Profissionais: A Base Técnica Que Faz o Site Vender — Hendrix Garcia (Part 2)",
      "content": "Sites feitos em construtores genéricos ou com excesso de plugins/scripts costumam falhar justamente aqui — não porque o design é ruim, mas porque carregam uma quantidade grande de código desnecessário antes de mostrar qualquer coisa útil. Isso é mensurável, não é questão de gosto.\n\n## Ser Encontrado: Google e as Novas Buscas por IA\n\nAparecer bem no Google continua sendo a base — hierarquia de conteúdo organizada, título e descrição bem escritos, site rápido, link interno entre as páginas. Isso não mudou.\n\nO que mudou é que uma parte cada vez maior das pessoas está pesquisando direto no ChatGPT, no Perplexity ou nas respostas de IA que já aparecem no topo do Google, em vez de clicar numa lista de links. Esses sistemas leem o site e tentam entender, de forma automática, quem é a empresa e o que ela oferece — e um site organizado de um jeito que essa leitura automática consegue captar corretamente tem mais chance de ser citado como resposta.\n\nNa prática isso significa: informações da empresa (nome, serviço, área de atuação) escritas de forma clara e estruturada no código da página, não só dentro de uma imagem ou de um texto solto no rodapé. É um ajuste técnico relativamente barato de fazer durante a construção do site — e a maioria dos sites feitos sem essa preocupação simplesmente não tem essa informação organizada de um jeito que a IA consiga ler direito.\n\nNão é mágica nem substitui SEO tradicional — é uma camada a mais, que só faz sentido depois que o básico (velocidade, estrutura, conteúdo relevante) já está resolvido.\n\n## Da Visita ao Contato\n\nDe nada adianta o site carregar rápido e aparecer bem nas buscas se, quando a pessoa chega, não fica claro o que fazer em seguida. Os pontos que mais pesam aqui:\n\n- Um caminho direto e visível para falar com a empresa — WhatsApp, formulário ou telefone, sem esconder atrás de múltiplos cliques.",
      "description": "O que diferencia um site profissional de um site montado às pressas em 2026 — performance real, presença no Google e nas buscas por IA, explicado sem jargão técnico excessivo.",
      "keywords": [
        "para",
        "site",
        "não",
        "pt-br",
        "mais",
        "rápido",
        "contato",
        "google",
        "isso",
        "negócio"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 4,
        "sourcePath": "/pt-BR/blog/criacao-de-sites-profissionais"
      }
    },
    {
      "id": "a5d173ccb065316e",
      "url": "https://hdrx.com.br/about",
      "title": "About Hendrix Garcia (Part 2)",
      "content": "- ▸Founded and operates a web development agency, delivering 60+ projects across multiple client segments\n- ▸Development of websites, landing pages, blogs, and e-commerce stores\n- ▸Customization of WordPress themes, plugins, Elementor, forms, and hooks\n- ▸Interface development with React, TypeScript, Next.js, and Tailwind CSS\n- ▸Backend implementation with PHP, Laravel, Supabase, SQL, and REST APIs\n- ▸Integrations with CRM, WhatsApp, payment gateways, analytics, and webhooks\n- ▸Automation with n8n, Make, and AI tools\n- ▸Hosting, domains, SSL, Docker, Cloudflare, and production setup\n- ▸Scope management, client relationships, and documentation\n\n- WordPress\n- WooCommerce\n- PHP\n- JavaScript\n- TypeScript\n- React\n- Next.js\n- Astro\n- Laravel\n- Supabase\n- MySQL\n- PostgreSQL\n- Docker\n- Git\n- REST APIs\n- n8n\n- Make\n- GA4\n- GTM\n\n- WordPress\n- WooCommerce\n- PHP\n- JavaScript\n- TypeScript\n- React\n- Next.js\n- Astro\n- Laravel\n- Supabase\n- MySQL\n- PostgreSQL\n- Docker\n- Git\n- REST APIs\n- n8n\n- Make\n- GA4\n- GTM\n\n### Freelance WordPress Developer & Web Designer @ Workana\n\nJul 2019 – Oct 2022\n\n- ▸80+ projects delivered: institutional sites, landing pages, online stores, and custom solutions\n- ▸WordPress, WooCommerce, and Elementor customization\n- ▸Frontend development with HTML, CSS, JavaScript, and React\n- ▸Backend and integrations with PHP, Laravel, SQL, and REST APIs\n- ▸Hosting, domain, and SSL setup for production environments\n- ▸Site migration, maintenance, and bug fixing\n- ▸Performance optimization, technical SEO, and load time improvements\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- Laravel\n- JavaScript\n- React\n- HTML\n- CSS\n- MySQL\n- SQL\n- Git\n- REST APIs\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- Laravel\n- JavaScript\n- React\n- HTML\n- CSS\n- MySQL\n- SQL\n- Git\n- REST APIs\n\n[02]\n\n## Technical Capabilities Matrix\n\n### // Frontend\n\nReactNext.jsAstroTypeScriptTailwind CSSHTMLCSS\n\n### // Backend\n\nNode.jsPHPLaravelSupabaseMySQLPostgreSQLREST APIs\n\n### // CMS & E-commerce",
      "description": "Professional background, technical capabilities, and approach to product engineering.",
      "keywords": [
        "wordpress",
        "with",
        "woocommerce",
        "react",
        "javascript",
        "laravel",
        "elementor",
        "apis",
        "developer",
        "development"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 3,
        "sourcePath": "/about"
      }
    },
    {
      "id": "a61d6a5c8fe588b2",
      "url": "https://hdrx.com.br/pt-BR",
      "title": "Hendrix Garcia — Engenheiro de Produto Full-Stack (Part 3)",
      "content": "O Hendrix pode criar ou evoluir um site em WordPress ou WooCommerce?Sim. A experiência documentada de Hendrix com WordPress inclui Desenvolvedor WordPress e WooCommerce na HempHealthOnline (mar. de 2026 – Presente); Fundador e Desenvolvedor Web Full-Stack na CONEX.HUB (jan. de 2022 – Presente); Desenvolvedor WordPress Freelancer e Web Designer na Workana (jul. de 2019 – out. de 2022). Isso abrange desenvolvimento, customização, manutenção, migração e troubleshooting em WordPress e WooCommerce.\n\nO Hendrix pode trabalhar em um produto full-stack ou aplicação web?Sim. A stack documentada inclui React, Next.js, Astro, TypeScript, Tailwind CSS, HTML, CSS no frontend e Node.js, PHP, Laravel, Supabase, MySQL, PostgreSQL, APIs REST no backend. Sistemas relevantes no portfólio incluem Portfólio Preparado para Agentes e WOP - Plataforma de Operações Web e Prompt Pocket e Jumbox e Web Ready.\n\nO Hendrix integra IA, automação ou serviços de terceiros?Sim. Hendrix trabalha com API Claude, MCP, n8n, Make, Agentes de IA, Webhooks e tem integrações documentadas com CRM, WhatsApp, gateways de pagamento, analytics e webhooks. Sistemas relevantes no portfólio incluem Portfólio Preparado para Agentes e Prompt Pocket e Web Ready.\n\nO Hendrix pode ajudar com performance, migrações ou problemas em produção?Sim. O trabalho documentado inclui otimização de performance, Core Web Vitals, SEO técnico, replicação de sites, migração, deploy e troubleshooting de plugins, temas, bancos de dados, URLs e redirecionamentos.\n\nO que devo incluir ao entrar em contato?Envie o problema ou a vaga, o escopo que quer discutir, a stack ou ambiente atual e qualquer prazo relevante. O formulário aceita contatos de recrutamento em tempo integral, consultoria ou contrato e conversas de engenharia.\n\n// Camada de agente autônomo\n\n### Este site fala MCP\n(Model Context Protocol)",
      "description": "Engenheiro de Produto Full-Stack que desenvolve produtos web rápidos, confiáveis e sistemas com IA.",
      "keywords": [
        "para",
        "pt-br",
        "wordpress",
        "typescript",
        "hendrix",
        "projetos",
        "react",
        "tailwind",
        "desenvolvedor",
        "conectar"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 4,
        "sourcePath": "/pt-BR"
      }
    },
    {
      "id": "aa6bb4924131328c",
      "url": "https://hdrx.com.br/blog/woocommerce-performance-ttfb",
      "title": "WooCommerce TTFB Optimization: The Complete Guide to Sub-300ms Stores — Hendrix Garcia (Part 4)",
      "content": "It converts repeated MySQL reads (options, transients, product meta, term relationships) into sub-millisecond Redis lookups shared across all PHP-FPM workers. This is the single highest-leverage change available on most WooCommerce installs, because WordPress core and WooCommerce both already call wp_cache_get()/wp_cache_set() extensively — you just need a persistent backend behind those calls.\n\nSetup with the redis-cache drop-in:\n\nwp plugin install redis-cache --activate\nwp redis enable\n// wp-config.php\ndefine('WP_REDIS_HOST', '127.0.0.1');\ndefine('WP_REDIS_PORT', 6379);\ndefine('WP_REDIS_TIMEOUT', 1);\ndefine('WP_REDIS_READ_TIMEOUT', 1);\ndefine('WP_REDIS_DATABASE', 0);\ndefine('WP_CACHE', true);\nVerify it’s actually connected, not silently falling back to non-persistent cache:\n\nwp redis status\n\n### Redis vs Memcached for WooCommerce — which one?\n\n- **Redis** supports persistence, key expiration introspection, and — critically for WooCommerce — **cache groups with pattern-based flushing**, which matters when a plugin needs to invalidate all product-related keys after a stock update without flushing the entire cache. This is why it’s the de facto standard for WooCommerce object caching.\n\n- **Memcached** is marginally faster for pure key-value gets under some benchmarks but has no persistence and weaker introspection tooling. Use it only if Redis isn’t available in your hosting environment.\n\n### The WooCommerce session gotcha",
      "description": "A deep technical guide to WooCommerce Time to First Byte: Redis object caching, HPOS, Action Scheduler bottlenecks, autoloaded options, PHP-FPM tuning, and edge caching for high-traffic stores.",
      "keywords": [
        "woocommerce",
        "cache",
        "redis",
        "object",
        "caching",
        "time",
        "this",
        "cart",
        "queries",
        "query"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/blog/woocommerce-performance-ttfb"
      }
    },
    {
      "id": "ad88c69baa1f0af5",
      "url": "https://hdrx.com.br/projects/prompt-pocket",
      "title": "Prompt Pocket — Case Study · Hendrix Garcia (Part 1)",
      "content": "[← Back to all projects](/projects)\n\n// ai Featured System\n\n## Prompt Pocket\n\nPrivacy-first Chrome extension to save, organize, and instantly reuse AI prompts across tools.\n\n[Source Code ↗](#)[Discuss Similar Project](/contact)\n\n[01] Problem Statement & Context\n\n## The Challenge\n\nAI users end up rewriting or hunting through old chats for the same prompts over and over, across every site and tool they use. Generic notes apps don't understand prompt structure — no reusable variables, no per-prompt organization — and syncing a prompt library through someone else's server means trusting them with everything you've ever asked an AI.\n\n[02] Technical Architecture & Solution\n\n## Engineering Delivery\n\nBuilt Prompt Pocket, a Manifest V3 Chrome extension using a side panel instead of a popup, so the library stays open alongside whatever page you're working in. Prompts support {{variable}} placeholders filled in per use, with categories, tags, favorites, and usage-based sorting, and insert directly into the focused input, textarea, or contenteditable field of the active tab in two clicks. Everything lives in chrome.storage.local — no accounts, no analytics, no server. What started as a working-but-fragile extension was hardened through a systematic audit: the content script injects on-demand via chrome.scripting.executeScript scoped to activeTab (no host_permissions, no <all_urls>), every storage read is validated against a Zod schema with a versioned migration path, writes always re-read storage first to stay race-safe across multiple open side panels, and the UI stays accessible by default (native <dialog>, associated labels, aria-labels on icon-only buttons).\n\n[03] Technology Stack & Utilities\n\nReact 19TypeScriptVite 8@crxjs/vite-pluginTailwind CSSZodVitestChrome Extension · Manifest V3\n\n[← Previous SystemWOP - Web Operations Platform](/projects/wop)[Next System →Jumbox](/projects/jumbox)",
      "description": "Privacy-first Chrome extension to save, organize, and instantly reuse AI prompts across tools.",
      "keywords": [
        "projects",
        "prompt",
        "chrome",
        "extension",
        "server",
        "with",
        "connect",
        "profile",
        "prompts",
        "across"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects/prompt-pocket"
      }
    },
    {
      "id": "adb087b96786bae8",
      "url": "https://hdrx.com.br/blog/professional-website-development",
      "title": "Professional Website Development: The Technical Base That Makes a Site Sell — Hendrix Garcia (Part 3)",
      "content": "- Flawless performance on mobile, since most traffic arrives there first.\n\n## How I Work\n\nI’m a full-stack developer and I build sites — institutional sites, landing pages, blogs, systems with integrations — on this exact technical base from the start of the project: measured performance (not estimated), structure built for both Google and AI systems, and a clear path to contact. Every project is built for the specific business, not adapted from a generic template.\n\nYou can see real projects I’ve delivered on the [projects page](/projects).\n\n## Frequently Asked Questions\n\n### How much does a professional website cost?\n\nIt depends on the type of project — a landing page is simpler and faster than a full institutional site or a system with integrations. Tell me what you need and I’ll come back with a specific number for your case.\n\n### How long does it take to build?\n\nA well-built landing page usually ships in a few days. Larger projects, with more pages and original content, take a few weeks — I give you the exact timeline at the start of the conversation, not after.\n\n### Does this apply to a small business, or only to larger companies?\n\nIt applies mainly to small and mid-sized businesses, because they’re the ones losing the most visitors to a competitor with a faster, better-organized site in search. It doesn’t need to be a big project — it needs to be technically well-built.\n\n### Do you build landing pages for launches or campaigns?\n\nYes, and it’s usually the fastest-turnaround type of project, since the campaign already has a start date.\n\n### I don’t understand anything about technology — can you explain it without technical terms?\n\nYes, and that’s how I work with clients outside the field: I explain what’s being done and why it matters for your business, without expecting you to understand code or SEO.\n\n---",
      "description": "What separates a professional website from a site thrown together in a hurry in 2026 — real performance, presence in Google and in AI search, explained without excessive technical jargon.",
      "keywords": [
        "that",
        "site",
        "with",
        "what",
        "business",
        "google",
        "page",
        "project",
        "technical",
        "search"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 4,
        "sourcePath": "/blog/professional-website-development"
      }
    },
    {
      "id": "adfd523caa092816",
      "url": "https://hdrx.com.br/projects/jumbox",
      "title": "Jumbox — Case Study · Hendrix Garcia (Part 2)",
      "content": "- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Private, local-first file transfer system with resumable streaming and end-to-end integrity.",
      "keywords": [
        "with",
        "projects",
        "transfer",
        "github",
        "files",
        "connect",
        "profile",
        "system",
        "jumbox",
        "code"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects/jumbox"
      }
    },
    {
      "id": "b05b1795ac82003f",
      "url": "https://hdrx.com.br/pt-BR/blog/engenharia-de-prompts-como-codigo",
      "title": "Engenharia de prompts como código: versionamento, testes e CI/CD para prompts de LLMs — Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os artigos](/pt-BR/blog)**\n\n5 de agosto de 2026• 16 min de leitura\nAIPrompt EngineeringLLMTypeScriptNext.jsCI/CDEval\n\n## Engenharia de prompts como código: versionamento, testes e CI/CD para prompts de LLMs\n\nUm framework prático para tratar prompts como artefatos de software — versionamento semântico, saída estruturada validada por Zod, suítes de eval de regressão e gates de CI/CD, a partir da arquitetura do Prompt Pocket.\n\nA maior parte das equipes que executa LLMs em produção ainda administra prompts como strings soltas — inline no código da aplicação, espalhadas por arquivos .env ou editadas diretamente no dashboard de um fornecedor, sem diff, revisão ou suíte de testes. Isso funciona até deixar de funcionar: um “pequeno ajuste de texto” quebra silenciosamente o parsing de saída estruturada, uma atualização de modelo altera tom ou formato sem ninguém perceber, ou um agente de suporte encontra um jailbreak três semanas antes da engenharia.\n\nPrompt Engineering as Code (PEaC)** trata o prompt como artefato de software versionado, testável e revisável — sujeito à mesma disciplina de qualquer código que chega à produção: contratos de schema, suítes de regressão, code review e gates de CI/CD. Esta é a arquitetura do projeto **Prompt Pocket**; o restante deste post detalha o raciocínio, os modos de falha que ela evita e os detalhes de implementação que importam depois de um protótipo de brinquedo.\n\n## Por que prompts precisam de disciplina de engenharia de software\n\n### O que quebra quando prompts são tratados como strings, e não como artefatos?\n\nQuatro modos de falha aparecem de modo recorrente em sistemas LLM de produção que ignoram essa disciplina:\n\n- **Deriva comportamental silenciosa** — um prompt editado em dashboard muda o comportamento downstream sem code review, diff visível ou verificação automatizada de que formato e qualidade permaneceram estáveis.",
      "description": "Um framework prático para tratar prompts como artefatos de software — versionamento semântico, saída estruturada validada por Zod, suítes de eval de regressão e gates de CI/CD, a partir da arquitetura do Prompt Pocket.",
      "keywords": [
        "prompt",
        "não",
        "para",
        "saída",
        "modelo",
        "schema",
        "como",
        "validação",
        "json",
        "versão"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/engenharia-de-prompts-como-codigo"
      }
    },
    {
      "id": "b271c7a5bbadaf18",
      "url": "https://hdrx.com.br/projects/web-ready",
      "title": "Web Ready — Case Study · Hendrix Garcia (Part 2)",
      "content": "HDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "An open-source website auditor for Technical SEO, AI readiness, and fundamental web health.",
      "keywords": [
        "projects",
        "technical",
        "readiness",
        "https",
        "github",
        "connect",
        "profile",
        "system",
        "ready",
        "health"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects/web-ready"
      }
    },
    {
      "id": "b43b78fa50dd7327",
      "url": "https://hdrx.com.br/blog/astropress-headless-wordpress-astro",
      "title": "AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS — Hendrix Garcia (Part 1)",
      "content": "[← Back to all articles](/blog)**\n\nAugust 24, 2026• 12 min read\nAstroWordPressHeadless CMSOpen SourcePerformance\n\n## AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS\n\nHow AstroPress decouples WordPress as a pure editorial backend from an Astro static frontend — the content layer, the 4-tier SEO cascade, real-time draft preview, and the CI performance budgets that enforce it.\n\nAstroPress is an open-source starter that decouples WordPress from page rendering: WordPress stays a pure editorial backend — Gutenberg, taxonomies, media library — while Astro queries the WordPress REST API entirely at build time and compiles static HTML/CSS for the edge, shipping 0 KB of client-side JavaScript by default on editorial pages. The project is [on GitHub](https://github.com/hd-rx8/AstroPress) under the MIT license.\n\nThe problem it targets is a specific and common one: WordPress is genuinely good as a content-editing experience for non-technical authors, and genuinely bad as a page-rendering runtime once traffic or performance requirements get serious. Most “headless WordPress” writeups stop at “call the REST API from your frontend.” AstroPress goes further — it’s an opinionated, batteries-included stack with a real content-normalization layer, a companion WordPress plugin for authenticated draft preview, enforced performance budgets in CI, and a diagnostic tool that checks the whole pipeline end to end.\n\n## Why Decouple WordPress From Rendering at All\n\nA conventional WordPress theme executes PHP on every request: bootstrap WordPress, run every active plugin’s hooks, query MySQL for the post and its metadata, render a template, and only then send HTML. Under load, or with a heavy plugin stack, that path is where most WordPress performance problems originate — not the frontend.",
      "description": "How AstroPress decouples WordPress as a pure editorial backend from an Astro static frontend — the content layer, the 4-tier SEO cascade, real-time draft preview, and the CI performance budgets that enforce it.",
      "keywords": [
        "wordpress",
        "that",
        "astropress",
        "plugin",
        "astro",
        "with",
        "from",
        "content",
        "static",
        "preview"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 5,
        "sourcePath": "/blog/astropress-headless-wordpress-astro"
      }
    },
    {
      "id": "b9612fc8f2b976b3",
      "url": "https://hdrx.com.br/pt-BR/blog/criacao-de-sites-profissionais",
      "title": "Criação de Sites Profissionais: A Base Técnica Que Faz o Site Vender — Hendrix Garcia (Part 3)",
      "content": "- Textos organizados por prioridade: o que o negócio resolve primeiro, os detalhes depois — não um parágrafo institucional genérico antes de qualquer informação útil.\n\n- Funcionamento perfeito no celular, já que a maior parte do tráfego chega por lá primeiro.\n\n## Como Eu Trabalho\n\nEu sou desenvolvedor full-stack e construo sites — institucionais, landing pages, blogs, sistemas com integração — usando essa base técnica desde o início do projeto: performance medida (não estimada), estrutura pensada para Google e para os sistemas de IA, e um caminho claro até o contato. Cada projeto é montado para o negócio específico, não adaptado de um template genérico.\n\nVocê pode ver projetos reais que já entreguei na [página de projetos](/pt-BR/projetos).\n\n## Perguntas Frequentes\n\n### Quanto custa um site profissional?\n\nDepende do tipo de projeto — uma landing page é mais simples e rápida do que um site institucional completo ou um sistema com integrações. Me conta o que você precisa e eu retorno com um valor específico para o seu caso.\n\n### Quanto tempo leva para ficar pronto?\n\nUma landing page bem-feita costuma sair em poucos dias. Projetos maiores, com mais páginas e conteúdo próprio, levam algumas semanas — o prazo exato eu já te passo no início da conversa, não depois.\n\n### Isso vale para negócio pequeno, ou só para empresa grande?\n\nVale principalmente para negócio pequeno e médio, porque é quem mais perde visitante para um concorrente com site mais rápido e mais bem-organizado nas buscas. Não precisa ser um projeto grande — precisa ser tecnicamente bem-feito.\n\n### Você faz landing page para lançamento ou campanha?\n\nFaço, e costuma ser o tipo de projeto com prazo mais curto, porque a campanha já tem data para começar.\n\n### Não entendo nada de tecnologia — dá pra explicar sem termo técnico?\n\nDá, e é assim que eu trabalho com quem não é da área: eu explico o que está sendo feito e por que importa pro seu negócio, sem esperar que você entenda de código ou de SEO.\n\n---",
      "description": "O que diferencia um site profissional de um site montado às pressas em 2026 — performance real, presença no Google e nas buscas por IA, explicado sem jargão técnico excessivo.",
      "keywords": [
        "para",
        "site",
        "não",
        "pt-br",
        "mais",
        "rápido",
        "contato",
        "google",
        "isso",
        "negócio"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 4,
        "sourcePath": "/pt-BR/blog/criacao-de-sites-profissionais"
      }
    },
    {
      "id": "bc8b781844e6d42d",
      "url": "https://hdrx.com.br/about",
      "title": "About Hendrix Garcia (Part 1)",
      "content": "Engineering Profile\n\n## About & ExperienceAbout & Experience\n\nFull-stack developer with 7+ years building for the web, combining freelance work through Workana with founding CONEX.HUB in 2022. Specializes in WordPress/WooCommerce in production environments — development, migration, performance, and troubleshooting — backed by a modern stack (TypeScript, React, Next.js, Supabase, Astro, Laravel). Combines technical execution with product and automation thinking, understanding the business problem before proposing a technical solution.\n\n[01]\n\n## Career Timeline & Deliveries\n\n### WordPress & WooCommerce Developer @ HempHealthOnline\n\nMar 2026 – Present\n\n- ▸Ongoing maintenance of multiple production WordPress sites\n- ▸Customization with Elementor, PHP, JavaScript, HTML, and CSS\n- ▸Administration of multiple WordPress environments on Docker infrastructure\n- ▸Site replication, migration, and deployment across different servers\n- ▸Troubleshooting plugins, themes, databases, URLs, and redirects\n- ▸Performance optimization, Core Web Vitals, and technical SEO\n- ▸Version control with Git and technical documentation\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- JavaScript\n- HTML\n- CSS\n- MySQL\n- Docker\n- Git\n\n- WordPress\n- WooCommerce\n- Elementor\n- PHP\n- JavaScript\n- HTML\n- CSS\n- MySQL\n- Docker\n- Git\n\n### Founder & Full-Stack Web Developer @ CONEX.HUB\n\nJan 2022 – Present",
      "description": "Professional background, technical capabilities, and approach to product engineering.",
      "keywords": [
        "wordpress",
        "with",
        "woocommerce",
        "react",
        "javascript",
        "laravel",
        "elementor",
        "apis",
        "developer",
        "development"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 3,
        "sourcePath": "/about"
      }
    },
    {
      "id": "becdfe56e471c3a2",
      "url": "https://hdrx.com.br/blog/astropress-headless-wordpress-astro",
      "title": "AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS — Hendrix Garcia (Part 3)",
      "content": "Real WordPress sites accumulate SEO metadata from multiple, often conflicting sources: a dedicated SEO plugin, native WordPress fields, and site-wide defaults, not always kept in sync with each other. AstroPress’s README describes an “intelligent metadata cascade” that resolves this deterministically: **Yoast SEO → Rank Math → native WP fields → site defaults**, falling through to the next source only when the current one has nothing set, and feeding the result into Schema.org JSON-LD graphs (BlogPosting, BreadcrumbList, WebSite).\n\nThe practical benefit is that migrating between SEO plugins, or running a site that started with native WP fields and later added Yoast, doesn’t produce silently missing metadata — the cascade always resolves to *something*, in a predictable priority order, instead of requiring every template to special-case which plugin happens to be active.\n\n## Image Pipeline and Draft Preview\n\nRemote media from WordPress is compiled through Astro’s astro:assets pipeline into responsive WebP/AVIF at build time, with explicit width and height attributes set so the browser can reserve layout space before the image loads — the direct mechanism for keeping Cumulative Layout Shift at zero, rather than relying on lazy-loading alone to mask the problem.\n\nStatic generation has one structural gap: editors can’t see unpublished drafts on a site that only builds from published content. AstroPress’s answer is a companion WordPress plugin, astropress-connector, that performs a tokenized handshake with an on-demand SSR route in Astro — a narrow, purpose-built exception to the static-by-default rule, scoped specifically to preview rather than left open as a general SSR escape hatch. An editor gets real-time preview of unpublished content without the project giving up its default of shipping publish-time static HTML for everything else.\n\n## Headless Doctor: Diagnosing the Full Pipeline",
      "description": "How AstroPress decouples WordPress as a pure editorial backend from an Astro static frontend — the content layer, the 4-tier SEO cascade, real-time draft preview, and the CI performance budgets that enforce it.",
      "keywords": [
        "wordpress",
        "that",
        "astropress",
        "plugin",
        "astro",
        "with",
        "from",
        "content",
        "static",
        "preview"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/blog/astropress-headless-wordpress-astro"
      }
    },
    {
      "id": "bee343c6ab2c5260",
      "url": "https://hdrx.com.br/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce",
      "title": "Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms — Hendrix Garcia (Part 2)",
      "content": "- Páginas **Minha conta** são inerentemente por usuário e não podem ser cacheadas publicamente.\n\n- Páginas de **catálogo com preço dinâmico** (preço por perfil, flash sale, mensagens dependentes de estoque) invalidam regras ingênuas de cache.\n\nÉ por isso que simplesmente aplicar uma configuração genérica de cache WordPress a uma loja WooCommerce produz carrinhos quebrados ou preços desatualizados, e não só ganhos de performance perdidos. Toda otimização abaixo precisa respeitar essa divisão entre conteúdo cacheável e não cacheável.\n\n## Diagnosticando TTFB antes de otimizá-lo\n\nNão adivinhe. Otimizar no escuro desperdiça tempo de engenharia na camada errada.\n\n### Como medir onde o TTFB está sendo gasto de fato?\n\nAdicione headers **Server-Timing** em cada etapa do bootstrap (banco, object cache, render de template) e leia-os na aba Network do navegador ou com curl -w:\n\n// mu-plugins/server-timing.php\nadd_action('plugins_loaded', function () {\n$GLOBALS['__ts_start'] = microtime(true);\n});\n\nadd_action('shutdown', function () {\nif (!headers_sent() && isset($GLOBALS['__ts_start'])) {\n$elapsed = (microtime(true) - $GLOBALS['__ts_start']) * 1000;\nheader(sprintf('Server-Timing: wp-total;dur=%.2f', $elapsed));\n}\n});\nPara uma checagem rápida em CLI, sem overhead do navegador:\n\ncurl -o /dev/null -s -w \"DNS: %{time_namelookup}s | TCP: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\\n\" https://store.example.com/cart/\n\n### Como encontrar plugin ou query lenta?\n\nInstale **Query Monitor** num ambiente de staging com volume de dados parecido com produção (não uma instalação nova com 10 produtos de teste; comportamento de índice e cache hit só aparece em escala realista). Observe:\n\n- O painel **Queries**, ordenado por tempo e filtrado por componente, que atribui consultas lentas ao plugin ou função de tema que as disparou.",
      "description": "Um guia técnico aprofundado para Time to First Byte no WooCommerce: cache de objetos Redis, HPOS, gargalos do Action Scheduler, opções autocarregadas, ajuste de PHP-FPM e cache edge para lojas de alto tráfego.",
      "keywords": [
        "cache",
        "não",
        "woocommerce",
        "redis",
        "para",
        "ttfb",
        "object",
        "query",
        "time",
        "páginas"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/otimizacao-de-ttfb-no-woocommerce"
      }
    },
    {
      "id": "c17327d199486d12",
      "url": "https://hdrx.com.br/pt-BR/projetos",
      "title": "Projetos — Hendrix Garcia (Part 3)",
      "content": "- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Um catálogo estruturado de software em produção, integrações de agentes de IA e infraestrutura de alta performance projetados para gerar impacto mensurável nos negócios.",
      "keywords": [
        "pt-br",
        "projetos",
        "typescript",
        "para",
        "github",
        "caso",
        "react",
        "tailwind",
        "https",
        "destaque"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 3,
        "sourcePath": "/pt-BR/projetos"
      }
    },
    {
      "id": "c51b59a16e5d7e05",
      "url": "https://hdrx.com.br/blog/prompt-engineering-as-code",
      "title": "Prompt Engineering as Code: Versioning, Testing, and CI/CD for LLM Prompts — Hendrix Garcia (Part 4)",
      "content": "- **A migration path when the contract changes.** Schema changes become explicit diffs reviewable in a PR, not implicit renegotiations between prompt text and downstream parsing code that happen to still work.\n\n### Structured Output: Tool-Calling Mode vs. JSON-Mode System Prompt\n\nTwo ways to get structured output, with different reliability profiles:\n\n- **Native tool/function calling** (Claude’s tool use, OpenAI’s function calling) — the model is constrained toward a schema at the API level. Higher adherence, works well for nested and strict enum schemas, and integrates naturally with a schema library like Zod when you generate the tool definition from the same schema you validate against.\n\n- **JSON-mode via system prompt instruction** (“respond only with valid JSON matching this shape”) — lower reliability, more prone to prose leakage or malformed brackets, but necessary when the workflow doesn’t fit a tool-call shape (e.g., the “tool” *is* the final answer, not an intermediate action). Always pair this with runtime validation and a retry-with-error-feedback loop, not blind trust.\n\nPrefer tool-calling for anything with a strict schema and low failure tolerance; reserve JSON-mode prompting for cases where tool-calling semantics don’t map cleanly onto the task.\n\n### Handling Validation Failures: Retry Strategy\n\nA validation failure isn’t necessarily terminal. A pragmatic retry ladder:\n\n- **Re-prompt with the validation error appended** — feed the Zod/Pydantic error message back to the model as context (“your previous response failed validation: findings[0].severity must be one of critical/important/minor, got ‘high’”) and request a corrected response. This resolves the majority of transient format failures because the model can self-correct given specific feedback.\n\n- **Fall back to a stricter extraction prompt** — if retry #1 fails, drop to a narrower, single-purpose prompt whose only job is reformatting the previous raw output into the schema.",
      "description": "A practical framework for treating prompts as software artifacts — semantic versioning, Zod-validated structured output, regression eval suites, and CI/CD gating, built from the Prompt Pocket architecture.",
      "keywords": [
        "prompt",
        "output",
        "with",
        "model",
        "schema",
        "this",
        "that",
        "code",
        "validation",
        "from"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/blog/prompt-engineering-as-code"
      }
    },
    {
      "id": "c71f84711d910eca",
      "url": "https://hdrx.com.br/pt-BR/projetos/jumbox",
      "title": "Jumbox — Estudo de caso · Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os projetos](/pt-BR/projetos)\n\n// fullstack Sistema em destaque\n\n## Jumbox\n\nSistema privado e local-first de transferência de arquivos, com streaming retomável e integridade ponta a ponta.\n\n[Código-fonte ↗](https://github.com/hd-rx8/jumbox)[Falar sobre projeto semelhante](/pt-BR/contato)\n\n[01] Declaração do problema e contexto\n\n## O desafio\n\nCompartilhar arquivos na mesma rede local ou Wi-Fi ainda costuma significar rotear tudo por um serviço de nuvem de terceiros, e quando uma transferência grande é interrompida, é preciso recomeçar do zero — não existe uma forma direta e privada de simplesmente enviar arquivos de uma máquina para outra na rede com resiliência embutida.\n\n[02] Arquitetura técnica e solução\n\n## Entrega de engenharia\n\nO Jumbox foi construído como um serviço FastAPI self-hosted com um modelo de domínio em camadas (um agregado TransferSession que gerencia entidades TransferItem), expondo sessões de transferência multi-arquivo sob um código de 8 dígitos ou QR code que outros dispositivos na rede local podem escanear. Os uploads usam um protocolo de chunks retomável (PATCH .../chunks com sondagem via Upload-Offset) que sobrevive a quedas de rede sem retransmitir bytes já aceitos, com novas tentativas automáticas usando backoff exponencial. Cada transferência é verificada ponta a ponta via SHA-256 com headers de checksum e ETag, os downloads fazem streaming direto para o disco com suporte a Accept-Ranges para evitar buffer de arquivos grandes em memória, e um modo efêmero opcional apaga os arquivos do disco assim que o destinatário faz o download. Roda sem configuração em SQLite para uso standalone ou em Postgres via Docker Compose para uma stack de produção, com SQLAlchemy 2.0 e migrações Alembic por baixo.\n\n[03] Stack de tecnologia e utilitários\n\nPythonFastAPISQLAlchemy 2.0AlembicSQLite / PostgreSQLDocker Compose\n\n[← Sistema anteriorPrompt Pocket](/pt-BR/projetos/prompt-pocket)[Próximo sistema →AstroPress](/pt-BR/projetos/astropress)",
      "description": "Sistema privado e local-first de transferência de arquivos, com streaming retomável e integridade ponta a ponta.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "arquivos",
        "sistema",
        "transferência",
        "ponta",
        "github",
        "rede",
        "conectar"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/jumbox"
      }
    },
    {
      "id": "c92d54a3d8f1033a",
      "url": "https://hdrx.com.br/pt-BR/blog/criacao-de-sites-profissionais",
      "title": "Criação de Sites Profissionais: A Base Técnica Que Faz o Site Vender — Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os artigos](/pt-BR/blog)**\n\n24 de agosto de 2026• 8 min de leitura\nCriação de SitesLanding PageSites para EmpresasSEO\n\n## Criação de Sites Profissionais: A Base Técnica Que Faz o Site Vender\n\nO que diferencia um site profissional de um site montado às pressas em 2026 — performance real, presença no Google e nas buscas por IA, explicado sem jargão técnico excessivo.\n\nUm site profissional em 2026 precisa resolver três coisas ao mesmo tempo: carregar rápido de verdade (não “parece rápido”), ser encontrado tanto no Google quanto nas ferramentas de IA que cada vez mais pessoas usam para pesquisar, e conduzir quem chega até um contato ou uma venda. Design bonito é parte disso, mas é a parte mais fácil de acertar — e a que menos separa um site que converte de um que só existe.\n\nEste post explica, sem forçar termo técnico desnecessário, o que realmente entra num site bem construído hoje, por que isso pesa no resultado do negócio, e onde a maioria dos sites — mesmo os “bonitos” — ainda deixa dinheiro na mesa.\n\n## Performance Não é Opinião, é Medido\n\n“Meu site é rápido” é uma frase que qualquer um pode dizer. O Google mede isso de verdade, com métricas específicas — chamadas de Core Web Vitals — e usa esse resultado tanto para decidir a experiência do visitante quanto para ranquear o site nas buscas. Na prática, isso se traduz em coisas simples de entender:\n\n- A página tem que aparecer rápido na tela**, idealmente em menos de 2,5 segundos, mesmo numa conexão de celular mediana — não só no wi-fi rápido do escritório de quem fez o site.\n\n- **Nada pode “pular” enquanto carrega** — botão que muda de lugar, imagem que empurra o texto. Isso irrita o visitante e o Google penaliza.\n\n- **O site precisa responder rápido ao toque**, sem aquele atraso de meio segundo antes do menu abrir.",
      "description": "O que diferencia um site profissional de um site montado às pressas em 2026 — performance real, presença no Google e nas buscas por IA, explicado sem jargão técnico excessivo.",
      "keywords": [
        "para",
        "site",
        "não",
        "pt-br",
        "mais",
        "rápido",
        "contato",
        "google",
        "isso",
        "negócio"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 4,
        "sourcePath": "/pt-BR/blog/criacao-de-sites-profissionais"
      }
    },
    {
      "id": "d0c96a6369932b7f",
      "url": "https://hdrx.com.br/blog/prompt-engineering-as-code",
      "title": "Prompt Engineering as Code: Versioning, Testing, and CI/CD for LLM Prompts — Hendrix Garcia (Part 5)",
      "content": "- **Surface a typed error to the caller** — after N retries (2–3 is typical), stop retrying silently. Bubble up a structured error the caller can handle explicitly, rather than looping indefinitely and burning tokens.\n\nNever retry unboundedly — cap attempts, and log every failure with the",
      "description": "A practical framework for treating prompts as software artifacts — semantic versioning, Zod-validated structured output, regression eval suites, and CI/CD gating, built from the Prompt Pocket architecture.",
      "keywords": [
        "prompt",
        "output",
        "with",
        "model",
        "schema",
        "this",
        "that",
        "code",
        "validation",
        "from"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/blog/prompt-engineering-as-code"
      }
    },
    {
      "id": "d3884ca8ff330e1a",
      "url": "https://hdrx.com.br/pt-BR/projetos/prompt-pocket",
      "title": "Prompt Pocket — Estudo de caso · Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os projetos](/pt-BR/projetos)\n\n// ai Sistema em destaque\n\n## Prompt Pocket\n\nExtensão Chrome privada para salvar, organizar e reutilizar prompts de IA entre ferramentas.\n\n[Código-fonte ↗](#)[Falar sobre projeto semelhante](/pt-BR/contato)\n\n[01] Declaração do problema e contexto\n\n## O desafio\n\nUsuários de IA acabam reescrevendo ou procurando em conversas antigas os mesmos prompts repetidas vezes, em todos os sites e ferramentas que usam. Aplicativos genéricos de notas não entendem a estrutura de um prompt — não há variáveis reutilizáveis nem organização por prompt — e sincronizar uma biblioteca de prompts pelo servidor de outra pessoa significa confiar a ela tudo o que você já perguntou a uma IA.\n\n[02] Arquitetura técnica e solução\n\n## Entrega de engenharia\n\nO Prompt Pocket foi construído como uma extensão Chrome Manifest V3 que usa um painel lateral em vez de um pop-up, para que a biblioteca permaneça aberta ao lado da página em uso. Os prompts aceitam placeholders {{variable}} preenchidos a cada uso, com categorias, tags, favoritos e ordenação por uso, e são inseridos diretamente no input, textarea ou campo contenteditable em foco da aba ativa em dois cliques. Tudo fica em chrome.storage.local — sem contas, analytics ou servidor. O que começou como uma extensão funcional, mas frágil, foi reforçado por uma auditoria sistemática: o script de conteúdo é injetado sob demanda via chrome.scripting.executeScript com escopo em activeTab (sem host_permissions, sem <all_urls>), cada leitura de armazenamento é validada com um schema Zod com caminho de migração versionado, as escritas sempre leem o armazenamento novamente antes para permanecerem seguras contra condições de corrida entre múltiplos painéis laterais abertos, e a interface permanece acessível por padrão (<dialog> nativo, labels associados e aria-labels em botões somente de ícone).\n\n[03] Stack de tecnologia e utilitários",
      "description": "Extensão Chrome privada para salvar, organizar e reutilizar prompts de IA entre ferramentas.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "prompt",
        "chrome",
        "prompts",
        "servidor",
        "conectar",
        "perfil",
        "todos"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/prompt-pocket"
      }
    },
    {
      "id": "d4f4920631b97055",
      "url": "https://hdrx.com.br/blog/mcp-stateless-edge-functions",
      "title": "Stateless MCP on Edge Functions: Architecture, Trade-offs, and Implementation — Hendrix Garcia (Part 2)",
      "content": "- **No persistent process.** A stdio server owns a process for the life of the session. An Edge Function invocation is a single request lifecycle — there is no guarantee the next request from the same client lands on the same isolate, and most platforms explicitly do not guarantee it.\n\n- **No shared memory across invocations.** Anything held in a module-level variable to represent “session state” (a negotiated protocol version, a list of previously listed tools, an auth context established during initialize) is invisible to the next invocation unless it’s externalized to a database, KV store, or the request itself.\n\n- **Handshake-as-prerequisite conflicts with cold starts.** If tools/call is only valid after a successful initialize in the same session, and the platform cannot guarantee session continuity, every cold isolate effectively needs to either replay the handshake or reject requests it should be able to serve.\n\nThe practical failure mode before the 2026-07-28 update: teams built MCP servers on Lambda or Vercel Functions that tried to fake session continuity with sticky routing, external session stores keyed by a client-generated ID, or (worse) accepting tools/call without initialize and hoping clients didn’t enforce the sequence strictly. All three are workarounds for a protocol assumption that doesn’t hold on the target runtime — not solutions.\n\n## What the Stateless Spec Actually Changed\n\n- **Handshake elimination as a hard requirement.** initialize is no longer a stateful prerequisite gating every other method. A server can accept a self-contained tools/call or tools/list request with no prior session context and respond correctly.\n\n- **server/discover as a direct capability route.** Instead of requiring a session to learn capabilities, server identity, and protocol version, clients can call server/discover directly and get a complete, cacheable answer in one round trip.",
      "description": "A deep technical guide to building a stateless Model Context Protocol server on Vercel Edge Functions — JSON-RPC 2.0 design, the 2026-07-28 spec change, auth and rate limiting without sessions, and headless testing with curl.",
      "keywords": [
        "edge",
        "server",
        "tools",
        "that",
        "session",
        "request",
        "call",
        "stateless",
        "with",
        "node"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/blog/mcp-stateless-edge-functions"
      }
    },
    {
      "id": "d67501b6a7eeb2be",
      "url": "https://hdrx.com.br/projects",
      "title": "Projects — Hendrix Garcia (Part 2)",
      "content": "- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose\n\n[Case Study →](/projects/jumbox)\n[Source Code ↗](https://github.com/hd-rx8/jumbox)\n\nwordpress Featured\n\n### [AstroPress](/projects/astropress)\n\nPerformance-first WordPress headless starter for Astro 5 — zero client-side JavaScript by default.\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n- Astro 5\n- TypeScript\n- WordPress REST API\n- PHP\n- Docker Compose\n- Vitest\n\n[Case Study →](/projects/astropress)\n[Source Code ↗](https://github.com/hd-rx8/AstroPress)\n\ndev tool Featured\n\n### [Web Ready](/projects/web-ready)\n\nAn open-source website auditor for Technical SEO, AI readiness, and fundamental web health.\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n- TypeScript\n- Node.js\n- REST / HTTP\n- CLI\n- Vitest\n- GitHub Actions\n- Vercel\n- Technical SEO\n- AEO / AI Readiness\n\n[Case Study →](/projects/web-ready)\n[Source Code ↗](https://github.com/hd-rx8/web-ready)[Live Production ↗](https://web-ready-go.vercel.app/)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Selected engineering projects, full-stack architectures, performance engines, and MCP agent systems.",
      "keywords": [
        "projects",
        "typescript",
        "github",
        "case",
        "react",
        "tailwind",
        "https",
        "featured",
        "astro",
        "study"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects"
      }
    },
    {
      "id": "d9275e5262709083",
      "url": "https://hdrx.com.br/pt-BR/blog/engenharia-de-prompts-como-codigo",
      "title": "Engenharia de prompts como código: versionamento, testes e CI/CD para prompts de LLMs — Hendrix Garcia (Part 3)",
      "content": "### Por que não confiar diretamente em saída de linguagem natural em pipelines de produção?\n\nPorque LLMs são geradores de texto não determinísticos, não chamadas de função tipadas — mesmo com temperatura baixa, o formato deriva (uma fence Markdown extra, uma frase antes do JSON, um campo renomeado pelo impulso “prestativo” do modelo). Todo pipeline que consome essa saída precisa de uma fronteira de validação, tal como você validaria a resposta de uma API externa que não controla.\n\nO padrão é definir o contrato com uma biblioteca de schema (Zod em TypeScript, Pydantic em Python), pedir saída estruturada ao modelo (modo tool-calling/function-calling quando disponível, ou prompt de sistema em JSON mode como fallback) e **fazer parse e validação antes de qualquer lógica de negócio**:\n\nimport { z } from \"zod\"\n\nexport const CodeReviewOutputSchema = z.object({\nstatus: z.enum([\"approved\", \"changes_requested\"]),\nfindings: z.array(\nz.object({\nseverity: z.enum([\"critical\", \"important\", \"minor\"]),\nfile: z.string(),\ndescription: z.string(),\n})\n),\n})\n\nexport type CodeReviewOutput = z.infer<typeof CodeReviewOutputSchema>\n\n// Na fronteira da API — falhe de modo explícito e tipado, não silenciosamente no downstream\nconst result = CodeReviewOutputSchema.safeParse(rawModelOutput)\nif (!result.success) {\n// Nunca deixe uma saída malformada do modelo chegar à lógica de negócio.\n// Registre o erro de validação, a saída bruta e a versão do prompt\n// que a produziu — essa tríade é sua superfície de depuração.\nthrow new StructuredOutputValidationError(result.error, promptVersion)\n}\nIsso oferece três coisas que parsing com regex ou “peça com educação” não oferece:\n\n- **Um único ponto de falha observável.** Quando a forma da saída quebra, há um erro de validação tipado vinculado a uma versão específica do prompt — não um TypeError: undefined is not a function três camadas dentro do app.",
      "description": "Um framework prático para tratar prompts como artefatos de software — versionamento semântico, saída estruturada validada por Zod, suítes de eval de regressão e gates de CI/CD, a partir da arquitetura do Prompt Pocket.",
      "keywords": [
        "prompt",
        "não",
        "para",
        "saída",
        "modelo",
        "schema",
        "como",
        "validação",
        "json",
        "versão"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/engenharia-de-prompts-como-codigo"
      }
    },
    {
      "id": "e1bcda45e978452f",
      "url": "https://hdrx.com.br/pt-BR/projetos/web-ready",
      "title": "Web Ready — Estudo de caso · Hendrix Garcia (Part 2)",
      "content": "HDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Uma ferramenta open-source para auditoria técnica de sites em SEO Técnico, prontidão para IA e saúde básica da web.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "sistema",
        "https",
        "github",
        "conectar",
        "perfil",
        "ready",
        "desenvolvedores"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/web-ready"
      }
    },
    {
      "id": "e69c4ca59e6d2214",
      "url": "https://hdrx.com.br/pt-BR/blog/astropress-wordpress-headless-com-astro",
      "title": "AstroPress: Um Starter WordPress Headless + Astro com 0 KB de JS no Cliente — Hendrix Garcia (Part 4)",
      "content": "A geração estática tem uma lacuna estrutural: editores não conseguem ver rascunhos não publicados num site que só compila a partir de conteúdo publicado. A resposta do AstroPress é um plugin WordPress complementar, o astropress-connector, que realiza um handshake tokenizado com uma rota de SSR sob demanda no Astro — uma exceção estreita e propositalmente delimitada à regra de estático por padrão, escopada especificamente para preview, em vez de deixada aberta como uma saída genérica para SSR. O editor ganha preview em tempo real de conteúdo não publicado sem que o projeto abra mão do padrão de entregar HTML estático de tempo de publicação para tudo o mais.\n\n## Headless Doctor: Diagnosticando o Pipeline Completo\n\nConfigurações headless falham de formas difíceis de localizar — é o WordPress, o conector REST, os permalinks, o plugin de preview, ou o build do Astro? O AstroPress vem com uma ferramenta de diagnóstico, executada via npm run doctor (CLI) ou pelo dashboard /doctor (web), que verifica sete categorias de ponta a ponta: configuração de ambiente, conectividade com o WordPress, disponibilidade dos endpoints REST, estrutura de permalinks, estado de instalação do plugin conector, detecção do plugin de SEO e o handshake de preview de rascunho.\n\nÉ o tipo de ferramenta fácil de pular num tutorial mínimo de WordPress headless e cara de não ter quando algo quebra numa implantação real — um diagnóstico que aponta qual das sete peças falhou evita ter que checar cada uma manualmente sob pressão de tempo.\n\n## Orçamentos de Performance Aplicados em CI, Não Só Documentados",
      "description": "Como o AstroPress desacopla o WordPress como backend editorial puro de um frontend estático em Astro — a camada de conteúdo, a cascata de SEO em 4 níveis, preview de rascunho em tempo real e os orçamentos de performance aplicados em CI.",
      "keywords": [
        "wordpress",
        "para",
        "não",
        "conteúdo",
        "astropress",
        "como",
        "plugin",
        "astro",
        "preview",
        "performance"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/astropress-wordpress-headless-com-astro"
      }
    },
    {
      "id": "e728c14c22060d54",
      "url": "https://hdrx.com.br/projects",
      "title": "Projects — Hendrix Garcia (Part 1)",
      "content": "Engineering Portfolio\n\n## Systems & ProductsSystems & Products\n\nSelected systems, web products, and engineering case studies by Hendrix Garcia.\n\nAll Projects(6)AI & Agents(3)Full-Stack(6)WordPress & Performance(1)\n\nmcp Featured\n\n### [Agent-Ready Portfolio](/projects/agent-ready-portfolio)\n\nAn agent-ready portfolio with MCP, llms.txt, and an interactive terminal for AI assistants.\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n- Astro 5\n- React 19\n- TypeScript\n- Tailwind CSS v4\n- MCP · JSON-RPC 2.0\n- Vercel Edge Functions\n- Resend\n\n[Case Study →](/projects/agent-ready-portfolio)\n[Source Code ↗](#)[Live Production ↗](https://hdrx.com.br)\n\nfullstack Featured\n\n### [WOP - Web Operations Platform](/projects/wop)\n\nOperations platform for agencies: site inventory, uptime monitoring, incidents, and maintenance.\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n- Next.js 16\n- React 19\n- TypeScript\n- Tailwind CSS 4\n- shadcn/ui · Base UI\n- Supabase (Postgres, Auth, RLS, Edge Functions, pg_cron)\n- Zustand\n- Recharts\n\n[Case Study →](/projects/wop)\n[Source Code ↗](#)\n\nai Featured\n\n### [Prompt Pocket](/projects/prompt-pocket)\n\nPrivacy-first Chrome extension to save, organize, and instantly reuse AI prompts across tools.\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n- React 19\n- TypeScript\n- Vite 8\n- @crxjs/vite-plugin\n- Tailwind CSS\n- Zod\n- Vitest\n- Chrome Extension · Manifest V3\n\n[Case Study →](/projects/prompt-pocket)\n[Source Code ↗](#)\n\nfullstack Featured\n\n### [Jumbox](/projects/jumbox)\n\nPrivate, local-first file transfer system with resumable streaming and end-to-end integrity.\n\n- Python\n- FastAPI\n- SQLAlchemy 2.0\n- Alembic\n- SQLite / PostgreSQL\n- Docker Compose",
      "description": "Selected engineering projects, full-stack architectures, performance engines, and MCP agent systems.",
      "keywords": [
        "projects",
        "typescript",
        "github",
        "case",
        "react",
        "tailwind",
        "https",
        "featured",
        "astro",
        "study"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects"
      }
    },
    {
      "id": "e74d30aa096d4543",
      "url": "https://hdrx.com.br/connect",
      "title": "Connect — Hendrix Garcia (Part 3)",
      "content": "What should I include when I get in touch?Share the problem or role, the scope you want to discuss, the current stack or environment, and any relevant timeline. The contact form supports full-time recruiting, consulting or contract work, and engineering conversations.",
      "description": "Connect an AI agent to Hendrix Garcia",
      "keywords": [
        "hendrix",
        "wordpress",
        "contact",
        "developer",
        "endpoint",
        "agents",
        "portfolio",
        "woocommerce",
        "work",
        "this"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 3,
        "sourcePath": "/connect"
      }
    },
    {
      "id": "e88033cf2b41eb43",
      "url": "https://hdrx.com.br/projects/wop",
      "title": "WOP - Web Operations Platform — Case Study · Hendrix Garcia (Part 2)",
      "content": "- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links\n\n- [MCP Server EndpointMCP Server Endpoint](/connect)\n- [LinkedIn Profile ↗LinkedIn Profile ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Profile ↗GitHub Profile ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. All rights reserved.\n\nBuilt with Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Operations platform for agencies: site inventory, uptime monitoring, incidents, and maintenance.",
      "keywords": [
        "projects",
        "uptime",
        "maintenance",
        "that",
        "with",
        "connect",
        "profile",
        "website",
        "next",
        "linkedin"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/projects/wop"
      }
    },
    {
      "id": "e93ed4131e7d119f",
      "url": "https://hdrx.com.br/projects/astropress",
      "title": "AstroPress — Case Study · Hendrix Garcia (Part 1)",
      "content": "[← Back to all projects](/projects)\n\n// wordpress Featured System\n\n## AstroPress\n\nPerformance-first WordPress headless starter for Astro 5 — zero client-side JavaScript by default.\n\n[Source Code ↗](https://github.com/hd-rx8/AstroPress)[Discuss Similar Project](/contact)\n\n[01] Problem Statement & Context\n\n## The Challenge\n\nCoupling WordPress's own PHP rendering to the frontend means every visitor request re-runs Gutenberg templating and database queries, and even a headless setup usually still ships a client-side framework bundle for what is, in practice, static editorial content — leaving performance on the table for a use case that has none of the interactivity to justify it.\n\n[02] Technical Architecture & Solution\n\n## Engineering Delivery\n\nAstroPress decouples WordPress as a pure editorial backend (Gutenberg, taxonomies, media library) from an Astro 5 layer that queries the WordPress REST API entirely at build time and compiles static HTML/CSS for the edge, shipping 0 KB of client JavaScript by default. A normalization layer isolates WordPress REST payloads from the rest of the codebase, a 4-tier SEO cascade (Yoast SEO, Rank Math, native WP fields, then site defaults) feeds Schema.org JSON-LD graphs, and an astro:assets image pipeline compiles remote WordPress media into responsive WebP/AVIF with explicit dimensions to keep layout shift at zero. A companion WordPress connector plugin enables tokenized real-time draft preview through an on-demand SSR route without a full rebuild, and a 7-category 'Headless Doctor' diagnostic (CLI and /doctor dashboard) checks environment, connectivity, REST endpoints, permalinks, the connector plugin, SEO, and draft preview end-to-end. Ships as a full Docker Compose stack pre-seeded with WordPress, MySQL, and demo content, with performance budgets enforced in CI.\n\n[03] Technology Stack & Utilities\n\nAstro 5TypeScriptWordPress REST APIPHPDocker ComposeVitest",
      "description": "Performance-first WordPress headless starter for Astro 5 — zero client-side JavaScript by default.",
      "keywords": [
        "wordpress",
        "projects",
        "astro",
        "rest",
        "github",
        "with",
        "connect",
        "profile",
        "astropress",
        "headless"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects/astropress"
      }
    },
    {
      "id": "ea2d47998e04d489",
      "url": "https://hdrx.com.br/blog/agent-ready-portfolios",
      "title": "Agent-Ready Portfolios: Building Developer Sites for MCP, LLMs, and Answer Engines — Hendrix Garcia (Part 4)",
      "content": "llms.txt is a proposed convention — not a W3C or IETF standard, and not universally honored — for a plain-Markdown file at the site root that gives an LLM a curated, high-signal summary of the site: what it is, the key pages, and links to more detail. It’s the machine-readable analog of a sitemap, but written as prose/Markdown for a model to consume directly rather than as XML for a crawler to enumerate.\n\nIts actual utility today is mixed and worth being honest about:\n\nAspect\n\nReality\n\nAdoption by major AI products\n\nInconsistent — some crawlers fetch it, most general-purpose search/answer engines do not currently prioritize it the way they do robots.txt or sitemaps\n\nCost to implement\n\nNear zero — one static Markdown file\n\nFailure mode if wrong\n\nSilent — no consumer enforces schema, so a stale file just quietly misleads whichever agent does read it\n\nBest current use case\n\nAgent tooling that explicitly checks for it (coding agents, MCP clients, dev-tool integrations) rather than mainstream consumer AI search\n\nGiven the low cost and the optionality, it’s worth shipping — but don’t treat it as a guaranteed discovery channel. It’s a hedge, not infrastructure.\n\n### agents.md — the machine-facing README\n\nagents.md (also seen as AGENTS.md) has better real-world traction because coding agents (Claude Code, Cursor, Copilot Workspace, etc.) actively look for it as an instruction file when operating inside a repository or against a project. On a portfolio, its role is narrower than the repo-level convention: it documents **how an agent should interact with the site’s agent layer** — the MCP endpoint URL, the tool names and their input schemas, rate limits, and any side-effecting operations that require care.\n\nPractical content worth including:\n\n- The MCP transport endpoint and protocol version.\n\n- A list of available tools with one-line descriptions (the full schema is discoverable via the protocol itself — don’t duplicate it and risk drift).",
      "description": "A technical guide to dual-layer portfolio architecture: MCP servers, llms.txt, agents.md, and structured APIs that make your site legible to AI agents and answer engines, not just human visitors.",
      "keywords": [
        "that",
        "agent",
        "agents",
        "llms",
        "site",
        "your",
        "tool",
        "this",
        "tools",
        "content"
      ],
      "metadata": {
        "chunkIndex": 3,
        "totalChunks": 5,
        "sourcePath": "/blog/agent-ready-portfolios"
      }
    },
    {
      "id": "eccaf3056258453a",
      "url": "https://hdrx.com.br/projects/wop",
      "title": "WOP - Web Operations Platform — Case Study · Hendrix Garcia (Part 1)",
      "content": "[← Back to all projects](/projects)\n\n// fullstack Featured System\n\n## WOP - Web Operations Platform\n\nOperations platform for agencies: site inventory, uptime monitoring, incidents, and maintenance.\n\n[Source Code ↗](#)[Discuss Similar Project](/contact)\n\n[01] Problem Statement & Context\n\n## The Challenge\n\nAgencies and freelancers maintaining dozens of client websites end up tracking status, uptime, and maintenance work across scattered spreadsheets or generic project managers that don't understand the domain — with no fast answer to the one question that actually matters: which of my sites need attention right now?\n\n[02] Technical Architecture & Solution\n\n## Engineering Delivery\n\nBuilt WOP around a Client → Proxy Store → Website → Task hierarchy: full website inventory (domain, hosting, IP, environment), operational status tracking (online/degraded/offline/maintenance plus workflow stage), automated uptime checks every 5 minutes with 24h/7d/30d history, and incidents that open and resolve themselves as sites go down and recover. Tasks are organized per website across list, drag-and-drop board, and table views, with reusable templates and recurring maintenance tasks that recreate themselves on schedule — backed by an executive dashboard summarizing infrastructure, uptime, and what needs action. Background jobs (uptime monitoring, recurring-task materialization) run as Supabase Edge Functions on pg_cron, decoupled from the Next.js app.\n\n[03] Technology Stack & Utilities\n\nNext.js 16React 19TypeScriptTailwind CSS 4shadcn/ui · Base UISupabase (Postgres, Auth, RLS, Edge Functions, pg_cron)ZustandRecharts\n\n[← Previous SystemAgent-Ready Portfolio](/projects/agent-ready-portfolio)[Next System →Prompt Pocket](/projects/prompt-pocket)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation",
      "description": "Operations platform for agencies: site inventory, uptime monitoring, incidents, and maintenance.",
      "keywords": [
        "projects",
        "uptime",
        "maintenance",
        "that",
        "with",
        "connect",
        "profile",
        "website",
        "next",
        "linkedin"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects/wop"
      }
    },
    {
      "id": "ed6231251c173fef",
      "url": "https://hdrx.com.br/pt-BR/blog/portfolios-prontos-para-agentes",
      "title": "Portfólios preparados para agentes: criando sites de desenvolvedores para MCP, LLMs e mecanismos de resposta — Hendrix Garcia (Part 5)",
      "content": "- Uma lista de ferramentas disponíveis com descrições de uma linha (o schema completo é descoberto pelo próprio protocolo — não o duplique e corra o risco de divergência).\n\n- Quais operações são somente leitura e quais têm efeitos colaterais (este site tem exatamente uma ferramenta com efeito colateral: contact, que envia um e-mail; todo o restante é somente leitura por desenho).\n\n- Limites de taxa e o comportamento esperado em erro, para que um agente integrador não precise fazer engenharia reversa dos modos de falha.\n\n### Preciso dos dois arquivos?\n\nSim, mas eles atendem a consumidores diferentes. llms.txt mira um agente que faz leitura ou sumarização geral do seu site. agents.md mira um agente (ou desenvolvedor) que",
      "description": "Um guia técnico para a arquitetura de portfólio em duas camadas: servidores MCP, llms.txt, agents.md e APIs estruturadas que tornam seu site legível para agentes de IA e mecanismos de resposta, e não apenas para visitantes humanos.",
      "keywords": [
        "para",
        "não",
        "agentes",
        "agente",
        "site",
        "llms",
        "agents",
        "como",
        "resposta",
        "ferramentas"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/pt-BR/blog/portfolios-prontos-para-agentes"
      }
    },
    {
      "id": "ee32a4b8aa8658fc",
      "url": "https://hdrx.com.br/blog/prompt-engineering-as-code",
      "title": "Prompt Engineering as Code: Versioning, Testing, and CI/CD for LLM Prompts — Hendrix Garcia (Part 2)",
      "content": "- **Schema breakage without a stack trace** — the model returns prose instead of JSON, omits a required field, or hallucinates an enum value outside your allowed set. Without runtime validation this fails downstream silently or crashes deep in business logic, far from the actual cause.\n\n- **Model-swap regressions** — upgrading from one model version to another (or switching providers) changes formatting habits, verbosity, or instruction-following fidelity in ways manual QA won’t catch until a customer complains.\n\n- **No blast-radius control** — a bad prompt change ships straight to 100% of traffic because there’s no staging gate, no eval suite, and no rollback path distinct from a full deploy.\n\nPrompt-as-code closes these gaps by applying the same guardrails you already use for application code: version control, typed contracts, automated regression testing, and staged rollout.\n\n### Prompt-as-Code vs. Ad-Hoc Prompting: A Direct Comparison\n\nDimension\n\nAd-hoc prompting\n\nPrompt-as-code (PEaC)\n\nStorage\n\nInline strings, dashboard UI, .env\n\nVersioned files in git, reviewed via PR\n\nChange tracking\n\nNone, or informal Slack message\n\nGit diff + semantic version bump\n\nOutput contract\n\nImplicit, parsed with regex/hope\n\nExplicit schema (Zod/Pydantic/JSON Schema), validated at runtime\n\nRegression detection\n\nManual spot-checking, if any\n\nAutomated eval suite run in CI against a golden dataset\n\nRollback\n\nRedeploy previous app version\n\nPoint back to previous prompt version, no app deploy needed\n\nModel upgrades\n\n“Try it and see”\n\nEval suite re-run against new model, diffed against baseline scores\n\nAdversarial input handling\n\nDiscovered in production\n\nTested against an adversarial/red-team input set pre-merge\n\nOwnership\n\nWhoever last edited the dashboard\n\nCode owners via CODEOWNERS, PR review required\n\n## Core Principle 1: Strict Schemas for Structured Output\n\n### Why can’t you trust natural-language output directly in production pipelines?",
      "description": "A practical framework for treating prompts as software artifacts — semantic versioning, Zod-validated structured output, regression eval suites, and CI/CD gating, built from the Prompt Pocket architecture.",
      "keywords": [
        "prompt",
        "output",
        "with",
        "model",
        "schema",
        "this",
        "that",
        "code",
        "validation",
        "from"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/blog/prompt-engineering-as-code"
      }
    },
    {
      "id": "eec046b6335886ee",
      "url": "https://hdrx.com.br/blog/agent-ready-portfolios",
      "title": "Agent-Ready Portfolios: Building Developer Sites for MCP, LLMs, and Answer Engines — Hendrix Garcia (Part 5)",
      "content": "- Which operations are read-only versus which have side effects (this site has exactly one side-effecting tool: contact, which sends an email — everything else is read-only by design).\n\n- Rate limits and expected error behavior, so an integrating agent doesn’t need to reverse-engineer failure modes.\n\n### Do I need both files?\n\nYes, but they serve different consumers. llms.txt targets an agent doing general-purpose reading/summarization of your site. agents.md targets an agent (or developer) that wants to *act* — call your tools, integrate against your API. Treat them as a discovery layer and an integration-contract layer, respectively, not duplicates of each other.\n\n## The MCP Server: Exposing a Portfolio as Callable Tools\n\n**Model Context Protocol (MCP)** standardizes how an LLM client (Claude Desktop, Cursor, a custom agent) discovers and calls external tools over a consistent JSON-RPC 2.0 interface, instead of every integration inventing its own bespoke API shape and the model having to be told about it out-of-band via prompt engineering.\n\nFramed as a REST/JSON-RPC comparison, the actual value proposition is:\n\n- **Self-describing.** MCP clients call a discovery method (tools/list) and",
      "description": "A technical guide to dual-layer portfolio architecture: MCP servers, llms.txt, agents.md, and structured APIs that make your site legible to AI agents and answer engines, not just human visitors.",
      "keywords": [
        "that",
        "agent",
        "agents",
        "llms",
        "site",
        "your",
        "tool",
        "this",
        "tools",
        "content"
      ],
      "metadata": {
        "chunkIndex": 4,
        "totalChunks": 5,
        "sourcePath": "/blog/agent-ready-portfolios"
      }
    },
    {
      "id": "eef63abb1c5ddd41",
      "url": "https://hdrx.com.br/blog/agent-ready-portfolios",
      "title": "Agent-Ready Portfolios: Building Developer Sites for MCP, LLMs, and Answer Engines — Hendrix Garcia (Part 3)",
      "content": "┌────────────────────────┐\n│ Public Domain │\n└────────────┬─────────────┘\n│\n┌────────────────────┴────────────────────┐\n▼ ▼\n[Human Layer] [Agent Layer]\n• Astro 5 SSG/SSR hybrid • Stateless MCP Server (/api/mcp)\n• View Transitions SPA-feel nav • /llms.txt discovery file\n• Semantic HTML + JSON-LD • /agents.md contribution guide\n• Design system, motion, imagery • REST endpoints (/api/resume, /api/projects)\n│ │\n└────────────────────┬─────────────────────┘\n▼\n/src/data/*.ts (single source of truth)\nThe critical constraint that makes this maintainable: **both layers read from the same typed data module.** The MCP server’s get_projects tool and the /projects page component pull from the identical projects.ts array. There is no separate “content for bots” that can drift out of sync with “content for humans” — a common failure mode in sites that bolt on an llms.txt as an afterthought and then never update it after the visible site changes.\n\n### Why Astro’s Hybrid Output Model Matters Here\n\nAstro ships zero JavaScript by default and renders to static HTML at build time, with the option to opt specific routes into server rendering (output: \"hybrid\" with per-route export const prerender = false). For agent-readability this matters for a boring but decisive reason: **content that exists in the initial HTML response is visible to every consumer, regardless of whether they execute JavaScript.** A React SPA that mounts content client-side is invisible to any agent doing a plain fetch() — which, for cost and latency reasons, is the majority of them.\n\nReact islands (client:load, client:visible) are used here only for actual interactivity — the project filter, the chat widget — never for content that needs to be discoverable. That’s not a performance optimization first; it’s an information-architecture decision that happens to also improve Core Web Vitals.\n\n## Discovery Files: llms.txt and agents.md\n\n### What does llms.txt actually do?",
      "description": "A technical guide to dual-layer portfolio architecture: MCP servers, llms.txt, agents.md, and structured APIs that make your site legible to AI agents and answer engines, not just human visitors.",
      "keywords": [
        "that",
        "agent",
        "agents",
        "llms",
        "site",
        "your",
        "tool",
        "this",
        "tools",
        "content"
      ],
      "metadata": {
        "chunkIndex": 2,
        "totalChunks": 5,
        "sourcePath": "/blog/agent-ready-portfolios"
      }
    },
    {
      "id": "ef97bbd20a10d090",
      "url": "https://hdrx.com.br/pt-BR/projetos/wop",
      "title": "WOP - Plataforma de Operações Web — Estudo de caso · Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os projetos](/pt-BR/projetos)\n\n// fullstack Sistema em destaque\n\n## WOP - Plataforma de Operações Web\n\nPlataforma operacional para agências: inventário, uptime, incidentes e manutenção de sites.\n\n[Código-fonte ↗](#)[Falar sobre projeto semelhante](/pt-BR/contato)\n\n[01] Declaração do problema e contexto\n\n## O desafio\n\nAgências e freelancers que mantêm dezenas de sites de clientes acabam acompanhando status, disponibilidade e trabalho de manutenção em planilhas dispersas ou gerenciadores de projeto genéricos que não entendem o domínio — sem uma resposta rápida para a única pergunta que realmente importa: quais dos meus sites precisam de atenção agora?\n\n[02] Arquitetura técnica e solução\n\n## Entrega de engenharia\n\nO WOP foi construído em torno de uma hierarquia Cliente → Proxy Store → Website → Tarefa: inventário completo de sites (domínio, hospedagem, IP, ambiente), acompanhamento de status operacional (online/degradado/offline/em manutenção mais estágio do fluxo), verificações automáticas de disponibilidade a cada 5 minutos com histórico de 24h/7d/30d e incidentes que são abertos e resolvidos automaticamente quando os sites caem e se recuperam. As tarefas são organizadas por site em visualizações de lista, quadro com arrastar e soltar e tabela, com modelos reutilizáveis e tarefas de manutenção recorrentes que se recriam no cronograma — apoiadas por um dashboard executivo que resume a infraestrutura, a disponibilidade e o que precisa de ação. Jobs em segundo plano (monitoramento de disponibilidade, materialização de tarefas recorrentes) são executados como Supabase Edge Functions em pg_cron, desacoplados do app Next.js.\n\n[03] Stack de tecnologia e utilitários\n\nNext.js 16React 19TypeScriptTailwind CSS 4shadcn/ui · Base UISupabase (Postgres, Auth, RLS, Edge Functions, pg_cron)ZustandRecharts\n\n[← Sistema anteriorPortfólio Preparado para Agentes](/pt-BR/projetos/agent-ready-portfolio)[Próximo sistema →Prompt Pocket](/pt-BR/projetos/prompt-pocket)",
      "description": "Plataforma operacional para agências: inventário, uptime, incidentes e manutenção de sites.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "sites",
        "manutenção",
        "disponibilidade",
        "conectar",
        "perfil",
        "sistema",
        "são"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/wop"
      }
    },
    {
      "id": "efea64eda462fe86",
      "url": "https://hdrx.com.br/pt-BR/projetos/web-ready",
      "title": "Web Ready — Estudo de caso · Hendrix Garcia (Part 1)",
      "content": "[← Voltar para todos os projetos](/pt-BR/projetos)\n\n// dev tool Sistema em destaque\n\n## Web Ready\n\nUma ferramenta open-source para auditoria técnica de sites em SEO Técnico, prontidão para IA e saúde básica da web.\n\n[Em produção ↗](https://web-ready-go.vercel.app/)[Código-fonte ↗](https://github.com/hd-rx8/web-ready)[Falar sobre projeto semelhante](/pt-BR/contato)\n\n[01] Declaração do problema e contexto\n\n## O desafio\n\nDesenvolvedores já têm ferramentas para performance, acessibilidade, SEO tradicional e verificações individuais de AEO, mas verificar se um site moderno expõe os sinais técnicos exigidos por mecanismos de busca e sistemas de IA geralmente significa combinar múltiplas ferramentas e inspecionar manualmente metadados, diretivas de robôs, dados estruturados, HTML semântico e sinais de infraestrutura. O Web Ready foi criado para consolidar essas verificações em uma única auditoria transparente orientada a desenvolvedores.\n\n[02] Arquitetura técnica e solução\n\n## Entrega de engenharia\n\nConstruído o Web Ready em torno de duas formas de execução: uma ferramenta CLI (`npx web-ready <url>`) e uma interface Web de suporte. O sistema funciona obtendo a URL, analisando o HTML de origem, executando detectores determinísticos e gerando um relatório detalhado abrangendo pontuações de SEO técnico, prontidão para IA e saúde da web, com recomendações e evidências claras. A pontuação é totalmente transparente, baseada em regras conhecidas e sem dependência obrigatória de LLMs. Classifica as descobertas em PASS, WARN, FAIL, INFO ou SKIP, facilitando a automação local ou em pipelines de CI.\n\n[03] Stack de tecnologia e utilitários\n\nTypeScriptNode.jsREST / HTTPCLIVitestGitHub ActionsVercelTechnical SEOAEO / AI Readiness\n\n[← Sistema anteriorAstroPress](/pt-BR/projetos/astropress)[Próximo sistema →Portfólio Preparado para Agentes](/pt-BR/projetos/agent-ready-portfolio)",
      "description": "Uma ferramenta open-source para auditoria técnica de sites em SEO Técnico, prontidão para IA e saúde básica da web.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "sistema",
        "https",
        "github",
        "conectar",
        "perfil",
        "ready",
        "desenvolvedores"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/web-ready"
      }
    },
    {
      "id": "f0b2e464e1219834",
      "url": "https://hdrx.com.br/projects/web-ready",
      "title": "Web Ready — Case Study · Hendrix Garcia (Part 1)",
      "content": "[← Back to all projects](/projects)\n\n// dev tool Featured System\n\n## Web Ready\n\nAn open-source website auditor for Technical SEO, AI readiness, and fundamental web health.\n\n[Live Production ↗](https://web-ready-go.vercel.app/)[Source Code ↗](https://github.com/hd-rx8/web-ready)[Discuss Similar Project](/contact)\n\n[01] Problem Statement & Context\n\n## The Challenge\n\nDevelopers already have tools for performance, accessibility, traditional SEO, and individual AEO checks, but verifying whether a modern website exposes the technical signals required by both search engines and AI systems usually means combining multiple tools and manually inspecting metadata, robots directives, structured data, semantic HTML, and infrastructure signals. Web Ready was created to consolidate those checks into one transparent developer-oriented audit.\n\n[02] Technical Architecture & Solution\n\n## Engineering Delivery\n\nBuilt Web Ready around two forms of execution: a CLI-first tool (`npx web-ready <url>`) and a companion Web UI. The core system operates by fetching the URL, parsing the origin HTML, running deterministic detectors, and producing a detailed report covering overall, SEO, AI readiness, and basic web health scores with recommendations and evidence. The scoring is fully transparent and rule-based with no mandatory LLM dependency, classifying issues as PASS, WARN, FAIL, INFO, or SKIP. It supports technical SEO (metadata, headers, sitemaps, JSON-LD), AI readiness/AEO (llms.txt, crawler directives like GPTBot/ClaudeBot/PerplexityBot), and basic health (TTFB, mixed content, redirect flags), making it easily integration-friendly for local dev and CI pipelines.\n\n[03] Technology Stack & Utilities\n\nTypeScriptNode.jsREST / HTTPCLIVitestGitHub ActionsVercelTechnical SEOAEO / AI Readiness\n\n[← Previous SystemAstroPress](/projects/astropress)[Next System →Agent-Ready Portfolio](/projects/agent-ready-portfolio)",
      "description": "An open-source website auditor for Technical SEO, AI readiness, and fundamental web health.",
      "keywords": [
        "projects",
        "technical",
        "readiness",
        "https",
        "github",
        "connect",
        "profile",
        "system",
        "ready",
        "health"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects/web-ready"
      }
    },
    {
      "id": "f1ee615a89b76dfe",
      "url": "https://hdrx.com.br/projects/agent-ready-portfolio",
      "title": "Agent-Ready Portfolio — Case Study · Hendrix Garcia (Part 1)",
      "content": "[← Back to all projects](/projects)\n\n// mcp Featured System\n\n## Agent-Ready Portfolio\n\nAn agent-ready portfolio with MCP, llms.txt, and an interactive terminal for AI assistants.\n\n[Live Production ↗](https://hdrx.com.br)[Source Code ↗](#)[Discuss Similar Project](/contact)\n\n[01] Problem Statement & Context\n\n## The Challenge\n\nRecruiters and hiring tools increasingly run AI agents to screen candidates before a human ever opens a resume, but almost every developer portfolio is built for human eyes only — flat HTML an agent has to scrape and guess at, with no reliable way to ask it a direct question and get a structured answer back.\n\n[02] Technical Architecture & Solution\n\n## Engineering Delivery\n\nBuilt the portfolio itself as the proof: two parallel layers reading from the same source-of-truth data. The human layer is an Astro 5 + React 19 site with a hero terminal that runs real commands (including a hidden multi-chapter narrative easter egg) with a typewriter reveal. The agent layer is a stateless MCP server speaking JSON-RPC 2.0 over HTTP at /api/mcp, exposing read-only tools (resume, projects, capabilities, availability, and the hidden manifest) plus one tool with a side effect (email contact via Resend). Any MCP-compatible client — Claude, Cursor, ChatGPT — connects directly and queries the exact same data the human site renders, with zero scraping.\n\n[03] Technology Stack & Utilities\n\nAstro 5React 19TypeScriptTailwind CSS v4MCP · JSON-RPC 2.0Vercel Edge FunctionsResend\n\n[← Previous SystemWeb Ready](/projects/web-ready)[Next System →WOP - Web Operations Platform](/projects/wop)\n\nHDRX\nFull-Stack Developer & Product Engineer. Building agent-ready web products, high-concurrency systems, and developer tools.\n\nOpen to full-time roles\n\n#### // Navigation\n\n- [HomeHome](/)\n- [ProjectsProjects](/projects)\n- [AboutAbout](/about)\n- [BlogBlog](/blog)\n- [Connect (MCP)Connect (MCP)](/connect)\n- [ContactContact](/contact)\n\n#### // Protocols & Links",
      "description": "An agent-ready portfolio with MCP, llms.txt, and an interactive terminal for AI assistants.",
      "keywords": [
        "with",
        "projects",
        "portfolio",
        "human",
        "connect",
        "profile",
        "agent-ready",
        "https",
        "contact",
        "tools"
      ],
      "metadata": {
        "chunkIndex": 0,
        "totalChunks": 2,
        "sourcePath": "/projects/agent-ready-portfolio"
      }
    },
    {
      "id": "f7b9d3180db0fca9",
      "url": "https://hdrx.com.br/blog/professional-website-development",
      "title": "Professional Website Development: The Technical Base That Makes a Site Sell — Hendrix Garcia (Part 2)",
      "content": "Sites built on generic page builders or loaded with excess plugins and scripts tend to fail right here — not because the design is bad, but because they load a large amount of unnecessary code before showing anything useful. This is measurable, not a matter of taste.\n\n## Getting Found: Google and the New AI Search\n\nRanking well in Google is still the foundation — organized content hierarchy, well-written titles and descriptions, a fast site, internal links between pages. That hasn’t changed.\n\nWhat has changed is that a growing share of people are now searching directly in ChatGPT, Perplexity, or the AI answers that already appear at the top of Google, instead of clicking through a list of links. These systems read the site and try to automatically understand who the business is and what it offers — and a site organized in a way that automated reading can pick up correctly has a better chance of being cited as the answer.\n\nIn practice, that means: the business’s information (name, service, area of expertise) written clearly and in a structured way in the page’s code, not buried inside an image or a loose paragraph in the footer. It’s a relatively cheap technical adjustment to make during the build — and most sites built without this in mind simply don’t have that information organized in a way AI can read properly.\n\nIt’s not magic, and it doesn’t replace traditional SEO — it’s an additional layer, one that only makes sense once the basics (speed, structure, relevant content) are already handled.\n\n## From Visit to Contact\n\nThere’s no point in a site loading fast and ranking well in search if, once someone arrives, it’s not clear what to do next. The parts that carry the most weight here:\n\n- A direct, visible path to reach the business — WhatsApp, a form, or a phone number, not hidden behind multiple clicks.\n\n- Content organized by priority: what the business solves first, the details after — not a generic institutional paragraph before any useful information.",
      "description": "What separates a professional website from a site thrown together in a hurry in 2026 — real performance, presence in Google and in AI search, explained without excessive technical jargon.",
      "keywords": [
        "that",
        "site",
        "with",
        "what",
        "business",
        "google",
        "page",
        "project",
        "technical",
        "search"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 4,
        "sourcePath": "/blog/professional-website-development"
      }
    },
    {
      "id": "fdfb788246d99fc7",
      "url": "https://hdrx.com.br/blog/astropress-headless-wordpress-astro",
      "title": "AstroPress: A Headless WordPress + Astro Starter With 0 KB Client JS — Hendrix Garcia (Part 2)",
      "content": "Headless WordPress removes PHP from the request path for content pages entirely. WordPress becomes a data source consumed at build time (or via on-demand SSR for the few things that genuinely need it, like draft preview); the actual page a visitor loads is static HTML served from the edge, with no database round-trip per request. The trade-off is real: you give up the “install a plugin, get a feature” ergonomics of a monolithic WordPress theme, in exchange for rendering performance that doesn’t degrade under traffic.\n\n## Architecture: Content Layer, Not Just an API Call\n\nAstroPress’s docs/architecture.md documents the data flow as: WordPress → REST API (/wp-json/wp/v2/*) → a WordPress client (client.ts) → raw JSON → a content layer** (src/lib/wordpress/) that normalizes the payload → typed, normalized data consumed by Astro routes and components → static HTML (or the on-demand preview route).\n\nThe content layer is the part that matters architecturally. Rather than letting WordPress’s REST response shape leak into every page component — field names, nested taxonomy objects, WordPress-specific quirks — the normalization layer isolates that entirely. Components consume a typed, project-defined shape; if WordPress’s API response changes or you swap a plugin that alters the payload, you fix it in one place instead of hunting through every template that touched post.acf.some_field directly.\n\nThe project also documents explicit **JavaScript boundaries**: client-side fetches or hydration are prohibited for content that’s known at build time — that’s what the content layer and static generation are for. Astro islands are permitted only for narrowly-scoped interactivity that genuinely can’t be static, like a client-side search box. This is the same discipline that keeps a “static-first” architecture from quietly regressing into a client-rendered app one convenient client:load at a time.\n\n## The 4-Tier SEO Cascade",
      "description": "How AstroPress decouples WordPress as a pure editorial backend from an Astro static frontend — the content layer, the 4-tier SEO cascade, real-time draft preview, and the CI performance budgets that enforce it.",
      "keywords": [
        "wordpress",
        "that",
        "astropress",
        "plugin",
        "astro",
        "with",
        "from",
        "content",
        "static",
        "preview"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 5,
        "sourcePath": "/blog/astropress-headless-wordpress-astro"
      }
    },
    {
      "id": "fef39c373fa1a251",
      "url": "https://hdrx.com.br/pt-BR/projetos/agent-ready-portfolio",
      "title": "Portfólio Preparado para Agentes — Estudo de caso · Hendrix Garcia (Part 2)",
      "content": "HDRX\nDesenvolvedor Full-Stack e Engenheiro de Produto. Criando produtos web prontos para agentes, sistemas de alta concorrência e ferramentas para desenvolvedores.\n\nAberto a oportunidades em tempo integral\n\n#### // Navegação\n\n- [InícioInício](/pt-BR/)\n- [ProjetosProjetos](/pt-BR/projetos)\n- [SobreSobre](/pt-BR/sobre)\n- [BlogBlog](/pt-BR/blog)\n- [Conectar (MCP)Conectar (MCP)](/pt-BR/conectar)\n- [ContatoContato](/pt-BR/contato)\n\n#### // Protocolos e links\n\n- [Endpoint do servidor MCPEndpoint do servidor MCP](/pt-BR/conectar)\n- [LinkedIn Perfil ↗LinkedIn Perfil ↗](https://linkedin.com/in/hendrixgarcia)\n- [GitHub Perfil ↗GitHub Perfil ↗](https://github.com/hd-rx8)\n- [hdrxgarcia@gmail.comhdrxgarcia@gmail.com](mailto:hdrxgarcia@gmail.com)\n\n© 2026 Hendrix Garcia. Todos os direitos reservados.\n\nDesenvolvido com Astro 5•React 19•Tailwind v4•Stateless MCP",
      "description": "Portfólio pronto para agentes, com MCP, llms.txt e terminal interativo para assistentes de IA.",
      "keywords": [
        "pt-br",
        "para",
        "projetos",
        "agentes",
        "portfólio",
        "conectar",
        "perfil",
        "sistema",
        "https",
        "sobre"
      ],
      "metadata": {
        "chunkIndex": 1,
        "totalChunks": 2,
        "sourcePath": "/pt-BR/projetos/agent-ready-portfolio"
      }
    }
  ],
  "metadata": {
    "totalEntries": 113,
    "generator": "aeo.js",
    "generatorUrl": "https://aeojs.org",
    "embedding": {
      "recommended": "text-embedding-ada-002",
      "dimensions": 1536
    }
  }
}