00-day-brief.md

00 — Day brief · 2026-08-18 · ZAGUÁN

Decisiones ALS-2 BRIEF

Terna unicidad

R-IN · S-WIZ · H-WIZARD · F-CMP

0 códigos iguales a N−1 (MARGEN). ≥2 distintos vs N−2 (CESTA) y N−3 (RONDA). Ventana 4 días tenía 2× R-CL (CESTA, MARGEN) → hoy R-IN.

Ground (CRON §5.6)

• Familia: G-CONCRETE
• Hex: #E3E1DC
• Por qué: hormigón fresco / reja. No es G-GALLERY #FFFFFF (MARGEN), G-MOSS (CESTA), G-CHROME (RONDA), G-WATER (DERIVA) ni G-MUNICIPAL (PIZARRA). No es beige por inercia: el suelo es gris mineral frío.

Mood visual (Paper)

• Candidatos: mineral (primer instinto), rusted, industrial, chapel, nocturnal
• Elegido: rusted — no el primer instinto mineral (agencia caliza previsible)
• Paleta: #E3E1DC hormigón · #1F1D1B grafito · #B54A2A óxido · #6A6560 hierro · #F3F1EC caliza (cards) · #C9C4BB junta
• Tipo: Instrument Serif display · Sora UI (evita Cormorant / Public Sans / Spectral / Manrope / Zilla / Mulish / Newsreader / Outfit / Lora / Karla)

Alcance L1 must

1. Wizard 3 pasos: zona+tipo → presupuesto+habitaciones → musts (ascensor, terraza, mascotas, reforma)
2. Comparador 3 columnas con datos reales (precio, m², planta, gastos, extras)
3. Ficha de finca
4. Login + mesa AGENTE JWT (DRAFT → PUBLISHED)
5. Alta de finca + success
6. Empty (0 matches) / loading / error / mobile wizard
7. ≥12 UX + ≥10 UI

Microcopy duro

• Comparar ≠ reservar. El comparador no pide ni confirma una visita.
• Criterio ≠ oferta. El presupuesto del wizard no es una oferta vinculante.
• Publicado ≠ visitado. La finca en mesa no implica que alguien haya entrado.
• ZAGUÁN no llama. La agencia llama; el producto no agenda slot (≠ F-BOOK / ≠ F-LEAD).

Supuestos

• S1: Una agencia de barrio lleva 8–20 fincas activas; la demo tiene 5 publicadas + 1 DRAFT.
• S2: Quien busca piso compara 2–3 anuncios en pestañas; no rellena un lead para «que le llamen».
• S3: La mesa es 1 agente; no un CRM de captación.
• S4: No hay pasarela, señal, ni contrato. El producto es criterio + comparación + catálogo.

Hipótesis

00-paper-reference.md

Paper reference · ZAGUÁN

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 Wizard 1 zona · UI-02 Wizard 2 presupuesto · UI-03 Wizard 3 musts · UI-04 Comparador 3 cols · UI-05 Ficha · UI-06 Login · UI-07 Mesa · UI-08 Alta · UI-09 Success · UI-10 Empty · UI-11 Error

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. ZAGUÁN es wizard: el núcleo es zona → presupuesto → musts → 3 columnas y mesa → alta → publicar.

Loading (skeletons de 3 columnas / hold de wizard) y mobile wizard (~390px, variante de UI-01…03) se especifican en docs 16 y 17; no ocupan un board extra del inventario de 12. [DECISIÓN]

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 W1 → W2 → W3 → comparar → ficha · mesa en fila login → lista → alta → success · mobile wizard debajo de UI-01. [DECISIÓN] Bandas jerárquicas D-P0-04 / D-P1-04.

2. Mapeo Paper → Angular

[COMPROBADO] Rutas del encargo. No hay /visita, /reservar, /lead, search-first ni hero 2-col.

Loading y mobile no tienen artboard propio en el inventario de 12: el loading es skeleton sobre UI-04 / UI-01; el mobile es la misma ruta / a 390px. Ver docs 16 y 17.

3. Tokens de diseño en Paper

[COMPROBADO] Hex y tipo salen de docs/00-day-brief.md. Mood elegido: rusted, no el primer instinto mineral (agencia caliza previsible).

4. Checklist de densidad (anti thin-frames)

5. Media

• assets/hero.jpg — atmósfera de zaguán / portal de finca de barrio, reja y hormigón
• assets/listings/amparo.jpg — Calle Amparo 14, 3º D, Usera (patio, sin ascensor)
• assets/listings/albufera.jpg — Av. de la Albufera 212, 5º, Vallecas (terraza, ascensor)
• assets/listings/yeserias.jpg — Paseo de Yeserías 8, bajo, Usera (mascotas OK)
• assets/listings/sicilia.jpg — Calle Sicilia 9, 2º, Entrevías (reforma, ascensor)
• assets/listings/alegria.jpg — Calle de la Alegría 3, ático, Orcasur (terraza, sin ascensor)

[COMPROBADO] Los seis archivos existen en el case 2026-08-18-zaguan/assets/. El DRAFT merced-2 no tiene foto pública.

6. Enlaces

• Paper: https://app.paper.design/file/01M09V13JEANPFFD6DS1RCN29G
• Case: /Users/cristian/orca/ux-projects/2026-08-18-zaguan/
• App: /Users/cristian/orca/zaguan-app/
• GitHub: https://github.com/Criscode2022/zaguan-app
• Neon project: curly-recipe-23023272
• API: http://localhost:3018
• Web: http://localhost:4200

01-project-definition.md

