El módulo anterior cerró el recorrido técnico y terminó con una promesa: construir CicloUrbano entero, de principio a fin, con Vite y React Router. Esta lección es el primer paso, y es el que más gente se salta: antes de escribir una línea de JSX hay que saber qué se construye, para quién, con qué datos y con qué decisiones técnicas. Un proyecto que empieza por npm create vite sin haber respondido a esas preguntas acaba, sin excepción, refactorizándose a mitad de camino.

Vas a hacer tres cosas, en este orden. Primero definir el producto: el alcance en una frase, las dos personas usuarias, las historias con sus criterios de aceptación y —tan importante como lo anterior— la lista explícita de lo que no entra en la primera versión. Segundo, fijar las decisiones de arquitectura en un acta que justifique cada elección y nombre la alternativa descartada, para que dentro de tres meses nadie tenga que reconstruir el razonamiento. Y tercero, montar el andamiaje real: Vite, dependencias, scripts, linter, formateador, variables de entorno, estructura de carpetas, json-server sembrado y un primer commit que ya arranca.

Al terminar tendrás un repositorio que se clona, se instala y se ejecuta, con la API de desarrollo respondiendo y sin una sola pantalla escrita. Las pantallas son la lección siguiente.

1. El producto en una frase
2. Personas usuarias y sus objetivos
3. Historias de usuario y criterios de aceptación
4. Lo que queda fuera de la primera versión, y por qué
5. Modelo de datos definitivo
6. El db.json inicial completo
7. Mapa de pantallas y árbol de rutas
8. El acta de decisiones de arquitectura
9. Crear el proyecto con Vite
10. Dependencias: qué se instala y por qué
11. El package.json completo
12. Calidad del código: ESLint, Prettier y .editorconfig
13. Variables de entorno con import.meta.env
14. Estructura de carpetas: por tipo o por funcionalidad
15. La API de desarrollo: json-server en marcha
16. Convenciones del equipo
17. El plan de trabajo: incrementos verticales
18. El primer commit

Si no puedes describir lo que construyes en una frase, todavía no sabes lo que construyes. La de este proyecto:

CicloUrbano es una aplicación web privada que permite a una persona cliente reservar bicicletas de una red urbana por estaciones, y a una persona operaria mantener el estado de la flota.

Esa frase carga más información de la que parece:

La palabra «privada» es la que decide la arquitectura de renderizado, y lo hace antes de que se discuta ninguna herramienta. Volveremos a ella en el apartado 8.

Dos personas, ni una más. Un producto con cinco perfiles en la primera versión no tiene ninguno bien resuelto.

De este cuadro salen dos consecuencias de diseño que ya no se discuten después:

• La pantalla de inicio es el catálogo, no un panel de control. El cliente es quien más entra, y entra con prisa.
• El taller es una pantalla aparte con acceso por rol, no un modo oculto del catálogo. Mezclar los dos usos en una pantalla obligaría a esconder controles por permiso en cada tarjeta, que es exactamente la clase de complejidad que se paga durante años.

Una historia de usuario tiene una forma fija —como X quiero Y para Z— y solo sirve si lleva criterios de aceptación comprobables. «Que el catálogo funcione bien» no es un criterio; «al filtrar por eléctrica solo aparecen las de tipo electrica» sí lo es. En 11-04 cada uno de estos criterios se convertirá en una prueba, y por eso están redactados así desde hoy.

La distinción no es cosmética: si el plazo se estrecha, se corta por D1-D4 sin tocar H1-H8. Tener esa línea trazada antes de empezar es lo que impide que un proyecto entregue diez cosas a medias en lugar de ocho terminadas.

Esta lista es tan importante como la anterior, y conviene escribirla y compartirla, porque lo que no está escrito se acaba pidiendo a mitad de proyecto.

Fíjate en la última fila. Decidir que algo está fuera no es decidir que nunca se hará: es decidir que no compite por el tiempo de esta versión, y de paso dejar anotado cómo se haría si llega el momento.

Cuatro entidades. Las conoces de todo el curso; aquí quedan fijadas con sus relaciones.

Tres decisiones del modelo que conviene entender antes de codificar:

