Reestruturar o marketing como monorepo

TLDR: Renomear o repositório para marketing, mover a app para automation/, trocar o namespace para marketing-automation e alinhar a estrutura às convenções do onion-backend.

Contexto

O repositório marketing-automation cresce para um monorepo marketing, que abrigará múltiplas apps (automation hoje, agents no futuro). A mudança unifica as convenções de namespace com o separador --, renomeia o contexto k8s/terraform e aproxima a estrutura ao padrão do onion-backend.

Objetivos

  • Renomear o repositório marketing-automation → marketing
  • Mover o conteúdo atual para automation/ dentro do monorepo
  • Atualizar namespace/contexto: mkt-n8n → marketing-automation (ex.: marketing-automation--staging)
  • Definir a estrutura de pastas do monorepo: .workspace/ na raiz, .module/ por app
  • Alinhar a estrutura ao padrão do onion-backend
  • CI integrado, com detecção de mudanças por app

Fora de escopo

Pontos deixados em aberto para a implementação decidir:

  • O .commons fica na raiz ou dentro de cada app?
  • O que exatamente vai em .workspace/ e o que vai em .module/?
  • O Makefile da raiz delega ou apenas orienta?

Mudanças

Repositório

  • Renomear marketing-automation → marketing no GitHub
  • Criar a pasta automation/ na raiz
  • Mover todo o conteúdo atual para automation/

Namespace / contexto

  • Todos os usos de mkt-n8n → marketing-automation
  • Ambientes com o separador --: marketing-automation--staging, marketing-automation--production
  • Afeta: terraform (namespace.tf, variables.tf), overlays k8s, workflows de CI, .env.example
  • Remover todos os recursos k8s com prefixo mkt-n8n* antes de recriar com o novo namespace

.commons

  • Cada app (automation/, agents/) terá seu próprio symlink de .commons
  • Sem .commons na raiz do monorepo

Estrutura do monorepo

marketing/ ← raiz do monorepo .workspace/ ← substitui .project/ na raiz changes/ ← histórico de mudanças do monorepo ai/ ← rules e skills gerais .commons -> wehive/commons ← symlink compartilhado .claude/ ← configuração do Claude Code .github/ ← workflows com detect changes Makefile ← delega para cada app automation/ ← app atual (conteúdo de marketing-automation) .module/ ← substitui .project/ por app make/ shell/ docker/ init.sh .infra/ ← infra específica da app .commons -> wehive/commons ← symlink próprio da app (a definir) bin/ compose.yml Makefile src/ tasks/ agents/ ← futuro

Nota de hoje: a estrutura efetivamente adotada difere do que esta spec propôs — o monorepo usa modules/automation/ e a documentação vive em .project/docs/ na raiz, não em .workspace/.

CI

  • Detecção de mudanças por app (filtro de path automation/**)
  • Os workflows de deploy continuam por app, acionados via detecção de mudanças
  • Estrutura de workflows alinhada ao padrão do onion-backend

Alinhamento com o onion-backend

  • Estrutura de bin/, tasks/, .project/make/ e .project/shell/ dentro de automation/, seguindo o mesmo padrão
  • .infra/ dentro de automation/ (não compartilhado)

Como verificar

  • kubectl get ns mostra marketing-automation--staging e marketing-automation--production
  • O CI dispara apenas para a app alterada
  • make na raiz e dentro de automation/ funcionam
  • O deploy de staging funciona depois da mudança

Documentação

  • Atualizar a skill structure para refletir o padrão de monorepo (.workspace/, .module/)
  • Registrar a convenção de namespace com -- como regra compartilhada