hamza-ali-shahjahan/hamzaish

/tidy — la etapa de limpieza

La basura se acumula en cada repositorio: enlaces que apuntan a archivos movidos/ignorados, una clave que se coló en un commit, un activo que nadie referencia, una dependencia que da 404 al instalarse. Nada de esto es visible en el día a día — sale a la luz en el peor momento (un 404 del lector, un CI fallido, una clave filtrada). /tidy es la etapa donde encuentras y limpias esta basura a propósito.

Esta es una etapa, no una compuerta. Los guardias rápidos (check-changelog, check-assets) bloquean en cada push; /tidy es el barrido amplio que primero informa y ejecutas cuando llega el momento de limpiar.

Cómo ejecutarlo

bun run tidy                      # el repo actual → resumen + próximos pasos recomendados
bun run tidy <ruta>               # un repo específico
bun run tidy --all ~/Claude       # cada repo git bajo una carpeta → una tabla agregada
bun run tidy --links              # profundiza en una categoría (--secrets --files --deps)

Escanea cuatro tipos de basura y muestra primero el alcance (un recuento por categoría) para que nunca recibas un muro de salida:

	qué detecta
🔗 Enlaces	enlaces markdown/HTML a archivos faltantes, o que solo se resuelven a un objetivo gitignorado (funciona en el disco del autor, da 404 para todos los demás)
🔑 Secretos	patrones de clave comprometida de alta confianza (AWS, Stripe, GitHub, Google, Slack, bloques de clave privada) — marcados para revisión, no juicio automático
🗑 Archivos muertos	imágenes/activos subidos que nada referencia — seguros de podar
📦 Deps	dependencias en package.json que no se resuelven en npm (la clase @inngest/sdk muerta)

El flujo (informar → recomendar → preguntar → arreglar)

1. Ejecútalo. Presenta la tabla resumen — alcance por categoría, por repositorio.
2. Recomienda. Señala qué categorías importan y por qué (un enlace roto es un 404 del lector; un secreto marcado necesita rotación; una dependencia irresoluble rompe toda instalación).
3. Pregunta. Deja que el operador elija qué limpiar. Nunca asumas.
4. Arregla con confirmación — planifica, luego aplica. bun run tidy --fix <repo> imprime el plan de cambios exacto (qué enlaces rotos se desenlazan) sin escribir nada; vuelve a ejecutar con --apply para hacer esas ediciones. Así siempre ves cada cambio primero. La corrección automática es deliberadamente limitada: solo desenlaza enlaces de texto rotos/ignorados ([texto](malo) → texto). Los secretos, dependencias, imágenes/enlaces HTML y eliminaciones de archivos nunca se aplican automáticamente — se listan como manuales con orientación (rotar una clave, elegir el paquete correcto), porque su arreglo requiere criterio, no una edición de línea. Inspecciona muchos con --all, luego --fix un repositorio a la vez.

Disciplina

• Siempre informar primero. El valor está en ver la basura antes de tocar nada.
• No la conviertas en compuerta. /tidy es lento (verificaciones de dependencias en red) y amplio — mantenlo como etapa, no como bloqueador de push. Los guardias estrechos siguen siendo la compuerta.
• Los secretos son solo para revisión. Un patrón coincidente es un aviso para mirar, no un veredicto — y si es real, la solución es rotar la clave, no solo eliminar la línea.
• Los directorios congelados se saltan (_archive/, node_modules/) — no son tuyos para ordenar.
• El motor es portable. scripts/tidy.ts se ejecuta contra cualquier ruta de repositorio — eso es lo que convierte el barrido de 100+ repositorios en un solo comando.