00-day-brief.md

00 — Day brief · 2026-08-22 · RAMAL

Decisiones ALS-2 BRIEF

Terna unicidad

R-CL · S-SPLIT · H-FULL · F-ONB

0 códigos iguales a N−1 (TEMPLE: R-HY · S-MIN · H-KIOSK · F-BOOK).
≥2 distintos vs N−2 (PREGÓN) y N−3 (MATIZ).
Ventana 4: R-HY + R-IN + R-HY + R-IN → hoy R-CL.

S-SPLIT, H-FULL y F-ONB no están en los últimos 5.

Ground (CRON §5.6)

• Familia: G-ICE
• Hex: #E7F0F5
• Por qué: escarcha en teja a las 8, no negro de flight case (TEMPLE), no fotocopia (PREGÓN), no yeso (MATIZ), no hormigón (ZAGUÁN), no blanco de kiosco (MARGEN).

Mood visual (Paper)

• Candidatos: cyan SaaS / NOC (primer instinto telecom), ice, mineral, tidal, alpine
• Elegido: ice — no el primer instinto tablero de operador. Una red de bloque se ve desde la azotea un martes con escarcha, no desde un NOC.
• Paleta:
  • #E7F0F5 hielo (ground)
  • #1A2A32 mástil mojado
  • #FFFFFF ficha
  • #3D7A96 cobre oxidado del mástil
  • #5C6B73 galvanizado
  • #B42318 precinto (poco)
• Tipo: Newsreader display · Figtree UI

Alcance L3 must

1. Home H-FULL: portada + 3 nodos (lead + 3 datos)
2. Checklist de alta (4 ítems, una pantalla, no wizard)
3. Acuse con código (alta ≠ cobertura)
4. Login JWT VOCAL
5. Mesa split: lista de altas | ficha + aceptar/rechazar
6. Empty / error / loading / mobile portada
7. ≥12 UX + ≥10 UI

Microcopy duro

• Alta ≠ cobertura del operador. RAMAL no sustituye a Movistar.
• Nodo ≠ router de casa. El nodo está en la azotea del bloque.
• RAMAL no instala hoy. Aceptar no sube a la azotea.
• Checklist ≠ técnico. Completar el alta no programa una visita.

Supuestos

• S1: Una asociación atiende 4–8 altas/semana; la demo tiene 3 nodos y 5 altas (3 PENDIENTE, 2 ACEPTADA).
• S2: La vecina pide alta desde el salón; no crea cuenta.
• S3: Un VOCAL (Pablo) acepta o rechaza; el técnico no entra en el slice L3 de código (sí en docs).
• S4: Sin pago, sin radio planning, sin mapa GIS. [DECISIÓN]

Hipótesis

00-paper-reference.md

Paper reference · RAMAL

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 Portada · UI-02 Portada mobile · UI-03 Alta · UI-04 Alta mobile · UI-05 Success · UI-06 Login · UI-07 Mesa split · UI-08 Ficha · UI-09 Empty · UI-10 Error · UI-11 Loading

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

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

Mapeo Paper → Angular

01-project-definition.md

01 — Definición de proyecto — RAMAL

1. Identidad

[COMPROBADO] Nombre, terna, nivel, sector, ground y paleta salen de docs/00-day-brief.md.
[SUPUESTO de catálogo] Vallecas / Palomeras / Sierra Gádor es atrezzo de mercado, no el inventario de una red real.

2. Problema

Principal (hipótesis de diseño)

[HIPÓTESIS] La vecina de un bloque de Palomeras no necesita un comercial de fibra: necesita pedir nodo en su bloque sin llamar a un operador. Hoy eso vive en un grupo, una junta y una expectativa de cobertura. El alta se lee como contrato de Movistar; el nodo se lee como router de casa; el producto se lee como speedtest. [SUPUESTO] Una asociación atiende 4–8 altas/semana; no opera un NOC ni un chat municipal.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Una asociación atiende 4–8 altas/semana; la demo tiene 3 nodos y 5 altas (3 PENDIENTE, 2 ACEPTADA). [SUPUESTO]
• S2: La vecina pide alta desde el salón; no crea cuenta. [SUPUESTO]
• S3: Un VOCAL (Pablo) acepta o rechaza; el técnico no entra en el slice L3 de código (sí en docs). [SUPUESTO]
• S4: Sin pago, sin radio planning, sin mapa GIS. [DECISIÓN]

Hipótesis de producto

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

3. Propuesta de valor

No es RAMAL

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L3 telecomunicaciones / comunidad vecinal con Node + Alta + JWT VOCAL.
• Portfolio coherente: Paper (12 UX + 12 UI) + docs + app runnable.
• Terna R-CL · S-SPLIT · H-FULL · F-ONB frente a TEMPLE (kiosk/horas), PREGÓN (chat/kanban) y MATIZ (bento/editor).

