Reportar un defecto en Jira

Un defecto mal reportado se cierra como "no reproducible" y el problema sigue ahí. La única regla que importa:

Quien lea tu reporte debe poder reproducirlo sin hablar contigo.

La plantilla

Copia esto en la descripción de la incidencia:

## Resumen
(Una línea: qué falla y dónde)

## Entorno
- Aplicación: ReservaLab · https://web.theproject.ec
- Usuario: studentNN@theproject.ec
- Navegador / herramienta:
- Fecha y hora:

## Pasos para reproducir
1.
2.
3.

## Resultado esperado
(Qué debería pasar, y de dónde sale ese "debería": criterio de aceptación,
regla de negocio, sentido común documentado)

## Resultado obtenido
(Qué pasa en realidad. Literal: código de estado, mensaje exacto)

## Evidencia
(Captura de pantalla, respuesta de la API, consulta SQL con su resultado)

## Severidad
(Crítica / Alta / Media / Baja — con su justificación)

## Notas adicionales
(¿Siempre pasa o a veces? ¿Solo en un navegador? ¿Depende de los datos?)

El título

El título es lo único que ve quien prioriza. Debe decir qué falla, dónde y en qué condición.

✅ Cancelar cita: un cliente puede cancelar la cita de otro cambiando el id en la URL
✅ Registro: se acepta un email sin formato válido ("no-soy-un-email")
✅ POST /appointments: devuelve 500 en vez de 400 cuando el cuerpo está vacío

❌ Error en citas
❌ No funciona el botón
❌ Bug

Cómo elegir la severidad

La severidad mide el daño, no lo molesto que es.

Severidad	Criterio	Ejemplo de este laboratorio
Crítica	Pérdida o exposición de datos, fallo de seguridad, sistema inutilizable	Un cliente puede cancelar citas de otros clientes
Alta	Una función principal no cumple su propósito; datos incorrectos	Citas que existen en la base de datos y no aparecen en la aplicación
Media	Funciona pero mal: validación ausente, error mal manejado	Se acepta un email inválido; un 500 en vez de un 400
Baja	Cosmético o de conveniencia	Un texto mal alineado, un mensaje poco claro

Severidad no es prioridad

La severidad la pones tú: es técnica y objetiva. La prioridad la pone producto: depende del negocio. Un defecto crítico en una función que nadie usa puede tener prioridad baja, y está bien.

Ejemplo completo

Así se ve un reporte que nadie va a devolverte:

Título: Cancelar cita: un cliente puede cancelar la cita de otro cambiando el id en la URL

Tipo: Bug · Severidad: Crítica

## Resumen
El endpoint de cancelación no verifica que la cita pertenezca al usuario
autenticado. Cualquier cliente puede cancelar la cita de cualquier otro
conociendo (o adivinando) su id.

## Entorno
- API: https://api.theproject.ec
- Usuario atacante: student01@theproject.ec
- Usuario víctima: student02@theproject.ec
- Fecha: 2026-07-29 16:40

## Pasos para reproducir
1. Iniciar sesión como student01 y obtener su token:
   curl -X POST https://api.theproject.ec/auth/login \
     -H 'Content-Type: application/json' \
     -d '{"email":"student01@theproject.ec","password":"<pw>"}'

2. Obtener el id de una cita de student02 (por ejemplo, 23).

3. Con el token de student01, cancelar la cita de student02:
   curl -i -X POST https://api.theproject.ec/appointments/23/cancel \
     -H "Authorization: Bearer <token-de-student01>"

## Resultado esperado
HTTP 403 Prohibido. Un usuario solo puede cancelar sus propias citas.
Referencia: el endpoint GET /appointments/:id sí valida la propiedad y
devuelve 403 en el mismo escenario, lo que confirma que es el comportamiento
previsto.

## Resultado obtenido
HTTP 200 y la cita ajena queda cancelada:
{"id":23,"user_id":10,"estado":"cancelada","cancelled_at":"2026-07-29T16:40:26Z"}

Nótese que user_id es 10 (student02) mientras el token pertenece a student01.

## Evidencia
- Respuesta HTTP completa (arriba)
- Confirmación en base de datos:
  SELECT a.id, u.email, a.estado FROM appointments a
  JOIN users u ON u.id = a.user_id WHERE a.id = 23;
  → 23 | student02@theproject.ec | cancelada

## Severidad
Crítica. Es un fallo de autorización (IDOR) que permite a cualquier usuario
autenticado alterar datos de otros. No requiere privilegios especiales ni
conocimiento técnico: basta cambiar un número en la URL. Los ids son
secuenciales, así que son triviales de adivinar.

## Notas adicionales
- Reproducible el 100% de las veces.
- El endpoint de lectura (GET /appointments/:id) NO tiene el problema: la
  comprobación de propiedad existe ahí pero falta en la cancelación.

Antes de dar "Crear"

[ ] El título dice qué, dónde y en qué condición
[ ] Los pasos son ejecutables por otra persona, con datos concretos
[ ] El resultado esperado está justificado, no es una opinión
[ ] El resultado obtenido es literal (código y mensaje exactos)
[ ] Hay evidencia adjunta
[ ] La severidad está justificada
[ ] Dice si es intermitente o siempre

Errores que hacen que te devuelvan el reporte

Error	Por qué es un problema
"No funciona"	No dice qué, ni dónde, ni cómo llegar
Pasos con "etc."	Quien lo lea no puede reproducirlo
Sin resultado esperado	Nadie puede juzgar si de verdad es un defecto
Captura de la pantalla entera	Se pierde el detalle relevante
Varios defectos en una incidencia	No se pueden priorizar ni cerrar por separado
Severidad sin justificar	Se discute la etiqueta en vez del problema

Reportar un defecto en Jira ​

La plantilla ​

El título ​

Cómo elegir la severidad ​

Ejemplo completo ​

Antes de dar "Crear" ​