---
type: OUT
asset_id: OUT-EL-Posta-BriefPlataformaAlex-v01
version: v01
status: 🟡 Listo para reenviar a Alex
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
fecha_creacion: 2026-06-26
fecha_evento: 2026-06-29
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-LoopX
proposito: Brief accionable para Alex — requisitos de plataforma del EmpowerScan en vivo (Posta/Estafeta), esquema de export objetivo y criterios de aceptación.
relacionados: "[[XD-EL-LoopXOP-Posta-EScanEventoVivo-v01]] · [[TP-EL-Posta-EScanPromptExpress-v01]]"
tags: [out, brief, plataforma, alex, posta]
---

# Brief de Plataforma — EmpowerScan en Vivo (Estafeta)
## Para: Alex · Evento: lunes 29-jun · 150 participantes · 6 rooms simultáneos

Alex — esto es lo que la plataforma necesita entregar para que el análisis en tiempo real y el tablero funcionen. Lo ordené por prioridad: lo **MUST** es lo que sí o sí necesitamos el lunes; lo **SHOULD** suma si da tiempo.

---

## 1. El esquema de export que necesitamos (lo más importante)

Cada export CSV (uno cada 3-4 min) debe traer estas columnas:

| Columna | Nuevo? | Para qué |
|---------|--------|----------|
| `id` | ya existe | identificador único |
| `room_id` | **NUEVO** | saber de qué room viene (tablero por grupo) |
| `timestamp` | **NUEVO** | calcular velocidad (nuevas por corte) |
| `area_org` | **NUEVO** | área del participante (Operación/Proyectos/Datos/Seguridad/Soporte/Liderazgo) — para el cruce |
| `pregunta` | ya existe | a qué ronda responde |
| `titulo` | ya existe | título de la disfunción |
| `descripcion` | ya existe | **debe incluir el IMPACTO** (ver §3) |
| `prioridad` | ajustar | vocabulario controlado de 5 niveles (ver §4) |
| `area` (disfunción) | ya existe | self-tag opcional del participante (lo reclasificamos con IA igual) |
| `likes`, `dislikes` | ya existen | votos |

---

## 2. Requisitos MUST (gating para el lunes)

| ID | Requisito | Criterio de aceptación |
|----|-----------|------------------------|
| P-1 | **Captura de `area_org` en el login** (dropdown) | Cada participante elige su área al entrar; queda en cada aportación. Lista en §5. |
| P-2 | **Export con `room_id` + `timestamp` + `area_org`** | El CSV de cada corte trae las 3 columnas pobladas. |
| P-6 | **Export estable cada 3-4 min, esquema fijo** | Mismo orden de columnas siempre; archivo nuevo por corte (o acumulado con marca de tiempo). |
| P-7 | **Campos Título + Descripción (con IMPACTO)** | El form pide los dos; el placeholder de descripción guía a escribir el impacto. |
| P-3 | **Prioridad como vocabulario controlado** | Selector de 5 opciones (no texto libre). Valores en §4. |
| P-8 | **Buzón especial (confidencial) como canal aparte** | Stream separado, anónimo; no se mezcla con el resto (ver §6). |
| — | **6 rooms simultáneos** | Los 6 corren en paralelo sin pisarse; cada uno exporta con su `room_id`. |

## 3. El campo IMPACTO (clave para el costo oculto)
En la descripción, el participante debe escribir **el impacto** de la disfunción (qué genera: retrabajo, tiempo perdido, riesgo, etc.). Es el insumo para estimar el costo oculto. Sugerencia de placeholder en el form:
> *"Describe la disfunción y su IMPACTO: ¿qué provoca? (retrabajo, demoras, errores, riesgo, tiempo perdido…)"*

## 4. Vocabulario de prioridad (5 niveles fijos)
`1 Baja · 2 Media · 3 Alta · 4 Urgente · 5 Crítica`
(Sin valores libres tipo "Medium/alta/baja" — eso ensucia el análisis.)

## 5. Áreas para el dropdown de login (`area_org`)
Operación · Proyectos · Datos · Seguridad · Soporte · Liderazgo/Dirección · Otra
*(Ajustar contra el listado final de participantes.)*

## 6. Buzón especial (confidencial)
- Canal/ronda dedicada para riesgos y vulnerabilidades.
- **Anónimo**: no debe poder de-anonimizarse cruzando room + área. Si el grupo es chico, omitir `area_org` en este stream.
- Export por separado o claramente marcado, para no mezclarlo con la vista que se proyecta.

## 7. Requisitos SHOULD (suman si da tiempo)
| ID | Requisito |
|----|-----------|
| P-4 | Votación visible en tiempo real en la app |
| Auto-feed | Que el export quede en una carpeta/URL fija para que el tablero lo lea solo (si no, lo procesamos pegando el archivo) |

---

## 8. Cómo se conecta con lo nuestro
Tu export → lo procesamos en Cowork con el Prompt Express → sale un JSON → alimenta el tablero proyectable (`WOI-...EScanTableroVivo`). Entre más limpio y estable venga el export (esquema fijo, prioridad controlada, room/área pobladas), más rápido y confiable el ciclo en vivo.

**Pregunta para ti, Alex:** ¿el export lo puedes dejar en una ruta fija (carpeta compartida/URL) para auto-lectura, o lo descargamos manual cada corte? Con eso definimos el flujo del operador en el ensayo.