tabby-better-sidebar — Gouvernance IA

Ce dossier documente le plugin Tabby tabby-better-sidebar : sidebar de profils enrichie (favoris, statut live, drag & drop, SFTP contextuel à venir) construite à partir du composant profile-tree natif de Tabby.

Dépôt de code : C:\Users\Alex Ramirez\Documents\Développement\tabby-ssh-sidebar — github.com/TooMuhtsh/tabby-better-sidebar (public).
Ce dossier de gouvernance (.AIRules/) vit à la racine du dépôt, donc versionné avec le code.

Ce dossier est versionné avec le code (dans le dépôt Git de tabby-ssh-sidebar) — une reprise du développement depuis un autre PC via git clone inclut donc l'intégralité de l'historique, des pièges et de la roadmap.

Structure

Fichier	Contenu
AI-CONTEXT.html	Invariants du code déjà construit : identité du projet, pièges rencontrés (référence numérotée), points fragiles à revérifier après mise à jour de Tabby.
AI-HISTORY.html	Journal chronologique par chantier, le plus récent en tête. Chaque chantier liste ses commits (date / hash / résumé).
ROADMAP.html	Statut, priorité et détail de design complet de chaque chantier restant à faire.
annexes/REALISE.html	Registre du réalisé (option `registre-livrés`) : l'état et le détail des chantiers livrés, sortis de la roadmap active qui n'en garde qu'une ligne de renvoi.
PROFIL.md	Réponses de cadrage propres à ce projet : une ligne par option de la charte, avec son motif. 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. L'original canonique vit dans un dépôt public dédié, indépendant de ce workspace et de toute machine. Ne pas l'adapter au projet : elle doit rester comparable à l'original par un `diff`.
GABARITS.md	Copie conforme des squelettes de documents et du modèle de profil. Ne s'ouvre qu'au moment de créer ou de restructurer un document, jamais en début de session.

Le CLAUDE.md à la racine du dépôt tabby-ssh-sidebar reste la référence rapide de build/dev (commandes, jonction NTFS) — auto-chargé par Claude Code. Un CLAUDE.md à la racine de Développement/ pointe vers ce dossier pour que toute session ouverte depuis ce niveau le lise aussi.

Protocole

En début de session sur ce projet

Lire AI-CONTEXT.html pour les invariants et pièges déjà résolus.
Lire le haut d'AI-HISTORY.html pour savoir où en est le dernier chantier actif.
Vérifier l'état réel avant de faire confiance à la doc : jonction NTFS présente (%APPDATA%\tabby\plugins\node_modules\tabby-better-sidebar), build à jour (dist/index.js), git log pour les derniers commits.
Comparer l'identifiant de conformité du pied de page à celui du pied de page de GOUVERNANCE-IA.md (format AAAAMMJJ-HHMMSS, monotone : une simple comparaison de chaînes suffit, sans rien parser). Si le premier est inférieur, signaler l'écart et proposer une remise à niveau (charte, A-15, Cas B) — ne jamais l'appliquer d'office.
Ouvrir PROFIL.md pour les conventions tranchées de ce projet plutôt que d'en redécider une au coup par coup.

Règle de détection de dérive

Si l'état réel du code contredit un invariant d'AI-CONTEXT.html (méthode renommée, comportement 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.

Validation utilisateur avant de marquer "fait"

Ne pas décrire une fonctionnalité comme terminée dans AI-HISTORY.html ou ROADMAP.html avant que l'utilisateur ait explicitement confirmé qu'elle fonctionne en conditions réelles (test dans Tabby, pas seulement une relecture de code). C'est déjà la pratique suivie jusqu'ici (chaque entrée "Fait" du journal cite sa vérification CDP) — à garder systématique.

Quand mettre à jour

Deux cadences opposées, à ne pas confondre :

AI-CONTEXT.html — au fil de l'eau, sans rien demander. Dès qu'un piège technique notable est rencontré ou qu'un nouvel invariant apparaît, il est consigné immédiatement, avant même que le chantier en cours soit terminé. C'est le seul document alimenté proactivement. Quand une décision de design change, remplacer la section périmée plutôt que de l'empiler — juste l'état final et le "pourquoi" s'il est utile.
AI-HISTORY.html et ROADMAP.html — sur feu vert explicite de l'utilisateur. Aucun changement de statut, aucune décision de design actée, aucune description de correctif n'y est écrite avant qu'il ait confirmé — y compris une mention intermédiaire du type « implémenté, en attente de test ». Un build qui passe ou un test CDP réussi ne déclenchent rien ici. Exception — session qui s'éternise : quand le contexte risque d'être perdu (compactage, interruption), proposer un point de gouvernance et n'écrire que ce que l'utilisateur valide à ce moment-là.
Toute modification de ce dossier se commite et se pousse dans la foulée (charte, A-10) : une gouvernance à jour qui dort en local n'est ni sauvegardée, ni récupérable depuis une autre machine. Le feu vert porte sur l'écriture, pas sur le push.
Un chantier non abouti vit sur une branche (option branches, tranchée au cadrage du 2026-07-31) : sa documentation l'accompagne et arrive sur master avec lui, dans le même merge. C'est ce qui garantit qu'une gouvernance publiée sur master ne décrit jamais du code absent.

Ne jamais modifier les entrées déjà écrites d'AI-HISTORY.html — uniquement en ajouter en tête du chantier concerné.

Discipline de test

Toujours tester sur des entrées jetables (grp-zzz-test-*) avant toute manipulation touchant config.store.groups/.profiles, jamais directement sur les vraies données de l'utilisateur — même quand le risque semble faible (voir piège #12 dans AI-CONTEXT.html, qui a réellement corrompu la config de production une fois).