Actúa como un revisor de código senior que además sabe explicar las cosas a alguien sin formación técnica. Voy a pasarte un cambio de código y necesito entenderlo y decidir si lo acepto.
Mi nivel: [programador con experiencia / junior / no programo, construyo con IA]
Qué se supone que hace este cambio: [describe en una o dos frases el encargo original]
Qué es la aplicación: [dos frases sobre el proyecto]
CAMBIO A REVISAR:
[Pega aquí el diff completo, o los ficheros antes y después. Si es largo, pégalo por partes y avísame]
Devuélveme, en español y sin jerga innecesaria (cuando uses un término técnico, explícalo entre paréntesis la primera vez):
1. RESUMEN EN TRES FRASES. Qué hace este cambio, contado como se lo contarías a alguien que paga por la aplicación pero no la programa.
2. FICHERO POR FICHERO. Para cada fichero tocado: qué había antes, qué hay ahora y por qué se ha cambiado. Una o dos frases por fichero, nada de recitarme el código.
3. ¿HACE LO QUE SE PEDÍA? Responde sí, no o parcialmente, y justifícalo comparando con el encargo que te he descrito. Si hace cosas que nadie pidió, dilo aquí y márcalo claramente.
4. PROBLEMAS ENCONTRADOS, ordenados por prioridad:
- P0: puede provocar pérdida de datos, un fallo de seguridad, un cobro incorrecto o dejar la aplicación caída.
- P1: puede romper una funcionalidad existente o fallar en un caso realista.
- P2: mejorable, pero no urgente.
Para cada problema: en qué fichero y línea está, qué situación concreta lo dispara y cuál es el arreglo. Si no encuentras nada de un nivel, escribe "ninguno" en vez de rellenar.
5. LO QUE NO PUEDO VERIFICAR. Qué partes del cambio dependen de código, datos o configuración que no me has pasado y por tanto no puedo asegurar. Sé honesto aquí.
6. ANTES DE ACEPTAR, COMPRUEBA ESTO. Entre 3 y 6 acciones concretas que yo debo hacer en la aplicación, con el resultado esperado de cada una. Escríbelas como pasos que pueda seguir alguien que no sepa programar.
No suavices los problemas para quedar bien. Si el cambio está mal planteado de raíz, dilo en la primera línea.
Traduce y audita un diff aunque no programes
Explica en español llano qué cambia un diff, señala lo peligroso por prioridad y te dice exactamente qué comprobar antes de aceptarlo.
