Mise à niveau node-pty de DeepSeek Harness : tests Mac

Le changement annoncé concerne la couche qui fournit un pseudo-terminal à l’application. Le dépôt officiel de DeepSeek Harness permet de vérifier le contexte du projet et les versions publiées, tandis que le dépôt amont de node-pty décrit cette bibliothèque comme une liaison Node.js vers des pseudo-terminaux. Elle sert notamment à lancer un shell, recevoir les données produites par le processus et transmettre des entrées ou des commandes de redimensionnement.

Pour votre décision, cette distinction est importante :

• une dépendance PTY peut influencer le lancement du shell et le transport des caractères ;
• elle ne garantit pas la disponibilité du réseau entre votre navigateur et le Mac ;
• elle ne contrôle pas seule le temps de réponse du modèle ;
• elle ne prouve pas qu’un processus enfant survivra à une coupure ;
• elle ne remplace pas une vérification du code de sortie après annulation.

Le mot « amélioration » doit donc rester attaché à son périmètre. Le journal de rc.7 confirme l’intention de compatibilité, mais ne détaille pas une matrice complète des versions de macOS, des architectures Apple Silicon, des shells ou des commandes interactives couvertes. Vous ne devez pas transformer cette information en conclusion du type « Bash est désormais stable ».

Le projet node-pty publie lui-même des versions bêta et des correctifs successifs. La page officielle des versions node-pty 1.2 beta montre que les changements peuvent toucher des zones différentes selon la plateforme, y compris la gestion de descripteurs sur macOS dans certaines versions amont. Cela justifie une validation par scénario plutôt qu’une simple installation suivie d’un test manuel rapide.

Ne commencez pas par changer simultanément DeepSeek Harness, Node.js, le shell et les paramètres réseau. Vous perdriez la cause possible d’une amélioration ou d’une régression.

Avant l’upgrade, créez une fiche de référence contenant :

1. la version exacte de DeepSeek Harness ;
2. la version node-pty effectivement résolue dans l’arbre de dépendances ;
3. la version de macOS et l’architecture du Mac ;
4. le shell réellement lancé, par exemple Bash ;
5. le répertoire de travail ;
6. la commande exacte et ses paramètres ;
7. le code de sortie observé ;
8. l’état du processus après annulation ou coupure ;
9. les journaux de l’interface et du service distant ;
10. l’heure de début et de fin de chaque essai.

Utilisez le même dépôt, le même état Git et les mêmes variables d’environnement pour l’ancienne version et rc.7. Si vous testez un projet audio, vidéo ou de design, choisissez une opération qui ressemble à votre usage réel : génération de fichiers, traitement d’images, export, compilation d’un outil de rendu ou vérification automatisée d’un projet.

Si l’environnement distant n’est pas encore figé, notez aussi la méthode d’accès, les droits d’écriture et le répertoire de travail par défaut. La page d’accueil de CALMVPS consacrée aux environnements Mac distants peut servir de point de référence pour distinguer la machine utilisée, le mode d’accès et le périmètre de l’environnement avant de comparer deux versions logicielles. Pour un pilote exécuté sur une machine distante dédiée, consignez également la région d’accès et les conditions de livraison dans une fiche séparée ; une page de mise à disposition d’un Mac distant pour un pilote technique peut aider à identifier cette variable d’infrastructure, sans constituer une preuve de compatibilité logicielle.

Attention : une commande qui affiche « terminé » dans l’interface n’est pas une preuve suffisante. Enregistrez aussi le code de sortie et vérifiez qu’aucun processus enfant ne continue à écrire dans le répertoire de travail.

Le premier test doit être court, déterministe et interactif. Son objectif n’est pas de mesurer une performance générale. Il sert à vérifier que le terminal reçoit une entrée, renvoie l’écho attendu, transmet une sortie continue et signale correctement la fin de la commande.

Vous pouvez procéder ainsi :

