balam/planeacion/Avance-Etapa1-2026-07-27.md

Corte de avance — Etapa 1

Fecha: 27-jul-2026 (corte de los lunes, formato pedido por Erika: entregable + actividad + horas por etapa) Etapa: Plataforma base y sincronización con BIND Rango estimado contractual: 32–39 h · Horas registradas de Etapa 1: 19.75 h (total del proyecto: 41.58 h) Adjunto: Plan-actividades-avance-2026-07-27.xlsx

Documento interno de Johann. El mensaje para Erika va abajo; el resto es sustento propio (no se comparte).

---

Mensaje breve para Erika (WhatsApp)

Hola Erika, buen día. Te comparto el avance de la Etapa 1 al corte de hoy (Excel adjunto, con entregable · actividad · horas por etapa como lo pediste).

El núcleo de la plataforma ya está construido y probado contra producción: autenticación con roles y bitácora de auditoría, arquitectura multi-tenant con aislamiento por RLS, el cliente de la API de BIND, la sincronización de clientes, facturas y cotizaciones, el modelo central de facturas con sus estados y la cartera separada por moneda. La sincronización del histórico ya corrió y cuadró: 1,494 facturas con sus totales de cartera coincidiendo con BIND.

Lo que sigue pendiente es, sobre todo, la capa de escritura (cotización→factura), que dejé en pausa a propósito hasta que definan el flujo de facturación en la sesión del martes, ya que de ahí dependen las reglas. También quedan por cerrar el afinado de datos de prueba y la parte de Azure/CI-CD, que depende de los accesos de su lado.

En horas voy en 19.75 h de Etapa 1 (rango estimado 32–39 h), con 6 de los 8 entregables de la etapa ya terminados. Con la key de Jira que nos pasó Pedro hoy y las definiciones del martes, arranco la integración con Jira y la capa de escritura. Cualquier duda quedo al pendiente. 🙌

(Nota: el ajuste de la propuesta y el conteo de horas formal van por separado; este mensaje es solo el avance de Etapa 1.)

---

Sustento interno

Terminado y verificado contra producción

