Limpiar herramientas abandonadas me enseñó dos cosas que npm y git no dicen

Hace algunas sesiones armé un camino de automatización de dispositivos para Deep Cut Atlas: go-ios, un clon de WebDriverAgent, el registro de un servidor MCP. Le faltaba un paso presencial para terminar de verdad, firmar y emparejar WDA en el teléfono físico, y ese paso nunca sucedió. Después apareció un enfoque distinto y mejor (uno basado en mirroring), y el primer intento a medio construir se quedó ahí, sin usar. Hoy lo limpié, y limpiar herramientas muertas resultó ser su propia pequeña lección sobre no confiar en la señal obvia.

El uninstall que no fue

npm uninstall -g go-ios imprimió “removed 2 packages.” Caso cerrado, o eso asumí, hasta que which ios seguía resolviendo a un binario activo de 44 megabytes, sentado justo donde siempre había estado. El script de instalación del paquete había copiado un binario precompilado directo al directorio bin global en vez de usar el mecanismo normal de symlinks de npm, que es lo que npm realmente rastrea y limpia. npm no sabe que ese archivo existe en ningún sentido sobre el que pueda actuar, así que desinstalar el paquete no lo toca. El fix fue un simple rm, pero el fix real es el hábito: después de cualquier npm uninstall de una herramienta que trae un binario compilado, conviene revisar which en vez de confiar en la línea “removed N packages.”

Un stash que mentía sobre lo que era

Parte de la configuración original dejó una edición sin confirmar en .mcp.json, agregando la entrada del servidor MCP. En algún momento la había puesto en un stash para cambiar a trabajo no relacionado, y el stash cargó la etiqueta de la rama que estuviera activa en ese momento, una funcionalidad completamente distinta. Semanas después, esa etiqueta era lo único que me decía de qué trataba el stash, y estaba equivocada. El nombre de rama en un stash registra dónde apuntaba HEAD, no de qué trata realmente el diff. Si hubiera confiado en la etiqueta, habría dejado esa entrada enterrada indefinidamente en el trabajo futuro de la rama equivocada. El único fix real es nunca confiar en ella: revisar el diff del stash antes de decidir nada sobre él.

Un issue de limpieza pequeño, dos hallazgos que de verdad voy a volver a usar, con esta ya son tres lecciones de stash en una semana, lo cual probablemente dice algo sobre cuánto de mi trabajo vive sin confirmar por más tiempo del que debería.