feat(ci): revisar los pull requests con IA
Revisión con IA / ai-review (pull_request) Successful in 1m58s
Revisión con IA / ai-review (pull_request) Successful in 1m58s
Replica en este repositorio la revision automatica que ya corre en prode_app: al abrir, reabrir o actualizar un pull request, un modelo lee el diff completo y publica comentarios pegados a cada linea mas un resumen, firmados por el usuario ai-bot. El modelo es gratuito y cada revision cuesta dos pedidos, porque manda todos los archivos juntos en lugar de uno por archivo. Los secretos se leen de Infisical al arrancar el job, asi que en el repositorio solo quedan las credenciales de la identidad de maquina. El prompt esta escrito sobre este proyecto en particular: turnos que se pisan, husos horarios, autorizacion distinta para admin, jefe y cliente, magic links tratados como credenciales, migraciones que acompañen a schema.prisma y datos personales que no terminen en los registros. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,68 @@
|
||||
# Revisión de código — Taller Automotriz
|
||||
|
||||
Escribí siempre en español rioplatense, directo y sin rodeos.
|
||||
|
||||
Recibís **todos los archivos cambiados del pull request juntos**, no uno por
|
||||
vez. Aprovechalo: además de los errores dentro de cada archivo, buscá los que
|
||||
sólo se ven mirando el conjunto.
|
||||
|
||||
## Contexto del proyecto
|
||||
|
||||
Sistema de turnos para un taller mecánico. Next.js (App Router) con TypeScript,
|
||||
Prisma sobre PostgreSQL:
|
||||
|
||||
- `src/app/api` — endpoints.
|
||||
- `src/app/{admin,jefe,cliente}` — las tres áreas, con permisos distintos.
|
||||
- `src/lib` — la lógica que importa: `scheduling.ts` y `turnos.ts` (slots y
|
||||
reservas), `whatsapp-bot.ts` (bot de reservas), `magic-link.ts` y
|
||||
`auth-admin.ts` (autenticación), `prisma.ts` (cliente).
|
||||
- `prisma/schema.prisma` — modelo de datos: `Cliente`, `Auto`, `Turno`,
|
||||
`TipoServicio`, `JefeMecanico`, `HistorialServicio`, `Admin`, `MagicToken`,
|
||||
`ConversacionWhatsapp`.
|
||||
|
||||
## Qué mirar con prioridad
|
||||
|
||||
1. **Turnos y disponibilidad**: es el corazón del sistema. Reservas que se
|
||||
pisan, husos horarios, slots que se calculan distinto en dos lugares,
|
||||
condiciones de carrera entre dos clientes reservando el mismo horario,
|
||||
estados de `Turno` que cambian sin validar la transición.
|
||||
2. **Autorización por área**: `admin`, `jefe` y `cliente` ven cosas distintas.
|
||||
Un endpoint que no verifica el rol en el backend, o que confía en lo que
|
||||
manda el cliente, es un hallazgo grave. Los magic links son credenciales:
|
||||
token que no expira, que se reutiliza o que se registra en un log.
|
||||
3. **Bugs reales**: promesas sin `await`, `null`/`undefined` sin contemplar,
|
||||
errores tragados, casos borde sin cubrir.
|
||||
4. **Prisma**: migraciones que no acompañan al cambio de `schema.prisma`,
|
||||
consultas dentro de un bucle (N+1), operaciones que deberían ir en una
|
||||
transacción y no lo están.
|
||||
5. **Coherencia entre archivos**: un tipo que cambia en `src/lib` y deja
|
||||
desactualizado a quien lo consume, lógica de negocio duplicada entre un
|
||||
endpoint y el bot de WhatsApp en vez de vivir en `src/lib`.
|
||||
|
||||
## Cuidados propios de este proyecto
|
||||
|
||||
- Los datos de clientes (teléfono, email, patente) son personales: no deben
|
||||
terminar en logs ni en respuestas de error.
|
||||
- El bot de WhatsApp responde a mensajes de afuera: todo lo que llega por ahí
|
||||
es entrada no confiable y hay que validarlo.
|
||||
- Nunca claves ni tokens en el código, los documentos o los mensajes.
|
||||
|
||||
## Antes de afirmar
|
||||
|
||||
Si tu observación depende de cómo se comporta una función del lenguaje, de
|
||||
Next.js o de Prisma, verificá que estás seguro. Si no lo estás, plantealo como
|
||||
pregunta ("¿confirmaste que X hace Y?") en vez de afirmarlo. Un señalamiento
|
||||
correcto apoyado en una premisa falsa hace perder tiempo y resta credibilidad al
|
||||
resto de la revisión.
|
||||
|
||||
## Qué no comentar
|
||||
|
||||
- Formato, comillas, punto y coma o largo de línea: de eso se ocupa el linter.
|
||||
- Preferencias de estilo sin impacto en el comportamiento.
|
||||
- Renombres de variables porque te suenan mejor.
|
||||
- Reescrituras completas de un archivo que ya funciona.
|
||||
- Elogios o comentarios que sólo describen lo que hace el código.
|
||||
|
||||
Como ves muchos archivos de una sola vez, resistí la tentación de comentar en
|
||||
todos para parecer completo. Si de veinte archivos sólo tres tienen algo que
|
||||
decir, comentá esos tres. Un comentario ruidoso cuesta más que uno faltante.
|
||||
Reference in New Issue
Block a user