1. ouvrez une session DeepSeek Harness sur le Mac ;
2. confirmez le répertoire courant avec une commande sans effet de bord ;
3. lancez une commande Bash qui écrit plusieurs lignes séparées par une courte attente ;
4. envoyez ensuite une entrée simple, comme une nouvelle commande ou une interruption contrôlée ;
5. vérifiez que l’entrée apparaît au bon endroit ;
6. contrôlez la dernière ligne et le code de sortie ;
7. répétez le test avec une sortie contenant des caractères accentués, des chemins longs et des lignes de journal.

Surveillez trois symptômes distincts. Une entrée qui n’apparaît pas peut signaler un problème de transmission ou de mode interactif. Une sortie qui arrive uniquement à la fin peut venir de la mise en tampon de la commande, du terminal ou de la couche d’affichage. Une commande terminée mais affichée comme active peut indiquer que le signal de fin n’est pas correctement propagé à l’interface.

Ne concluez pas à partir d’une seule commande echo. Le test utile comporte une entrée, plusieurs événements de sortie et une fin observable. Pour les tâches de développement, ajoutez une commande Bash qui retourne explicitement un code d’erreur, puis vérifiez que DeepSeek Harness ne confond pas « processus terminé » et « tâche réussie ».

Le comportement doit aussi être observé avec les API de processus réellement utilisées par l’environnement. La documentation officielle de Node.js sur les processus enfants rappelle que le lancement, les flux de sortie, les signaux et le code de sortie correspondent à des événements distincts. Une interface qui affiche une erreur de transport ne permet donc pas, à elle seule, de conclure que le processus a échoué.

Une compilation lente n’est pas forcément un problème de node-pty. Vous devez séparer trois chaînes :

• la production réelle de sortie par le processus ;
• le transport et l’affichage de cette sortie ;
• l’attente du modèle ou de l’orchestrateur avant une nouvelle action.

Lancez une compilation représentative, mais ajoutez un repère de progression compréhensible. Lorsque la sortie semble figée, vérifiez directement sur le Mac si le processus consomme encore du processeur, écrit des fichiers ou ouvre des sous-processus. L’interface seule ne permet pas de distinguer un affichage bloqué d’une compilation réellement suspendue.

Le dépôt amont de node-pty expose des événements de données, d’arrêt et de redimensionnement. Ces capacités rendent le test possible, mais elles ne définissent pas le comportement complet de DeepSeek Harness après une coupure ou une annulation. La documentation officielle des événements node-pty doit donc être lue comme une description de l’interface technique, non comme une garantie de récupération des tâches.

Pour un projet vidéo, vous pouvez surveiller la création progressive de fichiers intermédiaires. Pour un projet audio, vérifiez qu’un rendu interrompu ne laisse pas un fichier final marqué comme valide. Pour le design, comparez l’état des ressources exportées plutôt que de vous fier à la dernière ligne visible dans le terminal.

Ne mesurez pas uniquement le temps total. Notez où apparaît le premier blocage : avant le lancement, pendant le flux de sortie, au moment de l’annulation ou après la fin du processus. Cette position vous aide à distinguer un changement de terminal d’un ralentissement lié à l’outil lancé ou à l’orchestration.

Les programmes interactifs sont utiles pour révéler les limites du terminal, mais une liste exhaustive de fonctionnalités ne vous aidera pas à décider. Choisissez une ou deux commandes dont votre flux dépend réellement : assistant de configuration, outil de contrôle de version avec invite, programme de surveillance ou utilitaire nécessitant une confirmation.

Pour chaque programme, vérifiez :

• la taille initiale du terminal ;
• le comportement après redimensionnement de la fenêtre ;
• l’envoi d’une touche de contrôle ;
• l’affichage d’une invite ;
• la validation ou l’annulation ;
• la sortie du programme ;
• l’état du processus après la sortie.

La taille du terminal doit être testée dans le contexte de votre interface. Une application peut recevoir une nouvelle dimension sans que son rendu soit immédiatement correct. Ce point est particulièrement visible dans les outils affichant des tableaux, des barres de progression ou des interfaces plein écran.

