Journal de bord

Chantiers classés du plus récent au plus ancien. À l'intérieur d'un chantier, entrées les plus récentes en tête.

Publication de la 1.0.3 (2026-08-14)

Première publication depuis la 1.0.2 : elle embarque le lot de sécurité, le toast des retraits SVG (les deux chantiers ci-dessous) et introduit le CHANGELOG.md, rétro-rempli de la 0.2.0 à la 1.0.3 et ajouté aux fichiers du paquet — la fiche #changelog voulait qu'il naisse avec la version qui le mentionne.

Lot de sécurité sans majeure — 22 → 18 vulnérabilités (2026-08-14)

Sur consigne de l'utilisateur, depuis les notes de son tableau de bord GitHub consignées en roadmap le matin même (fiche #audit-devdeps). Exécution et instruction de compatibilité menées par deux agents en parallèle, vérifiées ensuite.

Toast des retraits SVG (2026-08-14)

Trouvé par l'utilisateur pendant la passe de validation du lot ci-dessus : le décompte « N élément(s) retiré(s) » s'affichait dans la modale du sélecteur d'icônes, que applyIcon() ferme aussitôt l'icône appliquée — le message mourait avec elle, illisible. Demande explicite : un vrai toast, pas une ligne dans la modale.

1.0.2 — référencement npm seul, aucun changement de code (2026-08-10)

Publication menée par l'utilisateur lui-même, consignée a posteriori le 2026-08-14. Le paquet remontait mal dans la recherche npm : ses six mots-clés ne couvraient pas ce qu'il fait. Seul le référencement a été amélioré — la liste keywords de package.json passe de 6 à 28 entrées (sftp-client, ssh-tunnel, drag-and-drop, workspaces, better-tabby…), tabby-plugin restant en tête pour le gestionnaire de plugins de Tabby. Aucun changement de code ni de fonctionnalité entre 1.0.1 et 1.0.2 ; dist/ n'a été rebuildé que par prepublishOnly.

1.0.1 — les notices tierces voyagent avec le paquet (2026-08-08)

Trouvé en répondant à une question de l'utilisateur sur les différences entre licences : le paquet npm ne contenait pas THIRD-PARTY-NOTICES.md. Le champ files ne listait que dist, et npm n'ajoute d'office que la licence et les README. Or le paquet redistribue des œuvres sous Apache 2.0 — les logos dashboard-icons et DOMPurify — dont l'article 4a demande que le destinataire reçoive une copie de la licence. Sur GitHub tout était en place ; dans le paquet installé, non.

README français, parité avec le plugin frère (2026-08-08)

Question de l'utilisateur : « le README.fr.md a disparu ? ». Vérification faite dans l'historique complet — il n'a jamais existé sur ce dépôt, qui n'a connu que README.md et .AIRules/README.html. C'est le vault qui en a un. Créé donc, pour la parité entre les deux plugins.

Publication de la V1.0 (2026-08-08)

tabby-better-sidebar@1.0.0 est sur npm et sur GitHub. La condition posée par la roadmap — une passe de test de release avant toute publication — est remplie : la passe porte sur le paquet et non sur les fonctionnalités, celles-ci ayant été validées une à une dans la journée.

Préparation de la V1.0 — dépôt, vitrine et paquet (2026-08-08)

Demande de l'utilisateur : un dépôt propre et un README exhaustif avant la mise en ligne. Le tour d'inventaire a surtout montré que le dépôt l'était déjà — aucun fichier source mort, aucun résidu non suivi, et un paquet npm qui ne publiait que dist/, README.md et LICENSE, comme le plugin frère.

Durcir l'import de dossier collé — défaut de sécurité du code livré (2026-08-08)

Trouvé en instruisant l'idée « Team Sharing » d'un backlog post-V1.0, et sans rapport avec elle : le défaut était dans le chemin déjà livré et publié du collage de dossier. Corrigé par un agent en worktree isolé, puis relu et revalidé. Fiche au registre du réalisé.

Popups à formulaire en modales centrées (2026-08-08)

Dernier chantier ouvert de la roadmap, mené par un agent en worktree isolé puis relu et revalidé. Les deux popups qui portaient un formulaire — tunnels du profil, sélecteur d'icônes — passent sur le patron des modales existantes. Les menus contextuels restent des menus, comme la fiche l'exigeait. Fiche au registre du réalisé.

Menus contextuels en sous-menus nommés (2026-08-08)

Le menu du dossier portait treize entrées — « il s'étend vers l'infini », signalé par l'utilisateur le 2026-08-03. La fiche imposait de poser le critère de partage plutôt que de le deviner ; bien lui en a pris : aucun des deux angles qu'elle opposait (fréquence d'usage / nature du geste) n'a été retenu. L'utilisateur a demandé des sous-menus nommés à la façon de Windows. Chantier mené par un agent (Sonnet) en worktree isolé, puis relu et revalidé. Fiche au registre du réalisé.

Icônes dashboard-icons — troisième source du picker (2026-08-08)

Demandé par l'utilisateur : les collections en place offraient peu d'icônes reflétant des solutions IT. Chantier mené par un agent (Sonnet) dans un worktree isolé, puis relu, corrigé et revalidé. Design tranché en amont — ajout et non remplacement, tout embarqué hors-ligne plafonné à 50 Ko par fichier, variantes proposées par icône. Fiche complète au registre du réalisé.

i18n lot 4 — modules purs, clôture de la couverture (2026-08-08)

Dernier lot de l'internationalisation, mené par un agent (Sonnet) dans un worktree isolé sur consigne de l'utilisateur, puis relu et revalidé. Les modules purs sans accès à l'injecteur rendent un TranslatableMessage (src/i18nMessage.ts) — clé anglaise + paramètres — traduit au point d'affichage par sidebarTree.component.ts, seul appelant. Le chantier i18n est terminal : fiche basculée au registre du réalisé.

Publication npm v0.4.0 (2026-08-08)

Publication demandée par l'utilisateur dans la foulée de deux validations du jour. Ce que la 0.4.0 apporte depuis la 0.3.0 : couverture i18n complète de la sidebar (lot 3 — arbre des profils, bloc Transferts, onglet de réglages, fr/es/de) et pied de page inviolable et opaque. Le lot 4 (messages d'erreur des modules purs) est en cours sur sa branche et partira dans une version ultérieure.

Pied de page inviolable — colonne flex, contenu clippé, fond opaque (2026-08-08)

Signalé par l'utilisateur pendant la passe i18n : une ligne de transfert chevauchait le pied de page (fenêtre courte + fond translucide). La réserve par padding-bottom sous un pied de page absolu était une convention géométrique que tout débordement contournait. Exigence posée : rien ne doit entrer dans la zone, et aucune transparence, sur les deux vues. Branche fix/pied-de-page-intouchable.

i18n lot 3 — sidebarTree, Transferts et onglet de réglages traduits (2026-08-08)

Dernier gros lot de l'internationalisation (issue GitHub #1) : les trois surfaces restées en français statique après les lots 1-2 passent aux clés anglaises + tables fr/es/de. L'onglet de réglages, cassé au lot 2 par le JIT (apostrophe dans un littéral inline), est refait selon le motif imposé par la fiche : tout en propriétés lbl*, aucun littéral inline. Branche feat/i18n-lot-3.

Remise à niveau 20260804-071239 : deux options tranchées, registre du réalisé créé (2026-08-08)

Les branches de sync du 2026-08-04, créées avant la fusion de la phase 0.3.0, étaient périmées — les fusionner aurait annulé la phase. Elles ont été supprimées (avec feat/phase-0.3.0, déjà fusionnée) et la propagation refaite depuis master, sur la branche governance-sync-20260804-071239.

G2, G3 et G4 — la phase 0.3.0 close, une passe de test presque tout entière pilotée, et un socle d'i18n (2026-08-08)