1. Las relaciones se guardan por identificador, nunca anidando el objeto entero. Una reserva guarda bicicletaId, no una copia de la bicicleta. Si se anidara, el precio de la reserva quedaría congelado en el momento de crearla y cualquier cambio en la bicicleta dejaría copias desincronizadas por toda la base de datos. Es la misma normalización que se aplicó al estado de Redux en 07-04, y por el mismo motivo.
2. El estado es una cadena de un conjunto cerrado, no un booleano. disponible | alquilada | mantenimiento admite un cuarto estado el día que haga falta; disponible: true/false obliga a añadir otro booleano y a razonar sobre combinaciones imposibles.
3. El campo de la reserva se llama usuario y contiene un identificador. Es una incoherencia de nombre respecto a bicicletaId, y se conserva porque así se fijó en todo el curso: cambiarlo ahora rompería validarReserva, las pruebas y los manejadores de MSW. Se anota como deuda técnica menor en el acta, que es exactamente lo que se hace en un proyecto real con una incoherencia inofensiva ya extendida.

Este fichero es la base de datos de desarrollo y, a la vez, la semilla que 11-04 restaurará antes de cada prueba de extremo a extremo. Va en la raíz del repositorio.

El conjunto está elegido para que cada estado y cada caso límite tenga al menos un representante, que es la propiedad que debe cumplir cualquier juego de datos de desarrollo:

Ese penúltimo caso es el que más se olvida y el que más fallos produce: si nunca ves la lista vacía en desarrollo, no la diseñas, y el usuario que estrena la aplicación se encuentra un hueco en blanco.

Las rutas quedaron fijadas en el módulo 6. Aquí se comprueba que cada una sirve a una historia y que ninguna historia se queda sin pantalla.

Y la tabla de cobertura, que es la que se revisa para detectar huecos:

Un detalle que cambia respecto al módulo 6: /reservas entra dentro de la rama protegida. En su momento se dejó pública para no complicar los ejemplos; en el proyecto real, ver reservas exige sesión, porque son datos personales. Es el tipo de ajuste que aparece justo al hacer esta tabla, y por eso se hace la tabla.

Este es el documento más valioso de la lección. Cada fila registra qué se decide, por qué, y qué se descarta. Se guarda en el repositorio como DECISIONES.md y se actualiza cuando algo cambia; nunca se borra una fila, se añade la nueva con su fecha.

Y la asignación de estado, que es la aplicación literal de la taxonomía de 07-01 a este proyecto:

Con el acta firmada, el andamiaje es mecánico.

Qué ha hecho cada línea:

• npm create vite@latest descarga y ejecuta el generador oficial. El -- separa los argumentos de npm de los del generador; sin él, npm intentaría interpretar --template como suyo.
• --template react elige la plantilla de React con JavaScript. Existe react-ts para TypeScript y react-swc para usar SWC en lugar de Babel; con React 19 y el complemento oficial, la diferencia de velocidad en un proyecto de este tamaño es irrelevante.
• npm run dev levanta el servidor de desarrollo en http://localhost:5173.

Comprueba la versión de React antes de seguir, porque el proyecto asume React 19:

Nada se instala «porque sí». Cada paquete responde a una fila del acta.

La distinción entre dependencies y devDependencies no es burocracia: lo que está en dependencies puede acabar en el paquete que descarga el usuario. Poner json-server o Cypress ahí no rompería el build de Vite, pero sí engorda cualquier instalación de producción y da una señal falsa sobre lo que la aplicación necesita para funcionar.

Los scripts merecen un comentario, porque son la interfaz del proyecto para cualquiera que llegue nuevo:

El --max-warnings 0 de lint es deliberado: un aviso que no rompe nada se acumula hasta que hay ciento veinte y nadie los mira. O importan y fallan, o se desactiva la regla.

Vite genera un eslint.config.js básico. Este es el del proyecto, con las dos adiciones que exige el acta: accesibilidad y reglas de hooks.

Tres puntos que hay que entender, no copiar:

• react-hooks/exhaustive-deps como error, no como warn. Es la decisión más discutida de cualquier configuración de React y aquí se toma a conciencia: en 05-02 se vio que una dependencia omitida produce datos obsoletos que no fallan en desarrollo y sí en producción. Como aviso, se ignora; como error, obliga a resolverlo o a justificar la excepción con un comentario eslint-disable-next-line que queda visible en la revisión de código.
• jsx-a11y en modo recomendado. Caza en el editor la imagen sin alt, el onClick sobre un div sin rol ni teclado, y la etiqueta sin control asociado. No sustituye a la revisión manual de 03-06, pero elimina el 80 % de los fallos habituales antes de que existan.
• prettier va el último del array. eslint-config-prettier no añade reglas: desactiva las de ESLint que se pisan con el formateo. Si se pusiera antes, las reglas posteriores volverían a activarlas y tendrías al linter y al formateador peleándose en cada guardado.

