00-day-brief.md

00 — Day brief · 2026-08-16 · CESTA

Decisiones ALS-2 BRIEF

Terna unicidad

R-CL · S-RAIL · H-TABLE · F-LEAD

0 códigos iguales a N−1 (RONDA). ≥2 distintos vs N−2 (DERIVA). Ventana 4 días ya tenía R-HY e R-IN; hoy R-CL. Experimento §8: tabla densa / ONG.

Mood visual (Paper)

• Candidatos: charity cream+naranja (primer instinto), chapel, botanical, mineral, bookish
• Elegido: botanical — no el primer instinto (warm off-white × terracotta, cliché y vetado)
• Paleta: #E6EFDD hueso · #1C2418 tierra · #3D6B4A musgo · #7A9A6A hoja · #C4B49A saco · #B23A2F ficha
• Tipo: Spectral 52/36/24 display · Manrope 16/14 UI

Alcance L1 must

1. Home: tabla de 5 necesidades (foto, ítem, pedido, comprometido, hueco)
2. Fila → compromiso (nombre, email, cantidad) — compromiso ≠ entrega
3. Success CE-MMDD-NNN
4. Login + inbox STAFF JWT (NEW → RECEIVED / PARTIAL / CANCELLED)
5. Empty / loading / error / mobile tabla apilada
6. ≥12 UX + ≥10 UI

Supuestos

• S1: Una despensa de barrio cubre 8–20 líneas activas (demo: 5).
• S2: El vecino llega con “qué falta”, no a donar dinero.
• S3: La coordinadora necesita cola con estado, no un CRM de donantes.
• S4: La entrega se confirma en el local; CESTA no cobra.

Hipótesis

00-paper-reference.md

Paper reference · CESTA

UX-count: 12 UI-count: 11

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

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. CESTA no es wizard: el núcleo es tabla → 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 tabla → ficha → compromiso → success · mobile debajo de la tabla. [DECISIÓN] Bandas jerárquicas D-P0-04 / D-P1-04.

2. Mapeo Paper → Angular

[COMPROBADO] Rutas del encargo. No hay /inbox/:id, search, mapa, feed ni hero 2-col.

3. Tokens de diseño en Paper

[COMPROBADO] Hex y tipo salen de docs/00-day-brief.md.

4. Checklist de densidad (anti thin-frames)

5. Media

• assets/hero.jpg — atmósfera de despensa / cesta / local vecinal
• assets/needs/arroz.jpg — Arroz redondo
• assets/needs/aceite.jpg — Aceite de oliva
• assets/needs/tomate.jpg — Tomate en conserva
• assets/needs/panales.jpg — Pañales T3
• assets/needs/leche.jpg — Leche entera

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

6. Enlaces

• Paper: https://app.paper.design/file/01M04P0VFWGX1DQVSCR5TPWM9Z
• Case: /Users/cristian/orca/ux-projects/2026-08-16-cesta/
• App: /Users/cristian/orca/cesta-app/
• GitHub: https://github.com/Criscode2022/cesta-app
• Neon project: jolly-night-99671179
• API: http://localhost:3016
• Web: http://localhost:4200

01-project-definition.md

01 — Definición de proyecto — CESTA

1. Identidad

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

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] Quien quiere ayudar a la despensa no abre un marketplace ni un Bizum: pregunta “qué falta” en un grupo de WhatsApp, un cartel del local o un mensaje que se pierde. [SUPUESTO] La coordinadora confirma cajas por mensaje suelto, sin cola, sin código y sin ver el hueco (pedido − comprometido) en un solo vistazo.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Una despensa de barrio cubre 8–20 líneas activas (demo: 5). [SUPUESTO]
• S2: El vecino llega con “qué falta”, no a donar dinero. [SUPUESTO]
• S3: La coordinadora necesita cola con estado, no un CRM de donantes. [SUPUESTO]
• S4: La entrega se confirma en el local; CESTA no cobra. [SUPUESTO]

