Évaluer la Migration React Native

Produire une décision de migration en lecture seule. Diagnostiquer le produit et le système de livraison ; ne pas exécuter la migration.

Établir la Portée du Produit

Exécuter l'évaluation à partir d'un workspace qui expose autant de bases de code de clients en production que possible. Le checkout actuel n'est pas la preuve qu'il contient le produit entier.

Avant d'évaluer la maturité :

1. Inspecter le repository actuel et chaque racine de workspace disponible pour l'agent.
2. Déduire les plateformes clientes supportées à partir de la documentation produit, CI, configuration de release, manifests du workspace, submodules, et références à des repositories frères.
3. Localiser chaque base de code de client en production, y compris les repositories natifs iOS et Android séparés, les variantes d'app, et tout client web pertinent pour les ressources ou le partage de code proposé.
4. Enregistrer un inventaire des plateformes avec le client, le repository ou le chemin, la preuve d'appartenance au produit, et le statut d'accès.

Quand iOS et Android sont tous deux supportés, inspecter les deux bases de code natives avant de recommander un chemin. Si une base de code reste inaccessible, marquer son indice unknown, déclarer que l'évaluation couvre uniquement les plateformes accessibles, et réduire la confiance en conséquence. Ne pas déduire qu'une plateforme n'est pas supportée simplement parce que son projet est absent du repository actuel.

Portail de portée : chaque client en production supporté est listé, et chaque base de code est accessible, explicitement indisponible, ou confirmée comme n'existant pas.

Portail de Première Réponse

Quand le portail de portée n'a pas été dépassé, la première réponse doit être exactement :

**Question :** Où puis-je accéder à la base de code en production pour chaque plateforme client que ce produit supporte, y compris iOS et Android si les deux existent ?

**Pourquoi c'est important :** Un chemin de migration basé sur une seule plateforme peut manquer des dépendances natives, du comportement du produit, et des contraintes de livraison qui changent la décision.

Après que le portail de portée passe, poser des questions pointues plutôt que de faire une enquête quand la preuve du repository est indisponible.

Si le facteur de migration mesurable est inconnu, la première réponse doit être exactement :

**Question :** Quel problème mesurable de livraison ou métier une migration React Native devrait-elle résoudre ?

**Pourquoi c'est important :** Cela détermine si la migration est pertinente et quels résultats l'évaluation doit tester.

Si le facteur est déjà connu, poser uniquement la question suivante avec le plus grand impact en utilisant la même forme deux lignes. Terminer le tour immédiatement après la question et la raison. Ne pas ajouter de préambule, de questionnaire, de recommandation, ou de guide d'implémentation.

Règles

• Traiter chaque app en production comme une source de vérité, y compris le comportement non documenté.
• Inspecter le code disponible, CI, tests, configuration de release, documents produit, et preuve runtime avant de poser des questions.
• Comparer explicitement iOS et Android quand leur implémentation, comportement, dépendances, livraison, ou roadmap diffèrent.
• Baser les affirmations au niveau du produit uniquement sur des preuves de chaque plateforme supportée, ou qualifier leur couverture de plateforme.
• Étiqueter les affirmations matérielles observed, measured, reported, assumed, ou unknown.
• Recommander à partir de preuves, pas d'un score de maturité agrégé.
• Privilégier la collecte de preuves, pas le brownfield, le greenfield, ou la migration elle-même.
• Posséder la phase de décision. Ne pas appliquer les compétences d'implémentation ou sélectionner Expo par rapport à React Native bare avant que Path A soit acceptée.
• Compter uniquement la valeur marginale de React Native par rapport au système natif actuel.
• Mesurer les agents par le travail accepté et vérifié, pas les tokens, le code généré, ou les pull requests.
• Ne faire aucune affirmation universelle sur la durée, le coût, le partage de code, la productivité des agents, ou le ROI.

Sélectionner le Mode de Preuve

Utiliser l'évaluation soutenue par repository quand le code source ou les artefacts de livraison sont disponibles :

