veza/CURSOR_PROMPT_VERSIONING.md

# PROMPT CURSOR — Initialisation / Mise à jour du système de versionnage Veza

---

## USAGE

Ce prompt est à utiliser dans deux cas :
1. **Première initialisation** : créer `VEZA_VERSIONS_ROADMAP.md` à partir des ORIGIN docs
2. **Mise à jour** : ajuster le roadmap après une évolution du projet

Pour le travail quotidien, tu n'as pas besoin de ce prompt.
Dis simplement à Cursor : **"implémente la prochaine version"**

---

## PROMPT À COLLER DANS CURSOR

```
Tu es l'architecte principal du projet Veza, une plateforme de collaboration audio pour musiciens indépendants.

## Contexte

Le projet possède une documentation de référence dans le dossier ORIGIN/ du monorepo :
- ORIGIN_MASTER_ARCHITECTURE.md — architecture système complète
- ORIGIN_FEATURES_REGISTRY.md — registre des 560 features actives (40 supprimées pour raisons éthiques)
- ORIGIN_IMPLEMENTATION_TASKS.md — tâches d'implémentation avec priorités P0/P1
- ORIGIN_SECURITY_FRAMEWORK.md — framework de sécurité (dont VEZA-SEC-001/002 critiques)
- ORIGIN_DEVELOPMENT_PHASES.md — phases P3.5 → P6R
- ORIGIN_REVISION_SUMMARY.md — résumé de la révision éthique v2.0.0
- ORIGIN_CODE_STANDARDS.md — standards de code Go/Rust/TypeScript
- ORIGIN_FEATURE_VALIDATION_STRATEGY.md — checklist de validation (dont Phase 7 éthique)
- ORIGIN_ERROR_PATTERNS.md — patterns d'erreur à éviter (PAT-024 à PAT-028)
- ORIGIN_BUSINESS_LOGIC.md — règles métier et principes éthiques

## Ta mission

Lire TOUS ces fichiers ORIGIN, puis créer (ou mettre à jour) le fichier `VEZA_VERSIONS_ROADMAP.md` à la racine du repo.

Ce fichier est le système de versionnage opérationnel du projet. Il doit permettre de dire simplement "implémente la prochaine version" pour déclencher une session de travail complète, autonome, et correcte.

## Structure requise du fichier VEZA_VERSIONS_ROADMAP.md

### Pour chaque version, inclure :

1. **Numéro de version** (ex: v0.9.1) en suivant le schéma :
   - v0.9.x : Phase P3.5 (Consolidation & Sécurité)
   - v0.10.x : Phase P4R (Social & Live)
   - v0.11.x : Phase P5R (Analytics & Recherche)
   - v0.12.x : Phase P6R (Premium & Infrastructure)
   - v1.0.0 : Release stable

2. **Nom descriptif** de la version (ex: "JWT Migration RS256")

3. **Statut** : ⏳ TODO | 🔄 IN PROGRESS | ✅ DONE

4. **Priorité** : P0 (bloquant) | P1 (haute) | P2 (moyenne) | P3 (basse)

5. **Durée estimée** en jours

6. **Prerequisite** : liste des versions qui doivent être DONE avant

7. **Objectif** : une phrase claire sur ce que cette version accomplit

8. **Tâches** : liste de checkboxes avec :
   - Référence aux TASK-XXX de ORIGIN_IMPLEMENTATION_TASKS.md si applicable
   - Référence aux features Fxxx de ORIGIN_FEATURES_REGISTRY.md
   - Description précise de ce qui doit être implémenté
   - Fichiers principaux à modifier (backend, frontend, infra)

9. **Critères d'acceptation** : liste de conditions vérifiables (pas ambiguës)

### Contraintes absolues (à respecter dans tout le fichier)

- Les versions doivent être **atomiques** : chaque version est mergeable indépendamment
- Les versions doivent être **séquentielles** dans chaque phase (pas de parallélisme)
- Les tâches P0 de ORIGIN_IMPLEMENTATION_TASKS.md (TASK-SEC-001/002) passent EN PREMIER
- Aucune version ne doit implémenter du code AI/ML, blockchain/Web3, ou gamification addictive
- Les critères d'acceptation doivent être **vérifiables automatiquement** (tests, métriques) ou **vérifiables manuellement** (checklist UX)
- La Phase 7 de validation éthique de ORIGIN_FEATURE_VALIDATION_STRATEGY.md s'applique à toute version touchant la découverte, les métriques, ou les interactions sociales

### Section finale obligatoire : "Instructions pour Cursor"

À la fin du fichier, inclure une section expliquant le protocole à suivre quand Cursor reçoit "implémente la prochaine version" :
1. Identifier la prochaine version TODO
2. Vérifier les prerequisites
3. Lire les fichiers ORIGIN référencés
4. Implémenter
5. Valider selon ORIGIN_FEATURE_VALIDATION_STRATEGY.md
6. Marquer comme DONE dans ce fichier
7. Créer le tag git

### Section finale obligatoire : "Règles immuables pour Cursor"

Liste des choses que Cursor ne doit JAMAIS faire, dérivées de la révision éthique v2.0.0.

## Critères de qualité du fichier généré

- Le fichier doit être complet : de v0.9.1 jusqu'à v1.0.0, sans saut
- Chaque version doit avoir minimum 3 tâches et 3 critères d'acceptation
- Les références aux fichiers ORIGIN doivent être exactes (section + numéro de feature)
- Les durées estimées doivent être réalistes (1 développeur, pas d'optimisme excessif)
- Les prerequisites doivent former un graphe acyclique cohérent

## Ce que tu NE dois PAS faire

- Ne pas modifier les fichiers ORIGIN/ (ils sont en lecture seule)
- Ne pas créer d'autres fichiers que VEZA_VERSIONS_ROADMAP.md
- Ne pas inventer des features qui ne sont pas dans les ORIGIN docs
- Ne pas ignorer les features supprimées pour raisons éthiques (F456-F470, F491-F500, F536-F550)

## Format de sortie

Fichier Markdown unique : VEZA_VERSIONS_ROADMAP.md
Encodage : UTF-8
Longueur : aussi long que nécessaire pour être complet et exploitable

Commence par lire tous les fichiers ORIGIN/ avant d'écrire une seule ligne du fichier de sortie.
```

---

## NOTES D'UTILISATION

### Pour initialiser le roadmap (première fois)
Colle le prompt ci-dessus dans Cursor. Il lira tes ORIGIN docs et générera le fichier.

### Pour implémenter une version (usage quotidien)
Dis simplement à Cursor dans un nouveau chat :
```
Implémente la prochaine version. Le fichier VEZA_VERSIONS_ROADMAP.md 
est à la racine du repo et contient les instructions.
```

### Pour mettre à jour le roadmap après un changement d'architecture
```
Le fichier VEZA_VERSIONS_ROADMAP.md est à la racine du repo. 
[Décrire le changement].
Mets à jour les versions concernées sans toucher aux versions déjà DONE
et sans modifier les fichiers ORIGIN/.
```

### Pour voir où en est le projet
```
Donne-moi un résumé de l'avancement dans VEZA_VERSIONS_ROADMAP.md :
versions DONE, version en cours, prochaine version, et estimation 
pour atteindre v1.0.0.
```