.editorconfig es el que evita el clásico «el fichero entero aparece modificado en el diff» cuando alguien trabaja en Windows: fija los finales de línea y la indentación a nivel de editor, antes de que Prettier intervenga.

La URL de la API no puede estar escrita a mano en quince ficheros. Vite expone las variables de entorno a través de import.meta.env, con una regla estricta: solo las que empiezan por VITE_ llegan al código del cliente.

Por qué un módulo configuracion.js en lugar de leer import.meta.env allí donde haga falta:

1. Un único punto de verdad. El día que la variable cambie de nombre, se toca un fichero.
2. Valores por defecto en un solo sitio, con ??, para que clonar el repositorio y olvidarse del .env no rompa el arranque.
3. Se puede sustituir en las pruebas con un vi.mock de un módulo propio; con import.meta.env esparcido, no.

Y el aviso que se repetirá en 11-05 con todas las letras: import.meta.env es texto que se incrusta en el JavaScript que descarga el navegador. Cualquier persona puede leerlo con dos clics. Una clave de API privada, una contraseña o un token de administración no van ahí jamás, ni siquiera «temporalmente mientras probamos».

Hay dos escuelas, y las dos tienen razón en su contexto:

CicloUrbano adopta un híbrido, que es lo que hace la mayoría de proyectos reales de este tamaño: por tipo para lo compartido, por funcionalidad para el estado de dominio. Esta última parte ya venía decidida desde 07-05.

Dos reglas de colocación que evitan la mayoría de las discusiones:

• Un fichero de prueba vive junto al código que prueba (TarjetaBicicleta.jsx y TarjetaBicicleta.test.jsx en la misma carpeta). Solo la infraestructura de pruebas está en src/pruebas/. Así, al borrar un componente, su prueba se va con él.
• Un componente sube a componentes/ cuando lo usa la segunda pantalla, no antes. Hasta entonces vive junto a su página. Generalizar con un solo caso de uso produce abstracciones equivocadas.

Comprobación obligatoria antes de seguir. Si esto no responde, ninguna pantalla de 11-03 funcionará y perderás una hora buscando el fallo en React:

Lo que json-server da de serie y el proyecto va a aprovechar:

Y lo que no da, y hay que tener presente desde ahora: no valida nada, no autentica a nadie y no comprueba permisos. Un PATCH desde la consola del navegador cambia el estado de cualquier bicicleta sin sesión. Es aceptable en desarrollo y es la razón por la que 11-05 insiste en que la autorización de verdad se comprueba siempre en el servidor.

Escritas en el README.md, porque una convención que solo está en la cabeza de quien la inventó no es una convención.

Nombres

Exportaciones: export default para componentes y páginas; exportación nombrada para hooks, utilidades, slices y selectores. Mezclar los dos criterios en el mismo tipo de fichero es lo que produce importaciones inconsistentes.

Orden de importaciones, siempre el mismo, con línea en blanco entre grupos:

Mensajes de commit, en formato convencional, en español y en imperativo:

El prefijo no es decoración: permite generar el registro de cambios automáticamente y, sobre todo, obliga a que un commit haga una sola cosa. Si dudas entre feat y fix, probablemente el commit contenga dos cambios y haya que partirlo.

Aquí está la decisión de método que más influye en cómo se siente el proyecto mientras se construye.

Se elige vertical, con una salvedad honesta: este módulo está organizado por capas —interfaz, estado, pruebas, despliegue— porque explicar requiere agrupar conceptos, mientras que construir requiere entregar valor pronto. Es una diferencia importante y conviene tenerla clara: el orden del libro no es el orden del taller.

Aun así, dentro de cada lección se trabaja por historias completas. Y si estuvieras haciendo este proyecto en un equipo real, el orden sería este:

Y el orden de las historias, priorizado por riesgo primero:

