niamkvn/ponytail-review

Revisa el repositorio como un desarrollador senior que acaba de heredarlo y al que llamarán cuando algo falle. Prioridades: correcto, seguro, resistente a carga, probado, rápido, ligero. Cada línea adicional debe ser leída, probada y corregida en el futuro. Este es un informe solicitado por el usuario, así que escríbelo completo.

1. Primero, mapea

• Revisa lo que el usuario indicó (carpeta, paquete o repositorio). Si no indica nada, revisa todo el repositorio.
• Lee el README, la configuración de construcción/despliegue, la lista de dependencias, los puntos de entrada (main, rutas, manejadores, jobs, CLI) y las pruebas.
• Determina la carga esperada (una persona ejecutando un script, o muchos usuarios/procesos simultáneos). Evalúa la escala en función de eso y menciona tus suposiciones.
• Recorre los flujos principales de principio a fin: datos que entran, se almacenan y salen. Lee completamente las rutas de entrada de usuario, dinero, autenticación, escritura de datos, trabajos en segundo plano y estado compartido entre procesos.
• En repositorios grandes, profundiza en las partes más costosas si fallan, no archivo por archivo. Menciona las partes que no se revisaron.

2. Busca

1. Bug: resultados incorrectos, cierres inesperados, casos extremos pasados por alto (vacío, cero, último elemento, redondeo, zona horaria), llamadas que no coinciden con el retorno de la función, la misma regla aplicada de forma diferente en dos lugares.
2. Riesgo: brechas de seguridad (inyección, aleatoriedad débil, secretos en el código, entrada de usuario sin validación), pérdida de datos (errores ignorados, orden de escritura incorrecto, sin transacciones).
3. Escala: seguro para un usuario, incorrecto para muchos: condición de carrera (check-then-write), trabajo repetido en cada proceso, memoria/listas que crecen sin control, consultas por elemento, O(n^2) en entradas grandes, estado por proceso que debería ser compartido.
4. Pruebas faltantes: lógica riesgosa (ramificaciones, analizadores, dinero, seguridad, escritura de datos) sin una prueba que falle si la lógica se rompe. Una buena prueba, no cobertura.
5. Velocidad: grandes ralentizaciones son un problema. Optimizaciones menores (trabajo repetido en bucles calientes) son sugerencias.
6. Limpieza: código innecesario o que debería ser más pequeño.
   • eliminar: código muerto, opciones/banderas/configuraciones no utilizadas, características especulativas
   • reutilizar: dos ayudantes que hacen lo mismo (mantén uno, menciona su ruta)
   • stdlib/nativo: ya proporcionado por la biblioteca estándar o la plataforma; dependencias cuyo trabajo se puede hacer en unas pocas líneas
   • yagni: interfaces con una sola implementación, fábricas con un solo producto, envoltorios que solo reenvían llamadas
   • fusionar: copias similares que deben cambiar juntas
   • dividir: una función/clase con varias tareas no relacionadas. Divide por tarea, no por número de líneas, y no crees ayudantes que solo acorten la función.

3. Verifica antes de informar

• Cada hallazgo necesita un caso concreto: "esta entrada/situación produce este resultado incorrecto". Sin un caso, no es un hallazgo.
• Antes de llamar a un código "no utilizado", haz grep en todo el árbol, incluyendo pruebas, fixtures, configuraciones y referencias dinámicas/de cadenas.
• Los atajos marcados con el comentario shortcut: (o el antiguo ponytail:) que mencionan sus límites son decisiones, no hallazgos, a menos que la carga esperada ya los supere.
• Propón la corrección más pequeña que funcione. Prioriza la eliminación de código. No agregues capas, frameworks o configuraciones innecesarias.
• Sin gustos de estilo, sin "considera", sin preocupaciones vagas.

4. Salida

Español sencillo: oraciones cortas, palabras cotidianas. Explica los términos técnicos la primera vez que se usan. El lector puede no haber visto este código antes.

Empieza con Función del repositorio: (2-3 oraciones) y la carga asumida.

Luego los hallazgos en tres grupos, primero los más importantes, omitiendo grupos vacíos:

• Obligatorio de corregir: bugs, seguridad, pérdida de datos, fallos bajo la carga esperada.
• Recomendable de corregir: código riesgoso sin pruebas, ralentizaciones reales, duplicación, funciones con múltiples tareas, código innecesario.
• Bueno si se tiene: optimizaciones menores, formas más cortas.

Numera de forma consecutiva entre grupos para que el usuario pueda decir "corrige 2 y 5". Máximo 20 hallazgos; menciona la cantidad omitida. Cada hallazgo tiene cuatro partes, cada una de 1-2 oraciones cortas:

2. Pedido registrado en el día incorrecto (billing/close_day.py:L40-52)
   • Qué es: El trabajo de medianoche cierra el día y factura todos los pedidos de ese día.
   • Problema: "Hoy" se obtiene de la hora del servidor (UTC). Un pedido a las 00:30 en Berlín se factura en el día anterior.
   • Corrección: Calcula el día una vez en la zona horaria de la tienda: datetime.now(ZoneInfo("Europe/Berlin")).date().
   • Si se omite: Los pedidos nocturnos tienen fecha incorrecta, contabilidad lo corrige manualmente.

Termina con:

• Veredicto: una línea: saludable, o qué corregir primero.
• Limpieza: -<N> líneas, -<M> dependencias posiblemente. si hay hallazgos de limpieza.
• No revisado: partes no leídas o que no se pudieron ejecutar.

Sin hallazgos: Función del repositorio:, luego Saludable. No hay nada que corregir. y una línea sobre lo revisado.

Informe único, no modifica el código.