Refonte Runtime avec Autorité Backend

Que fait Refonte Runtime avec Autorité Backend ?

Refactorisez seulement après avoir pu dire exactement où réside la vérité d'exécution et comment l'UI la lit.

Quand l'utiliser

• L'UI synthétise des graphes, des phases ou des choix de fournisseurs que le backend ne comprend pas.
• Un redémarrage ou une reconnexion modifie l'état d'exécution visible car le frontend a mis l'autorité en cache.
• Des schémas, formats de démarrage ou types de nœuds anciens et nouveaux coexistent dans le chemin d'édition actif.
• L'approbation, la révision ou l'exécution en aval dépend d'une reconstruction uniquement frontend.

PAS pour

• Nettoyage cosmétique visuel sans changement de propriété d'exécution.
• Refontes de composants isolés où le contrat backend est déjà faisant autorité.
• Livraison de nouvelles fonctionnalités métier avant d'avoir supprimé la couture d'autorité partagée.
• Travail de performance backend pur lorsque l'architecture a déjà une source de vérité unique.

Points de décision

flowchart TD
  A[Demande de refonte de workflow] --> B{L'UI peut-elle encore inventer la vérité d'exécution ?}
  B -->|Non| C[Utiliser une compétence de domaine ou UI plus étroite]
  B -->|Oui| D[Inventorier les coutures de commandes, requêtes et événements]
  D --> E{Chaque action utilisateur peut-elle correspondre à une commande, requête ou événement ?}
  E -->|Non| F[Geler le contrat avant le travail fonctionnel]
  E -->|Oui| G[Séparer l'état de projection de l'état possédé par le backend]
  G --> H{Les chemins de compatibilité hérités sont-ils toujours actifs ?}
  H -->|Oui| I[Les déplacer vers des bords de migration ou les supprimer]
  H -->|Non| J[Ajouter des évaluateurs, des requêtes de démarrage sûres pour la relecture et des abonnements aux événements]
  I --> J
  J --> K[Valider la préparation à la reconnexion, à l'approbation et à l'exécution en aval]

Utilisez d'abord ce modèle de routage :

• Si l'UI ne peut pas être décrite comme commande -> transition backend -> requête ou projection d'événement, la couture est encore erronée.
• Si un chemin de "compatibilité temporaire" se trouve dans le chemin chaud, traitez-le comme une dette de refactorisation, pas une fonctionnalité.
• Si un redémarrage ou une reconnexion ne peut pas reconstruire l'état visible à partir de la seule vérité backend, la refactorisation est incomplète.

Méthode de travail

1. Inventorier le cerveau divisé

Trouvez tous les endroits où l'UI :

• génère ou modifie la vérité d'exécution
• invente des phases que le backend ne connaît pas
• simule l'exécution dans des chemins de code actifs
• conserve à la fois les schémas anciens et nouveaux dans le même chemin d'édition
• mélange des niveaux de routage abstraits avec des ID de fournisseur exacts

2. Geler le contrat

Définissez trois classes uniquement :

• Commandes : démarrer, arrêter, approuver, reprendre, modifier
• Requêtes : état de démarrage, charge utile de révision, instantané d'exécution, santé du fournisseur
• Événements : transitions faisant autorité, verdicts d'évaluateurs, état des portes, marqueurs de relecture

Si une action de l'UI ne peut pas être exprimée comme l'un de ces éléments, l'architecture est encore trouble.

3. Normaliser la propriété de l'état

Divisez les stores en :

• état d'entrée du contrat
• état de projection d'instantané backend
• état de mise en page de l'UI

Ne laissez aucun store posséder à la fois la vérité d'exécution et les préoccupations de mise en page.

4. Supprimer les coutures de compatibilité actives

Préférez la suppression au "support des deux pour l'instant".

Suppressions typiques :

• compatibilité de schéma singulier et pluriel dans l'édition active
• simulation navigateur ou démo dans le runtime de bureau actif
• types de nœuds obsolètes dans le chemin principal
• résumés de révision en double
• plusieurs formats de démarrage ou d'importation

5. Ajouter des évaluateurs avant de faire confiance à la refactorisation