1. H4 (acceso) antes que nada: es la puerta de todo lo demás y toca sesión, formulario, redirección y persistencia. Si algo va a salir mal en la arquitectura, sale mal aquí.
2. H1 + H2 (catálogo y filtro): la pantalla más visitada, y la que valida la capa de datos.
3. H5 (reservar): el camino del dinero. Toca mutación, validación, invalidación y navegación.
4. H6 (mis reservas y cancelar): reutiliza casi todo lo anterior.
5. H3, H8 (ficha y estaciones): lectura pura, poco riesgo.
6. H7 (taller): el rol se prueba con todo lo demás ya en pie.
7. D1-D4 si queda tiempo.

La regla que gobierna la lista: lo que puede hundir el proyecto va primero. Dejar la identificación para el final es el error clásico, porque es justo la funcionalidad que atraviesa todas las capas y obliga a rehacer lo que ya se dio por bueno.

Un commit inicial debe cumplir una condición: quien lo clone, puede arrancarlo.

Y el README.md que lo acompaña, que es lo primero que lee cualquiera:

npm install cp .env.example .env npm run dev:todo # Vite en :5173 y json-server en :3001

La lista de comprobación antes de dar el andamiaje por terminado:

• [ ] npm install funciona en un clon limpio
• [ ] npm run dev sirve la aplicación en el 5173
• [ ] npm run api responde en el 3001 con los cuatro recursos
• [ ] npm run lint termina sin errores ni avisos
• [ ] .env está ignorado y .env.example versionado
• [ ] DECISIONES.md tiene las diez filas del acta
• [ ] El README.md permite arrancar sin preguntar nada a nadie

• Empezar por el código y planificar sobre la marcha. Es el error de fondo de esta lección. Sin historias con criterios de aceptación no sabes cuándo has terminado, y sin acta de decisiones cada discusión técnica se repite cada dos semanas. Media jornada de planificación ahorra semanas.
• Historias sin criterios comprobables. «El catálogo debe ser rápido» no se puede verificar ni convertir en prueba. «El catálogo muestra el esqueleto mientras carga y la lista en cuanto llegan los datos» sí.
• No escribir lo que queda fuera. El alcance que no se niega explícitamente se asume incluido. La tabla del apartado 4 es la que protege la entrega.
• Anidar objetos en el modelo de datos. Guardar la bicicleta entera dentro de la reserva parece cómodo el primer día y produce datos desincronizados el segundo. Identificadores, siempre.
• Un juego de datos de desarrollo sin casos límite. Si todas las bicicletas están disponibles y todos los usuarios tienen reservas, nunca verás el estado vacío ni el botón deshabilitado, y llegarán rotos a producción.
• Poner herramientas de desarrollo en dependencies. Cypress y json-server en producción son un síntoma de que nadie ha mirado el package.json desde que se generó.
• Dejar exhaustive-deps como aviso. Con el tiempo se acumulan decenas y dejan de leerse. Como error, se resuelve o se justifica con un comentario visible.
• Poner eslint-config-prettier en cualquier posición menos la última. Deja de hacer efecto y acabas con el linter y el formateador en conflicto en cada guardado.
• Secretos en variables VITE_. Todo lo que empieza por VITE_ viaja al navegador en texto plano. No hay excepción, ni «solo mientras probamos».
• Consejo: crea DECISIONES.md desde el primer día y añade una fila cada vez que discutas una elección técnica. El valor no está en el documento, está en no volver a tener la misma conversación.
• Consejo: verifica la API con curl antes de escribir el primer fetch. Descartar la mitad del sistema en treinta segundos ahorra depuraciones larguísimas.

Ejercicio 1. El cliente pide una historia nueva: «como cliente quiero recibir un aviso 10 minutos antes de que termine mi reserva». Escríbela con el formato del apartado 3, con criterios de aceptación comprobables. Después decide si es imprescindible o deseable, y si entra o no en la primera versión, justificándolo con el alcance del apartado 1 y la tabla del apartado 4. Si decides dejarla fuera, redacta la fila correspondiente.

Ejercicio 2. El equipo propone añadir una entidad Incidencia para la pestaña de incidencias de /estaciones/:estacionId, con la información de una avería reportada. Define sus campos y sus relaciones, añádela al diagrama de entidad-relación y al db.json con dos registros de ejemplo coherentes con el canon, y explica qué recursos nuevos aparecerían en json-server. Indica además qué clave de TanStack Query le correspondería según la fábrica del proyecto.

