Referencia Paper — COMAL

Mapa del canvas (bandas verticales, CRON §5.2)

Lectura arriba → abajo. Etiquetas §N encima de cada banda.

Inventario completo de artboards — UI producto

Inventario proceso UX (11) — alineado a markdown del case

Total: 46 artboards hi-fi en Paper (35 UI + 11 proceso UX).

Media real (2026-08-01)

Fotos fotorrealistas generadas en las cards/heroes de cocinas (no placeholders de color):

Insertadas con paper-asset:// (regla permanente del cron: ver CRON.md §5.1).

Design tokens

Definidos en el archivo Paper (CSS variables). Duplicados en 08-design-system.md.

Prototipo y navegación

Ver 17-prototype-map.md.

Auditoría de completitud

Ver 18-completeness-audit.md.

01 — Definición del proyecto · COMAL

5.1 Identidad

5.2 Problema

Problema principal

Los emprendedores gastronómicos sin cocina propia certificada no pueden producir de forma legal, predecible y escalable. Coordinan espacios por WhatsApp, Excel o boca a boca, con conflictos de horarios, falta de trazabilidad sanitaria y pagos informales.

Problemas secundarios

• Dificultad para demostrar cumplimiento (HACCP, registros de uso) ante inspecciones.
• Operadores de cocinas con ocupación irregular y cobro manual.
• Falta de transparencia en equipamiento real disponible por franja.
• Cancelaciones de última hora sin política clara.
• Desconfianza en la limpieza y el solapamiento entre usuarios.

Quién lo experimenta

1. Cocinero emprendedor — produce para venta online, delivery o eventos.
2. Operador de cocina compartida — dueño o gestor del local.
3. Indirectamente: clientes finales del emprendedor (calidad/seguridad alimentaria).

Cómo se resuelve hoy (supuesto de mercado)

• Grupos de WhatsApp y Telegram.
• Alquiler de cocinas de restaurantes en horario muerto (acuerdos informales).
• Coworkings gastronómicos con reserva por email/teléfono.
• Ghost kitchens B2B con contratos largos y precios altos.

Deficiencias de las soluciones actuales (hipótesis)

• No hay inventario en tiempo real de franjas y equipos.
• Sin flujo de pago unificado ni facturación automática.
• Sin evidencia digital de quién usó qué y cuándo.
• Onboarding del operador lento; del cocinero, opaco.

Coste del problema (supuestos, no medidos)

Oportunidad de producto

Digitalizar el marketplace de capacidad de cocina certificada con confianza (certificados, reseñas, reglas) y operaciones (calendario, pago, check-in).

Clasificación de evidencias

5.3 Objetivos

Negocio

• Alcanzar product-market fit en 1 ciudad piloto en 6 meses.
• GMV de reservas y tasa de ocupación media de cocinas listadas.
• Retención de operadores (oferta) y cocineros activos mensuales (demanda).

Usuario (cocinero)

• Reservar una franja adecuada en < 5 minutos en el primer uso.
• Confiar en que el espacio está limpio, equipado y certificado.
• Recibir comprobante y acceso sin fricción el día de la reserva.

Usuario (operador)

• Ver ocupación del día y huecos en un vistazo.
• Reducir no-shows y cobros pendientes.
• Publicar reglas y precios sin intermediación manual constante.

Producto

• Flujo completo: descubrir → reservar → pagar → check-in → valorar.
• Panel operador MVP: calendario, precios base, bloqueos, check-in.

Experiencia

• Claridad industrial: horarios y precios siempre visibles.
• Reducir ansiedad pre-reserva (qué incluye, qué no, política de cancelación).

Técnicos

• Disponibilidad 99,5 % en horario comercial.
• Confirmación de pago < 3 s percibidos tras autorización.
• WCAG 2.2 AA en flujos críticos.
• PWA instalable; offline limitado (ver mis reservas cacheadas).

No objetivos (Won’t have por ahora)

• Marketplace de ingredientes o personal de cocina.
• IA de planificación de menús.
• App nativa en v1.
• Multi-país con compliance fiscal local completo.
• Reservas de comensales (no es OpenTable).

Restricciones

