SimpleClient-releases/.claude/commands/dev.md

# Workflow complet de développement (de A à Z)

Suivre **systématiquement** ce workflow pour chaque nouvelle fonctionnalité ou correction de bug :

## Phase 1 : Développement itératif

### Principe : Petit à petit, commit par commit

**Une fonctionnalité = plusieurs petits commits atomiques**

Éviter de faire un gros commit avec toute la fonctionnalité. Préférer découper en petites étapes testables :

```
Exemple : Ajouter un bouton "Pause" avec confirmation

❌ MAUVAIS : 1 gros commit
git commit -m "feat: Ajouter bouton Pause avec modal et gestion IPBX"

✅ BON : 5 petits commits
1. feat: Ajouter le bouton Pause dans le header
2. style: Ajouter l'icône SVG pour le bouton Pause
3. feat: Implémenter la modal de confirmation
4. feat: Connecter le bouton à SignalR pour pause IPBX
5. docs: Documenter la fonctionnalité de pause
```

### 1. Créer une branche feature

```bash
git checkout -b feature/nom-de-la-fonctionnalite
```

### 2. Cycle itératif (répéter jusqu'à complétion de la fonctionnalité)

**Pour chaque petite modification :**

#### a) Développer une petite partie

- Faire UNE modification logique à la fois
- Ne pas chercher à tout finir d'un coup
- Rester concentré sur une seule tâche

#### b) Tester

**IMPORTANT : Toujours tester AVANT de committer**

```bash
npm run dev  # Test en mode développement
```

- Vérifier que la modification fonctionne
- Tester les cas limites
- S'assurer qu'aucune régression n'a été introduite

#### c) Committer (commit atomique)

Seulement après avoir testé avec succès :

- Préfixes : `feat:`, `fix:`, `refactor:`, `docs:`, `style:`, `test:`, `chore:`
- Un commit = une modification logique
- Messages clairs et descriptifs

```bash
git commit -m "feat: Ajouter le bouton Pause dans le header"
```

**Pourquoi tester avant de committer ?**
- Historique Git propre (chaque commit = code fonctionnel)
- Rollback facile vers un état stable
- `git bisect` fonctionne correctement

#### d) Continuer

Retour à l'étape **a)** pour la prochaine petite modification, jusqu'à ce que la fonctionnalité soit complète.

### 3. Fonctionnalité terminée → Passer à la Phase 2 (Release)

Une fois tous les commits de la fonctionnalité effectués, passer à la préparation de la release ci-dessous.

**Exception - WIP commits** (travail en cours à sauvegarder) :

```bash
git commit -m "wip: Travail en cours sur la fonctionnalité X"
# Plus tard, après tests réussis :
git commit --amend -m "feat: Ajouter la fonctionnalité X"
```

---

## Phase 2 : Préparation de la release

### 4. Mettre à jour le changelog (`docs/changelog.md`)

- Obtenir la date : `date +%Y-%m-%d`
- Format : `## [X.X.X] - AAAA-MM-JJ`
- Catégories : **Ajouté**, **Modifié**, **Corrigé**, **Supprimé**, **Technique**, **Documentation**
- Ajouter en haut du fichier (au-dessus de la version précédente)

### 5. Bumper la version (`package.json`)

- **PATCH** (x.x.+1) : Corrections, petits ajustements
- **MINOR** (x.+1.0) : Nouvelles fonctionnalités compatibles
- **MAJOR** (+1.0.0) : Changements majeurs incompatibles
- Modifier le champ `"version": "X.X.X"`

### 6. Commit de release

```bash
git add docs/changelog.md package.json
git commit -m "release: Version X.X.X - Titre court

- Fonctionnalité 1
- Fonctionnalité 2
- Correction 1
- Bump version X.X.X"
```

**Important** : Ne jamais mentionner Claude, Anthropic ou des adresses emails relatives à ces entités

---

## Phase 3 : Fusion dans main

### 7. Basculer sur main et fusionner

```bash
git checkout main
git merge feature/nom-de-la-fonctionnalite --no-ff
```

- `--no-ff` : Force un merge commit (historique propre et tracé)

### 8. Push vers origin

```bash
git push origin main
```

---

## Phase 4 : Build des exécutables

### 9. Build pour les plateformes nécessaires

```bash
# macOS (si développement sur Mac)
npm run build

# Linux x64 (production principale)
npm run build:linux-x64

# Windows (si nécessaire)
npm run build:win
```

### 10. Organiser les builds dans `dist/vX.X.X/`

```bash
# Créer le dossier de version
mkdir -p dist/vX.X.X

# Copier le changelog
cp docs/changelog.md dist/vX.X.X/CHANGELOG.md

# Déplacer les builds
mv dist/SimpleConnect-X.X.X*.{AppImage,dmg,zip,exe} dist/vX.X.X/ 2>/dev/null
mv dist/SimpleConnect-X.X.X*.blockmap dist/vX.X.X/ 2>/dev/null

# Vérifier le contenu
ls -lh dist/vX.X.X/
```

---

## Phase 5 : Documentation finale

