[Proyecto I] Planificador Romano

[al3x24l-source]

Alex Luis Parra Espinosa
C 111:
https://github.com/al3x24l-source/planificador_romano.git:

Descripción

(Este proyecto trata de simular como seria una planificación de Batallas o reuniones en la antigua Roma).

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/al3x24l-source/planificador_romano.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.
✅ requirements.txt encontrado.
Dependencias declaradas: python

Archivos Python (13, 2,195 líneas en total):

• app.py
• main.py
• modelos/restricciones.py
• modelos/__init__.py
• modelos/recurso.py
• modelos/evento.py
• nucleo/calendario.py
• nucleo/__init__.py
• nucleo/buscador.py
• nucleo/persistencia.py
• pantallas/intro_epica.py
• pantallas/gestion_eventos.py
• pantallas/menu_principal.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

⚠️ Error al instalar dependencias en el virtualenv:

ERROR: Could not find a version that satisfies the requirement python>=3.6 (from versions: none)

[notice] A new release of pip is available: 25.0.1 -> 26.1.2
[notice] To update, run: python -m pip in

✅ El proyecto se ejecuta.

📁 Directorio de datos: /tmp/tmpoofc9tfl/repo/datos

==================================================
🎮 INICIANDO APLICACIÓN...
==================================================
Traceback (most recent call last):
  File "/tmp/tmpoofc9tfl/repo/main.py", line 21, in <module>
    app = PlanificadorRomanoApp()
          ^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/tmpoofc9tfl/repo/app.py", line 16, in __ini

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/al3x24l-source/planificador_romano

Qué hace tu proyecto

Construiste un gestor de eventos con temática romana e interfaz gráfica Tkinter: una intro épica a pantalla completa, un menú principal y una pantalla donde creas eventos (nombre, fechas, recursos), los ves en una tabla, los buscas y los eliminas. Por debajo hay bastante más de lo que parece: persistencia real en JSON, búsqueda multi-criterio, estadísticas (eventos en curso, próximos, pasados, recursos más usados) y gestión de recursos con disponibilidad. Es un proyecto ambicioso y bien organizado para primer año.

Ejecución

Como es una app gráfica, no la alimenté por consola. Compilé los 11 módulos (py_compile, todos ✅) y, como separaste muy bien la lógica de la vista, pude ejecutar el núcleo de verdad sin la GUI: creé eventos reales ("Batalla de Cannas", "Sesión del Senado", "Triunfo de César"), verifiqué que se escriben bien en eventos.json, los recargué desde disco, y probé todo el Buscador. Todo funcionó: búsqueda por nombre, por recurso, por fecha, estadísticas y el informe completo, con valores correctos. Intentar arrancar la GUI sin pantalla falla por el entorno (no hay display), no por tu código.

Lo que está bien

• Arquitectura modular real. Separaste modelos/ (Evento, Recurso), nucleo/ (Calendario, Persistencia, Buscador) y pantallas/ (una clase por vista). Que yo pudiera probar toda tu lógica de negocio sin tocar la GUI demuestra que la separación es de verdad. Esto está por encima del nivel típico de primer año.
• Persistencia sólida. El guardado/cargado a JSON funciona en ambos sentidos, con encoding='utf-8' (tildes y emojis se guardan bien) y manejo de archivo corrupto (JSONDecodeError → lista vacía, sin reventar). Lo verifiqué.
• Búsqueda defensiva. Tus métodos de fechas atrapan errores por evento y los saltan: buscar_por_rango_fechas con basura devuelve [] e imprime un aviso, sin Traceback.
• Buena defensa de tipos: agregar_evento con algo que no es un Evento lanza el TypeError esperado.

Qué mejorar

• Falta la validación de fechas que tú mismo prometes. En gestion_eventos.py:444 (_agregar_evento) solo compruebas que los campos no estén vacíos, pero nunca validas el formato ni el rango. Lo probé: un evento con inicio "no-es-fecha" o con fin anterior al inicio se acepta y se guarda. Sugerencia concreta: antes de crear el Evento, prueba datetime.strptime(inicio, "%d/%m/%Y") y datetime.strptime(fin, ...) dentro de un try/except ValueError, y compara que fin >= inicio; si algo falla, muestra un messagebox.showwarning y no agregues el evento. Es el arreglo de mayor impacto.
• Bug en el botón "+ Nuevo Recurso" (gestion_eventos.py:393): llamas messagebox.askstring(...), pero ese método no existe en tkinter.messagebox (da AttributeError). Lo correcto es simpledialog.askstring(...) — ya importas simpledialog en app.py, solo cámbialo aquí. Ahora mismo ese botón no crea el recurso.
• modelos/restricciones.py quedó huérfano. La clase Restricciones (co-requisitos y exclusiones) está bien hecha y funciona, pero no la usas en ninguna parte. O la cableas en agregar_evento (validar antes de crear el evento) o la quitas — código construido y sin conectar confunde a quien lee.
• Ruta de datos inconsistente en Recurso (recurso.py:78): agregar_recurso llama guardar_estado() sin argumento, así que usa el default "datos" relativo en vez del directorio absoluto que calcula la app. Según desde dónde ejecutes main.py, los recursos podrían guardarse en otra carpeta que los eventos. Pásale directorio_datos explícito.
• Detalle menor: varios except: desnudos (p. ej. gestion_eventos.py:582) ocultan errores; mejor atrapar el tipo concreto.

Sobre el informe

El README está muy bien presentado, pero hay dos desajustes con el código. Primero, afirma "validaciones exhaustivas" de fechas y hasta pone ejemplos de "Evento Inválido" que darían error — pero esa validación no existe en el código (lo comprobé ejecutando). Segundo, en la sección de estructura solo listas evento.py y calendario.py, y mencionas JSON como algo "(Planeado)"; en realidad tu proyecto es más grande de lo que documentas y la persistencia JSON ya está implementada y funciona. Vale la pena actualizar el README para que refleje lo que de verdad construiste — que es bastante — y para que no prometa la validación que aún falta.

Muy buen trabajo de estructura y alcance. Cierra la validación de fechas y el bug del botón, y tendrás un proyecto redondo. ¡Ave César! 🏛️