00-day-brief.md

00 — Day brief · 2026-08-17 · MARGEN

Decisiones ALS-2 BRIEF

Terna unicidad

R-CL · S-TOP · H-GALLERY · F-STORY

0 códigos iguales a N−1 (CESTA). ≥2 distintos vs N−2 (RONDA) y N−3 (DERIVA). Ventana 4 días ya tenía R-IN (DERIVA) y R-HY (RONDA); hoy R-CL editorial.

Ground (CRON §5.6)

• Familia: G-GALLERY
• Hex: #FFFFFF
• Por qué: kiosco / papel prensa. No es G-MOSS (CESTA), G-CHROME (RONDA), G-WATER (DERIVA), G-MUNICIPAL (PIZARRA) ni G-ICE (PRIMA).

Mood visual (Paper)

• Candidatos: bookish plaster×ink (primer instinto), chapel, candlelit, gallery / newsstand
• Elegido: gallery / newsstand — no el primer instinto bookish
• Paleta: #FFFFFF papel · #16141A tinta · #C41E3A cadmio · #5C5866 grafito · #F4F1EA pliego (solo cards) · #E8E4DC filete
• Tipo: Cormorant Garamond display · Public Sans UI (evita Newsreader / Outfit / Spectral / Manrope / Zilla / Mulish / Lora / Karla)

Alcance L2 must

1. Home lookbook: número en curso + ≥3 portadas/piezas con lead (visibles en recorte 16:10)
2. Ficha de crónica (kicker, título, cuerpo, crédito)
3. Agenda familiar de la semana (3 eventos reales)
4. Login + mesa EDITOR JWT (DRAFT → PUBLISHED)
5. Alta de pieza + success
6. Empty / loading / error / mobile lector
7. ≥12 UX + ≥10 UI

Microcopy duro

• Publicar ≠ imprimir. El número digital no es el tiraje de kiosco.
• Borrador ≠ publicado. La familia no ve DRAFT.
• Agenda ≠ inscripción. El evento se lee; no se reserva plaza (≠ PIZARRA).

Supuestos

• S1: Un semanario de barrio cierra 1 número / semana y 4–8 piezas (demo: 1 número + 4 piezas + 3 eventos).
• S2: La lectora llega por “qué hay esta semana”, no a suscribirse a un paywall.
• S3: La redacción es 1–2 personas; la mesa es lista de piezas, no un CMS enterprise.
• S4: No hay comentarios ni likes. El producto es lectura + publicación.

Hipótesis

00-paper-reference.md

Paper reference · MARGEN

UX-count: 12 UI-count: 12

UX-00 Cover · UX-01 Stakeholders · UX-02 Personas · UX-03 JTBD · UX-04 Stories · UX-05 Journey · UX-06 Blueprint · UX-07 Site map · UX-08 Flujos · UX-09 Datos+permisos · UX-10 Métricas · UX-11 Research UI-00 Tokens · UI-01 Lookbook · UI-02 Crónica · UI-03 Agenda · UI-04 Login · UI-05 Mesa · UI-06 Alta pieza · UI-07 Success · UI-08 Empty · UI-09 Error · UI-10 Loading · UI-11 Mobile lector

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. MARGEN no es wizard: el núcleo es lookbook → crónica → agenda y mesa → alta → publicar.

Paper se construye en paralelo a esta suite. Los nombres de la tabla son el inventario planificado; el file ID ya existe.

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 lookbook → crónica → agenda · mesa en fila login → lista → alta → success · mobile debajo del lookbook. [DECISIÓN] Bandas jerárquicas D-P0-04 / D-P1-04.

2. Mapeo Paper → Angular

[COMPROBADO] Rutas del encargo. No hay /inscribir, /comentarios, /suscribir, search-first ni hero 2-col.

3. Tokens de diseño en Paper

[COMPROBADO] Hex y tipo salen de docs/00-day-brief.md. Mood elegido: gallery / newsstand, no el primer instinto bookish plaster×ink.

4. Checklist de densidad (anti thin-frames)

5. Media

• assets/hero.jpg — atmósfera de kiosco / semanario abierto en mesa de cocina, café y cuaderno de niños
• assets/merienda.jpg — Patio de manzana, familias en banco de piedra, merienda
• assets/colegio.jpg — Puerta de CEIP, mochilas en la valla, espera de madres y padres
• assets/piscina.jpg — Vaso municipal de verano, bloques de ladrillo al fondo
• assets/biblioteca.jpg — Sala de lectura municipal, patio y cartel «Biblioteca Municipal»

[COMPROBADO] Los cinco archivos existen en el case 2026-08-17-margen/assets/.

6. Enlaces

• Paper: https://app.paper.design/file/01M078GFW7QQF5RRA2XGKQ8BD9
• Case: /Users/cristian/orca/ux-projects/2026-08-17-margen/
• App: /Users/cristian/orca/margen-app/
• GitHub: https://github.com/Criscode2022/margen-app
• Neon project: morning-truth-64427459
• API: http://localhost:3017
• Web: http://localhost:4200

01-project-definition.md

01 — Definición de proyecto — MARGEN

1. Identidad

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

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] La familia del sur de Madrid no abre un paywall ni un PDF institucional: pregunta “qué hay esta semana” en el grupo del cole, el del patio y el de la AMPA. El recado se pierde, el cartel se desactualiza y el “PDF del cole” circula en tres versiones. [SUPUESTO] La redacción de un semanario de barrio es 1–2 personas; no opera un CMS enterprise ni una mesa de inscritos.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Un semanario de barrio cierra 1 número / semana y 4–8 piezas (demo: 1 número + 4 piezas + 3 eventos). [SUPUESTO]
• S2: La lectora llega por “qué hay esta semana”, no a suscribirse a un paywall. [SUPUESTO]
• S3: La redacción es 1–2 personas; la mesa es lista de piezas, no un CMS enterprise. [SUPUESTO]
• S4: No hay comentarios ni likes. El producto es lectura + publicación. [SUPUESTO]