• Cumplimiento RGPD; pagos PCI vía PSP (Stripe).
• No almacenar datos de tarjetas en claro.
• Contenido legal/sanitario: el operador es responsable de la veracidad de certificados subidos (COMAL verifica de forma ligera en onboarding).

Dependencias

• Stripe (pagos y suscripciones).
• Proveedor SMS/email.
• Mapas (Mapbox o Google) para geolocalización.
• Identidad (Auth.js / OAuth email + Google).

Riesgos iniciales

5.4 Métricas

Roles del producto

02 — Investigación UX y estrategia · COMAL

Nota metodológica: No se realizó investigación primaria en esta ejecución. Los perfiles, JTBD y journeys son constructos de diseño basados en supuestos documentados. Antes de implementar, validar con entrevistas y observación en cocinas compartidas reales.

6.1 Stakeholders

6.2 Perfiles de usuario

Perfil 1 — Lucía “Food truck” (Cocinera)

Perfil 2 — Marcos “Pastelería B2B” (Cocinero)

Perfil 3 — Elena “Kitchen Hub” (Operadora)

Perfil 4 — Andrés “Soporte COMAL” (secundario)

6.3 Jobs To Be Done

JTBD 1 — Cocinero, reserva puntual

Cuando me sale un pedido grande o un evento, quiero asegurar una cocina certificada con el equipo que necesito en una franja concreta, para poder producir sin incumplir la normativa ni improvisar a última hora.

JTBD 2 — Cocinero, hábito recurrente

Cuando ya sé mis días de producción, quiero fijar turnos recurrentes con descuento de membresía, para planificar stock y personal sin renegociar cada semana.

JTBD 3 — Operador, ocupación

Cuando abro la semana, quiero ver huecos y cobros pendientes de un vistazo, para llenar franjas y cobrar sin perseguir a nadie.

6.4 Historias de usuario (por épicas)

Épica A — Descubrimiento y ficha

A1 — Criterios de aceptación

• Filtros: ciudad/barrio, rango €/h, equipos (multi-select), franja horaria, valoración mínima.
• Resultados actualizan en < 1 s percibido o muestran skeleton.
• Contador de resultados visible.
• Sin resultados → empty state con sugerencia de ampliar filtros.

Dependencias: catálogo de equipos normalizado.
Errores: fallo de red → reintentar.
Métrica: CTR ficha desde listado.

Épica B — Reserva y pago

B1 — Criterios de aceptación

• Slots de 1 h; selección continua (no huecos en medio en la misma reserva).
• Slots ocupados deshabilitados con razón tooltip (“Reservado” / “Bloqueado”).
• Mínimo 2 h por reserva (configurable por cocina) — decisión de diseño.
• Zona horaria Europe/Madrid explícita.

Épica C — Check-in y sesión

Épica D — Operador

Épica E — Cuenta y membresía

Won’t have por ahora

• Reservas de personal de cocina.
• Chat in-app entre cocinero y operador (usar email/teléfono del listado).
• IA de sugerencia de horarios.

6.5 Journey map — Lucía: primera reserva de emergencia

6.6 Service blueprint (reserva completada)

Decisiones de investigación pendientes (reales)

1. Entrevistas con 8–12 cocineros y 5 operadores en ciudad piloto.
2. Shadowing de un día de cocina compartida.
3. Benchmark de comisiones y precios/h de mercado local.
4. Prueba de usabilidad del flujo de reserva (5 usuarios).

03 — Arquitectura de información · COMAL

Mapa del sitio

PÚBLICO
├── /                     Landing marketing
├── /como-funciona
├── /precios
├── /para-operadores
├── /cocinas              Explorar (listado)
│   └── /cocinas/:slug    Ficha cocina
├── /entrar
├── /registro
└── /legal
    ├── privacidad
    ├── terminos
    └── cookies

APP COCINERO (auth)
├── /app                  Redirect → explorar o home
├── /app/explorar
├── /app/cocinas/:id
├── /app/reservar/:id     Flujo reserva
├── /app/reservas         Mis reservas
│   └── /app/reservas/:id Detalle + check-in
├── /app/membresia
├── /app/perfil
│   ├── datos
│   ├── pagos
│   ├── notificaciones
│   └── privacidad
└── /app/soporte

