fullstack

fullstack é para o monorepo que tem as duas metades do produto: uma API de backend e um frontend separado. Em vez de empilhar backend e frontend à mão e lembrar de adicionar audit-contracts, este bundle une os três numa escolha só — incluindo o gate de contrato cross-stack que só faz sentido quando os dois lados vivem no mesmo repo.

Por que isso existe

backend e frontend são deliberadamente estreitos — cada um fica na sua faixa para que um repo de stack única não seja forçado a carregar a outra metade. Mas um monorepo de verdade cruza essa linha o tempo todo: um endpoint muda de forma e o DTO do frontend deriva; um enum ganha uma variante que a UI não renderiza. O modo de falha de um repo full-stack é a costura entre as stacks, não cada stack isolada.

fullstack existe para tornar essa costura uma preocupação de primeira classe. Carrega tudo o que backend e frontend fazem, mais audit-contracts — a skill que pega o drift API ↔ frontend antes de ir pra produção.

Arquétipo de time

É para times que são donos das duas stacks num repo só:

• Um frontend Next.js / React e uma API Node / .NET / Python no mesmo monorepo
• Um time de produto pequeno onde as mesmas pessoas tocam as duas metades
• Stacks acopladas em que uma mudança de API e sua mudança de UI caem num PR só

Se o seu repo é de stack única, prefira o bundle mais estreito: backend para um serviço só de API, frontend para um app só de UI. fullstack num repo de stack única só carrega skills que você nunca vai disparar.

O que inclui

skills:
  - backend-patterns  # padrões de layering do lado servidor
  - test-e2e          # testes end-to-end (compartilhado pelas duas stacks)
  - frontend-patterns # design de componente, estado, a11y
  - test-component    # testes em nível de componente (RTL)
  - audit-contracts  # detecção de drift de contrato API ↔ frontend
roles:
  - backend-developer
  - dba
  - frontend-developer

Fonte: bundles/fullstack.yml

Isto é backend ∪ frontend ∪ audit-contracts. test-e2e pertence às duas stacks; o expansor de bundles o de-duplica para uma única entrada. O review per-engine da camada de dados (dba-mssql, dba-postgres, dba-mongodb, dba-redis) não está aqui — vem dos perfis de banco de dados (db-mssql, db-postgres, db-mongodb, db-redis) que o setup auto-seleciona a partir dos drivers detectados no repo, da mesma forma que faz para o bundle backend isolado. Consulte a visão geral de bundles para o eixo de perfis.

Por que cada um está aqui

• Todo o backend — backend-patterns, test-e2e e as roles backend-developer e dba. A metade de API do repo ganha os mesmos padrões e o gate pre-merge da camada de dados que ganharia do bundle isolado. (A role dba ainda casa com architect, que o quality traz.)
• Todo o frontend — frontend-patterns, test-component e a role frontend-developer. A metade de UI ganha seus padrões de componente e a camada de teste de componente.
• audit-contracts — a razão pela qual fullstack é mais do que a soma das partes. Detecta drift entre o que a API retorna e o que o frontend espera: endpoints, formatos de DTO, variantes de enum, status codes, regras de auth. Num repo de stack única essa skill não tem o que comparar; num monorepo ela guarda a costura.

Por que não incluído

• As auditorias do quality (audit-money, audit-tenant, audit-security) e as roles architect/security — são agnósticas de stack e se aplicam independentemente da forma do repo. Um repo full-stack em produção quase sempre quer fullstack + quality; mantê-los separados evita forçar o overhead de auditoria em todo repo full-stack e mantém o quality como a casa única dos gates de auditoria.
• Skills específicas de framework (dotnet, uma hipotética nextjs) — instaladas separadamente, nunca no bundle, já que nem todo repo full-stack compartilha os mesmos frameworks.

Workflow que isso habilita

Uma mudança que cruza a costura fica coerente num PR só:

1. Chega uma tarefa: “adicione um campo status à API de pedidos e exiba-o na lista de pedidos da UI.”
2. backend-developer + backend-patterns moldam a mudança de endpoint; a role dba (apoiada pelo perfil db auto-selecionado) revisa a migration que adiciona a coluna.
3. frontend-developer + frontend-patterns adicionam a coluna à UI, com os estados de loading/empty/error tratados.
4. test-component cobre os estados de render da nova célula; test-e2e cobre a jornada montada “ver lista de pedidos”.
5. audit-contracts roda pre-merge e confirma que o DTO Order do frontend bate com a nova forma da API — sem drift silencioso.

Compõe com

• starter — fundação obrigatória.
• quality — quase sempre casada em produção. Traz os gates de auditoria e a role architect que casa com dba em PRs da camada de dados.
• docs — features full-stack frequentemente justificam ADRs e PRDs que cruzam as duas metades.

Se você se pegar escolhendo backend e frontend juntos, fullstack é o bundle que você realmente quer.