Registros de Decisiones Arquitectónicas

# ADR-NNNN: <Título>
 
- **Estado:** propuesto | aceptado | supersedido por ADR-XXXX
- **Fecha:** YYYY-MM-DD
- **Decisores:** @mobile-lead, @platform
- **Reloj de lanzamiento:** OTA | binario de store | backend | ninguno
 
## Contexto
¿Qué problema y restricciones? (tamaño del equipo, brownfield, cumplimiento)
 
## Decisión
Vamos a <elección> porque <un párrafo>.
 
## Consecuencias
### Positivas
- …
### Negativas
- …
### Reversión / revocación
- OTA: `eas update --roll-back --channel <ch>`
- Store: envía <versión> binaria; marca de feature <nombre> apagada
 
## Alternativas consideradas
| Opción | Rechazada porque |
| --- | --- |
| … | … |

# Disposición del repo
docs/adr/
  0001-ota-vs-store-for-checkout-copy.md
  0002-expo-camera-vs-custom-scanner.md
  README.md   # índice con tabla de estado

# ADR-0007: Copia de error de pago vía OTA
 
- **Estado:** aceptado
- **Fecha:** 2026-03-12
- **Decisores:** @mobile-lead, @pm-checkout
- **Reloj de lanzamiento:** OTA (canal `production`)
 
## Contexto
Soporte necesita un mensaje de declive de tarjeta más claro antes de la campaña del fin de semana.
Sin cambios de API, nativo o `runtimeVersion`. Binario en vivo: `2.4.1` (runtimeVersion `2.4.0`).
 
## Decisión
Envía el cambio de copia con `eas update` a `production` después de las pruebas de QA del canal de staging.
No crees un lanzamiento de store `2.4.2` para un cambio solo de texto.
 
## Consecuencias
### Positivas
- Envío el mismo día; reversión en minutos
- Evita la cola de revisión del store durante la campaña
### Negativas
- Los usuarios en compilaciones antiguas offline fuera del canal pueden no recibir la actualización
### Reversión
`eas update --roll-back --channel production`
ID de actualización conocido y bueno: registrado en el ticket de lanzamiento MOB-4821
 
## Alternativas consideradas
| Opción | Rechazada porque |
| --- | --- |
| Envío de store 2.4.2 | Revisión de 2-5 días para cero beneficio nativo |
| Solo copia impulsada por backend | El pago offline aún necesita cadenas locales |

# ADR-0008: Escaneo de código de barras - expo-camera vs módulo Vision personalizado
 
- **Estado:** aceptado
- **Fecha:** 2026-04-02
- **Decisores:** @mobile-lead, @android-lead, @ios-lead
- **Reloj de lanzamiento:** binario de store (nueva dependencia nativa)
 
## Contexto
La aplicación de almacén necesita escaneo Code 128 a 30 fps en Android de rango medio.
La API de código de barras `expo-camera` cumple con MVP; el envoltorio ML Kit personalizado prometió 2× velocidad.
 
## Decisión
Usa escaneo de código de barras `CameraView` de **expo-camera** para v1.
Revisa el módulo personalizado solo si las métricas de campo muestran >5% de fallo de escaneo en la clase Pixel 6a.
 
## Consecuencias
### Positivas
- El plugin de configuración - la ruta de actualización de Expo SDK se mantiene por Expo
- Un módulo Swift/Kotlin menos para que los junior mantengan
### Negativas
- Puede que no coincida con la latencia del hardware del escáner dedicado
- Aún requiere reconstrucción de **dev client** - no es actualizable por OTA como complemento nativo
### Reversión
Marca de feature `warehouse_scan_v1` apagada; el flujo de entrada manual anterior permanece
 
## Alternativas consideradas
| Opción | Rechazada porque |
| --- | --- |
| TurboModule personalizado - ML Kit | 2 meses de ingeniería de mantenimiento; sin datos de campo aún |
| WebView - escaneo de navegador | Offline pobre; riesgo de política WebView del store |
| Escáner RN de terceros (no mantenido) | Último commit hace 18 meses; RN 0.86 sin probar |

# ADR-0009: Push - Expo Notifications vs SDK de OneSignal
 
- **Estado:** aceptado
- **Fecha:** 2026-05-18
- **Decisores:** @mobile-lead, @growth
- **Reloj de lanzamiento:** binario de store si cambia después
 
## Contexto
Growth quiere push enriquecido A/B; la ingeniería quiere una superficie nativa mínima.
 
## Decisión
**expo-notifications** - herramientas de campaña del lado del servidor para v1.
OneSignal evaluado - aplaza hasta que marketing necesite IAM en la aplicación más allá del alcance del producto.
 
## Consecuencias
### Positivas
- Se alinea con las credenciales de EAS y el flujo de token push de Expo
- Binario nativo más pequeño vs SDK dual
### Negativas
- La segmentación avanzada vive en nuestro backend, no en la interfaz de usuario del proveedor
### Reversión
Mantente en expo-notifications; no hay SDK de proveedor que remover
 
## Alternativas consideradas
| Opción | Rechazada porque |
| --- | --- |
| SDK RN de OneSignal | Dependencia nativa adicional - cableado duplicado FCM/APNs |
| Solo Firebase (sin envoltorio Expo) | Pierda la experiencia unificada de push de Expo para el flujo de trabajo administrado |

# Índice ADR
 
| ID | Título | Estado | Reloj |
| --- | --- | --- | --- |
| 0007 | OTA de copia de pago | aceptado | OTA |
| 0008 | escaneo expo-camera | aceptado | store |
| 0009 | expo-notifications | aceptado | store |
| 0010 | Expo Router (greenfield) | aceptado | - |