Contexto obligatorio: PLAN_STELLAR.md, PLAN_XAMAN.md (invariante I1) y ISSUES_STELLAR.md.
Ola 5 — bloqueada por #3, #13, #18 y los issues de backend y app en micopay-protocol.
♻️ Reescrita el 22/07/2026. Antes era el cliente de LOBSTR; ahora la billetera es la app de MicoPay.
Por qué cambió
LOBSTR era de terceros y no expone un API de solicitudes de firma. La decisión de producto es usar la app de MicoPay como billetera de Stellar: se controlan los dos extremos, y a medio plazo — cuando MicoPay sume XRPL — sustituye también a Xaman y el operador deja de tener dos apps.
Problema
Con el contrato definido (#3), los endpoints en micopay/backend y la bandeja de firma en micopay/frontend, falta la mitad de escritorio: el cliente HTTP, los ajustes y el cableado en los flujos.
Por qué importa
Es lo que completa la billetera dual y elimina la asimetría de seguridad: hoy el operador firma XRPL desde el teléfono con Xaman, pero tendría que teclear un seed para Stellar. Con esto, la llave privada no toca el software en ninguna de las dos redes.
Alcance
core/micopay_client.py — réplica de core/xaman_client.py contra los endpoints especificados en #3, incluyendo from_config(). Son ~95 líneas: mismo contrato, otra URL base.
payment_app/ui_payment/settings_dialog.py — sección de MicoPay junto a la de Xaman, con las mismas claves cifradas en AppConfig y su propio botón de "probar conexión".
Cableado en auth_flow.py (registrar el firmante de Stellar en el WalletSession), payment_flow.py y escrow_view.py.
Reutilizar el SignDialog genérico de #18 sin ramificar: si el backend respeta el contrato de #3, el diálogo no necesita saber si habla con Xaman o con MicoPay.
Fuera de alcance
- Endpoints del backend y bandeja de firma en la app — viven en
micopay-protocol.
- Notificaciones push del lado del escritorio: el escritorio hace polling, igual que con Xaman (decisión D2 de
PLAN_XAMAN.md).
Criterios de aceptación
Pruebas
Unitarias del cliente con backend mockeado; pruebas manuales de pago y escrow documentadas en un comentario, con hashes.
Dependencias
Por qué cambió
LOBSTR era de terceros y no expone un API de solicitudes de firma. La decisión de producto es usar la app de MicoPay como billetera de Stellar: se controlan los dos extremos, y a medio plazo — cuando MicoPay sume XRPL — sustituye también a Xaman y el operador deja de tener dos apps.
Problema
Con el contrato definido (#3), los endpoints en
micopay/backendy la bandeja de firma enmicopay/frontend, falta la mitad de escritorio: el cliente HTTP, los ajustes y el cableado en los flujos.Por qué importa
Es lo que completa la billetera dual y elimina la asimetría de seguridad: hoy el operador firma XRPL desde el teléfono con Xaman, pero tendría que teclear un seed para Stellar. Con esto, la llave privada no toca el software en ninguna de las dos redes.
Alcance
core/micopay_client.py— réplica decore/xaman_client.pycontra los endpoints especificados en #3, incluyendofrom_config(). Son ~95 líneas: mismo contrato, otra URL base.payment_app/ui_payment/settings_dialog.py— sección de MicoPay junto a la de Xaman, con las mismas claves cifradas enAppConfigy su propio botón de "probar conexión".Cableado en
auth_flow.py(registrar el firmante de Stellar en elWalletSession),payment_flow.pyyescrow_view.py.Reutilizar el
SignDialoggenérico de #18 sin ramificar: si el backend respeta el contrato de #3, el diálogo no necesita saber si habla con Xaman o con MicoPay.Fuera de alcance
micopay-protocol.PLAN_XAMAN.md).Criterios de aceptación
SignDialogde [XLM-17] SignDialog genérico y cierre de la Fase X5 #18 funciona con las dos billeteras sin ramificar.Pruebas
Unitarias del cliente con backend mockeado; pruebas manuales de pago y escrow documentadas en un comentario, con hashes.
Dependencias
SignDialoggenérico), y los issues demicopay/backendymicopay/frontenden micopay-protocol.