Ejercicio 3. Un compañero propone tres cambios sobre el acta: (a) usar BrowserRouter con <Routes> porque «es más sencillo», (b) guardar la lista de bicicletas en Redux «para tenerlo todo en un sitio», y (c) poner la clave de un servicio de mapas en VITE_CLAVE_MAPAS para usarla desde el cliente. Responde a cada uno con el argumento técnico correspondiente y di qué fila del acta lo cubre. Para el tercero, explica además qué haría falta para usar ese servicio sin exponer la clave.

Solución 1.

Clasificación: deseable (D5), fuera de la primera versión. Los tres argumentos:

1. No bloquea el objetivo principal de ninguna de las dos personas. Ana puede reservar y usar la bicicleta sin el aviso; Marc no lo necesita en absoluto.
2. El aviso útil de verdad es el que llega con la aplicación cerrada, y eso son notificaciones push, que están explícitamente fuera de alcance por exigir servidor, permisos y service worker. Un aviso que solo se ve con la pestaña abierta resuelve una fracción pequeña del problema real y puede dar falsa sensación de cobertura.
3. Requiere un temporizador global que reevalúe cada minuto y una fuente de verdad de la hora actual, lo que complica las pruebas (hay que fijar el reloj) para un beneficio marginal en esta versión.

Fila para la tabla del apartado 4:

Y la anotación honesta: cuando llegue la API real, esta historia sube a imprescindible, porque el negocio penaliza la devolución tardía y avisar es más barato que cobrar recargos.

Solución 2.

Campos y relaciones. Una incidencia pertenece a una bicicleta (que a su vez está en una estación) y la reporta un usuario:

Registros para db.json, coherentes con el canon —bici-003 está en mantenimiento, así que es la candidata natural a tener una incidencia abierta, y bici-002 puede tener una ya resuelta:

Decisión de modelado importante: la incidencia se asocia a la bicicleta, no a la estación, aunque la pestaña que la muestra sea la de una estación. El motivo es que una avería viaja con la bicicleta: si bici-003 se traslada a est-03, su historial debe ir con ella. La pestaña de incidencias de una estación se obtiene entonces derivando: las bicicletas de esa estación, y las incidencias de esas bicicletas. Modelar la relación al revés obligaría a reescribir el estacionId de cada incidencia en cada traslado.

Recursos que aparecen en json-server:

Y la clave de consulta, aprovechando que la fábrica del proyecto ya la había previsto:

La jerarquía importa: invalidar ['estaciones', 'est-02'] invalida también ['estaciones', 'est-02', 'incidencias'], porque TanStack Query compara las claves por prefijo. Es justo el comportamiento que se quiere al resolver una incidencia.

Solución 3.

(a) BrowserRouter con <Routes>. Cubierto por la fila A2. Es cierto que es más sencillo de escribir, pero el proyecto necesita tres cosas que ese modo no da:

• errorElement por rama: sin él, un fallo al cargar la ficha de una bicicleta derriba toda la aplicación en lugar de dejar la cabecera y el menú en pie. Es la diferencia entre una pantalla en blanco y un error contenido.
• lazy a nivel de ruta con el enrutador gestionando la carga, que es lo que hace posible la división de código de 08-04 sin envolver cada pantalla a mano.
• La API de datos (useNavigation, useRouteError, handle para las migas de pan), que ya se usa en MigasDePan.

Y el argumento decisivo: migrar después cuesta más que empezar bien, porque implica reescribir el árbol de rutas entero cuando ya hay pantallas encima.

(b) La lista de bicicletas en Redux. Cubierto por A3 y por la tabla de asignación de estado. «Tenerlo todo en un sitio» suena a orden, pero mezcla dos cosas de naturaleza distinta: las bicicletas son estado del servidor, una copia local de un dato que vive en otra máquina y que puede cambiar sin que la aplicación se entere. Meterlas en Redux obliga a escribir a mano, y a mantener, todo esto:

Es exactamente el trabajo que 07-06 mostró que no merece la pena reescribir. Redux se queda con lo que sí es suyo: sesión, término de búsqueda y orden.