1. Compléter l'inventaire des plateformes et établir quels repositories l'évaluation peut inspecter.
2. Pour chaque base de code mobile accessible, localiser les variantes d'app, CI, tests, configuration de release, enregistrements d'architecture, et documentation produit.
3. Chercher dans chaque base de code native les SDKs, permissions, extensions d'app, stockage, authentification, push, deep links, analytics, expériences, et comportement spécifique à la plateforme.
4. Citer les noms de repository plus les chemins de fichiers et numéros de lignes pour que la preuve reste attribuable quand les bases de code sont séparées.
5. Poser des questions aux stakeholders uniquement pour les emplacements manquants de base de code ou pour les faits produit, organisationnels, et opérationnels que les repositories ne peuvent pas établir.

Utiliser l'évaluation par entrevue quand le repository est indisponible ou la preuve matérielle reste manquante :

1. Commencer par le problème de livraison ou métier mesurable sauf si l'utilisateur l'a déjà fourni.
2. Poser exactement une question qui change la décision par tour.
3. Expliquer en une phrase quel chemin, risque, ou hypothèse la réponse affecte.
4. Contester les réponses vagues ou contradictoires avec une question de suivi plus étroite au lieu de les accepter comme preuve.
5. Enregistrer la réponse, mettre à jour l'état des preuves, et choisir l'inconnu suivant avec le plus grand impact.
6. Arrêter le questionnement quand une autre réponse ne peut pas changer la recommandation, la confiance, ou le checkpoint.

Avant que le portail de preuve ne passe, chaque réponse doit contenir uniquement :

**Question :** [une question]

**Pourquoi c'est important :** [une phrase]

Ne pas inclure de questionnaire, recommandation de chemin, checkpoint, ou guide d'implémentation durant ces tours. Si l'utilisateur fait une pause dans l'entrevue, retourner l'état actuel des preuves et l'inconnu unique avec le plus grand impact sans prétendre que l'évaluation est complète.

Portail de tour d'entrevue : une réponse a été demandée, son impact de décision est explicite, et aucune deuxième question n'apparaît.

1. Collecter les Preuves de Décision

Énoncer la décision, la date limite, l'alternative actuelle, et le facteur mesurable. Une préférence de framework n'est pas un facteur.

Inspecter ces dimensions :

Pour un plan dépendant d'OTA, exiger un propriétaire plus compatibilité runtime, rollout, observabilité, rollback ou republish, et politique d'audit. La disponibilité d'OTA seule n'est pas un bénéfice de migration.

Utiliser un petit noyau de migration qui combine le produit existant et la connaissance native avec l'expertise de migration React Native. Poser uniquement pour les faits manquants qui pourraient changer la décision ; exposer le reste comme hypothèses.

Portail : chaque dimension a une preuve ou un inconnu explicite, et chaque inconnu bloquant le chemin est nommé.

2. Choisir un Chemin

Choisir un résultat et énoncer pourquoi les alternatives perdent.

Traiter Path C comme le modèle opérationnel post-2025 émergent de Callstack, pas un benchmark de l'industrie. L'accès des agents rend le porting comportemental plus viable ; seul un checkpoint mesuré sur ce produit établit la vitesse et la qualité.

Après que Path A soit acceptée, remettre la planification d'implémentation à react-native-brownfield-migration. Ne pas répéter son guide Expo, XCFramework, AAR, ou host-integration.

Portail : un résultat est soutenu par une preuve décisive, les alternatives rejetées ont des raisons, et la confiance reflète la qualité de la preuve.

3. Définir un Checkpoint Représentatif

Utiliser un checkpoint pour Path C et chaque fois qu'une incertitude pourrait invalider le chemin recommandé. Fixer un budget de calendrier et d'effort fixe fourni par l'organisation. Sélectionner deux ou trois flux verticaux :

1. Un flux commun couvrant UI, données, analytics, et navigation.
2. Un flux authentifié et stateful couvrant la persistance, les erreurs, et le comportement de session.
3. La frontière la plus susceptible de réfuter le plan, comme un SDK natif, une tâche en arrière-plan, une API matérielle, comportement offline, extension d'app, exigence d'accessibilité, ou contrainte Android bas de gamme.

Lier chaque flux à des références de code source native, preuve runtime, propriétaires, et scénarios de parité. Ne pas sélectionner uniquement des écrans faciles.

Définir des critères d'acceptation mesurables par rapport au produit existant :