Chaque nœud d'implémentation devrait avoir :

• un évaluateur de sortie locale pour la correction
• un évaluateur de préparation en aval pour la sécurité du contrat
• un chemin de redémarrage ou de reconnexion qui se réhydrate à partir de la vérité backend, pas de suppositions frontend

Modes d'échec

Projection se faisant passer pour une autorité

Symptôme : l'UI semble "en lecture seule" mais assemble silencieusement la vérité de phase, de graphe ou de fournisseur localement.

Correctif : déplacez cette logique dans des commandes ou requêtes backend et traitez le frontend comme un projecteur.

Calcification de la couture de compatibilité

Symptôme : "supporter les deux pour l'instant" reste dans le chemin chaud pendant des semaines et devient l'architecture réelle.

Correctif : poussez la compatibilité vers des bords de migration unidirectionnels avec une date de suppression explicite ou supprimez-la maintenant.

Approbation sans inspectabilité

Symptôme : un humain peut approuver un travail qu'il ne peut pas inspecter car la charge utile de révision est partielle ou synthétisée par le frontend.

Correctif : le backend doit émettre la charge utile de révision exacte ; l'UI ne fait que la rendre.

Démarrage hostile à la relecture

Symptôme : le redémarrage de l'application modifie l'état visible ou perd la position des portes parce que le frontend a mis l'autorité en cache.

Correctif : le démarrage doit être une requête contre la vérité backend plus la relecture d'événements, pas une reconstruction du store.

Shibboleth

Si le redémarrage de l'application modifie l'état d'exécution visible sans aucun nouvel événement backend, l'autorité est encore partagée.

Exemple concret

Éditeur de workflow Tauri avec logique de phase détenue par le frontend

Problème :

• Les stores React créaient le graphe, inféraient l'état de phase et normalisaient les niveaux de fournisseurs.
• L'exécution backend utilisait un contrat différent, donc les flux de révision et de redémarrage dérivaient.

Chemin de refactorisation :

1. Inventorier chaque endroit où l'UI inventait la vérité d'exécution.
2. Réduire les interactions d'exécution à des commandes, requêtes et événements.
3. Déplacer la normalisation des fournisseurs et les transitions de phase derrière des commandes backend.
4. Supprimer les unions de format de démarrage du chemin d'édition actif.
5. Ajouter des portes d'évaluateurs pour que le travail en aval ne procède que depuis des sorties validées par le backend.

Condition de succès :

• Au redémarrage, l'UI reconstruit le même état visible à partir de l'instantané backend plus les événements.
• Les écrans d'approbation rendent une charge utile de révision émise par le backend, pas une recomposition React.

Guide de bifurcation

Bifurquez lorsque le travail se sépare proprement :

• Lane de contrat : inventorier les coutures d'autorité partagée et définir commandes, requêtes et événements.
• Lane de suppression : supprimer les couches de compatibilité, les types de nœuds obsolètes et les unions de format de démarrage.
• Lane de vérification : ajouter des portes d'évaluateurs, des tests de relecture et une couverture de redémarrage ou de reconnexion.

Conservez les décisions finales de propriété dans la lane parente afin qu'un seul acteur décide ce que le backend possède réellement.

Portes de qualité

• L'UI ne peut pas fabriquer localement la vérité de graphe, de phase, de fournisseur ou de porte.
• Chaque action utilisateur correspond à une commande, requête ou événement.
• L'état d'exécution survit au redémarrage et à la reconnexion à partir de la seule vérité backend.
• Les charges utiles de révision et d'approbation sont émises par le backend et rendues par l'UI.
• La logique de compatibilité ne vit que sur les bords de migration, pas dans le chemin actif.
• L'exécution en aval s'arrête en cas d'échec du contrat en amont.
• Les ID de fournisseur exacts et les choix de modèles sont visibles à la frontière du contrat.
• Les tests couvrent les chemins de redémarrage, de reconnexion, d'approbation et d'échec des évaluateurs.

Carte de référence

• references/architecture-patterns.md — motifs de contrat de workflow détenu par le backend et séparations de propriété d'état.
• references/windags-lessons.md — leçons concrètes d'une migration d'exécution à autorité partagée réelle.