Les séquences de contrôle doivent être testées avec prudence. Une interruption envoyée à une tâche peut être traitée par le shell, par l’application interactive ou par un processus enfant. Vous devez donc observer le processus qui reçoit réellement le signal et vérifier le résultat dans le répertoire de travail.

Si le programme échoue, conservez un environnement minimal : version du shell, commande exacte, variables nécessaires, dimensions initiales, séquence d’entrée et journal brut. Ne masquez pas l’échec en ajoutant plusieurs réglages à la fois. Un petit cas reproductible est plus utile qu’une session complète impossible à comparer.

Sur un Mac distant, quatre états peuvent diverger :

1. le navigateur peut être déconnecté ;
2. le canal de communication peut être fermé ;
3. le pseudo-terminal peut encore exister ;
4. le processus enfant peut continuer ou être arrêté.

Vous devez donc provoquer une coupure contrôlée, puis vérifier chaque état séparément. Lancez une tâche dont la progression laisse une trace vérifiable dans un fichier de travail. Coupez ensuite le réseau ou fermez la session distante. Après reconnexion, contrôlez l’affichage, la possibilité d’envoyer une entrée, l’état du fichier et l’existence du processus.

Une reconnexion qui restitue quelques lignes ne signifie pas que la session est pleinement récupérable. Testez aussi une commande d’inspection et une annulation. Si l’interface indique que la tâche est active alors que le processus n’existe plus, vous avez un problème d’état. Si le processus continue mais que l’interface ne permet plus de le contrôler, vous avez un risque opérationnel différent.

Pour l’exploitation quotidienne, séparez le journal du navigateur, le journal du service et les traces présentes sur le Mac. Cette séparation permet de savoir si la perte concerne uniquement la vue, le canal de transport ou le processus. Elle évite également de relancer une tâche déjà active et de produire deux résultats concurrents. Si vous devez ensuite vérifier les conditions de connexion d’un environnement distant, utilisez une documentation d’infrastructure générale comme référence, sans l’utiliser comme preuve de compatibilité logicielle.

Un scénario parallèle doit rester limité à quelques tâches représentatives. Le nombre exact de sessions supportables dépend de votre Mac, de la charge, de la configuration et des tâches lancées. Il ne faut donc pas inventer un seuil universel.

Exécutez des commandes différentes dans des répertoires distincts. Attribuez à chaque tâche un identifiant visible dans la sortie et dans les fichiers produits. Puis vérifiez :

• qu’une sortie n’apparaît pas dans la mauvaise session ;
• qu’une annulation ne termine pas une autre tâche ;
• que chaque répertoire conserve le bon état Git ;
• que les fichiers temporaires restent associés au bon travail ;
• qu’une reconnexion ne mélange pas les historiques ;
• que les erreurs sont attribuées à la bonne commande.

N’en déduisez pas que la réussite de deux tâches garantit la stabilité d’une charge plus importante. Le but de cette étape est de détecter les erreurs d’isolation suffisamment tôt, avant qu’elles ne touchent des tâches de production.

La bonne décision ne repose pas sur une impression générale. Utilisez la même grille pour l’ancienne version et v0.1.0-rc.7.

Avant toute extension, conservez les journaux et notez le système, la date, la version de DeepSeek Harness, la version node-pty, le shell et la commande. Une version candidate peut encore recevoir des changements de compatibilité. La mise à niveau d’une dépendance native ne doit pas, à elle seule, déclencher une modification d’achat, une extension du parc ou un basculement de toutes les équipes.

Si vous devez exécuter le pilote sur un Mac distant fourni à votre équipe, ajoutez à la fiche de comparaison la méthode de livraison, les droits d’écriture, le shell disponible et la procédure de récupération après coupure. Consignez séparément les versions effectivement installées et les résultats des commandes afin de ne pas mélanger un défaut logiciel avec une différence d’environnement.

La mise à niveau node-pty supprime-t-elle les ralentissements de Bash ?

