Vault Inspector

Que fait Vault Inspector ?

Utilisez Vault Inspector comme une porte de qualité en lecture seule pour la maintenance d'un coffre Obsidian. Cette compétence est destinée aux workflows en terminal, CI et gérés par agent nécessitant de trouver les liens brisés, les pièces jointes orphelines, les notes vides, les liens externes, les fichiers en double, les dérives de type de frontmatter, les problèmes d'utilisation de balises et les fichiers volumineux.

Règles de sécurité

• Traitez l'interface CLI comme étant en lecture seule. Ne modifiez, ne déplacez, ne supprimez et ne réécrivez aucun fichier du coffre dans le cadre de cette compétence.
• Ne présentez pas --fix comme disponible. L'interface CLI se termine actuellement par une erreur en cas d'exécution de correction.
• Ne supprimez pas automatiquement les pièces jointes orphelines, les candidats en double ou les fichiers volumineux. Résumez les preuves et recommandez une révision manuelle.
• Ne traitez pas title, message, generatedAt ou durationMs comme des identifiants d'automatisation stables.
• Utilisez les champs stables pour l'automatisation : schemaVersion, toolVersion, summary, scannerId, severity, primaryPath, relatedPaths, evidence, fingerprint, fixAction, isNew et summary.newIssues.
• Gardez la progression de l'analyse sur stderr avec --progress ; gardez stdout lisible par machine.

Quand exécuter

Exécutez Vault Inspector :

• avant de réorganiser, publier, exporter ou archiver un coffre ;
• après des modifications de notes générées ou gérées par un agent ;
• avant et après des modifications en masse sur les liens, balises, frontmatter ou pièces jointes ;
• en CI lorsqu'un coffre ou un dépôt de documentation générée nécessite des vérifications de régression ;
• lorsqu'un utilisateur demande une analyse d'hygiène du coffre, des liens brisés, des fichiers orphelins, des fichiers en double ou des fichiers volumineux.

Commandes de base

Depuis l'intérieur d'un coffre :

vinspect . --format json

Pour une utilisation ponctuelle sans installation globale :

npx vault-inspector /path/to/vault --format json

Écrire un rapport lisible par un humain :

vinspect . --format markdown --output report.md

Exécuter des analyseurs sélectionnés :

vinspect . --scanner broken-links,empty-notes,large-files --format json

Exécuter l'analyseur de liens externes optionnel seulement lorsque les vérifications réseau sont acceptables :

vinspect . --scanner external-links --format json

Afficher la progression sans corrompre stdout :

vinspect . --format json --progress

Workflow de référence

Créer une référence :

vinspect . --format json --output .vault-inspector-baseline.json --fail-on none

Ne faire échouer que sur les nouveaux résultats :

vinspect . --baseline .vault-inspector-baseline.json --fail-on new --format json

Lorsqu'une référence est utilisée, inspectez summary.newIssues et le champ isNew de chaque problème. Signalez les nouveaux problèmes avant les problèmes connus existants.

Codes de sortie

• 0 : analyse terminée et n'a pas atteint le seuil configuré par --fail-on.
• 1 : analyse terminée et a atteint le seuil configuré par --fail-on.
• 2 : utilisation invalide de l'interface CLI ou échec de configuration de l'analyse.

Si le code de sortie est 2, signalez l'erreur de l'interface CLI et n'interprétez pas stdout comme un résultat d'analyse réussi.

Interprétation des résultats

Priorisez les résultats dans cet ordre :

1. Liens brisés et liens de pièces jointes manquantes de sévérité error.
2. Résultats warning, incluant les en-têtes manquants, les fichiers volumineux, les fichiers en double confirmés et les pièces jointes orphelines plus anciennes.
3. Résultats info, incluant les balises peu utilisées, les vérifications externes ignorées ou expirées, les pièces jointes orphelines récentes et les candidats en double.

Pour chaque résumé, incluez :

• le nombre total de problèmes ;
• les comptes par sévérité ;
• les analyseurs exécutés ;
• les problèmes à haute confiance en premier ;
• les chemins de fichiers et preuves nécessaires pour une révision manuelle ;
• les comptes de nouveaux problèmes par rapport à la référence, le cas échéant.

Évitez de surestimer la certitude. Les pièces jointes orphelines et les candidats en double peuvent être des faux positifs lorsque les fichiers sont référencés par CSS, Canvas, Dataview, des pipelines de publication ou des outils externes.

Réponse suggérée de l'agent

Utilisez ce format lors du rapport des résultats d'analyse :

Vault Inspector a trouvé <N> problème(s) : <E> erreur(s), <W> avertissement(s), <I> info.

Résultats les plus prioritaires :
- [<severity>] <scannerId> : <primaryPath> - <brève explication basée sur les preuves>

Notes :
- <note sur les nouveaux problèmes / référence si pertinent>
- <mise en garde sur la révision manuelle pour les candidats orphelins/en double si pertinent>

Si l'analyse réussit, indiquez la commande exécutée et les comptes nuls correspondants. Ne prétendez pas que le coffre est parfait ; dites que Vault Inspector n'a trouvé aucun problème correspondant aux analyseurs et filtres sélectionnés.