00-day-brief.md

00 — Day brief · 2026-08-13 · PIZARRA

Decisiones ALS-2 BRIEF

Terna unicidad

R-CL · S-CMD · H-SEARCH · F-SEARCH

Cumple memory §6.5: ≥2 códigos distintos vs N−1 (PRIMA) y vs N−2 (CANTERA). Ventana de 4 días recupera R-CL (faltaba tras PRIMA híbrido).

Directivas aplicadas

• D-P0-01…08, D-P1-01 (≥12 UX Paper), D-P0-08 (≥10 UI), D-P1-05 JWT COORD
• Tipografía Newsreader + Atkinson Hyperlegible (evitar Outfit, Archivo, Fraunces, Syne)
• Paleta chalky — tiza / pizarra / musgo / rail — no slate/teal, no limestone, no wine
• Home no es hero 2-col + 3 cards (AP-12). La superficie principal es la barra de búsqueda + resultados facetados.

Alcance L2 must

1. Home search-first: query + chips de disciplina / distrito / precio / accesibilidad
2. Ficha de taller con foto real, aforo, horario, sede
3. Formulario público de solicitud (solicitud ≠ plaza confirmada)
4. Success con código PZ-MMDD-NNN
5. Login + inbox COORD JWT (estados NEW → CONTACTED → ENROLLED / WAITLIST / CANCELLED)
6. Empty / loading / error / mobile search
7. ≥12 UX + ≥10 UI artboards Paper

Supuestos documentados

• S1: Un distrito tipo Usera–Vallecas publica 8–20 talleres por trimestre (rango operativo, no dato de campo).
• S2: El vecino llega con una pregunta (“cerámica los martes cerca”) no a “explorar marca”.
• S3: La coordinación municipal necesita cola con estado, no un LMS ni pagos online.
• S4: Cupo visible reduce llamadas; la inscripción definitiva sigue siendo administrativa.

Hipótesis

Anti-patrones evitados

• AP-12 plantilla VOLTA/RELE (hero 2-col + lista badges)
• AP-16 UI thin (se planifican 12 UI)
• AP-08 UX thin (12 boards canónicos)
• No L3, no kanban, no wizard campo

Mood visual (Paper)

• Candidatos: chalky · chapel · bookish · botanical · mineral
• Elegido: chalky (no el primer instinto “bookish biblioteca”) — la metáfora es la pizarra del aula, no el folio.
• Paleta: #E4EAF2 polvo · #1A231E pizarra · #D4A017 tiza · #3F6B5A borrador · #D7D0C2 rail · #EEF2F8 papel
• Tipo: Newsreader 56/40/28 display · Atkinson 16/14 UI

00-paper-reference.md

Paper reference · PIZARRA

UX-count: 12 UI-count: 12

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

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

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

1. Mapa de canvas (bandas)

Layout canvas (referencia de diseño): origen (0,0) · gaps ~100–120px · UX en 3×4 · UI pública en fila search → ficha → form → success.

2. Mapeo Paper → Angular

3. Tokens de diseño en Paper

4. Checklist de densidad (anti thin-frames)

5. Media

• assets/hero.jpg
• assets/taller-ceramica.jpg
• assets/taller-escritura.jpg
• assets/taller-teatro.jpg
• assets/taller-cocina.jpg
• assets/taller-robotica.jpg
• assets/taller-musica.jpg

6. Enlaces

• Paper: https://app.paper.design/file/01KZWYWE6BFRD96MAAF8HQWJ78
• Case: /Users/cristian/orca/ux-projects/2026-08-13-pizarra/
• App: /Users/cristian/orca/pizarra-app/
• GitHub: https://github.com/Criscode2022/pizarra-app
• Neon project: crimson-voice-36926751

01-project-definition.md

01 — Definición de proyecto — PIZARRA

1. Identidad

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] La vecindad descubre talleres en carteles, PDFs trimestrales y listados institucionales difíciles de filtrar. Llega con una pregunta (“cerámica los martes cerca”), no a explorar marca. [SUPUESTO] La coordinación municipal recibe llamadas y correos sin cola, sin código de referencia y sin estado compartido.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Un distrito tipo Usera–Vallecas publica 8–20 talleres por trimestre (rango operativo, no dato de campo).
• S2: El vecino llega con una pregunta concreta, no a “explorar marca”.
• S3: La coordinación necesita cola con estado, no un LMS ni pagos online.
• S4: El cupo visible reduce llamadas; la inscripción definitiva sigue siendo administrativa.

