backend

backend adiciona skills específicas de backend e dois roles em cima do starter — cobrindo tanto implementação de API/serviço (a trilha backend-developer) quanto review pre-merge da camada de dados (a trilha dba, um segundo approval ao lado do architect em qualquer PR que toca a camada de dados). O bundle existe para dar aos times de backend um ponto de extensão coerente sem inflar o starter para repos que não são de backend.

Por que isso existe

As skills do starter são agnósticas de stack. debug não se importa se você está debugando Python ou C#; implement não traz opiniões específicas de framework. Mas trabalho de backend tem padrões com forma de framework que as skills agnósticas de stack não conseguem carregar: como as camadas de Repository e Service se compõem, como é uma idempotency key na fronteira da API, qual a forma de um teste end-to-end contra um servidor HTTP real com um banco de dados real.

Colocar esses padrões no starter forçaria todo repo a carregá-los, mesmo os puramente de frontend ou de tooling. backend os mantém opt-in.

Arquétipo de time

Isso é para times cujo trabalho principal é em uma API ou serviço server-side:

APIs REST ou gRPC servindo um frontend ou outros serviços
Workers em background, filas, batch jobs
Código pesado em banco de dados (migrations, ORMs, SQL puro)
Webhook handlers e adapters de integração

Se o seu repo é um frontend, uma CLI, uma biblioteca ou um projeto de tooling, backend é a forma errada. Fique com starter (e adicione quality para auditorias se você lida com dinheiro / auth / multi-tenant).

O que inclui

skills:
  - backend-patterns  # padrões com forma de framework para código backend
  - test-e2e          # protocolo de teste end-to-end (DB real, HTTP real)
roles:
  - backend-developer # persona sênior de backend para /octopus:delegate
  - dba               # gate pre-merge pareado com architect em PRs de DB

Fonte: bundles/backend.yml

backend é agnóstico de stack: traz os padrões, a disciplina de e2e e o role dba — mas não as heurísticas per-engine. As skills de review específicas de engine (dba-mssql, dba-postgres, dba-mongodb, dba-redis) chegam como perfis de banco de dados (db-mssql, …) que o setup auto-seleciona a partir do driver detectado no repo, de forma que um time SQL Server recebe só o dba-mssql — nunca os outros três. Consulte a visão geral de bundles para entender o eixo de perfis.

Por que cada item está aqui

backend-patterns — codifica as formas comuns que código de backend assume: repository pattern (encapsular acesso a dados atrás de uma interface uniforme), service layer (orquestrar lógica de negócio entre repositories e serviços externos), envelope de erro ({ data, error, metadata }), idempotência na fronteira da API, queries parametrizadas sempre. A skill entra em ação quando o agent está trabalhando em código de backend e direciona a implementação através desses padrões.
test-e2e — a disciplina de testes end-to-end. Distinta do test-tdd (que vive na fronteira unit / integration). test-e2e cobre rodar testes contra um servidor HTTP real, um banco de dados real (frequentemente via testcontainers), e asserções sobre comportamento observável em vez de estado interno.
role backend-developer — a persona para quem você delega quando a tarefa é inequivocamente de backend. O arquivo do role força detecção de stack (.NET / Scala / Node / Python) e aplica as convenções da stack detectada. Útil quando um frontend developer está despachando trabalho de backend e quer o agent no modelo mental certo.
skills per-engine de review (dba-mssql, dba-postgres, dba-mongodb, dba-redis) — não estão no backend; chegam como perfis de banco de dados (db-mssql, …) que o setup auto-seleciona a partir do driver no repo, de forma que você carrega apenas o engine que usa.
role dba — a persona que orquestra os perfis de engine instalados como um segundo gate de aprovação pre-merge ao lado do architect. O role detecta engines tocados pelo diff e despacha as skills correspondentes em paralelo.

Por que não está incluído

Nenhuma outra persona de implementador — o bundle permanece focado em backend; incluir roles de frontend ou de outros domínios fugiria do tema.
audit-money, audit-tenant, audit-security — esses vivem em quality porque a forma da auditoria deles se aplica independentemente da stack. Um repo de backend que vai para produção quase sempre quer backend + quality.
Skills específicas de framework como dotnet — chegam como perfis de stack (stack-csharp traz dotnet + as rules de C#), auto-selecionados a partir do repo (ex.: um *.csproj). Não estão no bundle backend porque nem todo backend é .NET — o eixo de perfis mantém a camada de linguagem ortogonal ao bundle de intenção.

Workflow que isso habilita

Tarefas com forma de backend ficam roteadas:

Uma tarefa chega: “adicionar idempotência ao endpoint /charges.”
O agent reconhece o sinal de backend (o path, Program.cs na árvore, ou seu explícito /octopus:delegate @backend-developer …) e entra no modo backend-developer.
backend-patterns informa a implementação: idempotency keys vão no header da requisição, são checadas contra um store antes do side effect acontecer, e a resposta é cacheada para retries subsequentes com a mesma key.
Os testes seguem test-e2e: sobem a API contra um DB real via testcontainer, fazem uma requisição com uma idempotency key, repetem a mesma requisição, asseguram que a segunda retorna a resposta cacheada sem cobrar o cliente de novo.
Se a mudança toca em dinheiro ou em escopo de tenant (provável para /charges), as auditorias do bundle quality rodam pre-merge.

Compõe com

starter — fundação obrigatória.
quality — quase sempre pareado. A maior parte do código de backend que vai para produção quer as auditorias.
docs — combina naturalmente. Mudanças de backend frequentemente justificam ADRs (formato de idempotency key, política de retry) e PRDs para novos endpoints.