APP OPERADOR (auth + rol)
├── /ops                  Dashboard día
├── /ops/calendario
├── /ops/estaciones
├── /ops/precios
├── /ops/bloqueos
├── /ops/reservas
├── /ops/checkin
├── /ops/ingresos
└── /ops/configuracion

Navegación

Principal (cocinero, bottom nav móvil)

Principal (operador, sidebar desktop)

Dashboard · Calendario · Reservas · Estaciones · Ingresos · Configuración

Secundaria

• Filtros en explorar (sheet / sidebar)
• Breadcrumbs en desktop: Explorar / Cocina X / Reservar

Contextual

• CTA “Reservar” sticky en ficha
• Acciones en reserva: cancelar, añadir al calendario, contactar operador

Búsqueda

• Texto libre: nombre de cocina, barrio
• Filtros facetados: equipo, €/h, horario, valoración, certificados

Taxonomías

Equipos (catálogo cerrado)

Horno convección · Freidora · Plancha · Fogones · Abatidor · Cámara frigorífica · Obrador pastelería · Empaquetado · Lavavajillas industrial · Campana extractora

Certificaciones (etiquetas)

Registro sanitario · Formación manipuladores · Seguro RC · Acceso 24h · Parking · Zona carga

Tipos de espacio

Estación individual · Cocina completa · Obrador · Solo packaging

Inventario de contenido

Matriz de permisos

Leyenda: V=Ver C=Crear E=Editar D=Eliminar

04 — Flujos de usuario · COMAL

Convenciones

• TZ: Europe/Madrid
• Slot: 1 hora; reserva mínima configurable (default 2 h)
• Idempotencia: Idempotency-Key en pago y creación de reserva

F1 — Descubrimiento → Landing → Explorar

F2 — Registro / Login

Registro

1. Email + contraseña (min 10 chars) o Google OAuth
2. Nombre y teléfono
3. Rol inicial: Cocinero (default) u Operador (ruta separada)
4. Aceptación términos + privacidad
5. Verificación email (magic link)
6. Onboarding: ciudad, equipos frecuentes, aviso legal producción

Errores: email en uso, contraseña débil, OAuth cancelado
Recuperación: mensaje + link a login

Login

Email/password o Google · “Recordarme” · link olvidé contraseña

Recuperación contraseña

Email → link 30 min → nueva contraseña → sesión invalidada en otros dispositivos

Analytics: sign_up, login, password_reset_request

F3 — Explorar y filtrar

1. Listado ordenado por distancia o relevancia
2. Abrir filtros → aplicar chips equipo / precio / horario
3. Vacío → empty state
4. Tap en card → ficha

Estados: loading skeleton, error red, empty, resultados

Analytics: search_filter_apply, listing_impression, listing_click

F4 — Reserva end-to-end (crítico)

Ficha → Reservar → Fecha → Slots → Resumen → Pago → Confirmación

Decisiones en branch:

• Slot se ocupa entre resumen y pago → error “ya no disponible” + reembolso si cargo
• Pago falla → reintentar; no crear reserva
• Usuario cierra → carrito no persistente (slots no hold largos); hold 10 min opcional v1.1

Analytics: booking_start, slot_select, checkout_start, payment_success|fail, booking_confirmed

F5 — Check-in

1. Desde Mis reservas o tab Acceso
2. Ventana: desde 15 min antes hasta fin de franja
3. Muestra QR + PIN de 6 dígitos
4. Operador escanea o introduce PIN en /ops/checkin
5. Estado → “En curso”

Offline: PIN visible si reserva cacheada; validación operador puede ser manual
Error: fuera de ventana; reserva cancelada; PIN revocado

F6 — Cancelación

1. Detalle reserva → Cancelar
2. Mostrar política y importe reembolsable
3. Confirmar
4. Reembolso Stripe (parcial/total) async
5. Slot liberado

Analytics: booking_cancel, refund_initiated

F7 — Membresía

Planes:

• Sin plan: pay-as-you-go
• Base (29€/mes): 10 % dto, soporte prioritario
• Pro (59€/mes): 15 % dto, hold prioritario, 1 cancelación flexible/mes

Flujo: ver planes → Stripe Subscription → badge en UI

F8 — Operador: bloqueo y dashboard