Le fait de méthode du groupe : une passe de test de trois vagues, seize contrôles pilotés par l'assistant via CDP (injecteur Angular racine, mutations sous zone.run(), jamais un clic simulé), sur des données jetables (ZZZ … / grp-zzz-test-*) et avec sauvegarde de config.yaml vérifiée à l'octet avant/après. Workspaces 20/20, sessions et gel de vue et retour-auto et récents 16/16, SFTP (multi-sélection distante fichiers et dossiers, chargement par blocs, suppression et déplacement en masse) et transferts au complet. Une seule case n'a pas pu être pilotée et a été déléguée à l'œil de l'utilisateur : la confirmation d'annulation d'un transfert en cours — le composant des transferts est monté par Angular en mode production, donc inatteignable par CDP (window.ng n'expose que ɵcompilerFacade, __ngContext__ n'est qu'un entier vers un registre injoignable). Le mécanisme lui-même était déjà prouvé par ailleurs via ConfirmModalComponent pendant la passe SFTP.

Un faux négatif à ne pas rejouer : le « gel de la vue » a d'abord semblé cassé. Le diagnostic passait par launchProfile, dont le chemin composant réenveloppe les onglets ; capturé ainsi, l'onglet lié paraissait dériver. Un diagnostic direct (expr-diag-freeze.js) a montré que l'onglet lié restait bien épinglé et frozen=true — l'artefact venait de l'instrument, pas du code. Régle de la maison, reconfirmée : lire l'état écrit, pas l'écran, et se méfier de l'outil de mesure avant de conclure au défaut.

Le sélecteur de workspaces a été repris deux fois sur retour utilisateur, et c'est la deuxième reprise qui a trouvé la bonne forme. Le mode « liste » n'est plus une valeur de contextMenuMode mais un état propre (workspaceSwitcherOpen) : la liste déroulante reste affichée sous le menu de gestion et ses sous-popups, qui s'ouvrent désormais à un ancrage fixe au bord droit de la liste (switcherPopupAnchor()), jamais au curseur — un clic dans la liste ne fait plus disparaître le panneau, ce qui rendait l'usage pénible. Le choix onglets/liste est un réglage explicite (workspaceSelectorMode), la bascule automatique par ResizeObserver ayant été refusée au test. Le clamp de position exclut .workspace-switcher-menu, puisque deux popups coexistent maintenant par conception.

