El plan maestro — restaurar el poder, unificarlo, hacerlo enterprise y AI-first
No es reskin ni recortar poder. El producto ya es super flexible; el poder solo está regado, invisible, y en parte se regresó. Este es el plan ejecutable por Kimi, pantalla por pantalla y flujo por flujo.
◆ La tesis en 5 líneas
El producto es super flexible + super enterprise + AI-first y debe seguir siéndolo. El poder no falta — está regado, invisible, inconsistente y en parte regresado.
Hay DOS caminos de escritura para las mismas operaciones de dinero: el humano/UI (regado, sin confirmación unificada, sin audit, precedencia invisible, sin undo) y el AI (execute-action: un gateway con RBAC + before/after + paridad + undo + idempotencia). El camino de la AI ya es más enterprise que el humano.
La jugada grande: enrutar TODA escritura — humana y AI — por UN gateway con UN drawer de confirmación. Eso entrega flexible + enterprise + AI-first + legible de un solo golpe.
Restaurar, no reinventar. El viejo RulesLibrary tenía un Tester de 7 etapas (precedencia visible) + Test Mode (draft→simular→commit con audit). Se borró por accidente. Mucho de su motor sigue vivo como código muerto — re-cablear.
Nunca tocar las APIs del portal. Demos antes de prod. Ninguna celda de la matriz de flexibilidad se pierde.
1 La idea grande — un solo gateway de escritura
Hoy dos caminos hacen lo mismo con calidad muy distinta. El rediseño los funde: el humano hace clic ✏️ o le pide al Copilot → misma propuesta, mismo drawer, mismo execute-action.
Camino humano / UI (hoy)
- El cap se edita en 6 lugares, la tarifa en 4+
- Sin confirmación unificada (form + toast)
- Sin audit —
match_rules.created_bynunca se llena - Precedencia invisible · sin undo
Camino AI / Copilot (hoy)
- UN gateway (
execute-action) - RBAC + bounds + partner∈client
- Audit before/after (
ai_action_log) + paridad - Idempotencia + undo
<ConfirmDrawer> compartido. Toda edición de dinero queda auditada, deshacible y con consecuencia visible.2 La arquitectura — 7 cimientos (se construyen una vez)
Todo lo demás cuelga de aquí. Se hacen al arrancar P2.
useClientProfile()
Objetivo(s), fuente(s), billing model, ticket, validation rate. Mata el branching de tracking_type en 12+ archivos.
Vocabulario por objetivo
Objetivo → nombres de KPI, Órdenes/Leads/Conversiones, modelo de comisión, niveles de tabla.
El gateway unificado
Generalizar execute-action + un <ConfirmDrawer> compartido. La keystone: colapsa 3 patrones de "confirmar antes de aplicar" en uno.
La columna de audit
Enrutar match_rules por el gateway → provenance (quién/cuándo/vía qué) en cada número de dinero. Visor de audit en Users&Access.
Restaurar Tester + Test Mode
Re-cablear el Tester de 7 etapas (precedencia visible) + draft→simular(overlay.go)→commit. El código sobrevive.
Contrato de data
🟢 completa / 🟡 estimada ("calculado con…") / 🔴 falta config. Nunca inventar un número.
2 campos de config
client_billing_model + ticket_estimado. Para KPIs + drawers en clientes no-Samsung.
3 Reúso — el código que sigue vivo (no reconstruir)
El hallazgo que abarata todo: la mayoría del poder regresado sigue en el repo como código muerto. Re-cablear > reescribir.
| Feature | Activo que sobrevive |
|---|---|
| Editor de reglas (flat+tiered) | RateOverrideEditorBody.tsx + ImpactPreviewPanel + FireBadge |
| Matchers del Tester | attributionMatcher.ts · rulesMatch.ts · rulesTypes.ts |
| Lector de audit | RulesAuditView.tsx · useV2CommissionAuditEvents.ts |
| Test Mode (simulador) | useV2RuleDrafts.ts · commit_rule_drafts() · backbone/…/overlay.go (17 tests) |
| El gateway de escritura | execute-action.ts · actions/*.ts · action-permissions.ts |
| UI de confirmación | ActionConfirmCard.tsx → promover a ConfirmDrawer |
| Patrones de audit que sí jalan | audit-logger.ts (budget/payment/partner) + /api/activity |
4 Las fases (revisadas con los hallazgos)
Cada fase se mergea sola + demo antes de prod. Nota: Reglas subió a P3 — es lo de mayor valor y el más barato (reúso).
Sidebar 2-modos, ⌘O, mes, ⌘K, real·validado, fix de orders. Listo para merge incremental.
useClientProfile + vocabulario + el gateway unificado + Hoy (bento 8 KPIs + tabla maestra + cinta del ciclo) + contrato de data + 2 campos. Construir el gateway aquí para que P3-P5 lo reúsen.
Restaura el Tester + Test Mode + CRUD inline por el gateway. El Deal (una tabla por segmento, precedencia visible) absorbe reglas + atribución y mata el problema de los 6 números.
Launch de verdad (sin teatro, atómico, todos los segmentos). Órdenes = una tabla que absorbe Leads + Fraude review + Pixel.
Alta que nace viva (checklist de vida). Drawers con recalc en todos lados. Audit visible + provenance + Users&Access real (hoy es mock).
Clusters de config en tabs, platform pages, i18n, Planner v4 live-chain.
→ Qué construye Kimi primero (apertura de P2)
useClientProfile() + vocabulario por objetivo — desbloquea el lenguaje del objetivo en todos lados.
El gateway unificado de escritura — extraer de execute-action, el ConfirmDrawer compartido, arreglar el tipo V2Proposal. Esto desbloquea TODO lo demás.
Hoy: bento + tabla maestra + aritmética de pace/runway (sin backend nuevo).
Los 2 campos de config + contrato de data. → demo. Luego P3 (restaurar Reglas), la joya, con reúso pesado.