1. Login rol operador
2. Dashboard: estaciones del día, llegadas, ocupación %
3. Bloquear franja: motivo + rango
4. Slots dejan de venderse

Estados de UI transversales

Eventos analíticos (lista maestra)

Ver 12-analytics.md.

05 — Modelo de datos · COMAL

Diagrama ER simplificado

User 1──* Membership
User 1──* Booking
User *──* Kitchen (via KitchenStaff for operators)
Kitchen 1──* Station
Kitchen 1──* KitchenEquipment
Kitchen 1──* KitchenCertification
Station 1──* SlotLock / AvailabilityRule
Booking *──1 Station
Booking 1──1 Payment
Booking 1──0..1 CheckIn
Booking 1──0..1 Review
Booking 1──0..* BookingEvent (audit)

Entidades principales

User

Kitchen

Station

Equipment (catálogo) + KitchenEquipment (M2M)

code, label_es, icon_key

Certification

type, issuer, valid_until, document_url, verification_status

Booking

Constraint: EXCLUDE USING gist (station_id WITH =, tstzrange(starts_at, ends_at) WITH &&) WHERE (status IN ('confirmed','checked_in','completed','pending_payment'))

Payment

provider, provider_ref, amount_cents, status, raw_events jsonb

CheckIn

booking_id, method (qr|pin|manual), pin_hash, checked_in_at, checked_in_by

Membership

user_id, plan (base|pro), stripe_subscription_id, status, current_period_end

Review

booking_id unique, rating 1–5, body, published

Audit / BookingEvent

booking_id, actor_id, type, payload, created_at

Índices recomendados

• bookings (cook_user_id, starts_at desc)
• bookings gist exclusion (arriba)
• kitchens (city), kitchens gist geo
• kitchens (status) where published

Privacidad y retención

Cifrado: TLS en tránsito; campo phone opcional encrypted at rest; documentos en bucket privado firmado.

Multitenancy

• Lógico por kitchen_id para operadores
• Admin COMAL cross-tenant
• No shared DB por tenant en v1 (single DB, RLS por rol)

Eventos de dominio

UserRegistered KitchenPublished BookingHoldCreated BookingConfirmed PaymentCaptured BookingCancelled CheckInCompleted ReviewSubmitted MembershipStarted

06 — Stack tecnológico · COMAL

Decisión de arquitectura

PWA monorepo full-stack orientada a velocidad de MVP y operaciones de reserva con integridad temporal.

Por qué no X

Integridad de reservas

1. Hold en Redis 10 min (v1.1) o pending_payment con TTL
2. EXCLUDE gist en Postgres al confirmar
3. Webhook Stripe idempotente → confirmed
4. Job de limpieza de pending expirados

Entornos

• local · preview (Neon branch) · staging · production

Estimación de equipo mínimo implementación

2 fullstack, 1 designer part-time, 1 ops/product part-time — 10–14 semanas MVP ciudad piloto.

07 — Dirección creativa · COMAL

Brief de diseño (Paper)

Paleta

Tipografía

Escala

12 / 14 / 16 / 18 / 22 / 28 / 36 / 48 px
Line-height display ~1.15; body 1.5.

Principios visuales

1. Un acento intenso (naranja) para CTAs y estados activos; el resto es neutro industrial.
2. Asimetría controlada en marketing; alineación estricta en app y ops.
3. Sin emojis; iconos SVG de trazo 2px.
4. Precios y horas siempre legibles — nunca decoración sobre dato crítico.
5. Fotos de cocina reales (placeholder oscuro en mockups) con badge VERIFICADA.

Logo wordmark

COMAL en Fraunces Bold + cuadrado naranja 1:1 a la izquierda (marca de “estación”).

Voz de marca (enlace a content guide)

Directa, profesional, sin jerga startup. Español de España claro.

08 — Design system · COMAL

Tokens definidos en Paper como CSS variables. Fuente de verdad: archivo Paper + este documento.

Tokens de color

--color-background: #F4F2EF;
--color-surface: #FFFFFF;
--color-ink: #1A1A1A;
--color-ink-muted: #5C5955;
--color-ink-subtle: #8A8680;
--color-border: #E0DCD6;
--color-primary: #E85D04;
--color-primary-strong: #C44D03;
--color-primary-soft: #FFF0E6;
--color-secondary: #5C6B5A;
--color-secondary-soft: #E8EDE7;
--color-danger: #B42318;
--color-danger-soft: #FEE4E2;
--color-warning: #B54708;
--color-info: #175CD3;

