[iPoower]

Le 27 octobre, un iPhone physique a échoué à rouvrir Control Vault TEST depuis la même icône après une ouverture en 4G. La cause reste inconnue. Ce changement ajoute uniquement au build Fortress TEST un diagnostic visible de la registration, du contrôleur et de la présence du shell/JS/CSS en cache. Il annonce explicitement que le redémarrage hors ligne reste à vérifier.

Le diagnostic lit CacheStorage via match et n’ouvre, ne réécrit ni ne purge les caches. Les refus synchrones d’API et la vérification bloquée deviennent un état visible sans empêcher l’interface. Aucun changement du schéma métier ou de la cryptographie ; le code source du Service Worker reste celui de la base #26. Hors build TEST, le comportement d’enregistrement existant est conservé.

Candidat, CI et publication TEST

• Tête exacte : f87834b581532de507a1eb3ca7b5b0ce5616c3c8 ; base [TEST · NE PAS FUSIONNER] Rétablir le premier redémarrage hors ligne sur Cloudflare #26 51031e8d1a4b69565bc36830f6ef8efbfd986ca3.
• Pipeline 40493656154 réussi : CodeQL, 355 tests unitaires, 156 parcours navigateurs réussis et 14 ignorés ; 28 scénarios du diagnostic sur quatre profils. Le commit technique testé 875afa73a122be343087e004c0cde907d513a4fd a le même arbre que la tête : 7b9e2d764a83b9b07f690472db24f731e7ea1f5e.
• Artefact 12729646085, ZIP SHA-256 90193aa817dbfe6a50b4ca4a706565ed90eec8bae3a762ca75442d49648b6eea ; manifeste 016e0205134ffe507f0ec12d1fede0eaad31be6d02d9f0e526159561262d506a, 16 fichiers dont _headers.
• Publié par téléversement manuel sur le seul projet cv-drive-test-ipoower, déploiement fe687e19-636f-4bc7-82d0-ef00279c27e5, créé le 27 octobre à 14:43:40 UTC. Domaine unique cv-drive-test-ipoower.pages.dev. Cloudflare ne renseigne pas le commit du téléversement : la provenance vient de l’artefact et des octets observés.
• Audit indépendant dans son harnais #256, SHA 926af6f2b7ef5fe9cf08f31faa10fe9e8eba3cd8, run 40524990609 réussi : manifeste et 15 ressources publiques CV conformes, entêtes de sécurité/cache, SW natif, deux rechargements et fermeture/réouverture sans réseau dans Chromium et WebKit. Le diagnostic est observé avant et après coupure. Les trois routes de démonstration s’affichent. Une sentinelle localStorage fictive est conservée ; ce n’est pas une restauration exhaustive métier.
• Artefact d’audit 12744720186, SHA-256 297fa5ed2911ed65bca2e248828607c303faadb4ab0dbbdf6860f2564f80e5eb.

Preuves contradictoires et limites

Le run 40491973881 sur f8a6143c92e658515590c3dbd030e53642b3a9f6 a réellement enregistré deux échecs du diagnostic natif WebKit (144 réussites, 14 ignorés) avant correction du suivi d’état du contrôleur. Le run ciblé 40493072792 a ensuite réussi 2/2 sur 7855f40a3831c605e9b7030abcdc2dbc6c779f5a, mais ce commit contrevenait à la règle d’un workflow unique (354 tests locaux verts, 1 rouge) ; le workflow supplémentaire a été retiré et seule la CI complète de la tête actuelle vaut pour cette tête.

Le premier audit publié 40524501302 a échoué sur un sélecteur #main h1 absent de la vue Fichiers ; les vues et le diagnostic étaient présents dans les traces. Le harnais a été corrigé sans changer l’application, puis le nouveau run ci-dessus a réussi. Le vérificateur Python verify_fortress_release.py est réussi sur le ZIP local ; son mode HTTP reste en échec 403 sur le manifeste RC, avant d’atteindre CV, dans 40524990590. L’audit HTTP JavaScript est distinct et réussi. Cause du refus inconnue, aucun contournement.

Nouvelle preuve physique, 27 octobre à 17 h 39 : une capture montre le nouveau diagnostic local positif avec le Wi-Fi ; une autre montre l’erreur native Safari en mode Avion sur le domaine TEST. L’ordre chronologique exact et la fermeture forcée ne sont pas filmés. L’échec d’ouverture physique persiste malgré la présence du nouveau diagnostic dans l’écran connecté. Le SHA de l’écran n’est pas directement attesté et l’état du service au moment de l’erreur est inconnu. Aucun correctif de la cause iPhone n’est revendiqué. Les navigateurs attendent le SW prêt ; ils ne prouvent ni le lancement autonome iOS, ni son quota, ni la conservation future des données. Le diagnostic ne contrôle pas tous les fichiers ni les données métier. Aucun compte Google ni sauvegarde/restauration distante réelle n’est validé.

Rollback de code TEST non destructif : ancien déploiement conservé b2d0d0fb-dd91-4ae5-be75-aefab10dfee7, après vérification de compatibilité ; aucune suppression de stockage ou d’historique. Garder en brouillon ; ne pas fusionner ces branches de laboratoire vers main.

Un complément d’audit RC #257 recherche les écarts de démarrage : URL racine/alias et navigateur signalé hors connexion. Il ne modifie pas ce candidat et ne simule pas le lanceur iOS. Les images utilisateur ne sont pas publiées ici.

Comparaison d’outillage #257 terminée : tête d’audit fac4bc6fa3ded5b3e1bc360199c7f804bc141630, run 40546292945. Le job Playwright 1.63.0 reste rouge, avec le même échec WebKit sur une page minimale sans CV ; le job 1.64.1 réussit les contrôles du site publié et les témoins (dont 16 lancements CV sur alias/modes réseau). Les artefacts 12752004105 et 12751633956 conservent les deux résultats. Le workflow global demeure en échec ; cela ne valide pas le téléphone physique. Le défaut d’émulation de l’outil est distinct de l’ouverture réelle qui échoue sur l’iPhone. Aucun changement de ce candidat, de ses dépendances ou de son déploiement n’est effectué par cette comparaison.