[Proyecto I] Ludopath #326

Activity

1. github-actions commented on Jun 27, 2026

   

   github-actionsBot

   on Jun 27, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   Repositorio analizado: https://github.com/Monica15268/Proyecto-Nuevo

   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 (4, 1,208 líneas en total):

   • src/Consola.py
   • src/FuncionesEspecificas.py
   • src/Clasessala.py
   • src/bueno.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.
2. apiad commented on Jul 16, 2026

   

   apiad

   on Jul 16, 2026

   Member

   More actions

   🔍 Revisión de Código — Claude Code

   Repositorio: https://github.com/Monica15268/Proyecto-Nuevo

   Qué hace tu proyecto

   Ludopath es un sistema de reservas de consola para una sala de juegos, con menú de 8 opciones y persistencia en guardador.json. El corazón es tu motor de validación: comprueba día laboral (L-V), horario (08:00-17:00), duración (1-7h), fecha (no pasada, ≤30 días), solapamiento de salas y compatibilidad entre recursos. Lo mejor de tu proyecto es la organización: separaste presentación (Consola.py), lógica de negocio (bueno.py), datos (FuncionesEspecificas.py) y modelo (Clasessala.py). Eso es más de lo que se ve en muchos proyectos de primer año.

   Ejecución

   Lo corrí de verdad desde src/ alimentando el menú con entradas reales. El flujo principal funciona muy bien: creé reservas válidas (se guardaron con su ID), probé entradas inválidas (fecha pasada, domingo, hora fuera de rango, duración de 10h, fecha basura, opción de menú absurda) y ninguna reventó — todas dieron el mensaje correcto. La detección de solapamiento acertó: al reservar dos veces la misma sala en horarios que chocan, la segunda se rechazó y me sugirió huecos reales. Eliminar por ID y "eliminar pasadas" también funcionaron.

   Pero encontré tres fallos concretos al ejecutar:

   • Opción 5 (Ver Estado de Salas) rompe con AttributeError: 'Salas' object has no attribute 'capacidad' (Traceback completo).
   • Opción 3 (Buscar Huecos) falla por el mismo motivo (queda atrapada en tu try/except y solo imprime el error).
   • Opción 8 (Ver recursos) corre, pero reporta stock incorrecto: reservé 1x Bocinas en un horario y al consultar el stock de esa ventana seguía diciendo "Bocinas: 2" (inventario lleno).

   Lo que está bien

   • Arquitectura modular clara: presentación / lógica / datos / modelo bien separados.
   • El motor de validación de reservas es sólido y no se cae ante entradas basura — lo verifiqué caso por caso.
   • La detección de choques de horario funciona y sugiere alternativas reales.
   • La validación de compatibilidad de recursos funciona (p. ej. "las consolas requieren bocinas").
   • Buen uso de Counter, timedelta y comprensiones en varios puntos.

   Qué mejorar

   • sala.capacidad → sala.capacity (Consola.py líneas 171 y 275). Definiste el atributo como self.capacity (Clasessala.py:18) pero lo lees como capacidad. Este único cambio revive las opciones 3 y 5. Por qué: Python no adivina el nombre; el atributo tiene que coincidir letra por letra.
   • Método mal nombrado (Consola.py:205 y FuncionesEspecificas.py:79): llamas interfaz.buscar_huecos_disponibles(...) pero el método se llama search_disponibles_hours (bueno.py:279). Aunque arregles lo anterior, la opción 3 caería aquí. Unifica el nombre.
   • Falta la clave hora_fin en los huecos: Consola.py:227 lee hueco['hora_fin'], pero search_disponibles_hours solo guarda fecha, hora_inicio, duracion (bueno.py:311-314). Añade hora_fin al dict del hueco o el listado dará KeyError.
   • Clave equivocada en el conteo de stock (opción 8): obtention_state lee valor.get('Recurses_inventary', []) (FuncionesEspecificas.py:413), pero las reservas guardan los recursos bajo 'Recursos' (línea 154). Por eso el stock nunca baja. Cámbialo a valor.get('Recursos', []).
   • Menor: tienes un try/except: desnudo en varios sitios (p. ej. FuncionesEspecificas.py:248). Captura la excepción concreta (ValueError) para no esconder bugs; justamente uno de estos ocultó parte del error de la opción 3.
   • Menor: la ruta "guardador.json" es relativa, así que la "base de datos" que ves depende de desde dónde ejecutas. Si quieres que siempre use el mismo archivo, construye la ruta a partir de la ubicación del script.

   Sobre el informe

   Está muy bien redactado y transmite tu motivación (la visita a LudoTerra es un buen gancho). Pero adelanta cosas que hoy no corren o exagera un poco: la "búsqueda inteligente" que sugiere "15 horarios" en realidad corta en 5 (bueno.py:317) y su opción de menú no ejecuta por los bugs de arriba; la "comprobación de recursos" de la opción 8 da datos erróneos; y menciona sistema de calificación, recordatorios sanitarios, tutoriales y métodos de pago que no están en el código (algunos ya los pones como "Futuras Mejoras", perfecto — solo separa bien lo que ya funciona de lo que planeas). También requests aparece en pyproject.toml pero no lo usas. Ajusta el informe a lo que el programa hace hoy y quedará impecable.

   Tienes una base excelente: el diseño está bien pensado y el núcleo funciona de verdad. Los tres arreglos que te señalo son de una o dos líneas cada uno y dejarían el menú completo funcionando. ¡Muy buen trabajo, sigue así!