(c) La clave del servicio de mapas en VITE_CLAVE_MAPAS. Es el más grave de los tres. Todo lo que empieza por VITE_ se sustituye literalmente en el código durante la construcción y acaba en un fichero de dist/ que cualquiera puede abrir:

No hay ofuscación que lo arregle: el navegador tiene que poder leerla para usarla, luego el usuario también. Las consecuencias son consumo facturado a tu cuenta y, según el servicio, acceso a datos que no deberían salir.

Qué hacer en su lugar, en orden de preferencia:

1. Que la petición al servicio salga del servidor. El cliente llama a tu API, tu API llama al servicio con la clave y devuelve el resultado. La clave nunca sale de la máquina.
2. Si el servicio está pensado para el cliente —muchos proveedores de mapas ofrecen claves públicas—, usar ese tipo de clave y restringirla en el panel del proveedor por dominio de origen, por cuota y por permisos mínimos. Sigue siendo visible, pero solo funciona desde tu dominio y con un techo de gasto.
3. Nunca usar una clave con permisos de escritura o de facturación desde el cliente, en ninguna circunstancia.

Y como el ejercicio parte de una historia que está fuera de alcance —el mapa geográfico—, la respuesta completa incluye recordarlo: no hay que resolver el problema de la clave todavía, porque la funcionalidad no entra en esta versión.

Esta lección ha convertido una idea en un proyecto que se puede empezar a construir, y lo ha hecho en el orden correcto: primero el producto, después las decisiones, y solo al final las herramientas.

Del producto queda fijado lo esencial: CicloUrbano en una frase que ya decide la arquitectura al declararse privada, dos personas usuarias con objetivos y contextos distintos que justifican por qué el inicio es el catálogo y el taller una pantalla aparte, ocho historias imprescindibles y cuatro deseables con criterios de aceptación comprobables —que en 11-04 se convertirán literalmente en pruebas—, y una lista explícita de lo que queda fuera con su motivo, que es la que protege la entrega cuando alguien proponga añadir un mapa a mitad de camino.

Del dominio queda el modelo definitivo con sus cuatro entidades y tres reglas que se respetan sin excepción: relaciones por identificador y nunca objetos anidados, estados como cadena de un conjunto cerrado en lugar de booleanos, y las incoherencias heredadas anotadas como deuda en vez de arregladas a destiempo. El db.json no es un montón de datos de relleno: cada estado, cada caso límite y el estado vacío tienen su representante, porque lo que no se ve en desarrollo no se diseña.

Del rumbo técnico queda el acta de decisiones, diez filas con su justificación y su alternativa descartada: Vite en lugar de Next.js porque la aplicación es privada e interactiva; React Router en modo de datos por errorElement, lazy y la API de datos; TanStack Query para el servidor y Redux Toolkit para el cliente, con contexto para tema y avisos y la URL para el filtro; CSS Modules; el cuarteto Vitest, Testing Library, MSW y Cypress; y JavaScript ahora con la puerta abierta a TypeScript. Junto al acta, la tabla de asignación de estado que responde de antemano a la pregunta que más veces se repite en un proyecto de React: ¿dónde vive este dato?

Y del andamiaje queda un repositorio funcionando: Vite con React 19, dependencias elegidas una a una y bien separadas entre producción y desarrollo, un package.json con catorce scripts que son la interfaz del proyecto, ESLint con jsx-a11y y exhaustive-deps elevado a error, Prettier el último de la cadena, .editorconfig, .gitignore, variables de entorno centralizadas en configuracion.js con .env.example versionado y ningún secreto, una estructura de carpetas híbrida —por tipo lo compartido, por funcionalidad el estado de dominio—, json-server sembrado y verificado con curl, las convenciones del equipo escritas en el README.md, y un plan de trabajo por incrementos verticales que ataca primero lo que más riesgo tiene.

Ahora hay un esqueleto que arranca y no hay nada que mirar. La siguiente lección lo llena: Construyendo la Interfaz de Usuario levanta CicloUrbano entero con datos todavía estáticos —el sistema de diseño con sus componentes base, el marco de la aplicación con Diseno y la navegación, las ocho pantallas con sus estados vacío, de carga y de error previstos desde el primer momento, la accesibilidad aplicada pantalla a pantalla y el diseño adaptable con CSS Modules—, para poder verla, recorrerla y validarla antes de conectar una sola petición.