Picos, PoCs y Nueva Arquitectura

Q: Spike tuvo éxito - ¿podemos fusionar el viernes?

Solo con ADR, feature flag desactivada por defecto, evidencia normal de plantilla PR y sin hacks solo spike restantes en app.config.ts. De lo contrario, programa sprint de PoC.

Q: ¿Quién aprueba la fusión de spike brownfield en repositorio host?

Líder de plataforma nativa + líder de móvil + propietario de CI. Solo aprobación de RN es insuficiente - el binario host se envía a tiendas.

Un recetario para evaluar Expo UI, embed brownfield y flags experimentales de forma segura - ramas con límite de tiempo, criterios de éxito claros y resultados de ADR para que la exploración no se convierta en deuda de producción permanente.

Receta

Tarjeta de referencia rápida - lista para copiar-pegar.

# Bootstrap spike (nunca en main)
git checkout main && git pull --ff-only
git worktree add ../MyApp-spike-ui spike/expo-ui-tabs
cd ../MyApp-spike-ui
EXPO_PACKAGER_PORT=8082 npx expo start

# docs/spikes/TEMPLATE.md - copiar por spike
## Spike: <nombre>
- **Propietario:** @engineer
- **Límite de tiempo:** 3 días (parada fija)
- **Hipótesis:** <qué aprenderemos>
- **Criterios de éxito:** <medible>
- **Fuera de alcance:** fusión de producción, validación de perf, auditoría a11y
- **Resultado:** ADOPT | DEFER | REJECT + enlace a ADR

Ciclo de vida spike
  charter (30 min) -> rama -> límite de tiempo -> demo -> ADR -> eliminar rama
                              |
                    nunca fusionar sin ADR + flags + matriz QA

Cuándo usar esto:

Evaluando Expo UI (interoperabilidad SwiftUI/Jetpack Compose) para una nueva clase de pantalla.
Factibilidad de brownfield embed antes de que el equipo nativo se comprometa con cambios en CI.
Validación de Nueva Arquitectura después de agregar un módulo nativo solo de bridge.
Experimental app.config.ts u APIs de Expo Router marcadas como inestables en docs.
El liderazgo solicita PoC "este sprint" sin criterios de éxito - primero hacer charter.

Cuándo evitar:

