[Proyecto I] AgencePro

[isabela533]

Nombre: Isabela Alvarez Ramos
Grupo: C122
Repositorio: https://github.com/isabela533/Calendar-Project

Descripción

AgencePro es una aplicación web para agencias de marketing que necesitan organizar eventos, recursos, equipo humano y presupuesto desde un solo lugar.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/isabela533/Calendar-Project

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

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

3. Proyecto Python

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

Archivos Python (21, 3,016 líneas en total):

• classes/__init__.py
• classes/session.py
• classes/resources.py
• classes/gestor_json.py
• classes/restrictions.py
• classes/working_team.py
• visual/calendario.py
• visual/inventory.py
• visual/signup.py
• visual/reportes.py
• visual/ideas.py
• visual/dashboard.py
• visual/visual.py
• visual/logic_buttons.py
• visual/fechas_clave.py
• (y 6 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/isabela533/Calendar-Project

Qué hace tu proyecto

AgencePro es una aplicación web (Streamlit) para gestionar una agencia de marketing: autenticación por correo con dos roles (admin/operador), creación y borrado de eventos con validación de presupuesto, fechas y restricciones, inventario de recursos y equipo humano, fechas comerciales clave calculadas automáticamente, calendario mensual y reportes en tiempo real. Lo más valioso: montaste todo eso sobre una arquitectura en capas de verdad, con la lógica de negocio separada de la interfaz.

Ejecución

La corrí de dos formas. Primero ejecuté tu lógica de negocio aislada (classes/, gestor/, tools/ no importan Streamlit, así que pude instanciar Session con tu cuenta de ejemplo y probar cada operación con datos reales — sobre una copia del JSON para no tocar tu dato). Después arranqué la GUI en modo headless (streamlit run main.py y también cd visual && streamlit run visual.py): ambas levantan el servidor sin ningún Traceback y responden HTTP 200. Y py_compile de todos los módulos: compilan limpio.

Lo que está bien

• La validación atómica funciona de verdad. Probé agregar un evento que pide 5 cámaras teniendo solo 1, o un proyector sin su sala requerida: en ambos casos lanza el error correcto y el inventario no se descuenta. Tu diseño de "validar todo primero, ocupar después, revertir lo ya ocupado si algo falla" (gestor/add_event.py:33-51) hace exactamente lo que prometes en el informe. Verifiqué el rollback ejecutándolo, no leyéndolo.
• El round-trip de presupuesto e inventario es correcto: agregué un evento (dinero 49900→49800, Laptop 8→7) y al borrarlo todo volvió a su valor original. ✅
• La sugerencia de huecos ante fechas ocupadas es real: al solapar un evento, me devolvió alternativas de fechas libres concretas. ✅
• Los roles se respetan: un operador que intenta agregar operadores recibe "Solo el administrador puede...", y la UI le oculta Inventario y Reportes. ✅
• Detalles avanzados bien resueltos para primer año: TYPE_CHECKING para evitar imports circulares, @property, dict como índice de inventario, comprehensions idiomáticas.

Qué mejorar

• Un bug real (menor) en el registro. En visual/signup.py:137 compruebas la cadena en inglés "already exists", pero handle_signup (visual/logic_buttons.py:54) devuelve el mensaje en español "Cuenta ya existente...". Como nunca coinciden, si alguien se registra con un correo que ya existe, en vez de avisarle "esta cuenta ya existe, inicia sesión", lo logueas directamente en esa cuenta (con su presupuesto viejo, no el que tecleó). No se pierde nada (comprobé que la cuenta no se sobrescribe), pero el aviso que describes en el informe nunca aparece. El porqué importa: comparar mensajes de texto para tomar decisiones es frágil — cualquier cambio de redacción rompe la lógica. Mejor devolver un código o usar una excepción propia.
• add_event devuelve cosas distintas según el caso: a veces True, a veces una tupla (False, sugerencias), a veces lanza excepción. Tu dashboard lo maneja bien, pero un contrato uniforme (siempre un objeto/dict resultado con success y data) sería más robusto y más fácil de leer.
• Quita los print("Your data is saved") de Gestor_json.save_data (classes/gestor_json.py:36): en una app web ese ruido no se ve, pero es depuración que quedó dentro.
• Unifica el idioma de los mensajes (mezclas español e inglés) y, de paso, considera excepciones propias en vez de Exception genérica: además de ser más claras, te habrían evitado el bug del registro.

Sobre el informe

Tu report.md es honesto y coincide muy bien con el código, sin exagerar. La afirmación central — que validas todo antes de tocar el inventario para no dejarlo inconsistente — la verifiqué ejecutándola y es cierta. La única discrepancia: dices que al registrarte "el sistema valida que el correo no esté registrado... si ya existe, invita a iniciar sesión" (report.md:87-88), pero por el bug de arriba ese aviso no llega a mostrarse. Corrige el código o el texto para que cuadren. Detalle menor: el README y main.py proponen comandos de arranque distintos (streamlit run visual.py vs streamlit run main.py) — probé los dos y funcionan, pero conviene unificarlos.

Muy buen trabajo, Isabela. Este proyecto refleja decisiones de diseño reales, no solo "que funcione", y eso es exactamente lo que se busca. Sigue así.