yurgeno/taut-data-community

dev-review — el revisor (etapa 3)

Ojos independientes sobre el cambio. Revisa el DIFF contra la TAREA, no el diff contra nada.

Invocación	dev-review <TAREA>
Entrada	el diff del working tree + memory/spec/<TAREA>/analysis.md y implementation.md
Salida	memory/spec/<TAREA>/review.md, status: draft, veredicto approve / needs-changes
Puerta	el propietario acepta el veredicto — ver La puerta del propietario más abajo
Siguiente	needs-changes → dev-implement <TAREA> otra vez; approve → el propietario lo aterriza

0. Comprobación de entrada

• No se proporcionó <TAREA> → preguntar.
• implementation.md falta o está vacío → detener: aún no hay nada que revisar.
• implementation.md aún tiene status: draft → decirlo y revisar de todos modos si el propietario lo pide, pero registrar en el veredicto que la etapa 2 no había pasado su puerta.
• Leer el análisis ANTES del diff. Juzgar un cambio sin saber lo que se pretendía produce comentarios de estilo y omite el hallazgo importante.

Proceso (universal)

1. Re-derivar la intención a partir de la tarea y el análisis; luego juzgar si el diff la cumple. Un cambio hermoso en el lugar equivocado es un hallazgo crítico.

2. Corrección primero: casos límite, rutas de error, concurrencia, formas de datos en los límites. Luego convenciones y claridad. Nits de estilo al final y marcados como tales.

3. No confíes en la evidencia del implementador — verifícala de nuevo. Re-ejecuta la verificación decisiva tú mismo (delegando al subagente dev-reviewer cuando la suite sea larga). Las notas de implementación dicen qué se ejecutó; tu trabajo es comprobar que todavía se cumple y que se ejecutaron las cosas CORRECTAS.

4. Verifica el radio de explosión: ¿qué más consume el código cambiado? Busca usos que el diff no tocó; cambios no intencionados en lockfile, configuración o archivos generados son hallazgos.

5. Hallazgos, no arreglos. Reporta por severidad (critical / should-fix / nit) con archivo y línea; las correcciones mecánicas triviales PUEDEN aplicarse directamente, todo lo demás vuelve a dev-implement. Escribe el veredicto en memory/spec/<TAREA>/review.md, empezando con:

   ---
   tarea: <TAREA>
   etapa: review
   estado: draft
   veredicto: approve | needs-changes
   ---
   

Comprobaciones de revisión específicas de stack

node: escapes de tipo (any, as, @ts-ignore) introducidos por el diff; cadenas de promesas sin manejo de errores; dependencia no intencionada o deriva de lockfile; ediciones en monorepo que evitan el grafo del proyecto (importaciones relativas profundas entre paquetes).

jvm: nulabilidad en los nuevos límites (tipos de plataforma Kotlin, mal uso de Optional); manejo de recursos (try-with-resources / use); alcance de transacciones e inyección de nuevos beans; pruebas colocadas para que realmente se ejecuten (módulo correcto, convención de nombres correcta).

android: revisa el ciclo de vida, no solo la lógica — el trabajo iniciado en un composable o una Activity debe sobrevivir a la rotación y detenerse cuando el ámbito muere (recopilar en repeatOnLifecycle/collectAsStateWithLifecycle, cancelar corrutinas con el ámbito correcto). Un Context retenido en un objeto de larga duración es una fuga. Los nuevos permisos en AndroidManifest.xml también necesitan la ruta de solicitud en tiempo de ejecución; las API por encima de minSdk necesitan una puerta explícita. Las compilaciones de release difieren de las de debug — las reglas de R8/ProGuard para cualquier cosa reflectiva (serialización, Room, DI) son parte del cambio. Y preguntar si las pruebas instrumentadas se EJECUTARON realmente: son las que CI suele omitir.

php: declare(strict_types=1) y tipos de parámetros/retorno en código nuevo; superficies de inyección (SQL sin escape, salida sin escapar) en las rutas tocadas; supresión de errores (@) introducida por el diff; cambios de configuración/DI coherentes con las convenciones del framework.

python: tipado en los nuevos límites (Any, tipos de retorno faltantes, # type: ignore introducidos por el diff); argumentos mutables por defecto y estado mutable a nivel de clase; recursos cerrados (with para archivos y conexiones) y llamadas async efectivamente await; manejo de excepciones que traga (except Exception: pass); manifiesto y lock cambiados juntos (pyproject.toml vs uv.lock / poetry.lock); Django: una migración por cada cambio de modelo, reversible; pruebas colocadas donde el ejecutor las encuentra (tests/, test_*.py, conftest.py fixtures) y no omitidas por un marcador obsoleto.

La puerta del propietario

DETENERSE aquí — el revisor nunca aterriza el cambio ni lo reimplementa. Reporta el veredicto en dos oraciones con los hallazgos que lo motivan.

• needs-changes → el propietario decide; con su palabra el ciclo vuelve a dev-implement <TAREA>, que añade a implementation.md en lugar de empezar de nuevo. review.md permanece como el registro de lo que estaba mal.
• approve → con la aceptación explícita del propietario, establece estado: approved. Aterrizar el cambio (commit, rama, push) es un acto del propietario bajo la ley git del espacio de trabajo — no de esta habilidad.

Listo cuando

review.md lleva su frontmatter y el veredicto con hallazgos por severidad, la verificación decisiva fue vuelta a ejecutar POR TI, y el resumen del chat da el veredicto en dos oraciones. Aprueba solo lo que defenderías en un análisis post-mortem de otra persona.