• Backend base: autenticación con JWT propio, matriz de roles (Finanzas, Dirección, Operaciones, Administración) con policies, y bitácora de auditoría universal (logins, sync, transiciones, escritura). — entregable contractual 1 ✅
• Multi-tenant + RLS real de Postgres (no solo filtro EF): políticas tenant_isolation fail-closed en las 8 tablas de negocio + interceptor de conexión. — entregable 2 ✅ (verificación de aislamiento local pendiente de rol de app no-superusuario; las políticas ya están correctas — ver REGISTRO #53)
• Cliente productivo de BIND en C#: paginación OData, reintentos, control de cuota y errores; solo lectura por defecto. — entregable 3 ✅
• Sync de clientes (full-scan barato + hash + detalle solo de nuevos/cambiados, normalización RFC/nombre, dedup por RFC exacto). — entregable 5 ✅
• Sync de facturas y cotizaciones con estados normalizados, tipo de cambio y detección de pagos (fecha de detección, ADR-004). — entregable 6 ✅
• Modelo central de facturas con estados (Emitida, Vigente, Vencida, Pagada, Cancelada) como función pura con pruebas. — entregable 7 ✅
• Cartera por moneda (jamás suma monedas): GET /api/cartera verificado BD↔endpoint — MXN 17 abiertas $1,568,772.32 · USD 92 abiertas $320,379.06.
• Sync histórico corrido y verificado (jamás en vivo): 1,494 facturas + 43 cotizaciones, detalle 1,494/1,494, idempotencia comprobada, 0 pagos falsos. (REGISTRO #52)
• 26/26 pruebas unitarias verdes.

En construcción / en pausa

• Capa de escritura controlada (cotización→factura) — entregable 4. Al 40 %: diseño y modelo listos, implementación en pausa. Ya hecho: entidad WriteOperation con el pipeline Draft→DryRun→Confirmed migrada, policy PuedeOperarEscritura, ADR-001, el diseño del BindWriteClient con flags apagados por default y la regla PPD/PUE (informada por el hallazgo de que 1,374/1,374 facturas del histórico son PUE). Falta el BindWriteClient, el pipeline implementado, los shapes reales de los POST y las pruebas. 🔴 Pausa deliberada hasta la definición del flujo de facturación (sesión martes 28-jul con Arturo/Araceli): de ahí salen las reglas de prefactura, PPD/PUE, alta de cliente y qué estatus de Jira dispara qué.
• Scheduler + backfill (sync programado cada 15 min) — el sync ya funciona en manual; falta automatizarlo.
• Datos de prueba (seeder) + runbook — entregable 8, al 85 %: modelo central de facturas con el InvoiceStatusMapper (13 pruebas) ✅, migraciones ✅; falta el seeder de datos ficticios y el runbook.
• Suite de pruebas de flujos críticos (integración) — pendiente.

Dependencias externas (lado Balam)

• Definición del flujo de facturación/prefacturación — sesión martes 28-jul (Erika coordina). Desbloquea la capa de escritura.
• Correo del flujo de facturación de Jira (Erika lo envió 22-jul) — a incorporar.
• Alcance Jira → cotización BIND al 90 %: conectividad resuelta el 27-jul (token PAF con vigencia a 1 año, API confirmada de lectura y escritura, bandeja Facturación (FAC) identificada, límites de consumo aclarados por correo de Pedro: sin tope mensual, 3 límites de velocidad, autorregulación por headers X-RateLimit-*). Falta el 10 %: qué estatus de Jira dispara qué (amarrado a la definición del 28-jul) y validar si basta escuchar FAC o hay que rastrear los procesos que nacen en RH/Administración General y caen ahí.
• Acceso a Azure + CI/CD (Pedro/Noé) — condiciona el despliegue.

Criterio de medición

• Entregables contractuales: 6 de 8 terminados (1, 2, 3, 5, 6, 7). Los dos restantes van parciales y su avance se muestra en su propia fila del Excel, no promediado en el encabezado: el 8 al 85 % (migraciones sí, seeder no) y el 4 al 40 % (escritura: diseño y modelo listos, implementación en pausa por definición de Balam). → El Excel reporta 75 % de Etapa 1, contando solo entregables cerrados, que es lo verificable.
• Horas de Etapa 1: 19.75 h de un rango de 32–39 h (~51–62 % del esfuerzo estimado).
• Se reporta por entregable terminado, no por promedio ponderado de actividades. El corte anterior mostraba 82 % ponderado, que era optimista e indefendible: no distinguía entre trabajo hecho y trabajo bloqueado. "6 de 8" dice exactamente qué falta y de quién depende.
• La brecha entre 75 % de entregables y ~55 % de horas no es un error: refleja que las sesiones de desarrollo asistidas por IA produjeron el núcleo en mucho menos tiempo de reloj que la estimación manual (ver la nota en Seguimiento-horas.md).

Horas: estado de la validación (resuelto el 27-jul)

• 41.58 h en total — Etapa 0: 21.83 h · Etapa 1: 19.75 h.
• Cero horas pendientes de validar. 9.13 h con duración documentada (confirmada) y 32.45 h reconstruidas y confirmadas por Johann contra evidencia fechada (validada).
• Correcciones aplicadas en este corte:
  • Se corrigió un error de formato del CSV que ocultaba 1.00 h del 19-jul (entorno local).
  • Se re-etiquetó el 10-jul: la mayor parte eran 6 commits de pulido del prototipo (E0-05), no el entregable de cierre (E0-06). Mismo total, etiquetas correctas.
  • Se incorporaron 3.50 h de trabajo real que no estaba cobrado: diseño del plan de Etapa 1 (2.00 h, Plan-Etapa1.md) y preparación de las sesiones del 22 y 24-jul (1.50 h, agenda y guion de validación).
  • Ajustes a la baja en las horas reconstruidas de Etapa 0: análisis del Discovery de facturación 1.92 → 1.00 h, documentación del de cobranza 1.50 → 0.75 h, guion de validación 0.75 → 0.45 h. Las duraciones de sesión documentadas en transcript no se tocaron.
  • Cada celda de horas del Excel se genera desde el CSV y el script falla si el detalle no cuadra con el total.
• Etapa 0 cerró en 21.83 h, dentro del rango contractual de 18–22 h.

Punto abierto (no bloquea el envío)

• Tono del mensaje: el borrador enmarca la capa de escritura como "en pausa por la definición del 28-jul" — pone la pelota de su lado, y es verdad. Si prefieres suavizarlo, se ajusta.