01 — Definición de proyecto — ZAGUÁN

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] Quien busca piso en el sur de Madrid no rellena un lead para «que le llamen»: abre seis pestañas de Idealista y compara de memoria. El presupuesto se lee como oferta, el anuncio publicado se lee como «ya lo he visitado» y el botón «pedir visita» se lee como cita confirmada. [SUPUESTO] Una agencia de barrio lleva 8–20 fincas activas; no opera un CRM de captación ni una pasarela de señal.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Una agencia de barrio lleva 8–20 fincas activas; la demo tiene 5 publicadas + 1 DRAFT. [SUPUESTO]
• S2: Quien busca piso compara 2–3 anuncios en pestañas; no rellena un lead para «que le llamen». [SUPUESTO]
• S3: La mesa es 1 agente; no un CRM de captación. [SUPUESTO]
• S4: No hay pasarela, señal, ni contrato. El producto es criterio + comparación + catálogo. [SUPUESTO]

Hipótesis de producto

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

3. Propuesta de valor

No es ZAGUÁN

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L1 inmobiliario wizard + comparador con Listing + JWT AGENTE + Comparison opcional.
• Portfolio coherente: Paper (12 UX + 12 UI) + docs + app runnable.
• Terna R-IN · S-WIZ · H-WIZARD · F-CMP frente a MARGEN (galería/masthead), CESTA (tabla/rail) y CANTERA (dock de parte).

Usuario

No objetivos v1 (explícitos)

• Lead, teléfono del buscador, «te llamamos»
• Reserva de visita / calendario / slot
• Cuenta de buscador, favoritos, alertas
• Pasarela, señal, contrato, scoring hipotecario
• Multi-agente, comisiones, captación
• Mapa de fincas, street view, tour 3D
• Portal multi-agencia / scrap de Idealista
• App nativa ni notificaciones push

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: AGENTE. El buscador es anónimo. La propietaria no es un rol de sistema: es persona / stakeholder que usa la cara pública (o habla con Lucía fuera).

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 completar el wizard sin autenticación y ver hasta 3 fincas comparadas.
2. Un visitante puede abrir una ficha sin cuenta y sin encontrar un CTA de reserva o «te llamamos».
3. La UI dice explícitamente que comparar no es reservar, que el criterio no es oferta, que publicado no es visitado y que ZAGUÁN no llama.
4. Sin token, GET /api/mesa/listings y POST/PATCH de listings responden 401.
5. GET /api/listings devuelve solo PUBLISHED; el DRAFT merced-2 no aparece.
6. GET /api/listings/:slug de un DRAFT responde 404 (no 200 + aviso).
7. Un AGENTE puede iniciar sesión y ver la mesa con DRAFT y PUBLISHED.
8. El AGENTE puede crear una finca y publicarla (DRAFT → PUBLISHED).
9. La home es el paso 1 del wizard: no hay hero 2-col + 3 cards como superficie principal.
10. Fotos reales en las 5 fincas publicadas (assets del case).
11. El comparador muestra precio, m², planta, gastos, extras en 3 columnas.
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-IN · S-WIZ · H-WIZARD · F-CMP. 0 códigos iguales a N−1 (MARGEN). ≥2 distintos vs N−2 (CESTA) y N−3 (RONDA). Ventana 4 días tenía 2× R-CL (CESTA, MARGEN) → hoy R-IN. Ground G-CONCRETE #E3E1DC, no G-GALLERY.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — ZAGUÁN

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 búsqueda de alquiler en Madrid sur, portales (Idealista / Fotocasa) y agencias de barrio con escaparate en Marcelo Usera.
• Analogía operativa con wizard de criterios + mesa JWT de la serie daily.
• Restricciones ALS-2: no lead, no reserva, no galería editorial, no tabla de necesidades, no parte de obra.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: la agente (quien publica el escaparate) y, en difusión, el boca a boca del local.
• Usuario frecuente de comparación: BUSCADOR (wizard + 3 columnas + ficha).
• Usuario frecuente de publicación: AGENTE (mesa).
• Riesgo de rechazo: si la home no es el paso 1; si el comparador parece un formulario de visita; si un DRAFT se filtra.

4. Personas

P1 — Marcos Vidal · BUSCADOR

Escenario: Abre ZAGUÁN, elige Usera + ALQUILER, tope 950 €, 2 hab, no exige ascensor, compara Amparo 14 y Yeserías 8, abre la ficha del 3º. No se registra.

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

P2 — Lucía Ferrer · AGENTE

Escenario: Login → mesa → ve Calle de la Merced 2 en DRAFT → termina → Publicar → success con aviso de que publicado no es visitado.

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

P3 — Inés Roldán · PROPIETARIA

Escenario: Abre el comparador (o se lo enseña Lucía), ve Amparo 14 al lado de Yeserías 8. No hay botón Reservar.

[DECISIÓN] Inés no es rol de sistema. No hay login PROPIETARIA en L1. Evita convertir ZAGUÁN en CRM de captación.

Anti-personas

5. JTBD y user stories

Job principal (BUSCADOR)

Cuando busco piso en el barrio y ya tengo tope y zona,
quiero dejar el criterio y ver tres fincas a la vez,
para no abrir seis pestañas ni dejar el móvil a un captador.

Job principal (AGENTE)

Cuando entra un piso o termino las fotos,
quiero listar las fincas, dar de alta la que falta y publicarla,
para que el barrio vea solo lo cerrado y yo no confunda borrador con escaparate.

Job principal (PROPIETARIA)

Cuando mi piso está en alquiler,
quiero que se compare con otros dos del barrio,
para que se entienda el precio sin que ZAGUÁN reserve la visita.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L1)

6. Journey (BUSCADOR → AGENTE)

Momentos de verdad