### 11. Créer les notes de release (`releases/vX.X.X.md`)

- Structure markdown avec sections :
  - Titre et date
  - Résumé des changements
  - Nouveautés principales
  - Corrections
  - Fichiers disponibles
  - Compatibilité
  - Guide d'utilisation (si nécessaire)

### 12. Commit et push de la documentation

```bash
git add releases/vX.X.X.md
git commit -m "docs: Ajout des notes de release pour vX.X.X"
git push origin main
```

---

## Phase 6 : Publication sur Gitea

### 13. Créer le tag Git

```bash
# Trouver le commit de release
git log --oneline --grep="X.X.X" -5

# Créer le tag annoté
git tag -a vX.X.X <commit-hash> -m "Release vX.X.X - Titre court

Description des principales fonctionnalités
- Fonctionnalité 1
- Fonctionnalité 2
- Correction 1"
```

### 14. Push du tag vers Gitea

```bash
git push origin vX.X.X
```

### 15. Créer la release sur Gitea avec l'outil `tea`

**Prérequis** : S'assurer que `tea` est configuré avec le login `simpleconnect`

```bash
# Vérifier la configuration tea
tea login list

# Créer la release avec tous les fichiers binaires
tea release create \
  --login simpleconnect \
  --repo pierre/SimpleConnect-client-electron \
  --tag vX.X.X \
  --title "SimpleConnect vX.X.X - Titre de la release" \
  --note-file releases/vX.X.X.md \
  --asset dist/vX.X.X/SimpleConnect-X.X.X.AppImage \
  --asset dist/vX.X.X/SimpleConnect-X.X.X-arm64.dmg \
  --asset dist/vX.X.X/SimpleConnect-X.X.X-arm64-mac.zip
```

**Notes importantes** :
- L'option `--note-file` utilise le fichier markdown des notes de release
- On peut spécifier plusieurs `--asset` pour uploader tous les binaires en une fois
- Le code source (TAR.GZ et ZIP) est ajouté automatiquement par Gitea

### 16. Vérifier la release sur Gitea

```bash
# Lister toutes les releases
tea release list --login simpleconnect --repo pierre/SimpleConnect-client-electron

# Vérifier les assets d'une release spécifique
tea release assets --login simpleconnect --repo pierre/SimpleConnect-client-electron vX.X.X
```

**Résultat attendu** :
- ✅ SimpleConnect-X.X.X.AppImage (Linux x64)
- ✅ SimpleConnect-X.X.X-arm64.dmg (macOS)
- ✅ SimpleConnect-X.X.X-arm64-mac.zip (macOS)
- ✅ Code source (TAR.GZ et ZIP automatiques)

### 17. Ajouter des assets manquants (si nécessaire)

Si des fichiers ont été oubliés ou doivent être ajoutés après coup :

```bash
tea release assets create \
  --login simpleconnect \
  --repo pierre/SimpleConnect-client-electron \
  vX.X.X \
  dist/vX.X.X/fichier-supplementaire.ext
```

### 18. Supprimer des assets en doublon (si nécessaire)

```bash
tea release assets delete \
  --login simpleconnect \
  --repo pierre/SimpleConnect-client-electron \
  --confirm \
  vX.X.X \
  nom-du-fichier.ext
```

---

## Phase 7 : Déploiement sur serveur (optionnel)

### 19. Déployer sur le serveur de production

```bash
scp dist/vX.X.X/SimpleConnect-X.X.X.AppImage user@server:/path/to/app/
```

---

## Résumé du workflow complet

```
1. git checkout -b feature/XXX
2. BOUCLE (jusqu'à fonctionnalité complète) :
   a) Développer une petite partie
   b) Tester (npm run dev)
   c) Committer (git commit -m "...")
   d) Continuer
3. Mettre à jour changelog
4. Bumper version package.json
5. Commit de release
6. Merger dans main (--no-ff)
7. Push
8. Build des exécutables
9. Organiser dist/vX.X.X/
10. Notes de release
11. Commit + push docs
12. Créer tag Git
13. Push tag vers Gitea
14. Créer release sur Gitea avec tea
15. Vérifier assets sur Gitea
16. Déployer sur serveur (optionnel)
```

---

## Commandes `tea` utiles

### Gestion des logins
```bash
tea login list                    # Lister les logins configurés
tea login add                     # Ajouter un nouveau login
tea login default <nom>           # Définir un login par défaut
```

### Gestion des releases
```bash
tea release list --login simpleconnect --repo pierre/SimpleConnect-client-electron
tea release create --help
tea release edit vX.X.X --title "Nouveau titre"
tea release delete vX.X.X --confirm
```

### Gestion des assets
```bash
tea release assets list vX.X.X
tea release assets create vX.X.X fichier.ext
tea release assets delete vX.X.X fichier.ext --confirm
```

### Options globales
```bash
--login simpleconnect             # Utiliser le login 'simpleconnect'
--repo pierre/SimpleConnect-client-electron  # Spécifier le repository
--output json                     # Format de sortie (simple, table, json, yaml)
```