​

E4 — El tablero y el layout: cómo conviven conversación, plan, progreso y resultados

​

1. La decisión de fondo: dossier argumentado, no spreadsheet

• Lo que la tabla gana: densidad a escala (500 filas), pensamiento por columnas (enriquecer campo a campo), familiaridad de RevOps.
• Por qué aquí pierde: nuestro usuario no es RevOps y nuestra unidad de valor no es la fila — es la oportunidad argumentada (qué pasó / por qué ahora / por qué tú / cómo entrar / con qué evidencia). Ese argumento no cabe en celdas; una tabla lo degrada a “datos” e invita al modelo mental de base de datos que el brief prohíbe. Además nuestra escala típica es 10–30 oportunidades curadas, no 700 leads.
• La síntesis: tarjetas argumentadas para la shortlist, filas compactas para el resto, dossier al expandir. Si el producto algún día sirve volúmenes estilo lista (>100), se añade una vista densa como vista, no como identidad.

​

2. Anatomía del tablero (el artifact de la búsqueda)

┌─ ENCABEZADO ────────────────────────────────────────────────┐
│ Uniformes — compras Jalisco          Terminada · hace 2 min │  ← estado: UNA vez (E3 §5)
│ Criterio: uniformes/EPP · gobierno estatal · Jalisco        │  ← el contrato, legible y EDITABLE
│   ajustado hace 5 min: "solo procesos > $500 mil"           │     (editar = steering, no re-run ciego)
│ 37 revisados · 12 propuestos · 0 créditos                   │  ← métricas honestas del embudo
├─ DESTACADAS (3) ────────────────────────────────────────────┤
│ ① [Convocante/Organización]                    cierra en 9d │
│    Qué pasó: publicó proceso para 3,000 juegos…   [hecho]   │
│    Por qué ahora: cierre 14 ago; monto publicado $1.2 MDP   │
│    Cómo entrar: registro de proveedor + propuesta… [inferencia] │
│    ▸ 2 fuentes y contexto        👍 👎  · Contactos · Ficha │
│ ② …                                                          │
├─ TAMBIÉN CUMPLEN (9) — filas compactas ─────────────────────┤
│ · Org — qué pasó (1 línea) — cierre — ▸ fuentes             │
├─ TARJETAS ESPECIALES ───────────────────────────────────────┤
│ ⚠ Evidencia en conflicto (1)  · fuentes lado a lado         │
│ ◌ Hueco: Bajío sin cubrir — Investigar (tope 20 cr)         │
├─ PLEGADO ───────────────────────────────────────────────────┤
│ ▸ Descartadas (5, con causa) · ▸ Sin evidencia mostrable (2)│
└─ ACCIONES DEL TABLERO (máx 3): Vigilar · Afinar · Guardar ──┘

• Criterio editable = el contrato hecho interfaz. No existe pantalla de “contrato”; el WorkContract compilado se PROYECTA aquí en lenguaje del usuario y editarlo despacha steering tipado. Historial de ajustes visible (“ajustado hace 5 min”).
• Métricas (adoptado de Origami, adaptado): revisados · propuestos · gasto (y tope) — más, cuando hay gasto, costo por calificada (“14 cr → 9 nuevas ≈ 1.6 cr c/u”). Nunca métricas de motor (steps, tools, latencias).
• Tarjeta de oportunidad: organización (título) · qué pasó [hecho, con fuente] · por qué ahora · ángulo/cómo entrar [inferencia, marcada] · estado (encontrada/verificando/calificada/descartada + causa) · evidencia plegada · desconocidos explícitos (“monto por confirmar”). El par confianza-evento / confianza-comercial de la tesis MVP se expresa en palabras (“anuncio confirmado; compra abierta: por validar”), jamás como score numérico único (invariante: tres cálculos nunca colapsados en un score).
• Filas de estado vivo: durante el run las tarjetas entran como esqueleto con estado y se completan (encontrada → verificando → calificada/descartada); una fila jamás desaparece — se pliega a Descartadas con causa (semántica delete/restore, adoptada de Origami).
• Tarjetas especiales: conflicto (dos afirmaciones lado a lado, fecha cada una, badge ámbar) y hueco de cobertura (la propuesta de investigación VIVE aquí tras ser declinada en chat — latente, no insistente).
• Dossier (ficha): expandir una tarjeta → vista completa: cronología del evento con fases (anuncio→construcción→ramp-up→operación cuando aplique), evidencia completa, compradores probables por función, ruta de entrada, personas (solo tras C10), borrador de mensaje, historial de acciones sobre esa oportunidad. El dossier es el opportunity_dossier; se navega con breadcrumb, el chat sigue accesible.
• Evidencia: tocar ”▸ fuentes” abre una hoja lateral (overlay, no navegación): cita textual o dato extraído, nombre público de la fuente, fecha de publicación Y fecha de consulta, enlace saliente, permiso de atribución cuando aplique. Cerrar regresa exactamente donde estabas. La conversación nunca se pierde por inspeccionar (patrón validado en Origami).

​

3. Cuándo se abre el panel y quién domina la pantalla

​

4. Plan y progreso: dónde viven

• El runway (adoptado de DESIGN §0.9, conservado): aside de ~260px en desktop dentro de la zona de chat — Ahora / Después (≤3) / “N pasos hechos” plegado. En móvil: dentro del mini-status expandible (bottom sheet). El runway muestra etapas del encargo (“Revisando compras vigentes → Verificar cierres → Proponer”), nunca steps de motor.
• El plan inspeccionable: tocar el runway expande la vista de estrategia: qué voy a hacer, en qué orden, qué es gratis y qué costaría, supuestos activos. Es el ExecutionPlan proyectado; de nuevo: contenido, no ceremonia — nunca bloquea.
• El progreso numérico vive en las métricas del tablero (revisadas/propuestas), no en el runway. Una sola fuente por número (reductor E3 §5).

​

5. La vida del tablero después del run

1. Aparece en Inicio bajo “Tus búsquedas” con estado (viva · vigilada · en pausa · archivada) y badge de novedad.
2. Refrescable: “Actualizar datos” re-ejecuta lo gratuito con el criterio vigente y marca los cambios (“2 procesos nuevos · 1 venció”); lo pagado solo re-corre con nueva aprobación.
3. Vigilable: activar monitor lo convierte en tablero vigilado; los avisos del monitor referencian y actualizan ESTE tablero (deltas marcados “nuevo desde tu última visita”), jamás crean uno paralelo.
4. Accionable por oportunidad: contactos (C10), preparar mensaje, marcar “la contacté / no me interesa” — estados comerciales del usuario que alimentan el aprendizaje (outcome ledger existente).
5. Exportable: Guardar en mi CRM (Collections — ya existe como destino) y CSV. Al guardar, la evidencia viaja como referencia, no se pierde.
6. Reabrible: entrar de nuevo = estado Reabierto (E3 S9), con continuidad explícita.

​

6. Qué adoptamos de Origami y qué no (registro de decisión)

​

7. Estados visuales que quedan prohibidos

• Panel abierto y vacío (“esperando resultados…” sin filas).
• Dos secciones de oportunidades apiladas por dos búsquedas (el apilado actual RC7): búsqueda nueva = tablero nuevo = objeto nuevo en Inicio.
• Cualquier render del estado terminal fuera del encabezado del tablero.
• Filas esqueleto sin estado declarado, spinners >10 s sin texto de qué se espera, y todo progreso que no pueda nombrar su etapa en lenguaje del encargo.
• Score numérico único por oportunidad (colapsa los tres cálculos que el producto jura mantener separados).