1. Paso 1 en el primer viewport — si hay que “descubrir la marca”, se rompe H-WIZARD. [HIPÓTESIS]
2. Comparador sin botón de reserva — si aparece “Pedir visita”, H2 falla.
3. DRAFT invisible en público — prueba de integridad de catálogo.
4. Success de mesa dice que publicado no es visitado — evita la mentira de la visita.
5. Tope etiquetado como criterio — si el paso 2 dice “tu oferta”, H2/microcopy fallan. [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

ZAGUÁN se diseña como configurador de barrio que compara y publica, no como portal de leads, no como agenda de visitas y no como lookbook editorial.
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 — ZAGUÁN

1. Principios de IA

2. Sitemap

/                                      Wizard paso 1 · zona + tipo (público)     H-WIZARD
/criterio/presupuesto                  Wizard paso 2 · tope + habitaciones
/criterio/musts                        Wizard paso 3 · ascensor / terraza / mascotas / reforma
/comparar                              Comparador 3 columnas (público)
/fincas/:slug                          Ficha de finca (público si PUBLISHED)
/login                                 Login JWT AGENTE
/mesa                                  Lista de fincas (auth AGENTE)
/mesa/nueva                            Alta de finca (auth AGENTE)
/mesa/ok/:slug                         Success post-publicación (auth AGENTE)
/**                                    → redirect /

Árbol por audiencia

[COMPROBADO] Nueve rutas del encargo L1. No se inventan /visita, /reservar, /lead, /favoritos, /mesa/:id.

3. Navegación

Chrome de pasos (S-WIZ)

[DECISIÓN] El chrome de pasos es la única navegación primaria de la cara pública. Encaja L1 compacto. No hay masthead (MARGEN), no rail (CESTA), no dock (RONDA / CANTERA).

Desktop ≥960px: wordmark a la izquierda; pasos 1—2—3 a la derecha o centrados; rule junta bajo el chrome; óxido en el paso activo.
Mobile ~390px: wordmark + “1 de 3”; los labels Zona / Presupuesto / Musts se compactan. [DECISIÓN] En 390 no se introduce hamburger de marketing.

Pública (además del chrome)

[DECISIÓN] No hay /fincas índice. El catálogo se compara, no se lista. Un listado facetado sería H-SEARCH / L+1.

AGENTE (autenticado)

[DECISIÓN] L1: 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.

En mesa el chrome de pasos desaparece: la trastienda no finge un wizard. Wordmark + Mesa + Salir bastan. [DECISIÓN]

4. Inventario de contenido

5. Taxonomía

PublishStatus (Listing)

Orden de mesa: updatedAt descendente (lo último tocado primero).
[DECISIÓN] No hay RESERVED / VISITED / OPTIONED: S3, mesa de 1 agente.

Zona

Tipo

[DECISIÓN] tipo no es ático/bajo: eso vive en floorLabel y extras.

Listing (líneas seed)

[COMPROBADO] Cinco publicadas + un DRAFT cubren el must del brief. El DRAFT extra es para que la mesa no sea una lista de solo publicados. [DECISIÓN]

Musts (booleanos)

6. Modelo mental vs UI

7. Query string y estado de criterio

El wizard persiste el criterio en el cliente (sessionStorage zaguan_criteria) y lo reenvía en POST /api/compare.

Únicos query admitidos en URL:

[DECISIÓN] Sin ?q= ni chips de zona en una home-listado. Eso sería H-SEARCH.

Campos del criterio (cliente + POST compare):

zona, tipo, maxRent, rooms, elevator, terrace, pets, renovation

Paso 2 no avanza sin zona + tipo. Paso 3 no avanza sin maxRent + rooms. Comparar no corre sin los tres pasos. [DECISIÓN]

8. Rutas API alineadas a IA

[COMPROBADO] Contrato del encargo (Listing, AGENTE, compare). No se documentan visitas, leads ni POST /api/visits como Must.

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — ZAGUÁN

Convenciones

• Actor: Guest (BUSCADOR / PROPIETARIA) | AGENTE
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico: F-CMP (criterio 3 pasos → 3 columnas → ficha)
• Flujo de mesa: login → lista → alta → publicar

F1 — Wizard paso 1 · zona + tipo (BUSCADOR)

/  → H-WIZARD paso 1
   → chips zona · tipo ALQUILER | VENTA
   → sessionStorage.zaguan_criteria { zona, tipo }
   → Siguiente → /criterio/presupuesto
   → pie “Soy agente” → /login

Éxito: criterio tiene zona + tipo; avanza al paso 2.
AC: no hay que hacer scroll de “marca” para llegar a los chips. No hay hero 2-col.

Errores / estados

F2 — Wizard paso 2 · presupuesto + habitaciones (BUSCADOR)

/criterio/presupuesto
   → si no hay zona → redirect /
   → input/slider maxRent · chips 1 / 2 / 3+
   → disclaimer “Esto es un criterio, no una oferta.”
   → Atrás / Siguiente → /criterio/musts

Éxito: maxRent + rooms persistidos.
Rango demo: 500–1500 €, step 10. Default sugerido 950 (Marcos). [DECISIÓN]

F3 — Wizard paso 3 · musts (BUSCADOR)

/criterio/musts
   → si falta tope → redirect /criterio/presupuesto
   → toggles elevator, terrace, pets, renovation (default OFF)
   → Atrás / Comparar → POST /api/compare → /comparar

Éxito: criterio completo; navega a 3 columnas o empty.
AC: OFF significa “me da igual”, no “sin ascensor”. [DECISIÓN]

Default OFF = no filtrar por ese must. ON = filtro duro.

F4 — Comparador 3 columnas (BUSCADOR)

/comparar → POST /api/compare { zona, tipo, maxRent, rooms, elevator, terrace, pets, renovation }
          → { criteria, listings[≤3] }
          → 3 cols  |  empty  |  error  |  skeleton
          → click columna → /fincas/:slug

Éxito: hasta 3 fincas PUBLISHED alcanzables, o empty accionable.
AC columnas: cada una muestra precio, m², planta, gastos, extras. Cero botones Reservar / Te llamamos.

Ranking [DECISIÓN]

1. Solo PUBLISHED.
2. Filtros duros: tipo, maxRent (renta ≤ tope), musts ON.
3. Preferencia: misma zona, luego rooms exactas, luego renta más cercana al tope por debajo.
4. Devuelve hasta 3. Si hay más de 3, top-3. Si hay 1–2, se muestran huecos vacíos (no se inventan fincas). Si hay 0, UI-10.

Guión Marcos (demo): zona USERA, ALQUILER, 950 €, 2 hab, musts OFF → amparo-14 (890) + yeserias-8 (820). Tercera columna vacía o, si se relajara zona, alegria-3 no entra por 1 hab. [COMPROBADO de seed] 2 matches exactos.

Errores / estados

[DECISIÓN] GET /api/listings con query es el listado crudo (Could en UI). El Must de producto es POST compare.

F5 — Ficha de finca (BUSCADOR)

/fincas/:slug → GET /api/listings/:slug
              → cover, dirección, zona, precio, m², planta, gastos, extras, cuerpo
              → “ZAGUÁN no llama. Si hay visita, la agencia llama.”
              → enlace Comparar → /comparar
              → 404 slug DRAFT o inexistente → mensaje + volver al wizard

Éxito: finca leíble; disclaimer visible; no hay reserva ni teléfono de captación.
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.

F6 — Login JWT (AGENTE)

/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=AGENT, nombre Lucía Ferrer.
Credencial demo: lucia@zaguan.barrio / password123.

F7 — Mesa de la agencia (AGENTE)

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

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

Seed: 5 PUBLISHED + merced-2 DRAFT.

F8 — Alta de finca (AGENTE)

/mesa/nueva
  → validación cliente
  → POST /api/listings {
        title, address, zona, tipo,
        sqm, rooms, rent, expenses, floorLabel,
        elevator, terrace, pets, renovation,
        cover, body
     }
  → 201 Listing { 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 buscador en v1.

Errores

[DECISIÓN] Crear siempre como DRAFT. El botón Publicar del form hace POST + PATCH. Ver doc 20.

[COMPROBADO] Entidad Listing según encargo.

F9 — Publicar desde la mesa (AGENTE)

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

Transiciones (máquina simple L1)

Éxito: badge actualizado; la finca aparece en GET /api/listings y puede salir en compare.
Errores: 404 id; 401 sin token; 400 status inválido.

Regla de integridad (ops): Publicar no crea una visita, una llamada ni un lead. Publicado ≠ visitado. ZAGUÁN no llama.

F10 — Success de publicación (AGENTE)

/mesa/ok/:slug → copy de acuse + título/slug
               → “Publicado no es visitado.”
               → “El barrio ya puede compararla. Nadie ha subido todavía.”
               → CTA ver finca 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]

F11 — Logout (AGENTE)

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

Matriz de errores global

Flujos fuera de alcance v1

• Registro / recuperación de password de AGENTE
• Cuenta de buscador / favoritos / alertas
• Reserva o confirmación de visita
• “Te llamamos” / captura de teléfono
• Notificación email “hay un piso nuevo”
• Filtros multi-criterio en mesa
• Detalle /mesa/:id
• Mapa / street view
• Pasarela / señal / contrato

05-data-model.md

05 — Modelo de datos — ZAGUÁN

1. Visión general

Dominio L1 de inmobiliaria de barrio + mesa de publicación:

Base: PostgreSQL (Neon project curly-recipe-23023272) · 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

Zona

USERA | VALLECAS | ENTREVIAS | ORCASUR

Tipo

ALQUILER | VENTA

3. Diagrama ER (texto)

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

sessions
  id, user_id → users
  token_hash, expires_at
  created_at

listings
  id, slug (unique)
  title, address, floor_label
  zona (USERA | VALLECAS | ENTREVIAS | ORCASUR)
  tipo (ALQUILER | VENTA)
  sqm, rooms, rent, expenses
  elevator, terrace, pets, renovation
  cover, body
  status (DRAFT | PUBLISHED)
  created_at, updated_at

comparisons                  -- opcional
  id
  zona, tipo, max_rent, rooms
  elevator, terrace, pets, renovation
  listing_slugs (TEXT[] o JSON)
  created_at

No hay FK entre listings y users en v1: la agente opera sobre el conjunto global.
No hay FK buscador: comparar es anónimo.

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.

listings

extras no se persiste como columna suelta: se deriva para el comparador (patio vive en body / un campo libre opcional extras TEXT). [DECISIÓN v1] columna opcional extras TEXT para “patio”, “terraza”, “mascotas OK”, “reforma”. Seed la rellena.

comparisons (opcional)

[DECISIÓN] Persistencia opcional. El Must del contrato es el response { criteria, listings }. Si no hay tabla, el POST compara en caliente y no guarda.

5. Reglas de integridad y negocio

6. Contratos API (resumen)

GET /api/listings (público)

Query opcional: zona, maxRent, rooms, elevator, terrace, pets, renovation.
Response 200: ListingCard[] solo PUBLISHED.

[
  {
    "id": "lst_amparo",
    "slug": "amparo-14",
    "title": "Calle Amparo 14, 3º D",
    "address": "Calle Amparo 14, 3º D",
    "floorLabel": "3º D",
    "zona": "USERA",
    "tipo": "ALQUILER",
    "sqm": 68,
    "rooms": 2,
    "rent": 890,
    "expenses": 42,
    "elevator": false,
    "terrace": false,
    "pets": false,
    "renovation": false,
    "extras": "patio",
    "cover": "amparo.jpg",
    "status": "PUBLISHED"
  }
]

JSON camelCase hacia el web. [DECISIÓN]

POST /api/compare (público)

Body

Response 200

{
  "criteria": {
    "zona": "USERA",
    "tipo": "ALQUILER",
    "maxRent": 950,
    "rooms": 2,
    "elevator": false,
    "terrace": false,
    "pets": false,
    "renovation": false
  },
  "listings": [ "/* hasta 3 ListingCard */" ]
}

