Ir al contenido
Lade Wiki

Estado general del proyecto

Documento centralizado a nivel workspace. Consolida y reemplaza docs/product/master-plan.md (billing/suscripciones, fechado 2026-03-20), verificado contra el código real el 2026-07-13. Para pendientes ver PROXIMOS_PASOS.md en esta misma carpeta.

Estado por repo con más detalle: lade-infra/docs/ESTADO_ACTUAL.md, lade-app/docs/ESTADO_ACTUAL.md.

Repositorios

Sección titulada «Repositorios»
Repo Stack Estado
lade-app/ React 19 + Vite + Tailwind v4 + Zustand Activo
lade-infra/ Terraform + Python 3.11 + AWS (DynamoDB single-table) Activo
lade-landing/ — Fuera de este seguimiento
lade-api/ NestJS Deprecado, no usar

Producto

Sección titulada «Producto»

Lade es una plataforma SaaS B2B para pequeñas/medianas empresas de logística y transporte en México: gestión de flota (vehículos, conductores), clientes, rutas y viajes, con CFDI (Carta Porte) automatizado vía Facturapi. Multi-tenant por equipo. Modelo freemium: 45 días de prueba (20 viajes) → planes de suscripción + recargas de viajes.

Billing / Suscripciones — verificado contra código (2026-07-13)

Sección titulada «Billing / Suscripciones — verificado contra código (2026-07-13)»

Implementado y confirmado en código:

  • Trial de 45 días + 20 viajes al crear equipo; TripsLimit/TripsUsed/TrialEndsAt en TEAM#METADATA.
  • billing/get-subscription, create-checkout, portal, list-payments.
  • billing/webhook: maneja checkout.session.completed, subscription.updated, subscription.deleted, invoice.payment_failed. El bug de _find_team_by_customer (buscaba GSI1PK="BILLING", índice inexistente) está corregido — ahora lee teamId de metadata del subscription y cae a un scan de fallback por StripeCustomerId.
  • Idempotencia del webhook implementada: _is_already_processed(event_id) usa la tabla de idempotencia antes de procesar cualquier evento.
  • check_subscription_active() existe y está wireado en la mayoría de lambdas de escritura (clients, drivers/create+update, vehicles/create+update, trips/assign, trips/update-status). Ver huecos verificados en PROXIMOS_PASOS.md.
  • Frontend: BillingStore con isBlocked, daysLeftInTrial, tripsLimitReached calculados; UpgradeModal existe y está montado en DashboardLayout; fetchSubscription se auto-dispara al cambiar de equipo; useBillingGuard (hook canWrite/guardWrite) existe.
  • Precios Stripe reales configurados en stripePrices.ts (no placeholders).

Reclamado como “✅ COMPLETADO” en el doc anterior pero NO confirmado en código (ver PROXIMOS_PASOS.md para el detalle): banner de trial en el dashboard, aplicación de useBillingGuard en los botones de crear/editar, idempotencia de trips/create.

Facturación CFDI (Facturapi)

Sección titulada «Facturación CFDI (Facturapi)»

Ver lade-infra/docs/ESTADO_ACTUAL.md — flujo completo, incluye el fix de esta sesión al borrador automático de factura (bug de import cruzado entre lambdas, ver ese documento).

Arquitectura backend (hexagonal + event-driven)

Sección titulada «Arquitectura backend (hexagonal + event-driven)»

Migración en curso documentada en lade-infra/docs/architecture/architecture-plan.md — Fases 0 a 4 completadas (repositories, use cases, Powertools en trips, event bus). Fase 5 (Powertools en el resto de lambdas) pendiente, ver lade-infra/docs/PROXIMOS_PASOS.md.

Sesión 2026-07-13 — bugs corregidos y features agregadas

Sección titulada «Sesión 2026-07-13 — bugs corregidos y features agregadas»
  • Fix: borrador de factura no se creaba (import cruzado entre lambdas de distintos folders, rompía el paquete de events/invoice-drafter).
  • Fix: fotos de conductor/imagen de vehículo no aparecían en el viaje (dato nunca se denormalizaba al Trip).
  • Fix: conductor/vehículo se bloqueaban al crear el viaje en vez de al iniciarlo — ahora el bloqueo ocurre solo al pasar a EN_PROCESO.
  • Nuevo: cron trip-auto-start (EventBridge, cada 3 min) transiciona automáticamente los viajes cuya fecha de inicio ya llegó, usando el índice disperso GSI2 (antes provisionado pero sin uso).
  • Nuevo: sistema de alertas (AlertRepository, endpoints, campana en el Header) con 3 alertas activas: viaje auto-iniciado, borrador de factura fallido, límite de viajes alcanzado.
  • Nuevo: Mapa de Operaciones (/dashboard/operations/map) — ver docs/features/mapa-operaciones.md.
  • Nuevo: cálculo de distancia/duración/casetas de una ruta vía Google Routes API, calculado una sola vez al crear la ruta y cacheado (encodedPolyline, etc.) — elimina llamadas repetidas a Directions/Routes API al solo ver una ruta.
  • Extendido: docs/features/driver-as-user.md con la especificación de tracking GPS (contrato de API, etapas de rollout).