Pas nécessairement. La version v0.1.0-rc.7 indique une mise à niveau de node-pty 1.2 beta destinée à améliorer la compatibilité des pseudo-terminaux. Elle ne fournit pas de garantie générale sur la latence de Bash, le débit des longues sorties ou les attentes du modèle. Vous devez donc comparer les mêmes commandes avant et après l’upgrade, dans le même environnement et avec les mêmes journaux.

Faut-il modifier la configuration d’un terminal DeepSeek Harness sur Mac distant ?

Commencez par ne rien modifier. Vérifiez d’abord la version de DeepSeek Harness, la version node-pty réellement chargée, le shell utilisé, le répertoire de travail et les variables d’environnement. Une reconfiguration prématurée rend la comparaison moins fiable. Ne changez les paramètres de reconnexion, de taille du terminal ou de lancement que si un test reproductible révèle un défaut précis.

Quelles tâches faut-il rejouer après l’installation de rc.7 ?

Rejouez au minimum une commande interactive Bash, une commande produisant une sortie continue, une compilation représentative, une annulation explicite, une reconnexion après coupure et deux tâches parallèles. Pour chaque essai, conservez la commande, le code de sortie, les journaux, l’état du processus enfant et le comportement de l’interface. Les tâches audio, vidéo et design sont utiles si elles représentent votre activité réelle.

Une coupure du terminal distant arrête-t-elle le processus en cours ?

Non, vous ne pouvez pas le déduire de la seule disparition de l’interface. Une coupure du navigateur ou du réseau peut laisser le pseudo-terminal actif, mais elle peut aussi interrompre la session ou empêcher sa récupération. Après reconnexion, vérifiez la sortie reçue, la possibilité d’envoyer une entrée et l’existence réelle du processus avec un contrôle séparé. Contrôlez également les fichiers produits.

Voici la séquence minimale à appliquer avant de laisser rc.7 sortir du pilote :

• [ ] noter les versions et l’environnement avant modification ;
• [ ] rejouer une commande Bash interactive ;
• [ ] vérifier l’écho, la sortie progressive et le code de sortie ;
• [ ] lancer une longue compilation ou un rendu représentatif ;
• [ ] distinguer sortie visible, activité du processus et attente du modèle ;
• [ ] envoyer une annulation et vérifier les processus enfants ;
• [ ] tester une commande interactive réellement utilisée par votre équipe ;
• [ ] provoquer une coupure contrôlée ;
• [ ] vérifier sortie, contrôle, fichiers produits et état du processus après reconnexion ;
• [ ] exécuter quelques tâches parallèles avec répertoires isolés ;
• [ ] comparer les mêmes preuves avec l’ancienne version ;
• [ ] classer la version : pilote élargi, pilote limité ou retour arrière.

La mise à niveau node-pty de DeepSeek Harness peut améliorer un point précis de compatibilité, mais elle ne remplace pas votre procédure de validation du terminal. Cette première série vous permet de savoir où se situe réellement le gain : démarrage de Bash, flux de sortie, gestion des signaux, récupération distante ou isolation des sessions.

Si votre environnement actuel repose sur une machine locale saturée, un poste Windows avec accès indirect ou une instance cloud générique, vous rencontrez souvent trois limites concrètes : le matériel n’est pas toujours disponible quand une tâche démarre, la reconnexion dépend de plusieurs couches réseau et la reproduction de l’environnement Mac demande des réglages supplémentaires. Pour des workflows audio, vidéo, design ou compilation Apple, ces écarts compliquent encore la comparaison.

La location d’un Mac via CALMVPS ne supprime pas les tests node-pty et ne convient pas à tous les usages. Un achat local reste préférable pour une charge lourde permanente ou pour les équipes qui doivent contrôler directement les périphériques physiques. En revanche, pour un pilote rc.7, une vérification temporaire ou une capacité distante à activer rapidement, un Mac livré dans un environnement identifiable peut réduire les variables à contrôler. Commencez par la checklist ci-dessus et utilisez les preuves recueillies pour décider si vous avez besoin d’un Mac distant temporaire plutôt que d’une extension immédiate de votre infrastructure.