[Proyecto I] Victoria Secret Fashion Show

[anacalzado335-sys]

Nombre: Ana Paula Martínez Calzado
Grupo: C-122
Repositorio: https://github.com/anacalzado335-sys/Victoria-s-Secret-Fashion-Show/tree/Branch_dev

Descripción

Este software es automatiza y optimiza la gestión de la planificación de desfiles de moda para la marca Victoria's Secret.

### PD: Lo subí a esta hora por problemas de conexión

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/anacalzado335-sys/Victoria-s-Secret-Fashion-Show

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 (4, 103 líneas en total):

• models.py
• clothes.py
• resource.py
• planner.py

4. Punto de Entrada

✅ Punto de entrada detectado: clothes.py

5. Ejecución

✅ El proyecto se ejecuta.

sostén
bragas
corsés
bikinis
blusas
deportiva
juvenil
tenistacón extremo
collares
aretes gigantes
guantes
cinturones

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/anacalzado335-sys/Victoria-s-Secret-Fashion-Show (rama Branch_dev)

Qué hace tu proyecto

Construiste un planificador de desfiles de Victoria's Secret con una interfaz web en Streamlit. Permite crear desfiles con fecha/hora, asignarles modelos, lugares, ropa y accesorios, y antes de guardar valida co-requisitos (modelo sin lugar), exclusividades (Naomi Cambell no puede ir en Grand Palais) y conflictos de horario. Además tienes un asistente que busca el próximo hueco libre y una vista de agenda por modelo/lugar. Lo más valioso: separaste de verdad la lógica de negocio (Planner) de la interfaz.

Ejecución

La corrí de verdad. Primero noté que la verificación automática del issue miró la rama main (una versión vieja), así que evalué Branch_dev, donde está tu trabajo completo y tu report.md.

• Los 5 módulos compilan sin error (py_compile).
• Ejercité toda tu lógica de negocio con los datos reales de tus JSON: validate_co_requisite, validate_inclusion, is_available, add_event, save_to_json → todas funcionan correctamente. Ejemplos reales: una modelo sin lugar da tu error de co-requisito; Naomi + Grand Palais da tu error de exclusión; una modelo ocupada del 24 al 27 de septiembre detecta el choque si le pones un evento el día 26.
• Arranqué la GUI en modo headless (streamlit run main.py) → arrancó limpia, HTTP 200, sin ningún Traceback.
• Guardé un evento nuevo y lo volví a cargar: el database.json se reconstruyó perfecto con las 3 claves. El roundtrip de persistencia funciona.

Lo que está bien

• Arquitectura desacoplada de verdad. Pude probar toda tu lógica sin arrancar Streamlit, justo porque Planner recibe las listas ya instanciadas en el constructor. Eso es diseño maduro para primer año.
• Modularización por entidad: Event, Clothes, Resource, Planner, cada uno en su archivo. Muy legible.
• Validaciones que devuelven (bool, str) — patrón limpio y fácil de probar. Todas dieron el resultado esperado al ejecutarlas.
• Manejo de errores: los tres loaders atrapan FileNotFoundError, imprimen mensaje y devuelven [] sin reventar. Lo verifiqué con archivos inexistentes.
• Persistencia con ensure_ascii=False para que tildes y eñes se guarden legibles. Detalle cuidado.

Qué mejorar

• find_next_gap no siempre da el primer hueco (planner.py:151). Cuando un recurso está ocupado, avanzas gap_needed + 1 día, en vez de saltar al fin del evento que causa el choque. Al probar con una modelo ocupada de +1h a +5h buscando 3h, me devolvió un hueco a +27h en lugar del hueco válido justo tras el evento. Encuentra un hueco correcto, pero no el más cercano. Sugerencia: cuando detectes conflicto, avanza search_time = event.end en vez de + gap_needed + 1 día.
• La ropa/accesorios seleccionados no se guardan en el evento. En el formulario los eliges (main.py:99-101), pero al construir el evento solo pasas modelos y lugares a assigned_resources (main.py:115-118). La selección de ropa es visual pero no persiste. Si querías que cada desfile recuerde su vestuario, agrégalo al evento y a save_to_json.
• Validación de "lugar vacío". El informe dice que verificas que el campo lugar no esté vacío, pero en realidad validate_co_requisite solo exige lugar si hay una modelo. Un evento sin nadie pasaría. Si quieres exigir siempre un lugar, añade un chequeo explícito.
• Detalles menores de estilo: algunos typos en mensajes al usuario ("asiganr" en planner.py:88, "regristrados" en main.py:157) y métodos que hacen return lista.append(...) (devuelve None sin necesidad, planner.py:15). No afectan nada, pero pulirlos sube la calidad.

Sobre el informe

Tu report.md está bien escrito y coincide en lo esencial con el código: la POO por módulos, el desacople del Planner y el mecanismo de database.json son todos verificables. Dos matices honestos: (1) lo de "verificar que el campo lugar no esté vacío" es un poco más fuerte que lo que hace el código (la validación es condicional a que haya modelos); y (2) presentas find_next_gap como una funcionalidad sólida sin mencionar que no siempre da el hueco más cercano. Nada grave, ni features inventadas — solo un par de afirmaciones que redondean de más.

Muy buen trabajo, Ana Paula. Pasaste de consola a una web app funcional leyendo documentación por tu cuenta, con una arquitectura limpia y toda la lógica de reglas funcionando. Con los dos ajustes de find_next_gap y la persistencia de la ropa, esto queda redondo. ¡Sigue así!