00-day-brief.md

00 — Day brief · 2026-08-27 · PIÑÓN

Decisiones ALS-2 BRIEF

Terna unicidad

R-HY · S-TOP · H-BENTO · F-CMP

0 códigos iguales a N−1 (BOBINA: R-IN · S-DOCK · H-FEED · F-STORY).
≥2 distintos vs N−2 (LOMO: S-CMD · H-DATA · F-LEAD) y N−3 (ONDA: S-RAIL · H-GALLERY · F-SEARCH).

S-TOP, H-BENTO y F-CMP no están en los últimos 5.
R-HY cumple la mezcla de 4 días (BOBINA R-IN, LOMO R-CL, ONDA R-HY).

Ground (CRON §5.6)

• Familia: G-GRAPHITE
• Hex: #2C3033
• Por qué: suelo de nave y esmalte de cuadro, no terciopelo (BOBINA), no caliza (LOMO), no cartel blanco (ONDA), no hielo (RAMAL), no tinta de flight case (TEMPLE).

Mood visual (Paper)

• Candidatos: nocturnal/fixie neón (primer instinto taller cool), industrial, rusted, arid, botanical
• Elegido: industrial — no el primer instinto Rapha/neón. Un taller de Legazpi se lee con esmalte, hormigón y naranja de reflector, no con LED de tienda de fixies.
• Paleta:
  • #2C3033 grafito de nave (ground)
  • #F3F1EC ficha / cream
  • #1A1C1B card oscura
  • #E24A17 naranja de reflector (mark)
  • #8B8E8A mute
  • #C5C8C4 cromo (poco)
• Tipo: Spectral display · Sora UI

Home foto-led (D-P1-09)

UI-01 = Deriva en bento: tile de la nave a sangre (≥40 % del recorte 16/10) + lead + 3 datos (en taller / listas / esperan) + 4 bicis. No feed. No H-DATA tabla. Cuota last 6: BOBINA+LOMO = 2 → PIÑÓN es el 3º.

Alcance L2 must

1. Home bento foto-led: 4 bicis + 3 métricas
2. Configurador de arreglo (F-CMP)
3. Dejar la bici (nombre, teléfono, color del cuadro)
4. Success con código de encargo
5. Login JWT MECÁNICO
6. Mesa de ganchos (EN_TALLER / LISTA / ESPERA) — no kanban
7. Empty / error / loading / mobile bento
8. ≥12 UX + ≥10 UI

Microcopy duro

• Dejar la bici ≠ comprar el taller. No se vende una bici nueva.
• Encargo ≠ cita de fitness. No reserva una clase.
• Recoger ≠ alquilar. No es un bike-share.
• PIÑÓN no es Decathlon.

Supuestos

• S1: El taller atiende 2–4 bicis/día en el slice; demo 4. [SUPUESTO]
• S2: El vecino deja la bici sin cuenta. JWT solo MECÁNICO. [SUPUESTO]
• S3: Repartidor y dueño de la nave fuera del producto. [SUPUESTO]
• S4: Sin e-commerce, sin GPS, sin chat, sin kanban. [DECISIÓN]

Hipótesis

Seed demo

Modelos son catálogo demo. No es un taller real ni un acuerdo con Orbea. [SUPUESTO de taller]

JWT

nuria@pinon.taller / password123 · rol MECANICO · API :3027

00-paper-reference.md

Paper reference · PIÑÓN

UX-count: 12 UI-count: 12

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

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

Media

• assets/hero.jpg
• assets/bicis/orbea.jpg
• assets/bicis/bh.jpg
• assets/bicis/fold.jpg
• assets/bicis/trek.jpg

01-project-definition.md

01 — Definición de proyecto — PIÑÓN

1. Identidad

[COMPROBADO] Nombre, terna, nivel, sector, ground y paleta salen de docs/00-day-brief.md.
[SUPUESTO de taller] Arganzuela / Legazpi / Orbea / BH / Trek es atrezzo de mercado, no un taller real ni un acuerdo de marca.

Tras BOBINA (L1 cineclub, 2026-08-26) el día elige L2 taller, no otro L1 consecutivo. N−1 es BOBINA. [DECISIÓN]

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] El vecino de Legazpi no necesita comprar una bici nueva ni reservar una clase: necesita dejar la suya y saber si está lista sin preguntar por WhatsApp. Hoy eso vive en un recado al mostrador, un grupo del barrio y una expectativa de «tienda». Dejar la bici se lee como comprar el taller; el encargo se lee como cita de fitness; recoger se lee como alquilar; el producto se lee como Decathlon. [SUPUESTO] Un taller de barrio atiende 2–4 bicis/día; no opera un lineal ni un GPS de flota.

Secundarios

Supuestos (no investigación primaria propia)

• S1: El taller atiende 2–4 bicis/día en el slice; demo 4. [SUPUESTO]
• S2: El vecino deja la bici sin cuenta. JWT solo MECÁNICO. [SUPUESTO]
• S3: Repartidor y dueño de la nave fuera del producto. [SUPUESTO]
• S4: Sin e-commerce, sin GPS, sin chat, sin kanban. [DECISIÓN]

Hipótesis de producto

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

3. Propuesta de valor

No es PIÑÓN

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L2 taller de barrio con Bike + Request + JWT MECÁNICO.
• Portfolio coherente: Paper (12 UX + 12 UI) + docs + app runnable.
• Terna R-HY · S-TOP · H-BENTO · F-CMP frente a BOBINA (dock/feed/story), LOMO (cmd/datos/lead) y ONDA (rail/galería/archivo).
• No encadenar otro L1 tras BOBINA. [DECISIÓN]

Usuario

No objetivos v1 (explícitos)

