tderoussel/vault-doctor

Docteur du coffre

La plupart des coffres Obsidian n'ont ni git ni annulation, et beaucoup sont synchronisés en direct via iCloud, OneDrive ou Dropbox. Considérez chaque écriture comme irréversible. Confirmez la situation de sauvegarde réelle du coffre avant de toucher quoi que ce soit, lisez avant d'écraser, préférez les modifications ciblées aux réécritures de fichier entier, et n'exécutez jamais une boucle d'écriture rapide — sur un dossier synchronisé, elle produit des copies de conflit.

Analyse

Parcourez les fichiers .md, en ignorant node_modules, .git, .obsidian, et tous les répertoires de construction ou de bric-à-brac que le coffre a accumulés. Construisez l'ensemble des cibles de liens à partir de chaque nom de fichier (pièces jointes incluses, pas seulement les .md), puis extrayez les [[cibles]], en supprimant les suffixes |alias, #heading et ^block.

Enregistrez une ligne de base — nombre de notes, cibles cassées distinctes, total de références cassées, noms de base en double — afin que les exécutions ultérieures puissent montrer l'évolution plutôt que de répéter le même recensement.

Classifier avant de réparer

Un nombre brut de liens cassés n'est pas une liste de défauts. Classez chaque résultat dans l'un des quatre seaux suivants :

1. Références inter-systèmes — ne pas « réparer ». Certaines cibles ne sont pas du tout des notes de coffre : ID de mémoire d'agent, clés de ticket ou identifiants d'un autre outil qui se trouvent être écrits en syntaxe de wikilien. Ils ne se résoudront jamais. Les convertir en texte brut est défendable ; créer des notes factices pour les satisfaire ne l'est pas.

2. Documentation d'un lien cassé — ne jamais toucher. Certaines notes citent délibérément un lien cassé, comme exemple ou comme vérité de base pour un exercice (« si votre outil ne trouve pas cela, votre outil a tort »). Modifier ces notes casse ce qu'elles enseignent. La syntaxe de wikilien citée dans la prose relève de la même classe.

3. Dérive de nom — corriger à la cible, pas à la source. Lorsque de nombreuses références pointent vers un nom court et que la note est classée sous un nom plus long, préférez ajouter aliases: [NomCourt] dans le frontmatter de la cible plutôt que de modifier chaque fichier référencant. Une modification, un mécanisme natif d'Obsidian, aucun risque de déformer le contexte environnant.

4. Notes vraiment manquantes. La cible n'a jamais existé. Signalez-la ; ne la créez pas automatiquement. Un stub vide est pire qu'un lien cassé car il donne l'impression d'avoir une réponse.

L'interdiction du rechercher-remplacer

Ne réparez jamais les liens avec un rechercher-remplacer non cadré. Un remplacement aveugle dans tout un coffre déformera les noms de dossier, les URL, les blocs de code et les vocabulaires de balises qui contiennent par hasard la chaîne recherchée — et comme il n'y a pas d'annulation, les dégâts sont permanents. Corrigez fichier par fichier, après avoir lu la ligne environnante.

Autres vérifications

• Les noms de base en double rendent les liens ambigus dans tout le coffre, car Obsidian résout les [[liens]] par nom de fichier dans tout le coffre. Le coupable habituel est un projet de code ou une arborescence de dépendances qui vit à l'intérieur du coffre, contribuant des milliers de fichiers .md fantômes. Signalez-le ; la correction consiste à déplacer le projet hors du coffre ou à ajouter une exclusion. Ne supprimez rien sans demander.

• Le frontmatter doit réellement être analysé. Exécutez chaque bloc avec un vrai analyseur YAML — ne l'évaluez pas à l'œil. La panne dominante est un scalaire simple non entre guillemets contenant : (espace après deux-points), qui échoue à ce caractère et emporte avec lui chaque clé en dessous, rendant tout le bloc invisible pour le panneau Propriétés d'Obsidian et pour Dataview.

  Une deuxième panne courante : une valeur non entre guillemets commençant par | ou > ouvre un scalaire de bloc YAML.

  Corriger signifie ajouter des guillemets aux valeurs, ce qui, sur une note importante, peut toucher des centaines de clés — proposez-le, ne le faites jamais sans y être invité, et sauvegardez d'abord le fichier. Jusqu'à ce qu'il soit corrigé, respectez la convention existante (même cassée) plutôt que d'introduire un deuxième style ; une clé valide unique dans un bloc invalide n'apporte rien.

• Les tags doivent être dans YAML sous forme de liste, pas de hashtags en ligne — vérifiez par rapport au vocabulaire réel du coffre plutôt qu'à un vocabulaire idéalisé. Signalez les dérives ; ne re-taguez pas unilatéralement.

• État obsolète — notes portant des marqueurs PAUSÉ/EN ATTENTE/FAR dont le projet a depuis évolué. Signalez-les ; ne les résolvez pas vous-même.

• Hubs froids — une note hub dont la section d'état la plus récente est antérieure à l'activité la plus récente de son projet est obsolète. Signalez l'écart.

Sortie

Un rapport, ordonné par seau, avec des comptes et des références exactes fichier:ligne. Proposez des réparations ; n'effectuez que celles que l'utilisateur approuve.

Indiquez clairement quels résultats sont vérifiés et lesquels sont inférés du nom — une cible qui ressemble à une dérive peut être une note que l'utilisateur a l'intention d'écrire.