ADR-0002 — Apps em produção mantêm repos próprios; monorepo abriga standards + packages + apps novos

Status: aceita Data: 2026-05-02 Decisores: Marcelo Lermen Referencia: ADR-0001

Contexto

Em 2026-05-02, durante o planejamento da fábrica Tynna, foi confirmado que:

• EuGestor Core (eugestor.net) já está em produção com dados reais de usuários, em repositório GitHub próprio.
• Loresmith (loresmith.tynna.app) está em fase de teste com usuários, em repositório GitHub próprio.
• JeP (Justo e Perfeito) ainda está em desenvolvimento, sem produção.

A proposta inicial (ADR-0001) era abrigar todos os apps (atuais e futuros) dentro do tynna-monorepo. Essa decisão foi revisitada ao se descobrir que dois apps já estão em produção/teste com usuários reais.

Opções consideradas

A. Migrar todos os apps pro monorepo agora

• Prós: refactor atômico, build cache total, types compartilhados, descoberta unificada.
• Contras: alto risco em produção; janela de manutenção necessária; ruptura de CI/CD existente; dor de cabeça pra reconfigurar deploy, secrets, branch protection; sem ganho imediato proporcional ao trabalho.

B. Manter apps em produção/teste em repos próprios; novos apps nascem no monorepo

• Prós: zero risco em produção; standards centralizados; packages compartilhados disponíveis pra todos; migração futura é opcional e por ADR.
• Contras: repos externos precisam de mecanismo pra consumir packages e referenciar standards; multi-repo tem mais cerimônia que monorepo puro.

C. Multi-repo total (sem monorepo central de código)

• Prós: isolação máxima; cada repo evolui independente.
• Contras: duplicação massiva de código (auth, RBAC, UI), sem build cache compartilhado, refactor cross-repo sofrido.

Decisão

Opção B — abordagem híbrida.

tynna-monorepo abriga:

• Standards (docs/standards/)
• ADRs (docs/adr/)
• Packages compartilhados (packages/* — @tynna/auth, @tynna/ui, @tynna/rbac, etc)
• Generators e Golden Paths (tooling/)
• Apps novos (apps/*)

Apps em produção/teste mantêm seus repos próprios:

• EuGestor Core
• Loresmith

JeP (em dev) pode entrar no monorepo agora ou manter repo próprio — decisão a ser tomada com novo ADR quando o JeP for o tópico ativo.

Como repos externos consomem o monorepo

Packages compartilhados

Publicação via GitHub Packages com escopo @tynna/:

// .npmrc no repo do EuGestor / Loresmith
@tynna:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}

pnpm install @tynna/auth @tynna/ui

Versionamento via Changesets + CI publica automaticamente em release.

Standards e ADRs

Padrão default — referência por URL no README do repo externo:

## Padrões

Este projeto segue [tynna-monorepo dev-standards.md](https://github.com/<org>/tynna-monorepo/blob/main/docs/standards/dev-standards.md).

Opcional — submódulo git quando o repo quiser uma cópia local sincronizada:

git submodule add https://github.com/<org>/tynna-monorepo.git .tynna-standards
git submodule update --init --recursive

Opcional — script de sync via CI (mais leve que submódulo):

# .tynna-sync.sh — roda em GitHub Action quando standards mudam
git clone --depth 1 --filter=blob:none --no-checkout \
  https://github.com/<org>/tynna-monorepo.git /tmp/tynna
cd /tmp/tynna && git sparse-checkout set docs/standards
cp -r docs/standards/. /target-repo/.tynna-standards/

Skills locais e config Claude Code

Cada repo externo pode adicionar .claude/dev-standards/ (link ou submódulo) pra que Claude Code carregue os padrões automaticamente.

Critérios para migração futura ao monorepo

Um app externo migra pro monorepo apenas se:

1. Custo de manter separado > custo de migrar (ex: muito refactor cross-repo, muita duplicação de código).
2. Tem janela de manutenção planejada (deploys congelados, comunicação com usuários se aplicável).
3. CI/CD redesenhado e testado em staging antes do switch.
4. Plano de rollback documentado.
5. ADR específico aprovado.

Sem ADR específico, apps externos permanecem onde estão.

Consequências

Positivas

• Zero risco em produção atual.
• Standards e packages compartilhados disponíveis pra todos sem migração forçada.
• Cada repo mantém autonomia operacional (CI, deploy, branch protection, rotinas).
• Versionamento real entre projetos via SemVer + Changesets aumenta disciplina.

Negativas

• Refactor cross-repo de packages compartilhados exige bump de versão + atualização em cada repo consumidor.
• Mais setup inicial nos repos externos (.npmrc, autenticação GitHub Packages, CI pra atualizar standards).
• Build cache não é compartilhado entre repos externos e o monorepo.

Riscos a monitorar

• Repos externos ficarem "atrasados" em standards (mitigar: scheduled task que checa compliance e abre issues).
• Versões diferentes do mesmo package em uso simultâneo entre repos (mitigar: dashboard de versões consumidas).
• Drift de stack entre repos externos e o padrão do monorepo (mitigar: revisão trimestral).