Usuario

No objetivos v1 (explícitos)

• Cobertura, speedtest, Mbps, SLA de operador
• Router de casa, Wi-Fi, ONT, radio planning
• Instalación, visita técnica, cuadrante de Nerea
• Chat, kanban, columnas Recibido / En curso
• Cuenta de vecina, seguimiento con login, push
• Pago, cuota, pasarela
• Mapa GIS / cadastro
• Multi-asociación, multi-vocal
• App nativa ni notificaciones push
• Rol TÉCNICA autenticado

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: VOCAL. La vecina no es un usuario del sistema: es autora/autor de un alta. La técnica no es un rol de sistema el día 1.

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

7. Alcance funcional v1 (L3)

8. Criterios de aceptación de producto

1. / es la portada de 3 nodos a sangre. No pide cuenta. No es un hero 2-col + 3 cards.
2. Una vecina puede ver 3 nodos en el recorte 16/10 (lead + 3 datos), tocar Azotea Palomeras, completar el checklist y obtener un código RM-XXXX.
3. /ok/:code dice explícitamente que alta no es cobertura del operador y que RAMAL no instala hoy.
4. La UI dice explícitamente que nodo no es router de casa y que checklist no es técnico.
5. Sin token, GET /api/mesa responde 401. POST /api/altas y GET /api/nodes son públicos.
6. Un POST de alta crea status=PENDIENTE. Completar no programa una visita.
7. Un VOCAL inicia sesión y ve 5 altas (3 PENDIENTE, 2 ACEPTADA) en el seed.
8. El tablero es un split lista | ficha. No es un kanban de 3 columnas.
9. Fotos reales en los 3 nodos seed (assets nodos/*).
10. Checklist visible: vivienda · planta · azotea · no instala.
11. Chrome S-SPLIT en mesa; portada pública sin top-nav de marketing.
12. Rutas solo las del doc 03. No existen /cobertura, /speedtest, /chat, /turno, /kanban.
13. GET /api/health devuelve service: "ramal-api".
14. La portada no muestra nombres de otras vecinas; la mesa sí.

9. Stack y artefactos

[COMPROBADO] Puerto, Neon, Paper file ID, repo y path de app constan en el encargo.
El código se escribe en paralelo a esta suite.

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-SPLIT · H-FULL · F-ONB. 0 códigos iguales a N−1 (TEMPLE). ≥2 distintos vs N−2 (PREGÓN) y N−3 (MATIZ). Ventana 4 días: R-HY + R-IN + R-HY + R-CL. Ground G-ICE #E7F0F5, no G-INK.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — RAMAL

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 redes comunitarias y asociaciones de vecinos (nodo en azotea, alta en junta, técnico que no entra el día 1, distinción red de bloque vs operador comercial).
• Analogía operativa con superficie pública + panel JWT de la serie daily.
• Restricciones ALS-2: no Movistar, no speedtest, no chat, no kanban, no kiosk de horas.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: la junta (quién pone la portada) y, en uso diario, Pablo (quien mira la mesa).
• Usuario frecuente de pedir alta: VECINA (portada + checklist, sin cuenta).
• Usuario frecuente de decisión: VOCAL (mesa).
• Riesgo de rechazo: si el acuse parece un contrato de cobertura; si el nodo parece router; si hay que crear cuenta; si la mesa parece un kanban.

4. Personas

P1 — Inés Soto · VECINA

Escenario: Abre / en el salón, toca Azotea Palomeras, marca los 4 ítems, escribe Inés Soto / 4º B, lee «Alta ≠ cobertura» y el código RM-XXXX.

[COMPROBADO] Nombre, edad y gesto (vecina, 52) salen del encargo. Es constructo de diseño, no entrevistada. [DECISIÓN]

P2 — Pablo Ruiz · VOCAL

Escenario: Entra a /login, abre /mesa, toca RM-2201 Inés Soto, lee la ficha, pulsa Aceptar. El copy dice que aceptar no sube a la azotea.

[COMPROBADO] Nombre, edad, email demo y rol salen del encargo.

P3 — Nerea Gil · TÉCNICA (docs)

[COMPROBADO] Nombre, edad y exclusión de login salen del encargo. [DECISIÓN] no hay cuenta TÉCNICA en v1.

5. JTBD

Job principal (vecina)

Cuando quiero saber si hay nodo en mi bloque, quiero pedir alta sin llamar a un comercial, para dejar constancia en la junta sin que eso signifique cobertura ni técnico mañana.

Job principal (vocal)

Cuando hay altas nuevas, quiero ver lista y ficha y decidir, para mover el oficio de la asociación sin un kanban ni un NOC.

Jobs que RAMAL no hace

6. Stories Must (v1)

Could (fuera de L3): login de Nerea, mapa GIS, radio planning, pago, speedtest, historial de vecina.

7. Journey (resumen)

1. Inés abre /. Ve foto a sangre y 3 nodos. [H1]
2. Toca Azotea Palomeras → /alta?nodo=azotea.
3. Marca vivienda, planta, azotea, no instala. Escribe nombre y 4º B.
4. POST → /ok/RM-XXXX. Lee las cuatro oposiciones.
5. Pablo entra a /login → /mesa. Lista a la izquierda.
6. Abre /mesa/RM-2201. Acepta. Copy: no sube a la azotea.

Backstage: Nest + Neon + JWT. Nerea no entra. El mástil no se mueve.

8. Matriz hallazgo → requisito → feature

9. Preguntas que este case no responde

• ¿Cuántas altas reales hay en Palomeras en 2026?
• ¿Qué asociación opera un mástil en Sierra Gádor?
• ¿Inés preferiría WhatsApp?
• ¿Nerea necesita un cuadrante?

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

10. Cierre

Investigación = modelado etiquetado + restricciones ALS-2.
No hay entrevistas inventadas.
Las personas son constructos. Vallecas / Palomeras / Sierra Gádor son [SUPUESTO de catálogo].

03-information-architecture.md

03 — Arquitectura de información — RAMAL

1. Principios de IA

2. Sitemap

/                                      Portada pública (3 nodos)                    H-FULL
/alta                                  Checklist 4 ítems                            F-ONB · público
/ok/:code                              Acuse post-alta                              público
/login                                 Login JWT VOCAL                              público
/mesa                                  Split lista | vacío de ficha                 auth
/mesa/:code                            Split lista | ficha aceptar/rechazar         auth
/**                                    → redirect /

Árbol por audiencia

[COMPROBADO] Seis rutas del encargo L3. No se inventan /cobertura, /speedtest, /chat, /turno, /kanban, /tecnico.

El checklist sí es ruta (/alta): una pantalla, no wizard chrome. [DECISIÓN]
La ficha sí es ruta (/mesa/:code) porque S-SPLIT necesita URL compartible para Pablo. [DECISIÓN]

3. Navegación

Portada pública (H-FULL · sin top-nav de marketing)

[DECISIÓN] La portada no tiene tabs, no tiene hamburger, no tiene «Cobertura / Tarifas / Área cliente». Un link «Vocal» discreto basta para Pablo.

Chrome de mesa (S-SPLIT autenticado)

[DECISIÓN] No hay rail S-SIDE (eso fue PREGÓN). No hay kiosk S-MIN (TEMPLE). No hay bottom tabs (MATIZ). La mesa es un split a pantalla.

Chrome de alta (F-ONB)

4. Etiquetas de IA (UI)

5. Contenido de cada nodo de IA

6. Error / empty / loading (sitio)

Viven en las mismas rutas, no en URLs extra.

7. Profundidad y búsqueda

Sin buscador en v1. 3 nodos y 5 altas caben en una lista. [DECISIÓN]
Pablo ordena por PENDIENTE primero, no filtra por nodo. Could L+1.

04-user-flows.md

04 — Flujos de usuario — RAMAL

1. Convenciones

2. F1 — Vecina pide alta (Must)

/  →  GET /api/nodes
   →  tap nodo  →  /alta?nodo=azotea
   →  marca 4 ítems + nombre + vivienda
   →  POST /api/altas
   →  201 { code: RM-XXXX, status: PENDIENTE }
   →  /ok/RM-XXXX

Entrada: portada, sin cuenta.
Salida: código visible + copy «alta ≠ cobertura».
Errores: red (reintentar), checklist incompleto (400, no POST), 0 nodos (empty).

AC

• 4 checks obligatorios. El botón permanece disabled hasta completar.
• No hay paso 2. No hay «Siguiente».
• POST no cobra, no crea user, no llama a Nerea.

3. F2 — Vocal entra a mesa (Must)

/login  →  POST /api/auth/login
        →  JWT VOCAL
        →  /mesa
        →  GET /api/mesa
        →  tap RM-2201  →  /mesa/RM-2201
        →  GET /api/mesa/RM-2201

AC

• Sin token, /mesa redirige a /login?next=/mesa.
• GET /api/mesa sin Bearer → 401.
• Lista a la izquierda, ficha a la derecha (desktop). Mobile: lista o ficha, no las dos a la vez si no cabe.

4. F3 — Vocal acepta / rechaza (Must)

ficha PENDIENTE
  →  PATCH /api/mesa/:code { status: ACEPTADA | RECHAZADA }
  →  200 ficha actualizada
  →  lista refleja el status

Si ya no está PENDIENTE → 409. Copy: «Aceptar no sube a la azotea.»

AC

• Aceptar no cambia el nodo, no crea visita, no envía email.
• Rechazar no es un parte municipal.
• Los botones desaparecen cuando el status no es PENDIENTE.

5. F4 — Estados de sistema

6. Flujos que no existen

7. Tiempos de demo (modelo)

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

05-data-model.md

05 — Modelo de datos — RAMAL

1. Visión general

Dominio L3 de portada de nodos + mesa autenticada:

Base: PostgreSQL (Neon project gentle-bonus-75761237) · IDs: serial + texto estable (azotea, RM-2201).
[DECISIÓN] ensureSchema es válido si el contrato de tablas se cumple; el brief de stack no exige Prisma.

Contrato de producto: nodes + altas + JWT VOCAL. No rooms / bookings / bandos / reports.

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

Role

AltaStatus

NodeKind

azotea | bloque | arqueta

3. Diagrama ER (texto)

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

sessions
  id, user_id → users
  expires_at, revoked_at
  created_at

nodes
  id
  slug (unique)
  name, kind, street, lead
  data_1, data_2, data_3
  cover
  sort_order
  created_at, updated_at
  1 ──< altas

altas
  id
  code (unique, RM-XXXX)
  node_id → nodes
  neighbor_name
  dwelling
  status (PENDIENTE|ACEPTADA|RECHAZADA)
  created_at, decided_at, updated_at

v1: un solo VOCAL opera sobre el conjunto global.
No hay FK de vecina-usuaria: la vecina no se loguea.
altas no apunta a users: el alta es anónima de cuenta.

4. Tablas

users

sessions

nodes

altas

Índices: nodes(slug), altas(code), altas(status), altas(created_at DESC), users(email).

5. Seed

VOCAL

pablo@ramal.vallecas / password123 · Pablo Ruiz · VOCAL

Nodos

Altas

[SUPUESTO de catálogo] Nombres de vecinas secundarias, calles y conteos de viviendas son atrezzo.

6. JSON (camelCase)

API: neighborName, nodeSlug, nodeName, nodeKind, sortOrder, createdAt, decidedAt, data1, data2, data3.
SQL: neighbor_name, node_id, sort_order, created_at, decided_at, data_1.

7. Generador de código

SELECT max(code) numérico + 1, formateado RM- + 4 dígitos. Seed máximo 2205 → siguiente POST = RM-2206 (si no hay altas nuevas). Si se agota 9999, L+1 amplia a 5 dígitos; no es Must.

8. Qué no se modela

06-tech-stack.md

06 — Stack tecnológico — RAMAL

1. Visión

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

El código se escribe en paralelo a esta suite. Este doc es el contrato.

2. Estructura

ramal-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 (/cobertura, /speedtest, /reports).

4. Justificación

5. Variables

.env local (nunca git):

.env.example solo placeholders.
Web: URL de API en ApiService (default http://localhost:3022/api). Proxy Angular proxy.conf.json → :3022.

6. Módulos API

health · auth · users · nodes · altas · mesa · database · common.

Health: HealthService.name = 'ramal-api'.
main.ts PORT default 3022.

7. Frontend

Páginas: HomePage / · AltaPage /alta · OkPage /ok/:code · LoginPage /login · MesaPage /mesa y /mesa/:code.

Guard JWT en mesa. Interceptor Bearer. Token key ramal.accessToken.

8. Lo que el stack no es

No es un NOC. No es un OSS/BSS. No es un speedtest. No es Prisma obligatorio. No es un leftover de horas de ensayo: el contrato es nodes + altas + VOCAL.

07-creative-direction.md

07 — Dirección creativa — RAMAL

1. Concepto

RAMAL es una portada de red de bloque con escarcha en la teja: se entra a tres nodos y se sale con un alta, no una landing de «tu operadora». El ground es hielo de las ocho. El cobre oxidado es el mástil. El precinto sella lo urgente, poco.

Mood elegido: ice.
Primer instinto descartado: cyan SaaS / NOC. Una red de bloque se ve desde la azotea un martes, no desde un centro de operaciones.

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

2. Territorio visual

3. Paleta

Jerarquía de color: el hielo carga; el mark puntúa; la card encuadra el nodo. Si el mark pinta fondos enteros, deja de ser mástil y se vuelve «brand teal». El seal no decora el header: solo puntual (error). [DECISIÓN]

4. Tipografía

Prohibido: Newsreader por debajo de 18px (se rompe). Figtree en el wordmark de portada (se vuelve SaaS).

Fuentes vetadas de la serie reciente: Fraunces / Atkinson Hyperlegible / Ibarra Real Nova / Jost / Libre Baskerville / Nunito / Instrument Serif / Sora / Cormorant / Public Sans / Spectral / Manrope / Zilla / Mulish / Outfit / Lora / Karla.

5. Fotografía

Alt: nodo + lugar, no «imagen1». Ver doc 09.

6. Registro R-CL

Institucional de asociación: márgenes serios, tipo con contraste, foto a sangre, ficha blanca. No es un dashboard de red. No es un kiosk de horas. No es un chat municipal.

La innovación está en H-FULL + S-SPLIT + F-ONB, no en un look «telecom cian». [DECISIÓN]

7. Anti-moods

08-design-system.md

08 — Sistema de diseño — RAMAL

1. Tokens

Tailwind: bg-ground, text-ink, bg-card, bg-mark, text-mute, text-seal, font-display.

2. Escala de tipo

3. Componentes

Tile de nodo (portada)

Foto 16/10 recortada + kind · calle + nombre + lead + 3 datos. Toda la card es el hit. Destino /alta?nodo=:slug.

Checklist (alta)

4 labels con checkbox ≥20px + texto. Fieldset. Disabled CTA hasta complete.

Acuse

Código Newsreader enorme + bloque mark con nodo y nombre + 4 oposiciones en mute.

Fila de mesa

Código · status · vecina · nodo · vivienda. Ring mark si seleccionada.

Ficha

Código, nombre, dl nodo/vivienda, copy irrenunciable, Aceptar (mark) / Rechazar (ground).

Login

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

Skeleton

animate-pulse bg-card (o bg-ground sobre card). aria-busy.

Error

Titular display + cuerpo mute + Reintentar mark.

4. Layouts

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

5. Estados de control

6. Iconografía

Cero iconos decorativos de «wifi / 5G / cohete». El oficio es tipográfico + foto. [DECISIÓN]

7. Motion

120–160ms ease-out. Reduced motion: 0ms. Skeletons pulse; no spinners de operador.

8. Densidad (AP-21)

En el recorte 16/10 de portada: eslogan + 3 nodos con lead + 3 datos. Headline huérfano + foto = card hueca. [COMPROBADO] CRON §5.8.

09-content-guide.md

09 — Guía de contenido — RAMAL

1. Voz

Cercana de bloque y de mesa. Tuteo en UI a la vecina. Segunda persona cuando la interfaz habla. Tercera cuando habla la mesa (Inés Soto ocupa…).

Sin jerga de operador («tu cobertura», «hasta 600 Mb», «contrata ahora»). Sin speedtest. Sin «reserva tu slot». Sin sirena. Sin kanban en UI.

El producto se pide y se decide. No vende cobertura, no es router, no instala hoy, no es técnico.

2. Palabras permitidas / prohibidas

«Kanban» y «F-ONB» son lenguaje de diseño, no de UI: Inés no lee «onboarding»; Pablo lee Pendiente / Aceptada.

«Alta» en UI es la petición de nodo. Si hay ambigüedad, preferir pedir nodo o código. [DECISIÓN]

3. Microcopy duro (literales irrenunciables)

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

[DECISIÓN] Los cuatro textos son obligatorios en UI. No se diluyen a un tooltip.
Pie de portada puede condensar dos en dos líneas; acuse muestra los cuatro.

4. Microcopy por superficie

5. Nodos y altas seed (tono)

Los nodos demo se escriben como infraestructura de bloque, no como ficha de operador ni como anuncio.

No inventar declaraciones de vecinas reales. Si hay una voz, es de persona de diseño etiquetada.

En ACEPTADA no se reescribe a «ya estáis en cobertura». El cierre es la decisión. [DECISIÓN]

6. Nombres propios del seed

No inventar CIF de asociación, teléfono de operador, ni cobertura real como si fuera el producto. [SUPUESTO de catálogo demo]
Vallecas / Palomeras / Sierra Gádor son topónimos reconocibles, no un inventario oficial de una red 2026.

7. Tono por estado

La app no envía esos mensajes a la vecina en v1. El copy solo prepara el habla. No hay email de «ya tenéis fibra».

8. Capitalización y números

• Wordmark: RAMAL en versales Newsreader.
• Código: RM-2201 (RM versales, guion, 4 dígitos).
• Nombres: Inés Soto, Pablo Ruiz, Nerea Gil.
• Nodos: Azotea Palomeras (mayúscula de kind + lugar).
• Vivienda: 4º B en UI.
• Fecha: 22 ago si hay línea larga.
• No mezclar rm-2201 en minúsculas en UI. API puede normalizar a versales.

9. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar «onboarding» ni «coverage» en UI. En API sí: nodes, neighborName, status.

«Vecina» en UI cuando hablamos de Inés; «el vocal» para Pablo; «la técnica» solo en docs. [DECISIÓN]

10. Accesibilidad de copy

• No transmitir estado solo con color (el mark no «significa» pendiente él solo).
• Filas llevan texto: Pendiente / Aceptada / Rechazada.
• Aviso de no-cobertura lleva palabras, no solo el seal.
• Alt de fotos: nodo + lugar, no «imagen1».
  • hero: «Azotea de un bloque en Vallecas; mástil de red de comunidad, no un operador.»
  • azotea: «Mástil en azotea de Palomeras; nodo de bloque.»
  • bloque: «Fachada y patio del bloque Sierra Gádor.»
  • arqueta: «Arqueta de acera en Pablo Neruda.»

11. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad — RAMAL

1. Alcance

WCAG 2.2 AA orientada al slice: portada, checklist, acuse, login, mesa split. No es una auditoría certificada. [DECISIÓN]

2. Contraste

Texto sobre foto: gradient from-ink/80 bajo el titular. No titular suelto sobre teja clara.

3. Teclado y foco

• Orden: wordmark → Vocal → tiles de nodo → form → mesa lista → ficha.
• Foco visible: ring mark 2px.
• Radio de nodo y checks operables con teclado.
• Aceptar / Rechazar no se activan al pasar el foco.

4. Targets

≥44×44 en CTA, checks, filas de mesa, link Vocal. Checks 20px visual + label amplia.

5. Nombre accesible

Fotos: alt de doc 09. Decorative? No: las tres son contenido.

6. Estados no solo por color

Pendiente / Aceptada / Rechazada en texto. Completo del checklist: botón disabled + copy. Error: texto seal + mensaje.

7. Motion

prefers-reduced-motion: sin pulse. Skeletons estáticos.

8. Mobile 390

Portada: foto + 3 nodos apilados. No carousel.
Alta: una columna.
Mesa: lista o ficha (master-detail). Back a lista = /mesa.

9. Autocomplete

Login: username / current-password. Nombre: name. Vivienda: sin autocomplete de dirección de operador.

10. Idioma

html lang="es". Números y códigos leídos como texto (RM-2201).

11-privacy-security.md

11 — Privacidad y seguridad — RAMAL

1. Superficie pública vs cerrada

[DECISIÓN] El acuse no hace GET público por código. Evita enumeración de Inés Soto.

2. Datos de vecina

neighbor_name + dwelling + node_id. Sin email, sin DNI, sin teléfono en v1.
La vecina no tiene fila en users.

3. Auth

• JWT HS256. Claims: sub userId, sid session.
• Password bcrypt 12. Demo password123 solo en seed local.
• Guard: Bearer + sesión no revocada.
• Role VOCAL para mesa. 401 sin token, 403 si no VOCAL.
• Rate limit en login.

4. Secretos

DATABASE_URL y JWT_SECRET en apps/api/.env (gitignore). Nunca en Angular.

5. CORS

Allowlist localhost:4200. Previews Vercel opcionales.

6. Amenazas del slice

7. RGPD (modelo, no dictamen)

Base: interés de la asociación en gestionar altas. Minimización: nombre + vivienda. Sin cesión a operador. Derecho de supresión Could L+1 (Pablo no borra en v1).

Nerea no tiene acceso. No hay logs de «quién subió a la azotea».

8. Lo que no hacemos

No OAuth. No cookies de marketing. No analytics de terceros en v1. No cifrado de dwelling más allá de TLS.

12-analytics.md

12 — Analítica — RAMAL

1. North star

% de altas que Pablo mueve (ACEPTADA o RECHAZADA) en 7 días.

Oficio de junta. No pageviews. No «engagement con el mástil». [DECISIÓN]

2. Métricas de producto (modelo)

3. Eventos (si se instrumentara)

No hay tracker en v1. Contrato de nombres por si L+1:

Prohibido: purchase, coverage_unlocked, speedtest_run.

4. Lo que no medimos

Mbps. Tiempo en azotea. Aperturas de WhatsApp (no hay dato). NPS de operadora.

5. Salud

GET /api/health → { ok: true, service: "ramal-api" }. Error rate 4xx/5xx en nodes/altas/mesa.

13-qa-test-plan.md

13 — Plan de QA — RAMAL

1. Smoke API (pnpm test:api)

1. GET /api/health → ramal-api
2. GET /api/nodes → 3 slugs azotea,bloque,arqueta + lead + 3 datos
3. GET /api/nodes/azotea → kind azotea
4. POST /api/altas completo → RM- PENDIENTE
5. POST incompleto → 400
6. GET /api/mesa sin JWT → 401
7. POST /api/auth/login Pablo → VOCAL
8. GET /api/mesa → ≥5 e incluye RM-2201…2205
9. GET /api/mesa/RM-2201 → Inés Soto PENDIENTE
10. PATCH ACEPTADA → 200; segundo PATCH → 409

2. Smoke UI

3. Regresión de unicidad

• No copy TEMPLE (hora, concierto, conserje, turno, TM-).
• No copy PREGÓN (chat, kanban, 112, parte).
• No Movistar, no Mbps, no speedtest.
• Health no dice temple-api.
• Puerto 3022.

4. Accesibilidad rápida

Tab por tiles y checks. Focus ring. Alt de 4 fotos. Status en texto.

5. Datos

Seed idempotente por email y code. Un POST de smoke no borra RM-2201.
Playwright futuro: esperar Inés Soto, no Lola ni Los Yesos.

6. Criterio de salida

Smoke API verde + guión UI completo + 0 leftover de dominio anterior en UI.

14-dev-handoff.md

14 — Handoff de desarrollo — RAMAL

1. DoD del slice

• Health { ok: true, service: "ramal-api" } en :3022
• 3 nodos seed con foto, lead, 3 datos
• POST alta pública → RM-XXXX PENDIENTE
• JWT VOCAL pablo@ramal.vallecas / password123
• Mesa split lista | ficha · PATCH ACEPTADA / RECHAZADA
• Empty / error / loading en portada y mesa
• Copy ×4 visible
• Rutas / /alta /ok/:code /login /mesa /mesa/:code
• Paper 12 UX + 12 UI mapeados
• Docs 01–20 + README + executive

2. Contratos

Ver docs 05 y 20. JSON camelCase. SQL snake_case.

POST /api/altas:

{ nodeSlug, neighborName, dwelling, vivienda, planta, azotea, noInstala }

Los cuatro booleanos deben ser true.

PATCH /api/mesa/:code:

{ status: "ACEPTADA" | "RECHAZADA" }

3. Mapas de pantalla

4. Tokens en código

tailwind.config.js + styles.scss. Fuentes Google: Newsreader + Figtree.

5. Assets

Copiar 2026-08-22-ramal/assets/nodos/*.jpg y hero.jpg a apps/web/public/assets/.

6. No hacer

• No reintroducir rooms / bookings como dominio vivo.
• No documentar leftover TEMPLE como estado actual.
• No añadir signup de vecina, speedtest, chat, kanban, GIS, pago.

7. Arranque

cd /Users/cristian/orca/ramal-app
# apps/api/.env → DATABASE_URL Neon gentle-bonus-75761237, JWT_SECRET, PORT=3022
pnpm --filter @repo/api start:dev
pnpm --filter @repo/web start

15-roadmap.md

15 — Roadmap — RAMAL

Aquí solo viven ideas de L+1 / L4 y pulido posterior.
El slice L3 del día está cerrado: portada, checklist, acuse, JWT VOCAL, mesa split.

1. Hecho (L3)

• Portada H-FULL · 3 nodos · lead + 3 datos
• Checklist F-ONB · 4 ítems · una pantalla
• Acuse /ok/:code
• Mesa S-SPLIT · aceptar / rechazar
• Empty / error / loading · portada 390
• Neon gentle-bonus-75761237 · API :3022 · ramal-api

2. L+1 (mismo producto, más oficio)

3. L4 (requiere brief nuevo de diversidad)

• Rol TÉCNICA (Nerea) + cuadrante de azotea
• Radio planning / mapa GIS
• Pago / cuota de asociación
• Multi-vocal / multi-bloque
• Speedtest (otro producto; no es RAMAL)
• Chat / kanban (fue PREGÓN)

4. Fuera para siempre en este nombre

Movistar. Cobertura como promesa. Router de casa como nodo. Instalación el día del alta.

5. Criterio para abrir L4

Solo si un día futuro elige telecom L4 y la diversidad ALS-2 lo permite. No parche silencioso.

16-interaction-specs.md

16 — Especificación de interacción — RAMAL

1. Convenciones

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

2. Portada (UI-01) + mobile (UI-02) · H-FULL

AC: nombre, lead y 3 datos visibles sin hover. 3 nodos en el recorte 16/10 (AP-21). Cero botones Cobertura / Mbps / Crear cuenta.

El aviso «RAMAL no instala hoy» es texto, no un CTA de instalación. [DECISIÓN]

390: mismas 3 nodos apilados. No carousel. [DECISIÓN]

3. Alta checklist (UI-03) + mobile (UI-04) · F-ONB

AC: una pantalla. Cero stepper. Los 4 checks son el job, no un modal.

4. Acuse (UI-05)

No GET público por código. [DECISIÓN] doc 11.

5. Login (UI-06)

6. Mesa split (UI-07) + ficha (UI-08)

Desktop: dos columnas. 390: ficha a pantalla; volver a lista = /mesa. [DECISIÓN]

7. Loading / empty / error (UI-09…11)

Skeletons pulse. Empty usa titular display, no un illustration pack. Error no usa copy de 112.

17-prototype-map.md

17 — Mapa de prototipo — RAMAL

Paper file: 01M0M4FJGXPG315PDNT7PCAY3J
https://app.paper.design/file/01M0M4FJGXPG315PDNT7PCAY3J

UX process → docs

UI producto → app

Guión de prototipo

1. Cover → Portada (3 nodos).
2. Alta checklist Inés.
3. Acuse RM-XXXX.
4. Login Pablo.
5. Mesa · RM-2201 · Aceptar.
6. Empty / error / loading.

No hay artboard de speedtest, chat, kiosk de horas ni kanban.

18-completeness-audit.md

18 — Auditoría de cierre — RAMAL

1. Alcance L3

2. Terna y diversidad

3. Copy irrenunciable

Presente en alta, acuse, ficha, pie de portada. Ver doc 09.

4. Anti-patrones vigilados

5. Seed

3 nodos · 5 altas (3 PENDIENTE, 2 ACEPTADA) · Pablo VOCAL · Inés sin cuenta.

6. Huecos conscientes (fuera)

GIS, pago, login Nerea, email transaccional, instrumentación analytics.

7. Veredicto

Slice L3 cerrado a nivel de case. El código se escribe en paralelo con el mismo contrato. Si el repo diverge, gana docs 05 + 20 tras alinear ambos.

19-backlog-completo.md

19 — Backlog — RAMAL

1. Done (Must L3)

2. Could L+1 (no bloquea cierre)

3. Explícito L4 / otro brief

4. No-backlog (rechazado)

Hero 2-col. Signup vecina. leftover TEMPLE como feature. Movistar. «Instalar hoy».

5. Cómo usar este archivo

Done = el día. Could = L+1. E = otro cron. Nada de esta lista es deuda del L3.

20-implementation.md

20 — Implementación — RAMAL

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.

El código se escribe en paralelo a esta suite. Contrato: nodes + altas + JWT VOCAL. Puerto 3022. Health ramal-api.

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

2. Cómo arrancar

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

# apps/api/.env
#   DATABASE_URL=   # Neon gentle-bonus-75761237
#   JWT_SECRET=
#   PORT=3022

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

Credenciales

Vecina / técnica: sin cuenta. Inés pide alta en /alta. Nerea no entra.

3. Schema

Al boot o vía migrate:

1. CREATE TABLE de users, sessions, nodes, altas (doc 05).
2. Índices: nodes(slug), altas(code), altas(status), users(email).
3. Seed idempotente:
   • upsert VOCAL pablo@ramal.vallecas (bcrypt de password123)
   • upsert nodes por slug (azotea, bloque, arqueta)
   • upsert altas por code (RM-2201…RM-2205)
4. Dominio: solo nodes + altas + users. [DECISIÓN]

No borrar altas nuevas de Inés/Marisa en cada boot si ya existen filas distintas al seed (upsert por code no pisa status de altas ya decididas).

Generador de código: SELECT max(code) numérico + 1, formateado RM- + 4 dígitos. Seed máximo 2205 → siguiente POST = RM-2206. Si se agota 9999, L+1 amplia a 5 dígitos; no es Must.

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 === VOCAL protege mesa.
• Públicos: health, nodes, nodes/:slug, POST altas, login.

Oficio

Health (referencia de implementación)

HealthService.name = 'ramal-api'
main.ts PORT default 3022

Alta (referencia)

require vivienda && planta && azotea && noInstala
node = nodes.bySlug(nodeSlug)
code = next RM-
INSERT PENDIENTE
return Alta camelCase con nodeName

JSON camelCase: neighborName, nodeSlug, nodeName, nodeKind, sortOrder, createdAt, decidedAt, data1.
SQL: neighbor_name, node_id, sort_order, created_at, decided_at, data_1.

POST no cobra, no instala, no llama a Nerea, no mueve kanban.

Módulos de dominio: nodes/, altas/, mesa/, auth/, health.

5. Frontend a implementar

Estados: loading / ready / empty / error en portada y mesa.
Token key: ramal.accessToken.
Proxy: /api → :3022.

Tokens Tailwind: ground / ink / card / mark / mute / seal. Fuentes Newsreader + Figtree.

6. Seed visible en UI

Playwright: esperar Inés Soto y Azotea Palomeras. No esperar Lola, Los Yesos, turno.

7. Smoke

apps/api/scripts/test-api.mjs · pnpm test:api contra :3022.

Cubre health, 3 nodos, POST alta, 400 checklist, 401 mesa, login VOCAL, lista ≥5, ficha RM-2201, PATCH + 409.

8. DoD técnico

Ver doc 14. Este archivo no lista leftover de otro día como estado del producto. El contrato vivo es RAMAL.