Espaciado

4 · 8 · 12 · 16 · 20 · 24 · 32 · 40 · 48 · 64 px

Radios

4 (sm) · 8 (md) · 12 (lg) · 16 (xl) · 9999 (full)

Componentes

Button

Altura táctil mínima: 44px. Padding horizontal 18–28px.

Input

• Label 12–14px medium sobre campo
• Campo: border border, radius md, padding 12–14
• Focus: border primary 1.5–2px
• Error: border danger + texto danger

Chip / Filter

• Default: surface + border
• Selected: ink bg + white text (listado) o primary-soft + primary border (estaciones)

Card cocina

• Imagen 16:9 o altura fija ~120–140
• Badge VERIFICADA / 24H
• Título Fraunces 18
• Meta 13 muted
• Precio display alineado a la derecha

Slot hour

• Disponible: surface + border
• Selected: primary + white mono
• Occupied: border fill + subtle text, no interactive

Bottom nav (móvil)

4 tabs: Explorar · Reservas · Acceso · Perfil
Active: primary stroke + label primary

Sidebar ops

Fondo ink; item activo #2A2A2A

Status badges

Empty / Error

Icono en frame 64–72, título Fraunces, body muted, CTA primary + secondary link

Breakpoints

640 · 768 · 1024 · 1280

Responsive rules

Librería en Paper

Implementada en artboards: botones, chips, cards, slots, badges, nav, sidebar, empty, error, check-in dark.

09 — Guía de contenido · COMAL

Voz y tono

Principios UX writing

1. Acción primero en botones: “Reservar franja”, no “Continuar”.
2. Consecuencia visible en destructivos: “Cancelar reserva (reembolso 50%)”.
3. Errores con salida: qué pasó + qué hacer + contacto.
4. Números y horas en formato ES: 31 jul 2026 · 05:00–08:00 · 54,00 €.
5. Zona horaria explícita en selección de franjas (Europe/Madrid).

Microcopy clave

Terminología

Legal en UI (no es asesoramiento legal)

• Disclaimer en ficha: el operador declara la veracidad de certificados.
• COMAL no otorga licencia sanitaria al cocinero.
• Enlace a términos y privacidad en registro y pie.

10 — Accesibilidad · COMAL

Objetivo: WCAG 2.2 nivel AA en flujos críticos (explorar, reservar, pagar, check-in, ops dashboard).

Auditoría de diseño (checklist)

Hallazgos y correcciones en esta entrega

1. Primary sobre soft backgrounds — chips de equipo usan secondary-soft + secondary para no depender solo de naranja.
2. Check-in dark mode — PIN en mono grande 36px; contraste white/ink OK.
3. Estados ocupados — no solo gris: deshabilitados + leyenda.
4. Pendiente QA real — axe-core + prueba teclado + VoiceOver en iOS Safari PWA.

Riesgos

• Mapas: proporcionar lista equivalente.
• QR: siempre PIN alternativo (cumplido en diseño).
• PDF facturas: generar etiquetados en implementación.

No se declara cumplimiento legal definitivo — solo intención de diseño AA.

11 — Privacidad y seguridad · COMAL

No constituye asesoramiento legal. Revisar con counsel antes de lanzamiento.

Datos personales tratados

Principios

• Minimización: no pedir NIF en v1 salvo facturación empresa.
• PSP: Stripe — no almacenar PAN.
• Cifrado en tránsito TLS 1.2+.
• Secretos en vault / env, no en repo.
• RLS o checks de autorización por kitchen_id y user_id.
• Soft delete + derecho de supresión (export + delete account).
• Retención de facturas según obligación fiscal.

Amenazas y controles

Roles y acceso físico

COMAL no garantiza cerraduras smart en v1; el check-in puede ser validación humana. Documentar responsabilidad del operador.

Cookies

• Esenciales sesión
• Analytics (PostHog) con consentimiento si no estrictamente necesarias
• Banner ES conforme ePrivacy (implementación)

