Backend — Próximos pasos

Consolida los pendientes de architecture-plan.md, billing/stripe.md, billing/facturapi.md y migrations/rds-migration-plan.md (todos eliminados tras esta consolidación).

Arquitectura

1. Fase 5 de la migración hexagonal: aplicar AWS Lambda Powertools (Logger/Tracer/Metrics) al resto de lambdas fuera del dominio trips (clients, drivers, vehicles, routes, route-points, invitations, teams, users). Patrón ya establecido — ver trips/create/handler.py y trips/update-status/handler.py como referencia.

Billing — ver detalle completo en docs/PROXIMOS_PASOS.md (root)

Resumen (detalle verificado contra código el 2026-07-13): 2. trips/create sin idempotencia real (_check_idempotency siempre retorna None — regresión post-migración RDS→DynamoDB). 3. check_subscription_active() falta en: drivers/update-status, vehicles/update-status, route-points/{create,update,delete}, trips/delete, invitations/create, routes/delete.

Facturación CFDI

4. Verificar el path real de create_live_api_key (PUT /organizations/{id}/apikeys, inferido del patrón del endpoint de listado) contra una llamada real de Facturapi la primera vez que un equipo complete CSD + datos fiscales — si el path es incorrecto, revisar logs de invoices/upload-certificate/invoices/setup-organization.
5. Registrar manualmente el webhook secret (terraform output -raw facturapi_webhook_secret) en el dashboard de Facturapi tras el próximo terraform apply.
6. invoices/list no enriquece cada factura con datos del viaje (columna Cliente muestra “N/A” hasta agregar ese join) — gap menor conocido, no resuelto.
7. Si invoices/stamp se corta a medio vuelo (timeout de 60s) tras reclamar PENDING, no hay recuperación automática de locks obsoletos — caso extremo, requeriría intervención manual o reconciliación vía el webhook de Facturapi.

Migración DynamoDB → RDS (rds-migration-plan.md, eliminado)

Nota importante: este documento proponía migrar de DynamoDB a Aurora Serverless v2/Postgres. El código actual muestra la dirección contraria ya tomada: hay un comentario explícito en infra/main.tf (“DB Migrations Lambda removed — migrated from RDS/Postgres to DynamoDB single-table design”) indicando que el sistema ya vivió en RDS y se migró a DynamoDB, no al revés. El plan de migración a RDS parece obsoleto/abandonado en favor de DynamoDB — si se quiere retomar esta idea, hay que decidir explícitamente la dirección (¿volver a RDS, o descartar el documento?) antes de usar su contenido (DDL, modelos SQLAlchemy, fases) como referencia.

CI/CD

8. deploy.yml fallará en el step de migraciones — invoca aws lambda invoke --function-name lade-{env}-migrations, lambda que ya no existe tras el punto anterior. Quitar el step (o los tres, uno por entorno) del workflow, o reemplazarlo por un no-op mientras no haya una base de datos relacional que migrar.

Google Routes / Rutas

9. routes/update no soporta editar stops (solo name, code, clientId, status) — si se agrega esa capacidad, hay que recalcular compute_route_metrics() cuando cambien los stops, igual que se hace en routes/create.
10. Rutas creadas antes de esta sesión (2026-07-13) no tienen EncodedPolyline/DistanceMeters/etc. — el frontend cae automáticamente al DirectionsRenderer en vivo para esas rutas (compatibilidad hacia atrás), pero no hay backfill. Un script one-off que recorra rutas existentes y llame compute_route_metrics() para poblarlas retroactivamente es opcional, no urgente.
11. Confirmar el precio vigente de Google Routes API (SKU Essentials vs. Pro al usar extraComputations: TOLLS) antes de escalar el volumen de creación/edición de rutas — a la fecha de implementación (2026-07-13) el costo es marginal dado el volumen esperado, pero vale la pena reconfirmar en developers.google.com/maps/billing-and-pricing.