[Proyecto I] Gestor Musical

[Shelflogic]

Nombre: Andres F. Bell Barcelo
Grupo: C111
Repositorio: https://github.com/Shelflogic/Proyecto_de_Pro

Descripción

Este proyecto está pensado para organizar y gestionar la renta de equipos y personal para eventos (como escenarios, consolas de sonido, micrófonos, luces, etc). El objetivo principal es simular cómo funcionaría el negocio de una productora, controlando que los recursos alcancen y que no se superpongan las fechas entre diferentes clientes.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Shelflogic/Proyecto_de_Pro

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 (3, 694 líneas en total):

• Funciones.py
• Menu.py
• Main.py

4. Punto de Entrada

✅ Punto de entrada detectado: Funciones.py

5. Ejecución

✅ El proyecto se ejecuta.

(sin salida)

Resumen

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

4/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/Shelflogic/Proyecto_de_Pro

Qué hace tu proyecto

Construiste un gestor de renta de equipos y personal para eventos que simula el negocio de una productora. Lo más valioso está en el corazón del problema: controlas la disponibilidad de cada recurso por fechas, detectando cuándo dos clientes solapan sus reservas con la misma empresa, y hasta sugieres automáticamente el próximo "hueco" libre en el calendario. Además implementaste tres reglas de negocio realistas (consola de sonido exige ingeniero, exclusión entre consolas de luces, luces con efectos exigen consola inteligente). Todo eso, en primer año, es ambicioso y está bien logrado.

Ejecución

Lo corrí de verdad, recorriendo las 8 opciones del menú con los datos reales de tu repo (Python 3.12, sin dependencias externas — solo json, datetime y copy). Los tres módulos compilan sin errores.

• Un contrato completo funciona: renté la empresa sas para 2011-01-05/06, rellené las cantidades y confirmé; se guardó evento_3 con su periodo y lista_asignacion.json pasó a [1,2,3]. RC 0.
• La disponibilidad por solape es correcta: al pedir fechas que solapaban evento_1 (que ya reserva 1 de cada recurso sobre un stock de 2), me mostró exactamente 1 disponible de esos recursos y 2 de los que evento_1 no había reservado.
• La sugerencia de hueco libre funciona: me propuso "desde 2010-10-03 hasta 2010-10-10", que es el hueco real entre evento_1 y evento_2.
• Verifiqué también: validación de fechas malas, empresa inexistente, cantidad no numérica o mayor a la disponible, la restricción del ingeniero de sonido, cancelar un evento y la guarda que impide borrar una empresa que tiene reservas. Todo respondió bien.

Lo que está bien

• El cálculo de disponibilidad por intervalos de fecha — el núcleo difícil del proyecto — funciona de verdad, comprobado con datos reales.
• La sugerencia automática del próximo hueco libre está correctamente implementada (ordenas los periodos y comparas fin de uno con inicio del siguiente).
• Separaste el código en tres módulos con responsabilidades claras (Main/Menu/Funciones), más de lo que hace mucha gente en este nivel.
• Usaste copy.deepcopy a propósito para no dañar los datos originales al calcular disponibilidad — eso muestra que entiendes el problema de mutación de diccionarios.
• Tu número de evento reutiliza huecos al cancelar (si borras el 2, el próximo evento vuelve a ser el 2). Buen diseño.

Qué mejorar

• Cancelar eventos ≥10 está roto. En Menu.py:218 haces int(ver_evento_cliente[-1::]), que toma solo el último dígito: para evento_12 intenta quitar el 2 de la lista. Cámbialo por ver_evento_cliente.split("_")[1] para tomar el número completo.
• except: desnudos. Los usas en varios sitios (Menu.py:37,86, Funciones.py:70). Ocultan errores reales — de hecho, si el input se interrumpe a media contratación, tu clientes.json se queda en 0 bytes porque lo abres en modo 'w' (que lo vacía) antes de tener el dato final. Captura excepciones concretas (FileNotFoundError, json.JSONDecodeError) — ya lo haces bien en Menu.py:74, generalízalo.
• El número de evento se "quema" aunque abandones el contrato. Lo escribes en lista_asignacion.json al principio de guardar_evento_cliente (Funciones.py:63-73), antes de confirmar. Si cancelas, el número queda ocupado para siempre. Asigna y persiste el número solo después de que el usuario confirme "si".
• menu() se llama a sí misma al final (Menu.py:333). Funciona, pero cada operación crece la pila de llamadas. Un while True alrededor del menú hace lo mismo sin ese crecimiento.
• Detalle: para chequear "vacío" te basta if not x: en vez de repetir is None, == {} y len(x) == 0 seguidos.

Sobre el informe

Tu REPORT.md (1262 palabras) es honesto y coincide con el código: describe las tres restricciones, el número de asignación reutilizable y la sugerencia de hueco tal como están implementados — y verifiqué que los tres funcionan. No exageras ni dices "probé exhaustivamente". Un apunte: la verificación automática lo marcó como ausente porque buscaba report.md en minúsculas y pedía ≥2000 palabras; el archivo sí existe (en mayúsculas) y su contenido es correcto. Solo ten presente que la afirmación de que el número sirve "para borrar sin alterar los eventos de los demás" (REPORT.md:45) es cierta salvo por el bug de la cancelación con números ≥10.

Muy buen trabajo — resolviste la parte genuinamente difícil. Ajusta la robustez y quedará redondo.