docs : update project documentation and frontend submodule pointer

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

RELEASE.md

@@ -1,12 +1,18 @@
 # Guide de Release
 
-## Versioning
+## C'est quoi une release ?
 
-Le projet utilise le [Semantic Versioning](https://semver.org/) (SemVer) : `MAJOR.MINOR.PATCH`
+Une release c'est une **version officielle** de l'application. Chaque release a un numéro de version (ex: `1.8.1`) et est marquée par un **tag git**.
 
-- **MAJOR** : Changements incompatibles avec les versions précédentes
-- **MINOR** : Nouvelles fonctionnalités rétrocompatibles
-- **PATCH** : Corrections de bugs rétrocompatibles
+## Versioning (Semantic Versioning)
+
+Le projet utilise le [Semantic Versioning](https://semver.org/) : `MAJOR.MINOR.PATCH`
+
+| Type | Quand l'utiliser | Exemple |
+|------|------------------|---------|
+| **PATCH** | Correction de bug, pas de nouvelle fonctionnalité | `1.8.0` → `1.8.1` |
+| **MINOR** | Nouvelle fonctionnalité, rétrocompatible | `1.8.1` → `1.9.0` |
+| **MAJOR** | Changement majeur, potentiellement incompatible | `1.9.0` → `2.0.0` |
 
 La version est centralisée dans le fichier `VERSION` à la racine du projet.
 
@@ -14,9 +20,9 @@ La version est centralisée dans le fichier `VERSION` à la racine du projet.
 
 ### Prérequis
 
-- Tous les changements doivent être commités
-- Les tests doivent passer
-- Être sur la branche à releaser (ex: `main`, `develop`)
+- Tous les changements doivent être commités (pas de fichiers modifiés non commités)
+- Les tests doivent passer (`make test`)
+- Être sur la branche à releaser (généralement `develop` ou `master`)
 
 ### Utilisation du script
 
@@ -24,28 +30,38 @@ La version est centralisée dans le fichier `VERSION` à la racine du projet.
 # Afficher l'aide et la version actuelle
 ./scripts/release.sh
 
-# Bump patch : 1.0.0 → 1.0.1
+# Bump patch : 1.8.1 → 1.8.2
 ./scripts/release.sh patch
 
-# Bump minor : 1.0.0 → 1.1.0
+# Bump minor : 1.8.1 → 1.9.0
 ./scripts/release.sh minor
 
-# Bump major : 1.0.0 → 2.0.0
+# Bump major : 1.8.1 → 2.0.0
 ./scripts/release.sh major
 
 # Version spécifique
 ./scripts/release.sh 2.0.0
 ```
 
-Le script :
-1. Met à jour le fichier `VERSION`
-2. Met à jour `config/packages/api_platform.yaml`
-3. Crée un commit `chore(release): vX.Y.Z`
-4. Crée le tag `vX.Y.Z`
+### Que fait le script ?
+
+1. Vérifie qu'il n'y a pas de changements non commités
+2. Vérifie/commit le submodule frontend si nécessaire
+3. Met à jour le fichier `VERSION` avec le nouveau numéro
+4. Met à jour `config/packages/api_platform.yaml` (version affichée dans l'API)
+5. Crée un commit `chore(release) : vX.Y.Z`
+6. Crée le tag git `vX.Y.Z`
+7. Affiche les commandes pour pousser
 
 ### Pousser la release
 
+Après avoir exécuté le script :
+
 ```bash
+# Pousser le frontend d'abord (si modifié)
+cd Inventory_frontend && git push && git push --tags && cd ..
+
+# Pousser le backend
 git push && git push --tags
 ```
 
@@ -54,12 +70,21 @@ git push && git push --tags
 1. Aller sur le dépôt Gitea
 2. **Releases** > **New Release**
 3. Sélectionner le tag `vX.Y.Z`
-4. Titre : `v1.0.0` (ou avec un nom descriptif)
-5. Description : résumé des changements (voir section Notes de release)
+4. Titre : `vX.Y.Z` (ou avec un nom descriptif)
+5. Description : résumé des changements (copier depuis CHANGELOG.md)
+
+## Fichiers impactés par le versioning
+
+| Fichier | Rôle |
+|---------|------|
+| `VERSION` | Source unique de vérité |
+| `config/packages/api_platform.yaml` | Version affichée dans la doc API (Swagger) |
+| `Inventory_frontend/nuxt.config.ts` | Lit `VERSION` au build pour l'afficher dans le footer |
+| Footer de l'app | Affiche `v{{ appVersion }}` |
 
 ## Notes de release
 
-Template pour les notes de release :
+Template pour les notes de release (à copier dans Gitea) :
 
 ```markdown
 ## Nouveautés
@@ -73,66 +98,25 @@ Template pour les notes de release :
 ## Changements
 - Refactoring de Z
 - Mise à jour des dépendances
+
+## Migration requise
+\`\`\`bash
+docker compose exec web php bin/console doctrine:migrations:migrate
+\`\`\`
 ```
 
-## Fichiers impactés par le versioning
+## Déploiement après une release
 
-| Fichier | Usage |
-|---------|-------|
-| `VERSION` | Source unique de vérité |
-| `config/packages/api_platform.yaml` | Version affichée dans l'API |
-| `Inventory_frontend/nuxt.config.ts` | Lit VERSION au build |
-| Footer de l'app | Affiche `v{{ appVersion }}` |
+Voir [DEPLOY.md](DEPLOY.md) pour les instructions de mise à jour en production.
 
-## Déploiement en production
-
-### 1. Base de données
-
-Dump de la base locale :
-```bash
-pg_dump -h localhost -p 5433 -U root -d inventory > backup_v1.0.0.sql
-```
-
-Import en production :
-```bash
-psql -h <PROD_HOST> -U <PROD_USER> -d inventory < backup_v1.0.0.sql
-```
-
-### 2. Variables d'environnement production
-
-Créer un fichier `.env.local` en production avec :
-
-```env
-APP_ENV=prod
-APP_SECRET=<générer avec: openssl rand -hex 32>
-DATABASE_URL="postgresql://user:password@host:5432/inventory?serverVersion=16"
-CORS_ALLOW_ORIGIN='^https://votre-domaine\.com$'
-JWT_SECRET_KEY=%kernel.project_dir%/config/jwt/private.pem
-JWT_PUBLIC_KEY=%kernel.project_dir%/config/jwt/public.pem
-JWT_PASSPHRASE=<votre-passphrase>
-```
-
-### 3. Build production
-
-Backend :
+En résumé :
 ```bash
+# Sur le serveur de production
+cd /var/www/Inventory
+git pull
+git submodule update --init --recursive
 composer install --no-dev --optimize-autoloader
-php bin/console cache:clear --env=prod
 php bin/console doctrine:migrations:migrate --no-interaction
+php bin/console cache:clear --env=prod
+cd Inventory_frontend && npm install && npx nuxi generate
 ```
-
-Frontend :
-```bash
-cd Inventory_frontend
-NUXT_PUBLIC_API_BASE_URL=https://api.votre-domaine.com yarn build
-```
-
-### 4. Checklist avant mise en prod
-
-- [ ] Tests passent
-- [ ] Migrations DB testées
-- [ ] Variables d'environnement configurées
-- [ ] Clés JWT générées
-- [ ] CORS configuré
-- [ ] SSL/HTTPS actif
-- [ ] Backup de la DB prod existante (si upgrade)