Template de Impact Report: Breaks vs Must-change vs Risky

El artefacto #1 que falta cuando envias con IA no es la generacion.

Es el Impact Report.

Porque un diff puede verse inocente y romper la realidad: schema -> API/SDK -> UI flows -> auth/PII -> docs/support.

Los tests detectan parte de los "breaks". No detectan todo el drift.

Los 3 grupos que importan

Un Impact Report es una clasificacion:

1. Breaks Stop-ship. Algo va a fallar.

2. Must-change Nada se cae hoy, pero el sistema ya miente en algun punto. Eso es drift.

3. Risky Puede funcionar, pero necesita verificacion + guardrails de rollout.

La mayoria cubre (1) con tests. Cubren (3) cuando tienen miedo. Ignoran (2) porque parece opcional. Luego pagan despues.

Template de Impact Report (copiar/pegar)

INTENT (1 sentence): CHANGE SUMMARY: SURFACES TOUCHED: UI / API / DB / Policy / Docs

BREAKS (stop-ship):

• ...

MUST-CHANGE (cambios requeridos para evitar drift):

• ...

RISKY (requiere verificacion + rollout):

• ...

VERIFY PLAN:

• tests:
• runtime signals:
• owner:

ROLLOUT PLAN:

• flag? staged? thresholds?

ROLLBACK PLAN:

Ejemplo: "es solo un rename"

Renombrar un campo toca: migracion DB -> respuesta API -> tipos cliente -> validacion UI -> reglas policy -> docs.

BREAKS: Clientes antiguos se rompen o parsean mal.

MUST-CHANGE: Docs + ejemplos SDK + copy UI quedan incorrectos. Nada cae, pero la realidad se vuelve inconsistente.

RISKY: Rendimiento de migracion a escala.

Como hacerlo manualmente en 10 minutos

• Escribe la intencion (1 frase)
• Lista superficies tocadas (UI/API/DB/Policy/Docs)
• Por cada superficie pregunta: "cual es el peor fallo plausible?"
• Clasifica en Breaks / Must-change / Risky
• Agrega 1 senal de verificacion por cada item Risky

Donde encaja ContractSpec Studio

ContractSpec Studio genera un Impact Report desde los mismos inputs que tu brief/Change Card, y luego exporta work items a Linear/Jira.

Si quieres ver ejemplos:

• https://www.contractspec.studio/