• E-commerce, precio, pago, lineal de bicis nuevas
• GPS, tracking, flota, última milla
• Cita de fitness, slot, coach, plaza
• Alquiler, bike-share, candado conectado
• Chat, kanban, columnas Recibido / En curso
• Cuenta de vecino, socio, newsletter
• Multi-nave, multi-mecánico
• App nativa ni notificaciones push
• Rol repartidor / dueño autenticado
• Sesiones, butacas, PROGRAMADOR (BOBINA es otro día)
• Ejemplares, BIBLIO, comando (LOMO es otro día)
• Programas, repeticiones, CONDUCTOR (ONDA es otro día)
• Fórmulas, COLORISTA, editor de gramos (MATIZ es otro día)

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: MECÁNICO. El vecino no es un usuario del sistema: es autor/autora de un request. Amparo 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 bento foto-led Deriva (tile de nave a sangre ≥40 % del recorte 16/10 + lead + 3 datos + 4 bicis). No pide cuenta. No es un hero 2-col + 3 cards. No es un feed. No es una mesa de datos.
2. Un vecino puede ver 4 bicis, configurar un arreglo, dejar la bici y obtener success en /ok/PIN-XXXX.
3. /ok/:code dice explícitamente que dejar la bici no es comprar el taller y que encargo no es cita de fitness.
4. La UI dice explícitamente que recoger no es alquilar y que PIÑÓN no es Decathlon.
5. Sin token, GET /api/mesa responde 401. POST /api/encargos y GET /api/bicis son públicos.
6. Un POST de encargo no crea user, no cobra, no abre un lineal, no mueve kanban, no enciende GPS.
7. Un MECÁNICO inicia sesión y ve 4 bicis (2 EN_TALLER, 1 LISTA, 1 ESPERA) en el seed.
8. El tablero autenticado es una mesa de ganchos. No es un kanban de 3 columnas. No es un split lista | ficha.
9. Fotos reales en las cubiertas seed (assets bicis/*).
10. Chrome S-TOP: Taller · Encargo · Mesa. Home sin dock de cineclub y sin comando de archivo.
11. Rutas solo las del doc 03. No existen /buscar, /sesion, /pedir, /lomo, /cita, /tienda.
12. GET /api/health devuelve service: "pinon-api" (no bobina-api, no lomo-api).
13. El bento público no muestra teléfonos de otros vecinos; la mesa MECÁNICO sí muestra encargos con nombre y teléfono.
14. PIN-2702 aparece LISTA; PIN-2704 aparece ESPERA; no se vende ninguna.

9. Stack y artefactos

[COMPROBADO] Puerto, Paper file ID y path de app constan en el encargo.
El código vive en pinon-app con este contrato. Este doc es la fuente de verdad del slice L2.

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-TOP · H-BENTO · F-CMP. 0 códigos iguales a N−1 (BOBINA). ≥2 distintos vs N−2 (LOMO) y N−3 (ONDA). S-TOP, H-BENTO y F-CMP no están en los últimos 5. Ground G-GRAPHITE #2C3033, no G-VELVET ni G-STONE.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — PIÑÓN

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 talleres de barrio (mostrador, gancho, recado de «¿está lista?», 2–4 bicis al día, mecánica que opera la nave, dueño y reparto fuera del producto día 1).
• Analogía operativa con superficie pública + panel JWT de la serie daily.
• Restricciones ALS-2: no Decathlon, no cita de fitness, no alquiler, no flota GPS, no cineclub, no archivo, no editor de gramos.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: el taller (quién cuelga las bicis) y, en uso diario, Nuria (quien mira ganchos).
• Usuario frecuente de dejar bici: VECINO (bento + configurador + form, sin cuenta).
• Usuario frecuente de oficio: MECÁNICO (mesa /mesa).
• Riesgo de rechazo: si el success parece un ticket de tienda; si el tile parece un SKU de Decathlon; si hay que crear cuenta; si la mesa parece un kanban; si el encargo parece una cita.

4. Personas

P1 — Nuria Vega · MECÁNICO

Escenario: Entra a /login, abre /mesa, lee PIN-2702 BH paseo LISTA, ve los encargos. El copy dice que recoger no es alquilar.

[COMPROBADO] Nombre de cuenta, email demo y rol salen del encargo. Edad y apellido son constructo de diseño. [DECISIÓN]

P2 — Pablo Mora · VECINO

Escenario: Abre / en el móvil, ve 4 ganchos, toca Encargo, elige frenos, escribe nombre y teléfono y color, lee «dejar la bici ≠ comprar el taller» y el código PIN-XXXX.

[COMPROBADO] El gesto (vecino, deja sin cuenta) sale del encargo. Nombre y edad son constructo de diseño. [DECISIÓN]
Pablo no tiene fila en users. [DECISIÓN]

P3 — Amparo Díaz · VECINA MAYOR (docs / a11y)

[DECISIÓN] no hay cuenta de Amparo en v1; a11y la contempla en docs 10. Nombre y edad son constructo de diseño.

5. JTBD

Job principal (vecino)

Cuando la bici falla (rueda, frenos, cadena o toca revisión), quiero configurar el arreglo y dejarla en el taller sin preguntar por WhatsApp, para que Nuria la cuelgue sin que eso signifique compra, cuenta, cita ni alquiler.

Job principal (mecánica)

Cuando hay ganchos ocupados y encargos nuevos, quiero ver ESPERA / EN_TALLER / LISTA, para mover el oficio del taller sin un kanban ni un lineal.

Jobs que PIÑÓN no hace

6. Stories Must (v1)

Could (fuera de L2, solo L3): GPS, e-commerce, login de Amparo, pago, chat, cuenta de vecino.

7. Journey (resumen)

1. Pablo abre /. Ve tile de nave a sangre + 3 datos (en taller / listas / esperan) + 4 bicis. PIN-2702 LISTA; PIN-2704 ESPERA. [H1]
2. Toca Encargo → /encargo. Elige Frenos. [H2]
3. Paso 2: escribe «Pablo Mora», teléfono, color del cuadro. POST → /ok/PIN-XXXX. Lee las cuatro oposiciones.
4. Nuria entra a /login → /mesa. Ganchos por estado + encargos.
5. Lee PIN-2702 LISTA y el encargo nuevo de Pablo en ESPERA. Copy: recoger no es alquilar.

Backstage: Nest + Neon + JWT. Repartidor y dueño no entran. No hay Decathlon. No hay GPS.

8. Blueprint (resumen)

9. Matriz hallazgo → requisito → feature

10. Preguntas que este case no responde

• ¿Cuántas bicis reales se dejan en Legazpi en 2026?
• ¿Qué taller opera un acuerdo con Orbea?
• ¿Pablo preferiría el WhatsApp?
• ¿Amparo necesita un modo tipográfico mayor permanente?
• ¿Nuria marcaría LISTA antes de las 19:00 de verdad?

Esas preguntas piden campo. Aquí hay un vertical slice de diseño, no un estudio.

11. Cierre

Investigación = modelado etiquetado + restricciones ALS-2.
No hay entrevistas inventadas.
Paper UX-00…11 documenta el mismo arco. [COMPROBADO] inventario en 00-paper-reference.md.

03-information-architecture.md

03 — Arquitectura de información — PIÑÓN

1. Principios de IA

2. Sitemap

/                                      Taller bento público (Deriva)                   H-BENTO
/encargo                               Configurador + dejar bici                       F-CMP · público
/ok/:code                              Success post-encargo                            público
/login                                 Login JWT MECÁNICO                              público
/mesa                                  Ganchos ESPERA / EN_TALLER / LISTA              auth
/**                                    → redirect /

Árbol por audiencia

[COMPROBADO] Cinco rutas del encargo L2. No se inventan /buscar, /sesion, /pedir, /lomo, /cita, /tienda, /gps.

El configurador sí es ruta (/encargo): F-CMP necesita URL compartible y un paso antes del POST. [DECISIÓN]
Dejar bici no es ruta extra: es el paso 2 de /encargo (UI-03). L2 compacto. [DECISIÓN]
/ok/:code usa el código de bici (PIN-2705), no un código de petición distinto. [DECISIÓN]
No hay /buscar: no hay S-CMD. El hallazgo es el bento. [DECISIÓN]
No hay /bici/:code de ficha pública: el oficio de estado vive en el bento y en la mesa. Could L3. [DECISIÓN]

3. Navegación

Top (S-TOP · todas las superficies salvo login/ok pueden mostrarlo)

[DECISIÓN] El top es la navegación primaria. No hay dock (BOBINA), no hay comando (LOMO), no hay rail (ONDA), no hay bottom tabs (MATIZ), no hay wizard chrome (ZAGUÁN).

Desktop ≥960px: barra superior fija grafito; wordmark PIÑÓN a la izquierda; slots a la derecha.
Mobile ~390px: top compacto Taller · Encargo · Mesa; no hamburger. [DECISIÓN] En 390 el top no se esconde detrás de un menú.

Taller público (H-BENTO Deriva)

[DECISIÓN] El taller no tiene tabs de marketing, no tiene «Tienda / Clases / Alquiler». El bento basta para hallar.

Chrome de encargo (F-CMP)

[DECISIÓN] El paso 2 no se alcanza sin job elegido. No hay wizard de criterios tipo ZAGUÁN (zona / presupuesto / musts). Hay dos gestos de oficio: qué se arregla, quién deja la bici.

Chrome de mesa (/mesa autenticado)

[DECISIÓN] No hay S-SPLIT (RAMAL). No hay kanban (PREGÓN). No hay /mesa/:code: L2 lee ganchos + encargos. ENTREGADA no se lista en mesa v1.

4. Etiquetas de IA (UI)

En docs puede decirse «taller bento» para H-BENTO y «mesa MECÁNICO» para el oficio JWT. En UI pública el titular es Taller. En UI autenticada el titular es Mesa. [DECISIÓN]

5. Contenido de cada nodo de IA

6. Error / empty / loading (sitio)

Viven en las mismas rutas, no en URLs extra. Artboards: UI-07 empty · UI-08 error · UI-09 loading.

7. Profundidad y hallazgo

No hay búsqueda Must: el hallazgo es el bento de 4 bicis. Introducir /buscar copiaría LOMO y rompería la terna. [DECISIÓN]
Nuria no filtra la mesa con chips en v1: ve los tres grupos de ganchos. Could L3: filtro; no se cuela como deuda del L2.

8. Códigos y URLs

9. Mapa Paper → rutas

[COMPROBADO] Mapeo alineado a docs/00-paper-reference.md.

04-user-flows.md

04 — Flujos de usuario — PIÑÓN

1. Convenciones

2. F1 — Vecino deja la bici desde el bento (Must)

/  →  GET /api/bicis
   →  ve 3 métricas (en taller / listas / esperan) + 4 bicis
   →  tap Encargo  →  /encargo
   →  elige job «Frenos»          (UI-02)
   →  continúa a dejar bici       (UI-03)
   →  escribe nombre «Pablo Mora», teléfono, color «verde»
   →  POST /api/encargos  { name, phone, color, job }
   →  201 { code: PIN-2705, model?, color, job, status: ESPERA }
   →  /ok/PIN-2705

Entrada: taller bento, sin cuenta.
Salida: código visible + copy «dejar la bici ≠ comprar el taller».
Errores: red (reintentar), 400 validación, 0 bicis (empty del taller; el encargo sigue permitido).

AC

• El form no pide email, DNI, pago ni signup.
• POST no cobra, no crea user, no abre lineal, no mueve kanban, no enciende GPS.
• /ok/PIN-2705 muestra las cuatro oposiciones.
• El paso configurador existe: F-CMP no es un POST oculto en el tile. [DECISIÓN]
• El paso dejar bici existe en la misma ruta: no es un modal efímero sin URL. [DECISIÓN]
• Job es uno de rueda / frenos / cadena / revisión. [DECISIÓN]

3. F2 — Vecino intenta enviar sin configurar (Must · estado)

/encargo  →  tap Dejar la bici sin job
          →  CTA disabled o 400 local
          →  copy «Elige qué se arregla.»

AC

• No se permite POST sin job (400 si se fuerza).
• Copy: no «arréglame lo que sea». No «añadir al carrito».
• Pablo puede elegir Frenos y continuar.

4. F3 — Mecánica entra a mesa (Must)

/login  →  POST /api/auth/login
        →  JWT MECANICO
        →  /mesa
        →  GET /api/mesa

AC

• Sin token, /mesa redirige a /login?next=/mesa.
• GET /api/mesa sin Bearer → 401.
• Ganchos: 4 filas agrupadas ESPERA / EN_TALLER / LISTA + encargos (nombre, teléfono, código). No columnas Recibido / En curso.
• Desktop: grupos + encargos en el panel. 390: apilado bajo el S-TOP.
• ENTREGADA no aparece. [DECISIÓN]

5. F4 — Estados de sistema

6. Flujos que no existen

7. Tiempos de demo (modelo)

No son KPIs medidos. Son techos de diseño para el guión. [HIPÓTESIS]

8. Guión de demo canónico

1. / — tile de nave a sangre + 3 datos (2 en taller / 1 lista / 1 espera) + 4 bicis. Eslogan. S-TOP.
2. Lectura rápida: PIN-2701 Orbea EN_TALLER frenos; PIN-2702 BH LISTA revisión; PIN-2703 fold EN_TALLER rueda; PIN-2704 Trek ESPERA cadena.
3. Encargo — /encargo · elige Frenos.
4. Dejar la bici — nombre Pablo Mora · teléfono · color verde.
5. Enviar — /ok/PIN-2705. Copy ×4.
6. /login — nuria@pinon.taller / password123.
7. /mesa — ganchos ESPERA / EN_TALLER / LISTA; PIN-2702 LISTA; encargo de Pablo en ESPERA si se hizo el POST.
8. 390: bento + S-TOP; no carousel; targets ≥44px.
9. API down: error + Reintentar.

9. Contratos de error de API (flujo)

10. S-TOP en flujo

[DECISIÓN] El slot Encargo no inventa un quinto SKU; abre el configurador vacío (job aún no elegido).

05-data-model.md

05 — Modelo de datos — PIÑÓN

1. Visión general

Dominio L2 de ganchos de taller + configurador de arreglo + encargo autenticable:

Base: PostgreSQL (Neon project dedicado PIÑÓN · DATABASE_URL) · IDs: serial + texto estable (PIN-2701).
[DECISIÓN] ensureSchema es válido si el contrato de tablas se cumple; el brief de stack no exige Prisma.

Contrato de producto: bicis + requests + JWT MECANICO.
No sesiones / pedidos / ejemplares / programas / nodes / altas / bookings.

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

Role

JobPart

[DECISIÓN] Un encargo lleva un job. Multi-pieza y «arréglame todo» quedan fuera (H2).

BiciStatus

Un POST de encargo siempre crea la bici en ESPERA. [DECISIÓN]
Nuria no hace PATCH de estado en v1: la mesa es lectura de ganchos. [DECISIÓN]

3. Diagrama ER (texto)

users
  id, email, password_hash, name, role(MECANICO)
  created_at
  1 ──< sessions

sessions
  id, user_id → users
  expires_at, revoked_at
  created_at

bicis
  id
  code (unique, PIN-XXXX)
  model, color
  job (RUEDA|FRENOS|CADENA|REVISION)
  status (ESPERA|EN_TALLER|LISTA|ENTREGADA)
  cover
  sort_order
  created_at, updated_at
  1 ──< requests

requests
  id
  bici_id → bicis
  code (denorm PIN-XXXX)
  name
  phone
  created_at

v1: una sola MECÁNICO opera sobre el conjunto global.
No hay FK de vecino-usuario: el vecino no se loguea.
requests.name es el nombre de mostrador (oral), no una cuenta.
requests.phone es el recado para avisar que está LISTA; no se pinta en el bento público.

4. Tablas

users

sessions

bicis

requests

Sin email, sin DNI, sin pago, sin GPS. Dejar la bici ≠ comprar el taller. [DECISIÓN]

Índices: bicis(code), bicis(status), bicis(sort_order), users(email), requests(bici_id), requests(created_at DESC).

5. Seed

MECÁNICO

nuria@pinon.taller / password123 · Nuria Vega · MECANICO
Hash bcrypt fijo: $2b$12$OEKcNck63neDJ.CrVP0lNOaXp2NG2zd2aMiGmnYY221h4ZAZ58x1m

Bicis

Métricas derivadas del seed: en taller 2 · listas 1 · esperan 1. ENTREGADA = 0.

[SUPUESTO de taller] Modelos, colores y marcas son atrezzo. No es un taller oficial ni un acuerdo con Orbea / BH / Trek.
[DECISIÓN] sort_order 1…4 = PIN-2701…2704.

Requests seed

El POST de smoke crea el de Pablo Mora sobre un código nuevo (PIN-2705).
El seed idempotente restaura las 4 bicis de catálogo (estados y jobs) para que el demo sea repetible. [DECISIÓN]
Re-seed no borra PIN-2705+ salvo flag explícito de demo. [DECISIÓN]

6. JSON (camelCase)

API: sortOrder, createdAt, requestCount, enTaller, listas, esperan, cover, status, model, color, job, code, name, phone.
SQL: sort_order, created_at, request_count derivado.

GET /api/bicis

{
  "metrics": { "enTaller": 2, "listas": 1, "esperan": 1 },
  "bicis": [
    {
      "code": "PIN-2701",
      "model": "Orbea urbana",
      "color": "verde",
      "job": "FRENOS",
      "status": "EN_TALLER",
      "cover": "/assets/bicis/orbea.jpg",
      "sortOrder": 1
    }
  ]
}

Lista pública: no incluye name ni phone de requests (evita enumerar vecinos). [DECISIÓN]
Métricas no cuentan ENTREGADA. [DECISIÓN]

GET /api/bicis/:code

Mismo shape de item; 404 si no existe. El success puede usarlo para pintar modelo/color/job.

POST /api/encargos

Request:

{ "name": "Pablo Mora", "phone": "600123123", "color": "verde", "job": "FRENOS", "model": "urbana" }

model opcional. name obligatorio, trim, min 2. phone obligatorio, dígitos ≥ 9. color obligatorio, trim, min 3. job obligatorio, enum. [DECISIÓN]

Response 201:

{
  "code": "PIN-2705",
  "color": "verde",
  "job": "FRENOS",
  "status": "ESPERA",
  "dejada": true
}

Algoritmo: INSERT bici (status ESPERA, code siguiente) + INSERT request. Transacción única. [DECISIÓN]

GET /api/mesa (JWT)

{
  "metrics": { "enTaller": 2, "listas": 1, "esperan": 1 },
  "ganchos": {
    "ESPERA": [ /* bicis */ ],
    "EN_TALLER": [ /* bicis */ ],
    "LISTA": [ /* bicis */ ]
  },
  "requests": [
    {
      "id": 1,
      "code": "PIN-2701",
      "name": "Elena Ortiz",
      "phone": "612440271",
      "job": "FRENOS",
      "status": "EN_TALLER",
      "createdAt": "2026-08-27T09:12:00.000Z"
    }
  ]
}

