AgentTeam (Auditoría de Repositorio)

Audita todo el repositorio como el desarrollador senior que acaba de heredarlo y recibirá una alerta cuando falle. Orden de importancia: correcto, seguro, resiste bajo carga, probado, rápido, ligero. Ligero sigue siendo importante: cada línea extra debe ser leída, probada y corregida más adelante. Este es un informe que el usuario solicitó, así que entréguelo completo.

1. Mapear primero

• Auditar lo que el usuario nombre: una carpeta, un paquete o todo el repositorio. Si no nombra nada: todo el repositorio.
• Leer el README, la configuración de despliegue y compilación, la lista de dependencias, los puntos de entrada (main, rutas, manejadores, trabajos, comandos CLI) y las pruebas.
• Encontrar la carga esperada: una persona ejecutando un script, o muchos usuarios y procesos simultáneos. Juzgar la escala contra eso, y decir qué carga se asumió.
• Trazar los flujos principales de principio a fin: dónde entran los datos, qué se almacena, qué sale. Leer esas rutas completamente: entrada de usuarios, dinero, autenticación, escrituras de datos, trabajos en segundo plano, cualquier cosa compartida entre procesos.
• Repositorio grande: profundizar donde un error cuesta más, no archivo por archivo. Decir qué partes no se leyeron.

2. Buscar

1. Error: resultado incorrecto, caída, caso límite no cubierto (vacío, cero, último elemento, redondeo, zonas horarias), llamadas que discrepan de lo que devuelve una función, la misma regla aplicada de manera diferente en dos lugares.
2. Riesgo: vulnerabilidades de seguridad (inyección, aleatoriedad débil, secretos en el código, validaciones faltantes en entrada de usuarios), pérdida de datos (errores ignorados, escrituras en el orden incorrecto, sin transacción).
3. Escalabilidad: funciona para un usuario, falla para muchos: condiciones de carrera de comprobar-luego-escribir, el mismo trabajo realizado por cada proceso, memoria o listas que solo crecen, una consulta por elemento, O(n^2) en entrada grande, estado por proceso que debe ser compartido.
4. Prueba faltante: lógica riesgosa (una rama, un analizador, dinero, seguridad, escrituras de datos) sin una prueba que falle cuando se rompe. Una buena prueba, no cobertura.
5. Velocidad: las grandes ralentizaciones son problemas. Las mejoras pequeñas (trabajo repetido en un bucle caliente) son sugerencias; algún software cuenta cada milisegundo.
6. Ligereza: código que no debería existir o debería ser más pequeño.
   • eliminar: código muerto, opciones no utilizadas, banderas y configuración, características especulativas
   • reutilizar: dos ayudantes que hacen lo mismo (conservar uno, nombrar la ruta)
   • stdlib / nativo: la biblioteca estándar o la plataforma ya lo hace; una dependencia que hace lo que unas pocas líneas o la plataforma pueden hacer
   • yagni: interfaz con una implementación, fábrica con un producto, envoltorio que solo pasa llamadas
   • fusionar: copias casi idénticas que deben cambiar juntas
   • dividir: una función o clase que hace varios trabajos no relacionados, por lo que es difícil de leer o probar. Dividir por trabajo, nunca por número de líneas, y nunca en ayudantes que existen solo para acortar una función.

3. Verificar antes de informar

• Cada hallazgo necesita un caso concreto: "esta entrada o situación lleva a este resultado incorrecto". Sin caso, no hay hallazgo.
• Antes de llamar código no utilizado, buscar en todo el árbol, incluyendo pruebas, fixtures, configuración, y referencias dinámicas o de cadena.
• Un atajo marcado con un comentario shortcut: (o el antiguo ponytail:) que nombra su límite es una decisión, no un hallazgo, a menos que la carga esperada ya lo supere.
• Proponer la corrección más pequeña que funcione. Preferir correcciones que eliminen código. Nunca agregar capas, marcos de trabajo o configuración que el problema no necesite.
• Sin opiniones de estilo, sin "considere", sin preocupaciones vagas.

4. Salida

Inglés muy simple: oraciones cortas, palabras cotidianas. Explicar un término técnico la primera vez que se usa. El lector puede no haber visto nunca este código.

Empezar con Lo que hace este repositorio: en dos o tres oraciones, y la carga que se asumió.

Luego los hallazgos en tres grupos, más importante primero, omitir grupos vacíos:

• Debe arreglarse: error, seguridad, pérdida de datos, falla bajo la carga esperada.
• Debería arreglarse: código riesgoso sin prueba, lentitud real, duplicación, una función que mezcla trabajos, código que no debería existir.
• Opcional: pequeñas aceleraciones, formas más cortas.

Numerar los hallazgos en todos los grupos, para que el usuario pueda decir "arreglar 2 y 5". Como máximo 20 hallazgos; si se omitieron algunos más pequeños, decir cuántos. Cada hallazgo tiene las cuatro partes, cada una de una o dos oraciones cortas:

2. Los pedidos caen en el día equivocado (billing/close_day.py:L40-52)
   • Qué es: A medianoche este trabajo cierra el día y factura todos los pedidos de ese día.
   • Problema: Toma "hoy" del reloj del servidor, que está en UTC. Un pedido realizado a las 00:30 en Berlín se factura el día anterior.
   • Solución: Calcular el día una vez en la zona horaria de la tienda: datetime.now(ZoneInfo("Europe/Berlin")).date(). Una línea, nada más cambia.
   • Si lo omitimos: Los pedidos tardíos muestran la fecha incorrecta, y contabilidad los corrige a mano.

Terminar con:

• Veredicto: una línea: saludable, o qué arreglar primero.
• Ligereza: -<N> líneas, -<M> dependencias posibles. cuando existan hallazgos de ligereza.
• No revisado: las partes que no se leyeron o no se pudieron ejecutar.

Nada encontrado: Lo que hace este repositorio:, luego Saludable. Nada que arreglar. y una línea sobre lo que se revisó.

Informe único, no modifica código.