Hipótesis de producto

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

3. Propuesta de valor

No es PIZARRA

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L2 cívico search-first con catálogo Workshop + SeatRequest + JWT COORD.
• Portfolio coherente: Paper (12 UX + 12 UI) + docs + app runnable.
• Recuperar registro R-CL y shell S-CMD frente a PRIMA (S-SIDE / H-DATA / F-KAN).

Usuario

No objetivos v1 (explícitos)

• Pago de tasas
• Cuenta de vecino / “mis solicitudes”
• Aforo en tiempo real multi-sede sincronizado con mostrador
• Chat in-app o notificación email transaccional
• CMS de talleres para editores de distrito
• Calendario iCal / recordatorios

5. Roles y permisos (resumen)

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

7. Alcance funcional v1 (L2)

8. Criterios de aceptación de producto

1. Un visitante puede buscar y filtrar talleres sin autenticación y abrir una ficha.
2. Un visitante puede enviar una solicitud sin cuenta y recibir un código PZ-….
3. La UI dice explícitamente que la solicitud no confirma plaza.
4. Sin token, GET/PATCH /api/requests* responden 401.
5. GET /api/workshops acepta query q y facetas (discipline, district, price, accessibility).
6. Un COORD puede iniciar sesión y ver el inbox ordenado (createdAt desc) con stats.
7. El detalle permite transicionar NEW | CONTACTED | ENROLLED | WAITLIST | CANCELLED.
8. La home es la búsqueda: no hay hero 2-col + 3 cards como superficie principal.
9. Distritos cubiertos en seed: Usera, Vallecas, Latina, Carabanchel, Villaverde, Arganzuela.
10. Fotos de taller reales en fichas (assets del case).

9. Stack y artefactos

10. Riesgos y mitigaciones

11. Glosario

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

02-ux-research-strategy.md

02 — Estrategia de investigación UX — PIZARRA

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 centros cívicos, programaciones trimestrales y colas de inscripción presencial.
• Analogía operativa con catálogos search-first + inbox JWT de la serie daily.
• Restricciones ALS-2: sector cívico libre; no LMS; no kanban; no wizard de campo.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: coordinación de programa / dirección de centro.
• Usuario frecuente de captura: vecina (search + form) y COORD (inbox diario).
• Riesgo de rechazo: si la home no deja buscar en el primer viewport, o si el form implica “ya estás inscrita”.

4. Personas

P1 — Rosa Belmonte · Vecina / participante

Escenario: Abre PIZARRA, escribe “cerámica”, chip Usera, entra a Barro de Usera, solicita plaza, guarda PZ-0813-001.

[DECISIÓN DE DISEÑO] Rosa no tiene cuenta. Crear usuario municipal sería fricción y no aporta al job de captura.

P2 — Inés Marzal · COORD

Escenario: Login → inbox → Rosa NEW → llama → CONTACTED → si hay silla ENROLLED; si el grupo está lleno WAITLIST.

Anti-personas

5. JTBD y user stories

Job principal (vecina)

Cuando quiero un taller municipal cerca y que encaje (día, precio, accesibilidad),
quiero buscarlo y dejar mis datos en un solo paso,
para que coordinación me contacte sin perder el mensaje y sin creer que ya tengo plaza.

Job principal (COORD)

Cuando llegan solicitudes de plaza,
quiero verlas con taller, distrito y estado,
para contactar en 48 h e inscribir o poner en espera sin overbooking.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L2)

6. Journey (vecina → COORD)

Momentos de verdad

1. Search en el primer viewport — si hay que “descubrir el catálogo”, se rompe S2 [HIPÓTESIS].
2. Disclaimer en form y success — si falta, H2 falla.
3. Código PZ- — prueba de “ha llegado” para ventanilla y llamada.
4. WAITLIST visible — evita la mentira social del “ya te apunto”.

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

PIZARRA se diseña como catálogo cívico con cola de contacto, no como campus ni como sede electrónica.
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 — PIZARRA

1. Principios de IA

2. Sitemap