Hipótesis de producto

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

3. Propuesta de valor

No es MARGEN

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L2 editorial gallery-first con Issue + Piece + Event + JWT EDITOR.
• Portfolio coherente: Paper (12 UX + 11 UI) + docs + app runnable.
• Terna R-CL · S-TOP · H-GALLERY · F-STORY frente a CESTA (tabla/rail), RONDA (feed/dock) y DERIVA (mapa).

Usuario

No objetivos v1 (explícitos)

• Paywall, newsletter transaccional, cuenta de lectora
• Comentarios, likes, bookmarks
• Inscripción / cupo / WAITLIST
• Multi-número archivo con búsqueda
• CMS de tipos, taxonomías profundas, workflow de 5 estados
• Impresión / PDF de kiosco / punto de venta
• Multi-editor con roles (redactor / jefe / fotógrafo)
• App nativa ni notificaciones push

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: EDITOR. La lectora es anónima. AMPA no es un rol de sistema: es persona / stakeholder que usa la cara pública.

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 ver el lookbook del número sin autenticación y abrir una crónica.
2. Un visitante puede leer la agenda sin cuenta y sin encontrar un CTA de reserva o inscripción.
3. La UI dice explícitamente que publicar no es imprimir (success de mesa y, si cabe, pie de número).
4. Sin token, GET /api/mesa/pieces y POST/PATCH de piezas responden 401.
5. GET /api/issues/current devuelve el número PUBLISHED con ≥3 piezas publicadas.
6. GET /api/pieces/:slug de un DRAFT responde 404 (no 200 + aviso).
7. Un EDITOR puede iniciar sesión y ver la mesa con DRAFT y PUBLISHED.
8. El EDITOR puede crear una pieza y publicarla (DRAFT → PUBLISHED).
9. La home es galería: no hay hero 2-col + 3 cards como superficie principal.
10. Fotos reales en portada y piezas (assets del case).
11. Recorte 16:10 de las portadas es visible (no recorte 1:1 que recorta el lead).
12. Rutas públicas y de mesa solo las del 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 fija terna R-CL · S-TOP · H-GALLERY · F-STORY. S / H / F son 0 coincidencias con CESTA (S-RAIL · H-TABLE · F-LEAD). Ventana 4 días ya tenía R-IN (DERIVA) y R-HY (RONDA); hoy R-CL editorial, distinto de CESTA en shell, home y flujo. Ground G-GALLERY #FFFFFF, no G-MOSS.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — MARGEN

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 semanarios de barrio, grupos de WhatsApp de AMPA y cartelería de cole / biblioteca / piscina municipal.
• Analogía operativa con lookbook editorial + mesa JWT de la serie daily.
• Restricciones ALS-2: no tabla de leads, no feed, no mapa, no search-first, no inscripción, no paywall.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: la editora (quien cierra el número) y, en difusión, el AMPA (quien pega el enlace).
• Usuario frecuente de lectura: LECTORA (lookbook + ficha + agenda).
• Usuario frecuente de publicación: EDITOR (mesa).
• Riesgo de rechazo: si la home no enseña portadas en el primer viewport; si la agenda parece un formulario de plaza; si un DRAFT se filtra.

4. Personas

P1 — Elena Vargas · LECTORA

Escenario: Abre MARGEN, ve El patio no cierra en agosto, entra a La merienda que no cabe en el grupo, pasa a Agenda, anota Pradolongo el sábado. No se registra.

[DECISIÓN] Elena no tiene cuenta. Crear usuario de lectora sería fricción y contradice H3 / S2.

P2 — Nuria Ceballos · EDITOR

Escenario: Login → mesa → ve Lo que el AMPA no va a colgar en Stories en DRAFT → termina → Publicar → success con aviso de que no es el tiraje.

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

P3 — Raúl Méndez · AMPA

Escenario: Abre Agenda, ve Charla de vuelta al cole el lunes 18:00, copia el dato al grupo. No hay botón Inscribirse.

[DECISIÓN] Raúl no es rol de sistema. No hay login AMPA en L2. Evita convertir MARGEN en PIZARRA.

Anti-personas

5. JTBD y user stories

Job principal (LECTORA)

Cuando se acaba la semana y el grupo del cole echa humo,
quiero ver el número y leer qué pasa en el patio, el cole y el barrio,
para no perseguir el PDF ni enterarme el lunes de la merienda.

Job principal (EDITOR)

Cuando cierro el número del domingo,
quiero listar las piezas, escribir la que falta y publicarla,
para que la familia vea solo lo cerrado y yo no confunda borrador con kiosco.

Job principal (AMPA)

Cuando hay una cita de la semana (charla, merienda, cuento),
quiero que se lea en la agenda del número,
para difundirla sin que MARGEN se convierta en hoja de inscripción.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L2)

6. Journey (LECTORA → EDITOR)

Momentos de verdad

