Registre des livrés

Annexe de Roadmap → Registre des livrés. Dernière revue : 2026-08-07

Ce registre ne porte que l'état d'un chantier déjà livré — le design retenu au moment de la bascule, repris ici sans être réécrit. Ce qui reste à faire vit dans ROADMAP.html ; l'événement daté de chaque livraison vit dans AI-HISTORY.html, que cette page renvoie sans répéter. Le plus récent chantier livré est en tête — l'inverse de l'ordre du journal.

Granularité par profil — livré le 2026-08-07

Exclure des profils SSH du déverrouillage automatique : pour un profil exclu, le plugin ne sert pas la passphrase et laisse la pop-up native de Tabby demander le mot de passe, pour cette connexion-là seulement. La « voie médiane » retenue à l'arbitrage du 2026-08-07, après que la passe de faisabilité a montré que le « déverrouillage paresseux » de la fiche d'origine était structurellement impossible en config chiffrée et déjà natif en config claire. Conçu, codé (trois lots parallèles + fondation), testé et validé le même jour.

Les arbitrages, tels que tranchés par l'utilisateur

• Ids de PROFIL uniquement, jamais de groupe — le groupe n'est qu'un raccourci d'interface qui applique l'exclusion à ses membres au moment du clic. Le re-parentage côté sidebar (nouvel uuid, piège hérité #12) ne peut donc rien invalider, par construction.
• Profils built-in hors périmètre — seuls les profils SSH de config.store.profiles sont excluables ; le nettoyage des orphelines reste synchrone.
• Passphrases de clés privées hors périmètre — indexées par hash de fichier, une clé partagée serait indistinguable.

Le mécanisme, tel que livré

• Store — excludedProfiles dans better-vault.json (#V11), helpers isProfileExcluded / setProfilesExcluded (lot = raccourci groupe) / pruneExcludedProfiles. writeSettings() préserve désormais les clés inconnues : une version antérieure du plugin n'efface plus les champs qu'elle ignore.
• Interception — ProfileExclusionsService enveloppe loadPassword(profile, username) de PasswordStorageService, dernier point où l'identité du profil existe (elle est réduite à {user, host, port} juste après). Profil exclu → fenêtre de délégation runWithNativePrompt() du pont, compteur et non booléen, cas limites du single-flight documentés dans le code. Toute anomalie vaut « non exclu » : une entrée illisible n'empêche jamais un déverrouillage.
• Acquisition par l'injecteur seul — multi-provider ProfileProvider de tabby-core, entrée ssh, champ passwordStorage. Jamais de require('tabby-ssh') : voir #V30, le bug critique que la première passe de test a attrapé (patch posé sur un singleton jumeau, jamais déclenché). Plus aucune dépendance de chargement sur tabby-ssh.
• Réglages — sous-onglets internes « Général / Profils exclus » (motif de la sidebar), l'onglet des exclusions disparaît avec l'interrupteur du plugin. Profils groupés, bascule par profil, bouton de groupe unique (« Tout exclure / Tout réintégrer ») dérivé de l'état des membres, groupes pliables à état mémorisé (localStorage, betterVaultExclusionsCollapsed). Texte des limites sans adoucissement : pas un cloisonnement des secrets, boot en config chiffrée toujours automatique, clés privées non couvertes, groupe = instantané. Purge des orphelines à l'ouverture du panneau — seul endroit où la config fait référentiel, jamais sur le chemin du déverrouillage.
• Pont inter-plugins — contrat BetterVaultExclusions:v1 sous clé de chaîne (src/exclusionsBridge.ts) : isExcluded / setExcluded (lot) / excludedIds, implémentation useValue à replis sûrs. Seuls le jeton et l'interface se dupliquent côté sidebar ; l'entrée de menu contextuel est un chantier sidebar, non commencé.

Validation du 2026-08-07

Passe pilotée par l'injecteur (CDP), données jetables grp-zzz-test-* nettoyées après coup : chargement, pont, écriture/persistance à travers un redémarrage, préservation d'un champ inconnu, profil non exclu servi par jeton (56–111 ms, zéro modale), profil exclu → pop-up native + deux lignes de journal attendues, annulation propagée nativement, fenêtre de délégation refermée derrière elle. Passe visuelle validée par l'utilisateur (onglets, liste, pliage). La première passe a levé le défaut critique consigné en #V30, corrigé et revalidé dans la même session.

Panneau de réglages unifié « Better Tabby » — livré le 2026-08-07

Quand plusieurs plugins de la famille « Better * » sont installés, un seul onglet Better Tabby apparaît dans les réglages Tabby, à deux niveaux : un onglet par plugin, les sous-onglets internes d'un plugin (Général/Fonctionnalités/Snippets côté sidebar) au niveau du dessous, une page plate (ce plugin) affichée directement. Seul de sa famille, chaque plugin garde son onglet solo, sans habillage. Conçu, codé et validé le même jour — cinq vagues de tests, 25/25, y compris poids inversés : ce plugin sait héberger la sidebar, le mécanisme est entièrement symétrique.

Le mécanisme, tel que livré

• Contrat dupliqué, jamais d'import npm : chaque plugin expose sa contribution sous la clé de chaîne BetterPanelContribution:<id> dans les providers de son module (src/betterPanel.ts, liste des tokens connus codée en dur — un futur « Better X » s'y ajoute dans chaque dépôt).
• Élection par hostWeight minimal (égalité départagée par id alphabétique) : sidebar = 10, vault = 20, espacés de 10.
• Retrait du non-hôte par getComponentType() → null — le filtre officiel du constructeur de SettingsTabComponent ; le provider reste toujours enregistré, car SettingsHotkeyProvider parcourt tous les providers sans ce filtre (un useFactory rendant null l'aurait fait planter). Conséquence assumée : un hotkey fantôme « Open settings tab: Better Vault » subsiste côté non-hôte.
• Hébergement : l'hôte élu d'une famille de plusieurs rend son src/components/hostPanel.component.ts, qui monte chaque contribution — la sienne comprise — par NgComponentOutlet avec un injecteur portant le jeton BetterPanelEmbedded ; les pages embarquées lâchent leur content-box et ne montent jamais les autres. L'onglet unifié prend l'id better-tabby.
• Deep-link croisé : un plugin vise son propre onglet du panneau partagé en posant openRequested = true sur sa contribution (objet partagé tel quel via l'injecteur) — l'hôte, quel qu'en soit le porteur, le lit et l'efface à sa construction.

Corrigé en passant

@HostBinding('class.content-box') true sur le panneau de réglages était une coquille : un champ littéralement nommé true, de valeur undefined — la classe n'avait jamais été réellement appliquée (vérifié dans le bundle compilé). Remplacée par contentBox = !embedded ; l'application réelle en solo, changement d'apparence, a été validée à l'œil (vague 2).

Limites consignées, non bloquantes

• Le bouton « désactiver » de l'onglet Plugins de Tabby fausse l'élection : il blackliste les services sans décharger le module, le token de contribution reste visible et plus aucun onglet Better ne s'affiche. Amélioration possible : faire consulter pluginBlacklist par l'élection. En attendant, écarter un plugin de la famille se fait en retirant sa jonction.
• Ce panneau hébergeant une famille de plusieurs n'arrive que si un membre de poids supérieur à 20 existe un jour — vérifié en poids inversés précisément parce que le cas nominal ne l'exerce pas.

L'événement daté et les commits vivent dans AI-HISTORY.log (branche feat/panneau-unifie, fusionnée avec cette documentation).

Correctifs issus de la 3ᵉ campagne — priorité absolue

Le plan ci-dessous a été arrêté le 2026-08-01, après revérification des dix constats un par un contre les sources — tous tiennent, et les mécanismes sont ceux que le rapport décrit.

Les quatre lots

1. Le jeton détruit — écrit le 2026-08-02, non exercé (7608323). Le catch de déchiffrement de serveFromToken() ne purge plus. La purge se justifie là où on a une preuve positive que le jeton est faux — échéance dépassée, échec PBKDF2 — et ces deux chemins existent déjà et purgent correctement. Un blob qu'on ne sait pas déchiffrer est un problème de trousseau, pas de jeton. Pire cas si on ne purge plus : un déchiffrement raté par démarrage sur un jeton réellement corrompu, révocable depuis les réglages. Strictement meilleur que détruire un bon jeton.
2. Écriture du fichier — écrit le 2026-08-02, non exercé (9a67513). Quatre constats, un seul geste sur writeSettings(). Le temporaire à nom fixe est plantable en lien symbolique : writeFileSync écrit à travers le lien et renameSync déplace le lien lui-même, si bien que better-vault.json devient un lien et que le jeton atterrit hors du dossier de config — le chmod suit lui aussi vers la victime. Un dossier en lecture seule fait échapper un EACCES non rattrapé, le try ne couvrant que rename : la cible préexistante reste en 0666 avec son ancien contenu, sans une ligne de journal. Le resserrage des droits est postérieur à l'écriture du contenu (82 250 observations du temporaire en 0666 avec charge utile). Et strace compte zéro fsync. Correctif : unlink puis création en wx — échoue si le temporaire existe, lien compris, et garantit un fichier neuf donc le mode 0600 appliqué à la création — le tout sous try qui journalise. Deux commentaires du code deviennent faux et tombent avec : « le fichier qui atterrit est TOUJOURS un fichier neuf » et « quel que soit l'état antérieur, il ressort en 0600 ».
3. Lisibilité — écrit le 2026-08-02, non exercé (d72c669). Le motif d'échec déversait String(e) tel quel, soit neuf lignes dont sept de pile Node, à l'écran et au journal, pour un utilisateur qui vient simplement de refuser une authentification. Les dates suivent la locale du système et non celle de Tabby (toLocaleString() sans argument, cinq sites) alors que Tabby fournit TabbyFormatedDatePipe. Après un refus, le bouton de récupération est inopérant pour toute la session — l'OSCrypt de Chromium mémorise son échec pour la vie du processus, et learnFromUser ne peut alors plus rien enregistrer : il faut le dire à l'écran, puisque le redémarrage de Tabby est le seul remède. Et withSafeStorage() ne teste que if (!safeStorage), jamais l'existence des méthodes.
4. Outillage — écrit et validé le 2026-08-02 (405b67d). lint:i18n ne lisait jamais TABLES : sa liste de langues est codée en dur et le script n'ouvre pas src/i18n/index.ts. Une table écrite mais non enregistrée, ou enregistrée sous un code invalide ('fr' au lieu de 'fr-FR'), passerait au vert. Collision latente à traiter dans le même geste : la clé 'Cancel' est aussi un msgid de Tabby, et la greffe fusionnant, notre valeur écrase celle de Tabby pour toute l'application. Sans effet aujourd'hui — les valeurs coïncident dans les trois langues — et non surveillé.

Deux sujets de conception, pas des correctifs

Internationalisation — interface traduite, journal en anglais

Fait le 2026-08-01, sur la branche feat/i18n-ui — priorisé le 2026-07-29 devant la granularité par profil, motif donné par l'utilisateur : « à l'usage c'est ce qui est le plus important maintenant, le reste c'est du bonus ». Validé en conditions réelles sur Windows 11 le jour même, fusionné dans master, puis vérifié sur Linux par la 3ᵉ campagne. Testé sur Windows & Linux ; macOS accepté comme non testable le 2026-08-06 (voir correctifs-c3), même règle ici.

Ce qui a été décidé, et qui n'était pas décidé au départ

La demande du 2026-07-29 portait sur « les cinq langues les plus utilisées, journal d'audit compris ». Les deux termes ont bougé le 2026-08-01, sur décision de l'utilisateur :

• Quatre langues, pas cinq : fr-FR, en-US, es-ES, de-DE. La cinquième n'a pas été choisie faute de pouvoir la justifier. La mesure faite ce jour-là — taux de complétion des 24 .po livrés par Tabby — ne discrimine pas : dix-huit locales sont à 100 %, et elle n'écarte que en-GB (3 %), pt-PT (71 %) et da-DK (78 %). Elle ne dit rien de l'usage réel. Ajouter une langue plus tard ne coûte qu'une table.
• Le journal n'est pas traduit : il passe en anglais fixe. La réserve posée en amont — un fichier persistant dont la langue suivrait la locale devient incohérent et incherchable — a été tranchée dans ce sens plutôt que par des codes d'événement. Pas de changement de format du journal, donc.

Ce que la réalisation a appris — quatre pièges consignés

Aucun n'avait été anticipé par la préparation de ce chantier, et deux d'entre eux sont silencieux par construction. Voir AI-CONTEXT.html :

• #V19 — enregistrer une traduction avant Tabby fait sauter le chargement de ses propres .po : toute l'interface de Tabby serait restée en anglais, pas seulement celle du plugin. Le défaut ne se voit qu'en regardant Tabby ; c'est ce qui rend le point 2 du protocole de test indispensable.
• #V20 — TranslateService est typé any, contrairement au reste de tabby-core, et c'est justement le membre le plus dangereux qui n'était pas vérifié.
• #V21 — la chaîne source est la clé, et le piège ICU de l'apostrophe collée à une accolade, que le français déclenche naturellement.
• #V22 — ce qui est écrit sur disque ne se traduit pas : le témoin du garde-fou portait une phrase française, il porte désormais un identifiant.

Reste à faire

• Une cinquième langue — écartée le 2026-08-14, décision de l'utilisateur : quatre langues suffisent, l'anglais servant de repli. L'ajout resterait mécanique (le validateur refuse une table incomplète) si la décision était un jour rouverte.

Troisième campagne — menée le 2026-08-01

Changements de protocole — issus des deux campagnes précédentes

• Toute valeur que l'opérateur devra saisir est écrite dans le protocole AVANT la campagne. Deux ici, et il en faut bien deux : la phrase maîtresse du coffre de test, vault1, avec laquelle la fixture config.yaml est fabriquée ; et la phrase volontairement fausse du scénario D2, wrong2. Déclarer la première sans la seconde reviendrait à faire improviser la seconde. Courtes — voir la seconde révision ci-dessus pour pourquoi c'est méthodologique.
• L'opérateur ne saisit rien qui ne figure pas dans le protocole. Si une instance lui demande une valeur non prévue, la réponse est de refuser et de le signaler — pas d'improviser.
• L'effacement des traces se fait par instantané de VM, jamais par une purge que l'instance lancerait elle-même — consigne inversée après la campagne 3, qui a réfuté la précédente. L'instance se contente de déclarer où elle écrit.
• L'opérateur humain reste dans la boucle pour toute saisie GUI. C'est ce qui a permis d'exercer learnFromUser de bout en bout, resté non testé lors de la première campagne. À reconduire tel quel.
• Aveuglement maintenu : clone sans .AIRules/, CLAUDE.md, .tempfiles/ ni .git. Rappeler le faux positif attendu — des renvois vers .AIRules/ dans les commentaires, qui résolvent dans le dépôt réel.

Périmètre, par ordre de priorité

1. D4 — le témoin comme verrou global entre processus. Jamais mesuré, à mesurer d'abord. guardState() conclut à la suspension sur la seule présence du fichier, et depth ne compte qu'au sein d'un processus. Deux fenêtres Tabby ouvertes en même temps devraient donc voir la seconde se refuser le trousseau et journaliser une suspension fictive. Observable attendu si le défaut est réel : une ligne CRIT … accès au trousseau suspendu sans qu'aucun blocage réel n'ait eu lieu, et un déverrouillage automatique qui échoue dans la seconde fenêtre alors que le trousseau est déverrouillé. Mesurer avant de redessiner : c'est une piste tirée du code, pas un constat.
   Le dispositif lui-même n'est pas acquis : rien ne garantit qu'une seconde instance concurrente soit atteignable, ni que le module du plugin s'instancie une fois par renderer. Si le banc ne peut pas être monté, le verdict est « non testé », avec la raison — jamais « aucun défaut trouvé ». Un dispositif qui ne tourne pas ne prouve rien.
2. Le correctif de D1, dans le scénario exact qui l'a révélé. Trousseau verrouillé, plugin activé, jeton en place → blocage → fermeture forcée → relance → état « suspendu » → clic sur « Lever la suspension et vérifier ». Trois issues à distinguer, et les trois comptent :
   • l'opérateur répond à l'invite d'authentification → la vérification doit réussir, le panneau afficher un trousseau vérifié, et le démarrage suivant se passer normalement ;
   • l'opérateur rejette l'invite → la vérification doit échouer avec un motif lisible, sans laisser le plugin dans un état où il repartirait vers un blocage certain ;
   • l'opérateur ne répond pas du tout → Tabby bloque, le témoin doit avoir été posé, et le démarrage suivant doit retrouver l'état « suspendu ». C'est le cas qui vérifie que l'exception délibérée de keychainRoundTrip() ne rouvre pas le trou.
   Le défaut à guetter : que le bouton annonce un succès sans que rien n'ait été chiffré. C'était exactement D1.
3. Le correctif de D2. Saisir une phrase erronée dans la pop-up native, sur un coffre dont la vraie phrase est connue. Attendu : aucun jeton écrit, aucune notification de succès, et une ligne WARN le mot de passe saisi n'ouvre pas le coffre — non enregistré. Puis saisir la bonne phrase et vérifier que le chemin nominal fonctionne toujours — le risque d'un contrôle ajouté est qu'il refuse aussi le cas valide.
4. Non-régression des cinq revendications déjà validées. Le code a changé depuis : osKeychain.ts, vaultBridge.service.ts et le panneau de réglages ont tous été touchés. Rejouer les mesures de la deuxième campagne, pas les relire.
5. Le refus du backend basic_text, non rejoué la deuxième fois. La branche Linux de keychainStatus() a été modifiée depuis sa dernière vérification : le garde-fou doit toujours refuser, avec son motif explicite.

Hors périmètre, et pourquoi

• Windows (DPAPI) et macOS — pas la bonne machine. Reste le plus gros angle mort du projet : c'est là que keychainStatus() emprunte le chemin isEncryptionAvailable() seul, donc là où il engage davantage que sur Linux.
• La non-synchronisation du jeton — exige deux machines et la config sync active.
• L'atomicité sous coupure réelle — déduite de rename(2). La mesurer supposerait de couper l'alimentation de la VM au bon moment ; le rapport coût/information est mauvais tant que rien ne suggère un problème. La campagne a ajouté un fait à ce sujet : strace compte zéro fsync. L'atomicité mesurée est celle du rename face à un lecteur concurrent, pas face à une coupure — ce ne sont pas les mêmes garanties, et le code n'en offre qu'une.
• L'i18n — pas encore écrite au moment d'écrire ce périmètre. Elle l'a été le 2026-08-01 avant le lancement, et un sixième point a donc été ajouté au protocole.

Deuxième campagne — résultats (2026-07-29)

Menée sur la VM remise au propre, avec un opérateur humain pour toute saisie GUI — c'est ce qui a permis d'exercer enfin learnFromUser de bout en bout, resté non testé la première fois faute d'injection clavier atteignant le renderer de Tabby. Banc Electron 38.8.6 identique à celui de Tabby, dbus-monitor comme instrument indépendant du plugin, CDP en lecture seule pour mesurer le blocage du renderer plutôt que le constater à l'œil.

Les cinq revendications tiennent

• « L'appel ne revient jamais, sans afficher de dialogue » — RÉFUTÉ sur ses deux termes. Le système affiche une invite d'authentification, et l'appel rend la main en 4 à 7 secondes dès qu'on y répond. C'est une invite bloquante, pas un gel irrécupérable. Le garde-fou reste nécessaire — un utilisateur absent bloque indéfiniment, et c'est le cas nominal d'un démarrage — mais la nuance rend praticable une vérification réelle déclenchée par l'utilisateur. Corrigé partout : #V17, les deux README, les commentaires de keychainGuard.ts et osKeychain.ts.
• D1 — la vérification du panneau ne vérifiait rien, et réarmait le gel. Sévérité haute. « Lever la suspension et vérifier » appelait keychainStatus(), qui sur Linux ne lit que le nom du backend — l'appel dont la même campagne mesure qu'il ne touche jamais le trousseau. Sur trousseau verrouillé, le bouton annonçait « disponible », effaçait le témoin, et le démarrage suivant regelait à l'identique, mesuré. La garantie « le premier blocage est le dernier » tenait face à un utilisateur passif et était annulée par le seul chemin de sortie que le plugin lui-même désigne. Le raccourci Linux introduit le matin pour retirer un appel bloquant du chemin de démarrage est exactement ce qui a vidé la vérification de sa substance — une optimisation correcte à un endroit, ruineuse à un autre. Corrigé par keychainRoundTrip() : aller-retour chiffrement/déchiffrement réel sur une valeur jetable, réservé aux actions explicites de l'utilisateur.
• D2 — enregistrement annoncé sans validation. Une phrase erronée était chiffrée, écrite et annoncée « enregistrée » pendant que Tabby affichait BAD_DECRYPT pour la même saisie. passphraseOpensVault() existait et servait déjà dans serveFromToken() ; learnFromUser() ne l'appelait pas. Corrigé, voir #V18.

Signalé, non corrigé

• D3 — le jeton chiffré est déterministe. Deux chiffrements de la même phrase donnent un résultat identique octet pour octet : l'OSCrypt de Chromium utilise une IV fixe. Propriété de la plateforme, pas du plugin. Qui lit better-vault.json à deux dates sait si le mot de passe maître a changé, sans rien déchiffrer. Le fichier est en 600, l'exposition est faible : dit dans les README, pas corrigé côté plugin — il n'y a rien à y corriger.
• D4 — le témoin est un verrou global, non réentrant entre processus. NON MESURÉ. guardState() conclut à la suspension sur la seule présence du fichier, et depth ne compte qu'au sein d'un processus. Deux fenêtres Tabby démarrant ensemble verraient donc la seconde se refuser le trousseau et journaliser une suspension fictive. À exercer avant de redessiner quoi que ce soit : c'est une piste issue du code, pas un constat. Premier point de la troisième campagne.

Toujours non exercé

• Windows (DPAPI) et macOS — une seule machine Linux. C'est là que le chemin isEncryptionAvailable() seul est emprunté, getSelectedStorageBackend n'existant pas ; donc là où keychainStatus() engage davantage que sur Linux.
• Le refus du backend basic_text — non rejoué cette fois (exigerait --password-store=basic). Vérifié lors de la première campagne.
• La non-synchronisation du jeton — exige deux machines et la config sync active.
• L'atomicité sous coupure réelle — déduite de rename(2), jamais provoquée.
• Le blocage en écriture (learnFromUser sur trousseau verrouillé) — couvert par déduction depuis la mesure de encryptString, pas par une exécution Tabby dédiée.
• Expiration sliding/never, rétention du journal — hors du périmètre imposé.

Campagne de vérification indépendante (2026-07-29)

Une instance externe, sans accès à .AIRules/, à CLAUDE.md ni à l'historique Git, a mené une vérification adversariale sur Ubuntu 24.04 / GNOME / X11, Tabby 1.0.235, Electron 38.8.6. Périmètre imposé : stockage interne et garde-fou du trousseau. Rapport intégral, 516 lignes de mesures : RAPPORT-TEST-LINUX.md — commandes reproduites, tableaux de résultats, et les six pistes de son § 8. Les conclusions sont ci-dessous ; l'annexe ne porte que le détail qui les étaye (A-8).

Sa méthode mérite d'être notée pour être rejouée : plutôt que de raisonner sur le code, elle a compilé et exécuté les vrais store.ts et osKeychain.ts dans un banc Electron 38.8.6, en interceptant @electron/remote et en redirigeant configDir() vers un dossier jetable — puis a validé la causalité par une expérience de contrôle (plugin retiré, condition maintenue).

Ce que la campagne n'a pas pu exercer

À reprendre dans une campagne ultérieure — ce sont des non testés, pas des conformes :

• La capture du mot de passe depuis la pop-up native (learnFromUser), de bout en bout. L'injection clavier XTEST n'atteint pas le moteur de rendu Chromium de Tabby (les clics passent, les touches non) ; la campagne a contourné en fabriquant les jetons. Les briques (encrypt, writeToken) sont vérifiées, l'enchaînement par l'interface ne l'est pas.
• La non-synchronisation du jeton — exige deux machines et la config sync active.
• Windows (DPAPI) et macOS — hors plateforme ; c'est là que le chemin isEncryptionAvailable seul est emprunté, getSelectedStorageBackend n'existant pas.
• La notification in-app — attestée par le journal, jamais observée à l'écran.

Faux positif à ne pas reprendre : le rapport signale des renvois morts vers .AIRules/ dans le code livré. C'est un artefact du dispositif de test — le dossier avait été retiré du clone pour préserver l'aveuglement. Dans le dépôt réel, ces renvois résolvent.

Panneau de réglages et politique d'expiration — livré le 2026-07-28

Onglet « Better Vault » dans les paramètres de Tabby (SettingsTabProvider de tabby-settings, composant Angular avec template Pug inliné — piège hérité #3).

Expiration du jeton

Trois modes, l'échéance étant recalculée à chaque enregistrement de mot de passe :

Cas limites vérifiés sur le calcul : un jeton créé le lundi à 2 h expire le jour même à 3 h (pas une semaine plus tard) ; à 3 h pile ou après, il vise le lundi suivant. Passage d'année et changement d'heure traités — tout est calculé en heure locale.

Un jeton enregistré avant qu'une politique d'expiration n'existe se voit attribuer une échéance au premier usage suivant, sans quoi il resterait éternellement valide alors que les réglages affichent une échéance.

Transparence — notification à l'enregistrement

À l'instant où le mot de passe est confié à l'OS, une notification l'annonce : où il est stocké, jusqu'à quand, et comment le révoquer. Un plugin qui capte un secret ne doit jamais le faire en silence — l'information doit atteindre l'utilisateur au moment où elle le concerne, pas dormir dans un panneau de réglages qu'il n'ouvrira peut-être jamais.

Affichée via ToastrService (ngx-toastr), avec un délai allongé à 12 s : le message compte trois informations à lire. ngx-toastr doit rester external dans webpack — Tabby le pré-cache (#V8) et sert sa propre instance, seule reliée au conteneur de toasts réellement affiché. Le bundler n'ayant pas de paquet à résoudre, il est installé en devDependency pour ses seuls typages, avec @angular/platform-browser qu'il réclame en peer.

Réglages par machine

Aucune mécanique dédiée n'a été nécessaire : better-vault.json étant strictement local et jamais synchronisé (§ Stockage), chaque machine a naturellement ses propres réglages. Un poste fixe peut garder le mot de passe une semaine pendant qu'un portable le redemande chaque jour, et l'exclusion d'une machine se fait simplement en la laissant désactivée.

• Exclure une machine — interrupteur « Activer sur cette machine ».
• Expiration propre à la machine — chaque poste a sa politique.
• « Oublier maintenant » — purge immédiate du jeton, sans attendre l'échéance.
• Nommer la machine — libellé indicatif (défaut : nom d'hôte), repris dans le journal pour savoir de quel poste vient une trace.

Journal d'audit et notifications — livré le 2026-07-28

better-vault.log est un véritable historique d'événements de cycle de vie : savoir quand le coffre a été ouvert, quand un jeton a expiré, quand un garde-fou s'est déclenché. Emplacement tranché par l'utilisateur : le fichier dédié existant, et non le flux natif de Tabby — choix confirmé par le code, LogService ne fabriquant qu'un ConsoleLogger qui écrit dans la console DevTools, sans rien persister.

L'invariant de sécurité s'applique sans exception : le mot de passe en clair n'est jamais journalisé, ni sa longueur. Seuls des événements anonymes sont tracés.

Ce qui est en place

• En-tête de session horodaté ISO à chaque démarrage.
• Nom de la machine, état actif/inactif du plugin et backend de trousseau retenu, à l'installation.
• Déverrouillage automatique réussi ; vérification du jeton ; jeton illisible.
• Jeton arrivé à échéance et purgé ; échéance appliquée à un jeton qui n'en avait pas.
• Enregistrement d'un mot de passe, avec la date d'échéance calculée.
• Trousseau indisponible, avec la raison exacte (dont le refus de basic_text).
• Révocation manuelle : « Oublier maintenant » journalise manual revocation from the settings — token deleted (settingsTab.component.ts, forgetNow()).
• Horodatage absolu par ligne — stamp()/writeLine() dans src/logger.ts, et non un délai relatif au démarrage.
• Niveaux de sévérité INFO/WARN/CRIT (Level, src/logger.ts).
• Changements de configuration : activation/désactivation du plugin, changement de politique d'expiration (settingsTab.component.ts, persist()).
• Plafonnement du fichier : rétention par date au démarrage (applyRetention()), doublée d'un plafond de taille fixe et non configurable (HARD_SIZE_LIMIT, 4 Mo) qui tronque par la fin même en cours de session — la purge par date, elle, ne tourne qu'au démarrage.

Deux réserves à ne pas perdre de vue