00-day-brief.md

00 — Day brief · 2026-08-20 · PREGÓN

Decisiones ALS-2 BRIEF

Terna unicidad

R-IN · S-SIDE · H-CHAT · F-KAN

0 códigos iguales a N−1 (MATIZ: R-HY · S-BOTTOM · H-BENTO · F-EDIT).
≥2 distintos vs N−2 (ZAGUÁN) y N−3 (MARGEN).
Ventana 4: R-HY + R-IN + R-CL + R-CL → hoy R-IN (sigue habiendo clásico en la ventana).

S-SIDE, H-CHAT y F-KAN no están en los últimos 5 (S-BOTTOM/WIZ/TOP/RAIL/DOCK · H-BENTO/WIZARD/GALLERY/TABLE/FEED · F-EDIT/CMP/STORY/LEAD/BOOK).

Ground (CRON §5.6)

• Familia: G-FOG
• Hex: #F1F3F6
• Por qué: fotocopia fría de un bando, no yeso de capilla (MATIZ), no hormigón (ZAGUÁN), no kiosco blanco (MARGEN), no musgo (CESTA), no cromo (RONDA).

Mood visual (Paper)

• Candidatos: chalky (primer instinto municipal), highlighter, brutalist, maritime, bookish
• Elegido: highlighter — no el primer instinto pizarra (eso fue PIZARRA). Un bando se marca con fluorescente, no con tiza.
• Paleta:
  • #F1F3F6 fotocopia (ground)
  • #12141A tinta de sello
  • #C8F000 rotulador fluorescente
  • #FFFFFF ficha
  • #5C6370 grafito
  • #C1121F lacre (acento de urgente, poco)
• Tipo: Ibarra Real Nova display · Jost UI (evita Libre Baskerville / Nunito / Instrument / Sora / Cormorant / Public Sans / Spectral / Manrope)

Alcance L1 must

1. Home chat: hilo de bandos del distrito + compositor de incidencia (calle, tipo, texto)
2. Acuse con código (enviado ≠ resuelto)
3. Login JWT OPERADOR
4. Mesa kanban Recibido / En curso / Cerrado
5. Ficha de parte + cambio de columna
6. Empty / error / loading / mobile chat
7. ≥12 UX + ≥10 UI

Microcopy duro

• Mensaje ≠ expediente. PREGÓN no abre un procedimiento SIA.
• Enviado ≠ resuelto. El acuse no apaga la farola.
• PREGÓN no cita. No hay slot ni “te llamamos a las 10”.
• PREGÓN no es 112. Urgencia vital fuera.

Supuestos

• S1: Un distrito atiende 8–20 partes/día; la demo tiene 7 partes en tres columnas.
• S2: El vecino escribe desde el móvil en la acera; no crea cuenta.
• S3: Un OPERADOR (Nuria) mueve columnas; no hay sede electrónica.
• S4: Tipos: farola, cubo, banco, acera, otro. Sin GIS.

Hipótesis

00-paper-reference.md

Paper reference · PREGÓ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 Chat home · UI-02 Chat mobile · UI-03 Composer · UI-04 Success · UI-05 Login · UI-06 Kanban · UI-07 Ficha · UI-08 Empty · UI-09 Error · UI-10 Loading · UI-11 Mesa mobile

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 — PREGÓ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] El vecino de un distrito del sur de Madrid no necesita otro formulario de sede: necesita decirle al distrito que la farola no enciende sin adivinar el procedimiento. Hoy eso vive en WhatsApp al vecino, llamada al 010 que no es el 112, y un acuse que se lee como «ya está arreglado». La operadora vive en una bandeja que no distingue recibido de cerrado. [SUPUESTO] Un distrito atiende 8–20 partes/día; no opera un SIA de consejería ni un GIS corporativo.

Secundarios

Supuestos (no investigación primaria propia)

• S1: Un distrito atiende 8–20 partes/día; la demo tiene 7 partes en tres columnas. [SUPUESTO]
• S2: El vecino escribe desde el móvil en la acera o el banco de la plaza; no crea cuenta. [SUPUESTO]
• S3: Un OPERADOR (Nuria) mueve columnas; no hay sede electrónica ni rol de brigada autenticado. [SUPUESTO]
• S4: Tipos: farola, cubo, banco, acera, otro. Sin GIS. [SUPUESTO]

Hipótesis de producto

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

3. Propuesta de valor

No es PREGÓN

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L1 admin pública local con Bando + Report + JWT OPERADOR.
• Portfolio coherente: Paper (12 UX + 12 UI) + docs + app runnable.
• Terna R-IN · S-SIDE · H-CHAT · F-KAN frente a MATIZ (bento/editor), ZAGUÁN (wizard/comparador) y MARGEN (galería/masthead).

Usuario

No objetivos v1 (explícitos)

• Sede electrónica, Cl@ve, certificado, DNI
• 112, policía, bomberos, urgencia vital
• Cita previa, slot, «te llamamos»
• GIS, mapa, coordenadas, inventario de farolas
• Cuenta de vecino, seguimiento con login, push
• Multi-operador, turnos, brigada autenticada
• Chat entre vecinos (foro)
• App nativa ni notificaciones push
• Rol JUNTA / JEFE autenticado

5. Roles y permisos (resumen)

[DECISIÓN] Un solo rol autenticado: OPERADOR. El vecino no es un usuario del sistema: es autora/autor de un report. La junta no es un rol de sistema el día 1.

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

7. Alcance funcional v1 (L1)

8. Criterios de aceptación de producto

