# Three destinations for 44 projects: how I organize my code, files and notes > Source: > Published: 2026-11-13 23:15:07+00:00 My inventory counted 44 real projects against 11 declared. Today I sort everything into three destinations: GitHub for code, OneDrive for binaries, Obsidian for knowledge. On top of that sit a sorting airlock, a version kept in three places, one `pilotage/` folder per project and written limits for my coding agent. My underlying problem fits in one sentence: I create more projects than I close. The inventory produced these numbers: Reality was four times what I had declared, and half of the projects had no backup. The rules below live in Claude Code's global instructions file. They apply whichever folder I launch the agent from. Every file has a single place, set by its nature: OneDrive holds about 300 GB in files-on-demand mode, and that mode is deliberate. I treat it as a destination, not as something to sort: I don't scan it and I don't pull it back in bulk. I also check that a file isn't already there before copying it, because I already have duplicates. Four prohibitions protect this split: `.git` during editing, and GitHub already covers that need.`.gitignore` keeps it out. I also back up branch by branch, never in one block. Turning on OneDrive sync for my entire workspace would pull the code and the vault in with a single setting, so that option stays forbidden. My development folder splits into three segments: On GitHub, each repository name starts with its segment's prefix. A topic gives its status: `actif` (active), `dormant` or `archive`. All client repositories are private, without exception. Nothing enters the development folder or the vault directly. An incoming item, whether from OneDrive, a clone or a transfer, first goes through an airlock folder, where I sort it before filing it. A regenerable folder has no place in a repository or an archive. Here is my full exclusion list: ``` node_modules .next .nuxt dist build out .output target vendor .venv venv __pycache__ .dart_tool .gradle Pods DerivedData .terraform coverage .cache .turbo bin obj ``` A versioned project carries its number in three places that must always agree: `package.json`, `pubspec.yaml`, `pyproject.toml` or `composer.json`.` v`. A Claude Code skill updates all three at once. Semver is strict, and conventional commits set the version level. I made this bump proactive on August 20, 2026, because forgetting it had become the norm. As soon as a committed batch contains at least one `feat` or `fix`, the agent bumps without waiting for me to ask. It then stops and displays the push command. A dependency upgrade, through Renovate or `npm update`, triggers no project version. Every dev project must keep a `pilotage/` folder (French for "steering") with eight documents: roadmap, todo, done, work-log, pending-decision, decisions, bugs and quality-checklist. The `docs/CONTEXT.md` file remains the short entry point and links to this folder. Before acting, the agent reads this state, then checks `git status` and `git log`. If the folder is missing, it offers to set it up. A new project gets one from the start. Three rules keep this tracking reliable: `done.md` without proof.`TASK-`, `BUG-` or `DEC-` are never used twice. This tracking gets committed with the batch of work, and it doesn't reach GitHub without my approval. On my projects and files, the agent works read-only by default. The bump and the pilotage folder are two deliberate write exceptions. The other limits are explicit: `git push` For the other side of my workstation, I wrote separately about [how I set up my Mac](https://dimitriaigle.fr/articles/configurer-mac-dev-en). My rules sort projects, they don't close them, and this article announces no drop in these numbers. I keep this finding as a finding, not as a condition for creating anything: a 45th project remains possible. It will get a prefix, a status topic and its `pilotage/` folder.