Une notification ne devrait pas seulement ouvrir l'app, elle devrait te ramener à la bonne Session

Nous décrivons souvent les notifications comme un problème de livraison : est-ce que l'alerte est arrivée, à quelle vitesse, apparaît-elle sur l'écran verrouillé. Pour le codage IA à distance, ce cadrage est trop superficiel.

Si une notification ne sait faire qu'ouvrir l'app, elle ne ferme pas réellement la boucle de feedback. L'utilisateur doit encore reconstituer la scène lui-même : quelle machine était concernée, quelle session, est-ce que Claude demandait une approbation ou annonçait une fin, et cela appartenait-il à la tâche en cours ou à une autre session laissée en arrière-plan plus tôt ?

Ce n'est ni un problème de copy, ni un problème d'animation. C'est un vrai problème de synchronisation d'état.

Pourquoi c'est pire dans le codage IA

Dans beaucoup d'apps classiques, une notification correspond proprement à un objet unique : un e-mail, un message, un événement calendrier. Une fois touchée, la destination est évidente.

Le codage IA à distance ne fonctionne pas ainsi.

Tu peux avoir trois sessions actives en même temps :

• une qui refactorise un module
• une qui attend des résultats de tests
• une autre bloquée sur une demande d'approbation

Dans ce contexte, "Claude a besoin de toi" n'a pratiquement aucune valeur. Ce qui compte vraiment, c'est :

• quel server a émis la notification
• quelle session l'a déclenchée
• dans quel état se trouve cette session maintenant
• si l'utilisateur regarde déjà cette session

Dès qu'un de ces éléments manque, la notification se dégrade en interruption vague. Elle peut casser la concentration, mais elle n'aide pas à décider de la suite.

Une notification ne rate pas seulement quand elle se perd

Beaucoup de systèmes voient la fiabilité des notifications comme "ne pas perdre le message". Dans un workflow multi-session, il existe un deuxième échec tout aussi grave : la notification arrive, mais elle te renvoie vers le mauvais contexte.

Cet échec est plus subtil qu'une perte complète et souvent plus dangereux.

L'utilisateur croit être revenu au bon endroit, puis continue d'opérer dans la mauvaise session. En codage IA à distance, cela peut vouloir dire :

• répondre à Claude dans le mauvais dépôt
• approuver la mauvaise tâche
• lire l'état d'une session comme s'il appartenait à une autre

Au niveau interaction, cela ressemble à un bug de navigation banal. Au niveau produit, cela casse la confiance dans tout le workflow distant.

Pour qu'une notification soit utile, le contexte doit survivre à toute la chaîne

Une notification utile n'est pas seulement un payload APNs. Elle doit traverser toute la chaîne sans perdre son identité :

1. quand le hook event serveur est créé, il faut savoir quelle tmux_session l'a déclenché
2. quand le server diffuse la notification, il faut inclure session
3. quand le push relay déduplique, il ne peut pas dédupliquer par project seul, sinon différentes sessions vont se supprimer entre elles
4. quand l'app démarre à froid, elle doit remapper l'identité de server contenue dans le push vers le server enregistré localement
5. quand la navigation finale se produit, elle doit revenir dans le bon server puis sélectionner la bonne session, au lieu d'atterrir sur un écran par défaut

Dès qu'une étape retombe sur un "best effort", le comportement final devient instable.

C'est pour cela que les changements liés aux notifications en 1.6.6 semblent répartis entre iOS, Mac, le server et le push relay. En réalité, ils corrigent tous la même chose : transformer une notification, d'un rappel générique, en point d'entrée exécutable vers le bon contexte.