Si 0 matches: { criteria, listings: [] } + empty UI-10.
Si se persiste Comparison: el id no es Must en response.

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

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

POST /api/auth/login

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

GET /api/mesa/listings (JWT)

Array Listing (incluir status), updatedAt desc. Sin token → 401. Incluye DRAFT.

POST /api/listings (JWT)

Body

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

PATCH /api/listings/:id (JWT)

Body: { status?: PublishStatus, ...campos editables }
Mínimo Must: { status }.
Response: Listing actualizada. Sin token → 401.

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

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

AGENTE

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

Listings PUBLISHED

Listing DRAFT

Gastos (expenses) son catálogo demo, no cuotas reales de comunidad. [SUPUESTO de catálogo]

Textos de body son contenido de producto demo, no anuncios de una agencia real. [SUPUESTO de catálogo]

Las seis fincas son seed de producto. No se presentan como cartera real de una agencia de Marcelo Usera. [SUPUESTO de catálogo]

8. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — ZAGUÁN

1. Visión

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

2. Estructura

zaguan-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 (/visits, /leads, /favorites).

4. Justificación

5. Variables

.env local (nunca git):

.env.example solo placeholders.
Web: URL de API en ApiService (default http://localhost:3018/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: Instrument Serif + Sora (Google Fonts o self-host)

7. Arranque (contrato)

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

8. Lo que este stack no es

9. Nota sobre el repo existente

[COMPROBADO] Existe /Users/cristian/orca/zaguan-app y el remoto previsto Criscode2022/zaguan-app.
El scaffold contiene leftover de MARGEN (issues, pieces, events, fotos de semanario en public/assets/). Esta suite define el contrato ZAGUÁN; 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 — ZAGUÁN

1. Concepto

ZAGUÁN es un umbral de finca en pantalla: se entra con un criterio y se salen tres pisos, no una landing de “inmobiliaria digital”. El ground es hormigón fresco. Las columnas se apoyan como portales en una acera. El óxido es la reja, no un botón de marketing.

Mood elegido: rusted.
Primer instinto descartado: mineral / agencia caliza (piedra clara, serif de centro, “lujo sereno”). Ese mood ya huele a estudio de Chamberí. ZAGUÁN es Marcelo Usera, reja y junta.

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

2. Territorio visual

3. Paleta

Jerarquía de color: el hormigón carga; el óxido puntúa; la caliza encuadra la foto. Si el óxido pinta fondos enteros, deja de ser reja y se vuelve “brand rust”. [DECISIÓN]

4. Tipografía

Prohibido: Instrument Serif por debajo de 20px (se rompe). Sora en el wordmark (se vuelve startup).

Fuentes vetadas de la serie: Cormorant / Public Sans / Spectral / Manrope / Zilla / Mulish / Newsreader / Outfit / Lora / Karla.

5. Fotografía

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

Crop: columnas y ficha en 4:3 o 3:2 (fachada). No recorte 1:1 que corta el portal. [DECISIÓN] 4:3 de finca, distinto del 16:10 editorial de MARGEN.

Tratamiento: saturación real, sin LUT “real estate teal”, sin cielo HDR. El óxido no se superpone como filtro: vive en UI.

El DRAFT merced-2 no tiene foto pública. En mesa: placeholder junta + texto “sin foto”.

6. Layout

Chrome de pasos (S-WIZ)

ZAGUÁN                         1 Zona    2 Presupuesto    3 Musts
────────────────────────────────────────────  (rule junta 1px; óxido bajo el activo)

Wordmark a la izquierda. Pasos a la derecha o centrados. Sin hamburger en desktop. Sin “Agenda / Número / Blog”.

Home (H-WIZARD)

1. Titular Instrument Serif: ¿Por dónde entras?
2. Chips de zona (4) + tipo (2).
3. CTA Siguiente. Pie “Soy agente”.

No hay portada fotográfica a 60vh. hero.jpg puede vivir en UX-00 Cover, no como hero de producto. [DECISIÓN]

Comparador (F-CMP)

3 columnas caliza, misma retícula: foto 4:3 → dirección → precio → fila m² / planta / gastos → extras. Disclaimer bajo el criterio, sobre las columnas.

Ficha

Cover a ancho de columna (~720px), no full-bleed de marketing. Dirección → precio → datos → cuerpo. Blancos de umbral, no de landing.

Mesa

Lista densa sobre hormigón. No imita el comparador. Es trastienda: filas, badges, CTA óxido. Lucía no necesita “inspiración de marca” para publicar.

7. Motion

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

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

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

Cercano de portal y de reja. Tuteo. Segunda persona cuando habla la UI. Tercera cuando habla la ficha.

El producto se compara y se publica. No vende una hipoteca, no pide visita, no pide el móvil.

10. Criterios de aceptación creativos

1. Ground de página = #E3E1DC. Cards = #F3F1EC. Nunca al revés.
2. Óxido en el paso activo y en el CTA, no un header naranja lleno.
3. Comparador de 3 columnas visible en el primer viewport desktop (tras el criterio).
4. Ninguna fuente de la lista vetada.
5. Home reconocible como paso 1, no como hero 2-col de startup.
6. Success de mesa no celebra una “visita confirmada”.

08-design-system.md

08 — Design system — ZAGUÁN

1. Tokens

--color-concrete: #E3E1DC;   /* G-CONCRETE ground */
--color-graphite: #1F1D1B;
--color-rust:     #B54A2A;
--color-iron:     #6A6560;
--color-limewash: #F3F1EC;   /* cards only — caliza */
--color-joint:    #C9C4BB;
--color-draft:    #6A6560;   /* badge DRAFT */
--color-live:     #B54A2A;   /* badge PUBLISHED */

--font-display: "Instrument Serif", "Iowan Old Style", serif;
--font-ui:      "Sora", system-ui, sans-serif;

--radius-card: 2px;          /* junta de finca, no pill */
--radius-cta:  2px;
--rule-wiz:    1px solid var(--color-joint);
--space:       4 / 8 / 12 / 16 / 24 / 32 / 48 / 64;

Tailwind (referencia):

[COMPROBADO] Hex y tipo = brief.

2. Escala tipográfica

3. Componentes

Chrome de pasos (S-WIZ)

Slots: 1 Zona / · 2 Presupuesto /criterio/presupuesto · 3 Musts /criterio/musts.
Wordmark ZAGUÁN → / (reinicia).
Mesa no vive aquí.

Chip de zona / tipo / hab

┌──────────┐
│  Usera   │   idle: caliza + junta
└──────────┘   selected: óxido texto o rule 2px óxido

• <button type="button"> con aria-pressed.
• Target ≥44px.
• No pills 999px: radius 2.

Columna de comparador

┌─────────────────────────────┐
│ cover 4:3                   │
├─────────────────────────────┤
│ Dirección Instrument        │
│ 890 €/mes                   │
│ 68 m² · 3º D · 42 € gast.   │
│ patio                       │
└─────────────────────────────┘

• Fondo caliza, sin sombra.
• Toda la columna es un <a> a /fincas/:slug.
• Hover: rule 1px grafito. Sin lift.
• Hueco vacío (menos de 3): caliza + junta dashed + “Sin tercera finca”.

Ficha de finca

Fila de mesa

Badge DRAFT: texto hierro, rule junta.
Badge PUBLISHED: texto óxido o caliza sobre óxido ≥14 bold.

Botones

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

Form

Labels visibles (no placeholder-only). Inputs h-44, radius 2, rule junta, foco outline 2px óxido offset 2. Textarea cuerpo min 6 filas. Select de zona, tipo, cover (allowlist).

Tope de renta: input numérico + (Should) slider. El valor se lee en Sora 24.

Toggles de musts: switch o checkbox grande, label a la derecha. OFF = “me da igual”.

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 zaguán no es un set de iconos outline de casita.

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

6. Elevación y borde

Cero sombras shadow-lg. El portal 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 caliza; página en hormigón.
3. Primary CTA nunca en hierro sobre junta (contraste).
4. Instrument Serif no aparece en labels de form ni en badges.
5. Recorte de finca aspect-[4/3], no 16:10 editorial ni 1:1.
6. Targets de chips, pasos y CTA ≥44px.

09-content-guide.md

09 — Guía de contenido — ZAGUÁN

1. Voz

Cercana de portal y de reja. Tuteo en UI. Segunda persona cuando la interfaz habla. Tercera cuando habla la ficha.

Sin jerga de portales (“inmueble premium”, “oportunidad única”, “no te lo pierdas”). Sin sede electrónica. Sin “te llamamos en 5 minutos”.

El producto se compara y se publica. No vende una hipoteca, no pide visita, no pide el móvil.

2. Palabras permitidas / prohibidas

3. Microcopy duro (literales irrenunciables)

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

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

4. Microcopy por superficie

5. Fichas seed (tono)

Las fincas demo se escriben como nota de portal de barrio, no como folleto de obra nueva ni como copy de lujo.

No inventar declaraciones de vecinos reales. Si hay una voz, es de la ficha (neutra) o de persona de diseño etiquetada.

6. Nombres propios del seed

No inventar CIF, número de colegiada, ni precios oficiales de comunidad. [SUPUESTO de catálogo demo]
Rentas seed: 890 · 980 · 820 · 1050 · 760 · 870. No se afirman como mercado 2026.

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: ZAGUÁN en versales Instrument Serif (con tilde).
• Zonas: Usera, Vallecas, Entrevías, Orcasur (con mayúscula).
• Renta: 890 €/mes (espacio ante €, 24h no aplica).
• Superficie: 68 m² (espacio, superíndice).
• Planta: 3º D · bajo · ático (minúscula en común).
• Gastos: 42 € comunidad.
• No mezclar “€890/mo” estilo US.

9. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar “listing” en UI. En API sí: listings, maxRent.

10. Accesibilidad de copy

• No transmitir estado solo con color (“el óxido significa publicado”).
• Badge lleva texto: Borrador, Publicado.
• Alt de fotos: descriptivo de la finca, no “imagen1”.
  • hero: “Zaguán de finca de barrio, reja y hormigón.”
  • amparo: “Fachada y patio de Calle Amparo 14, Usera.”
  • albufera: “Bloque en la avenida de la Albufera, terraza en quinto.”
  • yeserias: “Bajo en el paseo de Yeserías, umbral a la calle.”
  • sicilia: “Portal de Calle Sicilia 9, Entrevías.”
  • alegria: “Ático con terraza en Calle de la Alegría, Orcasur.”

11. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad — ZAGUÁN

Objetivo: WCAG 2.2 AA. No se declara conformidad legal certificada.
Este documento cubre la UI (wizard, comparador, ficha, mesa). No audita la accesibilidad física de las fincas seed (ascensor, umbral, baño). [SUPUESTO]

1. Decisiones

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

3. Teclado

• Enter en chip = selecciona (aria-pressed).
• Enter en columna = navegar a ficha.
• Escape no cierra el wizard (no es modal).
• Focus trap: no hay modal Must.

4. Semántica

5. Lector de pantalla — copy

6. Producto vs finca física

[DECISIÓN] v1 no incluye auditoría a11y de sede. El campo elevator es dato de catálogo, no un certificado.

7. Riesgos

8. QA a11y (mínimo)

9. Criterios de aceptación

1. Ningún control del wizard o CTA mide menos de 44×44 CSS px.
2. El disclaimer no depende del color óxido para ser entendido.
3. Las 5 fotos seed + hero tienen alt no vacío y no genérico.
4. El foco no se pierde al reintentar un error de red.
5. En 390 el comparador no obliga a leer 3 columnas a la vez: hay snap.
6. Un DRAFT no se anuncia en el comparador.

11-privacy-security.md

11 — Privacidad y seguridad — ZAGUÁN

1. Datos que existen

No se pide cuenta al buscador. No hay teléfono, email ni nombre de Marcos en producto. No hay tracking de menores. Las fotos seed no identifican vecinos reales.

2. Minimización

Comparison persistida (si se activa) guarda criterio + slugs, no IP como identidad. [DECISIÓN] Si se persiste, retención corta (p. ej. 30 días) en L+1; v1 puede ser efímera.

3. Seguridad L1

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

4. Superficies de riesgo

5. Roles y autorización (recordatorio)

Inés y Marcos no tienen fila en users.

6. Criterios de aceptación

1. Response de login no incluye password ni password_hash.
2. GET público de merced-2 es 404.
3. GET /api/mesa/listings sin Bearer es 401, no 200 [].
4. No hay formulario público que pida teléfono o email del buscador.
5. .env no se commitea.

12-analytics.md

12 — Analítica — ZAGUÁN

North star: % de sesiones que llegan a /comparar con ≥1 columna y abren ≥1 ficha (compare_view + listing_open).

Instrumentación modelo. No hay proveedor conectado en v1 salvo que el build añada un logger local. [DECISIÓN] No se inventan cifras de conversión.

1. Eventos

2. Qué no se mide

Hipótesis H2: compare_view sin visit_click (el CTA no existe). Si en un test de 5 usuarios alguien busca el botón, se anota en research futuro, no como KPI inventado.

3. Funnel modelo (BUSCADOR)

paso 1  →  paso 2  →  paso 3  →  compare_view  →  listing_open

Activación = compare_view con matches ≥ 1.
Completud = listing_open en la misma sesión.

AGENTE: agent_login → listing_publish.

4. Integridad (producto, no vanidad)

5. Privacidad de analítica

Sin PII. Criterio se puede agregar (zona=USERA, maxRent en buckets de 50 €). No se guarda IP como usuario. Ver doc 11.

6. Criterios de aceptación (si se instrumenta)

1. Los 7 eventos de §1 tienen nombre estable.
2. No se dispara ningún evento de lead / visita / oferta.
3. Un bloqueador de cookies no rompe el wizard (analítica no es Must de runtime).

13-qa-test-plan.md

13 — Plan de pruebas — ZAGUÁN

1. Smoke obligatorio (D-P1-06)

[COMPROBADO] Smoke = listings + ficha + 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 (3 pasos, 3 columnas, disclaimer de reserva, ausencia de signup buscador, DRAFT 404).

6. Criterios de salida QA v1

• Smoke §1 en verde.
• S2, S3, S5, S6, S8, S11, S17, S21, S22, S25 en verde.
• Cero blockers de copy deshonesto (reservar / ofertar / te llamamos / visitado).
• Sin .env en el repo.

7. Fuera de este plan

Playwright e2e completo, carga, fuzzing, auditoría de una finca o agencia reales.

14-dev-handoff.md

14 — Handoff desarrollo — ZAGUÁN

1. Arranque

cd /Users/cristian/orca/zaguan-app

# apps independientes (npm --prefix o pnpm --filter)
# apps/api/.env
#   DATABASE_URL=  # Neon curly-recipe-23023272
#   JWT_SECRET=
#   PORT=3018

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

Demo: lucia@zaguan.barrio / password123.

2. Paridad Paper

Loading (skeleton 3 cols) y mobile wizard (~390) se implementan sobre las mismas rutas; spec en docs 16–17.

No clonar MARGEN (lookbook + masthead), CESTA (tabla + rail), RONDA (feed + dock), CANTERA (parte + dock) 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 público: si falta el paso anterior, /.
Soft guard mesa: si no hay token, /login?next=. La API es la autoridad.

[COMPROBADO] Solo estas rutas. No implementar /visita, /agenda, /piezas, /mesa/:id.

5. Assets

Copiar desde el case:

2026-08-18-zaguan/assets/hero.jpg
2026-08-18-zaguan/assets/listings/amparo.jpg
2026-08-18-zaguan/assets/listings/albufera.jpg
2026-08-18-zaguan/assets/listings/yeserias.jpg
2026-08-18-zaguan/assets/listings/sicilia.jpg
2026-08-18-zaguan/assets/listings/alegria.jpg
  → apps/web/public/assets/listings/   (hero a public/assets/)

cover del seed = filename (amparo.jpg, …).

Quitar leftover public/assets/{merienda,colegio,piscina,biblioteca}.jpg (semanario MARGEN) si sigue en el repo.

6. DoD implementación L1

7. No hacer

8. Contactos de diseño (artefactos)

15-roadmap.md

15 — Roadmap — ZAGUÁN

Este documento no es un cajón de trabajo L1 a medias.
El vertical slice L1 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 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 zaguan-app. El alcance L1 ya está cerrado en spec; el código alinea leftover (issues / pieces / events) al contrato.

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

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

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 L+1.

4. L3 (requiere brief nuevo de diversidad)

• Multi-agencia / varios locales
• Cuenta BUSCADOR y favoritos
• Calendario de visitas / F-BOOK
• Lead “te llamamos”
• Pasarela / señal / contrato
• Mapa como home
• Search-first (rompería terna)
• CRM de captación (40 estados)

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…11
3. Preview token + mismatch badges (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 — ZAGUÁN

1. Convenciones

Loading y mobile wizard (variante 390 de UI-01…03 y skeleton de UI-04) viven en este doc; no tienen artboard extra en el inventario de 12. [DECISIÓN]

2. Chrome de pasos (S-WIZ)

Estado activo: label óxido + filete 2px óxido bajo el ítem.
Estado default: hierro.
Estado bloqueado: hierro 50%, no es enlace.

Desktop: pasos a la derecha o centrados.
390: wordmark + “1 de 3 · Zona”. Los tres labels caben si se compactan a 1 / 2 / 3.

3. Paso 1 · zona + tipo (UI-01 · mobile variante)

AC: chips y titular están en el viewport inicial a 390 y a 1280 (sin hero de 60vh).

390: chips en wrap 2×2; CTA full-width h-44 al fondo del paso, no tapado por teclado (el paso 1 no abre teclado).

4. Paso 2 · presupuesto (UI-02)

El valor del tope nunca se etiqueta “oferta” ni “puja”.

5. Paso 3 · musts (UI-03)

Doble tap Comparar: ignorado mientras pending.

6. Comparador (UI-04) + loading

AC: precio, m², planta, gastos, extras visibles en cada columna sin hover. Disclaimer “Comparar no es reservar” sobre el fold desktop.

390: scroll-x scroll-snap-type: x mandatory; cada columna ~82vw; dots o “1/3” Sora 12. Criterio resumen sticky arriba.

Orden visual = score del API. No “destacados” por likes.

7. Ficha de finca (UI-05)

Sin doble tap like. Sin “llamar ahora”. Sin WhatsApp click-to-chat.

8. Login (UI-06)

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

9. Mesa (UI-07)

No swipe-to-archive. No kanban.

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

Publicar no anima unas llaves ni un “+1 visita”.

10. Alta de finca (UI-08)

Submit deshabilitado si address < 4, body < 40, rent vacío o zona vacía.

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

11. Success (UI-09)

Sin confetti. Sin “¡ya hay visitas!”.

12. Empty (UI-10) · Error (UI-11) · Loading · Mobile

13. Motion

Prohibido: scroll-jacking, page transitions de 400ms, parallax de portal, like animation, llaves girando.

14. Criterios de aceptación de interacción

1. Un BUSCADOR en 390px llega de paso 1 a comparar en 3 taps de CTA (Siguiente ×2 + Comparar).
2. Un AGENTE en 390px publica un DRAFT en ≤ 3 taps desde mesa (acción en fila).
3. Ningún submit permite doble POST.
4. El chrome no cubre el H1 del paso (spacer si sticky).
5. Reduced-motion elimina stagger y slide.
6. La home no es hero 2-col (AP-12).
7. En 390 el recorte 4:3 de la primera columna es visible (snap).
8. /comparar no presenta ningún control de reserva ni “te llamamos”.
9. El loading de compare es skeleton de 3 columnas, no un logo.
10. Paso 2 muestra “criterio, no una oferta” sin scroll en desktop.

17-prototype-map.md

17 — Mapa de prototipo — ZAGUÁN

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.

Loading y mobile no tienen board propio en el inventario de 12: se prototipan como estados / variantes de UI-01 (390) y UI-04 (skeleton). Ver doc 16.

Recorrido demo (guión)

1. Abrir / — paso 1 ¿Por dónde entras?; chips Usera / Vallecas / Entrevías / Orcasur.
2. Elegir Usera + Alquiler → Siguiente.
3. Paso 2: tope 950 €, 2 hab. Leer “Esto es un criterio, no una oferta.”
4. Paso 3: musts OFF → Comparar estas tres.
5. /comparar — columnas Amparo 14 (890) y Yeserías 8 (820); tercera hueco o vacía. Leer “Comparar no es reservar.”
6. Tocar Calle Amparo 14, 3º D — ficha, patio, “ZAGUÁN no llama.”
7. Comprobar que no hay botón Reservar ni Te llamamos.
8. /login — lucia@zaguan.barrio / password123.
9. /mesa — ver DRAFT Calle de la Merced 2.
10. Nueva finca o Publicar el DRAFT → /mesa/ok/:slug — “Publicado no es visitado.”
11. Volver a comparar 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.
• Llamada de Lucía a Inés / juego de llaves (backstage).
• Visita en el zaguán físico.
• Reserva de visita (no existe).
• Lead / teléfono.
• Mapa.
• Portal multi-agencia.

18-completeness-audit.md

18 — Auditoría de completitud — ZAGUÁN (2026-08-18)

1. Alcance auditado

Vertical slice L1: wizard de criterios + comparador de 3 fincas + ficha + mesa AGENTE JWT, con docs, referencia Paper, contratos Angular + Nest + Neon.

Este encargo cubre la suite documental. Paper hi-fi y el repo zaguan-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: 12 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-18.
La suite define producto L1 usable (tablas, AC, riesgos, contratos) sin presentar investigación de campo como hecho.
Cualquier ampliación visita / lead / mapa / search-first / lookbook requiere nuevo brief de diversidad, no parche silencioso.

19-backlog-completo.md

19 — Backlog completo — ZAGUÁN

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-18)

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

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

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

3. Backlog L+1 (polish)

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 + B07 si el empty es frecuente
5. Evaluar brief L3 — no parche silencioso

8. Trazabilidad