[Proyecto I]

[josuetamayo05]

Nombre: Josué Alejandro Tamayo Ayrado
Grupo: C122
Repositorio: https://github.com/josuetamayo05/Smart-Event-Planner.git

Descripción

HospitalPlannerFlet es una aplicación de escritorio moderna diseñada para la planificación eficiente de eventos clínicos en entornos hospitalarios. Desarrollada con Python y el framework Flet, ofrece una interfaz intuitiva para gestionar cirugías, consultas, procedimientos y otros eventos médicos.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/josuetamayo05/Smart-Event-Planner.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.
⚠️ Sin requirements.txt.

Archivos Python (25, 4,926 líneas en total):

• HospitalPlannerFlet/version.py
• HospitalPlannerFlet/app.py
• HospitalPlannerFlet/test.py
• HospitalPlannerFlet/utils/create_users.py
• HospitalPlannerFlet/utils/auth_manager.py
• HospitalPlannerFlet/models/__init__.py
• HospitalPlannerFlet/models/database_manager.py
• HospitalPlannerFlet/models/constraint.py
• HospitalPlannerFlet/models/event.py
• HospitalPlannerFlet/models/resource.py
• HospitalPlannerFlet/models/scheduler.py
• HospitalPlannerFlet/ui/dialogs.py
• HospitalPlannerFlet/ui/__init__.py
• HospitalPlannerFlet/ui/state.py
• HospitalPlannerFlet/ui/design.py
• (y 10 más)

4. Punto de Entrada

⚠️ No se encontró un punto de entrada claro (main.py, app.py, etc.).

5. Ejecución

⚠️ Sin punto de entrada identificado — no se intentó ejecutar.

Resumen

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

2/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/josuetamayo05/Smart-Event-Planner

Qué hace tu proyecto

Es una aplicación de escritorio hecha con Python y Flet para planificar eventos clínicos en un hospital: cirugías, consultas, diagnósticos y terapias. Tras un inicio de sesión, ofrece un panel con barra lateral y varias vistas (Dashboard, Eventos, Nuevo evento, Calendario diario, Recursos y Búsqueda). El corazón del proyecto es un motor de reglas que asigna recursos (quirófanos, médicos, enfermeras, equipos) y detecta conflictos automáticamente: capacidad ocupada, choques de horario, corequisitos por tipo de evento y exclusiones mutuas. El estado se guarda en archivos JSON.

Ejecución

Monté un entorno aislado, instalé Flet y arranqué la app en modo web: el servidor levantó sin errores y respondió correctamente (HTTP 200), con la pantalla de login construyéndose sin fallos. Como no había pantalla gráfica, ejercité además toda la lógica de negocio con escenarios reales: autenticación, corequisitos del quirófano, cruce de medianoche, disponibilidad horaria, cirugía cardíaca sin cardiólogo/CEC, exclusión tomógrafo-radioterapia, capacidad de recursos y búsqueda de huecos libres. Todo respondió correctamente y no apareció ningún error de ejecución.

Lo que está bien

• Arquitectura en capas real: separaste modelos, interfaz y utilidades en carpetas propias, en vez de amontonar todo en un archivo. Para primer año esto es sobresaliente.
• Motor de validación de conflictos genuino: las reglas (equipo mínimo del quirófano, disponibilidad semanal, exclusiones mutuas, cirugía cardíaca con CEC) funcionan y son correctas al ejecutarlas.
• Seguridad de contraseñas seria: usas hashing PBKDF2 con salt e iteraciones, comparación segura e incluso migración automática desde un formato antiguo. Muy poca gente hace esto tan bien tan pronto.
• Persistencia cuidada: guardado atómico para no corromper el archivo si el proceso se corta, con respaldos e importación/exportación.

Qué mejorar

• Borra el código muerto. El archivo test.py (más de 800 líneas) es una versión vieja y monolítica de la app anterior a tu refactorización; ya no se usa y confunde. Elimínalo o muévelo a un histórico. Igual, la función sum_one_day quedó a medio escribir.
• Cierra un bug latente: hay una rama de validate_event que llama a un método que no existe (_auto_requisites). Hoy no explota porque nadie la activa, pero es una trampa: bórrala o impleméntala.
• Un import huérfano acopla capas: el scheduler importa parse_dt de la interfaz sin usarlo; quítalo para que los modelos no dependan de la UI.
• Unifica los tipos de evento: algunos eventos guardados usan cirugia_cardiovascular mientras las reglas esperan cirugia_cardiaca, así que esa validación no dispararía. Centraliza los códigos de tipo en un solo lugar.

Sobre el informe

No hay report.md, pero tu README hace de informe y es excelente: instalación, uso, estructura y capturas. Coincide con el código y no exagera funciones; si acaso, subestima lo mejor que tienes, que es el motor de reglas. Un detalle: dice que es exclusivo de Windows, pero al ser Flet corre igual en Linux (lo probé aquí).

Valoración general

Trabajo muy fuerte y por encima del nivel esperado en primer año: GUI real, arquitectura limpia, un motor de conflictos correcto y una base de datos con guardado atómico y autenticación profesional. Tu principal fortaleza es la solidez de la lógica y la infraestructura; tu principal área de mejora es la higiene del proyecto: limpiar el código muerto y cerrar el bug latente. Muy buen trabajo.

---

Revisión automática de código con Claude Code — orientativa. La nota final la pone el profesor.

📄 Reporte detallado (código, archivo y línea): ver análisis completo