Capítulo 7.5 — Comunicação de breaking changes¶
🎯 Objetivo¶
Tratar comunicação de breaking changes como disciplina de engenharia, não como e-mail tardio. Em IA, breaking change atinge não só clientes externos: agentes, MCP servers, A2A peers e equipes internas também sofrem.
🛡️ Boas práticas¶
- Changelog público com semver respeitado.
- Release notes claras descrevendo o que muda, por quê, qual alternativa.
- Migration guide com exemplos antes/depois.
- Janela mínima anunciada (4–12 semanas, dependendo do impacto).
- Suporte a versões anteriores por tempo definido (não "indefinidamente").
- Alertas para consumidores ainda na versão antiga: e-mail, Slack, dashboard, ou - em sistemas internos - warning em runtime.
- Bloqueio progressivo para novos consumidores antes do desligamento total (ver Cap. 3.7.3 e 7.4).
- ADR público documentando a decisão e o caminho.
🧠 Particularidades em sistemas com agentes¶
- Quando uma tool muda, todos os agentes que a usam precisam ser re-avaliados, não apenas o agente "alvo".
- Quando um schema de saída muda, todos os consumidores downstream dependem do dual-support enquanto migram.
- Quando um MCP server muda capabilities, agentes que dependiam delas podem falhar silenciosamente - precisa de eval de regressão por agente.
- Quando um A2A Agent Card muda contrato, peers precisam de janela mínima e de capabilities versionadas explícitas.