Files
localesp/openspec/specs/pasarela-proponer-local/spec.md
T
edgar.friendly 7bb3ea22da
deploy-branch / deploy (push) Failing after 6s
deploy-branch / teardown (push) Skipped
chore(openspec): archiva pasarela-proponer-local y sincroniza specs principales
- Mueve el cambio (36/36 tareas, 4/4 artefactos) a changes/archive/
- Crea las specs principales de boton-flotante-proponer-local,
  pasarela-proponer-local y proveedores-ubicacion (con Purpose)
2026-08-16 11:51:11 +02:00

5.2 KiB

Pasarela de propuesta de local

Purpose

Experiencia guiada (wizard) en un modal para proponer un local con un solo campo por pantalla —empezando por la ubicación con autodetección del proveedor e inferencia de nombre/provincia—, sin campos de comentario ni puntuación, conservando las validaciones existentes (palabras prohibidas, duplicados, privacidad obligatoria).

Requirements

Requirement: Pasarela paso a paso en un modal

El sistema SHALL presentar la propuesta de un local como una pasarela (wizard) dentro de un modal, con un solo campo por pantalla, navegación atrás/siguiente e indicador de progreso.

Scenario: Una pantalla por campo

  • WHEN la pasarela está abierta
  • THEN cada pantalla muestra únicamente el campo correspondiente al paso actual, con botones para avanzar y retroceder

Scenario: Navegación hacia atrás

  • WHEN el usuario pulsa "Atrás" en una pantalla intermedia
  • THEN vuelve a la pantalla anterior conservando los datos ya introducidos

Scenario: Avance bloqueado sin dato válido

  • WHEN el campo de la pantalla actual está vacío o es inválido
  • THEN el botón "Siguiente" está deshabilitado y la pantalla no avanza

Scenario: Cierre del modal

  • WHEN el usuario cierra el modal (botón ✕, botón Cancelar o tecla Escape)
  • THEN la pasarela se cierra y se descarta el borrador en curso

Requirement: Orden de las pantallas empezando por Ubicación

La pasarela SHALL presentar las pantallas en este orden: 1) Ubicación, 2) Nombre, 3) Provincia, 4) Categoría, 5) Tipo específico (opcional), 6) Revisión y envío.

Scenario: Primera pantalla

  • WHEN se abre la pasarela
  • THEN la primera pantalla que se muestra es la de Ubicación

Scenario: Tipo específico omitible

  • WHEN el usuario está en la pantalla de Tipo específico
  • THEN puede continuar sin seleccionar ninguna subcategoría

Requirement: Inferencia de Nombre y Provincia desde la Ubicación

El sistema SHALL pre-rellenar los campos Nombre y Provincia a partir de la ubicación introducida en la primera pantalla (geocodificación inversa), permitiendo al usuario corregirlos.

Scenario: Nombre y provincia pre-rellenados

  • WHEN el usuario introduce una ubicación válida en la primera pantalla y esta se resuelve con éxito
  • THEN al llegar a las pantallas de Nombre y Provincia ambos campos aparecen pre-rellenados con los valores inferidos

Scenario: Valores corregibles

  • WHEN los valores inferidos no son correctos
  • THEN el usuario puede editarlos libremente antes de enviar

Scenario: Degradación sin inferencia

  • WHEN la inferencia falla o devuelve campos vacíos
  • THEN las pantallas de Nombre y Provincia aparecen vacías y el usuario los rellena manualmente, sin bloquear la pasarela

Requirement: Sin campo de comentario ni puntuación

La pasarela SHALL NOT incluir el campo de comentario/descripción ni el campo de puntuación; la propuesta se envía sin esos datos.

Scenario: Envío sin comentario ni puntuación

  • WHEN el usuario completa la pasarela y envía
  • THEN la propuesta se registra con nombre, provincia, categoría, subcategoría, dirección/enlace y coordenadas, sin descripción y sin puntuación

Requirement: Revisión y aceptación de privacidad antes de enviar

La última pantalla de la pasarela SHALL mostrar un resumen de los datos introducidos y el checkbox de aceptación de la política de privacidad, siendo este último obligatorio para enviar.

Scenario: Envío bloqueado sin aceptar privacidad

  • WHEN el usuario llega a la pantalla final sin marcar la casilla de privacidad
  • THEN el botón de envío está deshabilitado hasta que la marque

Scenario: Resumen antes de enviar

  • WHEN el usuario llega a la pantalla final
  • THEN ve un resumen legible de todos los datos introducidos con posibilidad de volver atrás a corregirlos

Requirement: Validaciones existentes integradas en la pasarela

La pasarela SHALL conservar las validaciones actuales del formulario: filtro de palabras prohibidas y comprobación de duplicados, mostrando los avisos dentro del modal.

Scenario: Palabra prohibida detectada

  • WHEN el texto introducido contiene una palabra no permitida
  • THEN se muestra un aviso dentro del modal y la propuesta no se envía

Scenario: Posible duplicado detectado

  • WHEN al enviar se detecta un local igual o muy cercano
  • THEN se muestra el aviso de duplicado dentro del modal con las coincidencias y las opciones de enviar de todos modos o revisar los datos

Scenario: Envío correcto

  • WHEN la propuesta se envía con éxito
  • THEN el modal se cierra y aparece la confirmación de propuesta enviada en la página principal

Requirement: Modal responsive accesible

El modal de la pasarela SHALL ser usable en PC (diálogo centrado) y móvil (ocupando prácticamente toda la pantalla), con foco contenido y cierre mediante Escape.

Scenario: Uso en móvil

  • WHEN la pasarela se abre en una pantalla estrecha
  • THEN el modal ocupa el ancho completo y es operativo con teclado y scroll táctil

Scenario: Foco contenido en el modal

  • WHEN el modal está abierto
  • THEN el foco de teclado permanece dentro del modal y la tecla Escape lo cierra