00-day-brief.md

00 — Day brief · 2026-08-15 · RONDA

Decisiones ALS-2 BRIEF

Terna unicidad

R-HY · S-DOCK · H-FEED · F-BOOK

Cumple memory §6.5: 0 códigos iguales a N−1 (DERIVA) y ≥2 distintos vs N−2 (PIZARRA). Ventana de 4 días ya tenía R-IN y R-CL; hoy R-HY. Experimento §8: feed, no mapa ni search.

Directivas aplicadas

• D-P0-01…09, D-P1-01 (≥12 UX), D-P0-08 (≥10 UI), D-P1-05 JWT HOST
• Tipografía Zilla Slab + Mulish (evitar Lora, Karla, Newsreader, Atkinson, Outfit, Archivo, Fraunces)
• Paleta signage — blanco / tinta / amarillo cromo / felt / liner. No dusk, no chalky, no slate/teal, no limestone, no wine
• Home no es hero 2-col ni mapa (AP-12). Superficie = feed + dock

Alcance L2 must

1. Home feed cronológico de 5 mesas (foto, juego, hora, local, asientos)
2. Ficha de mesa (reglas cortas, anfitrión, aforo, punto de encuentro)
3. Formulario público RSVP (solicitud ≠ plaza confirmada)
4. Success con código RD-MMDD-NNN
5. Login + inbox HOST JWT (NEW → CONTACTED → SEATED / WAITLIST / CANCELLED)
6. Publicar mesa (HOST)
7. Empty / loading / error / mobile feed + dock
8. ≥12 UX + ≥10 UI Paper

Mood visual (Paper)

• Candidatos: taberna candlelit (primer instinto), felt casino, phosphor arcade, signage, alpine
• Elegido: signage — no el primer instinto taberna (cerca de DERIVA dusk / PLIEGO wine)
• Paleta: #FFFFFF suelo · #111111 tinta · #F5C400 cromo · #1F4D3A felt · #FFF6C2 liner · #E24B2A ficha
• Tipo: Zilla Slab 56/36/24 display · Mulish 16/14 UI

Supuestos

• S1: Un barrio tipo Malasaña–Lavapiés sostiene 5–12 mesas públicas por semana (rango operativo).
• S2: El jugador llega con “qué se juega esta noche”, no a comprar un juego.
• S3: El anfitrión necesita cola con estado, no un Discord ni un marketplace.
• S4: La plaza se confirma en el local; RONDA no cobra.

Hipótesis

00-paper-reference.md

Paper reference · RONDA

UX-count: 12 UI-count: 11

UX-00 Cover · UX-01 Stakeholders · UX-02 Personas · UX-03 JTBD · UX-04 Stories · UX-05 Journey · UX-06 Blueprint · UX-07 Site map · UX-08 Flujos · UX-09 Datos+permisos · UX-10 Métricas · UX-11 Research UI-00 Tokens · UI-01 Feed Hoy · UI-02 Ficha mesa · UI-03 RSVP · UI-04 Success · UI-05 Login · UI-06 Inbox HOST · UI-07 Empty · UI-08 Error · UI-09 Loading · UI-10 Mobile feed

UX process (prefijo UX- · mínimo 12)

UI producto (prefijo UI- · mínimo 10)

Regla: wizard de N pasos → N boards UI solo para esos pasos, además de success/empty/error/loading/staff. RONDA no es wizard: el núcleo es feed → ficha → form de 1 pantalla.

1. Mapa de canvas (bandas)

Layout canvas (referencia de diseño): origen (0,0) · gaps ~100–120px · UX en 3×4 · UI pública en fila feed → ficha → RSVP → success · mobile debajo del feed. [DECISIÓN] Bandas jerárquicas D-P0-04 / D-P1-04.

2. Mapeo Paper → Angular

Rutas HOST adicionales (no artboard UI dedicado v1, sí en IA): /inbox/:id detalle solicitud · /publicar crear mesa · /yo sesión.

3. Tokens de diseño en Paper

4. Checklist de densidad (anti thin-frames)

5. Media

• assets/hero.jpg — atmósfera de mesa / signage de local
• assets/tables/azulejos.jpg — Azulejos de Lavapiés
• assets/tables/cartas.jpg — Cubilete y cartas
• assets/tables/minis.jpg — Mazmorra de Chamberí
• assets/tables/cooperativo.jpg — Farol cooperativo
• assets/tables/coleccion.jpg — Colección de patio

[COMPROBADO] Los seis archivos existen en el case 2026-08-15-ronda/assets/.

6. Enlaces

• Paper: https://app.paper.design/file/01M023RM2TZ49CYM2FN1FRRGNY
• Case: /Users/cristian/orca/ux-projects/2026-08-15-ronda/
• App: /Users/cristian/orca/ronda-app/
• GitHub: https://github.com/Criscode2022/ronda-app (se creará)
• Neon project: curly-lab-77015594
• API: http://localhost:3015
• Web: http://localhost:4200

01-project-definition.md

01 — Definición de proyecto — RONDA

1. Identidad

[COMPROBADO] Nombre, eslogan, terna, nivel y sector salen de docs/00-day-brief.md.

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] Quien quiere jugar esta noche no abre un marketplace ni un Discord: pregunta “qué hay” en un grupo de WhatsApp, un cartel del bar o un hilo que se pierde. [SUPUESTO] El anfitrión confirma sillas por mensaje suelto, sin cola, sin código y sin tope de aforo visible.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Un barrio tipo Malasaña–Lavapiés sostiene 5–12 mesas públicas por semana (rango operativo). [SUPUESTO]
• S2: El jugador llega con “qué se juega esta noche”, no a comprar un juego. [SUPUESTO]
• S3: El anfitrión necesita cola con estado, no un Discord ni un marketplace. [SUPUESTO]
• S4: La plaza se confirma en el local; RONDA no cobra. [SUPUESTO]

