# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Nature du dépôt

**OpenSource by Elevaseo** — dépôt **multi-projets open source**. Il n'y a pas de code partagé, pas de workspace commun, pas de build racine : **un dossier racine = un projet autonome**, avec sa propre licence, son propre README, son propre gestionnaire de paquets et sa propre CI.

```
open source/
├── CLAUDE.md            # ce fichier — conventions du dépôt
└── advmfr-password/     # Projet 1 — app desktop Tauri v2 (voir son CLAUDE.md)
```

Conséquences pratiques :
- Toute commande (`install`, `build`, `test`) s'exécute **depuis le dossier du projet**, jamais depuis la racine.
- Ne jamais hisser une dépendance ou une config à la racine « pour factoriser ». Les projets doivent rester clonables/extractibles individuellement.
- Les règles de stack (`nextjs-16.x.md`, etc. dans `~/Github/Rules/`) sont importées dans le `CLAUDE.md` **du projet concerné**, jamais ici.

## Scaffolding : toujours par CLI, jamais à la main

**Règle non négociable.** Un nouveau projet se crée avec la CLI officielle de sa stack en mode non-interactif (`create-tauri-app`, `create-next-app`, `cargo new`…), et **la documentation officielle de la version ciblée se lit avant**. On ne recopie pas une arborescence de mémoire : les templates changent entre versions majeures et les erreurs qui en découlent sont coûteuses à diagnostiquer.

Corollaire : `bun create <x>` avale les flags avant de les transmettre. Passer par `bunx <x>@latest` pour un scaffold paramétré. Exemple réellement utilisé ici :

```bash
sfw bunx create-tauri-app@latest advmfr-password \
  -m bun -t react-ts --identifier com.elevaseo.advmfrpassword --tauri-version 2 -y
```

## Projets

| Dossier | Description | Stack |
| --- | --- | --- |
| `advmfr-password/` | **ADVMFR Password** — génération et rotation de mots de passe, desktop Windows | Tauri v2 + React 19 + TS, bun |

Les conventions, l'architecture et les commandes de chaque projet vivent dans **son propre `CLAUDE.md`**.

## Outillage imposé

- **bun, toujours.** Bun est le seul gestionnaire de paquets et le seul runner JS/TS du dépôt : `bun install`, `bun add`, `bun run <script>`, `bunx <cli>`. **Jamais** `npm`, `npx`, `yarn`, `pnpm`, ni `node <fichier>` — y compris dans les scripts `package.json`, la CI et les blocs de doc. Seule exception : `cargo` pour tout ce qui est Rust, qui n'a pas d'équivalent bun.
- **Installation de dépendances** : préfixer par `sfw` (Socket Firewall) — `sfw bun add <pkg>`, `sfw cargo add <crate>`.
- **Lint / format JS-TS** : toolchain oxc (`oxlint`, `oxfmt`) plutôt qu'ESLint/Prettier quand le projet le permet. Côté Rust : `cargo fmt` + `cargo clippy`.
- **Code mort** : `knip` avant toute PR sensible.
- **RTK** : les commandes shell sont réécrites automatiquement par le hook global (`git status` → `rtk git status`). Ne pas préfixer manuellement ; appeler `rtk gain` / `rtk discover` directement.

## Git flow

Le dépôt suit le flow global (`~/Github/Rules/global-rules.md`) : `main` = production (jamais de commit direct), `dev` = intégration, `feature/<nom>` / `fix/<nom>` éphémères créées depuis `dev`, mergées en `--ff-only` puis supprimées. Commits au format **Conventional Commits**.

Spécificité multi-projets : **scoper le commit au projet** — `feat(pwgen): ajoute le mode bulk CSV`. Un commit ne touche qu'un seul projet.

Le merge `dev` → `main` ne se fait **que** sur demande explicite de l'utilisateur.