El mapa de las 40 pantallas y cómo aterrizarlas por fases
P1 (el shell) está hecho: la nueva sidebar 2-modos, el switcher ⌘O, el estado de mes y ⌘K envuelven el admin — pero las páginas por dentro siguen siendo las viejas. Este es el inventario de cada pantalla: qué hace hoy, cómo se re-piensa su flow + UI + UX bajo el objetivo, cuánto pesa, y en qué orden entra.
01 Estrategia de merge
El shell es no-breaking: re-parenta las páginas que ya existen, así que siguen funcionando sin cambios. No hay que rediseñar las 40 pantallas antes de mergear.
recomendado Incremental
Mergeas el shell + lo ya rediseñado, y luego página por página en main, cada una con su demo. Rompe la maldición de los 4 intentos previos (una branch gigante que divergió semanas y nunca aterrizó). Valor desde el día 1, branches chicas, feedback continuo. Cada merge deja el admin 100% funcional.
Big-bang
No mergeas hasta que todo esté rediseñado. Coherencia total al "lanzar", pero la branch crece y diverge de main — exactamente el modo de falla que estamos evitando.
02 El mapa — cada pantalla, por sección
Fuente de verdad: el modelo de nav (sidebarModel.ts, 40 PageIds). El v5 no solo rediseña — consolida: varias páginas de hoy se vuelven tabs dentro de un padre.
| Nav | Páginas hoy | Forma v5 |
|---|---|---|
| Inicio | home | hecho real·validado — falta bento + attention strip |
| Clientes | clientsclient-setupcampaigns | directorio + rebuild de onboarding |
| Partners | partnerspartner-profilepartner-onboardinglink-generator | lista + perfil 6-tabs + Deal |
| Pagos y cierres | payments | tabla densa (pendientes = engine vivo, ya) |
| Assets | assets | mantener, polish ligero |
| AI Copilot | ai | fuera de scope |
| Sistema y salud | systemcontrol-centerpipelinescommission-paritybudget-engine-runs | umbrella, mantener |
| Fraude · Tickets · Equipo · Org | admin-fraudticketsuserssettings | mantener, polish |
| Nav | Páginas hoy | Forma v5 |
|---|---|---|
| Hoy | client-overview | P2 bento 8 KPIs + tabla maestra |
| Campañas | client-campaignscampaign-detailcampaign-launch | tabla densa + detalle 6-tabs |
| Partners | client-partnersclient-media-sourcesclient-quality | absorbe media sources + calidad |
| Órdenes | client-ordersclient-leadsclient-fraudclient-pixel-analytics | 4 páginas → 1 tabla, renombrada por objetivo |
| Planner | client-planner | Planner v3 ✓ (v4 live-chain después) |
| Validación | client-reconciliationclient-sla | consola ledger ✓ (fuera de scope) + tab SLA |
| Reglas y tarifas | client-rulesclient-attribution | absorbidas por el Deal |
| Fuentes y píxel | client-integrationsclient-tracking-sourcesclient-funnels | tabs |
| Fraude y alertas | client-fraud-rulesclient-alerts | tabs |
| Ajustes | client-settingsclient-audiencesclient-usersclient-setup-edit | tabs |
03 Fundaciones — se construyen una vez, todo las usa
Prerrequisitos que desbloquean el vocabulario por objetivo en todos lados. Se hacen al arrancar P2, no son una página.
useClientProfile()
Resuelve objetivo(s), fuente(s), hasBase, hasSprints, modelo de billing, ticket estimado, tasa de validación. Reemplaza el branching ad-hoc de tracking_type en 12+ archivos.
Vocabulario por objetivo
Un solo lugar que mapea objetivo → nombres de KPI, "Órdenes/Leads/Conversiones", modelo de comisión, niveles de la tabla. "Revenue/Orders" se renombra solo por cliente.
Contrato de data
🟢 completa · 🟡 estimada (badge + "calculado con…") · 🔴 falta config (sin gráfica falsa, pide el input). El sistema nunca inventa un número que no puede sostener.
2 campos nuevos de config
Modelo de billing del cliente (%rev / $venta / $lead / $click / CPM) + ticket estimado. Migración + captura en onboarding. Hoy solo Samsung los tiene.
04 Las fases
Cada una se mergea sola; el admin sigue funcionando durante todo el proceso.
Shell
hecho✓ listoSidebar 2-modos, switcher ⌘O (DB-driven), estado de mes, un solo modelo de nav, breadcrumbs, ⌘K agrupado, borré el shell V3 muerto. Más (esta sesión) real·validado en Inicio + Hoy y el fix de orders-distinto en el backbone.
"Hoy" — el centro de comando
lo siguienteLEl cliente aterriza en un centro de comando real, no en una página de tarjetas. El mayor valor.
- Las 4 fundaciones de arriba.
- Bento de 8 KPIs (solo campañas activas): Revenue generado · Órdenes/Conversiones · Nos cuesta · Nos queda (días de runway) · Relo gana (+margen) · ROAS · Proyección cierre · Atención. Todo aritmética sobre agregados existentes — sin engine nuevo.
- La tabla maestra — UNA tabla con "Agrupar por": Deals · Campaña · Segmento · Partner. Default inteligente por cliente. Filas se expanden por objetivo. Acciones inline ⏸ ➕ ✏️.
Campañas — lista + detalle
LLa campaña se vuelve la unidad que escaneas y en la que entras.
- Lista = tabla densa estilo Ads Manager: columna ⭐ default, badges Objetivo·Fuente, Resultado + Costo/resultado en el idioma del objetivo, barra Gastado/cap, Pace, filtros + búsqueda.
- Detalle: el nombre es un switcher (⭐ default). 6 tabs: Resumen · Partners y deals · Conversiones · Creativos y links · Reglas · Ajustes (absorbe los 7 tabs de hoy).
- Barrido de vocabulario aterriza aquí (usa useClientProfile).
Partner profile + Deal + consolidación de Órdenes
XLLa consolidación más grande — y donde muere el dolor #1 de partners.
- Partner profile = 6 tabs: Resumen · Deal · Pagos · Media sources · Mensajes y tickets · Cuenta. Header con acciones (✉️ 👁 ⏸).
- Deal (partner × cliente, el contrato completo): fila de atribución + una tabla por segmento (Base → Override → Efectiva → Gastado/cap → Queda → Runway → ⏸✏️) + Simulador (engine real en dry-run). Absorbe Reglas + Atribución.
- Órdenes = una tabla renombrada por objetivo, absorbiendo Leads + Fraude review + Pixel analytics.
Flujos — onboarding vivo + drawers con live-recalc
LEl dinero se edita con las consecuencias visibles y honestas.
- Onboarding termina VIVO: Step 2 = Objetivo + Fuente con la fuente verificada dentro del wizard; pantalla final = Checklist de vida (anillo de progreso, DATOS FLUYENDO / DINERO / OPCIONAL, acciones inline); async, nunca bloquea. Mata la pantalla "creado pero muerto".
- Drawers de budget / tarifa / pausa: abren desde cualquier fila, recalculan en vivo, la bolsa (barra apilada), tarjeta de ecuación, línea de transparencia, el piso de margen es el único bloqueo.
Polish + la cola larga
MAgrupar lo disperso, aplicar el lenguaje visual, limpiar.
- Clusters de config en tabs: Fuentes y píxel, Fraude y alertas, Ajustes.
- Platform pages (Sistema, Fraude global, Tickets, Equipo, Org, Assets) — mantener + lenguaje visual.
- Pagos (por-cliente), poda de redirects, barrido de i18n, Planner v4 live-chain (reusa el motor del drawer).
05 Fuera de scope v5 — NO rediseñar ahora
06 3 decisiones tuyas para arrancar P2
Con esto le hago a P2 su plan de implementación detallado (como el de P1) + demo antes de cualquier merge a prod.