Incidentes

Runbook: detectar → contener → notificar DPO/usuarios si alto riesgo (72h AEPD si aplica).

12 — Plan analítico · COMAL

Herramienta recomendada: PostHog (product) + Stripe (revenue) + Sentry (errors).

North Star

Horas de cocina confirmadas y completadas / semana

Funnel principal

landing_view → cta_explore_click → listing_view → listing_click
→ kitchen_view → booking_start → slot_select → checkout_start
→ payment_success → booking_confirmed → checkin_complete → review_submit

Eventos

KPIs semanales

• Activation rate (1ª reserva ≤7d)
• Checkout conversion
• Completed kitchen-hours
• No-show rate
• Operator occupancy %
• CSAT post-sesión

Privacidad analytics

IP truncada; no PII en props; opt-out en ajustes.

13 — Plan y casos de prueba · COMAL

Alcance MVP

Flujos: registro, explorar, reserva+pago, cancelación, check-in, ops bloqueo, membresía básica.

Tipos

Casos prioritarios

Criterios de salida a staging

• 0 P0 abiertos
• Pago y booking race cubiertos
• Lighthouse a11y ≥ 90 en ficha y checkout

14 — Handoff de diseño (UX/UI) · COMAL

Alcance actual: entrega de producto, UX y UI de alta fidelidad.
Fuera de alcance ahora: implementación de código, repos de app o pipelines.

Referencias

Artboards entregados (35 — completos en Paper)

Marketing: Landing cocineros · Landing operadores

Auth: Login · Registro · Recuperar contraseña · Email enviado · Validación error · Sesión expirada

Cocinero: Onboarding · Explorar m/d · Ficha · Reserva · Sin huecos · Checkout · Confirmación · Mis reservas · Empty reservas · Detalle · Cancelar · Check-in · Perfil · Planes · Notificaciones · Facturas

Estados: Empty filtros · Loading · Error pago · Error red

Operador: Dashboard · Calendario · Bloquear franja · Precios/estaciones · Check-in recepción (tablet)

Sistema: Design System

Especificaciones de interacción (resumen)

Detalle completo: 16-interaction-specs.md.

Cuando se implemente (futuro)

1. Exportar desde Paper (get_jsx / computed styles), no desde capturas.
2. Orden sugerido: Auth → Catálogo → Booking → Check-in → Ops → Membresía.
3. DoD por pantalla: tokens, empty/loading/error, a11y, analytics, e2e.

Definition of Done — entrega UX/UI (esta fase)

• Flujo cocinero end-to-end en hi-fi
• Flujo operador principal en hi-fi
• Auth + recuperación + onboarding
• Cancelación, membresía, facturas, notificaciones
• Estados empty, loading, error, red, sesión, sin huecos
• Responsive mobile + desktop + tablet ops
• Design system en Paper
• 35 artboards con contenido en Paper
• Documentación de producto y UX
• Spec de interacciones + mapa de prototipo
• Auditoría de completitud

15 — Roadmap · COMAL

Fase 0 — Foundation (2–3 sem)

• Design system en código
• Auth, layout PWA shell
• CI, entornos Neon

Fase 1 — MVP ciudad piloto (8–10 sem)

• Listado + ficha + reserva + pago
• Check-in PIN
• Ops: calendario día, bloqueos, listado reservas
• Emails transaccionales
• 10–20 cocinas onboarded concierge

Fase 2 — Retención (4–6 sem)

• Membresías Stripe Billing
• Reseñas
• Reservas recurrentes
• Hold de slots + mejor race handling
• CSAT in-app

Fase 3 — Escala (6–8 sem)

• Multi-ciudad
• Cerraduras smart (partner)
• App nativa si métricas PWA lo justifican
• Facturación avanzada operadores
• Programa referidos

Métricas de go/no-go entre fases

16 — Especificación de interacciones · COMAL

Documento de prototipo / comportamiento UI. Sin implementación de código en esta entrega: sirve como especificación para diseño y futuro desarrollo.

Mapa de pantallas y navegación

Landing ──► Explorar ──► Ficha ──► Reserva (slots) ──► Checkout ──► Confirmación ──► Check-in
   │            │          │
   │            │          └── (auth gate si no sesión) → Login / Registro → Onboarding → vuelve
   │            └── Empty | Loading
   └── Login / Registro

