GoWeBaKnowledge Center

THE UNIFIED PLATFORM BIBLE — ADDENDUM 07

Triple Verificación — Pipeline de Migración & Correcciones Junio 2026

Versión: 1.0
Fecha: 16 de junio de 2026
Autor: Alain Bessette, CFO/Product Owner, ABI Conglomerate
Dominio: GoWeBa.com
Estado: Addendum estratégico oficial — Especificación vinculante
Restricciones: CERO pérdida de datos · CERO force-reset · CERO interrupción de email


⚠️ AVISO CRÍTICO
Este addendum tiene la MISMA autoridad que la Parte 1, la Parte 2 y todos los addendums anteriores de la Biblia.
Todas las correcciones descritas están desplegadas en producción y guardadas en checkpoint.
No se realizaron cambios de esquema incompatibles.

📋 TABLA DE CONTENIDOS

  1. Contexto y Objetivo
  2. Fase M — Verificación del Google Pull
  3. Fase C — Verificación de la Clasificación V10
  4. Fase E — Corrección Email Forward/Reply
  5. Fase A — Pestaña ARCHIVED y Cuadrícula de 15 tarjetas
  6. Corrección de Dirección Bounce
  7. Registro de Dominios — Seed Inicial
  8. Estado de la Base de Datos
  9. Veredicto Final y Recomendaciones
  10. Archivos Modificados — Inventario Completo
  11. Cronología de Checkpoints

<a id="contexto"></a>

SECCIÓN 1: CONTEXTO Y OBJETIVO

Después de varias iteraciones en el pipeline de migración Google → GoWeBa, este addendum documenta la triple verificación exhaustiva realizada el 16 de junio de 2026, antes del lanzamiento oficial de las migraciones de usuario.

Las fases verificadas cubren todo el ciclo de vida:

FaseAlcanceEstado
MMigración automatizada (Google Pull API)✅ Verificado
CClasificación V10 (cascada de 12 capas)✅ Verificado
EEmail Forward/Reply (adjuntos + From)✅ Corregido y desplegado
APestaña ARCHIVED + cuadrícula 15 tarjetas✅ Corregido y desplegado
BounceCorrección de dirección bounce inbound✅ Corregido y desplegado
Registro de DominiosSeed inicial de 333 dominios✅ Ejecutado

<a id="fase-m"></a>

SECCIÓN 2: FASE M — VERIFICACIÓN DEL GOOGLE PULL

2.1 Arquitectura de Recuperación

El módulo lib/migration/google-pull.ts gestiona la extracción de datos de Google mediante APIs nativas (People, Gmail, Calendar, Drive) sin dependencia del paquete googleapis.

2.2 Parámetros de Rendimiento Verificados

ParámetroValorJustificación
QUERIES_PER_MIN200Bajo el límite de Gmail de 250/min
MICRO_BATCH8 solicitudes concurrentesParalelismo controlado
DELAY_BETWEEN_BATCHES_MS2.400 ms8 / 2,4s ≈ 3,33 req/sec = 200/min
MACRO_BATCH_SIZE2.250Procesamiento por chunks
FLUSH_SIZE200Flush a DB cada 200 emails
MAX_RETRIES4Intentos con backoff exponencial
INITIAL_BACKOFF_MS2.000 msBackoff inicial (2s → 4s → 8s → 16s)
MAX_CONSECUTIVE_ERRORS20Parada de seguridad

2.3 Mecanismos de Robustez

  • Backoff exponencial: 2s → 4s → 8s → 16s + jitter aleatorio de 1s
  • Detección de rate limit: isRateLimitError() detecta códigos HTTP 429 y errores específicos de Google
  • Parada preventiva: Después de 20 errores consecutivos, la importación se detiene limpiamente
  • Flush progresivo: Los emails no se mantienen en memoria — se envían a la DB en lotes de 200
  • Logs de progreso: Un log cada ~500 emails con el tiempo transcurrido

2.4 Veredicto

SÓLIDO — Los parámetros son conservadores, los mecanismos de retry y parada están en su lugar.

<a id="fase-c"></a>

SECCIÓN 3: FASE C — VERIFICACIÓN DE LA CLASIFICACIÓN V10

3.1 Cascada de 12 Capas

CapaNombreConfianzaDescripción
1USER SENDER RULES1.00Reglas de usuario — BLOCK→SPAM, ALLOW→skip
2GMAIL STARRED0.95isStarred=true → URGENT
3EXPLICIT URGENCY0.92Regex jurídico/urgencia (FR/EN/ES)
4DOMAIN REGISTRY0.90lookupDomain() — 333 dominios mapeados
5FROM-ADDRESS PATTERNS0.88noreply→OFFICE, newsletter→JOURNAL
6GMAIL CATEGORY LABELS0.85CATEGORY_SOCIAL→SOCIAL, etc.
7SUBJECT LINE PATTERNS0.72Correspondencia de palabras clave trilingüe
8TEMPORAL ANALYSIS0.70Deadlines→URGENT/IMPORTANT
9CONTACT GRAPH0.68Contacto CRM conocido → IMPORTANT
10LLM INTELLIGENCEvariableGPT-4.1-mini + 6E few-shot
11(parte de L10)Few-shot inyectado en el prompt LLM
12FALLBACK0.10NONE

3.2 Feature Flags

Todos los flags V10 están activados por defecto:

FlagFunción
V10_WEBABOX_UIInterfaz cuadrícula 4×4
V10_NEW_CATEGORIESTRAVEL, SOCIAL, PROMOTIONS
V10_AUTO_ARCHIVEAuto-archivo cron 90 días
V10_CONTACT_CLASSIFIERClasificación de tipos de contactos
V10_SECURITY_SCORERPuntuación de seguridad de emails
V10_DOMAIN_REGISTRYRegistro de dominios (capa 4)
V10_REALTIME_PIPELINEPipeline de cascada en tiempo real

