Roadmap

Roadmap

Qué estamos construyendo y qué sigue.

Inicia sesión con tu cuenta del dashboard para proponer o reportar.

Planeado

25
  • 0
    IdeaOtro

    Tours: temporizador visible para el pasajero en las paradas (tiempo de estadia por vinicola) — mxc-tours / MXC City

    Juan Pablo Pelayo (MXC City, ex MXC Tours, PRO, conv 390976) opera tours de vinicolas de 4 a 12 horas con precio fijo por paquete (2000/2500/3000/3500/4500 MXN). Su peticion: que la app maneje un TEMPORIZADOR para el usuario con los tiempos de estadia en cada vinicola, para que pasajero y conductor vean cuanto tiempo queda en cada parada antes de continuar el recorrido. Hoy no existe el concepto de 'parada con tiempo de estadia' en el viaje: un tour se modela como un ServiceType de precio fijo, sin waypoints ni cronometro por parada. Que haria falta (propuesta): - Waypoints/paradas por servicio (N paradas configurables por el dueno) con duracion objetivo por parada. - Cronometro visible en la app del pasajero y del conductor durante la parada (cuenta regresiva) + aviso cuando se acaba. - Opcional: cargo por tiempo extra si se pasan del tiempo contratado. Aplica al vertical Tours en general, no solo a este tenant.

  • 0
    IdeaOtro

    Impresion automatica de comandas en TABLET: hoy solo hay cero-toque en Windows (Chrome kiosk-printing) — falta impresion nativa ESC/POS por Bluetooth/USB desde la app del negocio

    Pedido de Pavel (rapi2, PRO, conv 384594): quiere montar la auto-impresion de comandas en una TABLET con impresora Bluetooth o por cable, no en una computadora. ESTADO REAL VERIFICADO (2026-07-22): - La auto-impresion vive en el portal web del negocio: src/lib/business-portal/auto-print-orders.ts (guard anti-doble-impresion) + src/components/shared/order-ticket.tsx (window.print(), @page size 80mm auto). - El cero-toque depende de que el NAVEGADOR imprima sin dialogo. Eso hoy solo existe en desktop Chrome con --kiosk-printing (Windows/macOS/Linux). - Android: Chrome NO tiene impresion silenciosa; window.print() abre el dialogo del framework de impresion de Android y alguien tiene que tocar Imprimir en cada comanda. Ademas las termicas Bluetooth genericas (ESC/POS) no aparecen en ese dialogo salvo que el usuario instale un print service de terceros (RawBT o el de la marca). No es cero-toque y no lo controlamos. - iPadOS: solo AirPrint. Una termica Bluetooth ESC/POS no es AirPrint -> no imprime. PEDIDO: impresion nativa de la comanda desde la APP del negocio (Flutter) hacia impresora termica ESC/POS por Bluetooth o USB-OTG, disparada al llegar el pedido. Convertiria una tablet Android barata + termica Bluetooth en la estacion de comandas (lo que usa el mercado de delivery), sin depender del navegador. WORKAROUND comunicado al cliente: mini-PC o tablet WINDOWS junto a la impresora, Chrome con impresion de kiosco -> cero-toque real y garantizado hoy.

  • 0
    IdeaOtro

    Retos: falta meta DIARIA sostenida (15/dia x 6 dias) y recompensa POR TIEMPO (dia libre sin comision) — hoy solo hay total acumulado + N viajes sin comision

    Caso real navan-drivers (Orlando, conv 411976, tenant PRO). Su reto ACTIVO en DB: name='90 Viajes semanales es igual a 24 horas sin comision', goalType=TRIP_COUNT, targetValue=90, timeframeType=WEEKLY, startDate 2026-03-27, sin endDate, rewardType=COMMISSION_FREE_TRIPS, rewardValue=25, isActive=true. El COPY que el cliente publica a sus conductores dice: 'Completa 90 viajes en seis dias (15 diarios) y recibe DOMINGO LIBRE SIN COMISIONES: todo lo que hagas el septimo dia es 100% para ti'. DOS BRECHAS entre lo que promete el copy y lo que el modelo puede expresar (prisma/schema.prisma model Challenge + enums ChallengeGoalType/ChallengeRewardType): 1) META DIARIA SOSTENIDA: ChallengeGoalType solo tiene TRIP_COUNT y el progreso es un contador ACUMULADO sobre la ventana (ChallengeEnrollment.currentProgress vs targetValue). No existe forma de exigir 'minimo 15 viajes cada dia durante 6 dias consecutivos'. Un conductor que hace 40 el lunes y 50 el martes ya cobra el premio, aunque el resto de la semana no trabaje. Falta un goalType tipo DAILY_STREAK (target por dia + numero de dias consecutivos). 2) RECOMPENSA POR TIEMPO: ChallengeRewardType solo tiene CASH_BONUS y COMMISSION_FREE_TRIPS. No hay 'ventana de tiempo sin comision' (ej. 24 h / el septimo dia con comision 0%). El cliente tuvo que aproximarlo con 25 viajes sin comision, que no es lo mismo: el conductor los consume cuando quiera, no el dia siguiente, y 25 viajes a su ritmo declarado (15/dia) equivale a ~1.7 dias, no a 1. Falta un rewardType tipo COMMISSION_FREE_WINDOW (rewardValue = horas o dias). IMPACTO: el tenant esta comunicando a sus conductores un beneficio (dia libre) que la plataforma no entrega tal cual; el riesgo de reclamo lo absorbe el cliente. Es el mismo tenant que ya viene de dos incidentes de confianza. PEDIDO: (a) goalType con meta diaria sostenida / racha, (b) rewardType de comision 0% por ventana de tiempo. Mientras tanto se le explico al cliente la diferencia exacta y se le ofrecio alinear el copy.

  • 0
    IdeaOtro

    Aviso al admin (email + push + badge) cuando un NEGOCIO nuevo se registra y queda PENDIENTE de aprobacion

    Pedido por Antonio (Driiby, slug taxi-y-movilidad, Honduras). FLUJO ACTUAL: un negocio se registra desde la app (POST /api/mobile/business/auth/register, tambien /api/mobile/business/auth/request y /api/business-portal/auth/request). Si el tenant tiene businessRequiresApproval=true (default), el Business se crea con status=PENDING y el usuario ve la pantalla 'tu negocio esta en revision'. Verificado en codigo: NO se dispara NINGUNA notificacion al operador — ni email (no existe triggerEvent en src/lib/email/catalog.ts), ni push, ni badge en el dashboard. El registro queda en silencio hasta que el admin entra por su cuenta a Delivery > Negocios y filtra por estado Pendiente. IMPACTO: negocios que se dan de alta con ganas quedan dias en revision porque el operador no se entera. Es el equivalente al push de 'registro completado' que si existe para conductores. PEDIDO (3 piezas, se pueden entregar por partes): 1. Email al admin/es de la empresa: 'Nuevo negocio pendiente de aprobacion: <nombre>' con link directo a su ficha. Nueva entrada en el catalogo de emails, on/off por tenant. 2. Push al admin (mismo evento). 3. Badge/contador de PENDIENTES en el menu Delivery > Negocios del dashboard (igual que el contador de conductores pendientes que pidio Dtour en cmrw94gpx) — asi se ve sin depender del correo. OPCION RELACIONADA YA EXISTENTE: businessRequiresApproval=false (systemFieldOverrides) auto-aprueba los negocios al registrarse; sirve para quien no quiere revisar, pero NO resuelve a quien SI quiere revisar y necesita enterarse.

  • 0
    IdeaOtro

    Oferta al conductor: no avisa que el viaje trae CUPON aplicado (la empresa cubre la diferencia) — en modo contraoferta el conductor ve un monto bajo y rechaza

    Reportado por Dtour Taxi (slug dtour, Peru, modo OFERTA/contraoferta tipo inDrive, comision 0%). HOY: en notifyDrivers (src/app/api/mobile/rider/trips/request/route.ts ~L2517) driverFacingFare = estimatedFare - couponDiscount, o sea la tarjeta de oferta le muestra al conductor EXACTAMENTE lo que el pasajero va a pagar, ya con el cupon descontado. Fue un fix intencional (bug cmqbx9m70, diluo) para que conductor y pasajero vean el mismo numero. PERO no hay ninguna etiqueta ni aviso de que ese monto viene rebajado por un cupon. CONSECUENCIA (caso Dtour): pasajero pide con tarifa estimada S/6, cupon 50% = S/3. El conductor ve el neto y piensa que el pasajero paga muy poco -> rechaza el viaje. En modo contraoferta es critico porque el conductor decide con ese numero en pantalla. OJO: el dinero del conductor SI esta protegido en liquidacion (complete-trip.ts: comision sobre calculatedFare completo, couponCompanyAbsorption contra companyNetTake y si queda negativo se acredita EARNING en la billetera del conductor). El problema es 100 por ciento de VISIBILIDAD en el momento de aceptar. PEDIDO: en la tarjeta de oferta del conductor (y en el detalle del viaje), cuando couponDiscount>0 y costAbsorption != DRIVER, mostrar un badge: Cupon aplicado - el pasajero paga X, la empresa cubre Y, tu ganas Z. Y que el Ganas del offer card se calcule sobre la tarifa COMPLETA (hoy se calcula sobre el fare ya descontado y subestima lo que realmente cobrara).

  • 0
    IdeaOtro

    API pública: comercio externo (tipo Oxxo) solicita repartidor vía API key

    Lead David (Villavicencio, conv 385243) quiere que un comercio externo con su propia app/web (ejemplo Oxxo) dispare por API un repartidor de su flota CabGo al concretar una venta (deliver-only) y registre la venta. Base ya existe: BusinessApiKey (/api/b2b/clients/[id]/api-keys) + merchant-initiated DELIVER_ONLY (/api/mobile/business/delivery-request). Falta endpoint público documentado que acepte la API key del comercio para crear la solicitud de repartidor.

  • 0
    IdeaOtro

    Dashboard: mostrar zonas activas al subir viaje manual (paridad con app del negocio)

    Tenant rapi2 (Pavel). Al crear un viaje manual desde el dashboard, hoy solo se ofrecen direcciones. Pide que ademas aparezcan las ZONAS ACTIVAS como opcion de origen/destino, igual que ya funciona en la App del negocio cuando solicita repartidor. Es una mejora de paridad de UX entre el flujo de viaje manual del dashboard y el flujo de solicitud de repartidor del negocio.

  • 0
    IdeaOtro

    Integración API Registro VTC España (Ministerio) — SOAP/XML + X.509

    Lead Guillermo Soto (Bizkaia, VTC, conv 423363). VTC en España debe comunicar cada servicio al Registro de Transportes en el momento de la solicitud. API Ministerio: SOAP/XML (no REST), auth por Certificado Digital X.509 (FNMT), cada peticion firmada. Metodos: altaServicio (devuelve ID+justificante firmado), modificarServicio, anularServicio, consultaServicios. WSDL/XSD + sandbox en Sede Electronica. Datos: NIF titular, matricula, NombreCliente/NIFCliente, FechaHoraInicio, Origen, Destino — ya capturados por la plataforma. Requiere scoping como desarrollo a medida. NO prometido al cliente como en desarrollo.

  • 0
    IdeaOtro

    navan-drivers (Orlando): promo 6x1 'Pide y Dale' — textos verbatim al conductor

    Orlando (navan-drivers, conv 411976, CO/PY) pidio reactivar la promo/mensajeria 6x1. TEXTO VERBATIM que dio el cliente (extraido del hilo, IN 21-jul 23:22): 1) Cuando el conductor SE GANA el 6x1, se le manda un texto que le dice: su siguiente viaje tiene un valor de 7.500 pesos en Colombia y de 11.000 guaranies en Paraguay, y que es COMPLETAMENTE GRATIS o sirve para ABONAR a una carrera de mayor valor. 2) Cuando el conductor TOMA ese viaje, se le dice: que por ayudar a fidelizar con 'Pide y Dale' tiene DOS servicios SIN pagar comision adicional (beneficio para conductor y pasajero). Contexto: un subagente previo cito un folio-id 'cmrv8b2lc' para esta spec que NO resolvia a ningun folio real (fantasma); se crea este folio real y rastreable con el texto exacto. navan-drivers = PRO/TRIAL. NO prometer fecha; avisar por chat al liberar.

  • 0
    IdeaOtro

    ARGENT (seven): splash limpio con logo sobre color de marca + pantalla de bienvenida/onboarding

    Cliente Temistocles (conv 418800, FULL) aprobo la recomendacion. Pide: (1) SPLASH LIMPIO = quitar el afiche de marketing actual del splash (splashImageUrl marketing webp) y dejar solo su LOGO sobre el color de marca #094ace, apertura rapida. Ya se aplico splashMinDurationMs 10000->3000 (splashBackgroundColor sigue #ffffff, revisar si se quiere #094ace). Falta el asset de splash logo-only y compilar. (2) PANTALLA DE BIENVENIDA / ONBOARDING al abrir por primera vez, donde SI se lea con calma el contenido del afiche: sus 3 servicios, eslogan y sellos de tiendas. Es dev/build-time. NOTA: la salida a Google Play sigue bloqueada por el critico cmruwfebx (builds 1.0.41-1.0.61 no llegan a produccion, todo en alpha). No prometer fecha.

  • 0
    IdeaOtro

    cibao-taxi- (Laura): recuperacion del viaje del conductor tras perder senal (rehidratar desde el estado del pasajero) + buffer offline de recorrido

    cibao-taxi- (Laura, LA IMPERIAL, conv 404167). Criterio de su navegacion propia, respondido por ella el 21/07 19:52 tras pedirselo explicitamente. Es el aporte que mas nos sirve porque es lo unico que nos mostro que NO tenemos resuelto. CRITERIO DE ELLA — RECALCULO POR DESVIO: - No usa umbral de metros: en cuanto hay desvio (o el pasajero confirma un cambio de ruta/destino), el GPS del conductor se re-encamina AUTOMATICAMENTE a la nueva direccion, tomando la PRIMERA SALIDA disponible que muestre el GPS. - Regla rectora: siempre la RUTA MAS RAPIDA, no la mas corta ni la original. CRITERIO DE ELLA — PERDIDA DE SENAL (lo mas interesante): - Si el conductor pierde senal, el viaje NO se cae: las apps de PASAJERO y ADMINISTRADOR siguen en tiempo real. El conductor puede incluso salir de la app y recorrer el viaje por otro medio. - Cuando el conductor recupera senal (o reinicia la app), su app RECONSTRUYE el viaje completo a partir del estado en tiempo real de la app del PASAJERO: lo que ve el pasajero es lo que se le re-activa al conductor, y siguen en conjunto. - O sea: la fuente de verdad durante la caida del conductor es el par pasajero+admin, y el conductor se re-sincroniza contra ella al volver. LO QUE TENEMOS HOY (verificado en codigo): - Navegacion: NO tenemos navegacion propia. apps/cabgo/lib/features/driver/rides/screens/active_ride_screen.dart abre Google Maps / Waze por deep link (_openWaze, https://waze.com/ul?...&navigate=yes) o dibuja el mapa heading-up, pero el giro a giro y el recalculo viven FUERA de nuestra app. No hay criterio de recalculo propio porque no hay motor propio. - Reconexion: apps/cabgo/lib/core/services/realtime/realtime_service.dart si tiene auto-reconnect con backoff acotado (max 30s), re-suscripcion de canales y banner de inestabilidad (anclas cmqk04558, balam 2026-06-03). Eso cubre el socket. - PERO no existe ninguna cola/buffer offline: grep de offlineQueue / pendingLocations / bufferedLocation / retryQueue en apps/cabgo/lib -> 0 resultados. Lo que ocurre mientras el conductor esta sin senal no se guarda ni se reenvia. - Y no existe el mecanismo que ella describe: reconstruir el viaje del conductor desde el estado en tiempo real del pasajero al reconectar. PROPUESTA (2 piezas separables): 1) RECUPERACION DE VIAJE TRAS CAIDA DEL CONDUCTOR: al reconectar (o al reabrir la app con un viaje activo), rehidratar la pantalla de viaje desde el estado autoritativo del backend/pasajero — etapa actual, paradas cumplidas, distancia acumulada — en vez de depender de lo que el conductor tenia en memoria. Complementa el reconnect de Centrifugo, que hoy recupera el socket pero no el ESTADO del viaje. 2) BUFFER OFFLINE DE RECORRIDO: guardar localmente los puntos GPS mientras no hay red y reenviarlos al recuperar senal, para que el trazo y la distancia del viaje no queden con un hueco (hoy no existe nada). 3) (largo plazo, si algun dia se evalua motor propio) Criterio de recalculo de Laura: sin umbral de metros, re-encaminar a la primera salida disponible priorizando SIEMPRE la ruta mas rapida. Aporte de producto de Laura, programadora y duena de LA IMPERIAL (NY/RD). Colabora con nosotros (opcion B). Es su 9no aporte.

  • 0
    IdeaOtro

    cibao-taxi- (Laura): pantalla de REFERIDOS in-app con codigo QR compartible (WhatsApp/Mensaje/Correo + Guardar QR) para conductor y pasajero

    cibao-taxi- (Laura, LA IMPERIAL / Cibao Taxi, conv 404167). Video 21/07 19:25 revisado frame por frame (40s, 40 frames con ffmpeg). LO QUE MUESTRA SU APP: - En el PERFIL DEL CONDUCTOR (tab Perfil, junto a Notificaciones / Contactos de emergencia / Seguridad) hay una entrada PREFERENCIAS > "Referidos - Comparte tu QR y gana" con icono de regalo. - Al abrirla: hoja "Mi codigo de referido - Comparte y gana beneficios" con tarjeta "Referido por David / Codigo: david", un QR grande, y debajo "ENLACE DE DESCARGA DIRECTA https://la-imperial-taxi.com/downlo..." con boton de copiar. - Tres botones de canal EXPLICITOS: WhatsApp (verde) / Mensaje (SMS) / Correo. Mas abajo: "Guardar QR" (descarga la imagen al telefono) y "Mas opciones" (share sheet del sistema). - Nota al pie: "El QR y enlace llevan directamente a la descarga de la app. Tus referidos quedaran registrados con tu nombre" = atribucion automatica al escanear. - En audio ella aclara que el mismo QR personal existe para CONDUCTOR y para PASAJERO. LO QUE TENEMOS HOY (verificado en codigo, hasta el punto de uso): - Pasajero: apps/cabgo/lib/features/rider/profile/screens/promotions_screen.dart -> muestra el referralCode en texto, boton copiar, y un unico boton "Compartir mi codigo" que arma https://<dominio>/ref/<code> y abre el share sheet generico (SharePlus). NO hay imagen QR, ni canales explicitos, ni guardar imagen. - Conductor: apps/cabgo/lib/features/driver/my_group/screens/my_group_screen.dart (Mi grupo, driver->driver MLM, solo si driverGroupReferralEnabled) -> codigo + copiar + Share.share. Tampoco QR. - Conductor: features/driver/passenger_invites (invitacion 1-a-1 con link unico por pasajero) -> tambien share sheet, sin QR. - QR nativo SOLO existe en el DASHBOARD del dueno: share-app-dialog.tsx del app-builder (folio cmr52pjpd, RELEASED). Es el QR de descarga de la EMPRESA, no el QR PERSONAL con codigo de referido de cada usuario. - No hay ninguna dependencia de generacion de QR en el app Flutter (0 usos de qr_flutter/QrImageView en apps/cabgo/lib). PROPUESTA: 1) Renderizar el QR del deep link de referido dentro de la pantalla de referidos (pasajero) y de Mi grupo / perfil (conductor), usando el link que ya existe: https://<dominio>/ref/<code>. 2) Botones de canal explicitos WhatsApp / SMS / Correo ademas del share sheet. 3) "Guardar QR" -> exportar el QR como imagen a la galeria (para imprimirlo o pegarlo en el auto). 4) Mostrar visible el enlace de descarga directa + boton copiar, y la leyenda de atribucion. 5) Entrada de menu "Referidos" en el perfil del conductor (hoy solo aparece como "Mi grupo" y depende del flag MLM). Aporte de producto de Laura (programadora, dueña de LA IMPERIAL, NY/RD). Eligio colaborar (opcion B).

  • 0
    IdeaOtro

    Recibo del viaje en PDF descargable (por viaje y reporte del historial) - hoy el boton 'Descargar PDF' muestra 'proximamente'

    Aporte de Laura (conv 404167) mostrando su app LA IMPERIAL. En 'Mis Viajes' del pasajero tiene: (a) boton 'Reporte PDF' arriba que exporta TODO el historial, (b) boton 'PDF' por cada viaje, junto a 'Repetir viaje', y (c) tarjetas de resumen (viajes completados, total gastado, rating dado). VERIFICADO EN NUESTRO CODIGO: apps/cabgo/lib/features/rider/receipts/screens/receipt_detail_screen.dart:51 tiene el boton 'Descargar PDF' pero al tocarlo solo muestra el snackbar l10n.pdfDownloadComingSoon. O sea: el recibo existe en pantalla, la descarga en PDF no. Tampoco hay export del historial completo. (Repetir viaje SI existe: history_screen.dart _rebookTrip.) PEDIDO: 1) cablear el boton 'Descargar PDF' del recibo a un PDF real (ya existe src/app/api/receipts/generate); 2) agregar 'Reporte PDF' del historial del pasajero con el resumen de gasto del periodo. Util sobre todo para pasajeros corporativos y comprobacion de gastos. --- _Reported via AI agent: AI agent - Chatwoot conv 404167 (Laura / cibao-taxi-)_

  • 0
    IdeaOtro

    Conductor: BLOQUEAR PASAJERO al cerrar el viaje (lista negra propia del conductor) - aportado por Laura, cibao-taxi-

    Aporte de Laura (conv 404167) mostrando su propia app LA IMPERIAL en video. Al finalizar el viaje, la pantalla de cierre del conductor ofrece, ademas de la calificacion del pasajero y 'Reportar un problema', un boton 'Bloquear pasajero': el conductor deja de recibir solicitudes de esa persona. VERIFICADO EN NUESTRO CODIGO: no existe nada equivalente. grep de blockPassenger / blockedPassenger / blockRider en apps/cabgo/lib, src y prisma/schema.prisma devuelve 0 resultados. Si tenemos rateCustomer (el conductor califica al pasajero en ride_complete_screen.dart) y 'Reportar un problema' del lado pasajero, pero no lista negra del conductor. PEDIDO: permitir que el conductor bloquee a un pasajero desde el cierre del viaje (y verlo/deshacerlo en su perfil), para que el matching no le vuelva a ofrecer ese pasajero. Deseable: que el admin vea los bloqueos en el panel. Detalle del video (para contexto): pantalla de cierre con minimapa del recorrido real, importe cobrado, estrellas, comentario opcional, 'Reportar un problema' y 'Bloquear pasajero'. --- _Reported via AI agent: AI agent - Chatwoot conv 404167 (Laura / cibao-taxi-)_

  • 0
    IdeaOtro

    Suscripcion del conductor: cobrar con TARJETA directo desde la app (paidVia CARD_*) - hoy responde 501 CARD_NOT_IMPLEMENTED

    Pedido de David Martinez (Yendo, demo-rayo-taxi-8a90688a, Rivera/Uruguay, conv 423017): 'quedaria mas practico con tarjeta, que la app ya registre el pago y le de la suscripcion'. Modelo de negocio: el conductor paga cuota fija en vez de comision. ESTADO VERIFICADO EN CODIGO: - La suscripcion de conductor SI existe: categoria driver_online, SubscriptionPlan por tenant, pantalla apps/cabgo/lib/features/driver/subscription/screens/my_subscription_screen.dart y endpoints GET /api/mobile/driver/subscription + POST /api/mobile/driver/subscription/renew. - El renew acepta paidVia: WALLET | CARD_STRIPE | CARD_MP | CARD_DLOCAL, pero src/app/api/mobile/driver/subscription/renew/route.ts linea ~93 devuelve 501 con code CARD_NOT_IMPLEMENTED para los tres CARD_*: 'El pago con tarjeta llega en la proxima version. Usa tu saldo del wallet por ahora.' El comentario del archivo lo marca como Phase 4 pendiente. - Hoy el camino real es de 2 pasos: el conductor recarga wallet con tarjeta (gateway tokenizable del tenant) y luego renueva la suscripcion desde la app debitando del wallet, con extension automatica (createOrExtendSubscription). PEDIDO: cerrar la Phase 4 para que el boton de la suscripcion cobre la tarjeta guardada en un solo paso y active/extienda la suscripcion al confirmar el pago, sin pasar por el wallet. NOTA DE CONFIG: en este tenant CompanySettings.subscriptionsEnabled = false y no hay SubscriptionCategory driver_online ni planes creados; se le ofrecio dejarlo armado en cuanto defina monto y periodicidad (moneda UYU). --- _Reported via AI agent: AI agent - Chatwoot conv 423017 (David Martinez / Yendo)_

  • 0
    IdeaOtro

    Borrar un servicio es destructivo e irreversible (se lleva sus tarifas por zona) — falta soft-delete o confirmacion

    teo-154a (Victor, PRO) borro por error el servicio Sedan desde el panel el 2026-07-21 ~17:23 UTC y pidio restaurarlo. El borrado hace prisma.serviceType.delete() en duro: cascade elimina ServiceTariff, ZoneServiceConfig (incluida su tarifa propia de 1.5/km en la zona Piura) y DriverServiceType, y deja los Trip historicos con serviceTypeId huerfano (este tenant ya acumula 4 ids huerfanos con 188 viajes). No hay ActivityLog del borrado, no hay papelera, no hay forma de reconstruirlo salvo que alguien haya leido la config antes. Se restauro a mano desde la memoria de la conversacion + la plantilla DefaultServiceType; el campo offerFareStep no se pudo recuperar (ademas /ai-agent/services no lo acepta en su schema). Propuesta: (1) soft-delete con restauracion desde el panel, o al menos (2) modal que advierta que se pierden las tarifas por zona y sugiera desactivar en vez de borrar, y (3) ActivityLog con snapshot del ServiceType + sus ZoneServiceConfig al borrar.

  • 0
    IdeaOtro

    Catalogo: campo de codigo de barras / SKU por producto + busqueda y escaneo por codigo (farmacias y minimarkets)

    Pedido del cliente (conv 423202, 2026-07-21): 'al ingresar una farmacia o minimarket son productos con codigo de barra, si tiene esa opcion para que cuando llega un pedido el encargado de la farmacia o minimarket busque los productos por codigo de barra'. ESTADO ACTUAL VERIFICADO (2026-07-21) — no existe nada de esto: 1) Modelo BusinessProduct (prisma/schema.prisma:8576) no tiene sku/barcode/ean/upc. Campos: id, businessId, categoryId, name, description, imageUrl, price, discountPrice, isAvailable, commissionRate, driverPerPlateBonusEligible, order, prepTimeMin. Tampoco existe modelo de inventario/stock (solo el booleano isAvailable). 2) No hay escaneo de codigo de barras en la app: apps/cabgo/pubspec.yaml solo trae camera y google_mlkit_face_detection; no hay mobile_scanner / barcode_scan2 / mlkit_barcode. 3) La importacion masiva de catalogo no acepta columna de codigo: src/lib/services/bulk-product-import/parse-structured.ts, ScalarField = name | description | price | discountPrice | categoryName | imageUrl. Cualquier encabezado tipo SKU/codigo se descarta en silencio. 4) No hay busqueda por codigo: src/app/api/mobile/rider/delivery/search/route.ts:100-103 busca por name/description; src/app/api/dashboard/delivery/businesses/[id]/products/route.ts:48-49 igual; GET /api/mobile/business/products ni siquiera tiene parametro de busqueda. ALCANCE PROPUESTO: campo sku/barcode en BusinessProduct (+ ProductImportItem), alias de encabezado en el importador, rama de busqueda por codigo exacto en el buscador del negocio, y (fase 2) escaneo con camara en el panel del comercio para el picking del pedido. POR QUE IMPORTA: desbloquea las verticales farmacia y minimarket, donde el catalogo es de miles de SKUs y el picking se hace por codigo, no por nombre. Mientras tanto el workaround es meter el codigo dentro del nombre o la descripcion del producto (ambos son buscables por texto en el panel). --- _Reported via AI agent: AI agent — Chatwoot conv 423202 (yevapp / Yevfood)_

  • 0
    IdeaOtro

    Conductor edita la ruta EN VIVO desde su app (cambiar recogida / agregar paradas) con recalculo automatico de tarifa y sync en tiempo real a pasajero y despacho

    Sugerencia de Laura (tenant cibao-taxi-, Rep. Dominicana, conv 404167). Mando un VIDEO de su propia app de taxi mostrando el flujo que propone. Revisado frame por frame: 1) Viaje EN CURSO en la app del CONDUCTOR. Panel inferior con boton "Editar ruta" (y chip "Parada" sobre el mapa) mientras el estado es "Hacia destino final". 2) Al expandir "Editar ruta": tarjetas RECOGIDA y DESTINO, cada una con lapiz para editarlas en vivo, mas botones "Agregar" (parada) y "Buscar direccion". El buscador abre overlay "CAMBIAR PUNTO DE RECOGIDA" con autocomplete. 3) Cambia la recogida a "Catskill Avenue 650 Copiague" y agrega "PARADA 1 = Straight Path Copiague" (tarjeta reordenable y eliminable). 4) Recalculo automatico visible: "RUTA POR CARRETERA calculada con GPS real (OSRM)", distancia 2.27 mi -> 3.01 mi, y bloque "PRECIO ACTUALIZADO: Precio original $5 -> $6 (+$1.00 extra)" con nota "las millas adicionales por paradas/modificaciones incrementan el precio final". 5) Boton "Guardar cambios de ruta" -> chip en mapa "Ruta actualizada", el estado pasa a "Hacia parada 1 de 1" y aparece la CTA "Parada 1 completada -> Ir al destino". En el itinerario la parada cumplida queda tachada. 6) Todo con TAXIMETRO en vivo por GPS corriendo en paralelo, con el total ya sincronizado al precio nuevo. Laura remarca por escrito que en su implementacion las TRES superficies se sincronizan en tiempo real: si el cambio lo hace el conductor se refleja al instante en la app del pasajero y en el despacho, y viceversa. Complementa la idea ya registrada cmruuf82e (despacho edita ruta con conductor en servicio activo): esto es la contraparte del lado CONDUCTOR, mas el recalculo de tarifa transparente y el manejo de estados de parada. Referencia visual: video del cliente en la conversacion 404167.

  • 0
    IdeaOtro

    Bot WhatsApp: auto-asignar ServiceType por modo (Viaje/Pedido) sin menu — rapi2

    Pedido de Pavel (rapi2, conv 384594). Con enableOrderMode + serviceFirst activos, al elegir "Un viaje" el bot SIEMPRE abre el menu de tipos de servicio (maybeStartServiceFirstFlow, src/app/api/webhooks/whatsapp/route.ts:797). El cliente quiere que "Un viaje" asigne directo Moto Ride (e152b036-1734-49b0-be0b-e314a28a6994) y "Un pedido" asigne directo Envios Rapi2. (76d7b310-6493-4dd7-a05f-4e153864f9e5), sin paso extra. Verificado: hoy NO existe config para esto. resolvedServiceTypeId solo se autorresuelve cuando el tenant tiene UN SOLO ServiceType activo (route.ts:1960-1975); rapi2 tiene 3 activos. El branch request_order (route.ts:1116) pone tempServiceTypeId=null explicitamente. Propuesta: dos claves nuevas en flowConfig (tripModeServiceTypeId / orderModeServiceTypeId) expuestas por PATCH /api/ai-agent/whatsapp-flow-config, que fijen tempServiceTypeId al entrar al branch y salten el menu de servicios cuando esten seteadas. Sin ellas, comportamiento actual intacto. --- _Reported via AI agent: AI agent — Chatwoot conv 384594 (Pavel / rapi2)_

  • 0
    IdeaOtro

    Mapa del panel: icono de carrito (vehiculo) para los conductores en vez del pin de gota

    Cita textual de la clienta (conv 404167, 2026-07-21): "Tambien poder colocar carritos en vez de punto a los conductores. Para que se vea mas atractivo". Estado verificado: en src/app/(dashboard)/dashboard/trips/live/live-trips-client.tsx el marcador de conductor usa un SVG path de pin de ubicacion (gota) coloreado por estado (driverMarkerColors). Ya se le agrego etiqueta con nombre/placa y color por estado, pero la FORMA sigue siendo un pin, no un vehiculo. Pedido: icono de auto/moto segun el tipo de vehiculo del conductor (idealmente rotado segun heading) en el mapa de Viajes en vivo. --- _Reported via AI agent: AI agent - Chatwoot conv 404167 (Laura, Taxi Centroamericanos)_

  • 0
    IdeaOtro

    Despacho: agregar y modificar paradas/ruta desde el panel con el viaje en curso

    Cita textual de la clienta (conv 404167, 2026-07-21): "Creo que tambien pueden arreglar el sistema de que los despacho puedan agregar o modificar las rutas cuando un conductor esta en servicio activo y tambien los usuarios puedan agregar paradas una ves el viaje inicia". Caso de uso: la operadora/despachadora recibe una llamada del pasajero ya en ruta ("pasame primero por X", "cambiame el destino") y hoy no puede tocar el viaje desde el panel. Estado verificado en codigo: - El pasajero SI puede agregar paradas con el viaje IN_PROGRESS (POST /api/mobile/trips/[id]/stops, STOP_ADDABLE_STATUSES incluye IN_PROGRESS). Ese punto ya existe. - El endpoint de despacho existe (POST /api/trips/[id]/stops, sesion NextAuth, misma lista de estados) PERO no hay NINGUNA UI en el dashboard que lo consuma: grep de "/stops" en src/app/(dashboard) y src/components no devuelve nada. La operadora no tiene boton. - MODIFICAR o eliminar una parada ya creada, o cambiar el destino final del viaje en curso, NO existe en ningun rol: /api/mobile/trips/[id]/stops/[stopId] solo hace progresion de estado (arrive/depart/skip), no edita direccion. No hay endpoint de cambio de destino. Pedido: (1) UI en Viajes en vivo para que despacho agregue paradas al viaje activo (el endpoint ya esta), (2) editar/eliminar parada y cambiar destino final con recalculo de tarifa. --- _Reported via AI agent: AI agent - Chatwoot conv 404167 (Laura, Taxi Centroamericanos)_

  • 0
    IdeaOtro

    QR / deep-link directo al menu de UN negocio (mesa de restaurante)

    Wilson Camacho (Veci Delivery, conv 381909) pregunta si escaneando un QR se puede ir directo a la web y ver el menu de un restaurante concreto. Hoy NO existe: el QR de Compartir mi app (share-app-dialog / /api/apps/share-link) apunta a la app completa (Play/App Store o web.cabgo.app/?company=slug) y el usuario cae en la LISTA de negocios. La ruta /rider/delivery/business/:businessId existe y esta permitida en modo visitante (app_router.dart:288), pero un enlace en frio cae en el login: AuthGuest solo se activa con el boton manual Continuar como visitante (social_login_buttons.dart), no desde la URL. PEDIDO: soportar deep-link publico por negocio (ej. web.cabgo.app/?company=<slug>&business=<id>) que entre en modo visitante automaticamente y abra el menu de ese negocio, mas un boton QR de este negocio en el dashboard de Negocios para imprimirlo en mesa. Caso de uso muy comercial: QR en mesa -> menu digital -> pedido.

  • 0
    IdeaOtro

    Deposito de registro del conductor configurable (billetera)

    Tu Conductor RD (demo-rayo-taxi-696e2379, Manuel Perez Chala, conv 422089) opera asi: cada taxista deposita RD$500 para entrar y de ahi se le descuenta 12% por servicio. Hoy la comision (commissionRate=0.12) y el bloqueo por saldo (walletRestrictionEnabled=true + maxDriverDebt=0) SI son config y ya quedaron aplicados, pero el deposito inicial de registro NO existe como campo: el operador debe acreditar el saldo a mano desde el panel al ver el comprobante bancario. Pedido: monto de deposito/registro configurable por tenant que se exija o se registre al alta del conductor, para que el saldo inicial no dependa de un paso manual. Prioridad baja: el flujo manual ya cubre el caso.

  • 0
    IdeaOtro

    Cliente migrado de Apphive: el panel nuevo le resulta MENOS intuitivo que el legacy (precios, zonas, cupones, postulacion de conductor, compartir viaje)

    Feedback textual de Daniel (STAF, Lima Peru, conv 390056, tenant demo-rayo-taxi-379eb2e0), cliente legacy de Apphive reactivado con cupon LEGACY-STAF-300. Cita 1 (2026-07-20): "pero no se entiende bien, podria explicarme por favor, antes podia entrar a cada app y era mas intuitiva creo yo, ahora intento ver el tema de configurar los precios y no veo donde, tampoco la zonas, la generacion de codigos de descuento y mas, tampoco para ingresar y postular como conductor y en el app pasajero no veo como compartir mi viaje". Cita 2 (2026-07-21): "muy aparte del app la cual sigo indagando ya que a mi parecer la antigua version era mas intuitiva". Puntos concretos que no encontro solo en el dashboard: (1) configurar precios/tarifas, (2) zonas, (3) codigos de descuento/cupones, (4) donde postularse como conductor, (5) compartir viaje en la app del pasajero. IDEA: onboarding guiado / buscador de ajustes dentro del dashboard y accesos directos visibles a Tarifas, Zonas y Promociones para los clientes que llegan del panel legacy de Apphive. Es un patron repetible: toda la ola apphive-reactivacion aterriza en el mismo panel.

  • 0
    IdeaOtro

    [TAREA ISA — D18] Correo de soporte por tenant: definir campo supportEmail + editor en panel

    Decision D18 (Jonatan 2026-07-20). Contexto: los correos white-label a conductores (fix ya deployado, PR #273) dejaron el contacto como responde este correo porque NO existe un correo de soporte por tenant. Tarea de Isa: definir e implementar Company.supportEmail (campo + editor en el panel del tenant + validacion), y decidir que se muestra en el pie del correo cuando el tenant lo configura. Coordinar con la tarea de Jose (envio desde dominio propio) para que el remitente y el correo de soporte sean coherentes. Referencia: cmrramshk (super/Lima, FULL). --- _Reported via AI agent: Loop tecnico cabgo — batch D18 de Jonatan_

En progreso

18
  • 3
    BugApp móvil

    NO INICIA EL LAUNCHER.

    SIGUE APARECIENDO DIRECTAMENTE EN LA PANTALLA DE TAXI

  • 1
    IdeaOtro

    Documentacion sobre seguridad de la app

    Un cliente me pregunto sobre el nivel de seguridad que tiene la aplicacion, busque en la documentacion pero no encontre ningun apartado donde hable sobre la seguridad a nivel de desarrollo que tiene la App, algo como que garantice que no sea vulnerable ante hackeos, los clientes siempre les interesa saber eso.

  • 0
    BugOtro

    email.mail.apphive.io sirve un certificado de mailgun.org — todo cliente que abre un link de nuestros correos ve pantalla roja de sitio no seguro

    ## Sintoma El subdominio de tracking de correos **`email.mail.apphive.io`** presenta un certificado TLS emitido para **`mailgun.org`**, sin ningun SAN que cubra nuestro dominio. Verificado en vivo: ``` subject = CN = mailgun.org issuer = Let's Encrypt X509v3 Subject Alternative Name: DNS:mailgun.org ``` Como el nombre no coincide con el host, el navegador corta la navegacion con la interstitial roja de **sitio no seguro** (`NET::ERR_CERT_COMMON_NAME_INVALID` o equivalente). ## Por que importa Los links de nuestros correos de compilacion pasan por ese subdominio de tracking. Es decir: **cualquier cliente que reciba un correo nuestro y haga clic en el enlace de su build ve una pantalla roja que le dice que el sitio no es seguro**, con nuestro nombre encima. No es un caso aislado de un tenant: **afecta a todos**. Y ocurre justo en el momento mas delicado — el cliente esta intentando descargar su app por primera vez. El impacto real de confianza es alto: un cliente reporto textualmente que **no se atreve a pasarle ese enlace a sus conductores** por los avisos que aparecen. Es decir, el defecto no solo asusta: esta bloqueando distribucion. ## Como se detecto Un cliente (Eric, Pana Taxi, conv 423043) mando capturas de las advertencias que le salen al abrir el APK desde el correo. Al revisarlas se vio que una era el aviso estandar de Chrome por instalar fuera de Play (esperable y explicable), pero **la otra era nuestra**: el error de certificado del dominio de correo. ## Arreglo Configurar el tracking domain en Mailgun con su propio certificado para `email.mail.apphive.io` (Mailgun soporta HTTPS en tracking domains con certificado propio), o desactivar el tracking de clics para que los enlaces salgan directos al destino final sin pasar por ese host. Mientras no se arregle, conviene evitar mandar por correo los enlaces de descarga criticos y entregarlos por chat. ## Origen Detectado y verificado por la terminal Support en el loop de barridos /sweep, 24-jul-2026.

  • 0
    BugOtro

    delivery-go (GeoTaxi Pro): la ventana de Google del login web dice Cabgo (consent/account-chooser) — Firebase/OAuth web por-tenant, pieza c de cmrj5ikqx

    EVIDENCIA NUEVA del cliente (video conv 401633, 23-jul 04:09 UTC, analizado frame a frame): geotaxipro.com carga v1.10.835 con marca GEOTAXI correcta y boton Continuar con Google restaurado (hideGoogleLogin=false aplicado a su pedido). Al tocar el boton, accounts.google.com muestra Elige una cuenta / Ir a Cabgo / Antes de usar Cabgo revisa su Politica de Privacidad — la etiqueta Cabgo dentro de la ventana de Google. CAUSA (ya diagnosticada en internalNotes de cmrj5ikqx): el login web usa el proyecto de auth de PLATAFORMA (cabgo2-app.firebaseapp.com; meta google-signin-client_id 629906511408 en apps/cabgo/web/index.html:313), pese a que el tenant tiene Firebase propio geotaxi-533a3. Incluye tambien los enlaces legales del consent apuntando a cabgo.app. cmrj5ikqx se cerro RELEASED con esta pieza anotada como cola (piezas b y c); el cliente FULL lleva ~1 mes pidiendo el des-branding completo y ahora reporta ESTA superficie explicitamente con video. Se le respondio honesto: login funcional, solo se filtra el nombre; sin fecha prometida; se le avisara al quedar. Alcance del fix: Firebase web por-tenant (authDomain + client id por dominio) [M].

  • 0
    BugOtro

    pedimos-algo: logo del tenant SOBREESCRITO sin accion del cliente — build iOS 1.0.51 en revision de Apple con icono generico azul "go"

    EVIDENCIA (verificada 22-jul): 1) Cliente Alejandro (conv 412401, appPlan=PRO) reporta que el icono de su app cambio SOLO al actualizar por TestFlight — el NO subio ningun logo. Su captura de TestFlight muestra la 1.0.51 (52) con un icono AZUL/periwinkle con "go" y carita (logo generico tipo CabGo), NO su marca. 2) El icono se hornea en build con el logo del panel. Build iOS 1.0.51: creada 2026-07-21 23:06 UTC, SUCCESS, subida a TestFlight 23:37 UTC, hoy Waiting for Review en Apple. => al momento de compilar, el blob del logo contenia el logo azul generico. 3) Company.logoUrl NO cambio desde 2026-06-17 (misma URL .../logos/aca7fa8a-1d40-45ca-830b-04b0e9e002d2/logo.png) — el CONTENIDO del blob fue sobreescrito in-place. last-modified actual del blob: 2026-07-22 20:49:06 GMT; contenido actual = logo CORRECTO (P naranja PEDIMOS ALGO 512x512 con cajita verde). O sea: entre la build del 16-jun (icono correcto) y la build del 21-jul 23:07 UTC alguien/algo escribio el logo generico azul en el blob del tenant, y hoy 20:49 UTC volvio a escribirse el correcto. PEDIDOS: A) INVESTIGAR que proceso escribio el blob de logo del tenant sin accion del dueno (¿seed/provisioning/default re-upload? ¿otro flujo que pisa logos/<id>/logo.png?). Un logo de tenant que cambia solo es grave — puede estar pasando a mas tenants. B) RE-DISPARAR build iOS de pedimos-algo con el logo correcto (ya restaurado en el blob) y REEMPLAZAR la 1.0.51 Waiting for Review, para que la app NO se publique con el icono azul generico. Se le prometio aviso cuando quede. C) Revisar si Android necesita lo mismo (ultima build Android 1.0.57 del 16-jun, previa a la corrupcion — probablemente sana).

  • 0
    IdeaOtro

    Colectivos: habilitar cobro anticipado PREPAID (retencion en billetera hasta confirmar abordaje) — hoy el stub devuelve 501

    Pedido de Oscar Belizario / BELI GO (conv 421587): billetera virtual donde el pasajero recarga y paga desde la app, y el dinero queda RETENIDO hasta que el conductor confirma el abordaje y el servicio se completa. Objetivo del cliente: reducir pedidos falsos y evitar efectivo en el viaje. Estado actual: collectivePaymentMode acepta IN_PERSON | PREPAID (src/lib/services/collective/collective-service.ts:47), pero el cobro PREPAID es un STUB: collective-charge.ts:32 define NOT_ENABLED = "PREPAID stub — habilitar en sub-fase 5e" y captureSeatBooking LANZA. En src/app/api/mobile/rider/collective-bookings/route.ts:195-205 la reserva se crea, el cobro falla, se borra la reserva y el pasajero recibe 501 "El cobro anticipado (PREPAID) aun no esta habilitado". Si un tenant pone PREPAID, NINGUN pasajero puede reservar asiento. Pedido: (a) completar la sub-fase 5e (captura al reservar + retencion + liberacion/no-show) y (b) mientras tanto, que el panel advierta/bloquee PREPAID porque hoy mata la operacion en silencio. Mitigacion aplicada: la demo de BELI GO quedo en IN_PERSON y se le informo al cliente de frente que la retencion en billetera para colectivos aun no esta habilitada.

  • 0
    IdeaOtro

    Cupon de bienvenida no se auto-aplica: la tarjeta en Promociones no tiene boton Canjear y el pasajero debe copiar/pegar el codigo

    Reportado por CarVip (cupon BIENVENIDA, NEW_USERS, CLP 3.000 fijo). El dueno pregunta si un cupon de bienvenida se aplica solo o si el pasajero debe ponerlo en algun lado. Estado verificado en codigo: - coupon-engine.resolveCouponForTrip con couponCode=null SOLO auto-aplica si existe una CouponRedemption pendiente (tripId=null). Sin canje previo NO hay descuento y /mobile/rider/services tampoco devuelve priceAfterCoupon. - La app del pasajero NUNCA envia couponCode en el request de viaje (grep en trip_service.dart / ride_options_screen.dart: solo lee couponCode de la respuesta). - promotions_screen.dart lista el cupon en Promociones activas pero la tarjeta solo permite COPIAR el codigo (Clipboard) — no hay boton Canjear/Aplicar. El unico camino real es copiar el codigo y pegarlo en el campo Tienes un codigo -> Aplicar. Resultado: un cupon de BIENVENIDA para usuarios nuevos exige un paso manual de copiar/pegar que la mayoria de los pasajeros nuevos no va a hacer -> el beneficio no llega y el tenant cree que esta activo. Propuesta: 1) Boton Canjear/Activar en cada tarjeta de la lista de Promociones (llama a /promotions/redeem con ese codigo). 2) Opcion por cupon Aplicar automaticamente (sin canje) para targetAudience=NEW_USERS, de modo que el precio en el selector de servicio ya salga con descuento. 3) Que la ficha del cupon en el panel muestre al dueno el flujo real que vera su pasajero.

  • 0
    BugOtro

    REINCIDE apolo-food: sonido insistente al LOCAL no es constante (web NO suena; app suena 1 vez y repite al minuto) pese a cmruy5c5d RELEASED

    PDF de pruebas del cliente (William, conv 412412, 22/07/26). Punto 3 textual: SONIDO CONTINUO AL LOCAL Y WEB NO ES CONSTANTE; EN LA WEB NO SUENA y EN EL APP SUENA UNA VEZ Y LUEGO SUENA AL MINUTO; DEBE SER CONSTANTE PARA QUE EL LOCAL SEPA QUE TIENE PEDIDO POR ACEPTAR. Dos frentes: (a) portal web del comercio no emite sonido al llegar pedido; (b) app del comercio suena una vez y reintenta al minuto en vez de loop insistente hasta aceptar/rechazar (paridad con driverOfferInsistentSoundAndroid). cmruy5c5d se marco RELEASED y se comunico resuelto el 22/07.

  • 0
    BugOtro

    REINCIDE apolo-food: push de pedido delivery SIGUE con icono generico (al conductor Y al local) pese a cmrux4yt3 RELEASED

    PDF de pruebas del cliente (William, conv 412412, 22/07/26, detalles del app apolo 2.0 (2).pdf). Punto 1: SIGUE APARECIENDO EL LOGO GENERICO en las notificaciones push, tanto AL CONDUCTOR como AL LOCAL. El folio cmrux4yt3 se marco RELEASED y se le comunico como resuelto al cliente el 21/07. Verificar en build instalado del tenant (no solo en codigo): payload de notificacion (largeIcon/smallIcon/image por tenant) en los canales de conductor y de comercio. Reincidente: requiere verificacion end-to-end en dispositivo antes de volver a marcar resuelto.

  • 0
    BugOtro

    Taxi Up (taxi-up): app en PRODUCCION pero no aparece en buscador de Play — verificar visibilidad de ficha

    Cliente Carlos (conv 385842, PRO). App com.taxiup.usuario publicada v1.0.44 en produccion; instala bien por link directo. Reporta desde hace dias que NO aparece al buscar Taxi Up en Play (probado en varios equipos). Probablemente indexacion lenta, pero pidio verificar: confirmar en Play Console que la ficha NO tenga restringidos los paises de disponibilidad ni gating por clasificacion/contenido que la excluya de resultados de busqueda, y que este en produccion abierta (no closed testing). Reportar hallazgo para responder al cliente.

  • 0
    BugOtro

    500s a nivel framework durante ventanas de deploy (cold-start/rotacion de chunks) — evaluar Vercel Skew Protection

    Evidencia 2026-07-22: 42 eventos 500 cliente en /api/mobile/driver/status en 24h, CERO filas server-side (el logging del PR #323 esta activo y no capturo nada → el fallo ocurre ANTES del handler). Clustering: 36/42 entre 22:00-23:59Z del 21-jul = exactamente la ventana con un deploy de Vercel cada ~20 min (cola de merges fases 4-5). Firma conocida: responseBody con __next_error__ (HTML de Next), predicha como residuo en el propio PR #323. DIAGNOSTICO: cold-starts + rotacion de chunk-hashes durante deploys frecuentes hacen fallar requests in-flight a nivel framework. No es bug del endpoint; afecta a cualquier ruta bajo trafico durante deploy. MITIGACIONES a evaluar (en orden): 1) Vercel Skew Protection (feature nativa para exactamente esto — clientes viejos siguen sirviendose de su deployment); 2) mantener las colas de merges serializadas agrupando (ya lo hacemos — la frecuencia de hoy fue excepcional); 3) revisar memoria/maxDuration de las rutas mobile calientes si el cold-start es OOM. Los 42 eventos cliente quedan dispuestos como REVIEWED con esta explicacion.

  • 0
    BugOtro

    LojaVa (com.lojava.usuario): entregar certificado de upload key (.pem) para reset de clave de subida

    Joseph (conv 404662, company slug=lojava, appPlan=STARTER activo) eligio la Opcion 2: actualizar su ficha existente de Google Play (com.lojava.usuario, ya en produccion) sin espera de testers. Debe solicitar en Play Console el restablecimiento de la clave de subida; Google le pedira subir el CERTIFICADO (.pem) de la NUEVA upload key que controla el keystore de CabGo. El cliente ya lo pidio explicitamente ("me puede pasar el certificado para cargarlo"). Necesito que el equipo genere/exporte el certificado de upload key (.pem) del keystore de com.lojava.usuario y me lo comparta aqui para reenviarselo a Joseph, para que lo cargue en el flujo de reset. Build de actualizacion ya compilado y listo.

  • 0
    BugOtro

    TAXTEP (Poncho, conv 421910): tenant PRO PAGADO el 14-jul con CERO builds y CERO Play Console — 7 dias sin arrancar el pipeline

    VERIFICADO EN DB (read-only) el 2026-07-21: - Company slug demo-rayo-taxi-b78a22de ("Taxtep"), id 924646c9-39c2-4fa5-a436-052681d17081. - appPlan = PRO, appPlanPurchasedAt = 2026-07-14 15:21 UTC. O sea PAGO hace 7 dias. - SELECT count(*) FROM AppBuild WHERE companyId=... -> 0 - SELECT count(*) FROM GooglePlayConfig WHERE companyId=... -> 0 - GET /api/ai-agent/store/releases?companySlug=demo-rayo-taxi-b78a22de -> releases: [], total 0. RIESGO DE CONFIANZA: el 17-jul se le dijo al cliente por WhatsApp "en cuanto TAXTEP entre a revision de Google, te aviso por aqui mismo". No hay nada que pueda entrar a revision: no existe ni una build ni la vinculacion con Play Console. El cliente ya volvio a escribir (21-jul 21:01). PEDIDO: arrancar el pipeline de este tenant (crear GooglePlayConfig / asignar service account y disparar la primera build Android), o decir explicitamente que falta del lado del cliente (p.ej. su cuenta de Play Console) para poder decirselo con honestidad. Es un tenant PAGADO: la promesa tecnica procede segun TIER-1.

  • 0
    BugOtro

    idealo iOS: no se puede subir FOTO DE PERFIL — el selector solo ofrece imagenes/videos y la carga nunca se completa

    Reportado por AleXnadr (idealo, conv 381052) el 2026-07-21, con video. En la app iOS, al intentar subir la foto de perfil el picker solo permite elegir imagenes o videos y la carga NO se completa: la foto nunca queda guardada. El cliente lo describe como especifico de iOS (en Android funciona). CONTEXTO: es el SEGUNDO bug de iOS del mismo tenant en la misma semana — ya existe el folio cmrthy8fh de 'registro iOS con Face ID falla / Registro no completado' (mismo cliente, mismo dispositivo). Revisar si comparten causa: ambos pasan por el flujo de captura/subida de imagen (image_picker + permisos de galeria en iOS). Sospecha a verificar: falta la declaracion de permiso o el mediaType del picker en iOS, o el upload se corta sin reportar error. PEDIDO: reproducir en un iPhone real con la build actual de idealo, revisar el picker de foto de perfil (rider/driver profile) y el endpoint de upload, y confirmar si es el mismo origen que cmrthy8fh. IMPACTO: cliente con plan activo, altamente colaborativo, reportando bugs con video. Es el segundo iOS seguido — erosiona confianza en la plataforma iOS del tenant. --- _Reported via AI agent: Chatwoot conv 381052_

  • 0
    BugOtro

    PARAGUAS Apolo Food (William, conv 412412): indice unico de TODO lo pendiente del tenant, con estado verificado por commit/rama

    Folio indice pedido explicitamente por el cliente el 2026-07-21: 'puedes resumir todo lo pendiente de APOLO FOOD en un solo ticket y darme el detalle junto al numero de ticket?'. NO reemplaza a los folios hijos: cada uno sigue su curso. Este post es la vista unica para el cliente y para el equipo. ESTADO VERIFICADO POR COMMIT/RAMA (no por el flag del post), corte 2026-07-21 19:00 UTC: 1) cmruwbarm - Express del ADMIN: el buscador de direcciones no ofrece las ZONAS del tenant (paridad con el flujo del comercio). ESTADO: codigo escrito, commit 3e01cad1f en rama fix/express-address-zones. NO esta en main ni desplegado. Es cambio de panel: al mergear queda disponible sin build de app. 2) cmruy5uze - Cancelacion: en un pedido EXPRESS (FoodOrder MERCHANT_INITIATED con Trip.source=DELIVERY) el repartidor entra por active_ride_screen y ve motivos de taxi ('El pasajero no aparece'), cancelando directo sin la aprobacion del admin, pese a deliveryAdminOnlyCancelInProcess=true en apolo-food. Evidencia historica en FoodOrderStatusLog: 05-jun express cancelado por conductor; 02-jun DELIVERED->CANCELLED y COMPLETED->CANCELLED por conductor. ESTADO: codigo escrito, commit 470f1a0d6 en rama fix/delivery-trip-cancel-context. NO esta en main. Requiere merge + build nueva de la app del repartidor. 3) cmruy5c5d - Comercio: sonido INSISTENTE (loop) al llegar pedido de plataforma con la app CERRADA. Hoy el loop lo hace la app en primer plano; con la app cerrada el push sale sin la marca insistente y suena una sola vez. ESTADO: codigo escrito (re-push nag), commit 4370f7ce1 en rama feat/order-acceptance-nag. NO esta en main. 4) cmrux4yt3 - Push de PEDIDO DE DELIVERY con icono/logo generico (al repartidor le llegan dos logos distintos segun el tipo de aviso). ESTADO: codigo escrito, commit 88ec86235 en rama fix/delivery-push-branding. NO esta en main. 5) cmrujmzen - Asignacion MANUAL desde el panel: el repartidor no se entera con la app ABIERTA. El fix de notificacion ya esta en main (18c394bcd, PR #315), pero la causa raiz principal confirmada el 21-jul SIGUE ABIERTA: home_screen.dart _checkForActiveTrip() aborta antes de navegar cuando CompanySettingsCache.multiOrderEnabled == true (guard multipedido #68). apolo-food tiene deliveryBundlingEnabled=true y deliveryMaxOrdersPerDriver=3 => multiOrderEnabled=TRUE, o sea el caso de William cae exactamente ahi. Explica su reporte de que asignando desde una pantalla si llega y desde otra no. 6) cmrv0vulu - NUEVO (levantado hoy con su reporte): el repartidor puede tomar pedidos y quedar en saldo NEGATIVO pese a walletRestrictionEnabled=true + maxDriverDebt=0. Dos causas: el guard solo bloquea si YA esta en negativo (no reserva la comision del pedido) y las rutas preassign-driver + PATCH /api/trips/[id] no llaman a checkDriverCanTakeDelivery. 1 de 6 wallets del tenant en -1.88. 7) cmrusz5nh - Express del ADMIN sin solo-entrega / entregar-y-cobrar ni monto a cobrar. ESTADO: RESUELTO Y EN MAIN (fddb8f4af, PR #325). Es el unico de la lista que ya esta del lado del producto. NOTA DE ALCANCE: quedan fuera de este paraguas los folios de sus OTROS proyectos, que siguen con folio propio: cmrm8yv1d (AKA Delivery, error al descargar de Play), cmrul9zt6 (aka-delivery 1.0.117 marcada publicada pero produccion sigue atras), cmruuxgbj (icono de app aka-delivery), cmrmd7hyv (Suifty, ventana de punto de recogida no colapsable). PEDIDO AL EQUIPO: priorizar el merge de las cuatro ramas listas (1,2,3,4) porque el cliente ya vio el diagnostico y esta esperando el efecto en su app, y cerrar la causa raiz pendiente de (5). --- _Reported via AI agent: William (Apolo Food) - conv 412412_

  • 0
    BugOtro

    Icono de app se ve mal: placa azul (primaryColor) + wordmark full-bleed — aka-delivery

    Reporte de Alejandro (aka-delivery, conv 402735) con captura del home screen del telefono: el icono instalado muestra el logo naranja AKA DELIVERY dentro de una placa AZUL, ocupando casi todo el ancho del slot, con la palabra DELIVERY ilegible a tamano de icono. Diagnostico verificado: 1) Company.iconBackgroundColor estaba VACIO -> generateAndroidIcons (src/lib/services/build/build-worker.js:245 y :317) cae a primaryColor = #3B82F6 (azul) tanto para el fill del foreground como para el <background> del adaptive icon. La marca del cliente es naranja/blanco, de ahi el azul fuera de marca. YA corregido por config: iconBackgroundColor = #FFFFFF (verificado en DB). Aplica desde la PROXIMA build. 2) El logo del tenant (512x512, https://4a898acpxayxoeag.public.blob.vercel-storage.com/logos/9f084cd1-0c82-4195-ac3f-b6b6d2e40898/logo.png) es un wordmark HORIZONTAL ~2.1:1. Tras el -trim, en un slot cuadrado solo puede ocupar una banda central. Medido sobre la captura: la banda naranja ocupa ~92% del ancho y ~44% del alto del icono, lo que corresponde al ratio LEGACY 0.90 (ic_launcher.png), NO al 0.60 del foreground adaptativo — vale revisar si en el launcher real se esta resolviendo el icono legacy en vez del adaptive (mipmap-anydpi-v26), porque el legacy se genera SIN fill de color. Pedido: (a) revisar resolucion legacy vs adaptive en launchers reales, (b) evaluar composicion cuadrada automatica para logos wordmark horizontales (o derivar/pedir un icono cuadrado por tenant). Cualquier cambio de icono requiere build nueva + revision de Google. appPlan del tenant: PRO (procede). --- _Reported via AI agent: AI agent — Chatwoot conv 402735 (Alejandro / aka-delivery)_

  • 0
    IdeaOtro

    Ajustes > Operadores por zona: el toggle 'Despacho limitado a las zonas del conductor' esta mal ubicado y se confunde con 'Operadores por creador' (Victor, teo-154a)

    Reporte del cliente Victor (teo-154a, PRO), conv 413214, 2026-07-21: 'Estas 2 opciones estan causando conflicto y tienen casi la misma definicion' y 'Despacho limitado a las zonas del conductor esta mal ubicado, esta configuracion es para operadores no conductores; al conductor no se le limita una zona'. PROBLEMA REAL (UX/copy, no bug funcional): el bloque de Ajustes agrupa TRES toggles bajo el titulo 'Operadores por zona', pero solo DOS hablan de operadores: - zoneScopedOperatorsEnabled ('Operadores por zona') -> visibilidad del EQUIPO. - zoneScopeStrictEnabled ('Zoning estricto') -> visibilidad del EQUIPO (quita la red de seguridad de conductores sin zona). - enforceZoneScopedDispatch ('Despacho limitado a las zonas del conductor') -> NO es visibilidad: cambia el DESPACHO (src/lib/services/trip/driver-search.ts:525), o sea a quien se le ofrece el viaje. Vive anidado dentro del bloque de operadores, lo que hace pensar al dueno que activar operadores por zona limita a sus conductores. Victor es explicito: sus conductores son independientes y deben poder trabajar en cualquier zona. Y creatorScopedOperatorsEnabled ('Operadores por creador') tiene copy que no dice explicitamente que es OTRO EJE (quien dio de alta al conductor) y que al combinarse con zonas da la INTERSECCION. PROPUESTAS: 1. Sacar 'Despacho limitado a las zonas del conductor' del bloque de operadores y moverlo a la seccion de Despacho/Matching, renombrandolo a 'Ofrecer viajes solo a conductores de la zona de origen' con nota 'afecta a los conductores, no a tu equipo'. 2. En 'Operadores por creador' anadir una linea de contraste: 'Zona = donde trabaja el conductor. Creador = quien lo dio de alta. Si prendes ambos, el operador ve solo la interseccion'. 3. GUARD DE DATOS relacionado detectado en el mismo tenant: teo-154a tiene DOS zonas activas llamadas 'Piura' (981afafc-27e0-4e0a-841a-6954c45e40bc y c8298772-d3ad-46b7-804d-96de0672063d) de 85 zonas totales; es la unica duplicada. Con operadores por zona encendido, asignar al operador una 'Piura' y al conductor la otra deja al conductor invisible sin ningun mensaje de error. Pedimos avisar/bloquear nombres de zona duplicados dentro del mismo tenant y desambiguarlos en los selectores.

  • 0
    IdeaNotificaciones

    [PRIORIDAD ALTA] Onboarding obligatorio de permisos+batería para conductores (asistente paso a paso, bloqueante hasta quedar listo)

    Solicitado por Edwin (tenant Geotaxi = slug delivery-go, Perú, 46 conductores Android). Problema operativo real: sus conductores NO reciben las alertas de nuevo pedido, y la causa raíz (confirmada por diagnóstico de push) NO es el backend sino la CONFIGURACIÓN del dispositivo Android: optimización de batería/inicio automático apagados matan el servicio en segundo plano, y/o permiso de notificaciones + sonido no habilitados. Edwin lo resume: "los conductores no saben manejar sus teléfonos y por eso no les llega la alerta". Diagnóstico (push-diagnostics, delivery-go): - 46 dispositivos Android registrados, 0 iOS. Tokens FCM presentes y RECIENTES (refrescados 2-3 jul 2026). - Verdict por conductor (muestra de 3 activos: Willy Alata, Eduardo Mendoza, Raúl Orihuela): deliverable:true, bestChannel:fcm. El backend SÍ puede alcanzarlos. - Un envío a conductor (offer_accepted) salió SENT por FCM. => Entrega backend sana; el fallo está del lado del dispositivo. Petición concreta de Edwin: que al descargar/instalar la app del conductor haya un asistente PASO A PASO OBLIGATORIO (bloqueante) que lo guíe a: 1) quitar optimización de batería / permitir inicio automático, 2) habilitar notificaciones + sonido del canal de pedidos (ride_requests_v2), 3) no cerrar la app deslizándola. Que no pueda ponerse EN LÍNEA / recibir carreras hasta completar los checks. Idealmente con deep-links directos a los ajustes del fabricante (Xiaomi/Samsung/etc. que son los que más matan procesos). Hoy existen banners pasivos (notification_permission_banner → openAppSettings, background_location_banner, overlay_permission_banner) pero NO un flujo bloqueante y obligatorio antes de salir en línea. Esto es lo que falta. Nota: los fixes recientes de push en background (cmr73iive) ya salieron RELEASED pero aplican solo en un BUILD nuevo; parte del alivio llega actualizando la app del conductor. El asistente obligatorio es el complemento estructural para no depender de que cada conductor sepa configurar su teléfono. Prioridad sugerida: HIGH (afecta operación diaria del tenant). --- _Reported via AI agent: Edwin (Geotaxi / delivery-go) — conv 401633, +51950987937, Perú_

Liberado

497
  • 5
    IdeaOtro

    App para Usuarios (Operadores de plataforma)

    Se tiene pensado lanzar una App para los operadores de plataforma? La verdad el dashboard esta muy completo para los administradores globales (nosotros) pero creo que es más práctico una aplicación para los operadores, he intentado hacer la versión app de la pagina web (opción de chrome) pero se visualiza muy pequeña y el mapa en la sección de "Viajes en vivo" es casi imposible manejarlo desde el móvil. Vaya, creo que un operador de zona podría trabajar muy bien con una App que le permita acceder a "+Nuevo viaje", "Viajes en Vivo", "Conversaciones", "Conductores", "Historial de viajes", "Pedidos" y "Citas". Incluso tal vez se pueda hacer desde la misma app. solo que al detectar que el correo es de un usuario (Operador) le abra la aplicación de admin.

    Liberado el 15/7/2026
  • 4
    BugWhatsApp

    NO PERMITE CONFIGURAR CANALES WHATSAPP

    los números de celular en META BUSIINESS SON : El principal + 57 3205231670 El segundo numero es +57 3113835800 ,la URL CORRESPONDE a META BUSINESS de VIA. https://business.facebook.com/latest/home?asset_id=700661610373928

    Liberado el 27/4/2026
  • 3
    IdeaPlataforma

    Usuarios de plataforma por zona

    Que en mi equipo de trabajo, pueda designar operadores de plataforma por zona, es decir que si abro una nueva ciudad este usuario pueda gestionar esa zona, conductores clientes y negocios, dados de alta solo en esa zona que le corresponde, Mapa, Vijes etc. sin los datos economios de los viajes (comisiones etc.)

    Liberado el 5/6/2026
  • 3
    IdeaDelivery

    INCLUIR EN DELIVERY SOLICITUD DE PEDIDO SIN NECESIDAD QUE HAYAN PRODUCTOS GUARDADOS

    EJEMPLO: Una Droguería o una Ferretería puede tener 10MIL REFERENCIAS ,el usuario como va a pedir un medicamento X si el sistema no permite avanzar si no se tienen preestablecidos los productos, muchos comercios también necesitan entregar lo que ya vendieron directamente y no recibieron la orden de pedido por Delivery delivery

    Liberado el 15/5/2026
  • 2
    IdeaPlataforma

    Verificacion d pasajeros

    Seria bueno que en determinado horario (poder configurar ese horario) pudiera activarse la verificacion de pasajeros y el PIN (obligando a mostrar rostro y credencial de identificacion oficial)

    Liberado el 13/7/2026
  • 2
    IdeaOtro

    Aplicar IVA a las comisones del OPERADOR

    Por ley estan grabadas los servicios por plataforma eso significa quede la comision que se obtiene de cada viaje o servicio se debe pagar el impuesto IVA sobre ese monto obtenido es necesario crear un modulo contable en el dasboard para liquidar a todas la comisiones de IVA por PAIS.

    Liberado el 20/5/2026
  • 2
    BugApp móvil

    Desactivacion de productos

    En la aplicacion de negocio, en los productos disponibles, no sepuede dessactivar/ activar un producto que ya no se tiene en tienda de la app, MARCA ERROR

    Liberado el 11/5/2026
  • 2
    BugDashboard

    URL personalizada de admin

    He configurado la versión web del admin con el dominio admin.apolofood.com.pe y lo muestra bien, pero al hacer login me lleva a la ur cabgo.app/dashboard...

    Liberado el 2/5/2026
  • 2
    IdeaPlataforma

    PARNERTS O FRANQUICIA

    les explico algo que me esta funcionando como gancho en paraguay y es que conducotres traigan a otros conductores y ellos queden con un codigo de referido y comisionen despues de gastos por lo que sus referidos traigan , es un programa como de resellers y en muchos paises d elatinoamerica funciona porque ellos tiene sus grupos de whatssapp y de alli se envian servicoos entre ellos y si enganchamos a esos conducotres la app de apphive tendria un punto mas d evalor agregado en el mercado

    Liberado el 1/5/2026
  • 2
    BugDashboard

    desinformacion en conducotres y clientes

    desde el dia de ayer me aparecen clintes y conductores como pendinetes en el dash boiard poero realmente ya los aprobe todos

    Liberado el 29/4/2026
  • 2
    IdeaOtro

    RECARGOS EN LOS VIAJES POR TIEMPO Y FERIADOS

    SERA BUENO TENER RECARGOS POR DIA DOMINICAL Y FESTIVO ASI COMO EL RECARGO NOCTURNO ESTE NO ES POR PORCENTAJE SI NO RECARGO FIJO SERIA BUENO INCLUIRLO EN ROADMAP PARA INICIAR

    Liberado el 29/4/2026
  • 2
    BugApp móvil

    No aparecen cantidad de viajes ni nombre

    Buenas no aparecen cuando estra la solicitud del viaje el nombre del cliente , tipo de servicios y cantidad de viajes , solo aparece cuando caen en centro de viajes

    Liberado el 29/4/2026
  • 2
    BugDelivery

    Código del cliente

    Estoy haciendo una prueba como repartidor y me piden un cogido. Pero ellos no tienen como darme un código por q no tienen la aplicación. Es reparto interno

    Liberado el 29/4/2026
  • 2
    BugOtro

    Modificar cuenta google en APPS ios Marca Blanca

    Al ingresar a registrarse en un equipo de apple, este si te quieres loguear con tu cuenta de google de gmail te aparece no el nombre de tu app si no cabgo y si le das nombre aparece el correo de Jonatan@apphive.io, esto es una falla en el servicio de marca blanca por que inmediatamente tus competidores sabran la procedencia de tu app, si considero modificar y es vital para mi operacion este detalle cosmetico anque minimo es relevante y lo que puede implicar e impactar en tu negocio. Con lo cual solicito modificar o permitirnos crear nuesta cuenta en firebase y modificarla.

    Liberado el 26/4/2026
  • 2
    IdeaPlataforma

    MENOS CONSUMO DE COMBUSTIBLE PARA LOS CONDC¡UCTORES

    Hola J, te pregunto , hay forma de configurar unos serivicios de0 a 1 km de 1,1 a 2 km , de 2,1 a 3 km de 3,1 a 4 km y que cada unos de estos servicios tenga un valo9r especifico y despues del 5 kkilometro si sea como esta ahora configurado, esto con la idea que los conductores consuman las carreas mas cortas y gasten menos combustible y generen mas dinero apidamente y asi las carreras largas tendran un valor alto y tambien sera rentable para el conductor

    Liberado el 27/4/2026
  • 2
    BugApp móvil

    El icono del auto en el mapa

    El app pasajero pide y nose visualiza el icono del auto solo el trazado punto A y B. En el conductor se visualiza el auto pero no se mueve ni se desplaza .. solo esta estática... no se mueve en tiempo real

    Liberado el 27/4/2026
  • 2
    BugDashboard

    Notificaciones en tiempo real

    Muchas de las interacciones desde la app hacia el dashboard no las notifica en tiempo y forma debes estar actualizando la plataforma para verlas algunas como emergencias o cambios o conductores de registro funciona bn pero aun hay limitaicones en esto.

    Liberado el 27/4/2026
  • 2
    BugApp móvil

    Sobre la trayectoria en el mapa

    En la ultima actualización de versión.... en el app conductor no se mueve el icono del auto en el trayecto... Y en El pasajero no se muestra el icono del auto... He verificado en la web que el conductor si está en línea y los permisos tanto en el app conductor y pasajero están correctamente permitidos.. en el teléfono.

    Liberado el 27/4/2026
  • 2
    IdeaOtro

    Es genial que se mueva el icono de manera personallizada

    la imagen del icono debe salir y mostrar su avance en el trayecto de recogida, es importante la imagen del servicio solicitado, Ejemplo: moto, ambulancia .taxi. camión de carga etc...la imagen ubica al usuario del tipo de vehículo y al tener movilidad el usuario puede medir la distancia y el tiempo de llegada.

    Liberado el 27/4/2026
  • 2
    BugApp móvil

    El icono del auto

    Anteriormente se movía el icono del auto dentro del mapa siguiendo la ruta, pero con esta actualización reciente ya no se mueve .... esta estático en el conductor. Y el app pasajero ni se visualiza el icono del auto

    Liberado el 17/4/2026
  • 1
    BugApp móvil

    Historial de viajes de colectivos no muestra el Status real

    Cuando el pasajero revisa sus reservas de colectivos, aparece como que si ese viaje no se ha llevado a cabo aún, cuando desde la App de conductor ya salen como Completados y en el pasajero salen en Status reservado

    Liberado el 27/7/2026
  • 1
    BugDashboard

    No guarda el nombre de la App al configurar el Demo

    Cuando estoy creando la empresa, me pide el nombre de la App, se lo coloco pero cuando ya esta creada y vengo a esta vista me sale asi vacio y siempre se lo tengo que volver a poner de nuevo.

    Liberado el 27/7/2026
  • 1
    BugDashboard

    Al crear un Demo hay un camino que cobra los $15

    Cuando le das click al boton de "Crear una empresa nueva", te manda al flujo de pagar los $15 por el Demo, cuando tendria que ser como es con el boton que esta dentro en donde creas el Demo si costo.

    Liberado el 27/7/2026
  • 1
    BugApp móvil

    No se ve la opción de Recoger en tienda en la app real.

    No se ve la opción de Recoger en tienda en la app real. aqui en la demo se ve bien, pero en una prueba real con mis clientes no se ve esa opción a pesar de que esa prueba se hizo desde la app android instalada.

    Liberado el 27/7/2026
  • 1
    BugApp móvil

    Aparece "sin conductores"

    me estan saliendo que no hay conductores cuando si tengo disponibles

    Liberado el 26/7/2026
  • 1
    BugOtro

    Panel admin > Delivery > Negocios: el alta usa labels fiscales GENERICOS (RUT/RFC/NIT) e ignora businessFieldLabels por pais (AR)

    SUPERFICIE QUE FALTA de cmrw506uz (ya RELEASED por web+movil). El cliente seven/ARGENT (Temistocles) sigue viendo labels de otro pais EN EL PANEL ADMIN, y tiene razon. Es su 3er reclamo del mismo punto. Verificado 2026-07-23 ~23:30 UTC: - OK: GET /api/mobile/public/company-config?slug=seven devuelve businessFieldLabels correcto (taxId="Identificacion Fiscal (CUIT)" 11 digitos, bankAccount="CBU/CVU" 22, legalRepId="DNI del representante legal", accountType=[Cuenta Corriente, Caja de Ahorro, Billetera virtual]) + bankAccountTypes AR. - OK: src/app/(business-portal)/business/request/page.tsx usa labels.taxId.label (country-aware). - OK: apps/cabgo/lib/features/business/auth/screens/register_screen.dart + business/profile/screens/profile_screen.dart leen businessFieldLabels; main.dart.js desplegado en web.cabgo.app ya lo contiene. - FALLA: src/app/(dashboard)/dashboard/delivery/businesses/businesses-client.tsx:1162 renderiza {m.taxIdLabel} (i18n estatico). src/i18n/messages/delivery/businesses.es.ts:121 taxIdLabel = "Identificacion fiscal (RUT / RFC / NIT)", :133 legalRepIdLabel = "Cedula del representante legal", :125 bankAccountLabel = "Cuenta bancaria". Eso es EXACTAMENTE lo que reporta el cliente ("aparecen los datos de un comercio que se registra en otro pais, probablemente Mexico" -> RFC). Fix propuesto: que businesses-client.tsx consuma getBusinessFieldLabels(company.country) (src/lib/bank-field-templates.ts) como ya hace el business-portal, con fallback al i18n generico cuando el pais no tiene override; idem para el selector de tipo de cuenta (bankAccountTypes). Impacto: todo tenant con pais tuneado (AR hoy) ve nomenclatura equivocada en el alta de negocios del panel.

    Liberado el 23/7/2026
  • 1
    BugDashboard

    billetera y login

    revisando la billetera me sale 5 notificaciones pero cuando reviso en rechazado me sale uno pero no me deja quitar la notificacion adicional cuando el usuario descarga la aplicacion y abre se carga como conductor seria mas practico que saldria una opcion si es conductor negocio o delivery etc para que el usuario no sienta que ingreso a la sesion de conductores

    Liberado el 24/7/2026
  • 1
    BugDashboard

    Agregar mas paises en el buscador para documentos

    Aqui en esta parte hacen falta paises, por ejemplo lo necesitaba para El Salvador, y no se encuentra.

    Liberado el 22/7/2026
  • 1
    BugDashboard

    Error con Mayusculas en correo de Demo

    Este error ya lo habia hecho pero vuelve a pasar, el correo del cliente es Cazun3030@gmail.com, la Demo lo crea con la primera minuscula (cazun3030@gmail.com), pero cuando el cliente intenta con su correo original que esta en Mayuscula le da error, deberia de poder ingresar ya sea que lo ponga en mayuscula o minuscula.

    Liberado el 22/7/2026
  • 1
    BugDashboard

    Error al Cargar Logo al crear empresa desde Panel Revendedor

    Estoy cargando un logo que es JPEG y me sale ese mensaje de Sin permiso, lo converti a PNG pensando que podria ser eso pero el error de sin permiso sigue saliendo.

    Liberado el 22/7/2026
  • 1
    BugDelivery

    Cree un cupon llamado IRMA100 pero mis clientes no están pudiendo aplicarlo. Algo falla ahi

    Les mandé un coupon a mis clientes y ahora me llamó uno para decirme que su cupón no de aplicaba

    Liberado el 20/7/2026
  • 1
    BugDashboard

    Porqué mi build sigue dice demo-rayo-taxi-?

    Tengo una duda? porqué mi build dice asi: https://pub-02daf8ad890c433980e0375bb04c0bd6.r2.dev/builds/demo-rayo-taxi-29f83294/882da006-eaca-41c0-8fd0-3a84a791d754/demo-rayo-taxi-29f83294-1.0.42.apk ¿esto es correcto? no debería decir nodo en vez de demo-rayo-taxi-... ?

    Liberado el 19/7/2026
  • 1
    BugOtro

    Problema con pasajero

    Realizando las pruebas desde el apartado del pasajero se realiza la solicitud y cuando el pasajero sale y regresa a la aplicación sale que tiene una solicitud

    Liberado el 15/7/2026
  • 1
    IdeaOtro

    Ofrecer plan de pagos para clientes

    Tengo clientes que han probado la Demo y me preguntan si existe algun plan de pago para adquirir las Apps, se puede pensar o evaluar la alternativa de pago a meses para darle opciones a quienes se les complique pagar de una vez el monto total.

    Liberado el 15/7/2026
  • 1
    BugDashboard

    NO SE PUEDEN EDITAR / BORRAR

    LOS AJUSTES FISCALES NO SE PUEDEN EDITAR O ELIMINAR EN CASO QUE QUEDARAN INCORRECTOS AL CREARLOS

    Liberado el 14/7/2026
  • 1
    BugApp móvil

    Corrección urgente – Falla en el sistema de asignación directa de viajes

    ​Hola. ​Estoy teniendo un problema con la lógica del despacho de viajes en la aplicación. Actualmente, los servicios solo se están mostrando en el Radar de Viajes, pero la asignación directa no está funcionando. ​La configuración debe ser la siguiente: cuando un usuario pide un viaje, el sistema debe buscar y mandarle la alerta exclusiva al conductor más cercano en tiempo real. Si ese conductor no acepta en el tiempo límite, entonces ya puede pasar al radar general o al siguiente conductor. ​Por favor, revisen el algoritmo de despacho en el backend y las notificaciones push en la app de los conductores, porque no les está llegando ninguna solicitud directa a la pantalla. Quedo al pendiente de sus comentarios para hacer pruebas.

    Liberado el 10/7/2026
  • 1
    BugDashboard

    Cliente sale sin app en panel Revendedor

    Este usuario ya compilo las aplicaciones, pero me sale en el panel como Sin App, entenderia que cuando ya compila deberia de aparecer que si ya tiene App.

    Liberado el 13/7/2026
  • 1
    BugDashboard

    En transacciones no refleja las recargas de Billetera por Efectivo

    Le hice una recarga de Billetera a un conductor por $100 MXN, pero no se ve reflejada en el apartado de transacciones

    Liberado el 10/7/2026
  • 1
    BugApp móvil

    No sale los datos de mi vehículo

    En la app del Drivers no sale los datos del vehículo.

    Liberado el 12/7/2026
  • 1
    BugApp móvil

    Error en texto con color primario #faf314

    Cuando se tiene el tema claro en ese color, hay algunos textos que no se leen bien, por ejemplo adjunto la imágen.

    Liberado el 12/7/2026
  • 1
    BugOtro

    Erro con texto y colores

    Cuando el color de un botón es claro como amarillo, el texto en color blanco no se alcanza a leer, en ese caso tendría que mostrar un texto en color oscuro como negro para que contraste con el background del botón.

    Liberado el 9/7/2026
  • 1
    BugDashboard

    Error con mayusculas en correo

    Al momento de registrar una nueva empresa, el sistema pasa a minusculas todas las letras del correo que se le pone, luego da error si el propietario ingresa el correo original que tiene mayusculas, ver video.

    Liberado el 9/7/2026
  • 1
    IdeaDashboard

    Agregar el numero de telefono del dueño de la empresa

    Desde el panel de revendedor, se tiene el nombre y el correo del dueño de la empresa, seria bueno tambien agregar el numero de telefono que se le pide cuando entra por primera vez, para que tambien este a la vista de los revendedores.

    Liberado el 9/7/2026
  • 1
    BugPagos

    Error en etiqueta de panel de vendedor

    Cuando se ha creado una emepresa para Trial, sale una etiqueta de Convertido, la cual entiendo que esa deberia de ir cuando ya el cliente ha pagado; es decir, al terminar el Trial. A mi criterio no tendria que aparecer, unicamente tendria que verse la de pago pendiente.

    Liberado el 8/7/2026
  • 1
    BugApp móvil

    viajes

    despues de las ultimas actualizaciones ya no se asignan los viajes al conductor mas sercano solo se ven en centro de viajes .

    Liberado el 8/7/2026
  • 1
    BugOtro

    Al configurar un servicio diferente a delivery no se activa , se activa en zonas pero en servicios aparece como que no esta activo en ninguna zona

    tengo delivery activado pero quiero meter aparte servicio como de paqueteria , pero al momento de activarlo , en la de zona aparece activo pero , en servicios aparece que no esta activo en ninguna zona

    Liberado el 4/7/2026
  • 1
    BugOtro

    CONFIGURACION Y AJUSTES FISCALES

    AJUSTES FISCALES Reglas opcionales que se aplican sobre cada viaje o entrega para cargar impuestos, retenciones o comisiones extra. Sin reglas configuradas el cobro funciona normal. tengo configurado IVA 8% ISR 2.1% IMPUESTO AL ESTADO POR CADA VIAJE 2% EMPRESA 5% pero pero no se esta plicando la regla a los viajes realisados. CONFIGURACION Que ve el conductor en la oferta Define la cifra principal que aparece al conductor cuando recibe una oportunidad. El default ("Total del viaje") muestra lo que cobra al pasajero — util cuando la comision se ajusta despues. "Mi ganancia" muestra ya descontada la comision, util cuando el conductor toma decisiones por lo que le queda. "Total con desglose" mantiene el total pero agrega la linea de comision al detalle. Mi ganancia (neto al conductor) pero al conductor le sigue apareciendo el total del viaje

    Liberado el 30/6/2026
  • 1
    BugApp móvil

    Barra de direcciones

    al registrar el profesional, la barra de direcciones la habilitaron para ingresarla manualmente (muchas gracias), pero no tiene funcion y marca error (no registra la direccion)

    Liberado el 29/6/2026
  • 1
    BugApp móvil

    Notificaciones sonoras

    No esta notificando (sonido) en primer plano En segundo plano solo manda un Ping, deberia sonar persistente como la notificacion de primer plano

    Liberado el 29/6/2026
  • 1
    BugPlataforma

    No se actualiza

    Han caducado los 16 dias de pruba pero el boton para proceder con el ultimo paso no se desbloquea.

    Liberado el 25/6/2026
  • 1
    IdeaWhatsApp

    Flujo para pedidos.

    Implementar un flujo para el bot de WhatsApp que le permita al cliente solicitar un pedido a domicilio/Entrega por WhatsApp. Por ejemplo. que al principio pregunte si desea un viaje o realizar un pedido... En la dirección de recogida puede ser la del cliente sin dirección de entrega. y el pedido que haga el cliente (texto del mensaje en whatsapp) se puede agregar en "Notas para el conductor". En ocasiones los clientes solicitan articulos muy especificos o de negocios que actualmente no estan en la App.

    Liberado el 15/7/2026
  • 1
    IdeaPlataforma

    Zona en la Plataforma

    Seria bueno que cada zona tuviera al darle click abriera su propia plataforma, paraa poder abrir los mapas en diferentes monitores o en su defeccto computadoras, asi tambien que al mometo de agregaar nuevos usuarios de plataforma puedan darles roles de solo esa zona a trabajar

    Liberado el 7/7/2026
  • 1
    IdeaPlataforma

    Conductores con 2 o mas autos

    Realmente no es una idea, es algo que vi recientemente en otra plataforma (competencia) que un conductor puedad dar de alta otro auto u otros autos en su nombrepara uso propio, y tambien, que los pueda dar a trabaajar a otros conductores sin perder el historial del auto, para esto tendria que el nuevo conductor ser dado de alta con su respectiva licencia para posteriormete asociarlo al auto del propietario (en caso de renta vehicular).

    Liberado el 24/6/2026
  • 1
    BugApp móvil

    Error en mensaje de error

    El mensaje se oculta detrás

    Liberado el 17/6/2026
  • 1
    BugDashboard

    No sale notificacion en Retiros

    Cuando un conductor quiere retirar, llega la notificacion pero no sale otra notificacion al entrar dentro de billetera, pareciendo que no se sabe que se debe de revisar.

    Liberado el 17/6/2026
  • 1
    BugApp móvil

    Error en dónde muestra el puntero de las direcciones

    Al buscar una dirección en El Salvador (no se si pasa con otros países), el punto lo coloca en un lugar más retirado de dónde debería de estar.

    Liberado el 17/6/2026
  • 1
    IdeaApp móvil

    Opción de fidelización pasajero

    Sería una buena opción para que sea más transparente que en el menú de pasajero esté la opción , como en el conductor está la de retos en el pasajero este reto o fidelización para que las personas puedan observar más fácil

    Liberado el 17/6/2026
  • 1
    BugApp móvil

    No funciona el cargo por espera activo

    Cuando el tiempo de espera finaliza, comienza a aumentar una tarifa, que al final no se suma al precio final del viaje, por lo tanto no la toma en cuenta y solo cobra el mismo precio que salía al inicio sin tomar esa tarifa de cargo extra.

    Liberado el 17/6/2026
  • 1
    BugOtro

    Mostrar foto perfil del pasajero en el chat

    Mostrar la foto en el chat, tanto del pasajero en la App de conductor y del conductor en la App de usted

    Liberado el 17/6/2026
  • 1
    BugDashboard

    Error en "Que ve el conductor en la oferta"

    En esa opcion tengo configurado Mi ganancia(neto al conductor), pero cuando le llega la oferta al conductor le sale Cobraras y le sale el total en vez de la ganancia como dice esa opcion.

    Liberado el 17/6/2026
  • 1
    BugDashboard

    No muestra notificacion visible al llegar chat de soporte

    Si no se esta dentro de Conversaciones, el Admin no se dara cuenta que tiene un ticket de soporte porque no se visualiza fuera de esa pestaña.

    Liberado el 17/6/2026
  • 1
    BugDashboard

    Reporte de conductor sale con etiqueta de pasajero

    Este mensaje lo mande desde la App de conductor dentro del chat de soporte, y en el panel sale la etiqueta de pasajero cuando deberia de decir conductor.

    Liberado el 17/6/2026
  • 1
    BugApp móvil

    Ya no salen las preguntas frecuentes en Ayuda de usuario

    En el Side Menu de la App de usuario, al seleccionar la ultima pestaña que es la de Ayuda, manda directamente al chat de soporte y no a las preguntas frecuentes como lo hacia antes.

    Liberado el 17/6/2026
  • 1
    BugApp móvil

    El centro de viajes muestra información diferente

    Pedí un viajé, y en el centro de viaje muestra datos erróneos: Sale el precio de $6.45 cuando el viaje fue de $7.17, decía que era en efectivo cuando el viaje era en Wallet, solo pasa en la vista de centro de viajes, porque cuando sale la ventana emergente con los detalles ahí si sale bien.

    Liberado el 17/6/2026
  • 1
    BugDelivery

    SOLICITUDES DE REPARTIDOR,

    En solicitudes de repartidor, es importante que al RECIBIR LA OPORTUNIDAD, SI TIENE QUE PAGAR EN TIENDA, DIGA LA PANTALLA "Deberas pagar $ X.XX", EN VEZ DE "COBRAR TOTAL $X.XX." ESTO ES IMPORTANTE YA QUE DE ESTA INFORMACION EL REPARTIDOR DECIDE SI TOMA O NO TOMA EL PEDIDO DEBIDO A LO QUE TIENE QUE PAGAR (LO MISMO EN LAS SIGUIENTES PANTALLAS DE LLEGUE AL NEGOCIO Y RECOLECTAR PEDIDO)

    Liberado el 17/6/2026
  • 1
    BugPagos

    AJUSTES FISCALES

    AL CREAR LOS AJUSTES FISCALES, LAS CANTIDADES RETENIDAS DEBEN DE QUEDAR COMO DEUDA Y/O ACREDITARSE A LA PLATAFORMA, YA QUE ESTA ESTA A CARGO DE PAGAR LAS RETENCIONES COMO IMPUESTOS (AHORA SOLO SE MUESTRA EN EL NEGOCIO EN EL TOTAL DE GANANCIAS GENERADAS CON ESTOS DESCONTADOS, PERO NO LAS ESTA RECIBIENDO LA PLATAFORMA EN LOS BALANCES)

    Liberado el 17/6/2026
  • 1
    BugDashboard

    No se entiende la notificacion de cambios de clientes

    Cambie la foto desde la App de cliente, manda la notificacion al panel pero al darle click solo manda a la pestaña de clientes pero no se entiende lo que se debe hacer ahi.

    Liberado el 16/6/2026
  • 1
    BugPagos

    PAGO DE BALANCE NEGOCIO

    SI EL NEGOCIO TIENE SALDO NEGATIVO (DEUDA), NO HAY COMO LIQUIDARLO (SOLO HAY OPCION DE RETIRO DE GANANCIAS *SALDO POSITIVO) SUGIERO ADEMAS DE INCLUIRLO, MANDAR EVIDENCIA (FOTO) DE PAGO/DEPOSITO/TRANSFERENCIA

    Liberado el 16/6/2026
  • 1
    BugDelivery

    COMISIONES

    HABIA SUGERIDO QUE EN DELIVERY, HUBIERA 2 COMISIONES SEPARADAS YA QUE SON 2 MODELOS DE NEGOCIO DIFERENTE, UNA COMISION QUE ES LA YA EXISTENTE QUE SERIA PARA EL MODELO DELIVERY Y OTRA PARA CUANDO SOLICITA REPARTIDOR EL NEGOCIO, YA QUE EN ESTOS ESCENARIOS, LAS VENTAS SON GENERADAS DE FORMA DIFERENTE, EN DELIVERY EL APP GENERA LA VENTA (POR LO QUE REQUIERE UNA COMISION MAS ALTA) Y EN SOLICITAR REPARTIDOR ES EL NEGOCIO QUIEN GENERA LA VENTA, POR LO QUE SOLO SE COBRARIA POR LA GESTION DEL PEDIDO (COMISION MAS BAJA) SUGIERO QUE SE MANEJE POR NEGOCIO Y CON OPCION A PORCENTAJE O CUOTA FIJA, YA QUE QUIZAS RESTAURANTES SE COBRE POR PORCENTAJE, MIENTRAS QUE CARNICERIAS O FERRETERIAS SE COBRE CUOTA FIJA

    Liberado el 16/6/2026
  • 1
    IdeaPlataforma

    Agregar todos los paises en los escenarios

    Cuando pruebas el Emulador Web, hacen falta varios paises, entre ellos El Salvador para poder hacer ciertas pruebas.

    Liberado el 16/6/2026
  • 1
    BugOtro

    No sale parada en el resumen del viaje

    En esta pantalla de calificación, no sale la parada que se hizo en el viaje.

    Liberado el 14/6/2026
  • 1
    BugDashboard

    No diferencia cuando un reporte lo hace el conductor o pasajero

    Les pone siempre hecho por pasajero

    Liberado el 14/6/2026
  • 1
    BugApp móvil

    En esta pantalla del conductor no sale la parada del viaje

    En la pantalla de la captura no sale los detalles de la parada que se hará, únicamente sale en la App de pasajero cuando está en ese Status del viaje.

    Liberado el 14/6/2026
  • 1
    BugApp móvil

    No funciona el agregar boton de cancelar

    Tengo habilitada esta opcion pero al conductor no le sale ningun boton para denegar o rechazar un viaje.

    Liberado el 14/6/2026
  • 1
    BugPagos

    No muestra el numero de Clabe de banco

    Este conductor tiene todos los campos del banco ya configurada, pero sale que la Clabe no esta registrada.

    Liberado el 14/6/2026
  • 1
    BugDashboard

    Error en vista de calendario

    Cuando se quiere personalizar un filtrado de fecha en el historial de viajes, sale desplazado los dias del calendario.

    Liberado el 14/6/2026
  • 1
    BugDashboard

    El codiog del viaje no coincide al entrar a los detalles

    El codigo del viaje es mas corto en la lista del que sale al entrar a los detalles

    Liberado el 14/6/2026
  • 1
    BugOtro

    No funciona el buscador por codigo en el historial de viajes

    Al pegar el codigo, deberia de mostrar el viaje que coincida con ese codigo y no todos.

    Liberado el 14/6/2026
  • 1
    BugDashboard

    Error al Descargar Recibo

    En el historial de viaje, cuando le das en descargar Recibo, sale error cuando abre la pestaña.

    Liberado el 14/6/2026
  • 1
    BugDashboard

    No muestra notificacion cuando hay un pendiente en verificacion facial

    No hay forma de enterarse porque no muestra notificacion.

    Liberado el 13/6/2026
  • 1
    BugOtro

    Ventana no tiene Scroll

    Cuando tiene varias opciones, está ventana corta lo de arriba y no tiene Scroll para bajarlo.

    Liberado el 13/6/2026
  • 1
    BugApp móvil

    Error en notificacion de Chat Soporte

    Cuando soporte manda un chat, al estar en segundo plano la App redirige bien al chat, pero cuando se esta en primer plano y llega la notificacion, al dar click en la notificacion no hace nada, esto sucede cuando se tiene abierta la App.

    Liberado el 13/6/2026
  • 1
    BugDashboard

    La ventana de transacciones no registra las transacciones por efectivo

    Solo muestra las transacciones por tarjeta

    Liberado el 13/6/2026
  • 1
    BugApp móvil

    Error al ocupar el cupon en un viaje

    Cuando ocupas el cupon, en la app de usuario se descuenta el porcentaje diciendole cuanto pagara (esta bien), pero en la app del conductor sigue teniendo el precio original y no se ve reflejado nada del cupon.

    Liberado el 13/6/2026
  • 1
    BugDashboard

    No deberia de poderse compilar cuando el Trial de una cuenta finaliza

    Cuando un Trial de una cuenta finaliza, mno deberia dejar compilar si no hasta que haya adquirido un plan.

    Liberado el 12/6/2026
  • 1
    IdeaApp móvil

    Donde visualizar lo que le debo a los conductores que hicieron viajes con tarjeta

    Actualmente desconozco donde se visualiza lo que se les debe a los conductores que han hecho viajes con tarjetas, porque ese dinero llega a la cuenta del Admin pero tengo que tener un lugar donde ver a que conductor le debo y cuanto le debo por esos viajes que se pagan con tarjeta. Porque si no la otra opcion seria que se los sume a la billetera del conductor para que luego lo pueda retirar.

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    El precio del Total del viaje varia entre Usuario y Conductor

    Haciendo pruebas, al usuario le sale que un viaje le costara $7.14 por ejemplo, y al conductor cuando se le manda la solicitud le sale $7.31, siempre varia por unos centavos, pero entiendo que deberia de ser el mismo precio.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    No hace nada la pestala de Promociones

    En la app de usuario, cuando entras al Side Menu a la pestaña de Promociones, si agregas un cupon, sale la notificacion de exito que se aplico el cupon pero no se visualiza por ningun lado, ni se puede aplicar en el viaje porque al momento de solicitar un viaje no hay donde uno pueda agregar un cupon.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    No funciona la pestaña de Transacciones

    En el apartado de Finanzas, cuando se hace una transaccion no se ve reflejada en la pestaña de Transacciones.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    Las recargas de Billetera con Efectivo no llegan

    Al darle en Recargar Billetera con Efectivo desde la app de usuario, no aparece en la App el movimiento para cargar el comprobante y tampoco llega ninguna notificacion al panel de Admin.

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    Error en configuracion "Que ve el conductor en la oferta"

    Yo lo tengo configurado como "Total del viaje (default)", pero al conductor le sale el Total del viaje (lo cual esta bien) pero arriba dice Ganaras, ese texto tendria que cambiar dependiendo lo que uno configure, en ese caso tendria que decir "Cobraras" cuando este en Total del Viaje.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    No funciona el reportar un problema

    Cuando estás dentro de un viajé Completado, está el botón para reportar un problema, pero al enviar el reporte no llega a ningún lado, yo pensaba que se vería en la pestaña de emergencias del panel pero no

    Liberado el 12/6/2026
  • 1
    BugDashboard

    No se puede cerrar una conver de Chat

    Deberia de poderse cerrar una conversacion de Chat con soporte para darla como resuelta o completada.

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    En el chat de soporte en la App no se ven las imágenes

    Cuando desde Admin manda una foto en el chat de soporte, la app no ve esa fotos sale el icono de la foto con la palabra imagen a la par.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    No llega notificaciones del Chat de Soporte

    Cuando se esta dentro de la App de usuario, no llega notificaciones de los mensajes que manda el Admin desde el Chat de soporte, asi que no hay forma de saber que escribio.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    Error en el Estado de un cliente

    Cuando entras a los detalles del cliente desde el Chat sale Inactivo, pero al ir a la pestaña de clientes si sale Activo.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    La notificacion del Chat no manda al Chat

    Cuando un conductor escribe al soporte, llega esta notificacion arriba a la derecha, pero al darle en Ver, lo manda al Dashboard inicial y no a la conversacion.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    Notificacion de Billetera quedo trabada

    Me dice que tengo un pendiente en la Billetera pero al entrar no me queda claro cual es el pendiente. No se si hay un pendiente o quedo trabada ahi esa notificacion.

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    Campos duplicados al Editar perfil de usuario

    Estando en el perfil, cuando le das Editar perfil, en dónde dice información adicional vuelve a mostrar el nombre, apellido y correo cuando ya lo tiene en la parte de arriba.

    Liberado el 12/6/2026
  • 1
    IdeaApp móvil

    Que se pueda iniciar viaje desde Viajes Recientes

    En la ventana de Home de la App User, debajo de lugares guardados estan los Viajes recientes, seria bueno que al seleccionar un viaje reciente se cree el viaje en ese momento, ya que al seleccionarlos no hacen nada.

    Liberado el 12/6/2026
  • 1
    IdeaOtro

    Que se pueda iniciar un viaje desde Lugares guardados

    Cuando en la app de usuario se va a los lugares guardados, pensaba que al seleccionar uno de ellos me mandaria a crear el viaje, pero no hace nada al seleccionar los lugares guardados desde esa ventana.

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    No esta haciendo la verificacion Facial

    Cuando un conductor manda a hacer la verificacion Facial, la App lo marca como exitosa de una vez sin haberle llegado al Admin para revisarla. De hecho al Admin no le llega, de una vez se aprueba y le aparece aprobada al conductor

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    Etiqueta de Completado se corta por nombre largo

    Cuando el nombre es muy largo, la etiqueta de Completado se corta y se sale de la pantalla

    Liberado el 12/6/2026
  • 1
    IdeaApp móvil

    Agregar evento en Ganancia y Viajes

    En la pantalla de inicio del conductor todos los recuadros tienen un evento, excepto los de Ganancias y viajes, al seleccionar esos no hace nada y con los demás si lleva a algún lado. Sería bueno que cuando le dé click al icono donde está el símbolo del dólar lo lleve a la ventana de los detalles de la ganancia al igual que con la pestaña de viaje.

    Liberado el 12/6/2026
  • 1
    BugDashboard

    Error al subir videos para reporte de Bug

    Cuando se sube un vídeo MP4 (es menor a 50 MB), sale el error en rojo que dice: Fallo la subida del archivo

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    Error en Modal de Necesitamos tu ubicación

    En la foto que anexo, muestro como ese botón de "reintentar" no hace nada, a pesar de que ya tengo el GPS activado, solo se quita cuando se van a aceptar los permisos de ubicación del teléfono.

    Liberado el 12/6/2026
  • 1
    BugApp móvil

    Error en la pantalla Mis Ganancias del conductor

    La App no refleja bien las ganancias del conductor, hice un viaje HOY dónde la ganancia del conductor fue de $38, pero en la App aparece $0.00 en las ganancias de Hoy

    Liberado el 11/6/2026
  • 1
    BugPlataforma

    dominio

    "ya tengo un dominio" no funciona.

    Liberado el 11/6/2026
  • 1
    BugApp móvil

    Agregar la calificacion correcta en el Side Menu

    Al abrir el Side Menu, en la parte donde esta el nombre de la cuenta aparece una estrella con una calificacion, veo que esta fijo en 5 porqu eno cambia para ningu a cuenta que tienen menos estrella.

    Liberado el 11/6/2026
  • 1
    BugApp móvil

    Hace falta Status cuando el viaje ha llegado a una parada

    Seleccione 3 puntos: A es mi origen B es una parada a la mitad del camino C es el destino que esta mas adelante que B Al momento de estar en el Status de viaje en curso justo despues de haber iniciado, la navegacion de Google Maps y Waze manda a la ubicacion C cuando primero tendria que pasar primero por la B. Tendria que haber un paso mas donde el conductor marque que ya llego a la parada que definia el viaje, luego que pueda continuar el viaje hasta el destino que es C

    Liberado el 12/6/2026
  • 1
    BugDashboard

    No sale la foto del Doc al hacer Verificacion Facial

    Cuando mandas una verificacion Facial, te pone la foto que manda la persona y al lado te pone la foto del Documento para que el Admin compare, pero el problema que no muestra nada en la foto del documento, unicamente sale el fondo gris.

    Liberado el 11/6/2026
  • 1
    BugDashboard

    No funcion el boton Capturar pantall al reportar un Bug

    Cuando se requiere reportar un Bug y se le da al boton Capturar pantalla, sale el error "No se pudo capturar la pantalla"

    Liberado el 11/6/2026
  • 1
    IdeaOtro

    Poder pagar pago pendiente desde el saldo disponible de la Billetera

    Si un cliente no paga un viaje anterior, le muestra la App que tiene un pago pendiente (Hasta ahi todo bien), pero al momento de saldar esa deuda, solo tiene la opcion para hacerlo con efectivo o con tarjeta, seria bueno que exista una tercera opcion para pagar desde el dinero que se tiene en la billetera, porque para las pruebas que estuve haciendo, mi usuario tiene un pago pendiente de $63.32, tengo $100 de saldo en mi billetera, pero no puedo pagar con esos $100 porque no me da la opcion.

    Liberado el 11/6/2026
  • 1
    IdeaDashboard

    Agregar que cambios necesitan volver a compilar la app

    En las opciones que se encuentran en el apartado de ajustes, no me queda claro que cambios de los que ahi se encuentran se necesita volver a compilar la app para que se vean reflejados, porque por ejemplo, el agregar el numero de la cuenta bancaria en donde retiraran los conductores no necesita compilar para que se vea reflejado. Seria bueno identificar de alguna forma para saber si el cambio que estamos haciendo necesita compilacion o no necesariamente.

    Liberado el 11/6/2026
  • 1
    BugNotificaciones

    campañas push masivas

    hice notificaciones push para pasajeros y conductores, no tdos recibieron la notificacion.

    Liberado el 11/6/2026
  • 1
    BugApp móvil

    Error en color de saldo agregado en Billetera

    Si te vas a la pestaña de billeteras, y le abonas saldo de forma manual a un conductor, dentro de la App del conductor si se lo suma pero en la interfaz aparece ese mismo valor en color rojo y con el icono de resta, como si fuera una salida pero en realidad es un ingreso. No subo captura por el error que reporte anteriormente que no me deja.

    Liberado el 11/6/2026
  • 1
    BugDashboard

    No permite subir imagenes a los reportes de Bug

    Cuando se le da en Capturas o videos estando en el formulario completo, siempre da este error en letras rojas: Failed to fetch (cabgo-builds.96971f99d22cd52d2880ba1e9c875e7d.r2.cloudflarestorage.com)

    Liberado el 11/6/2026
  • 1
    BugDashboard

    Las solicitudes de Cambio no salen en las notificaciones

    Cuando se manda una solicitud de cambio como el retiro de dinero por parte del conductor, no aparece en el icono de campaña dentro del Dashboard donde se espera que se vea todas estas notificaciones. Unicamente sale el numero 1 en la pestaña de Conductores.

    Liberado el 11/6/2026
  • 1
    BugPlataforma

    Crear Zonas

    no me deja crear zonas ahora, marca un error. antes no sucedia eso

    Liberado el 11/6/2026
  • 1
    BugPlataforma

    CARGA A TIENDAS

    Intente cargar la app en IOS hace 3/4 dias. Aun esta bloqueada. Como puedo hacer para cargarla correctamente en ios y hacerla operativa? gracias.

    Liberado el 11/6/2026
  • 1
    IdeaDashboard

    Mostrar dias pendientes de Trial

    En la barra superior, seria bueno mostrar los dias de Trial que le restan a una cuenta nueva que se ha creado, para tener mayor visibilidad y que aparezca que lleva 3/7 dias de Trial por poner un ejemplo, y cuando llegue a la fecha limite muestre un mensaje que el Trial ha finalizado, que debe adquirir uno de los paquetes y que desde ahi mismo lo mande.

    Liberado el 9/6/2026
  • 1
    IdeaApp móvil

    Cliente puede dejar nota

    Que el cliente puede indicar si gusta un producto sin un elemento

    Liberado el 9/6/2026
  • 1
    BugPlataforma

    Viajer programados

    Fallo en los viajes programados, en la aplicacion se programan a cierta hora (ejemplo ubicacion X el dia X y la hora ejemplo: 14:00) y en el sistema aparece otra hora mas temprana y en automatico lo cancela pasando el periodo de gracia

    Liberado el 8/6/2026
  • 1
    BugDashboard

    Botón de surge

    Lo desactivo y a la hora que ingreso a servicios y me devuelvo a surge está activo no funciona bien .

    Liberado el 8/6/2026
  • 1
    BugApp móvil

    iconos

    Los iconos que yo he agregado no aparecen mientras se usa la app. Aparecen los iconos de default.

    Liberado el 8/6/2026
  • 1
    BugDashboard

    Buenas noches el whatsapp no quiere responder automáticamente

    No quiere funcionar en whatsapp automático por ende la aplicación de con ductores no funciona bn no hemos podido trabajar

    Liberado el 4/6/2026
  • 1
    IdeaApp móvil

    Conductores conectados

    Seria bueno que hubiera historial de conexcion de los conductores, y si hay conductores con X tiempo desconectados podamos poner su cuenta en suspension por inactividad y que tengan que comunicarse con el administrador para activarla.

    Liberado el 4/6/2026
  • 1
    BugDashboard

    Aprobar conductores

    me comentan que ya no pueden hacer nada por que la app les muestra el mensaje que estann por aprobarse, y por esa razon no pueden llenar los campos que les hacen falta.

    Liberado el 4/6/2026
  • 1
    BugApp móvil

    Al Asignar Connductor

    en modo usuario: una vez que se asigna conductor parpadea todo el tiempo entre "buscando conductor" y "conductor asiganado y muestra recorrido en mapa" hasta que el conductor llega al lugar de recogida y se inicia el viaje.

    Liberado el 4/6/2026
  • 1
    IdeaPlataforma

    Solicitud de documentación sobre jerarquía de configuraciones y persistencia en entornos

    Hola, equipo: Les escribo para solicitar documentación técnica detallada o una guía clara sobre cómo la plataforma prioriza y aplica las configuraciones internas. Actualmente, estamos enfrentando conflictos con variables que pueden ser ajustadas desde múltiples niveles (por ejemplo, las tarifas de envío, que pueden configurarse a nivel de servicio de delivery o mediante un override en el local). Al no conocer el orden exacto en el que el sistema lee estas reglas, se generan conflictos de cálculo. Adicionalmente, hemos notado inconsistencias en la actualización del estado según el entorno de ejecución. Por ejemplo, al desactivar funciones de interfaz (como el cobro de propinas), el cambio se refleja correctamente en el APK, pero la capa Web y el emulador siguen mostrando la configuración anterior. Para poder estructurar nuestros procesos y evitar tiempos muertos de depuración, necesitamos que nos compartan: El árbol de decisión o jerarquía de configuraciones: Cuál es el orden exacto de prioridad (fallback) que aplica el sistema cuando existen configuraciones en conflicto (Global vs. Servicio vs. Local). Manejo de estado por plataforma: Cómo administra el sistema la lectura de la base de datos y la caché en los distintos entornos (APK compilado vs. Web/Emulador) para garantizar que los cambios (como un simple toggle de encendido/apagado) se sincronicen en todos lados. Entender esta arquitectura nos servirá como punto de partida fundamental para alinear nuestros ajustes sin afectar la experiencia final del usuario. Quedo atento a sus comentarios. De antemano, muchas gracias por el apoyo.

    Liberado el 2/6/2026
  • 1
    BugDashboard

    ERROR AL APROBAR CONDUCTOR

    al aprobar el conductor manda a error

    Liberado el 2/6/2026
  • 1
    BugPlataforma

    No puede aprobar a los conductores

    intente aprobar a Karen Rojas y me marco un error en la esquina del la parte superior la pantalla aldar de alta al conductor

    Liberado el 2/6/2026
  • 1
    BugOtro

    no puedo agregar categorias de servicios profesionales dice datos invalidos

    no puedo agregar categorias de servicios profesionales dice datos invalidos

    Liberado el 2/6/2026
  • 1
    IdeaPlataforma

    Botón o check habilitar o no

    Hola gente sería genial que tengamos una opción donde se pueda habilitar a conveniencia , lluvia , congestión vial donde al habilitar tenga la opción de sumar un monto o porcentaje a todas las tarifas habilitadas, y luego poderla deshabilitar , esto sería muy conveniente para poderlo tener en casos atípicos

    Liberado el 29/5/2026
  • 1
    BugPlataforma

    eliminar clientes

    Al intentar eliminar estos clientes de prueba, no me lo perite el sistema y me da un mensaje de error

    Liberado el 29/5/2026
  • 1
    BugDashboard

    Desaparecen Tabs

    En esta pantalla de Clientes, cuando seleccionas las Tabs vacias como Pendientes o Rechazado, desaparecen todas las Tabs, por lo que si se quiere regresar a los Clientes Activos se tiene que cambiar de pestaña y luego regresar.

    Liberado el 29/5/2026
  • 1
    BugDashboard

    Error en Video Youtube

    En este paso manda a un video de Youtube de 4 minutos el cual no esta disponible al darle click. Tambien en la parte de abajo muestra una documentacion que no esta vinculada.

    Liberado el 29/5/2026
  • 1
    BugPlataforma

    Retiros de billetera

    al momento de probar el retiro no pasa nada, ni para acepta t ra cancelar

    Liberado el 27/5/2026
  • 1
    BugDelivery

    ASIGNE MANUALMENTE UN PEDIDO Y DESCONECTO AL

    TE ENVIE UN REPORTE DE QUE NO ESTABA ASIGNANDO A REPARTIDORES HACE UN PAR DE HORAS, REGRESE DE NUEVO AL PEDIDO Y LO ASIGNE MANUALMENTE PARA SEGUIR HACIENDO PRUEBAS Y AL HACERLO, DESCONECTO AL REPARTIDOR

    Liberado el 27/5/2026
  • 1
    BugPlataforma

    Repartidores internos

    La invitacion a los repartidores internos no llega al correo y tampoco al telefono como sms o whatsapp.

    Liberado el 26/5/2026
  • 1
    BugApp móvil

    SALDO EN WALLET

    EL SALDO EN WALLET APARECE EN CEROS

    Liberado el 26/5/2026
  • 1
    BugApp móvil

    NO NOTIFICA OPORTUNIDADES DE VIAJES

    AL SOLICITAR UN VIAJE, EL DASHBOARD INDICA QUE YA HA NOTIFICADO A CONDUCTORES, PERO NO LES LLEGA LA NOTIFICACION, EN ESTE SCREENSHOT INDICA QUE LO HABIA NOTIFICADO A 2 (YO TENGO LOS 2 MOBILES PARA LAS PRUEBAS) Y NO SONO EN NINGUNO DE LOS DOS ADEMAS TENGO LA IMPRESION QUE AL SOLICITAR EL VIAJE, ME DESCONECTO EL APP DE CONDUCTOR Y AL RECONECTAR HASTA ENTONCES RECIBIO LA OPORTUNIDAD

    Liberado el 26/5/2026
  • 1
    BugOtro

    OPORTUNIDAD DE VIAJE SE OFRECE SOLO A UNO

    AL SOLICITAR UN VIAJE Y SE DISPARA LA OPORTUNIDAD, LE CAE A UN CHOFER Y EXISTEN ESTAS SITUACIONES 1. UNA VEZ RECIBIDA LA OPORTUNIDAD, NO BRINCA A OTROS CHOFERES DESPUES DEL TIEMPO DE NO ACEPTAR **MODALIDAD ASIGNACION AUTOMATICA / Progresivo (uno a la vez por cercanía) 2. NO HAY FORMA DE RECHAZAR EL PEDIDO 3. POR LO MISMO, LA UNICA FORMA DE REGRESAR AL HOME, ES CERRANDO Y ABRIENDO EL APP DE NUEVO

    Liberado el 25/5/2026
  • 1
    BugWhatsApp

    automatizado whatsapp

    Buenas deberia de crear una nota a la hora que alguien va solicitar un viaje por whatsapp cuando no esta registrado, deberia de sincronizar correo, celular , cedula de indentificacion para evitar dulplicaciones de usuarios, actuealmente sigue el problema que la app del conductor no sale el nombre ni viajes cuando cliente solicita poe whatsapp, aparte del nomre , modelo de carro y placa actualmente se deberia agregar color generalmente la ente tiene retentiva del color que de la placa

    Liberado el 25/5/2026
  • 1
    BugPlataforma

    mapa

    no aparece el mapa

    Liberado el 25/5/2026
  • 1
    BugPagos

    moneda

    La parte de recompensas no esta configurada para Euro.

    Liberado el 25/5/2026
  • 1
    BugDelivery

    banner

    No permite crear banner para delivery

    Liberado el 24/5/2026
  • 1
    BugPlataforma

    CLIENTE NO PUEDE REGRESAR AL CALCULAR PEDIDO

    SI EL CLIENTE QUIERE SOLICITAR UN SERVICIO, DESPUES DE INGRESAR DIRECCION Y PASAR A LA PAGINA DE ESCOGER EL SERVICIO (SEDAN, TAXI, ETC...), NO HAY FORMA DE REGRESAR A LA PAGINA ANTERIOR

    Liberado el 25/5/2026
  • 1
    BugApp móvil

    los codigos de referido y promocion

    los codigos de referido desaparecen de la app los codigos promocionales envian error al colocarlos en la app y no paracen las promociones en la pantalla de promociones de la app

    Liberado el 25/5/2026
  • 1
    IdeaOtro

    También tener un código para pasajero

    Cuando el pasajero pide el servicio de taxi debería de generarse un código o pin de 4 dígitos. Ese código se vincula con el conductor.... El pasajero al momento de subir dicta el código y el conductor le pone y se vincula el viaje para iniciar su viaje a desgino

    Liberado el 22/5/2026
  • 1
    BugPlataforma

    No se puede editar ni borrar los viajes programados

    en los viajes progrmados detro de la plataforma no permite borrarlos ni editarlos en la app muestra una hora distinta a la programada y tampoco se puede editar ni borrar

    Liberado el 22/5/2026
  • 1
    BugPlataforma

    Funcion de viajes programados

    1.- Fallo al programar viaje desde el mismo dia a hora futura en el celular 2.- Fallo al programar dia futuro y hora futura en el celular (no se registra en el panel) 3.- Fallo al asignar conductor en Panel (las funciones no responden)

    Liberado el 22/5/2026
  • 1
    BugDashboard

    No me registra el whatsapp en la app

    No me registra el whatsapp en la app

    Liberado el 22/5/2026
  • 1
    BugWhatsApp

    incentivación y fidelización

    A la hora que activó el check para enviar por WhatsApp y le doy guardar , ingreso nuevamente y sale el check apagado, sería bueno tener un desglose de los viajes solicitados por WhatsApp

    Liberado el 20/5/2026
  • 1
    BugDashboard

    COMISION PERSONALIZADA

    AJUSTES/SERVICIOS/COMISION PERSONALIZADA Si quiero crear una comision personalizada., al presionar Guardar cambios, no queda guardada

    Liberado el 20/5/2026
  • 1
    BugDelivery

    RECOGER EN TIENDA

    Ya aparece la opcion de recoger en tienda pero cuando realizo el pedido no hay ningun apartado donde yo pueda modificar si quiero delivery o pasar a recoger

    Liberado el 19/5/2026
  • 1
    BugOtro

    Pedidos / envios

    si el conductor inicia sesion , le aparecen pedidos "pendientes *aparecieron como 5 que ya estaban o cerrados o cancelados

    Liberado el 19/5/2026
  • 1
    BugDelivery

    Centro de viajes

    En el centro de viajes, es importante si el pedido es en efectivo Y HAY QUE PAGAR EN TIENDA (MODALIDAD Ajustes>general>gestion de efectivo>Modo de flujo de efectivo en delivery>Pago previo al negocio (conductor paga en pickup)), que muestre el TOTAL A PAGAR EN TIENDA, de esta forma puede tomar la decision si toma o no el pedido por el efectivo a pagar

    Liberado el 20/5/2026
  • 1
    BugDashboard

    Actualización

    Los viajes solicitados por WhatsApp no apetece el nombre y cantidad de viajes al cliente , en la opción de ver viajes en el Dashboard sale 0 kilómetros y 0 minutos , no permite calificar al conductor por medio de WhatsApp

    Liberado el 19/5/2026
  • 1
    BugPlataforma

    IDIOMAS

    No se ha actualizado el idioma italiano, o al menos mi plataforma no me lo permite ver. Cordiales saludos.

    Liberado el 20/5/2026
  • 1
    BugApp móvil

    idiomas

    Podrian por favor agregar el idioma italiano al sistema?

    Liberado el 15/5/2026
  • 1
    IdeaOtro

    Wallet top-up via SPEI

    Sería útil que los riders pudieran recargar su wallet directamente con SPEI sin pasar por tarjeta. En México la mitad de los clientes no tiene tarjeta y usan transferencias bancarias.

    Liberado el 19/5/2026
  • 1
    IdeaOtro

    Implementación de Módulo de Suscripciones (SaaS) para Conductores, Repartidores y Comercios

    Necesito migrar el modelo de negocio actual. Vamos a dejar de cobrar comisiones por cada viaje o pedido y pasaremos a un modelo de suscripción prepagada. El sistema debe restringir el acceso a los servicios de la plataforma basándose en la vigencia de un pago fijo mensual, semanal o diario. Especificaciones Técnicas: 1. Gestión de Perfiles y Roles: Crear una lógica de validación de suscripción independiente para cada rol: Conductores (Transporte), Repartidores (Logística) y Restaurantes (Comercios). Añadir en la base de datos los campos: status_suscripcion (Activo/Inactivo), fecha_vencimiento y tipo_de_plan. 2. Reglas de Negocio por Rol: Conductores y Repartidores: Si la suscripción está vencida, el sistema debe bloquear el switch de "Ponerse en línea" y mostrar un aviso para renovar el plan. Restaurantes: Si el comercio no tiene su suscripción activa, su perfil debe pasar automáticamente a estado "Invisible" o "Cerrado" para los usuarios en la app de cliente. 3. Modificación del Motor de Transacciones: Ajustar la lógica de la billetera (Wallet) para que, al finalizar un viaje o entrega, la comisión de la plataforma se calcule en $0.00. El total de la tarifa (menos impuestos si aplica) debe ir íntegro al saldo del prestador. 4. Panel de Administración (Backend): Necesito una sección para configurar los planes: Nombre del plan, duración en días y precio. Poder asignar planes específicos a cada categoría (ejemplo: Plan Moto, Plan Auto, Plan Restaurante). 5. Interfaz de Usuario (App de Socio/Comercio): Crear una pantalla de "Mi Suscripción" donde puedan ver los días restantes. Integrar un flujo de pago para renovar el plan usando el saldo de su propia billetera interna o pasarelas de pago existentes. 6. Notificaciones: Configurar alertas automáticas (Push y correo) 48 y 24 horas antes del vencimiento. Notas Adicionales: El objetivo es que el usuario sienta que la plataforma es una herramienta de trabajo que alquila por un precio fijo, permitiéndole maximizar sus ingresos diarios. Favor de confirmar si esta modificación afecta la arquitectura actual del flujo de pagos para revisarlo en una llamada.

    Liberado el 21/5/2026
  • 1
    BugApp móvil

    NO APARECE LA OPCION DE RECOGER EN EL LOCAL

    En la version de produccion solo aparece la opcion de delivery y no la de pasar a recoger en el negocio y si esta la opcion habilitada de retiro en el local

    Liberado el 14/5/2026
  • 1
    IdeaOtro

    Definir metas con beneficios para revendedores

    Para motivar al equipo de revendedores, seria bueno crear un sistema que permitas tener mas ganancia conforme se venda mas, por decir un ejemplo, si se llega a la meta de 20 ventas que el porcentaje de ganancia sea 35%, si llega a 50 ventas sea 40%, si llega a 100 ventas, el porcentaje de ganancia vaya aumentando hasta llegar al punto de buscar un 50% de ganancia, esto para tener motivacion y que los ingresos no se vean lineales, si no que aumenten conforme crezcan las ventas.

    Liberado el 21/5/2026
  • 1
    BugApp móvil

    PROBLEMAS CON EL REGISTRO

    buen dia , cmo lo manifete en el whatssapp tengo problemas con el registro d elso clientes, tanto de nates del dia de ayer como uno s d eoy mismo , no existe forma de verificr los documentos de los clientes en el panel clinetes , dnde dice editar solo aparece el nombre , el teelefno y el correo , ademas los clinetes pasajeros intentan cambiar desde sus perfiles y o le spermite realziar los cambios les made adjuntos ene l whatssapp mio +573013744333 fotos y evidncias de lña situacion, solpude cambair el telefno en el dashboard mas nada

    Liberado el 14/5/2026
  • 1
    BugApp móvil

    pantalla log in

    Esto aparece al hacer log in con una nueva mail en la app de delivery: soy pasajero, soy conductor, soy negocio. se deberia cambiar por soy cliente, soy rider, soy negocio. correcto?

    Liberado el 14/5/2026
  • 1
    BugApp móvil

    panatalla despues de log in

    la pantalla presenta dos opciones: soy pasajero o soy conductor. Eso supongo es para la app de taxi. Se podria quitar eso y escribir soy cliente, soy rider, soy negocio? para delibery? gracias.

    Liberado el 14/5/2026
  • 1
    BugApp móvil

    NO HA SIDO POSIBLE ACTUALIZAR APP VIA EN PLAY CONSOLE

    Continua la primera versión ,NO ACTUALIZA los Builder

    Liberado el 14/5/2026
  • 1
    BugDelivery

    NO APRACE EL REPARTIDOR

    Hice una prueba completa realizando un pedido desde la app. Todo el proceso de compra funciona correctamente hasta el momento en que, como negocio, marco el pedido como “listo” para enviarlo al repartidor. El problema es que la notificación o solicitud nunca llega a la app del repartidor, por lo que el pedido no se refleja ni puede ser aceptado para entrega.

    Liberado el 14/5/2026
  • 1
    IdeaWhatsApp

    incentivacion y fidelizacion

    Seria genial que asi como se envia un correo con la informacion de viaje , este una opcion para que se envie por whatsapp y con ello crear un modo de fidelizar y dar mayor seeguimiento al cliente, y poder filtrar tanto conductores como pasajero por email, fecha de nacimiento.

    Liberado el 20/5/2026
  • 1
    IdeaOtro

    COMISION REPARTIDOR

    LAS COMISIONES DE REPARTIDOR Y CONDUCTOR DEBEN SER DIFERENTES YA QUE SON MODELOS DE OPORTUNIDAD DIFERENTES, INCLUSO LA PANTALLA DE VIAJE COMPLETADO DEBE MOSTRAR INFO DIFERENTE, POR EJEMPLO, EL REPARTIDOR MUESTRA TOTAL COBRADO (QUE INCLUSO EL TOTAL ES INCORRECTO, YA QUE DEBERIA MOSTRAR VIAJE+PEDIDO+PROPINA+CARGO DE SERVICIO) QUIZAS EN RESUMEN, DEBERIA MOSTRAR UNICAMENTE "TU GANANCIA" MOSTRANDO UNA SOLA CANTIDAD COMO CUALQUIER APP, SERIA GANANCIA (VIAJE MAS PROPINA) MENOS RETENCIONES PARA MEXICO MENOS COMISIONES SI LAS HUBIERA

    Liberado el 15/5/2026
  • 1
    BugOtro

    SUMATORIA DE COBRO DE PEDIDO

    AL LLEGAR REPARTIDOR A ENTREGAR, SOLO ESTA COBRANDO PEDIDO Y ENVIO, FALTA EN LA SUMATORIA CARGO DE SERVICIO Y PROPINA ( VA A COBRAR INCOMPLETO). SUGIERO SOLO MOSTRAR EN ESE CAMPO EL TOTAL A COBRAR AL CLIENTE (NO DESGLOSE) "COBRAR AL CLIENTE $X.00"

    Liberado el 11/5/2026
  • 1
    BugOtro

    RECOLECCION DE PEDIDO

    AL LLEGAR A TIENDA, DEBERIA DE MOSTRAR (EN ESCENARIO DE PAGAR EN TIENDA) LA LEYENDA "PAGAR EN TIENDA $X.00" (SUGIERO SIN DESGLOSE) Y AL ENTREGAR DEBE DECIR "COBRAR AL CLIENTE $X.00, TAMBIEN SIN DESGLOSE, YA QUE COBRARA PRODUCTO, CARGO DE SERVICIO, PROPINA Y ENVIO (EL CARGO DE SERVICIO SE LE IRA A DEUDA CON EL APP)

    Liberado el 11/5/2026
  • 1
    BugOtro

    CODIGO DE PEDIDO NO VISIBLE

    EN MODULO DE CLIENTE, PARA RECIBIR EL PEDIDO DE REPARTIDOR TIENE QUE DAR UN CODIGO, PERO NO ES MUY VISIBLE (LETRAS NEGRAS), ES LA UNICA BURBUJA QUE LA TIENE NEGRAS, TODAS LAS DEMAS EN DIFERENTES ESCENARIOS ES BLANCA (YA QUE LA BURBUJA TENDERA A SE COLOR DOMINANTE (MAS OSCCURO), PUEDES VER LAS OTRAS COMO EJEMPLO

    Liberado el 11/5/2026
  • 1
    BugDelivery

    NO CONDUCTORES DISPONIBLES

    SI EL PEDIDO SE RECIBE O CREA MIENTRAS NO HAY CONDUCTORES DISPONIBLES, Y SE CONECTAN DESPUES, NO RECIBEN LA, OPORTUNIDAD Y/O SIGUE MOSTRANDO NO CONDUCTORES DISPONIBLES, ASI MISMO, SI UN REPARTIDOR LE CAE LA OPORTUNIDAD, NO HAY FORMA DE RECHAZRLA Y NO BRINCA A OTRO REPARTIDOR. SI ESTE LA ACEPTA Y SE REASIGNARA A OTRO, NO DESAPARECE DEL REPARTIDOR ORIGINAL (NO SE ACTUALIZA PANTALLA)

    Liberado el 14/5/2026
  • 1
    BugOtro

    Falla de compilación

    Sigue teniendo problemas al compilar este cliente, previamente se detectó un tema con el idioma italiano, no estoy seguro si persiste el error

    Liberado el 11/5/2026
  • 1
    BugOtro

    ERROR EN ICONO DE CARRO PARA SEGUIMIENTO

    El icono que en AJUSTES SE CONFIGURA EN APARIENCIA GENERAL PARA TODOS LOS SERVICIOS QUE EN MI CASO NO QUIERO USAR UN ICONO PERSONALIZADO PARA CADA SERVICIO SI NO EL GENERAL DE LA APP NO FUNCIONA EN CAMBIO APARECEN APUTADORES AZULES ESTO YA SE REPORTO Y PERSISTE NO SOLUCIONAN NADA LAS SUPUESTAS RESPUESTA DE SE SOLUCIONO EN TU PROXIMO BUILD VERAZ LA CONFIGURACION CORREGIDA,, FALSOOOOOO LLEVO SEMANAS PIDIENDO ESTO Y NADA

    Liberado el 11/5/2026
  • 1
    BugOtro

    QUIERO QUE LA ZONA QUE APARECE EN VIAJES EN VIVO SIEMPRE SEA LA ZONA QUE TENGO POR DEFECTO EN AJUSTES O POR LO MENOS QUE TENGA ACTIVA

    SI NO TENGO CONDUCTORES ACTIVOS NO APARECE LA ZONA DE LA CIUDAD QUE TENGO OPEERACION SI NO MEXICO ESTO LO DEBEMOS CORREGIR.

    Liberado el 11/5/2026
  • 1
    BugApp móvil

    NO APARECEN LAS FOTOS DE LOS CONDUCTORES EN LAS ETAPAS DEL VIAJE AL USUARIO SOLO AL CONDUCTOR

    En la app del conductor la foto del usuario funciona sin ningun contratiempo, pero en la app del USUARIO no aparece en ninguna ETAPA DEL VIAJE LA FOTO DEL CONDUCTOR ESTO ES SUPER IMPORTANTE PARA GARANTIZAR LA SEGURIDAD AL USUARIO DEL CONDUCTOR QUE LE RECOGE ESTO YA LO REPORTE PERO PERSISTE NO FUNCIONA NINGUNA DE ESTAS CORRECCIONES NECESITO QUE POR FAVOR NOS AYUDEN A COMPLETAR YA UNA APP MEDIANAMENTE ESTABLE Y NO SE PRESENTEN MAS BUGS.

    Liberado el 11/5/2026
  • 1
    BugOtro

    DESCRIMINACION DE TARIFA RECORRIDO RECARGOS EN ETAPA DE FINALIZACION DE VIAJE CONDUCTOR

    En la finalizacion del viaje cuando termina y saca el resumen de kilometros recorridos, tiempo de desplzamiento tarifa base etc, no aparece igual que la del usuario para la vista del usuario es mas completa y esta perfecta por que incluye todos los item y recargos pero en la vista del conductor no debe ser igual para ambos tambien solicitar colocar una nota que las tarifas incluyen redondeo para que los usuarios conductores lo sepan y sepan que se redondean el valor de la tarifa si es en centimos al entero mas proximo

    Liberado el 11/5/2026
  • 1
    BugApp móvil

    RETIROS EN BILLETERA (CONDUCTOR)

    Los retiros no funcionan correctamente cuando se envia la orden de retiro el sistema devuelve un mensaje como error de procesamiento, al refescar la app, muestra que si tomo la solicitud y lo pe en estado retiro con la etiqueta bank_name, deberia salir el nombre completo de la entidad bancaria escogida por el conductor seguido de los numeros de su cuenta de retiro y no los ultimos 4 digitos. Luego en el dasboard llega la alerta pero nuna vez aprobado solo aparece un estado que dice mis retiros sin icono solo aparece como completado pero el sado retirado no se descuenta de la billetera sigue apareciendo el monto completo y adicional en pendiente 25 mil no se si la logica esta pensada para un proceso manual pero no tiene sentido esto se habia reportado pero sigue estando igual.

    Liberado el 11/5/2026
  • 1
    BugApp móvil

    ERROR EN INGRESO A APP ANDROID

    Todos los usuarios que descargan al APP no pueden ingresar ingresan por google escogen el correo y cuando se supone debe ingresar se devuelve al login otra vez ya he lanzando los ultimos builds con la correccion supuesta de esta firma del proyecto en FIREBASE, pero nada sigue persistiendo tengo multiples usuarios dando quejas en la app por no poder ingresar llevo semanas en esto la AI no hace si no replicar esto por whatsapp pero no veo SOLUCION ESTOY YA DESESPERADO CON ESTA APLICACION NECESITO UNA SOLUCION URGENTE!

    Liberado el 11/5/2026
  • 1
    BugApp móvil

    Error en sincronizacion de viajes en APP iOS (usuarios) Android (Conductores)

    En las ultimas versiones tenemos problema con la sincronizacion de viajes el condunctor recibe el viaje de su lado sin problema, el fallo esta del lado del usuario con dispositivo apple, para el usuario sige viendo el contador de busqueda de viaje pero este ni se entera que ya el asignaron el conductor pasan los casi 3 minutos y le dice al usuario que no hay conductores cuando ya tiene el asignado eso es un error grave por que el conductor ya va en camino y el usario no se entera cancela la busqueda e inicia otra provacando una asignacion doble o simplemente deciste del viaje dejando al conductor en un viaje sin pasajero ese error lo tengo con las versiones 1.0.64, de igual manera no muestra el recorrido del taxi camino a su ubicacion asi como el recorrido del icono del asingado en ajustes para identificar el servicio en el MAPA. ni cuando el viaje se acepta y camino al destino, tampoco muestra el ICONO si no un apuntador AZUL generico para los carros en linea en el proceso de busqueda de servicio. Por favor solicito solucion pronta con este BUG lo llevo reportando hace mucho y tengo en problemas la operacion por esto quejas y viajes abandonados. GRACIAS!!!

    Liberado el 11/5/2026
  • 1
    BugPlataforma

    zona geografica

    no reconoce la zona de italia para trabajar.

    Liberado el 11/5/2026
  • 1
    BugApp móvil

    No muestra los banners

    en el dashboard cree un banner cumplimiento todos los requerimiento pero no se logra ver en la app

    Liberado el 11/5/2026
  • 1
    BugDelivery

    Pedidos completados delivery

    No deja ver los pedidos que se han completado intento abrir el pedido completado para ver los detalles y abre y cierra rapido

    Liberado el 11/5/2026
  • 1
    BugDelivery

    no llega al repartidor la notificacion de pedido

    hice el proceso un pedido y cuando marco en un negocio buscando repartidor no aparece el pedido en la app de repartidor

    Liberado el 11/5/2026
  • 1
    IdeaDashboard

    RETOS

    Seriaa bueno que se pudieran reactivar los retos al editarlos algo asi como APAGAR ENCENDER

    Liberado el 11/5/2026
  • 1
    BugWhatsApp

    No aparece número de viajes

    Los viajes solicitados por WhatsApp no permite calificar el viaje al cliente , al conductor no le aparece los viajes que tiene ese cliente ni sale el nombre además a la hora de finalizar no respete la moneda seleccionada

    Liberado el 11/5/2026
  • 1
    BugPlataforma

    cargar imagen

    no permite cargar foto el cuadro de texto en respuesta a solicitud de solucion de problemas.

    Liberado el 8/5/2026
  • 1
    IdeaDelivery

    Comisiones a negocios

    ahora para los negocios existe en el perfil de estos el asignar comisiones individuales, sugiero implementar tambien una comision separada para cuando solicitan repartidor ya que debido a que estos envion no son por ventas generadas en el app, no les podemos cobrar lo mismo; esta debe tener 2 opciones, por porcentaje de pedido y por cantidad $ fija de cobro por pedido (habra negocios que por el giro, el porcentaje no funcionaria, ahi les cobrariamos una cantidad fija por cada pedido)

    Liberado el 20/5/2026
  • 1
    BugDelivery

    cobro total al entregar pedido

    al entregar pedido, la cantidad al parecer solo muestra el envio y no el total (pedido, envio, propina y cargo de servicio), asi mismo esta info debe estar en la pantalla ANTES de ingresar el codigo de entrega y no al ya haber entregado

    Liberado el 7/5/2026
  • 1
    IdeaDelivery

    Poder asignar la categoria a un negocio ya creado

    Debería existir una opción para asignarle una categoría a un negocio que ya fue registrado, en caso de que el dueño no la haya seleccionado durante el proceso de registro.

    Liberado el 7/5/2026
  • 1
    BugApp móvil

    Error en registro de conductor

    Cuando el conductor esta en el paso #3, y desea regresarse al paso #1 por ejemplo para cambiar algo que, al darle el continuar manda la solicitud, luego no deja agregar las imagenes pendientes, muestra error.

    Liberado el 7/5/2026
  • 1
    BugDelivery

    similador (repartidor) no funciona

    en el simulador, al modulo de repartidor, no hace login o se mantiene desconectado (en el APK si funciona) si recibe pedidos, pero aun si se aceptan, no aparecen en pantalla.

    Liberado el 6/5/2026
  • 1
    BugDelivery

    codigo de recoleccion en tienda

    cuando llega un pedido a tienda, aparece un codigo de recoleccion, pero cuando un repartidor acepta el pedido, este desaparece, asi que cuando llega el repartidor a tienda a recolectar, ya no hay codogo de liberacion. este debe estar presente minimo hasta que se recolecte el pedido

    Liberado el 7/5/2026
  • 1
    BugDelivery

    asignacion manual de pedido

    al asignar manualmente pedido a un repartidor, no aparece en su pantalla aun cuando el admin y en el pedido ya indica que esta asignado a este.

    Liberado el 7/5/2026
  • 1
    BugDelivery

    pedidos en efectivo

    en el modulo de negocio, en pedidos en efectivo es importante que diga el pedido una vez listo o cuando llegue el repartidor "deberas cobrar al repartidor $.00", de otra forma se entregara sin cobro como si fuera pagado con tarjeta

    Liberado el 7/5/2026
  • 1
    IdeaApp móvil

    📌 Propuesta Funcional: Registro de Pasajeros desde la App de Conductores

    🎯 Objetivo Optimizar el proceso de adquisición de usuarios (pasajeros) durante la fase inicial de lanzamiento, permitiendo que los conductores registren pasajeros directamente desde su aplicación, sin necesidad de que el usuario descargue la app en ese momento. 🚧 Problema Actual Durante la operación en campo: Los conductores deben detenerse para: Pedir el celular al pasajero Descargar la app Completar el registro manual Esto genera: Fricción en el proceso Pérdida de tiempo operativo Menor conversión de nuevos usuarios 💡 Solución Propuesta Desarrollar una funcionalidad dentro de la app de conductores que permita: 👉 Pre-registrar pasajeros directamente desde la app del conductor ⚙️ Flujo Funcional El conductor accede a una opción: “Registrar pasajero” Ingresa datos básicos del pasajero: Nombre Documento Correo electrónico Número de teléfono El sistema: Crea un pre-registro del pasajero Genera automáticamente un link de descarga personalizado El pasajero recibe: Link vía WhatsApp o correo (Ej: link versión actual app – v81) Cuando el pasajero descarga la app: Sus datos ya están precargados Solo completa pasos mínimos (validación, contraseña, etc.) 🚀 Beneficios Para el negocio: Aumento en la conversión de usuarios Crecimiento acelerado de la base de pasajeros Reducción de fricción en onboarding Para conductores: Más facilidad para captar usuarios Mayor eficiencia operativa Incentivo directo para expandir la red Para pasajeros: Registro rápido y sin fricción Mejor experiencia inicial 🔐 Consideraciones Técnicas Validación de datos (correo / teléfono) Protección de datos personales Generación de tokens únicos por registro Integración con sistema de referidos (opcional futuro) 🧠 Mejora futura (opcional) Asociar el pasajero al conductor que lo registró Crear sistema de incentivos por registro efectivo Tracking de conversión por conductor 🎯 Conclusión Esta funcionalidad convierte a cada conductor en un canal activo de adquisición de usuarios, lo cual es clave en etapas tempranas. Es una solución simple, de alto impacto y alineada con el crecimiento orgánico del producto.

    Liberado el 20/5/2026
  • 1
    BugOtro

    inicio de sesion simulador

    llevo dias sin poder iniciar sesion en conductor - repartidor en el simulador, me muestra desconectado y no puedo recibir viajes

    Liberado el 6/5/2026
  • 1
    BugOtro

    PROBLEMAS EN REGISTROS AUN

    1. Las personas están actualizando sus documentos y quedan en esta pantalla y en el dash board no se reflejan los cambios entonces no puedo aprobar los cambios 2. ⁠parecen solo 100 clientes pero en la realidad hay más de 400 ,hablo de los pasajeros 3. ⁠que ha pasado con la subida a tiendas para el test de play store

    Liberado el 6/5/2026
  • 1
    BugDashboard

    ERROR EN LA BILLETERA DEL CONDUCTOR

    Aparece ese error en la app

    Liberado el 6/5/2026
  • 1
    BugPlataforma

    La aplicación debe admitir tamaños de página de memoria de 16 KB

    Para garantizar que su aplicación funcione correctamente en las últimas versiones de Android, Google Play requiere que todas las aplicaciones dirigidas a Android 15+ admitan tamaños de página de memoria de 16 KB.

    Liberado el 14/5/2026
  • 1
    BugDelivery

    recoleccion de pedido

    aqui hay varios puntos a resolver, -el repartidor ya acepto el pedido, pero en el negocio muestra todavia buscando repartidor. -en el simulador esta marcando error tanto como para ingresar credenciale s como para actualizar,si notas en la captura, pese a haber aceptado, ya no mostro el pedido -en el APK en el telefono, al llegar a tienda en pedidos en efectivo, no muestra cuanto pagar en tienda *digo en el apk porque ya no actualizo en el simulador -SI EL REPARTIDOR CANCELA LA RECOLECCION, SE CANCELA TODO EL PEDIDO, NO SOLO LA OPORTUNIDAD -AL ENTREGAR, SIGUE MARCANDO ERROR, YA NO PIDE EL CODIGO DE ENTREGA EN SOLICITAR REPARTIDOR, PERO NO PUEDE TERMINARSE

    Liberado el 6/5/2026
  • 1
    BugDelivery

    oportunidad de entrega (repartidor)

    en la oportunidad de envio (pedido / solicitud de repartidor) en pedidos en efectivo, no muestra cuanto tiene que pagar en tienda (valor del pedido/productos). esto es importante para el repartidor para saber si cuenta con el efectivo parra tomar la oportunidad)

    Liberado el 4/5/2026
  • 1
    BugDashboard

    simulador (log in repartidor)

    al querer comenzar a conducir el conductor / repartidor, marca este error y no acepta pedidos en el simuladro (en telefono con APK si ingresa y si recibe pedidos)

    Liberado el 6/5/2026
  • 1
    IdeaOtro

    INCLUIR PASARELA DLOCAL

    Seria bueno contar con la pasarela Dlocal tiene mayor cobertura y seguridad

    Liberado el 20/5/2026
  • 1
    BugDelivery

    Error al solicitar conductor desde el comercio

    me aparece ese error de prisma, y no se crea el pedido

    Liberado el 7/5/2026
  • 1
    BugDashboard

    sale este error en el simulador de app

    error en el simulador de apps que al entrar o recargar aparece

    Liberado el 6/5/2026
  • 1
    BugApp móvil

    Error al cambiar a modo repartidor en versión web

    El error que aparece en la franja roja en la parte inferior de la pantalla es el siguiente: Error al cargar datos: DioException [connection error]: The connection errored: The XMLHttpRequest onError callback was called. This typically indicates an error on the network layer. This indicates an error which most likely cannot be solved by the library. CabGo | v1.10.205 | Web | williamc.mkt@gmail.com Este es un error de la librería Dio (comúnmente usada en Flutter/Dart). Indica que la petición web falló a nivel de red antes de recibir cualquier respuesta del servidor. Las causas más comunes suelen ser: Problemas de CORS: El navegador bloquea la petición porque el servidor no permite el acceso desde ese dominio. Conexión a internet: Una caída momentánea o bloqueo por firewall/VPN. Servidor caído: El endpoint al que intenta conectar no está disponible. Certificado SSL: Si el sitio usa HTTPS y el certificado ha expirado o es inválido.

    Liberado el 6/5/2026
  • 1
    IdeaPagos

    Retencion de impuestos

    Para el mercado mexicano es necesario que la plataforma retenga los impuestos tanto de los conductores como de los negocios, sugiero añadir esos campos en el admin en los perfiles de negocios y conductores y hacer la retención por viaje / pedido. Al ofrecer el pedido / viaje mostraria cantidad total y al terminar el pedido / viaje mostraria la cantidad con la retencion descontada

    Liberado el 20/5/2026
  • 1
    BugPlataforma

    LIMITACION TERRITORIAL / LIMITACION DE CUNETA POR CELULAR /ERROR REGISTRO EN REVISION

    Buen dia sigo con los mismos problemaa anteriores, la IA nos reporta que los solucino pero no es verdad 1. error en el reistro de la spersonas adjunte en whatssapp la pantalal dcie REGISTRO EN REVISION Y no l es permite moverse ne sus usuarios de pasajero a conducotr y ya esta cuneta ha sido aprobada en el dashboard 2. mando servicios desde barranquilla colombia y aparecen en paraguay 3. aun pueden usar la misma cuneta ed dops celualres distintos 4. no me han enviado el link de subida de la app a mi cuneta de google play console lisdrive.console@gmail.com de mi cnueta de cabgo navantransportes.tics@gmail.com POR FAVOR NECESITAMOS HUMANOS RESOLVIENDO ESTO la IA nos esta mintiendo POR FAVOR NECESITAMOS HUMAOS RESOLVIENDO

    Liberado el 7/5/2026
  • 1
    BugDelivery

    Notas para el repartidor

    las notas para el repartidor (en este caso del negocio) no aparecen en el pedido a entregar (repartidor), si ves la captura, la del negocio dice "casa azul" en las nota donde muestra los totales, pero esa nota no aparece para el repartidor

    Liberado el 2/5/2026
  • 1
    BugDelivery

    codigo de entrega incorrecto

    en pedidos de producto, al entregar pedido al cliente muestra error en codigo de entrega. y en pedidos de solicitud de repartidor, pide codigo de entrega (no debe pedirlo ya que el cliente no tendra el app o info del pedido)

    Liberado el 4/5/2026
  • 1
    BugDelivery

    pantallas de ruta hacia negocio y hacia cliente

    en app del repartidor, Al aceptar pedido y al recolectar pedido, quedan bloqueados los mapas con la info del pedido, no bajan y no se ve la ruta en ambas pantallas (tambien no actualizaba la posicion del repartidor en estas, no se si ya se resolvio)

    Liberado el 2/5/2026
  • 1
    BugDelivery

    total a pagar pedido

    En la pantalla del negocio al llegar repartidor a pagar el pedido, muestra el total del pedido, deberia mostrar solamente total del producto (a cobrar), los empleados del negocio van a conbrar lo que diga el app.

    Liberado el 2/5/2026
  • 1
    BugDelivery

    sumatoria ganancia repartidor

    al aceptar el pedido no muestra el total con propina incluida, por ejemplo, en esta captura la ganancia es $40 mas $17 de propina, pero solo muestra $40, asi mismo en esta misma pantalla es importante que muestre resaltado cuanto debe de pagar en tienda (pago del pedido), quizas que en vez que diga "Producto", diga Deberas pagar en tienda" o algo asi

    Liberado el 2/5/2026
  • 1
    BugDelivery

    total de pedido en negocio

    En app de negocio, al recibir y gestionar pedido muestra el total del cliente y no el total de solamente el pedido (incluye envio y cargo de servicio, el negocio al querer gestionar finanzas este es el total que tendra a primera vista, que solo le compete el total de productos)

    Liberado el 2/5/2026
  • 1
    BugDelivery

    total del pedido

    cliente al hacer pedido, en la ultima pagima antes de reakizar pedido (pantalla de agreagar propina), muestra total solo del producto y propina, no el total a cobrar (mas envio y servicio)

    Liberado el 2/5/2026
  • 1
    BugPlataforma

    DUALIDAD EN CUENTAS

    me doy cuenyta qu euna misma cuneta de conductor opasajero la pueden abrir en varios telefonos , esto no da garantia ni seguridad a l aoperacion porque pueden hampones hacerse pasar por conducotres y cometer delitos, cad cuneta debe abrirse nada mas en un cleualr y si va a brise en otro debe ser por cambio de cleualr y bajo aprobacion de el admin ESTO ES SUPER URGENTE ya los conducotrs que prueban se estan quejando

    Liberado el 2/5/2026
  • 1
    BugPlataforma

    ZONAS Y PAISES

    yo abri paraguay para lanzar mi app, peor abri todso el pais, en el dash board coloque limitacion de 3 kilometros para recibir pedidos y estan haciendo pruebas y les sale el pedido d euna ciudad en otra , asi como mis pruebas en colomia le salen a ellos, por favor corregir para que fectivamente si uno pone limitaciones en kilometros esto funciones

    Liberado el 2/5/2026
  • 1
    BugApp móvil

    ERROR EN LOGUEO IOS EN VERSION ANDRIOD MARCA BLANCA

    AL INGRESAR A UN EQUIPO ANDRIOD E INGRESAR A LOGUARME APARECE TAMBIEN EL NOMBRE DE CABGO DIRECTAMENTE EN EL REGISTRO PERO AHORA DEL LADO DE ANDROID.

    Liberado el 2/5/2026
  • 1
    BugNotificaciones

    Bug de Notificaciones PUSH portal DASHBOARD

    Este error de notificacion VAPID sucede por que no estan sincronizados los dominios personalizados solo funciona correctamente el simulador de apps en cabgo.app asi como las notificaciones de su dasboard en el dominio raiz cabgo.app, pero en las marcas blancas este error persiste al igual que funciones como ver simulador de taxi.

    Liberado el 2/5/2026
  • 1
    BugOtro

    DIFERENCIA EN PRECIOS ABISMAL

    1. hay una diferencia entre los precios que oferta el sistema en la pantalla del que lo pide y el que l ellega al conducotr, por ejemplo pido un viaje de 1.5 kmts en taxi y me ofereta 8000 al pedirlo pero al aceptarlo el conducotr siube a 12000, asi en woman igual, pero al pedir el mismo servico en particular sube a 42,000 gs y si lo pido en peluditos sube a 240.000 y tengo los mismos valroes d e inico y por kilometros en todos

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    SINCRONIZACION DE SOLICITUD DE VIAJE EN IOS

    En la nueva compliacion de ios 1.0.50 -38, se pide viaje como usuario desde el iphone este si es aceptado no es notificado de que se tomo el viaje y asume que esta buscando el conductor cuando culmina el tiempo este dice que no hay carrros y se sale de la busqueda quedando el viaje activo en el lado del conductor pero sin sincronizidad con el usuario. Esto se habia reportado antes se solvento pero volvio a persistir.

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    Los recargos no se reflejan

    el total del recargo no se muesta en el total del viaje del usuario cuando lo solicita solo lo muesta cuando termina el viaje y no deberia ser asi debe darle el total del viaje y ya luego de finalizado si la descriminacion de ese total como se muesta hoy en la finalizacion del viaje, del lado del conductor deberia mostrar tambien el mismo detalle solo le da el total pero no muestra el recargo deberia mostrar todos los recargos por zona y recargo por tiempo y dias festivos tanto en la app del usuario y del conductor en la liquidacion final del viaje y en la toma del viaje el total cuando entre ya sea en la zona de solicitud o en la hora de recargo o feriado o domingo si aplica.

    Liberado el 29/4/2026
  • 1
    BugOtro

    CLIENTES

    desde hace mas de 7 dias aparecen 16 clientes en rojo y muchos clinetes realies se quejan que no puedne entrar a su app de pasajeros, creoq ue no esta dejando regstrar pasajeros , ademas seguimos eon el probelma que no se rgistran los numeorasd e telefonos de los pasajeros al hacr el registro

    Liberado el 29/4/2026
  • 1
    IdeaApp móvil

    Un mismo nombre en registro conductor y cliente

    Sería bueno que en ambos roles de conductor y cliente sea el mismo nombre ; número y foto de perfil y que si este lo quiere cambiar en modo pasajero cualquier dato quede en espera para aprobarlo manualmente como así es el del conductor , para más seguridad

    Liberado el 15/5/2026
  • 1
    BugDashboard

    PROBLEMAS CON EL REGISTRO / AUN

    1. TENGO MAS DE 340 CONDUCTRES REGISTRADOS Y YA ESTAN PRESNETANDO PORBLEMAS EEN SUS REGISTROS SE QUEDA EN L APANTALLA DE APROBACION, ALGUNOS NO ME APARCEN EN EL DASH BOARD Y OTROS NO PUEDEN CMABAIRSE AL PASAJERO SOLO SE LES QUEDA ALLI LA APNTALLA 2. SIGO SIN ENTENDER NI PODER PUBLICAR EN TIENDAS, NEECESITO ASISTENCIA 3. Y AUNN NO ENTIENDO COMO SE CONFIGURA LO DE LOS TELEFONOS EN ELPEFIL DE LOS PASAJEROS , CASI NUNGUNO TIENE NUEMOR DE CONTACTO

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    VIAJES POR ZONAS NO FUNCIONA

    VIAJES POR ZONAS CREE VARIAS ZONAS DENTRO DE LA MISMA CIUDAD QUE TINEN RECARGO DESDE Y HACIA DENTRO Y FUERA PERO ESTAS NO SE LIQUIDAN EL VIAJE NO LAS TOTALIZA

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    NO PERMITE VER EL CARRO DE LOS TAXIS DISPONIBLES EN EL MAPA

    NO PERMITE VER EL CARRO DE LOS TAXIS DISPONIBLES EN EL MAPA AL MOMENTO DE PEDIR EL VIAJE

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    NO PERMITE LOS VIAJES PROGRAMADOS

    NO PERMITE LOS VIAJES PROGRAMADOS NO RESPETA EL TIEMPO DE 3 HORAS ASI PONGAS 3 O 4 NO LO TOMA Y LO LANZA EN AUTOMATICO SOLO LO PROGRAMA CUANDO HAY UNA DIFERENCIA DE 8 HORAS

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    NO PERMITE VIAJES SIMULTANEOS PERSISTE

    NO PERMITE VIAJES SIMULTANEOS PERSISTE

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    ERROR EN DETALLE DE VIAJE USUARIO

    PERSISTE ERROR EN DETALLE DE KILOMETROS EN MIS VIAJES EN EL DETALLE DISTANCIA 0.0. KM

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    NO APARECEN LOS NOMBRES DE LOS USUARIOS LUEGO DE ACEPTADO EL VIAJE

    SI EL CONDUCTOR VE LA FOTO DEL PASAJERO CUANDO TOMA EL SERVICIO PERO CUANDO SE ACEPTA SALE EL NOMBRE QUE TENIA ANTES CUANDO SE REGISTRO EN EL CORREO ES DECIR SI SU CORREO SE LLAMA LOLA PALUZA ASI HAYA ACTUALIZADO SUS DATOS EL USUARIO EN LA APP DEL CONDUCTOR CUANDO LO TOMA APARECE BN SU NOMBRE PERO DESPUES QUE CARGA PARA DIRIGIRSE A LA RECOGIDA ESTE APARECE CON EL NOMBRE DEL CORREO YA NO “ALEJANDRO ALVAREZ” SI NO LOLA PALUZA Y SIN LA FOTO

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    PERSISTE BANDERA DE PAIS MEXICO EN NUMERO TELEFONICO EN EL PERFIL DEL USUARIO

    PERSISTE EN APARTADO MODIFICAR PERFIL LA BANDERA DEL PAIS DE MEXICO EN EL NUMERO DEL CELULAR DEL USUARIO

    Liberado el 29/4/2026
  • 1
    BugDashboard

    CARGA ERRONEA EN FOTOS DE USUARIO Y CONDUCTOR

    CARGA LA FOTO DEL USUARIO AL CONDUCTOR AL RECIBIR ESTE, EL VIAJE LUEGO DE ACEPTADO Y DIRIGIRSE YA NO APARECE MAS LA FOTO EN LA SIGUIENTE VISTAS Y ETAPAS DEL VIAJE HASTA LA FINALIZACION, ASI MISMO EL CONDUCTOR EN EL HISTORIAL DE VIAJES NO VE LA FOTO DEL USUARIO DEL LADO DEL USUARIO NO APARECE LA FOTO CUANDO SU VIAJE A SIDO TOMADO POR EL CONDUCTOR ASI COMO EN LAS DEMAS ETAPAS DEL VIAJE ASI COMO EN EL HISTORIAL DE VIAJES

    Liberado el 29/4/2026
  • 1
    BugOtro

    ERROR EN REGISTRO DE DATOS EN LA APP DE ANDROID Y IOS

    ASI PONGAS PEPITO PEREZ EN EL FORM EN LA APP NO SE ACTUALIZA EL NOMBRE NI EL APELLIDO LO TOMA COMO LO CAPTURO DEL NOMBRE DEL CORREO ELECTRONICO DE GOOGLE ESO VA A GENERAR UN PROBLEMA EN LA VALIDACION DE CONDUCTORES Y VIAJES DE USUARIOS

    Liberado el 29/4/2026
  • 1
    BugOtro

    AL LOGUARSE CON APPLE EN LA APP EN IOS EL FORMULARIO NO CARGA

    AL LOGUARSE CON APPLE EN LA APP EN IOS ESTE NO CARGA EL FORMA NO APARECE Y NO DEJA AVANZAR

    Liberado el 29/4/2026
  • 1
    BugOtro

    LOGUEO CON MARCA BLANCA EN IOS

    LA CORRECCION DEL LOGUEO EN IOS COMO LA NOTIFICARON NO ESTA FUNCINANDO ESTA ERRONEA SIGUE APARECIENDO CABGO. Y EL NOMBRE Y CORREO DE JONATAN Y APPHIVE EN LA ULTIMA COMPILACION FIGURA EL MISMO ERROR.

    Liberado el 29/4/2026
  • 1
    BugOtro

    ERROR EN RETIRO DE FONDOS

    EN LA NUEVA COMPILACION LANZADA AYER SEGUN ACTUALZACIONES EL RETIRO DE FONDOS NO FUNCIONA CORRECTAMENTE CUANDO SELECCIONA LA CANTIDAD QUE HAY DISPONIBLE EN WALLET ESTA DICE QUE DEBE CONFIGURAR INFORMACION BANCARIA PRIMERO Y NO SUCEDE NADA SI COLOCAS UNA CIFRA SUPERIOR ESTA SI FUNCIONA CORRECTAMENTE! ESTA ES UNA SOLICITUD QUE DESDE HACE MUCHO SE HA PEDIDO SIN EXITO!!

    Liberado el 29/4/2026
  • 1
    BugApp móvil

    MONTO DE RETITO MINIMO CONDUCTOR

    APARECE RETIRO MINIMO ES DE $50 PERSISTE

    Liberado el 29/4/2026
  • 1
    BugPagos

    no acepta los pagos con tarjeta

    al querer realizar el pedido con el método de pago con tarjeta en automático lo rechaza apareciendo la leyenda de cliente no encontrado

    Liberado el 29/4/2026
  • 1
    BugPagos

    no aparecen saldos negativos a conductor

    cuando terminan el viaje, y se cobra en efectivo, al conductor no le aparece saldo en negativo, y al comercio le aparece saldo positivo en automatico

    Liberado el 29/4/2026
  • 1
    BugPagos

    no se pueden eliminar tarjetas de credito

    no existe una opcion para eliminar las tarjetas agregadas

    Liberado el 29/4/2026
  • 1
    BugDelivery

    los codigos de cliente a repartidor no funcionan

    terminando la entrega se coloca el codigo del cliente y apaece como codigo invalido y no deja cancelar el viaje en la app de repartidor

    Liberado el 29/4/2026
  • 1
    IdeaDelivery

    pestana del sutio web

    aparaece como cabgo y deberia de aparecer el nombre de la empresa

    Liberado el 27/4/2026
  • 1
    IdeaIntegraciones

    Incorporar Servicio SPEI para mayor eficiencia en el servicio

    Para que se vuelva mas comodo el servicio, deberian implementar que los clientes añadan una tarjeta de crédito/debito para pago automatico de los servicios hacia una cuenta indicada

    Liberado el 15/5/2026
  • 1
    IdeaIntegraciones

    Opción de cancelar y poder modificar pago pendiente app pasajero

    Buen9s días sería excelente que esté la opción de cancelar cuando se está esperando al cliente ya que no está habilitado solo cuando sep acepto y no mientras se está esperando al cliente, además de la opción de poder modificar si un cliente el conductor puso no pago pide un modificar ese variable a sea para asumirlo o eliminar por error .

    Liberado el 27/4/2026
  • 1
    BugDelivery

    No me da el codigo cómo restaurante , para darcelo al delivery

    Ya e actualizado la aplicación en todas sus versiones y el código no aparece en el panel de administración ni el la aplicación del restaurante

    Liberado el 27/4/2026
  • 1
    BugApp móvil

    PROBLEMAS EN EL REGISTRO

    USANDO LA ULTIMA COMPILACION DEL DIA DE AYER 1. REGISTRE UN PASAJERO Y NO SOLICITO LOS DOCUMENTOS NI LA INFOR,ACION DE TELEFONO NOMBRE SEXO Y CORREO, SOLO LO MANDO DIRECTO A LA PNATALLA COMO SI SE HUBIERA REGISTRADO CON TODA L AINFO 2. REGIUSTRE UN CONDUCTOR Y ME HIZO REPETIR EL REGISTRO DOS VECES Y SALIA UN MENSAJE QUE DECIA QUE ESTABA INCOMPLETO EL REGISTRO PERO NO ERA A SI YA LO HABIA LLENAOD TODO 3. NO HE PODIDO SUBIRLA A GOOGLE PLAY CONSOLE, SOLICITO ASISTENCIA EN ESTO YA LES ENVIE LA INVOITACION MI CUNETA ES lixdrive.console@gmail.com tengo fecha de lanzamiento 30 de julio y no encuentro apoyo del soporte, se que estan muy ocupados pero necesto solucionar, al menos empezar ais como estamos y despues ir afinando pero necesito subir a tiendas y empezar

    Liberado el 27/4/2026
  • 1
    BugApp móvil

    No se visualiza número de viajes ni tipo de viaje

    El app del conductor no se aprecia el tipo de viaje que es "rápido" "PET", solo cuando está en el centro de viajes si se aprecia , igualmente con la cantidad de viajes que tiene el cliente solo se visualiza en el centro de viajes y no cuando le sale la notificación del viaje

    Liberado el 27/4/2026
  • 1
    BugApp móvil

    No me permite publlicar en tienda playstore

    la cuenta en Play Consolé es : viatechsolutionscolombia@gmail.com la cuenta cabgo es: garzonusme2@gmail.com No se si es la diferencia de cuenta la que no engancha la invitación!

    Liberado el 27/4/2026
  • 1
    BugNotificaciones

    ASIGNACION DE SERVICIO FALLIDA POR FALTA DE NOTIFICACIONES A CONDUCTORES O REPARTIDORES

    En las pruebas de clienta la solicitar un servicio para traslado, el celular se queda buscando, aunque haya conductores no les envia la notific acion de servicio, lo mismo sucede cuando el pedido sale del negocio, no envia la notificacion a los repartidores. que debo de hacer ?

    Liberado el 27/4/2026
  • 1
    BugWhatsApp

    CONFIGURAR CANALES

    No permite configurar el Whatsapp

    Liberado el 27/4/2026
  • 1
    BugWhatsApp

    No permite enlazar whatsapp

    Doy clic en el enlace de WhatsApp, me lleva a Facebook, pero no pasa de ahí. Evidencia en la imagen

    Liberado el 27/4/2026
  • 1
    IdeaDashboard

    Personalizar el Dashboard para el Contexto del Pais

    Aun hay cosas de Mexico que salen en el dasboard y seria bueno que al darse de alta te cargue una personalizacion propia para cada pais con sus propios campos y personalizaciones el Dashboard carece de esto.

    Liberado el 27/4/2026
  • 0
    BugOtro

    canary-connect-taxi (Juanma): ofertas de viaje a conductores WHATSAPP se marcan SENT pero Meta las DESCARTA fuera de la ventana 24h (free-form sin template)

    Conductores en notificationChannel=WHATSAPP no reciben las ofertas de viaje pese a estar ONLINE. Diagnostico en codigo+DB: 1) whatsapp-offer.ts -> sendTripOfferWhatsApp() envia la oferta con sendButtonsMessage() (interactive/button, FREE-FORM, NO template). Ese tipo de mensaje solo lo entrega WhatsApp Cloud API dentro de la ventana de 24h (el conductor debe haber escrito al numero en las ultimas 24h). Fuera de la ventana Meta responde error 131047 y NO entrega. 2) En sendButtonsMessage (src/lib/whatsapp-messaging.ts), cuando !response.ok se hace console.error + fallback a sendTextMessage y NO se propaga el fallo; sendTripOfferWhatsApp hace 'return true' sin comprobar el messageId -> TripNotification.status queda SENT aunque Meta lo rechazo. Por eso el panel dice 'enviado' y al conductor no le llega nada. Evidencia canary-connect-taxi: driver Jose (phone ...7596), ONLINE, notificationChannel=WHATSAPP; ultimo INBOUND del conductor al numero = 2026-07-17 19:05 (7 dias). TripNotification 07-22..07-24 todas status=SENT, ninguna DELIVERED. Driver Taxi (...9417) escribio 2026-07-24 05:48 -> su ventana SI esta abierta ahora. Canal usado: wa_1264684436722839 audience=BOTH, sin accessToken de tenant (envia con token central). Mismo tipo de bug ya resuelto para reengagement (cmqd4ha37 'Reengagement auto-send manda free-form a ventanas 24h cerradas -> 100% fallan', RELEASED), pero la ruta de OFERTA A CONDUCTOR no quedo cubierta. Fix propuesto: (a) enviar la oferta de viaje al conductor via TEMPLATE aprobado (utility, con quick-reply Aceptar/Rechazar) para que entregue fuera de la ventana 24h; (b) marcar TripNotification=FAILED (no SENT) cuando Meta rechaza, y registrar errorMessage con el codigo de Meta; (c) para drivers con app instalada + fcmToken, fallback a push. Impacto: cualquier tenant con flota WhatsApp-only y conductores que no escriben en 24h queda sin recibir viajes en silencio.

    Liberado el 24/7/2026
  • 0
    BugOtro

    Campaña push queda en DRAFT sin forma de enviarla/editarla/borrarla cuando el send falla

    Pantalla: Panel > Notificaciones (notifications-client.tsx) + endpoints push-campaigns. FLUJO ROTO: handleCreateAndSend hace 2 llamadas NO atomicas: (1) POST /api/push-campaigns crea la campana en status DRAFT, (2) POST /api/push-campaigns/{id}/send. Si el send falla (p.ej. recipients.length===0 -> 400 "No hay destinatarios"), la campana YA quedo creada como DRAFT con totalRecipients=0. El dialogo de compose NO se cierra pero el borrador huerfano queda en la lista. DEAD-END EN UI: un DRAFT no tiene NINGUNA accion. En la fila de la tabla solo hay un boton Eye (ver). El detail dialog es solo-lectura (footer solo Cerrar). No hay boton Enviar, ni Editar, ni Borrar para un DRAFT. => el dueno no puede reenviarlo, ni cambiar la casilla excludeDualProfile, ni eliminarlo. Queda atascado para siempre. CASO REAL super/Super Ride (Lima, FULL, conv 416414): 1 DRAFT (id 369f51a4-90a4-4eb1-909d-79efc4ab42cc, ALL_DRIVERS, excludeDualProfile=true, totalRecipients=0). Tiene 2 drivers, 1 con fcmToken, y ese driver es dual (telefono tambien en Customer) -> excludeDualProfile lo dropea -> 0 destinatarios -> send 400 -> DRAFT huerfano. El dueno reporto textual: "no puedo entrar a desmarcar" y "ademas sale como borrador". FIX SUGERIDO: (a) permitir Enviar/Editar/Borrar un DRAFT desde la lista o el detail dialog; y/o (b) hacer el flujo atomico -> si el send falla por 0 destinatarios, NO dejar el DRAFT huerfano (o mostrar el motivo y ofrecer editar la audiencia/casilla dual ahi mismo). Idealmente validar destinatarios>0 ANTES de crear la campana.

    Liberado el 24/7/2026
  • 0
    BugOtro

    teo-154a: habilitar login de marca (Google/Apple) en dominio propio app.teoperu.com

    Victor/Taruca (teo-154a, PRO). app.teoperu.com restablecido pero el login solo muestra Continuar como visitante: sin botones Google ni Apple. Causa: Company.hideGoogleLogin=true (oculta AMBOS botones por diseno; login_screen.dart:342 / social_login_buttons.dart), seteado para no mostrar consent generico Cabgo porque el tenant esta en el POOL COMPARTIDO cabgo-pool-3 (FirebaseProject.isPublicPool=true), no en proyecto Firebase de marca. Para activar Google/Apple con marca TEO en app.teoperu.com: (1) OAuth/branding propio para que el consent diga TEO, (2) app.teoperu.com en authorized domains, (3) hideGoogleLogin=false. Prometido avisarle por el hilo cuando quede.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Delivery: lista de negocios (selector operador/express) no hace scroll, solo el buscador

    rapi2 (Pavel): en el listado de negocios del panel para crear pedidos express/mandado, el scroll no arrastra (la lista no se desplaza con dedo/rueda); solo se navega por el buscador, que SI funciona. Afecta seleccion de negocios cuando hay varios. Revisar overflow/scroll del contenedor de esa lista.

    Liberado el 24/7/2026
  • 0
    BugOtro

    El endpoint de dominios custom reporta verified:true cuando el CNAME NO existe en DNS (NXDOMAIN) — nos hace decirle al cliente que su dominio ya quedo cuando no resuelve

    ## El problema El endpoint de dominios custom (`/api/ai-agent/custom-domain` y la superficie que expone `dnsRecords` + `verified`) devuelve **`verified: true`** para dominios cuyo CNAME **no existe en el DNS publico**. ## Verificacion (dig contra DNS publico) Tenant navan-drivers (Orlando), tres subdominios provisionados: ``` pideydale.navandrivers.com.co -> CNAME 34c6221a38568601.vercel-dns-016.com RESUELVE (Colombia, real) paraguay.navandrivers.com.co -> NXDOMAIN NO existe guatemala.navandrivers.com.co -> NXDOMAIN NO existe ``` Los dos que no resuelven (PY y GT) el endpoint los da como `verified: true` con `dnsRecords` incluidos. Solo Colombia esta realmente creado en el registrador. ## Por que importa El CNAME lo tiene que crear **el cliente** en su zona DNS (la de `navandrivers.com.co`). Nuestro lado solo registra el dominio en Vercel y entrega los registros a crear. Pero el endpoint marca `verified: true` **antes** de que el cliente cree el registro, es decir marca como verificado algo que fisicamente no resuelve. El riesgo directo: en un tick anterior le dijimos a Orlando que le **provisionamos sus dominios propios para PY y GT**. Si nos fiamos del `verified: true` del endpoint, le confirmamos al cliente que su dominio quedo listo — y cuando el o sus usuarios lo abren, **no carga** (NXDOMAIN). Es una promesa que se rompe sola. ## Que convendria 1. Que `verified` refleje una **comprobacion real de DNS** (resolver el CNAME y confirmar que apunta al target de Vercel) en vez de marcarse true al crear el registro del lado nuestro. 2. Mientras tanto, un estado intermedio claro tipo `pending_dns` para no confundir 'dominio registrado en Vercel' con 'dominio resolviendo'. ## Mitigacion en soporte (ya aplicada) Nunca confiar en el `verified` del endpoint para dominios custom: **verificar con `dig`/`curl` contra DNS publico**. A Orlando se le entregaron los dos CNAME exactos (target per-tenant `34c6221a38568601.vercel-dns-016.com`) y donde crearlos, en vez de decirle que ya estaban listos. ## Origen Detectado por la terminal Support en el loop de barridos /sweep, 24-jul-2026, al verificar por que los dominios de PY/GT de navan-drivers seguian sin cargar pese a figurar como verificados.

    Liberado el 24/7/2026
  • 0
    BugOtro

    Login social de pasajero no verificaba el ID token (Google/Apple) — identidad tomada del body

    Las rutas /api/mobile/rider/auth/google y /auth/apple aceptaban el token como cadena opaca y tomaban googleId/appleId/email del cuerpo del request, emitiendo un JWT móvil válido sin verificar la credencial. Apple solo comparaba un claim nonce sin validar la firma. Afectaba a todos los tenants. La ruta business-portal/auth/google ya hacía verifyIdToken, confirmando que era un descuido. Corregido en PR #433: nuevo src/lib/auth/social-token-verifier.ts que valida firma (certs de Firebase/Google, JWKS de Apple), iss, aud del tenant resuelto (proyecto Firebase + default), expiración y nonce; la identidad ahora sale del token verificado. Medición prod: 0 tenants con logins sociales activos quedan sin audiencia (los 70 sin proyecto propio caen en el default cabgo2-app, aceptado). El conductor no repite el patrón (login social unificado pega a estas mismas rutas; login propio es email+password). Rechazos quedan en AppErrorLog (social_auth_rejected:*) sin PII. Este folio es el rastro propio del hallazgo. --- _Reported via AI agent: AI agent — loop técnico (ticket cmrqn0xn, security one-pager)_

    Liberado el 24/7/2026
  • 0
    BugOtro

    Un lead de taxi que abre su demo desde WhatsApp NO tiene ninguna forma de entrar: el login es solo Google/Apple y el boton de invitado no existe sin catalogo

    ## El problema, en una frase Le mandamos la demo a un lead de taxi por WhatsApp, el la abre ahi mismo, y **no puede entrar de ninguna manera**. No es su telefono ni un error suyo: es estructural. ## Los tres hechos que se combinan 1. **El login de la app no tiene correo y contrasena.** Solo Google y Apple (`login_screen.dart`). 2. **El boton de "entrar como invitado" solo se renderiza si el tenant tiene catalogo navegable** (`login_screen.dart:345-360`, gate `hasGuestBrowsableCatalog`). Un tenant de **taxi puro no tiene catalogo** ⇒ ese boton no aparece. 3. **El webview de WhatsApp bloquea el sign-in de Google.** Es una restriccion del propio Google para navegadores embebidos. Resultado: en una demo de taxi abierta desde WhatsApp **no queda ninguna via de entrada**. Ni Google (bloqueado), ni invitado (no existe), ni usuario/clave (no existe). ## Por que importa comercialmente Esta es exactamente la situacion de casi todos nuestros leads: llegan por WhatsApp, les mandamos el link de la demo por WhatsApp, y la abren desde ahi. **El primer contacto con el producto termina en una pantalla de la que no se puede pasar.** El lead no concluye "debo abrirlo en Chrome": concluye **"esto no funciona"**. Y la mayoria no lo dice — simplemente deja de responder. En el caso que destapo esto (Ronald, Alajuela, conv 423652) el cliente si insistio, y su tenant tiene **0 conductores y 0 clientes registrados**: nunca paso del login pese a varios intentos y a que ya le habiamos explicado como probar. ## Lo que hace soporte hoy (parche, no solucion) Explicarle que copie el link y lo pegue en Chrome, y ofrecerle que **nosotros le disparemos el viaje de prueba desde el backend**. Funciona, pero solo para los leads que se quejan; los que se van en silencio no se recuperan. ## Ideas de arreglo (por orden de impacto) 1. **Permitir el modo invitado tambien en tenants sin catalogo** — al menos para demos. Que el lead pueda ver la pantalla de pedir un viaje sin autenticarse es justo lo que queremos que vea. 2. **Detectar el webview embebido** y mostrar un aviso claro con boton "Abrir en el navegador" en vez de dejar que el sign-in falle en silencio. 3. Ofrecer una via de entrada alternativa para demos (enlace magico, codigo, o un usuario de prueba pre-creado que se entregue junto con el link). ## Origen Detectado por la terminal Support al diagnosticar por que un lead no lograba entrar a su demo, 24-jul-2026. Se verifico en el codigo del login y en la base del tenant (0 Driver, 0 Customer).

    Liberado el 24/7/2026
  • 0
    BugOtro

    Copy publico del plan FULL promete independencia que NO entregamos (Sin dependencia de terceros + FAQ conectar la app a tu propio backend)

    REPORTADO POR UN REVENDEDOR (Trafiqo, conv 423639) y VERIFICADO EN VIVO en www.cabgo.app/precios. Tiene razon: nuestro copy publico del plan FULL contradice lo que realmente entregamos y contradice nuestra propia doctrina interna. == EVIDENCIA 1 — bullet de la tarjeta de plan == src/app/(marketing)/precios/pricing-page-client.tsx:198 (y su gemelo EN linea 205) Features del plan Full ($999): [Todo lo de Pro, Codigo fuente completo (ZIP), Modificable por tu equipo, 'Sin dependencia de terceros'] / EN: 'No third-party dependency'. Mismo bullet duplicado en el dashboard del cliente: src/i18n/messages/plan.es.ts:225 y plan.en.ts:191 (seccion Mi Plan). Verificado en produccion: curl https://www.cabgo.app/precios devuelve literalmente 'Sin dependencia de terceros'. == EVIDENCIA 2 — la FAQ de la MISMA pagina ofrece desconectarse == src/app/(marketing)/precios/pricing-page-client.tsx:437 (ES) / :439 (EN), pregunta 'Que incluye el plan Full con codigo fuente?': '...Importante: el codigo del backend no se entrega. Puedes seguir usando nuestro backend con tu suscripcion activa O CONECTAR LA APP A TU PROPIO BACKEND SI PREFIERES OPERARLO POR TU CUENTA.' Verificado en produccion (mismo curl). == LO QUE REALMENTE ENTREGAMOS == - src/app/api/apps/source-download/route.ts: exige appPlan === 'FULL' y sirve la PLANTILLA DE LA APP FLUTTER. No hay descarga de backend en ninguna ruta. - Doctrina interna (project_full_plan_source_code_scope.md): 'No es un fork independiente — el codigo de la app sigue conectandose a NUESTRO backend'; 'si el cliente quiere correr todo independiente con su propio backend, tendria que desarrollarlo el mismo — eso NO es un servicio que ofrecemos'. - src/lib/cabgo-product.ts:68 lo dice bien: 'Backend de Cabgo sigue corriendo en plataforma compartida — el operador NO mantiene servidor propio, sigue siendo SaaS'. O sea: la superficie LLM/agent-md es correcta y la pagina de precios es la que esta mal. == POR QUE ES GRAVE (riesgo comercial, no cosmetico) == Un revendedor leyo 'Sin dependencia de terceros' y le vendio a su cliente que con el FULL podia montar todo en su servidor y dejar de pagar la mensualidad. Cuando soporte le dijo la verdad, su respuesta textual fue: 'Entonces esta mal la descripcion del plan Full, porque ahi dice Sin dependencia de terceros'. Un FULL vendido bajo esa promesa termina en disputa/chargeback y en un revendedor quemado. == FIX PROPUESTO == 1. Cambiar el bullet 'Sin dependencia de terceros' / 'No third-party dependency' por algo veraz: 'Codigo de la app modificable por tu equipo' o 'Sin depender de nosotros para cambiar tu app'. Los 3 lugares: pricing-page-client.tsx (ES+EN) y plan.es.ts/plan.en.ts. 2. Corregir la FAQ: quitar 'o conectar la app a tu propio backend si prefieres operarlo por tu cuenta' (no es un producto que ofrezcamos, no hay contrato de API ni documentacion para eso) y dejar explicito que la mensualidad de operacion sigue corriendo en todos los planes, FULL incluido. 3. Anadir a la tarjeta del FULL una linea de alcance: 'Codigo fuente de la app movil (Flutter). El backend, el panel y la infraestructura los seguimos operando nosotros.'

    Liberado el 24/7/2026
  • 0
    BugOtro

    CompanySettings.surgeEnabled/surgeMultiplier no llega NUNCA al precio: se puede activar la tarifa dinamica a nivel empresa, responde exito, y no cambia nada

    ## El problema Existen **tres** mecanismos distintos que en el producto se llaman o parecen *tarifa dinamica*, y **solo dos afectan el precio real**: 1. **`ZoneServiceConfig.surgeEnabled` / `surgeMultiplier`** -> **SI aplica**. Es lo que lee el calculo de tarifa (`fare-calculator.ts:218-219`, que toma el surge de `svcConfig`, es decir de la config por zona+servicio). Caveat conocido: es **plano 24/7**, no sube ni baja por demanda, y exige `useCustomPricing=true`. 2. **`CompanyTariffRule`** (*Tarifas Especiales*) -> **SI aplica**. Es el unico mecanismo por **franja horaria / dia / fecha**, en fijo o porcentaje, aditivo, en la zona horaria del tenant. 3. **`CompanySettings.surgeEnabled` / `surgeMultiplier`** (+ `surgeAutoEnabled` y la tabla `ZoneSurge`) -> **NO aplica**. No aparece ningun consumidor en el camino de precio. ## Verificacion Se rastreo el uso de esos campos en todo `src/`: - `fare-calculator.ts` toma el surge **exclusivamente** de la config por zona/servicio (`svcConfig.surgeEnabled` / `svcConfig.surgeMultiplier`, lineas 218-219). Cuando no hay config de zona, cae a `surgeEnabled: false`. - Los campos de `CompanySettings` solo se leen para **exponerlos**: `/api/mobile/zones/surge` (informativo), `/api/zones/surge`, `/api/v1/surge` y `/api/v1/settings`. - `getSurgeForLocation` (surge-service) solo lo consume la ruta informativa `/api/mobile/zones/surge`. ## Por que importa **`/api/v1/surge` permite ACTIVARLO por PATCH y responde con exito**, incluso dejando un resumen tipo `Surge -> enabled=true, multiplier=1.5x`. Un operador (o nosotros desde soporte) puede activar la tarifa dinamica, ver la confirmacion, y **el precio que paga el pasajero no cambia jamas**. No hay ningun aviso de que ese interruptor no hace nada. El riesgo concreto para el negocio: un tenant cree que tiene tarifa dinamica activa en hora pico, cobra lo mismo de siempre, y **descubre el hueco cuando revisa sus numeros** — o peor, nunca lo descubre y simplemente gana menos. ## Que convendria Cualquiera de estas tres, en orden de preferencia: 1. Que los campos de `CompanySettings` funcionen como **valor por defecto** que el calculo aplique cuando la zona no define surge propio. 2. Si la decision de producto es que la dinamica vive solo por zona/servicio, **quitar los campos de nivel empresa** (o dejarlos como solo-lectura) y que `/api/v1/surge` deje de aceptar el PATCH. 3. Como minimo, que la respuesta del PATCH **avise explicitamente** que ese ajuste no afecta al precio y que hay que configurarlo por zona. ## Nota de soporte Mientras tanto, desde soporte **no se debe prometer tarifa dinamica automatica por oferta/demanda a ningun cliente**. Lo que si existe y se puede ofrecer con honestidad es: multiplicador por zona (plano) y *Tarifas Especiales* por franja horaria/dia/fecha. ## Origen Detectado por la terminal Support al responderle a un cliente (Elison, MotoManaus, Brasil) que preguntaba por precios dinamicos en hora pico. Se le ofrecio la solucion que si funciona (`CompanyTariffRule` con valor fijo en el pico) y se le dijo de frente que el multiplicador tipo Uber no existe.

    Liberado el 24/7/2026
  • 0
    BugOtro

    Tooling: soporte no puede prender las fotos de evidencia de delivery (deliveryRequirePickupPhoto/DeliveryPhoto) por ningun endpoint

    Caso Yev/yevfood (conv 423202): el cliente pidio explicitamente la foto de prueba de entrega. La funcion EXISTE completa (CompanySettings.deliveryRequireDeliveryPhoto -> FoodOrder.deliveryPhotoUrl, captura en active_ride_screen y visualizacion en Viajes en Vivo), pero desde soporte NO se puede activar: - PATCH /api/ai-agent/company-config: el campo no esta en el schema zod ni en la allowlist. - PATCH /api/assistant/companies/{id}/settings: responde 'Field deliveryRequireDeliveryPhoto is not modifiable via the assistant API'. - No hay endpoint /api/ai-agent/delivery/settings (solo businesses, products, settle-balance, variations). Resultado: hubo que devolverle la tarea al dueno con instrucciones de click, en vez de dejarselo puesto y verificado. PETICION: exponer en PATCH /api/ai-agent/company-config (campos planos) los toggles de la seccion 'Confirmaciones y evidencia' de Delivery: deliveryRequirePickupPhoto, deliveryRequireDeliveryPhoto, deliveryRequireCustomerCode, deliveryRequirePickupCode, deliveryReceiptEnabled. NOTA COLATERAL (verificar, posible bug aparte): en el flujo FoodOrder puro (delivery_order_detail_screen.dart) el boton 'Entregue el pedido' llama _performAction('deliver') con body VACIO -> no manda ni 'code' ni 'photoUrl', mientras el backend driver/delivery/orders/[id]/deliver/route.ts:83-102 exige 'code' cuando deliveryRequireCustomerCode=true (default TRUE) y 'photoUrl' cuando deliveryRequireDeliveryPhoto=true. En yevfood no se manifiesta porque sus pedidos llevan tripId y confirman por el flujo Trip/Express (active_ride_screen), que si captura ambos. Revisar si algun tenant usa la pantalla FoodOrder pura: ahi la entrega quedaria bloqueada con 400 MISSING_DELIVERY_CODE.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Delivery: el repartidor ve su ganancia BRUTA (envio + propina) sin descontar su comision, y la propina no se desglosa en la pantalla de Ganancias

    Reportado por Deivith / Aztek (conv 421774) el 24-jul: 'cuando se finaliza el pedido el repartidor nada mas ve lo de su ganancia pero no se integra la propina... seria muy importante que si el cliente selecciona que hubo propina desde un principio, el sistema lo pueda desglosar en sus ganancias del reparto al igual que con tarjeta'. VERIFICADO EN CODIGO (2 gaps distintos): 1) BUG DE DINERO — delivery_order_detail_screen.dart:422 calcula `driverEarnings = deliveryFee + tip` y lo pinta en :558 como 'Total a recibir' (card 'Tu ganancia'). NO resta la comision del repartidor (deliveryDriverCommissionRate). Con el pedido real FD-E2TUFNVT de Aztek (envio 35, propina 30, comision 10% = 3.50) la pantalla dice 65 cuando lo que realmente le queda son 61.50. Misma familia que cmry1ocm8 (active_ride_screen:3593 muestra tarifa bruta ignorando NET_EARNINGS) pero en la superficie de delivery. 2) GAP DE DESGLOSE — la pantalla de Ganancias del conductor (earnings_screen.dart) solo pinta total / comisiones / neto. La propina SI entra en el total (api/mobile/driver/earnings/route.ts:204 suma deliveryFee + tipAmount) pero NUNCA aparece como renglon propio, ni en efectivo ni en tarjeta. El unico lugar donde hoy se ve 'Propina' es el detalle del pedido, y solo si showFareBreakdownToDeliveryDriver != false (en Aztek esta en true). PEDIDO DEL CLIENTE: que la propina se desglose como renglon propio en las ganancias del repartidor al cerrar el pedido, en efectivo y en tarjeta, y que el total mostrado sea el NETO real. Datos del tenant: demo-andale-delivery-6306684c (Aztek), deliveryCashFlowMode=DEBT, deliveryDriverCommissionRate=0.10, showFareBreakdownToDeliveryDriver=true.

    Liberado el 24/7/2026
  • 0
    BugOtro

    Fechas timestamp-without-time-zone leidas por node-pg se desplazan con la TZ del proceso — casi nos hace afirmar lo contrario de la verdad a un cliente

    ## Que paso Durante un barrido de soporte habia que decidir si la build `1.0.179` de apolo-food era anterior o posterior al despliegue de un fix. Se consulto `AppBuild."createdAt"` con node-pg y se imprimio con `.toISOString()`: ``` to_char("createdAt",'YYYY-MM-DD"T"HH24:MI:SS') -> 2026-07-23T20:14:55 (valor REAL en la columna) createdAt.toISOString() -> 2026-07-23T18:14:55Z (2 HORAS MENOS) TZ del proceso: Europe/Berlin (+02:00) ``` La columna es `timestamp without time zone` y guarda UTC, pero **node-pg la convierte a `Date` interpretandola en la zona horaria del PROCESO**. Al imprimirla en UTC, el valor sale desplazado tantas horas como el offset local. ## Por que importa mas alla del caso puntual Con ese dato desplazado se concluyo que la build era ANTERIOR al fix y que el cliente necesitaba recompilar. Era falso: la build es posterior y si traia el fix. El error se detecto porque otro agente lo verifico empiricamente (lanzo una build a una hora conocida y comparo), pero pudo haber terminado en un mensaje equivocado a un cliente que lleva meses esperando ese arreglo. **Dos horas de desfase alcanzan para invertir cualquier comparacion**: build vs deploy, trial vencido o no, ticket movido antes o despues de una respuesta, ventana de 24h de WhatsApp abierta o cerrada. ## Alcance a revisar (esto es lo que no se pudo verificar desde soporte) 1. **Cualquier codigo de la app que compare fechas leidas por Prisma/pg** y corra en un proceso cuya TZ no sea UTC. Si los servidores de produccion corren en UTC el riesgo es nulo ahi, pero conviene confirmarlo explicitamente (Vercel, workers de build, cron jobs, el Mac Mini de iOS y el server de Android pueden no compartir TZ). 2. **Scripts operativos y de agentes** que leen fechas de la DB: hoy corren en un runner en `Europe/Berlin`, asi que TODOS los que impriman `Date` estan desfasados 2 h en verano y 1 h en invierno. 3. Si alguna de esas fechas alimenta un calculo de vencimiento (trials, cupones, expiraciones de sesion de Stripe), el desfase se convierte en una decision de negocio equivocada. ## Mitigacion inmediata que ya se aplico en soporte Regla documentada para todos los agentes del barrido: leer fechas SIEMPRE con `to_char("col",'YYYY-MM-DD"T"HH24:MI:SS')` y no imprimir nunca un `Date` devuelto por pg. ## Arreglo de fondo sugerido Forzar `TZ=UTC` en los procesos que leen la base (o configurar el parser de tipos de node-pg para `timestamp without time zone` de modo que no aplique la zona local). Asi el problema desaparece en origen en vez de depender de que cada consulta se acuerde de usar `to_char`. ## Origen Detectado por la terminal Support en el loop de barridos /sweep, madrugada del 24-jul-2026, tras una cadena de correcciones contradictorias sobre la misma build.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Delivery efectivo modo PREPAY: el cargo de servicio se lo queda el repartidor - cashRemitIncludeServiceFee es inoperante fuera de DEBT/PREPAID_WALLET

    Tenant: demo-andale-delivery-6306684c (Aztek / Deivith, conv 421774). Pedido real FD-E2TUFNVT: subtotal 300 + envio 35 + serviceFee 15 + propina 30 = 380 MXN en EFECTIVO. EL MODELO QUE PIDE EL OPERADOR (y que la plataforma ya nombra PREPAY): el repartidor le paga al restaurante el valor del producto en efectivo al recoger, y lo recupera del cliente al entregar. Entonces su Wallet NO debe cargar el subtotal - solo debe quedar en NEGATIVO por lo que le debe al operador: comision de reparto + cargo de servicio. LO QUE PASA HOY: 1) En DEBT (default, el actual de Aztek) el Wallet queda -300 (producto por remitir) -3.50 (comision) = -303.50 y el repartidor se queda con los 15 del serviceFee. Se corrige con el flag cashRemitIncludeServiceFee (cash-remit-composition.ts) -> -318.50, correcto. 2) En PREPAY el subtotal NO se debita (correcto) y el negocio queda debiendo la comision (businessOwesCommission, settle-delivery.ts:555) - tambien correcto. PERO el serviceFee NO se debita NUNCA: applyDeliveryCashDebit (driver-cod-debit.ts) hace early-return cuando cashFlowMode !== DEBT && !== PREPAID_WALLET, ANTES de mirar includeServiceFeeInRemit. O sea: el flag cashRemitIncludeServiceFee es INOPERANTE en PREPAY. CONSECUENCIA DE DINERO: todo tenant que opere delivery en efectivo con el modelo PREPAY pierde el 100% de su cargo de servicio en cada pedido en efectivo (15 MXN por pedido en este caso). Y no hay forma de configurarlo: o usa DEBT (y entonces el repartidor tiene que remitirle el producto, que no es su operacion) o usa PREPAY y regala el serviceFee. ALCANCE PROPUESTO: que applyDeliveryCashDebit escriba el renglon del serviceFee (codServiceFeeDebitDescription) tambien en PREPAY cuando includeServiceFeeInRemit sea true - el early-return debe filtrar solo el renglon del SUBTOTAL, no el del cargo de servicio. La liquidacion (cash-remit-settlement.ts) ya es ledger-driven, asi que acredita de vuelta exactamente lo que se debito por bucket y no habria que tocarla. Nota de producto: el nombre del flag (cashRemitIncludeServiceFee) deja de ser exacto en PREPAY, donde no hay remision de producto - ahi es simplemente 'el cargo de servicio se le cobra al repartidor'.

    Liberado el 26/7/2026
  • 0
    BugOtro

    Delivery: la app/panel del NEGOCIO muestra KPI 'Propinas' que el negocio NUNCA recibe (la propina es 100% del repartidor)

    Reportado por Deivith (Aztek, conv 421774): 'las propinas se las dan al restaurante, pero el repartidor no puede visualizar esas propinas'. VERIFICADO EN CODIGO Y EN DATOS REALES. 1) La propina es 100% del repartidor. delivery-commission-calculator.ts: driverEarnings = deliveryFee - driverCommission + tipAmount + perPlateBonus. El negocio nunca la toca: businessEarnings = subtotal - businessCommission. 2) PERO la app del negocio la muestra como si fuera suya. src/app/api/mobile/business/earnings/route.ts:82 acumula totalTips += o.tipAmount y lo devuelve en earnings.tips; apps/cabgo/lib/features/business/earnings/screens/earnings_screen.dart:157 lo pinta como StatCard 'Propinas' junto a Ventas/Comisiones/Neto. Mismo patron en el dashboard: src/i18n/messages/delivery/business-detail.es.ts kpiTips 'Propinas'. El local ve una tarjeta de dinero que jamas se le acredita en su BusinessWallet. EVIDENCIA CON DATOS REALES (pedido FD-E2TUFNVT, CASH, DELIVERED): subtotal 300 / deliveryFee 35 / serviceFee 15 / tipAmount 30 / totalAmount 380 businessCommission 43.59 (14.53%) -> businessEarnings 256.41 driverCommission 3.50 (10% del envio) -> driverEarnings 61.50 = 35 - 3.50 + 30 (propina) BusinessWalletTransaction: ORDER_EARNING 256.41 (SIN propina) WalletTransaction repartidor: -3.50 comision, -300 efectivo por remitir O sea: la propina de 30 fue integra al repartidor y aun asi el negocio ve 'Propinas 30' en su pantalla de Ganancias. FIX PROPUESTO: quitar el KPI 'Propinas' de la vista del negocio (o etiquetarlo explicitamente 'Propinas al repartidor (no se te acreditan)'). Aplica a la app de negocio Y al detalle de negocio del dashboard. NOTA RELACIONADA (misma conversacion, NO es este bug): en pedidos en EFECTIVO la propina viaja fisica dentro del efectivo que cobra el repartidor, asi que no aparece como renglon en su Billetera; solo se ve en el detalle del pedido ('Tu ganancia' -> Propina). Vale evaluar un renglon informativo de propina en el ledger del repartidor para pedidos en efectivo.

    Liberado el 24/7/2026
  • 0
    BugOtro

    company-config: deliveryMinimumFee capado a <=1000 — imposible calibrar delivery en monedas de alta denominacion (ARS/COP/PYG/CLP/NIO)

    REPRO (24-jul, tick soporte): PATCH /api/ai-agent/company-config sobre demo-andale-delivery-71827fc1 (Argentina, ARS) con {deliveryBaseFee:1200, deliveryPerKmRate:250, deliveryMinimumFee:1500} devuelve 400: {"error":"Datos invalidos","details":{"fieldErrors":{"deliveryMinimumFee":["Too big: expected number to be <=1000"]}}}. Curioso/inconsistente: deliveryBaseFee 1200 y deliveryPerKmRate 250 SI pasan; solo deliveryMinimumFee tiene el techo de 1000. O sea el zod acepta una base mayor que el minimo permitido, lo cual no tiene sentido dimensional. IMPACTO: en cualquier tenant/demo con moneda de alta denominacion (ARS ~1.000-1.500/USD, COP ~4.000, PYG ~7.500, CLP ~950, NIO ~37) el minimo de envio realista supera 1000 unidades. Hoy no se puede dejar el minimo correcto por endpoint: el envio queda con el minimo de plantilla (20) o topado en 1000, que en ARS/COP/PYG es practicamente cero -> la demo/el tenant muestra costos de envio absurdos y el lead concluye que la app calcula mal. Es de la misma familia que el patron MXN de las demos: fallo SILENCIOSO de credibilidad. FIX PROPUESTO: quitar el max fijo de 1000 en el schema de deliveryMinimumFee (o escalarlo por moneda, igual que ya se hace con otros montos), y como minimo alinearlo con el techo que ya aceptan deliveryBaseFee/deliveryPerKmRate. Revisar si el mismo cap existe en el formulario del dashboard. WORKAROUND actual: dejar deliveryMinimumFee en 1000 y subir deliveryBaseFee para que el piso efectivo lo ponga la base.

    Liberado el 23/7/2026
  • 0
    BugOtro

    provision-demo-company: demos de leads NO mexicanos nacen en MX/MXN (y una con la zona en lat 0/lng 0) — 4 casos verificados en un dia

    ## Sintoma Las demos creadas por `provision-demo-company` para leads de paises NO mexicanos estan naciendo con configuracion mexicana, y en al menos un caso con la zona geolocalizada en el oceano (lat 0 / lng 0). Confirmado tenant por tenant durante los barridos de soporte del 23-jul (todos leads de la tanda ~20-jul): - `demo-rayo-taxi-e7545a5d` (Johan, Medellin COLOMBIA) -> nacio country=MX, currency=MXN, timezone=America/Mexico_City + tarifas de plantilla mexicana. - `demo-rayo-taxi-cb19ea7c` (JaNeRoV, Cochabamba BOLIVIA) -> identico patron MXN. - `demo-rayo-taxi-f6df580b` (Santiago/Chaski, Loja ECUADOR) -> ademas de la moneda, `apply-preset delivery` dejo deliveryBaseFee/PerKm/Minimum en 15/5/20 (valores MXN) y sembro los productos con nombres y precios mexicanos, en un tenant USD. - `demo-rayo-taxi-44be0e25` (Huancayo, PERU) -> patron MXN **mas** la zona con geometria CIRCLE centrada en **lat 0 / lng 0** (golfo de Guinea). Cualquier cotizacion desde Huancayo cae fuera de zona. ## Impacto comercial Es lo primero que ve un lead que pidio su demo. Abre el link y encuentra precios en pesos mexicanos (o ninguna cobertura). En soporte lo estamos detectando y corrigiendo a mano tenant por tenant, pero solo cuando el lead vuelve a escribir: los que no responden se quedan con una demo rota y se pierden en silencio. Ya van al menos 4 casos verificados en un solo dia de barridos, y el patron sugiere que toda la tanda esta afectada. ## Residual adicional Aun despues de corregir, `Company.currency` se queda en MXN mientras `CompanySettings.currency` si toma la moneda correcta (mismo desfase ya visto en navan-drivers). Lo que consume la app es CompanySettings, pero conviene que las dos fuentes coincidan. ## Que habria que revisar 1. Por que `provision-demo-company` no esta propagando el `country` recibido a `currency` y `timezone` (parece caer a un default MX cuando el parametro llega vacio o no se mapea). 2. Por que la zona por defecto puede quedar en 0,0 en vez de centrarse en la ciudad del lead. 3. Que `apply-preset delivery` derive las tarifas de delivery y los productos sembrados de la moneda del tenant, no de constantes mexicanas. 4. Un barrido de correccion sobre las demos ya creadas de la tanda (leads no-MX), para no depender de que cada uno vuelva a escribir. ## Origen Detectado en el loop de soporte /sweep (terminal Support), ticks 222-223 del 23-jul-2026. Cada caso fue corregido manualmente por endpoint ai-agent y verificado por GET + simulacion de tarifa antes de mandarle el link al cliente.

    Liberado el 24/7/2026
  • 0
    BugOtro

    servicePricingMode=QUOTE en VIAJES: no existe superficie para cotizar (ni app conductor ni panel) — el pedido muere en AWAITING_QUOTE a los 60 min

    Caso: Danny / TRANS RAMOS (conv 390135, tenant demo-rayo-taxi-5f723d31, PE). Quiere cobrar su servicio Carga POR TONELADA (ref real: Trujillo->Quiruvilca, ~S/150 por tonelada, viaje de 5h). La via correcta seria servicePricingMode=QUOTE en el ServiceType Carga (id faa13809-ae97-47e2-ae86-1bb0a4d1d646). VERIFICADO EN CODIGO HOY — el ciclo esta MEDIO construido: - Rider: COMPLETO. ride_options_screen muestra Solicitar cotizacion en vez de precio; el trip nace status=AWAITING_QUOTE + quoteStatus=PENDING_QUOTE (mobile/rider/trips/request/route.ts:1348-1354, 1674-1695); awaiting_quote_screen.dart hace polling y deja aceptar/rechazar via /trips/{id}/respond-quote. - Operador: NO EXISTE SUPERFICIE. El endpoint POST /api/mobile/driver/trips/{id}/quote existe, pero NO hay cliente Dart que lo llame (0 ocurrencias de PENDING_QUOTE/quotedAmount en apps/cabgo/lib/features/driver) ni pantalla en el dashboard (0 ocurrencias de AWAITING_QUOTE fuera de api/mobile; quotedAmount solo se renderiza en delivery/orders/[id] y en el portal de negocio). O sea: para DELIVERY el ciclo de cotizacion tiene UI, para TRIPS no. - Consecuencia: si un tenant activa QUOTE en un servicio de taxi/carga, el pasajero queda en Esperando cotizacion, nadie puede poner el precio, y a los 60 min /trips/active lo AUTO-CANCELA (route.ts:73-100). Por eso NO se le activo a Danny (habria roto su prueba). Se le explico de frente y se le ofrecio la alternativa que si funciona hoy (bandas sizeTier por rango de peso, que el picker del rider si renderiza). Alcance pedido: (a) accion Cotizar en el detalle del viaje del panel (Viajes en Vivo / detalle) llamando al endpoint que ya existe, y/o (b) pantalla equivalente en la app del conductor/operador; (c) que el aviso admin de nuevo viaje distinga AWAITING_QUOTE; (d) que el ai-agent avise cuando alguien ponga QUOTE en un ServiceType kind=TAXI mientras no exista la superficie.

    Liberado el 23/7/2026
  • 0
    BugOtro

    aka-delivery: la tarjeta del pedido EN CURSO muestra Tarifa BRUTA e ignora driverOfferDisplayMode=NET_EARNINGS

    Reportado por Alejandro (Aka Delivery, conv 402735, 23-jul). Captura: pantalla del conductor con el pedido FD-QSVZFSPM ya aceptado (slider He llegado al negocio) mostrando Tarifa: $2.800 — el bruto que paga el cliente, no lo que el repartidor se queda. Diagnostico verificado en codigo y config: - CompanySettings de aka-delivery ya tiene driverOfferDisplayMode = NET_EARNINGS (desde 2026-06-17) y taxiServiceLabel = null, commissionMode PERCENTAGE 0.05. O sea el tenant YA pidio ver neto. - ride_request_screen.dart:295-315 SI respeta driverOfferDisplayMode en la tarjeta de OFERTA (_headlineFare = driverEarnings cuando NET_EARNINGS). - active_ride_screen.dart:3593-3624 renderiza incondicionalmente `${context.l10n.fareLabel}: ` + formatAmount(_estimatedEarnings) — el BRUTO. No consulta driverOfferDisplayMode. Mismo caso en trip_card.dart:171-175 del Trip Center, que usa driverEarnings solo si commissionAmount>0 y taxiServiceLabel==null. Esperado: cuando el tenant esta en NET_EARNINGS, la pantalla del viaje/pedido en curso (y la tarjeta del Trip Center) deben encabezar con la ganancia neta del conductor, con el mismo fallback al bruto para payloads legacy sin driverEarnings. Impacto: el repartidor ve un numero mayor al que cobra y el dueño recibe reclamos. Requiere actualizacion de la app (cambio Dart).

    Liberado el 24/7/2026
  • 0
    BugOtro

    ZoneServiceConfig surgeEnabled es un multiplicador FIJO siempre-activo, no surge por hora pico — el tenant cree lo contrario

    Hallazgo verificado en codigo (tick 217, caso Orlando/Pide Y Dale GT+PY, conv 411976). HAY DOS SURGES DISTINTOS Y SE LLAMAN IGUAL: 1) Surge DINAMICO real: ZoneSurge + surge-service.ts getSurgeForLocation() — calcula multiplicador por demanda/oferta, expira, y esta gateado por CompanySettings.surgeEnabled. 2) ZoneServiceConfig.surgeEnabled + surgeMultiplier: fare-calculator.ts:375 hace `if (config.surgeEnabled) price = price * config.surgeMultiplier` SIN ninguna condicion de hora, demanda ni expiracion. Es un multiplicador PLANO que se aplica a TODAS las carreras, 24/7. EVIDENCIA: en demo-rayo-taxi-db9ee850 (Pide Y Dale Guatemala) los 7 servicios Dale* tienen ZSC surgeEnabled=true surgeMultiplier=1.5 → toda carrera sale +50% permanente. En dale (Paraguay) surgeEnabled=true surgeMultiplier=1.3 → +30% permanente. En AMBAS companies CompanySettings.surgeEnabled=false, o sea el surge dinamico esta apagado y lo unico vivo es el recargo plano. El cliente lo describio textualmente como \"todos tienen 1,5 en surge pricing\" y \"el Surge pricing es de 1.3\", claramente entendiendo hora pico. Un Dale Taxi de 6 km pasa de Q27.16 a Q40.74 sin que el tenant lo sepa. PEDIDO: (a) renombrar el campo del panel a algo como \"Recargo fijo por zona\" y separarlo visualmente del surge dinamico, (b) mostrar un aviso \"se aplica a TODAS las carreras\" al activarlo, (c) que el desglose de tarifa lo etiquete como recargo fijo y no como surge.

    Liberado el 27/7/2026
  • 0
    BugOtro

    si-voy: AAB con divulgacion de ubicacion prominente (aviso ANTES del permiso Android) pendiente 8 dias

    Diego (conv 415203, si-voy PRO) recibio correo de Google exigiendo que el aviso de uso de ubicacion aparezca ANTES del permiso de Android (prominent disclosure). El 15-jul se le prometio un AAB corregido subido a su panel para que el mismo lo mande a revision. Al 23-jul sigue preguntando novedades y NO hay folio que lo rastree ni evidencia de que el fix este en una build. Builds recientes: 1.0.60 SUCCESS 20-jul (no confirmado que lleve el cambio de disclosure), 1.0.87/88/89 FAILED. Necesita: aplicar el ajuste de prominent disclosure de ubicacion en la app si-voy, compilar AAB nuevo y dejarlo descargable en su panel. Cliente esperando 8 dias con promesa explicita de avisarle por el chat.

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    Tooling ai-agent: no se puede togglear showOnAppleSignIn/showOnGoogleSignIn de un campo de registro desde soporte

    El endpoint /api/ai-agent/registration-fields (PATCH) no expone showOnAppleSignIn ni showOnGoogleSignIn en su zod schema, asi que soporte NO puede activar/desactivar la visibilidad de un campo por proveedor de login. Hoy solo se puede via dashboard (PUT /api/settings/registration-fields, session-auth). Caso pido-taxi (PRO): el dueno quiere que el campo Telefono del pasajero (isRequired=true, showOnGoogleSignIn=true) se pida TAMBIEN en Apple Sign-In, pero showOnAppleSignIn=false y no hay forma de cambiarlo desde ai-agent. Propuesta: agregar showOnAppleSignIn/showOnGoogleSignIn al PATCH_SCHEMA de registration-fields.

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    Reenviar la misma notificacion push desde el apartado de Notificaciones

    Alfredo (yumm, conv 417942) pide: en el apartado de Notificaciones del panel, poder REENVIAR de nuevo una notificacion ya enviada (mismo titulo/cuerpo/segmento) con un boton, sin tener que reescribirla. Caso de uso: repetir una promo/aviso que ya se mando. Hoy hay que redactarla desde cero cada vez.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Migrar 43 conductores +502 (Guatemala) de navan-drivers (CO) a Pide Y Dale Guatemala

    Orlando (conv 411976, cliente PRO multi-pais Pide Y Dale) abrio Pide Y Dale Guatemala (slug demo-rayo-taxi-db9ee850) y no ve conductores activos ahi; sus conductores guatemaltecos se registraron en la operacion de Colombia (navan-drivers) antes de que existiera GT. SQL confirma 43 Driver con phone LIKE +502% dentro de navan-drivers. No hay endpoint ai-agent para reasignar Driver.companyId entre tenants. Necesita: migrar esos 43 conductores (con sus datos/saldo) a la company GT db9ee850. Prometido al cliente avisar cuando esten. NO es bug de codigo, es tarea de datos manual del equipo.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Editar tarifas en panel REVIERTE category transport->delivery y pierde perKm/perMin (2a recurrencia, super/Entregas)

    REPRO CONFIRMADO 2 VECES en super (Lima, FULL): el servicio Entregas (paqueteria por vehiculo, doctrina category=transport kind=TAXI para salir en el picker elige-tu-viaje) fue corregido a category=transport via ai-agent PUT (tick 153) y HOY 23-jul ~16:34 UTC, tras editar el cliente las tarifas desde su panel (puso base 5 + 0.70/km + 0.20/min), el row quedo category=delivery kind=DELIVERY con perKmRate=0 y perMinuteRate=0 (solo sobrevivio baseFare 5) -> el servicio DESAPARECE de elige tu viaje y el cliente cree que sus valores no se guardaron. Es la 2a vez que su edicion de panel deshace la correccion. ANCLAS: (1) src/components/settings/service-type-manager.tsx:392-395 — al abrir el form de edicion deriva kind del row (DELIVERY) y :1222-1224 el selector de kind espeja category=delivery; como el fix por endpoint dejaba kind=DELIVERY con category=transport (estado inconsistente), cualquier guardado del panel re-espeja category=delivery. (2) src/app/api/settings/service-types/route.ts:343/414 acepta category del payload del cliente wholesale. (3) Ademas el guardado zeroa perKmRate/perMinuteRate cuando el servicio se trata como DELIVERY (el cliente los escribio y llegaron 0/0 a DB). FIX aplicado por soporte HOY: PUT ai-agent/services con category=transport Y kind=TAXI juntos (elimina el estado inconsistente) + tarifas restauradas 5/0.70/0.20; simulacion rider verificada: Entregas S/10.94 en ruta 4.2km/15min. PROPUESTA de fix raiz: que el form del panel NO derive/espeje category-kind al editar solo tarifas (preservar los valores del row salvo cambio explicito) y que ai-agent PUT mapee category->kind como el POST.

    Liberado el 24/7/2026
  • 0
    BugOtro

    Chatbot WA: direccion de texto SIN ciudad se geocodifica a otra ciudad del pais y responde falso fuera de zona (ted-go/Buga)

    Caso real ted-go (conv 401863, 23-jul): pasajero Alvaro (573194253538) escribio al chatbot WA el origen como texto: Carrera 7 # 12-12 (sin ciudad). El webhook (src/app/api/webhooks/whatsapp/route.ts, rama de texto >5 chars) geocodifica con region=CO sin bias por las zonas del tenant; una direccion ambigua tipo Carrera 7 resuelve a otra ciudad de Colombia (Bogota/otra), el punto cae fuera de las 11 zonas activas y el bot contesta flowCopy.outsideZone aunque el cliente esta en plena zona de Buga (CIRCLE 3.9007,-76.2978 r5km, verificada activa). Propuesta: (1) bias del geocode con los centroides/bounds de las zonas activas del tenant (components/locationbias) y/o append de la localidad de la zona mas cercana; (2) si el geocode resuelve fuera de TODAS las zonas y la direccion no traia ciudad, re-intentar con <direccion>, <ciudad de la zona> antes de responder fuera de zona; (3) copy: sugerir compartir ubicacion o incluir la ciudad. Workaround dado al cliente: escribir la direccion con la ciudad (Carrera 7 # 12-12, Buga) o compartir el pin de ubicacion.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Aviso de reserva programada al conductor llega SIN tono de alerta (sendPushToDriver sin channel -> sound default) — el conductor lo ve pero no lo oye

    driving-viajes (conv 411789, audio del cliente: la notificacion de reserva aparece pero -no pita-, y el conductor solo se entera si entra al Trip Center). Causa verificada en codigo: scheduled-create-notify.ts llama sendPushToDriver SIN el parametro channel, por lo que buildDriverPushMessage (firebase-admin.ts:90-92) cae a channelId ride_requests + sound -default-, mientras las ofertas reales de viaje usan el canal RIDE_OFFER con androidSound new_order_alert + timeSensitive (firebase-admin.ts:74-77). Resultado: el heads-up de nueva reserva entra silencioso o casi. Fix: pasar el mismo PushChannelOpts de ofertas (o un canal propio con tono audible) al push scheduled_trip_created. El tenant tiene notifyDriversOnScheduledCreate=true.

    Liberado el 23/7/2026
  • 0
    BugOtro

    PayPhone Prepare: rechazos REALES invisibles server-side (providerStatus/providerMessage no se persisten) + retry del mismo pedido muere por ClientTransactionId duplicado

    yevfood- (conv 423202). DOS intentos reales HOY rechazados por PayPhone (FD-LKUFNXQ8 13:24 UTC y FD-HKZ3HKMU 14:41 UTC, video del cliente: dialog generico PAYPHONE_PREPARE_REJECTED, o sea status NO 401/403) mientras probes con el payload EXACTO del route (mismo monto 1004 cents, mismo email/phone del customer, mismo responseUrl) devuelven 200 una y otra vez. No podemos saber POR QUE PayPhone rechaza los intentos del cliente: payphone-checkout/route.ts solo hace console.error del providerMessage y NO persiste nada (PaymentTransactionLog quedo VACIO hoy). Pedido 1: persistir provider+type=PREPARE_REJECTED con httpStatus y message literal en PaymentTransactionLog en el catch de PayPhonePrepareError. Pedido 2 (bug de diseno REPRODUCIDO): clientTransactionId es estatico PPO-<orderId>; si un Prepare del pedido YA fue aceptado y el WebView no abrio, TODO reintento del mismo pedido rebota HTTP 400 errorCode 23 -Ya existe una transaccion con el ClientTransactionId especificado- (reproducido en vivo con las llaves del tenant), o sea el -intenta de nuevo- del mensaje de error es un callejon sin salida. Fix: sufijo por intento (PPO-<orderId>-<n>) o reusar la sesion existente. Relacionados: cmrwpy6ue, cmrx41vva (RELEASED).

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    tooling ai-agent: agregar UserCompanyMembership a un usuario existente SIN resetear password ni repuntar su company primaria (multi-pais Navan CO/PY/GT)

    GAP DE TOOLING detectado en conv 411976 (Orlando/Navan, tick 184): Orlando (navantransportes.tics@gmail.com, COMPANY_ADMIN de navan-drivers) necesita ver/administrar su nueva company de Guatemala (demo-rayo-taxi-db9ee850) desde su panel, pero NO existe via ai-agent para agregarle una UserCompanyMembership: (a) POST /api/ai-agent/company-admin SIEMPRE setea password (temp si se omite, route.ts:168) y reassignCompanyOwner repunta User.companyId a la company nueva (reassign-owner.ts:47) — sobre un usuario ACTIVO eso rompe su login actual y lo saca de su company principal; (b) ningun otro endpoint ai-agent escribe UserCompanyMembership (grep verificado). Propuesta: endpoint add-membership {companySlug, email, role} idempotente que solo cree/active la membership, sin tocar password ni ownerId ni companyId primario. Caso de uso real: operadores multi-pais (Navan CO/PY/GT). Relacionado: cmrtmm5oi (dueno sin membership en su 2da empresa).

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    reengagement-pending.mjs: suprimir sugerencias cuyo ultimo OUT ya es un HSM (anti-doble-HSM en el script, no solo en la disciplina del agente)

    El script scripts/reengagement-pending.mjs re-sugiere tick tras tick hilos cuyo ultimo OUT ya es un HSM 'Actualizacion de tu solicitud' (reincidentes: convs 422805, 422806, 422804, 421811, 422109, 422162 — re-sugeridos en ticks 179, 181 y 182 del 23-jul). La regla operativa es NUNCA 2 HSM seguidos, asi que hoy la unica defensa es que cada agente lea el hilo y skipee manualmente. Propuesta: (1) al armar sugerencias, detectar si el ultimo OUT del hilo es un HSM (content empieza con 'Actualizacion de tu solicitud') y suprimir la sugerencia hasta que haya un IN nuevo; (2) opcional: flag no-recontacto-automatico persistente por conversacion. Beneficio: elimina el riesgo de doble-HSM por descuido y limpia el listado diario (~6 falsos positivos por tick hoy).

    Liberado el 23/7/2026
  • 0
    BugOtro

    Dialogo Sin conductores disponibles concatena el nombre de la empresa SIN espacio (noDriverFoundRetry)

    Reportado por Lima/Super Ride (conv 416414) con captura: el dialogo del rider muestra "No se encontraron conductores disponiblesSuper Ride Technologies. ¿Deseas intentar de nuevo?" — el nombre de la empresa pegado a la palabra disponibles. Causa verificada en codigo: la key ARB noDriverFoundRetry = "No se encontraron conductores disponibles{companyName}. ¿Deseas intentar de nuevo?" (apps/cabgo/lib/l10n/app_es.arb:5168, mismo patron en en/pt/it) y los call-sites pasan el nombre crudo: searching_driver_screen.dart:344 y ride_options_screen.dart:1771 hacen context.l10n.noDriverFoundRetry(companyName ?? ""). No hay separador — cuando companyName viene poblado el texto queda pegado. Afecta a TODOS los tenants en todos los idiomas. Fix sugerido: plantilla "...disponibles en {companyName}..." (o quitar el placeholder y no interpolar el nombre). Requiere rebuild para apps nativas; web lo toma en el siguiente deploy.

    Liberado el 23/7/2026
  • 0
    BugOtro

    apolo-food: pedidos delivery CANCELADOS desde la web del admin siguen listados en el Centro de Viajes de la app del conductor

    PDF de William 23-jul (conv 412412, build 1.0.171 #172): canceló pedidos desde la web del administrador y las tarjetas siguen apareciendo en el Centro de Viajes del conductor; solo al intentar aceptarlas sale el aviso Este viaje ya no está disponible (captura: 2 tarjetas express de NAPOS CHIKEN persistentes con el aviso amarillo). El guard anti-aceptación funciona, pero la lista no se refresca/limpia al cancelarse la orden → confunde a los repartidores. Esperado: la cancelación (web o app) remueve la tarjeta del trip center en tiempo real (Centrifugo) o al refetch.

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    apolo-food: Crear pedido express (web admin) — falta "con cuánto paga el cliente" (vuelto) y tiempo de recolección (paridad con app de comercios)

    PDF de William 23-jul (conv 412412): en el diálogo Crear pedido express de la WEB del administrador falta (1) el campo de con cuánto paga el cliente en efectivo (para calcular el vuelto que debe llevar el repartidor) y (2) el tiempo de recolección del pedido. Ambos campos YA existen en la opción Solicitar repartidor de la APP de comercios — es paridad de superficies. El diálogo web hoy solo tiene: dirección, tipo de entrega, monto a cobrar, tarifa de envío, notas.

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    Dashboard: detalle del pedido en Delivery->Pedidos no muestra los codigos de recogida/entrega del repartidor (solo Viajes en Vivo los tiene)

    rapi2/Pavel (conv 384594): el detalle de pedido en delivery/orders/ no muestra el codigo que el repartidor necesita para RECOGER el pedido en el local ni el de ENTREGA al cliente. Hoy solo se ven en Viajes en Vivo. Caso de uso: el operador auxilia a un repartidor que no encuentra su codigo, y ademas hay tenants que restringen Viajes en Vivo a los operadores — ahi quedan sin ninguna superficie con los codigos. Propuesta: paridad — mostrar pickupCode/deliveryCode en el detalle del pedido de Delivery->Pedidos (misma fuente de datos que ya usa Viajes en Vivo). Solo dashboard, sin rebuild.

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    Deep link directo a Enviar paquete (mandado) para compartir con clientes — migracion desde WhatsApp

    rapi2/Pavel (conv 384594): pide un link para mandar a sus clientes actuales de WhatsApp que abra DIRECTO la pantalla Enviar paquete, como herramienta de migracion WA->app. Hoy existe la ruta interna /rider/delivery/direct (app_routes.dart:241, GoRoute en app_router.dart:1170) pero no hay deep link compartible verificado que aterrice ahi (el link web ?company=<slug>&role=rider abre el home; en nativo no hay scheme/App Link publicado para esa pantalla). Propuesta: soportar un parametro tipo ?company=<slug>&role=rider&screen=delivery-direct en web + App Links/Universal Links en nativo, preservando el destino a traves del login. Referencia de patron: cmrlye7m1 / cmqg3x6e3 (deep link de perfil de negocio /d/<slug>).

    Liberado el 23/7/2026
  • 0
    BugOtro

    Enviar paquete (mandado directo) desaparece en cold start — deliveryDirectEnabled no se persiste ni rehidrata (misma familia que cmrwu2f0x)

    rapi2/Pavel (conv 384594, build 1.0.34): con el modo delivery ya seleccionado, al cerrar la app por completo y reabrirla la card Enviar paquete NO aparece; reaparece solo al re-seleccionar el modo cliente. Causa en codigo: company_settings_cache.dart — _deliveryDirectEnabled (linea ~306) vive SOLO en memoria con default false; el restore de SharedPreferences (~830) no lo incluye y delivery_home_screen.dart:472/739 lo lee en build antes de que la hidratacion de /company termine. Es exactamente el patron de cmrwu2f0x (defaultHomeVertical), que se corrigio con persistencia SWR — aplicar el mismo fix a deliveryDirectEnabled (y valorar deliveryDirectFixedFare). Fix Dart = requiere rebuild. Workaround cliente: re-seleccionar el modo tras abrir. Impacto: los clientes de Pavel que migran desde WhatsApp no ven el boton en el arranque — golpea directo su caso de uso principal.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Viajes en Vivo: 'Detalles del Viaje' pierde las notas del pedido delivery en cuanto un repartidor acepta (Trip.notes vacio, sin fallback a FoodOrder.deliveryNotes) — operadores ciegos a que transporta el mandado

    Caso Pavel/Rapi2 (conv 384594), orden real FD-TVX2QK8A / Trip DL-6M9QSA (mandado directo 'Enviar paquete', source DIRECT_COURIER). El cliente escribio la nota 'PEDIDO DE PRUEBA / traer una orden de carne asada de tacos el paisa y unos frijoles especiales'. La app del REPARTIDOR la muestra perfecto (card Notas), pero el modal 'Detalles del Viaje' del dashboard (Viajes en Vivo) muestra 'NOTAS: Sin notas' — los operadores no saben que transporta el repartidor. CAUSA (verificada en codigo y DB): - src/app/(dashboard)/dashboard/trips/live/page.tsx: los pedidos delivery TEMPRANOS (sin Trip, synthetic ORDER_*) SI mapean notes: order.deliveryNotes (~linea 343). Pero en cuanto existe el Trip real, mappedTrips usa notes: trip.notes (~linea 288) SIN fallback al FoodOrder, y el select anidado de FoodOrder (~linea 67) NO incluye deliveryNotes ni customRequestText. - Trip.notes queda vacio para delivery: ni direct-order (src/app/api/mobile/rider/delivery/direct-order/route.ts:118 escribe solo FoodOrder.deliveryNotes) ni el flujo normal copian las notas al Trip. - Resultado: el operador ve las notas SOLO mientras nadie acepto; se pierden justo cuando el repartidor va en camino. Afecta a TODOS los pedidos delivery con notas (agravado en DIRECT_COURIER, donde la nota ES el contenido del encargo). DB verificada: FoodOrder 8c9244d8-57dd-4b94-a229-fb074d2d4b72 deliveryNotes con texto, Trip 9a5fb7f1-d169-4c8e-91b7-a8b28282b117 notes vacio. FIX SUGERIDO: agregar deliveryNotes (y customRequestText) al select de FoodOrder en trips/live y hacer fallback notes: trip.notes || foodOrder?.deliveryNotes; opcional copiar la nota a Trip.notes al crear el Trip de delivery. WORKAROUND ya comunicado al cliente: el detalle del PEDIDO (Delivery -> Pedidos -> abrir la orden) SI muestra deliveryNotes (order-detail-client.tsx:826). Relacionado pero distinto: cmrx7qesv/PR #395 solo cubrio el detalle de ORDEN (encargo/cotizacion), no el detalle de VIAJE.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Mandado directo (Enviar paquete): primer pedido revienta 500 si el tenant tiene un negocio con email vacio — placeholder Mandado choca en unique (companyId,email)

    Caso real: Pavel/rapi2 conv 384594, 23-jul 08:50-08:52 (AppErrorLog, 2 intentos 500). getOrCreateDirectCourierBusiness (src/lib/services/delivery/direct-courier.ts:44) crea el negocio oculto Mandado con email:"" — si el tenant ya tiene CUALQUIER negocio con email vacio (rapi2 tenia Tacos El Ballo), prisma.business.create revienta con Unique constraint failed on (companyId,email) y el POST /api/mobile/rider/delivery/direct-order devuelve 500. El cliente solo ve el generico No se pudo crear el envio (direct_order_screen.dart:103). La feature queda muerta al PRIMER uso en esos tenants. Mitigacion aplicada a mano en rapi2: se libero el email vacio (PATCH ai-agent/businesses al negocio Tacos El Ballo -> tacos-el-ballo@placeholder.cabgo.app). Fix propuesto: email unico por tenant para el placeholder (ej direct-courier+<companyId>@cabgo.internal) o upsert por isDirectCourierPlaceholder; y en el catch del route devolver un code diagnostico en vez de 500 crudo.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Dashboard admin: detalle de orden delivery NO muestra encargo personalizado ni UI de cotizacion y permite avanzar estado sin cotizar (orden viaja en $0)

    Caso Pavel/Rapi2 (conv 384594), negocio casa ENVIOS RAPI2 (b6c16479, allowCustomOrderRequests=true) para mandados de negocios fuera de la plataforma. EVIDENCIA (3 ordenes de prueba 23-jul): FD-4Q3EU5SZ, FD-4YR5HLKR, FD-V2ABJCAC — las 3 con customRequestText, quoteStatus=PENDING_QUOTE y AUN ASI status DELIVERED/COMPLETED con subtotal=0, deliveryFee=0, totalAmount=0. GAP 1 (paridad UI): src/app/(dashboard)/dashboard/delivery/orders/[id]/order-detail-client.tsx no referencia customRequestText/quoteStatus — el operador del panel admin no ve el texto del encargo ni el formulario de cotizacion. La app de comercio (order_detail_screen.dart:1524) y el portal web del negocio ((business-portal)/business/orders/[id]/page.tsx:251) SI lo tienen (cmqqru2i4). El dueno que gestiona su negocio-casa desde el panel admin concluye que "no se puede poner precio". GAP 2 (guard): el avance de estado (admin y POST /api/mobile/business/orders/[id]) no exige quoteStatus=QUOTE_ACCEPTED para ordenes con customRequestText — se puede ACEPTAR/entregar una orden sin cotizar y viaja con precio $0 (el cliente nunca aprueba monto). En la app de comercio el form de cotizacion reemplaza al boton aceptar (bien), pero el panel admin lo bypasea. Fix sugerido: (a) portar la card de encargo+cotizacion al order-detail del dashboard admin; (b) bloquear el avance PENDING->ACCEPTED cuando customRequestText != null && quoteStatus != QUOTE_ACCEPTED (en API, no solo UI).

    Liberado el 23/7/2026
  • 0
    BugOtro

    Cashback delivery: el cliente lo GANA pero no puede GASTARLO — checkout sin opcion Usar saldo ni banner ganaste X (Deivith/Aztek)

    Cierre del loop de k0xc4s (cashback % RELEASED, acredita bien a CustomerWallet en settle-delivery.ts:1064+). Verificado en codigo 2026-07-23: (1) el backend de creacion de pedidos /api/mobile/rider/delivery/orders YA soporta gastar saldo (param useWallet / paymentType WALLET, parcial o total, gateado por CompanySettings.deliveryWalletPaymentEnabled — que en demo-andale-delivery-6306684c esta en TRUE), PERO la app NUNCA lo manda: checkout_screen.dart maneja solo cash/card/custom/redirect (_selectedPaymentType linea 75) y delivery_service.dart no envia useWallet. El toggle Usar saldo existe solo en el flujo TAXI (payment_method_selector.dart:339). (2) grep cashback en apps/cabgo/lib = 0 hits: no existe banner ganaste $X en cashback ni en checkout ni post-compra; el cliente solo lo descubre si abre la Billetera. Reporte textual del cliente Deivith (conv 421774, casi-comprador, feature construida PARA el): ya lo visualice en la billetera del cliente, pero como los puede usar... al momento de pagar no le da la opcion de usar puntos o usar cashback nada. Pedido: (a) exponer en el checkout de delivery el toggle Usar mi saldo (mismo patron taxi, wireado a useWallet), (b) banner de cashback ganado en confirmacion de pedido/checkout. Requiere rebuild de app; web sale con deploy.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Rutas Inter-Zona: el dialogo de edicion en bloque (op booleana) nace con default 'appliesToDelivery=true' — un tenant que solo queria 'Sin recargos nocturnos' saco sus 14 filas del pricing de taxi SIN AVISO

    INCIDENTE REAL (super / Super Ride, Lima, FULL — conv 416414, 2026-07-23 ~05:50 UTC): El dueno siguio la instruccion de activar 'Sin recargos nocturno/festivos (tarifa fija)' en sus 14 filas Miraflores<->Aeropuerto via Configuracion -> Rutas Inter-Zona -> seleccion -> Editar en bloque -> operacion booleana. Resultado en DB: las 14 filas quedaron con suppressTariffRules=t (lo que queria) PERO TAMBIEN con appliesToDelivery=t (lo que NO queria y nadie le mostro). CAUSA en codigo (zone-route-price-manager.tsx): - El dialogo ZoneRouteBulkEditDialog resetea al abrir: setFilterBoolField("appliesToDelivery") + setFilterBoolValue(true) (lineas ~2210-2211). O sea: el combo DESTRUCTIVO es el DEFAULT — basta un click en Guardar con la op booleana sin tocar el selector para flipear appliesToDelivery=true en todas las filas del filtro. CONSECUENCIA SILENCIOSA (services/route.ts:343): el quote de taxi carga ZoneRoutePrice con appliesToDelivery:false — una fila flipeada a true DESAPARECE del pricing de taxi sin ninguna senal en el panel (la tabla la sigue mostrando igual). El pasajero vuelve a tarifa por km + recargos: en el incidente, el aeropuerto nocturno paso de S/38 FLAT a S/29.15 medido +30% (y en otros casos puede ser mas caro). Es el mismo patron 'fallo silencioso' de cmrwdc67c pero en pricing. YA MITIGADO PARA ESTE TENANT: soporte restauro appliesToDelivery=false en las 14 filas via /api/ai-agent/zone-route-prices/bulk y verifico con simulacion rider nocturna en vivo (ambos sentidos FLAT 38/46/65/65/55/90, surchargeTotal=0). FIX SUGERIDO (cualquiera de estos): 1) Default del selector booleano = isActive o el ultimo campo usado, NUNCA appliesToDelivery=true. 2) Confirmacion explicita cuando la op booleana toca appliesToDelivery ('esto saca N filas del pricing de taxi / las mueve a delivery'). 3) Indicador visible en la tabla de filas con appliesToDelivery=true (hoy son indistinguibles). Nota: verificar tambien el label i18n del campo en el dialogo — el dueno no reporto haber entendido que estaba tocando ese campo.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Delivery nativo: PayPhone seleccionado (prueba en VIDEO) pero la app JAMAS llama /payphone-checkout — orden nace CARD/PENDING sin pagina de pago y sin error visible

    EVIDENCIA (yevfood-, conv 423202, cliente Yev, 2026-07-23): 1) VIDEO del cliente (msg 2574113, 05:53 UTC): en la app NATIVA Android el checkout muestra 'Metodo de pago: PayPhone', la pantalla Metodos de pago muestra PayPhone con badge 'Predeterminado' + check (initialSelection='redirect:PAYPHONE'), pulsa Siguiente -> dialogo 'Ubicacion lejana 18.4km' -> Continuar -> pantalla Propina -> Realizar pedido. La pagina de PayPhone NUNCA abre. Sin ningun error visible. 2) DB: FoodOrders 8ca77f50 (05:52:45), 3a5d7ba9 (05:11:32), 29d2329a (05:10:42), de94a103 (01:29:49) — TODOS paymentType=CARD, paymentStatus=PENDING. PENDING = el endpoint /api/mobile/rider/delivery/orders/[id]/payphone-checkout NUNCA fue alcanzado (el route pone PROCESSING en linea ~119 ANTES del Prepare). Cero filas PAYPHONE en PaymentTransactionLog. En contraste, los intentos de 23:08 y 01:01 SI quedaron PROCESSING (el endpoint si corria entonces, fallaba el Prepare por el token viejo 401 = cmrwpy6ue, ya resuelto por el cliente). 3) Server DESCARTADO: PaymentConfig PAYPHONE de yevfood- completo (isEnabled=t, secretKey 347 chars, storeId eab07bad..., codingPassword ok) y probe Prepare 200 verificado con sus llaves reales. Todos los guards del route pasarian. 4) Cliente DESCARTADO: config correcta, token con permiso Boton de Pagos activo, seleccion correcta en UI (video). 5) Codigo revisado en TODO su rango de builds (1.0.7-1.0.12 = templates 1.10.824-1.10.833): checkout_screen restore 'redirect:' -> _cart.setRedirectProvider OK; tap handler (ambos layouts) OK; tip_screen._placeOrder -> if (_cart.redirectProvider != null) _runRedirectCheckout OK. El wiring EXISTE y aun asi en el dispositivo real _cart.redirectProvider llega null (o la llamada muere antes de salir) en 4 intentos consecutivos desde la 01:29. Se necesita repro en dispositivo / breadcrumbs. 6) AGRAVANTE confirmado en codigo: tip_screen._runRedirectCheckout mantiene `catch (_) {} // Swallow` (linea ~133) — el fix de error visible de cmrwpy6ue solo se aplico a checkout_screen, NO a tip_screen, que es donde vive 'Realizar pedido' cuando hay pantalla de propina. Cualquier fallo ahi es invisible para el cliente y para Sentry (no hay reportError en ese catch). PISTA DE REPRO: el flujo del video pasa por la pantalla de Propina (deliveryTipType habilitado). Reproducir: seleccionar PayPhone -> Siguiente -> propina -> Realizar pedido, y ver si _cart.redirectProvider sobrevive la navegacion checkout->tip en dispositivo real (no solo en teoria del singleton). Tambien instrumentar el catch del tip_screen con reportError. IMPACTO: el tenant tiene PayPhone como UNICA pasarela online; hoy NINGUN cliente suyo puede pagar en linea en la app nativa. El cliente lleva 2 dias probando y cada intento muere en silencio.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Culqi: guardar tarjeta falla con 'Failed to fetch' — errores de Culqi enmascarados por CORS en el form de tokenizacion (y comercio teo-154a sin permiso de tokens API)

    Caso Victor / Taruca En One (teo-154a, conv 413214), continuacion de cmrwh0zrj (probe sk ya corregido). Victor intento guardar 2 tarjetas distintas en la pantalla 'Agregar tarjeta - Culqi' del rider y ambas fallaron con 'Error: Failed to fetch'. DIAGNOSTICO REPRODUCIDO (23-jul 05:41 UTC, llamadas reales): 1) CAUSA RAIZ DEL CASO: la pk_live real de teo-154a contra POST https://secure.culqi.com/v2/tokens devuelve HTTP 400 {type:'authentication_error', merchant_message:'Tu codigo de comercio no esta autorizado para realizar este tipo de peticiones. Contactate con culqi.com/soporte'}. Control con pk falsa devuelve el error generico 'Olvidaste indicar tu API Key...' => la llave de Victor SI es reconocida; lo que falta es un PERMISO a nivel de comercio en Culqi (creacion de tokens via API / integracion custom). Accion del cliente: pedir a Culqi que habilite la creacion de tokens via API para su codigo de comercio. Ya se le dio el mensaje literal para reenviar a Culqi. 2) BUG NUESTRO (esta ficha): el form generado por buildCulqiHtml (src/app/api/mobile/rider/payments/tokenize-form/route.ts:666, fetch en :738) hace la tokenizacion client-side desde el WebView. El preflight OPTIONS de secure.culqi.com responde access-control-allow-origin:*, pero la RESPUESTA real de error (400, x-cache: 'Error from cloudfront') NO trae access-control-allow-origin => el browser bloquea la lectura y el catch (linea 757) muestra 'Error: Failed to fetch'. Consecuencia: TODO error de Culqi (permiso de comercio, tarjeta rechazada, llave mal) le llega al usuario como 'Failed to fetch', indiagnosticable — exactamente el patron de opacidad que ya nos costo 3 dias con este cliente. Evidencia curl reproducible: - OPTIONS /v2/tokens con Origin https://www.cabgo.app => 200 con ACAO:* - POST /v2/tokens (pk_live teo-154a) => 400 authentication_error SIN header ACAO => en browser = TypeError Failed to fetch. FIX SUGERIDO: proxyear la creacion del token por nuestro backend (endpoint que recibe los datos del form y hace el POST server-side con la pk, devolviendo el user_message literal de Culqi), o usar el SDK oficial Culqi Checkout; como minimo, mapear el TypeError a un mensaje claro ('No se pudo contactar a Culqi / tu comercio puede no tener habilitada la tokenizacion — revisa con Culqi') y loggear el intento en AppErrorLog. Hoy no queda NINGUN rastro server-side de estos fallos (PaymentTransactionLog y AppErrorLog en cero para teo-154a). Nota: cuando Culqi habilite el permiso del comercio de Victor, verificar tambien que la respuesta 200 de /v2/tokens si incluya ACAO (no comprobable hoy sin un comercio autorizado).

    Liberado el 23/7/2026
  • 0
    BugOtro

    Web rider: el checkout de pasarelas redirect (PayPhone/Pagadito/Kontigo) se abre en IFRAME y el proveedor lo BLOQUEA por CSP — página en blanco siempre

    En Flutter web, WebViewCheckout.show (kIsWeb) renderiza la URL hosted del proveedor en un iframe overlay (packages/cabgo_payments/lib/src/widgets/web_checkout_overlay_web.dart), pero PayPhone responde con CSP frame-ancestors none + X-Frame-Options DENY (verificado hoy con curl -D sobre pay.payphonetodoesposible.com/Anonymous/Index con paymentId real del tenant yevfood-). Resultado: en la app WEB la página de pago de PayPhone NUNCA carga (overlay oscuro con tarjeta blanca vacía). En la app nativa el WebView es top-level y sí funciona. Evidencia: Prepare 200 OK con las llaves reales de yevfood- (paymentId ph25fkerUVP00q2rhr4w), la página carga 200 standalone, y bloquea todo framing (doble CSP: frame-ancestors none + frame-ancestors self https://www.cabgo.app/r/yevfood- => intersección = bloqueado en cualquier ancestro; ademas web.cabgo.app ni siquiera matchea). Fix sugerido: en web, para pasarelas redirect NO usar iframe — abrir top-level (window.location o nueva pestaña con retorno via responseUrl /confirm-order), dejando el iframe solo para tokenize-forms propios. Aplica a PayPhone/Pagadito/Kontigo y a cualquier hosted checkout con frame-ancestors. Contexto cliente: Yev/yevfood- (conv 423202) reporta "no abre la página de payphone"; su token ya es válido (folio previo cmrwpy6ue RELEASED).

    Liberado el 23/7/2026
  • 0
    BugOtro

    Delivery: el listado por CATEGORIA filtra por GPS del telefono (ignora la direccion de entrega elegida) y sin coords muestra TODO sin filtrar

    Caso Deivith/Aztek (demo-andale-delivery-6306684c, conv 421774): con los 9 negocios ya en deliveryRadiusKm=7 verificado, el cliente reporta que 'aun aparecen restaurantes a 20km' tras cambiar su direccion a una lejana. REPRODUCIDO server-side OK: GET /api/mobile/rider/delivery/businesses con lat/lng a 20km devuelve 0 negocios; con coords cercanas 7; SIN coords devuelve los 7 sin filtrar (by design). Los gaps son de cliente: (1) category_businesses_screen.dart:47-64 obtiene posicion con Geolocator.getCurrentPosition (timeout 3s) en vez de usar la direccion de entrega elegida (CartManager.deliveryLat/Lng) — si el usuario esta fisicamente cerca ve todo aunque su direccion este lejos, y si el GPS falla/deniega pasa lat/lng null y el server no filtra nada; (2) en web, sin permiso de ubicacion y sin direccion elegida, el home lista TODO el catalogo sin filtro y el usuario recien se entera en checkout ('Direccion fuera del radio'). Propuesta: la pantalla de categoria debe preferir CartManager.deliveryLat/Lng y solo caer a GPS si no hay direccion; y considerar un empty-state 'comparte tu ubicacion para ver negocios cercanos' en vez de listar sin filtrar. El fix (1) es de app nativa: requiere rebuild.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Autocomplete de direcciones: en ciudades fronterizas el GPS deriva el PAIS VECINO y el filtro duro countryCode excluye todas las direcciones locales (Ituzaingo AR -> resultados solo de Paraguay)

    Caso real: Favio / Itu Drive (demo-rayo-taxi-2c389d5b, Ituzaingo CORRIENTES AR, conv 423531). El lead reporta: 'no me esta tomando direcciones de Ituzaingo, me muestra de Paraguay'. CAUSA RAIZ (verificada en codigo): 1. src/app/api/maps/autocomplete/route.ts:102-105 — cuando el cliente manda GPS, tenantCountry = getCountryFromCoords(lat,lng), con fallback a Company.country solo si la derivacion falla. 2. src/lib/services/maps/coords-to-country.ts — lookup por BOUNDING BOXES ordenados por area. El bbox de PY llega hasta south=-27.600; Ituzaingo AR esta en (-27.5884, -56.6901), o sea DENTRO del rectangulo de PY, y PY (mas chico) gana sobre AR en la banda de solape. getCountryFromCoords devuelve PY para toda la ciudad de Ituzaingo. 3. here-provider.ts:184-187 aplica in=countryCode:PRY como filtro DURO -> HERE excluye TODA direccion argentina. google-provider.ts:120-123 tiene el mismo filtro duro (components=country:py). REPRO (token demo rider del tenant, prod): - GET /api/maps/autocomplete?input=plaza san martin ituzaingo&lat=-27.5884&lng=-56.6901 -> 5/5 resultados de Paraguay (Asuncion, Carmen del Parana, Villeta...). - Misma query SIN lat/lng -> 'Plaza San Martin, Corrientes, W3302 Ituzaingo, Argentina' (correcto, via Company.country=AR). La zona del tenant esta perfecta (CIRCLE -27.5884,-56.6900 r=30km, ARS, country=AR) — el fallo es exclusivo de la derivacion pais-por-GPS. IMPACTO: cualquier tenant/demo en ciudad fronteriza dentro del solape de bboxes pierde el buscador de direcciones por completo (el sintoma parece 'la demo no funciona'). Ituzaingo, Posadas/Encarnacion, y en general toda ciudad a <30-50km de una frontera con bbox generoso. FIX SUGERIDO: si el punto GPS tambien cae dentro del bbox del Company.country del tenant, preferir Company.country (la derivacion multi-pais solo debe ganar cuando el punto esta INEQUIVOCAMENTE fuera del pais del tenant). Alternativas: point-in-polygon real, o degradar countryCode de filtro duro a bias cuando derived != Company.country. Sin workaround de config: no hay flag por tenant para desactivar la derivacion por GPS. Al lead se le dio como interim elegir origen/destino con el pin del mapa.

    Liberado el 23/7/2026
  • 0
    BugOtro

    aka-delivery: defaultHomeVertical=delivery se ignora en cold start — la app abre en Taxi (race de hidratación, no se persiste en SWR)

    Cliente: Alejandro / Aka Delivery (PRO), conv 402735, reporta 23-jul con video: "Todavía al abrir, me abre en modo taxi y no Delivery". Diagnóstico verificado en código: - CompanySettings.defaultHomeVertical=delivery está correcto en su config (verificado por GET company-config). - Sus builds son 1.0.121 del 22-jul, posteriores al feat d12e7140e (14-jul) que introdujo defaultHomeVertical — NO es build vieja. - Causa raíz: company_settings_cache.dart línea 280 inicializa _defaultHomeVertical="taxi" y SOLO se actualiza en la hidratación de red (línea 1380). A diferencia de riderTabsConfig/riderLandingMode/roleBranding, NO se persiste a SharedPreferences ni se restaura en restoreModuleFlags() → en cold start defaultRiderHomeRoute() (app_router.dart:2078) corre con "taxi" antes de que llegue la config y el rider aterriza en Taxi. El launcher HOME tuvo su fix de esta misma race (cmrt0p1n3, riderProvisionalLanding) pero el camino defaultHomeVertical no tiene equivalente. Fix sugerido: persistir defaultHomeVertical en SharedPreferences (patrón SWR igual que riderLandingMode) y/o re-aterrizar al llegar la hidratación como hace el launcher. Requiere recompilar para nativo. Ironía: la feature se construyó específicamente para aka-delivery (comentario nb8fus en app_router.dart:2074) y es el tenant al que no le funciona.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Driver web/Trip Center: la PRIMERA solicitud entrante llega EN SILENCIO (sin tono de nueva solicitud)

    Reporte de Efrain / Alo Taxi (conv 380033, probando app conductor WEB web.cabgo.app/?company=alo-taxi&role=driver): al pedir un viaje como pasajero, la solicitud entra al Centro de viajes del conductor pero SIN sonido — cero tono de nueva solicitud. Las demas notificaciones (voces predeterminadas voice_arrived etc.) SI suenan, o sea el audio del navegador esta desbloqueado; el problema es que el trigger nunca dispara. Diagnostico de codigo: apps/cabgo/lib/features/driver/trip_center/bloc/trip_center_bloc.dart:266-273 — el sonido newBusinessOrder solo se reproduce si hadExistingTrips=true (asume que la PRIMERA solicitud ya sono upstream via el path de oferta de home_screen/RideRequestScreen). Cuando la solicitud llega solo por el stream/lista del Trip Center (caso web y/o modo sin offer-card), esa asuncion falla y la primera solicitud de la sesion entra muda. home_screen.dart:2323 si suena cuando TripCenterScreen.isActive pero solo en el evento de RideRequestBloc, que no siempre dispara en web. Propuesta: en trip_center_bloc sonar tambien cuando !hadExistingTrips si ningun sonido upstream se reprodujo (p.ej. flag/timestamp compartido en SoundService), o sonar siempre en web. Es la alerta mas critica del conductor (misma familia que cmqk04558/cmqfkoebe).

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    App conductor/pasajero: enlace Cambiar modo del menu lateral se ve deshabilitado (gris alpha 0.4, sin forma de boton) — parece roto aunque funciona

    Reporte de Antonio (Driiby, taxi-y-movilidad, conv 423015, build Driiby v1.0.4 #5): "el boton de cambiar modo no se ve. A veces aparece y a veces desaparece, solo se ven las letras pero no el boton". Diagnostico en codigo: en el drawer del conductor (apps/cabgo/lib/features/driver/home/screens/home_screen.dart ~3594-3628) y del pasajero (rider/home/screens/home_screen.dart ~1579) la entrada Cambiar modo es un InkWell con texto caption al 40% de opacidad — SI es tocable y funciona, pero visualmente lee como texto deshabilitado/fantasma, y contrasta con Mi perfil donde el mismo switchMode es un AppButton completo. El cliente interpreta la inconsistencia como que el boton "a veces aparece y a veces desaparece". Propuesta: darle affordance de boton (outline/chip) al enlace del drawer o igualarlo al AppButton del perfil.

    Liberado el 23/7/2026
  • 0
    BugOtro

    ZoneRoutePrice: el orderBy serviceTypeId desc con NULLS FIRST puede hacer que la fila ALL-services gane sobre la especifica

    Detectado durante el diagnostico de pricing de super/Super Ride (tick 126, terminal Support). En el resolver de ZoneRoutePrice (src/app/api/mobile/rider/trips/request/route.ts:784) el orderBy usa serviceTypeId: desc. Con el comportamiento NULLS FIRST de Postgres en orden desc, la fila generica (serviceTypeId NULL = aplica a todos los servicios) puede ordenarse ANTES que la fila especifica del servicio, contradiciendo el comentario del codigo sobre service specificity. SINTOMA OBSERVABLE: una ruta con precio especifico por servicio puede ser pisada por la fila generica, o al reves segun el caso — pricing inconsistente en rutas inter-zona. MITIGACION APLICADA EN super: se desactivaron las 6 filas FLAT solo-Estandard en conflicto y se recrearon 90 rutas MULTIPLIER coherentes. Pero el bug de ordenamiento sigue latente para cualquier tenant que mezcle filas genericas y especificas en la misma ruta. FIX SUGERIDO: ordenar con NULLS LAST explicito (o sortear en JS privilegiando serviceTypeId != null).

    Liberado el 23/7/2026
  • 0
    BugOtro

    Registro conductor: ocultar un campo de sistema del paso 3 (vehicleModel) BLOQUEA el registro — sentinel de 1 char no pasa min(2) del step3Schema

    Tenant driving-viajes oculto vehicleModel via systemFieldOverrides (DRIVER.3.vehicleModel isActive:false). La app oculta el campo correctamente, pero el server inyecta el sentinel STEP3_DEFAULTS.vehicleModel = em-dash (1 caracter) via applyOverrideDefaults, y step3Schema (src/lib/registration/step-schemas.ts:121) exige vehicleModel min(2) -> el registro SIEMPRE rebota con FIELD_MIN_LENGTH:2 (snackbar: Modelo del vehiculo debe tener al menos 2 caracteres) sin campo visible en pantalla. Imposible completar el paso 3 con el campo oculto. Evidencia: video de Hernando Garzon conv 411789 (22-jul), diagnostico reproducido en codigo. LATENTE en paso 1: step1Defaults usa em-dash para firstName/lastName con min(2) -> ocultarlos rompera igual. Fix sugerido: sentinel de 2+ chars o relajar el min cuando el fieldKey esta en hiddenKeys. Workaround aplicado: se pide al tenant reactivar el campo Modelo en su panel (Configuracion -> Registro).

    Liberado el 23/7/2026
  • 0
    BugOtro

    PWA: manifest dinamico con start_url punto PIERDE ?company= — la app instalada abriria la generica (secuela de cmrwkz30u)

    Detectado verificando conv 390135 (Danny/TRANS RAMOS). El fix cmrwkz30u dejo el href del manifest con ?company=<slug> (verificado OK: GET web.cabgo.app/manifest.json?company=demo-rayo-taxi-5f723d31 devuelve name/short_name/icons del tenant). PERO el manifest generado en _worker.js handleManifest usa start_url: "." — al resolverse contra la URL del manifest el query se descarta: una PWA instalada de verdad (WebAPK) abriria https://web.cabgo.app/ SIN ?company= -> app generica sin tenant. Hoy no explota porque Chrome esta creando shortcuts (badge de Chrome sobre el icono, abren la URL exacta con query), pero eso trae el segundo sintoma que el cliente SI reporto: el acceso queda con badge de Chrome y abre con la barra del navegador (no standalone). Fix: en handleManifest setear start_url (y scope) conservando la query, ej. start_url=/?company=<slug>&role=rider con el slug ya resuelto; y revisar criterios de instalabilidad (service worker del build Flutter en web.cabgo.app) para que Chrome ofrezca instalacion real sin badge.

    Liberado el 23/7/2026
  • 0
    IdeaOtro

    Listado de negocios del rider: los ABIERTOS deben ordenarse antes que los cerrados

    Pedido de Alejandro / Aka Delivery (PRO, conv 402735): Pizza Party esta abierto pero no se ve hasta scrollear porque el listado ignora isOpen al ordenar. Verificado en codigo: /api/mobile/rider/delivery/businesses ordena por name asc (route.ts:171), luego por distancia si hay lat/lng (:297) o por assignment order de categoria (:315) — el estado abierto/cerrado (isCurrentlyOpen, :215) NUNCA participa del sort. Con 43 negocios en su tenant, los abiertos quedan enterrados entre cerrados. Propuesta: sort estable con abiertos primero (isCurrentlyOpen desc) antes del criterio actual (distancia/nombre/orden de categoria). Cambio server-side, no requiere rebuild.

    Liberado el 23/7/2026
  • 0
    BugOtro

    PayPhone: Prepare 401 (token sin permiso Boton de Pagos) falla en SILENCIO — sin probe al guardar y la app se traga el 500

    Tenant yevfood- (EC, conv 423202): al presionar Realizar pedido con PayPhone la pagina NO abre y no se muestra ningun error. Evidencia reproducida con SUS credenciales reales: POST https://pay.payphonetodoesposible.com/api/button/Prepare con su token (326 chars) y storeId eab07bad-a818-4e75-b2e5-51f9fc5945d9 devuelve HTTP 401 {message: Su aplicacion no esta autorizada para acceder a este recurso... a que recursos puede acceder su tipo de aplicacion}. Sus 3 FoodOrders de prueba (22-jul 17:31, 19:58, 23:08) quedaron paymentStatus=PROCESSING: /delivery/orders/[id]/payphone-checkout marca PROCESSING, llama Prepare, revienta con 500, y en Flutter _runRedirectCheckout hace catch(_){} (checkout_screen.dart ~647) -> el cliente solo ve que nada pasa. DOS gaps: (1) NO existe payphone-probe.ts — provider-probe no valida PAYPHONE al guardar, un token invalido queda como configurado (mismo patron que cmrwdc67c/Culqi); (2) el error de Prepare no se muestra al usuario en el checkout. Causa raiz del cliente: su token PayPhone no es de una aplicacion tipo Boton de Pagos autorizada — se le pidio generar el correcto. Fix sugerido: probe PAYPHONE al guardar + surface del error en la app.

    Liberado el 23/7/2026
  • 0
    BugOtro

    Registro conductor app: campos FILE/PHOTO configurados en PASO 1 NUNCA se suben — el POST omite el archivo y el backend rechaza '<label> es requerido' pese al checkmark (bloquea TODO registro)

    Caso: driving-viajes (Yesid, conv 411789, video). Conductor Hernando Garzon adjunta la Licencia de conduccion en Paso 1 (checkmark rosa visible), pulsa Continuar -> spinner -> toast rojo 'Licencia de conduccion es requerido'. Imposible registrarse. Causa raiz (verificada en codigo): en apps/cabgo/lib/features/driver/auth/screens/register_screen.dart el submit del case 1 arma `data` con firstName/lastName/email/phone + `_collectCustomFieldsForStep(1)`, y `_collectCustomFieldsForStep` (linea ~1501) SALTA explicitamente los tipos FILE/PHOTO/PROFILE_PHOTO ('handled separately in dynamic step submission') — pero el manejo separado (loop de `_uploadFile` + docData) SOLO existe en los cases 2 y 4. Un campo FILE/PHOTO con registrationStep=1 jamas se sube ni se incluye en el POST, y el fail-fast del backend (src/app/api/mobile/auth/register/route.ts:592-608, preSchema de step-1 regFields) devuelve CUSTOM_FIELDS_INVALID con '<label> es requerido'. Resultado: cualquier tenant que configure un campo de foto requerido en el paso 1 (el dashboard lo permite) bloquea el 100% de los registros de conductores, con un mensaje que culpa al usuario. Fix sugerido: en el case 1 del submit, correr el mismo loop de upload de `_getFileFieldsForStep(1)` que usan los pasos 2/4 y adjuntar las URLs; o que el dashboard/endpoint no permita FILE/PHOTO en step 1 mientras la app no lo soporte. Workaround YA aplicado para driving-viajes: el campo id_front (Licencia de conduccion) se movio de registrationStep 1 -> 2 via /api/ai-agent/registration-fields (DELETE+POST, verificado por SQL); en el paso Documentos el upload si funciona. Otros tenants con el mismo patron siguen expuestos. Emparentado (superficie distinta, misma familia): cmrmdw7cc (additional_info_screen valida 'Foto de perfil es requerido' con foto cargada).

    Liberado el 23/7/2026
  • 0
    BugOtro

    seven/ARGENT: publicar build 1.0.63 al track alpha BLOQUEADO — declarations preflight falla (worker Play Console 401 + ERR_TOO_MANY_REDIRECTS)

    Cliente Temistocles (FULL) corrigio con razon: la ultima version PUBLICADA en Play es 1.0.61 (StoreRelease PUBLISHED 2026-07-21 17:02 UTC = 14:02 AR). Los builds 1.0.62 (b63) y 1.0.63 (b64, id 57a30ce9-85ae-4738-af01-f58dad091962, SUCCESS 22-jul 20:21 UTC, con AAB) NUNCA se subieron a Play (0 StoreRelease). Un OUT del 22-jul 20:51 le afirmo que 1.0.63 subia al canal de prueba — falso. Intente POST /api/ai-agent/store/publish (track alpha) hoy 23-jul: rebota en declarations-preflight con missing background_location, foreground_services, full_screen_intent. El heal POST /store/declarations falla 2 veces: foreground_services HTTP 401 invalid authentication credentials (Play Console API), full_screen_intent net::ERR_TOO_MANY_REDIRECTS en play.google.com/console/u/1/developers/5091815942403329462/app/4972424899529220579, background_location pide releaseId/trackId via releaseStatusRest. Parece sesion/worker Play Console degradada para ese developer account. ACCION: sanar sesion del worker, completar las 3 declaraciones y re-disparar publish de 1.0.63 a alpha. Cliente MOLESTO esperando ver los cambios; se le prometio aviso cuando este visible.

    Liberado el 25/7/2026
  • 0
    BugOtro

    Elige tu viaje (rider) IGNORA ServiceType.order — la lista sale en orden de filas de ZoneServiceConfig

    Tenant super/Super Ride (FULL, Lima, conv 416414): el dueno reordeno sus servicios y Economico tiene order=0 en DB, pero en la app del pasajero (Elige tu viaje) sale ULTIMO: Estandard, SUV, Premium, Super Patas, Turismo, Economico (captura del cliente 22-jul). Causa en codigo: src/app/api/mobile/rider/services/route.ts construye serviceConfigsMap iterando zone.ZoneServiceConfig SIN orderBy (el include de ZoneServiceConfig no ordena; el unico orderBy order asc es el del include ServiceType de companySettings, que solo alimenta un Set de IDs). El array final Array.from(serviceConfigsMap.values()) nunca se re-ordena por ServiceType.order, y el cliente Flutter (ride_options_screen.dart) renderiza el orden del API tal cual. El fix del drag-handle del dashboard (cmrw626v4 RELEASED) persiste bien el order — pero el endpoint del rider lo ignora. Fix sugerido: sort final por ServiceType.order (asc) antes de responder. Afecta a TODOS los tenants que reordenan servicios.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Home delivery del pasajero ignora el orden admin de categorias y el bloque virtual Otros no se puede posicionar

    Reporte de Alfredo (yumm, PRO, conv 417942): quiere mover la seccion Otros al final del home de delivery del pasajero y hoy NO es posible por config. Diagnostico en codigo: (1) el home agrupa secciones en orden de insercion de la lista de negocios que el API devuelve ordenada POR DISTANCIA (src/app/api/mobile/rider/delivery/businesses/route.ts:297 sort by distance; apps/cabgo/lib/features/rider/delivery/screens/delivery_home_screen.dart _businessesByCategory + render en orden del map), o sea la posicion de cada seccion la decide que categoria tenga el negocio mas cercano — el campo BusinessCategory.order (que el dashboard SI permite reordenar con drag&drop en delivery/categories) NO se respeta en el home. (2) Otros es un bucket virtual del cliente Flutter (delivery_home_screen.dart:257 catName ?? Otros) para negocios con categoryId NULL — yumm tiene 54 negocios sin categoria — y no existe forma de posicionarlo. Pedido: que el home ordene las secciones por BusinessCategory.order asc y que el bucket Otros caiga SIEMPRE al final (o sea posicionable). Workaround actual comunicado al cliente: asignar categoria a los negocios para que Otros desaparezca. Nota: el fix del home es en la app Flutter -> requiere rebuild para que el cliente lo vea.

    Liberado el 22/7/2026
  • 0
    BugOtro

    driving-viajes: Editar perfil rider (web) muestra bandera +52 MX con telefono guardado +57 CO — riesgo de corrupcion al Guardar (reincidencia de cmqjcywuy/cmqld8qqw ya RELEASED)

    Yesid (conv 411789, tenant driving-viajes CO, STARTER) manda captura 2026-07-22: pantalla Editar perfil del rider en web.cabgo.app muestra selector con bandera MEXICO +52 y el numero local 3104851200, pese a que el Customer esta guardado CORRECTO como +573104851200 (verificado por SQL; dylan +573152824980 tambien correcto). Es defecto de DISPLAY: el selector no parsea el prefijo +57 guardado y cae al default +52. RIESGO REAL: _saveProfile concatena _selectedCountryCode + digitos -> si el usuario toca Guardar sin corregir la bandera, el telefono se re-guarda como +52310... (corrupcion: el conductor llamaria a numero mexicano). NOTA: en el working tree de apps/cabgo/lib/features/rider/profile/screens/edit_profile_screen.dart YA existe el wiring resolvePhoneInitial (parsea prefijo guardado + fallback a Company.country) sin deployar — el build web servido aun trae el default +52. Falta: commit + deploy del build web (y builds moviles de tenants CO). Reincidencia del patron de folios RELEASED cmqjcywuy, cmqld8qqw, cmper6xr8.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Chat de soporte del NEGOCIO roto desde las pantallas de auth business (welcome/pending): rutea al endpoint rider/driver con JWT de business -> 401 y el ticket nunca se crea

    Tenant: seven / ARGENT (FULL, businessChatEnabled=true desde el panel). Cliente Temistocles reporta que el boton con audifonos 'Contactar soporte' entrando como negocio NO funciona, y confirmo que pasa IGUAL en celular y en computadora (web.cabgo.app es el mismo build Flutter web) -> no es del dispositivo. EVIDENCIA DB: SupportTicket de seven = 7 tickets, TODOS senderRole=RIDER, CERO con businessId. El envio del negocio jamas llega a crear ticket. (Globalmente SI existen 5 tickets BUSINESS de otros tenants — la feature cmpvt1dum funciona cuando se entra por la ruta correcta.) ROOT CAUSE (verificado en codigo): 1) apps/cabgo/lib/features/business/auth/screens/welcome_screen.dart:92 — boton 'Contactar soporte' (Icons.headset_mic_outlined, label businessContactSupport, exactamente el que describe el cliente) hace context.push(AppRoutes.supportTickets) — la ruta GENERICA rider/driver, NO AppRoutes.businessSupportTickets. 2) Idem en apps/cabgo/lib/features/business/auth/screens/pending_approval_screen.dart:114. 3) Con business:false, SupportTicketsScreen (features/shared/screens/support_tickets_screen.dart initState) usa el getter dinamico apiService, que con currentRole==business devuelve businessApiService -> baseUrl {server}/api/mobile + /support = /api/mobile/support CON EL JWT DE BUSINESS. 4) /api/mobile/support usa verifyMobileJWT (src/lib/mobile-auth.ts:62) que solo acepta type driver|rider|guest -> el token business da 'Invalid token' 401. 5) El GET se traga el error en silencio (catch vacio -> lista vacia) y el POST de crear ticket cae al snackbar de error. Resultado: el cliente ve que 'no funciona' y el backend nunca recibe nada — consistente con 0 tickets BUSINESS. FIX SUGERIDO: en welcome_screen y pending_approval_screen rutear a AppRoutes.businessSupportTickets (SupportTicketsScreen(business:true)) cuando hay sesion de negocio; ojo que en welcome (sin negocio vinculado) puede no haber JWT business valido — en ese caso usar el canal rider con riderApiService o esconder el boton. Requiere rebuild de la app del tenant para verse en su dispositivo. Conv Chatwoot 418800. Al cliente se le comunico que el fallo esta identificado en el cableado del boton y que se avisara al quedar — SIN fecha.

    Liberado el 22/7/2026
  • 0
    BugOtro

    PWA instalada desde link compartido (?company=) queda con icono y nombre CabGo genericos — index.html no reescribe el href del manifest con el slug

    Caso: Danny / TRANS RAMOS (conv 390135, demo-rayo-taxi-5f723d31). Instalo la PWA con Agregar a pantalla de inicio desde https://web.cabgo.app/?company=demo-rayo-taxi-5f723d31&role=rider y el acceso quedo con el icono generico de CabGo (smiley go) y nombre CabGo/Cabgo, no con su logo TRANS RAMOS (captura en el hilo). Golpea la percepcion de marca de TODOS los tenants/demos en host compartido — es el primer momento marca-en-el-celular de cada lead. Diagnostico (verificado en vivo 2026-07-22): - GET https://web.cabgo.app/manifest.json?company=demo-rayo-taxi-5f723d31 -> CORRECTO: name TRANS RAMOS + logoUrl del tenant (handleManifest en apps/cabgo/web/_worker.js resuelve ?company bien). - GET https://web.cabgo.app/manifest.json (sin query) -> manifest default CabGo. - El HTML servido para ?company=... contiene <link rel=manifest href=manifest.json> SIN el query param: rewriteBrandedHead() reescribe title/favicon/apple-touch-icon/og:* pero NUNCA el href del manifest. Chrome pide /manifest.json pelado -> resolveBranding devuelve null -> manifest default -> PWA generica. - cmr24tndr (RELEASED) cubrio solo dominios propios (resolucion por Host); el caso host compartido ?company= quedo fuera. Fix sugerido: en rewriteBrandedHead reescribir el href a manifest.json?company=<slug> cuando la resolucion vino por slug (analogo al favicon). Nota menor: los icons del manifest dinamico se declaran type image/png aunque logoUrl puede ser webp — declarar el MIME real o omitir type.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    Exponer en el panel el interruptor notifyDriversOnScheduledCreate (aviso al conductor al crear la reserva)

    El flag CompanySettings.notifyDriversOnScheduledCreate (default OFF) ya esta implementado end-to-end (src/lib/services/trip/scheduled-create-notify.ts, llamado desde mobile/rider/trips/request y b2b-trip-service) y /api/settings/general lo ACEPTA en el PATCH (route.ts:45,268) — pero NO existe ningun control en la UI del dashboard: grep de 'notifyDriversOnScheduled' en src/**/*.tsx devuelve 0 resultados. Consecuencia: el tenant no puede encenderlo solo; hoy solo se puede mover por endpoint ai-agent/company-config, o sea que depende de soporte. Caso ancla: driving-viajes (Yesid, STARTER, Colombia, conv 411789). Configuro CONFORT como 'Siempre programado' y su objetivo textual es 'que el conductor apenas vea el mensaje lo pueda reservar de inmediato'. Con el flag OFF sus conductores no se enteraban de la reserva hasta el dispatch (y su scheduledNotifyMinutesBefore esta en 1 min). Se le encendio a mano por endpoint. Ademas pidio explicitamente aprender a hacer estos cambios el mismo — y este es justo el que NO puede. Propuesta: agregar el toggle en Configuracion > General > seccion 'Viajes programados', junto a 'Habilitar Viajes Programados', 'Dias de anticipacion maxima' y 'Anticipacion minima (min)'. Texto sugerido: 'Avisar a los conductores al crear la reserva' con ayuda de que el aviso previo sigue siendo scheduledNotifyMinutesBefore. Idealmente exponer tambien scheduledNotifyMinutesBefore ahi mismo (driving-viajes lo tiene en 1 minuto, valor que en la practica deja la reserva sin conductor). Antecedentes: la funcionalidad salio por cmrvhd50a (ted-go, RELEASED) y cmrvhwmm6 (DUPLICATE). Este folio NO es la feature: es el gap de UI que la deja atada a soporte.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    Tooling: /api/ai-agent/coupons no permite EDITAR un cupon existente (solo create + toggle isActive)

    Caso real: carvip (CarVip, CL, conv 416183). El dueno pidio por chat bajar el minTripAmount de su cupon BIENVENIDA (FIXED 3.000 CLP, NEW_USERS, minTripAmount 4.000 CLP -> queria 0 para que aplique a cualquier viaje). Desde soporte NO se pudo ejecutar: POST /api/ai-agent/coupons solo acepta action='create' y action='toggle' (isActive). No hay PATCH/PUT ni DELETE, y Coupon tiene @@unique([companyId, code]) asi que tampoco se puede recrear con el mismo codigo. El unico camino con PATCH real (PATCH /api/v1/coupons/[id], que SI acepta minTripAmount, discountValue, maxDiscount, maxUsesTotal, maxUsesPerUser, validUntil, isActive, audience, description) exige token OAuth de dashboard con scope tenant.settings:write, no la x-api-key de ai-agent. Resultado: hubo que devolverle al cliente la instruccion manual en vez de resolverselo. Pedido: agregar action='update' (o PATCH) a /api/ai-agent/coupons con los mismos campos mutables que ya expone /api/v1/coupons/[id], resolviendo por companySlug + code. Alternativa minima: permitir que el endpoint ai-agent reutilice el handler de v1. Nota de producto relacionada (distinta, ya levantada como cmrwh25vr): el cupon tampoco se auto-aplica al pasajero.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Servicio con "Siempre programado" queda IMPOSIBLE de pedir si el tenant tiene Viajes programados apagado

    Reportado por Yesid (driving-viajes). Su servicio CONFORT quedo con ServiceType.requiresScheduling=true, pero CompanySettings.scheduledTripsEnabled=false. Efecto en la app del pasajero: ride_options_screen.dart:3075 esconde TODA la fila de Programar cuando scheduledTripsEnabled=false, asi que el pasajero NO tiene forma de elegir fecha/hora. Al tocar Solicitar, el backend (mobile/rider/trips/request/route.ts:628-634) devuelve 400 SCHEDULING_REQUIRED con el texto "Este servicio requiere agendar una fecha y hora". Resultado: el servicio es 100% inpedible y el dueno solo ve un mensaje que le pide una fecha que la app nunca le deja poner. Gaps concretos: 1) /api/mobile/rider/services NO expone requiresScheduling por servicio (grep confirmado) -> la app no puede marcar el servicio como solo-reserva ni abrir el date picker automaticamente al seleccionarlo. 2) No hay validacion cruzada en el dashboard: el toggle "Siempre programado" del ServiceType se puede encender aunque "Viajes programados" de la empresa este apagado. Deberia advertir o auto-encenderlo. 3) El error 400 llega como texto crudo sin decir donde se pone la fecha. Workaround aplicado hoy por soporte: PUT /api/ai-agent/services con requiresScheduling=false en CONFORT (verificado por GET posterior).

    Liberado el 22/7/2026
  • 0
    BugOtro

    CRITICO: probeCulqi valida contra https://api.culqi.com/v2/balance, que NO EXISTE — Culqi responde 401 'Ruta invalida' y NINGUNA sk_live valida se puede guardar jamas

    CAUSA RAIZ del folio cmrwdc67c (secretKey NULL en teo-154a). No era llave revocada del cliente: es nuestro probe apuntando a una ruta inexistente. EVIDENCIA REPRODUCIBLE (curl real contra Culqi, 22-jul): 1) Con la sk_live REAL de Victor/Taruca En One (teo-154a): GET https://api.culqi.com/v2/balance -> HTTP 401 {"object":"error","type":"authentication_error","merchant_message":"Ruta invalida, enterate de las rutas en https://apidocs.culqi.com."} GET https://api.culqi.com/v2/customers?limit=1 -> HTTP 200 {"data":[],"paging":null} <-- LA LLAVE ES VALIDA GET https://api.culqi.com/v2/orders?limit=1 -> HTTP 200 2) Control con llave falsa: GET /v2/customers con sk_live_FAKEFAKEFAKE1234 -> HTTP 401 'La llave de autenticacion enviada no es valida' (mensaje DISTINTO). Es decir /v2/customers si autentica de verdad. El 401 de /v2/balance no es un fallo de credencial: es 'ruta invalida'. /v2/balance NO figura en apidocs.culqi.com. El propio cliente nos mando el link de la doc para senalarlo y tenia razon. CODIGO: - src/lib/services/payment/culqi-probe.ts:36 -> fetch('https://api.culqi.com/v2/balance'); linea 40: if (res.status === 401 || res.status === 403) return { ok:false, reason:'invalid_token' }. - src/app/api/ai-agent/payment-config/route.ts:298 -> if (probe && !probe.ok) return 400 => aborta el guardado ANTES de persistir secretKey (linea 313). Misma logica en la ruta del dashboard. IMPACTO: NINGUN tenant en el mundo puede configurar Culqi. Toda sk_live valida se rechaza, el secretKey nunca se persiste y la pasarela queda con isEnabled=true + pk_live + secretKey NULL (sintoma del folio cmrwdc67c). Victor (teo-154a, PRO) lleva 3 dias sin poder cobrar con tarjeta y Culqi ya lo llamo. Ademas le dijimos por error que su llave estaba revocada. FIX SUGERIDO: 1. Cambiar el endpoint del probe a una ruta documentada y de solo lectura: GET https://api.culqi.com/v2/customers?limit=1 (o /v2/orders?limit=1). 200 = llave valida. 2. supportedCurrencies ya no sale del probe: derivarlas del pais del tenant (Culqi = PEN/USD) o dejar de sobreescribirlas. 3. Distinguir en el probe 'ruta invalida' (merchant_message contiene 'Ruta invalida') de 'llave invalida' y NUNCA tratar el primero como credencial mala. 4. Ademas: cuando el probe falle, el panel debe mostrar el merchant_message literal de la pasarela (hoy falla en silencio; ver cmrwdc67c). 5. Al desplegar: recargar la sk_live de teo-154a y avisar a Victor por la conv 413214.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    apolo-food: el selector de Negocio del dialogo 'Crear pedido express' (admin) no tiene buscador ni autocompletado

    Pedido de William (apolo-food, PRO, conv 412412, captura 22/07 18:36). En el panel de admin > Delivery > Pedidos > 'Crear pedido express', el campo 'Negocio' ('Selecciona un negocio') es un desplegable plano: con muchos negocios en la cuenta de produccion hay que scrollear la lista completa. Pide poder ESCRIBIR y que AUTOCOMPLETE (type-ahead) para elegir el negocio. UBICACION EXACTA EN CODIGO: src/app/(dashboard)/dashboard/delivery/orders/express-order-dialog.tsx lineas 224-238 — usa <Select>/<SelectItem> de shadcn (sin campo de busqueda) sobre el array businesses. Arreglo natural: cambiarlo por un combobox (Command + Popover) con filtro por nombre, igual que otros selectores buscables del panel. NO ES DUPLICADO de cmrwceo91 (ese era el buscador sobre la LISTA de solicitudes Express, ya RELEASED el 22/07 y ampliado a busqueda por telefono). Este es OTRO control: el selector de negocio DENTRO del formulario de creacion. William respondio 'no lo veo' al aviso de cmrwceo91 justamente porque lo que necesita es este. Sugerencia adicional del mismo dialogo: si el patron combobox se extrae a un componente, aplicarlo tambien a otros selectores largos del panel (negocios/conductores).

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    Campañas push: el toggle 'excluir perfiles duales' saca destinatarios en silencio (dtour perdio 28 de 57 conductores)

    Caso real dtour (conv 387181, 22-jul). El operador mando 5 campanas seguidas a conductores (ALL_DRIVERS, DRIVERS_BY_ZONE, DRIVERS_BY_SERVICE) y reporto 'no le llega el push al conductor, de todas las formas'. Verificado en DB: TODAS salieron con exito (29/29, 17/17, 16/16, 0 fallos FCM) y hay ACKs de dispositivo en PushLog (RECEIVED, appVersion 1.0.351). La causa del sintoma es el flag excludeDualProfile=true: dropDualProfileMatches() elimina a todo conductor cuyo telefono tambien exista como Customer del mismo tenant. En dtour eso son 28 de 57 conductores con token (verificado por SQL). Comparativa: su campana del 17-jul con excludeDualProfile=false llego a 57; las de hoy con true llegaron a 29. En una empresa de taxi es normalisimo que el conductor tenga tambien cuenta de pasajero — y el dueno que prueba en su propio telefono SIEMPRE cae en ese grupo, asi que el se auto-excluye de su propia prueba y concluye 'no funciona'. Propuesta (UI, sin cambiar la logica): 1) En el preview de la campana mostrar el desglose: 'N destinatarios (M excluidos por perfil dual)' antes de enviar. 2) Cambiar el copy del toggle para que diga a quien saca ('no enviar a conductores que tambien tienen cuenta de pasajero') en vez de 'excluir perfiles duales'. 3) Que el default para audiencias de CONDUCTOR sea OFF (el dedup tiene sentido sobre todo cuando mandas la MISMA campana a pasajeros y conductores el mismo dia). 4) Guardar en el detalle de la campana enviada el conteo de excluidos, para poder diagnosticarlo sin SQL. Codigo: src/lib/services/push-campaign/push-campaign-service.ts (getTargetRecipients / dropDualProfileMatches). --- _Reported via AI agent: AI agent — Chatwoot sweep tick 110D_

    Liberado el 27/7/2026
  • 0
    BugOtro

    REINCIDE (dtour): push de campaña llega con ICONO GENERICO (silueta/cuadro blanco) en Android

    Tenant dtour (DTour Taxi, Peru, conv 387181). El cliente mando captura del centro de notificaciones (22-jul 13:32 hora PE, Samsung/Entel, Android): la notificacion de su campana '🚕 ¡Conductores DTour, actívense! 📲' (enviada 18:24:53 UTC a ALL_CUSTOMERS) aparece con el ICONO GENERICO de Android (circulo azul + cuadro blanco), sin su marca. El cliente lo remarco en verde en la captura y dice textualmente: 'Lo hice para cliente y antes salía un pequeño logo'. Es REINCIDENCIA de dos folios ya marcados RELEASED: - cmqo0o92q 'Icono de notificacion Android: silueta blanca (no hay ic_notification monocromo por-tenant)' - cmrwcefj6 'REINCIDE apolo-food: push de pedido delivery SIGUE con icono generico' Datos verificados en DB: dtour tiene AppBuild SUCCESS recientes (21 y 22-jul), sus DeviceToken son todos android con firebaseProjectId vacio (proyecto Firebase por defecto). La entrega funciona (0 fallos FCM); el problema es exclusivamente el asset del icono de notificacion en el build por-tenant. Pedido: que el pipeline de build genere/embeba el ic_notification monocromo por tenant (y el large icon con el logo del tenant) y que quede verificado EN DISPOSITIVO antes de cerrar — los dos folios previos se cerraron y el sintoma sigue en produccion en otro tenant. --- _Reported via AI agent: AI agent — Chatwoot sweep tick 110D_

    Liberado el 27/7/2026
  • 0
    BugOtro

    RIESGO DE COBRO DUPLICADO: mxc-tours figura appPlan=PRO pagado y aun asi soporte le pide STARTER $399

    Detectado durante sweep (tick 108, terminal Support). REQUIERE DECISION HUMANA antes de volver a hablarle de pago. TENANT: mxc-tours (Juan Pablo Pelayo, MXC Tours). Conv Chatwoot: 390976. DATOS EN DB: appPlan=PRO, appPlanPurchasedAt=2026-06-18 22:21, stripeCustomerId=cus_UiVYnQwae6DWHu, builds Android SUCCESS (la ultima 16-jul). CONTRADICCION: pese a eso, los OUTs de soporte le siguen pidiendo el App Plan STARTER $399 (el de hoy 12:50 lo repite). O ya pago (posiblemente via Alex, el ex-colaborador que le publico la app) o el PRO se activo a mano sin cobro. RIESGO: pedirle dinero a un cliente que ya pago. En la respuesta de hoy se OMITIO deliberadamente toda mencion de pago para no cobrarle dos veces. ACCION SOLICITADA (requiere Stripe, fuera del alcance de soporte): 1. Verificar en Stripe si cus_UiVYnQwae6DWHu tiene un pago real de App Plan. 2. Si pago: marcar el hilo como cliente activo PRO y dejar de pedirle plan. 3. Si NO pago y el PRO se activo a mano: decidir si se regulariza el cobro o se deja como cortesia, y dejarlo escrito para que soporte no improvise. CONTEXTO ADICIONAL: hoy se corrigio que sus ServiceType seguian siendo los de fabrica pese a un OUT del 02-jul que afirmaba que sus tours por asiento ya estaban configurados (era falso). El cliente ya se quejo por eso.

    Liberado el 22/7/2026
  • 0
    BugOtro

    i18n: la tarjeta de entrada al mandado punto-a-punto (Enviar paquete) esta HARDCODEADA en espanol en la app del pasajero

    Archivo: apps/cabgo/lib/features/rider/delivery/screens/delivery_home_screen.dart, _buildSendPackageCard() (~linea 609). Los dos textos visibles son literales en espanol: const Text('Enviar paquete') y const Text('Pide un repartidor para llevar algo de un punto a otro'). Se renderiza en el TOP de la home de delivery cuando deliveryDirectEnabled=true (variante desktop ~linea 438 y movil ~linea 705), asi que lo ve cualquier tenant que active el mandado, en cualquier idioma. Viola la regla TIER-1 de i18n (todo texto visible por context.l10n). Impacto comercial concreto: lead brasileno Entregas Roders (Guarapuava, conv 423461, demo demo-andale-delivery-e88ef42e) escribio 'Esse aplicativo nao gostei' justo cuando lo que buscaba era ese flujo (coleta -> entrega). Se le acaba de activar deliveryDirectEnabled y el boton que va a ver esta en espanol. Nota para el lanzamiento pt-BR: apps/cabgo/lib/l10n/app_pt.arb tiene ~2361 lineas contra ~8749 de app_es.arb (cobertura parcial ~27%), asi que el usuario brasileno ve mezcla pt + fallback. Pedido: mover los 2 literales a las ARB (es/en/it/pt) y exponerlos por context.l10n.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Billetera: cuando la pasarela rechaza la recarga, la pantalla muestra el DioException 502 crudo en vez del motivo real (yevfood-, dLocal Go 403 'Merchant has no authorization')

    Tenant yevfood- (Ecuador, conv 423202). El dueno prueba la recarga de billetera desde web.cabgo.app/d y la pantalla 'Billetera' pinta un bloque rojo con el texto crudo del cliente HTTP: Error: DioException [bad response]: ... status code of 502 ... RequestOptions.validateStatus was configured to throw ... In order to resolve this exception you typically have either to verify and fix your request code or you have to fix the server code. CAUSA REAL (verificada en PaymentTransactionLog, 3 intentos hoy 2026-07-22 17:30:21, 17:41:35 y 17:43:19 UTC, los tres status=FAILED): metadata.error = "dLocalGo /v1/payments 403: Merchant has no authorization to use this API." O sea: la cuenta dLocal Go del tenant (merchantId 218567, probe kycLevelStatus=PENDING) todavia no esta habilitada por dLocal para la API de pagos. Las credenciales SI son validas (no es 401): es un tema de estado del comercio en dLocal. DOS PROBLEMAS: 1) UX/observabilidad (nuestro): src/app/api/mobile/wallet/top-up/route.ts responde 502 cuando el gateway falla, y la app/web pinta el DioException completo. El dueno no tiene forma de saber que el problema es su cuenta de dLocal. Deberia mostrar el motivo mapeado ('Tu pasarela rechazo la operacion: la cuenta dLocal Go aun no esta habilitada para cobrar') + un enlace/aviso en el panel. Mismo patron que el folio cmrpm4bo7 (DioException 403 crudo en Aceptar viaje): es un error crudo de Dio filtrandose a la UI. 2) Diagnostico proactivo: el probe de dLocal ya guarda kycLevelStatus=PENDING y currencies=[] en PaymentConfig.config, pero el panel muestra la pasarela como 'configurada'. Igual que el folio cmrwdc67c (secretKey NULL con isEnabled=true), aqui hay un estado 'habilitada pero incapaz de cobrar' que nada advierte. Propuesta: badge/alerta en Configuracion > Pagos cuando el ultimo probe trae kycLevelStatus != aprobado o cuando hay N transacciones FAILED consecutivas del mismo provider. NOTA para soporte: PAYPHONE no es opcion de recarga de billetera (el hosted top-up solo soporta WOMPI, MERCADOPAGO y DLOCAL — ver route.ts lineas ~720-766), asi que en Ecuador la recarga siempre cae a dLocal Go. PayPhone si opera en pagos de viaje y checkout de delivery.

    Liberado el 27/7/2026
  • 0
    IdeaOtro

    Dashboard: exponer el interruptor de aprobacion automatica de negocios (businessRequiresApproval) en Ajustes

    El flag businessRequiresApproval vive solo en CompanySettings.systemFieldOverrides y NO tiene control en el dashboard: la unica forma de cambiarlo es PATCH /api/ai-agent/company-config. El tenant taxi-y-movilidad (Driiby, Antonio) lo pidio explicitamente (conv 423015) y hubo que activarlo por endpoint. Pedido: un toggle en Ajustes > Delivery/Negocios (Aprobar negocios automaticamente al registrarse) con texto de ayuda de que se saltan la revision manual. Complementa el folio cmrwckwjw (aviso por email/push de negocio nuevo pendiente).

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    Dueno no tecnico nunca llega a su panel: abre cabgo.app (landing en EN + dark) y no hay ninguna puerta visible a /login ni desde la app

    Caso real verificado hoy (Manuel Perez, RD, conv 422089, tenant demo-rayo-taxi-696e2379). El dueno necesitaba aprobar a un conductor PENDING_APPROVAL y estuvo ~1h30 sin lograrlo, mandando audios de frustracion ('no me sale conductores, no me sale, revise en todas partes', 'voy a tener que buscar ayuda'). DIAGNOSTICO POR CAPTURA (el cliente mando screenshot): NO estaba en su panel — estaba en la LANDING de marketing de cabgo.app con el menu hamburguesa abierto (Features / Solutions / Monetization...), renderizada en INGLES y en tema OSCURO. Escribio 'cabgo.app' y aterrizo en la web comercial; nunca vio /login. Sus quejas literales fueron 'me sale muy oscura' y 'en ingles', y ademas 'estoy dandole a los iconos que me estan mandando y todo, pero en una me manda el correo, en otra me manda a pagar' (los CTA de la landing lo mandaban a registro/checkout). TRES HUECOS REALES: 1) La landing publica no ofrece una entrada evidente tipo 'Iniciar sesion / Entrar a mi panel' que lleve a /login. Un dueno que solo recuerda 'cabgo.app' queda atrapado en la web comercial. 2) La APP (rider/driver) no tiene ninguna referencia a que el panel de administracion existe y vive en el navegador. El cliente busco 'Conductores' dentro de la app durante mas de una hora. 3) La landing arranca en ingles + dark segun el navegador/dispositivo, incluso para un visitante de RD (pais LATAM, es). Para un usuario mayor eso es directamente ilegible. PROPUESTAS (cualquiera reduce este soporte): - Boton 'Iniciar sesion' persistente y visible en el header de la landing (hoy el usuario tuvo que abrir el menu y ahi solo hay features). - Default de idioma por pais/Accept-Language en la landing (RD -> es) en vez de EN. - En la app del dueno/admin: fila 'Panel de administracion' que abra el navegador en /login. - Que el correo de bienvenida del tenant traiga el link /login como primer elemento. MITIGACION MANUAL DE HOY (no escalable): el agente aprobo al conductor por POST /api/ai-agent/drivers/approve y forzo themeMode=light en el tenant.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Pasarela habilitada SIN llave privada: PaymentConfig.secretKey queda NULL y el tenant no puede cobrar (teo-154a / Culqi pk_live cargada, sk vacia)

    TENANT: teo-154a (Taruca En One, PE, PRO). Conv 413214 (Victor). El cliente reporta que Culqi le confirmo por telefono que sus llaves ya estan en produccion. ESTADO VERIFICADO EN DB (read-only, 2026-07-22): PaymentConfig id f1cb13b4-0592-43de-a0e0-645358d1aca5 | provider=CULQI | isEnabled=true | isTestMode=false | publicKey=pk_live_YBdC... (24 chars, PRODUCCION) | secretKey IS NULL | config vacio | createdAt 2026-04-05 | updatedAt 2026-07-22 17:18:01 (un minuto DESPUES del mensaje del cliente = acaba de guardar esa pantalla). IMPACTO: gateway-factory.ts case CULQI -> new CulqiGateway(config.secretKey) con undefined -> Authorization: Bearer undefined -> todo cobro con tarjeta responde 401. El tenant aparece con la pasarela ENCENDIDA en el panel (isEnabled=true, publicKey live), cardEnabled=true y zonas General/Zona 1 con enabledProviders=[CULQI], asi que el pasajero veria la opcion de tarjeta y moriria al cobrar. Hoy no hay perdida real: 0 PaymentMethod guardados y los 341 viajes son CASH. GAPS A CORREGIR (src/app/api/settings/payment-config/route.ts): 1) No hay validacion que impida guardar/activar (isEnabled=true) una pasarela sin secretKey. Deberia bloquear el guardado o forzar isEnabled=false + aviso visible. 2) Linea ~261: if (secretKey !== undefined) updateData.secretKey = secretKey || null; -> mandar el campo VACIO BORRA la llave existente sin confirmacion. El GET devuelve la llave enmascarada (maskSecret); si el usuario selecciona y borra ese campo para re-pegarla y guarda sin pegar, la pierde en silencio. Deberia requerir una accion explicita de eliminar, no un string vacio. 3) Falta senal en el dashboard: una pasarela con publicKey live y secretKey NULL deberia mostrarse como INCOMPLETA, no como configurada. ACCION CON EL CLIENTE: se le indico pegar su sk_live en Panel > Configuracion > Pagos > Culqi > Llave privada y guardar; queda pendiente verificar por DB cuando lo haga.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    apolo-food: buscador en la LISTA DE SOLICITUDES de Express (rider express) desde el ADMIN

    Pedido del cliente (William, conv 412412, PDF de pruebas 22/07/26, punto 5). La lista de solicitudes de Express en el panel de administracion no tiene buscador; con volumen alto el admin no puede ubicar una solicitud por cliente, direccion, telefono o numero de orden. Se pide campo de busqueda (y filtro por estado si aplica) sobre esa lista.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    apolo-food: boton para contactar al CLIENTE por WhatsApp desde el detalle de la orden en la app del CONDUCTOR

    Pedido del cliente (William, conv 412412, PDF de pruebas 22/07/26, punto 4). Hoy el repartidor no tiene forma rapida de escribirle al cliente desde el detalle del pedido. Se pide un boton de WhatsApp (wa.me con el telefono del cliente normalizado) dentro del detalle de la orden en la app del conductor/repartidor. Respetar la configuracion de privacidad del telefono del tenant.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Tarifas escalonadas: al activar el toggle queda 1 bloque 0->inf con monto 0 y los campos Desde/Hasta bloqueados — el tenant guarda y el servicio pasa a cobrar SOLO el minimumFare

    TENANT: super (Super Ride Technologies, Lima PE, appPlan FULL). Conv Chatwoot 416414. Reportado por la duena: 'no me deja colocar nada'. ESTADO REAL EN DB (verificado read-only): ServiceType 'Economico' (a99e15c6-d0d3-4fe5-8d11-57ca465db270) tiene useTieredFare=true y tieredFare=[{"from":0,"to":null,"amount":0}], tieredFareSpilloverMode=FIXED. Los otros 6 servicios del tenant estan en false. IMPACTO (pricing leak): en fare-calculator.ts, con useTieredFare=true y spillover FIXED, price = match.block.amount = 0 y luego Math.max(price, minimumFare) => TODO viaje Economico cobra S/4 (el minimo) sin importar la distancia. baseFare/perKm/perMinute quedan ignorados. Aun no hay viajes Economico registrados, asi que no hubo dano economico todavia, pero la config esta viva en produccion. CAUSA UX (src/components/shared/tiered-fare-editor.tsx): 1) 'Desde (km)' es SIEMPRE readOnly+disabled (encadenado). 2) Con UN solo bloque, ese bloque es el ultimo => 'Hasta (km)' se renderiza como un div con simbolo infinito, NO como input. => El unico campo escribible es 'Monto'. El operador percibe que 'no deja colocar nada' y no descubre que primero hay que pulsar '+ Agregar bloque'. 3) validateTieredFare acepta amount=0 (solo rechaza <0), asi que el estado roto SE GUARDA en silencio via /api/settings/service-types. PEDIDOS: a) Bloquear/avisar el guardado cuando useTieredFare=true y algun bloque tiene amount=0 (o exigir >0), o al menos warning explicito 'con monto 0 este servicio cobrara solo el minimo'. b) Al encender el toggle, sembrar 2-3 bloques de ejemplo (0-3 / 3-6 / 6-inf) en vez de un unico 0->inf con monto 0. c) Texto de ayuda visible: 'Desde' es automatico y 'Hasta' del ultimo bloque es infinito; para crear bandas hay que agregar bloques. d) GAP DE TOOLING: no existe endpoint ai-agent para escribir useTieredFare/tieredFare (services PUT no incluye esos campos; company-config solo expone tieredFareCommissionEnabled). Soporte NO puede dejar configuradas las tarifas escalonadas de un tenant aunque este lo autorice — solo puede guiarlo. Agregar tieredFare + tieredFareSpilloverMode a PUT /api/ai-agent/services.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    IDEA (dtour): resaltar con color las filas de conductores PENDIENTES en el panel web de Conductores

    Sugerencia de Dtour Taxi (conv 387181). En el panel web -> Conductores, cuando hay un conductor en estado PENDIENTE de aprobacion, el admin no lo distingue facil de un vistazo. Pide que cuando exista un pendiente se marque la celda/fila completa con otro color (o algun diferenciador visual) para que el admin se de cuenta rapido de que hay solicitudes por revisar. Mejora de UX/visibilidad para el operador del tenant. No es bug: es una idea de producto. Sin compromiso de fecha.

    Liberado el 27/7/2026
  • 0
    BugOtro

    Worker de builds Android COLGADO >14h (service activo, HTTP muerto) — 3 builds BUILDING fantasma; detector de hang desplegado (PR #366)

    Detectado 2026-07-23 ~05:30Z: /status del worker (5.161.219.212:3456) HTTP 000 desde ~19:45Z del 22-jul (primera falla del job Sync). Sintomas: 3 AppBuild en BUILDING desde 15:2xZ (taxi-centroamericanos x2 SIMULTANEAS — imposible en worker serial — y apolo-food 1.0.170) + taxi-la-vip QUEUED. El guard del CI trataba el hang como busy para siempre (skip de restart). FIX desplegado: PR #366 — marker persistente; hang >45min fuerza restart. Kick programado (commit vacio a los 50min) para la 2a corrida que destraba. POST-RECUPERACION pendiente: re-disparar las 4 builds fantasma (taxi-la-vip 1.0.147, taxi-centroamericanos 1.0.54/55 — solo la ultima, apolo-food 1.0.170) y marcar las filas BUILDING viejas como FAILED si el worker no las re-encola solo. Los bugs de balam (cmrw83h4q, splash no aplica) muy probablemente son consecuencia: su build salio del worker colgado o nunca compilo con la config nueva.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Conductor rechazado que RE-COMPLETA registro no vuelve a PENDING_APPROVAL (queda rechazado/BANNED, sin ruta de re-aprobacion)

    Tenant dtour (Dtour Taxi, Peru). El dueno rechazo a una conductora (deisy jahaira ccapali, driverId 790adecb-4833-4ffd-9c71-dcbc099984c0, accountStatus=BANNED, rejectedAt 2026-07-22 14:29). La conductora luego COMPLETO su registro (el dueno recibio push de registro completado) PERO en la web sigue apareciendo como RECHAZADA, NO como PENDIENTE. Consecuencia: no hay ruta natural de re-aprobacion; el flujo de aprobacion solo levanta accountStatus=PENDING_APPROVAL y un driver REJECTED/BANNED que reenvia registro no se resetea a PENDING, asi que no reaparece en la cola de pendientes. Workaround actual: cambiar estado manualmente BANNED->ACTIVE desde el control de estado del conductor (PUT /api/drivers/[id]/status). Pedido: cuando un conductor rechazado completa/reenvia su registro, devolverlo a PENDING_APPROVAL para que el dueno lo apruebe desde la cola normal.

    Liberado el 27/7/2026
  • 0
    BugOtro

    balam: splash (4s) y logo nuevos no se aplican tras compilar

    Tenant balam (PRO, dueno Gerardo Guzman, conv 419872). Actualizo LOGO y subio PANTALLA DE SPLASH a 4 segundos desde el panel y ya COMPILO, pero al abrir la app el splash no se activa y el logo no se refleja. Verificar que el build de balam tome los assets de splash+logo del tenant y respete la duracion 4s. Reportado 2026-07-22.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Operador creator-scoped ve totales/historial GLOBALES en el overview del dashboard (delivery-go / Edwin, op. Angeles)

    Tenant delivery-go (FULL) tiene creatorScopedOperatorsEnabled=true + zoneScopedOperatorsEnabled=true (strict=false). Operadora COMPANY_USER Angeles (angelesdelsur@gmail.com, membership cmrpql2ie000h04lagxxbn8w4, zona Arequipa) creada para subir SUS propios conductores. El LISTADO de conductores (/api/drivers) SI aplica resolveDriverScope (creator+zone). Pero el OVERVIEW/HOME del dashboard le sigue mostrando totales GLOBALES de la empresa (cuantos conductores hay = 23, historial, etc.): esos endpoints de resumen/stats/historial NO consumen resolveDriverScope/getMembershipCreatorScope. Un operador restringido ve numeros que no le corresponden. Pedido de Edwin: que TODO su panel arranque en 0 y solo refleje su sub-flota. Gap = extender el creator/zone scope (idea 0r9yst) a las tarjetas de resumen + historial del dashboard, no solo al listado de conductores. Prioridad: HIGH (cliente FULL que quiere entregar accesos a clientes en Peru).

    Liberado el 22/7/2026
  • 0
    BugOtro

    CLIENT-BLOCKED rapidin: selector Entrega/Recoger NO renderiza en app checkout pese a pickupEnabled=true (reincidente; folio previo cmrvvc4xz marcado resuelto)

    Tenant rapidin (appPlan=PRO). Cliente Ernesto Ayala, conv 411105. REINCIDENTE: el folio previo cmrvvc4xz (App checkout no renderiza selector Delivery/Recoger con pickupEnabled=true, web si lo muestra) fue marcado RESUELTO el 22-jul ~10:10, pero el cliente confirma que SIGUE fallando. Estado verificado del backend/config (todo correcto): - Business MINIMARKET LATINO (id a0e883c0-5ac2-4c01-a6c3-7460f96b3600) tiene pickupEnabled=TRUE, status ACTIVE. - GET /api/mobile/rider/delivery/businesses/[id] devuelve pickupEnabled via ...rest. - Codigo mobile checkout_screen.dart renderiza _buildFulfillmentSelector cuando _businessPickupEnabled && !_pickupLocked (lineas 1435-1447). Sintoma: en la WEB el selector Entrega a domicilio / Recoger en tienda SI aparece; en la APP no aparece en el checkout (pantalla de direccion). Cliente en la ULTIMA build publicada: 1.0.73 #74 (v1.10.824), reinstalada limpia. Antes estaba en v67 y no se autoactualizaba; ya subio a 1.0.73 y AUN asi no aparece el selector. Pasos para reproducir: app rapidin actualizada -> MINIMARKET LATINO -> agregar producto -> checkout (pantalla de direccion) -> selector Entrega/Recoger NO se muestra. Hipotesis a validar: 1) La build publicada 1.0.73 de rapidin se compilo ANTES del fix de cmrvvc4xz -> requiere REBUILD + REPUBLICAR rapidin. 2) O el selector aun no renderiza (regresion / _cart.pickupOnly forzando lock / businessId no coincide en cart). Bloquea operacion real: el negocio no puede recibir pedidos de recoger-en-tienda desde la app.

    Liberado el 30/7/2026
  • 0
    BugOtro

    Dashboard Ajustes>Tipos de Servicio: el drag-handle (arrastrar para reordenar) no cambia la posicion de los servicios

    Tenant taxi-y-movilidad (Driiby, Antonio). En admin.driiby.com/dashboard/settings?tab=services cada fila de Tipo de Servicio muestra el drag-handle de 6 puntos, pero arrastrar NO reordena ni persiste el nuevo orden. El cliente marco en rojo el handle de la fila Economico intentando moverlo sin exito. Esperado: poder reordenar los tipos de servicio y que ese orden se refleje en la app del pasajero. Revisar componente de reorder de service types + persistencia (sortOrder/position). Reportado via Chatwoot conv 423015.

    Liberado el 22/7/2026
  • 0
    BugOtro

    ted-go (Roberto): validar que el radio de busqueda de conductores (2 km) se respeta en pedidos inmediatos

    Roberto configuro el radio de busqueda de conductores en 2 km. Reporta que estando el conductor a ~8 km del punto de recogida igual le llega la notificacion y el servicio. Pedido: validar si el filtro de radio se aplica correctamente en la busqueda ABIERTA/inmediata (no en reservas asignadas directo, donde el aviso al conductor asignado es esperado sin importar distancia). Se le pidio confirmar si fue reserva asignada o pedido inmediato. Contexto: recien se activo notifyDriversOnScheduledCreate (aviso instantaneo al asignar) en su cuenta.

    Liberado el 23/7/2026
  • 0
    BugOtro

    ARGENT (seven): paridad web-movil en registro de negocio + labels AR fiscales/bancarios

    Cliente Temistocles (ARGENT/seven, AR, FULL) reporta que los campos fiscales/bancarios del registro de negocio existen en la app MOVIL (register_screen.dart: businessTaxIdLabel, businessBankNameLabel, businessBankAccountLabel, businessAccountTypeLabel, businessLegalRepIdLabel) pero NO aparecen en la version WEB/PC del registro de clientes en la seccion negocios. Pide paridad web<->movil y ademas labels AR-especificos: (1) Identificacion fiscal -> 'Identificacion Fiscal (Cuit)' con 11 digitos; (2) Banco -> 'Banco/Entidad financiera'; (3) casillero de cuenta -> 'CBU/CVU' con 22 digitos; (4) Tipo de Cuenta como selector con opciones: Cuenta Corriente, Caja de Ahorro, Billetera virtual; (5) 'Cedula del representante legal' -> 'DNI del representante legal'. Los labels son l10n hardcoded (no self-serve). Necesita esto para captar posibles negocios. Conv Chatwoot 418800.

    Liberado el 23/7/2026
  • 0
    BugOtro

    App checkout no renderiza selector Delivery/Recoger con pickupEnabled=true (web si lo muestra)

    Tenant rapidin (PRO). Negocio MINIMARKET LATINO tiene pickupEnabled=TRUE en DB y el endpoint GET /api/mobile/rider/delivery/businesses/[id] devuelve pickupEnabled. En la WEB el cliente SI ve el selector Entrega a domicilio / Recoger en tienda al checkout. En la APP nativa (android 1.0.71, posterior al feature 56dbc26a6 del 2026-05-14) el selector NO aparece: el checkout va directo a Entrega a domicilio, sin el segmented control arriba de la direccion. Sospecha: _loadBusinessFulfillment() (getBusiness) soft-falla en la app dejando _businessPickupEnabled=false, o la version instalada en el device es anterior. Verificar por que la app no rinde el selector cuando pickupEnabled=true mientras web si. Reportado por Ernesto Ayala, conv 411105.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Pre-cobro (PRE_TRIP 'Al solicitar') NO soporta Culqi: cae en proceed:true = se comporta como POST_TRIP en SILENCIO

    Hallazgo proactivo (hilo Victor/teo-154a conv 413214). `src/lib/services/payment/pre-trip-charge.ts` (handlePreTripCharge) implementa el pre-cobro solo para STRIPE, TRANSBANK, MERCADOPAGO, WOMPI, QPAYPRO, PAYWAY. **Culqi NO esta cableado** (grep 'culqi' en el archivo = 0 matches). Un tenant con Culqi + chargeTiming=PRE_TRIP ('Al solicitar el viaje') cae en un `return { proceed: true }` (fallthrough) y se comporta como POST_TRIP: NO cobra por adelantado pese a estar configurado asi, SIN avisar al operador. Ademas `complete-trip.ts` solo captura pre-auths de Stripe/MP. Riesgo: un tenant Culqi que activa 'Al solicitar' cree que garantiza el pago por adelantado y en realidad no lo hace (silencioso). Hoy teo-154a esta en POST_TRIP asi que no le afecta, pero es un gap latente para cualquier tenant Culqi que toque ese toggle. Fix pedido (uno de dos): (a) cablear Culqi en handlePreTripCharge + captura en complete-trip; o (b) al menos BLOQUEAR/ADVERTIR en el UI de config cuando se elige PRE_TRIP con un gateway no soportado (Culqi u otros fuera de la lista), para que el operador no crea que pre-cobra cuando no. Prioridad LOW (ningun cliente bloqueado hoy, es preventivo).

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    ted-go: activar notifyDriversOnScheduledCreate (aviso al conductor al MOMENTO de crear/asignar la reserva)

    Cliente Roberto (TED Go, slug ted-go, PRO, conv 401863) pide que en viajes PROGRAMADOS la notificacion al conductor llegue en el momento en que se programa el servicio y se asigna el conductor, no solo el recordatorio de 60 min antes. DB actual: notifyDriversOnScheduledCreate=false, scheduledNotifyMinutesBefore=60. La funcion scheduled-create-notify.ts hace exactamente esto (broadcast a conductores elegibles al instante de crear la reserva) pero esta gateada por CompanySettings.notifyDriversOnScheduledCreate y NO es settable via /api/ai-agent/company-config. Accion pedida: poner notifyDriversOnScheduledCreate=true para ted-go (el recordatorio de 60 min queda como respaldo). Bajo riesgo: toggle de config por-tenant.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Tooling interno: GET /api/ai-agent/feedback ignora ?companySlug y ?id, y topa en 100 -> agentes crean folios DUPLICADOS

    El endpoint GET /api/ai-agent/feedback que usa el agente de soporte para verificar si un folio ya existe tiene 3 problemas que causan folios duplicados a diario: 1) El filtro ?companySlug es IGNORADO (devuelve la lista general, no filtra por empresa). 2) El filtro ?id es IGNORADO (devuelve el primer post, no el buscado) -> falso positivo peligroso: un GET ?id=<x> 'encuentra' algo que no es <x>. 3) La respuesta topa en ~100 items mas recientes. Consecuencia: cuando un agente quiere confirmar que un folio ya existe (para no duplicar) y ese folio es mas viejo que los 100 recientes, NO lo encuentra por ningun filtro -> lo trata como fantasma y crea uno nuevo. Ya paso con navan 6x1 (folio real quedo fuera de ventana -> se creo duplicado cmrvdkw84) y con el bug de Driiby ganancias en efectivo (folio real cmrvdjtg4 del tick previo no encontrable -> se creo duplicado cmrvgcvs3). Ambos bugs reales quedan rastreados 2 veces. Fix pedido: que ?companySlug y ?id filtren de verdad en el GET (o exponer ?search por titulo/slug server-side), y/o paginacion (?offset/?cursor) para poder buscar mas alla de los 100. Con eso el agente puede confirmar existencia antes de crear y se eliminan los duplicados. Prioridad MEDIUM (no bloquea al cliente, pero ensucia el backlog de FeedbackPosts y desperdicia trabajo del agente).

    Liberado el 22/7/2026
  • 0
    BugOtro

    Driiby (taxi-y-movilidad): tarjetas de ganancias del conductor muestran Ganancia bruta L0,00 en viajes en EFECTIVO — solo aplica comision y la ganancia neta sale NEGATIVA

    Conductor de Driiby (Honduras, conv 423015, moneda L/Lempira) reporta que su tarjeta de ganancias no refleja lo ganado. 3 capturas verificadas (2026-07-22): - Home conductor: tarjeta HOY = L0,00 con 2 Viajes. - Mis Ganancias > Esta semana: Ganancia bruta = L0,00, Comisiones = -L52,04, Ganancia neta = L-52,04 (NEGATIVA), 3 viajes completados, promedio L115,64/viaje. El Historial de viajes SI muestra las tarifas correctas (kenis wifi L71,19; L206,96; etc.), todos en EFECTIVO. - Billetera: Esta semana Ganancias = L0; los Movimientos recientes solo muestran cargos de Comision 15% en negativo (-L10.68, -L31.04, -L10.32). SINTOMA: en viajes en EFECTIVO (COD), el agregado de ganancia bruta (tarjetas Hoy / Esta semana en Home, Billetera y Mis Ganancias) NO suma la tarifa de los viajes completados; solo se aplica la comision, dando bruta=0 y neta negativa. Las tarifas individuales SI estan registradas (aparecen en el historial), asi que es un bug de agregacion/visualizacion de earnings del conductor para viajes en efectivo, no perdida de datos. Probablemente afecta a todas las cuentas con comision + cobro en efectivo, no solo Driiby. IMPACTO: alto — al conductor le parece que trabajo y perdio dinero; rompe la confianza en la app del conductor. Version app: Driiby v1.0.4 (#5).

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    UX repartidor: control de mapa intuitivo + cobrar total en pantalla de entrega (Balam)

    Cliente Balam (PRO) pide 3 mejoras de UX en la app del repartidor, con video: 1) Control de minimizar/maximizar el mapa poco descubrible: hoy hay una raya/flecha diminuta junto al carro que casi no se ve; el usuario tardo semanas y lo descubrio por accidente. Pide que el area de toque sea mas amplia y el indicador (flecha/barra) mas visible e intuitivo para minimizar/expandir el panel de informacion sobre el mapa. 2) Pantalla de recoleccion (ve a recoger el pedido): el monto deberas pagar aparece abajo; pide subirlo arriba o resaltarlo en negrita para que se vea facil. 3) Pantalla despues de liberar el codigo (entrega): cuando el pago es en efectivo, que ya no diga deberas pagar sino cobrar total. Logica: si ya se pago (tarjeta/online) no mostrar cobro; si es efectivo, mostrar el total a cobrar al entregar.

    Liberado el 27/7/2026
  • 0
    BugOtro

    pedimos-algo iOS: agreement aceptado hoy - re-disparar build (distribution cert) + screenshots ASC

    Alejandro (conv 412401, PRO) acepto hoy 21/07 ~21:09 el nuevo Apple Developer Program License Agreement (Account Holder, Team 92R4V4UUTH) y marco NO-Europa. Esto desbloquea el fallo iOS AppBuild 1.0.48 (12-jul): Manual signing setup failed: Failed to create distribution certificate = sintoma del agreement pendiente (Apple bloquea crear el cert de distribucion). ACCION: re-disparar build iOS de pedimos-algo. PASO SIGUIENTE: StoreRelease iOS 1.0.46 (17-jun) fallo SCREENSHOT_REQUIRED (faltan iPad Pro 12.9 3ra gen 2048x2732 e iPhone 6.5 1242x2688) -> subir screenshots al StoreListing IOS + POST /api/ai-agent/asc/sync-listing antes del submit. SIN fecha prometida al cliente.

    Liberado el 22/7/2026
  • 0
    BugOtro

    reengagement-send rechaza moment T_LINK (400) — el nudge post-link no se puede enviar ni marcar

    POST /api/dashboard/reengagement-send valida contra VALID_MOMENTS = [T1,T2,T3,T_HSM,T_HSM2..T_HSM5], que NO incluye T_LINK. Pero el detector (scripts/reengagement-pending.mjs) SI genera filas reeng:<conv>:T_LINK (ver conv 421461, Alfredo +593994003718) y src/lib/marketing/send-reengagement.ts YA soporta T_LINK (lo rutea por la rama HSM junto con T_HSM*). Resultado: el momento mas caliente de la escalera (post-checkout, casi-comprador) es el unico que el endpoint no puede enviar ni marcar -> queda colgado y se re-sugiere cada tick. Fix: agregar T_LINK al array VALID_MOMENTS en src/app/api/dashboard/reengagement-send/route.ts (y a la validacion de action=skip). Workaround usado hoy: envio manual del HSM via scripts/chatwoot-send.mjs, con la fila T_LINK de 421461 sin marcar sent.

    Liberado el 22/7/2026
  • 0
    IdeaPagos

    Recarga de billetera con checkout hospedado de MercadoPago (habilitar dinero en cuenta / QR / efectivo)

    Pedido de Temistocles Villegas (ARGENT, Neuquen AR, tenant seven), conv Chatwoot 418800. SITUACION ACTUAL (verificada en codigo): POST /api/mobile/rider/wallet/top-up con MercadoPago usa SOLO tokenizacion de tarjeta dentro de la app (card_token + createPaymentIntent). El unico camino de checkout hospedado (data.checkout === true -> redirectUrl / status pending_checkout) esta gateado a dLocal Go (cmrhzww2f, Paraguay/Guatemala). Resultado: en la recarga de billetera NO aparece dinero en cuenta (saldo MP), ni QR, ni efectivo/Rapipago: solo tarjeta. En cambio el PAGO DEL VIAJE si pasa por la pagina de MercadoPago, por eso ahi si aparece dinero en cuenta. PEDIDO: extender el flujo de hosted checkout de top-up (que ya existe en la ruta) al gateway MercadoPago, creando una preference de MP y devolviendo init_point, de modo que el pasajero (y el conductor) pueda recargar su billetera con saldo en cuenta de MercadoPago, QR o los medios offline que MP ofrece en su pagina. VALOR: en Argentina dinero en cuenta es de uso masivo y es la salida natural cuando la tarjeta rebota. El mismo cliente reporto hoy 3 rechazos consecutivos de MercadoPago al recargar (CPT01-OFXLO5OSZFDN dinero en cuenta, CPT01-PQ4Y8OC1Y5TA debito Santander Rio, CPT01-NQ50WNO84TKI credito BBVA Visa): con checkout hospedado esos intentos se resuelven del lado de MP con sus propios medios alternativos. ALCANCE SUGERIDO: reutilizar la rama if (method === CARD && data.checkout) de src/app/api/mobile/rider/wallet/top-up/route.ts, hoy limitada a DLOCAL, y exponer checkoutProvider: MERCADOPAGO cuando el tenant tenga MP configurado. Aplica igual a la billetera del conductor. --- _Reported via AI agent: Temistocles Villegas (ARGENT / seven) — WhatsApp conv 418800_

    Liberado el 27/7/2026
  • 0
    BugOtro

    navan-drivers: builds 1.0.194-1.0.198 compiladas OK pero NO promovidas a Play (produccion sigue en 1.0.193 del 17-jul) - bloquea el CTA Recargar con Wompi

    Verificado 2026-07-21 (conv 411976, Orlando pide estado del boton de Wompi). EVIDENCIA: - ai-agent/builds navan-drivers android: 1.0.198 vc100000149 SUCCESS 21-jul 07:52; 1.0.197 vc100000148 SUCCESS 20-jul 16:18; 1.0.196 FAILED; 1.0.195 SUCCESS 19-jul; 1.0.194 SUCCESS 18-jul. - ai-agent/play-console/release-status?slug=navan-drivers: track production = 1.0.193 (vc100000144) status=completed. NO hay release mas nueva enviada. pendingReview=true pendingCount=2, isRejected=false, policyIssues=[]. - 1.0.193 se compilo el 17-jul 22:40 -> 4 dias con builds diarias exitosas sin promover a Play. IMPACTO CLIENTE: el commit 6b3fa0a4b (20-jul, CTA de recarga con la marca de la pasarela hosted; l10n topUpWithProvider -> "Recargar con Wompi") YA viaja en 1.0.197/1.0.198, pero Orlando sigue viendo "Recargar con tarjeta" porque Play le sirve la 1.0.193. Del lado CODIGO el folio cmrpqgv5d (branding del boton Wompi) esta cumplido; lo que resta es SUBIR la version. Mismo patron que el tenant seven (el paso de subida a Play dejo de dispararse pese a builds diarias OK). Revisar promote-track para navan-drivers. Lanzamiento meta 30-jul.

    Liberado el 21/7/2026
  • 0
    BugOtro

    PATCH /api/ai-agent/feedback REEMPLAZA internalNotes en silencio: cada agente que anota borra el diagnostico del anterior

    src/app/api/ai-agent/feedback/route.ts:445 hace `data.internalNotes = internalNotes` a secas: el PATCH SOBRESCRIBE el campo completo, no concatena. La doctrina de soporte es 'sumar evidencia al internalNotes del post' y varios agentes lo hacen a lo largo del dia sobre el mismo folio, asi que cada anotacion destruye la anterior sin aviso ninguno (la respuesta es ok:true y ni siquiera devuelve el valor viejo). INCIDENTE REAL 2026-07-21 19:1x: al anotar evidencia nueva en cmrj5ikqx (branding CabGo en app.geotaxipro.com) y cmrr47t4z (recarga con tarjeta, delivery-go) se perdio el diagnostico previo de ambos. Solo se pudo restaurar el fragmento de 200 chars que quedaba en el buffer de la consulta previa; el resto se perdio de forma irrecuperable (no hay tabla de historial: solo FeedbackPost, FeedbackComment, FeedbackVote, FeedbackRelease, FeedbackAttachment, FeedbackBugDetails). PROPUESTA (cualquiera sirve): (a) modo append por defecto -- concatenar con separador de timestamp, y exigir un flag explicito replaceInternalNotes:true para pisar; (b) o exponer appendInternalNotes como campo aparte; (c) o devolver el valor previo en la respuesta para que quien anota pueda restaurarlo. Es la misma familia de footgun que cmrv0e1mu (PATCH company-config que responde success:true y no escribe nada): endpoints de agente que fallan/pisan en silencio. --- _Reported via AI agent: Agente de soporte (sweep 2026-07-21)_

    Liberado el 22/7/2026
  • 0
    BugOtro

    Modulo Billetera ignora el alcance por ZONA del operador y mezcla wallets de pasajeros con las de conductores (teo-154a)

    Reportado por Victor (teo-154a, PRO, conv 413214): 'si la funcion del operador es ver, gestionar y recargar a los conductores, por que en el modulo de billetera puede ver a los pasajeros/clientes?'. Tiene razon, y al verificarlo aparecio algo mas grave que lo que el pregunto. 1) SIN SEPARACION CONDUCTOR/PASAJERO. src/app/(dashboard)/dashboard/wallet/wallet-client.tsx:67,1034-1036 expone un selector ALL | DRIVER | CUSTOMER sin ningun chequeo de permisos en el cliente. La API src/app/api/wallet/route.ts:40-41 solo exige requireModuleAccess(session,'finance'), y devuelve wallets de conductores (:107) Y de clientes (:192) filtrando unicamente por companyId (:92,:176). El modulo 'finance' se satisface con CUALQUIERA de sus permisos (src/lib/permission-modules.ts:131-141 + :204-206), y VIEW_WALLETS viene por defecto en COMPANY_USER (src/lib/permissions-constants.ts:491). Es decir: no existe permiso que separe billeteras de conductor de billeteras de pasajero. 2) EL ALCANCE POR ZONA NO SE APLICA EN BILLETERA (lo mas grave para este tenant). El helper resolveDriverScope (src/lib/services/zone-scope/driver-scope-filters.ts) solo tiene callers en src/app/api/drivers/route.ts:83 y src/app/api/drivers/[id]/route.ts:75,215,620. NINGUNA ruta bajo src/app/api/wallet/** lo importa (route.ts, customers/route.ts:44-46, top-ups, rider-top-ups, withdrawals, sync: todas requireModuleAccess('finance') a secas). teo-154a corre zoneScopedOperatorsEnabled=true + zoneScopeStrictEnabled=true, con 2 membresias zonificadas (Edwin Sosa y Max, 1 zona cada uno): en la lista de conductores ven solo su zona, pero en /dashboard/wallet ven y pueden recargar a los 41 conductores y a los 137 pasajeros del tenant. Ironia: el propio doc de driver-scope-filters.ts:24-27,43-46 cita a teo-154a/Edwin-Piura como incidente ancla — la fuga se arreglo en el modulo de conductores y nunca se llevo a billetera. 3) POST /api/wallet/adjust (recarga de conductor desde el panel, invocado en wallet-client.tsx:765) solo exige requireModuleAccess('finance') (route.ts:24-25): NO valida MANAGE_WALLETS y NO consume rechargeBudget, a diferencia de su gemelo de pasajeros (src/app/api/wallet/customers/[walletId]/transactions/route.ts:116-119,155-162). Resultado: el presupuesto de recarga de Max (500) no limita nada en conductores. Ownership solo por companyId (adjust/route.ts:40-44). Queda auditado con performedById, eso si. 4) GET src/app/api/wallet/customers/[walletId]/transactions/route.ts:25-28 no tiene requireModuleAccess ni chequeo de permiso alguno: sesion + companyId. PROPUESTA: (a) aplicar resolveDriverScope / getMembershipZoneScope en todas las rutas de /api/wallet cuando zoneScopedOperatorsEnabled este activo; (b) separar la visibilidad de wallets de pasajero de la de conductor (permiso propio o filtro por rol del usuario del panel); (c) alinear /api/wallet/adjust con MANAGE_WALLETS + consumeRechargeBudget; (d) cerrar el GET de transacciones de cliente. --- _Reported via AI agent: Victor (teo-154a) - conv 413214_

    Liberado el 22/7/2026
  • 0
    BugOtro

    PUT /api/ai-agent/tariff-rules pisa campos no enviados con los defaults del schema (corrompe reglas de tarifa)

    Al hacer un PUT parcial a /api/ai-agent/tariff-rules enviando solo {startTimeMinutes, endTimeMinutes}, la regla existente quedo con los DEFAULTS del schema en todos los campos no enviados: chargeType paso de PERCENTAGE a FIXED, daysOfWeek de [0..6] a [], itemized de false a true. Un recargo del 25% se convirtio en un recargo fijo de 0.25. Repro real 21/07 en pido-taxi, regla 5574cc95-e7cb-41b1-bf2a-d2c56251448d: se corrigio reenviando el objeto completo, pero cualquier update parcial (que es justo lo que documenta el propio route: patchear un subset por id) corrompe la tarifa del tenant en silencio. El update deberia mergear contra la fila existente antes de aplicar defaults, o updateTariffRuleSchema no deberia inyectar defaults en campos ausentes.

    Liberado el 22/7/2026
  • 0
    BugOtro

    apolo-food: el repartidor toma pedidos y queda en saldo NEGATIVO pese a walletRestrictionEnabled + maxDriverDebt=0

    Reportado por William (Apolo Food, conv 412412, PRO): 'LA BILLETERA TE DEJA TOMAR ORDENES Y TE PONE SALDO NEGATIVO, NO DEBIERA DEJAR TOMAR ORDENES SI NO TIENES SALDO'. CONFIG VERIFICADA EN DB (apolo-food): walletRestrictionEnabled=true, maxDriverDebt=0, driverDebtWarnThreshold=0, minDriverWalletBalance=0, cardOnlyWhenNoBalanceEnabled=false, deliveryCashFlowMode=PREPAID_WALLET, deliveryBundlingEnabled=true, deliveryMaxOrdersPerDriver=3, currency PEN. La politica del cliente esta BIEN puesta. EVIDENCIA: 1 de 6 DriverWallet del tenant en negativo, minimo -1.88 PEN. CAUSA RAIZ 1 (semantica del guard) - src/lib/services/wallet/driver-debt-guard.ts:133-137: la regla es 'bloquear si balance <= -maxDriverDebt', o sea SOLO si el repartidor YA esta en negativo al momento de aceptar. No se exige que el saldo cubra la comision del pedido que esta por tomar. Un repartidor con +0.50 acepta legitimamente y termina en -1.88 cuando se le descuenta la comision al completar. Para el cliente eso se lee como 'la restriccion no funciona'. minDriverWalletBalance quedo muerto (el propio doc del archivo lo declara reemplazado; no tiene un solo caller). CAUSA RAIZ 2 (rutas de asignacion sin guard) - checkDriverCanTakeDelivery (src/lib/services/delivery/driver-take-guard.ts) solo se invoca desde src/app/api/dashboard/delivery/orders/[id]/route.ts:238 y :267. NO lo llaman src/app/api/dashboard/delivery/orders/[id]/preassign-driver/route.ts ni el PATCH de src/app/api/trips/[id]/route.ts. Por esas dos rutas el panel puede entregar pedidos a un repartidor sin saldo, sin el override consciente que si existe en bf2fa2238. PROPUESTA: (a) guard de suficiencia: exigir balance >= comision estimada del pedido (o un umbral configurable 'saldo minimo para tomar pedido') en vez de solo 'no estar ya en negativo'; (b) cablear checkDriverCanTakeDelivery en preassign-driver y en el PATCH de trips, con el mismo override de operador de bf2fa2238. --- _Reported via AI agent: William (Apolo Food) - conv 412412_

    Liberado el 22/7/2026
  • 0
    BugOtro

    Recargos nocturnos configurados 24/7 sin que nada avise: el pasajero paga un extra permanente y encima invisible cuando itemized=false

    Detectado en el barrido del 2026-07-21 atendiendo a D&C / Pido Taxi (conv 412163, tenant pido-taxi, appPlan PRO) y despues medido en toda la base. CASO ANCLA (verificado con la matematica de viajes reales): pido-taxi tiene una CompanyTariffRule llamada **Viaje Noctruno** de **+25% PERCENTAGE**, activa, con `startTimeMinutes=0` y `endTimeMinutes=1440` y `daysOfWeek={0,1,2,3,4,5,6}` -> **se aplica las 24 horas, los 7 dias**. Ademas `itemized=false`, asi que el pasajero **no la ve desglosada**. Comprobacion numerica: viaje TMR6W2RF4 (8.736 km / 20 min) calculaba 134.89 y se cobro **168.61 = 134.89 x 1.25**, exacto. Un viaje anterior a la creacion de la regla calzo exacto SIN el 25%. El cliente venia reclamando que le salia ~20 por km sin entender por que. ALCANCE (SQL sobre prod, reglas activas con ventana 0-1440 cuyo nombre implica horario nocturno): - `pido-taxi` — Viaje Noctruno, +25%, los 7 dias, itemized=false, **appPlan PRO** - `via-1efd` — Recargo Nocturno, +9%, daysOfWeek vacio (= todos), itemized=true - `jmndrive-viajes-` — NOCHE DE RUMBA, +500 fijo, sabados y domingos completos, itemized=false (Nota: hay otras reglas con 0-1440 que son CORRECTAS porque son por DIA — feriados, domingos, sabados. El problema es especifico de las que se llaman nocturnas y no tienen ventana horaria.) POR QUE PASA: la ventana 0-1440 es el default cuando el usuario no define horario, asi que una regla pensada para la noche termina corriendo siempre. Nada en el producto avisa de la contradiccion. QUE HACE FALTA: 1. **Advertencia en el panel** al guardar una regla con ventana 0-1440: confirmar que se aplicara SIEMPRE (y sugerir un rango si el nombre sugiere horario). 2. **Revisar/avisar a los 3 tenants** afectados; pido-taxi es PRO y esta cobrando de mas a sus pasajeros desde que creo la regla. 3. Que `itemized` sea **true por defecto** en recargos: un extra que el pasajero no ve desglosado es la receta para el reclamo. Idealmente no permitir recargos ocultos. 4. Chequeo de coherencia: si `daysOfWeek` cubre los 7 dias Y la ventana es 0-1440, la regla es de hecho un aumento de tarifa base — deberia decirlo asi en la UI.

    Liberado el 26/7/2026
  • 0
    IdeaOtro

    Reglas de tarifa: avisar cuando una regla queda 00:00-24:00 los 7 dias (aplica SIEMPRE) y cuando esta 'no desglosada'

    Caso real: tenant pido-taxi (D&C Sistemas, conv 412163). El dueno reporto que 'los precios estan mal, un viaje de 4.2 km se calculo con precio por km de $20 cuando tenemos $8'. DIAGNOSTICO VERIFICADO EN DB: la CompanyTariffRule 5574cc95-e7cb-41b1-bf2a-d2c56251448d, llamada 'Viaje Noctruno', esta isActive=true, chargeType=PERCENTAGE, amount=0.25 (+25%), daysOfWeek={0,1,2,3,4,5,6} y startTimeMinutes=0 / endTimeMinutes=1440. O sea: una regla NOCTURNA configurada de medianoche a medianoche los 7 dias -> se aplica a TODOS los viajes, todo el dia. Ademas itemized=false, asi que el pasajero no la ve como concepto aparte: entra silenciosa al total. Evidencia en pricingSnapshot de viajes reales del tenant: TMR6W2RF4 (8.736 km / 20 min) = 25 base + 69.89 km + 40 min = 134.89, +25% = 168.61 cobrado (exacto). TMQ9MZZQM del 11/06 (antes de que existiera la regla) calzo exacto SIN el 25%. PEDIDO DE PRODUCTO: 1) en el formulario de reglas de tarifa, avisar visiblemente cuando la ventana queda 00:00-24:00 y los 7 dias ('esta regla se aplicara a TODOS los viajes'); 2) sugerir un rango por defecto cuando el nombre sugiere nocturno/festivo; 3) hacer mas evidente el efecto de itemized=false (recargo invisible para el pasajero); 4) idealmente un simulador 'cuanto costaria un viaje de X km / Y min' en el panel de tarifas para que el dueno vea el desglose antes de publicar cambios. --- _Reported via AI agent: AI agent - Chatwoot conv 412163 (D&C Sistemas / Pido Taxi)_

    Liberado el 27/7/2026
  • 0
    BugOtro

    Iconos de los servicios se quedan en el coche gris (fallback) en la web del pasajero - _ServiceIconBox usa CachedImage sin retryOnError

    Tenant demo-rayo-taxi-62553b01 (Tx Guaymas, Jose Baro, conv 421936). Los 4 ServiceType activos (Tx Guaymas, San Carlos, Empalme, Santa Clara) tienen icon = https://pub-02daf8ad890c433980e0375bb04c0bd6.r2.dev/branding/126b4a3d-ccb9-4ec7-8545-94bd646e2b9c/2026-07-21/ed52c152-84e1-4b5e-bf87-505bfe2a0493.webp VERIFICADO POR HTTP: la URL responde 200, Content-Type image/webp, 31842 bytes, Access-Control-Allow-Origin: *, Cache-Control public immutable. El dato esta bien. EVIDENCIA DEL CLIENTE: captura fresca (una sola pestana abierta, y los nombres YA salen renombrados a Tx Guaymas / San Carlos / Empalme / Santa Clara -> no es cache vieja) y aun asi los 4 renglones de 'Elige tu viaje' muestran el glifo de coche gris por defecto. Reabrio varias veces, sigue igual. El workaround de cache que se le habia dado NO resuelve. CAUSA RAIZ PROBABLE: apps/cabgo/lib/features/rider/ride/screens/ride_options_screen.dart:4464 - _ServiceIconBox renderiza con CachedImage(url: iconUrl, errorWidget: Icon(fallbackIcon)) SIN pasar retryOnError, cuyo default es false. Es exactamente el modo de fallo ya documentado en packages/cabgo_ui/lib/src/widgets/cached_image.dart (doc del campo retryOnError): en Flutter web CachedNetworkImage salta al errorWidget ante cualquier hipo del primer fetch y NUNCA reintenta, dejando el placeholder latcheado toda la sesion aunque el servidor devuelva 200 y CORS *. El mismo comentario nombra el THROTTLING de los subdominios pub-*.r2.dev como la ventana larga que motivo la cola de reintentos de 10s y 30s (casos cmrpcivy0, cmr9slvu0, cmru9c1ji). Ese fix se aplico SOLO a las superficies de LOGO (AppLogo / heroes de auth), no a los iconos de servicio. Con 4 iconos pidiendo el MISMO objeto de r2.dev al mismo tiempo, el throttling es muy plausible. ARREGLO PROPUESTO: pasar retryOnError: true en _ServiceIconBox y revisar las demas superficies que pintan icon de ServiceType (mapa, historial, pantalla de confirmacion). Evaluar tambien servir los iconos por dominio propio en vez de pub-*.r2.dev. --- _Reported via AI agent: AI agent - Chatwoot conv 421936 (Jose Baro / Tx Guaymas)_

    Liberado el 22/7/2026
  • 0
    BugOtro

    PATCH company-config devuelve success:true y NO escribe nada si los campos van anidados (zod sin .strict() los descarta en silencio)

    Es un footgun que produce el peor error de confianza que tenemos: decirle a un cliente que su cambio ya quedo aplicado cuando no se aplico. VERIFICADO EN CODIGO: `PATCH_SCHEMA` en `src/app/api/ai-agent/company-config/route.ts:64` es un `z.object({...})` que cierra en la linea 914 **sin `.strict()`**. El comportamiento por defecto de Zod es **descartar claves desconocidas en silencio**. Entonces un body como: { "companySlug": "super", "settings": { "maxDriverDebt": 50 } } parsea correctamente (companySlug es valido, `settings` se descarta), `settingsUpdate` queda VACIO, no se escribe nada, y el endpoint responde **success:true**. El llamador no tiene forma de darse cuenta. El shape correcto es con los campos **planos** en el body: { "companySlug": "super", "maxDriverDebt": 50 } INCIDENTE REAL (2026-07-21): el cliente `super` (FULL) autorizo subir su tope de deuda de conductor de 5 a 50. Se llamo el PATCH con el body anidado, respondio success, se le confirmo al cliente y se anoto como aplicado — pero en DB seguia en 5. Se detecto recien en un barrido posterior y se re-aplico con body plano. Estuvimos a un paso de dejar a sus conductores bloqueados de madrugada creyendo que estaba resuelto. QUE HACE FALTA: 1. `.strict()` en `PATCH_SCHEMA` para que un body con claves desconocidas devuelva **400 con el detalle**, en vez de un exito silencioso. 2. Que la respuesta incluya **que campos se escribieron efectivamente** (p. ej. `updatedFields: [...]`), asi el llamador puede verificar sin ir a la DB. 3. Si `settingsUpdate` queda vacio y el body traia algo mas que `companySlug`, responder 400 ("ningun campo reconocido") en lugar de 200. Aplica al mismo patron en otros endpoints ai-agent que usen z.object sin strict.

    Liberado el 22/7/2026
  • 0
    BugOtro

    URGENTE dinero: el cupon LEGACY-TAXIAMIGO-300B quedo ACTIVO y SIN restriccion de empresa - USD 300 de descuento usable por cualquiera

    EXPOSICION FINANCIERA VIVA. Detectado en el barrido del 2026-07-21 auditando los cupones legacy creados hoy. QUE PASO: se crearon DOS cupones para el mismo cliente (Polax / TaxiamiGO, conv 396940) con 14 segundos de diferencia: - `LEGACY-TAXIAMIGO-300` (18:25:10) — isActive=true, restrictedCompanyId = 495dfac7-aba9-4219-a8f8-201403767e3d (demo-rayo-taxi-330881c1). **Correcto.** - `LEGACY-TAXIAMIGO-300B` (18:25:24) — isActive=true, **restrictedCompanyId = NULL**. **Este es el problema.** RIESGO: es un cupon AMOUNT de **USD 300** sobre App Plan, activo y **sin restriccion de empresa**. Cualquiera que conozca o adivine el codigo puede aplicarlo a su propio checkout y pagar 99 en lugar de 399. timesRedeemed = 0 por ahora, asi que todavia no hubo dano. QUE HACE FALTA (no lo puedo ejecutar desde soporte): 1. **Desactivar `LEGACY-TAXIAMIGO-300B`** (isActive=false) o restringirlo al mismo companyId que el original. Es lo urgente. 2. `POST /api/ai-agent/plan-coupons` **no valida** que un cupon AMOUNT nazca con restriccion: deberia exigir `restrictedCompanyId` (o `maxRedemptions=1` + restriccion) para cupones de credito legacy, que por definicion son para UN cliente. 3. El endpoint solo expone **GET y POST** — no hay PATCH ni DELETE, asi que desde soporte no se puede corregir un cupon mal creado. Agregar PATCH (al menos para isActive y restrictedCompanyId). 4. Revisar si hay otros cupones AMOUNT historicos sin restriccion: `SELECT code, "amountOffCents"/100, "isActive", "timesRedeemed" FROM "PlanCoupon" WHERE "restrictedCompanyId" IS NULL AND "amountOffCents" > 0 AND "isActive";` Contexto: hoy se crearon 10 cupones legacy por USD 2.800 en total (todos segun el playbook de reactivacion, 0 redimidos). Este es el unico que quedo sin restriccion.

    Liberado el 21/7/2026
  • 0
    BugOtro

    Simulador: el enlace del dashboard va sin demoAuth=1 y cae en el wizard de registro dentro del iframe (parece congelado)

    Reporte de Armando / GetRide 588 (conv 390610): "esta congelado, no sube ni baja, no deja seguir para ver el demo". Video revisado frame a frame. VERIFICADO: - La URL que abrio es https://www.cabgo.app/simulator/taxi?company=getride588 (sin demoAuth). - src/app/(dashboard)/dashboard/page.tsx:417 genera el link como `/simulator/taxi?company=${company.slug}` SIN demoAuth=1. - src/app/simulator/taxi/page.tsx:50-64 solo pre-autentica los iframes (ensureDemoRider/ensureDemoDriver) cuando demoAuth==="1". Sin ese flag el panel del pasajero arranca en el wizard de registro ("Step 1 of 4 - Personal Information") DENTRO de un iframe de ~300px de alto: el formulario no cabe, el scroll de la rueda no se propaga al iframe y el usuario lo lee como pantalla congelada. Mismo comportamiento en /simulator/delivery (page.tsx:50). - Bonus del mismo video: el wizard sale en INGLES ("Step 1 of 4", "Personal Information", "Continue", "Schedule for later", "Notes for the driver") aunque el tenant es es-MX. PROPUESTA: que el link del dashboard (y cualquier link de simulador que mandemos) incluya demoAuth=1 por defecto, o que el simulador lo aplique solo cuando el tenant es demo. SEGUNDO HALLAZGO (mismo cliente): tiene DOS Company con el mismo nombre "GetRide 588" -> slug getride588 (creada 2026-03-06, email getridegr@gmail.com, SIN ningun User asociado, servicios default Sedan/SUV/Premium/Moto/Entrega) y slug demo-rayo-taxi-8e1c4fc9 (creada 2026-07-20, es donde vive su usuario getridegr@gmail.com como COMPANY_ADMIN y donde esta toda su configuracion real). El tenant huerfano getride588 sigue siendo alcanzable por URL y es el que abrio en el simulador, por eso vio servicios y precios que no son los suyos.

    Liberado el 22/7/2026
  • 0
    IdeaOtro

    Panel: iniciar mensaje/aviso directo a UN conductor desde el dashboard (hoy solo se puede responder o segmentar)

    Pedido de CarVip (conv 416183): el operador necesita avisarle a un conductor concreto que le falta subir un documento, pero el conductor nunca abrio un ticket. VERIFICADO EN CODIGO: - SupportTicket/DriverSupportTicket solo se CREAN desde endpoints mobile (src/app/api/mobile/support/route.ts:123; mobile/support/message/route.ts:250,302; mobile/business/support/route.ts:114; mobile/rider/trips/[id]/report/route.ts:94). No hay ruta ni boton en el dashboard que cree un ticket -> el admin solo puede RESPONDER hilos que abrio el conductor (/dashboard/conversations?tab=support). - Push manual (/dashboard/notifications -> POST /api/push-campaigns) solo acepta audiencias de segmento: ALL_DRIVERS, DRIVERS_BY_ZONE, DRIVERS_BY_SERVICE. El zod del server (src/app/api/push-campaigns/route.ts:12-19) y targetFilter no tienen driverId/driverIds. - El unico texto libre a un solo conductor hoy es el motivo de RECHAZO (src/app/api/drivers/[id]/route.ts:364-378), pero ese flujo ademas pone accountStatus=BANNED/isActive=false -> inusable como canal de aviso. - El rechazo de DOCUMENTO (src/app/api/documents/[id]/review/route.ts) guarda rejectionReason y el conductor lo ve pasivo en la app, pero NO dispara push. - Ya existe el primitivo por-conductor: modelo DriverPopupMessage (schema:5674) acepta driverId, pero su unico productor es la recompensa de lealtad (src/lib/services/driver/driver-popup.ts:37). No hay UI admin. PROPUESTA (2 piezas chicas, reusando lo que ya existe): 1) Boton "Enviar mensaje" en la fila del conductor (/dashboard/drivers) que cree un SupportTicket del lado admin (o un DriverPopupMessage con driverId) + push al fcmToken. 2) Que el rechazo de documento dispare push con el rejectionReason (hoy es silencioso).

    Liberado el 27/7/2026
  • 0
    BugOtro

    POST /api/ai-agent/services no llama ensureZoneServiceConfigs: el servicio creado queda invisible para el pasajero

    Al recrear el servicio Sedan de teo-154a via POST /api/ai-agent/services el ServiceType quedo isActive=true pero sin ninguna fila ZoneServiceConfig, y /api/mobile/rider/services solo lista servicios con fila en la zona del pasajero: 84 zonas activas quedaron sin el servicio (hubo que enlazarlas a mano con 84 POST a /ai-agent/zone-service-config). El helper ensureZoneServiceConfigs (src/lib/services/zones/ensure-zone-service-configs.ts) hoy solo se invoca desde /api/settings/service-types (dashboard). Fix: llamarlo tambien al final del POST/PUT de /api/ai-agent/services. Mismo sintoma del barrido de prod 2026-07-21 (21 servicios invisibles en 10 tenants pagados).

    Liberado el 22/7/2026
  • 0
    BugOtro

    Cancelacion: el conductor en trabajo tipo VIAJE ve motivos de pasajero ("El pasajero no aparece") y cancela directo, sin pasar por la aprobacion del administrador que SI existe en pedidos de delivery

    Cliente: William / Apolo Food (apolo-food, PRO), conv 412412. Captura del 21-jul 17:26: hoja "Cancelar viaje" con motivos El pasajero no aparece / Direccion incorrecta / El pasajero me pidio cancelar / Problema con el vehiculo / Emergencia personal / Otro. Su reclamo textual: "Estas opciones no son opciones de delivery hermano y que si quieren cancelar el administrador tiene que aprobar". QUE HAY HOY (verificado): - FLUJO DELIVERY (FoodOrder) = CORRECTO. src/lib/services/delivery/cancellation-policy.ts decideCancellation() -> DIRECT | REQUEST | FORBIDDEN. En apolo-food (GET company-config): deliveryAdminOnlyCancelInProcess=true, deliveryCourierDirectCancel=false, deliveryBusinessCancelInProcess=false, deliveryClientCancelAfterAccept=false, deliveryCancellationRequiresReason=true. La app del repartidor ya muestra "Solicitar cancelacion" + motivo libre (apps/cabgo/lib/features/driver/delivery/screens/delivery_order_detail_screen.dart:240-330) y el estado queda en CANCEL_REQUESTED. - FLUJO VIAJE (Trip) = SIN aprobacion y con copy de pasajero. Las claves cancelReasonPassengerNoShow / cancelReasonPassengerAsked (apps/cabgo/lib/l10n/app_es.arb:4536-4557) SOLO se usan en apps/cabgo/lib/features/driver/rides/screens/active_ride_screen.dart. Ahi no hay politica de aprobacion: el conductor cancela directo. Los trabajos EXPRESS/courier que viajan como Trip caen en esta pantalla -> el cliente ve motivos de taxi en una operacion de delivery y sin aprobacion del admin. HUECOS ADICIONALES DEL LADO ADMIN (aunque el motor exista): 1) El panel NO tiene botones aprobar/rechazar cancelacion: las acciones approveCancellation / rejectCancellation existen solo en API (src/app/api/dashboard/delivery/orders/[id]/route.ts:250-257 y 993-1090) y no aparecen en ningun .tsx. 2) CANCEL_REQUESTED no esta en el filtro de pedidos del panel (src/app/(dashboard)/dashboard/delivery/orders/orders-client.tsx:83-95) ni en orderStatusColor -> una solicitud pendiente se ve como badge gris sin alerta. 3) Al admin NUNCA se le notifica una solicitud de cancelacion: la ruta del cliente notifica solo al comercio (mobile/rider/delivery/orders/[id]/cancel/route.ts:157-175) y la del comercio no notifica a nadie pese al comentario. Esta es la causa raiz de pedidos atascados en CANCEL_REQUESTED. PEDIDO: (a) que el trabajo de delivery/express asignado a un conductor use la hoja de cancelacion de DELIVERY (motivos de delivery + Solicitar cancelacion) y respete cancellation-policy; (b) botones aprobar/rechazar + filtro CANCEL_REQUESTED + notificacion al admin en el panel.

    Liberado el 21/7/2026
  • 0
    IdeaOtro

    Comercio: sonido INSISTENTE (loop) al llegar pedido de plataforma con la app CERRADA — no existe el equivalente de driverOfferInsistentSoundAndroid

    Cliente: William / Apolo Food (apolo-food, PRO). Reporta que en la app del COMERCIO el aviso de nuevo pedido de plataforma suena UNA sola vez cuando la app esta cerrada, y solo suena continuo si la app esta abierta. Pide que suene igual (insistente) este abierta o cerrada. DIAGNOSTICO VERIFICADO EN CODIGO: - Foreground: apps/cabgo/lib/features/business/orders/services/order_alert_coordinator.dart + screens/order_alert_screen.dart:37-49 -> soundService.play(SoundType.newBusinessOrder, loop: true). Por eso con app abierta SI suena en bucle (lo toca la app, no el SO). - Background/cerrada: apps/cabgo/lib/main.dart:62-108, rama NEW_ORDER -> AndroidNotificationDetails(channel business_orders_v2, sound new_order_alert) SIN additionalFlags -> sin FLAG_INSISTENT -> Android reproduce el tono UNA vez. La rama de OFERTA al conductor (main.dart:147-180) SI aplica additionalFlags [4] cuando llega data.insistentSound==true. - Backend: src/lib/services/notification/notification-service.ts sendNewOrderToBusiness() (~L982-1240) arma el payload NEW_ORDER y NUNCA llama withInsistentSoundTag() (src/lib/services/notification/insistent-sound.ts). Ademas usa sendToDevice/APNs directo, no sendPushToAllDevices (donde se inyecta el tag, src/lib/firebase-admin.ts:317-329). - No existe ningun flag businessOrderInsistentSound* en prisma/schema.prisma. El unico es CompanySettings.driverOfferInsistentSoundAndroid (schema L967-973). PROPUESTA (clon casi exacto del trabajo del conductor): 1) CompanySettings.businessOrderInsistentSoundAndroid Boolean @default(false) (per-tenant, Android-only; iOS/APNs no puede loopear). 2) Taggear el payload en sendNewOrderToBusiness con insistentSound=true via withInsistentSoundTag. 3) additionalFlags: Int32List.fromList([4]) en la rama NEW_ORDER de main.dart:76-97. 4) Exponerlo en /api/ai-agent/company-config y en el panel. Nota: crear el canal business_orders_v2 nativamente en MainActivity.kt (hoy solo lo crea flutter_local_notifications).

    Liberado el 22/7/2026
  • 0
    BugOtro

    apolo-food: los push de PEDIDO DE DELIVERY (Nueva orden / Nuevo pedido de entrega) salen con icono generico, no con el logo del tenant — los push de VIAJE si lo traen

    Cliente PRO (conv 412412, William/Apolo Food, tenant apolo-food). Evidencia: dos capturas del 2026-07-21 del mismo telefono. - Captura 1 (11:50, app del COMERCIO): notificaciones 'Nueva orden - Pedido #FD-5WAGZGLL' con icono circular gris/silueta generica en vez del logo Apolo Food. - Captura 2 (11:53, app del REPARTIDOR): en la MISMA sombra conviven DOS iconos distintos bajo el mismo nombre Apolo Food: * 'Nueva solicitud de viaje' y 'Apolo Food Repartidor' (foreground service) -> icono verde correcto del tenant. * 'Nuevo pedido de entrega - Pedido DL-PLVSTE' -> icono monocromo/generico. DIAGNOSTICO: el canal/payload de los push de DELIVERY (nueva orden al comercio y nuevo pedido al repartidor) no setea el mismo small/large icon con branding por tenant que si usan los push de viaje. El cliente lo percibe como 'llegan 2 logos diferentes'. PEDIDO: unificar el icono de notificacion (small+large) de todos los canales de delivery con el branding del tenant, igual que en los push de viaje.

    Liberado el 21/7/2026
  • 0
    BugOtro

    Los HSM de reactivacion legacy caen en conversaciones NUEVAS duplicadas en vez del hilo existente del mismo telefono

    Detectado 2 veces en el barrido del 2026-07-21 (y probablemente venia pasando sin que nadie lo notara): CASO 1 — Benjamin/Velox: el HSM de reactivacion se envio y aterrizo en la conv **423211**, pero el cliente respondio *Ok* en su hilo historico **388229**. Desde 388229 ese Ok parecia un ack sin sentido (nuestro ultimo OUT ahi era viejisimo). CASO 2 — Luis/Taxi Si (+52 961 232 2261): el HSM cayo en la conv **423210** y 20 minutos despues el cliente escribio *??* en su hilo historico **389134**. Mismo telefono, mismo lead WOTI 11769. Desde 389134 el ?? era incomprensible. POR QUE IMPORTA: 1. **El agente de soporte pierde el contexto**: ve una respuesta corta (Ok, ??) en un hilo cuyo ultimo OUT es de hace semanas, y no tiene forma de saber que responde a un HSM enviado hace 20 minutos en OTRA conversacion. Sin cruzar por telefono es imposible entenderlo. 2. **Riesgo de doble contacto**: el mismo lead puede recibir mensajes de dos hilos distintos como si fueran conversaciones independientes. 3. **Las metricas de reactivacion se ensucian**: la respuesta del lead queda registrada en una conversacion distinta de la del envio, asi que el nudge figura como no-contestado. QUE HACE FALTA: 1. Que el envio de reactivacion **reuse la conversacion existente** del contacto (buscar por telefono normalizado antes de crear) en vez de abrir una nueva. 2. Si Chatwoot abre conversacion nueva por diseno (p. ej. porque la anterior estaba resolved), entonces **dejar una nota privada cruzada** en ambos hilos con el id del otro, para que el agente del siguiente tick no quede ciego. 3. Idealmente, deduplicar/mergear los hilos historicos del mismo telefono. Detectado desde soporte; los dos casos ya se atendieron a mano cruzando por telefono.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Alcance de operadores: 'operadores por creador' oculta TODO conductor auto-registrado (creador NULL) + los contadores de pendientes y la cola de solicitudes de cambio NO respetan el alcance

    Reporte Victor (conv 413214, 2026-07-21): 'Operador por creador me esta causando problemas: si lo activo el operador ve todos los pendientes en general (y solo debe ver los pendientes de su zona) y los asignados; si los desactivo desaparecen los pendientes y tambien los que le asigne.' DATOS DEL TENANT teo-154a (verificado en DB 2026-07-21): 41 conductores, 21 pendientes, y 0 (CERO) con createdByMembershipId no nulo — todos se auto-registraron por la app. Flags: zoneScopedOperatorsEnabled=true, zoneScopeStrictEnabled=true, creatorScopedOperatorsEnabled=true (lo dejamos en false tras el diagnostico). 18 de los 21 pendientes no tienen ninguna zona asignada. TRES DEFECTOS CONFIRMADOS EN CODIGO: 1) CREADOR = NULL EQUIVALE A INVISIBLE. src/lib/services/zone-scope/driver-scope-filters.ts:153-155 empuja {createdByMembershipId: membershipId} — igualdad, nunca cierta para NULL. El unico lugar que escribe esa columna es POST /api/drivers (src/app/api/drivers/route.ts:348-355). Registro movil (src/app/api/mobile/auth/register/route.ts), registro por WhatsApp (src/lib/whatsapp/driver-registration.ts:737) e import masivo (src/lib/import-export/commit.ts) NO la escriben. Resultado: con el flag ON, un tenant cuyos conductores se auto-registran deja a TODOS sus operadores con lista vacia y no pueden aprobar a nadie. El eje zona ya tiene su antidoto (assignDriverZonesAtRegistration, driver-zone-assignment.ts:177-245); el eje creador no tiene equivalente. Propuesta: al activar el flag, backfillear/derivar creador (p.ej. por operador de la zona elegida en el registro) o degradar a OR con zona en vez de AND. 2) LOS CONTADORES MIENTEN. Badge del sidebar (src/app/api/dashboard/sidebar-counts/route.ts:61-75), campanita (src/lib/notifications/bell-counts.ts:50-52,109-118) y los contadores de pestana de la lista (src/app/api/drivers/route.ts:208-216) cuentan por companyId sin aplicar zona ni creador — mientras la LISTA si los aplica. El operador ve 'Pendientes 21' y una lista vacia o mas corta. Esto es literalmente lo que el cliente describe como 've todos los pendientes en general'. 3) COLAS DE PENDIENTES SIN ALCANCE (incluye WRITES). Filtran solo por companyId: solicitudes de cambio de conductor GET+POST aprobar/rechazar (src/app/api/drivers/change-requests/route.ts:25-27,38,57,61-66,124-133), aprobaciones de servicio (src/app/api/drivers/service-enrollments/route.ts:34-37,74-76 y src/app/api/drivers/[id]/service-enrollment/[enrollmentId]/route.ts:31-33), documentos pendientes (src/app/api/documents/pending/route.ts:19-25), verificacion facial y de pasajero (src/app/api/verification/face/pending/route.ts:10-15, src/app/api/verification/passenger/pending/route.ts:14-16), solicitudes de cambio de cliente (src/app/api/customers/[id]/change-requests/route.ts:20-23) y las rutas v1 (src/app/api/v1/drivers/pending, v1/customers/pending, v1/drivers/bulk-activate). El POST de aprobar/rechazar solo valida companyId: un operador con alcance puede aprobar cambios de un conductor fuera de su zona y fuera de su creador — misma clase de hueco que ya se cerro para /api/drivers/[id]. PEDIDO DE PRODUCTO DEL MISMO CLIENTE (separable): en la primera pantalla de registro del conductor, en vez de 'elegir zona' que el conductor elija OPERADOR (operador ya enlazado a su zona), y que sea opcional. Eso ademas resolveria el defecto 1 de raiz, porque el registro quedaria atado a un operador. Relacionado: cmrusyf4f (UX/copy de los toggles del bloque 'Operadores por zona'). --- _Reported via AI agent: AI agent — Chatwoot conv 413214 (Victor, teo-154a, PRO)_

    Liberado el 26/7/2026
  • 0
    BugOtro

    seven/ARGENT: 20 builds Android exitosas (1.0.41 a 1.0.61) nunca se subieron a Google Play — ultimo StoreRelease es 1.0.40 del 07-jul

    Cliente FULL (conv 418800) reporta que la app que descarga siempre es 1.0.40 (#41). EVIDENCIA VERIFICADA (2026-07-21): - AppBuild: builds diarias SUCCESS hasta 1.0.61 (#62) del 2026-07-21 06:01. - StoreRelease: el ultimo registro es 1.0.40 (#41), track alpha, PUBLISHED 2026-07-07 23:47. NO existe ningun StoreRelease posterior (ni FAILED ni PENDING): el paso upload+release dejo de dispararse desde el 07-jul. - GET /api/ai-agent/store/google-play-status?companySlug=seven -> bundles en Play = [25,29,30,33,41]; tracks: production releases=[], beta=[], internal=[], alpha=[1.0.40 completed]; hasProductionRelease=false; defaultTrack=production. DOS PROBLEMAS: 1) El pipeline compila pero no publica: ninguna build posterior a #41 llego a Play. Hay que disparar upload+release de 1.0.61 y averiguar por que se corto el auto-release tras el 07-jul. 2) La app nunca estuvo en produccion: production esta vacio, solo alpha (closed testing). El cliente FULL espera Play produccion y despues App Store. Ademas NO existe ninguna build iOS para este tenant (AppBuild platform=ios: 0 filas), la fase iOS no ha arrancado. IMPACTO: cliente FULL bloqueado ~2 semanas; se le entregaron ~9 fixes que nunca le llegaron al telefono. --- _Reported via AI agent: AI agent — Chatwoot conv 418800 (Temistocles, plan FULL)_

    Liberado el 24/7/2026
  • 0
    BugOtro

    Express del ADMIN: el buscador de direcciones no ofrece las ZONAS del tenant (paridad con el flujo del comercio) — Apolo Food

    Apolo Food (calandria-taxis, conv 412412) reporta DESPUES de cmrusz5nh: el buscador de direcciones del modal 'Crear pedido express' del panel sigue SIN mostrar las zonas. Verificado en codigo: el modal usa <AddressPicker> (src/components/shared/address-picker.tsx), que solo consulta /api/maps/autocomplete (Google/HERE Places). No existe el equivalente al zone-name search que SI tiene el flujo del comercio en mobile: apps/cabgo/lib/features/business/courier/screens/request_courier_screen.dart + GET /api/mobile/business/zones-search, gated por CompanySettings.requestCourierIncludeZones (ya lo active para este tenant via ai-agent/company-config). cmrusz5nh agrego la tarifa automatica con zonas/interzona en el express del admin, pero NO la sugerencia de zonas dentro del buscador de direcciones — que es exactamente lo que el cliente pide. Pedido: portar el zone-name search al AddressPicker del express del admin (mismo toggle requestCourierIncludeZones), snapeando al centroide o al midpoint del bbox del poligono, igual que hace zones-search. Nota de datos (no bug): el tenant tiene 33 zonas activas con poligono, pero 0 filas en ZoneRoutePrice, asi que la interzona no aplicara al calculo hasta que configure rutas origen-destino con appliesToDelivery=true. Ademas 30 de sus 33 zonas se llaman 'poligono dibujado N', por lo que la busqueda por nombre no las encontrara hasta que las renombre.

    Liberado el 21/7/2026
  • 0
    BugOtro

    Auditoria forense: corrupcion de montos por interpolacion de shell en mensajes OUT de Chatwoot (2 convs, 5 mensajes) — falta guard server-side

    AUDITORIA FORENSE (read-only) sobre 2.669 conversaciones / 48.005 mensajes de todos los inboxes de Chatwoot (201 Apphive WA, 67, 206, 207, 8, 203, 3, 204, 205), ventana 2026-04-20 -> 2026-07-21 (90 dias). Se filtraron 14.491 mensajes OUT reales (message_type=1, no privados) con 5 pasadas de regex + revision manual de 95 candidatos. == CAUSA RAIZ == Cuando el texto de la respuesta se pasa por linea de comandos / heredoc sin comillas simples, el shell interpola el '$': '$399' -> '99' (la var $3 se expande vacia), '$699' -> '99', '$999' -> '99', '$15' -> '5', '$30' -> '0', '$70' -> '0', '$1,702.00' -> ',702.00', '$0.00' -> '/bin/sh.00' (!! $0 = nombre del shell). El artefacto '/bin/sh' es la prueba definitiva del mecanismo. == HALLAZGOS CONFIRMADOS: 5 mensajes OUT, 2 conversaciones, 2 clientes distintos, ventana 2026-06-20 -> 2026-06-21 (36 horas) == 1) conv 397476 — LOR4 / MilDestinos (Bogota, CO) — PRECIOS DE PLAN CORRUPTOS - msg 2503600 (2026-06-20 02:57 UTC): 'App Plan: STARTER 99 · PRO 99 · FULL 99' + 'BASIC 5 · PRO 0 · ENTERPRISE 0 al mes' - msg 2503810 (2026-06-20 12:26 UTC): 'STARTER 99 -> Android / PRO 99 -> Android + iOS / FULL 99 -> Android + iOS + codigo fuente' + 'BASIC 5/mes / PRO 0/mes / ENTERPRISE 0/mes' - msg 2503924 (2026-06-20 13:25 UTC): 'pagas UNA sola vez (desde 99 USD) + una mensualidad chica de servidores (desde 5/mes)' - IMPACTO REAL: la clienta habia preguntado 'Oye no entiendo que tengo que pagar?' y respondio 'Jajaja no entiendo'. Un mes despues (2026-07-08) seguia preguntando 'Necesito entender el tema de los precios'. Perdida de confianza sostenida durante 30+ dias. - ESTADO: LEAD VIVO. Sigue respondiendo (ultimo IN 2026-07-08), labels casi-comprador + compromiso-abierto + tech-action-required. Requiere correccion explicita del precio. 2) conv 382111 — Mario Carbajal / PIDE (tenant en produccion) — SALDOS DE BILLETERA CORRUPTOS - msg 2505694 (2026-06-21 05:14 UTC): 'Recargas que le aprobaste: +,500 | Retiro que hizo: -,000 | Comisiones: -.60 | Saldo resultante: *91.40*' (reales: +$2,500 / -$1,000 / -$X.60 / $491.40) - msg 2505732 (2026-06-21 06:44 UTC): 'Juan Escutia: 91.40 | Mario Carbajal: ,702.00 | Agcel Miranda: /bin/sh.00' y '13 de ellas cierran en /bin/sh' (reales: $491.40 / $6,702.00 / $0.00 / $0) - IMPACTO REAL: el cliente respondio 'Aun no se corrige los saldos... siguen los mismos numeros de error' — la corrupcion le hizo creer que su contabilidad seguia descuadrada. Se corrigio solo por accidente 9 horas despues (msg 2506086 con 6,702 / 491 / 0 correctos). - ESTADO: CLIENTE VIVO Y ACTIVO (hilo con actividad diaria hasta hoy). Impacto ya absorbido, no requiere correccion retroactiva, pero es el caso mas grave: se le dieron cifras contables falsas. == DESCARTADOS COMO FALSOS POSITIVOS (revisados uno a uno) == - $99 USD/ano de la cuenta Apple Developer (legitimo, ~20 convs). - $99 = STARTER $399 menos credito legacy de $300 (convs 421936, 390610, 390056, 400877, 385277, 387983, 394875, 396845, 387198, 422292, 404662): precio correcto post-descuento. - Cuotas de US$99.75 (4 pagos de $399) — convs 380343, 421903. - $0 legitimo: creditos que cubren el plan (395889, 394524, 404662, 382111 STARTER gratuito), saldos de billetera en cero, '0% de comision', APIs/mapas incluidos US$0, TRIAL $0. - $5 legitimo: 5 centavos por viaje extra, $5/km de tarifas de delivery, presupuesto de ads $5-8/dia. - conv 422154 'marca — *99*': el cliente literalmente escribio 'Marca 99' (marca brasilena). No es corrupcion. - conv 421391: $99.540 COP (conversion legitima de $30 USD). == RECOMENDACION TECNICA (lo que este ticket pide) == El guard actual vive solo en scripts/chatwoot-send.mjs (client-side). No cubre (a) mensajes ya enviados, (b) cualquier otra via de envio, (c) montos que no sean de plan (saldos de billetera, tarifas, liquidaciones) — que es justo donde ocurrio el caso 382111. Se pide: 1. GUARD SERVER-SIDE en el endpoint de salida a Chatwoot/WhatsApp (no solo en el script): rechazar/alertar cualquier OUT cuyo content matchee (a) precios de plan no canonicos (STARTER/PRO/FULL != 399/699/999 salvo descuento declarado; BASIC/PRO/ENTERPRISE != 15/30/70), (b) artefactos de shell: '/bin/sh', '/usr/bin', numero que empieza con ',' o '.' precedido de espacio o signo, (c) '$' seguido de nada. 2. Prohibir por construccion la interpolacion: todo texto de respuesta debe viajar por archivo (--file) o stdin con quoting fuerte, nunca como argumento inline ni heredoc sin comillas. 3. Monitor retroactivo: job que escanee OUTs recientes y levante alerta si aparece el patron (esta auditoria hecha a mano). 4. Correccion comercial pendiente: reafirmar los precios canonicos a conv 397476. CONTEO AGREGADO: 5 mensajes OUT corruptos · 2 conversaciones · 2 clientes distintos · inbox 201 (Apphive WA) en ambos casos · ventana 2026-06-20 a 2026-06-21 · 1 lead vivo que requiere correccion de precio (397476) · 1 cliente vivo ya auto-corregido (382111) · 0 conversaciones perdidas atribuibles.

    Liberado el 21/7/2026
  • 0
    BugOtro

    CRITICO: drift de saldo de billetera en 137 de 732 wallets (18.7%) repartido en 29 de 45 tenants con plan

    Detectado en el barrido de soporte del 2026-07-21, partiendo del reporte de un cliente (carvip, conv 416183) y despues medido en TODA la base de tenants con plan activo via GET /api/ai-agent/wallet-reconcile?slug=<slug>. ALCANCE MEDIDO (45 tenants con appPlan != NONE): - 732 wallets revisadas - 137 con drift = 18.7% - 29 de 45 tenants afectados Peores: navan-drivers 52/100 · rapi2 20/23 · idealo 8/100 · rj-taxi-shalom 7/32 · urba-express 5/30 · balam 4/18 · gercel-drive 4/18 · aka-delivery 3/14 · apolo-food 3/6 · d1una-express 3/23 · pedimos-algo 3/9 · apply-taxi 2/100 · delivery-go 2/22 · lojava 2/6 · seven 2/5. QUE ES EL DRIFT: las TRES fuentes de verdad no coinciden entre si. 1. balanceField (campo Wallet.balance) 2. legacyLedgerSum (suma de DriverWalletTransaction) <- ES LO QUE VE EL CONDUCTOR EN LA APP (/api/mobile/wallet/balance) 3. polyLedgerSum (suma de WalletTransaction, el ledger nuevo) Caso ancla reconstruido (carvip, driver Roberto Collao, rcolga89@gmail.com): balanceField=4388 · legacyLedgerSum=27706 · polyLedgerSum=10500. El retiro de 10.000 CLP era REAL y ya estaba descontado en el ledger nuevo (WalletTransaction ebf6e645, COMPLETED). Lo que quedo colgado es la fila legacy DriverWalletTransaction ae8350b4 en status pending PARA SIEMPRE: predata el fix syncMobileTransaction (src/app/api/wallet/withdrawals/route.ts) y NO se auto-sana, porque action=complete exige la solicitud en APPROVED y esta ya esta COMPLETED -> devuelve 409. POR QUE ES CRITICO: el conductor ve el ledger LEGACY. Un conductor puede estar viendo 27.706 cuando su saldo real es 4.388 (o al reves, verse en negativo y quedar bloqueado sin deberlo, porque el bloqueo por deuda usa maxDriverDebt contra el balance). Es dinero mal mostrado a usuarios finales en 29 tenants que pagan. QUE HACE FALTA (no lo puedo ejecutar desde soporte, la DB es read-only para el agente): 1. Script de reconciliacion idempotente que, por wallet, elija la fuente autoritativa y cierre las filas legacy huerfanas en pending cuya WithdrawalRequest ya esta COMPLETED (el caso 409 de arriba). 2. Que el path de sync no dependa de que la solicitud este en APPROVED: aceptar tambien COMPLETED para cerrar la fila legacy. 3. Idealmente, deprecar la lectura legacy en /api/mobile/wallet/balance y servir siempre el ledger autoritativo, para que la app no muestre nunca la fuente desincronizada. 4. Alerta/monitor: correr wallet-reconcile por tenant periodicamente y avisar cuando driftCount > 0. Relacionado: FeedbackPost cmruvfjn4000r04ihdun7slwp (el reporte individual de carvip que destapo esto).

    Liberado el 22/7/2026
  • 0
    BugOtro

    delivery-go (Geotaxi): Play produccion sigue en 1.0.75 (pre-relink Firebase) — publicar 1.0.78 que ya trae geotaxi-533a3

    Edwin (conv 401633) no puede entrar con Google en NINGUNA version instalada. Verificado hoy 2026-07-21: - Company.firebaseProjectId = geotaxi-533a3 (correcto). - firebase-sha GET: ambas huellas SHA-1 (c5ccffef... instalaciones directas y f0d21e3d... firma de tienda) YA registradas en geotaxi-533a3 + SHA-256. action=already-present. - FirebaseOAuthRegistration muestra re-registro en cabgo-pool-10 el 21/07 12:57 (el re-pool ya corregido). - AppBuild android: 1.0.77 #100000094 (cron daily 06:02) salio con cabgo-pool-10 — es la que el cliente probo y grabo en video (selector de cuenta -> splash -> rebote al login). 1.0.78 #100000095 (ai-agent support-repool-fix, 13:04-13:15) SI es correcta: descargue el APK de R2 y en resources.arsc aparece geotaxi-533a3 y senderId 377399150315, sin rastro de cabgo-pool-10 ni geotaxipro. - store/releases: produccion ANDROID = 1.0.75 #100000092 publicada 2026-07-20 08:07 (compilada ANTES del enlace de Firebase de las 22:11). Por eso la version de Play tampoco entra. Accion pedida: promover/publicar 1.0.78 (#100000095) a produccion en Play para com.siberianz.appusers. Mientras tanto el cliente instala 1.0.78 desde el builder. Tenant appPlan=FULL.

    Liberado el 21/7/2026
  • 0
    IdeaOtro

    Bot WhatsApp: excluir ServiceTypes del menú del bot sin ocultarlos en la app (flowConfig.excludedServiceTypeIds)

    Tenant rapi2 (Pavel, conv 384594, PRO). Pedido: retirar "Servicio Afiliado" del menú del bot de WhatsApp, dejando solo Moto Ride y Envíos Rapi2. Estado hoy: getActiveServiceTypes() en src/app/api/webhooks/whatsapp/route.ts (~L780) arma el menú con TODOS los ServiceType con isActive=true AND isHidden=false. No existe forma de excluir un servicio SOLO del bot. Por qué no se resuelve con isHidden/isActive: 'Servicio Afiliado' (id b37c06de-3e3e-499b-aca4-2dca9dd3d877, kind DELIVERY) está atado a 83 registros de BusinessAvailableServiceType (los negocios de delivery del tenant) y tiene 40 viajes (33 MANUAL + 7 DELIVERY, último 2026-07-20). Ocultarlo/desactivarlo lo sacaría también de la app del pasajero y cambiaría la resolución de servicio de los pedidos de delivery (src/lib/services/delivery/resolve-business-service-type.ts filtra por isHidden y cae a otro ServiceType o crea uno) — riesgo de alterar tarifas de 83 negocios en producción. Propuesta: soportar flowConfig.excludedServiceTypeIds (array de ids) en el resolver del menú del bot + exponerlo en PATCH /api/ai-agent/whatsapp-flow-config, para retirar un servicio del bot sin tocar su visibilidad en la app ni el delivery. Relacionado: IDEA cmruuxg55 (auto-asignar servicio según modo Viaje/Pedido) — esta exclusión es el paso intermedio que el cliente pide mientras llega esa.

    Liberado el 22/7/2026
  • 0
    BugOtro

    Correos tenant-branded siguen filtrando cabgo.app en los enlaces (supportUrl y 'Cancelar suscripcion' hardcodeados) — super/Lima iPhones FULL

    Continuacion de D18/cmrramshk (el footer ya se white-labeleo, el TEXTO ya sale con la marca del tenant). Lo que sigue roto son los ENLACES: el cliente ve la marca correcta pero al hacer clic aterriza en cabgo.app. CASO VERIFICADO — tenant 'super' (Super Ride Technologies, Lima iPhones, appPlan FULL, companyId e7779af6-3592-4c2f-9e29-72059736114e). EmailScheduledSend d8896891-b09d-439b-b105-6f7c1155982b, templateId driver.abandoned_reminder.remind, SENT 2026-07-21 02:00:34, a felipemcglow@gmail.com. data: {"appName":"super", "resumeUrl":"https://www.cabgo.app/super/driver/registro/resume?driverId=98b136d3-...", "supportUrl":"https://www.cabgo.app/support"}. TRES FUGAS: 1) supportUrl: src/app/api/cron/abandoned-driver-reminders/route.ts:309 -> `supportUrl: APP_URL + "/support"` — hardcodeado a la plataforma, ignora customDomain aunque exista. 2) Unsubscribe: src/lib/email/templates/shared/layout.tsx — en la rama TENANT_FOOTER el <Link href> sigue siendo "https://www.cabgo.app/unsubscribe" fijo. Es el unico link del footer branded y apunta a Cabgo. 3) CTA principal (resumeUrl): route.ts:243 SI respeta customDomain (`https://${company.customDomain}`), pero cae a `${APP_URL}/${company.slug}` cuando no hay dominio. En 'super' Company.customDomain esta vacio y no hay fila en DomainVerification (esta montando app.super.com.pe ahora), asi que hoy cae al fallback cabgo.app. Este punto se resuelve solo cuando termine su dominio — 1 y 2 NO. PEDIDO: que todo link de un correo tenant-branded se construya desde una unica base por-tenant (customDomain -> appDomain/canonicalSubdomain -> fallback APP_URL/slug), incluidos supportUrl y unsubscribe. Cliente FULL que esta pagando justamente por marca propia.

    Liberado el 22/7/2026
  • 0
    BugOtro

    carvip: retiro de 10.000 CLP quedo 'pending' para siempre en el ledger movil + las 3 fuentes de saldo del conductor no cuadran (Roberto Collao)

    Tenant carvip (PRO). Driver de prueba Roberto Collao rcolga89@gmail.com, driverId de6f5726-1c34-474f-ac4d-c1536b9ad82f, walletId 61dc8f63-8a86-4bbf-9964-4a2391c01db5. EVIDENCIA (solo lectura en prod): 1) WithdrawalRequest 2f761b08-c6d9-46d5-bfd4-691da9734708 — amount 10000 CLP, status COMPLETED, createdAt 2026-04-30 02:57:03.786, processedAt 2026-04-30 12:44:39.944. Retiro REAL y cerrado. 2) WalletTransaction ebf6e645-9f88-49fb-b443-8b116a521141 — WITHDRAWAL -10000, COMPLETED, 2026-04-30 12:30:08.794 ('Retiro aprobado - Solicitud 2f761b08'). El ledger admin SI se liquido. 3) DriverWalletTransaction ae8350b4-722d-4fd0-89bb-4e2866fc82d6 — WITHDRAWAL -10000, status 'pending', createdAt 2026-04-30 02:57:03.784. NUNCA paso a 'completed'. Ese es el registro 'pegado' que el cliente ve y pide borrar. CAUSA RAIZ: src/app/api/wallet/withdrawals/route.ts ya trae el helper syncMobileTransaction() que promueve la fila legacy al aprobar/completar, pero esa fila es ANTERIOR al fix y nunca hubo backfill. Hoy no se puede sanar sola: action='complete' exige status APPROVED y la solicitud ya esta COMPLETED (409), asi que la fila queda huerfana de por vida. GET /api/mobile/wallet/balance suma DriverWalletTransaction status='pending' type='WITHDRAWAL' y lo reporta como pendingBalance -> el conductor ve 10.000 pendientes eternos. DRIFT ADICIONAL (GET /api/ai-agent/wallet-reconcile?slug=carvip&driverId=...): balanceField=4388, legacyLedgerSum=27706, polyLedgerSum=10500. Drift vs legacy -23318, vs poly -6112. Las 3 fuentes discrepan: el panel muestra 4388 y la app del conductor calcula 27706. PEDIDO: A) Backfill/one-shot: liquidar las filas DriverWalletTransaction type=WITHDRAWAL status='pending' cuyo WithdrawalRequest pareado ya esta COMPLETED/APPROVED/REJECTED (no solo carvip — es un patron global de filas pre-fix). B) Reconciliar el saldo de este wallet a una fuente unica y decidir cual manda (el endpoint wallet-reconcile re-truea el campo pero NO limpia la fila pending). C) Idealmente FK real WithdrawalRequest -> DriverWalletTransaction en vez del heuristico por monto + ventana de 60s.

    Liberado el 21/7/2026
  • 0
    BugOtro

    provision-demo-company sin companyName MUTA el tenant maestro del preset (demo-rayo-taxi) en vez de crear uno nuevo

    Riesgo alto de dano en produccion. QUE PASA: al llamar POST /api/ai-agent/provision-demo-company con clientPhone + conversationId pero SIN `companyName`, el endpoint reusa el tenant MAESTRO del preset (`demo-rayo-taxi`, el que sirve de plantilla para todas las demos) y le aplica los datos del lead — en el incidente le cambio la ciudad de Guadalajara a Sao Joaquim da Barra. IMPACTO: el tenant maestro es la base de las demos de TODOS los leads nuevos. Mutarlo contamina las demos siguientes con la ciudad/marca de un lead ajeno. Se detecto por casualidad; si nadie mira, queda roto en silencio. DETECTADO: barrido del 2026-07-21, provisionando la demo de Robson (conv 423197). Se restauro la ciudad a Guadalajara manualmente (verificado) y luego se creo el tenant propio pasando `companyName`. FIX SUGERIDO: cuando venga `conversationId` o `clientPhone`, NUNCA reusar el tenant maestro del preset — o crear uno nuevo, o fallar con error explicito pidiendo `companyName`. Alternativa/complemento: marcar los tenants maestros de preset como inmutables (flag `isPresetMaster`) y rechazar cualquier PATCH/provision sobre ellos.

    Liberado el 21/7/2026
  • 0
    BugOtro

    installment-plan: conversationId numerico revienta con f?.trim is not a function

    POST /api/ai-agent/installment-plan falla con `f?.trim is not a function` cuando `conversationId` se manda como NUMERO. Hay que mandarlo como string ("422717") para que funcione. Inconsistencia: el resto de endpoints ai-agent (app-plan-checkout, provision-demo-company, feedback) aceptan conversationId numerico sin problema. Esto hace que el agente de soporte pierda intentos en cada cierre con cuotas. Detectado en el barrido del 2026-07-21 armando el plan de cuotas de Yupee (conv 422717, demo-andale-delivery-12f1e6a1, STARTER 2x$199.50). Funciono recien al castear a string. Fix sugerido: coercer con String(conversationId) antes del trim, o aceptar z.union([z.string(), z.number()]) en el schema de validacion.

    Liberado el 21/7/2026
  • 0
    BugOtro

    Delivery: las pasarelas de redireccion (PayPhone/Pagadito/Kontigo) no aparecen como metodo de pago en el checkout

    Tenant yevfood- (Ecuador, USD, deliveryEnabled=true / taxiEnabled=false) configuro PAYPHONE completo (isEnabled=true, storeId + codingPassword + webhookSecret, chargeTiming=POST_TRIP) y el metodo NO aparece ni en la app ni al pagar. Diagnostico: 1) Backend OK: /api/mobile/rider/company devuelve PAYPHONE en paymentProviders (flowType=redirect, se salva del filtro de publicKey vacio). 2) Flutter: payment_methods_screen.dart solo renderiza (a) efectivo, (b) customPaymentMethods, (c) tarjetas guardadas. Los providers de tipo redirect NUNCA se renderizan ahi; _showAddCardDialog los excluye explicitamente con .where((p) => p.supportsTokenization). El unico lugar donde se pintan es ride_options_screen.dart (_redirectProviders) = flujo TAXI. 3) checkout_screen.dart (delivery) navega a riderPaymentMethods -> un tenant delivery-only se queda sin metodo de pago online. 4) Backend tampoco tiene ruta PayPhone para pedidos: /api/payments/payphone/prepare exige tripId y trip.status=COMPLETED. No existe equivalente por DeliveryOrder. Agravante: yevfood- tiene cashEnabled=false, asi que hoy su app no ofrece NINGUN metodo de pago. Pedido: soportar pasarelas redirect en el checkout de delivery (render en payment_methods_screen + prepare/confirm por orderId). --- _Reported via AI agent: AI agent - Chatwoot conv 423202 (yevapp, Ecuador)_

    Liberado el 22/7/2026
  • 0
    BugOtro

    driver/status 500 escapaba del handler sin registrar (GET sin logging + import dinámico de log-server-error en el catch)

    Diagnóstico (AppErrorLog prod, read-only) del bucket P1 de 500 en POST/GET /api/mobile/driver/status. CAUSA A (confirmada, ya mitigada): el único stack server-side capturado (2026-07-16) fue "DriverAdapterError: deadlock detected" (SQLSTATE 40P01) en el UPDATE de la fila Driver (la más caliente: heartbeat + PATCH ONLINE compiten con las transacciones de ciclo de viaje). Lo absorbe retryOnDeadlock (commit 793dac164, desplegado 2026-07-16). Faltaba el test de regresión, ahora añadido. CAUSA B (la que dejaba el bucket ACTIVO y ciego): los 30 PATCH(ONLINE)+4 GET recientes devuelven el HTML __next_error__ de Next (no nuestro JSON) y hay CERO filas server-side en 3 días => los 500 escapaban del catch del handler y no se registraban. Dos huecos reales: (1) GET no tenía logging server-side (solo console.error); (2) el catch de PATCH hacía await import() dinámico de log-server-error, que puede rechazar en un deploy (chunk-hash rotado => MODULE_NOT_FOUND) y re-lanzar fuera del catch => 500 sin registro. REPARACIÓN (PR #323, merge f893fe74): import estático de logServerError; GET ahora captura a Sentry + persiste el stack en AppErrorLog (paridad con PATCH); log de PATCH enriquecido con companyId + requestBody. Test tests/unit/driver-status-500-repair.test.ts (5 casos) con retryOnDeadlock real. NOTA bucket 400 (15 ev): {status:OFFLINE} bloqueado por viaje TAXI activo = comportamiento correcto, no bug (documentado con test). PENDIENTE / recomendación infra (fuera del área del endpoint): el residuo de __next_error__ sin log en GET apunta a fallo a nivel de framework/module-init (init de PrismaClient en module-scope / cold-start / timeout de la función). Ahora GET sí deja stack real cuando el 500 llega al handler; si siguen apareciendo __next_error__ sin fila, la causa es cold-start/module-init y toca revisar el arranque de Prisma/Vercel.

    Liberado el 21/7/2026
  • 0
    BugOtro

    loyalty-progress devolvía 403 a sesiones de invitado (bucle en AppErrorLog)

    GET /api/mobile/rider/loyalty-progress respondía 403 "Solo accesible para pasajeros" a cualquier token cuyo tipo != rider. La home del pasajero (home_screen.dart, initState -> _loadLoyalty) llama ese endpoint al cargar en TODA sesión, incluidas las de invitado (guest = browse sin cuenta, Apple 5.1.1(v), dominante en web). Cada carga de invitado generaba un 403 que el interceptor global de la app registra en AppErrorLog. Evidencia prod (3 días): 31 filas 403, todas userType=rider, platform=web, body exacto 'Solo accesible para pasajeros', varias appVersion. Del lado del cliente el error se traga (la tarjeta de fidelidad es best-effort y nunca bloquea el mapa), pero contaminaba el log de errores (P2 del triage). Causa raíz: un invitado no tiene cuenta y por tanto no tiene progreso de fidelidad; ese es el estado vacío, no un error de auth. El endpoint lo trataba como token inválido. Fix (solo server-side, cura apps ya publicadas sin recompilar): un token guest ahora recibe 200 {campaigns: []} (la app no renderiza nada, igual que un tenant sin campaña activa). El 403 queda reservado para un tipo de token genuinamente incorrecto (p. ej. token de conductor). PR #321, merge bb375a7ca, CI verde. Tests: tests/e2e/rider-loyalty-progress-flow.test.ts + 2 casos (guest->200, driver->403). --- _Reported via AI agent: AI agent — loop técnico CabGo (triage P2)_

    Liberado el 21/7/2026
  • 0
    BugApp móvil

    GET /api/mobile/driver/earnings devuelve 500 (pantalla Mis Ganancias del conductor)

    AppErrorLog: 33 filas 500 en GET /api/mobile/driver/earnings?period=today (rango 2026-06-12 → 2026-07-19), body genérico {"error":"Error interno del servidor"}, 30 conductores distintos, pico de 20 eventos el 2026-07-16. Diagnóstico read-only (rol cabgo_agent_ro): repliqué la secuencia COMPLETA de queries del handler para los 4 conductores identificables + una muestra de 119 conductores más pesados (90 días) y para las 3 empresas con retenciones — 0 fallos. La tabla TripAdjustment tiene 352 filas (no hay costo/timeout real). Conclusión: los 500 registrados de ?period=today NO son un bug determinista de cálculo; el patrón (pico en un solo día + goteo entre muchos conductores) es consistente con fallos TRANSITORIOS de conexión/pool a la BD (Neon pooler) capturados por el catch genérico. Lo que SÍ era una clase de 500 determinista y quedó cerrada: page/limit malformados llegaban a Prisma como NaN (skip/take) y from/to malformados como Invalid Date (gte/lte) → PrismaClientValidationError → 500 (verificado contra prod). Fix: sanitizar entradas con parseEarningsPagination/parseEarningsCustomRange (clamp page≥1, limit 1..50, ignora fechas inválidas) + enriquecer el log del catch con query y nombre del error para diagnosticar futuros transitorios. Archivos: src/lib/mobile/earnings-params.ts (+ tests/unit/earnings-params.test.ts), src/app/api/mobile/driver/earnings/route.ts. PR: fix/sentry-triage-p2. Pendiente (no incluido): resiliencia a transitorios (retry sobre P1001/P1017/timeout) si el goteo persiste. --- _Reported via AI agent: AI agent — loop técnico CabGo (triage AppErrorLog P2)_

    Liberado el 21/7/2026
  • 0
    BugApp móvil

    Crash en Ajustes → Apariencia (rider web): ProviderNotFound del ThemeCubit al abrir el bottom sheet

    Sentry CABGO-F9 (release cabgo-web@1.10.818, Flutter web). 5 eventos / 5 usuarios en ~40 min, nivel fatal, transaction /rider/profile. Stack: _SettingsScreenState.build → showModalBottomSheet (_BottomSheetState.build) → context.read<ThemeCubit>() (provider.dart) → ProviderNotFoundException. Causa raíz: en settings_screen.dart el `value: context.read<ThemeCubit>()` estaba DENTRO del `builder:` del modal, es decir una lectura diferida que corre cuando la ruta modal se construye; en ese momento el provider quedaba fuera de alcance para el contexto capturado y tronaba antes de re-proveerlo con BlocProvider.value. Fix: capturar el ThemeCubit de forma síncrona en onTap (settings montado, provider presente) y pasar la instancia al BlocProvider.value del sheet. Archivo: apps/cabgo/lib/features/rider/profile/screens/settings_screen.dart. PR: fix/sentry-triage-p2. --- _Reported via AI agent: AI agent — loop técnico CabGo (triage Sentry P2)_

    Liberado el 21/7/2026
  • 0
    IdeaOtro

    [TAREA JOSE — D18] Envio de correos desde el dominio propio del tenant (Mailgun/DNS)

    Decision D18 (Jonatan 2026-07-20). Cuando un tenant conecta su dominio propio, los correos transaccionales a SUS usuarios (conductores, clientes) deberian salir desde ese dominio (ej. no-reply@dominio-del-tenant) en vez de cabgo.app. Tarea de Jose: flujo de verificacion del dominio de envio (Mailgun subdomain/DNS SPF+DKIM por tenant), seleccion de remitente por tenant en el pipeline de envio (process-email-queue), y fallback al remitente de plataforma cuando el dominio no este verificado. Coordinar con la tarea de Isa (supportEmail). Referencia: cmrramshk (super/Lima, FULL) + PR #273. --- _Reported via AI agent: Loop tecnico cabgo — batch D18 de Jonatan_

    Liberado el 27/7/2026
  • 0
    BugOtro

    demo-company: builds iOS nocturnas fallan con ASC 401 NOT_AUTHORIZED (credenciales invalidas) — ruido recurrente del cron

    El tenant demo-company entra en la ola nocturna de cron:daily-builds con iOS y falla SIEMPRE en el signing manual: Apple responde 401 NOT_AUTHORIZED (bearer token de App Store Connect invalido/expirado; son credenciales propias del tenant, las compartidas funcionan — taptap y otros iOS pasan). Anoche ademas dejo una build colgada 99min (huerfana 1.0.82, cosechada) y el retry 1.0.83 fallo con el 401. Cada noche quema slot del worker Mac. Opciones: 1) quitar iOS del daily-build para demo-company 2) renovar/corregir sus credenciales ASC (.p8/issuer) 3) borrar la config iOS del tenant demo. Decidir y aplicar. Pelota: jonatan

    Liberado el 19/7/2026
  • 0
    IdeaOtro

    teo-154a: conectar la ficha de Google Play (publicada por el cliente) al storeUrl para que /d/<negocio> muestre Descargar para Android

    Seguimiento de cmr5ct5op parte (1), conv 413214 (Victor). El link de negocio /d/<slug>?company=teo-154a ya renderiza la pagina smart (verificado: https://cabgo.app/d/todo?company=teo-154a muestra Abrir en la app + Continuar en navegador). PERO la seccion de Descargar para Android/iOS no aparece para teo-154a porque loadTenantStoreUrls lee AppBuild.storeUrl y teo NO tiene ningun AppBuild con storeUrl (el cliente publico la Play el mismo desde SU consola el 2026-07-09; la ficha existe pero nuestro sistema no la registro). PEDIDO: registrar la URL de la ficha Play de teo en el AppBuild correspondiente (o mecanismo equivalente) para que los links de negocio muestren el boton de descarga. iOS quedara igual cuando Apple apruebe la 1.0.61. No hay endpoint ai-agent para escribir storeUrl, por eso va como post.

    Liberado el 15/7/2026
  • 0
    BugOtro

    Panel de Balance del negocio (business-portal) ignora currencyDecimalPlaces y siempre muestra 2 decimales

    El tenant aka-delivery ya tiene CompanySettings.currency=CLP y currencyDecimalPlaces=0 (correcto, CLP no usa centavos). Sin embargo, el panel de Balance del negocio (business-portal) muestra todos los montos con 2 decimales: Saldo disponible $12991.11, Retiros pendientes $0.00, Ganancias esta semana $12991.11, y el Resumen de totales (Ganancias/Comisiones/Retiros/Ajustes/Reembolsos) y Movimientos recientes. Causa: src/app/(business-portal)/business/balance/page.tsx, función fmt() línea ~97-98 hace `${sym}${Math.abs(amount).toFixed(2)}` hardcodeando 2 decimales en TODOS los usos (líneas ~219, 230, 242, 264, 272, 280, 288, 296, 404, 428), sin leer currencyDecimalPlaces de la empresa. Esperado: fmt() debe formatear según currencyDecimalPlaces (y currencyRoundingMultiple) de la empresa, igual que ya lo respetan otras vistas (dashboard, receipts, mobile). Para CLP el resultado debe ser $12.991 sin decimales. Aplica a cualquier moneda de 0 decimales (CLP, COP, PYG, JPY, etc.). Reportado por el cliente con captura del panel de Balance de Pizza Party. --- _Reported via AI agent: Chatwoot #402735 — Alejandro (Aka Delivery, Chile, CLP)_

    Liberado el 10/7/2026
  • 0
    BugOtro

    Viajes creados desde Dashboard/despachador NO llegan a conductores WhatsApp-only (rama WHATSAPP sin implementar)

    Reportado por Mr Sepulveda (vip-taxi-services, conv Chatwoot 384353, 2026-07-08). Continuacion de cmr292l2r (fix del heartbeat que mantiene ONLINE a conductores WhatsApp-only — RELEASED y confirmado por el cliente como funcionando). SINTOMA: El cliente quiere operar como DESPACHADOR creando viajes desde el Dashboard/computadora (ej. el pasajero llama a la compania y el reserva el viaje). La oferta SOLO llega a conductores que tienen la app instalada (notificationChannel=APP); los conductores WhatsApp-only (notificationChannel=WHATSAPP) NO reciben nada por su numero de WhatsApp. Textual: "lo reservo desde la computadora, no le salen a los choferes si no tienen la aplicacion". CAUSA RAIZ (codigo): 1) src/app/api/mobile/rider/trips/request/route.ts, funcion sendNotificationsToDrivers, ~linea 2676: la rama `else if (notification.channel === "WHATSAPP" && driver.phone)` es un TODO — `// TODO: Implement WhatsApp notification via WhatsApp Business API` → setea success=false. Nunca envia la oferta. 2) src/lib/services/trip/driver-finder.ts (usado por searchAndNotifyDrivers, que llaman /api/trips y otros dispatchers): solo notifica `if (driver.notificationChannel === "APP")`; no hay rama WHATSAPP. CONTRASTE (ya existe la pieza reutilizable): el flujo originado POR WhatsApp (pasajero escribe al numero) SI envia la oferta a conductores WhatsApp-only. Ver src/app/api/webhooks/whatsapp/route.ts ~linea 4106-4170: arma `🚗 *NUEVO VIAJE*` con sendButtonsMessage y botones accept_trip_/reject_trip_. Esa logica (buscar la Conversation DRIVERS del tenant por driver.phone + sendButtonsMessage) se puede portar a los paths de dispatch de app/dashboard. PETICION: que los viajes creados desde el Dashboard/despachador (y desde la app del rider) tambien hagan fan-out por WhatsApp a los conductores WhatsApp-only, no solo a los de app. Impacto: el cliente opera con flota WhatsApp-only y hoy no puede despachar manualmente hacia ellos. Prioridad: alta (cliente con desarrollo a medida, hilo custom-dev-followup, ~6 dias). --- _Reported via AI agent: Mr Sepulveda (conv 384353, vip-taxi-services) via /sweep_

    Liberado el 8/7/2026
  • 0
    BugPlataforma

    driper: Google Sign-In web sigue en redirect_uri_mismatch (incognito) en driper.org y app.driper.org — falta config OAuth client web

    Tenant driper (SotecXP, M, conv Chatwoot #418203). Cliente NO puede iniciar sesion con Google en su app web branded. Sintoma: Error 400 redirect_uri_mismatch (pantalla Google Acceso bloqueado: la solicitud de esta app no es valida) al tocar Continuar con Google. Ocurre en driper.org Y en app.driper.org, y persiste en INCOGNITO y modo normal (descartado cache/PWA). Diagnostico: el proxy same-origin /__/auth/* (fix 68030c47f) YA esta activo en ambos dominios (GET https://driper.org/__/auth/handler y https://app.driper.org/__/auth/handler devuelven 200). appDomain=app.driper.org (verified/active, cloudflare active). Aun asi Google devuelve redirect_uri_mismatch => el redirect_uri que se envia (probablemente https://<host>/__/auth/handler) NO esta en las Authorized redirect URIs del OAuth client WEB compartido del proyecto cabgo2-app. Accion (per playbook seven/ARGENT, rama Google Cloud console): en el OAuth 2.0 Web client de cabgo2-app agregar a Authorized redirect URIs: https://driper.org/__/auth/handler y https://app.driper.org/__/auth/handler; y a Authorized JavaScript origins: https://driper.org y https://app.driper.org. Verificar tambien que ambos dominios esten en Firebase Auth authorizedDomains de cabgo2-app. No hay endpoint ai-agent que edite los redirect URIs del client web (gcp-oauth-list es mobile-by-package) => accion manual/infra. El cliente prefiere driper.org como dominio unico (compromiso-abierto de apex vigente). Cliente bloqueado para que sus usuarios entren a la app web. --- _Reported via AI agent: AI agent — Chatwoot conv 418203 (M, driper/SotecXP)_

    Liberado el 8/7/2026
  • 0
    IdeaOtro

    Geopush de proximidad: notificar al pasajero cuando esta a <1km de un negocio, profesional o conductor registrado

    Tenant driper (SotecXP, M, conv Chatwoot #418203). Peticion del cliente: habilitar una notificacion push basada en geolocalizacion (geofence/geopush) para que el usuario/pasajero, en su modo, reciba un aviso cuando esta a MENOS DE 1 KM de un negocio, profesional o conductor registrado, invitandolo a usar Driper e indicando la proximidad (ej. "Tienes un profesional/negocio a X m de ti"). Alcance sugerido: - Geofencing del lado del cliente (app) o evaluacion por backend con la ubicacion del usuario vs entidades registradas (Business / Professional / Driver con lat/lng). - Radio del disparador configurable (cliente pidio ~1 km). - Copy de la notificacion invitando a usar Driper + distancia/proximidad. - Considerar: control de frecuencia/anti-spam (no notificar repetidamente por la misma entidad), permisos de ubicacion en background (iOS/Android), y opt-in del usuario. - Relacionado con el pedido de radio de visibilidad de profesionales (FeedbackPost reservas-profesionales-filtrar-listado-del-pasajero-por-radi). Estado: idea/feature request, sin fecha comprometida. Requiere evaluacion de producto (background location + reglas anti-spam). --- _Reported via AI agent: AI agent — Chatwoot conv 418203 (M, driper/SotecXP)_

    Liberado el 18/7/2026
  • 0
    IdeaOtro

    Reservas/Profesionales: filtrar listado del pasajero por radio de distancia (configurable) + mostrar distancia auto-detectada

    Tenant driper (SotecXP, M, conv Chatwoot #418203). Situacion actual: en el listado de profesionales del pasajero (GET /api/mobile/rider/professionals) se calcula distanceKm y se ORDENA por cercania cuando llegan lat/lng, pero NO se FILTRA por distancia. Devuelve TODOS los profesionales ACTIVE/isVisible de la empresa sin importar la distancia. Resultado: al iniciar sesion en la app web, a un usuario le aparece un profesional registrado en Venezuela aunque este en otro pais. Peticiones del cliente: 1) Que solo se vean profesionales dentro de un radio maximo del usuario (pidio ~30 km por defecto). 2) Que ese radio sea CONFIGURABLE/editable desde la interfaz (dashboard) del negocio. 3) Que se muestre la distancia a la que esta cada profesional y que se detecte automaticamente la ubicacion del usuario (la API ya devuelve distanceKm si el cliente envia lat/lng; falta asegurar auto-deteccion de ubicacion + render de la distancia en la UI web/app, y que los profesionales tengan lat/lng seteado). Notas tecnicas: - Existe serviceRadiusKm POR profesional (FeedbackPost RELEASED radio-de-cobertura-autoservicio-por-profesional), pero NO se aplica en el listado del pasajero para ocultar profesionales fuera de rango. Considerar: (a) un radio MAX a nivel empresa (nuevo campo en CompanySettings, editable en professionals-config), y/o (b) respetar serviceRadiusKm por-profesional para no mostrar pros donde el usuario cae fuera de su cobertura. - Endpoint a tocar: src/app/api/mobile/rider/professionals/route.ts (agregar filtro por distancia). Config: src/app/api/ai-agent/professionals-config (agregar campo radio) + UI dashboard. --- _Reported via AI agent: AI agent — Chatwoot conv 418203 (M, driper/SotecXP)_

    Liberado el 8/7/2026
  • 0
    BugOtro

    Revisar pasarela MercadoPago de nodo (tenant PRO) — rechazos cc_rejected_high_risk con clientes reales

    Agustin (nodo / app.nodos.link, tenant PRO, MX) tiene clientes reales pagando desde la web y reporta rechazos de tarjeta "El pago fue rechazado por seguridad" (cc_rejected_high_risk de MercadoPago). Config verificada via payment-diagnostics: MERCADOPAGO isEnabled=true, isTestMode=false, credenciales APP_USR- (produccion), sin whitespace; STRIPE tambien enabled (pk_live/sk_live); cashEnabled=false (correcto, solo tarjeta). No hay fallas en el transaction log (el rechazo high_risk es server-side de MP, antes de persistir). ACCION: confirmar que el access token APP_USR- conectado pertenece a la cuenta de MercadoPago PROPIA de Agustin y esta VERIFICADA/aprobada por MP (cuenta nueva/no verificada dispara high_risk). Tambien evaluar si conviene dejar solo MP (no Stripe) para MX. Agustin ademas estuvo auto-probando (el mismo comercio pagandose a si mismo), lo que dispara el filtro anti-fraude. Coordinar revision de la conexion MP con el.

    Liberado el 8/7/2026
  • 0
    BugOtro

    carvip (Chile): compilar y PUBLICAR build Android nuevo a PRODUCCION (dueno subio a mano y ve avisos; solo 1.0.29 en alpha)

    Tenant carvip (Chile CLP), conv 416183 (labels tech-action-required + compromiso-abierto). SITUACION: El dueno ("n") intento subir un AAB A MANO a Play Console y reporta "errores". La captura que envio NO es error de firma ni de build: es la pagina Enlaces profundos (Deep Links / App Links) de Play sobre la version 30 (1.0.29) mostrando avisos NO bloqueantes: "1 dominio sin verificar" y "2 enlaces no funcionan" (assetlinks.json / Digital Asset Links). Son advisories, no bloquean produccion. ESTADO BUILDS (store/releases carvip): unico build SUCCESS/PUBLISHED = 1.0.29 (versionCode 30, track ALPHA, 2026-05-15). Todos los FAILED son ANTIGUOS (may 8-15) por setup ya resuelto: "must be enrolled in Play Signing" y "Version code 29 has already been used". El pipeline funciona; no hay fallos recientes. NO existe todavia un build nuevo con los 3 arreglos pendientes. PENDIENTE / ACCION: 1) Cerrar auditoria de pagos (feedback cmr5sfsae000104l204e438ze: cobro en cancelacion + 3620 vs 3314 + doble 5% billetera conductor). 2) Compilar UN build Android nuevo del conductor que incluya: fix recarga billetera CVV/MercadoPago (ya corregido) + resultado de la auditoria de pagos. 3) PUBLICAR ese build a PRODUCTION por el pipeline (el dueno pidio explicitamente produccion). NO promover 1.0.29 (viejo, sin fixes) a produccion prematuramente. NOTA para soporte: recordar al dueno que NO suba builds a mano (la plataforma firma con la keystore correcta del proyecto y gestiona Play Signing + versionCode; el upload manual es justo lo que historicamente fallaba). --- _Reported via AI agent: AI agent — CabGo WhatsApp (conv 416183)_

    Liberado el 7/7/2026
  • 0
    BugOtro

    Zyvo: texto en amarillo se pierde — forzar color de letra oscuro sobre fondo/marca amarilla

    Miller (Zyvo, marca amarilla) reporta que la letra en varios lugares sale en amarillo sobre fondo claro y NO se lee. Pide que el color del texto sea negro/oscuro. ACCION: revisar contraste del texto en la app cuando el primaryColor/branding del tenant es amarillo — el texto no debe heredar el color de marca cuando eso rompe legibilidad; forzar onSurface oscuro. Relacionado con branding por-tenant. Verificar tema/typography del tenant demo-rayo-taxi-9830f411. --- _Reported via AI agent: sweep conv 401960 (Miller/Zyvo)_

    Liberado el 3/7/2026
  • 0
    BugOtro

    Dashboard: al cambiar de motorizado en un pedido, la lista no hace scroll/no se puede buscar

    Ichiro (rapidin) reporta que desde el dashboard, al intentar CAMBIAR DE MOTORIZADO en un pedido, la lista de motorizados no se puede desplazar (no baja) ni buscar para seleccionar otro. Queda inutilizable si hay varios motorizados. ACCION: el selector de reasignacion de motorizado/conductor en el dashboard debe ser scrollable + tener buscador por nombre/telefono. Verificar el componente del modal de reasignacion en la vista de pedidos/orders del dashboard. --- _Reported via AI agent: sweep conv 396354 (Ichiro Higuchi)_

    Liberado el 3/7/2026
  • 0
    BugOtro

    ARGENT (seven): cargar registros MX + SPF (y DKIM) de Zoho en Cloudflare para argent.com.ar

    Continuacion del setup de correo Zoho para argent.com.ar (dominio delegado a nuestro Cloudflare). El TXT de verificacion ya se cargo y el dominio quedo Verificado en Zoho. Ahora Zoho lo marca Pendiente de apuntar registros MX y pide MX + SPF + DKIM. Accion infra: cargar en Cloudflare de argent.com.ar los registros de correo de Zoho (data center global zoho.com): MX -> mx.zoho.com (prio 10), mx2.zoho.com (prio 20), mx3.zoho.com (prio 50); SPF TXT @ -> v=spf1 include:zoho.com ~all. El DKIM es un valor unico por dominio que Zoho aun no mostro expandido en las capturas del cliente (columna Valor decia No se propago el registro); se le pidio a Zayin/Temistocles (conv 420592) que expanda la fila DKIM y mande la captura con Host+Valor para cargarlo tambien. Confirmar MX/SPF y avisar para pulsar Verificar en Zoho.

    Liberado el 2/7/2026
  • 0
    BugOtro

    pidelo-x-app colectivos: desfase de 1 hora en la notificacion de reserva al conductor (bug de zona horaria)

    Un usuario reservo un viaje/salida de colectivo para las 7:00 AM pero la notificacion le llego al conductor a las 6:00 AM (1 hora antes). Sugiere bug de zona horaria (offset incorrecto, posible UTC vs hora local MX UTC-6) en el calculo/envio de la notificacion de reserva de colectivo. Revisar el timezone con que se agenda/dispara la notificacion al conductor. Cliente pidelo-x-app (Mexico). --- _Reported via AI agent: AI agent - CabGo support (Chatwoot conv 418128, Dar Ideas)_

    Liberado el 2/7/2026
  • 0
    IdeaOtro

    Servicios Profesionales: recordatorio de cita al CLIENTE como notificacion push DENTRO de la app (no solo correo/WhatsApp)

    Solicitado por Gerardo Guzman (demo-expertos-ya, MX, vertical Estetica/Salon, Chatwoot #419872). Pide que al cliente le llegue el recordatorio de su cita como notificacion push DENTRO de la app, igual que al conductor le llega la oportunidad de viaje — no solamente por correo o WhatsApp. Contexto: ya tiene una app equivalente en Apphive (AZISTA) y planea migrar a CabGo; este recordatorio in-app es una funcion que valora para impulsar la vertical de servicios profesionales.

    Liberado el 30/6/2026
  • 0
    BugDelivery

    App de comercio: encargos (cotización) no muestran el texto del cliente ni el botón de cotizar

    El flujo de Encargos (customRequestText / quoteStatus / quotedAmount) está completo en Flutter y en el endpoint POST /api/mobile/business/orders/[id]/quote, PERO la API de negocio que alimenta la app NUNCA devuelve esos campos: - src/app/api/mobile/business/orders/route.ts (lista) → el .map() de orders NO incluye customRequestText, quoteStatus ni quotedAmount. - src/app/api/mobile/business/orders/[id]/route.ts (detalle) → el return NextResponse.json({ order: {...} }) tampoco los incluye. La app Flutter espera esos campos: apps/cabgo/lib/features/business/core/models/order_model.dart (fromJson lee customRequestText/quoteStatus/quotedAmount; getters isCustomRequest, awaitingQuote = quoteStatus=='PENDING_QUOTE'). El formulario _QuoteInputForm en order_detail_screen.dart (línea ~871) solo se renderiza si order.isPending && order.awaitingQuote, y el texto del cliente sale de order.customRequestText (~línea 1591). Como la API manda null, el comercio NO ve la solicitud escrita por el cliente NI el botón/campo para enviar la cotización. Reproducido en prod: orden FD-WRTLYA6A de aka-delivery, quoteStatus=PENDING_QUOTE, customRequestText='me puedes comprar 4 cervezas' — existe en DB pero invisible en la app de comercio. FIX: agregar customRequestText, quoteStatus, quotedAmount, quotedAt (y un orderType/isCustom si aplica) tanto al .map() de la lista como al objeto de detalle en ambas rutas mobile business. SECUNDARIO (currency): la orden de encargo tomó currency MXN porque Business.currency estaba vacío; el código en src/app/api/mobile/rider/delivery/custom-orders/route.ts hace currency: business.currency || 'MXN'. Mitigado a mano (seteé CLP a los 43 Business de aka-delivery + la orden pendiente), pero el fallback debería caer a CompanySettings.currency antes que al hardcode 'MXN'. --- _Reported via AI agent: AI agent — Chatwoot conv 402735 (Alejandro / aka-delivery)_

    Liberado el 22/6/2026
  • 0
    IdeaDelivery

    CHAT ENTRE ADMINISTRADOR Y NEGOCIOS

    ¿Estaría bien agregar un chat dentro de la app entre administrador (yo) y los negocios, para que puedan escribirme directamente desde ahí cuando necesiten soporte, ayuda o resolver dudas?

    Liberado el 12/6/2026
  • 0
    IdeaOtro

    Modo OFERTA: banda de negociación anclada al monto ofertado por el cliente (100%-500%)

    Ichiro (rapidin-peru-) pide que en modo OFERTA la banda de negociación del conductor vaya del 100% del MONTO OFERTADO por el cliente (piso) hasta el 500% (techo), en vez de la lógica actual que ancla a la tarifa recomendada del sistema (recommendedFare x offerMinFarePercent 0.7 / offerMaxFarePercent 1.5). Hoy: trip TMPPVKC76 ofertado 2.00, recomendado 1.50 -> banda 1.05-2.25. El quiere: piso = lo ofertado (2.00) y techo 5x. Implica: (a) cambiar el ancla de recommendedFare a estimatedFare/offeredFare en ride_options_screen.dart + dispatch (offerMinFare/offerMaxFare), (b) percents configurables por tenant (0.7/1.5 -> hasta 1.0/5.0). Cambio de comportamiento compartido + per-tenant config + rebuild. Caso: 396354. --- _Reported via AI agent: AI agent — Ichiro WhatsApp 396354_

    Liberado el 11/6/2026
  • 0
    BugOtro

    Tarjeta de oferta del conductor no muestra el número de pasajeros

    En modo OFERTA, el backend SÍ envía passengerCount en el payload de dispatch (src/app/api/mobile/rider/trips/request/route.ts L2036), pero el modelo de la tarjeta de oferta del conductor (apps/cabgo/lib/features/driver/core/models/ride_request_model.dart) NO tiene el campo passengerCount, así que la oferta nunca lo muestra. trip_detail_screen.dart SÍ lo muestra, pero esa pantalla es post-aceptación. Fix: agregar passengerCount a ride_request_model.dart (parse desde json + firestore) y mostrarlo en la tarjeta de oferta. Requiere rebuild de la app. Caso: rapidin-peru-/Ichiro 396354. --- _Reported via AI agent: AI agent — Ichiro WhatsApp 396354_

    Liberado el 29/5/2026
  • 0
    IdeaPagos

    Subir imagen de QR para recarga por depósito manual

    En la recarga por depósito/transferencia manual, hoy las instrucciones solo soportan texto + datos de cuenta (titular, número, referencia). Falta poder subir una imagen de QR (Yape/Plin) para que el cliente la escanee. Caso: Ichiro (rapidin-peru-) quiere activar la recarga manual pero por privacidad NO quiere exponer su número/nombre; prefiere mostrar solo el QR como imagen. Propuesta: agregar un campo de imagen de QR en la config de depósitos (CompanySettings/depositInstructions) y renderizarlo en la pantalla de recarga de la app. --- _Reported via AI agent: AI agent — Ichiro (rapidin-peru-)_

    Liberado el 26/5/2026
  • 0
    IdeaPlataforma

    AI-agent endpoint: consultar solicitudes de revendedor (status, datos, aprobar)

    Cuando un cliente como dale (navan-drivers, conv 415663 2026-05-23) aplica al programa revendedor vía https://www.cabgo.app/es/resellers#aplicar, hoy el agente no tiene forma de consultar si la solicitud llegó / en qué status está / ver los datos enviados. Se le da el link y se pierde la trazabilidad hasta que el usuario admin lo aprueba manualmente. Propuesta: 2-3 endpoints AI-agent bajo /api/ai-agent/reseller/: 1. GET /api/ai-agent/reseller/applications?status=PENDING|APPROVED|REJECTED&limit=20 — lista solicitudes con id, nombre, email, fecha, status, comentario admin. 2. GET /api/ai-agent/reseller/applications/[id] — detalle de una solicitud específica (datos del form completo). 3. Opcional (NO en v1): POST /api/ai-agent/reseller/applications/[id]/approve — aprobar desde el agente. Requeriría authorización explícita del usuario admin antes de cada call (no auto-approve). Use case: cliente pregunta si su solicitud llegó → agente consulta GET applications?status=PENDING&email=X → confirma. Cliente pregunta cuándo se aprueba → agente ve status. Sin esto, el cliente se queda en el limbo y el agente solo puede repetir el link. Doctrine: ya existe POST /api/ai-agent/reseller/{create-company,payment-link} pero solo para POST-aprobación, no para consulta de aplicaciones pendientes. --- _Reported via AI agent: AI agent — internal, after dale conv 415663 2026-05-23_

    Liberado el 24/5/2026
  • 0
    IdeaDelivery

    Delivery cash payment: campo "¿Con cuánto vas a pagar?" con opciones Exacto / Custom

    En la pantalla de pago efectivo de delivery, agregar campo Con cuanto vas a pagar pero con 2 opciones para el cliente: (1) Exacto (no necesita cambio) y (2) Campo numérico para indicar el monto que va a entregar. Solicitado por Victor (teo-154a) conv 413214 2026-05-23. Quote: en delivery cuando elijes el pago con efectivo, allí si es importante una pregunta con cuanto vas a pagar. Opciones: Exacto / Campo para digitar la cantidad. Contexto: en taxi no aplica (vivienda y ride más informal), pero en delivery el repartidor lleva billete y debe preparar cambio. UX paralela al campo cashChangeFor de taxi pero con opción explícita Exacto. Propuesta: nuevo widget en delivery cart/checkout con 2 radio (Exacto, Otro monto), y si elige Otro Monto surge el campo numérico. Mismo CompanySettings.cashChangeFieldEnabled puede gatear el feature o usar un toggle aparte deliveryCashChangeFieldEnabled. --- _Reported via AI agent: AI agent — Victor (teo-154a) conv 413214_

    Liberado el 24/5/2026
  • 0
    IdeaApp móvil

    Rider home: opciones de pago/comentario ocupan demasiado espacio + naming inconsistente

    Victor (teo-154a) reporta 2 puntos UX en la pantalla de pedir viaje del rider (conv 413214 2026-05-23): 1. Las opciones (método de pago + nota al conductor) ocupan la MITAD inferior de la pantalla. Cliente propone que ocupen solo 1/4 de pantalla con 2 botones de cambio: pago y comentario. 2. El campo Con cuánto vas a pagar es ilógico — el monto ya se puede indicar en el comentario. Propone eliminarlo. 3. Naming: actualmente se llama nota al conductor — cliente propone comentario (más corto, más universal). Quote: El propósito es pedir un viaje, esa opciones ocupan la mitad de la pantalla, debe ocupar 1/4 de pantalla con 2 botones de cambio pago y comentario. Si se dan cuenta es ilógico el campo de con cuánto vas a pagar Porque en el comentario puedes poner ese detalle. Nota: el campo Con cuánto vas a pagar fue específicamente solicitado por otros tenants (William/calandria-taxis 22-may) para flujos donde el conductor necesita preparar cambio. Sugerencia: hacer el campo opcional / configurable por tenant via CompanySettings.showCashChangeField (default true para back-compat). Si se desactiva, la nota al conductor incluye el detalle del monto. Renombre nota al conductor a comentario es safe (cambio de copy). --- _Reported via AI agent: AI agent — Victor (teo-154a) conv 413214_

    Liberado el 29/5/2026
  • 0
    IdeaPlataforma

    Driver: bloqueo automático por saldo bajo en wallet

    Cliente propone modelo de pago de comisiones via wallet recarga previa (no descuento por viaje). Conductor recarga wallet → admin define umbral mínimo → si saldo < umbral, conductor NO recibe ofertas de viaje. Solicitado por ted-go conv 401863 2026-05-23. Quote (audio): habilitar o deshabilitar el uso de la aplicación para los conductores según el saldo. La lógica es habilitar la aplicación para el conductor según el saldo, sin descontar de lo que cobra por el servicio. Diseño: 1) CompanySettings.driverMinWalletBalance (decimal, opt-in). 2) Driver visibility filter: cuando balance < driverMinWalletBalance, hide del dispatcher pool. 3) Push notification: alerta al conductor cuando se queda sin saldo. 4) Opt-in por tenant (CompanySettings.useWalletGatedDispatch bool). 5) UI driver app: ver saldo + botón recargar. --- _Reported via AI agent: AI agent — ted-go conv 401863_

    Liberado el 24/5/2026
  • 0
    IdeaPlataforma

    Sistema de comisión por referido conductor-pasajero (cuantificable)

    Cliente propone: cuando un conductor invita a un pasajero, el pasajero queda vinculado a ese conductor (link de invitación). Sistema debe permitir asignar una COMISIÓN al conductor por cada viaje del referido + reporte cuantificable (cuánto generó cada referido para el conductor). Solicitado por dale (navan-drivers) conv 415663 2026-05-23. Quote: el sistema de que el conductor invita pasajero dice que el pasajero queda vinculado con ese conductor, PODEMOS ASIGNAR UNA COMISION A CADA CONDUCTOR POR REFERIDO Y QUE SE PUEDA CUANTIFICAR. Sería un éxito. Propuesta de diseño: 1) ya existe el sistema DriverPassengerInvite que vincula. 2) agregar tabla DriverReferralRevenue (driverId, customerId, trip, commission). 3) hook en trip-complete que detecta si Trip.customer está vinculado a un driver vía DriverPassengerInvite y crea registro. 4) tablero reporte por driver: total referidos + revenue acumulado. 5) opcional: porcentaje configurable por tenant. --- _Reported via AI agent: AI agent — dale (navan-drivers) conv 415663_

    Liberado el 8/6/2026
  • 0
    BugApp móvil

    Rider: estado del viaje no se refresca, hay que cerrar y reabrir la app

    Cuando el cliente sale del tracking screen y luego intenta volver, el home screen no refleja que hay un viaje en curso. Tiene que cerrar la app entera y reabrirla para que aparezca el estado de Buscando conductor. Reporte: Victor (teo-154a) conv 413214 2026-05-23. Quote: Tienes que cerrar la app y volver abrir para que veas el curso del pedido en buscando conductor. Propuesta: en home screen.initState() llamar a tripService.getActiveTrip() para detectar trip en curso y redirigir a tracking. O bien suscribir a un stream global de trip-status que se mantenga vivo entre screens. --- _Reported via AI agent: AI agent — Victor (teo-154a) conv 413214_

    Liberado el 23/5/2026
  • 0
    BugApp móvil

    Taxi: cliente puede pedir otro viaje aun teniendo uno en curso

    En el flow de taxi, cuando un cliente tiene un viaje pendiente (searching for driver), si presiona atras puede regresar al home y solicitar OTRO viaje. Aplicaciones de taxi conocidas bloquean al cliente en la pantalla de Buscando conductor hasta que finalice o cancele. Para delivery está bien permitir multiples pedidos. Para taxi NO. Reporte: Victor (teo-154a) conv 413214 2026-05-23. Quote: Cuando uno pide un taxi en cualquier app conocida, siempre se queda en línea, aquí pides y puedes ir hacia atrás y volver a pedir y te dicen que tienes una solicitud de viaje en curso, eso está mal. Para delivery si está bien porque el cliente puede hacer varios pedidos pero para taxi el pasajero se debe quedar en el curso del pedido hasta que finalice o cancele. Propuesta: en home screen del rider, si hay un Trip activo (status SEARCHING/PENDING/ASSIGNED/DRIVER_ARRIVED/IN_PROGRESS) y source != DELIVERY, redirect al tracking screen automáticamente en lugar de mostrar el botón Pedir viaje. Para delivery dejar como está. --- _Reported via AI agent: AI agent — Victor (teo-154a) conv 413214_

    Liberado el 23/5/2026
  • 0
    BugApp móvil

    Rider tracking: botón chat visible antes de tener conductor asignado

    En la pantalla de seguimiento del viaje del cliente, el componente DriverCard se renderiza incluso cuando RidePhase=searching (no hay conductor asignado todavía). Mostraba el texto generico Conductor y los botones onCall/onMessage activos, llevando a una pantalla de chat sin contraparte. Reporte: Victor (teo-154a) conv 413214 2026-05-23. Quote: hay un botón de chat y al presionar te mando a una pantalla de chat, es ilógico si aún no tiene conductor asignado o conductor que aceptó la oferta. Fix: wrap DriverCard with if (_currentPhase != RidePhase.searching). Commit 37154ace 2026-05-23. --- _Reported via AI agent: AI agent — Victor (teo-154a) conv 413214_

    Liberado el 23/5/2026
  • 0
    BugApp móvil

    Driver: pickup code del pasajero no se genera (regression post db7449b1)

    Bryan (dtour) reporta que tuvo que desactivar el codigo del pasajero en el panel web porque la app del conductor no genera el codigo para iniciar viaje. Reporte: dtour conv 387181 2026-05-23 03:23. Quote: Tambien lo desactive en el panel web el codigo del pasajero. Porque no genera el codigo para iniciar viaje. Contexto: el 22-may commit db7449b1 desplego fix de PIN missing. Algo no quedo completo. Verificar: Trip.pickupCode se genera al asignar conductor? Confirmar dispatch.ts genera + persiste pickupCode al pasar a ASSIGNED. requiresPickupVerification surge en payload trip al cliente Y conductor? UI del conductor lee requiresPickupVerification y muestra prompt PIN al cambiar estado a STARTED? Si CompanySettings.requirePickupCode estaba off, verificar que dispatcher NO genere el codigo. App Bryan: DTour v1.0.207. --- _Reported via AI agent: AI agent — Bryan (dtour) conv 387181_

    Liberado el 23/5/2026
  • 0
    BugApp móvil

    Driver ofertas: precio subido por pasajero no se refleja en app del conductor

    Cuando el pasajero sube manualmente el precio en la pantalla de oferta (ej. Estimado S/7 ofertado por pasajero), la app del conductor sigue mostrando la Tarifa recomendada (S/6) en lugar del precio ofertado. Slider del conductor muestra Min S/4.20 Max S/9 con valor S/6. Reporte: Bryan (dtour) conv 387181 2026-05-23 03:03. Capturas: pasajero Esperando ofertas Estimado S/7 + conductor Tarifa recomendada S/6. Contexto: el 22-may se desplego commit db7449b1 que arreglo modal regression + PIN missing. Este bug especifico no estaba en ese fix. Verificar: cuando trip.source=RIDE_OFFER y cliente envia precio custom, el dispatcher debe propagar trip.estimatedFare al payload de oferta al conductor (no devolver pricingSnapshot.recommendedFare). App: DTour v1.0.207 #100000229. --- _Reported via AI agent: AI agent — Bryan (dtour) conv 387181_

    Liberado el 23/5/2026
  • 0
    BugPlataforma

    Tarifa fija zona-ruta: recargo nocturno y festivos siguen sumando encima

    Cuando una zona-ruta tiene precio fijo (ZoneRoutePrice con tarifa fija configurada), las TariffRule de recargo nocturno y festivos siguen aplicandose encima del fijo. Cliente esperaba pagar 120k pero se sumo recargo encima. Reporte: ted-go conv 401863 2026-05-22 testeando Condominio Campestre El Laguito a Aeropuerto y desde ICESI a Aeropuerto. Quote cliente: Para estos servicios fijos no les aplica el recargo nocturno y los festivos. Es algo que debemos resolver. Propuesta: flag ZoneRoutePrice.suppressTariffRules bool default false. Cuando true salta TODAS las TariffRule y sirve precio fijo tal cual. --- _Reported via AI agent: AI agent — ted-go conv 401863_

    Liberado el 23/5/2026
  • 0
    BugDelivery

    Cart delivery: método de pago solo muestra Efectivo, falta Plin/Yape configurados

    En el simulador delivery del proyecto apolo-food, al entrar al carrito y tocar "cambiar método de pago" solo aparece Efectivo. No surgen Plin ni Yape, aunque están configurados como CustomPaymentMethod activos en la tenant. Reporte: William (calandria-taxis) — 2026-05-23 09:46 conv 412412. Hipótesis a verificar: 1. La pantalla de cart delivery fetcha CustomPaymentMethod de un endpoint distinto al que usa la pantalla de viaje taxi. 2. Filter de "deliveryEnabled=true" sobre CustomPaymentMethod no incluye los métodos configurados para apolo-food (revisar tabla CompanyCustomPaymentMethod). 3. La build Flutter actual no surgida desde apolofood mostraba siempre solo cash — necesita rebuild con el fix del 22-may. Verificar primero: GET /api/mobile/rider/payment-methods?companySlug=apolo-food devuelve Plin/Yape? Si SI, el bug es UI Flutter. Si NO, el bug es backend (filter / data missing). --- _Reported via AI agent: AI agent — William (calandria-taxis) conv 412412_

    Liberado el 23/5/2026
  • 0
    IdeaApp móvil

    Viajes programados

    por que no pueden ver los coductores los viajes programados en el cenntro de viajes

    Liberado el 23/5/2026
  • 0
    IdeaDelivery

    Bulk product upload with AI for commerce/restaurant menus (paid consumption-based feature)

    **Origin**: Mundo Limpio / pedimos-algo conv 412401, 2026-05-22. Cliente delivery vertical, va a onboardear varios comercios y la carga manual producto-por-producto es prohibitiva para 50-100+ productos por comercio. **Modelo de negocio acordado**: - Feature *pagado aparte*, no incluido en el plan mensual del tenant. - Cobro por *consumo real* de IA — tokens consumidos para reconocer productos + imágenes generadas (opcional). - Estimado: ~$0.03-0.10 USD por producto procesado. Imágenes ~$0.05 USD cada una. **Funcionalidades**: 1. **Reconocimiento de menú via IA**: - Input: foto/PDF/Excel/Word del menú impreso o digital. - LLM (Claude o GPT-4o vision) extrae: nombre, descripción, precio, variantes, categoría, alérgenos. - Crea los productos en bloque en el comercio destino. 2. **Generación de imágenes** (opcional, activable): - Para productos sin foto, IA genera imagen representativa via DALL-E / Stable Diffusion / Imagen. - Cliente paga por cada imagen generada. 3. **Sync con Google Sheets** (fase 2): - Vincular un Sheet a un comercio. Cada cambio en el Sheet sincroniza al catálogo. **Scope técnico**: 1. **Endpoint** `POST /api/ai-agent/business/[id]/bulk-product-upload` (o `/api/businesses/[id]/products/bulk-ai`): ``` { source: 'image' | 'pdf' | 'excel' | 'sheets-url', file?: <file upload>, generateMissingImages: boolean, dryRun: boolean // si true, solo muestra preview sin guardar } ``` 2. **Job worker** — procesa el input async. Reporta progreso. Acumula costo en `BusinessAIUsage` table (companyId + businessId + cost + timestamp). 3. **Dashboard UI** — en el panel comercio, botón 'Cargar menú con IA'. Modal de upload + preview. Confirmación de precio estimado antes de procesar. 4. **Billing** — al fin del mes, suma `BusinessAIUsage` y aparece en factura como item separado del plan. 5. **Tope de seguridad** — `CompanySettings.aiBulkUploadMonthlyBudgetUSD` opcional. Si el consumo del mes excede, bloquea más uploads hasta que admin apruebe. **Próximo paso** (waiting on cliente): - pedimos-algo me va a pasar ejemplos reales de menús (foto/PDF/Excel) para que hagamos pruebas y midamos qué tan bien lo reconoce la IA antes de definir tarifa final. **Beneficio amplio**: aplicable a cualquier tenant delivery vertical (no solo pedimos-algo). Diferenciador competitivo vs apps básicas que requieren carga manual. **Estimación**: 3-4 semanas (IA prompts + endpoint + worker + dashboard UI + billing integration + tests con varios formatos de menú). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Mundo Limpio / pedimos-algo conv 412401)_

    Liberado el 12/6/2026
  • 0
    BugPlataforma

    Apphive admin role reassignment doesn't propagate to apphive.dev frontend (cache stale or role-link bug)

    **Origin**: Tyson / proj_vf5gMc8KFHsaP46cHBxEWQ conv 417911, 2026-05-22. Caso reproducible. **Flujo**: 1. Tyson reporta 'Permisos insuficientes' en apphive.dev al intentar acceder a su proyecto (que él dice ser Owner). 2. Jonatan reasigna manualmente el role Owner a su email `hirchazofe@gmail.com` en el backend de Apphive. 3. Tyson refresca apphive.dev (Cmd+Shift+R) y re-loguea — *sigue viendo el mismo error*. 4. Screenshot muestra: 'Permisos insuficientes — Tu email: hirchazofe@gmail.com — Tus roles actuales: Ninguno'. **Posibles causas a investigar**: 1. **Caché frontend stale** — apphive.dev mantiene el resultado del lookup de permisos en localStorage / IndexedDB y no invalida tras cambio de role en backend. Test: clear all site data → re-login. 2. **Caché backend stale** — Redis o similar cachea `user_id → roles` por X minutos. Tras reasignación admin, no se invalida. 3. **Mismatch de cuenta** — Jonatan reasignó a la cuenta vinculada a Google Sign-In de `hirchazofe@gmail.com`, pero Tyson se loguea con un método diferente (email+password tradicional) que internamente es OTRA cuenta. Mismo email, diferente `userId`. *Esto lo estamos verificando ahora pidiendo screenshot del User ID arriba a la derecha de apphive.dev*. 4. **Bug en la reasignación** — la API admin guardó el role en la fila incorrecta (e.g., en una versión vieja del project owner record). Auditar tabla `project_members` o equivalente. **Acción inmediata** (sweep activo): pedido a Tyson screenshot del User ID + método de login. **Acción de fondo** (este FB): 1. **Invalidación de caché explícita** post-reasign — si existe caché Redis/memory: clearProjectCache(projectId) inmediato. 2. **Multi-account-per-email handling** — si un email puede tener 2 userIds (uno Google, uno password), el dashboard debería *mostrar ambos* en el modal de reasignación + ofrecer 'asignar al usuario activo más reciente'. 3. **UI de diagnóstico** — en apphive.dev cuando aparece 'Permisos insuficientes', mostrar el `userId` actual debajo del email, así el cliente puede pasarle al support fácilmente para verificar match. 4. **Auditoría** del incidente: ver logs del proyecto `proj_vf5gMc8KFHsaP46cHBxEWQ` para confirmar dónde se rompió. **Estimación**: 1-2 días (depende de qué causa raíz se confirme primero). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Tyson conv 417911)_

    Liberado el 23/5/2026
  • 0
    IdeaPlataforma

    AI-agent endpoint to set Company.customDomain + add to Vercel/Cloudflare (mirror of session endpoint)

    **Origin**: dale / navan-drivers conv 415663, 2026-05-22. Cuando el cliente pidió URL en su dominio propio, no pude configurarlo del lado nuestro vía AI-agent — el endpoint actual `POST /api/companies/[id]/domain` requiere NextAuth session (admin del tenant logueado en dashboard). Tuve que orientar a dale a entrar al dashboard él mismo y usar el self-service UI. **Gap**: cualquier configuración de dominio personalizado que un cliente pida vía chat (común en migraciones Apphive→Cabgo o clientes que ya tienen dominio comprado), el agente no puede ejecutar — el cliente tiene que hacerlo manualmente desde el dashboard. Esto agrega fricción + delays + chat back-and-forth. **Propuesta**: `POST /api/ai-agent/domains` ``` { companySlug: string, domain: string, // 'www.cliente.com' o 'admin.cliente.com' type: 'DASHBOARD' | 'APP', // DASHBOARD → Vercel, APP → Cloudflare Pages } ``` Mirror exacto del `POST /api/companies/[id]/domain` (NextAuth) pero con `x-api-key`. Internamente delega a las mismas funciones: - `addDomainToProject` (Vercel) si type=DASHBOARD - `addDomainToCloudflarePages` si type=APP - `addFirebaseAuthorizedDomain` para Google Sign-In - Upsert `DomainVerification` row - Set `Company.customDomain` o `Company.appDomain` Return: el CNAME exacto que el cliente debe poner en su DNS provider + status. **También requerido** — endpoint para *verificar* el estado del dominio sin tener que hacer SQL: `GET /api/ai-agent/domains?companySlug=<slug>` ``` { dashboard: { domain, status: 'verified'|'pending'|'misconfigured', dnsRecord }, app: { domain, status, dnsRecord } } ``` Esto ya está parcialmente cubierto por el `GET /api/ai-agent/company-config` enriquecido de hoy (devuelve DomainVerification[]), pero un endpoint específico ayuda a que el agente solo lea lo que necesita. **Beneficio**: en cada caso de migración Apphive→Cabgo donde el cliente quiere dominio propio, el agente lo configura sobre la marcha sin que el cliente toque el dashboard. Reduce el flow de 5-10 min a 30 seg. **Estimación**: 1 día dev (endpoint + auth check + tests con dale o tenant similar). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (dale / navan-drivers conv 415663)_

    Liberado el 23/5/2026
  • 0
    IdeaPagos

    Per-passenger fare scaling for high-capacity vehicles (min fare + per-pax surcharge)

    **Origin**: Tour Instinct conv 418018, 2026-05-22 (Q4). Modelo de pricing que necesitan: una SUV (7 pax max) tiene una *tarifa mínima* (para 1-4 pax) y luego *un cargo proporcional adicional* por cada pasajero del 5to al 7mo. Ejemplo: - SUV 1-4 pax: $400 MXN base - 5to pax: +$50 MXN ($450 total) - 6to pax: +$50 MXN ($500 total) - 7mo pax: +$50 MXN ($550 total) Hoy Cabgo soporta `ServiceType.maxPassengers` pero la tarifa es flat por ServiceType — no escala con número real de pasajeros. **Scope**: 1. **Schema** — en `ServiceType` o `ZoneServiceConfig`: ``` minPassengersForBase Int? // ej. 4 → 1-4 pax pagan baseFare perPassengerSurcharge Decimal? // ej. 50.00 → cobra esto por cada pax adicional sobre minPassengersForBase ``` 2. **Cálculo en fare-calculator**: si `numPassengers > minPassengersForBase`, agrega `(numPassengers - minPassengersForBase) * perPassengerSurcharge` al fare total. Esto se snapshottea en `Trip.pricingSnapshot` para auditoría. 3. **Rider UI** — al solicitar viaje, el rider tiene que *especificar el número de pasajeros* (selector 1-N). Hoy no existe ese flow para Cabgo en general (asume 1 pasajero por viaje). Agregar un widget de pasajero-count en el flow de request, default 1, visible solo cuando el ServiceType tenga `perPassengerSurcharge` set. 4. **Driver UI** — el conductor ve `numPassengers` en la pantalla del viaje (para confirmar conteo al recoger). 5. **Dashboard** — en el editor de ServiceType, dos campos nuevos: 'Min pasajeros para tarifa base' y 'Cargo por pasajero adicional'. **No incluye**: - Tarifa decreciente por pasajero (ride-sharing style: 'más pasajeros = más barato por persona'). Opuesto a este uso. - Splits entre pasajeros (dividir cuenta). Feature distinto. **Estimación**: 3 días dev (schema + cálculo + rider UI selector + driver UI display + dashboard editor + tests con varios escenarios). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Tour Instinct conv 418018 Q4)_

    Liberado el 23/5/2026
  • 0
    IdeaApp móvil

    Driver languages spoken — visible to passenger in trip card

    **Origin**: Tour Instinct conv 418018, 2026-05-22 (Q2). Tour Instinct opera con turismo en Quintana Roo + Yucatán; los pasajeros son frecuentemente turistas internacionales. Quieren saber qué idiomas habla el conductor antes/durante el viaje para decidir si necesitan otro conductor o ajustar expectativas de comunicación. **Scope**: 1. **Schema** — nuevo campo en `Driver`: ``` languages String[] @default([]) // ISO 639-1 codes: ['es', 'en', 'fr', 'de', etc.] ``` Default array vacío (no asumimos nada de conductores existentes). 2. **Dashboard UI** — en la edición del conductor, un multi-select con la lista de idiomas soportados (es, en, fr, de, it, pt, ru, zh, ja). Conductor puede marcar varios. 3. **Onboarding driver** — en el flow de registro del conductor (RegistrationFieldConfig dinámico), agregar un campo nuevo tipo `MULTISELECT` con key `languages`. Tenant decide si lo activa. 4. **API mobile** — `/api/mobile/rider/trips/active` y `/[id]` incluyen `driver.languages: string[]` cuando feature on. 5. **Rider UI** — debajo del nombre del conductor: row de flag-icons con los idiomas que habla. Ej. 🇪🇸 🇺🇸 🇫🇷 (mostrando los 3 que speak). Si el conductor habla solo el idioma del tenant default, no mostrar (no aporta info útil). **No incluye**: - Filter en dispatch por idioma del pasajero (ej. 'pasajero anglo → solo asignar conductores que hablen inglés'). Eso es feature separado de matchmaking; este FB es solo display. - Traducción automática de chat in-app. Idem. **Estimación**: 1.5 días dev (schema + RegistrationFieldConfig integration + dashboard form + mobile API + rider UI + flag iconography). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Tour Instinct conv 418018 Q2)_

    Liberado el 23/5/2026
  • 0
    IdeaApp móvil

    Driver affiliation field (Empleado / Aliado / Freelancer) visible to passenger

    **Origin**: Tour Instinct conv 418018, 2026-05-22. La empresa opera con 3 categorías de conductores: empleados directos, conductores de *compañías aliadas*, y *freelancers* independientes. El pasajero quiere ver de qué categoría es su conductor al ser asignado (transparencia + seguridad) y la copia del PDF orden de servicio debe registrarlo legalmente. **Scope**: 1. **Schema** — nuevo campo en `Driver`: ``` affiliation DriverAffiliation @default(EMPLOYEE) enum DriverAffiliation { EMPLOYEE // empleado directo del tenant ALLIED_COMPANY // empleado de una compañía aliada FREELANCER // independiente } ``` Default EMPLOYEE para mantener comportamiento actual (todos los conductores existentes quedan tagged como empleados sin migration data loss). 2. **Dashboard UI** — en la edición del conductor (driver detail page), un dropdown con las 3 opciones. Visible solo cuando el tenant tiene el feature on (CompanySettings.showDriverAffiliation default false). Si el conductor es ALLIED_COMPANY, agregar campo opcional `allyCompanyName` para mostrar de qué compañía aliada es. 3. **API mobile** — `/api/mobile/rider/trips/active` y `/api/mobile/rider/trips/[id]` deben incluir `driver.affiliation` y `driver.allyCompanyName` cuando el feature esté on para el tenant. 4. **Rider UI** — en `ride_tracking_screen` y el detalle del viaje, agregar una línea pequeña debajo del nombre del conductor: 'Empleado de Tour Instinct' / 'Conductor aliado: [Compañía X]' / 'Conductor independiente'. Solo se muestra si el tenant tiene el feature on. 5. **PDF orden de servicio** (depende de feature separado): incluye el campo en la copia para Tour Instinct interno + copia del pasajero. **No incluye**: - Driver onboarding diferenciado por affiliation (ej. freelancer paga más comisión que empleado). Eso es feature separado (commission per affiliation), no parte de este FB. - Notification flow per affiliation. Idem. **Estimación**: 2 días dev (schema + migration + dashboard form + mobile API + rider UI strings + tests). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Tour Instinct conv 418018 Q3)_

    Liberado el 23/5/2026
  • 0
    IdeaPlataforma

    Pre-check Play declarations before publish consumes a versionCode

    **Origin**: Herberth / via-1efd conv 405524, 2026-05-22. Cuando disparé `POST /api/ai-agent/store/publish` por primera vez con v1.0.100, Google Play rechazó la subida con 'Your background location permission declaration needs to be updated' — pero el versionCode 100000092 quedó *consumido* aunque el upload no completó. Re-intentar con el MISMO buildId fallaba con 'Version code 100000092 has already been used'. Mismo problema con v1.0.102 (foreground_services missing). Resultado: tuve que disparar v1.0.103 desde cero para finalmente publicar. Quemamos 2 builds + 2 versionCodes evitablemente. **Root cause**: El endpoint `/api/ai-agent/store/publish` (y su mirror `/api/apps/store/publish`) NO valida que todas las declaraciones requeridas estén presentes en Play Console ANTES de subir el AAB. Si falta una declaración (background_location, foreground_services, full_screen_intent, etc.), Play acepta el upload (consumiendo versionCode) pero después rechaza por declaración faltante. El versionCode queda *burned*. **Propuesta**: 1. **Pre-flight check en `POST /api/ai-agent/store/publish`** (antes del AAB upload): - GET internal a la lista de declarations actuales en Play. - Si alguna falta + el endpoint sabe cómo declararla (`POST /api/ai-agent/store/declarations`), *dispararlas en serie* antes de continuar. - Si alguna falta requiriendo input externo (ej. permission video YouTube URL no generada), responder `412 Precondition Failed` con el listado de pendientes — no avanza al upload, no quema versionCode. 2. **Especial para background_location**: detectar automáticamente que el AAB declara `ACCESS_BACKGROUND_LOCATION` permission y si la declaración Play correspondiente no está, llamar a `permission-video/retry-youtube` si la URL del video aún no está en formato YouTube (caso via-1efd: tenía R2 .mp4 pero no YouTube, lo que rompía la declaration POST). 3. **Endpoint para re-uso de versionCode quemado** (no estoy seguro si la API de Play permite esto — si no, no aplica). Si no, al menos *no quemarlo en primer lugar*. **Beneficio**: cada upload fallido por declaración consume ~10 min de rebuild (depende del tenant). Para tenants con migraciones masivas o automation, multiplicar por 10-20 versiones nuevas implica horas perdidas. Este fix lo elimina. **Estimación**: 1-2 días dev (pre-flight check + integrar retry-youtube en publish + test con tenant nuevo simulando declaraciones faltantes). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Herberth / via-1efd debugging)_

    Liberado el 23/5/2026
  • 0
    IdeaPlataforma

    AI-agent endpoint for Firebase pool routing (assign + auto-pool-when-default-full)

    **Origin**: Serali Mx (conv 387707, 2026-05-22). Su tenant quedó pegado al Firebase project equivocado (via-tech-solutions con SA inválida) tras la migración Apphive→Cabgo. El fix requirió: 1. Manual `UPDATE Company.firebaseProjectId` (3 SQL queries directas). 2. Manual decremento/incremento de `FirebaseProject.appCount`. 3. Llamada manual a `POST /api/ai-agent/firebase-sha` para registrar el bundle en el nuevo pool. 4. Trigger build. **Gap actual**: no hay un endpoint AI-agent que haga esto en un solo paso. `POST /api/super-admin/firebase-projects/assign` existe pero requiere NextAuth session — no llamable desde agente. Cabgo2-app (el default) además está al máximo 30/30, así que cualquier tenant nuevo necesita asignación manual a pool secundario. **Propuesta de endpoint**: `POST /api/ai-agent/firebase-projects/assign` ``` { companySlug: string, // Opcional: si se omite, el endpoint auto-elige el pool con menor appCount. firebaseProjectId?: string, // Si se omite, asume el bundle activo del AppConfig. bundleId?: string, // Si true (default), llama internamente a syncAndroidSha para crear el // app Android en el nuevo pool y registrar el SHA-1 si existe. registerBundle?: boolean, // Si true (default false), también dispara un build después de la asignación. triggerBuild?: boolean, } ``` **Acciones del endpoint** (atomicas dentro de un transaction): 1. Lookup company by slug. 2. Si firebaseProjectId no se pasa: auto-pool. Selecciona el FirebaseProject con `appCount < maxApps` y menor `appCount`. Si todos están full, ERROR `no-capacity-available` para que el operator provisione un pool nuevo. 3. UPDATE `Company.firebaseProjectId` (con clearProjectCache). 4. Decrementa `FirebaseProject.appCount` del proyecto anterior. 5. Incrementa `FirebaseProject.appCount` del proyecto nuevo. 6. Si registerBundle (default true): llama `syncAndroidSha` para crear/find el Android app + registrar SHA-1. 7. Si triggerBuild: dispara build via `POST /api/ai-agent/builds`. 8. Return `{ok, previousProjectId, newProjectId, newProjectName, registered, buildId?}`. **Cleanup nice-to-have**: cuando se reasigna un tenant, debería llamar `buildCleanupNeeded` (del super-admin endpoint) para devolver al caller qué hay que limpiar manualmente en el proyecto Firebase anterior (Android apps huérfanos). Hoy en super-admin lo retorna; en AI-agent también es útil para reportarlo en sweep. **Beneficio**: cada migración Apphive→Cabgo (Serali, futuros), o cada situación de "build falla por Token exchange", se resuelve en 1 HTTP call en lugar de 3 SQL + 1 endpoint + 1 build trigger. **Capacity check separado** (opcional, scope reducido): `GET /api/ai-agent/firebase-projects?withCapacity=true` ``` { projects: [{id, name, projectId, isDefault, appCount, maxApps, available: maxApps - appCount}], poolHealth: "ok" | "near-full" | "full", // near-full: <10% capacity en al menos 1 pool } ``` Permite al agente diagnosticar el estado del pool sin tocar SQL antes de hacer reasignaciones masivas. --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Serali / serali conv 387707 + gap operacional identificado durante el fix)_

    Liberado el 23/5/2026
  • 0
    IdeaApp móvil

    Service-order PDF emailed to driver + passenger + internal upon trip assignment

    **Origin**: Tour Instinct (Quintana Roo + Yucatán, México, transporte privado + tours personalizados). Conv 418018, 2026-05-22. Tour Instinct lo califica como NEGOCIABLE-NO bloqueante para legal compliance — sin PDF no pueden lanzar la app. **Trigger**: cuando el conductor *acepta* el viaje (no al asignar, no al completar — específicamente al accept). **Destinatarios + 3 versiones del PDF**: 1. **Copia conductor** (al email registrado del conductor) - Sin tarifa - Solo leyenda "PAGADO" + últimos 4 dígitos de la tarjeta del pasajero - Idioma: español neutro 2. **Copia pasajero** (al email del pasajero) - Con tarifa completa - Mención expresa: "se encuentra cubierto el seguro del viajero" - Reconocimiento de aceptación de términos y condiciones - Idioma: el que el pasajero haya elegido en la app 3. **Copia interna Tour Instinct** (a `sales@tourinstinct.com.mx`) - Con tarifa completa - Idioma: español neutro - Sirve como registro fiscal / legal de cada servicio **Campos del PDF (legalmente obligatorios para Tour Instinct)**: - Nombre comercial: `Tour Instinct` - Denominación / Razón social: `Instinto de Gira` - Folio / Número de orden (numeración secuencial — no aleatoria — global por tenant) - Fecha y horario del servicio - Datos del pasajero principal: nombre, teléfono, correo electrónico - Número total de pasajeros - Datos del conductor: nombre + status en la organización (`Empleado` / `Empleado de compañía aliada` / `Freelancer`) — depende del feature "mostrar afiliación conductor" que también pidieron (Q3) - Datos del vehículo: modelo, año, placa, número de asientos - Ruta: origen → destino - Tarifa (visible en pasajero+interno, oculta en conductor con "PAGADO") - Membrete con logo del tenant (cabecera del PDF) **Scope técnico estimado** (post-priorización): 1. **Template PDF (HTML→PDF con Puppeteer o jsPDF)**: 1 template parametrizable + 3 variantes (driver/passenger/internal) que sea reutilizable por otros tenants con campos custom. 2. **Hook trigger**: en `acceptTrip` handler (driver mobile API). Después de `Trip.status = ASSIGNED`, encolar job `generate-service-order-pdf`. 3. **Job processor**: render PDF → guardar en R2 → enviar 3 emails via Mailgun (o el mailer configurado del tenant). 4. **Configuración per-tenant**: - `CompanySettings.serviceOrderPdfEnabled: Boolean` (default false) - `CompanySettings.serviceOrderPdfInternalEmail: String?` - `CompanySettings.serviceOrderPdfDenominacionSocial: String?` (razón social, para tenants donde difiere del nombre comercial) - `CompanySettings.serviceOrderPdfFolioPrefix: String?` (ej. `TI-2026-`, default null = solo numero global) - Counter global del tenant: `CompanySettings.serviceOrderPdfNextFolio: Int @default(1)` - Para campo "afiliación conductor" → Driver model needs `affiliation` enum field (EMPLOYEE / ALLIED_COMPANY / FREELANCER) — esto es feature separada (Q3 de Tour Instinct). 5. **i18n**: emails + PDF en idioma del receptor. Driver siempre español neutro, internal siempre español neutro, passenger según `Customer.languageCode`. 6. **Endpoint AI-agent**: `POST /api/ai-agent/service-order-pdf/test?companySlug=<slug>&tripId=<id>` — genera un PDF de prueba con datos de un viaje histórico para validación con el cliente antes de poner en prod. **Estimación de dev**: 4-6 días (template + email delivery + per-tenant config + tests + endpoint AI-agent + dashboard config UI). **Prioridad sugerida**: ALTA. Tour Instinct lo ata directamente a la decisión de comprar el Plan PRO ($699 USD). Su junta de socios es el martes próximo (2026-05-26) — si para entonces tenemos esta feature mínimamente prototipada o con ETA firme, cierran. Sin eso pueden buscar competidor. **Dependencias**: - Q3 (mostrar afiliación conductor) — comparte el campo `Driver.affiliation`. - Existing mailer infra (Mailgun) — ya está en el stack. - Existing PDF generation infra — verificar si ya hay Puppeteer / jsPDF en el repo (existe permission-video pipeline, probablemente sí). **Tenants que se beneficiarían** (más allá de Tour Instinct): - Cualquier transporte que opere en mercados con regulación fiscal estricta (México, Argentina, Colombia para taxis legales). - Tenants delivery que quieran enviar comprobante al motorizado por cada entrega. - Generic feature, no específica de Tour Instinct. --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Tour Instinct conv 418018)_

    Liberado el 11/6/2026
  • 0
    IdeaPlataforma

    White-label invite URL: serve /invite from tenant's customDomain + hide 'Powered by Cabgo' footer

    **Scope** (definido con dale / navan-drivers conv 415663, 2026-05-22): Los invites de pasajero (`https://www.cabgo.app/invite?t=...`) hoy renderizan correctamente la marca del tenant en el contenido HTML *y* en el OG preview de WhatsApp — pero la URL visible al usuario sigue siendo `cabgo.app` (en el preview de WhatsApp y en la barra de direcciones cuando hace click). El cliente quiere que aparezca *su* dominio (`navandrivers.com.co/invite?t=...`) y que el pie de página *no* diga 'Powered by Cabgo'. La infraestructura para hacer esto ya existe parcialmente: - `Company.customDomain` (Vercel mask para dashboard) — campo existe pero hoy no se utiliza para enrutar el path `/invite`. - `lib/vercel.ts addDomainToProject` + `lib/services/domain/cloudflare-pages-domain.ts` — wiring presente desde compras de dominio. - Endpoint `POST /api/companies/[id]/domain` (auth NextAuth) — UI de dashboard self-service ya disponible en /dashboard/branding. **Tareas concretas**: 1. **Verificar/extender la masking layer de Vercel** para que `/invite/*` se sirva desde cualquier dominio en `Company.customDomain`. Si Vercel ya lo hace por defecto (cualquier dominio mapeado al proyecto sirve todas las rutas), validar que sí funciona y documentarlo. Si no, agregar middleware de host-resolve. 2. **Página /invite/page.tsx**: detectar `Host` header en server-component, resolver tenant por `Company.customDomain` (cuando difiera de cabgo.app), y ocultar el `<div>... · Powered by Cabgo</div>` cuando customDomain esté seteado y verificado. Mantener el footer solo cuando se sirve desde cabgo.app. 3. **AI-agent endpoint nuevo** `POST /api/ai-agent/domains`: mirror del POST `/api/companies/[id]/domain` con auth x-api-key. Permite a un agente agregar customDomain sin que el cliente toque el dashboard. (Hoy el agente puede leer customDomain via `/api/ai-agent/company-config` enriquecido — falta el lado escritura.) 4. **DomainVerification status**: surface en company-config (ya agregado en 0e3323aa). Confirmar que la UI dashboard refresca status post-verificación. **Caso ancla**: navan-drivers (Dale Navan Drivers) — Orlando comparte invites por WhatsApp y los receptores ven `cabgo.app` como la URL del link en el preview, lo que lleva a confusión / pérdida de tracking de marca propia. dale pidió explícitamente 'que no aparezca cabgo en ningún lado'. Confirmó con screenshots que el OG preview ya muestra Dale Navan Drivers (post-cache-refresh) pero la URL del link sigue en cabgo.app. **Prioridad sugerida**: media. Hoy hay workaround (orientar al cliente a configurar dominio personalizado vía /dashboard/branding) pero la pieza #2 (ocultar 'Powered by Cabgo' condicional) sí requiere código y bloquea el verdadero white-label. **No incluye**: - Mailgun domain para emails (otro flow). - Custom domain para la app móvil (eso ya está via appDomain → Cloudflare Pages). --- _Reported via AI agent: AI agent — sweep 2026-05-22 (Dale / navan-drivers conv 415663)_

    Liberado el 23/5/2026
  • 0
    IdeaPlataforma

    Enriquecer GET /api/ai-agent/company-config (logoUrl, customDomain, appDomain, related tenants)

    Durante los sweeps el agente toca SQL directo para resolver logoUrl, customDomain, appDomain de un tenant, y para descubrir tenants 'hermanos' (mismo dueño / nombre similar). Ej. caso dale (2026-05-22): hubo que hacer 3 SQL directos para entender que 'dale' (Navan Transportes SAS) y 'navan-drivers' (Dale Navan Drivers) son tenants distintos pero del mismo dueño operativo. Propuesta: extender GET /api/ai-agent/company-config?slug=<slug> para devolver: - logoUrl, customDomain, appDomain, primaryColor, secondaryColor - DomainVerification[] (estado de cada dominio verificado) - relatedTenants[]: { slug, name, relationKey } donde relationKey detecta 'mismo dueño' por email/teléfono compartido Mantiene compatibilidad con campos actuales (currency, country, etc). Mirror existing PATCH para no tocar columnas read-only. Impacto: cada sweep que antes hacía 3+ SQL queries por tenant ahora hace 1 HTTP. Surface reutilizable desde MCP servers y futuras integraciones. --- _Reported via AI agent: AI agent — internal infra (sweep 2026-05-22)_

    Liberado el 22/5/2026
  • 0
    IdeaPlataforma

    Auto pre-activate Apple reviewer Workspace account after provisioning

    Cada tenant nuevo que provisiona ensureAppStoreReviewer crea un Workspace account (review-<slug>@cabgo.app) que NUNCA ha sido logueado, y por eso al primer login Google muestra el speedbump 'Welcome to your new account / I understand' que el revisor de Apple no puede saltar dentro del flujo OAuth de la app — resulta en rechazo automático 2.1(a) Google Sign-In. Hoy el fix es manual: SSH al e2e farm + correr scripts/preactivate_workspace.mjs en Playwright headless. Funciona pero requiere intervención humana cada vez (apply-taxi 2026-05-22, futuro tenant Y, futuro tenant Z). Propuesta: dentro de ensureAppStoreReviewer (src/lib/app-store-reviewer.ts), después del POST a admin.users.insert(), hacer un fetch HTTP al farm orchestrator con un endpoint /pre-activate-workspace que ejecute el script Playwright. Timeout 90s, log éxito/falla en AppStoreConnectConfig.reviewerPreActivatedAt (nueva columna), no bloquea el flow si falla. Impacto: cada submission iOS de tenant nuevo deja de requerir pasos manuales. Reduce time-to-Apple-submission y elimina una clase de rechazo recurrente. --- _Reported via AI agent: AI agent — internal infra (sweep 2026-05-22)_

    Liberado el 22/5/2026
  • 0
    BugOtro

    Ghost trip race — sexta capa: bug en Flutter driver app (fail-CLOSED + skip cache)

    Anchor: Dtour conv 387181, 2026-05-22. Bryan Vilca reprodujo el ghost trip de nuevo despues de 5 iteraciones backend (b7890fa2, ad17ffd6, e1172935, 2bca4bc4, a4ba4ed5) todas activas en prod. Confirmacion definitiva: bug NO es del backend, es del Flutter driver app. Dos leaks identificados: 1. RideRequestBloc safety check (getTrip) era fail-OPEN — si la verify call fallaba (network blip durante la cancel cascade), el bloc sonaba el offer de todos modos. Fix: retry una vez con 400ms, si vuelve a fallar DROP silenciosamente. 2. FirebaseService.watchRideRequests solo filtraba EMPTY cache snapshots. Non-empty cache emissions con doc stale (status=pending pre-cancel) flowed through en cold-start. Fix: filtrar TODOS los cache-only snapshots, esperar server-confirmed only. Shipped commit 81383671. Nueva build dtour v1.0.204 disparada con ambos fixes — solo aplica cuando driver app sea actualizada en Play Store o reinstalada del APK.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Ghost trip race — quinta capa: wrap sendFirestoreRideRequest en transaccion atomica

    Anchor: Dtour conv 387181, 2026-05-22. Test coordinado: Renzo Vilca canceló trip TMPH6RTTI 7s después de crear (17:21:09 UTC creación, 17:21:16 cancel, 2 notifs). Bryan Vilca abrió app, vio offer, contraoferta. 4 iteraciones anteriores no fueron suficientes — quedaba ventana sub-segundo entre read y write del dispatcher en sendFirestoreRideRequest. 5ta fix shipped a4ba4ed5: wrap el check trips/<id>.status + write per-driver doc en fs.runTransaction. Firestore garantiza isolation transaccional — si cancel commitea entre read y write, retry y abort. Cerrado definitivo.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Source download falla con RESOURCE_EXHAUSTED para tenants en pool Firebase overflow

    Anchor: delivery-go conv 401633, 2026-05-22. El endpoint /api/apps/source-download no pasaba credenciales Firebase del tenant al build server. El build server intentaba registrar un nuevo Android app en el proyecto Firebase default (cabgo2-app) que ya esta lleno, fallaba con 429 RESOURCE_EXHAUSTED. delivery-go runtime build funcionaba porque triggerCompanyBuild si pasa las credenciales Firebase. Fix shipped c7b7ff74: source-download ahora hace getFirebaseProjectForCompany y pasa firebaseProjectId/clientEmail/privateKey/messagingSenderId al payload del build server, mirror exacto del flujo de trigger-company-build.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Invite landing — OpenGraph estatico mostraba marca Cabgo en preview WhatsApp/SMS

    Anchor: dale Navan Drivers conv 415663, 2026-05-22. La pagina /invite usaba metadata estatica con titulo Invitacion a la app y sin og:image. Cuando un conductor compartia el invite por WhatsApp, el preview mostraba el favicon de Cabgo + Invitacion a la app generico. Operadores se quejaban de que recipientes ven la marca Cabgo en lugar de la suya - riesgo de perder clientes a Cabgo. Fix shipped commit 620e04fb: generateMetadata dinamica por token con tenant name + logo en og:image + og:siteName.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Ghost trip race — cuarta capa: cancel debe escribir trips/<id> antes que docs por conductor

    Anchor: Dtour conv 387181, 2026-05-22. Cuarto fix despues de b7890fa2, ad17ffd6, e1172935. La ventana restante de 200-400ms se cerraba ahora con: (a) reorden del cancel route — escribir trips/<tripId> con status=CANCELLED ANTES de iterar per-driver docs (asi el guard de sendFirestoreRideRequest lo encuentra siempre), (b) requery fresh de TripNotification dentro del bloque Firestore-update en lugar de usar el snapshot inicial (capta conductores agregados en paralelo por el dispatcher). Fix shipped commit 2bca4bc4.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Ghost trip race — tercera capa: dispatcher debe leer Firestore antes de escribir

    Anchor: Dtour conv 387181, 2026-05-22. Tercer fix despues de b7890fa2 (cancel set+merge) + ad17ffd6 (dispatcher loop guard via Postgres). Quedaba ventana sub-segundo entre el read de Postgres trip.status al inicio de la iteracion y el write de Firestore al final. Fix shipped e1172935: dentro de sendFirestoreRideRequest, leer trips/<tripId> en Firestore justo antes del write. Si status CANCELLED o COMPLETED, abort y return null. Beneficia a todos los callers: request dispatcher, B2B service, WhatsApp webhook, notifyDriverOfPendingTrips.

    Liberado el 22/5/2026
  • 0
    BugOtro

    William calandria-taxis PDF — 21 issues consolidados (Usuario/Conductor/Comercio)

    Anchor: William calandria-taxis conv 412412, 2026-05-22. PDF ERRORES_CABGO_WILLIAM.pdf con 21 items recopilados de clientes haciendo pruebas. Resumen por modulo: USUARIO (8): (1) Copy boton Cambiar a Pasajero no debe ser tan transport-specific en tenants no-transporte. (2) Plin/Yape configurados en dashboard no aparecen en metodos de pago delivery. (3) Cambio de codigo de pais no persiste en PATCH Customer. (4) Al pedir taxi tambien sale opcion Delivery (filtrar por intent). (5) Efectivo: pedir con cuanto paga para vuelto. (6) Yape/Plin: distinguir de efectivo, no pedir monto. (7) Carrito no muestra extras (ya anotado en feedback aparte). (8) Extras x cantidad: agregar etiqueta UI. CONDUCTOR (9): (9) Hora recojo en 24h, debe respetar locale es-PE 12h. (10) BUG: deslizar para aceptar cambia orderStatus preparando->listo (debe ser solo el comercio). (11) Offer ignora precio puesto por cliente, motorizado ve tarifa calculada. (12) Pantalla principal motorizado no suma viajes taxi efectivo. (13) Mis ganancias no suma ganancia neta taxis. (14) Historial: formato moneda no respeta dashboard config. (15) Centro mensajes: mismo problema formato decimal. (16) Mis ganancias no suma propinas. (17) Sesion motorizado se desconecta automatic. COMERCIO (4 CRITICOS porque afectan flujo $): (18) Pago Yape/Plin desde comercio -> balance motorizado suma ganancia neta como pasarela cuando deberia solo restar comision (cash-like). Si comercio pide retiro cobra doble. (19) Mismo bug en flujo cobrar-entregar y solo-entregar. (20) Solo-entregar falta campo monto pedido para calcular comision/tarifa fija. (21) Pago efectivo con vuelto desde comercio: monto debe llegar al motorizado. Priorizacion propuesta: P1 esta semana: 18, 19, 20 (financiero) + 11, 12, 13, 10. P2 dos semanas: 1, 2, 3, 4, 7, 8, 9. P3 mes: 5, 6, 14, 15, 16, 17, 21.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Ghost trip race: dispatcher loop ignora cancel cuando va a mitad del fan-out

    Anchor: Dtour conv 387181, 2026-05-22. Fix anterior commit b7890fa2 atacaba solo el lado del cancel route (set+merge sobre docs no existentes). Pero el dispatcher inicial en /api/mobile/rider/trips/request itera N drivers haciendo .set() completo del doc ride_requests con status=pending. Si el cancel ocurre a mitad del loop, los drivers que faltan recibian un doc fresh con status=pending - overwrite del marker cancelled. Fix complementario commit ad17ffd6: re-check trip status en BD al inicio de cada iteracion del loop, break al primer no-PENDING/SEARCHING/COLLECTING_OFFERS.

    Liberado el 22/5/2026
  • 0
    IdeaOtro

    Carrito delivery: no permite customizacion por unidad en multiples items identicos

    Anchor: William calandria-taxis conv 412412, 2026-05-22. Caso uso: cliente quiere 3 pizzas - una con pepperoni, otra con tocineta, otra con tocineta+champinones. Hoy el carrito agrupa items identicos en una linea con cantidad - los extras aplican a las 3. Tampoco permite quitar ingrediente por alergia/preferencia. Fix: cuando se agrega con personalizacion, cada unidad cuenta como linea separada con sus propios extras y notas.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Carrito delivery: extras no aparecen en el resumen del item

    Anchor: William calandria-taxis conv 412412, 2026-05-22. Cuando se agrega item con extras (modifiers), en el resumen del carrito solo se ve el nombre del item, no se listan los extras seleccionados ni su precio adicional. Confuso para el cliente, parece que se perdieron. Fix: mostrar cada extra como linea debajo del item con su precio (+$X).

    Liberado el 22/5/2026
  • 0
    IdeaOtro

    Multi-tenant session switcher para revendedores

    Anchor: William (calandria-taxis) conv 412412, 2026-05-22. Revendedor entra a varios business portals de clientes distintos con el mismo email. El sistema solo soporta una sesion activa, la nueva pisa la vieja. Feature: al login con email vinculado a N tenants, mostrar selector dropdown. Una vez dentro, menu para switchear sin re-loguear (pattern GitHub org/Slack workspace switcher). Workaround actual: incognito/browsers distintos.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Driver marker icon aparece rotado con llantas hacia arriba en mapa rider

    Anchor: ted-go (Taxi Elegant Driver) conv 401863, 2026-05-22. Reportado por audio del cliente: el icono del carrito que indica posición del conductor sale con las llantas hacia arriba. Es un bug de rotación del marker en Flutter — probablemente el rotation angle se está aplicando con offset incorrecto (180° vs heading). Pendiente investigar en apps/cabgo/lib/features/rider/.../map/.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Zone detection prefers LOCALITY over POLYGON cuando hay overlap — inter-zone routes ignorados

    Anchor: ted-go (Taxi Elegant Driver) conv 401863, 2026-05-22. Tenant tiene Zona Metropolitana Cali (LOCALITY, bbox de toda Cali) con order=0 y zonas pequeñas dentro (Sur Cali, Centro, Aeropuerto…). findZoneForPoint devolvía Metropolitana primero, no se encontraba ZoneRoutePrice Metropolitana→Aeropuerto, fallback a per-km. Rider veía $61.200 en vez de $90.000 FLAT. Fix shipped commit 774afdac (2026-05-22): findZoneForPoint ahora scorea cada zona matched y devuelve la más específica (POLYGON/CIRCLE > LOCALITY).

    Liberado el 22/5/2026
  • 0
    BugOtro

    Driver passenger-invite landing page faltante — clientes que recibían el link veían página en blanco

    Anchor: Orlando navan-drivers + dale Navan Drivers, 2026-05-22. El endpoint /api/mobile/driver/passenger-invites generaba un inviteUrl https://{host}/invite?t=<token> pero NO existía la ruta /invite en Next.js — los recipientes del link veían página totalmente blanca en el browser. La invitación quedaba inútil. Fix shipped in commit b9c3e331 (2026-05-22): created src/app/invite/page.tsx that resolves the token, looks up the invite + driver + tenant branding, and renders a friendly landing with download buttons (Play Store + App Store from current AppBuild storeUrl) + branded with tenant colors/logo. Follow-up no implementado todavía: deep linking con Universal Links (iOS) + App Links (Android) para que si el cliente ya tiene la app instalada, el link la abra directo en lugar de la landing web.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Driver app — ghost trips: viajes cancelados por cliente siguen apareciendo activos al conductor al reabrir app

    Cuando un cliente cancela un viaje y el conductor tenía la app cerrada/background cuando llegó la cancelación, al reabrir la app el viaje sigue mostrándose como activo (ghost trip). El status real en BD es CANCELLED pero la lista local del conductor no se reconcilia. Fix esperado: al inicializar el driver home / lista de viajes activos, hacer fetch al server (GET /trips/active o equivalente) y descartar trips con status CANCELLED / COMPLETED. Hoy parece confiar 100% en el broadcast Firestore en tiempo real, pero si el broadcast no llegó (app cerrada), el state local queda stale. Anchor: Dtour conv 387181 2026-05-22. Trip 4d9ec770 cancelado por cliente correctamente en BD pero seguía apareciendo activo al conductor.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Driver app — oferta de viaje muestra recommendedFare como precio principal en lugar del estimatedFare del cliente (offer mode)

    Anchor: Ichiro rapidin-peru conv 396354 2026-05-21. En modo oferta (offer mode) el cliente puede poner su propio precio (estimatedFare). Verificado en logs de viajes (eee167d3, 90e0d03d, 2e8a7697 etc.) que el estimatedFare se guarda correcto del lado servidor, pero el motorizado, al recibir la oportunidad, ve el recommendedFare (calculado por la config tarifaria) en lugar del precio que puso el cliente. Fix esperado: en el driver app Flutter, la pantalla de oportunidad debe destacar el estimatedFare como precio principal y mostrar el recommendedFare como sugerido en menor jerarquía (o tachado). Buscar el widget que renderiza la oportunidad y revisar qué campo del payload toma para el monto principal. Afecta varios tenants en offer mode — Cabgo Delivery + Cabgo Taxi cuando la config permite negociación de precio.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Dashboard conductores — columna última conexión muestra hora errónea (driver desconectado hace 4h aparece como hace 3 min)

    Anchor: Dtour conv 387181 2026-05-21. Reportó que en Dashboard → Conductores la columna que muestra última conexión sigue indicando hace 3 minuto para conductores que realmente están OFFLINE hace 4+ horas. Ejemplo: Bryan Vilca (driver id 9bd689b9), status=OFFLINE en BD, updatedAt correcto, pero el dashboard muestra hace 3 min. Probable causa: el dashboard está leyendo un campo cacheado de presencia o un timestamp derivado en lugar del Driver.updatedAt real. Fix esperado: investigar qué campo lee el componente de listado de conductores y reemplazarlo por updatedAt o el campo correcto de heartbeat. El estado funcional ya es correcto (drivers OFFLINE no reciben viajes), solo es display engañoso.

    Liberado el 22/5/2026
  • 0
    BugOtro

    Rider app: mostrar No hay conductores disponibles en vez de Internal server error cuando trip se cancela por 0 drivers

    Cuando un rider pide viaje y no hay conductores online en el tenant, el flow es: Trip se crea en SEARCHING → search-drivers encuentra 0 → Trip pasa a CANCELLED → la app cliente muestra Internal server error genérico. Esto confunde al cliente porque NO es un error del server — es que no hay conductores activos. Fix esperado: la app debe interpretar la respuesta del search-drivers / status del trip y mostrar mensaje contextual No hay conductores disponibles en este momento. Intentá de nuevo en unos minutos en lugar del genérico Internal server error. Anchor: Gabriel d1una-express conv 391126 2026-05-21 — pasó horas debugueando creyendo que era bug del server, cuando la causa era que los 8 conductores estaban OFFLINE. Lado backend: el endpoint trips/request devuelve 200 con el Trip creado; el cancel posterior viene del search-drivers job. El mensaje de error que ve el rider posiblemente venga de otra llamada subsequent (subscribe-to-trip, get-trip-status). Identificar dónde y reemplazar mensaje.

    Liberado el 21/5/2026
  • 0
    IdeaOtro

    Pricing page: claridad sobre la necesidad combinada subscription + App Plan

    Cliente Víctor (teo-18af) reportó 2026-05-21 que la pagina de precios genera la lectura engañosa de que pagando solo USD 15/mes (BASIC) tenes la app. La realidad es que necesitas ambos: App Plan (one-time 399/699/999) + suscripción mensual (15/30/70). En su lectura: "crea tu app desde 15 dólares" suena a oferta total, no a un componente del costo. Texto suyo: "deberían decir crea tu app desde 399 dólares y pago por suscripción para su uso". Fix propuesto: 1. En el hero/headline de /precios incluir línea explícita "App Plan (única vez) + suscripción mensual para uso". 2. En cada tier mensual (BASIC/PRO/ENTERPRISE) incluir aviso visible "Requiere App Plan activo" con link al bloque de App Plans. 3. En cada App Plan (STARTER/PRO/FULL) incluir aviso "Requiere suscripción mensual activa para que la app funcione". Nota: hicimos cross-reference notices hoy (commit cd58d673) pero parece que no resuelven la lectura previa del visitante — la lectura inicial sigue siendo "app desde 15 dólares". Repensar el hero copy.

    Liberado el 21/5/2026
  • 0
    IdeaOtro

    Push campaigns: opción Excluir conductores + aviso de perfiles duales en preview

    Cuando un operador envía PushCampaign con targetAudience=ALL_CUSTOMERS, las personas con perfil dual (cliente+conductor, mismo phone) reciben el push en su lado cliente. Confuso para el operador. Anchor: Dtour conv 387181, 2026-05-21. Fix: agregar checkbox Excluir conductores en form + mostrar conteo perfiles duales en preview.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Dashboard delivery: detalle de orden corta info cuando dirección es larga

    En el panel admin, cuadro de detalles de una orden: cuando la dirección del cliente es larga, hay información que se corta y no se ajusta. No se ven códigos de recolección. Reportado por Mario (pide-bd93) — Chatwoot conv 382111, 2026-05-21.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Dashboard delivery: detalle de orden corta info cuando dirección es larga

    En el panel admin, cuadro de detalles de una orden: cuando la dirección del cliente es larga, hay información que se corta y no se ajusta. No se ven códigos de recolección. Reportado por Mario (pide-bd93) — Chatwoot conv 382111, 2026-05-21. Repro: orden con dirección larga → abrir detalles desde dashboard → códigos de recolección no visibles, layout no responsive. Fix esperado: el cuadro de detalles debe ajustar/scrollear el contenido cuando la dirección es larga, sin tapar los códigos de recogida/entrega.

    Liberado el 21/5/2026
  • 0
    BugOtro

    B2B trips: notas del solicitante no llegan al conductor

    Cuando el viaje se solicita por el portal B2B, la nota / comentario (campo Notas) se guarda en el viaje (visible en el portal B2B con texto correcto) pero NO se muestra en la app del conductor cuando recibe la solicitud. Ejemplo: viaje R7JI6Y tiene nota "hola es mensajeria" en portal B2B, pero la pantalla del driver al recibir el viaje no muestra el campo notas. Reportado por taxi-turismo-peru via Chatwoot 2026-05-21.

    Liberado el 21/5/2026
  • 0
    IdeaOtro

    B2B trips: ocultar tarifa al usuario y al conductor

    Cuando un viaje se solicita desde el portal B2B (cuenta Empresa), el cliente reporta que no debería figurar la tarifa ni en la app del pasajero ni en la del conductor. Actualmente sale (ej: S/14,3 en pantalla del pasajero, Ganarás S/112,40 en pantalla del driver). Reportado por taxi-turismo-peru via Chatwoot 2026-05-21.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Android App Links del AndroidManifest generado apuntan a cabgo.app y no al dominio del tenant

    Balam 2026-05-20 conv 417640: en Play Console > Vínculos directos del app de Balam los Vínculos web asociados son https://cabgo.app/ y https://cabgo.app/auth con activity com.cabgo.cabgo_rider.MainActivity. Eso provoca que: (1) No se verifique la propiedad del dominio cabgo.app desde Balam (porque cabgo.app no le pertenece a Balam), (2) Falle la prueba del archivo JSON de Vínculos de recursos digitales, (3) Falle la verificación de accesibilidad. Bug del generator AndroidManifest.xml de Flutter — debería usar el customDomain del tenant (o un subdominio que SÍ pueda verificar) en lugar del default cabgo.app. Esto afecta a TODOS los tenants con customDomain seteado, no solo Balam.

    Liberado el 21/5/2026
  • 0
    BugOtro

    OFFER mode: rider sube su oferta sobre la base pero el driver no la ve

    Dtour 2026-05-20 conv 387181: en modo OFFER, el rider ve tarifa recomendada S/9 y sube su oferta a S/10 (pantalla Ofertas de conductores muestra S/10,00 estimado). El driver recibe la oferta pero su pantalla muestra Tarifa recomendada S/9,00 y slider en S/9 — la oferta de S/10 del rider no se propaga al driver. Probable causa: el TripAssignment / TripNotification al driver usa fareEstimated/baseFare en lugar del riderOffer cuando éste lo sube. Bug visible en la app del driver — descubrir por qué offerSubmitted no se pasa al payload del driver.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Driver registration se traba después de datos personales (paso 1) sin error visible

    Code1a xkubo 2026-05-20 (conv 389330): un conductor que se registra completa los datos personales (paso 1) y la app NO le permite avanzar al siguiente paso. Sin error visible / sin captura específica todavía. xkubo NO tiene RegistrationFieldConfig custom para target=DRIVER (verificado en BD), solo 3 Drivers ACTIVE en total. Hay que reproducir end-to-end en emulador del lado nuestro (commitido a Code1a) y documentar dónde exactamente se traba. Posibles causas a investigar: phone OTP timeout, validación silenciosa de un campo, edge case con la cuenta de prueba que usó. Cliente está a 24h de cerrar Stripe — bloqueador.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Customer registration: token no válido después de Google Sign-In al completar campos adicionales

    Orlando navan-drivers 2026-05-20 (conv 411976): cuando un pasajero se loguea con Google Sign-In y la app le pide completar campos custom adicionales (RegistrationFieldConfig CUSTOMER required), al intentar guardarlos sale mensaje token no válido. Probable causa: JWT del lado nuestro expira antes de tiempo en el flujo post-Google. Workaround temporal: cerrar app completamente y reabrir/relogin con Google — el nuevo JWT dura suficiente. Fix root: revisar expiración del JWT emitido en el callback de Google Sign-In + considerar refresh automático antes de submit de campos custom.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Country detection: tenant pasajero en Colombia ve prefijo +52 México

    Orlando navan-drivers 2026-05-20: cuando IP de geolocation no se detecta (corporate / VPN / IPv6-only), el endpoint /api/utils/detect-country devolvía DEFAULT_CALLING_CODE=+52 hardcoded, ignorando que el tenant es CO. Pasajeros en Colombia veían +52 en el phone field del registro. Fix: el endpoint ahora acepta ?defaultCountry=XX (commit 30f594ec backend + 33d5ab0a Flutter wire-up + cabgo_ui resetCache).

    Liberado el 21/5/2026
  • 0
    BugOtro

    Notificación de viaje sigue sonando al conductor después de expirar el pedido del pasajero

    Cliente Dtour reporta: cuando un pasajero pide un viaje pero ninguno conductor oferta dentro del tiempo límite, el pedido expira del lado del pasajero (vuelve a inicio) PERO el conductor sigue recibiendo la notificación sonora cuando abre la app después. Probable causa: cola de notificaciones del conductor no se limpia cuando el trip pasa a EXPIRED/CANCELLED. Conv 387181.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Solicitud de viaje sin conductores en zona no queda en estado SEARCHING

    Cliente reporta v1.0.65: cuando un pasajero pide un viaje y no hay conductores disponibles en la zona, la app muestra 'No hay conductores en línea en este momento' pero el trip no queda en estado SEARCHING para ser tomado cuando un conductor aparezca. Conv 412402.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Bottom nav muestra 'Taxi' en vez de respetar driverRoleLabel del tenant

    Cliente reporta v1.0.65: aunque driverRoleLabel está configurado como 'Soy transportista' y driverRoleIcon como 'local_shipping', el bottom navigation del home del pasajero muestra el ícono y label de 'Taxi'. El override de rol del tenant solo aplica a algunas pantallas, no a todo. Conv 412402.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Registro driver: validación de documentos falsa positiva (check verde pero 'completa los campos requeridos')

    Cliente reporta v1.0.65: en el step de documentos del registro de conductor, los 3 documentos (INE, Licencia, Foto perfil) aparecen con check verde indicando que están cargados, pero el botón muestra 'Completa todos los campos requeridos' en rojo y no permite continuar. Conv 412402.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Registro driver: prefijo +54 duplicado en campo teléfono (no permite continuar)

    Cliente reporta v1.0.65: en el step de registro de conductor, al ingresar el teléfono el prefijo +54 queda duplicado/mal concatenado y el botón Continuar no se activa. Conv 412402.

    Liberado el 21/5/2026
  • 0
    BugOtro

    Edit producto desde dashboard NO actualiza imagen subida por afiliado

    Mario (pide-bd93) 2026-05-20. Flujo: el afiliado sube imagen del producto desde la app del negocio. El admin después edita ese producto desde el dashboard (cambios de texto: nombre, descripción, precio). Los cambios de TEXTO se guardan correctamente, pero la imagen NO se actualiza en el dashboard. Persiste la imagen vieja del afiliado o queda en blanco. Investigar: src/app/(dashboard)/dashboard/delivery/businesses/[id]/products/[productId]/page.tsx — endpoint PATCH del producto, ver si el dashboard envía imagen pero el endpoint la ignora, o si dashboard hace cache de imagen vieja. Reproducir con tenant pide-bd93.

    Liberado el 20/5/2026
  • 0
    BugOtro

    Agregar parada adicional — no aparece durante viaje ni en ticket final

    Reportado por Code1a (xkubo) 2026-05-20. Flow: rider arma viaje, agrega parada extra, app la muestra y la marca al inicio pero NO la cobra. Cuando el viaje arranca, la parada no aparece en ninguna pantalla del flujo del conductor. Al finalizar el viaje, en el ticket detallado tampoco figura. Posibles puntos a investigar: (1) Frontend rider: parada agregada al state local pero no se incluye en el payload del request POST /api/mobile/rider/trips/request, campo stops. (2) Backend: endpoint recibe pero no persiste en TripStop / no suma al fare. (3) Driver app: modelo Trip no expone stops o pantalla activeRide no las renderiza. (4) Receipt: /api/mobile/trips/[id]/receipt no incluye stops en el desglose. Reproducir con tenant xkubo.

    Liberado el 20/5/2026
  • 0
    BugApp móvil

    xkubo — paradas intermedias no se renderizan en driver/passenger/history

    Code1a (xkubo) reportó 2026-05-19 que las paradas intermedias (TripStop) no se ven en ninguna de estas pantallas: - Driver waiting (espera arribo cliente) - Cliente app (active trip) - Driver history - Cliente history Verificación BD: la tabla TripStop tiene registros para varios trips recientes de xkubo (id efb29ee1, 35ededa0 con stops=1). El feature server-side funciona, los stops se persisten. El bug es de UI Flutter en las pantallas mencionadas — el código de render solo muestra origin + destination, ignora el array de stops. Fix propuesto: 1. Identificar el widget que renderiza la lista de paradas en cada una de las 4 pantallas. 2. Reemplazar el render hardcoded [origin, destination] por [origin, ...stops, destination]. 3. Validar contra el modelo TripStop (campos: address, lat, lng, stopOrder). Ubicaciones probables: - apps/cabgo/lib/features/driver/rides/screens/ride_request_screen.dart - apps/cabgo/lib/features/rider/ride/screens/active_trip_screen.dart - apps/cabgo/lib/features/{driver,rider}/history/* screens --- _Reported via AI agent: AI agent — Apphive WA_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    Driver register — app permite avanzar el rol "Conductor" cuando isActive=false

    Orlando (navan-drivers) reportó 2026-05-19 que conductores con cuenta deshabilitada (isActive=false en Driver) pueden seguir intentando "activar la cuenta como conductor" desde la app, aun cuando el sistema indica que su registro no está completo. Eso confunde al usuario y a Orlando le complica la triage. Fix propuesto: 1. La app del conductor, en el inicio del flujo de role-picker o activación, debe verificar isActive + accountStatus + campos requeridos completos antes de permitir avanzar. 2. Si está incompleto, mostrar pantalla de "Tu registro está incompleto — completá X, Y, Z" en vez del flujo normal de activación. 3. Si está suspendido por admin (accountStatus=DELETED u otro), mostrar pantalla de "Tu cuenta fue deshabilitada — contactá a soporte". Ubicación: apps/cabgo/lib/features/driver/auth/screens/role_picker_screen.dart o similar. --- _Reported via AI agent: AI agent — Apphive WA_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    Business — bell badge solo se actualiza al entrar a la pestaña Negocios

    BusinessMainShell._pendingCount solo se incrementa via (a) initState, (b) polling 20s mientras la shell esté montada, (c) FCM onMessage SOLO mientras la shell esté montada. Si el dueño del negocio está en home/profile/role-picker (fuera de /business/orders) recibe el FCM pero la campana no badgea hasta que entre a Negocios. Ubicación: apps/cabgo/lib/core/router/app_router.dart línea 1929-1959 (_BusinessMainShellState). Fix propuesto: 1. Mover el listener FCM + polling a un nivel global (provider o GetX/Riverpod singleton) que viva mientras la app esté abierta. 2. La campana lee del singleton globalmente. 3. Persistir last-seen-orderId en SharedPreferences para que sobreviva restarts. Surfaceado por Mario (pide-bd93) 2026-05-19. --- _Reported via AI agent: AI agent — Apphive WA_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    Business — sonido del canal business_orders no se actualiza si el canal fue creado antes

    Android cachea NotificationChannel — una vez creado en el dispositivo, no se puede cambiar el sonido por código. Si una versión vieja de la app creó el canal business_orders sin sonido (o con otro), las versiones nuevas con RawResourceAndroidNotificationSound(new_order_alert) NO sonarán hasta que el usuario reinstale la app o cambie manualmente la config del canal en System Settings. Ubicación: apps/cabgo/lib/main.dart línea 343-355 (registración del canal business_orders). Fix propuesto: 1. Bump del channelId a business_orders_v2 (nuevo canal = nuevo registro con el sonido correcto). 2. Actualizar también el backend (sendNewOrderToBusiness usa channelId: business_orders → business_orders_v2). 3. Documentar en CHANGELOG que tras este update el sonido sí se escucha. Surfaceado por Mario (pide-bd93) 2026-05-19 — la notif de restaurante llega pero no suena en su dispositivo. --- _Reported via AI agent: AI agent — Apphive WA_

    Liberado el 19/5/2026
  • 0
    IdeaApp móvil

    Driver app — mostrar oferta real del pasajero en modo OFFER

    En el modo OFFER (bid&offer), cuando el pasajero oferta un monto (ej. $15), la app del conductor muestra el monto *recomendado por el sistema* (ej. $14.40) como starting point del slider, no la oferta del pasajero. Tenants que quieren un flujo más take-it-or-leave-it esperan ver la oferta del pasajero prominente. Ubicación: apps/cabgo/lib/features/driver/rides/screens/ride_request_screen.dart línea 280-294 (_recommendedFare como base del slider). Fix propuesto: 1. Añadir CompanySettings.driverOfferInitialFare = `RECOMMENDED` | `RIDER_OFFER` (default RECOMMENDED). 2. Backend ya envía `estimatedFare` (rider offer) + `recommendedFare` separados al Firestore. Flutter debe leer la setting y elegir cuál mostrar como base. 3. Exponer la setting via /api/ai-agent/company-config. Surfaceado por taxi-turismo-peru 2026-05-19 (Chatwoot 384865). --- _Reported via AI agent: AI agent — Apphive WA_

    Liberado el 19/5/2026
  • 0
    IdeaPlataforma

    TECH-038 — AI-agent endpoint para bulk deactivate drivers/customers por filtro

    Caso documentado: Orlando 2026-05-19. Tuve que desactivar 531 drivers + 889 customers en navan-drivers que no tenían prefix +57 (eran paraguayos en tenant colombiano). Hoy NO existe endpoint AI-agent para eso — tuve que usar SQL directo. Propuesta: - POST /api/ai-agent/drivers/bulk-deactivate - POST /api/ai-agent/customers/bulk-deactivate Body: { companySlug, filter: { phonePrefix?: "+57" | "!+57", isActive?: bool, createdViaIn?: [...] }, reason? } Returns: { affected: number, sample: [first 10 ids] } Mismo patrón que zone-route-prices/bulk: filter + action. Operación reversible (sólo flag isActive). NO permitir DELETE — siempre soft-deactivate. Doctrina: la migración entre tenants NO se soporta (rompe trip history) — solo desactivar. Ubicación: nuevos archivos en /api/ai-agent/{drivers,customers}/bulk-deactivate/route.ts. Reutilizar patrón authAndResolveCompany + zod schema + prisma.updateMany. --- _Reported via AI agent: AI agent — Cabgo internal_

    Liberado el 19/5/2026
  • 0
    IdeaIntegraciones

    TECH-037 — Auto-cleanup OAuth/SHA al cambiar tenant.firebaseProjectId

    Problema: cuando movemos un tenant de un Firebase project a otro (cabgo-pool-2 → cabgo2-app por ejemplo), el OAuth Android queda huérfano en el proyecto anterior. Google detecta la colisión SHA+package y se rehúsa a auto-crear el OAuth en el proyecto nuevo. Resultado: Google Sign-In roto, descubrimos el bug solo cuando el cliente reclama (Ted-go 2026-05-19). Propuesta: hook que cuando Company.firebaseProjectId cambia (vía /api/ai-agent/company-config o cron de detección de mismatches): 1. release-legacy-sha del proyecto anterior 2. gcp-oauth-list + gcp-oauth-cleanup en proyecto anterior 3. firebase-sha en proyecto nuevo (rebind=true para forzar auto-OAuth) Ubicación: src/app/api/ai-agent/company-config/route.ts PATCH handler — detectar el cambio + disparar el flow. Alternativa o complemento: cron diario que compare AppKeystoreVersion.bundleId vs OAuth clients en pools antiguos del tenant + alerta. --- _Reported via AI agent: AI agent — Cabgo internal_

    Liberado el 19/5/2026
  • 0
    BugIntegraciones

    TECH-036 — gcp-oauth-list scanner devuelve 0 cuando el OAuth existe

    Caso documentado: Ted-go 2026-05-19. SHA registrado en cabgo2-app, OAuth residual existía en cabgo-pool-2 (verificado manualmente en console.cloud.google.com/auth/clients/{id}?project=cabgo-pool-2). Mi llamada GET /api/ai-agent/gcp-oauth-list con projectId=cabgo-pool-2 + packageName=com.cabgo.tedgo devolvió clients=[] y scannedCandidates=0. Esto bloqueó el diagnóstico automático — el usuario tuvo que encontrarlo manualmente. Si nuestro scanner no es confiable, los runbooks de migración entre pools se rompen silenciosamente. Ubicación: src/lib/services/play-console/gcp-oauth-cleanup.js listOAuthClientsByPackage. El walkAndCollect + lookup_key sweep no agarra todos los clientes en algunos proyectos. Fix: investigar y robustecer el scanner para que el resultado iguale lo que se ve manualmente. --- _Reported via AI agent: AI agent — Cabgo internal_

    Liberado el 19/5/2026
  • 0
    BugNotificaciones

    TECH-035 — Emails plantilla deben incluir desglose final del viaje

    Cliente: JP (done). Conv #412915. Los emails de plantilla (confirmación / receipt) que se mandan post-viaje no incluyen los campos del desglose final que SÍ aparecen en la pantalla final de la app. Falta paridad. Fix: actualizar los templates email-trigger para incluir baseFare, distance, time, surcharges, redondeo, total — los mismos campos del ride_completed_screen. --- _Reported via AI agent: AI agent — Dtour WhatsApp_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    TECH-034 — Nota de redondeo de tarifas solo aparece en conductor

    Cliente: JP (done). Conv #412915. La nota explicativa de redondeo de tarifas aparece en la pantalla final del conductor pero falta en la pantalla equivalente del pasajero (liquidación del viaje). Fix: replicar la línea de redondeo en ride_completed_screen rider. --- _Reported via AI agent: AI agent — Dtour WhatsApp_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    TECH-033 — Detalle del viaje difiere entre user y conductor al finalizar

    Cliente: JP (done). Conv #412915. Al finalizar el viaje, el detalle que ve el pasajero no coincide con el que ve el conductor (campos faltantes o distintos). Fix: alinear ride_completed_screen (rider) con la pantalla equivalente del driver para mostrar la misma información. --- _Reported via AI agent: AI agent — Dtour WhatsApp_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    TECH-032 — Campo notas del rider no aparece en la solicitud del conductor

    Cliente: JP (done). Conv #412915. El rider llena el campo notas al solicitar viaje. La nota se guarda en Trip.notes pero NO se muestra en la pantalla de oferta/solicitud que ve el conductor. Fix: incluir notes en la payload de oferta + render en el driver app. --- _Reported via AI agent: AI agent — Dtour WhatsApp_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    TECH-031 — Viaje programado mismo día con 3-4h falla por regla de 2h

    Cliente: JP (done). Conv #412915. El rider intenta agendar un viaje programado para el mismo día con 3-4h de anticipación. El sistema lo rechaza diciendo que debe haber 2 horas de diferencia. La regla de 2h sí debería existir (mínimo lead time) pero está fallando incluso cuando hay más de 2h. Fix: revisar la validación de scheduledFor — probable bug de comparación con TZ o tipo de fecha. --- _Reported via AI agent: AI agent — Dtour WhatsApp_

    Liberado el 19/5/2026
  • 0
    IdeaApp móvil

    TECH-030 — Formato hora 12h AM/PM (en lugar de 24h)

    Cliente: Ichiro Higuchi (rapidin-peru-). Conv #396354. Pide que las horas se muestren en formato 12h con AM/PM. Ahora aparecen en 24h. Fix: pasar todos los formateadores de hora a 12h con AM/PM. Idealmente respetar el locale del device pero forzar 12h para los apps en Peru por preferencia local. --- _Reported via AI agent: AI agent — Rapidin WhatsApp_

    Liberado el 19/5/2026
  • 0
    BugApp móvil

    TECH-029 — Hora de recojo cambia entre oferta y aceptación (UTC vs local)

    Cliente: Ichiro Higuchi (rapidin-peru-). Conv #396354. Mensaje de oportunidad Delivery muestra 21:23. Al aceptar el pedido cambia a 02:23. El delta de 5h coincide con UTC ↔ Lima (UTC-5). Una pantalla usa hora local, otra muestra UTC sin convertir. Fix: unificar a hora local (companySettings.timezone) en ambas pantallas: mensaje de oferta y vista de pedido aceptado. --- _Reported via AI agent: AI agent — Rapidin WhatsApp_

    Liberado el 19/5/2026
  • 0
    BugPagos

    TECH-028 — Ganancia conductor suma pagos Yape/Plin/efectivo cobrados directo

    Cliente: Ichiro Higuchi (rapidin-peru-). Conv #396354. En el dashboard / app conductor, la ganancia acumulada suma viajes/deliveries cuyo pago se hace por Yape, Plin o efectivo (que el conductor cobra directo al cliente, sin pasar por la plataforma). Esos no deberían sumarse porque el conductor ya recibió ese dinero al hacer entrega. Caso documentado: viaje desde módulo negocio, pago Yape, ganancia se sumó. Fix: en el calculator de earnings, excluir TripPayment.provider o paymentMethod cuando es cash/yape/plin/otro no-platform. Verificación: el log de earnings del driver no debería incrementar para esos métodos. --- _Reported via AI agent: AI agent — Rapidin WhatsApp_

    Liberado el 19/5/2026
  • 0
    IdeaOtro

    Notificación web cuando un pasajero solicita cambio de perfil/nombre

    Cuando un pasajero solicita un cambio de perfil (nombre, foto, etc.) la solicitud llega al panel admin para aprobación, pero hoy NO dispara notificación al admin. El operador tiene que entrar al panel a chequear manualmente. Pedido: que llegue una notificación al dashboard web (badge / toast / email) cuando hay un cambio pendiente, indicando qué pasajero solicita qué cambio, para que el admin pueda actuar más rápido. Fuente: Dtour Taxi App (Bryan), conv https://chat.apphive.io/app/accounts/1/conversations/387181 --- _Reported via AI agent: AI agent — Dtour WhatsApp_

    Liberado el 19/5/2026
  • 0
    IdeaOtro

    Retención fiscal ISR + IVA en perfil de negocio y conductor (MX)

    Solicita poder configurar retenciones fiscales ISR + IVA en los módulos de perfil tanto de negocio como de conductor para el mercado mexicano. Funcionamiento esperado: campos editables (en blanco) para %ISR y %IVA. El sistema aplica esos % como deducción/retención sobre el ganado del conductor/negocio (similar a una comisión adicional). El operador retiene y paga a Hacienda. Contexto urgente: lo requiere para una cita con el gobierno del Estado (capacidad de recaudación fiscal a cambio de apoyo). Fuente: Balam (afiliacionbalam@gmail.com), conv https://chat.apphive.io/app/accounts/1/conversations/417640 --- _Reported via AI agent: AI agent — Balam WhatsApp_

    Liberado el 20/5/2026
  • 0
    IdeaOtro

    Flujo de recarga manual conductor con aprobación admin (SIMPE/transferencia/depósito)

    En sistemas anteriores (ej: Redy CR), los conductores podían recargar su billetera enviando comprobante de SIMPE/transferencia/depósito desde la app conductor, y el admin lo veía pendiente en el dashboard para aprobar/rechazar. En Cabgo actualmente: se muestran las instrucciones de depósito al conductor (depositInstructionsText) pero NO hay flujo para que el conductor suba el comprobante en la app, NI un panel de admin para ver pending y aprobar/rechazar. Cuando el conductor hace el SIMPE, queda colgado — el admin no sabe que pasó y la billetera no se actualiza. Solicitado: (a) pantalla de recarga manual en app conductor con upload de foto/comprobante, (b) sección en dashboard admin de Recargas Pendientes con botones Aprobar/Rechazar, (c) actualización automática del balance al aprobar.

    Liberado el 20/5/2026
  • 0
    BugOtro

    Toggle de propinas para modo pasajero separado del toggle delivery

    Hoy el dashboard tiene un toggle único en Ajustes → Delivery → Propinas que controla SOLO las propinas en pedidos delivery. Pero las propinas en modo pasajero (ride-hailing transporte) salen igual aunque el toggle esté deshabilitado, porque no hay un toggle separado para transporte. Necesitamos: (a) un toggle independiente para propinas en modo pasajero, o (b) que el toggle existente afecte ambos modos. Reportado por Victor (TEO) Perú — allá no hay costumbre de dar propinas en taxis y la opción confunde a sus pasajeros.

    Liberado el 11/5/2026
  • 0
    BugDashboard

    Reactivar negocio suspendido devuelve error

    Bug reportado por Balam: suspendio un negocio por accidente durante pruebas, al intentar reactivarlo muestra error y no se puede reactivar. Bug en endpoint admin business toggle status. --- _Reported via AI agent: AI agent — Balam 417640_

    Liberado el 11/5/2026
  • 0
    BugDelivery

    Repartidor no puede rechazar oportunidad una vez recibida (efectivo PRE_TRIP)

    Bug reportado por Balam: en escenario Delivery con Modo de efectivo = Pago previo al negocio, cuando el REPARTIDOR recibe la oportunidad NO hay forma de rechazarla. Una vez la recibe, ya no puede salir del flow. Bug UX critico en mobile rider/driver. --- _Reported via AI agent: AI agent — Balam 417640_

    Liberado el 11/5/2026
  • 0
    IdeaDelivery

    Publicar/ocultar negocio del usuario (visibility toggle)

    Feature request de Balam: poder ocultar un negocio del listado público para el usuario (cliente) cuando aún no esta listo para vender, no tiene menú cargado, o solo requiere repartidores sin recibir pedidos. Toggle de visibilidad por negocio desde dashboard admin. --- _Reported via AI agent: AI agent — Balam 417640_

    Liberado el 11/5/2026
  • 0
    IdeaDelivery

    Multi-pedido por repartidor en delivery (asignar hasta 3 pedidos cercanos)

    Feature request de Victor (teo-154a): para emprendimientos chicos con 1 solo repartidor, el negocio debería poder asignar hasta 3 pedidos pequeños y cercanos al mismo repartidor para que haga la entrega en una sola corrida. Beneficia operadores delivery con poca flota. --- _Reported via AI agent: AI agent — Victor TEO_

    Liberado el 20/5/2026
  • 0
    IdeaDashboard

    Programa de referidos por GRUPO — comisión recurrente del grupo invitado

    Solicitado por Orlando (navan-drivers). El programa actual es 1-a-1 (referrer recibe bono único cuando referee completa N viajes). Orlando quiere referidos tipo AGENTE/MLM: un líder invita a un grupo de conductores y recibe comisión recurrente sobre los viajes de TODO su grupo, para pagarles a los líderes por traer y mantener conductores activos. Diferencia clave vs programa actual: - Hoy: bono único al referrer - Pedido: % recurrente del payout/cancellation/commission de cada viaje del referido, indefinido en tiempo (o por X meses) UI necesaria: - Vista "Mi grupo" en la app del líder con conductores invitados + ganancia acumulada - Configuración: % de comisión por viaje del grupo, plazo (life-time vs N meses), target (wallet líder) Caso de uso real: Orlando reportó que los líderes de grupos de conductores quieren cobrar por traer y motivar a sus conductores. Modelo similar al usado por DiDi PRO en Latinoamérica. --- _Reported via AI agent: AI agent — Orlando via Chatwoot 411976_

    Liberado el 20/5/2026
  • 0
    IdeaOtro

    Horarios de operación tenant para apps de taxi/delivery

    Permitir al admin de cada tenant definir horarios de operación de la app. Ejemplos de uso: - Cerrar automáticamente solicitudes fuera de un rango horario (ej: 6am-11pm) - Modo libre 24/7 - Modo solo dentro de horario Reportado por Gercel (gercel-drive) que opera en MX. Algunos clientes pasados de copas piden servicio de madrugada y quiere poder configurar si la app acepta o no en esa franja. Workaround actual: conductores se desconectan manualmente vía toggle ONLINE/OFFLINE — funciona pero falta control admin. Afecta también a delivery (no solo taxi). --- _Reported via AI agent: AI agent — Gercel WhatsApp #405834_

    Liberado el 15/5/2026
  • 0
    BugPlataforma

    problemas en compilacion

    estoy tratando de compilar pero me da problema de compilacion.

    Liberado el 8/5/2026
  • 0
    BugDelivery

    ACCESO COMO CLIENTE

    AL ACCEDER COMO CLIENTE EXISTEN DOS CATEGORIAS 1 SOY PASAJERO 2 SOY CONDUCTOR. DEBERIA ACCEDER DIRECTAMENTE Y VISUALIZAR LOS RESTAURANTES ACTIVOS.

    Liberado el 8/5/2026
  • 0
    BugDelivery

    falla el codigo a la hora de entregar

    cuando introduzco el codigo del cliente para marcarlo como entregando aparece como codigo incorrecto

    Liberado el 7/5/2026
  • 0
    BugApp móvil

    Es sobre el mapa de app movil

    App pasajero, no se visualiza el ICONO DEL AUTO App conductor, se visualiza el icono del auto NOSE DESPLAZA NI SE MUEVE EN SU TRAYECTORIA

    Liberado el 27/4/2026
  • 0
    BugApp móvil

    No salen lo viajes que tiene cliente

    Adjunto pantallas con la información en cada una, solo metendiose en centro de viajes sale la cantidad de viajes , también la necesidad de poder cancelar un viaje ya aceptado

    Liberado el 27/4/2026

¿No ves tu idea en el roadmap?

Proponla o reporta un bug desde tu cuenta del dashboard y entrará al proceso de revisión.