El reto: tickets que cambian de estado sin romperse

Mapa conceptual

# Reto: crea un sistema de tickets
## El reto: tickets que cambian de estado sin r
## Contexto · Wikipedia
## El modelo: un dato, muchas vistas

Contexto · Wikipedia

Reto: Reto puede referirse a: Amikeca Reto, "Red de la amistad" en esperanto. Competición, desafío. Los habitantes de Retia.

Wikipedia: Reto
Texto consultado y adaptado de Wikipedia (licencia CC BY-SA 4.0).

9-Euro-Tickets VBB.jpg — Imagen libre de Wikimedia Commons (CC BY-SA 4.0, autor: de:Benutzer:Skydou23)

Especificación mínima: (1) crear ticket con título, descripción, prioridad (alta/media/baja) y responsable; (2) tablero con tres columnas: abierto, en proceso, cerrado — mover un ticket de columna cambia su estado; (3) vista filtrada: 'solo altas abiertas' y 'lo mío' (por responsable). Fuera del alcance: SLAs y escalaciones, comentarios con notificaciones, adjuntos, roles y permisos, integración con correo. El CRM te enseñó a guardar; los tickets te enseñan algo más escurridizo: que el estado viaje bien. Un ticket que pasa de 'abierto' a 'cerrado' debe desaparecer de la columna correcta, reflejarse en los filtros y seguir existiendo en el historial. Ahí es donde se rompen el 90% de los sistemas hechos con IA.

El bug clásico de este reto Mover el ticket cambia la columna visual pero no el estado guardado (o al revés): al recargar, todo vuelve a su lugar. Por eso la regla: valida cada transición RECARGANDO, no arrastrando bonito. La persistencia es la única prueba de que el estado cambió.

El modelo: un dato, muchas vistas

Cuatro piezas, un solo principio: el estado vive en el dato, no en la pantalla.
Pieza	Qué es	Trampa a vigilar
Ticket	Registro: título, descripción, prioridad, responsable, estado, creado	Estado guardado como texto libre ("Abierto" vs "abierto"): usa valores fijos
Tablero 3 columnas	La misma lista filtrada por estado	Mover sin recargar parece funcionar; recarga y miente
Filtros	Consultas: prioridad + estado, responsable actual	Filtrar en la vista y no en los datos deja tickets fantasma
Transición	Acción: cambiar estado (no borrar y crear)	Permitir "cerrar" sin responsable borra la trazabilidad

Cómo atacarlo

Pide el CRUD de tickets con estado fijo (abierto/en_proceso/cerrado) y datos semilla en los tres estados. Sin tablero todavía.
El tablero no mueve datos, pregunta por estado. Mover = PATCH de estado, no mover un cartoncito.
Mueve un ticket, recarga la página: ¿sigue en su columna? Si sí, el estado es real.
"Altas abiertas" y "mías" combinados. Un ticket no puede estar en dos filtros que se contradicen.
Cierra sin responsable, crea con título vacío, recarga a media transición. Demo de 30 segundos mostrando el viaje completo.

Ordena los pasos del flujo de trabajo correcto en este reto

☰

Arrastras un ticket a "cerrado", se ve perfecto... pero al recargar la página regresa a "abierto". ¿Cuál es el diagnóstico correcto?

Para este reto, modelar el estado como texto libre que el usuario escriba es aceptable porque la IA puede interpretarlo igual.

Antes de promptear, escribe las 6 reglas de estado de TU tablero: qué estados existen, qué transiciones son válidas, qué se exige para cerrar, y qué pasa al recargar a media transición. Compáralas con las de otro compañero.

Pista

Si no puedes escribir las reglas sin abrir la app, las reglas viven en la pantalla, no en el modelo.

Siguiente reto: Crea un analizador de PDF — de datos que tú capturas a datos que el mundo te manda desordenados: aquí la IA sí es el motor.

Sigue: Cómo usar el laboratorio
Objeto de la misma ruta para continuar aprendiendo.