Hipótesis de producto

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

3. Propuesta de valor

No es CESTA

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L1 ONG table-first con Need + Request + JWT STAFF.
• Portfolio coherente: Paper (12 UX + 11 UI) + docs + app runnable.
• Terna R-CL · S-RAIL · H-TABLE · F-LEAD frente a RONDA (feed) y DERIVA (mapa).

Usuario

No objetivos v1 (explícitos)

• Pagos, Bizum, socio mensual, certificado fiscal
• Cuenta de vecino / “mis compromisos”
• Chat, matching o reputación de donantes
• Mapa de despensas / multi-sede
• Notificación email / WhatsApp transaccional
• Inventario de almacén (entradas/salidas/lote)
• CMS de necesidades para editoras
• Multi-staff con roles editoriales

5. Roles y permisos (resumen)

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

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 ver la tabla densa sin autenticación y abrir una ficha.
2. Un visitante puede enviar un compromiso sin cuenta y recibir un código CE-….
3. La UI dice explícitamente que el compromiso no confirma entrega.
4. Sin token, GET/PATCH /api/requests* responden 401.
5. GET /api/needs devuelve las 5 necesidades seed.
6. Un STAFF puede iniciar sesión y ver el inbox ordenado (createdAt desc).
7. El inbox permite transicionar NEW | CONTACTED | RECEIVED | PARTIAL | CANCELLED.
8. La home es la tabla: no hay hero 2-col + 3 cards como superficie principal.
9. Slugs cubiertos en seed: arroz, aceite, tomate, panales, leche.
10. Fotos de ítem reales en filas y fichas (assets del case).
11. Hueco visible = pedido − comprometido; no se vende como stock ERP.
12. Rutas públicas solo las seis del encargo (doc 03).

9. Stack y artefactos

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

10. Riesgos y mitigaciones

11. Glosario

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

13. Relación con el día anterior

[COMPROBADO] El brief exige 0 códigos iguales a N−1 y ≥2 distintos vs N−2. Terna de hoy: R-CL · S-RAIL · H-TABLE · F-LEAD. Ventana 4 días ya tenía R-HY e R-IN; hoy R-CL.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — CESTA

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 despensas de barrio, bancos de alimentos de proximidad y grupos de WhatsApp de donación en especie.
• Analogía operativa con tablas densas + form público + inbox JWT de la serie daily.
• Restricciones ALS-2: no feed, no mapa, no search-first, no pagos, no CRM de donantes.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: coordinadora de la despensa (quien abre el local).
• Usuario frecuente de captura: VECINO (tabla + form) y STAFF (inbox del día).
• Riesgo de rechazo: si la home no enseña el hueco en el primer viewport, o si el form implica “ya está entregado”.

4. Personas

P1 — Rosa Belmonte · VECINO

Escenario: Abre CESTA, ve Aceite de oliva con hueco, entra a la ficha, compromete 3 L, guarda CE-0816-001.

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

P2 — Inés Marzal · STAFF

Escenario: Login antes de abrir → inbox → Rosa NEW → escribe / llama → CONTACTED → el sábado RECEIVED (o PARTIAL si trajo menos).

[COMPROBADO] Edad, rol y credencial salen del encargo / brief.

Anti-personas

5. JTBD y user stories

Job principal (VECINO)

Cuando quiero ayudar a la despensa del barrio,
quiero ver qué falta y dejar una cantidad con mi nombre,
para que coordinación me contacte sin perder el mensaje y sin creer que ya entregué.

Job principal (STAFF)

Cuando se acercan el día de entrega y empiezan a llegar compromisos,
quiero verlos con ítem, cantidad y estado,
para contactar antes de abrir y anotar recibido o parcial sin inventar stock.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L1)

6. Journey (VECINO → STAFF)

Momentos de verdad

