[Proyecto I] Noemilator

[KEVINJuegos]

Nombre: Kevin Y. García-Pola González
Grupo: C122
Repositorio: https://github.com/KEVINJuegos/Noemilator

Descripción:

Noemilator es un programa de planificación de horarios semanales diseñado específicamente para centros educativos. Su propósito principal es organizar, crear y ofrecer una vista general de los horarios de las diferentes sesiones o clases de un centro educativo, relacionándolos con sus respectivos locales, personal docente, alumnos, materias y otros recursos relevantes.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/KEVINJuegos/Noemilator

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.
Dependencias declaradas: flet

Archivos Python (10, 1,345 líneas en total):

• main.py
• pages/main_menu.py
• pages/workspace.py
• data/temp_save.py
• data/resources.py
• pages/panels/dashboard.py
• pages/panels/places.py
• pages/panels/grupos.py
• pages/panels/humans.py
• pages/panels/objects.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

(el programa espera entrada — timeout normal)

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/KEVINJuegos/Noemilator

Qué hace tu proyecto

Noemilator es un planificador de horarios para centros educativos hecho con Flet (GUI sobre Flutter, no consola). Tiene un menú principal que abre un workspace con seis paneles: un Dashboard con tabla semanal (días × turnos) donde armas bloques de eventos, y cinco paneles CRUD para Eventos, Grupos, Locales, Humanos y Objetos. Puedes exportar todo el estado a un archivo JSON. Lo más valioso es la arquitectura por capas: separaste el modelo de datos, la lógica de estado y las vistas de forma limpia y consistente.

Ejecución

Corrí tu código de verdad en varios niveles. Todos los módulos compilan (py_compile). Ejercité tu capa de datos (data/temp_save.py) con un centro de ejemplo —altas, bajas, edición, export JSON, rango de días, turnos, eventos de horario— y no reventó ni una vez, ni siquiera con entradas basura. Además arranqué la GUI en modo web headless: el servidor Flet respondió HTTP 200 sirviendo la interfaz. O sea, la app funciona; solo faltaba el display de escritorio (limitación de mi entorno, no de tu código).

Lo que está bien

• Separación de capas ejemplar para primer año: modelos con @dataclass en resources.py, estado y operaciones en temp_save.py, vistas en pages/. Muy legible.
• Robustez ante lo inesperado, verificada: probé borrar cosas que no existen, actualizar un turno inexistente, poner días inválidos ("Basura") — nada crashea. Los días inválidos caen bien a Lunes–Viernes (resources.py:111).
• Rango de días con wrap-around funciona: de Viernes a Lunes te devuelve ['Viernes','Sábado','Domingo','Lunes']. Bien pensado.
• Consistencia referencial: al borrar un turno también se borran los eventos de ese turno (temp_save.py:231). Ese detalle es maduro.
• El patrón de factory functions que devuelven handlers (fl_delete_evento(id)) evita el clásico bug de closures en bucles. Idiomático.
• Export JSON correcto, con acentos preservados (ensure_ascii=False).

Qué mejorar

• Completa la importación JSON. Puedes exportar pero no volver a cargar: import_from_json está solo como comentario (temp_save.py:307) y el botón Load no tiene handler (main_menu.py:14). La persistencia hoy es de una sola dirección. Empieza por leer el JSON y reconstruir las dataclasses (Event(**d), etc.).
• Encapsula el estado global. Todo vive en globales de módulo con global en cada función. Funciona con un solo proyecto, pero una clase Project que agrupe esas listas te facilitaría cargar/cambiar de proyecto y testear.
• Identificas recursos por nombre (remove_place(place_name)): dos lugares con el mismo nombre chocan y solo se borra el primero. Un id único por recurso (como ya haces con los eventos) lo resuelve.
• Detalle menor: Object sombrea el builtin object; renómbralo (p. ej. Item) para evitar confusiones.

Sobre el informe

Aquí está el punto a corregir con más cuidado: el informe describe una app más ambiciosa que la entregada. Concretamente, promete cosas que no están en el código:

• "Detección de conflictos / superposiciones" (report.md:50,72,81) — no hay ninguna lógica de conflictos en el código. Es la feature estrella declarada y está ausente.
• "Importar JSON" y "guardado automático" (report.md:51,112) — la importación no existe y el guardado es manual (por botón), no automático.
• Gestión de "materias", "alumnos", "docentes con disponibilidad/especialidad" (report.md:47,89,99) — no hay esas entidades; lo más cercano son Event (evento genérico) y ClassGroup (solo nombre). El ejemplo práctico describe un flujo de validación que el programa no ejecuta.
• La sección "Dificultades Encontradas" quedó vacía (report.md:135).

Lo que sí construiste (dashboard, CRUD de cinco recursos, export JSON) funciona bien y ya es un logro respetable. Reescribe el informe para que describa eso —lo real— en vez de lo aspiracional; así tu trabajo queda mucho mejor representado. ¡Buen esfuerzo, vas por muy buen camino!