edgar.friendly
7bb3ea22da
- 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)
97 lines
5.2 KiB
Markdown
97 lines
5.2 KiB
Markdown
# 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
|