Cobranza y Reportes financieros (Payments) ✅ COMPLETADO (sesión 2026-07-14/15)

Sección titulada «Cobranza y Reportes financieros (Payments) ✅ COMPLETADO (sesión 2026-07-14/15)»

Módulo nuevo de cobranza por viaje — Trip solo guardaba montos planeados (cost/revenue) y no existía ningún registro de qué se había cobrado realmente. Ver detalle completo en lade-infra/docs/ESTADO_ACTUAL.md, sección “Pagos (Payments)”.

  • Fase 1: dominio Payment (ledger de abonos, soporta pagos parciales), estado de cobro derivado (SIN_COBRAR | PARCIAL | PAGADO | ATRASADO), lambdas create/list-by-trip/list/delete/overdue-check (alerta interna diaria por viaje atrasado). Frontend: tab “Viajes” en cliente + sección “Finanzas” (Reportes, Cobranza).
  • Fase 2: dos lambdas de agregación server-side (reports/revenue-by-client, reports/collections-summary) que reemplazan el cálculo client-side de Fase 1 — el API de trips nunca devolvía más de 100 registros, así que los totales quedaban mal para equipos con más viajes. Exportar CSV/PDF en Reportes y Cobranza. Dos KPIs nuevos (“Saldo por Cobrar”, “Saldo Atrasado”) disponibles en el selector de widgets del Home.
  • Pendiente, fuera de alcance a propósito: notificación por email al cliente cuando un pago se atrasa (hoy solo genera alerta interna).

Notas fundacionales (/Lade/md/, revisadas 2026-07-13)

Sección titulada «Notas fundacionales (/Lade/md/, revisadas 2026-07-13)»

Carpeta de notas sueltas anterior a la formalización de docs/. Revisadas y consolidadas:

  • plan.md y dynamo-endpoints-manager.md — plan de dominio original y diseño de patrones de acceso DynamoDB single-table. Se volvieron la arquitectura real — lo que describen coincide con el sistema implementado hoy (entidades, GSIs, patrones de llave). Sin valor de referencia adicional una vez verificado esto, se eliminaron.
  • auth&refreshtoken.md — proponía una lambda auth/refresh dedicada para refrescar el JWT. No se tomó ese camino: no existe tal lambda; Cognito maneja el ciclo de vida del token. El frontend sí guarda un refreshToken en tokenStorage (core/api/client.ts) pero no se confirmó que algún flujo lo consuma activamente — ver PROXIMOS_PASOS.md.
  • manage-user-tokens.md — proponía adoptar React Query para el manejo de datos remotos. No se adoptó: package.json no tiene @tanstack/react-query; el sistema usa Zustand + funciones de servicio simples (ver CLAUDE.md de lade-app), una decisión más simple que funcionó.
  • Connect-aws.md — snippet de 4 líneas para configurar el perfil de AWS CLI. Sigue siendo útil, no es un plan — se conserva tal cual en /Lade/md/.

Índice de docs vigentes (root)

Sección titulada «Índice de docs vigentes (root)»
  • docs/features/driver-as-user.md — plan de conductor-como-usuario en la app móvil Flutter + tracking GPS.
  • docs/features/mapa-operaciones.md — diseño del Mapa de Operaciones.
  • docs/features/milk-run.md, docs/features/nominas.md, docs/features/future-features.md — propuestas sin implementar, ver PROXIMOS_PASOS.md.
  • docs/features/ci-cd-oidc-compartido.md — roles OIDC compartidos por org (implementado, 2026-07-22) y los templates de scaffolding (lade-templates/); explica cómo difiere en lade-infra/lade-app vs. proyectos nuevos.
  • docs/infrastructure/cicd.md — pipeline CI/CD, mayormente implementado (ver gap en PROXIMOS_PASOS.md).
  • docs/infrastructure/waf.md — propuesta sin implementar, ver PROXIMOS_PASOS.md.