1. Portadas en el primer viewport — si hay que “descubrir la marca”, se rompe S2. [HIPÓTESIS]
2. Agenda sin botón de reserva — si aparece “Inscribirse”, H2 falla.
3. DRAFT invisible en público — prueba de “borrador ≠ publicado”.
4. Success de mesa dice que no es imprimir — evita la mentira del tiraje.
5. Masthead no esconde Agenda — Elena no busca un hamburger de 9 ítems. [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

MARGEN se diseña como semanario de barrio que se hojea y se publica, no como paywall, no como inscripción municipal y no como tabla de compromisos.
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 — MARGEN

1. Principios de IA

2. Sitemap

/                                      Lookbook del número (público)     H-GALLERY
/piezas/:slug                          Ficha de crónica (público si PUBLISHED)
/agenda                                Agenda familiar de la semana (público)
/login                                 Login JWT EDITOR
/mesa                                  Lista de piezas (auth EDITOR)
/mesa/nueva                            Alta de pieza (auth EDITOR)
/mesa/ok/:slug                         Success post-publicación (auth EDITOR)
/**                                    → redirect /

Árbol por audiencia

[COMPROBADO] Siete rutas del encargo L2. No se inventan /inscribir, /suscribir, /comentarios, /archivo, /mesa/:id.

3. Navegación

Masthead (S-TOP)

[DECISIÓN] El masthead es la única navegación primaria. Tres destinos públicos + mesa. Encaja L2 compacto. No hay rail (CESTA), no dock (RONDA), no command search (PIZARRA).

Desktop ≥960px: cabecera horizontal, filete cadmio 2px bajo el masthead, secciones en Public Sans 14.
Mobile ~390px: wordmark + 2–3 links; Mesa se compacta a “Mesa” o icono de escritorio. [DECISIÓN] En 390 no se introduce hamburger de 9 ítems.

Pública (además del masthead)

[DECISIÓN] La portada del número no abre un /numeros/:id en v1: el número es la home. Un archivo de números sería L+1.

EDITOR (autenticado)

[DECISIÓN] L2: el PATCH vive en la fila de la mesa y/o al final del form de alta. No se añade /mesa/:id como Must.

4. Inventario de contenido

5. Taxonomía

PublishStatus (Issue y Piece)

Orden de mesa: updatedAt descendente (lo último tocado primero).
[DECISIÓN] No hay SCHEDULED / REVIEW / KILLED: S3, mesa de 1–2.

PieceSection

Issue (línea seed)

Piece (líneas seed)

[COMPROBADO] Cuatro piezas + agenda de 3 y un DRAFT cubren el must del brief (demo: 1 número + 4 piezas + 3 eventos). El DRAFT extra es para que la mesa no sea una lista de solo publicados. [DECISIÓN]

EventAudience (texto libre en v1; valores seed)

No es un enum cerrado de producto: es copy. [DECISIÓN]

6. Modelo mental vs UI

7. Query string

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

[DECISIÓN] Sin ?q= ni chips de sección en home. Eso sería H-SEARCH (PIZARRA) o un archivo L+1.

8. Rutas API alineadas a IA

[COMPROBADO] Contrato del encargo (Issue, Piece, Event, EDITOR). No se documentan comentarios, likes ni POST /api/events como Must.

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — MARGEN

Convenciones

• Actor: Guest (LECTORA / AMPA) | EDITOR
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico: F-STORY (hojear número → leer crónica → agenda)
• Flujo de mesa: login → lista → alta → publicar

F1 — Descubrimiento por lookbook (LECTORA)

/  → lookbook del número (H-GALLERY)
   → GET /api/issues/current
   → portada 16:10 + ≥3 cards  |  empty  |  error  |  skeleton
   → click card → /piezas/:slug
   → masthead Agenda → /agenda
   → masthead Mesa / Entrar → /login  (si guest)

Éxito: al menos una ficha PUBLISHED alcanzable, o empty accionable.
AC: no hay que hacer scroll de “marca” para llegar a la primera portada. El recorte 16:10 deja ver el lead fotográfico (no un crop 1:1 que recorta cabezas).

Errores / estados

F2 — Leer crónica (LECTORA)

/piezas/:slug → GET /api/pieces/:slug
              → cover, kicker, título, cuerpo, crédito
              → enlace Número → /
              → enlace Agenda → /agenda
              → 404 slug DRAFT o inexistente → mensaje + volver al número

Éxito: crónica leíble; crédito visible; no hay comentarios ni likes.
Error: 404 si slug inexistente o status=DRAFT.

AC ficha

[DECISIÓN] Un DRAFT nunca hace 200 en esta ruta. No se “previsualiza” en público ni con query ?preview=. Preview = L+1 con token.

F3 — Agenda de la semana (LECTORA / AMPA)

/agenda → GET /api/events
        → 3 bloques (título, startsAt, place, audience)
        → disclaimer “Esto se lee; no es una inscripción.”
        → empty / error / skeleton

Éxito: 3 eventos visibles o empty honesto. Cero botones Inscribirse / Reservar / Apuntarme.

AC agenda

[DECISIÓN] Tap en evento no abre ficha de reserva. Si en L+1 hubiera detalle, seguiría siendo lectura.

F4 — Login JWT (EDITOR)

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

Éxito: token guardado; user role=EDITOR, nombre Nuria Ceballos.
Credencial demo: redaccion@margen.barrio / password123.

F5 — Mesa de redacción (EDITOR)

/mesa (token en cliente)
  → GET /api/mesa/pieces
  → Render filas + badges DRAFT / PUBLISHED + CTA Nueva

[DECISIÓN] Sin stats endpoint en v1. Recuentos DRAFT/PUBLISHED, si se muestran, se derivan del array.

F6 — Alta de pieza (EDITOR)

/mesa/nueva
  → validación cliente
  → POST /api/pieces {
        title,
        kicker,
        body,
        cover,
        section,
        issueId,        // default: current issue
        authorName      // default: user.name
     }
  → 201 Piece { slug, status: DRAFT, ... }
  → o bien POST + PATCH { status: "PUBLISHED" } si elige Publicar
  → /mesa/ok/:slug

Éxito: registro status=DRAFT (o PUBLISHED si eligió Publicar en el mismo viaje) + pantalla success.
No hay cuenta de lectora en v1.

Errores

[DECISIÓN] Crear siempre como DRAFT. El botón Publicar del form hace POST + PATCH (o un flag publishNow aceptado por el servidor que no salta el estado intermedio en disco: persiste PUBLISHED, pero el contrato documentado es POST DRAFT → PATCH PUBLISHED). [DECISIÓN de implementación] ver doc 20.

[COMPROBADO] Entidades Piece = { title, kicker, body, cover, section, issueId, status, authorName } según encargo.

F7 — Publicar desde la mesa (EDITOR)

/mesa
  → PATCH /api/pieces/:id { status: "PUBLISHED" }
  → 200 Piece actualizado
  → opcional: /mesa/ok/:slug si se quiere el board de success

Transiciones (máquina simple L2)

Éxito: badge actualizado; la pieza aparece en GET /api/issues/current.
Errores: 404 id; 401 sin token; 400 status inválido.

Regla de integridad (ops): Publicar no crea un PDF, un tiraje ni un Event. Publicar ≠ imprimir. Agenda ≠ inscripción.

F8 — Success de publicación (EDITOR)

/mesa/ok/:slug → copy de acuse + título/slug
               → “Publicar no es imprimir.”
               → “La familia ya puede leerla. El kiosco no ha tirado nada.”
               → CTA ver pieza pública / volver a la mesa

AC: el disclaimer es visible sin scroll en desktop.
Si se entra a /mesa/ok/algo-que-no-existe: mensaje genérico + volver a mesa; no se inventa un registro. [DECISIÓN]

F9 — Logout (EDITOR)

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

Matriz de errores global

Flujos fuera de alcance v1

• Registro / recuperación de password de EDITOR
• Cuenta de lectora / bookmarks
• Inscripción a Event
• Notificación email “ha salido el número”
• Filtros multi-criterio en mesa
• Detalle /mesa/:id
• Archivo de números
• Comentarios / likes
• Impresión / PDF de kiosco

05-data-model.md

05 — Modelo de datos — MARGEN

1. Visión general

Dominio L2 de semanario vecinal + mesa de publicación:

Base: PostgreSQL (Neon project morning-truth-64427459) · 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

PublishStatus

PieceSection

PATIO | COLE | BARRIO | LECTURA

3. Diagrama ER (texto)

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

sessions
  id, user_id → users
  token_hash, expires_at
  created_at

issues
  id, week_label (unique), title, cover, published_at
  status (DRAFT | PUBLISHED)
  created_at, updated_at
  1 ──< pieces
  1 ──< events

pieces
  id, slug (unique)
  issue_id → issues
  title, kicker, body, cover
  section (PATIO | COLE | BARRIO | LECTURA)
  status (DRAFT | PUBLISHED)
  author_name
  created_at, updated_at

events
  id
  issue_id → issues
  title, starts_at, place, audience
  created_at, updated_at

No hay FK entre pieces y users en v1: el byline es author_name texto. EDITOR 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.

issues

[DECISIÓN] GET /api/issues/current = el Issue PUBLISHED con published_at más reciente. En demo hay uno.

pieces

lead no se persiste: se deriva del primer párrafo de body (~160 caracteres) para las cards. [DECISIÓN]

events

Sin seats, enrolled, status. Agenda ≠ inscripción. [COMPROBADO]

5. Reglas de integridad y negocio

6. Contratos API (resumen)

GET /api/issues/current (público)

Response 200: Issue + pieces: PieceCard[] (solo PUBLISHED):

{
  "id": "issue_w33",
  "weekLabel": "17–23 ago",
  "title": "El patio no cierra en agosto",
  "cover": "hero.jpg",
  "publishedAt": "2026-08-17T05:00:00.000Z",
  "status": "PUBLISHED",
  "pieces": [
    {
      "slug": "merienda-en-el-banco",
      "title": "La merienda que no cabe en el grupo",
      "kicker": "Patio",
      "section": "PATIO",
      "cover": "merienda.jpg",
      "lead": "Familias se sientan en el banco de piedra…",
      "authorName": "Nuria Ceballos",
      "status": "PUBLISHED"
    }
  ]
}

JSON camelCase hacia el web. [DECISIÓN]
Si no hay Issue PUBLISHED: 404 o 200 con { pieces: [] } + empty de home. [DECISIÓN] 200 + empty es más amable para UI-08.

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

Piece completa (body) o 404 (inexistente o DRAFT).

GET /api/events (público)

Response 200: Event[] del current issue, startsAt asc.

{
  "id": "evt_merienda",
  "title": "Merienda de patio en Pradolongo",
  "startsAt": "2026-08-22T09:00:00.000Z",
  "place": "Parque de Pradolongo, Usera",
  "audience": "Familias"
}

POST /api/auth/login

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

GET /api/mesa/pieces (JWT)

Array Piece (sin necesidad de body largo; incluir status), updatedAt desc. Sin token → 401. Incluye DRAFT.

POST /api/pieces (JWT)

Body

Response 201: Piece + slug + status: "DRAFT".

PATCH /api/pieces/:id (JWT)

Body: { status?: PublishStatus, title?, kicker?, body?, cover?, section?, authorName? }
Mínimo Must: { status }.
Response: Piece actualizada. Sin token → 401.

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

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

EDITOR

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

Issue

Pieces

Textos de body / lead son contenido de producto demo, no reportaje de un diario real. [SUPUESTO de catálogo]

Events

Los tres eventos son seed de producto. No se presentan como calendario oficial de un distrito, un CEIP o una biblioteca concreta. [SUPUESTO de catálogo]

8. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — MARGEN

1. Visión

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

2. Estructura

margen-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 (/comments, POST /events, /subscribe).

4. Justificación

5. Variables

.env local (nunca git):

.env.example solo placeholders.
Web: URL de API en ApiService (default http://localhost:3017/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: Cormorant Garamond + Public Sans (Google Fonts o self-host)

7. Arranque (contrato)

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

8. Lo que este stack no es

9. Nota sobre el repo existente

[COMPROBADO] Existe /Users/cristian/orca/margen-app y el remoto previsto Criscode2022/margen-app.
El scaffold contiene leftover de otros productos (walks, requests, fotos de despensa CESTA en public/assets/needs/). Esta suite define el contrato MARGEN; 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 — MARGEN

1. Concepto

MARGEN es un kiosco de barrio en pantalla: semanario que se hojea, no una landing de “medio digital”. El ground es papel blanco de galería. Las portadas se cuelgan como en un expositor. El cadmio es la mancha de rotativa, no un botón de marketing.

Mood elegido: gallery / newsstand.
Primer instinto descartado: bookish plaster × ink (capilla, enyesado, vela). Ese mood ya huele a revista literaria de centro. MARGEN es patio, valla del cole y vaso municipal.

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

2. Territorio visual

3. Paleta

Jerarquía de color: el blanco carga; el cadmio puntúa; el pliego encuadra la foto. Si el cadmio pinta fondos enteros, deja de ser rotativa y se vuelve “brand red”. [DECISIÓN]

4. Tipografía

Prohibido: Cormorant por debajo de 20px (se rompe). Public Sans en el wordmark (se vuelve startup).

5. Fotografía

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

Crop: cards y portada en 16:10. El lead fotográfico (caras en el banco, mochilas, lámina de agua, mesa de lectura) debe quedar dentro del recorte. [COMPROBADO] Must del brief.

Tratamiento: saturación real, sin LUT “editorial teal-orange”, sin grano falso de película. El cadmio no se superpone como filtro: vive en UI.

6. Layout

Masthead (S-TOP)

MARGEN                         Número    Agenda    Mesa
17–23 ago · Usera · Carabanchel · Villaverde
────────────────────────────────────────────  (filete cadmio 2px)

Wordmark a la izquierda. Secciones a la derecha. Línea de distrito en Public Sans 12 grafito. Filete cadmio. No hamburger en desktop.

Home (H-GALLERY)

1. Bloque de número: weekLabel + título en Cormorant + portada 16:10 (hero.jpg).
2. Grid de piezas: 3 columnas desktop / 1 mobile. Card pliego: foto 16:10 + kicker + título + lead.
3. Cierre: enlace a Agenda, no un form.

La portada no comparte fila con un muro de copy (“Cómo funciona MARGEN”). Eso sería H-HERO2 / AP-12.

Ficha

Cover a ancho de columna de lectura (~680px), no full-bleed de marketing. Kicker → título → byline → cuerpo. Blancos verticales de semanario, no de landing.

Mesa

Lista densa sobre papel. No imita el lookbook. Es trastienda: filas, badges, CTA cadmio. El EDITOR no necesita “inspiración de marca” para publicar.

7. Motion

Prohibido: parallax en portada, scroll-jacking, page transitions de 400ms, sticker de “NEW” parpadeante.

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

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

Cercano de kiosco, concreto, de patio. Tuteo. Segunda persona cuando habla la UI. Tercera cuando habla la crónica.

El producto se hojea y se publica. No vende una comunidad, no pide plaza, no pide dinero.

10. Criterios de aceptación creativos

1. Ground de página = #FFFFFF. Cards = #F4F1EA. Nunca al revés.
2. Filete cadmio bajo el masthead, 2px, no un header rojo lleno.
3. ≥3 portadas/piezas con recorte 16:10 visible en el primer viewport desktop.
4. Ninguna fuente de la lista vetada (Newsreader / Outfit / Spectral / Manrope / Zilla / Mulish / Lora / Karla).
5. Home reconocible como kiosco, no como hero 2-col de startup.
6. Success de mesa no celebra un “número impreso”.

08-design-system.md

08 — Design system — MARGEN

1. Tokens

--color-paper:    #FFFFFF;   /* G-GALLERY ground */
--color-ink:      #16141A;
--color-cadmium:  #C41E3A;
--color-graphite: #5C5866;
--color-pliego:   #F4F1EA;   /* cards only */
--color-rule:     #E8E4DC;
--color-draft:    #5C5866;   /* badge DRAFT */
--color-live:     #C41E3A;   /* badge PUBLISHED */

--font-display: "Cormorant Garamond", Georgia, serif;
--font-ui:      "Public Sans", system-ui, sans-serif;

--radius-card: 0;            /* corte de kiosco, no pill */
--radius-cta:  2px;
--rule-mast:   2px solid var(--color-cadmium);
--space:       4 / 8 / 12 / 16 / 24 / 32 / 48 / 64;

Tailwind (referencia):

[COMPROBADO] Hex y tipo = brief.

2. Escala tipográfica

3. Componentes

Masthead

Slots: Número / · Agenda /agenda · Mesa /mesa · Entrar /login o Salir.

Card de pieza (lookbook)

┌─────────────────────────────┐
│ cover 16:10                 │
│                             │
├─────────────────────────────┤
│ KICKER                      │
│ Título en Cormorant         │
│ Lead 2–3 líneas Public Sans │
└─────────────────────────────┘

• Fondo pliego, sin sombra.
• Toda la card es un <a>.
• Hover: rule 1px grafito. Sin lift.
• Imagen object-fit: cover anclada al centro-arriba para no cortar caras.

Portada de número

• Ratio 16:10 obligatorio (must brief).
• Overlay opcional: weekLabel + título en papel sobre cadmio al 0% — preferible título fuera de la foto, debajo, para no pelear con hero.jpg. [DECISIÓN] Título bajo la foto.

Ficha de crónica

Evento (agenda)

Fila o card pliego con cuatro campos en este orden: cuándo · título · dónde · para quién.
Disclaimer de bloque, no de cada fila: “La agenda se lee. No es una inscripción.”

Fila de mesa

Badge DRAFT: texto grafito, rule filete.
Badge PUBLISHED: texto cadmio o papel sobre cadmio ≥14 bold.

Botones

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

Form

Labels visibles (no placeholder-only). Inputs h-44, radius 2, rule filete, foco outline 2px cadmio offset 2. Textarea cuerpo min 8 filas. Select de section y cover (allowlist de assets).

Estados

4. Grid y breakpoints

Padding horizontal: 24 desktop, 16 mobile.
Main en 390: padding-bottom 24 (no hay rail inferior).

5. Iconografía

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

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

6. Elevación y borde

Cero sombras shadow-lg. El kiosco no flota.

7. Mapa componente → ruta

8. Criterios de aceptación DS

1. Tokens Tailwind = hex del brief, sin “casi blanco” #FAFAFA como ground.
2. Cards en pliego; página en papel.
3. Primary CTA nunca en grafito sobre filete (contraste).
4. Cormorant no aparece en labels de form ni en badges.
5. Recorte 16:10 implementado como aspect-[16/10], no 4:3 ni 1:1.
6. Targets de masthead y CTA ≥44px.

09-content-guide.md

09 — Guía de contenido — MARGEN

1. Voz

Cercana de kiosco y de patio. Tuteo en UI. Segunda persona cuando la interfaz habla. Tercera cuando habla la crónica.

Sin jerga de medios (“contenido premium”, “engagement”, “comunidad de lectores”). Sin sede electrónica. Sin “únete a la conversación”.

El producto se hojea y se publica. No vende una causa, no pide plaza, no pide dinero.

2. Palabras permitidas / prohibidas

3. Microcopy duro (literales irrenunciables)

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

[DECISIÓN] Los tres textos son obligatorios en UI. No se diluyen a un tooltip.

4. Microcopy por superficie

5. Crónicas seed (tono)

Las piezas demo se escriben como crónica de barrio, no como nota de gabinete ni como columnismo de centro.

No inventar declaraciones de vecinas reales. Si hay una voz, es de la narradora (Nuria) o de persona de diseño etiquetada.

6. Nombres propios del seed

No inventar CIF, director de CEIP, ni horarios oficiales. [SUPUESTO de catálogo demo]
Franjas demo: sábado 11:00 merienda · lunes 18:00 charla · miércoles 17:30 cuento. No se afirman como agenda municipal.

7. Tono por estado (mesa)

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

8. Capitalización y números

• Wordmark: MARGEN en versales Cormorant.
• weekLabel: 17–23 ago (en-dash, mes abreviado minúscula).
• Fechas de agenda: sáb 22 ago · 11:00 (punto medio, 24h).
• Distritos: Usera, Carabanchel, Villaverde (con mayúscula).
• No mezclar “agosto 17-23” estilo US.

9. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar “piece” en UI. En API sí: pieces, issueId.

10. Accesibilidad de copy

• No transmitir estado solo con color (“el rojo significa publicado”).
• Badge lleva texto: Borrador, Publicado.
• Alt de fotos: descriptivo del barrio, no “imagen1”.
  • hero: “Semanario abierto en una mesa, café y cuaderno de cuadros.”
  • merienda: “Familias merendando en un banco de piedra de un patio de manzana.”
  • colegio: “Puerta de un colegio de ladrillo, mochilas colgadas en la valla.”
  • piscina: “Piscina municipal con bloques de viviendas al fondo.”
  • biblioteca: “Sala de lectura municipal con mesa de madera y patio al fondo.”

11. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad · MARGEN

Objetivo: WCAG 2.2 AA.

No conforme (fuera L2): subtítulos de vídeo (no hay vídeo). PDF accesible del número (no hay PDF).

11-privacy-security.md

11 — Privacidad y seguridad · MARGEN

Datos

No se pide cuenta a la lectora. No hay tracking de menores. No se recogen fotos de niños identificables en el seed.

Seguridad L2

• JWT + sesión en Neon. Bcrypt 12.
• DRAFT nunca en GET /pieces.
• Rate limit en /auth/login.
• CORS acotado al front.
• Secretos solo en .env (no git).

No se declara cumplimiento RGPD definitivo. Sí: minimización y derecho a borrar cuenta de editora (manual L2).

12-analytics.md

12 — Analítica · MARGEN

North star: piezas leídas / semana (evento piece_open, umbral 30s).

No hay funnel de suscripción. No se mide “likes”. Hipótesis H2: agenda_view sin signup_click (no existe CTA).

13-qa-test-plan.md

13 — Plan de pruebas — MARGEN

1. Smoke obligatorio (D-P1-06)

[COMPROBADO] Smoke = current + pieza + login JWT + mesa.

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 card, disclaimer de agenda, ausencia de signup lectora, DRAFT 404).

