Day brief — 2026-08-08 — ALS-2

1. LOAD — restricciones del día

Anti-patrones a evitar (top del catálogo)

Barra de calidad actual (ratchet)

• Paper: bandas §1–§5, ≥8 artboards UX densos + DS + público + coach + mobile + states.
• Angular alineado a tokens (chalk/ink/lime; no default Tailwind genérico).
• API Nest + Prisma + Neon con seed demo usable (5 ClassRequest + coach).
• Smoke: POST público request + login coach + list + patch status; ng build o serve OK.
• Docs en español, profundidad tipo portfolio (no stubs).

2. BRIEF — concepto del día

Por qué L1 fitness (y no otra cosa)

1. Diversidad de sector: la serie no había tocado club deportivo / fitness comunitario.
2. Complejidad L1 justa: un rol autenticado, entidad core con máquina de estados, form público y panel ops — vertical slice denso sin multi-rol ni multi-tenant.
3. Diferenciación vs CORREA: CORREA es marketplace B2C con reservas; VOLTA es lead de plaza del propio club (no matching de terceros).
4. Diferenciación vs SURCO: SURCO es tool multi-rol de finca; VOLTA es web de club + inbox de solicitudes.
5. Metáfora de marca: volta = vuelta / vuelta a la cancha; promesa de hueco real en el grupo, no de “app fitness genérica”.

Must-have del día (alcance L1)

Explicitamente fuera de alcance (no son deuda del día)

• Pagos / cuotas / Stripe
• Calendario de plazas en tiempo real / aforo live
• App nativa / wearables
• Multi-coach / multi-sede / multi-tenant
• Notificaciones email/SMS/WhatsApp automáticas
• Marketplace de entrenadores externos
• Perfil de socio completo / CRM pesado

3. Directivas activas aplicadas

4. Cuentas demo

Seed de referencia: 5 ClassRequest con códigos VO-0808-01…05 (HIIT NEW, YOGA CONTACTED, BASKET NEW, KIDS CONFIRMED, OPEN CANCELLED).

Supuestos (no investigación primaria)

• Clubs de barrio coordinan listas de espera y plazas por WhatsApp y papel en el mostrador.
• El coach necesita un inbox ordenado, no un ERP de socios.
• El visitante quiere pedir plaza sin crear cuenta ni app.

5. Criterio de cierre del día

• Brief de diversidad y anti-patrones documentado
• Producto definido (no marketplace, no agro, no logistics)
• Implementación runnable API :3008 / web :4200
• Documentación portfolio 00–20 + presentation + README
• Paper file enlazado y referenciado por bandas
• Hipótesis vs investigación marcadas (sin stats falsas)

Estado del brief: listo para EXECUTE y entrega de caso.

Referencia Paper — VOLTA

1. Mapa de canvas (bandas jerárquicas)

Layout canvas (referencia): origen (0,0) · gaps ~80px · bandas Y orientativas: UX ~100 / Design ~2180 / Coach ~3980 / Mobile ~4880 / States ~5680.

2. Inventario de artboards

§1 — UX PROCESS

§2 — DESIGN + PUBLIC

§3 — COACH (desktop)

§4 — MOBILE

§5 — STATES

3. Checklist de densidad (anti thin-frames)

4. Mapeo Paper → Angular

5. Tokens de diseño en Paper

Nota implementación: tailwind.config.js de la app usa los mismos hex de marca; primary mapea a ink para CTAs dark; lime para acentos.

6. Enlaces

• Paper: https://app.paper.design/file/01KZG2VRQFF2QF0PRDB10D4AG7
• Case: /Users/cristian/orca/ux-projects/2026-08-08-volta/
• App: /Users/cristian/orca/volta-app/
• Neon project: delicate-mountain-11765167

01 — Definición de proyecto — VOLTA

1. Identidad

2. Problema

Principal (hipótesis de diseño)