1. / es el chat público. No pide cuenta. No es un hero 2-col + 3 cards.
2. Una vecina puede leer 3 bandos en el fold, escribir un parte (calle + tipo + texto + nombre) y obtener un código PG-XXXX.
3. /ok/:code dice explícitamente que enviado no es resuelto y que PREGÓN no es 112.
4. La UI dice explícitamente que mensaje no es expediente, que PREGÓN no cita y que PREGÓN no es 112.
5. Sin token, GET /api/reports, GET /api/reports/:code y PATCH responden 401. POST /api/reports y GET /api/bandos son públicos.
6. Un POST de parte crea status=RECIBIDO. Enviar no marca CERRADO.
7. Una OPERADOR inicia sesión y ve el kanban con 3 RECIBIDO, 2 CURSO, 2 CERRADO en el seed.
8. Una OPERADOR abre un parte y lo mueve de columna (RECIBIDO → CURSO → CERRADO).
9. Fotos reales en las partes seed (assets partes/*).
10. Tipos visibles: farola · cubo · banco · acera · otro.
11. Rail S-SIDE de estados en mesa desktop. Chat público sin top-nav de marketing.
12. Rutas solo las del doc 03. No existen /cita, /112, /sede, /expediente, /mapa.
13. GET /api/health devuelve service: "pregon-api" — no matiz-api.

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-SIDE · H-CHAT · F-KAN. 0 códigos iguales a N−1 (MATIZ). ≥2 distintos vs N−2 (ZAGUÁN) y N−3 (MARGEN). Ventana 4 días: R-HY + R-IN + R-CL + R-IN. Ground G-FOG #F1F3F6, no G-CHAPEL.

02-ux-research-strategy.md

02 — Estrategia de investigación UX — PREGÓ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 incidencias urbanas de barrio (farola, cubo, banco, acera; distinción 010 vs 112; acuse vs arreglo).
• Analogía operativa con chat público + mesa JWT de la serie daily.
• Restricciones ALS-2: no sede electrónica, no 112, no cita, no GIS, no cuaderno de oficio, no wizard inmobiliario.

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: la junta (quién publica el pregón) y, en uso diario, Nuria (quien mueve columnas).
• Usuario frecuente de escritura: VECINA / VECINO (chat, sin cuenta).
• Usuario frecuente de triaje: OPERADOR (mesa + ficha).
• Riesgo de rechazo: si el acuse parece resuelto; si el chat parece 112; si hay que crear cuenta; si la mesa parece un GIS.

4. Personas

P1 — Rosa Méndez · VECINA

Escenario: Abre / en el móvil, lee el bando del agua, elige farola, escribe plaza Elíptica, se llama Rosa, envía, lee «Enviado no es resuelto» y el código PG-XXXX.

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

P2 — Nuria Delgado · OPERADOR

Escenario: Login → mesa 3/2/2 → abre PG-2401 (Rosa, farola, plaza Elíptica) → mueve a En curso → no encuentra «citar» ni «112».

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

P3 — Andrés Peña · VECINO digital (secundario)

Escenario: Mismo chat. Tipo cubo, Marcelo Usera 42, envía, captura /ok/PG-XXXX. No entra a /mesa.

[DECISIÓN] Andrés no es rol de sistema. Es la misma superficie que Rosa, con menos fricción percibida.

Autoras/autores de seed (no personas primarias extra)

[COMPROBADO] Nombres salen del encargo. Los textos de parte son catálogo demo.

Anti-personas

5. JTBD y user stories

Job principal (VECINA)

Cuando la farola del banco no enciende y estoy sentada debajo,
quiero escribirle al distrito en el mismo hilo del bando,
para no adivinar el formulario ni crear una cuenta.

Job principal (OPERADOR)

Cuando abro la mesa por la mañana,
quiero ver lo recibido, lo que está en curso y lo cerrado,
para no cazar partes en una bandeja de correo.

Job secundario (VECINO digital)

Cuando veo el cubo rebosando de camino al metro,
quiero dejar calle, tipo y dos líneas,
para seguir andando con un código en el bolsillo.

Jobs secundarios

Stories Must (v1)

MoSCoW (v1 L1)

6. Journey (VECINA · farola de la plaza + OPERADOR)

Momentos de verdad

1. 3 bandos + compositor en el primer viewport — si hay que «descubrir la marca», se rompe H-CHAT / AP-21. [HIPÓTESIS]
2. Sin cuenta — si aparece «regístrate», S2 / H3 fallan.
3. Success dice que enviado no es resuelto — evita la mentira de la farola apagada.
4. Cero CTA de 112 como botón de envío y cero cita — si aparece «Llamar 112» como primary o «Pedir cita», el microcopy falla. (El aviso de que no es 112 sí debe verse.)
5. Kanban de 3 columnas, rail a la izquierda — S-SIDE / F-KAN. [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

PREGÓN se diseña como pregón que se escribe y se mueve de columna, no como sede, no como 112 y no como expediente.
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 — PREGÓN

1. Principios de IA

2. Sitemap

/                                      Chat público (bandos + compositor)           H-CHAT
/ok/:code                              Acuse post-envío                             público
/login                                 Login JWT OPERADOR                           público
/mesa                                  Kanban Recibido / En curso / Cerrado         F-KAN · auth
/mesa/:code                            Ficha de parte + mover columna               auth
/**                                    → redirect /  (si no hay token) o /mesa

Árbol por audiencia

[COMPROBADO] Cinco rutas del encargo L1. No se inventan /cita, /112, /sede, /expediente, /mapa, /hoy, /fichas.

3. Navegación

Chat público (sin top-nav de marketing)

[DECISIÓN] El chat no tiene tabs, no tiene hamburger, no tiene «Servicios / Sede / Cita». Un link «Mesa» discreto basta para Nuria.

Rail de mesa (S-SIDE)

[DECISIÓN] El rail es la única navegación primaria autenticada. Encaja L1 mesa. No hay bottom tabs (MATIZ), no masthead (MARGEN), no chrome de pasos (ZAGUÁN).

Desktop ≥960px: rail izquierdo 220–260px + tablero 3 columnas.
Mobile ~390px: el rail se convierte en segmentos Recibido / En curso / Cerrado + lista de esa columna (UI-11). [DECISIÓN] En 390 no hay hamburger de marketing ni tres columnas aplastadas.

Header contextual (mesa; no es nav primaria del chat)

[DECISIÓN] El wordmark en autenticado lleva a /mesa (no al chat), para no mezclar oficios. El wordmark en público lleva a /.

Login (público; solo oficio)

[DECISIÓN] No hay /registro. No hay «Soy vecina». No hay Cl@ve.

4. Inventario de contenido

5. Taxonomía

Role

[DECISIÓN] No hay VECINA / JUNTA / BRIGADA / COLORISTA.

ReportStatus

Orden de columnas: Recibido → En curso → Cerrado.
Orden dentro de columna: createdAt descendente (lo último arriba). [DECISIÓN]

Kind

Bandos (líneas seed)

[COMPROBADO] Tres bandos del encargo. [DECISIÓN]

Partes (líneas seed)

[COMPROBADO] Siete partes, 3/2/2, del encargo.

6. Modelo mental vs UI

7. Query string y estado

[DECISIÓN] Sin búsqueda facetada en v1. 7 partes se recorren a ojo. L+1: filtro por tipo.

El compositor no persiste borrador en sessionStorage como Must. Si se sale sin enviar, se pierde. Could L+1: draft local.

/ok/:code no hace GET JWT. El código vive en la URL. Detalle de calle/tipo: state del POST si existe. [DECISIÓN] D9.

8. Rutas API alineadas a IA

[COMPROBADO] Contrato del encargo. No se documentan citas, 112 ni POST /api/expedientes como Must.

GET /api/me es Could (el login ya devuelve user). Mesa puede pintar «Nuria Delgado» desde pregon_user en storage.

9. Decisiones de IA descartadas

04-user-flows.md

04 — Flujos de usuario — PREGÓN

Convenciones

• Actor: Guest (vecina/vecino anónimo) | OPERADOR
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica
• Flujo canónico vecino: F-CHAT (hilo → composer → POST parte → ok)
• Flujo canónico oficio: F-KAN (login → mesa → ficha → PATCH status)
• Junta / 112: no tienen flujo de sistema

F0 — Entrada pública (Guest)

/                     →  GET /api/bandos  →  hilo + composer
/ok/:code             →  acuse (sin GET JWT)
/login                →  si hay token válido  →  /mesa  (o next)
/mesa  sin token      →  /login?next=/mesa

Éxito: cara pública = hilo.
AC: no hay landing, hero 2-col ni Cl@ve. Chat-first.

F1 — Leer bandos (Guest)

/ → GET /api/bandos
  → 3 bandos anclados  |  empty  |  error  |  skeleton

Éxito: 3 bandos reales en el fold, o empty accionable (composer visible).
AC: cada bando muestra título + cuerpo. El compositor no espera a que carguen para mostrarse (Should: se muestra; Enviar espera).

Guión Rosa (demo): bnd_1 agua · bnd_2 enseres · bnd_3 no es 112. [SUPUESTO de catálogo] alineado al seed de doc 05.

F2 — Enviar parte (Guest) · F-CHAT

/ composer
  → street, kind, body, authorName
  → POST /api/reports
  → 201 Report { code, status: RECIBIDO, ... }
  → /ok/:code

Éxito: registro status=RECIBIDO + pantalla acuse.
No hay «Resuelto» ni «Citar» en v1.

JSON camelCase: authorName (el brief nombra author_name en SQL). [DECISIÓN]

Errores

[DECISIÓN] Crear siempre como RECIBIDO. Cover no viaja en el POST v1 (seed sí tiene cover).

[COMPROBADO] Entidad Report según encargo (code, street, kind, body, status, author_name).

F3 — Acuse (Guest)

/ok/:code → muestra código de la URL
          → si hay router state del POST: calle / tipo
          → “Enviado no es resuelto. El acuse no apaga la farola.”
          → “PREGÓN no es 112.”
          → CTA escribir otro → /

AC: el disclaimer es visible sin scroll en desktop.
No hace GET /api/reports/:code (JWT). Si se recarga, queda el código + copy; no se inventa el parte. [DECISIÓN] D9.

Código con formato inválido (no PG- + 4 dígitos): mismo acuse genérico; no 404 de producto público.

F4 — Login JWT (OPERADOR)

/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=OPERADOR, nombre Nuria Delgado.
Credencial demo: nuria@pregon.ayto / password123.

[COMPROBADO] Credencial del encargo.

F5 — Mesa kanban (OPERADOR) · F-KAN

/mesa (token)
  → GET /api/reports
  → { recibido[3], curso[2], cerrado[2] }
  → tablero  |  empty por columna  |  error  |  skeleton
  → tap card → /mesa/:code

Éxito: 3/2/2 en el seed, o empty por columna.
AC cards: cada una muestra código, tipo, calle. Cero botones Citar / 112 / Expediente.

Guión Nuria (demo): Recibido PG-2401 farola Rosa · PG-2402 cubo Andrés · PG-2403 acera Rosa. En curso PG-2404 banco · PG-2405 farola. Cerrado PG-2406 cubo · PG-2407 otro. [SUPUESTO de catálogo]

Query opcional: GET /api/reports?status=RECIBIDO (plano) o ?view=flat. Default: agrupado. [DECISIÓN]

[DECISIÓN] GET /api/reports es el Must de producto. No hay drag-and-drop Must: se cambia status en la ficha. Could: drag entre columnas en desktop.

F6 — Ficha de parte (OPERADOR)

/mesa/:code → GET /api/reports/:code
            → foto, código, calle, tipo, cuerpo, autora, fecha, status
            → “El mensaje no es un expediente. PREGÓN no cita.”
            → chips Recibido / En curso / Cerrado
            → PATCH /api/reports/:code { status }
            → 200 Report
            → 404 code inexistente → mensaje + volver a /mesa

Éxito: ficha leíble; disclaimer visible; status actualizado.
Error: 404 si code inexistente; 401 sin token.

AC ficha

Transiciones permitidas

[DECISIÓN] v1 permite cualquier transición entre los 3 estados (mesa humana, no workflow SIA). PATCH solo acepta { status }. No acepta editar calle/cuerpo (el parte es lo que escribió el vecino).

F7 — Mesa mobile (OPERADOR) · UI-11

/mesa ~390
  → segmentos Recibido | En curso | Cerrado
  → lista de la columna activa
  → tap fila → /mesa/:code

Misma API que F5. No se aplastan 3 columnas. El rail S-SIDE se convierte en segmentos. [DECISIÓN]

F8 — Logout (OPERADOR)

Mesa / rail → Salir → limpia localStorage → /login

No hay pantalla /cuenta Must (MATIZ sí la tenía; aquí el oficio cabe en el rail). [DECISIÓN]

F9 — Health (ops)

GET /api/health → 200 { ok: true, service: "pregon-api" }

Sin auth. No es una pantalla. Smoke de arranque.
[COMPROBADO] El leftover actual responde service: "matiz-api" y puerto 3019. El contrato de esta suite es pregon-api :3020.

Matriz de errores global

Flujos fuera de alcance v1

• Registro / recuperación de password de OPERADOR
• Cuenta de vecino / «mis partes» / push
• Cita o «te llamamos»
• 112 / derivación operativa
• GIS / mapa / coordenadas
• Foto en el POST
• Drag-and-drop de kanban (Could)
• Chat entre vecinos
• Nota interna a brigada
• Multi-operador / turnos

05-data-model.md

05 — Modelo de datos — PREGÓN

1. Visión general

Dominio L1 de pregón municipal + mesa autenticada:

Base: PostgreSQL (Neon project empty-surf-15969880) · IDs: cuid() o texto estable (usr_nuria, bnd_1, PG-2401).
[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

ReportStatus

Kind

farola | cubo | banco | acera | otro

3. Diagrama ER (texto)

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

sessions
  id, user_id → users
  token_hash, expires_at
  created_at

bandos
  id
  title, body
  pinned (boolean)
  created_at, updated_at

reports
  id
  code (unique, PG-XXXX)
  street, kind, body
  status (RECIBIDO|CURSO|CERRADO)
  author_name
  cover                 -- filename, nullable
  created_at, updated_at

v1: una sola OPERADOR opera sobre el conjunto global.
No hay FK de vecina-usuaria: la vecina no se loguea.
reports no apunta a users: el parte es anónimo de cuenta.

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 en mesa.

bandos

[DECISIÓN] GET público lista pinned = true orden created_at asc (el pregón se lee de viejo a nuevo, como un hilo). L+1: bandos no anclados.

reports

[DECISIÓN] SQL snake_case (author_name); JSON camelCase (authorName).

5. Reglas de integridad y negocio

6. Contratos API (resumen)

JSON camelCase hacia el web. [DECISIÓN]

GET /api/health

Response 200: { "ok": true, "service": "pregon-api" }

[COMPROBADO] El leftover responde service: "matiz-api". El contrato de esta suite es pregon-api.

GET /api/bandos

Público.

Response 200: Bando[]

[
  {
    "id": "bnd_1",
    "title": "Corte de agua",
    "body": "Jueves 21, de 10 a 14 h, en Marcelo Usera, tramo plaza Elíptica.",
    "pinned": true,
    "createdAt": "2026-08-18T08:00:00.000Z"
  }
]

Si 0: [] + empty UI-08.

POST /api/reports

Público.

Body

Response 201

{
  "code": "PG-2408",
  "street": "Plaza Elíptica, banco de la plaza",
  "kind": "farola",
  "body": "La farola del banco no enciende desde anoche.",
  "status": "RECIBIDO",
  "authorName": "Rosa Méndez",
  "cover": null,
  "createdAt": "2026-08-20T09:12:00.000Z"
}

DTO inválido → 400. No JWT.

POST /api/auth/login

Body: { email, password }
Response 200: { accessToken, user: { id, email, name, role, districtName } }
401 credenciales inválidas. Response sin hash.

GET /api/reports (JWT)

Response 200 agrupada (default)

{
  "recibido": [ { "code": "PG-2401", "street": "…", "kind": "farola", "body": "…", "status": "RECIBIDO", "authorName": "Rosa Méndez", "cover": "farola.jpg", "createdAt": "…" } ],
  "curso": [ ],
  "cerrado": [ ]
}

Query:

Sin token → 401.

GET /api/reports/:code (JWT)

Report completo o 404. Sin token → 401.

PATCH /api/reports/:code (JWT)

Body: { status: "RECIBIDO" \| "CURSO" \| "CERRADO" }
Response 200: Report actualizado.
No acepta street, body, kind, authorName.
Sin token → 401. Code inexistente → 404. Status inválido → 400.

[COMPROBADO] PATCH sobre :code. [DECISIÓN] solo status.

GET /api/me (Could)

JWT. { id, email, name, role, districtName }. El login ya trae user; no es Must del encargo.

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

OPERADOR

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

Bandos (3 · pinned)

Reports (7)

Calles, cuerpos y fotos son catálogo demo, no partes oficiales de una junta. [SUPUESTO de catálogo]

Conteos: 3 RECIBIDO · 2 CURSO · 2 CERRADO.
Rosa firma 4; Andrés firma 3.

created_at demo (Europe/Madrid, 2026-08-20):

Las siete partes y los tres bandos son seed de producto. No se presentan como registro oficial de Usera o Villaverde. [SUPUESTO de catálogo]

Usera y Villaverde son dos distritos reales de Madrid; la demo los trata como una mesa. No se afirma una junta unificada. [DECISIÓN]

8. Evolución posible (no implementada)

06-tech-stack.md

06 — Stack tecnológico — PREGÓN

1. Visión

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

2. Estructura

pregon-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 (/me, /expedientes, /geo).

4. Justificación

5. Variables

.env local (nunca git):

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

[COMPROBADO] Leftover web apunta a :3019 (environment.ts, proxy.conf.json). Contrato: 3020.

6. Dependencias de producto (mínimas)

API

• @nestjs/common / core / platform-express
• JWT (jose o @nestjs/jwt)
• bcrypt (o bcryptjs)
• cliente Postgres (pg / @neondatabase/serverless) o Prisma
• class-validator + class-transformer

Web

• Angular standalone
• Tailwind 3
• fuentes: Ibarra Real Nova + Jost (Google Fonts o self-host)

7. Arranque (contrato)

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

8. Lo que este stack no es

9. Nota sobre el repo existente

[COMPROBADO] Existe /Users/cristian/orca/pregon-app y el remoto previsto Criscode2022/pregon-app.
El scaffold es leftover de MATIZ: módulos clients, formulas, hoy, sittings; rol COLORISTA; health service: "matiz-api"; puerto default 3019; Tailwind chapel (yeso / amatista / Libre Baskerville / Nunito Sans); rutas /fichas, /cuenta; index.html título MATIZ; docs/neon.md describe tablas de colorista.

Esta suite define el contrato PREGÓ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 — PREGÓN

1. Concepto

PREGÓN es un bando marcado con fluorescente: se entra al hilo y se sale con un código, no una landing de «ayuntamiento digital». El ground es fotocopia fría. El mark es el rotulador del tablón. El lacre sella lo urgente, poco.

Mood elegido: highlighter.
Primer instinto descartado: chalky (pizarra municipal). Un bando se marca con fluorescente, no con tiza. La tiza ya fue PIZARRA.

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

2. Territorio visual

3. Paleta

Jerarquía de color: el fog carga; el mark puntúa; la ficha encuadra el parte. Si el mark pinta fondos enteros, deja de ser rotulador y se vuelve «brand lime». El lacre no decora el header: solo puntual (112, sello). [DECISIÓN]

4. Tipografía

Prohibido: Ibarra Real Nova por debajo de 20px (se rompe). Jost en el wordmark (se vuelve startup).

Fuentes vetadas de la serie y del brief: Libre Baskerville / Nunito / Instrument Serif / Sora / 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: partes en 4:3 (calle). No recorte 1:1 de retrato MATIZ ni 16:10 editorial. [DECISIÓN] 4:3 de incidente, distinto del 1:1 de ficha de color y del 16:10 de MARGEN.

Tratamiento: saturación real, sin LUT «civic blue», sin cielo HDR. El mark no se superpone como filtro: vive en UI.

hero.jpg vive en UX-00 Cover, no como hero de producto en el chat. [DECISIÓN] AP-21: 3 bandos reales en el fold.

6. Layout

Chat (H-CHAT)

┌─────────────────────────────────┐
│  PREGÓN · Escríbele al distrito │
│  [bando] [bando] [bando]        │  hilo
│                                 │
├─────────────────────────────────┤
│  nombre · calle · tipo · texto  │  composer anclado
│  [ Enviar ]                     │
└─────────────────────────────────┘

1. Wordmark + eslogan (una línea, no portada).
2. Lead en el fold: 3 bandos (título Ibarra, cuerpo Jost).
3. Composer visible sin cazar el CTA.

No hay portada fotográfica a 60vh. [DECISIÓN]

Mesa (S-SIDE + F-KAN)

┌────────┬──────────┬──────────┬──────────┐
│ Recibido 3        │ En curso 2│ Cerrado 2│
│  · PG-2401        │           │          │
│  · PG-2402        │           │          │
│  · PG-2403        │           │          │
└────────┴──────────┴──────────┴──────────┘

Rail izquierdo: estados + contadores + Nuria + Salir.
Tablero: 3 columnas de cards blancas sobre fog.

390: segmentos + lista (UI-11).

Ficha

Foto 4:3 a ~240–320px, no full-bleed. Código → calle → cuerpo → chips de columna. Blancos de ficha, no de landing.

Login

Columna estrecha sobre fog. Sello, no splash municipal.

7. Motion

Prohibido: parallax de plaza, scroll-jacking, page transitions de 400ms, sticker de «NUEVO» parpadeante, animación de farola que se enciende al enviar (mentiría resuelto).

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

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

Cercano de plaza y de mesa. Tuteo. Segunda persona cuando habla la UI al vecino. Tercera cuando habla el parte.

El producto se escribe y se mueve de columna. No cita, no es 112, no abre expediente.

10. Criterios de aceptación creativos

1. Ground de página = #F1F3F6. Cards = #FFFFFF. Nunca al revés.
2. Mark en el CTA Enviar y en la columna activa, no un header lima lleno.
3. 3 bandos visibles en el primer viewport mobile (tras wordmark + eslogan).
4. Ninguna fuente de la lista vetada. Ibarra Real Nova + Jost.
5. Home reconocible como hilo, no como hero 2-col de smart city.
6. Success no celebra un «ya está resuelto» ni un 112 atendido.
7. Lacre solo en aviso 112 / sello, no en el chrome.

08-design-system.md

08 — Design system — PREGÓN

1. Tokens

--color-fog:      #F1F3F6;   /* G-FOG ground */
--color-ink:      #12141A;
--color-mark:     #C8F000;   /* rotulador */
--color-card:     #FFFFFF;   /* cards only */
--color-graphite: #5C6370;
--color-seal:     #C1121F;   /* lacre, poco */

--font-display: "Ibarra Real Nova", "Iowan Old Style", serif;
--font-ui:      "Jost", system-ui, sans-serif;

--radius-card: 2px;          /* fotocopia, no pill */
--radius-cta:  2px;
--rule-rail:   2px solid var(--color-mark);
--space:       4 / 8 / 12 / 16 / 24 / 32 / 48 / 64;

Tailwind (referencia):

[COMPROBADO] Hex y tipo = brief.
[COMPROBADO] Leftover Tailwind = chapel MATIZ. Contrato: tokens de esta tabla.

2. Escala tipográfica

3. Componentes

Composer (H-CHAT)

Bando (hilo)

┌─────────────────────────────┐
│ ▌ Corte de agua             │  pin mark 4px izq + título Ibarra
│ Jueves 21, de 10 a 14 h…    │  cuerpo Jost
│ Distrito                    │  meta grafito
└─────────────────────────────┘

• Fondo card, sin sombra.
• Filete izquierdo 4px mark (anclado).
• No es un <a> (no navega).

Card de parte (mesa)

Toda la card es un <a> a /mesa/:code. Hover: rule 1px ink. Sin lift.

Rail (S-SIDE)

390: el rail no se dibuja; hay segmentos (UI-11).

Segmentos mesa mobile (UI-11)

Tres slots iguales: Recibido · En curso · Cerrado. Activo: mark underline 2px. Lista debajo, una columna.

Ficha de parte

Botones

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

Contraste primary: mark #C8F000 + texto ink #12141A (no texto blanco sobre lima). [DECISIÓN]

Form

Labels visibles (no placeholder-only). Inputs h-44, radius 2, rule grafito 40%, foco outline 2px mark offset 2.

Chips de tipo / status: <button aria-pressed>. Selected: mark filete 2px o fondo mark 30%. Idle: card + rule.

Estados

4. Grid y breakpoints

Padding horizontal: 24 desktop, 16 mobile.
Chat 390: padding-bottom: calc(composer-height + env(safe-area-inset-bottom)) para no tapar el último bando.

5. Iconografía

Mínima. El pregón no es un set de iconos outline de farola.

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

6. Elevación y borde

Cero sombras shadow-lg. La fotocopia no flota.

7. Mapa componente → ruta

8. Criterios de aceptación DS

1. Tokens Tailwind = hex del brief, sin yeso MATIZ #E6E4ED como ground.
2. Cards en blanco; página en fog.
3. Primary CTA mark + texto ink (nunca grafito sobre fog como único CTA).
4. Ibarra Real Nova no aparece en labels de form ni en el rail.
5. Recorte de parte aspect-[4/3], no 1:1 de retrato ni 16:10 editorial.
6. Targets de chips, rail, segmentos y CTA ≥44px.
7. Composer anclado no tapa el último bando (padding-bottom).
8. Fuentes: Ibarra Real Nova + Jost. Cero Libre Baskerville / Nunito leftover.

09-content-guide.md

09 — Guía de contenido — PREGÓN

1. Voz

Cercana de plaza y de mesa. Tuteo en UI al vecino. Segunda persona cuando la interfaz habla. Tercera cuando habla el parte (Rosa escribió…).

Sin jerga de smart city («ciudadanía activa», «tu voz cuenta», «innovamos el barrio»). Sin sede electrónica. Sin «reserva tu slot». Sin sirena.

El producto se escribe y se mueve de columna. No cita, no es 112, no abre expediente.

2. Palabras permitidas / prohibidas

«Kanban» es lenguaje de diseño, no de UI: la vecina no lee «kanban»; Nuria lee Recibido / En curso / Cerrado.

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.

4. Microcopy por superficie

5. Bandos y partes seed (tono)

Los bandos demo se escriben como aviso de tablón, no como tuit institucional ni como crónica.

No inventar declaraciones de vecinas reales. Si hay una voz, es del parte (neutra) o de persona de diseño etiquetada.

En CERRADO no se reescribe el cuerpo a «arreglado». El cierre es el status de mesa. [DECISIÓN]

6. Nombres propios del seed

No inventar CIF de junta, código INE, ni teléfono 010 real como si fuera el producto. [SUPUESTO de catálogo demo]
Calles seed (plaza Elíptica, Marcelo Usera, Rafaela Ybarra, plaza de Ágata, Resina, Avenida de Andalucía, Amparo) son topónimos reconocibles, no un inventario oficial de incidencias 2026.

7. Tono por estado

La app no envía esos mensajes al vecino en v1. El copy solo prepara el habla. No hay email de «su farola ya luce».

8. Capitalización y números

• Wordmark: PREGÓN en versales Ibarra Real Nova (tilde).
• Código: PG-2401 (PG versales, guion, 4 dígitos).
• Nombres: Rosa Méndez, Nuria Delgado, Andrés Peña.
• Tipos en chip: Farola (mayúscula inicial).
• Calles: Plaza Elíptica, Calle de Marcelo Usera (mayúscula de vía).
• Fecha: 20 ago, 09:45 en card; jueves 20 de agosto si hay cabecera de mesa.
• No mezclar pg-2401 en minúsculas en UI. API puede normalizar a versales.

9. Idioma

es-ES. Fácil lectura. EN no en v1.
No mezclar «report» en UI. En API sí: reports, kind, status, authorName.

«Vecina» en UI cuando hablamos de Rosa; «vecino» para Andrés; «el vecino» genérico en copy de sistema. [DECISIÓN]

10. Accesibilidad de copy

• No transmitir estado solo con color (el mark no «significa» En curso él solo).
• Chips llevan texto: Recibido / En curso / Cerrado.
• Aviso 112 lleva palabras, no solo el lacre.
• Alt de fotos: tipo + lugar, no «imagen1».
  • hero: «Fotocopia de bando y plaza; pregón de distrito, no smart-city.»
  • farola: «Farola de barrio; parte de alumbrado.»
  • cubo: «Cubo de basura en la calle.»
  • banco: «Banco de plaza.»
  • acera: «Acera y baldosa de barrio.»

11. Piezas que no se escriben

10-accessibility.md

10 — Accesibilidad — PREGÓN

Objetivo: WCAG 2.2 AA. No se declara conformidad legal certificada.
Este documento cubre la UI (chat, acuse, login, mesa, ficha). No audita la accesibilidad física de la plaza Elíptica, de la junta ni del 112. [SUPUESTO]

1. Decisiones

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

3. Teclado

• Enter en chip tipo = selecciona (aria-pressed).
• Enter en card = navegar a ficha.
• Escape no cierra el composer (no es modal).
• Focus trap: no hay modal Must.
• En 390, el composer anclado no debe robar el foco al cargar.

4. Semántica

5. Lector de pantalla — copy

6. Producto vs calle física

[DECISIÓN] v1 no incluye auditoría a11y de sede ni de espacio público. authorName es dato de parte demo, no un certificado de identidad.

7. Riesgos

8. QA a11y (mínimo)

9. Criterios de aceptación

1. Ningún control de chip, rail, segmento o CTA mide menos de 44×44 CSS px.
2. El disclaimer no depende del color mark o lacre para ser entendido.
3. Las 4 fotos de parte + 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 composer queda por debajo del hilo (el último bando no queda tapado).
6. Una mesa no se anuncia en / sin token (no hay HTML público de columnas).
7. Rosa puede completar el composer solo con teclado y sin cuenta.

11-privacy-security.md

11 — Privacidad y seguridad — PREGÓN

1. Datos que existen

No se pide cuenta a la vecina. No hay DNI, email ni teléfono de Rosa en producto. No hay tracking de menores. Las fotos seed no se presentan como partes reales.

2. Minimización

authorName es dato de parte demo, no un requisito de identidad legal. L+1 podría hacerlo opcional o «Vecina». [DECISIÓN]

3. Seguridad L1

No se declara cumplimiento RGPD definitivo. Sí: minimización, mesa JWT y derecho a borrar la cuenta de operadora (manual L1). Los partes seed se tratan como datos de demo, no como encargo de tratamiento de una junta real.

4. Superficies de riesgo

5. Roles y autorización (recordatorio)

Rosa, Andrés y la junta no tienen fila en users.

6. Criterios de aceptación

1. Response de login no incluye password ni password_hash.
2. GET /api/reports y GET /api/reports/PG-2401 sin Bearer son 401, no 200 [].
3. POST /api/reports sin Bearer es 201 (público).
4. GET /api/bandos sin Bearer es 200.
5. No hay formulario público que pida DNI, email o teléfono.
6. /mesa sin token redirige a /login (no renderiza columnas en HTML anónimo).
7. /ok/:code no llama a GET JWT.
8. .env no se commitea.
9. Health no filtra datos: { ok: true, service: "pregon-api" }.

12-analytics.md

12 — Analítica — PREGÓN

North star: % de partes que Nuria mueve a En curso en 24 h (report_create + report_status a CURSO ligado a code, ventana 24 h Europe/Madrid).

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: ok_view sin resolved_claim (el copy contradice). Si en un test de 5 vecinas alguien dice «ya está arreglado», se anota en research futuro, no como KPI inventado.

3. Funnel modelo

Vecina:   chat_view  →  report_create  →  ok_view
Operadora: operador_login  →  mesa_view  →  parte_open  →  report_status(CURSO)

Activación vecina = primer report_create.
Activación mesa = primer report_status a CURSO.
North star de sesión de demo: de los RECIBIDO del seed (3) + los nuevos, cuántos pasan a CURSO en 24 h civiles Europe/Madrid.

4. Integridad (producto, no vanidad)

5. Privacidad de analítica

Sin PII extra. code es identificador de parte (PG-2401), no un email. authorName no se envía a un tercero. body no se envía. Ver doc 11.

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

1. Los eventos de §1 tienen nombre estable.
2. No se dispara ningún evento de lead / cita / 112-como-conversión / expediente / resuelto-al-enviar.
3. Un bloqueador de cookies no rompe el composer (analítica no es Must de runtime).
4. kind se mide; body no.

13-qa-test-plan.md

13 — Plan de pruebas — PREGÓN

1. Smoke obligatorio (D-P1-06)

[COMPROBADO] Smoke = health (pregon-api) + bandos públicos + login JWT + reports JWT.

2. Casos funcionales

3. Datos de prueba

4. Regresión de diversidad / craft

5. Hipótesis (no se «prueban» en la demo)

H1, H2, H3 requieren uso real. El QA verifica que existen las superficies que permitirían medirlas (composer, acuse con disclaimer, kanban 3 columnas, ausencia de signup vecino, 401 mesa).

6. Criterios de salida QA v1

• Smoke §1 en verde (incluido pregon-api).
• S2, S5, S7, S8, S10, S16, S21, S25 en verde.
• Cero blockers de copy deshonesto (expediente / resuelto-al-enviar / cita / 112-como-envío).
• Sin .env en el repo.
• Sin leftover MATIZ como superficie de producto.

7. Fuera de este plan

Playwright e2e completo, carga, fuzzing, auditoría de una junta real.

14-dev-handoff.md

14 — Handoff desarrollo — PREGÓN

1. Arranque

cd /Users/cristian/orca/pregon-app

# apps independientes (npm --prefix o pnpm --filter)
# apps/api/.env
#   DATABASE_URL=  # Neon empty-surf-15969880
#   JWT_SECRET=
#   PORT=3020

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

Demo: nuria@pregon.ayto / password123.

2. Paridad Paper

No clonar MATIZ (Hoy bento + editor + bottom tabs), ZAGUÁN (wizard + comparador), MARGEN (lookbook + masthead), PIZARRA (catálogo search) ni CESTA (tabla + rail de necesidades).

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

Guard: si no hay token, /login?next=. La API es la autoridad para mesa.

[COMPROBADO] Solo estas rutas. No implementar /fichas, /hoy, /cuenta, /cita, /112.

5. Assets

Copiar desde el case:

2026-08-20-pregon/assets/hero.jpg
2026-08-20-pregon/assets/partes/farola.jpg
2026-08-20-pregon/assets/partes/cubo.jpg
2026-08-20-pregon/assets/partes/banco.jpg
2026-08-20-pregon/assets/partes/acera.jpg
  → apps/web/public/assets/partes/   (hero a public/assets/)

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

Quitar leftover public/assets/clients/* y páginas hoy / fichas / ficha / formula / cuenta si siguen en el repo.

[COMPROBADO] El web leftover ya copia partes/*.jpg en public/assets/partes/ y src/assets/partes/. Conservar; no servir como fichas de colorista.

6. DoD implementación L1

7. No hacer

8. Contactos de diseño (artefactos)

15-roadmap.md

15 — Roadmap — PREGÓ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 pregon-app. El alcance L1 ya está cerrado en spec; el código alinea leftover MATIZ (clients / formulas / hoy / COLORISTA / :3019 / matiz-api) 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-operador / turnos / brigada JWT
• Cuenta de vecino y «mis partes»
• GIS / mapa / inventario de farolas
• Expediente SIA / plazos / sede / Cl@ve
• Integración 112 / 010
• Cita previa
• Chat entre vecinos (foro)
• Multi-distrito (Usera ≠ Villaverde como dos mesas)

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 MATIZ)
2. Web paridad UI-00…11
3. Acuse público mínimo + rate limit (L+1)
4. Foto POST si hay campo
5. Evaluar brief L3 (no parche silencioso)

16-interaction-specs.md

16 — Especificación de interacción — PREGÓN

1. Convenciones

Loading (skeleton de UI-10) y mesa mobile (UI-11) viven en este doc junto a los gestos; el inventario Paper ya reserva UI-10 y UI-11. [DECISIÓN]

2. Chat home (UI-01) + mobile (UI-02) · H-CHAT

AC: título y cuerpo de cada bando visibles sin hover. 3 bandos en el fold a 390 (AP-21). Cero botones Cita / Crear cuenta / 112-como-envío.

El aviso «PREGÓN no es 112» es texto, no un tel:112 primario. Could: link textual tel:112 secundario junto al disclaimer. [DECISIÓN v1] texto sin tel: para no competir con Enviar.

3. Composer (UI-03)

Submit deshabilitado si nombre < 2, calle < 4, kind vacío o body < 10.

[DECISIÓN] Un solo botón primario: Enviar. No existe «Enviar y resolver» ni «Citar».

390: CTA full-width h-44 en el composer anclado. Teclado iOS no debe tapar el textarea: scroll-margin en campos. Safe-area inferior.

Desktop 1440: composer en columna o bajo el hilo, CTA min 200px no full-bleed de viewport.

4. Success (UI-04)

Sin confetti. Sin farola que se enciende. Sin «cobrar». Sin «te llamamos».

5. Login (UI-05)

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

Login no muestra rail.

6. Kanban (UI-06) · F-KAN

AC: código, tipo y calle visibles en cada card sin hover. Cero botones Citar / 112 / Expediente.

7. Ficha (UI-07)

Sin «llamar ahora». Sin WhatsApp. Sin «citar». Sin «abrir expediente».

8. Empty (UI-08) · Error (UI-09) · Loading (UI-10)

9. Mesa mobile (UI-11)

390: una columna a la vez. [DECISIÓN]

10. Rail (S-SIDE) desktop

11. Motion

Prohibido: scroll-jacking, page transitions de 400ms, parallax de plaza, sirena, farola que se enciende al enviar, confetti de «resuelto».

12. Criterios de aceptación de interacción

1. Una vecina en 390px llega de abrir / a ver un código en ≤ 3 taps útiles (tipo → campos → Enviar).
2. Ningún submit permite doble POST.
3. El composer no cubre el H1 ni el último bando (spacer).
4. Reduced-motion elimina stagger y slide.
5. La home no es hero 2-col (AP-12).
6. En 390 los 3 bandos son visibles sin scroll de «marca» (AP-21) — o 2 + compositor si el teclado no está abierto; con teclado cerrado, 3.
7. / no presenta ningún control de cuenta, cita o expediente.
8. El loading de chat es skeleton de hilo, no un logo municipal.
9. El acuse muestra «enviado ≠ resuelto» y «no es 112» sin scroll en desktop.
10. Nuria en 1440 mueve un parte a En curso en ≤ 3 taps (card → chip).
11. Nuria en 390 usa lista por columna, no 3 columnas de 120px.
12. Manos en el banco: cero gestos que exijan hover o swipe horizontal como único camino.

17-prototype-map.md

17 — Mapa de prototipo — PREGÓ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.

Empty, error y loading se prototipan como estados / variantes de UI-01 / UI-06 además de sus boards propios. Ver doc 16.

Recorrido demo (guión)

1. Abrir / sin token — chat público. Leer eslogan Escríbele al distrito. Leer 3 bandos (agua, enseres, no es 112).
2. Composer: nombre Rosa Méndez, calle Plaza Elíptica, banco de la plaza, tipo Farola, texto La farola del banco no enciende desde anoche.
3. Enviar → /ok/PG-XXXX — «Enviado no es resuelto. El acuse no apaga la farola.» «PREGÓN no es 112.»
4. Ghost Mesa → /login. Entrar nuria@pregon.ayto / password123.
5. /mesa — Recibido 3 (PG-2401 farola Rosa · PG-2402 cubo Andrés · PG-2403 acera Rosa) · En curso 2 · Cerrado 2.
6. Tocar PG-2401 — ficha, foto farola, cuerpo, «El mensaje no es un expediente. PREGÓN no cita.»
7. Chip En curso → PATCH. Volver a mesa: Recibido 2 / En curso 3.
8. Comprobar que no hay botón Citar, 112-como-envío ni Expediente.
9. Viewport 390: chat con composer anclado; mesa con segmentos + lista.
10. Salir → /login. / sigue siendo el chat.

Estados en el mismo prototipo

Fuera del prototipo clicable

• Paper artboards son estáticos.
• Brigada de alumbrado / limpieza (fuera).
• 112 / 010 / sede electrónica.
• Cita con el distrito (no existe).
• GIS / mapa.
• Cuenta de vecino.
• Foro de partes ajenos.
• El leftover MATIZ (/fichas, /hoy) no forma parte del prototipo PREGÓN: si aparece, es desalineación (I01).

18-completeness-audit.md

18 — Auditoría de completitud — PREGÓN (2026-08-20)

1. Alcance auditado

Vertical slice L1: chat-first de incidencias vecinas + mesa OPERADOR JWT (kanban Recibido / En curso / Cerrado), con docs, referencia Paper, contratos Angular + Nest + Neon.

Este encargo cubre la suite documental + Paper + vertical slice. El day brief y el paper-reference no se han sobrescrito.

2. Checklist CRON / ALS-2

3. Cobertura funcional

4. Cobertura Paper (literales)

[COMPROBADO] UX-count: 12 y UI-count: 12 literales. get_basic_info = 12 UX + 12 UI + 4 labels §; gate check-paper-reference.mjs exit 0.

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-20.
La suite define producto L1 usable (tablas, AC, riesgos, contratos) sin presentar investigación de campo como hecho.
Cualquier ampliación GIS / 112 / sede / cuenta-vecino / cita requiere nuevo brief de diversidad, no parche silencioso.

19-backlog-completo.md

19 — Backlog completo — PREGÓ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-20)

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

2. Backlog L1 implementación (repo pregon-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 MATIZ)
2. B03 + B04 + B08
3. B01 + B06
4. B02 + B11 si hay campo
5. Evaluar brief L3 — no parche silencioso

8. Trazabilidad

20-implementation.md

20 — Implementación — PREGÓN

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 /Users/cristian/orca/pregon-app está alineado: health pregon-api, puerto 3020, módulos bandos/reports, rol OPERADOR, tokens highlighter, rutas / /ok/:code /login /mesa. Tablas leftover MATIZ se dropean al boot.

2. Cómo arrancar

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

# apps/api/.env
#   DATABASE_URL=   # Neon empty-surf-15969880
#   JWT_SECRET=
#   PORT=3020

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

Credenciales

Vecina / vecino: sin cuenta. Escriben en /.

3. Schema

Al boot o vía migrate:

1. CREATE TABLE / migrate de users, bandos, reports (doc 05). Opcional sessions.
2. Índices: reports(code), reports(status, created_at DESC), users(email), bandos(pinned, created_at).
3. Seed idempotente:
   • upsert OPERADOR nuria@pregon.ayto (bcrypt de password123)
   • upsert bandos por id (bnd_1…bnd_3)
   • upsert reports por code (PG-2401…PG-2407)
4. Leftover: no recrear clients / formulas / sittings. Drop si existen y no hay datos ajenos que preservar. [DECISIÓN]

No borrar partes nuevos de Rosa en cada boot si ya existen filas distintas al seed.

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