6. Criterios de salida QA v1

• Smoke §1 en verde.
• S2, S3, S6, S8, S11, S17, S21, S22 en verde.
• Cero blockers de copy deshonesto (imprimir / inscribir / like).
• Sin .env en el repo.

7. Fuera de este plan

Playwright e2e completo, carga, fuzzing, auditoría de un CEIP o biblioteca reales.

14-dev-handoff.md

14 — Handoff desarrollo — MARGEN

1. Arranque

cd /Users/cristian/orca/margen-app

# apps independientes (npm --prefix o pnpm --filter)
# apps/api/.env
#   DATABASE_URL=  # Neon morning-truth-64427459
#   JWT_SECRET=
#   PORT=3017

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

Demo: redaccion@margen.barrio / password123.

2. Paridad Paper

No clonar CESTA (tabla + rail), RONDA (feed + dock), DERIVA (mapa split) ni PIZARRA (command search + inscripción).

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

3. Contratos

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

4. Mapa de rutas web

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

[COMPROBADO] Solo estas rutas. No implementar /inscribir, /inbox, /walks, /mesa/:id.

5. Assets

Copiar desde el case:

2026-08-17-margen/assets/hero.jpg
2026-08-17-margen/assets/merienda.jpg
2026-08-17-margen/assets/colegio.jpg
2026-08-17-margen/assets/piscina.jpg
2026-08-17-margen/assets/biblioteca.jpg
  → apps/web/public/assets/   (o src/assets/)