7. Reglas de integridad

8. Fuera del modelo v1

9. Naming vs leftover

06-tech-stack.md

06 — Stack técnico — PIÑÓN

1. Resumen

[COMPROBADO] Angular + NestJS + Neon + Tailwind, puerto API 3027, Paper file ID y path de app salen del encargo.

2. Por qué este stack

3. Puertos y health

Leftover bobina-api / puerto 3026 / lomo-api no son el producto. [DECISIÓN]

4. Estructura de repo (contrato)

pinon-app/
  apps/
    api/          NestJS · PORT=3027
    web/          Angular · 4200
  package.json    pnpm workspaces o filter

Proxy web → API en dev (/api → http://localhost:3027). [DECISIÓN]

5. Variables de entorno (API)

No commitear secretos. .env local; ejemplo en .env.example sin credenciales reales. [DECISIÓN]

6. Auth

[COMPROBADO] Credenciales demo: nuria@pinon.taller / password123.

7. Endpoints (contrato)

CORS: origen http://localhost:4200 en dev. [DECISIÓN]

8. Frontend — rutas y componentes

Chrome: TopNavComponent (S-TOP). Tokens Tailwind: ground, cream, card, mark, mute, chrome.

9. Assets

Covers en DB como paths /assets/bicis/orbea.jpg etc. [DECISIÓN]

10. Calidad y toolchains

11. Anti-stack (no introducir)

12. Criterios de aceptación técnicos

1. GET /api/health → service: "pinon-api".
2. Seed idempotente: 1 MECÁNICO + 4 bicis + 4 requests.
3. POST encargo crea bici ESPERA + request y devuelve PIN-XXXX.
4. GET mesa sin token → 401.
5. Web en 4200 consume API 3027 sin mixed-content local.
6. 0 referencias de producto a sesiones, PROGRAMADOR, bobina-api en runtime.

[COMPROBADO] Contrato alineado a docs 01, 05 y README.

07-creative-direction.md

07 — Dirección creativa — PIÑÓN

1. Concepto

PIÑÓN es una nave de esmalte y hormigón: se entra a un tile de taller a sangre con tres números y cuatro ganchos, y se sale habiendo dejado una bici, no una landing de «tu bike shop». El ground es grafito. El naranja de reflector puntúa, poco. El cromo marca meta, poco.

Mood elegido: industrial.
Primer instinto descartado: nocturnal / fixie neón (tienda Rapha). Un taller de Legazpi se lee con esmalte, hormigón y naranja de reflector, no con LED de fixie.

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

2. Territorio visual

3. Paleta

Jerarquía de color: el grafito carga; el mark puntúa; el cromo filetea. Si el mark pinta fondos enteros, deja de ser reflector y se vuelve «brand naranja Decathlon». El cromo no decora la cabecera: solo puntual (bordes, meta). El texto sobre grafito es cream; nunca mute como párrafo largo. Cream sobre grafito debe pasar contraste WCAG 2.2 AA. [DECISIÓN]

Candidatos de mood descartados: nocturnal/fixie neón (primer instinto taller cool), rusted, arid, botanical.

4. Tipografía

Prohibido: Spectral por debajo de 18px (se rompe). Sora en el wordmark de taller (se vuelve SaaS). Mark como color de texto de párrafo largo (contraste).

Fuentes vetadas de la serie reciente cuando el brief fija otras: Cormorant / Manrope (BOBINA), Source Serif 4 / Outfit (LOMO), DM Serif Display / IBM Plex Sans, Newsreader / Figtree, Fraunces / Atkinson. Spectral + Sora sí entran: el brief los fija. [COMPROBADO]

5. Fotografía

Alt: modelo + color, no «imagen1». Ver doc 09.

[COMPROBADO] Los cuatro covers y el hero existen en assets/.

6. Registro R-HY

Híbrido: identidad de oficio clásica (S-TOP de taller, wordmark Spectral, ganchos) + bento/configurador (H-BENTO + F-CMP). No es un dashboard de seguros. No es un kiosk de horas. No es una mesa de datos de archivo. No es neón de fixie.

La innovación está en H-BENTO Deriva + S-TOP + F-CMP, no en un look «bike LED». [DECISIÓN]

7. Anti-moods

8. Densidad (AP-21)

En el recorte Deriva: eslogan + tile de nave dominante + 3 datos (en taller / listas / esperan) + 4 tiles con modelo, color, job y estado visibles sin hover. Headline huérfano + foto = card hueca. [COMPROBADO] CRON §5.8 / D-P1-09 foto-led.

Tile de nave ≥40 % del recorte 16/10. Los 3 datos y las 4 bicis no tapan el oficio de la foto: legibles, no sticker. [DECISIÓN]

9. Motion

10. Voice visual ↔ copy

El mood industrial refuerza el microcopy: gancho de nave, no lineal. Si la UI parece Decathlon (precio, talla, naranja de marca a pantalla completa) o Rapha (neón, kit), el copy irrenunciable pierde fuerza. [DECISIÓN]

08-design-system.md

08 — Sistema de diseño — PIÑÓN

1. Tokens

Tailwind: bg-ground, text-cream, bg-card, bg-mark, text-mute, text-chrome, font-display.
La tarjeta vive sobre --card; el ground es grafito alrededor. [DECISIÓN]

2. Contraste (obligatorio)

[DECISIÓN] Mark nunca como color de párrafo. Mute nunca como único color de disclaimer largo.

3. Escala de tipo

4. Componentes

Tile de bici (bento)

Cover recorte + modelo Spectral · color · job · status. Toda la tarjeta es el hit de lectura (no abre ficha pública). Orden por sort_order.

Tile Deriva (UI-01)

Imagen de nave a sangre ≥40 % del frame 16/10; gradient grafito→transparente para legibilidad del bento; wordmark + eslogan + 3 datos (en taller / listas / esperan).

Dato (métrica de gancho)

Número cream grande + label mute («en taller», «listas», «esperan»). Tres en fila desktop; wrap en 390. No es un sparkline ni una tabla H-DATA.

Configurador (UI-02)

Cuatro opciones exclusivas: Rueda · Frenos · Cadena · Revisión. Opción activa: ring mark + aria-checked. CTA Continuar (paso 2) disabled sin selección.

Form dejar bici (UI-03)

Nombre, teléfono, color del cuadro, job en solo lectura, disclaimer, submit mark.

Success (UI-04)

Código Spectral enorme + bloque card con job y color + 4 oposiciones en cream/mute.

Gancho de mesa MECÁNICO (UI-06)

Grupos ESPERA / EN_TALLER / LISTA. Fila: código · modelo · color · job · status. Encargos debajo: name · phone · code · hora. Sin acciones PATCH en v1.

Login (UI-05)

Wordmark + dos inputs + CTA mark. Ayuda mute con demo.

Top nav (S-TOP)

Tres slots: Taller · Encargo · Mesa. Activo: mark. Idle: mute. Fondo ground. Targets ≥44px.

Skeleton (UI-09)

animate-pulse bg-card. aria-busy.

Error (UI-08)

Titular display + cuerpo cream/mute + Reintentar mark.

Empty (UI-07)

Titular Spectral + mute. Sin CTA de Decathlon ni de cita.

Sello ESPERA / EN_TALLER / LISTA

Texto «Espera» / «En taller» / «Lista» + mark o mute. Nunca solo el color. Poco: un sello por tile, no un header naranja.

5. Layouts

Max page 1440px. Padding 20 / 40 / 48.

6. Estados de control

7. Iconografía

S-TOP: pictogramas simples (nave / llave / mesa). Stroke 1.5–2px. No icon packs «carrito» ni «bici de share». [DECISIÓN]

8. Elevación y bordes

9. Mapa a Paper UI

[COMPROBADO] Inventario en 00-paper-reference.md.

09-content-guide.md

09 — Guía de contenido — PIÑÓN

1. Voz

PIÑÓN habla como taller de nave, no como lineal ni como club de fitness.

[DECISIÓN] Tuteo en UI. Nuria en mesa puede verse en usted solo en docs, no en labels.

2. Microcopy irrenunciable

Presente en taller (pie o banner), encargo, success y pie de mesa:

No se parafrasean hasta diluirlas. Pueden acortarse en UI estrecha manteniendo ≠. [DECISIÓN]

3. Glosario UI

4. Pantalla a pantalla

Taller /

Encargo /encargo paso 1 (UI-02)

Encargo /encargo paso 2 (UI-03)

Success /ok/:code

Login /login

Mesa /mesa

5. Alt text de imágenes

Evitar «imagen1», «bike.jpg», copy de catálogo con precio. [DECISIÓN]

6. Modelos seed (atrezzo)

Orbea / BH / Classic / Trek son catálogo demo. En UI no se afirma «distribuidor oficial». Los blurbs pueden recordar dejar ≠ comprar. [SUPUESTO de taller]

7. Tono de error

Sin culpa al usuario. Sin jerga HTTP en UI.

8. Anti-copy (vetado)

9. Criterios de aceptación de contenido

1. Las cuatro oposiciones aparecen al menos en success y en una superficie de taller o encargo.
2. Ningún CTA dice Comprar / Alquilar / Reservar clase.
3. LISTA se etiqueta «Lista», no «Disponible» retail.
4. Códigos se muestran como PIN-XXXX en versales.
5. Docs y UI no inventan KPIs numéricos de Legazpi como hecho.

10-accessibility.md

10 — Accesibilidad — PIÑÓN

1. Objetivo

Cumplir WCAG 2.2 AA en el vertical slice L2. Ground oscuro (grafito): el par cream sobre grafito es el contrato de legibilidad. Amparo Díaz (71) es persona de diseño que fuerza contraste, tamaño y targets; no tiene login. [COMPROBADO] requisito del encargo · [DECISIÓN] persona Amparo en docs.

2. Contraste

[DECISIÓN] Si mute falla AA en párrafo, se asciende a cream. Mark no escribe disclaimers.

Verificación: contraste en tokens al build de UI; no se afirman ratios inventados sin medir en implementación. [HIPÓTESIS operativa] cream/grafito pasa; se valida en QA (doc 13).

3. Tipografía y lectura

4. Targets y pointer

Spacing entre slots del top ≥ 8px. [DECISIÓN]

5. Teclado y foco

Sin keyboard traps. Esc no es obligatorio en v1 (sin modales Must).
Opciones de job: radiogroup + radio o botones con aria-pressed. [DECISIÓN]

6. Semántica y nombres

7. Imágenes y tile

[DECISIÓN] Preferir tile con alt útil en cover UX; en producto, si el overlay ya nombra PIÑÓN y los ganchos, evitar alt redundante largo.

8. Motion

9. Estados y color

ESPERA / EN_TALLER / LISTA / error nunca se comunican solo con color: texto + sello. Mark refuerza, no sustituye. [DECISIÓN]

10. Auth y a11y

• Login solo MECÁNICO; Amparo no necesita cuenta para leer el taller ni dejar bici.
• Mensajes de error de login claros, sin enumerar si el email existe (seguridad + claridad).
• /mesa redirige a login con foco en email.

11. Mobile 390

• S-TOP fijo no tapa el CTA final: padding-top del contenido ≥ altura top; en encargo, el submit queda por encima del teclado.
• Formularios: autocomplete name on; tel tel; password current-password.
• Viewport meta; sin zoom bloqueado. [DECISIÓN]
• UI-11 bento y UI-12 encargo cubren el recorte 390. No carousel.

12. Criterios de aceptación a11y

1. Cream sobre grafito usado en cuerpo; mute limitado a meta.
2. Targets S-TOP y CTA ≥ 44×44.
3. Focus visible mark en todos los interactivos.
4. Status y métricas con texto, no solo color o número huérfano.
5. Reduced motion respetado.
6. Form con labels y errores anunciables.
7. Ningún toast único sin pantalla como único success (hay /ok/:code).

13. Fuera de v1 (L3, no deuda)

• Modo tipográfico «letra grande» persistente para Amparo.
• App nativa con VoiceOver de taller físico.
• ATAG de CMS (no hay CMS).

11-privacy-security.md

11 — Privacidad y seguridad — PIÑÓN

1. Principios

[DECISIÓN] No se inventa un aviso legal largo de cadena de tiendas; hay disclaimer de producto y minimización real.

2. Datos tratados

No se tratan: pago, tarjeta, geolocalización, ID de dispositivo publicitario, mensajes de chat, talla, IBAN.

[SUPUESTO] El taller demo opera en España; el slice no implementa un RGPD completo de empresa real.

3. Superficies públicas vs privadas

[DECISIÓN] Enumerar teléfonos en el bento rompería privacidad de nave; solo Nuria ve recados.

4. AuthN / AuthZ

Credenciales demo en docs: nuria@pinon.taller / password123. No reutilizar en producción real. [COMPROBADO] demo · [DECISIÓN] rotar fuera del case.

5. Amenazas y mitigaciones L2

6. Contenido de teléfono y nombre

phone es recado, no tracking. Se muestra a Nuria en mesa. Formato: dígitos, min 9. [DECISIÓN]
No se pide dirección, salud ni datos de terceros sensibles en el form.
name es texto libre corto (min 2, max 80).

7. Cookies y tracking

v1 no incluye analytics de terceros ni banners de cookies de ads. North star es modelo (doc 12). [DECISIÓN]
Token JWT puede vivir en localStorage (XSS risk aceptado en demo) o memory; documentar en handoff.

8. Logs

9. Criterios de aceptación

1. GET mesa sin Bearer → 401.
2. GET bicis no incluye name ni phone.
3. POST encargos no exige auth ni pago ni GPS.
4. Password solo como hash bcrypt.
5. .env no versionado con secretos reales.
6. Copy de success no implica contrato de compra ni de alquiler.

10. Fuera de v1 (L3 / org real, no deuda)

DPO, ROPA formal, exportaciones ARCO automatizadas, SSO, 2FA, WAF, geolocalización. Roadmap L3 si el taller deja de ser demo (GPS, e-commerce).

12-analytics.md

12 — Analytics y métricas — PIÑÓN

1. Norte

[COMPROBADO] North star alineada a H1 del day brief.
[DECISIÓN] En v1 es modelo: no hay instrumentación obligatoria ni dashboard. No se afirman porcentajes medidos inventados.

2. Por qué esta north star

El WhatsApp de «¿está lista?» es el recado que el bento y la mesa pretenden absorber. [SUPUESTO] operativo de diseño, no dato de campo.

3. Métricas de soporte (modelo)

4. Eventos (contrato si se instrumenta en un L3)

[DECISIÓN] Nunca enviar name ni phone a analytics.
Instrumentar eventos no es un hueco del L2: el slice cierra sin tracker. [DECISIÓN]

5. Cálculo north star (modelo)

listas = bicis con status LISTA en la ventana
listas_sin_whatsapp =
  (no medible en v1: no hay canal WhatsApp en producto)
proxy de diseño = visitas a / o /mesa que cubren el estado
                   frente a recados paralelos (cualitativo)

[DECISIÓN] v1 no persiste un flag whatsapp_asked. El north star queda como modelo de oficio, no como SQL fingido.

Timezone: Europe/Madrid. [DECISIÓN]

6. Integridad de expectativa (cualitativa)

Señales a vigilar en demo / soporte (no KPIs inventados):

• «¿Compro la bici?»
• «¿Reservo una clase?»
• «¿Esto es un alquiler?»
• «¿Es Decathlon?»
• «¿Dónde está el GPS?»

Mitigación: microcopy irrenunciable (doc 09). [HIPÓTESIS H2]

7. Qué no medir en v1

8. Criterios de aceptación

1. Docs y UI no muestran un % inventado como hecho.
2. North star documentada y alineada a H1.
3. Si hay eventos en un L3, sin PII de requests.
4. Health y 401 mesa son checks de integridad, no vanidad.

9. Relación con seed

Seed tiene 2 EN_TALLER + 1 LISTA + 1 ESPERA. Un guión con POST sobre un encargo nuevo es el ejemplo narrativo de activación; no es un dato de mercado. [SUPUESTO de demo]

13-qa-test-plan.md

13 — Plan de QA — PIÑÓN

1. Alcance

Smoke y regresión del vertical slice L2: bento, configurador, dejar bici, success, login, mesa, empty/error/loading, mobile 390, contraste cream/grafito.
No incluye campo real de Legazpi ni load test de gran superficie.

2. Entornos

3. Smoke crítico (Must pasar)

4. Regresión funcional

5. Accesibilidad (muestra)

6. Contenido

7. Visual / Paper

8. API negativa

9. Datos de prueba

Tras smoke: re-seed para restaurar las 4 de catálogo. [DECISIÓN]

10. Criterio de salida

Smoke S01–S12 en verde. Sin P0 (health mal, encargo roto, mesa abierta sin auth, copy Decathlon ausente en success).
P1 visual puede quedar anotado; no reabre el alcance L2.

11. Fuera de alcance QA v1

Penetration test, auditoría RGPD formal, GPS, pasarela de pago, compatibilidad IE, métricas reales de north star instrumentadas. Eso es L3 u org real, no un agujero de este slice.

14-dev-handoff.md

14 — Handoff a desarrollo — PIÑÓN

1. Contrato vivo

Si código y docs divergen, alinear ambos; no silenciar leftover BOBINA como producto. [DECISIÓN]

2. Definition of Done (DoD) L2

El DoD cubre todo el slice. No queda producto in-scope como «siguiente sprint». [DECISIÓN]

3. Mapa Paper → Angular

4. API checklist

Body encargo: { name: string, phone: string, color: string, job: JobPart, model?: string }.
INSERT bici ESPERA + request en transacción. [DECISIÓN] ver doc 05.

5. Seed y credenciales

6. Anti-patrones de implementación

7. Assets

Copiar desde case:

• assets/bicis/orbea.jpg
• assets/bicis/bh.jpg
• assets/bicis/fold.jpg
• assets/bicis/trek.jpg
• assets/hero.jpg (tile Deriva / cover)

[COMPROBADO] existen en el case.

8. QA mínimo antes de merge

Ejecutar smoke S01–S12 (doc 13). Verificar copy irrenunciable en /ok/:code.

9. Open questions (no reabren L2)

10. Contacto de diseño

Paper file + docs 07–09. No reinventar neón fixie. Mood industrial. Ground #2C3033. Mark #E24A17.

15-roadmap.md

15 — Roadmap — PIÑÓN

1. Horizonte

[DECISIÓN] El L2 no deja producto ni código in-scope como «próximos pasos». Este roadmap no es un cajón de deuda. Empty, error, loading, mobile, auth, seed, copy y API están en el slice de hoy.

2. Hecho en L2 (Must · cerrado)

Nada de la tabla se reabre como backlog de «el código ya vendrá». El case L2 cierra en una iteración. [DECISIÓN]

3. L3 only (nice-to-have · otro brief)

Estas dos ideas no completan PIÑÓN. Completarían otro producto. [DECISIÓN]

4. Anti-roadmap (no disfrazar)

5. Dependencias del slice cerrado

6. Criterios para abrir un L3

1. Smoke L2 en verde (doc 13).
2. Copy irrenunciable intacto.
3. El brief L3 nombra GPS o e-commerce sin reabrir ganchos, F-CMP ni mesa.
4. North star sigue siendo modelo o se instrumenta sin PII.

7. Cierre

L2 está completo en una iteración. El roadmap es un muro contra el lineal y el GPS, no una lista de lo que «faltó». [DECISIÓN]

16-interaction-specs.md

16 — Especificación de interacción — PIÑÓN

1. Convenciones

Loading, empty y error viven con los gestos (UI-07 / UI-08 / UI-09). [DECISIÓN]

2. Home bento (UI-01) + mobile (UI-11) · H-BENTO Deriva

AC: modelo, color, job y estado visibles sin hover. Tile nave ≥40 % del recorte 16/10 (AP-21 / D-P1-09). Tres datos con texto («2 en taller»), no solo cifra. Cero botones Comprar / Alquilar / Reservar clase.

El aviso «PIÑÓN no es Decathlon» es texto, no un CTA de tienda. [DECISIÓN]

390: mismas 4 bicis apiladas. No carousel. S-TOP visible. [DECISIÓN]

3. Configurador (UI-02) + mobile encargo (UI-12) · F-CMP paso 1

AC: una sola pieza. Cero «lo que sea». Cero carrito. Cero wizard de criterios (ZAGUÁN).

4. Dejar bici (UI-03) · F-CMP paso 2

AC: no email, no DNI, no pago. Dejar la bici ≠ comprar el taller visible.

5. Success (UI-04)

AC: las cuatro oposiciones están. No QR. No «ticket listo». No mapa GPS.

6. Login (UI-05)

AC: sin signup. Ayuda demo mute.

7. Mesa MECÁNICO (UI-06)

AC: no columnas Recibido / En curso. No PATCH estado. No split lista|ficha. No mapa.

8. S-TOP · chrome

AC: tres slots. No hamburger. No dock. Targets ≥44px. Fijo en 390.

9. Empty / Error / Loading (UI-07 / UI-08 / UI-09)

10. Motion

Sin Ken Burns agresivo sobre Deriva. [DECISIÓN]

11. Guión de interacción demo

1. / loading → tile + 3 datos + 4 bicis.
2. Leer PIN-2702 LISTA / PIN-2704 ESPERA.
3. Encargo → Frenos → form Pablo → pending → success.
4. S-TOP Mesa → login → mesa con gancho ESPERA nuevo.
5. 390: S-TOP no tapa CTA; scroll con padding.

12. Criterios de aceptación de interacción

1. F-CMP no salta el configurador.
2. POST sin job no navega a ok.
3. Pending no doble-envía.
4. S-TOP siempre alcanzable en 390.
5. Focus visible en todo el recorrido teclado.

17-prototype-map.md

17 — Mapa de prototipo — PIÑÓN

1. Fuentes

[COMPROBADO] conteos y file ID en docs/00-paper-reference.md.

2. UX process → docs

3. UI producto → rutas / componentes

4. Flujo prototipo clickable (orden demo)

UI-01 Home bento
  ├─→ UI-02 Configurador (Frenos)
  │     └─→ UI-03 Dejar bici → UI-04 Success
  ├─→ UI-11 (mismo /, viewport 390)
  ├─→ UI-12 (mismo /encargo, viewport 390)
  └─→ S-TOP Mesa → UI-05 Login → UI-06 Mesa

Estados: UI-07 empty · UI-08 error · UI-09 loading se prueban desconectando API o seed vacío.
Tokens: UI-10.

5. Datos de prototipo = seed

Hotspots Paper deben usar estos códigos en labels si muestran URL. [DECISIÓN]
POST demo → PIN-2705 (Pablo Mora, frenos, verde).

6. Breakpoints de artboard

7. Terna visible en prototipo

8. Gaps conscientes

Ningún gap es producto in-scope aplazado. [DECISIÓN]

9. Criterios de aceptación del mapa

1. Cada UI-01…12 tiene fila en esta tabla.
2. Cada ruta Must tiene artboard.
3. No hay artboard de /buscar, /sesion, tienda, GPS o cita.
4. Mobile 390 cubierto (UI-11, UI-12).
5. UX-00…11 cubiertos.

18-completeness-audit.md

18 — Auditoría de cierre — PIÑÓN

1. Alcance L2 · una iteración

El vertical slice cierra en esta iteración. No hay segunda pasada de producto in-scope. Empty, error, loading, mobile, auth, seed, copy y contrato de código forman parte del cierre, no de un roadmap.

2. Terna y diversidad

3. Copy irrenunciable

Presente en taller, encargo, success, pie de mesa. Ver doc 09.

• Dejar la bici ≠ comprar el taller
• Encargo ≠ cita de fitness
• Recoger ≠ alquilar
• PIÑÓN no es Decathlon

4. Anti-patrones vigilados

5. Seed

4 bicis · 2 EN_TALLER · 1 LISTA · 1 ESPERA · Nuria MECÁNICO · Pablo sin cuenta · Amparo fuera de login.

Métricas: en taller 2 · listas 1 · esperan 1.

6. Assets

7. Huecos conscientes (fuera · L3)

GPS, e-commerce. Nada más se etiqueta como «faltó del L2».

Login Amparo, email transaccional, instrumentación analytics, PATCH de estado, ficha /mesa/:code no son deuda: son decisiones de corte (S2, S4, D14).

8. Checklist archivos suite

9. Veredicto

Slice L2 cerrado en una iteración. El contrato de pinon-app (docs 14 y 20) no se lista como próximo paso de producto: es el mismo alcance, ya definido. Paper file 01M110K5JHDQ899C360KC4D0WD. Si el repo diverge (leftover BOBINA), gana docs 05 + 20 tras alinear ambos.

Cierre: Must cubierto. Roadmap = L3 GPS y e-commerce únicamente.

10. SCORE ALS-2 (cierre)

Gate: node scripts/check-paper-reference.mjs 2026-08-27-pinon → OK.

19-backlog-completo.md

19 — Backlog completo — PIÑÓN

1. Leyenda

No hay columna «Must (después)». El slice no deja producto in-scope a medias. [DECISIÓN]

2. Épica A — Taller H-BENTO Deriva

3. Épica B — Configurador F-CMP

4. Épica C — Dejar la bici

5. Épica D — Mesa MECÁNICO

6. Épica E — Chrome S-TOP

7. Épica F — Design system & a11y

8. Épica G — Plataforma

9. Épica H — Documentación & diseño

10. Orden de build (mismo alcance, no roadmap)

1. Schema + seed + health
2. GET bicis + TallerPage Deriva
3. EncargoPage paso 1 + paso 2
4. POST encargos + OkPage copy
5. Auth + MesaPage
6. S-TOP + 390 + empty/error/loading
7. Pulido tokens / a11y / smoke S01–S12

Ese orden no es «próximos pasos de producto»: es la receta del mismo L2 ya cerrado. [DECISIÓN]

11. Contadores

No se inventan story points ni velocidades de equipo. [DECISIÓN]

20-implementation.md

20 — Implementación — PIÑÓN

1. Resumen ejecutivo técnico

Este documento es la especificación de build del L2 ya cerrado. No es un roadmap: si el repo diverge, gana el contrato de docs 05 + este archivo tras actualizar ambos.

Contrato: bicis + requests + JWT MECANICO. Puerto 3027. Health pinon-api.

[COMPROBADO] Path, puerto y Paper salen del encargo.

El repo no debe contener leftover BOBINA (sesiones, PROGRAMADOR, bobina-api, puerto 3026) ni leftover LOMO (ejemplares, BIBLIO). Eso no es PIÑÓN.

2. Cómo arrancar

cd /Users/cristian/orca/pinon-app
# instalar dependencias por app (pnpm --filter; no npm workspaces)

# apps/api/.env
#   DATABASE_URL=<neon PIÑÓN>
#   JWT_SECRET=<secret>
#   PORT=3027

# schema + seed
# api → http://localhost:3027
# web → http://localhost:4200

Credenciales

Hash seed: $2b$12$OEKcNck63neDJ.CrVP0lNOaXp2NG2zd2aMiGmnYY221h4ZAZ58x1m

Vecino / vecina mayor: sin cuenta. Pablo deja en /encargo. Amparo no entra por login.

3. Schema

Al boot o vía migrate:

1. CREATE TABLE de users, sessions, bicis, requests (doc 05).
2. Índices: bicis(code), bicis(status), bicis(sort_order), users(email), requests(bici_id), requests(created_at DESC).
3. Seed idempotente:
   • upsert MECANICO nuria@pinon.taller (hash bcrypt canónico)
   • upsert bicis por code (PIN-2701…PIN-2704) restaurando status, job, color, cover
   • upsert 4 requests seed (Elena, Luis, Marta, Iván)
4. Dominio: solo bicis + requests + users. [DECISIÓN]

Upsert de bicis por code sí restaura status/job de catálogo para que el guión sea repetible. [DECISIÓN]

POST de encargo sí genera código nuevo (PIN-2705+). El success usa ese código.

Tablas (recordatorio)

DROP leftover sesiones, pedidos, ejemplares, programas si existen en el mismo Neon. [DECISIÓN] El project es de PIÑÓN.

Seed SQL (modelo)

[SUPUESTO de taller] Modelos demo.

4. Módulos API a implementar

Auth

• POST /api/auth/login
• Valida email/password; compara bcrypt; emite JWT con sub, email, role.
• Guard JWT + role === MECANICO protege /mesa.
• Públicos: health, bicis, bicis/:code, POST encargos, login.

Oficio

Health (referencia de implementación)

{ "ok": true, "service": "pinon-api" }

Cualquier leftover "bobina-api" o "lomo-api" falla el DoD.

POST encargos — algoritmo

1. Validar body.job ∈ {RUEDA,FRENOS,CADENA,REVISION} else 400
2. Validar body.name (trim, length >= 2) else 400
3. Validar body.phone (dígitos >= 9) else 400
4. Validar body.color (trim, length >= 3) else 400
5. model = body.model?.trim() || 'bici'
6. code = siguiente PIN-XXXX (max existente + 1, piso PIN-2705)
7. INSERT bicis (code, model, color, job, status=ESPERA)
8. INSERT requests (bici_id, code, name, phone)
9. 201 { code, color, job, status: ESPERA, dejada: true }

Transacción única. [DECISIÓN]

GET bicis — shape

{
  "metrics": { "enTaller": 2, "listas": 1, "esperan": 1 },
  "bicis": [ { "code", "model", "color", "job", "status", "cover", "sortOrder" } ]
}

Métricas: count status EN_TALLER / LISTA / ESPERA. No ENTREGADA. [DECISIÓN]

GET mesa — shape

{
  "metrics": { "enTaller": n, "listas": n, "esperan": n },
  "ganchos": {
    "ESPERA": [ /* bicis */ ],
    "EN_TALLER": [ /* bicis */ ],
    "LISTA": [ /* bicis */ ]
  },
  "requests": [ { "id", "code", "name", "phone", "job", "status", "createdAt" } ]
}

Orden requests: created_at DESC. [DECISIÓN]

5. Frontend Angular

Rutas

Servicios

UI Must

1. TallerPage — tile + 3 datos + 4 bicis (Deriva), no feed ni tabla.
2. EncargoPage — F-CMP paso 1 y 2.
3. OkPage — código + 4 oposiciones.
4. LoginPage / MesaPage.
5. TopNavComponent — S-TOP.
6. Estados empty/error/loading.

Tailwind tokens

ground: #2C3033
cream: #F3F1EC
card: #1A1C1B
mark: #E24A17
mute: #8B8E8A
chrome: #C5C8C4
font-display: Spectral
font-sans: Sora

6. Assets en app

Copiar desde el case a apps/web/public/assets/bicis/ (o path equivalente servido):

• orbea.jpg
• bh.jpg
• fold.jpg
• trek.jpg

hero.jpg → tile Deriva (/assets/hero.jpg).

Paths en DB alineados a /assets/bicis/.... [DECISIÓN]

7. Checklist anti-leftover

8. DoD técnico (merge)

1. Smoke S01–S12 (doc 13) en verde.
2. Health pinon-api.
3. Seed idempotente.
4. Mesa 401 sin token.
5. Success muestra las 4 oposiciones.
6. 390 + S-TOP usable.
7. 0 referencias de producto a sesiones/PROGRAMADOR/bobina-api.
8. Cream sobre grafito en cuerpo.

9. Fuera de esta especificación

• GPS (L3).
• E-commerce (L3).
• Instrumentación analytics (doc 12 modelo).
• PATCH de estado (mesa de lectura).

Ninguno de esos ítems es un «siguiente paso» del L2. [DECISIÓN]

10. Cierre

Implementación = contrato ejecutable del case 2026-08-27-pinon, cerrado en una iteración. [COMPROBADO] alcance L2.