La vérification de faisabilité bloquante n'a pas été franchie : Tabby n'expose
aucune API d'injection du mot de passe maître (#V2).
L'utilisateur a néanmoins acté le lancement sur la base d'un monkey-patch de
VaultService.getPassphrase, mécanisme déjà employé par un plugin publié
(état de l'art). Tout repose donc sur un comportement non
contractuel de Tabby, à revérifier à chaque mise à jour.
Le plugin fonctionne et a été validé en conditions réelles le 2026-07-28, dans les deux régimes (configuration chiffrée et non chiffrée) : déverrouillage automatique, panneau de réglages, expiration du jeton, notification. Le dépôt est public ; la publication npm reste à faire (§ Publication). Plus aucune inconnue technique — #V4 et #V7 sont levés.
Cinq campagnes de vérification menées sur VM Linux entre le 2026-07-29 et le
2026-08-06, chacune trouvant puis validant des correctifs sur la précédente — détail complet dans le
registre des livrés. La condition de publication npm est
remplie depuis le 2026-08-06 : le plugin est testé sur Windows et Linux ;
macOS est accepté comme non testable plutôt qu'attendu indéfiniment (aucune machine
macOS n'a jamais été disponible pour ce projet) — un risque assumé et documenté
(détail), pas une conviction que le défaut restant n'existe
pas. Reste la mécanique avant publication effective : version, vérifications de
package.json.
Plugin Tabby indépendant : déverrouillage automatique du coffre-fort (mot de passe maître) via
délégation à l'OS (electron.safeStorage) — sorti du périmètre de
tabby-better-sidebar car hors sujet (pas une fonctionnalité de sidebar) et parce que
c'est le point le plus sensible (manipulation d'un secret utilisateur) envisagé sur l'écosystème de
plugins de l'utilisateur.
package.json, src/,
webpack.config.js), plugin fonctionnel. Dépôt distant :
github.com/TooMuhtsh/tabby-better-vault
(public).tabby-better-sidebar —
.AIRules de ce projet. Interfaçage
prévu entre les deux (voir ROADMAP.html) : lien relatif valable tant
que les deux dossiers restent côte à côte dans Développement/.| Fichier | Contenu |
|---|---|
| AI-CONTEXT.html | Invariants : l'anatomie réelle du Vault de Tabby
(pièges propres #V1–#V29, le prochain numéro libre est indiqué en tête
du fichier) et les pièges hérités du projet frère, qui partage la même stack
Tabby/Angular/Electron. |
| AI-HISTORY.html | Journal jusqu'au 2026-08-06, gelé depuis (option journal-format
tranchée hors du menu de la charte). En ajout seul tant qu'il a vécu : une entrée écrite ne se
réécrit jamais, une correction s'ajoute (A-4). |
| AI-HISTORY.log | Journal actif depuis le 2026-08-06 — texte brut, une ligne par entrée
(horodatage | CHANTIER | Commit/Hash | Explication, 250 caractères max), la plus
récente en tête. Même règle d'ajout seul. |
| ROADMAP.html | Statut et design des chantiers restants — au premier rang, le bruit du journal (priorité haute) et la granularité par profil/groupe. |
| annexes/REALISE.html | Registre des chantiers livrés (option registre-livrés, A-8) — cinq entrées au
2026-08-06, reprises verbatim depuis la roadmap au moment de leur bascule. Annexe, pas un
document principal : hors navbar. |
| PROFIL.md | Réponses de cadrage propres à ce projet — les vingt-quatre options de la partie B de la charte. S'y reporter plutôt que de redécider une convention au coup par coup. |
| GOUVERNANCE-IA.md | Copie conforme de la charte de gouvernance appliquée par ce projet (original dans le dépôt
canonique Claude-Governance). Ne pas l'adapter au projet : elle doit rester
comparable à l'original. |
| GABARITS.md | Copie conforme des gabarits de documents. Ne s'ouvre qu'au moment de créer ou restructurer un document, jamais en début de session. |
Le coffre-fort réel de l'utilisateur et son
better-vault.json réel. Tout test passe par un coffre jetable sur la VM Linux
crash-test, et toute valeur qu'un opérateur humain devra saisir est déclarée dans le
protocole avant la campagne, jamais improvisée devant une pop-up. Détail dans
PROFIL.md, options jetables et
discipline-test.
La question posée était : VaultService expose-t-il une méthode d'injection
programmatique du mot de passe maître utilisable depuis un plugin tiers ? Les deux niveaux exigés ont
été vérifiés (typings et bloc d'export webpack de dist/index.js). Réponse :
la classe est bien exportée, mais l'API d'injection n'existe pas — le cache du mot
de passe est délibérément inaccessible (#V2).
Le blocage a été remonté conformément au garde-fou, et l'utilisateur a arbitré en faveur du contournement par monkey-patch — d'où le plugin existant, fonctionnel et validé (voir le callout en haut de page). Ce qui reste valable de cette étape : le socle est un comportement non contractuel de Tabby, pas une API, donc à revérifier à chaque mise à jour de l'application.
Leçon de méthode à conserver : typings/index.d.ts ne mentionne même pas
le Vault, alors que la classe est bel et bien exportée via export * from './api'. Un
grep sur le seul index.d.ts aurait produit un faux négatif — toujours suivre les
réexports en cascade (#V1).
AAAAMMJJ-HHMMSS, donc
une simple comparaison. S'il est antérieur, signaler l'écart et proposer une
remise à niveau (A-15, cas B) — ne jamais l'appliquer d'office.Si l'état réel du code contredit un invariant d'AI-CONTEXT.html
(méthode renommée, comportement de Tabby différent, statut de chantier faux) : ne pas coder par-dessus
l'hypothèse périmée. Corriger la documentation d'abord, puis continuer. Ce projet y est
particulièrement exposé : tout repose sur le remplacement de
VaultService.getPassphrase, un comportement non contractuel de Tabby
(#V2) — une mise à jour de l'application peut invalider un
invariant sans le moindre message d'erreur.
Ne rien écrire dans ces deux pages avant que l'utilisateur ait confirmé le résultat en conditions réelles (test dans Tabby, pas une relecture de code) — pas même une ligne d'état intermédiaire du type « implémenté, en attente de test ». Un build qui passe ou un déploiement réussi ne valent pas validation. Ici le test réel est double par nature : le plugin doit être exercé en configuration chiffrée et non chiffrée, un succès dans un seul des deux régimes ne prouve rien.
Deux cadences opposées, à ne pas confondre :
MAJ porte la chaîne
complète en un geste : feu vert, documents, vérification de CLAUDE.md, commit,
push.branches) : sa
documentation l'accompagne et arrive sur master avec lui, dans le même merge..AIRules/ vit bien dans le dépôt Git du plugin (pas au niveau parent
Développement/) — leçon tirée du projet frère, où ce dossier avait été positionné au
mauvais niveau puis déplacé pour rester versionné avec le code (A-1).