Hipótesis de producto

No se afirman estadísticas de demanda de ocio de mesa inventadas. Todo lo anterior es razonamiento de diseño etiquetado.

3. Propuesta de valor

No es RONDA

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L2 gaming feed-first con GameTable + SeatRequest + JWT HOST.
• Portfolio coherente: Paper (12 UX + 11 UI) + docs + app runnable.
• Terna R-HY · S-DOCK · H-FEED · F-BOOK frente a DERIVA (mapa) y PIZARRA (search).

Usuario

No objetivos v1 (explícitos)

• Pagos, fianza, TPV
• Cuenta de jugador / “mis solicitudes”
• Chat, matching o reputación
• Mapa de locales
• Notificación email / WhatsApp transaccional
• Inventario de juegos en venta
• Multi-anfitrión con roles editoriales

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: HOST. El jugador es anónimo en captura.

6. Métricas (modelo, no instrumentadas en v1 salvo base)

7. Alcance funcional v1 (L2)

8. Criterios de aceptación de producto

1. Un visitante puede ver el feed cronológico sin autenticación y abrir una ficha.
2. Un visitante puede enviar una solicitud sin cuenta y recibir un código RD-….
3. La UI dice explícitamente que la solicitud no confirma plaza.
4. Sin token, GET/PATCH /api/requests* y POST /api/tables responden 401.
5. GET /api/tables devuelve las 5 mesas seed ordenadas por startAt ascendente.
6. Un HOST puede iniciar sesión y ver el inbox ordenado (createdAt desc).
7. El detalle permite transicionar NEW | CONTACTED | SEATED | WAITLIST | CANCELLED.
8. La home es el feed: no hay hero 2-col + 3 cards como superficie principal.
9. Barrios cubiertos en seed: Lavapiés, Embajadores, Chamberí, Malasaña.
10. Fotos de mesa reales en fichas (assets del case).
11. Si los asientos visibles están cubiertos, el CTA ofrece WAITLIST, no “reserva tu silla”.
12. Un HOST autenticado puede publicar una mesa (POST /api/tables).

9. Stack y artefactos

[COMPROBADO] Puerto, Neon, Paper file ID y path de app constan en el brief de este encargo.

10. Riesgos y mitigaciones

11. Glosario

12. Decisiones de diseño (cierre de brief)

13. Relación con el día anterior

[COMPROBADO] El brief exige 0 códigos iguales a N−1 y ≥2 distintos vs N−2. Terna de hoy: R-HY · S-DOCK · H-FEED · F-BOOK.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — RONDA

Importante: este documento contiene artefactos de diseño y razonamiento secundario.
No hay entrevistas de campo primarias ni estadísticas inventadas presentadas como dato medido.
Etiquetas: [COMPROBADO] en producto, [SUPUESTO], [HIPÓTESIS], [DECISIÓN].

1. Objetivos de investigación (del caso)

2. Fuentes y límites

Fuentes admisibles (secundarias / operativas)

• Conocimiento general de bares de juego, cafés con mesa reservable y grupos de WhatsApp de barrio.
• Analogía operativa con feeds + RSVP + inbox JWT de la serie daily.
• Restricciones ALS-2: no mapa, no search-first, no kanban, no e-commerce, no Discord.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: HOST habitual del local (quien abre mesa).
• Usuario frecuente de captura: PLAYER (feed + form) y HOST (inbox diario).
• Riesgo de rechazo: si la home no enseña “esta noche” en el primer viewport, o si el form implica “ya tienes silla”.

4. Personas

P1 — Leo Navas · PLAYER

Escenario: Abre RONDA en el metro, ve Azulejos de Lavapiés a las 20:30 en La Palma 12, pide asiento, guarda RD-0815-001.

[DECISIÓN] Leo no tiene cuenta. Crear usuario jugador sería fricción y no aporta al job de captura.

P2 — Nerea Solís · HOST

Escenario: Login en el bar → inbox → Leo NEW → escribe / llama → CONTACTED → si hay silla SEATED; si la mesa está llena WAITLIST.

Anti-personas

5. JTBD y user stories

Job principal (PLAYER)

Cuando quiero saber qué se juega esta noche cerca,
quiero ver las mesas en un feed y dejar mis datos en un solo paso,
para que el anfitrión me contacte sin perder el mensaje y sin creer que ya tengo silla.

Job principal (HOST)

Cuando abro mesa y empiezan a llegar peticiones,
quiero verlas con juego, hora y estado,
para contactar antes de la hora y sentar o poner en espera sin overbooking.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L2)

6. Journey (PLAYER → HOST)

Momentos de verdad

1. Feed en el primer viewport — si hay que “descubrir la marca”, se rompe S2. [HIPÓTESIS]
2. Disclaimer en form y success — si falta, H2 falla.
3. Código RD- — prueba de “ha llegado” para la barra y el mensaje.
4. WAITLIST visible — evita la mentira social del “ya te apunto”.
5. Dock no esconde Publicar / Inbox — el HOST en el bar no busca un menú hamburger. [HIPÓTESIS]

7. Service blueprint (resumen)

Fallos de servicio y respuesta de diseño

8. Matriz hallazgo → requisito → feature

9. Preguntas abiertas (no bloquean v1)

10. Plan de research futuro (si hubiera campo real)

Estos métodos no se han ejecutado. No se reportan hallazgos como si lo hubieran sido.

11. Síntesis

RONDA se diseña como feed de mesas con cola de asiento, no como tienda, no como mapa y no como Discord.
La investigación del caso es constructiva y etiquetada: personas, JTBD y journey son artefactos de diseño; las métricas de validación quedan para uso real futuro.