Bottom nav (auth): Explorar | Reservas | Acceso | Perfil
Ops sidebar: Dashboard | Calendario | Reservas | Estaciones | Ingresos | Config

Transiciones y microinteracciones

Gestos móviles

• Pull-to-refresh en Explorar y Mis reservas
• Swipe back en iOS/Android nativo web (browser)
• No swipe-to-delete en reservas (evitar accidente); cancelar solo en detalle

Validaciones en UI

Estados por pantalla (matriz)

Flujo de prototipo recomendado (demo stakeholder)

1. Landing → Explorar
2. Abrir Kitchen Hub Vallecas
3. Reservar 05–08
4. Checkout → (simular éxito) Confirmación
5. Mis reservas → Check-in
6. Ops Dashboard + Calendario

En Paper: artboards enlazables manualmente o presentación en orden de capa.

Criterios de aceptación UX (no código)

• Usuario entiende precio total antes de pagar
• Política de cancelación legible en ficha y checkout
• Check-in usable con una mano en exterior
• Operador ve ocupación del día en < 5 s de mirada
• Empty y error tienen siguiente acción clara

17 — Mapa de prototipo y navegación · COMAL

Especificación de prototipo clicable de extremo a extremo.
En Paper: artboards hi-fi. Donde el MCP de Paper esté limitado, los mockups complementarios están en ui-mockups/.

Flujo maestro (cocinero)

[01 Landing]
    ├─ CTA Explorar ──────────────────────────────► [05 Explorar]
    ├─ CTA Soy operador ──────────────────────────► [01b Landing operadores]
    ├─ Entrar ────────────────────────────────────► [02 Login]
    └─ Crear cuenta ──────────────────────────────► [03 Registro]

[02 Login]
    ├─ Entrar OK ─────────────────────────────────► [05 Explorar] | deep link
    ├─ ¿Olvidaste? ───────────────────────────────► [02b Recuperar]
    ├─ Google OK ─────────────────────────────────► [05] o [04 Onboarding] si nuevo
    ├─ Crear cuenta ──────────────────────────────► [03 Registro]
    └─ Error validación ──────────────────────────► [18 Error validación]

[02b Recuperar] ── Enviar ──► [02c Email enviado] ── Volver ──► [02 Login]

[03 Registro]
    ├─ Cocinero + OK ─────────────────────────────► [04 Onboarding]
    └─ Operador ──────────────────────────────────► onboarding ops (concierge / 01b)

[04 Onboarding] ── Continuar / Saltar ────────────► [05 Explorar]

[05 Explorar]
    ├─ Card cocina ───────────────────────────────► [06 Detalle]
    ├─ Filtros sin resultados ────────────────────► [13 Empty]
    ├─ Carga ─────────────────────────────────────► [15 Loading]
    ├─ Error red ─────────────────────────────────► [20 Error red]
    └─ Bottom: Reservas|Acceso|Perfil ────────────► [09]|[10]|[11]

[06 Detalle] ── Reservar ──► [07 Reserva] (auth gate → 02 si hace falta)

[07 Reserva]
    ├─ Continuar al pago ─────────────────────────► [08b Checkout]
    └─ Sin huecos día ────────────────────────────► [19 Sin huecos]

[08b Checkout]
    ├─ Pagar OK ──────────────────────────────────► [08 Confirmación]
    └─ Pago fail ─────────────────────────────────► [14 Error pago] ⇄ reintentar

[08 Confirmación]
    ├─ Ver acceso ────────────────────────────────► [10 Check-in]
    └─ Mis reservas (implícito) ──────────────────► [09]

[09 Mis reservas]
    ├─ Empty ─────────────────────────────────────► [16 Empty reservas]
    ├─ Detalle ───────────────────────────────────► [09b Detalle reserva]
    └─ Check-in ──────────────────────────────────► [10]

[09b Detalle]
    ├─ Check-in ──────────────────────────────────► [10]
    └─ Cancelar ──────────────────────────────────► [09c Cancelar] ── confirmar ──► [09]

[10 Check-in] ── Reportar problema ───────────────► soporte (mailto / form futuro)