1. Tabla en el primer viewport — si hay que “descubrir la marca”, se rompe S2. [HIPÓTESIS]
2. Disclaimer en form y success — si falta, H2 falla.
3. Código CE- — prueba de “ha llegado” para el mostrador y el mensaje.
4. RECEIVED / PARTIAL visibles — evita la mentira social del “ya cuenta como stock”.
5. Rail no esconde Inbox — Inés antes de abrir no busca un menú hamburger. [HIPÓTESIS]

7. Service blueprint (resumen)

Fallos de servicio y respuesta de diseño

8. Matriz hallazgo → requisito → feature

9. Preguntas abiertas (no bloquean v1)

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

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

11. Síntesis

CESTA se diseña como lista de lo que falta con cola de compromiso, no como crowdfunding, no como inventario y no como feed de impacto.
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 — CESTA

1. Principios de IA

2. Sitemap

/                                      Tabla de necesidades (público)  H-TABLE
/necesidades/:slug                     Ficha de necesidad (público)
/necesidades/:slug/comprometer         Formulario de compromiso (público)
/ok/:code                              Success post-compromiso (público)
/login                                 Login JWT STAFF
/inbox                                 Lista de compromisos (auth STAFF)
/**                                    → redirect /

Árbol por audiencia

[COMPROBADO] Seis rutas del encargo. No se inventan /inbox/:id, /buscar, /mapa, /donar.

3. Navegación

Rail de iconos (S-RAIL)

[DECISIÓN] El rail es la única navegación primaria. Tres destinos: encaja L1 compacto. No hay top-nav de 7 ítems, no dock flotante (RONDA), no command search (PIZARRA).

Desktop ≥960px: rail vertical izquierdo (~56–64px) + panel de tabla.
Mobile ~390px: rail compacto inferior o superior de iconos; la tabla se apila (UI-10). [DECISIÓN] En 390 el rail no compite con un hamburger.

Pública (además del rail)

STAFF (autenticado)

[DECISIÓN] L1: el PATCH vive en la fila del inbox. No se añade /inbox/:id.

4. Inventario de contenido

5. Taxonomía

RequestStatus

Orden de inbox: createdAt descendente (más reciente primero).
[DECISIÓN] No hay WAITLIST: el hueco es numérico, no una silla.

NeedUnit

Need (líneas seed)

[COMPROBADO] Slugs y cantidades salen del encargo.

6. Modelo mental vs UI

7. Query string

L1 table-first no usa facetas de catálogo.
Único query admitido: /login?next=/inbox (redirect post-login).

[DECISIÓN] Sin ?q= ni chips. Eso sería H-SEARCH (PIZARRA).

8. Rutas API alineadas a IA

[COMPROBADO] Contrato del encargo. No se documentan /api/requests/stats ni POST /api/needs como Must.

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — CESTA

Convenciones

• Actor: Guest (VECINO) | STAFF
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico: F-LEAD (compromiso público → cola staff)

F1 — Descubrimiento por tabla (VECINO)

/  → tabla de necesidades (H-TABLE)
   → GET /api/needs
   → filas densas  |  empty  |  error  |  skeleton
   → click fila → /necesidades/:slug
   → rail Inbox / Entrar → /login  (si guest)

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

Errores / estados

F2 — Entender necesidad (VECINO)

/necesidades/:slug → GET /api/needs/:slug
                   → foto, unidad, pedido, comprometido, hueco, disclaimer
                   → CTA "Comprometer" → /necesidades/:slug/comprometer
                   → 404 slug → mensaje + volver a la tabla

Éxito: CTA visible; disclaimer “comprometer no confirma entrega” visible antes del form.
Error: 404 si slug inexistente.

AC ficha

[DECISIÓN] Hueco 0 no oculta el CTA: el vecino puede comprometer de más; STAFF decide. Copy: “El hueco puede haberse cubierto; te contactamos igual.”

F3 — Comprometer (VECINO, público)

/necesidades/:slug/comprometer
  → validación cliente
  → POST /api/requests {
        needSlug,
        name,
        email,
        quantity,
        note
     }
  → 201 Request { code, status: NEW, ... }
  → /ok/:code

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

Errores

[DECISIÓN] No se bloquea el POST aunque hueco sea 0. Bloquear en cliente mentiría sobre el mostrador (Q4).

[COMPROBADO] Body del POST = { needSlug, name, email, quantity, note } según encargo.

F4 — Success (VECINO)

/ok/:code → copy de acuse + code
          → “Esto no confirma la entrega”
          → CTA volver a la tabla / ir a la ficha

AC: el código es seleccionable; el disclaimer es visible sin scroll en desktop.
Si se entra a /ok/algo-que-no-existe sin haber POST: se muestra el código de la URL + copy genérico; no se inventa un registro. [DECISIÓN] Success es acuse de UI, no lookup público (lookup = L2+).

F5 — Login JWT (STAFF)

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

Éxito: token guardado; user role=STAFF, nombre Inés Marzal.
Credencial demo: ines@cesta.barrio / password123.

F6 — Inbox (STAFF)

/inbox (token en cliente)
  → GET /api/requests
  → Render filas + badges + acciones

[DECISIÓN] Sin stats endpoint en v1 (no está en el contrato API). Recuentos, si se muestran, se derivan del array.

F7 — Cambio de estado (STAFF, en la lista)

/inbox
  → PATCH /api/requests/:id { status }
  → 200 Request actualizado

Transiciones típicas (máquina simple L1)

Éxito: badge actualizado en la fila.
Errores: 404 id; 401 sin token; 400 status inválido.

Regla de integridad H3 (ops, no trigger DB v1): RECEIVED / PARTIAL no mutan requestedQty del Need. El hueco se calcula por suma de quantity no CANCELLED. Ajuste fino de kilos = L1+.

[COMPROBADO] PATCH body = { status } sobre /api/requests/:id.

F8 — Logout (STAFF)

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

Matriz de errores global

Flujos fuera de alcance v1

• Registro / recuperación de password de STAFF
• “Mis compromisos” por código público
• Notificación email automática
• Filtros multi-criterio en inbox
• Detalle /inbox/:id
• Pago / Bizum
• Alta de Need por UI

05-data-model.md

05 — Modelo de datos — CESTA

1. Visión general

Dominio L1 de tabla de necesidades + cola de compromiso:

Base: PostgreSQL (Neon project jolly-night-99671179) · IDs: cuid() o entero serial.
[DECISIÓN] ensureSchema o Prisma son válidos si el contrato de tablas se cumple; el brief de stack no exige Prisma.

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

Role

RequestStatus

NeedUnit

kg | L | ud | packs

3. Diagrama ER (texto)

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

sessions
  id, user_id → users
  token_hash, expires_at
  created_at

needs
  id, slug (unique), title, summary, description
  unit, requested_qty, image_key
  created_at, updated_at
  1 ──< requests

requests
  id, code (unique)
  need_id → needs          -- o need_slug
  name, email
  quantity
  note
  status (default NEW)
  created_at, updated_at

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

4. Tablas

users

sessions

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

needs

committed_qty y gap no se persisten: se calculan. [DECISIÓN]

requests

5. Reglas de integridad y negocio

6. Contratos API (resumen)

GET /api/needs (público)

Response 200: Need[] con campos de fila + agregados:

{
  "slug": "aceite",
  "title": "Aceite de oliva",
  "unit": "L",
  "requestedQty": 24,
  "committedQty": 3,
  "gap": 21,
  "imageKey": "aceite.jpg",
  "summary": "…"
}

JSON camelCase hacia el web. [DECISIÓN]

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

Need o 404. Incluye description.

POST /api/requests (público)

Body

Response 201: Request + need embebido mínimo (title, slug, unit) + code + status: "NEW".

[COMPROBADO] Campos del body = encargo.

POST /api/auth/login

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

GET /api/requests (JWT)

Array Request + need, createdAt desc. Sin token → 401.

PATCH /api/requests/:id (JWT)

Body: { status: RequestStatus }
Response: Request actualizado. Sin token → 401.

[COMPROBADO] PATCH sobre :id con { status }, no /status.

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

STAFF

[COMPROBADO] Credencial del encargo.

Needs

[COMPROBADO] Cinco líneas del encargo.
Textos de summary / description son contenido de producto demo, no inventario de una despensa real. [SUPUESTO de catálogo]

Requests

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

8. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — CESTA

1. Visión

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

2. Estructura

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

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

Scripts raíz esperados:

3. API pública vs JWT

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

[COMPROBADO] Superficie API del encargo. No se añaden Must extra (/stats, POST /needs).

4. Justificación

5. Variables

.env local (nunca git):

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

6. Dependencias de producto (mínimas)

API

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

Web

• Angular standalone
• Tailwind 3
• fuentes: Spectral + Manrope (Google Fonts o self-host)

7. Arranque (contrato)

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

8. Lo que este stack no es

9. Nota sobre el repo existente

[COMPROBADO] Existe /Users/cristian/orca/cesta-app y el remoto Criscode2022/cesta-app.
El scaffold puede contener restos de un producto anterior (rutas /mesas, GET /tables). Esta suite define el contrato CESTA; el código debe alinearse a las rutas y API de los docs 03–05, no al leftover. [DECISIÓN]

07-creative-direction.md

07 — Dirección creativa · CESTA

Mood: botanical (musgo wash #E6EFDD × soil). No charity naranja. Superficie = tabla, no hero 2-col.

Spectral display + Manrope UI. Rail 72px tierra. Hueco en #B23A2F. Fotos de despensa reales por línea.

08-design-system.md

08 — Design system · CESTA

Tokens: bone #E6EFDD soil #1C2418 moss #3D6B4A leaf #7A9A6A sack #C4B49A alert #B23A2F.

Componentes: rail, tabla (5 columnas fijas), fila con foto 56×40, CTA suelo, estados empty/loading/error.

09-content-guide.md

09 — Guía de contenido — CESTA

1. Voz

Cercana de barrio, concreta, de mostrador. Tuteo. Segunda persona.
Sin jerga de fundraising (“impacto premium”), sin sede electrónica, sin “haz tu donación ahora”.

El producto informa y recoge un compromiso, no vende una causa.

2. Palabras permitidas / prohibidas

3. Microcopy clave (literales de producto)

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

4. Códigos

Formato CE-MMDD-NNN. Se lee en voz alta en el mostrador: “ce, ocho dieciséis, cero cero uno”.
No UUID. No QR obligatorio en v1.

5. Nombres propios del seed

No inventar reseñas, CIF ni horarios oficiales de una despensa real. [SUPUESTO de catálogo demo]
Franja demo: sábado 10–13. No se afirma como horario de un local existente.

6. Tono por estado

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

7. Capitalización y números

• Wordmark: CESTA en versales.
• Cantidades: 40 kg, 24 L, 36 ud, 12 packs (espacio fino entre número y unidad).
• Hueco: 21 L (misma unidad que el pedido).
• No mezclar “litros” en UI si la unidad es L; en ficha se puede expandir “litros”.

8. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar “need” en UI. En API sí: needSlug, needs.

9. Accesibilidad de copy

• No transmitir estado solo con color (“el rojo significa parcial”).
• Badge lleva texto: Nuevo, Contactado, Recibido, Parcial, Cancelado.
• Alt de fotos: “Botellas de aceite de oliva”, no “imagen1”.

10. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad — CESTA

Objetivo: WCAG 2.2 AA. No se declara conformidad legal certificada.
Este documento cubre la UI (tabla, form, rail, inbox). No audita la accesibilidad física del local demo. [SUPUESTO]

1. Decisiones

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

3. Teclado

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

4. Semántica

5. Lector de pantalla — copy

6. Producto vs local físico

[DECISIÓN] v1 no incluye faceta a11y de sede (eso era PIZARRA). El campo note permite “voy con carrito” sin fingir auditoría.

7. Riesgos

8. QA a11y (mínimo)

9. Criterios de aceptación

1. Ningún control del rail o CTA mide menos de 44×44 CSS px.
2. El disclaimer no depende del color musgo para ser entendido.
3. Las 5 fotos seed tienen alt no vacío y no genérico.
4. El foco no se pierde al reintentar un error de red.
5. En 390 la tabla no obliga a scroll horizontal para leer el hueco.

11-privacy-security.md

11 — Privacidad y seguridad — CESTA

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

1. Datos

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

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

2. Base (supuesto de diseño)

[SUPUESTO] Interés de la despensa en coordinar entregas en especie + consentimiento de contacto al enviar el form.
El texto del form debe mencionarlo:

Usaremos tu nombre y email solo para escribirte por este compromiso.

No se cede a redes de fundraising, no se usa para marketing de terceros, no se pide IBAN.

3. Minimización

[COMPROBADO] Body público = { needSlug, name, email, quantity, note }. Sin phone.

4. Retención

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

5. Autorización

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

JWT

1. Login válido → bcrypt compare → emite JWT (sub, email, role).
2. Request protegida → verifica firma.
3. Logout → limpia cliente; si hay sessions, se invalida el sid.

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

6. Seguridad v1

7. Amenazas y respuesta

8. Credencial demo

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

9. Riesgos residuales (aceptados L1)

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

10. Criterios de aceptación

1. GET /api/requests sin Authorization → 401.
2. PATCH /api/requests/:id sin token → 401.
3. GET /api/needs no incluye emails de vecinos.
4. Response de login no incluye password_hash.
5. .env no se commitea.
6. /ok/:code no revela email ni nota.

12-analytics.md

12 — Analítica — CESTA

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

1. North star

% de compromisos válidos (nombre + email + need existente) que pasan a CONTACTED antes de la franja de entrega (sábado demo).

Por qué no “kilos recaudados” ni “pageviews”:

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

2. Hipótesis ↔ señales

3. Eventos

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

4. Funnel

Land tabla → need_opened → commit_started → commit_submitted
           → staff_login → status_changed(CONTACTED) ≤ franja
           → status_changed(RECEIVED)  |  PARTIAL

5. Invariantes (salud, no vanity)

6. Dimensiones

Sin user-id de vecino.

7. Privacidad de analítica

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

8. Qué no medimos en v1

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

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

13-qa-test-plan.md

13 — Plan de pruebas — CESTA

1. Smoke obligatorio (D-P1-06)

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

2. Casos funcionales

3. Datos de prueba

4. Regresión de diversidad / craft

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

H1, H2, H3 requieren uso real. El QA verifica que existen las superficies que permitirían medirlas (tap en fila, disclaimer, badge RECEIVED + pedido inmutable).

6. Criterios de salida QA v1

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

7. Fuera de este plan

Playwright e2e completo, carga, fuzzing, auditoría del local físico.

14-dev-handoff.md

14 — Handoff desarrollo — CESTA

1. Arranque

cd /Users/cristian/orca/cesta-app

# apps independientes (npm --prefix o pnpm --filter)
# apps/api/.env
#   DATABASE_URL=  # Neon jolly-night-99671179
#   JWT_SECRET=
#   PORT=3016

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

Demo: ines@cesta.barrio / password123.

2. Paridad Paper

No clonar RONDA (feed + dock), DERIVA (mapa split) ni PIZARRA (command search).

3. Contratos

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

4. Mapa de rutas web

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

[COMPROBADO] Solo estas seis rutas. No implementar /inbox/:id, /mesas, /donar.

5. Assets

Copiar desde el case:

2026-08-16-cesta/assets/hero.jpg
2026-08-16-cesta/assets/needs/*.jpg
  → apps/web/public/assets/needs/   (o src/assets/needs/)

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

6. DoD implementación L1

7. No hacer

8. Contactos de diseño (artefactos)

15-roadmap.md

15 — Roadmap — CESTA

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

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

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

3. L1+ (misma complejidad, polish)

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

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

4. L2 / L3 (requiere brief nuevo de diversidad)

• Multi-sede / varias despensas
• Cuenta VECINO y “mis compromisos”
• Email / WhatsApp transaccional
• CMS de necesidades
• Inventario ERP (lotes, caducidad)
• Check DB transaccional de hueco
• Audit log
• Search o mapa como home (rompería terna)

5. Explícitamente fuera (no backlog disfrazado)

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

1. Contratos 05–06 + seed 05 + smoke 13
2. Web paridad UI-00…10 (sustituir leftover)
3. Guards + mailto + clipboard
4. Rate limit si hay tráfico
5. Evaluar brief L2 (no parche silencioso)

16-interaction-specs.md

16 — Especificación de interacción — CESTA

1. Convenciones

2. Rail (S-RAIL)

Estado activo: disco tierra + icono hueso.
Estado default: tierra sobre saco/hueso.

Slots: Lista / · Inbox /inbox · Entrar /login (o Salir si auth).

3. Tabla home

AC: la primera fila (foto + hueco) está en el viewport inicial a 390 y a 1280 (sin hero de 60vh).

Orden visual = seed / title ASC. No “destacados”.

Columnas desktop: foto · ítem · pedido · comprometido · hueco.
Numéricos: tabular-nums, alineados a la derecha, unidad visible.

390 (UI-10): pila — [foto 56] [título] + fila de tres metas pedido / comprometido / hueco.

4. Ficha

5. Form compromiso

Submit deshabilitado si nombre < 2, email inválido o quantity ≤ 0.

6. Success

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

El :code de la ruta se pinta tal cual. No lookup PII.

7. Login

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

8. Inbox

No swipe-to-archive. No navegación a /inbox/:id.

9. Estados (acciones en lista)

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

RECEIVED no anima un “stock +N”. H3.

10. Motion

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

11. Criterios de aceptación de interacción

1. Un VECINO en 390px llega de tabla a success en ≤ 4 taps (fila, CTA, submit → success).
2. Un STAFF en 390px marca CONTACTED en ≤ 3 taps desde inbox (acción en fila).
3. Ningún submit permite doble POST.
4. El rail no cubre el CTA de ficha (padding).
5. Reduced-motion elimina stagger.
6. La home no es hero 2-col (AP-12).
7. En 390 el hueco se lee sin scroll horizontal.

17-prototype-map.md

17 — Mapa de prototipo — CESTA

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

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

Recorrido demo (guión)

1. Abrir / — tabla de 5 líneas, rail Lista activo.
2. Tocar Aceite de oliva — ficha + disclaimer.
3. Comprometer — form 3 L, Rosa Belmonte.
4. Success /ok/CE-… — código + “todavía no has entregado”.
5. /login — ines@cesta.barrio / password123.
6. /inbox — marcar Contactado / Recibido / Parcial.

Estados en el mismo prototipo

Fuera del prototipo clicable

• Paper artboards son estáticos.
• WhatsApp / llamada de Inés (backstage).
• Entrega física del sábado.
• Lookup público de PII por código.

18-completeness-audit.md

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

1. Alcance auditado

Vertical slice L1: tabla densa de necesidades de despensa vecinal + compromiso público + panel STAFF JWT, con docs, referencia Paper, contratos Angular + Nest + Neon.

Este encargo cubre la suite documental. Paper hi-fi y el repo cesta-app pueden existir en paralelo; la auditoría marca lo que esta suite cierra. El day brief no se ha sobrescrito.

2. Checklist CRON / ALS-2

3. Cobertura funcional

4. Cobertura Paper (literales del brief)

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

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

6. Huecos aceptados (no regresiones de cierre documental)

7. Veredicto

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

19-backlog-completo.md

19 — Backlog completo — CESTA

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

1. Done — L1 case documental (2026-08-16)

2. Backlog L1 implementación (repo cesta-app)

3. Backlog L1+ (polish)

4. Backlog L2 / L3 (requiere brief nuevo)

5. Backlog explícitamente fuera

6. Explicitamente no-backlog

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

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

8. Trazabilidad

20-implementation.md

20 — Implementación — CESTA

1. Resumen ejecutivo técnico

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

[COMPROBADO] Path, puerto, Neon, Paper y GitHub salen del encargo.
[COMPROBADO] El repo existe; puede contener leftover de otro producto (/mesas, GET /tables). El contrato de esta suite es CESTA.

2. Cómo arrancar

cd /Users/cristian/orca/cesta-app
# instalar dependencias por app (no npm workspaces)

# apps/api/.env
#   DATABASE_URL=   # Neon jolly-night-99671179
#   JWT_SECRET=
#   PORT=3016

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

Credenciales

3. Schema

Al boot o vía migrate:

1. CREATE TABLE / migrate de users, needs, requests (doc 05).
2. Índices: needs(slug), requests(created_at DESC), requests(need_id, status), users(email).
3. Seed idempotente:
   • upsert STAFF ines@cesta.barrio (bcrypt de password123)
   • upsert 5 needs por slug
   • upsert requests por code

No borrar datos de usuario en cada boot si ya existen filas distintas al seed.

Tablas (recordatorio)

4. Módulos API a implementar

Auth

• POST /api/auth/login
• Valida email/password; compara bcrypt; emite JWT con sub, email, role.
• Guard JWT protege lectura/escritura de requests.

Needs (público)

Requests

Generación de código

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

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

[DECISIÓN] Timezone Europe/Madrid, no UTC, para que el código coincida con el mostrador.

Agregados

committedQty = SUM(quantity) WHERE status <> 'CANCELLED'
gap          = GREATEST(0, requestedQty - committedQty)

RECEIVED / PARTIAL no actualizan requested_qty.

5. Frontend a implementar

Shell: RailComponent persistente.
ApiService centraliza base URL http://localhost:3016/api, token storage (cesta_token, cesta_user), métodos tipados (Need, Request, User).

6. Decisiones de implementación

7. Variables de entorno

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

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

1. Schema OK (tablas existen).
2. GET /api/needs length ≥ 5, incluye arroz, aceite, tomate, panales, leche.
3. POST /api/requests 201 + code CE-.
4. POST /api/auth/login 200 + accessToken.
5. GET /api/requests Bearer incluye el POST.
6. GET /api/requests sin token 401.
7. PATCH /api/requests/:id { status: "RECEIVED" } 200 y requestedQty intacto.
8. Web: tabla dominante, rail, disclaimer, fotos.

9. Estructura de ficheros clave (objetivo)

cesta-app/
├── package.json
├── apps/api/
│   ├── src/
│   │   ├── main.ts
│   │   ├── app.module.ts
│   │   ├── auth/
│   │   ├── needs/
│   │   └── requests/
│   └── .env.example
├── apps/web/
│   ├── tailwind.config.js
│   └── src/app/
│       ├── app.routes.ts
│       ├── core/api.service.ts
│       ├── shell/rail.component.ts
│       └── pages/
│           ├── home/          # tabla
│           ├── need/
│           ├── commit/
│           ├── ok/
│           ├── login/
│           └── inbox/
└── README.md

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

10. Seed — checklist de implementación

11. Alineación case ↔ app

12. Notas de cierre técnico

• El case documental L1 está especificado (docs + Paper ref + contratos).
• Must-have de producto del brief están escritos con AC.
• Mejoras (guards Angular, e2e, rate limit) viven en backlog L1+, no como deuda silenciosa.
• Si el repo aún muestra feed de mesas, no está alineado: I01 es el primer ítem de build.