00-day-brief.md

00 — Day brief · 2026-08-21 · TEMPLE

Decisiones ALS-2 BRIEF

Terna unicidad

R-HY · S-MIN · H-KIOSK · F-BOOK

0 códigos iguales a N−1 (PREGÓN: R-IN · S-SIDE · H-CHAT · F-KAN).
≥2 distintos vs N−2 (MATIZ) y N−3 (ZAGUÁN).
Ventana 4: R-IN + R-HY + R-IN + R-CL → hoy R-HY (sigue habiendo clásico).

S-MIN, H-KIOSK y F-BOOK no están en los últimos 5 (S-SIDE/BOTTOM/WIZ/TOP/RAIL · H-CHAT/BENTO/WIZARD/GALLERY/TABLE · F-KAN/EDIT/CMP/STORY/LEAD).

Ground (CRON §5.6)

• Familia: G-INK
• Hex: #12110F
• Por qué: cuadro de instrumentos de un quiosco en el pasillo (vehicle dashboard), no fotocopia (PREGÓN), no yeso (MATIZ), no hormigón (ZAGUÁN), no kiosco blanco (MARGEN), no musgo (CESTA).

Mood visual (Paper)

• Candidatos: nocturnal (primer instinto concierto), vehicle dashboard, subterranean, industrial, phosphor
• Elegido: vehicle dashboard — no el primer instinto escenario+neón (eso es Conciergo). Un local de ensayo se opera como un tablero de horas, ámbar LED sobre negro de flight case.
• Paleta:
  • #12110F instrument black (ground)
  • #1E1C18 panel
  • #F4EBD0 crema de dial
  • #E8A317 ámbar LED / gaffer
  • #8C8474 mute
  • #C23B22 joya de ampli (urgente, poco)
• Tipo: Fraunces display · Atkinson Hyperlegible UI (evita Ibarra+Jost / Libre Baskerville+Nunito / Instrument+Sora / Cormorant+Public Sans / Spectral+Manrope)

Alcance L2 must

1. Home kiosk: 3 salas a pantalla completa (lead + 3 datos)
2. Rejilla de horas (bloques de 2 h, hoy)
3. Confirmar con nombre de banda (sin cuenta)
4. Ticket (hora cogida ≠ concierto)
5. Login JWT CONSERJE
6. Tablero de ocupación de hoy (horario, no kanban)
7. Empty / error / loading / mobile kiosk
8. ≥12 UX + ≥10 UI

Microcopy duro

• Hora cogida ≠ concierto. TEMPLE no vende entradas.
• Sala ≠ escenario. Es un cuarto con moqueta.
• TEMPLE no actúa. El concierto es otro producto.
• Ensayar no es tocar en público.

Supuestos

• S1: Una nave atiende 12–20 horas/día en 3 salas; la demo tiene 3 salas y 5 bloques (10–12, 12–14, 16–18, 18–20, 20–22).
• S2: El músico coge hora en el pasillo, con la funda en el suelo; no crea cuenta.
• S3: Un CONSERJE (Lola) ve ocupación; no hay taquilla.
• S4: Sin backline extra, sin rider, sin pago en el kiosk (se paga en ventanilla). [DECISIÓN]

Hipótesis

00-paper-reference.md

Paper reference · TEMPLE

UX-count: 12 UI-count: 12

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 Kiosk home · UI-02 Kiosk mobile · UI-03 Slots · UI-04 Confirm · UI-05 Success · UI-06 Login · UI-07 Turno · UI-08 Empty · UI-09 Error · UI-10 Loading · UI-11 Slots mobile

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

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

Mapeo Paper → Angular

01-project-definition.md

01 — Definición de proyecto — TEMPLE

1. Identidad

[COMPROBADO] Nombre, terna, nivel, sector, ground y paleta salen de docs/00-day-brief.md.
[SUPUESTO de catálogo] Paseo de Yeserías / Carabanchel es atrezzo de mercado, no la dirección de un local real.

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] El músico de un local de ensayo de barrio no necesita taquilla: necesita coger Sala 2 dos horas sin preguntar por WhatsApp. Hoy eso vive en un grupo, una conserje con llaves y una expectativa de escenario. La hora se lee como concierto; la sala se lee como escenario; el producto se lee como Conciergo. [SUPUESTO] Una nave atiende 12–20 horas/día en 3 salas; no opera un ticketing ni un 112.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Una nave atiende 12–20 horas/día en 3 salas; la demo tiene 3 salas y 5 bloques (10–12, 12–14, 16–18, 18–20, 20–22). [SUPUESTO]
• S2: El músico coge hora en el pasillo, con la funda en el suelo; no crea cuenta. [SUPUESTO]
• S3: Un CONSERJE (Lola) ve ocupación; no hay taquilla. [SUPUESTO]
• S4: Sin backline extra, sin rider, sin pago en el kiosk (se paga en ventanilla). [DECISIÓN]

Hipótesis de producto

No se afirman estadísticas de locales de ensayo inventadas. Todo lo anterior es razonamiento de diseño etiquetado.

3. Propuesta de valor

No es TEMPLE

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L2 música / ensayo de barrio con Room + Booking + JWT CONSERJE.
• Portfolio coherente: Paper (12 UX + 12 UI) + docs + app runnable.
• Terna R-HY · S-MIN · H-KIOSK · F-BOOK frente a PREGÓN (chat/kanban), MATIZ (bento/editor) y ZAGUÁN (wizard/comparador).

Usuario

No objetivos v1 (explícitos)

• Entradas, taquilla, aforo, Conciergo
• Escenario, palco, line-up, rider
• 112, policía, bomberos
• Chat, kanban, columnas Recibido / En curso
• Cuenta de banda, seguimiento con login, push
• Pago en kiosk, TPV, pasarela
• Calendario semanal / mes
• Multi-nave, multi-conserje
• App nativa ni notificaciones push
• Rol DUEÑA autenticado

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: CONSERJE. El músico no es un usuario del sistema: es autora/autor de un booking. La taquilla no es un rol de sistema el día 1.

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

7. Alcance funcional v1 (L2)

8. Criterios de aceptación de producto