[11 Perfil]
    ├─ Ver planes ────────────────────────────────► [11b Planes]
    ├─ Notificaciones ────────────────────────────► [11c]
    ├─ Facturas / pagos ──────────────────────────► [11d]
    ├─ Privacidad ────────────────────────────────► copy + export/delete (doc)
    └─ Cerrar sesión ─────────────────────────────► [02]

[17 Sesión expirada] ── Entrar ───────────────────► [02] + restore deep link

Flujo operador

[01b Landing operadores]
    ├─ Publicar / Solicitar ──────────────────────► lead form (copy en landing)
    └─ Entrar ────────────────────────────────────► [02] rol operador

[Op-01 Dashboard]
    ├─ Bloquear ──────────────────────────────────► [Op-03 Bloquear]
    └─ Nav ───────────────────────────────────────► Op-02 | Op-04 | Op-05

[Op-02 Calendario] ── + Bloquear ─────────────────► [Op-03]
[Op-04 Precios y estaciones]
[Op-05 Check-in recepción] (tablet)

Orden de demo stakeholder (15 min)

1. 01 Landing → 05 Explorar → 06 Ficha → 07 Reserva → 08b Checkout → 08 Confirmación → 10 Check-in
2. 09 Mis reservas → 09b → 09c (cancelación)
3. 11 → 11b Planes
4. 01b Operadores → Op-01 → Op-02 → Op-03 → Op-04 → Op-05
5. Estados: 13, 14, 15, 16, 17, 18, 19, 20

Hotspots mínimos por artboard

Criterio de “prototipo completo”

• Camino feliz cocinero documentado y diseñado
• Auth + recuperación
• Cancelación con confirmación
• Membresía
• Estados empty / loading / error / sesión / validación / red / sin huecos
• Ops: dash, calendario, bloqueo, precios, check-in recepción
• Landing operadores
• Enlaces hotspots nativos en Paper (cuando la herramienta lo permita; mapa aquí es fuente de verdad)

18 — Auditoría de completitud UX/UI · COMAL

Cierre: 2026-08-01
Alcance: producto + UX + UI hi-fi. Excluido: implementación de código de producto.

Matriz de entregables del brief diario

Inventario Paper (35/35 con contenido)

Todos los artboards listados en 00-paper-reference.md tienen contenido hi-fi en el archivo Paper (incluyendo los rellenados tras Paper Pro: landing operadores, bloqueo, precios, estados 16–20, facturas, check-in recepción).

Autoverificación §29

Deuda residual (no bloqueante)

1. Hotspots nativos clicables en Paper (mapa en 17 es la fuente de verdad).
2. Investigación de campo real.
3. Fotografía real de cocinas (placeholders controlados).
4. Certificación legal WCAG / RGPD (orientación de diseño solo).

Declaración de cierre

COMAL se declara completo en alcance UX/UI de principio a fin para el cron diario, sin implementación de código.

19 — Backlog completo (historias + AC) · COMAL

Todas las historias con MoSCoW. Las Must tienen criterios de aceptación.

Épica A — Descubrimiento

Épica B — Reserva y pago

Épica C — Check-in

Épica D — Operador

Épica E — Cuenta

Épica F — Confianza y soporte

No objetivos (Won’t)

IA menús · chat in-app · app nativa v1 · marketplace de personal · reservas de comensales.

20 — Implementación · COMAL

Repositorio

Neon

Connection string en apps/api/.env (local, no commiteado). Plantilla: .env.example.

Arranque

cd /Users/cristian/orca/comal-app

# API (puerto 3000)
cd apps/api && npm install && npx prisma generate && npm run start:dev

# Web (puerto 4200)
cd apps/web && npm install && npm start

Cuentas seed

API (prefijo /api)

UI Angular (rutas)

Alcance implementado vs Paper

Must del vertical slice: explorar, ficha, reserva, auth, listado/detalle reserva, cancelar, check-in, ops dashboard + validar PIN.

No en v1 de código (sí en diseño Paper): Stripe real, membresía de pago, PWA offline, multi-ciudad, tablets dedicadas, OAuth Google.

Verificación

• Neon proyecto + migrate + seed
• API Nest arranca y responde
• Angular build OK
• Repo GitHub pusheado