---
id: architect-analyze-impact
agent: architect
title: Mapear o impacto cross-stack de uma mudança estrutural
inputs: [mudança proposta]
outputs: [mapa de impacto, módulos afetados, riscos de escala, recomendação]
elicit: false
modes: [interactive, yolo]
---

# Mapear o impacto cross-stack de uma mudança estrutural

**Objetivo:** traçar a onda de choque de uma mudança estrutural por todas as camadas — quem depende
do que muda, o que quebra ao escalar e qual o custo — para que a decisão seja tomada com o blast
radius inteiro à vista, não só o ponto da edição.

**Pré-condições:**
- A mudança proposta rastreia a uma story, spec ou restrição explícita. Sem isso, **pare** e elicite
  — não analiso impacto de uma mudança que ninguém pediu.
- O codebase está acessível. Se for desconhecido, rodo `document-project` antes para ter o mapa de
  dependências.

## Passos

1. **Defina a mudança com precisão.** O que exatamente muda: um contrato de API, um modelo de dados,
   uma fronteira de serviço, uma dependência. Uma mudança mal delimitada produz um mapa de impacto
   inútil.
2. **Encontre todos os dependentes** (`Grep`/`Glob`, e code-intel se disponível). Quem importa,
   chama ou consome o que muda. Sigo a cadeia até as folhas — um consumidor esquecido é um incidente
   em produção.
3. **Classifique o impacto por camada.** Para frontend, backend, dados e infra, anoto: muda /
   precisa adaptar / fica intacto. Cada camada afetada tem um dono (banco → @data-engineer; UI →
   @ux-design-expert; código → @dev; infra/CI → @devops).
4. **Rode o teste do 10× na mudança.** O que quebra quando escalar com a mudança aplicada? Migração
   de dados sob carga, breaking change de contrato, ponto único de falha novo. Anoto o failure mode,
   não só o caminho feliz.
5. **Estime o custo e o risco.** Esforço por camada, risco de breaking change, necessidade de
   migração/feature-flag/rollback. Segurança e custo são camadas do design, não apêndices — entram
   no mapa.
6. **Emita a recomendação.** PROSSEGUIR (impacto contido, plano claro) / FRACIONAR (quebrar em passos
   menores e seguros) / RECONSIDERAR (custo/risco maior que o ganho). Roteio cada frente afetada ao
   dono e, se virar plano de execução, encaminho para `plan-create-implementation`.

## Critério de pronto (DoD)

- [ ] Todos os dependentes do que muda foram rastreados até as folhas
- [ ] O impacto está classificado por camada (muda/adapta/intacto), cada um com dono
- [ ] O failure mode ao escalar foi declarado para a mudança (teste do 10×)
- [ ] Custo, risco e estratégia de migração/rollback estão no mapa
- [ ] Há uma recomendação explícita (PROSSEGUIR/FRACIONAR/RECONSIDERAR) que rastreia ao pedido

## Falha / recuperação

- **A cadeia de dependentes é grande demais para mapear com confiança** → recomendo FRACIONAR a
  mudança em passos menores e analiso cada um; não dou por seguro um blast radius que não consegui
  fechar.
- **A mudança exige migração de dados ou schema** → defino o contrato e o risco, mas delego o DDL e o
  plano de migração à @data-engineer.
- **A mudança toca CI/CD, release ou infra de deploy** → delego ao @devops; eu mapeio o impacto,
  não executo a mudança de infra.
- **Descubro que a mudança não rastreia a nenhum requisito** → paro e devolvo: não há No Invention que
  justifique uma mudança estrutural órfã.