Los clubs de barrio gestionan listas de plaza por WhatsApp, notas en el mostrador y mensajes perdidos. El visitante no sabe si su mensaje llegó; el coach no tiene un inbox con estado (nuevo / contactado / confirmado).

Secundarios

Supuestos (no investigación primaria propia)

• S1: Clubs pequeños–medianos no necesitan un CRM enterprise; sí un inbox de solicitudes con estado.
• S2: El visitante prefiere un form de 1 pantalla a crear cuenta o descargar app.
• S3: El valor inmediato está en captura estructurada + pipeline de estado, no en aforo live ni pagos.

Hipótesis de producto

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

3. Propuesta de valor

No es VOLTA

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L1 fitness con JWT coach y dominio ClassRequest.
• Portfolio coherente: Paper + docs + app runnable.

Usuario

No objetivos v1 (explícitos)

• Pagos y cuotas mensuales
• Aforo en tiempo real por clase
• Chat in-app
• Multi-coach con permisos granulares
• Export contable

5. Roles y permisos (resumen)

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

7. Alcance funcional v1 (L1)

8. Criterios de aceptación de producto

1. Un visitante puede enviar una solicitud sin autenticación y recibir un código VO-….
2. Sin token, GET/PATCH /api/requests* responden 401.
3. Un coach puede iniciar sesión y ver el inbox ordenado (createdAt desc) con stats.
4. El detalle permite transicionar estados NEW | CONTACTED | CONFIRMED | CANCELLED.
5. La home comunica club de barrio y plaza, no marketplace ni gym chain genérico.
6. Tipos de clase soportados: HIIT, YOGA, BASKET, KIDS, OPEN.

9. Stack y artefactos

10. Riesgos y mitigaciones

11. Glosario

02 — Estrategia de investigación UX — VOLTA

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 DE DISEÑO].

1. Objetivos de investigación (del caso)

2. Fuentes y límites

Fuentes admisibles (secundarias / operativas)

• Conocimiento general de clubs deportivos de barrio y gestión informal de listas.
• Analogía operativa con captación de leads + inbox ops (serie daily: paneles JWT, estados).
• Restricciones ALS-2 de diversidad (sector fitness libre; no marketplace; no agro/legal/logistics).

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: coach / responsable del club.
• Usuario frecuente captura: visitante (form) y coach (inbox diario).
• Riesgo de rechazo: si el form pide más que un WhatsApp sin devolver acuse ni claridad de estado.

4. Personas

P1 — Marc Solé · Visitante / socio potencial

Escenario: Entra en la web del club, elige HIIT 19:00, envía y guarda el código VO-.

P2 — Nora Beltrán · COACH

Escenario: Login → inbox → Marc NEW → CONTACTED → tras llamada CONFIRMED.

Anti-persona

5. JTBD y user stories

Job principal (visitante)

Cuando quiero un hueco en una clase o cancha del club,
quiero enviar mis datos y preferencias en un solo paso,
para que el coach me contacte sin perder el mensaje en WhatsApp.

Job principal (coach)

Cuando llegan pedidos de plaza,
quiero verlos con estado y tipo de clase,
para contactar y confirmar sin Excel ni papel.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1)

6. Journey (visitante → coach)

Momentos de verdad

1. Form sin cuenta — si pide login, abandono alto [HIPÓTESIS].
2. Código VO- — prueba social de “ha llegado”.
3. Estado en inbox — evita re-contactar a quien ya está confirmado.

7. Service blueprint (resumen)

8. Matriz hallazgo → requisito → feature

9. Preguntas abiertas (no bloquean v1)

10. Síntesis

VOLTA se diseña como canal de plaza del club, no como marketplace fitness.
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 — Arquitectura de información — VOLTA

1. Principios de IA

2. Sitemap

