hamza-ali-shahjahan/hamzaish

/tidy – die Aufräumphase

In jedem Repository sammelt sich mit der Zeit Müll an: Links, die auf verschobene oder gitignorierte Dateien verweisen, ein versehentlich eingecheckter Schlüssel, auf die nichts verweist, eine Asset-Datei, die niemand mehr verwendet, oder eine Abhängigkeit, die bei der Installation einen 404-Fehler auslöst. All das ist im Alltag nicht sichtbar – es taucht erst im ungünstigsten Moment auf (z. B. ein Leser erhält einen 404, eine CI schlägt fehl, ein Schlüssel wird geleakt). /tidy ist die Phase, in der Sie solche Fehler gezielt finden und beseitigen.

Dies ist eine Phase, kein Gate. Die schnellen Guards (check-changelog, check-assets) blockieren bei jedem Push; /tidy ist der breite, report-gestützte Durchlauf, den Sie ausführen, wenn eine Aufräumaktion ansteht.

Ausführung

bun run tidy                      # das aktuelle Repository → Zusammenfassung + empfohlene nächste Schritte
bun run tidy <pfad>               # ein bestimmtes Repository
bun run tidy --all ~/Claude       # alle Git-Repos unter einem Ordner → eine aggregierte Tabelle
bun run tidy --links              # in eine Kategorie eintauchen (--secrets --files --deps)

Es durchsucht vier Arten von Müll und zeigt zuerst den Umfang an (Anzahl pro Kategorie), damit Sie nie eine endlose Ausgabe erhalten:

	was gefunden wird
🔗 Links	Markdown/HTML-Links auf fehlende Dateien oder solche, die nur auf ein gitignoriertes Ziel verweisen (funktionieren auf der Festplatte des Autors, sind aber für alle anderen ein 404)
🔑 Geheimnisse	hochsichere Muster für eingecheckte Schlüssel (AWS, Stripe, GitHub, Google, Slack, private-key-Blöcke) – zur Überprüfung markiert, nicht automatisch beurteilt
🗑 Tote Dateien	eingecheckte Bilder/Assets, auf die nichts verweist – sicher zu entfernen
📦 Abhängigkeiten	package.json-Abhängigkeiten, die sich nicht über npm auflösen lassen (der tote @inngest/sdk-Fall)

Der Ablauf (Report → Empfehlung → Frage → Korrektur)

1. Ausführen. Präsentieren Sie die Zusammenfassungstabelle – Anzahl pro Kategorie, pro Repository.
2. Empfehlen. Weisen Sie darauf hin, welche Kategorien wichtig sind und warum (ein defekter Link ist ein 404 für den Leser; ein markiertes Geheimnis muss rotiert werden; eine nicht auflösbare Abhängigkeit bricht jede Installation).
3. Fragen. Lassen Sie den Operator wählen, was bereinigt werden soll. Niemals annehmen.
4. Korrektur mit Bestätigung – planen, dann anwenden. bun run tidy --fix <repo> gibt den genauen Änderungsplan aus (welche defekten Links werden entlinkt) ohne etwas zu schreiben; führen Sie es erneut mit --apply aus, um die Änderungen vorzunehmen. So sehen Sie jede Änderung zuerst. Die automatische Korrektur ist bewusst eng gefasst: Sie entlinkt nur defekte/gitignorierte Textlinks ([text](fehlerhaft) → text). Geheimnisse, Abhängigkeiten, Bilder/HTML-Links und Dateilöschungen werden niemals automatisch angewendet – sie werden als manuell mit Anleitung aufgelistet (Schlüssel rotieren, das richtige Paket auswählen), da deren Korrektur ein Urteil erfordert, keine reine Zeilenänderung. Untersuchen Sie viele mit --all, dann korrigieren Sie ein Repository nach dem anderen mit --fix.

Disziplin

• Immer zuerst den Report erstellen. Der Wert liegt darin, den Müll zu sehen, bevor man etwas anfasst.
• Nicht als Gate verwenden. /tidy ist langsam (Netzwerkabhängigkeitsprüfungen) und breit – behalten Sie es als Phase, nicht als Push-Blocker. Die engen Guards bleiben das Gate.
• Geheimnisse sind zur Überprüfung gedacht. Ein Musterfund ist ein Hinweis zum Hinschauen, kein Urteil – und wenn es ernst ist, besteht die Lösung darin, den Schlüssel zu rotieren, nicht nur die Zeile zu löschen.
• Eingefrorene Verzeichnisse werden übersprungen (_archive/, node_modules/) – sie gehören nicht zu Ihrem Aufräumbereich.
• Das Skript ist portabel. scripts/tidy.ts kann auf jeden Repository-Pfad angewendet werden – das ermöglicht die Bereinigung von über 100 Repos mit einem Befehl.