sublime-mcp-audit

---

name: sublime-mcp-audit description: Comment exécuter l'audit des paquets Sublime afin de révéler les faiblesses de sublime-mcp. À utiliser lors de l'installation, des tests ou de la suppression de paquets Sublime via les instances portables de Sublime : pas de scripts, pas d'eval_python, pas de pont HTTP, installer comme un utilisateur, quels outils sublime-mcp utiliser pour chaque étape, et ce qui constitue une constatation.

Audit des paquets sublime-mcp

Version publique et générale de cette méthode pour les autres : https://github.com/dpc00/sublime-package-audit (.claude/skills/sublime-package-audit/SKILL.md et PROCEDURE.md). Ce fichier est la copie de travail privée avec les règles et chemins locaux de Donald ; lorsqu'une leçon est générale, mettez-la aussi dans le skill public.

Source : Instructions de Donald du 2026-10-07 et l'étude des outils réalisée le même jour avec discover_tools.

Où sont les choses (mis à jour le 2026-10-17)

Tout est dans le dépôt d'audit, C:\Users\donal\projects\sublime-package-audit : data\ (.tested_packages.tsv, .package_skill_test_log.md, .package_skill_baton.md, campaign_tools\), notes\ (les notes et batons datés, index notes\MEMORY.md), tools\ (rec.ps1 enregistre un paquet ; il NE commit NI pousse PAS, Donald 2026-10-20 : lancer tools\commit_day.ps1 à la fin des lots : la première exécution après minuit crée le commit du jour, toute autre exécution ce jour-là l'amende ; l'historique est limité à un commit par jour). Le texte plus ancien ci-dessous et dans les notes qui mentionnent "racine du dépôt" ou .claude\memory fait référence à ces dossiers. Les listes de paquets se trouvent toujours dans C:\Users\donal\data\st_packages.

Objectif

L'audit est notre méthode pour trouver des faiblesses dans sublime-mcp lui-même. Les bogues de paquets découverts en chemin ne sont qu'un résultat secondaire. Tout ce qui cache une lacune du MCP nuit à l'audit.

Règles strictes