• Le comportement, états, validation, erreurs, analytics, accessibilité, et sortie visuelle correspondent à la référence native.
• Auth, stockage, deep links, push, et frontières natives sélectionnées fonctionnent sur les appareils et versions OS requises.
• Le startup, interaction, mémoire, et comportement de crash respectent les baselines convenus ou les tolérances.
• CI, distribution interne, observabilité, et la lane de release prévue fonctionnent de manière suffisamment fiable pour continuer.
• Chaque flux a une preuve au niveau appareil et une revue indépendante avec contexte clean.
• Path C empaquette et ouvre au moins un flux React Native représentatif dans chaque hôte natif requis.

Exécuter deux passes sur au moins un flux :

1. Pass faithful : préserver le comportement, analytics, accessibilité, états, et cas extrêmes. Enregistrer l'architecture en forme native conservée pour la parité.
2. Pass idiomatic : introduire la composition de composant React, frontières d'état claires, navigation typée, primitives réutilisables, tests appropriés, et performance mesurée. Répéter les vérifications de parité et appareil.

Avant de monter en charge, assigner des propriétaires pour MIGRATION.md, SCREENS.tsv, STATE_AND_STORAGE.tsv, DEPENDENCIES.tsv, EVENTS.tsv, et PARITY_CHECKS.md. Durant l'évaluation, identifier les artefacts manquants plutôt que de créer des inventaires complets sauf demande.

Terminer avec une décision : continuer greenfield, continuer Path C, déplacer le travail complété dans Path A, différer, ou arrêter. Ne pas prolonger le checkpoint simplement parce que son résultat est gênant.

Portail : flux, budget, critères, preuves, propriétaires, et décisions finales sont explicites.

4. Tester l'Économie

Mapper un changement représentatif de ready-for-implementation à verified availability sur les deux plateformes. Capturer deux horloges :

1. Change lead time : commit à un artefact disponible pour une cohorte en production ; séparer la livraison binaire et OTA.
2. Cross-platform feature lead time : ready-for-implementation à verified availability sur iOS et Android.

Compter le retour potentiel de l'implémentation dupliquée supprimée et revue de logique métier, baisse de coordination de parité, mobilité des ingénieurs, et améliorations mesurées de release ou récupération. Garder la vérification des appareils iOS et Android dans le modèle. Garder la convergence web en dehors du cas de base sauf si séparément financée et évaluée.

Compter l'investissement complet : checkpoint, maintenance duelle, modules natifs, formation, deuxième pass idiomatic, tests et automation d'appareil, observabilité, infrastructure de release, propriété de plateforme, cutover, et retraite de surface native.

Ne pas inventer les entrées de payback. Utiliser des plages quand les données fournies sont incertaines. Réviser, différer, ou arrêter quand la vérification et le travail de frontière consomment les économies attendues, les surfaces natives continuent de croître, la maintenance duelle n'a pas de limite de retraite, les agents ajoutent du rework sans débit vérifié, la parité s'améliore sans amélioration de livraison, ou la capacité libérée n'a pas d'usage planifié.

Portail : les bénéfices marginaux et l'investissement complet peuvent être comparés sans traiter la vérification deux-plateforme comme le travail supprimé.

Contrat de Sortie

Utiliser ce contrat uniquement après que le portail de preuve passe ou quand l'utilisateur termine l'entrevue.

Retourner un rapport concis dans cet ordre :

1. Recommandation : résultat, confiance, raison décisive, et frontière de décision.
2. Preuves : inventaire des plateformes, limites de couverture, et résultats matériels avec statut de source et différences de plateforme.
3. Hypothèses et bloqueurs : inconnues ordonnées par impact de décision.
4. Checkpoint : budget, flux, critères, propriétaires, preuves, et décisions finales.
5. Baseline et ROI : entrées mesurées, entrées manquantes, retour compté, investissement complet, et exclusions.
6. Prochaine décision : qui décide quoi, en utilisant quelles preuves, et quand.

Garder la conclusion diagnostique. Si l'exécution vient, énoncer uniquement que l'orchestration, contrats de tâches, prompts, règles de retry, et agents privés sont spécifiques à l'engagement. Ne jamais exposer ou inventer le matériel d'implémentation privé.