[Proyecto I]

[ErielMichel]

Eriel Michel
Grupo:C111
Repositorio:https://github.com/ErielMichel/Furvito-en-la-Polar.git

Descripción

Aplicación para gestionar eventos deportivos (partidos, entrenamientos y mantenimiento) que valida restricciones de recursos, evita conflictos de horario y sugiere automáticamente el próximo espacio disponible.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/ErielMichel/Furvito-en-la-Polar.git

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

❌ No se encontró report.md en el repositorio.

3. Proyecto Python

⚠️ Sin pyproject.toml.
⚠️ Sin requirements.txt.

Archivos Python (6, 676 líneas en total):

• events/event_templates.py
• events/models.py
• events/main.py
• events/scheduler.py
• events/database.py
• events/Constraints.py

4. Punto de Entrada

⚠️ No se encontró un punto de entrada claro (main.py, app.py, etc.).

5. Ejecución

⚠️ Sin punto de entrada identificado — no se intentó ejecutar.

Resumen

• ✅ Repositorio accesible
• ❌ report.md con ≥2000 palabras
• ✅ Archivos Python
• ❌ Configuración de dependencias
• ❌ Punto de entrada
• ❌ Ejecución

2/6 verificaciones pasadas.

---

Verificación automática — los resultados son orientativos. El profesor revisará en detalle.

[ErielMichel]

Actualicé el repositorio

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/ErielMichel/Furvito-en-la-Polar.git

Qué hace tu proyecto

Construiste un gestor de eventos deportivos por consola que persiste en SQLite: creas partidos, entrenamientos y mantenimientos, valida las restricciones de recursos de cada tipo, evita que dos eventos solapados usen el mismo recurso, y tiene un scheduler que busca el próximo hueco libre. Lo más valioso es que separaste bien la lógica (base de datos, restricciones, scheduler) de la interfaz — eso hace el código limpio y testeable, y se nota que entendiste el dominio.

Ejecución

Lo corrí de verdad alimentando el menú con entradas por stdin y también invocando la lógica directamente. py_compile de todos los módulos: OK. Aunque tu requirements.txt declara streamlit, pandas y numpy, el programa en realidad solo usa la biblioteca estándar (sqlite3, datetime), así que arrancó sin instalar nada de eso.

• Crear un Official Match válido: funciona — asigna los 9 recursos, crea el evento, y al listar aparece con todo correcto.
• Conflicto de horario: un segundo evento solapado se rechaza y revierte bien (rollback).
• Restricciones violadas y fecha inválida: manejadas con mensajes claros.

Lo que está bien

• El flujo completo de crear evento → validar restricciones → asignar recursos → detectar conflicto → hacer rollback funciona end-to-end. Eso es lo difícil y lo lograste.
• Usas consultas SQL parametrizadas (?) en todas partes: evitas inyección SQL sin siquiera proponértelo. Muy bien.
• El esquema relacional (resources, events, event_resources con clave compuesta) está bien pensado, y INSERT OR IGNORE para sembrar los recursos es idempotente y elegante.
• La validación de fecha con try/except sobre datetime.fromisoformat es limpia.

Qué mejorar

• El Scheduler revienta la última semana del mes. En scheduler.py:14 usas start_from.replace(day=start_from.day + day, ...). Cuando el día actual + 7 pasa del último día del mes (del 24 en adelante en julio, por ejemplo), Python lanza ValueError: day is out of range for month y el programa cae. Lo reproduje con fecha 31 de julio. La forma correcta es sumar días con timedelta: candidate_start = (start_from + timedelta(days=day)).replace(hour=hour, minute=0, second=0, microsecond=0). Así nunca te sales del mes.
• Los recursos se descuentan para siempre, no por horario. En assign_resource_to_event (database.py:205) haces available_quantity = available_quantity - cantidad. Eso convierte available_quantity en un contador global permanente: si un evento del 1 de agosto usa las 2 porterías, ningún otro evento —ni el del 5 de agosto, sin solape— podrá usarlas. Verifiqué que pasa exactamente eso. La idea de tu scheduler es que la disponibilidad dependa del tiempo, así que en vez de descontar el pool global, cuenta cuántas unidades están reservadas solo por los eventos que solapan la franja que consultas (tu consulta de conflicto en database.py:149 ya va por ahí — solo falta no tocar el pool global).
• La duración no numérica tumba el programa. float(input(...)) en main.py:66 y main.py:135 no está protegido: si el usuario escribe abc, sale un Traceback y se cierra todo. Envuélvelo en try/except ValueError como ya hiciste con la fecha.
• Una restricción no hace nada. En Constraints.py:45, if resources_dict.get("fence",0) < 0 nunca se cumple (una cantidad nunca es negativa), pero el mensaje dice "needs at least 3 fences". Probablemente querías < 3.
• Código que sobra. models.py (la clase Resource) y event_templates.py no se importan en ningún lado — toda la gestión la haces por SQL. Y tienes dos ficheros .db en el repo; el código solo usa events/events.db.

Sobre el informe

El informe está muy bien redactado, pero describe cosas que el código no hace todavía. La §4.2 "Exclusión Mutua" (que Field Maintenance no puede usar escaleras) no está implementada en Constraints.py — no hay ninguna lógica de exclusión. La §4.3 "Límites por Tipo" (que un entrenamiento no exceda 25 balones) tampoco: tus restricciones solo validan mínimos, nunca máximos. Y la conclusión afirma que "cumple con todos los requisitos", lo cual queda matizado por los bugs del scheduler. Para la próxima, alinea el informe con lo que el código realmente hace: es mejor un informe honesto y preciso que uno que promete de más.

Muy buen trabajo en el núcleo — arreglando el scheduler y la duración quedaría redondo. ¡Sigue así!