/                          Home (público)
/apuntarme                 Formulario de plaza (público)
/ok                        Success post-solicitud (público)
/login                     Login JWT coach
/inbox                     Lista + stats (auth COACH)
/inbox/:id                 Detalle + estado (auth COACH)
/**                        → redirect /

Árbol por audiencia

3. Navegación

Pública

Coach (autenticado)

No hay menú lateral multi-sección en v1 (evita IA de CRM).

4. Inventario de contenido

5. Taxonomía y etiquetas

RequestStatus

Orden de lista: por createdAt descendente (más reciente primero).

ClassType

6. Modelo mental vs UI

7. Rutas API alineadas a IA

8. Decisiones de IA descartadas

04 — Flujos de usuario — VOLTA

Convenciones

• Actor: Guest | COACH
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica

F1 — Descubrimiento (Guest)

Home (/) → anclas #clases / #horarios
        → CTA "Quiero una plaza" | "Apuntarme"
        → /apuntarme
        → (nav) "Coach" → /login

Éxito: form de plaza o login visible.

F2 — Solicitar plaza (Guest, público)

/apuntarme → validación cliente
          → POST /api/requests { fullName, email, phone?, classType, preferredDay, preferredSlot, notes? }
          → 201 ClassRequest { code, ... }
          → /ok (state o query con code)

Éxito: registro status=NEW, código VO-MMDD-XXX, pantalla success.
Errores:

No hay cuenta de socio en v1.

F3 — Success (Guest)

/ok → muestra copy de confirmación + code
    → CTA volver home o "seguir explorando"

F4 — Login JWT (COACH)

/login → POST /api/auth/login { email, password }
      → 200 { accessToken, user } → localStorage → /inbox
      → 401 → mensaje error en form

Éxito: token guardado; user role=COACH, nombre Nora Beltrán.
Errores:

F5 — Inbox + stats (COACH)

/inbox (token en cliente)
  → GET /api/requests
  → GET /api/requests/stats/summary
  → Render cards + métricas

F6 — Detalle y cambio de estado (COACH)

/inbox/:id
  → GET /api/requests/:id
  → UI: datos contacto + preferencias + notas
  → PATCH /api/requests/:id/status { status }
  → 200 ClassRequest actualizado

Transiciones permitidas (modelo v1)

Cualquier status del enum puede asignarse vía PATCH (máquina simple L1):

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

F7 — Logout (COACH)

Click "Salir" → limpia localStorage (token + user) → /login

Matriz de errores global

Flujos fuera de alcance v1

• Registro de socio
• Recuperación de password
• Notificación email automática al coach
• Filtros multi-criterio en inbox
• Asignación multi-coach

05 — Modelo de datos — VOLTA

1. Visión general

Dominio mínimo de club L1:

Base: PostgreSQL (Neon) · ORM: Prisma · IDs: cuid().

2. Enums

Role

RequestStatus

ClassType

3. Diagrama ER (texto)

User
  id, email, passwordHash, name, role(COACH)
  createdAt, updatedAt

ClassRequest
  id, code (unique)
  fullName, email, phone?
  classType, preferredDay, preferredSlot, notes
  status (default NEW)
  createdAt, updatedAt

No hay FK entre ClassRequest y User en v1: el form es anónimo (sin cuenta). El coach opera sobre el conjunto global de solicitudes.

4. Tablas / modelos Prisma

User

ClassRequest

5. Reglas de integridad y negocio

6. Contratos API (resumen)

POST /api/requests (público)

Body

Response 201: ClassRequest completo.

POST /api/auth/login

Body: { email, password }
Response 200: { accessToken, user: { id, email, name, role } }

GET /api/requests (JWT)

Array ClassRequest ordenado por createdAt desc.

GET /api/requests/stats/summary (JWT)

{
  "total": 5,
  "open": 3,
  "byStatus": {
    "NEW": 2,
    "CONTACTED": 1,
    "CONFIRMED": 1,
    "CANCELLED": 1
  }
}

open = NEW + CONTACTED.

GET /api/requests/:id (JWT)

ClassRequest o 404.

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

Body: { status: RequestStatus }
Response: ClassRequest actualizado.

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

El sufijo de fecha del código de seed es representativo del día del caso; la generación runtime usa la fecha del servidor.

8. Evolución posible (no implementada)

06 — Stack tecnológico — VOLTA

1. Visión

Stack fijo del cron: no se sustituye por React/Next/Firebase salvo excepción documentada.

2. Estructura monorepo app

volta-app/
├── apps/
│   ├── api/          # NestJS + Prisma
│   │   ├── prisma/
│   │   │   ├── schema.prisma
│   │   │   ├── seed.ts
│   │   │   └── migrations/
│   │   └── src/
│   │       ├── auth/
│   │       ├── requests/
│   │       ├── prisma/
│   │       └── main.ts
│   └── web/          # Angular + Tailwind
│       └── src/app/
│           ├── pages/
│           ├── core/api.service.ts
│           └── app.routes.ts
├── package.json      # scripts api / web
└── README.md

Regla D-P1-03: apps/api y apps/web independientes (npm install --prefix), sin workspaces npm que rompan Angular CLI.

3. Backend

Módulos

4. Frontend

Rutas web

5. Base de datos

6. Seguridad técnica (resumen)

Detalle en 11-privacy-security.md.

7. Scripts típicos

cd /Users/cristian/orca/volta-app
npm install --prefix apps/api
npm install --prefix apps/web
# apps/api/.env → DATABASE_URL + JWT_SECRET
npm --prefix apps/api run prisma:migrate
npm --prefix apps/api run prisma:seed
npm run api    # :3008
npm run web    # :4200

8. Decisiones técnicas

9. Dependencias clave (orientativo)

10. Despliegue (recomendado, no obligatorio del día)

Variables: DATABASE_URL, JWT_SECRET, PORT, y en web la URL pública de API.

07 — Dirección creativa — VOLTA

1. Concepto de marca

Metáfora

Volta evoca la vuelta a la cancha, el regreso al grupo, el ciclo del entrenamiento semanal. Visualmente: tiza (chalk) de pizarra de vestuario × tinta negra de dorsal × lima neón de línea de campo.

2. Personalidad (arquetipos)

3. Sistema visual

Color

Regla: el lime es acento, no relleno masivo. CTAs principales pueden ser ink (texto lime) o lime (texto ink) según jerarquía.

Tipografía

Forma

• Radios grandes (rounded-2xl, pills rounded-full) → amable sin “bubble tea app”.
• Bordes 1px #E2E2DC → estructura de vestuario limpio.
• Hero con foto real de cancha/club — no ilustración stock abstracta.

4. Moodboard verbal

5. Fotografía y media

[DECISIÓN DE DISEÑO]: media fotorrealista obligatoria (D-P0-05); no placeholders grises.

6. Voz en UI (preview; detalle en doc 09)

7. Diferenciación en la serie ALS-2

8. Criterios de aceptación creativa

1. Un scroll de home se reconoce como club de barrio, no como template Tailwind.
2. Syne aparece en logo y H1; Work Sans en body/forms.
3. Lime presente en CTAs o highlights sin saturar fondos.
4. Hero real; sin lorem en artboards Paper ni app.
5. Panel coach mantiene mismos tokens (no “admin theme” gris aparte).

08 — Design system — VOLTA

1. Fundamentos

2. Color tokens

Marca (fuente de verdad del caso)

Mapeo Tailwind app

3. Tipografía

4. Espaciado y radio

5. Componentes

5.1 Botones

Estados: default · hover (strong) · disabled (opacidad) · focus visible ring.

5.2 Badges de estado

Regla a11y: no codificar solo con color; siempre texto del label.

5.3 Badges de ClassType

5.4 Cards de solicitud (inbox)

Estructura:

1. Meta: code · classType (xs bold, muted o lime)
2. Nombre completo (lg semibold)
3. Día preferido · franja
4. Email / teléfono
5. Badge status (trailing)

5.5 Stats summary

Layout: grid 2–4 cards compactas sobre la lista.

5.6 Form fields

5.7 Header

6. Layout patterns

7. Iconografía

L1: preferir tipografía y badges; iconos mínimos si se usan (stroke 1.5–2, ink). No librería obligatoria.

8. Motion

9. Do / Don’t

09 — Guía de contenido — VOLTA

1. Voz y tono

Registro

2. Glosario de producto (copy)

3. Microcopy por pantalla

Home

Join (/apuntarme)

Success (/ok)

Login

Inbox

Detail

4. Labels de enums (UI)

5. Principios de redacción

1. Una idea por frase en marketing.
2. Verbos de acción en botones (no “OK” / “Submit”).
3. Errores con siguiente paso (“Reintenta”, “Revisa…”).
4. No inventar stats de mercado; si hay promesa de servicio, etiquetarla como hipótesis de producto.
5. Español peninsular neutro (es-ES); sin anglicismos innecesarios salvo HIIT, JWT en footer técnico.

6. Contenido de demo / seed (nombres)

Coach: Nora Beltrán · coach@volta.club

7. Accesibilidad de copy

• Badges con texto, no solo color.
• Alt de hero descriptivo.
• Placeholders no sustituyen labels.
• Errores asociados al campo cuando sea posible.

10 — Accesibilidad — VOLTA

1. Objetivo

Orientar la UI a WCAG 2.2 AA en lo razonable para un vertical slice L1.
No se afirma auditoría formal certificada; se listan requisitos y checks manuales.

2. Principios aplicados

3. Color y contraste

Prohibido: transmitir estado solo con color (badges llevan label).

4. Tipografía y legibilidad

5. Teclado y foco

6. Formularios

7. Imágenes y media

8. Auth y áreas coach

9. Checklist de verificación manual (QA)

10. Deuda a11y aceptada L1

11. Criterio de aceptación

La demo es usable con teclado en form y login; contraste principal cumple intención AA; estados no dependen solo del color.

11 — Privacidad y seguridad — VOLTA

1. Contexto

VOLTA trata datos de contacto y preferencias de clase de visitantes (PII ligera) y credenciales del coach.
Alcance L1 demo: no es un DPIA formal; documenta decisiones de diseño y controles implementados.

2. Datos tratados

3. Superficies de exposición

4. Controles de seguridad implementados

5. Autorización

6. Privacidad (RGPD — orientación)

No se afirma cumplimiento RGPD certificado. Es un mapa de riesgos para el case.

7. Amenazas y mitigaciones

8. Logging y secretos

9. Checklist de seguridad demo

10. Evolución recomendada (no deuda L1)

• Rate limiting + captcha en POST público
• Consent checkbox + política de privacidad
• Rotación JWT / refresh
• Soft-delete y retención configurable
• Audit log de cambios de status

12 — Analytics y métricas — VOLTA

1. Objetivo

Definir el modelo de medición del producto.
En v1 L1 la instrumentación puede ser mínima o nula en código; las métricas guían producto y roadmap.

No se reportan dashboards con números inventados como si fueran producción.

2. North Star

3. Árbol de métricas

4. Eventos propuestos (schema)

5. Funnels

Funnel visitante

home_viewed → join_started → join_submitted → join_succeeded → (offline) contact → CONFIRMED

Funnel coach

login → inbox_viewed → request_opened → status_changed(CONTACTED|CONFIRMED)

6. Segmentos

7. Implementación v1 vs futura

8. KPIs de éxito del case (demo)

9. Ética de medición

• No trackear notas libres con PII hacia terceros sin base legal.
• No inventar “conversión 37%” en el portfolio.
• Separar métrica modelo vs dato medido.

13 — Plan de QA y pruebas — VOLTA

1. Alcance

Validar el vertical slice L1: form público, success, login coach, inbox, detalle, estados, empty/error, seed Neon.

2. Entorno

3. Smoke tests (obligatorios)

4. Casos funcionales ampliados

Público

Coach

UI estados

5. Regresión visual (manual)

6. Seguridad smoke

Ver 11-privacy-security.md checks S1–S5.

7. Accesibilidad smoke

Ver 10-accessibility.md A1–A8.

8. Criterios de salida (release demo)

• S1–S12 OK
• Sin 500 en flujos felices
• Docs de case enlazadas
• Paper referenciado

9. Automatización futura

10. Datos de prueba recomendados

Además del seed:

14 — Handoff de desarrollo — VOLTA

1. Fuentes de verdad

2. Setup local (checklist)

1. Node LTS instalado.
2. Clonar/usar volta-app.
3. Copiar apps/api/.env.example → .env con DATABASE_URL (Neon) y JWT_SECRET.
4. npm install --prefix apps/api && npm install --prefix apps/web.
5. Migrar y seed.
6. npm run api (:3008) y npm run web (:4200).
7. Smoke S2, S4, S6, S11, S12 (doc 13).

3. Contratos que no romper

Cambios de contrato → actualizar docs 04, 05, 20 y Paper si afecta UI.

4. Mapa pantalla → API → modelo

5. Tokens UI a respetar

No sustituir por tema default de Angular Material sin brief de diseño.

6. Convenciones de código

7. Definition of Done (feature)

• API + validación DTO
• UI con tokens y microcopy ES
• Empty/error si aplica lista
• Doc actualizada si cambia dominio
• Smoke manual del flujo
• Sin secretos en git

8. Ambientes

9. Contacto de dominio (roles ficticios demo)

10. Riesgos de implementación

15 — Roadmap — VOLTA

1. Principio

El L1 del día está cerrado. Este roadmap no es deuda del alcance 2026-08-08; son opciones de evolución con subida de complejidad o polish.

2. Hecho (L1 — 2026-08-08)

3. L1+ (misma complejidad, mejoras)

4. L2 (nuevo brief)

5. L3+ (explícitamente mayor)

6. No-roadmap (fuera de VOLTA)

7. Priorización sugerida si hay continuidad

1. L1+01 guards + L1+06 e2e
2. L1+02 filtros + L1+08 contact shortcuts
3. L1+04 anti-spam si hay tráfico real
4. Evaluar L2 calendario solo con uso coach real

8. Métricas que desbloquean L2

16 — Especificaciones de interacción — VOLTA

1. Convenciones

2. Home

Estados: solo estáticos (marketing).

3. Join form

4. Success

5. Login

6. Inbox

Stats chips

Solo lectura en v1; click no filtra (filtro = L1+).

7. Request detail

Mapa de acciones sugerido

[DECISIÓN DE DISEÑO]: L1 puede mostrar las tres acciones siempre; el PATCH acepta el enum completo.

8. Responsive

9. Feedback y errores (copy interactivo)

10. Accesibilidad de interacción

• No usar solo hover para info crítica.
• Botones reales (button / a), no div clickable sin role.
• Mantener orden de tab natural en form y detail.

17 — Mapa de prototipo — VOLTA

1. Qué es “prototipo” en este case

2. Paper → rutas

Ver inventario completo: 00-paper-reference.md.

3. Flujos clicables en app

[Home] --Apuntarme--> [Join] --submit--> [Success] --inicio--> [Home]
[Home] --Coach------> [Login] --OK-----> [Inbox] --card--> [Detail] --status--> [Detail]
[Inbox] --Salir-----> [Login]

4. Datos del prototipo

5. Limitaciones del prototipo v1

6. Guión de demo (3 minutos)

1. Home — eslogan, clases, promesa.
2. Apuntarme — HIIT, día, 19:00, enviar.
3. Success — mostrar VO-….
4. Login coach@volta.club / password123.
5. Inbox — stats + lista seed + nueva.
6. Detail Marc o la nueva — CONTACTED → CONFIRMED.
7. (Opcional) empty/error si se demuestran estados.

7. Assets de prototipo

8. Criterio “prototype complete”

• Todos los must-have de flujo implementados en Angular
• Paper referencia bandas §1–§5
• Seed coherente con personas
• Microcopy ES sin lorem

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

1. Alcance auditado

Vertical slice L1: web club de barrio + solicitud pública de plaza + panel coach JWT, con docs, Paper, Angular+Nest+Prisma+Neon.

2. Checklist CRON / ALS-2

3. Cobertura funcional

4. Cobertura Paper

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

6. Huecos aceptados (no regresiones de cierre)

7. Veredicto

COMPLETO para entrega de caso 2026-08-08 con documentación portfolio y app alineada al brief.
Cualquier ampliación multi-sede/pagos/marketplace requiere nuevo brief de diversidad, no parche silencioso.

19 — Backlog completo — VOLTA

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

1. Done — L1 (2026-08-08)

2. Backlog L1+ (misma complejidad, mejoras)

3. Backlog L2 (requiere brief nuevo)

4. Backlog L3+ (explícito)

5. Explicitamente no-backlog

6. Orden de ataque recomendado (si hay continuidad)

1. B01 guards + B06 e2e + B11 env
2. B08 contact shortcuts + B02 filtros
3. B03 + B09 si hay tráfico real
4. Evaluar brief L2 calendario

7. Trazabilidad

20 — Implementación — VOLTA

1. Resumen ejecutivo técnico

2. Cómo arrancar

cd /Users/cristian/orca/volta-app
npm install --prefix apps/api
npm install --prefix apps/web
# Configurar apps/api/.env con DATABASE_URL y JWT_SECRET
npm --prefix apps/api run prisma:migrate   # o script documentado en README app
npm --prefix apps/api run prisma:seed
npm run api   # http://localhost:3008
npm run web   # http://localhost:4200

Credenciales

3. Módulos API implementados

Auth

• POST /api/auth/login
• Valida email/password; compara bcrypt; emite JWT con sub, email, role.
• JwtStrategy + JwtAuthGuard protegen requests de lectura/escritura coach.

Requests

Prisma

Enums Role, RequestStatus, ClassType; modelos alineados a doc 05; migración init; seed 1 coach + 5 requests.

4. Frontend implementado

ApiService centraliza base URL http://localhost:3008/api, token storage (volta_token, volta_user), métodos HTTP tipados (ClassRequest, stats, User).

5. Decisiones de implementación

6. Variables de entorno

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

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

1. Seed OK en consola (VOLTA seed OK).
2. Login coach 200.
3. List length ≥ 1.
4. Create request 201 + code.
5. Patch CONTACTED/CONFIRMED 200.
6. GET sin token 401.
7. Web muestra badges y home con Syne/lime.

8. Estructura de ficheros clave

volta-app/
├── apps/api/
│   ├── prisma/schema.prisma
│   ├── prisma/seed.ts
│   └── src/
│       ├── main.ts
│       ├── app.module.ts
│       ├── auth/
│       │   ├── auth.controller.ts
│       │   ├── auth.service.ts
│       │   ├── jwt.strategy.ts
│       │   └── jwt-auth.guard.ts
│       ├── requests/
│       │   ├── requests.controller.ts
│       │   └── requests.service.ts
│       └── prisma/
├── apps/web/
│   ├── tailwind.config.js
│   └── src/app/
│       ├── app.routes.ts
│       ├── core/api.service.ts
│       └── pages/
│           ├── home/
│           ├── join/
│           ├── success/
│           ├── login/
│           ├── inbox/
│           └── request-detail/
└── package.json

9. Alineación case ↔ app

10. Notas de cierre técnico

• Vertical slice L1 runnable local con Neon.
• No quedan features must-have del brief sin implementar.
• Mejoras (guards Angular, e2e, rate limit) viven en backlog L1+, no como deuda de cierre del día.