tzzs/storops

Que fait storops ?

Voyez où va votre stockage. Comprenez pourquoi. Déplacez ce qui compte. Nettoyez ce qui ne sert pas.

StorOps n'est ni un scanneur de disque, ni un nettoyeur de disque. WizTree répond déjà à la question "qu'est-ce qui prend de l'espace ?" — StorOps répond à ce que ces éléments sont, s'il est sûr d'y toucher, et exécute un nettoyage ou une migration en toute sécurité une fois que l'utilisateur donne son accord. Raisonnement complet dans docs/DESIGN.md.

Ce fichier définit comment un agent doit se comporter lorsqu'il utilise StorOps — pas seulement quelles commandes existent. Préférez suivre les workflows ci-dessous plutôt que d'appeler les commandes au coup par coup ; l'utilisateur ne devrait pas avoir besoin de connaître les noms des commandes.

Règles non négociables

1. Analyse avant action. Toujours scanner/inspecter/identifier avant de proposer quoi que ce soit, et ne jamais passer directement à une opération d'écriture.
2. Tout est en lecture seule par défaut. storops scan, storops inspect, storops search, storops identify, storops cleanup plan et storops migrate plan ne modifient jamais le système de fichiers — exécutez-les librement, sans demander d'abord.
3. Ne jamais deviner ce qu'est un chemin d'après son nom. Seul storops identify (basé sur rules/*.yaml) détermine la catégorie/risque/supprimabilité. Un chemin sans règle correspondante revient comme unknown / critical — traitez cela comme "ne pas toucher", pas comme une invitation à raisonner sur le dossier à partir de son nom.
4. Ne jamais considérer le mot "cache" ou "temp" dans un nom comme une autorisation de supprimer. N'agissez que sur ce que storops identify/storops cleanup plan a réellement classifié.
5. Les chemins à risque critique (Windows, Program Files, fichiers système inconnus, documents utilisateur) ne sont jamais proposés pour suppression ou migration. Ceci est appliqué dans le code (assert_not_critical dans src/storops/core/risk.py), pas seulement par convention — n'essayez pas de contourner cela.
6. Chaque opération d'écriture (storops cleanup execute, storops migrate execute) nécessite d'abord la confirmation explicite et détaillée de l'utilisateur, et le CLI lui-même refuse de s'exécuter sans --confirm. Montrez le plan, attendez un vrai "oui", puis passez --confirm — ne le faites jamais à la place de l'utilisateur de manière préemptive.
7. Si une application peut être en cours d'exécution, ne déplacez pas ses données. storops migrate plan signale RequiresAppClosed ; storops migrate execute refuse de s'exécuter sans un accusé de réception --app-closed explicite dans ce cas. Dites à l'utilisateur de fermer l'application — ne supposez pas qu'elle est fermée et ne tuez pas le processus vous-même.
8. Pour les données volumineuses et re-téléchargeables de modèles IA/cache (cache Hugging Face, modèles Ollama/LM Studio, etc.), énoncez toujours la conséquence à voix haute ("cela devra être re-téléchargé") avant de les inclure dans quoi que ce soit que l'utilisateur approuve.
9. Préférez la migration à la suppression pour tout ce que l'utilisateur identifie comme ayant de la valeur. La suppression est réservée aux données récupérables/ jetables ; les données volumineuses de modèles ou de projets qui ne sont pas jetables doivent être proposées comme DÉPLACEMENT, pas SUPPRESSION.
10. Préférez la relocalisation basée sur la configuration de l'application elle-même plutôt qu'un Junction. storops migrate plan intègre déjà cette priorité — ne la remplacez pas par un Junction simplement parce que cela semble plus simple.
11. Vérifiez après chaque migration (storops verify par rapport au fichier de résultat écrit par storops migrate execute). Si la vérification échoue, dites-le clairement et arrêtez-vous — ne supprimez ni ne modifiez rien d'autre pour "nettoyer" une vérification échouée.
12. Ne laissez pas le backend d'analyse (WizTree sur Windows, gdu/du sur Linux/macOS) devenir une dépendance dure dans votre raisonnement. S'il est complètement absent, le CLI lève une erreur claire indiquant où l'obtenir (WizTree : https://diskanalyzer.com/ ou $env:STOROPS_WIZTREE_PATH ; gdu : https://github.com/dundee/gdu ou $env:STOROPS_GDU_PATH) — relayez cela à l'utilisateur plutôt que d'essayer de contourner le problème d'une autre manière.
13. Sur Linux/macOS, chaque résultat --json d'une commande de lecture/planification (scan/inspect/search/cleanup plan/migrate plan) contient les champs Backend et BackendAdvice. BackendAdvice n'est non null que lorsque StorOps est tombé en recours sur le backend plus lent du parce que gdu n'a pas été trouvé. Mentionnez-le à l'utilisateur une fois par conversation s'il est non null (par exemple "au fait, installer gdu rendrait ces analyses sensiblement plus rapides") — ne le répétez pas à chaque commande, et ne le mentionnez pas du tout sur Windows ou lorsqu'il est null.

Workflow : "Pourquoi mon disque est-il plein ?"

1. storops scan C:\ (ou le disque mentionné par l'utilisateur) pour les consommateurs de premier niveau et l'espace libre.
2. Pour toute entrée volumineuse et non identifiée ou ambiguë, storops inspect pour voir ce qu'elle contient réellement.
3. Recoupez chaque entrée notable avec storops identify (scan/inspect attachent déjà l'identité + l'action recommandée, mais appelez-le directement pour un chemin unique demandé par l'utilisateur).
4. Présentez une répartition classée : ce que c'est, la taille, et l'action recommandée (GARDER / SUPPRIMER / DÉPLACER / VÉRIFIER) avec la raison et le risque.
5. Ne supprimez ni ne déplacez rien à ce stade — c'est purement diagnostic.

Workflow : "Nettoyer de l'espace disque" / "Supprimer X"

1. Assurez-vous que la cible a déjà été scannée/identifiée (exécutez d'abord le workflow d'analyse ci-dessus si ce n'est pas le cas).
2. Exécutez storops cleanup plan (par défaut --max-risk low ; ne l'augmentez que si l'utilisateur dit explicitement qu'il est d'accord avec les éléments à risque moyen/élevé aussi). Cela produit un plan JSON détaillé — rien n'est encore supprimé.
3. Présentez le plan groupé par niveau de risque, avec la taille de chaque élément, l'application concernée, et la conséquence (signalez explicitement les conséquences à risque moyen/élevé, par exemple "peut nécessiter d'être re-téléchargé"). Affichez la taille totale récupérable.
4. Demandez à l'utilisateur de confirmer. S'il ne veut qu'un sous-ensemble, régénérez avec un --max-risk plus strict ou indiquez quels éléments ignorer — ne modifiez pas les drapeaux Approved dans le fichier de plan sans dire exactement à l'utilisateur ce qui a changé.
5. Une fois que l'utilisateur a confirmé uniquement, exécutez storops cleanup execute --plan-file <chemin> --confirm.
6. Rapportez le résultat par élément (supprimé / ignoré / échoué) et la taille totale récupérée. Un élément échoué (par exemple fichier en cours d'utilisation) est signalé, pas réessayé de force.

Workflow : "Migrer X vers un autre disque"

1. Identifiez le chemin source (storops identify s'il n'est pas déjà connu d'une analyse). S'il n'est pas Migratable, dites-le et expliquez pourquoi (par exemple critique, ou aucun chemin de migration connu) au lieu d'en improviser un.
2. Exécutez storops migrate plan <source> <destination>. Cela décide de la méthode (changement de configuration d'application, ou Junction en solution de repli) et produit une liste d'étapes ordonnées — rien n'est encore déplacé.
3. Présentez le plan : source, destination, taille, méthode, et si l'application doit être fermée d'abord. Si RequiresAppClosed, demandez explicitement à l'utilisateur de la fermer avant de continuer.
4. Demandez une confirmation sur le plan dans son ensemble.
5. Exécutez storops migrate execute --plan-file <chemin> --confirm (ajoutez --app-closed une fois que l'utilisateur a confirmé que l'application est fermée). Cela copie les données, vérifie le nombre/taille des fichiers par rapport à la source, et seulement ensuite supprime l'original — pour la méthode Junction, cela relie également l'ancien chemin.
6. Si la méthode était un changement de configuration d'application (pas un Junction), dites à l'utilisateur le changement de configuration exact à effectuer (d'après le MigrationHint du plan) — StorOps ne modifie pas lui-même les fichiers de configuration arbitraires des applications.
7. Exécutez storops verify --result-file <chemin depuis la sortie de migrate execute> et rapportez RÉUSSI / ÉCHEC par vérification. En cas d'échec, arrêtez-vous et décrivez exactement ce qui ne correspond pas — ne supprimez jamais les données restantes pour "résoudre" une vérification échouée.

Workflow : "Est-il sûr de supprimer/déplacer ?"

Exécutez simplement storops identify <chemin> et rapportez textuellement Catégorie, Supprimable, Migrable, RisqueNettoyage, Conséquence et l'action recommandée — c'est la réponse directe et déterministe ; n'éditorialisez pas au-delà de ce que la base de règles dit réellement, et ne devinez pas pour un résultat unknown.

Référence des commandes

Niveau	Commandes	Confirmation
Lecture	storops scan, storops inspect, storops search, storops identify	aucune
Plan	storops cleanup plan, storops migrate plan	aucune (produit uniquement un fichier de plan)
Écriture	storops cleanup execute, storops migrate execute	nécessite --confirm (et --app-closed pour les migrations qui en ont besoin)
Vérification	storops verify	aucune (re-vérification en lecture seule)

Toutes les commandes supportent --json pour une sortie lisible par machine. Invoquez-les comme python -m storops <commande> ..., ou storops <commande> ... si le paquet a été installé via pip install.

Voir README.md pour l'installation / les prérequis et rules/README.md pour le schéma des règles derrière l'identification.