Le pied de page réserve enfin sa bande. L'engrenage, les lignes de transfert SFTP et le cadre natif se chevauchaient en bas de sidebar. Le correctif n'est pas un simple rembourrage : une barre de pied fixe occupe une bande réservée (padding-bottom du conteneur augmenté d'autant), l'engrenage y est agrandi et déplacé dans le flux, et la ligne libérée affiche better-sidebar by TooMuhtsh v{{version}} à gauche — la version est importée de package.json (resolveJsonModule). Autre réglage tranché par l'utilisateur : « Profils récents » (showRecentProfiles) est désormais désactivé par défaut, une meilleure présentation étant remise à un prochain lot.

G3 a été construit par agents séquentiels sur la branche de phase, chaque passe build-vert, puis repris à la main sur les deux retours utilisateur du sélecteur. Trois écarts de design à retenir, détaillés dans la fiche workspaces : la ligne d'insertion du réordonnancement n'est pas livrée (placeholder CDK verrouillé à hauteur nulle contre l'oscillation, pièges #25/#28) ; la couleur contextuelle passe par le champ color natif des profils (icône teintée + barre sous l'onglet, palette TAB_COLORS), injecté par structuredClone au lancement, la couleur propre d'un profil gagnant toujours ; l'export/import de workspace vit dans src/workspaceShare.ts (ids inconnus conservés, piège #74, icône SVG resanitisée à l'import).

G5 — transferts fiables et tunnels à état de reprise (2026-08-07)

Le fait marquant du groupe : les deux vrais défauts de la passe ont été trouvés par les contrôles eux-mêmes, dès leur première exécution. Le contrôle d'arrivée a déclaré « incomplet » un lien symbolique parfaitement livré — la taille d'un lien dans un listing est celle du lien, le téléchargement livre la cible ; d'où l'extraction du résolveur borné à 8 sauts dans remoteEntry.ts, partagé entre l'édition distante et la vérification. Et la cause réelle des tunnels affichés en 3-4 exemplaires n'était pas celle supposée : pas de doubles listeners, mais le multiplexage — plusieurs onglets partagent la même SSHSession et le panneau listait le même tableau une fois par onglet. Sur ce poste, un second bind local est refusé (EADDRINUSE, mesuré y compris à chaud) : le démontage automatique de doublon reste un filet de sécurité au chemin non exercé, à ne pas présenter comme validé.

Un fait établi sur les sources installées, qui a dicté le design des tunnels : il n'existe aucune reprise native à refléter. La micro-coupure détruit la session entière ; à la reconnexion de l'onglet, seuls les tunnels du profil sont remontés, et un tunnel ajouté à la volée disparaît en silence. Les trois états du panneau (« reprise… » 60 s, retour à live, « non remonté » 30 s) sont la mémoire que Tabby n'a pas. Vérifié au test 20 et voulu : fermer un onglet d'une session multiplexée laisse le tunnel vivant tant qu'un autre onglet la référence.

Méthode de passe, réutilisable : les services du plugin ne sont pas exportés par son paquet — ils se retrouvent par leur nom de classe dans inj.records de l'injecteur racine (complément au piège #8). pickDirectory() neutralisé vers un banc local (un dialogue natif fige le renderer, CDP compris), profil SSH jetable zzz-test-g5-tunnel créé puis retiré avec contrôle d'intégrité de la config à l'octet près, banc distant /tmp/zzz-test-g5 nettoyé, ForwardedPort fabriqué par prototype d'une instance vivante pour le montage à chaud. Harnais dans le scratchpad de la session.

Ouvert par l'utilisateur pendant la passe, consigné sans être tranché : le dialogue « Enregistrer sous » d'un téléchargement de fichier par menu contextuel affiche « 127.0.0.1 » — l'hôte de notre offre HTTP locale, non remplaçable par un texte arbitraire. Options dans la fiche panneau d'état.

G1 — duplication, snippets, notes et partage de groupe (2026-08-03)

Le fait marquant du groupe n'est aucun des cinq items : c'est que trois d'entre eux se sont révélés autres que leur fiche l'annonçait. Quick Snippets décrivait des listes de commandes par profil et est devenu une bibliothèque partagée avec variables. Group Exec n'était pas un item neuf — la fonction existait, seuls ses enrichissements restaient, et ils ont été refusés. Partage de groupe reposait sur une idée fausse du coffre-fort. Chaque fois, ce qui a changé le périmètre est le même geste : lire le code, ou poser la question, avant de chiffrer. Une fiche de roadmap consigne une intention écrite tôt, pas un état.

Deux défauts sérieux ont été trouvés par la mesure, pas par la relecture, et les deux méritent d'être retenus pour la méthode plus que pour le cas.

• La purge du partage laissait passer defaults.ssh.scripts (piège #77) — un script de login de dossier, que Tabby fusionne dans chaque profil du dossier, et où un mot de passe sudo se met couramment en dur. L'export paraissait correct : le mot de passe voisin avait bien disparu. Ce qui l'a révélé est un contrôle sur la catégorie du décompte — un mot de passe compté comme « champ sensible » au lieu de « mot de passe », donc retiré par un filet heuristique et non par la règle qui aurait dû s'en charger. Vérifier qu'un secret est parti ne suffit pas ; il faut vérifier par quelle règle.
• Le rapport de purge affiché au collage aurait toujours été vide. Il était re-dérivé en relisant le JSON — or l'export avait déjà tout retiré, donc il n'y avait plus rien à compter. L'utilisateur avait explicitement demandé que les scripts retirés soient dits ; la fonctionnalité aurait été silencieusement absente, et aucun test fonctionnel ne l'aurait montré. D'où deux comptes séparés : ce que l'export annonce, et ce que la relecture a dû retirer elle-même — le second non vide signalant un JSON qui portait plus que son en-tête n'admettait.

La purge, étant du code pur, a été vérifiée hors de Tabby avant toute passe manuelle : 59 contrôles sur src/groupShare.ts, refus et entrées malformées compris. C'est ce banc qui a trouvé le premier des deux défauts. La passe réelle a suivi, 36 points, et son contrôle le plus fort porte sur le résultat écrit et non sur l'export : vingt profils collés, aucun ne portant de secret, les quatre seules entrées encore chargées étant les originaux du banc.

Deux pièges d'environnement consignés au passage, tous deux sortis de la préparation du banc de test : #76 — un commentaire écrit dans config.yaml ne survit pas au premier config.save(), Tabby réécrivant tout depuis son état mémoire, ce qui rend inopérant tout retrait fondé sur des marqueurs — et #78, le fonctionnement réel du coffre-fort.

Un chantier ouvert par l'utilisateur pendant la passe, consigné sans être traité : le menu contextuel du dossier porte désormais treize entrées, dont les deux dernières viennent de ce chantier.

Régime temporaire : roadmap figée, consignation en une fois (2026-08-03)

La roadmap venait d'être remise à jour et il ne reste que des items petits, indépendants et sans couplage à trancher. Consigner chacun coûtait alors plus cher que le geste lui-même. D'où la décision : ce qui est demandé et réalisable de suite se fait de suite, sans ouvrir de fiche, et tout est consigné en une seule fois à la fin.

Ce qui est suspendu est la consignation au fil de l'eau, pas la prudence : l'option branches reste en vigueur et c'est elle qui rend le reste possible — le travail vit sur une branche unique, si bien que master ne porte à aucun moment du code que la gouvernance ne décrit pas, et la fusion finale amène le code et sa documentation d'un seul geste. Aucune option du PROFIL.md ne change : une modification d'option relèverait de l'entretien de cadrage, pas d'une organisation de travail.

L'état vit dans .AIRules/currentwork_roadmap.html — 24 items restants en six groupes, avec difficulté, jauge d'utilité et état d'avancement, plus un journal de phase qui sert de matière à la consignation. Ce fichier est supprimé à la consignation finale, en même temps que la section correspondante de CLAUDE.md : le laisser vivre créerait un second endroit où lire le même fait, et un régime dérogatoire qui survit à sa raison devient une règle par simple oubli.

Les points de veille restants : deux appuis retirés, le dernier point rouge rendu bruyant (2026-08-03)

La piste que la fiche recommandait aurait fabriqué une fausse panne. Elle proposait de lire ɵcmp.inputs pour vérifier que la modale de profil déclare toujours les deux entrées que le plugin lui assigne, en demandant d'établir d'abord « la forme exacte de la table ». Bien lui en a pris : cette table est indexée par le nom public de l'entrée, et la modale déclare @Input('profile') partialProfile. Une précondition y cherchant la clé partialProfile aurait échoué à tous les démarrages, sur un Tabby parfaitement sain — un contrôle ajouté pour rendre une panne visible aurait produit une panne imaginaire, ce qui est pire que le silence qu'il remplaçait.

Deux corrections en sont sorties, consignées au piège #75. reflectComponentType() est de l'API publique depuis Angular 14.1 : la réserve de la fiche — « un champ préfixé ɵ n'est pas contractuel non plus, donc le remède partage la nature du mal » — tombait d'elle-même, il n'y avait pas lieu de lire un champ interne. Et son résultat se lit par propName, jamais templateName, contrairement à l'exemple donné par la documentation d'Angular, qui intervertit les deux : c'est toRefArray() dans le bundle réellement chargé qui a tranché, pas le commentaire au-dessus.

fragile-7, le seul point rouge, dans l'ordre que ce projet s'impose — réduire d'abord, surveiller ensuite. src/profileModal.ts devient le point unique par lequel la modale s'ouvre : les deux appelants la nommaient chacun, elle n'est plus nommée qu'une fois, et c'est cette liste-là que la précondition edit-profile-modal confronte à ce qu'Angular déclare. Un satisfies l'arrime à l'augmentation de types — ce qui ne prouve rien sur Tabby, mais interdit que la liste vérifiée et la liste assignée divergent. En cas d'écart : un message nommant le champ absent et les entrées réellement déclarées, une notice, et un refus d'ouvrir plutôt qu'une fenêtre vide dont personne ne peut rien tirer.

fragile-5 : la discipline devient structure, et une supposition devient une mesure. readProfileGroups() est désormais le seul appel du plugin à getProfileGroups() et rend un clone par construction ; les deux appelants recopiaient les mêmes lignes et le même avertissement, et rien n'obligeait un troisième à le faire. La mesure a rapporté davantage : Tabby clone déjà — getSyncProfileGroups() rend deepClone(config.store.groups), et une comparaison d'identité sur l'app en marche confirme qu'aucun groupe ne revient comme le même objet. Le structuredClone() du piège #12 reste malgré tout : les bretelles sont un détail d'implémentation d'une méthode que personne n'exporte, et ce qu'elles retiennent est un config.yaml corrompu. Une sonde vérifie cette garantie une fois par session au lieu de la supposer.

fragile-8 : deux appuis retirés plutôt que documentés. La surcharge passe de downloadItem() à download(), où les deux voies aboutissent : la question « l'entrée de menu appelle-t-elle bien downloadItem() ? » devient sans objet, et cette méthode redevient celle de Tabby. Et l'absence d'un gestionnaire will-download, jusque-là supposée, est demandée avant chaque téléchargement par listenerCount() — méthode d'EventEmitter, donc réellement contractuelle, ce que rien d'autre n'est dans ce voisinage ; s'il y en a un, la voie héritée reprend la main.

Passe de test du 2026-08-03 — pilotée par l'assistant, à la demande de l'utilisateur

Le contrôle a été vérifié dans les deux sens, faute de quoi il n'aurait rien prouvé. Dans le bon : démarrage silencieux, modale s'ouvrant en portant le profil qu'on lui passe — donc l'entrée est bien assignée et consommée —, configuration inchangée par empreinte, arbre chargé sans qu'aucun groupe vivant ne gagne de propriété calculée. Dans l'autre : avec un nom d'entrée volontairement faux, recompilé pour l'occasion puis restauré, le démarrage sort le message attendu avec la liste des entrées réelles, la notice s'affiche, l'ouverture est refusée — pendant que la sidebar et son arbre restent intacts, la précondition n'étant pas fatale.

Passe SFTP sur le serveur VPN, dans /tmp/zzz-test-dl/ créé puis supprimé, sur un fichier au contenu déterministe (seq 1 20000, 108 894 octets — taille recalculée à la main pour que le banc lui-même soit vérifiable). Le chemin part de downloadItem(), c'est-à-dire de ce que Tabby appelle vraiment : l'offre HTTP locale est émise, répond 200 avec le bon Content-Length, et les octets reçus sont identiques à l'attendu. Trois contre-tests : un lien symbolique reste sur la voie héritée, un will-download installé pour l'occasion y renvoie aussi, son retrait rend la main à la voie HTTP.

Deux points de méthode. Aucune boîte de dialogue native n'a été ouverte de toute la passe : le clic sur l'ancre est intercepté et startDownload() neutralisé — un dialogue natif fige le renderer, CDP compris (#65). Et le panneau SFTP ne se construit pas tant que la sidebar est sur la vue Profils : c'est setSftpMode(true) qu'il faut appeler, l'entrée active du composant étant précisément ce qui l'empêche d'ouvrir un canal pour une vue que personne ne regarde.

Chaque bloc de la sidebar s'éteint, et son extinction coupe la source (2026-08-03)

Le chantier n'était pas le *ngIf. Six clés sous sidebarPlus, toutes à true par défaut, mais éteindre coupe ce qui alimente le bloc : le balayage de tous les onglets de tous les splits toutes les 2 s cesse de s'exécuter, la sonde de latence reçoit une liste vide et n'interroge plus aucun serveur, track() refuse toute inscription en un point unique qui couvre fileTransferStarted$ comme nos propres appels. Un interrupteur qui n'aurait masqué que la vue aurait épuré l'écran en gardant le coût.

Le composant SFTP est détruit et non caché — l'inverse du choix fait pour la bascule de mode, qui reste en [hidden] pour préserver son cache de panneaux. Les deux ont raison parce que ce ne sont pas les mêmes questions : changer de mode est temporaire, éteindre le bloc est censé rendre les canaux.

Un garde-fou demandé par l'utilisateur a trouvé un vrai défaut, et c'est le test écrit pour le vérifier qui l'a attrapé, pas la relecture. Éteindre les workspaces fait retomber l'affichage sur « Tous », et loadTreeItems() persistait cette valeur dans localStorage en fin de course : le workspace réellement choisi était perdu, et rallumer ne le rendait pas. D'où la règle, désormais écrite : un interrupteur ne persiste que sa propre valeur ; tout état qu'il se contente de cesser d'afficher lui survit intact. Vérifié par empreinte de toute la configuration — profils, groupes, workspaces avec masquages, favoris et ordres, tunnels configurés d'un profil — bit à bit identique de part et d'autre d'un cycle complet.

Le gestionnaire de transferts est passé sous la vue SFTP en seconde passe, à la demande de l'utilisateur. Le corollaire n'était pas dans la demande et compte autant : le registre reflète tous les transferts de l'application, y compris ceux du panneau natif et des autres plugins. Les rendre invisibles pendant que hideNativeTransfersMenu reste coché laissait l'utilisateur sans aucun affichage. Le masquage du menu natif est donc suspendu dès que notre panneau ne s'affiche plus — prolongement d'un principe déjà posé au montage : un plugin n'a pas à masquer un morceau de l'interface de l'hôte qu'il ne remplace plus.

Page de réglages refondue dans le même geste, sur trois règles de l'utilisateur : deux onglets (« Général », « Fonctionnalités ») plutôt qu'un long déroulé ; chaque option sous l'interrupteur de la fonctionnalité dont elle dépend, et qui disparaît avec elle — un réglage qui survit à sa fonctionnalité se lit comme cassé, pas comme sans objet ; descriptions d'une à deux lignes, le détail passant en infobulle sur une icône (i). Les blocs sans réglage propre sont groupés et resserrés en tête. Ce qui règle du même coup l'agencement qu'attendait « Options & polissage UI ».

Le point le plus fragile du plugin a été supprimé, pas consolidé (2026-08-03)

L'inventaire a précédé le correctif, et il a changé la conclusion. Quatre natures de couplage à l'hôte, très inégalement risquées : le DOM non versionné de Tabby (le seul réellement muet), les classes empruntées à tabby-ssh (exportées — le risque est leur dédoublement, pas leur absence), le SCSS global (débordement, discipline déjà tenue) et les API publiques de tabby-core (contractuelles, rien à durcir). Distinguer les quatre a évité de dépenser le chantier sur ce qui ne risquait rien.

« Éditer… » pilotait le DOM de tabby-settings : ouvrir l'onglet Paramètres, déplier tous les dossiers par des clics successifs, retrouver la ligne en comparant le texte d'un span, la cliquer, puis sonder .modal-content toutes les 300 ms pour savoir quand refermer. Le commentaire qui portait ce code affirmait qu'aucune API publique n'existait — et le même fichier ouvrait déjà cette modale quelques centaines de lignes plus haut, pour « Nouveau profil… ». editProfile() reprend donc les huit lignes de tabby-settings. Environ 135 lignes retirées, et le point de veille fragile-1 avec.

La leçon, plus large que ce cas : le premier réflexe devant un couplage fragile avait été de mieux surveiller la casse. Retirer le couplage a coûté moins cher que le garde-fou qu'on s'apprêtait à construire. Avant d'instrumenter un point de contact : peut-il disparaître ? Sinon seulement, comment le rendre bruyant. Un contournement survit à la raison qui l'a fait naître, et son commentaire devient l'argument qui empêche de le rouvrir.

Ce qui reste couplé est désormais vérifié. Quatre préconditions nommées dans src/hostCompat.ts, évaluées une fois à app.ready$, chacune portant la fonctionnalité qu'elle fait perdre — seul le conteneur de montage est fatal. Pas de contrôle de version de Tabby : un numéro crierait au loup sur une version compatible et se tairait sur un build local qui a bougé. Et une sonde pour ce qu'aucun contrôle statique ne peut voir : avec deux tabby-ssh chargés, les quatre préconditions passent — les classes existent, ce sont les mauvaises. isSSHTab() porte cette sonde, et les trois instanceof dispersés y passent désormais : le partage ne gagne pas une ligne, il crée le point où l'hypothèse est vérifiée au lieu d'être supposée.

Ce que ce contrôle ne fait pas, à ne pas relire plus tard comme une promesse : il ne rend pas le plugin plus compatible et ne réduit ni ce qui casse ni la fréquence. Il change le mode d'échec, d'un non-événement vers quelque chose qui se lit.

Un id supprimé ne laisse plus de trace derrière lui (2026-08-03)

favorites, favoriteGroups, hiddenProfileIds et hiddenGroupIds gardaient l'id d'une entrée supprimée, dans chaque workspace, sans que rien ne les ramasse. Aucune perte de données — une accumulation qui ne se vide jamais.

Ce qui a décidé de la forme du correctif, et qui n'était pas prévu : la solution évidente était d'élargir pruneDeadOrderIds() aux quatre listes. Elle est fausse. Un balayage doit répondre « cet id existe-t-il encore ? », et config.store.profiles/.groups ne portent que les entrées de l'utilisateur : l'arbre affiche aussi les profils fournis par les providers et les groupes synthétiques qui les portent, absents de config.store. Le balayage aurait donc supprimé les favoris de ces profils-là — soit exactement l'inverse du but. Le nettoyage se fait au point de suppression, où l'id est connu d'emblée et où rien n'a à être déduit. Voir piège #74.

Un défaut latent est tombé au passage, absent de la fiche : pruneDeadOrderIds() jugeait déjà la vie d'un id sur config.store seul, donc la position d'un profil builtin comptait pour morte et retombait à son défaut au prochain réordonnancement. Il consulte désormais aussi rawGroupsSnapshot. C'est en cherchant pourquoi la solution évidente était dangereuse qu'il est apparu.

Ce que le re-parentage ne fait pas, et ne doit pas faire : il n'appelle pas ce nettoyage. migrateWorkspaceGroupId() a déjà renommé toutes les traces de l'ancien id avant que le groupe ne soit supprimé — migrer, puis supprimer. Inverser les deux, ou ajouter le nettoyage « par symétrie », effacerait ce qui vient d'être migré. Écrit dans le code à l'endroit même où la question se pose.

Le SCSS ne déborde plus sur Tabby, et les icônes ne sont plus chargées au démarrage (2026-08-03)

La fuite de style s'est révélée à la fois plus large et plus étroite que décrite. La fiche annonçait deux débordements et une classe impossible à cadrer ; il y en avait trois, dont deux se cadrent très bien, chacun d'une façon différente. Ce qui a permis de trancher, c'est d'avoir lu la source de @angular/cdk installée plutôt que de raisonner par analogie : le placeholder ne quitte pas la liste (parent.replaceChild()), l'aperçu si — et se nomme par cdkDragPreviewClass, l'entrée que CDK expose pour ce cas exact —, et .cdk-drag-animating, absente de la fiche, est du côté de l'aperçu : la cadrer par le tag ne l'aurait pas restreinte, elle l'aurait supprimée. Détail en piège #71.

Un commentaire du code affirmait le contraire, et se recopiait de proche en proche vers les règles voisines. C'est le genre d'erreur qui ne se voit pas à la relecture : elle décrit un comportement plausible et cohérent avec ce que fait l'aperçu juste à côté.

Le reste du fichier a été confronté aux builtin-plugins/ de l'app installée, classe par classe — la méthode qui avait fait trouver .grabber. Aucune autre n'y apparaît : elles restent globales en connaissance de cause, pas par omission.

Les icônes passent en chargement à la demande. Les deux collections Iconify sont 97 % du paquet et étaient importées en entier, donc décodées à chaque lancement de Tabby, pour un sélecteur que la plupart des sessions n'ouvrent jamais. Un import() dynamique les sort du bundle de démarrage — sans réduire le paquet publié, ce qui est voulu et inévitable : les @iconify-json/* sont des devDependencies, absentes d'une installation utilisateur, donc le chunk doit voyager avec. Ce qui tombe, c'est le coût de démarrage. Deux conditions non évidentes, consignées en #72 et #73.

Cadrage relu, et seuil passe à roadmap-libre (2026-08-03)

Entretien complet rouvert à la demande de l'utilisateur, sous la charte 20260731-204511. Les vingt-deux clés de la charte et les vingt-deux lignes de PROFIL.md ont été confrontées une à une : elles correspondent exactement, aucune ajoutée ni retirée. La ligne « Charte au moment du cadrage » passe donc de 20260731-150737 à 20260731-204511 — elle attendait précisément cette relecture, et l'avancer plus tôt aurait écrit un fait faux (voir le chantier de remise à niveau).

Une seule option change : seuil, de strict à roadmap-libre. La roadmap s'écrit désormais librement ; le journal reste sous validation. Le motif n'est pas une commodité mais un défaut constaté deux fois le même jour : un chantier corrige en passant ce qu'une autre fiche décrit — les trois défauts mineurs du voisinage config.store, corrigés en construisant l'intégrité des données, puis build:prod et filesize, réglés dans la préparation de la 0.3.0 — et la fiche voisine, qui n'appartient à aucun de ces chantiers, reste périmée faute d'un feu vert que personne ne pense à demander. Une roadmap périmée ment autant qu'une roadmap écrite sans arbitrage : c'était le risque inverse de celui que strict protège, et c'est celui-là qui s'est réalisé.

Contrepartie assumée, écrite ici pour qu'elle ne se redécouvre pas : un statut de chantier peut désormais bouger sans arbitrage explicite de l'utilisateur. Ce qui la borne, c'est que le journal, lui, ne bouge pas — et qu'un statut « Fait » continue de reposer sur une validation en conditions réelles, qui est une autre règle.

Le build de publication n'embarque plus de source-map (2026-08-03)

Premier des points de Ménage avant release soignée à être traité. Deux des trois y étaient déjà faits sans que la fiche le dise : build:prod existe et prepublishOnly l'appelle depuis le d9d291b (2026-08-02), et filesize y a rejoint les devDependencies dans le même commit. La fiche décrivait donc un état périmé de deux jours — même travers que le bloc des trois défauts mineurs : un chantier corrige en passant ce qu'une autre fiche décrit, et la fiche ne suit pas.

Ce qui restait, et que personne n'avait vu : --mode production est passé en ligne de commande, et webpack-cli le fusionne par-dessus la configuration. La clé mode était donc bien corrigée, mais le fichier de config, lui, continuait de se croire en développement : devtool: 'source-map' et pathinfo: true gardaient leur valeur. Le paquet publié était minifié et embarquait sa source-map. La configuration s'exporte désormais en fonction, seule forme qui voit argv.mode.

Pourquoi pas output.clean, qui aurait été la réponse évidente au fichier résiduel : les .d.ts que désigne typings sont écrits directement dans dist/ par TypeScript (declarationDir du tsconfig), et ne passent pas par les assets webpack — vérifié en construisant vers un autre --output-path, qui n'a produit qu'index.js. Les nettoyer aurait publié un paquet sans typings. Le script de build retire la source-map lui-même.

Purge des données réelles de l'utilisateur dans le dépôt public (2026-08-03)

Demande de l'utilisateur, née d'une vérification d'attribution : la documentation de ce dépôt public citait le nom de l'employeur de l'utilisateur, un nom d'hôte de son infrastructure et l'organisation de son parc, repris de ses vraies données au fil des passes de test. Rien de secret — aucun identifiant, aucun accès — mais de l'information interne qui n'a pas à être publiée.

Ce que la vérification a établi au passage, et qui n'était pas l'objet de la demande : ce dépôt ne porte aucune métadonnée d'attribution IA, sur les 149 commits et toutes références confondues, et son unique contributeur GitHub est TooMuhtsh. La purge du 2026-08-01 a tenu et aucun commit depuis n'en a réintroduit. La page GitHub qui semblait dire le contraire servait un cache.

Exception assumée à l'ajout seul : la purge a réécrit les entrées existantes de ce journal, seule façon de retirer la mention de l'historique. Deux motifs de remplacement, App.<employeur>.fr vers app.exemple.fr et le nom seul vers Travail, appliqués à tout l'arbre de chacun des 149 commits — dont tabby_sidebar_roadmap.md, supprimé du HEAD depuis le 2026-07-26 mais toujours vivant dans l'historique. C'est le genre de fichier qu'une recherche au HEAD ne montre pas.

Deux enseignements sur la réécriture, qui corrigent le piège #11 : filter-branch efface sa table de correspondance en fin de course, il faut donc la reconstituer depuis refs/original — et l'apparier sur le sujet et la date de chaque commit, pas seulement sur la position, faute de quoi un décalage d'un cran passerait inaperçu. Et le contrôle « git diff refs/original… master doit être vide » ne vaut que pour une purge de messages : ici l'arbre change par construction.

Ce qui n'est pas refermé, et ne peut pas l'être depuis le poste : un push --force ne supprime rien chez GitHub. L'ancien sommet répond encore par son hash. Aucune référence ne pointe plus vers lui (ni fork, ni refs/pull/*, ni tag), donc un ramassage côté GitHub finira probablement par l'emporter, mais rien ne le garantit ni ne le date — seul un ticket au support purge réellement. Arbitrage de l'utilisateur : on laisse courir, le contenu retiré ne donnant aucun accès. Voir piège #70.

Le paquet npm publié (0.2.0, 2026-07-26) a été téléchargé et inspecté : indemne, la mention étant postérieure à sa publication.

L'éditeur par type de fichier est écarté (2026-08-03)

Chantier Éditeur par type de fichier, construit puis retiré le même jour. Décision de l'utilisateur à l'essai : « Ouvrir avec » du clic droit fait le travail plus directement, et la table extension → programme n'apportait rien qui vaille son coût. Branche non conservée, aucun code sur master — la fiche de roadmap porte la trace et le motif.

Ce que l'essai a établi, et qui manquait au cadrage : la règle retenue — un type inconnu demande plutôt que d'emprunter l'éditeur d'un autre type — pose une question à chaque nouvelle extension rencontrée, et son alternative (repli silencieux sur le défaut) revient au comportement d'avant. Aucune des deux positions ne justifiait la table.

Un reste à connaître : les configurations ayant servi au test portent une clé sidebarPlus.sftpEditors orpheline et un sftpEditorPath vidé par la migration. Le code revenu en arrière ignore la première ; l'éditeur se re-règle en un clic.

Latence et âge des sessions actives (2026-08-03)

Chantier Ping live, branche feat/ping-live, testé et validé par l'utilisateur le 2026-08-03.

La question à trancher n'était pas l'affichage mais la mesure : ni Tabby ni russh ne tiennent de temps d'aller-retour — vérifié sur le bundle installé, la seule mention de keepalive est l'intervalle passé à connect(), qui ne rend rien. Le chiffre est donc produit, et le moyen choisi est la définition de ce que la pastille signifie. Retenu après arbitrage de l'utilisateur : un stat() chronométré sur le canal SFTP déjà ouvert de la session. Il mesure l'aller-retour chiffré de cette session — le délai ressenti à la frappe — quand un ping ICMP mesure l'hôte et se fait couramment filtrer, et qu'une sonde TCP ouvrirait puis abandonnerait une connexion avant authentification à chaque tour, laissant une trace dans les logs du serveur et de quoi se faire bannir par son propre fail2ban.

Ce stat() ne contredit pas l'invariant du piège #50 : rien de la réponse n'est lu, seul le temps compte. La distinction est écrite dans le service pour qu'une relecture n'y voie pas une régression.

Trois retours de la passe de test ont refait la présentation. La pastille ajoutée au bout de la ligne était recouverte par le bouton SFTP au survol — et n'apportait rien, toutes les lignes de cette section étant vivantes par construction, donc la pastille de gauche était perpétuellement verte et muette. La latence a pris sa place. L'infobulle, d'abord posée sur la pastille, est passée sur la ligne entière : viser 6 px pour lire une valeur n'est pas un geste. Sa forme a été fixée à trois champs, app.exemple.fr | 13 ms | 1m 47s, ce qui a sorti le titre vivant de l'onglet — la ligne montre déjà le nom, et un titre qui suit le répertoire courant était la partie bavarde.

Un ajout non prévu, demandé en cours de passe : le temps écoulé depuis l'ouverture. Rien ne date une session dans Tabby, il est donc stampé à la première apparition dans la liste — avec les deux conséquences consignées dans la roadmap. Il ne dépend pas du réglage de latence.

Le sondage suit le passage de 2 s déjà en place plutôt que d'ajouter un timer, et ni la latence ni la durée ne sont portées par les lignes elles-mêmes : une valeur qui bouge ferait échouer sameSessions() et reconstruirait le DOM de chaque ligne deux fois par seconde, emportant le survol dont dépendent leurs boutons.

Barre de filtrage : raccourci, portée, et un ordre qu'on ne persiste plus (2026-08-03)

Chantier Barre de filtrage rapide, branche feat/filtre-rapide, testé et validé par l'utilisateur le 2026-08-03.

Le champ existait déjà — la fiche de roadmap décrivait un chantier neuf alors que l'essentiel était en place depuis le socle. Ce qui manquait vraiment : le raccourci, l'échappement, et une portée de recherche qui s'arrêtait au nom et à la description des profils. Constat fait en lisant le code plutôt qu'en croyant la fiche, et arbitré avec l'utilisateur avant d'écrire.

Ctrl+F est libre : Tabby met la recherche du terminal sur Ctrl+Shift+F hors macOS. Le raccourci passe par hotkey$ et non unfilteredHotkey$, donc il reste muet pendant qu'on tape dans un champ — y compris celui qu'il sert à atteindre. Depuis la vue SFTP il bascule d'abord sur Profils : le champ n'y existe pas, et ne rien faire ferait passer le raccourci pour cassé.

Un bug préexistant est tombé avec ce chantier, et c'est le point qui compte : glisser un profil pendant qu'un filtre est actif persistait l'ordre des résultats comme ordre réel — sur « Tous », directement dans les weight natifs des profils, dans config.yaml, sans un mot. Les résultats ne sont pas l'arbre, mais les directives CDK de la template n'en savent rien. Le défaut existait avant, et l'ajout des dossiers dans les résultats rendait le geste bien plus facile à déclencher : le glisser est donc coupé tant qu'un filtre est actif (piège #68).

Auto-Enter sort du périmètre (2026-08-03)

Décision de l'utilisateur, sans code. Le chantier Auto-Enter rejoint la section hors périmètre, son design conservé tel quel.

Deux motifs, à ne pas confondre. L'utilité n'est pas établie : le design valide une invite dont le mot de passe est pré-rempli, or Tabby envoie déjà ce mot de passe quand l'authentification enregistrée fonctionne — ne resteraient que les invites qu'il ne traite pas nativement, qui sont précisément celles où un Entrée parasite atteindrait un shell de production. Sans invite précise à nommer, le chantier n'a pas de cible. Le rattachement est discuté : l'utilisateur le verrait du côté de tabby-better-vault ; la roadmap note que le geste décrit est d'écrire dans un pty distant et non de lire un secret, donc que le rapprochement mérite examen plutôt que d'être supposé — et que cet examen se fait dans une session consacrée à l'autre projet.

Écart avec le précédent du Vault Auto-Unlock, qui est ce qui a justifié de garder le design ici : celui-là sortait vers un périmètre d'accueil déjà décidé, et son design a été transporté. Celui-ci sort sans destination acquise.

Plus de « terminé » avant que le système ait fini (2026-08-03)

Point 4 du chantier Panneau SFTP : suivre l'état réel de la session, sur la branche fix/etat-transitoire — dernier point ouvert, le chantier est clos avec lui.

L'arbitrage d'abord : le marqueur venait de rendre l'unification possible — passer aussi les fichiers par lui aurait donné une fin réelle et une destination connue. Écarté, et pour une raison de fond plutôt que par prudence : le marqueur suppose que la destination est un dossier du système de fichiers. Un dossier glissé n'a pas d'autre cible plausible ; un fichier, si — une zone d'envoi de navigateur, un client de messagerie — et celles-là auraient reçu le marqueur vide pendant que le fichier serait parti dans le dossier de repli. Le cas fichier marchait, il n'y avait pas lieu de le faire dépendre d'une heuristique.

Retenu : un état entre la fin de notre flux et la remise réelle, levé sur une durée estimée d'après la taille. Le sens de l'erreur a été choisi — 200 Mo/s supposés là où 250 avaient été mesurés (#58), donc la ligne finit tard plutôt que tôt, l'objet même de la manœuvre étant de ne plus annoncer en place un fichier qui ne peut pas l'être.

Un état terminal peut encore avoir besoin du minuteur, et c'est le seul vrai piège de ce chantier. « Ce qui peut être annulé » et « ce qui a besoin du tick » ne sont pas la même population : une ligne en remise n'a plus rien d'annulable de notre côté, mais son échéance n'est surveillée par rien d'autre, si bien qu'arrêter le minuteur au dernier transfert actif la laissait figée pour le reste de la session. Vérifié au test, avec la conséquence visible attendue : vider la liste pendant une remise ne demande pas confirmation et ne touche pas au fichier déposé.

Marqueur de dépôt : un dossier sort en un seul geste (2026-08-03)

Chantier Marqueur de dépôt, sur la branche feat/marqueur-depot, ouvert par l'étude du même jour. Le design est dans la roadmap ; ce qui suit est ce que la construction et le test ont appris.

L'inversion tient en une phrase : ne plus annoncer la charge utile, mais un fichier vide au nom unique. Le shell l'écrit à l'endroit du dépôt, et le retrouver donne la destination — que Windows ne communique jamais à l'application source (#58). Ce qui n'était pas prévu et qui compte autant : le geste redevient un glisser HTML5 ordinaire, donc le déplacement interne et la sortie vers l'OS cessent de se disputer le même geste. Tout l'échafaudage du glisser en deux temps — intention retenue d'un geste sur l'autre, surveillance de la sortie de fenêtre, notice « glissez-le à nouveau » — devient un repli, plus un chemin ordinaire.

Le socle a été mesuré avant d'être écrit : énumérer les fenêtres de l'Explorateur par Shell.Application en COM répond en ~50 ms et voit bien une fenêtre ouverte. C'est le point unique de rupture du mécanisme, et il ne valait pas d'écrire trois cents lignes avant de le savoir.

Ce que le test a établi (cinq cas au geste réel, tous validés) : dépôt dans une fenêtre, sur le Bureau, sur l'icône d'un dossier, déplacement interne inchangé, glisser d'un fichier inchangé. Et un cas que le design n'avait pas prévu — déposer sur le Terminal Windows ou MobaXterm ne produit rien, ces cibles ne réclamant jamais l'URL. Le repli n'a donc pas à se déclencher, et c'est bien ce qu'on veut (#67). Le repli lui-même reste non exercé.

La traversée d'arborescence a été sortie de sftpDragOut vers remoteTree.ts pour être partagée avec la livraison du marqueur, symlinks compris — deux copies auraient été deux occasions de n'en corriger qu'une.

Étude des plugins SFTP existants (2026-08-03)

Préalable posé par l'utilisateur au moment de valider le volet 3 : savoir ce qui est déjà résolu ailleurs avant d'écrire davantage de mécanique de glisser. Aucun code produit — le résultat est consigné dans la roadmap et a rouvert deux points qui y étaient donnés pour clos.

Trois plugins lus dans leurs sources d'origine : tabby-sftp-plus 2.0.0 (installé sur le poste), tabby-sftp-panel 0.3.0 et tabby-sftp-ui 0.2.7, récupérés depuis npm hors du dépôt. Tous trois publient leur index.js.map avec sourcesContent : les sources TypeScript s'en extraient en entier, commentaires d'implémentation compris. C'est bien plus sûr que la lecture de bundle compilé pratiquée jusqu'ici, et c'est ce qui a permis de lire les raisons de leurs choix, pas seulement leurs effets.

Ce que l'étude a confirmé : notre glisser sortant par DownloadURL + serveur HTTP local est exactement celui de tabby-sftp-panel, jusqu'à l'impératif de Content-Length exact — convergence indépendante, choix à ne pas rejuger. Et le geste en deux temps de tabby-sftp-plus, qui pré-copie avant de pouvoir annoncer quoi que ce soit, montre que notre « glissez-le à nouveau » décrivait une propriété du mécanisme.

Ce qu'elle a invalidé : le piège #58 concluait qu'un contrôle « le fichier est-il bien arrivé ? » était impossible pour un glisser sortant. Vrai de l'API, faux en pratique — tabby-sftp-panel fait écrire par le shell un marqueur de 0 octet au nom unique, puis le retrouve pour apprendre la destination. Le piège est corrigé et le chantier correspondant ouvert ; il rend sans objet les deux retours de test du volet 3 et fournit au point 4 du panneau d'état le signal de fin qui lui manquait. Relevé au passage : tabby-sftp-ui déplace lui aussi une entrée par dépôt sur une ligne de dossier, avec nos deux garde-fous mais sans regarder la collision, et il porte la troncature du piège #64 que notre traversée évite déjà.

Déplacer une entrée distante au glisser-déposer (2026-08-02)

Volet 3 du chantier Transferts SFTP, sur la branche feat/deplacement-interne-sftp. Le design est dans la roadmap ; ce qui suit est ce que la construction a appris.

Le geste de départ était déjà occupé par le glisser sortant, et les deux natures d'entrée ne se partagent pas pareil : un fichier annonce sa copie par un DownloadURL, qui voyage dans le glisser HTML5 — le type maison s'ajoute à côté et rien n'a à être décidé au départ. Un dossier, lui, réclame preventDefault() puis webContents.startDrag(), donc le geste entier. L'utilisateur ayant sftpDragOutFolders activé, le laisser prioritaire aurait supprimé en silence ce que ce volet vient ajouter. Arbitrage rendu par l'utilisateur : les deux, en deux temps — glisser un dossier le déplace ; le sortir de la fenêtre et le lâcher là démarre sa copie, et le geste suivant l'emporte. La sortie de fenêtre se lit à l'âge du dernier dragover reçu par le document.

Passe de test sur un serveur réel (machine VPN, autonomie accordée par l'utilisateur), dans /tmp/zzz-test-move/ créé pour l'occasion, rien touché en dehors. Neuf vérifications, dont les trois refus au survol — dossier visé sur lui-même, entrée lâchée dans le dossier où elle est déjà — sans le moindre écrit sur le serveur, le refus d'une collision, le déplacement à travers un lien symbolique vers un dossier, et un lien cassé qui ne déplace rien et le dit. Le curseur, lui, ne s'y vérifie pas (#66) : c'est la passe manuelle de l'utilisateur qui a validé l'usage, et qui a rapporté les deux réserves consignées en roadmap.

Trois gels du renderer avant d'y arriver, tous dus au harnais et non au plugin : piloter un glisser sur une ligne finit par appeler startDrag(), dont la boucle OLE attend une souris qui n'existe pas (#65). C'est ce qui a révélé au passage que le réglage était activé côté utilisateur, donc le conflit ci-dessus.

Dépôt depuis l'OS sur un dossier distant visé (2026-08-02)

Volet 2 du chantier Transferts SFTP, sur la branche feat/depot-sur-dossier-distant. Testé de bout en bout sur un serveur réel — pilotage par l'injecteur Angular depuis le CDP (#8), dans un dossier jetable supprimé après coup — puis validé par l'utilisateur au vrai geste, glisser depuis l'Explorateur.

Revue générale, remise en ordre des documents, et intégrité des données (2026-08-02)

Revue complète demandée sur le code, la gouvernance et les documents de production. Deux branches : chore/mise-en-ordre-doc-et-release pour ce qui était de la mise en ordre, puis fix/integrite-donnees pour le premier des trois chantiers que la revue a ouverts (#integrite-donnees).

Passe de test du 2026-08-02 — pilotée par l'assistant, à la demande de l'utilisateur

Menée dans Tabby lancé en --debug --remote-debugging-port=9333, sur des entrées grp-zzz-test-* exclusivement, avec un instantané complet de groups, profiles et sidebarPlus pris avant tout geste. L'instance vivante du composant s'atteint par getPlatform()._modules[0]._r3Injector puis les vues attachées à l'ApplicationRef — window.ng ne sert à rien, le build étant en production et ngDevMode à false. État final comparé champ à champ à l'instantané : identique.

• Re-parentage — neuf vérifications sur neuf : defaults et couleur préservés, les deux profils suivent, le sous-dossier reste favori et replié sous son nouvel id, aucun id mort laissé derrière.
• Sortie depuis « Épinglés » — le profil change bien de dossier et aucun autre weight n'est réécrit. L'ancien comportement a été rejoué sous sauvegarde pour vérifier que le test prouve quelque chose : il reclassait bien deux profils réels de l'utilisateur (Claude et app.exemple.fr). Restauré et vérifié dans la foulée.
• Dossier masqué par un workspace — le dossier paraissait vide à l'écran, la suppression est refusée, le profil masqué garde son dossier, et le message nomme le workspace en cause.
• Non-régression — un dossier réellement vide se supprime sans message ; un dossier non vide et visible est refusé avec le message d'origine, sans mention parasite du masquage.

Passe de test du 2026-08-02 sur les liens symboliques — serveur réel

Menée sur un serveur de l'utilisateur, avec son autorisation explicite, dans /tmp/zzz-test-symlink/ — répertoire créé pour l'occasion et supprimé après coup, rien touché en dehors. Une cible en 0o640, un lien vers elle, et un lien cassé.

Sept vérifications sur sept, round-trip complet inclus : c'est la cible qui part à l'éditeur, avec son mode réel 0o640 ; la copie locale est inscriptible ; le lien cassé est annoncé au lieu d'être subi ; et après téléchargement, modification et renvoi, le lien existe toujours et la cible a gardé 0o640.

La contre-preuve a été mesurée sur ce même serveur plutôt que supposée : stat() du lien rend un mode 0o0 et une date au 1970-01-01T00:00:00Z, et le chmod qu'appliquait l'ancien chemin aurait bien été 0o777.

Passe de test du 2026-08-02 sur le cycle de vie

Deux des sept points ont été exercés pour de bon, les deux visibles.

Démontage : éteindre puis rallumer le plugin, deux cycles de suite, laisse exactement une sidebar dans le DOM et une vue attachée à l'ApplicationRef. Avant le correctif, l'extinction en laissait une figée à l'écran et le rallumage en ajoutait une seconde.

Purge des temporaires : deux dossiers témoins posés à la main, l'un nommé d'après un pid mort, l'autre d'après un processus vivant, puis Tabby relancé. Le premier est purgé, le second conservé — c'est ce second cas que l'ancien repère temporel manquait, puisqu'il jugeait « antérieur au démarrage » tout ce qui précédait le renderer courant.

Transferts : montrer qu'un transfert est mort, et le servir nous-mêmes (2026-08-02)

Branche fix/transferts-interrompus. Ouverte sur le point 3 de #panneau-etat-session — « demander confirmation si un transfert est en cours au moment de la bascule » — dont la vérification a montré que la prémisse était fausse. Ce qui a été livré à la place répond au besoin réel : savoir qu'un transfert est mort.

Panneau SFTP : suivre l'état réel de la session (2026-08-02)

Branche fix/sftp-session-perdue. Porte les points 1 et 2 du chantier #panneau-etat-session : le panneau qui restait mort après une perte de connexion, et la sidebar qui rend la main aux Profils quand la session liée n'est plus exploitable. Les points 3 et 4 restent ouverts.

Glisser-déposer sortant réel, gestionnaire de transferts et réglages (2026-08-01 → 2026-08-02)

Branche feat/transferts-ui, ouverte le 2026-08-01 et mise en pause en cours de passe de test, reprise et terminée le 2026-08-02. Elle porte le volet 1 du chantier #transferts et l'aboutissement de #drag-out : le téléchargement démarre enfin au dépôt, ce que startDrag() ne permettait pas.

Renommer une entrée depuis le panneau SFTP (2026-08-01)

Demande venue en fin de session, livrée sur branche et validée dans la foulée.

Transferts officiels, fraîcheur des copies, purge et performance de la liste (2026-08-01)

Chantier #transferts-officiels mené sur branche, élargi en cours de route par ce que la passe de test a révélé. Le plan portait sur quatre volets ; trois défauts de fond, tous antérieurs au chantier, ont été trouvés en mesurant.

Ctrl+Entrée insère un saut de ligne (2026-08-01)

Premier chantier mené sur une branche depuis que l'option branches vaut branche : code et documentation arrivent ensemble sur master. Parti d'un signalement de régression du plugin, il s'est terminé en fonctionnalité — le diagnostic ayant montré qu'il n'y avait aucune régression à corriger.

Cadrage rouvert sur attribution — purge de l'attribution IA (2026-08-01)

Entretien rouvert sur cette seule clé. attribution passe de oui à non : plus aucune métadonnée d'attribution IA dans les messages de commit, et l'historique existant est purgé plutôt que laissé en l'état. Le motif enregistré au cadrage du 2026-07-31 — « revenir dessus imposerait de réécrire l'historique » — n'a pas été retenu comme suffisant : la réécriture est assumée. La trace de la collaboration reste dans les documents de gouvernance, qui la portent avec leur contexte.

Passe de test du glisser-déposer sortant (2026-08-01)

Le chantier glisser-déposer sortant, écrit le 2026-07-30, est resté deux jours sans passe de test. Entre-temps, la campagne de gouvernance a poussé master avec seize commits derrière lui : du code jamais exécuté a séjourné sur un dépôt public, ce que l'option branches tranchée le 2026-07-31 empêche désormais par construction. La passe le valide sans correctif ; elle produit en revanche trois constats d'usage, rassemblés dans un chantier dédié.

Cadrage de gouvernance du 2026-07-31 — PROFIL.md, validateur et charte 20260731-204511

Session ouverte à la racine du workspace pour relancer l'entretien de cadrage (A-15 Cas B, déclencheur « révision de la charte touchant le noyau »). Périmètre restreint à ce projet par l'utilisateur : tabby-better-vault n'est pas touché et sa branche de propagation reste non fusionnée. Le chantier Conformité de la gouvernance porte les deux items encore ouverts — audit A-15 Cas B, puis mention de conformité du pied de page, dans cet ordre.

Deux réponses de cadrage changent une pratique au lieu d'enregistrer l'existant : branches passe à branche (le projet travaillait en direct sur master) et outillage vaut oui, ce qui rend l'état « Adopté » utilisable — la classe .adopted existait dans style.css sans qu'aucun chantier ne puisse la porter. Trois dérives ont été constatées et corrigées en séance (A-5) ; elles sont décrites dans les entrées ci-dessous.

Campagne UX/sécurité du 2026-07-30 — suppression SFTP et sessions actives

Trois des quatre chantiers demandés le 2026-07-30 (suppression SFTP par Suppr, sessions actives en vue SFTP, éditeur forcé au double-clic), plus l'écart d' audit des confirmations refermé au passage — l'audit n'est pas un livrable mais un invariant à tenir. Menés directement sur master. Les deux premiers commits ont été poussés non testés ; la passe de test de l'utilisateur les a validés et a fait apparaître, sur les sessions actives, un défaut de mise en page que la correction d'origine ne pouvait pas résoudre seule. Reste de la campagne : glisser-déposer sortant.

Revue de gouvernance — mise en conformité à la charte (2026-07-29)

Revue au sens de la charte, Règle 7 Cas B : audit d'un .AIRules/ déjà au format mais qui a dérivé. Déclenchée en cours de session ordinaire, après un rappel de l'utilisateur sur une règle que je n'appliquais pas — les fichiers de .AIRules/ se commitent et se poussent à chaque mise à jour, ce qui était déjà écrit dans la charte (Règle 1) et resté lettre morte. Cette entrée acte la revue et les écarts constatés.

Tunnels SSH (2026-07-29)

Deuxième des trois chantiers de priorité moyenne attaqués d'affilée. Ouvert par une note de faisabilité avant tout code, sur le paquet tabby-ssh installé et non celui de node_modules (piège #32), aux deux niveaux typings + bundle. C'est cette vérification qui a délimité le chantier : la lecture de l'état et l'écriture en configuration sont acquises, l'action sur une session vivante ne l'est pas.

Sélection multiple (2026-07-29)

Premier des trois chantiers de priorité moyenne. Mené sur master, avec la répartition désormais habituelle : l'assistant pilote le cycle de vie de Tabby (--debug --remote-debugging-port=9333) et lit la console via CDP, l'utilisateur fait les gestes d'interface et valide point par point.

Section « Sessions actives » (2026-07-29)

Premier chantier de la liste restante, mené directement sur master. Même répartition que le chantier précédent : l'assistant lançait Tabby en --debug --remote-debugging-port=9333 et lisait la console via CDP, l'utilisateur faisait les gestes d'interface et validait point par point.

SFTP contextuel dans la sidebar (2026-07-29)

Chantier « SFTP contextuel », premier de la roadmap en priorité absolue. Mené sur la branche feat/sftp-panel, en aller-retours serrés avec l'utilisateur : l'assistant pilotait Tabby (lancement en --debug --remote-debugging-port=9333, lecture passive de la console via CDP, mesures du DOM rendu), l'utilisateur faisait les actions d'interface et validait. Design d'origine dans ROADMAP § SFTP contextuel.

Favoris d'icônes (2026-07-29)

Chantier « Favoris d'icônes » de la roadmap, enchaîné après la validation des Workspaces. Deux allers-retours avec l'utilisateur en test manuel, chacun ayant fait évoluer le design initial — détail dans ROADMAP § Favoris d'icônes.

Test manuel des Workspaces : 5 correctifs (2026-07-29)

Passe de test manuel du chantier Workspaces conduite par l'utilisateur (l'assistant en écoute passive : logs du renderer via CDP, lecture directe de config.yaml — déchiffré pour l'occasion, le coffre le rendant sinon illisible depuis l'extérieur de l'app). Trois retours, dont deux ont révélé des bugs de fond ; validé par l'utilisateur en fin de passe.

Workspaces + déblocage complet du glisser-déposer de dossiers (2026-07-28)

Chantier Workspaces de la roadmap, puis une longue chasse au bug : imbriquer un dossier dans un autre était impossible, et l'est resté à travers plusieurs correctifs successifs — il y avait trois causes indépendantes, chacune suffisante à elle seule. Détail technique dans les pièges #22 à #29.

Suite — fond des popups, distinct du fond de la sidebar (2026-07-28)

Menu contextuel enrichi — favoris, renommer, lancer (2026-07-28)

Premier chantier de la phase "extension du socle" de la roadmap, design déjà fourni par l'utilisateur. Trois actions ajoutées aux menus contextuels Profil/Groupe existants.

Diagnostic — jonction NTFS de dev manquante, plugin invisible (2026-07-26)

Signalé par l'utilisateur : le plugin n'apparaissait plus dans la liste des plugins Tabby.

Distinct : classement de recherche npm pour un paquet neuf (2026-07-26)

L'utilisateur cherchait le plugin depuis la recherche npm intégrée de Tabby, pas depuis le mode dev — confusion initiale avec le chantier ci-dessus, deux causes différentes.

Restructuration de la documentation — split roadmap → gouvernance IA (2026-07-26)

La roadmap unique (tabby_sidebar_roadmap.md) avait grossi au-delà de son rôle (historique + pièges + roadmap + points fragiles mélangés). Reprend le format déjà utilisé sur un autre projet de l'utilisateur (Travail, dossier .AIRules/) : README (index/protocole), AI-CONTEXT (invariants), AI-HISTORY (journal), ROADMAP (statut/priorités) — converti en HTML statique avec navigation commune.

Révisions de roadmap suite à consultations externes (Gemini) (2026-07-26)

Trois échanges successifs avec Gemini (Google) pour challenger la roadmap depuis une perspective dev/sysadmin/gestionnaire, plus une clarification directe de l'utilisateur.

Publication npm v0.2.0 (2026-07-26)

Fonctionnalités socle (2026-07-26)

Environnement de dev, scaffold initial, puis l'ensemble des fonctionnalités "vision" demandées : favoris, statut live, drag & drop, menus contextuels, icônes personnalisées. Détail technique complet (comportement exact, choix d'implémentation) dans les pièges correspondants d'AI-CONTEXT.html.