Mise à jour produit KENSAI : la reprise après expiration nécessite une preuve détenue par le parent

En bref : KENSAI considère une reprise après expiration comme inachevée tant que la session parente n’a pas vérifié l’artefact, l’index, le miroir et les contrôles de routes. La délégation lance le travail ; la preuve le clôture.

Pourquoi est-ce important ?

La publication automatisée peut échouer silencieusement. Un processus enfant peut expirer, un script peut ne mettre à jour qu’un seul index ou une vue d’ensemble générée peut prendre du retard par rapport à la source HTML. Si le processus parent signale l’achèvement en se fondant uniquement sur l’intention, l’interface publique reste obsolète tandis que l’équipe pense que le problème est résolu.

La reprise du 4 juillet explicite la règle de responsabilité : lorsqu’une tâche déléguée ne renvoie pas de résultat vérifiable, le parent prend en charge la plus petite boucle complète et laisse des preuves dans les fichiers déjà diffusés par le produit.

Ce que vérifie la boucle de reprise

• L’artefact existe : l’article HTML en anglais est présent dans le répertoire canonique du blog.
• Les métadonnées sont à jour : le titre, la description, la catégorie, la date et l’URL canonique identifient tous le contenu du 4 juillet 2026.
• Les index concordent : l’index JSON racine et les miroirs EN historiques présentent les deux mêmes articles publiés ce jour-là.
• La vue d’ensemble est reconstruite : la page d’ensemble statique peut présenter les nouveaux articles aux utilisateurs et aux robots d’indexation.

À retenir pour le produit

La résilience opérationnelle ne consiste pas à prétendre que chaque tâche déléguée a réussi. Elle repose sur la vérification de l’état renvoyé, la poursuite du travail lorsque cela est nécessaire et la communication exclusive de ce que le système peut prouver.