cover del seed = filename (hero.jpg, merienda.jpg, …).

Quitar leftover public/assets/needs/* (despensa CESTA) si sigue en el repo.

6. DoD implementación L2

7. No hacer

8. Contactos de diseño (artefactos)

15-roadmap.md

15 — Roadmap — MARGEN

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

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

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

Contrato en docs 14 y 20. No es deuda silenciosa del case documental: es el build del repo margen-app. El alcance L2 ya está cerrado en spec; el código alinea leftover (walks / requests) al contrato.

Eso no se reabre aquí como “próximo trimestre de producto”.

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

Estas son subidas de pulido o archivo, no parches del L2 documental.

[DECISIÓN] No dejar backlog del vertical slice como “mañana”. Lo de arriba es L+1.

4. L3 (requiere brief nuevo de diversidad)

• Multi-distrito / varias cabeceras
• Cuenta LECTORA y bookmarks
• Newsletter transaccional “ha salido el número”
• Workflow REVIEW / SCHEDULED / KILLED
• Comentarios o cartas al director
• Impresión / PDF de kiosco / punto de venta
• Paywall
• Search 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 (alinear leftover)
2. Web paridad UI-00…10
3. Preview token + archivo de números (L+1)
4. Rate limit si hay tráfico
5. Evaluar brief L3 (no parche silencioso)

16-interaction-specs.md

16 — Especificación de interacción — MARGEN

1. Convenciones

2. Masthead (S-TOP)

Estado activo: label tinta + filete 2px cadmio bajo el ítem.
Estado default: grafito.

Desktop: links a la derecha.
390: wordmark + Número + Agenda; Mesa entra en la misma fila si cabe, si no bajo la rule.

3. Lookbook home

AC: la portada 16:10 (foto + título del número) está en el viewport inicial a 390 y a 1280 (sin hero de 60vh de marca).

Orden visual = seed / createdAt ASC. No “destacados” por likes.

390 (UI-10): portada full + pila de cards. Lead de 2 líneas. Título Cormorant 32.

4. Ficha de crónica

Sin doble tap like. Sin barra de progreso de lectura como Must (Could L+1, off si reduced-motion).

5. Agenda

Si un tester busca un botón de reserva y no lo encuentra, H2 está bien implementada.

6. Login

next permitido: paths que empiezan por / y no // ni http. Allowlist sugerida: /mesa, /mesa/nueva.

7. Mesa

No swipe-to-archive. No kanban.

Optimistic UI en Publicar: badge pasa a Publicado; si PATCH falla, rollback + toast error.

Publicar no anima una rotativa ni un “+1 en kiosco”.

8. Alta de pieza

Submit deshabilitado si title < 4, body < 40 o section vacía.

[DECISIÓN] Dos botones visibles. Primario = Publicar. Secundario = Guardar borrador. El primario no se llama “Imprimir”.

9. Success

Sin confetti. Sin “¡ya está en el kiosco!”.

10. Motion

Prohibido: scroll-jacking, page transitions de 400ms, parallax en portada, like animation.

11. Criterios de aceptación de interacción

1. Una LECTORA en 390px llega de lookbook a ficha en 1 tap, y a agenda en 1 tap más (masthead).
2. Un EDITOR en 390px publica un DRAFT en ≤ 3 taps desde mesa (acción en fila).
3. Ningún submit permite doble POST.
4. El masthead no cubre el H1 de la ficha (spacer si sticky).
5. Reduced-motion elimina stagger.
6. La home no es hero 2-col (AP-12).
7. En 390 el recorte 16:10 de la primera card es visible sin scroll horizontal.
8. /agenda no presenta ningún control de inscripción.

17-prototype-map.md

17 — Mapa de prototipo — MARGEN

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

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

Recorrido demo (guión)

1. Abrir / — lookbook El patio no cierra en agosto, portada hero.jpg, ≥3 cards 16:10.
2. Tocar La merienda que no cabe en el grupo — ficha Patio, crédito Nuria.
3. Masthead Agenda — 3 eventos; leer “no es una inscripción”.
4. Comprobar que no hay botón Reservar.
5. /login — redaccion@margen.barrio / password123.
6. /mesa — ver DRAFT Lo que el AMPA no va a colgar en Stories.
7. Nueva pieza o Publicar el DRAFT → /mesa/ok/:slug — “Publicar no es imprimir”.
8. Volver a / en otra sesión: el DRAFT no está; lo publicado sí.

Estados en el mismo prototipo

Fuera del prototipo clicable

• Paper artboards son estáticos.
• WhatsApp del AMPA / grupo del cole (backstage).
• Impresión / kiosco físico.
• Inscripción a eventos (no existe).
• Comentarios.
• Archivo de números anteriores.

18-completeness-audit.md

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

1. Alcance auditado

Vertical slice L2: lookbook del número semanal + ficha de crónica + agenda familiar + mesa EDITOR JWT, con docs, referencia Paper, contratos Angular + Nest + Neon.

Este encargo cubre la suite documental. Paper hi-fi y el repo margen-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)

[COMPROBADO] UX-count: 12 y UI-count: 11 literales para el gate check-paper-reference.mjs. Paper hi-fi en construcción paralela; inventario planificado escrito.

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-17.
La suite define producto L2 usable (tablas, AC, riesgos, contratos) sin presentar investigación de campo como hecho.
Cualquier ampliación inscripción / paywall / feed / mapa / search-first requiere nuevo brief de diversidad, no parche silencioso.

19-backlog-completo.md

19 — Backlog completo — MARGEN

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

1. Done — L2 case documental (2026-08-17)

Los must-have del brief (lookbook, ficha, agenda, login+mesa, alta+success, empty/loading/error/mobile, ≥12 UX + ≥10 UI) están dentro de D01–D24, no como leftover.

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

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

3. Backlog L+1 (polish / archivo)

4. Backlog 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 + B05 + B09
3. B03 + B08
4. B02 si hay segundo número
5. Evaluar brief L3 — no parche silencioso

8. Trazabilidad

20-implementation.md

20 — Implementación — MARGEN

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; contiene leftover de otros productos (walks, requests, assets de despensa). El contrato de esta suite es MARGEN.

2. Cómo arrancar

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

# apps/api/.env
#   DATABASE_URL=   # Neon morning-truth-64427459
#   JWT_SECRET=
#   PORT=3017

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

Credenciales

3. Schema

Al boot o vía migrate:

1. CREATE TABLE / migrate de users, issues, pieces, events (doc 05).
2. Índices: issues(status, published_at DESC), pieces(slug), pieces(issue_id, status), pieces(updated_at DESC), events(issue_id, starts_at), users(email).
3. Seed idempotente:
   • upsert EDITOR redaccion@margen.barrio (bcrypt de password123)
   • upsert Issue por week_label
   • upsert pieces por slug
   • upsert events por (issue_id, title)

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 + role === EDITOR protege mesa / escritura.

Issues / pieces / events

Slug

kebab(title)  +  opcional "-2" si unique falla

Reintentar sufijo (máx. 5). No UUID en URL de lectura.

[DECISIÓN] Timezone Europe/Madrid para weekLabel y startsAt de UI. JSON transporta ISO UTC.

Filtro público

current.pieces = pieces WHERE issue_id = current.id AND status = 'PUBLISHED'
GET /pieces/:slug = 404 unless status = 'PUBLISHED'

Publicar no toca events ni genera PDF.

5. Frontend a implementar

Shell: MastheadComponent persistente.
ApiService centraliza base URL http://localhost:3017/api, token storage (margen_token, margen_user), métodos tipados (Issue, Piece, Event, User).

6. Decisiones de implementación

7. Variables de entorno

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

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

1. Schema OK (tablas existen).
2. GET /api/issues/current incluye 4 slugs PUBLISHED y cero DRAFT.
3. GET /api/pieces/lo-que-el-ampa-no-cuelga 404.
4. GET /api/events length 3.
5. POST /api/auth/login 200 + accessToken.
6. GET /api/mesa/pieces Bearer incluye el DRAFT.
7. GET /api/mesa/pieces sin token 401.
8. PATCH /api/pieces/:id { status: "PUBLISHED" } 200 y la pieza aparece en current.
9. Web: lookbook dominante, masthead, disclaimer agenda, fotos 16:10.

9. Estructura de ficheros clave (objetivo)

margen-app/
├── package.json
├── apps/api/
│   ├── src/
│   │   ├── main.ts
│   │   ├── app.module.ts
│   │   ├── auth/
│   │   ├── issues/
│   │   ├── pieces/
│   │   └── events/
│   └── .env.example
├── apps/web/
│   ├── tailwind.config.js
│   └── src/app/
│       ├── app.routes.ts
│       ├── core/api.service.ts
│       ├── shell/masthead.component.ts
│       └── pages/
│           ├── home/          # lookbook
│           ├── piece/
│           ├── agenda/
│           ├── login/
│           ├── desk/
│           ├── new-piece/
│           └── ok/
└── 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 L2 está especificado (docs + Paper ref + contratos).
• Must-have de producto del brief están escritos con AC.
• Mejoras (preview token, archivo, e2e, rate limit) viven en backlog L+1, no como deuda silenciosa.
• Si el repo aún muestra walks / requests / fotos de aceite, no está alineado: I01 es el primer ítem de build.