/                                 Home search (público)  ?q & disciplina & distrito & precio & acceso
/talleres/:slug                   Ficha de taller (público)
/talleres/:slug/solicitar         Formulario de solicitud (público)
/ok                               Success post-solicitud (público)
/login                            Login JWT COORD
/inbox                            Lista + stats (auth COORD)
/inbox/:id                        Detalle + estado (auth COORD)
/**                               → redirect /

Árbol por audiencia

3. Navegación

Pública (S-CMD)

[DECISIÓN DE DISEÑO] No hay mega-menú de concejalías ni “Áreas de gobierno”. Eso copiaría sede electrónica y rompería R-CL excelente (aula, no portal).

COORD (autenticado)

No hay sidebar multi-sección en v1 (evita IA de CRM / S-SIDE de PRIMA).

4. Inventario de contenido

5. Taxonomía

RequestStatus

Orden de inbox: createdAt descendente (más reciente primero).
[DECISIÓN DE DISEÑO] No se ordena por “prioridad de empadronamiento” en v1 (Q5 abierta).

Discipline

District

PriceBand (faceta)

AccessibilityTag (faceta, multi)

Las etiquetas de accesibilidad del seed son atributos de producto, no una auditoría real de cada centro [SUPUESTO de catálogo demo].

6. Modelo mental vs UI

7. Query string (contrato de search)

[DECISIÓN DE DISEÑO] Facetas en URL para compartir / volver atrás. Combinación AND. Texto q es AND con facetas.

8. Rutas API alineadas a IA

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — PIZARRA

Convenciones

• Actor: Guest (vecina) | COORD
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico: F-SEARCH

F1 — Descubrimiento por búsqueda (Guest)

/  → focus en campo search (H-SEARCH)
   → escribe query y/o activa chips
   → GET /api/workshops?q=&discipline=&district=&price=&access=
   → grid de cards  |  empty  |  error  |  skeleton
   → click card → /talleres/:slug
   → (nav discreta) "Coordinación" → /login

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

Errores / estados

F2 — Entender taller (Guest)

/talleres/:slug → GET /api/workshops/:slug
               → foto, aforo, horario, sede, precio, a11y, disclaimer
               → CTA "Solicitar plaza" → /talleres/:slug/solicitar
               → 404 slug → mensaje + volver a search

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

F3 — Solicitar plaza (Guest, público)

/talleres/:slug/solicitar
  → validación cliente
  → POST /api/requests {
        workshopId,
        fullName, email, phone?,
        residentDistrict?,
        notes?,
        accessNeed?
     }
  → 201 SeatRequest { code, status: NEW, ... }
  → /ok?code=PZ-…

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

Errores

[DECISIÓN DE DISEÑO] No se bloquea el POST aunque seats estén cubiertos: el vecino puede entrar en WAITLIST después, por decisión COORD. Bloquear en cliente mentiría sobre el mostrador.

F4 — Success (Guest)

/ok → copy de acuse + code
    → “Esto no confirma la plaza”
    → CTA volver a buscar / ir al taller

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

F5 — Login JWT (COORD)

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

Éxito: token guardado; user role=COORD, nombre Inés Marzal.
Credencial demo: coord@pizarra.ayto / password123.

F6 — Inbox + stats (COORD)

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

[DECISIÓN DE DISEÑO] Stats son de lectura en v1; el click no filtra (filtro inbox = L2+).

F7 — Detalle y cambio de estado (COORD)

/inbox/:id
  → GET /api/requests/:id
  → UI: contacto + taller + seats + nº solicitudes del taller + notas
  → PATCH /api/requests/:id/status { status }
  → 200 SeatRequest actualizado

Transiciones típicas (máquina simple L2)

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

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

F8 — Logout (COORD)

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

Matriz de errores global

Flujos fuera de alcance v1

• Registro / recuperación de password de COORD
• “Mis solicitudes” por código público
• Notificación email automática
• Filtros multi-criterio en inbox
• Asignación multi-COORD por distrito
• Pago de tasa
• Edición de catálogo Workshop por UI

05-data-model.md

05 — Modelo de datos — PIZARRA

1. Visión general

Dominio L2 de catálogo cívico + cola de plaza:

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

2. Enums

Role

RequestStatus

Discipline

CERAMICS | WRITING | THEATRE | COOKING | ROBOTICS | MUSIC

District

USERA | VALLECAS | LATINA | CARABANCHEL | VILLAVERDE | ARGANZUELA

PriceBand

FREE | FEE — derivado de feeCents en queries; no hace falta persistirlo si se calcula.

AccessibilityTag

STEP_FREE | LOOP | SEATED | LARGE_PRINT

3. Diagrama ER (texto)

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

Workshop
  id, slug (unique), title, summary, description
  discipline, district, venue, address
  scheduleLabel, startsOn, endsOn
  seats, feeCents
  accessTags String[]   // AccessibilityTag
  imageKey              // p.ej. taller-ceramica.jpg
  createdAt, updatedAt
  1 ──< SeatRequest

SeatRequest
  id, code (unique)
  workshopId → Workshop
  fullName, email, phone?
  residentDistrict?
  notes, accessNeed?
  status (default NEW)
  createdAt, updatedAt

No hay FK entre SeatRequest y User en v1: el form es anónimo. COORD opera sobre el conjunto global.

4. Tablas / modelos Prisma

User

Workshop

SeatRequest

5. Reglas de integridad y negocio

6. Contratos API (resumen)

GET /api/workshops (público)

Query: q?, discipline?, district?, price? (FREE|FEE), access?

Response 200: Workshop[] (campos de card + ficha; sin PII).

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

Workshop o 404.

POST /api/requests (público)

Body

Response 201: SeatRequest + workshop embebido mínimo (title, slug, district).

POST /api/auth/login

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

GET /api/requests (JWT)

Array SeatRequest + workshop, createdAt desc.

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

{
  "total": 6,
  "open": 3,
  "waitlist": 1,
  "byStatus": {
    "NEW": 2,
    "CONTACTED": 1,
    "ENROLLED": 1,
    "WAITLIST": 1,
    "CANCELLED": 1
  }
}

open = NEW + CONTACTED.

GET /api/requests/:id (JWT)

SeatRequest + workshop (seats) + enrolledCount del taller (agregado) o 404.

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

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

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

COORD

Workshops

Nombres de centros y horarios son contenido de producto demo, no programación oficial publicada [SUPUESTO de catálogo].

SeatRequests

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

8. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — PIZARRA

1. Visión

Stack fijo del cron. No React/Next/Firebase.

2. Estructura

pizarra-app/
├── apps/api/     # Nest + Prisma (independiente)
└── apps/web/     # Angular + Tailwind (independiente)

D-P1-03: npm --prefix, sin workspaces npm.

3. API pública vs JWT

4. Justificación

Angular + Nest alinean con el resto de la serie y con el handoff del estudio. Neon serverless encaja con un catálogo municipal de volumen bajo. Search-first no requiere Elasticsearch: ILIKE + índices de disciplina/distrito bastan para 8–20 talleres.

5. Variables

.env local (nunca git): DATABASE_URL, JWT_SECRET, PORT=3013. .env.example solo placeholders.

07-creative-direction.md

07 — Dirección creativa — PIZARRA

Mood

Chalky — pizarra de aula municipal al final de clase. No bookish (biblioteca) ni mineral (obra).

Candidatos descartados: chapel, botanical, mineral, bookish.

Paleta

Tipo

• Display: Newsreader 600 — institucional, editorial de centro cívico.
• UI: Atkinson Hyperlegible 400/700 — legibilidad cívica, no moda.

Evita Outfit, Archivo, Fraunces, Syne (cooldown).

Principios

1. La búsqueda es el monumento, no un hero 2 columnas.
2. Radio 6–10px. Sin píldoras atléticas.
3. Foto real del taller, nunca color sólido.
4. Copy honesto: solicitud ≠ plaza.
5. Contraste AA sobre polvo de tiza; labels ≥13px.

08-design-system.md

08 — Design system — PIZARRA

Tokens

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

Componentes

Estados

Empty, loading, error, validación email, 401 inbox, aforo 0 → WAITLIST.

No usar

Rounded-full lime, hero 2-col, badges genéricos de “SaaS”, emoji como icono.

09-content-guide.md

09 — Guía de contenido — PIZARRA

Voz

Municipal, cercana, concreta. Segunda persona de usted evitada: tuteo vecinal. Sin jerga de LMS.

Palabras permitidas / prohibidas

Microcopy clave

• Home: «¿Qué taller buscas?»
• Disclaimer: «Pedir plaza no confirma inscripción.»
• Success: «Guarda este código. No estás inscrita todavía.»
• Empty: «Nada con esos filtros.»
• Error: «Tu búsqueda se conserva. Reintenta.»
• Inbox: «Cola del trimestre · aforo real»

Códigos

Formato PZ-MMDD-NNN. Se lee en voz alta. No UUID.

Idioma

es-ES. Futuro: fácil lectura / EN no en v1.

10-accessibility.md

10 — Accesibilidad — PIZARRA

Objetivo: WCAG 2.2 AA. No se declara conformidad legal certificada.

Decisiones

Facetas de a11y de producto

Filtro «rampa / ascensor / bucle / planta baja» describe la sede, no sustituye auditoría física.

Riesgos

• Demasiados chips en móvil: wrap + fieldset.
• Chalk #D4A017 solo como fondo de botón con texto ink (no texto chalk 13px sobre dust).
• Status bar iOS en Paper no es producto.

QA a11y (mínimo)

1. Navegar home → ficha → form solo teclado.
2. Lighthouse a11y ≥ 90 en search.
3. Contraste de chips on/off.
4. Lector: legend de disciplina anunciado.

11-privacy-security.md

11 — Privacidad y seguridad — PIZARRA

No es un dictamen legal.

Datos

Sin datos de salud, menores con tutor, ni pagos.

Base (supuesto de diseño)

Interés público / misión de servicio cultural + consentimiento de contacto al enviar. Texto del form debe mencionarlo.

Retención

Solicitudes: 24 meses (hipótesis operativa). Luego borrado o anonimización. Demo Neon no es producción.

Seguridad v1

• TLS hacia Neon.
• JWT COORD, expiración por defecto Nest/passport.
• Validación DTOs.
• Público no lista PII.
• ENROLLED incrementa aforo una vez (evita overbooking).
• Secretos fuera de git.

Riesgos

Demo con emails ficticios. Si se publica, rotar JWT_SECRET y no reutilizar Neon de demo.

12-analytics.md

12 — Analítica — PIZARRA

North star

% de solicitudes con taller + email válidos que pasan a CONTACTED ≤ 48 h.

Eventos

Funnel

Land → search (resultado>0) → view_workshop → submit → contacted ≤48h → enrolled.

No vanity

Pageviews de home no son éxito. Un PDF institucional ya tenía visitas.

Privacidad

Sin fingerprinting. Eventos sin email en claro en analytics v1 (hash o solo code).

13-qa-test-plan.md

13 — Plan de pruebas — PIZARRA

Smoke obligatorio (D-P1-06)

1. GET /api/workshops → ≥6 ítems.
2. POST /api/requests con slug real → código PZ-.
3. POST /api/auth/login coord@pizarra.ayto / password123 → accessToken.
4. GET /api/requests Bearer → incluye el POST.
5. ng build OK.

Casos

Hipótesis a validar (no en demo)

H1 facetas bajan abandono. H2 copy honesto baja reclamaciones. H3 WAITLIST evita overbooking.

14-dev-handoff.md

14 — Handoff desarrollo — PIZARRA

Arranque

cd pizarra-app
# apps/api/.env con DATABASE_URL + JWT_SECRET + PORT=3013
npm --prefix apps/api install
npm --prefix apps/web install
npm --prefix apps/api run prisma:generate
npm --prefix apps/api run prisma:migrate
npm --prefix apps/api run prisma:seed
npm run api    # :3013
npm run web    # :4200

Demo: coord@pizarra.ayto / password123.

Paridad Paper

Home = UI-01 (command + chips + hits). No clonar VOLTA hero 2-col.

Contratos

• Login responde accessToken (no snake_case).
• Search query: q, discipline, district, level, free.
• POST request: workshopSlug, fullName, email, phone?, notes?.

No hacer

Workspaces npm. Commit de .env. Prometer plaza en copy.

15-roadmap.md

15 — Roadmap — PIZARRA

Hecho en L2 (esta ejecución)

Search + facetas, ficha, solicitud, success, JWT COORD, aforo/WAITLIST, estados, Paper ≥12+12, Neon, docs.

Fuera de alcance L2 (no deuda del día)

• Pagos / TPV
• Cl@ve
• App nativa
• Menores con tutor digital
• Multi-distrito multi-tenant
• Email transaccional real
• Export CSV (Could)

Estas son subidas de nivel, no parches del L2.

16-interaction-specs.md

16 — Especificación de interacción — PIZARRA

Home search

• Enter en la barra dispara búsqueda (mismo que CTA).
• Chip toggle: segundo click quita faceta.
• Hits: fila completa clicable a /taller/:slug.
• Loading: 3 skeletons, query visible.
• Empty: mantiene query; CTA limpia facetas.

Ficha

• CTA primario si seatsLeft > 0: «Solicitar plaza».
• Si 0: «Apuntarme a lista de espera».
• Disclaimer siempre visible antes del CTA.

Form

• Submit deshabilitado si nombre <2 o email inválido.
• Error de red: botón reintentar, no limpia campos.
• Success navega /ok?code=.

Inbox

• Sin token → /login.
• Acciones de estado: confirmación solo en CANCELLED.
• ENROLLED: si aforo lleno, UI avisa y API rechaza o espera.

Motion

150–200ms fade en resultados. Sin scroll-jacking.

17-prototype-map.md

17 — Mapa de prototipo — PIZARRA

Paper no es clicable vía MCP. El prototipo vivo es la app Angular.

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

18-completeness-audit.md

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

1. Alcance auditado

Vertical slice L2: catálogo municipal search-first + solicitud pública de plaza + panel COORD JWT, con docs, referencia Paper, contratos 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 documental)

7. Veredicto

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

19-backlog-completo.md

19 — Backlog completo — PIZARRA

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 (2026-08-13)

2. Backlog L2+ (misma complejidad, implementación / polish)

3. Backlog L3 (requiere brief nuevo)

4. Backlog explícitamente fuera

5. Explicitamente no-backlog

6. Orden de ataque recomendado (si hay continuidad de código)

1. Implementar contratos docs 05–06 + seed 05
2. B01 guards + B06 e2e + B10 env
3. B03 aforo + B08 contact
4. B04 + B05 si hay tráfico
5. Evaluar brief L3 distrito / CMS

7. Trazabilidad

20-implementation.md

20 — Implementación — PIZARRA

1. Resumen ejecutivo técnico

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

2. Cómo arrancar

cd /Users/cristian/orca/pizarra-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
npm --prefix apps/api run prisma:seed
npm run api   # http://localhost:3013
npm run web   # http://localhost:4200

Credenciales

3. Módulos API a implementar

Auth

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

Workshops (público)

Filtros: texto contains insensitive en title, summary, venue; facetas AND; price=FREE ⇒ feeCents = 0; access ⇒ accessTags has.

Requests

Prisma

Enums Role, RequestStatus, Discipline, District; modelos alineados a doc 05; migración init; seed 1 COORD + 6 workshops + 6 requests.

Generación de código

PZ- + MMDD (UTC o Europe/Madrid **[DECISIÓN: Europe/Madrid]**) + - + NNN

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

4. Frontend a implementar

ApiService centraliza base URL http://localhost:3013/api, token storage (pizarra_token, pizarra_user), métodos tipados (Workshop, SeatRequest, stats, User).

5. Decisiones de implementación

6. Variables de entorno

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

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

1. Seed OK (PIZARRA seed OK).
2. GET workshops length 6.
3. GET ?q=ceramica&district=USERA devuelve Barro de Usera.
4. Login COORD 200.
5. List length ≥ 1.
6. Create request 201 + code PZ-.
7. Patch CONTACTED / WAITLIST / ENROLLED 200.
8. GET requests sin token 401.
9. Web: search dominante, disclaimer, badges, fotos.

8. Estructura de ficheros clave

pizarra-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
│       ├── workshops/
│       │   ├── workshops.controller.ts
│       │   └── workshops.service.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-search/
│           ├── workshop-detail/
│           ├── request-seat/
│           ├── success/
│           ├── login/
│           ├── inbox/
│           └── request-detail/
└── package.json

9. Seed — checklist de implementación

10. Alineación case ↔ app

11. Notas de cierre técnico

• El case documental L2 está cerrado (docs + Paper ref + contratos).
• Must-have de producto del brief están especificados con AC.
• Mejoras (guards Angular, e2e, rate limit, check aforo) viven en backlog L2+, no como deuda silenciosa.
• Este encargo no modifica Paper, el repo pizarra-app, memory.md ni el registry.