tzzs/storops

Was macht storops?

Sehen, wohin Ihr Speicher geht. Verstehen, was er ist. Verschieben, was zählt. Bereinigen, was nicht.

StorOps ist weder ein Datenträger-Scanner noch ein Datenträger-Reiniger. WizTree beantwortet bereits die Frage „Was belegt Speicher?“ – StorOps beantwortet, was diese Dinge sind, ob sie sicher anzufassen sind, und führt eine Bereinigung oder Migration sicher durch, sobald der Benutzer grünes Licht gibt. Die vollständige Begründung finden Sie in docs/DESIGN.md.

Diese Datei definiert, wie sich ein Agent bei der Verwendung von StorOps verhalten soll – nicht nur, welche Befehle existieren. Befolgen Sie nach Möglichkeit die folgenden Arbeitsabläufe, anstatt Befehle ad hoc aufzurufen; der Benutzer sollte keine Befehlsnamen kennen müssen.

Unverhandelbare Regeln

1. Analyse vor Aktion. Führen Sie immer zuerst einen Scan, eine Inspektion oder eine Identifikation durch, bevor Sie etwas vorschlagen, und überspringen Sie niemals direkt eine Schreiboperation.
2. Standardmäßig ist alles schreibgeschützt. storops scan, storops inspect, storops search, storops identify, storops cleanup plan und storops migrate plan ändern niemals das Dateisystem – führen Sie sie ohne vorherige Rückfrage aus.
3. Raten Sie niemals, was ein Pfad anhand seines Namens ist. Nur storops identify (gestützt durch rules/*.yaml) bestimmt Kategorie/Risiko/Löschbarkeit. Ein Pfad ohne passende Regel wird als unknown / critical gemeldet – behandeln Sie das als „nicht anfassen“, nicht als Aufforderung, aufgrund des Ordnernamens zu spekulieren.
4. Behandeln Sie „Cache“ oder „Temp“ im Namen niemals als Erlaubnis zum Löschen. Handeln Sie nur basierend auf dem, was storops identify/storops cleanup plan tatsächlich klassifiziert hat.
5. Pfade mit kritischem Risiko (Windows, Program Files, unbekannte Systemdateien, Benutzerdokumente) werden niemals zum Löschen oder Migrieren angeboten. Dies wird im Code erzwungen (assert_not_critical in src/storops/core/risk.py), nicht nur durch Konvention – versuchen Sie nicht, diese Einschränkung zu umgehen.
6. Jede Schreiboperation (storops cleanup execute, storops migrate execute) erfordert zuerst die explizite, positionsbezogene Bestätigung des Benutzers, und die CLI selbst weigert sich, ohne --confirm ausgeführt zu werden. Zeigen Sie den Plan an, warten Sie auf ein echtes „Ja“, und übergeben Sie dann --confirm – niemals vorzeitig im Namen des Benutzers.
7. Wenn eine Anwendung möglicherweise ausgeführt wird, verschieben Sie ihre Daten nicht. storops migrate plan markiert RequiresAppClosed; storops migrate execute weigert sich in diesem Fall ohne ein explizites --app-closed-Bekenntnis auszuführen. Bitten Sie den Benutzer, die App zu schließen – gehen Sie nicht davon aus, dass sie geschlossen ist, und beenden Sie den Prozess nicht selbst.
8. Für große, erneut herunterladbare KI-Modell-/Cache-Daten (Hugging Face Cache, Ollama/LM Studio Modelle usw.) geben Sie die Konsequenzen stets laut an („dies muss erneut heruntergeladen werden“), bevor es in etwas aufgenommen wird, das der Benutzer genehmigt.
9. Bevorzugen Sie Migration gegenüber Löschung für alles, was der Benutzer als wertvoll identifiziert. Löschung ist für wiederherstellbare/wegwerfbare Daten gedacht; große Modell- oder Projektdaten, die nicht wegwerfbar sind, sollten als VERSCHIEBEN, nicht als LÖSCHEN angeboten werden.
10. Bevorzugen Sie eine anwendungseigene konfigurationsbasierte Verschiebung gegenüber einer Junction. storops migrate plan kodiert diese Priorität bereits – überschreiben Sie sie nicht in Richtung Junction, nur weil es einfacher erscheint.
11. Überprüfen Sie nach jeder Migration (storops verify anhand der Ergebnisdatei, die storops migrate execute schreibt). Wenn die Überprüfung fehlschlägt, sagen Sie dies deutlich und stoppen Sie – löschen oder ändern Sie niemals etwas, um eine fehlgeschlagene Überprüfung zu „bereinigen“.
12. Lassen Sie das Scan-Backend (WizTree unter Windows, gdu/du unter Linux/macOS) nicht zu einer harten Abhängigkeit in Ihrer Argumentation werden. Wenn es vollständig fehlt, gibt die CLI einen klaren Fehler aus, der darauf hinweist, wo Sie es erhalten (WizTree: https://diskanalyzer.com/ oder $env:STOROPS_WIZTREE_PATH; gdu: https://github.com/dundee/gdu oder $env:STOROPS_GDU_PATH) – leiten Sie dies an den Benutzer weiter, anstatt zu versuchen, es auf andere Weise zu umgehen.
13. Unter Linux/macOS trägt jedes --json-Ergebnis eines Lese-/Plan-Befehls (scan/inspect/search/cleanup plan/migrate plan) die Felder Backend und BackendAdvice. BackendAdvice ist nur dann nicht null, wenn StorOps auf das langsamere du-Backend zurückgefallen ist, weil gdu nicht gefunden wurde. Erwähnen Sie es dem Benutzer einmal pro Konversation, falls es nicht null ist (z. B. „übrigens, die Installation von gdu würde diese Scans merklich beschleunigen“) – wiederholen Sie es nicht bei jedem einzelnen Befehl, und erwähnen Sie es unter Windows oder wenn es null ist, gar nicht.

Arbeitsablauf: „Warum ist meine Festplatte voll?“

1. storops scan C:\ (oder das vom Benutzer genannte Laufwerk) nach den größten Verbrauchern und freiem Speicher.
2. Für jeden großen und nicht identifizierten oder mehrdeutigen Eintrag storops inspect ausführen, um zu sehen, was sich tatsächlich darin befindet.
3. Jeden bemerkenswerten Eintrag mit storops identify abgleichen (Scan/Inspektion fügen bereits Identität + empfohlene Aktion hinzu, aber für einen einzelnen Pfad, nach dem der Benutzer fragt, direkt aufrufen).
4. Eine nach Rang geordnete Aufschlüsselung präsentieren: was es ist, wie groß es ist, und die empfohlene Aktion (BEHALTEN / LÖSCHEN / VERSCHIEBEN / PRÜFEN) mit Grund und Risiko.
5. Löschen oder verschieben Sie in dieser Phase nichts – dies ist rein diagnostisch.

Arbeitsablauf: „Festplattenspeicher bereinigen“ / „X löschen“

1. Stellen Sie sicher, dass das Ziel bereits gescannt/identifiziert wurde (führen Sie andernfalls zuerst den Scan-Workflow oben aus).
2. Führen Sie storops cleanup plan aus (Standard --max-risk low; erhöhen Sie es nur, wenn der Benutzer ausdrücklich sagt, dass er auch mit mittleren/hohen Risiken einverstanden ist). Dies erzeugt einen positionsbezogenen JSON-Plan – es wird noch nichts gelöscht.
3. Präsentieren Sie den Plan, gruppiert nach Risikostufe, mit Größe, Anwendung und Konsequenz jedes Eintrags (nennen Sie Konsequenzen mit mittlerem/hohem Risiko explizit, z. B. „muss möglicherweise erneut heruntergeladen werden“). Zeigen Sie die insgesamt freigebbare Größe an.
4. Bitten Sie den Benutzer um Bestätigung. Wenn er nur eine Teilmenge möchte, generieren Sie den Plan mit einem engeren --max-risk neu oder zeigen Sie an, welche Einträge übersprungen werden sollen – bearbeiten Sie Approved-Flags in der Plan-Datei nicht von Hand, ohne dem Benutzer genau mitzuteilen, was geändert wurde.
5. Erst wenn der Benutzer bestätigt, führen Sie storops cleanup execute --plan-file <pfad> --confirm aus.
6. Melden Sie das Ergebnis pro Element (gelöscht / übersprungen / fehlgeschlagen) und die insgesamt freigegebene Größe. Ein failed-Element (z. B. weil eine Datei in Verwendung ist) wird gemeldet, nicht gewaltsam wiederholt.

Arbeitsablauf: „X auf ein anderes Laufwerk migrieren“

1. Identifizieren Sie den Quellpfad (storops identify, falls er nicht bereits aus einem Scan bekannt ist). Wenn er nicht Migratable ist, sagen Sie dies und erklären Sie warum (z. B. kritisch oder kein bekannter Migrationspfad), anstatt einen zu improvisieren.
2. Führen Sie storops migrate plan <quelle> <ziel> aus. Dies entscheidet über die Methode (Anwendungskonfigurationsänderung oder Junction als Fallback) und erzeugt eine geordnete Schrittliste – es wird noch nichts verschoben.
3. Präsentieren Sie den Plan: Quelle, Ziel, Größe, Methode und ob die Anwendung zuerst geschlossen werden muss. Wenn RequiresAppClosed, bitten Sie den Benutzer ausdrücklich, sie vor dem Fortfahren zu schließen.
4. Fragen Sie nach Bestätigung des gesamten Plans.
5. Führen Sie storops migrate execute --plan-file <pfad> --confirm aus (fügen Sie --app-closed hinzu, sobald der Benutzer bestätigt hat, dass die App geschlossen ist). Dies kopiert die Daten, überprüft Dateianzahl/-größe gegen die Quelle und entfernt erst dann das Original – bei der Junction-Methode wird auch der alte Pfad neu verlinkt.
6. Wenn die Methode eine Anwendungskonfigurationsänderung war (keine Junction), teilen Sie dem Benutzer die genaue Konfigurationsänderung mit (aus dem MigrationHint des Plans) – StorOps bearbeitet keine beliebigen App-Konfigurationsdateien selbst.
7. Führen Sie storops verify --result-file <pfad aus der migrate execute Ausgabe> aus und melden Sie BESTANDEN/NICHT BESTANDEN pro Prüfung. Bei NICHT BESTANDEN stoppen Sie und beschreiben genau, was nicht übereinstimmte – löschen Sie niemals verbleibende Daten, um eine fehlgeschlagene Überprüfung zu „beheben“.

Arbeitsablauf: „Ist es sicher, zu löschen/verschieben?“

Führen Sie einfach storops identify <pfad> aus und geben Sie Kategorie, Löschbar, Migrierbar, Bereinigungsrisiko, Konsequenz und die empfohlene Aktion wörtlich wieder – dies ist die direkte, deterministische Antwort; nehmen Sie keine redaktionellen Ergänzungen über das hinaus vor, was die Regelbasis tatsächlich sagt, und raten Sie nicht für ein unknown-Ergebnis.

Befehlsreferenz

Stufe	Befehle	Bestätigung
Lesen	storops scan, storops inspect, storops search, storops identify	keine
Planen	storops cleanup plan, storops migrate plan	keine (erzeugt nur eine Plan-Datei)
Schreiben	storops cleanup execute, storops migrate execute	erfordert --confirm (und --app-closed für Migrationen, die dies benötigen)
Prüfen	storops verify	keine (schreibgeschützte Nachprüfung)

Jeder Befehl unterstützt --json für maschinenlesbare Ausgabe. Aufruf als python -m storops <befehl> ..., oder storops <befehl> ..., wenn das Paket mit pip install installiert wurde.

Siehe README.md für Einrichtung/Anforderungen und rules/README.md für das Regelschema hinter der Identifikation.