Entreguei o motor por trás deste exato site: um portfólio bilíngue cujo conteúdo é curado automaticamente a partir de sessões reais de trabalho. Um hook de fim de sessão avalia cada sessão do Claude Code contra um rubric de relevância; quando algo passa na régua, é escrito em dois idiomas, sanitizado e commitado como rascunho que publica com um comando.
Resultado: O site que você está lendo foi produzido por esse pipeline.
Detalhe técnico
Três componentes: um site estático em Astro (i18n EN/PT, feed/projetos/CV renderizados de JSON no build), um servidor MCP em Python expondo cinco tools (log_activity, review_and_publish, add_project, update_now, get_portfolio_state) que escrevem pela API de Contents do GitHub, e um hook de Stop que embute o rubric verbatim — mudar critérios não exige mudar código. A validação tem três camadas: JSON Schema, completude bilíngue (tradução faltando quebra o build, de propósito) e uma denylist local como retaguarda determinística atrás da sanitização por categoria do LLM.
astromcppythonclaude-codei18n
Primeiro uso em produção de scroll-driven animations do CSS: a linha do tempo deste feed se desenha conforme você rola, com zero JavaScript. O conceito de movimento do site — pulso, traço, respiração — precisava comunicar 'vivo' sem nenhuma biblioteca de animação.
Resultado: A linha do feed se desenha no scroll em ~20 linhas de CSS; zero JS, zero bibliotecas.
Detalhe técnico
animation-timeline: view() mapeia o progresso de uma animação à posição do elemento no viewport — a borda da linha do tempo escala de 0 à altura total conforme cada entrada a cruza. Embrulhado em @supports para que navegadores sem suporte vejam só a borda estática, e desligado sob prefers-reduced-motion. O resto do sistema de movimento é um IntersectionObserver inline de ~30 linhas (reveal escalonado) atrás de uma classe html.js, então uma falha de JavaScript nunca deixa conteúdo escondido.
cssscroll-driven-animationsprogressive-enhancement
Meu portfólio precisava se atualizar sozinho sem virar um servidor pra manter. A decisão: sem CMS, sem banco de dados, sem backend — o conteúdo vive como JSON num repositório git, cada atualização é um commit, e o site é um build estático disparado por push. Uma branch drafts funciona como buffer obrigatório: a automação pode escrever, mas nada vai a público sem um merge humano.
Resultado: Zero infraestrutura pra operar; toda mudança de conteúdo é auditável no histórico do git.
Detalhe técnico
Um par competente poderia razoavelmente ter escolhido um CMS headless ou uma API pequena. Git-como-banco-de-dados venceu em três frentes: histórico completo e rollback de graça, custo de infraestrutura zero, e um pipeline de deploy (push → rebuild) que hosts estáticos oferecem de fábrica. A branch drafts existe por confidencialidade, não relevância — trabalho de cliente nunca pode auto-publicar sem um olhar humano. Trade-off aceito: sem atualizações em tempo real, que um portfólio não precisa.
architecturestatic-sitegitastro