Tres destinos para 44 proyectos: cómo organizo mi código, mis archivos y mis notas

TL;DR

Mi inventario contó 44 proyectos reales frente a 11 declarados. Hoy reparto todo en tres destinos: GitHub para el código, OneDrive para los binarios, Obsidian para el conocimiento. A eso se suman una esclusa de clasificación, una versión mantenida en tres lugares, una carpeta pilotage/ por proyecto y límites escritos para mi agente de código.

---

El diagnóstico: 44 proyectos, 11 declarados

Mi problema de fondo cabe en una frase: creo más proyectos de los que cierro. El inventario arrojó estas cifras:

• 44 proyectos reales
• 11 proyectos declarados
• 16 proyectos inactivos
• 22 proyectos sin copia de seguridad

La realidad cuadruplicaba lo declarado, y la mitad de los proyectos no tenía ninguna copia de seguridad. Las reglas que siguen viven en el archivo de instrucciones global de Claude Code. Se aplican sea cual sea la carpeta desde la que lanzo el agente.

Tres destinos, un tipo de contenido para cada uno

Cada archivo tiene un solo lugar, determinado por su naturaleza:

• GitHub: código fuente, documentación en texto, configuraciones saneadas, workflows de n8n limpios. El versionado lo convierte en la copia de seguridad de mi código, restaurable en cualquier sitio.
• OneDrive: binarios, medios, entregables para clientes, archivos de proyectos cerrados, PDF, exportaciones. Todo lo que git gestiona mal.
• Obsidian: notas, decisiones, método, fichas técnicas, contexto de clientes. El conocimiento, no los archivos.

OneDrive contiene unos 300 GB en modo de archivos bajo demanda, y ese modo es deliberado. Lo trato como un destino, no como un perímetro que clasificar: no lo escaneo ni lo traigo de vuelta en bloque. También compruebo que un archivo no esté ya allí antes de copiarlo, porque ya tengo duplicados.

Lo que nunca cruza la frontera

Cuatro prohibiciones protegen este reparto:

• El código vivo no va a OneDrive: la sincronización corrompe un .git en edición, y GitHub ya cubre esa necesidad.
• Ningún secreto en git: ni archivos de entorno, ni claves, ni certificados, ni bases de datos.
• Ningún medio pesado en git: va a OneDrive y .gitignore lo deja fuera.
• El vault de Obsidian queda fuera de OneDrive: una doble sincronización crea conflictos, y Obsidian móvil no abre un vault situado en la app de OneDrive. Le corresponde a Obsidian Sync.

También hago las copias de seguridad por rama, nunca en bloque. Activar una sincronización de OneDrive sobre todo mi espacio de trabajo metería el código y el vault de un solo gesto: esa opción sigue prohibida.

Tres segmentos de repositorios y una esclusa

Mi carpeta de desarrollo se divide en tres segmentos:

• El trabajo profesional: clientes, SaaS, sitio corporativo, herramientas internas.
• Los juegos: una actividad aparte, con su propio segmento.
• Lo personal: side projects y proyectos inactivos.

En GitHub, el nombre de cada repositorio empieza por el prefijo de su segmento. Un topic indica su estado: actif (activo), dormant (inactivo) o archive (archivado). Todos los repositorios de clientes son privados, sin excepción.

Nada entra directamente en la carpeta de desarrollo ni en el vault. Un elemento entrante, venga de OneDrive, de un clon o de una transferencia, pasa primero por una carpeta esclusa, donde lo reviso antes de clasificarlo.

Lo que git y los archivos comprimidos ignoran

Una carpeta regenerable no tiene cabida en un repositorio ni en un archivo comprimido. Esta es mi lista de exclusión completa:

node_modules  .next  .nuxt  dist  build  out  .output
target  vendor  .venv  venv  __pycache__  .dart_tool
.gradle  Pods  DerivedData  .terraform  coverage
.cache  .turbo  bin  obj

Una versión mantenida en tres lugares

Un proyecto versionado lleva su número en tres lugares que siempre deben coincidir:

1. El manifiesto: package.json, pubspec.yaml, pyproject.toml o composer.json.
2. La primera entrada del CHANGELOG.
3. El tag de git, con el prefijo v.

Una skill de Claude Code actualiza los tres de una vez. El semver es estricto y los commits convencionales determinan el nivel de la versión.

Hice proactivo este bump el 20 de agosto de 2026, porque olvidarlo se había vuelto la norma. En cuanto un lote con commit contiene al menos un feat o un fix, el agente hace el bump sin esperar a que lo pida. Después se detiene y muestra el comando de push. Una actualización de dependencia, con Renovate o npm update, no desencadena ninguna versión del proyecto.

Una carpeta pilotage por proyecto

Cada proyecto de desarrollo debe mantener una carpeta pilotage/ (pilotaje, en francés) con ocho documentos: roadmap, todo, done, work-log, pending-decision, decisions, bugs y quality-checklist. El archivo docs/CONTEXT.md sigue siendo la puerta de entrada corta y remite a esa carpeta.

Antes de intervenir, el agente lee ese estado y luego comprueba git status y git log. Si falta la carpeta, propone crearla. Un proyecto nuevo la recibe desde el principio.

Tres reglas mantienen fiable este seguimiento:

• Nada entra en done.md sin prueba.
• El agente no zanja ninguna decisión de negocio en mi lugar.
• Los identificadores como TASK-, BUG- o DEC- nunca se usan dos veces.

Este seguimiento se incluye en el commit del lote de trabajo, y no llega a GitHub sin mi validación.

Los límites que le doy a mi agente

En mis proyectos y archivos, el agente trabaja en solo lectura por defecto. El bump y el pilotage son dos excepciones de escritura asumidas. Los demás límites son explícitos:

• Dry-run antes de cualquier movimiento: muestra el plan y espera mi validación.
• Nunca una eliminación: mueve a una zona de archivo reversible.
• Nunca un git push sin mi validación.
• Nunca una reescritura del historial de git sin una petición explícita.
• Ningún movimiento de un proyecto con cambios sin commit.
• Inspección del destino antes de sobrescribirlo o eliminarlo: si contradice su descripción, me avisa en lugar de actuar.

Sobre la otra cara de mi puesto de trabajo, escribí aparte cómo configuro mi Mac.

La cifra sigue siendo la referencia

Mis reglas ordenan los proyectos, no los cierran, y este artículo no anuncia ninguna bajada de esas cifras. Mantengo este diagnóstico como diagnóstico, no como condición para crear nada: un proyecto número 45 sigue siendo posible. Recibirá un prefijo, un topic de estado y su carpeta pilotage/.