hamza-ali-shahjahan/hamzaish

/tidy — l'étape de nettoyage

La pourriture s'accumule dans chaque dépôt : des liens qui pointent vers des fichiers déplacés/ignorés par git, une clé qui a glissé dans un commit, un actif que rien ne référence, une dépendance qui fait 404 à l'installation. Rien de tout cela n'est visible au quotidien — cela refait surface au pire moment (un 404 pour un lecteur, une CI qui échoue, une clé divulguée). /tidy est l'étape où vous trouvez et éliminez cette pourriture délibérément.

C'est une étape, pas une barrière. Les gardes rapides (check-changelog, check-assets) bloquent à chaque push ; /tidy est le balayage large, d'abord rapport, que vous exécutez quand il est temps de nettoyer.

Comment l'exécuter

bun run tidy                      # le dépôt courant → résumé + prochaines étapes recommandées
bun run tidy <chemin>             # un dépôt spécifique
bun run tidy --all ~/Claude       # chaque dépôt git dans un dossier → un tableau agrégé
bun run tidy --liens              # approfondir une catégorie (--secrets --fichiers --deps)

Il analyse quatre types de pourriture et affiche d'abord l'étendue (un compte par catégorie) pour que vous n'ayez jamais un mur de sortie :

	ce qu'il détecte
🔗 Liens	Liens markdown/HTML vers des fichiers manquants, ou qui résolvent uniquement vers une cible gitignorée (fonctionne sur le disque de l'auteur, 404 pour tous les autres)
🔑 Secrets	Patterns de clés validées de haute confiance (AWS, Stripe, GitHub, Google, Slack, blocs de clés privées) — signalés pour révision, pas jugés automatiquement
🗑 Fichiers morts	Images/actifs validés que rien ne référence — sans risque de les élaguer
📦 Dépendances	Dépendances package.json qui ne résolvent pas sur npm (la classe @inngest/sdk morte)

Le flux (rapport → recommandation → demander → corriger)

1. Exécutez-le. Présentez le tableau récapitulatif — étendue par catégorie, par dépôt.
2. Recommandez. Signalez quelles catégories comptent et pourquoi (un lien cassé est un 404 pour un lecteur ; un secret signalé doit être roté ; une dépendance irrésoluble casse chaque installation).
3. Demandez. Laissez l'opérateur choisir quoi nettoyer. Ne présumez jamais.
4. Corrigez avec confirmation — planifiez, puis appliquez. bun run tidy --fix <dépôt> affiche le plan de modification exact (quels liens cassés sont dé-liés) sans rien écrire ; relancez avec --apply pour effectuer ces modifications. Vous voyez donc toujours chaque changement d'abord. La correction automatique est volontairement restreinte : elle se contente de délier les liens textes cassés/ignorés par git ([texte](mauvais) → texte). Les secrets, dépendances, images/liens HTML et suppressions de fichiers ne sont jamais appliqués automatiquement — ils sont listés comme manuels avec des conseils (rotater une clé, choisir le bon paquet), car leur correction relève du jugement, pas d'une simple édition de ligne. Sondez-en beaucoup avec --all, puis --fix un dépôt à la fois.

Discipline

• Rapport d'abord, toujours. La valeur réside dans le fait de voir la pourriture avant d'y toucher.
• N'en faites pas une barrière. /tidy est lent (vérifications réseau des dépendances) et large — gardez-le comme une étape, pas un bloqueur de push. Les gardes étroits restent la porte.
• Les secrets sont à réviser. Une correspondance de motif est une invitation à regarder, pas un verdict — et si c'est réel, la correction est de rotater la clé, pas de supprimer la ligne.
• Les répertoires gelés sont ignorés (_archive/, node_modules/) — ils ne sont pas à vous de nettoyer.
• Le moteur est portable. scripts/tidy.ts s'exécute sur n'importe quel chemin de dépôt — c'est ce qui permet de balayer 100+ dépôts en une seule commande.