[Proyecto I] Gimnasio App

[LianBob]

Nombre: Lian Ernesto Gomez Piñero
Grupo: c11
Repositorio: https://github.com/LianBob/gym_project

Descripción

Aplicación de gestión de sesiones de gimnasio con GUI, consola y entrenador IA. Desarrollada en Python con Tkinter, Rich y SQLite.

[apiad]

🔧 Título corregido al formato [Proyecto I] para disparar la verificación automática.

/revisar

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/LianBob/gym_project

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

⚠️ report.md encontrado pero con solo 1,938 palabras (mínimo: 2,000).

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: rich, groq

Archivos Python (8, 2,490 líneas en total):

• sesiones.py
• entrenador_ia.py
• datos_prueba.py
• auth.py
• main.py
• consola.py
• database.py
• ui.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmp32h7lb1r/repo/main.py", line 726, in <module>
    app = GymApp()
          ^^^^^^^^
  File "/tmp/tmp32h7lb1r/repo/main.py", line 38, in __init__
    super().__init__()
  File "/opt/hostedtoolcache/Python/3.12.13/x64/lib/python3.12/tkinter/__init__.py", line 2346, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactiv

Resumen

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

5/6 verificaciones pasadas.

---

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

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/LianBob/gym_project

Qué hace tu proyecto

Construiste un gestor de sesiones de gimnasio con reserva de recursos limitados: registro/login con contraseñas cifradas, creación de sesiones que verifica solapamientos de recursos en cada franja horaria, sugerencias automáticas de horarios cuando no hay hueco, recurrencia (diaria/semanal/quincenal/mensual) y hasta un entrenador IA con Groq que arma un plan y lo convierte en sesiones reales. Y lo hiciste con dos interfaces —GUI de Tkinter y consola con Rich— apoyadas en la misma capa de lógica. Eso último es lo más valioso del proyecto.

Ejecución

Compilé los 8 módulos (todos pasan py_compile) y ejecuté el núcleo de verdad, no solo lo leí. Corrí la consola con entradas simuladas (registro → login → crear sesión con banca → Sesión creada para el 2026-07-16 09:00.) y ejecuté la lógica de negocio directamente con una docena de casos válidos e inválidos. La GUI de Tkinter no la pude abrir en mi entorno sin pantalla (xvfb): aborta con un error de xcb, pero comprobé que hasta un Tkinter mínimo aborta igual ahí, así que es limitación de mi entorno headless, no tu código —import main carga limpio.

Lo que está bien

• Modularidad real. GUI y consola reusan sesiones.py, database.py, auth.py sin duplicar la lógica. Separación presentación/negocio de nivel avanzado para primer año.
• Modelo de datos sólido. Esquema normalizado con tabla asociativa recursos_sesion de clave primaria compuesta, claves foráneas con ON DELETE CASCADE, restricciones CHECK e índices sobre las columnas que más consultas reciben.
• Seguridad y SQL. Contraseñas con SHA-256 + salt por usuario, y todas tus consultas van parametrizadas (?), sin riesgo de inyección.
• La lógica aguanta. Probé: pedir más bancas de las que hay en esa franja → lo rechaza; fecha pasada, antes de las 5:00, terminar después de las 22:00, recurso inexistente, sobre-solicitud física → cada uno da su mensaje correcto. Las sugerencias devolvieron ['08:00', '10:01'], una antes y una después, bien ordenadas.
• Extractor de JSON del IA robusto. Lo probé con bloque ```json, con JSON suelto en el texto, sin JSON y con JSON roto: acierta cuando debe y devuelve None cuando no, sin reventar. Y sin API key, el chat captura el error y sigue vivo.

Qué mejorar

• Bug en datos_prueba.py: si lo corres sobre una base de datos limpia, falla con no such table: usuarios (línea 36), porque no crea las tablas antes de insertar. Añade database.crear_tablas(); database.precargar_recursos() al inicio del script y quedará autónomo.
• Código muerto: sesiones.py arrastra ~100 líneas comentadas (líneas 327–426) con versiones viejas de funciones. Bórralas: Git ya guarda la historia, y el archivo se lee mejor sin ese ruido.
• Duplicación de recurrencia: ya tienes generar_ocurrencias_futuras en consola.py, pero en main.py (líneas 571–588) reescribiste esa misma lógica a mano. Reusa la función; así un cambio se hace en un solo sitio.
• Imports locales repetidos: from collections import defaultdict aparece 3 veces dentro de funciones en sesiones.py. Súbelo al tope del módulo una sola vez.

Sobre el informe

Muy completo, bien escrito y en general fiel a lo que hace el código. Dos precisiones honestas: (1) afirmas que la verificación de disponibilidad y la inserción ocurren "dentro de una misma transacción" para evitar condiciones de carrera, pero en el código son dos conexiones separadas (verificar_disponibilidad y luego _insertar_sesion), así que esa garantía no está —para un proyecto monousuario no importa en la práctica, pero conviene no afirmarla; (2) hablas de "commits atómicos", y la historia tiene 4 commits, que es correcto pero no ilustra del todo esa idea. Nada de esto son features inventadas: todo lo que describes existe y funciona. Muy buen trabajo, Lian.