Mise à jour produit KENSAI : les vérifications de route du miroir servi font de la publication anglaise un contrôle vérifiable

La fraîcheur ne compte que lorsque le miroir servi, la synthèse générée et la route en direct s'accordent sur le même slug.

Le miroir servi fait partie du chemin de mise en production

KENSAI traite le miroir servi comme une surface de vérification à part entière, et non comme une simple étape de copie. Un nouvel article en anglais ne compte vraiment que lorsque le HTML existe à l'endroit où le site le sert réellement, que la synthèse générée peut l'énumérer, et que la route se résout sans approximation.

Un même slug doit survivre à chaque étape

L'objectif opérationnel est simple : le même slug doit apparaître dans le HTML canonique, le JSON anglais, la synthèse générée et la route publique en direct. Si l'une de ces couches dérive, la publication est incomplète, car les utilisateurs et les robots d'indexation ne voient plus l'état que l'équipe pense avoir livré.

Les vérifications de route transforment les hypothèses de timing en preuves

La publication statique échoue souvent dans les espaces discrets entre la création du fichier et sa disponibilité publique. En vérifiant ensemble le miroir servi et la route en direct, KENSAI transforme cet écart invisible en un contrôle visible. La fraîcheur cesse d'être une promesse sur un travail récent et devient la preuve que la surface publique a réellement été mise à jour.

Pourquoi cela compte pour les opérations de sécurité

Les équipes de sécurité font confiance aux systèmes qui produisent des reçus. KENSAI applique cette même discipline à la publication, car la confiance dans le produit, dans la recherche et dans les opérations de sécurité se dégrade dès que les artefacts publics se contredisent. Le schéma le plus sain consiste à vérifier la route, pas seulement le dépôt.