Shell / TypeScript / Python
monozukuri
Backlog em PRs pequenos e revisáveis.
★ 6 · 28/10/2026Ver projeto ↗Engenharia de software que escala — e que se automatiza.
░▒▓ VC ▓▒░
Senior Software Engineer com mais de 12 anos de experiência em arquitetura, plataforma e IA aplicada. Construo apps, backends e ferramentas para times entregarem melhor.
01 / IDEIA02 / SPEC03 / AGENTES04 / PR05 / PRODUÇÃO
01 / BUILD
Projetos selecionados
Swift / SwiftUI / Agent skills
swift-code-reviewer-skill
Review em camadas. Contexto em primeiro lugar.
★ 38 · 28/10/2026Ver projeto ↗TypeScript / Skills / Templates
Feature-marker
Da intenção a um plano executável.
★ 11 · 28/10/2026Ver projeto ↗TypeScript / Notion / OAuth
gastandoya-api
Integrações que respeitam fronteiras.
★ 0 · 28/10/2026Ver projeto ↗ArquivoTodos os repositórios ↗
Arquivo
- monozukuri ↗Backlog em PRs pequenos e revisáveis.
- SavePlace ↗Uma URL social. Um lugar verificável.
- ci-guard ↗Diagnosticar antes de repetir.
- swift-code-reviewer-skill ↗Review em camadas. Contexto em primeiro lugar.
- Feature-marker ↗Da intenção a um plano executável.
- gastandoya-api ↗Integrações que respeitam fronteiras.
BUILD / SYSTEMS & DECISIONS
Arquitetura em movimento.
Explore meu processo e as decisões por trás de cada projeto. Selecione um componente para entender sua responsabilidade.
THE PIPELINE / SYSTEM MAP
Como estruturo uma entrega
Uma leitura dos padrões presentes nos seis projetos: tornar a intenção explícita, separar responsabilidades e produzir evidência antes de avançar.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 7
Intenção & critérios
Definir problema, escopo e aceite em artefatos legíveis. Referências: Feature-marker e monozukuri.
Etapa 2 / 7
Spec & decisões
Transformar requisitos em plano técnico e tarefas; questionar lacunas antes de implementar. Referência: Feature-marker.
Etapa 3 / 7
Fronteiras & contratos
Separar extração, verificação e persistência no SavePlace; manter conexões Notion no backend do GastandoYa.
Etapa 4 / 7
Execução isolada
Worktrees, agentes e controles de custo no monozukuri; artefatos de execução continuam no repositório.
Etapa 5 / 7
Validação em camadas
Revisar aderência à spec e arquitetura com swift-code-reviewer-skill; classificar falhas com ci-guard.
Etapa 6 / 7
Entrega revisável
monozukuri abre PRs; Feature-marker termina em commit local e handoff. São contratos diferentes de entrega.
Etapa 7 / 7
Feedback & memória
Memória com proveniência no monozukuri e sugestões de padrões no reviewer alimentam a próxima iteração.
A arquitetura aparece nas decisões e nos limites, não só na escolha da stack.
Conexões e condições
- Intenção & critérios → Spec & decisõesDefine o plano
- Spec & decisões → Fronteiras & contratosExplicita os contratos
- Fronteiras & contratos → Execução isoladaOrienta a implementação
- Execução isolada → Validação em camadasProduz evidência
- Validação em camadas → Entrega revisávelSustenta a revisão
- Entrega revisável → Feedback & memóriaRegistra aprendizados
- Feedback & memória → Intenção & critériosInforma a próxima iteração
Fontes no GitHubFeature-marker / README ↗monozukuri / README ↗SavePlace / README ↗ci-guard / README ↗swift-code-reviewer-skill / README ↗gastandoya-api / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
THE PIPELINE / SYSTEM MAP
monozukuri
Orquestração fora do agente, execução por feature e memória entre entregas.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 6
Backlog & seleção
pick ordena ou seleciona features; loop coordena a fila de trabalho.
Etapa 2 / 6
Worktree isolada
Cada feature ganha um espaço de trabalho independente para mudanças revisáveis.
Etapa 3 / 6
Fases do agente
PRD, TechSpec, Tasks e Code rodam com o agente configurado e skills do projeto.
Etapa 4 / 6
Testes & limites
Validar a entrega e respeitar limites de custo, tempo e tokens. Checkpoints permitem retomada.
Etapa 5 / 6
Pull request
O resultado é uma mudança separada, acompanhada de resumo e evidência para revisão.
Etapa 6 / 6
Memory v2
Guardar aprendizado, origem e contexto de aplicação; o router injeta resumos antes de detalhes.
Isolar o trabalho e preservar contexto sem acoplar o fluxo a um único agente.
Conexões e condições
- Backlog & seleção → Worktree isoladaSeleciona uma feature
- Worktree isolada → Fases do agenteFornece isolamento
- Fases do agente → Testes & limitesEntrega mudanças
- Testes & limites → Pull requestValidação da entrega
- Pull request → Memory v2Preserva aprendizados
- Memory v2 → Fases do agenteReutiliza contexto
Fontes no GitHubmonozukuri / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
THE PIPELINE / SYSTEM MAP
SavePlace
Da evidência social ao lugar verificado, com salvamento explícito.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 6
URL pública
A entrada suportada é uma URL pública TikTok; o adaptador obtém metadados oficiais via oEmbed.
Etapa 2 / 6
Cache & idempotência
Reaproveitar análise da fonte e replay; PostgreSQL separa cache reutilizável do histórico privado por sessão.
Etapa 3 / 6
Extração com IA
Metadados sustentam candidatos estruturados. Prompt, tokens, custo estimado e latência são registrados.
Etapa 4 / 6
PlaceProvider
Google Places confirma identidade geográfica. Apenas o provedor pode marcar um lugar como verificado.
Etapa 5 / 6
Revisão & evidência
Ambiguidade ou falta de evidência vira um estado de revisão, sem inventar endereço ou coordenadas.
Etapa 6 / 6
Biblioteca privada
O clique explícito salva um lugar verificado na biblioteca da sessão; dados podem ser gerenciados depois.
A IA propõe candidatos. O provedor verifica o lugar. A pessoa decide salvar.
Conexões e condições
- URL pública → Cache & idempotênciaConsulta análise existente
- Cache & idempotência → Extração com IACache miss
- Extração com IA → PlaceProviderEnvia candidatos
- PlaceProvider → Revisão & evidênciaResultado ou ambiguidade
- Revisão & evidência → Biblioteca privadaConfirmação explícita
- Cache & idempotência → Revisão & evidênciaCache hit ou replay
Fontes no GitHubSavePlace / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
THE PIPELINE / SYSTEM MAP
ci-guard
Uma falha de CI vira uma decisão classificada, com orçamento e verificação.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 6
Snapshot do CI
Capturar checks e logs da falha antes de qualquer tentativa de rerun.
Etapa 2 / 6
Classificação
Distinguir falha da branch, infraestrutura, teste flaky, dependência e desconhecido. Scripts Python não chamam LLM.
Etapa 3 / 6
Limite de retry
Falhas elegíveis só podem repetir dentro dos limites por job, PR e minutos.
Etapa 4 / 6
Verificar o verde
Um teste flaky que ficou verde precisa de verificação adicional no mesmo SHA.
Etapa 5 / 6
Ledger & decisão humana
Registrar histórico de flakiness; recomendar quarentena quando os critérios se aplicam. A pessoa decide.
Etapa 6 / 6
Corrigir ou investigar
branch_failure exige correção; unknown exige leitura manual dos logs. Orçamento esgotado interrompe o retry.
Corrigir código, investigar ou repetir são caminhos diferentes.
Conexões e condições
- Snapshot do CI → ClassificaçãoReúne evidências
- Classificação → Limite de retryFalha elegível para retry
- Classificação → Corrigir ou investigarBranch ou desconhecido
- Limite de retry → Verificar o verdeFlaky ficou verde
- Limite de retry → Corrigir ou investigarLimite esgotado
- Verificar o verde → Ledger & decisão humanaRegistra a verificação
Fontes no GitHubci-guard / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
THE PIPELINE / SYSTEM MAP
swift-code-reviewer-skill
O mesmo núcleo de revisão, adaptado a quatro runtimes de agentes.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 5
Diff, spec & padrões
Ler mudanças, critérios de aceite e arquivo de padrões do projeto antes de avaliar código.
Etapa 2 / 5
Wrappers por agente
Claude, Codex, Gemini e Kiro recebem instruções nos formatos e caminhos de cada runtime.
Etapa 3 / 5
Sete camadas
Spec, Swift, SwiftUI, performance, segurança, arquitetura e padrões do projeto.
Etapa 4 / 5
Relatório priorizado
Achados por arquivo e severidade, com ações para orientar a próxima revisão.
Etapa 5 / 5
Padrões recorrentes
Agrupar achados repetidos e propor regras para o projeto; sugestões não são aprovação automática.
Revisar o código contra a intenção e os padrões do projeto.
Conexões e condições
- Diff, spec & padrões → Wrappers por agenteContextualiza a revisão
- Wrappers por agente → Sete camadasCompartilha o núcleo
- Sete camadas → Relatório priorizadoOrganiza os achados
- Relatório priorizado → Padrões recorrentesDetecta recorrência
- Padrões recorrentes → Diff, spec & padrõesPropõe novos padrões
Fontes no GitHubswift-code-reviewer-skill / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
THE PIPELINE / SYSTEM MAP
Feature-marker
O pacote instala assets; o agente conduz o trabalho e deixa artefatos no repositório.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 6
Instalador & templates
Copiar a skill e templates para Claude, Codex ou Gemini; o CLI não executa o workflow.
Etapa 2 / 6
Pedido no agente
Invocar a skill em um projeto Git e trabalhar em uma feature branch.
Etapa 3 / 6
PRD → Spec → Tasks
Produzir arquivos Markdown legíveis em tasks/{slug}, preservando intenção e plano.
Etapa 4 / 6
Revisão do plano
Questionar escopo, testes e handoff antes da implementação; resolver lacunas nos artefatos.
Etapa 5 / 6
Implementar & verificar
Executar as tarefas e verificações no runtime do agente, preservando trabalho não relacionado.
Etapa 6 / 6
Commit local & handoff
Entregar branch e comandos para push/PR. O fluxo não publica nem abre PR automaticamente.
Distribuição da skill e execução da feature têm responsabilidades separadas.
Conexões e condições
- Instalador & templates → Pedido no agenteDisponibiliza a skill
- Pedido no agente → PRD → Spec → TasksExplicita a intenção
- PRD → Spec → Tasks → Revisão do planoRevisa o plano
- Revisão do plano → Implementar & verificarResolve as lacunas
- Implementar & verificar → Commit local & handoffEntrega evidência
Fontes no GitHubFeature-marker / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
THE PIPELINE / SYSTEM MAP
gastandoya-api
Do OAuth por usuário às despesas normalizadas para o app iOS.
Movimento reduzido: explore pelas etapas.
Etapa 1 / 6
App iOS
Iniciar autorização e consumir os endpoints do backend com os cabeçalhos documentados.
Etapa 2 / 6
Backend & OAuth
Iniciar autorização, validar state no callback e trocar o code por token no servidor.
Etapa 3 / 6
Conexão por usuário
UserNotionConnectionStore usa KV quando configurado ou memória como fallback. Tokens não seguem para o cliente.
Etapa 4 / 6
Database discovery
Descobrir databases via Blocks API ou Search API e lidar com paginação e seleção.
Etapa 5 / 6
Serviço de despesas
Consultar o database selecionado e normalizar registros no formato ExpenseDTO.
Etapa 6 / 6
ExpenseDTO → iOS
O app recebe dados normalizados; o callback OAuth retorna pelo deep link intermediário.
Conexões ficam no servidor; o cliente consome um contrato de despesas.
Conexões e condições
- App iOS → Backend & OAuthAutoriza a conexão
- Backend & OAuth → Conexão por usuárioArmazena token no servidor
- Conexão por usuário → Database discoveryFornece conexão Notion
- Database discovery → Serviço de despesasDatabase configurado
- Serviço de despesas → ExpenseDTO → iOSNormaliza a resposta
- ExpenseDTO → iOS → App iOSExibe as despesas
Fontes no GitHubgastandoya-api / README ↗
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
02 / STACK
Da interface à infraestrutura.
Interfaces consistentes começam em contratos, tokens e componentes reutilizáveis.
Entrega confiável exige diagnósticos, automação e ciclos de feedback curtos.
Agentes precisam de contexto, critérios de aceite e limites de execução.
Integrações exigem isolamento, idempotência e controle de dados.
Decisões claras e conhecimento compartilhado multiplicam a capacidade do time.
03 / LOG
Software é construção contínua.
Minha trajetória conecta engenharia mobile, arquitetura e ferramentas para desenvolvimento. Hoje, meu trabalho também explora agentes de IA e fluxos de entrega de software.
Mercado Livre
Grupo OLX
TELUS Digital
$ git log --oneline_
04 / CONNECT