3.3 Veredicto

SÓLIDO — La cascada de 12 capas está completa, el self-chaining funciona, todos los feature flags están activados.

<a id="fase-e"></a>

SECCIÓN 4: FASE E — CORRECCIÓN EMAIL FORWARD/REPLY

4.1 Problemas Identificados

  1. Adjuntos no transferidos: Al reenviar, los adjuntos del email original no se incluían.
  2. Cuenta de envío incorrecta: El selector "From" no se posicionaba en la cuenta del thread.

4.2 Correcciones Aplicadas

  • compose-modal.tsx — Prop initialAttachments + lógica de carga (presigned URL → base64)
  • webabox-client.tsx — Adjuntos en replyComposeState
  • ongoing-client.tsx — Misma propagación para modo thread
  • Fix de sobreescritura de cuenta: if (!initialAccountId && ...)

4.3 Veredicto

CORREGIDO Y DESPLEGADO

<a id="fase-a"></a>

SECCIÓN 5: FASE A — PESTAÑA ARCHIVED Y CUADRÍCULA DE 15 TARJETAS

5.1 Cambios de UI

AntesDespués
Pestaña "Unread" arribaPestaña "Archived" arriba
16 tarjetas (4×4 con ARCHIVED)15 tarjetas (3×4 + 1×3, sin ARCHIVED)

5.2 Disposición de la Cuadrícula

FilaCategorías
1Urgent · Important · Conversations · Awaiting
2Journal · Office · Reply Later · Set Aside
3Travel · Social · Promotions · Clips
4Snooze · Spam · Trash

5.3 Veredicto

CORREGIDO Y DESPLEGADO

<a id="bounce-fix"></a>

SECCIÓN 6: CORRECCIÓN DE DIRECCIÓN BOUNCE

6.1 Problema

Los emails entrantes mostraban direcciones de remitente como bounce+xxx@m.relayfi.com en lugar de la dirección real, haciendo Reply y Forward inutilizables.

6.2 Causa Raíz

Archivo: app/api/webhooks/sendgrid-inbound/route.tshandleRawMode()

El código extraía correctamente la dirección real del encabezado MIME From:, pero luego la sobrescribía con envelope.from (la dirección técnica de rebote).

6.3 Impacto

ContextoAntesDespués
fromEmail en DBbounce+xxx@m.relayfi.comremitentereal@dominio.com
Función ReplyResponde al bounceResponde a la persona real
Contacto auto-creadoContacto bounceContacto real

6.4 Limitación Conocida

30 mensajes existentes aún tienen direcciones bounce. Solo los nuevos emails entrantes están corregidos.

6.5 Veredicto

CORREGIDO Y DESPLEGADO

<a id="domain-registry"></a>

SECCIÓN 7: REGISTRO DE DOMINIOS — SEED INICIAL

Durante la verificación se descubrió que la tabla DomainRegistry estaba vacía. Se ejecutó el seed:

  • 333 dominios creados (SOCIAL, TRAVEL, PROMOTIONS, JOURNAL, OFFICE)
  • La capa 4 de la cascada V10 ahora funciona correctamente
  • Mejora en velocidad, precisión y costos de clasificación
CORREGIDO — Seed ejecutado y verificado

<a id="estado-db"></a>

SECCIÓN 8: ESTADO DE LA BASE DE DATOS

8.1 Snapshot — 16 de junio de 2026

MétricaValor
Threads de email884
Mensajes de email1.284
Threads archivados184
Contactos1.045
Logs de clasificación59
Entradas registro de dominios333
Proyectos de migración9

8.2 Distribución de Categorías

CategoríaThreads%
NONE78188,3%
JOURNAL424,8%
IMPORTANT323,6%
OFFICE171,9%
URGENT80,9%
PROMOTIONS40,5%

<a id="veredicto"></a>

SECCIÓN 9: VEREDICTO FINAL Y RECOMENDACIONES

🟢 EL PIPELINE DE MIGRACIÓN ESTÁ LISTO. Todas las verificaciones pasaron. Las correcciones críticas fueron aplicadas. El registro de dominios fue poblado. El sistema está listo para procesar nuevas migraciones con confianza.

Recomendaciones

  1. Ejecutar la clasificación V10 sobre los 781 threads NONE existentes
  2. Ejecutar el auto-archivo para threads >90 días
  3. Verificar los primeros emails entrantes después de la corrección bounce
  4. Considerar un script de corrección retroactiva para los 30 mensajes con direcciones bounce
  5. Considerar agregar un campo replyTo al modelo EmailMessage

<a id="archivos"></a>

SECCIÓN 10: ARCHIVOS MODIFICADOS

ArchivoModificación
compose-modal.tsxProp initialAttachments + presigned URL → base64 + fix cuenta
webabox-client.tsxreplyComposeState + forward attachments + pestaña ARCHIVED + cuadrícula
ongoing-client.tsxcomposeState + forward attachments
snapshot/route.tsContador archived en totales
sendgrid-inbound/route.tsSeparación mimeFrom vs envelopeFrom

<a id="checkpoints"></a>

SECCIÓN 11: CRONOLOGÍA DE CHECKPOINTS

FechaCheckpointDescripción
15 junio 2026Fase EForward attachments + From default fix
15 junio 2026Fase AArchived tab + 15-card grid
16 junio 2026Bounce FixFix bounce address in fromEmail

Fin del Addendum 07 — Triple Verificación Migración

© 2024–2026 GOWEBA INC. — Make it Simple, Make it Possible, Make it Real.