---
id: feature-em-projeto-existente
title: Feature em projeto existente (brownfield)
when: adicionar uma capacidade a um código que já existe e não pode quebrar
---

# Runbook — Feature em projeto existente

**Cenário (3 linhas):** o código já roda em produção e uma feature nova precisa entrar sem regressão.
O risco aqui não é construir — é NÃO quebrar o que funciona. O time entende o terreno antes de mexer,
e o gate de qualidade guarda a porta contra regressão.

## Roster (em camadas)

- **Core (sempre):** architect, dev, qa, devops
- **Sob demanda:** analyst (mapear o legado), data-engineer (migração), ux-design-expert (UI nova)

## Execução

1. **Entender o terreno** — `nexus run "mapeie a arquitetura e os pontos de integração afetados por
   <feature>"` → Aria. Sem entender o que existe, "adicionar" vira "quebrar".
2. **Estrategizar o encaixe** — `nexus run "escreva a story de <feature> apontando riscos de regressão
   e ACs de não-quebra"` → Morgan/Pax. **Gate:** `story-draft-checklist`.
3. **Estruturar a mudança** — decida migração e compatibilidade. **Gate:** `foundation-checklist`
   (dados modelados, reversível). Handoff architect → dev com o spec + as fronteiras a respeitar.
4. **Construir com rede** — `nexus run --mode sprint "implemente <feature>; NÃO altere contrato
   público sem teste de compat"` → Dex. **Gate:** `story-dod-checklist` + testes de regressão.
5. **Endurecer contra regressão** — `nexus run "revise <feature>: prove que o comportamento antigo
   segue intacto (teste de regressão) e o novo funciona"` → Quinn. **Gate:** `reality-check-checklist`.
6. **Lançar gradual** — devops sobe atrás de flag/canário, rollback ensaiado. **Gate:** `launch-checklist`.
7. **Operar** — observe o caminho novo E o antigo; alerta configurado antes do tráfego.

## Sinais de que está no caminho

- Todo bug "corrigido" e todo comportamento antigo têm teste de regressão guardando a porta.
- A mudança sobe reversível e gradual — nunca 100% de uma vez.
- Contratos públicos só mudam com teste de compatibilidade.