Bug de producción - usa rama fix/*, no spike/*.
Patrón ya adoptado (rutas de archivo de Expo Router) - envía en rama de feature con QA normal.
Litigar de nuevo un ADR decidido sin restricciones nuevas - lee docs/adr/ primero.

Ejemplo Práctico A - Spike de Expo UI

Evalúa si los componentes Expo UI pueden reemplazar un chrome de pestaña nativa personalizado para layouts de tablet.

Paso 1 - Charter (antes del código)

## Spike: expo-ui-tablet-tabs
- **Límite de tiempo:** 3 días
- **Hipótesis:** Los primitivos de pestaña de Expo UI reducen PRs nativas para vista dividida de iPad
- **Éxito:** Cambio de pestaña < 100ms en iPad 10ª gen; tipos de TypeScript compilan SDK 57
- **Fallo:** Crash en Android API 26 o requiere edición manual de ios/ fuera de CNG
- **Documento de resultado:** docs/adr/0012-expo-ui-tabs.md

Paso 2 - Rama aislada + flag

// src/shared/config/featureFlags.ts
export const flags = {
  expoUiTabs: __DEV__ && process.env.EXPO_PUBLIC_SPIKE_EXPO_UI === "1",
};

EXPO_PUBLIC_SPIKE_EXPO_UI=1 EXPO_PACKAGER_PORT=8082 npx expo start

Nunca habilites flags de spike en perfil production de EAS
Empareja con Reglas de Navegación y Enrutamiento - un propietario de navigator

Paso 3 - Matriz de validación

Verificación	Comando / acción
Doctor	`npx expo-doctor`
Tipos	`npx tsc --noEmit`
Perf similar a release	`eas build --profile preview` + Flashlight
Layout de tablet	iPad física o tamaños de captura de ASC
Paridad de Android	Dispositivo API 26 - no solo emulador

Paso 4 - ADR de resultado

# ADR 0012: Expo UI para pestañas de tablet - DEFER
- **Razón:** Brechas de paridad de Android; equipo carece de revisor de SwiftUI
- **Revisitar:** SDK 58 o cuando Expo UI llegue a estable en changelog
- **Rama eliminada:** spike/expo-ui-tabs

DEFER es válido - vincula recordatorio de calendario en Seguimiento de Deprecación y EOL
ADOPT requiere plan de rollout de feature flag - Feature Flags para Lanzamiento Seguro

Ejemplo Práctico B - PoC de Embed Brownfield

Prueba que artefacto expo-brownfield se carga en host nativo existente sin Node en host CI.

Paso 1 - Layout de spike de dos repositorios

rn-checkout/          # Repositorio de módulo Expo (rama spike)
  expo-brownfield build -> AAR + XCFramework
host-ios-android/     # Host nativo (rama spike/brownfield-checkout)
  consume artifact v0.0.1-spike.1

# Repositorio RN
npx create-expo-app@latest CheckoutRn --template blank-typescript@sdk-57
npx expo install expo-brownfield
# construir artefactos según docs de expo-brownfield

Sigue Brownfield Basics - primero decisión aislada vs integrada
PoC no se fusiona en host main hasta que CI publique artefactos automáticamente - Brownfield CI/CD

Paso 2 - Criterios de éxito

- [ ] Host lanza pantalla de checkout de RN desde botón nativo
- [ ] Arranque en frío de superficie RN < 2s en Android de rango medio
- [ ] Navegación atrás regresa a nativo sin fuga (Instruments / LeakCanary)
- [ ] Token de auth pasado a través de contrato de bridge v1 - documentar en ADR
- [ ] Sin copia manual de bundle JS en host assets

Paso 3 - Versión de contrato de bridge

// Documentar en ADR - host y RN deben aumentar juntos
export const BRIDGE_CONTRACT_VERSION = "1.0.0-spike";

Relacionado: Autenticación Compartida y Bridges

Ejemplo Práctico C - Validación de Nueva Arquitectura

El módulo de cámara de terceros afirma soporte de NA - valida antes del lanzamiento en tienda.

Paso 1 - Habilitar NA solo en spike

git checkout -b spike/new-arch-camera
npx expo prebuild --clean

// app.config.ts - spike documenta NA explícito (SDK 57 greenfield puede defaultear a true)
export default {
  expo: {
    plugins: ["expo-camera", "expo-build-properties"],
  },
};

Paso 2 - Matriz de compilación (requerida)

npx expo-doctor
eas build --profile preview --platform ios
eas build --profile preview --platform android

Prueba	Criterios de éxito
Abrir cámara	Sin redbox en compilación NA
Tomar foto	URI de archivo devuelto
Fondo / reanudar	Sin crash
Puntuación de Flashlight	Sin regresión vs línea base de Old Arch

Expo Go es inválido para prueba de NA - cliente dev personalizado o vista previa de EAS
Si falla: fila de registro en Seguimiento de Deprecación y EOL; evalúa módulo alterno

Paso 3 - Criterios de fusión si ADOPT

- [ ] ADR: Nueva Arquitectura habilitada en todo el proyecto
- [ ] Todos los módulos nativos compatibles con NA o reemplazados
- [ ] Matriz de producción de eas build en verde
- [ ] 72h sin crashes en canal de preview

Flags Experimentales y Config

Superficie	Patrón spike seguro	Regla de producción
Toggles de spike `EXPO_PUBLIC_*`	`.env.local` solo	Nunca en env de producción de EAS
`experiments` en app config	rama spike	Eliminar o ADR antes de fusionar
API inestable de Expo Router	`spike/*`	Fijar a versión de API documentada
React 19 experimental	Coincidir con plantilla SDK 57	Sin override manual de canary

// No fusiones a main sin ADR
export default {
  expo: {
    experiments: {
      // typedRoutes, reactCompiler, etc. - solo spike hasta estable
    },
  },
};

Lee sección Experimental de changelog de Expo en cada bump de SDK
Lista de Verificación de Reglas de Proyecto Expo - fuente de verdad de config en app.config.ts

Reglas de Gobernanza de Spikes

Regla	Justificación
Máx 5 spikes activos por squad	Dilución de enfoque
Límite de tiempo duro (3-5 días por defecto)	Los spikes se expanden para llenar sprint
Demo en día N - incluso si falla	Forza articulación del aprendizaje
Sin código spike en rama de release	Envenenamiento de cherry-pick
ADR para ADOPT, DEFER, REJECT	Memoria institucional
Eliminar rama después del resultado	Previene fusión accidental meses después

# Después de REJECT - eliminar worktree
git worktree remove ../MyApp-spike-ui
git branch -D spike/expo-ui-tabs

PoC vs Spike vs Piloto de Producción

Tipo	Duración	¿Se envía a usuarios?	Doc
Spike	3-5 días	No	ADR breve
PoC	1-2 sprints	Solo TestFlight interno / pista interna	ADR + plan de prueba
Piloto	1 lanzamiento	Marcado 1-5% producción	QA completo + runbook de reversión

Ruta de promoción: Spike -> ADR -> PoC -> Piloto -> GA - omitir pasos requiere EM + aprobación de plataforma.

FAQs

Spike tuvo éxito - ¿podemos fusionar el viernes?

Solo con ADR, feature flag desactivada por defecto, evidencia normal de plantilla PR y sin hacks solo spike restantes en app.config.ts. De lo contrario, programa sprint de PoC.

¿Quién aprueba la fusión de spike brownfield en repositorio host?

Líder de plataforma nativa + líder de móvil + propietario de CI. Solo aprobación de RN es insuficiente - el binario host se envía a tiendas.

Spike de Nueva Arquitectura falló - ¿bloqueamos SDK 57?

No - documenta plan de reemplazo de módulo. SDK 57 / RN 0.86 aún se envía; el módulo fallido obtiene fila de registro de EOL y cronograma de intercambio.

Relacionado

Brownfield Basics - embed vs rewrite
ADR de Adopción Incremental - patrón strangler
Política de Actualización de SDK - spikes de actualización
Registros de Decisión Arquitectónica - formato ADR
Rebase Interactivo y Worktrees - trabajo spike paralelo
Mejores Prácticas de Gobernanza - resumen de política de spike

Versiones de Stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).

Receta

Tarjeta de referencia rápida - lista para copiar-pegar.

# Bootstrap spike (nunca en main)
git checkout main && git pull --ff-only
git worktree add ../MyApp-spike-ui spike/expo-ui-tabs
cd ../MyApp-spike-ui
EXPO_PACKAGER_PORT=8082 npx expo start

# docs/spikes/TEMPLATE.md - copiar por spike
## Spike: <nombre>
- **Propietario:** @engineer
- **Límite de tiempo:** 3 días (parada fija)
- **Hipótesis:** <qué aprenderemos>
- **Criterios de éxito:** <medible>
- **Fuera de alcance:** fusión de producción, validación de perf, auditoría a11y
- **Resultado:** ADOPT | DEFER | REJECT + enlace a ADR

Ciclo de vida spike
  charter (30 min) -> rama -> límite de tiempo -> demo -> ADR -> eliminar rama
                              |
                    nunca fusionar sin ADR + flags + matriz QA

Cuándo usar esto:

Evaluando Expo UI (interoperabilidad SwiftUI/Jetpack Compose) para una nueva clase de pantalla.
Factibilidad de brownfield embed antes de que el equipo nativo se comprometa con cambios en CI.
Validación de Nueva Arquitectura después de agregar un módulo nativo solo de bridge.
Experimental app.config.ts u APIs de Expo Router marcadas como inestables en docs.
El liderazgo solicita PoC "este sprint" sin criterios de éxito - primero hacer charter.

Cuándo evitar:

Bug de producción - usa rama fix/*, no spike/*.
Patrón ya adoptado (rutas de archivo de Expo Router) - envía en rama de feature con QA normal.
Litigar de nuevo un ADR decidido sin restricciones nuevas - lee docs/adr/ primero.

Ejemplo Práctico A - Spike de Expo UI

Evalúa si los componentes Expo UI pueden reemplazar un chrome de pestaña nativa personalizado para layouts de tablet.

Paso 1 - Charter (antes del código)

## Spike: expo-ui-tablet-tabs
- **Límite de tiempo:** 3 días
- **Hipótesis:** Los primitivos de pestaña de Expo UI reducen PRs nativas para vista dividida de iPad
- **Éxito:** Cambio de pestaña < 100ms en iPad 10ª gen; tipos de TypeScript compilan SDK 57
- **Fallo:** Crash en Android API 26 o requiere edición manual de ios/ fuera de CNG
- **Documento de resultado:** docs/adr/0012-expo-ui-tabs.md

Paso 2 - Rama aislada + flag

// src/shared/config/featureFlags.ts
export const flags = {
  expoUiTabs: __DEV__ && process.env.EXPO_PUBLIC_SPIKE_EXPO_UI === "1",
};

EXPO_PUBLIC_SPIKE_EXPO_UI=1 EXPO_PACKAGER_PORT=8082 npx expo start

Nunca habilites flags de spike en perfil production de EAS
Empareja con Reglas de Navegación y Enrutamiento - un propietario de navigator

Paso 3 - Matriz de validación

Verificación	Comando / acción
Doctor	`npx expo-doctor`
Tipos	`npx tsc --noEmit`
Perf similar a release	`eas build --profile preview` + Flashlight
Layout de tablet	iPad física o tamaños de captura de ASC
Paridad de Android	Dispositivo API 26 - no solo emulador

Paso 4 - ADR de resultado

# ADR 0012: Expo UI para pestañas de tablet - DEFER
- **Razón:** Brechas de paridad de Android; equipo carece de revisor de SwiftUI
- **Revisitar:** SDK 58 o cuando Expo UI llegue a estable en changelog
- **Rama eliminada:** spike/expo-ui-tabs

DEFER es válido - vincula recordatorio de calendario en Seguimiento de Deprecación y EOL
ADOPT requiere plan de rollout de feature flag - Feature Flags para Lanzamiento Seguro

Ejemplo Práctico B - PoC de Embed Brownfield

Prueba que artefacto expo-brownfield se carga en host nativo existente sin Node en host CI.

Paso 1 - Layout de spike de dos repositorios

rn-checkout/          # Repositorio de módulo Expo (rama spike)
  expo-brownfield build -> AAR + XCFramework
host-ios-android/     # Host nativo (rama spike/brownfield-checkout)
  consume artifact v0.0.1-spike.1

# Repositorio RN
npx create-expo-app@latest CheckoutRn --template blank-typescript@sdk-57
npx expo install expo-brownfield
# construir artefactos según docs de expo-brownfield

Sigue Brownfield Basics - primero decisión aislada vs integrada
PoC no se fusiona en host main hasta que CI publique artefactos automáticamente - Brownfield CI/CD

Paso 2 - Criterios de éxito

- [ ] Host lanza pantalla de checkout de RN desde botón nativo
- [ ] Arranque en frío de superficie RN < 2s en Android de rango medio
- [ ] Navegación atrás regresa a nativo sin fuga (Instruments / LeakCanary)
- [ ] Token de auth pasado a través de contrato de bridge v1 - documentar en ADR
- [ ] Sin copia manual de bundle JS en host assets

Paso 3 - Versión de contrato de bridge

// Documentar en ADR - host y RN deben aumentar juntos
export const BRIDGE_CONTRACT_VERSION = "1.0.0-spike";

Relacionado: Autenticación Compartida y Bridges

Ejemplo Práctico C - Validación de Nueva Arquitectura

El módulo de cámara de terceros afirma soporte de NA - valida antes del lanzamiento en tienda.

Paso 1 - Habilitar NA solo en spike

git checkout -b spike/new-arch-camera
npx expo prebuild --clean

// app.config.ts - spike documenta NA explícito (SDK 57 greenfield puede defaultear a true)
export default {
  expo: {
    plugins: ["expo-camera", "expo-build-properties"],
  },
};

Paso 2 - Matriz de compilación (requerida)

npx expo-doctor
eas build --profile preview --platform ios
eas build --profile preview --platform android

Prueba	Criterios de éxito
Abrir cámara	Sin redbox en compilación NA
Tomar foto	URI de archivo devuelto
Fondo / reanudar	Sin crash
Puntuación de Flashlight	Sin regresión vs línea base de Old Arch

Expo Go es inválido para prueba de NA - cliente dev personalizado o vista previa de EAS
Si falla: fila de registro en Seguimiento de Deprecación y EOL; evalúa módulo alterno

Paso 3 - Criterios de fusión si ADOPT

- [ ] ADR: Nueva Arquitectura habilitada en todo el proyecto
- [ ] Todos los módulos nativos compatibles con NA o reemplazados
- [ ] Matriz de producción de eas build en verde
- [ ] 72h sin crashes en canal de preview

Flags Experimentales y Config

Superficie	Patrón spike seguro	Regla de producción
Toggles de spike `EXPO_PUBLIC_*`	`.env.local` solo	Nunca en env de producción de EAS
`experiments` en app config	rama spike	Eliminar o ADR antes de fusionar
API inestable de Expo Router	`spike/*`	Fijar a versión de API documentada
React 19 experimental	Coincidir con plantilla SDK 57	Sin override manual de canary

// No fusiones a main sin ADR
export default {
  expo: {
    experiments: {
      // typedRoutes, reactCompiler, etc. - solo spike hasta estable
    },
  },
};

Lee sección Experimental de changelog de Expo en cada bump de SDK
Lista de Verificación de Reglas de Proyecto Expo - fuente de verdad de config en app.config.ts

Reglas de Gobernanza de Spikes

Regla	Justificación
Máx 5 spikes activos por squad	Dilución de enfoque
Límite de tiempo duro (3-5 días por defecto)	Los spikes se expanden para llenar sprint
Demo en día N - incluso si falla	Forza articulación del aprendizaje
Sin código spike en rama de release	Envenenamiento de cherry-pick
ADR para ADOPT, DEFER, REJECT	Memoria institucional
Eliminar rama después del resultado	Previene fusión accidental meses después

# Después de REJECT - eliminar worktree
git worktree remove ../MyApp-spike-ui
git branch -D spike/expo-ui-tabs

PoC vs Spike vs Piloto de Producción

Tipo	Duración	¿Se envía a usuarios?	Doc
Spike	3-5 días	No	ADR breve
PoC	1-2 sprints	Solo TestFlight interno / pista interna	ADR + plan de prueba
Piloto	1 lanzamiento	Marcado 1-5% producción	QA completo + runbook de reversión

Ruta de promoción: Spike -> ADR -> PoC -> Piloto -> GA - omitir pasos requiere EM + aprobación de plataforma.

FAQs

Spike tuvo éxito - ¿podemos fusionar el viernes?

Solo con ADR, feature flag desactivada por defecto, evidencia normal de plantilla PR y sin hacks solo spike restantes en app.config.ts. De lo contrario, programa sprint de PoC.

¿Quién aprueba la fusión de spike brownfield en repositorio host?

Líder de plataforma nativa + líder de móvil + propietario de CI. Solo aprobación de RN es insuficiente - el binario host se envía a tiendas.

Spike de Nueva Arquitectura falló - ¿bloqueamos SDK 57?

No - documenta plan de reemplazo de módulo. SDK 57 / RN 0.86 aún se envía; el módulo fallido obtiene fila de registro de EOL y cronograma de intercambio.

Relacionado

Brownfield Basics - embed vs rewrite
ADR de Adopción Incremental - patrón strangler
Política de Actualización de SDK - spikes de actualización
Registros de Decisión Arquitectónica - formato ADR
Rebase Interactivo y Worktrees - trabajo spike paralelo
Mejores Prácticas de Gobernanza - resumen de política de spike

Versiones de Stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).

Picos, PoCs y Nueva Arquitectura

Buscar en la documentación

Picos, PoCs y Nueva Arquitectura