[Proyecto I]ACUSE.S.A.

[Muzkatanke]

Nombre: Antonio Milian Corrales
Grupo: C122
Repositorio: https://github.com/Muzkatanke/planificador-inteligente-eventos.git

Descripción

Proyecto de programación sobre un gestor de eventos basado en una empresa de servicios multifuncional.
Escrito en Python y desarrollado para consola.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Muzkatanke/planificador-inteligente-eventos.git

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

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

Archivos Python (7, 496 líneas en total):

• Main.py
• logic/Evento.py
• logic/Planificador.py
• logic/Recursos.py
• logic/Manejo_Eventos.py
• logic/Datos.py
• logic/Persistencia.py

4. Punto de Entrada

✅ Punto de entrada detectado: Main.py

5. Ejecución

✅ El proyecto se ejecuta.

=== BIENVENIDO AL GESTOR DE EVENTOS DE ACUSE.S.A. ===
1.Agregar evento
2.Eliminar evento
3.Ver eventos
4.Salir

Seleccione una opción: Introduce un número válido!!
=== BIENVENIDO AL GESTOR DE EVENTOS DE ACUSE.S.A. ===
1.Agregar evento
2.Eliminar evento
3.Ver eventos
4.Salir

Seleccione una opción: sh: 1: cls: not found
sh: 1: cls: not found
Traceback (most recent call last):
  File "/tmp/tmp18a_jx

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/Muzkatanke/planificador-inteligente-eventos.git

Qué hace tu proyecto

Construiste un gestor de eventos de consola para ACUSE.S.A. que va bastante más allá del CRUD típico: planificas eventos con recursos limitados, aplicas reglas de inclusión obligatoria y exclusión entre recursos (un Electricista incluye automáticamente "Accesorios de electricidad" y excluye al Plomero), calculas disponibilidad por intervalo de tiempo, detectas solapamientos y hasta reprogramas automáticamente el evento al primer hueco libre. Todo eso corre de verdad. Muy buen nivel de ambición para primer año.

Ejecución

Lo ejecuté de verdad (Python 3.12, sin dependencias externas — solo biblioteca estándar). Recorrí el menú con entradas simuladas:

• Agregar un evento (Instalación eléctrica, 20/12/2026 10:00→12:00, Electricista×1): creado correctamente, con "Accesorios de electricidad" incluido automáticamente y Plomero marcado [EXCLUIDO]. Se guardó bien en eventos.json.
• Cerré y reabrí: la persistencia funciona, el evento reaparece con sus fechas y recursos, y el contador de IDs se restaura sin duplicar.
• Agregar → Eliminar → Ver: el JSON volvió a [] y "Ver" reportó que no hay eventos. OK.
• Entradas basura en el menú (abc, 99), fechas en el pasado, fechas mal escritas: todas rechazadas con mensaje claro, sin que el programa se caiga.
• Probé la lógica de reprogramación y la de activar/finalizar directamente: ambas correctas.

Nota de entorno: usas os.system("cls"), que es de Windows; en Linux imprime cls: not found pero no rompe nada. No es un bug, solo portabilidad.

Lo que está bien

• Modularización real: separaste datos (Datos.py), lógica de reglas (Recursos.py), planificación (Evento.py, Planificador.py), casos de uso (Manejo_Eventos.py), persistencia (Persistencia.py) e interfaz (Main.py). Exactamente lo que se busca enseñar.
• Manejo de entradas robusto: cada int(input(...)) está envuelto en try/except, y los bucles re-preguntan hasta obtener algo válido. El usuario no puede tumbar el programa con basura.
• El motor de recursos funciona de verdad: inclusión, exclusión y disponibilidad por intervalo, todo verificado al ejecutar.
• Persistencia bien pensada: re-sincronizas el contador de IDs desde el máximo guardado para no duplicar entre sesiones.

Qué mejorar

• Bug concreto — tu archivo de ejemplo no carga. storage/eventos_ejemplo.json guarda las fechas en formato ISO ("2026-02-10 14:00"), pero tu código las lee con "%d/%m/%Y %H:%M" (Persistencia.py:26). Si alguien copia ese ejemplo a eventos.json, el programa revienta al arrancar con ValueError: time data ... does not match format. Además ese archivo usa el recurso "Operario", que no existe en Datos.py. Solución rápida: regenera el ejemplo desde tu propia app (que sí escribe el formato correcto) o corrige las tres fechas a dd/mm/aaaa hh:mm y cambia "Operario" por un recurso real.
• Protege la carga con try/except. load_events() se llama sin red de seguridad (Manejo_Eventos.py:8); cualquier JSON inconsistente tumba el arranque con un traceback crudo. Envuélvelo y muestra un mensaje amable en vez de crashear.
• os.system("cls") no es portable. Un print("\n"*50) funciona en cualquier sistema.
• Detalle pequeño: en Persistencia.py:42 usas dict como nombre de variable, lo que sombrea el tipo built-in dict. Renómbralo a d o raw. Y en Recursos.py:1-3 importaste resources, rules dos veces (línea repetida).

Sobre el informe

Muy buen informe: explica el dominio, los eventos, los recursos, las reglas y la estructura del código, y coincide bien con lo implementado. La tabla de recursos y las reglas descritas concuerdan con Datos.py. La única inconsistencia real es que presentas eventos_ejemplo.json como "referencia del formato", pero ese archivo no carga con tu propio código (mismo bug de arriba) — vale la pena arreglarlo para que el ejemplo y el código digan lo mismo.

Buen trabajo, Antonio. La lógica de negocio es lo más difícil de este proyecto y la resolviste bien; el arreglo del ejemplo y un try/except en la carga te dejan un proyecto redondo.