1. / es el kiosk de 3 salas. No pide cuenta. No es un hero 2-col + 3 cards.
2. Un músico puede ver 3 salas en el fold (lead + 3 datos), tocar Sala 2, coger 18–20 y obtener un código TM-XXXX.
3. /ok/:code dice explícitamente que hora cogida no es concierto y que TEMPLE no vende entradas.
4. La UI dice explícitamente que sala no es escenario y que ensayar no es actuar.
5. Sin token, GET /api/turno responde 401. POST /api/bookings y GET /api/rooms son públicos.
6. Un POST de hora crea status=CONFIRMED. Coger no emite una entrada.
7. Una CONSERJE inicia sesión y ve el horario con 8 cogidas / 7 libres en el seed.
8. El tablero es un horario (filas = bloques, columnas = salas). No es un kanban de 3 columnas.
9. Fotos reales en las 3 salas seed (assets salas/*).
10. Bloques visibles: 10–12 · 12–14 · 16–18 · 18–20 · 20–22.
11. Chrome S-MIN: casi sin nav. Kiosk público sin top-nav de marketing.
12. Rutas solo las del doc 03. No existen /entradas, /concierto, /112, /mesa, /chat.
13. GET /api/health devuelve service: "temple-api".
14. El kiosk no muestra el nombre de otras bandas; el turno sí.

9. Stack y artefactos

[COMPROBADO] Puerto, Neon, Paper file ID, repo y path de app constan en el encargo.
El código se escribe en paralelo a esta suite.

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 fija terna R-HY · S-MIN · H-KIOSK · F-BOOK. 0 códigos iguales a N−1 (PREGÓN). ≥2 distintos vs N−2 (MATIZ) y N−3 (ZAGUÁN). Ventana 4 días: R-IN + R-HY + R-IN + R-HY. Ground G-INK #12110F, no G-FOG.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — TEMPLE

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 locales de ensayo de barrio (salas con kit / combo / seca; bloques de 2 h; llaves; pago en ventanilla; distinción ensayo vs concierto).
• Analogía operativa con kiosk público + panel JWT de la serie daily.
• Restricciones ALS-2: no Conciergo, no taquilla, no 112, no kanban, no chat, no editor de oficio.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: la nave (quién pone el kiosk en el pasillo) y, en uso diario, Lola (quien mira el horario).
• Usuario frecuente de coger hora: BANDA / BATERÍA (kiosk, sin cuenta).
• Usuario frecuente de ocupación: CONSERJE (turno).
• Riesgo de rechazo: si el ticket parece una entrada; si la sala parece escenario; si hay que crear cuenta; si el turno parece un kanban.

4. Personas

P1 — Iván Mora · BANDA (guitarra, Los Yesos)

Escenario: Abre / en el kiosk del pasillo, toca Sala 2 Combo, elige 18–20, escribe Los Yesos, lee «Hora cogida ≠ concierto» y el código TM-XXXX.

[COMPROBADO] Nombre, edad y gesto (guitarra, Los Yesos) salen del encargo. Es constructo de diseño, no entrevistado. [DECISIÓN]

P2 — Lola Rivas · CONSERJE

Escenario: Login → turno horario 8/15 → lee Marta Chen en Sala 1 16–18 → no encuentra «entradas» ni «112» ni columnas Recibido / En curso.

[COMPROBADO] Credencial demo sale del encargo. Nombre, edad y mesa son constructo de diseño. [DECISIÓN]

P3 — Marta Chen · BATERÍA (secundaria)

Escenario: En el seed ya ocupa Sala 1 Batería 16–18. No entra a /turno. Misma superficie que Iván.

[DECISIÓN] Marta no es rol de sistema. Es la misma superficie que Iván, con otra sala. En seed figura como bandName «Marta Chen».

Bandas de seed (no personas primarias extra)

[COMPROBADO] Nombres de persona salen del encargo. Los nombres de banda extra son catálogo demo. [SUPUESTO de catálogo]

Anti-personas

5. JTBD y user stories

Job principal (BANDA)

Cuando llego al pasillo con la funda y no sé si está libre la 2,
quiero coger Sala 2 dos horas en el quiosco,
para no preguntar por WhatsApp ni crear una cuenta.

Job principal (CONSERJE)

Cuando abro el turno por la tarde,
quiero ver quién ocupa cada bloque de las tres salas,
para no cazar horas en un grupo de WhatsApp.

Job secundario (BATERÍA)

Cuando necesito el kit,
quiero ver Sala 1 y sus bloques de hoy,
para no montar un rider ni un escenario.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L2)

6. Journey (BANDA · Sala 2 a las seis + CONSERJE)

Momentos de verdad

1. 3 salas + 3 datos en el primer viewport — si hay que «descubrir la marca», se rompe H-KIOSK / AP-21. [HIPÓTESIS]
2. Sin cuenta — si aparece «regístrate», S2 / H3 fallan.
3. Success dice que hora no es concierto — evita la mentira de la entrada.
4. Cero CTA de entradas y cero 112 como envío — si aparece «Comprar entrada» como primary, el microcopy falla.
5. Horario, no kanban — S-MIN / F-BOOK staff. [HIPÓTESIS]
6. Bloque cogido no se recoge — 409 visible. [DECISIÓN]

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

TEMPLE se diseña como quiosco de horas que se coge y se mira en un horario, no como taquilla, no como escenario y no como chat.
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 — TEMPLE

1. Principios de IA

2. Sitemap

/                                      Kiosk público (3 salas)                      H-KIOSK
/sala/:slug                            Rejilla de horas + confirmar                 F-BOOK · público
/ok/:code                              Ticket post-hora                             público
/login                                 Login JWT CONSERJE                           público
/turno                                 Horario de ocupación de hoy                  auth
/**                                    → redirect /  (si no hay token) o /turno

Árbol por audiencia

[COMPROBADO] Cinco rutas del encargo L2. No se inventan /entradas, /concierto, /112, /mesa, /chat, /hoy, /fichas.

Confirmación (UI-04) no es ruta extra: es estado de /sala/:slug con slot seleccionado. [DECISIÓN]

3. Navegación

Kiosk público (S-MIN · sin top-nav de marketing)

[DECISIÓN] El kiosk no tiene tabs, no tiene hamburger, no tiene «Conciertos / Entradas / Agenda». Un link «Turno» discreto basta para Lola.

Chrome de turno (S-MIN autenticado)

[DECISIÓN] No hay rail S-SIDE (eso fue PREGÓN). No hay bottom tabs (MATIZ). No hay masthead (MARGEN). El turno es una tabla-horario a pantalla.

Desktop ≥960px: cabecera 64px + matriz 5 filas × 3 columnas.
Mobile ~390px: la matriz se apila por sala (UI-11 slots mobile es del kiosk; el turno en 390 es lista por sala). [DECISIÓN] En 390 no hay hamburger ni tres columnas aplastadas de kanban.

Header contextual

[DECISIÓN] El wordmark en autenticado lleva a /turno (no al kiosk), para no mezclar oficios. El wordmark en público lleva a /.

Login (público; solo oficio)

[DECISIÓN] No hay /registro. No hay «Soy banda». No hay taquilla.

4. Inventario de contenido

5. Taxonomía

Role

[DECISIÓN] No hay BANDA / TAQUILLA / OPERADOR / COLORISTA.

BookingStatus

v1 no tiene CANCELLED como Must. L+1: cancel CONSERJE. [DECISIÓN]

Slot

Orden de filas: 10–12 → 12–14 → 16–18 → 18–20 → 20–22.
No existe 14-16. [DECISIÓN] D13

Kind / Room

SlotStatus (kiosk)

Salas (líneas seed)

[COMPROBADO] Tres salas del encargo. [DECISIÓN]

Horas (líneas seed)

[COMPROBADO] Ocho horas, 8 cogidas / 7 libres, del encargo de seed. Nombres de banda extra = catálogo. [SUPUESTO de catálogo]

6. Modelo mental vs UI

7. Query string y estado

[DECISIÓN] Sin calendario. Solo hoy. L+1: ?day=.

El confirmar no persiste borrador en sessionStorage como Must. Si se sale sin coger, se pierde el nombre. Could L+1: draft local.

/ok/:code no hace GET JWT. El código vive en la URL. Detalle de sala/hora: state del POST si existe. [DECISIÓN] D9 (nombres ajenos no se enumeran por código público hidratado). Could L+1: GET público mínimo { code, roomName, slot } sin listar el resto.

8. Rutas API alineadas a IA

[COMPROBADO] Contrato del encargo. No se documentan entradas, 112 ni PATCH de kanban como Must.

GET /api/me es Could (el login ya devuelve user). Turno puede pintar «Lola Rivas» desde temple_user en storage.

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — TEMPLE

Convenciones

• Actor: Guest (banda/batería anónima) | CONSERJE
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico músico: F-BOOK (kiosk → sala → slot → confirmar → ok)
• Flujo canónico oficio: F-TURNO (login → horario de hoy)
• Taquilla / 112: no tienen flujo de sistema

F0 — Entrada pública (Guest)

/                     →  GET /api/rooms  →  3 salas enormes
/sala/:slug           →  GET /api/rooms/:slug  →  rejilla + confirmar
/ok/:code             →  ticket (sin GET JWT)
/login                →  si hay token válido  →  /turno  (o next)
/turno  sin token     →  /login?next=/turno

Éxito: cara pública = quiosco de salas.
AC: no hay landing, hero 2-col ni taquilla. Kiosk-first.

F1 — Ver salas (Guest) · H-KIOSK

/ → GET /api/rooms
  → 3 salas  |  empty  |  error  |  skeleton

Éxito: 3 salas reales en el fold, o empty accionable.
AC: cada sala muestra nombre + lead + 3 datos + foto. Cero botones Entradas / Concierto.

Guión Iván (demo): toca Sala 2 Combo. [SUPUESTO de catálogo] alineado al seed de doc 05.

F2 — Ver horas (Guest) · F-BOOK

/sala/:slug → GET /api/rooms/:slug
  → 5 bloques free|taken  |  empty  |  error  |  skeleton

Éxito: rejilla de hoy; taken sin nombre de banda.
AC: 5 bloques. Libre = CTA. Cogida = no clicable (o clic = mensaje, no POST).

Guión Iván: Sala 2 · 18–20 libre · 10–12 y 12–14 y 16–18 cogidas. [SUPUESTO de catálogo]

F3 — Confirmar y coger hora (Guest) · F-BOOK

/sala/:slug  (slot seleccionado)
  → bandName
  → POST /api/bookings { roomSlug, slot, bandName }
  → 201 Booking { code, status: CONFIRMED, ... }
  → /ok/:code

Éxito: registro status=CONFIRMED + pantalla ticket.
No hay «Entrada» ni «Escenario» ni pago en v1.

JSON camelCase: bandName, roomSlug. [DECISIÓN]

Errores

[DECISIÓN] Crear siempre como CONFIRMED. Pago fuera (ventanilla). Unique (room_id, day, slot).

[COMPROBADO] Entidad Booking según encargo (code, sala, slot, banda).

F4 — Ticket (Guest)

/ok/:code → muestra código de la URL
          → si hay router state del POST: sala / slot / banda
          → “Hora cogida ≠ concierto. TEMPLE no vende entradas.”
          → “Sala ≠ escenario. Ensayar no es actuar.”
          → CTA coger otra → /

AC: el disclaimer es visible sin scroll en desktop.
No hace GET /api/turno ni lista otras horas. Si se recarga, queda el código + copy; no se inventa la banda. [DECISIÓN] D9.

Código con formato inválido (no TM- + 4 dígitos): mismo ticket genérico; no 404 de producto público.

F5 — Login JWT (CONSERJE)

/login → POST /api/auth/login { email, password }
      → 200 { accessToken, user } → localStorage → /turno  (o ?next sanitizado)
      → 401 → mensaje error en form

Éxito: token guardado; user role=CONSERJE, nombre Lola Rivas.
Credencial demo: lola@temple.nave / password123.

[COMPROBADO] Credencial del encargo.

F6 — Turno horario (CONSERJE) · F-TURNO

/turno (token)
  → GET /api/turno
  → matriz 5×3 (bandName | libre)
  → tablero  |  empty  |  error  |  skeleton

Éxito: 8 cogidas / 7 libres en el seed, o empty.
AC celdas: cada una muestra banda o Libre. Cero botones Entradas / 112 / Kanban. Cero drag-and-drop Must.

Guión Lola (demo): Sala 1 16–18 Marta Chen · Sala 2 18–20 Libre (hasta el POST de Iván) · tras el POST, Los Yesos. [SUPUESTO de catálogo]

[DECISIÓN] GET /api/turno es el Must de producto. No hay PATCH de status. Lola mira, no mueve columnas. Could L+1: cancel.

F7 — Kiosk / slots mobile (Guest) · UI-02 / UI-11

/ ~390
  → 3 salas apiladas (mismas 3, no un carousel de marketing)
/sala/:slug ~390
  → rejilla 1 col o 2 col de bloques
  → confirmar hoja inferior

Misma API que F1–F3. No se aplastan 3 columnas de kanban. [DECISIÓN]

F8 — Logout (CONSERJE)

Turno → Salir → limpia localStorage → /login

No hay pantalla /cuenta Must. [DECISIÓN]

F9 — Health (ops)

GET /api/health → 200 { ok: true, service: "temple-api" }

Sin auth. No es una pantalla. Smoke de arranque.
[COMPROBADO] El contrato de esta suite es temple-api :3021.

Matriz de errores global

Flujos fuera de alcance v1

• Registro / recuperación de password de CONSERJE
• Cuenta de banda / «mis horas» / push
• Entradas / aforo / Conciergo
• 112 / derivación operativa
• Pago en kiosk
• Calendario semanal
• Cancelación / no-show
• Chat
• Kanban
• Rider / backline extra
• Multi-conserje / multi-nave

05-data-model.md

05 — Modelo de datos — TEMPLE

1. Visión general

Dominio L2 de quiosco de horas + turno autenticado:

Base: PostgreSQL (Neon project divine-haze-05909195) · IDs: cuid() o texto estable (usr_lola, rm_1, TM-2101).
[DECISIÓN] ensureSchema o Prisma son válidos si el contrato de tablas se cumple; el brief de stack no exige Prisma.

Contrato de producto: rooms + bookings + JWT CONSERJE. No bandos / reports / clients / formulas.

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

Role

BookingStatus

RoomKind

bateria | combo | seca

Slot

10-12 | 12-14 | 16-18 | 18-20 | 20-22

3. Diagrama ER (texto)

users
  id, email, password_hash, name, role(CONSERJE)
  nave_name
  created_at, updated_at
  1 ──< sessions

sessions
  id, user_id → users
  token_hash, expires_at
  created_at

rooms
  id
  slug (unique)
  name, kind, size_m2, lead
  cover                 -- filename
  sort_order
  created_at, updated_at
  1 ──< bookings

bookings
  id
  code (unique, TM-XXXX)
  room_id → rooms
  day (DATE)
  slot (10-12|…)
  band_name
  status (CONFIRMED)
  created_at, updated_at
  UNIQUE (room_id, day, slot)

v1: una sola CONSERJE opera sobre el conjunto global.
No hay FK de banda-usuaria: la banda no se loguea.
bookings no apunta a users: la hora es anónima de cuenta.

4. Tablas

users

sessions

[DECISIÓN] El JWT viaja en Authorization: Bearer. sessions permite invalidar (logout) sin esperar expiración. Si el slice usa JWT stateless, documentar el hueco; D-P1-05 se cumple igual con guard en turno.

rooms

[DECISIÓN] GET público lista sort_order asc. L+1: salas inactivas.

bookings

UNIQUE (room_id, day, slot).
[DECISIÓN] SQL snake_case (band_name, room_id); JSON camelCase (bandName, roomId).

5. Reglas de integridad y negocio

6. Contratos API (resumen)

JSON camelCase hacia el web. [DECISIÓN]

GET /api/health

Response 200: { "ok": true, "service": "temple-api" }

[COMPROBADO] Contrato del encargo: temple-api.

GET /api/rooms

Público.

Response 200: Room[]

[
  {
    "id": "rm_1",
    "slug": "bateria",
    "name": "Sala 1 Batería",
    "kind": "bateria",
    "sizeM2": 12,
    "lead": "Kit dentro",
    "cover": "bateria.jpg",
    "sortOrder": 1,
    "freeToday": 2,
    "slotsToday": 5
  }
]

Si 0: [] + empty UI-08.

freeToday / slotsToday se calculan para hoy Europe/Madrid. [DECISIÓN]

GET /api/rooms/:slug

Público.

Response 200

{
  "id": "rm_2",
  "slug": "combo",
  "name": "Sala 2 Combo",
  "kind": "combo",
  "sizeM2": 18,
  "lead": "Amp + PA chico",
  "cover": "combo.jpg",
  "day": "2026-08-21",
  "slots": [
    { "slot": "10-12", "status": "taken" },
    { "slot": "12-14", "status": "taken" },
    { "slot": "16-18", "status": "taken" },
    { "slot": "18-20", "status": "free" },
    { "slot": "20-22", "status": "free" }
  ]
}

Sin bandName en slots públicos. Slug inexistente → 404.

POST /api/bookings

Público.

Body

Response 201

{
  "code": "TM-2109",
  "roomSlug": "combo",
  "roomName": "Sala 2 Combo",
  "slot": "18-20",
  "bandName": "Los Yesos",
  "day": "2026-08-21",
  "status": "CONFIRMED",
  "createdAt": "2026-08-21T16:12:00.000Z"
}

DTO inválido → 400. Slot cogido → 409 { "error": "SLOT_TAKEN" }. No JWT.

POST /api/auth/login

Body: { email, password }
Response 200: { accessToken, user: { id, email, name, role, naveName } }
401 credenciales inválidas. Response sin hash.

GET /api/turno (JWT)

Response 200

{
  "day": "2026-08-21",
  "naveName": "TEMPLE · Carabanchel",
  "slots": ["10-12", "12-14", "16-18", "18-20", "20-22"],
  "rooms": [
    {
      "slug": "bateria",
      "name": "Sala 1 Batería",
      "cells": [
        { "slot": "10-12", "status": "taken", "bandName": "Cuarto Aire", "code": "TM-2101" },
        { "slot": "12-14", "status": "free", "bandName": null, "code": null },
        { "slot": "16-18", "status": "taken", "bandName": "Marta Chen", "code": "TM-2104" },
        { "slot": "18-20", "status": "free", "bandName": null, "code": null },
        { "slot": "20-22", "status": "taken", "bandName": "Tres Cables", "code": "TM-2107" }
      ]
    }
  ]
}

Sin token → 401.

GET /api/me (Could)

JWT. { id, email, name, role, naveName }. El login ya trae user; no es Must del encargo.

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

CONSERJE

[COMPROBADO] Credencial del encargo. Nombre de pila es constructo de diseño.

Rooms (3)

Fotos y m² son catálogo demo, no un inventario de nave real. [SUPUESTO de catálogo]

Bookings (8)

Bandas, horas y fotos son catálogo demo, no reservas reales. [SUPUESTO de catálogo]
day seed = hoy al boot (Europe/Madrid), o fecha fija 2026-08-21 si el slice prefiere determinismo. [DECISIÓN] Preferir hoy relativo para que el turno nunca parezca de ayer en demo.

Conteos: 8 CONFIRMED · 7 libres.
Libres de guión: Sala 1 12-14 y 18-20 · Sala 2 18-20 y 20-22 · Sala 3 10-12, 16-18 y 20-22.

Iván / Los Yesos no está en el seed: el POST demo coge Sala 2 18-20 → TM-2109.

Paseo de Yeserías / Carabanchel es atrezzo de mercado. No se afirma catastro ni local existente. [SUPUESTO de catálogo]

8. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — TEMPLE

1. Visión

Stack fijo del cron (D-P0-03). No React/Next/Firebase.
[COMPROBADO] Puerto 3021, Neon, Paper y repo constan en el encargo.

El código se escribe en paralelo a esta suite. Este doc es el contrato, no un inventario de leftover.

2. Estructura

temple-app/
├── apps/api/     # Nest (paquete independiente)
├── apps/web/     # Angular + Tailwind (paquete independiente)
└── package.json  # scripts api / start · apps independientes

D-P1-03: npm --prefix o pnpm --filter. Prohibido npm workspaces que rompen Angular (AP-06).

Scripts raíz esperados:

3. API pública vs JWT

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

[COMPROBADO] Superficie API del encargo. No se añaden Must extra (/me, /entradas, /reports).

4. Justificación

5. Variables

.env local (nunca git):

.env.example solo placeholders.
Web: URL de API en ApiService (default http://localhost:3021/api). Proxy Angular proxy.conf.json → :3021.

6. Dependencias de producto (mínimas)

API

• @nestjs/common / core / platform-express
• JWT (jose o @nestjs/jwt)
• bcrypt (o bcryptjs)
• cliente Postgres (pg / @neondatabase/serverless) o Prisma
• class-validator + class-transformer

Web

• Angular standalone
• Tailwind 3
• fuentes: Fraunces + Atkinson Hyperlegible (Google Fonts o self-host)

7. Arranque (contrato)

cd /Users/cristian/orca/temple-app
# instalar apps independientes (npm --prefix o pnpm --filter)
# apps/api/.env → DATABASE_URL + JWT_SECRET + PORT=3021
# migrate / ensureSchema + seed
# api → http://localhost:3021
# web → http://localhost:4200

8. Lo que este stack no es

9. Nota sobre el repo

[COMPROBADO] Path previsto /Users/cristian/orca/temple-app y remoto Criscode2022/temple-app.
El código se escribe en paralelo. Esta suite define el contrato TEMPLE (rooms + bookings + JWT CONSERJE, health temple-api, puerto 3021). Si el scaffold parte de un día anterior, gana este contrato, no el dominio previo. [DECISIÓN]

07-creative-direction.md

07 — Dirección creativa — TEMPLE

1. Concepto

TEMPLE es un tablero de horas de flight case: se entra al quiosco y se sale con una hora, no una landing de «sala de conciertos». El ground es negro de instrumento. El ámbar es el LED del dial. La joya del ampli sella lo urgente, poco.

Mood elegido: vehicle dashboard.
Primer instinto descartado: nocturnal escenario+neón. Un local de ensayo se opera como un tablero de horas, no como Conciergo.

[COMPROBADO] Mood, ground y paleta salen de docs/00-day-brief.md.

2. Territorio visual

3. Paleta

Jerarquía de color: el ink carga; el amber puntúa; el panel encuadra la sala. Si el amber pinta fondos enteros, deja de ser LED y se vuelve «brand naranja». El jewel no decora el header: solo puntual (error, sello). [DECISIÓN]

4. Tipografía

Prohibido: Fraunces por debajo de 20px (se rompe). Atkinson en el wordmark (se vuelve SaaS).

Fuentes vetadas de la serie y del brief: Ibarra Real Nova / Jost / Libre Baskerville / Nunito / Instrument Serif / Sora / Cormorant / Public Sans / Spectral / Manrope / Zilla / Mulish / Newsreader / Outfit / Lora / Karla.

5. Fotografía

Las imágenes del case son el sistema, no un moodboard:

Crop: salas en 4:3 (cuarto). No recorte 16:9 de escenario ni 1:1 de retrato. [DECISIÓN] 4:3 de sala, distinto del 4:3 de incidente PREGÓN (calle) y del 16:10 editorial.

Tratamiento: saturación real, sin LUT «concert purple», sin haze de humo de escenario. El amber no se superpone como filtro: vive en UI.

hero.jpg vive en UX-00 Cover, no como hero de producto en el kiosk. [DECISIÓN] AP-21: 3 salas reales en el fold.

6. Layout

Kiosk (H-KIOSK)

┌─────────────────────────────────┐
│  TEMPLE · La hora, no el concierto.
│  ┌─────────┬─────────┬─────────┐│
│  │ Sala 1  │ Sala 2  │ Sala 3  ││  3 tiles enormes
│  │ Batería │ Combo   │ Seca    ││
│  │ 3 datos │ 3 datos │ 3 datos ││
│  └─────────┴─────────┴─────────┘│
└─────────────────────────────────┘

1. Wordmark + eslogan (una línea, no portada).
2. Lead en el fold: 3 salas (foto, nombre Fraunces, 3 datos Atkinson).
3. Cada tile es la acción. No hay que cazar un CTA de marca.

No hay portada fotográfica a 60vh. [DECISIÓN]

390: las mismas 3 salas apiladas, no un carousel.

Rejilla (F-BOOK)

Sala 2 Combo
[10–12 cogida] [12–14 cogida] [16–18 cogida]
[18–20 LIBRE ] [20–22 LIBRE ]

Bloque libre: panel + filete amber.
Bloque cogido: panel + mute; no nombre de banda.

Turno (horario)

         Sala 1        Sala 2        Sala 3
10–12    Cuarto Aire   Tres Cables   Libre
12–14    Libre         Cuarto Aire   Papel Fumado
16–18    Marta Chen    Las Cajas     Libre
18–20    Libre         Libre         Eco Bajo
20–22    Tres Cables   Libre         Libre

Cabecera S-MIN: TEMPLE · Hoy · Lola · Salir.
No rail. No columnas Recibido / En curso.

390: una sala debajo de otra, mismas filas de hora.

Ticket

Código Fraunces, sala + bloque Atkinson, disclaimers cream sobre ink. Sin confetti. Sin escenario.

Login

Columna estrecha sobre ink. Dial, no splash de concierto.

7. Motion

Prohibido: parallax de escenario, scroll-jacking, page transitions de 400ms, neón parpadeante, animación de público aplaudiendo al coger (mentiría concierto).

8. Anti-clichés (serie ALS-2)

9. Tono de marca (visual + verbal, puente a doc 09)

Cercano de pasillo y de mesa. Tuteo en UI al músico. Segunda persona cuando habla la interfaz. Tercera cuando habla el turno (Marta Chen ocupa…).

El producto se coge y se mira en un horario. No vende entradas, no es escenario, no es 112, no es kanban.

10. Criterios de aceptación creativos

1. Ground de página = #12110F. Cards = #1E1C18. Nunca al revés.
2. Amber en el CTA Coger y en el bloque libre, no un header naranja lleno.
3. 3 salas visibles en el primer viewport (lead + 3 datos).
4. Ninguna fuente de la lista vetada. Fraunces + Atkinson Hyperlegible.
5. Home reconocible como quiosco de salas, no como hero 2-col de concierto.
6. Success no celebra un «ya estáis en el escenario» ni una entrada.
7. Jewel solo en error / sello, no en el chrome.
8. Turno = horario. Cero columnas Recibido / En curso.

08-design-system.md

08 — Design system — TEMPLE

1. Tokens

--color-ink:    #12110F;   /* G-INK ground */
--color-panel:  #1E1C18;   /* cards / dial / celda */
--color-cream:  #F4EBD0;   /* texto, wordmark */
--color-amber:  #E8A317;   /* LED / gaffer */
--color-mute:   #8C8474;   /* meta */
--color-jewel:  #C23B22;   /* urgente, poco */

--font-display: "Fraunces", "Iowan Old Style", serif;
--font-ui:      "Atkinson Hyperlegible", system-ui, sans-serif;

--radius-card: 4px;          /* dial, no pill de SaaS */
--radius-cta:  4px;
--rule-led:    2px solid var(--color-amber);
--space:       4 / 8 / 12 / 16 / 24 / 32 / 48 / 64;

Tailwind (referencia):

[COMPROBADO] Hex y tipo = brief.

2. Escala tipográfica

3. Componentes

RoomTile (H-KIOSK)

Lead + 3 datos visibles sin hover. [DECISIÓN] AP-21.

SlotGrid (F-BOOK)

┌──────────────┐
│ 18–20        │  Fraunces/Atkinson 16
│ Libre        │  amber si free; mute si taken
└──────────────┘

• Libre: filete amber 2px, texto cream, CTA implícito.
• Cogida: panel, texto mute, aria-disabled, sin nombre de banda.
• Target ≥44 (mejor ≥56 en kiosk de pasillo).
• 5 celdas en orden de slot.

ConfirmSheet (UI-04)

Ticket (UI-05)

Código display-l, sala + bloque body, 4 disclaimers, CTA secondary Coger otra.

Login

Columna max 400 sobre ink. Inputs panel, rule mute, foco outline 2px amber offset 2.

TurnoMatrix (UI-07)

No es un kanban. No hay chips Recibido / En curso. [DECISIÓN]

Botones

Pending: disabled + aria-busy. No spinner de marca.

Contraste primary: amber #E8A317 + texto ink #12110F (no texto blanco sobre ámbar). [DECISIÓN]

Form

Labels visibles (no placeholder-only). Inputs h-44, radius 4, rule mute 50%, foco outline 2px amber offset 2. Fondo panel, texto cream.

Estados

4. Grid y breakpoints

Padding horizontal: 24 desktop, 16 mobile.

5. Iconografía

Mínima. El quiosco no es un set de iconos outline de guitarra.

Si hace falta un icono (salir, error): trazo 1.5, 20px, cream. No pack Remix/Lucide a color.

6. Elevación y borde

Cero sombras shadow-lg. El flight case no flota.

7. Mapa componente → ruta

8. Criterios de aceptación DS

1. Tokens Tailwind = hex del brief, sin fog PREGÓN #F1F3F6 como ground.
2. Cards en panel; página en ink.
3. Primary CTA amber + texto ink (nunca mute sobre ink como único CTA).
4. Fraunces no aparece en labels de form ni en meta 12px.
5. Recorte de sala aspect-[4/3], no 16:9 de escenario.
6. Targets de tiles, slots y CTA ≥44px (slots kiosk ≥56 preferible).
7. 3 datos de sala visibles sin hover.
8. Fuentes: Fraunces + Atkinson Hyperlegible. Cero Ibarra / Jost leftover.

09-content-guide.md

09 — Guía de contenido — TEMPLE

1. Voz

Cercana de pasillo y de mesa. Tuteo en UI al músico. Segunda persona cuando la interfaz habla. Tercera cuando habla el turno (Marta Chen ocupa…).

Sin jerga de concierto («esta noche en cartel», «tu público te espera», «compra tu entrada»). Sin taquilla. Sin «reserva tu slot» de Booksy. Sin sirena. Sin kanban en UI.

El producto se coge y se mira en un horario. No vende entradas, no es escenario, no es 112, no es chat.

2. Palabras permitidas / prohibidas

«Kanban» y «F-BOOK» son lenguaje de diseño, no de UI: Iván no lee «booking»; Lola lee Libre / cogida y nombres.

«Ticket» en UI es el acuse de hora. Si hay ambigüedad, preferir código o hora cogida. [DECISIÓN]

3. Microcopy duro (literales irrenunciables)

El brief fija oposiciones. Aparecen donde el usuario puede confundirse.

[DECISIÓN] Los cuatro textos son obligatorios en UI. No se diluyen a un tooltip.
Pie de kiosk puede condensar dos en dos líneas; ticket muestra los cuatro.

4. Microcopy por superficie

5. Salas y horas seed (tono)

Las salas demo se escriben como cuarto de ensayo, no como ficha de concierto ni como anuncio.

No inventar declaraciones de músicos reales. Si hay una voz, es de persona de diseño etiquetada.

En CONFIRMED no se reescribe a «ya estáis en el escenario». El cierre es la hora cogida. [DECISIÓN]

6. Nombres propios del seed

No inventar CIF de nave, teléfono de taquilla, ni cartelera real como si fuera el producto. [SUPUESTO de catálogo demo]
Paseo de Yeserías / Carabanchel son topónimos reconocibles, no un inventario oficial de un local 2026.

7. Tono por estado

La app no envía esos mensajes a la banda en v1. El copy solo prepara el habla. No hay email de «ya tenéis escenario».

8. Capitalización y números

• Wordmark: TEMPLE en versales Fraunces (sin tilde).
• Código: TM-2109 (TM versales, guion, 4 dígitos).
• Nombres: Iván Mora, Lola Rivas, Marta Chen.
• Salas: Sala 1 Batería (mayúscula de Sala + kind).
• Bloques: 10–12 en UI (en-dash); 10-12 en API.
• Fecha: 21 ago en cabecera de turno; viernes 21 de agosto si hay línea larga.
• No mezclar tm-2109 en minúsculas en UI. API puede normalizar a versales.

9. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar «booking» en UI. En API sí: bookings, slot, bandName, status.

«Banda» en UI cuando hablamos de Iván; «batería» para Marta; «el músico» genérico en copy de sistema. [DECISIÓN]

10. Accesibilidad de copy

• No transmitir estado solo con color (el amber no «significa» libre él solo).
• Celdas llevan texto: Libre / Cogida / nombre de banda.
• Aviso de no-entradas lleva palabras, no solo el jewel.
• Alt de fotos: sala + kind, no «imagen1».
  • hero: «Nave de ensayo y flight case; tablero de horas, no escenario.»
  • bateria: «Sala de batería con kit; cuarto de ensayo.»
  • combo: «Sala combo con ampli y PA chico.»
  • seca: «Sala seca, sin batería.»

11. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad — TEMPLE

Objetivo: WCAG 2.2 AA. No se declara conformidad legal certificada.
Este documento cubre la UI (kiosk, horas, ticket, login, turno). No audita la accesibilidad física de la nave, del pasillo ni de las salas. [SUPUESTO]

1. Decisiones

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

3. Teclado

• Enter en tile = navegar a sala.
• Enter en slot libre = abre confirmar.
• Enter en slot cogido = no POST; anuncia «Cogida».
• Escape cierra confirmar (vuelve a rejilla) si el confirmar está abierto.
• Focus trap: no hay modal Must; la hoja 390 no trampa si hay ← Salas.
• En 390, la hoja no debe robar el foco al cargar la rejilla.

4. Semántica

5. Lector de pantalla — copy

6. Producto vs nave física

[DECISIÓN] v1 no incluye auditoría a11y de la nave. bandName es dato de hora demo, no un certificado de identidad.

7. Riesgos

8. QA a11y (mínimo)

9. Criterios de aceptación

1. Ningún control de tile, slot o CTA mide menos de 44×44 CSS px.
2. El disclaimer no depende del color amber o jewel para ser entendido.
3. Las 3 fotos de sala + hero tienen alt no vacío y no genérico.
4. El foco no se pierde al reintentar un error de red o un 409.
5. En 390 las 3 salas son alcanzables sin un carousel de marketing.
6. Un turno no se anuncia en / sin token (no hay HTML público de nombres ajenos).
7. Iván puede completar coger hora solo con teclado y sin cuenta.

11-privacy-security.md

11 — Privacidad y seguridad — TEMPLE

1. Datos que existen

No se pide cuenta a la banda. No hay DNI, email ni teléfono de Iván en producto. No hay tracking de menores. Las fotos seed no se presentan como un local real.

2. Minimización

bandName es dato de hora demo, no un requisito de identidad legal. L+1 podría hacerlo opcional. [DECISIÓN]

3. Seguridad L2

No se declara cumplimiento RGPD definitivo. Sí: minimización, turno JWT y derecho a borrar la cuenta de conserje (manual L2). Las horas seed se tratan como datos de demo, no como encargo de tratamiento de una nave real.

4. Superficies de riesgo

5. Roles y autorización (recordatorio)

Iván, Marta y la dueña no tienen fila en users.

6. Criterios de aceptación

1. Response de login no incluye password ni password_hash.
2. GET /api/turno sin Bearer es 401, no 200 con nombres.
3. POST /api/bookings sin Bearer es 201 (público) o 409.
4. GET /api/rooms y GET /api/rooms/combo sin Bearer son 200.
5. GET /api/rooms/:slug no incluye bandName en slots.
6. No hay formulario público que pida DNI, email o teléfono.
7. /turno sin token redirige a /login (no renderiza nombres en HTML anónimo).
8. /ok/:code no llama a GET JWT.
9. .env no se commitea.
10. Health no filtra datos: { ok: true, service: "temple-api" }.

12-analytics.md

12 — Analítica — TEMPLE

North star: % de bloques ocupados sin WhatsApp (booking_create / capacidad 15 de hoy, ligado a kiosk — no a un mensaje de grupo).

Instrumentación modelo. No hay proveedor conectado en v1 salvo que el build añada un logger local. [DECISIÓN] No se inventan cifras de conversión.

1. Eventos

2. Qué no se mide

Hipótesis H2: ok_view sin entrada_claim (el copy contradice). Si en un test de 5 músicos alguien dice «ya tengo entrada», se anota en research futuro, no como KPI inventado.

3. Funnel modelo

Banda:     kiosk_view  →  room_open  →  slot_select  →  booking_create  →  ok_view
Conserje:  conserje_login  →  turno_view

Activación banda = primer booking_create.
Activación turno = primer turno_view con token.
North star de sesión de demo: de los 15 bloques del día, cuántos se ocupan desde el kiosk (seed + POSTs), no desde un WhatsApp fuera de producto.

El seed no cuenta como conversión de kiosk. [DECISIÓN]

4. Integridad (producto, no vanidad)

5. Privacidad de analítica

Sin PII extra. code es identificador de hora (TM-2109), no un email. bandName no se envía a un tercero. Ver doc 11.

6. Criterios de aceptación (si se instrumenta)

1. Los eventos de §1 tienen nombre estable.
2. No se dispara ningún evento de lead / entrada / 112-como-conversión / kanban / concierto.
3. Un bloqueador de cookies no rompe el kiosk (analítica no es Must de runtime).
4. slug y slot se miden; bandName no.

13-qa-test-plan.md

13 — Plan de pruebas — TEMPLE

1. Smoke obligatorio (D-P1-06)

[COMPROBADO] Smoke = health (temple-api) + rooms públicos + login JWT + turno 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 (kiosk 3 salas, ticket con disclaimer, horario, ausencia de signup de banda, 401 turno, 409 unique).

6. Criterios de salida QA v1

• Smoke §1 en verde (incluido temple-api).
• S2, S5, S7, S9, S10, S17, S22, S26, S28, S29 en verde.
• Cero blockers de copy deshonesto (entrada / escenario-como-hecho / 112-como-envío / kanban).
• Sin .env en el repo.

7. Fuera de este plan

Playwright e2e completo, carga, fuzzing, auditoría de una nave real.

14-dev-handoff.md

14 — Handoff desarrollo — TEMPLE

1. Arranque

cd /Users/cristian/orca/temple-app

# apps independientes (npm --prefix o pnpm --filter)
# apps/api/.env
#   DATABASE_URL=  # Neon divine-haze-05909195
#   JWT_SECRET=
#   PORT=3021

# migrate / ensureSchema + seed
# api → http://localhost:3021
# web → http://localhost:4200

Demo: lola@temple.nave / password123.

El código se escribe en paralelo. Este handoff es el contrato.

2. Paridad Paper

No clonar PREGÓN (chat + kanban + rail), MATIZ (Hoy bento + editor + bottom tabs), ZAGUÁN (wizard + comparador), MARGEN (lookbook + masthead) ni Conciergo (taquilla).

Paper se construye en paralelo; los nombres de artboard son el inventario planificado (doc 00).

3. Contratos

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

4. Mapa de rutas web

Guard: si no hay token, /login?next=. La API es la autoridad para turno.

[COMPROBADO] Solo estas rutas. No implementar /mesa, /chat, /entradas, /concierto, /112.

5. Assets

Copiar desde el case:

2026-08-21-temple/assets/hero.jpg
2026-08-21-temple/assets/salas/bateria.jpg
2026-08-21-temple/assets/salas/combo.jpg
2026-08-21-temple/assets/salas/seca.jpg
  → apps/web/public/assets/salas/   (hero a public/assets/)

cover del seed = filename (bateria.jpg, …).

6. DoD implementación L2

7. No hacer

15-roadmap.md

15 — Roadmap — TEMPLE

Este documento no es un cajón de trabajo L2 a medias.
El vertical slice L2 del brief está especificado como done-scope (docs 01, 18, 19).
Aquí solo viven ideas de L+1 / L3 y pulido posterior.

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 temple-app, en paralelo a esta suite. El alcance L2 ya está cerrado en spec.

Eso no se reabre aquí como «próximo trimestre de producto».

3. L+1 (misma familia, subida de pulido)

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 L+1.

4. L3 (requiere brief nuevo de diversidad)

• Multi-conserje / multi-nave
• Cuenta de banda y «mis horas»
• Calendario semanal / mes
• Pago / TPV / pasarela
• Entradas / taquilla / Conciergo
• Rider / backline extra
• Chat / kanban
• Integración 112

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 (build paralelo)
2. Web paridad UI-00…11
3. Ticket público mínimo + rate limit (L+1)
4. Cancel CONSERJE si hay campo
5. Evaluar brief L3 (no parche silencioso)

16-interaction-specs.md

16 — Especificación de interacción — TEMPLE

1. Convenciones

Loading (skeleton de UI-10) y slots mobile (UI-11) viven en este doc junto a los gestos; el inventario Paper ya reserva UI-10 y UI-11. [DECISIÓN]

2. Kiosk home (UI-01) + mobile (UI-02) · H-KIOSK

AC: nombre, lead y 3 datos visibles sin hover. 3 salas en el fold (AP-21). Cero botones Entradas / Concierto / Crear cuenta.

El aviso «TEMPLE no vende entradas» es texto, no un CTA de compra. [DECISIÓN]

390: mismas 3 salas apiladas. No carousel. [DECISIÓN]

3. Rejilla de horas (UI-03) + mobile (UI-11)

AC: Libre / Cogida en texto. Taken sin nombre de banda. 5 bloques en orden.

390: 1 o 2 columnas de bloques, no 5 aplastadas. [DECISIÓN]

4. Confirmar (UI-04)

Submit deshabilitado si nombre < 2 o no hay slot.

[DECISIÓN] Un solo botón primario: Coger hora. No existe «Comprar entrada» ni «Pagar ahora».

390: hoja inferior, CTA full-width h-44. Teclado iOS: scroll-margin en el campo. Safe-area inferior.

Desktop 1440: panel junto a la rejilla o debajo, CTA min 200px no full-bleed de viewport.

5. Success / ticket (UI-05)

Sin confetti. Sin público. Sin «cobrar». Sin escenario que se ilumina.

6. Login (UI-06)

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

Login no muestra matriz.

7. Turno horario (UI-07)

AC: banda o Libre visibles sin hover. Cero botones Entradas / 112 / Recibido.

8. Empty (UI-08) · Error (UI-09) · Loading (UI-10)

9. Cabecera S-MIN

10. Motion

Prohibido: scroll-jacking, page transitions de 400ms, parallax de escenario, neón parpadeante, público que aplaude al coger, confetti de «entrada».

11. Criterios de aceptación de interacción

1. Un músico en 390px llega de abrir / a ver un código en ≤ 3 taps útiles (sala → hora → Coger).
2. Ningún submit permite doble POST.
3. Reduced-motion elimina stagger y slide.
4. La home no es hero 2-col (AP-12).
5. En 390 las 3 salas son visibles sin carousel de marca (AP-21).
6. / no presenta ningún control de cuenta, entradas o kanban.
7. El loading de kiosk es skeleton de 3 tiles, no un logo de concierto.
8. El ticket muestra «hora ≠ concierto» y «no vende entradas» sin scroll en desktop.
9. Lola en 1440 lee Marta Chen en Sala 1 16–18 sin abrir una ficha.
10. Un 409 refresca la rejilla y no navega a /ok.
11. Manos en el pasillo: cero gestos que exijan hover o swipe horizontal como único camino.
12. Confirmación Escape / cancelar no POST.

17-prototype-map.md

17 — Mapa de prototipo — TEMPLE

Paper no es clicable vía MCP. El prototipo vivo es la app Angular.
Los artboards de Paper se construyen en paralelo; esta tabla es el contrato de paridad.

Proceso: UX-00…UX-11. Tokens: UI-00.

Empty, error y loading se prototipan como estados / variantes de UI-01 / UI-03 / UI-07 además de sus boards propios. Ver doc 16.

Recorrido demo (guión)

1. Abrir / sin token — kiosk público. Leer eslogan La hora, no el concierto. Leer 3 salas (Batería, Combo, Seca) con lead + 3 datos.
2. Tocar Sala 2 Combo. Ver rejilla: 10–12 / 12–14 / 16–18 cogidas; 18–20 y 20–22 libres. Sin nombres de otras bandas.
3. Tocar 18–20. Confirmar: nombre Los Yesos. Leer «Hora cogida no es concierto» y «se paga en ventanilla».
4. Coger hora → /ok/TM-XXXX — «Hora cogida no es concierto. TEMPLE no vende entradas.» «Sala ≠ escenario. Ensayar no es actuar.»
5. Ghost Turno → /login. Entrar lola@temple.nave / password123.
6. /turno — horario 5×3. Sala 1 16–18 Marta Chen. Sala 2 18–20 Los Yesos (tras el POST).
7. Comprobar que no hay botón Entradas, 112-como-envío ni columnas Recibido / En curso.
8. Viewport 390: kiosk 3 salas apiladas; rejilla; turno apilado por sala.
9. Salir → /login. / sigue siendo el kiosk.
10. (Opcional) POST otra vez Combo 18–20 → 409.

Estados en el mismo prototipo

Fuera del prototipo clicable

• Paper artboards son estáticos.
• Llaves físicas y cobro en ventanilla (fuera).
• 112 / taquilla / Conciergo.
• Chat / kanban.
• Cuenta de banda.
• Calendario semanal.
• El dominio de un día anterior no forma parte del prototipo TEMPLE: si aparece chat, mesa o kanban, es desalineación.

18-completeness-audit.md

18 — Auditoría de completitud — TEMPLE (2026-08-21)

1. Alcance auditado

Vertical slice L2: quiosco de horas de ensayo + tablero CONSERJE JWT (horario de ocupación, no kanban), con docs, referencia Paper, contratos Angular + Nest + Neon.

Este encargo cubre la suite documental. El day brief y el paper-reference no se han sobrescrito. El código se escribe en paralelo (/Users/cristian/orca/temple-app).

2. Checklist CRON / ALS-2

3. Cobertura funcional

4. Cobertura Paper (literales)

[COMPROBADO] UX-count: 12 y UI-count: 12 literales en docs/00-paper-reference.md (no sobrescrito). Gate check-paper-reference.mjs aplica.

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

6. Huecos conscientes (no deuda del L2 del día)

7. Cierre documental

La suite ALS de TEMPLE (README + executive + docs 01–20) cubre el vertical slice L2 del brief. docs/00-day-brief.md y docs/00-paper-reference.md permanecen intactos.

19-backlog-completo.md

19 — Backlog completo — TEMPLE

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-21)

Los must-have del brief (kiosk, horas, confirmar, ticket, login, turno, empty/error/loading, mobile, ≥12 UX + ≥10 UI) están dentro de D01–D25, no como leftover.

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

Alineación de código al contrato ya cerrado. Se escribe en paralelo. No es alcance documental pendiente.

3. Backlog L+1 (polish)