03-information-architecture.md

03 — Arquitectura de información — RONDA

1. Principios de IA

2. Sitemap

/                                 Feed Hoy (público) — mesas del día civil, startAt ASC
/mesas                            Feed semanal / próximas (público)
/mesas/:slug                      Ficha de mesa (público)
/mesas/:slug/asiento              Formulario RSVP (público)
/ok                               Success post-solicitud (público)
/login                            Login JWT HOST
/inbox                            Lista de solicitudes (auth HOST)
/inbox/:id                        Detalle + estado (auth HOST)
/publicar                         Crear mesa (auth HOST)
/yo                               Sesión HOST: nombre, salir (auth HOST)
/**                               → redirect /

Árbol por audiencia

[DECISIÓN] /mesas no es un buscador: es el mismo patrón de feed con recorte temporal más amplio.

3. Navegación

Dock flotante (S-DOCK)

[DECISIÓN] El dock es la única navegación primaria. No hay top-nav de 7 ítems ni sidebar CRM.

Pública (además del dock)

HOST (autenticado)

4. Inventario de contenido

5. Taxonomía

RequestStatus

Orden de inbox: createdAt descendente (más reciente primero).
[DECISIÓN] No se ordena por “prioridad de socio del local” en v1.

Mechanic

Neighborhood

Barrios y locales del seed son contenido de producto demo, no una agenda real publicada. [SUPUESTO de catálogo]

Recorte temporal (no es faceta de search)

[DECISIÓN] No hay query q ni chips de mecánica en v1. Eso sería H-SEARCH (PIZARRA). El feed se recorre.

6. Modelo mental vs UI

7. Query string (contrato mínimo)

[DECISIÓN] El feed no serializa filtros de mecánica/barrio en URL en v1. Evita disfrazar un search.

8. Rutas API alineadas a IA

Detalle inbox: GET /api/requests/:id (JWT) — Should de implementación, AC de F7.

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — RONDA

Convenciones

• Actor: Guest (PLAYER) | HOST
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico: F-BOOK (pedir asiento de una mesa)

F1 — Descubrimiento por feed (PLAYER)

/  → feed Hoy (H-FEED)
   → GET /api/tables
   → lista cronológica  |  empty  |  error  |  skeleton
   → click card → /mesas/:slug
   → dock Mesas → /mesas (recorte semana)
   → dock Yo → /login

Éxito: al menos una ficha alcanzable, o empty accionable.
AC: no hay que hacer scroll de “marca” para llegar a la primera mesa.

Errores / estados

F2 — Entender mesa (PLAYER)

/mesas/:slug → GET /api/tables/:slug
             → foto, juego, hora, local, dirección, aforo, anfitrión, reglas, disclaimer
             → CTA "Pedir asiento" → /mesas/:slug/asiento
             → si asientos cubiertos → CTA "Apuntarme a la lista de espera"
             → 404 slug → mensaje + volver al feed

Éxito: CTA visible; disclaimer “pedir asiento no reserva silla” visible antes del form.
Error: 404 si slug inexistente.

AC ficha

F3 — Pedir asiento / RSVP (PLAYER, público)

/mesas/:slug/asiento
  → validación cliente
  → POST /api/requests {
        tableId | slug,
        fullName, email, phone?,
        partySize?,
        notes?
     }
  → 201 SeatRequest { code, status: NEW, ... }
  → /ok?code=RD-…

Éxito: registro status=NEW, código RD-MMDD-NNN, pantalla success.
No hay cuenta de jugador en v1.

Errores

[DECISIÓN] No se bloquea el POST aunque seats estén cubiertos: el jugador puede entrar en WAITLIST después, por decisión HOST. Bloquear en cliente mentiría sobre la barra. El CTA cambia de copy, no de permiso.

F4 — Success (PLAYER)

/ok?code=RD-… → copy de acuse + code
              → “Esto no confirma la silla”
              → CTA volver al feed / ir a la mesa

AC: el código es seleccionable; el disclaimer es visible sin scroll en desktop.

F5 — Login JWT (HOST)

/login → POST /api/auth/login { email, password }
      → 200 { accessToken, user } → localStorage → crea session
      → redirect `next` o /inbox
      → 401 → mensaje error en form

Éxito: token guardado; user role=HOST, nombre Nerea Solís.
Credencial demo: nerea@ronda.club / password123. [COMPROBADO]

F6 — Inbox (HOST)

/inbox (token en cliente)
  → GET /api/requests
  → Render cards

[DECISIÓN] Inbox sin filtros de status en v1 (filtro = L2+). Orden createdAt desc.

F7 — Detalle y cambio de estado (HOST)

/inbox/:id
  → GET /api/requests/:id   (si el endpoint existe; si no, item del list)
  → UI: contacto + mesa + seats + nº solicitudes de la mesa + notas
  → PATCH /api/requests/:id/status { status }
  → 200 SeatRequest actualizado

Transiciones típicas (máquina simple L2)

Éxito: badge actualizado; lista refleja al volver.
Errores: 404 id; 401 sin token; 400 status inválido.

Regla de integridad H3 (ops, no trigger DB v1): HOST no debe marcar SEATED si seatedCount >= seats. La UI avisa; el API L2 v1 no rechaza (corrección humana). Rechazo duro = L2+.

F8 — Publicar mesa (HOST)

/publicar
  → validación cliente
  → POST /api/tables {
        title, mechanic, neighborhood,
        venue, address, startAt, seats,
        summary, description?
     }
  → 201 GameTable { slug, ... }
  → /mesas/:slug

Éxito: mesa aparece en GET /api/tables y en el feed.
Error: 401 sin token; 400 DTO.

[DECISIÓN] El slug se genera en servidor (kebab del título + sufijo si colisión). El HOST no elige slug.

F9 — Logout (HOST)

Click "Salir" en /yo o inbox
  → borra token cliente
  → (opcional) invalida fila en sessions
  → /login

Matriz de errores global

Eventos de dominio (para analytics / blueprint)

Flujos fuera de alcance v1

• Registro / recuperación de password de HOST
• “Mis solicitudes” por código público
• Notificación email / WhatsApp automática
• Filtros multi-criterio en inbox
• Asignación multi-HOST por local
• Pago / fianza
• Edición / baja de mesa publicada por UI (solo alta)
• Check-in QR en la puerta

05-data-model.md

05 — Modelo de datos — RONDA

1. Visión general

Dominio L2 de feed de mesas + cola de asiento:

Base: PostgreSQL (Neon project curly-lab-77015594) · Bootstrap: ensureSchema al arrancar la API · IDs: cuid() o uuid.

[DECISIÓN] Se llama game_tables y no tables (palabra reservada SQL).
[DECISIÓN] ensureSchema (CREATE TABLE IF NOT EXISTS + seed idempotente) en v1; no se exige Prisma para el slice.

2. Enums (aplicación; persistidos como TEXT + check)

Role

RequestStatus

Mechanic

TILE | CARDS | MINIS | COOP | COLLECTION

Neighborhood

LAVAPIES | EMBAJADORES | CHAMBERI | MALASANA

3. Diagrama ER (texto)

users
  id, email, password_hash, name, role(HOST)
  created_at, updated_at
  1 ──< sessions
  1 ──< game_tables          -- host_id

sessions
  id, user_id → users
  token_hash, expires_at
  created_at

game_tables
  id, slug (unique), title, summary, description
  mechanic, neighborhood, venue, address
  start_at, seats, image_key
  host_id → users
  created_at, updated_at
  1 ──< seat_requests

seat_requests
  id, code (unique)
  table_id → game_tables
  full_name, email, phone?
  party_size (default 1)
  notes
  status (default NEW)
  created_at, updated_at

No hay FK entre seat_requests y users en v1: el form es anónimo. HOST opera sobre el conjunto global.

4. Tablas (ensureSchema)

users

sessions

[DECISIÓN] El JWT viaja en Authorization: Bearer. sessions permite invalidar (logout) sin esperar expiración del JWT.

game_tables

Índice recomendado: (start_at ASC) para el feed.

seat_requests

Índice recomendado: (created_at DESC) para inbox; (table_id, status) para conteo SEATED.

5. Reglas de integridad y negocio

6. Contratos API

GET /api/tables (público)

Response 200: GameTable[] ordenado por start_at asc. Incluye campos de card + ficha; sin PII de solicitudes.

Query opcional L2+ (no Must): from, to ISO. v1 puede filtrar “hoy” en cliente.

GET /api/tables/:slug (público)

GameTable + hostName + seatedCount (agregado) o 404.

POST /api/tables (JWT HOST)

Body

Response 201: GameTable con slug generado.

POST /api/requests (público)

Body

Response 201: SeatRequest + table embebido mínimo (title, slug, startAt, venue).

POST /api/auth/login

Body: { email, password }
Response 200: { accessToken, user: { id, email, name, role } }
Efecto: inserta fila en sessions.

GET /api/requests (JWT HOST)

Array SeatRequest + table, created_at desc.

PATCH /api/requests/:id/status (JWT HOST)

Body: { status: RequestStatus }
Response 200: SeatRequest actualizado.

GET /api/requests/:id (JWT HOST) — Should

SeatRequest + table (seats) + seatedCount o 404.

7. Seed de referencia (2026-08-15)

HOST

[COMPROBADO] Credencial demo del brief.

game_tables

[COMPROBADO] Títulos, locales, horas y aforos salen del brief.

Direcciones extendidas, textos de reglas y start_at concreto (fecha del seed) son contenido demo. [SUPUESTO de catálogo]

Textos seed recomendados (no lorem):

seat_requests

El sufijo de fecha del código de seed es el día del caso; la generación runtime usa Europe/Madrid.

Idempotencia seed: upsert HOST por email; upsert mesas por slug; upsert requests por code. No duplicar al re-arrancar.

8. Generación de código

RD- + MMDD (Europe/Madrid) + - + NNN

NNN = siguiente entero del día, padded 3. Si unique falla, reintentar NNN+1 (máx. 5).
Ejemplo el 15 de agosto: RD-0815-001.

9. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — RONDA

1. Visión

Stack fijo del cron (D-P0-03). No React/Next/Firebase.
[COMPROBADO] Puerto 3015, Neon y pnpm constan en el brief de implementación.

2. Estructura

ronda-app/
├── apps/api/     # Nest + ensureSchema (paquete independiente)
├── apps/web/     # Angular + Tailwind (paquete independiente)
├── package.json  # scripts api / start + pnpm filter
└── pnpm-workspace.yaml

D-P1-03 (adaptado): apps independientes. [DECISIÓN] pnpm workspaces + --filter (no npm workspaces que rompen Angular; no npm --prefix si el brief pide pnpm).

Scripts raíz esperados:

3. API pública vs JWT

CORS: origen http://localhost:4200 en local.

4. Justificación

5. Variables

.env local (nunca git):

.env.example solo placeholders.
Web: URL de API en ApiService (default http://localhost:3015/api).

6. Dependencias de producto (mínimas)

API

• @nestjs/common / core / platform-express
• @nestjs/jwt + passport-jwt (o verificación manual)
• bcrypt (o bcryptjs)
• cliente Postgres (pg)
• class-validator + class-transformer

Web

• Angular standalone
• Tailwind 3
• fuentes: Zilla Slab + Mulish (Google Fonts o self-host)

7. Arranque (contrato)

cd /Users/cristian/orca/ronda-app
pnpm install
# apps/api/.env → DATABASE_URL + JWT_SECRET
pnpm api      # http://localhost:3015
pnpm start    # http://localhost:4200

Al boot, la API ejecuta ensureSchema y seed si las tablas están vacías o por upsert.

8. Lo que este stack no es

07-creative-direction.md

07 — Dirección creativa — RONDA

1. Mood

Signage — cartelería de local de barrio: pizarra de tiza sustituida por placa esmaltada, número de mesa, hora en negro y un amarillo de semáforo que dice “abierto esta noche”.

No es taberna candlelit (primer instinto). No es dusk cartográfico (DERIVA). No es wine de editorial (PLIEGO). No es chalky de aula (PIZARRA).

Candidatos del brief y veredicto:

[COMPROBADO] Mood signage y paleta salen de 00-day-brief.md.
[DECISIÓN] R-HY = flyer clásico de caja de juego (titular Zilla, foto de mesa, hora grande) + dock flotante innovador usable.

2. Paleta

[COMPROBADO] Hex literales del brief: #FFFFFF #111111 #F5C400 #1F4D3A #FFF6C2 #E24B2A.

Combinaciones legales

No usar cromo 13px sobre blanco como único indicador (contraste de acento, no de texto).

3. Tipo

[COMPROBADO] Familias y escalas del brief.

Evitar (cooldown / contaminación de serie): Lora, Karla, Newsreader, Atkinson, Outfit, Archivo, Fraunces.

4. Principios

1. La cronología es el monumento. Hora grande, no hero 2 columnas.
2. Radio 0–6px. Cartel, no píldora atlética.
3. Foto real de la mesa, nunca color sólido ni image_gen como captura de producto (D-P0-09).
4. Copy honesto: solicitud ≠ plaza.
5. Dock flotante siempre. Cinco slots, cromo en el activo.
6. Contraste AA tinta sobre blanco/liner; labels ≥14px.
7. Flyer + dock: el card parece recorte de caja; la navegación no parece caja.

5. Referentes visuales (no clonar)

6. Art direction de media

7. Motion

8. Anti-dirección

08-design-system.md

08 — Design system — RONDA

1. Tokens

Ver Paper UI-00 y apps/web/tailwind.config.js.

Tipo — escala

Espaciado

Escala 4: 8 / 12 / 16 / 24 / 32 / 48.
Feed: gap 16 entre cards. Dock: padding 8, gap 4 entre slots. Ficha: bloque 24.

2. Componentes

3. Layouts

Feed (UI-01 / UI-10)

[ wordmark + fecha ]
[ card ]
[ card ]
[ card ]
[ … ]
[ dock flotante ]

Desktop ≥960px: cards a 640–720px centradas (columna de cartel), no grid 3×N de marketplace.
[DECISIÓN] Una columna refuerza H-FEED y evita “catálogo de SKU”.

Ficha (UI-02)

Foto full-bleed de la columna → hora + título → meta (local, barrio, asientos, HOST) → reglas → disclaimer → CTA sticky sobre el dock.

Inbox (UI-06)

Lista densa: código · nombre · mesa · badge. Desktop puede añadir columna de acciones.

4. Estados

5. Iconografía del dock

Iconos 20×20 stroke 1.75, tinta. Activo: trazo tinta sobre disco cromo.

6. Breakpoints

Targets táctiles ≥44px (dock slots 56×48 cumple).

7. No usar

09-content-guide.md

09 — Guía de contenido — RONDA

1. Voz

Cercana de barrio, concreta, de barra. Tuteo. Segunda persona.
Sin jerga de marketplace (“experiencia premium”), sin Discord (“únete al server”), sin sede electrónica.

El producto informa y recoge, no vende una noche mágica.

2. Palabras permitidas / prohibidas

3. Microcopy clave (literales de producto)

[DECISIÓN] El disclaimer aparece tres veces: ficha, form, success. No es opcional.

4. Códigos

Formato RD-MMDD-NNN. Se lee en voz alta en la barra: “erre de, ocho quince, cero cero uno”.
No UUID. No QR obligatorio en v1.

5. Nombres propios del seed

No inventar reseñas de Google ni horarios oficiales de esos locales. [SUPUESTO de catálogo demo]

6. Tono por estado

La app no envía esos mensajes en v1. El copy solo prepara el habla.

7. Capitalización y números

• Wordmark: RONDA en versales.
• Horas: 20:30 (24 h, Europe/Madrid), no 8:30 PM.
• Asientos: 2/4 sillas (ocupadas estimadas / total) cuando hay dato; si no, 4 sillas.
• Barrios: Malasaña, Lavapiés, Chamberí, Embajadores (tilde correcta).

8. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar “table” en UI. En API sí: game_tables, tableId.

9. Accesibilidad de copy

• No transmitir estado solo con color (“el amarillo significa nueva”).
• Badge lleva texto: Nueva, Contactada, Sentada, Lista de espera, Cancelada.
• Alt de fotos: “Azulejos sobre mesa de café en Lavapiés”, no “imagen1”.

10. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad — RONDA

Objetivo: WCAG 2.2 AA. No se declara conformidad legal certificada.
Este documento cubre la UI (feed, form, dock, inbox). No audita la accesibilidad física de los locales seed. [SUPUESTO]

1. Decisiones

2. Contraste (comprobación de diseño)

3. Teclado

• Enter en card = navegar a ficha.
• Escape no cierra el dock (no es modal).
• Focus trap solo si hubiera modal; v1 no tiene modal salvo confirmación CANCELLED (Should).

4. Semántica

5. Lector de pantalla — copy

6. Producto vs local físico

[DECISIÓN] v1 no incluye faceta a11y de sede (eso era PIZARRA). Un campo libre notes permite “voy en silla” sin fingir auditoría.

7. Riesgos

8. QA a11y (mínimo)

9. Criterios de aceptación

1. Ningún control del dock o CTA mide menos de 44×44 CSS px.
2. El disclaimer no depende del color cromo para ser entendido.
3. Las 5 fotos seed tienen alt no vacío y no genérico.
4. El foco no se pierde al reintentar un error de red.

11-privacy-security.md

11 — Privacidad y seguridad — RONDA

No es un dictamen legal ni un DPIA. Es el contrato de producto para el vertical slice.

1. Datos

Sin datos de salud, menores con tutor, geolocalización continua, ni pagos.

[DECISIÓN] El jugador no crea cuenta. Menos superficie de credenciales.

2. Base (supuesto de diseño)

[SUPUESTO] Interés del HOST en organizar una mesa privada/pública de ocio + consentimiento de contacto al enviar el form.
El texto del form debe mencionarlo:

Usaremos tu nombre y email (y teléfono si lo dejas) solo para escribirte por esta mesa.

No se cede a editoriales, no se usa para marketing de terceros.

3. Minimización

[DECISIÓN] Teléfono opcional: el email basta para el acuse; el HOST prefiere WhatsApp en la práctica [HIPÓTESIS], pero no exigimos el número.

4. Retención

[HIPÓTESIS] 12 meses cubre una temporada de mesa y reclamaciones de “yo escribí”. No es plazo legal afirmado.

5. Autorización

Guards en API son la autoridad. La UI solo esconde.
[COMPROBADO] D-P1-05: panel interno cerrado desde el día 1.

JWT + sessions

1. Login válido → bcrypt compare → insert sessions → emite JWT (sub, email, role, sid).
2. Request protegida → verifica firma + sid no expirado.
3. Logout → expire/delete session; el JWT deja de valer aunque no haya caducado.

[DECISIÓN] Bearer header, no cookie de primer partido en v1 (demo localhost). CSRF residual bajo; XSS sigue siendo el riesgo (no innerHTML de notas sin escape).

6. Seguridad v1

7. Amenazas y respuesta

8. Credencial demo

[COMPROBADO] Brief. No reutilizar en un deploy público sin rotar.

9. Riesgos residuales (aceptados L2)

• No hay checkbox RGPD formal (Q3).
• No hay cifrado de columna PII (TLS en tránsito + Neon en reposo).
• localStorage XSS.
• Un HOST ve todas las solicitudes (cola única de demo).

10. Criterios de aceptación

1. GET /api/requests sin Authorization → 401.
2. PATCH status sin token → 401.
3. POST /api/tables sin token → 401.
4. GET /api/tables no incluye emails de jugadores.
5. Response de login no incluye password_hash.
6. .env no se commitea.

12-analytics.md

12 — Analítica — RONDA

Instrumentación modelo. v1 puede no emitir eventos reales; este doc es el contrato para cuando se encienda.
No se presentan tasas de conversión inventadas.

1. North star

% de solicitudes válidas (nombre + email + mesa existente) que pasan a CONTACTED antes de startAt de esa mesa.

Por qué no “mesas llenas” ni “pageviews”:

La north star mide contacto honesto a tiempo, alineada a S3/H2.

2. Hipótesis ↔ señales

3. Eventos

[DECISIÓN] No enviar email ni teléfono a analytics. El code es el identificador.

4. Funnel

Land feed → table_opened → rsvp_started → rsvp_submitted
         → host_login → status_changed(CONTACTED) ≤ startAt
         → status_changed(SEATED)  |  WAITLIST

5. Invariantes (salud, no vanity)

6. Dimensiones

Sin user-id de jugador.

7. Privacidad de analítica

• Sin fingerprinting.
• Sin email en claro.
• IP no se guarda en el plano de producto.
• Eventos de demo pueden quedarse en consola.

8. Qué no medimos en v1

9. Criterios de aceptación (si se implementa tracker)

1. Cada evento de la tabla §3 tiene nombre estable snake_case.
2. rsvp_submitted incluye code con prefijo RD-.
3. Ningún payload de analytics incluye email o phone.
4. El dashboard interno (si existe) no es Must del L2.

13-qa-test-plan.md

13 — Plan de pruebas — RONDA

1. Smoke obligatorio (D-P1-06)

El brief de implementación fija el mínimo:

[COMPROBADO] Smoke = GET tables + POST request + login JWT.

2. Casos funcionales

3. Datos de prueba

4. Regresión de diversidad / craft

5. Hipótesis (no se “prueban” en la demo)

H1, H2, H3 requieren uso real. El QA verifica que existen las superficies que permitirían medirlas (tap en card, disclaimer, badge SEATED + seats).

6. Criterios de salida QA v1

• Smoke §1 en verde.
• S2, S6, S7, S12, S18, S20 en verde.
• Cero blockers de copy deshonesto.
• Sin .env en el repo.

7. Fuera de este plan

Playwright e2e completo, carga, fuzzing, auditoría de locales físicos.

14-dev-handoff.md

14 — Handoff desarrollo — RONDA

1. Arranque

cd /Users/cristian/orca/ronda-app

# apps independientes · pnpm filter
pnpm install

# apps/api/.env
#   DATABASE_URL=  # Neon curly-lab-77015594
#   JWT_SECRET=
#   PORT=3015

pnpm api      # Nest → http://localhost:3015
pnpm start    # Angular → http://localhost:4200

Al boot: ensureSchema crea users, sessions, game_tables, seat_requests y semilla idempotente.

Demo: nerea@ronda.club / password123.

2. Paridad Paper

No clonar DERIVA (mapa split) ni PIZARRA (command search).

3. Contratos

Campos JSON en camelCase hacia el web aunque SQL sea snake_case. [DECISIÓN]

4. Mapa de rutas web

Soft guard: si no hay token, /login?next=. La API es la autoridad.

5. Assets

Copiar desde el case:

2026-08-15-ronda/assets/hero.jpg
2026-08-15-ronda/assets/tables/*.jpg
  → apps/web/src/assets/tables/

image_key del seed = filename (azulejos.jpg, …).

6. DoD implementación L2

7. No hacer

8. Contactos de diseño (artefactos)

15-roadmap.md

15 — Roadmap — RONDA

1. Hecho en L2 (esta ejecución documental)

2. Implementación L2 (misma complejidad, código)

Contrato en docs 14 y 20. No es deuda silenciosa del case documental: es el build del repo ronda-app.

3. L2+ (misma complejidad, polish)

Estas son subidas de pulido, no parches del L2 documental.

[DECISIÓN] No dejar backlog del vertical slice como “mañana”. Lo de arriba es polish o subida de nivel.

4. L3 (requiere brief nuevo de diversidad)

• Multi-HOST / un local varios anfitriones
• Cuenta PLAYER y “mis solicitudes”
• Email / WhatsApp transaccional
• Check-in QR en puerta
• Venues normalizados + calendario iCal
• Check DB transaccional de aforo
• Audit log
• Facetas search (rompería H-FEED si se convierten en home)

5. Explícitamente fuera (no backlog disfrazado)

6. Orden de ataque si hay continuidad de código

1. Contratos 05–06 + seed 05 + smoke 13
2. Web paridad UI-01…10
3. Guards + H3 UI + contacto tel
4. Rate limit si hay tráfico
5. Evaluar brief L3 (no parche silencioso)

16-interaction-specs.md

16 — Especificación de interacción — RONDA

1. Convenciones

2. Dock (S-DOCK)

Estado activo: disco cromo + label tinta.
Estado default: tinta sobre liner.
No: badge numérico obligatorio; si se implementa, aria-label="Inbox, 3 nuevas".

Slots: Hoy / · Mesas /mesas · Publicar /publicar · Inbox /inbox · Yo /yo o /login.

3. Feed Hoy / Mesas

AC: la primera card de esta noche está en el viewport inicial a 390 y a 1280 (sin hero de 60vh).

Orden visual = startAt ASC. Si dos mesas comparten hora, desempate title ASC.

4. Ficha

Hueco estimado = seats - seatedCount (agregado). Si el API no manda seatedCount, mostrar seats y CTA estándar. [DECISIÓN]

5. Form RSVP

Submit deshabilitado si nombre < 2 o email inválido.

6. Success

Sin animación de confetti. Sin “¡reserva confirmada!”.

Si se entra a /ok sin code: mensaje “Solicitud enviada” genérico + CTA feed. No inventar un código.

7. Login

next permitido: paths que empiezan por / y no // ni http.

8. Inbox

No swipe-to-archive en v1.

9. Detalle + estados

Aviso H3 (no bloqueo API v1):
“Hay tantas o más solicitudes sentadas que sillas. ¿Seguro?”

Optimistic UI: badge cambia al tap; si PATCH falla, rollback + toast error.

10. Publicar

No hay preview Paper-like. El HOST ve la ficha real.

11. Yo / logout

Tap “Salir” → limpia storage → (opcional DELETE session) → /login.
No confirmación.

12. Motion

Prohibido: scroll-jacking, page transitions de 400ms, parallax en foto.

13. Criterios de aceptación de interacción

1. Un PLAYER en 390px llega de feed a success en ≤ 4 taps (card, CTA, submit → success).
2. Un HOST en 390px marca CONTACTED en ≤ 3 taps desde inbox (card, acción).
3. Ningún submit permite doble POST.
4. El dock no cubre el CTA de ficha (padding / sticky por encima).
5. Reduced-motion elimina stagger.
6. La home no es hero 2-col (AP-12).

17-prototype-map.md

17 — Mapa de prototipo — RONDA

Paper no es clicable vía MCP. El prototipo vivo es la app Angular en /Users/cristian/orca/ronda-app/ (pnpm start :4200).

1. Paper → rutas

2. Guion de demo (click-through)

3. Estados en el mismo prototipo

4. Deep links seed

API :3015 · Web :4200 · proxy /api opcional.

5. Qué no es prototipo

• El file Paper no sustituye flujos clicables.
• Un HTML estático en presentation/ no es el vertical slice.
• Capturas image_gen no son evidencia de producto (D-P0-09).

18-completeness-audit.md

18 — Auditoría de completitud — RONDA (2026-08-15)

1. Alcance auditado

Vertical slice L2: feed cronológico de mesas de juego locales + RSVP público + panel HOST JWT, con docs, referencia Paper, contratos Angular + Nest + ensureSchema + Neon.

Este encargo cubre la suite documental. Paper hi-fi y el repo ronda-app pueden existir en paralelo; la auditoría marca lo que esta suite cierra.

2. Checklist CRON / ALS-2

3. Cobertura funcional

4. Cobertura Paper (literales del brief)

[COMPROBADO] Nombres coinciden con el encargo. UX-count: 12 y UI-count: 11 literales para el gate check-paper-reference.mjs.

5. Rúbrica de calidad (auto SCORE orientativo · docs)

6. Huecos aceptados (no regresiones de cierre documental)

7. Veredicto

COMPLETO para entrega documental del caso 2026-08-15.
La suite define producto L2 usable (tablas, AC, riesgos, contratos) sin presentar investigación de campo como hecho.
Cualquier ampliación mapa / search-first / pagos / Discord requiere nuevo brief de diversidad, no parche silencioso.

19-backlog-completo.md

19 — Backlog completo — RONDA

Inventario de ítems. Los del alcance L2 documental del día están Done.
El resto es opcional / siguiente nivel, no deuda oculta del cierre.

1. Done — L2 case documental (2026-08-15)

2. Backlog L2 implementación (repo ronda-app)

3. Backlog L2+ (polish)

4. Backlog L3 (requiere brief nuevo)

5. Backlog explícitamente fuera

6. Explicitamente no-backlog

7. Orden de ataque recomendado (continuidad de código)

1. I01–I12 (vertical slice runnable)
2. B01 + B06 + B10
3. B03 + B08
4. B04 + B05 si hay tráfico
5. Evaluar brief L3 — no parche silencioso

8. Trazabilidad

20-implementation.md

20 — Implementación — RONDA

1. Resumen ejecutivo técnico

Este documento es la especificación de build alineada al case. No sustituye al código: si el repo diverge, gana el contrato de docs 05 + este archivo tras actualizar ambos.

[COMPROBADO] Path, puertos, tablas, Neon y scripts pnpm api / pnpm start salen del brief de implementación.

2. Cómo arrancar

cd /Users/cristian/orca/ronda-app
pnpm install

# apps/api/.env
#   DATABASE_URL=   # Neon curly-lab-77015594
#   JWT_SECRET=
#   PORT=3015

pnpm api      # http://localhost:3015
pnpm start    # http://localhost:4200

Apps independientes: no npm workspaces. Usar:

pnpm --filter api add <pkg>
pnpm --filter web add <pkg>

Credenciales

3. ensureSchema

Al boot de Nest (onModuleInit o main.ts antes de listen):

1. CREATE TABLE IF NOT EXISTS de las 4 tablas (doc 05).
2. Índices: game_tables(start_at), seat_requests(created_at DESC), seat_requests(table_id, status), users(email), sessions(token_hash).
3. Seed idempotente:
   • upsert HOST nerea@ronda.club (bcrypt de password123)
   • upsert 5 game_tables por slug
   • upsert seat_requests por code

No borrar datos de usuario en cada boot si ya existen filas de requests distintas al seed. El seed solo garantiza las filas canónicas.

Tablas (recordatorio)

4. Módulos API a implementar

Auth

• POST /api/auth/login
• Valida email/password; compara bcrypt; inserta sessions; emite JWT con sub, email, role, sid.
• Guard JWT protege lectura/escritura de solicitudes y alta de mesas.

Tables (público lectura · HOST escritura)

Requests

Generación de código

RD- + MMDD (Europe/Madrid) + - + NNN

NNN = siguiente entero del día, padded 3. Si unique falla, reintentar NNN+1 (máx. 5).

[DECISIÓN] Timezone Europe/Madrid, no UTC, para que “Hoy” y el código coincidan con la barra.

5. Frontend a implementar

Shell: DockComponent persistente.
ApiService centraliza base URL http://localhost:3015/api, token storage (ronda_token, ronda_user), métodos tipados (GameTable, SeatRequest, User).

6. Decisiones de implementación

7. Variables de entorno

Web: URL de API en ApiService (default localhost:3015).

8. Smoke de implementación (mínimo)

1. ensureSchema OK (tablas existen).
2. GET /api/tables length ≥ 5, incluye azulejos, cartas, minis, cooperativo, coleccion.
3. POST /api/requests 201 + code RD-.
4. POST /api/auth/login 200 + accessToken.
5. GET /api/requests Bearer incluye el POST.
6. GET /api/requests sin token 401.
7. POST /api/tables sin token 401.
8. Web: feed dominante, dock, disclaimer, fotos.

9. Estructura de ficheros clave

ronda-app/
├── pnpm-workspace.yaml
├── package.json                  # scripts: api, start
├── apps/api/
│   ├── package.json
│   ├── src/
│   │   ├── main.ts
│   │   ├── app.module.ts
│   │   ├── db/
│   │   │   ├── ensure-schema.ts
│   │   │   └── seed.ts
│   │   ├── auth/
│   │   │   ├── auth.controller.ts
│   │   │   ├── auth.service.ts
│   │   │   ├── jwt.strategy.ts
│   │   │   └── jwt-auth.guard.ts
│   │   ├── tables/
│   │   │   ├── tables.controller.ts
│   │   │   └── tables.service.ts
│   │   └── requests/
│   │       ├── requests.controller.ts
│   │       └── requests.service.ts
│   └── .env.example
├── apps/web/
│   ├── package.json
│   ├── tailwind.config.js
│   └── src/app/
│       ├── app.routes.ts
│       ├── core/api.service.ts
│       ├── shell/dock.component.ts
│       └── pages/
│           ├── feed/
│           ├── table-detail/
│           ├── rsvp/
│           ├── success/
│           ├── login/
│           ├── inbox/
│           ├── request-detail/
│           ├── publish/
│           └── me/
└── README.md

Nombres de fichero orientativos; el contrato es de rutas y tablas, no de filenames exactos.

10. Seed — checklist de implementación

11. Alineación case ↔ app

12. Notas de cierre técnico

• El case documental L2 está especificado (docs + Paper ref + contratos).
• Must-have de producto del brief están escritos con AC.
• Mejoras (guards Angular, e2e, rate limit, check aforo) viven en backlog L2+, no como deuda silenciosa.
• Repo GitHub Criscode2022/ronda-app se creará; este doc no lo asume ya pusheado.