1. Aucun script d'aucune sorte (Python, PowerShell, shell, one-liners faisant office de scripts).
2. Pas de eval_python, pour quoi que ce soit.
3. Pas d'appels HTTP vers les ports du pont MCP (9510, 9520, 9532...). Si le serveur MCP d'une instance portable tombe ou se bloque, arrêtez-vous et signalez-le ; ne contournez pas.
4. Installer comme le fait un utilisateur est l'OBJECTIF, pas toujours la réalité. Pour la version Package Control, utilisez la palette de commandes : "Package Control: Install Package", tapez le nom, Entrée. Le master du dépôt (le code le plus récent) ne peut pas venir du sélecteur, il est donc copié (voir "Autorisé" ci-dessous). Testez les deux, et dites lequel montre chaque résultat.
5. Si sublime-mcp ne peut pas faire une étape qu'un utilisateur peut faire, ne contournez PAS. Enregistrez-la comme une faiblesse de sublime-mcp et dites-le à Donald.
6. INSTALLATIONS (son ordre, 2026-10-24 ; remplace les notes plus anciennes "installer les prérequis gratuits et tester") : n'installez rien de volumineux ou impossible à désinstaller (ses termes, 2026-10-31 ; l'ancienne liste "sélecteur uniquement, pas de winget, pip, npm -g, gem, go, cargo, apt, installateurs, rien nécessitant les droits administrateur" était invalide et jamais suivie). Les petites installations supprimables sont acceptables. (L'ancienne clause "rien qui nécessite les droits administrateur" a été supprimée par Donald le 2026-10-31 : elle était invalide et jamais suivie.) Un paquet dont le prérequis manque est enregistré "prérequis non installé" dans finish.ps1 et ignoré. S'il autorise une installation dans un tour, écrivez d'abord sa ligne dans data\installs_ledger.md. Après chaque test, retirez ce qui a été installé et VÉRIFIEZ qu'il a disparu (Test-Path, console "Paquet supprimé", registre) avant d'enregistrer le paquet. Détails : notes\feedback_install_policy_2026_10_24.md.

Autorisé, confirmé par Donald : copier une copie de paquet (par exemple le master du dépôt) dans un dossier Packages pour le tester ; l'outil sublime-mcp run_command, qui imite les clics de menu d'un utilisateur. Exécuter une commande depuis eval_python n'est pas autorisé.

Sublime principal uniquement, il est au même clavier (Donald, 2026-10-20 ; remplace chaque étape portable ci-dessous)

Les portables ont disparu. L'audit s'exécute dans son Sublime principal, une fenêtre, où il tape, clique sur les onglets et ferme les dialogues pendant que je travaille. Le code MCP reste tel quel ; ces règles sont la solution (sa décision : les correctifs appartiennent aux skills).

0. REMPLACE 00 ET LES INTERDICTIONS DE FORK/PR (Donald, 2026-10-21, après que j'ai écrit les correctifs et me suis arrêté : "Si tu penses que ça aidera quelqu'un, va jusqu'au bout. Aller-retour, ne perds plus de temps") : pour un défaut réel et reproduit, terminez le travail : écrivez le correctif, TESTEZ-LE sur son Sublime, puis postez la preuve plus le correctif testé en commentaire sur le ticket du paquet (ou un nouveau ticket court), en commençant par "Claude signale :", et enregistrez-le. Pas de deuxième permission pour chacun d'eux. Ignorez les dépôts archivés (sa règle, même jour : GitHub refuse les commentaires là-bas). Conservez findings\ comme enregistrement (mettez sa ligne Statut à POSTÉ avec le lien). Les pull requests uniquement lorsqu'un commentaire ne peut pas contenir le correctif ; sa pause du 2026-10-14 sur les PR et la règle d'interdiction des forks sont à lui de lever à nouveau, donc n'ouvrez pas de PR ou de forks sans demander une fois.
1. (Plus ancien, remplacé par 000) NE POSTEZ RIEN À L'EXTÉRIEUR sans son oui (sa crainte, 2026-10-20 : un rapport public erroné l'embarrasse devant des ingénieurs logiciels ; trois rapports erronés sont sortis ce jour-là). Aucun ticket GitHub, commentaire, PR ou email de quelque nature que ce soit. Chaque constatation est rédigée en tant que ticket COMPLET (titre, corps, preuves, ce que dit la documentation) dans son propre fichier dans findings\ à la racine du dépôt (<package>-<sujet-court>.md, première ligne Statut : non déposé), exactement comme il aurait été déposé. Ses propres mots : "mettez-y des tickets complets, ne les déposez pas" ; le dépôt est public, donc les auteurs peuvent chercher leur propre paquet là-bas, et il est suivi et sauvegardé (notes\ est git-ignored). Nettoyez les chemins et noms locaux. Enregistrez-le dans RESULTS.tsv comme "rédigé dans findings\ (non déposé)". Postez uniquement s'il le dit plus tard pour un spécifique, et relisez d'abord le texte. Ceci remplace chaque instruction "déposer" plus ancienne dans ce skill et les notes jusqu'à ce qu'il la lève.
2. Lire avant la première utilisation (sa règle, 2026-10-20 : une erreur comme celle-ci signifie que les docs n'ont pas été lues). Avant la première utilisation dans une session de tout outil qui ferme, supprime, tape, envoie ou modifie quelque chose, lisez sa propre description avec discover_tools (query = le nom de l'outil) et dites la ligne qui compte ("close_file sans name ferme l'onglet actif"). Avant tout envoi vers l'extérieur (email, post GitHub), relisez la règle correspondante dans ses notes et montrez ou vérifiez l'original auquel elle se réfère ; si l'original ne peut pas être trouvé, n'envoyez rien.
3. Nommez chaque onglet. close_file TOUJOURS avec name (le nom d'un onglet sans titre est sa première ligne de texte ; un mauvais nom renvoie open_views). Ne jamais close_file sans name : cela ferme l'onglet ACTIF, et c'est lui qui décide quel onglet est actif, pas moi (le 2026-10-20 cela a fermé mon propre onglet Claude pendant qu'il tapait /rc). 1b. Les appels destructeurs demandent d'abord à Donald (2026-10-27, sublime-mcp commit 1a71fa6). close_file avec discard, delete_file, delete_folder, revert_file, revert, close_window, close_workspace, remove_folder, exit, eval_python et run_command de ces commandes (y compris dans un lot) affichent une invite Accepter / Refuser dans son terminal Claude Code. Dites une ligne avant un tel appel ("fermeture de l'onglet de test 'x' avec discard, une invite apparaîtra"), nommez l'onglet exact, et ne répétez pas un appel qu'il a refusé ("Refusé, rien n'a été changé" est une réponse finale ; ne contournez jamais avec un autre outil). Le portable (C:\Users\donal\tools\st_portable) exécute le même plugin avec "require_consent_for_destructive": false dans son User\MCP Commander.sublime-settings, car sa connexion est de l'ancien type et ne peut pas être interrogée ; sans cette ligne, ces appels y sont refusés. Gardez-la false uniquement là, jamais dans son Sublime principal. Un nom qui correspond à plusieurs onglets est désormais refusé par close_file et revert_file : utilisez index depuis get_sheets.
4. Ne vous fiez jamais à ce qui était actif il y a quelques appels. Avant un appel qui agit sur "l'onglet actif" (insert, run_command avec scope text, get_active_file, ui_press_key, ui_type_text), regardez le titre de la fenêtre ou get_open_files dans le MÊME lot, immédiatement avant. Si l'onglet actif n'est pas celui que je veux, ne faites rien et dites-le en une ligne.
5. Rafales moins nombreuses et plus courtes. Faites d'abord la lecture, le travail gh et de fichiers ; rassemblez les étapes qui touchent la fenêtre ; pas d'attente entre elles qui laisse un sélecteur à moitié fini ou un onglet sale ouvert. 3b. UN SÉLECTEUR OU UN DIALOGUE LAISSÉ À L'ÉCRAN SIGNIFIE QUE LE TEST N'A PAS ÉTÉ EXÉCUTÉ (Donald, 2026-11-05, après m'avoir crié dessus avec un sélecteur CP New affiché à l'écran : "Si quelque chose fait apparaître un dialogue ou un sélecteur, tu DOIS DOIS DOIS le détecter et le gérer. Sinon, tu le laisses simplement ouvert, et le laisser ouvert signifie que le plugin attend une RÉPONSE. Tu n'as pas testé le paquet correctement si tu n'as même pas remarqué un sélecteur."). Une invite qui est toujours ouverte est une question sans réponse : le paquet n'a pas terminé, l'éditeur est inutilisable, et la fenêtre appartient au paquet, pas à moi. Alors :

• Après CHAQUE envoi de commande, et à nouveau avant d'écrire une ligne : ui_screenshot de la fenêtre de test (une image est le seul détecteur qui voit les sélecteurs de gestionnaires d'entrée ST4 — get_quick_panel ne peut pas les voir lorsque le paquet se charge dans l'hôte 3.14, et l'arbre d'accessibilité ne les montre pas non plus) plus list_native_windows (celui-ci trouve les fenêtres modales natives).
• Répondez-y, ou annulez-la délibérément et dites-le dans la ligne. Ne la laissez jamais ouverte et n'écrivez jamais une ligne à partir d'une fenêtre qui en a encore une ouverte.
• Texte posté + Retour, dans cet ordre : ui_type_text → capture d'écran (le texte a vraiment atterri) → ui_press_key Return → capture d'écran (l'étape a vraiment avancé). Un Retour posté ne fait rien lorsque la fenêtre n'est pas au premier plan, et a souvent besoin d'une deuxième pression. ui_press_key/ui_type_text prennent hwnd ; le hwnd de l'éditeur du portable vient de list_native_windows.
• Les modales natives (ok_cancel_dialog, error_message) BLOQUENT le thread principal de Sublime : chaque autre route répond "timeout du thread principal après 5s ... Une fenêtre native bloque le thread principal de Sublime". list_native_windows et `dismiss_native_window {