392 lines
		
	
	
		
			13 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			392 lines
		
	
	
		
			13 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| <img src="https://r2cdn.perplexity.ai/pplx-full-logo-primary-dark%402x.png" style="height:64px;margin-right:32px"/>
 | |
| 
 | |
| # Prompt Expert pour Windsurf avec Claude Haiku 4.5 : Optimisation Performance ObsiViewer
 | |
| 
 | |
| Voici un prompt optimisé pour Windsurf utilisant Claude Haiku 4.5 afin d'implémenter la meilleure solution de performance pour ObsiViewer et offrir une expérience utilisateur optimale.[^1][^2][^3]
 | |
| 
 | |
| ## 🎯 Prompt Principal pour Windsurf (Claude Haiku 4.5)
 | |
| 
 | |
| ```markdown
 | |
| # RÔLE ET CONTEXTE
 | |
| Tu es un expert en optimisation de performance pour applications Angular + Node.js. Je travaille sur ObsiViewer, un visualiseur de notes Markdown avec un problème critique de performance au démarrage.
 | |
| 
 | |
| # PROBLÈME ACTUEL
 | |
| - **Temps de démarrage**: 15-30 secondes pour 1000+ fichiers
 | |
| - **Cause**: Chargement de TOUS les fichiers avec contenu complet + enrichissement frontmatter coûteux
 | |
| - **Payload réseau**: 5-10 MB
 | |
| - **Utilisation mémoire**: 200-300 MB
 | |
| 
 | |
| # OBJECTIF
 | |
| Implémenter Phase 1 de l'optimisation: **Chargement métadonnées d'abord** (metadata-first)
 | |
| 
 | |
| **Cibles de performance**:
 | |
| - Temps de démarrage < 5 secondes
 | |
| - Payload réseau < 1 MB
 | |
| - Utilisation mémoire < 100 MB
 | |
| - Amélioration de 75% minimum
 | |
| 
 | |
| # ARCHITECTURE CIBLE
 | |
| 
 | |
| ## Backend (Node.js/Express)
 | |
| 1. **Créer endpoint rapide**: `/api/vault/metadata`
 | |
|    - Retourne UNIQUEMENT: id, title, filePath, createdAt, updatedAt
 | |
|    - SANS enrichissement frontmatter
 | |
|    - SANS contenu complet
 | |
|    - Fallback sur Meilisearch puis filesystem
 | |
| 
 | |
| 2. **Optimiser fonction**: `loadVaultMetadataOnly(vaultPath)`
 | |
|    - Parcourir filesystem sans enrichissement
 | |
|    - Extraire titre du premier heading uniquement
 | |
|    - Retourner métadonnées légères
 | |
| 
 | |
| 3. **Modifier**: `loadVaultNotes()`
 | |
|    - SUPPRIMER l'appel à `enrichFrontmatterOnOpen()` au démarrage
 | |
|    - L'enrichissement se fera à la demande via `/api/files`
 | |
| 
 | |
| ## Frontend (Angular 19 + Signals)
 | |
| 1. **VaultService** avec approche lazy-loading:
 | |
|    - `initializeVault()`: charge métadonnées uniquement
 | |
|    - `ensureNoteContent(noteId)`: charge contenu à la demande
 | |
|    - Utiliser signals pour état réactif
 | |
| 
 | |
| 2. **AppComponent**:
 | |
|    - Initialiser vault au ngOnInit avec métadonnées
 | |
|    - Charger contenu quand utilisateur sélectionne note
 | |
| 
 | |
| # CONTRAINTES STRICTES
 | |
| - ✅ Rétrocompatible: garder `/api/vault` pour compatibilité
 | |
| - ✅ Pas de breaking changes
 | |
| - ✅ Tous les tests doivent passer
 | |
| - ✅ Performance mesurable: console.time() / console.timeEnd()
 | |
| - ✅ Gestion d'erreur robuste avec try/catch
 | |
| - ✅ TypeScript strict mode
 | |
| 
 | |
| # APPROCHE D'IMPLÉMENTATION
 | |
| 
 | |
| <default_to_action>
 | |
| Par défaut, implémente les changements plutôt que de seulement les suggérer. Si mon intention n'est pas claire, infère l'action la plus utile et procède en utilisant les outils pour découvrir les détails manquants.
 | |
| </default_to_action>
 | |
| 
 | |
| <use_parallel_tool_calls>
 | |
| Si tu dois appeler plusieurs outils sans dépendances entre eux, exécute-les en PARALLÈLE pour maximiser la vitesse. Par exemple: lire 3 fichiers = 3 appels simultanés.
 | |
| </use_parallel_tool_calls>
 | |
| 
 | |
| ## Séquence d'implémentation:
 | |
| 
 | |
| **ÉTAPE 1 - Backend** (fichier: `server/index.mjs`):
 | |
| 1. Ajouter fonction `loadVaultMetadataOnly()` après `loadVaultNotes()` (ligne ~175)
 | |
| 2. Créer endpoint `GET /api/vault/metadata` après `/api/files/list` (ligne ~478)
 | |
| 3. Modifier `loadVaultNotes()`: remplacer `enrichFrontmatterOnOpen()` par `fs.readFileSync()` (ligne ~138-141)
 | |
| 
 | |
| **ÉTAPE 2 - Frontend** (fichier: `src/app/services/vault.service.ts`):
 | |
| 1. Créer/modifier VaultService avec signals:
 | |
|    - Signal `allNotesMetadata`
 | |
|    - Méthode `initializeVault()`: appelle `/api/vault/metadata`
 | |
|    - Méthode `ensureNoteContent(noteId)`: charge contenu via `/api/files`
 | |
| 
 | |
| **ÉTAPE 3 - AppComponent** (fichier: `src/app.component.ts`):
 | |
| 1. Appeler `vaultService.initializeVault()` dans `ngOnInit()`
 | |
| 2. Modifier `selectNote()` pour appeler `ensureNoteContent()` avant affichage
 | |
| 
 | |
| **ÉTAPE 4 - Validation**:
 | |
| 1. Mesurer performance avec console.time()
 | |
| 2. Vérifier payload réseau dans DevTools
 | |
| 3. Tester sélection de notes
 | |
| 4. S'assurer aucune régression
 | |
| 
 | |
| # CODE DE RÉFÉRENCE DISPONIBLE
 | |
| J'ai fourni 6 fichiers de documentation détaillée:
 | |
| - PERFORMANCE_OPTIMIZATION_STRATEGY.md: stratégie complète
 | |
| - IMPLEMENTATION_PHASE1.md: guide pas-à-pas
 | |
| - CODE_EXAMPLES_PHASE1.md: snippets prêts à utiliser
 | |
| - ARCHITECTURE_DIAGRAMS.md: diagrammes de flux
 | |
| - RESUME_OPTIMISATION_PERFORMANCE.md: résumé exécutif
 | |
| - README_PERFORMANCE.md: vue d'ensemble
 | |
| 
 | |
| Réfère-toi à ces fichiers pour les détails d'implémentation exacts.
 | |
| 
 | |
| # FORMAT DE RÉPONSE ATTENDU
 | |
| 
 | |
| Pour chaque modification:
 | |
| 1. **Fichier concerné** avec chemin exact
 | |
| 2. **Ligne approximative** où faire le changement
 | |
| 3. **Code AVANT** (si modification)
 | |
| 4. **Code APRÈS** avec commentaires explicatifs
 | |
| 5. **Pourquoi** ce changement améliore la performance
 | |
| 6. **Mesure de succès** attendue
 | |
| 
 | |
| Après implémentation:
 | |
| - Résumer les changements effectués
 | |
| - Indiquer les fichiers modifiés
 | |
| - Fournir commande pour tester
 | |
| - Estimer amélioration de performance
 | |
| 
 | |
| # EXEMPLE DE WORKFLOW
 | |
| 
 | |
| Voici comment procéder:
 | |
| 
 | |
| ```
 | |
| 
 | |
| // 1. Créer endpoint métadonnées (backend)
 | |
| app.get('/api/vault/metadata', async (req, res) => {
 | |
| // Implémentation avec fallback Meilisearch → filesystem
 | |
| });
 | |
| 
 | |
| // 2. Fonction loader rapide (backend)
 | |
| const loadVaultMetadataOnly = async (vaultPath) => {
 | |
| // Parcourir sans enrichissement
 | |
| };
 | |
| 
 | |
| // 3. Service Angular (frontend)
 | |
| @Injectable({ providedIn: 'root' })
 | |
| export class VaultService {
 | |
| async initializeVault() {
 | |
| const metadata = await firstValueFrom(
 | |
| this.http.get('/api/vault/metadata')
 | |
| );
 | |
| // Stocker dans signal
 | |
| }
 | |
| 
 | |
| async ensureNoteContent(noteId: string) {
 | |
| // Charger contenu à la demande
 | |
| }
 | |
| }
 | |
| 
 | |
| ```
 | |
| 
 | |
| # MÉTRIQUES DE SUCCÈS
 | |
| Une fois terminé, je dois pouvoir:
 | |
| - [ ] Démarrer l'app en < 5 secondes
 | |
| - [ ] Voir la liste des notes immédiatement
 | |
| - [ ] Cliquer sur une note et voir son contenu en < 1 seconde
 | |
| - [ ] Vérifier payload < 1MB dans Network tab
 | |
| - [ ] Constater amélioration > 75%
 | |
| 
 | |
| # QUESTIONS À POSER
 | |
| Si tu as besoin de clarifications:
 | |
| - Sur la structure exacte des objets Note?
 | |
| - Sur les types TypeScript utilisés?
 | |
| - Sur la configuration Angular (standalone components)?
 | |
| - Sur les dépendances disponibles?
 | |
| 
 | |
| MAIS n'attend pas mes réponses pour commencer. Infère l'approche la plus logique et procède avec confiance. Je te guiderai si nécessaire.
 | |
| 
 | |
| # COMMENCER MAINTENANT
 | |
| Analyse les fichiers fournis, planifie les modifications, puis exécute l'implémentation étape par étape avec des checkpoints. Utilise tes capacités d'exécution parallèle pour maximiser l'efficacité.
 | |
| 
 | |
| Commence par: "Je vais implémenter la Phase 1 d'optimisation. Voici mon plan d'action..."
 | |
| ```
 | |
| 
 | |
| 
 | |
| ## 📋 Prompts Complémentaires pour Tâches Spécifiques
 | |
| 
 | |
| ### Pour la création du backend uniquement:
 | |
| 
 | |
| ```markdown
 | |
| **Tâche**: Créer uniquement la partie serveur de l'optimisation
 | |
| 
 | |
| **Fichier cible**: `server/index.mjs`
 | |
| 
 | |
| **Actions précises**:
 | |
| 1. Ligne ~175: Ajouter `loadVaultMetadataOnly()` (voir CODE_EXAMPLES_PHASE1.md section 1.1)
 | |
| 2. Ligne ~478: Ajouter endpoint `/api/vault/metadata` (voir section 1.2)
 | |
| 3. Ligne ~138-141: Remplacer enrichissement par lecture simple
 | |
| 
 | |
| **Contraintes**:
 | |
| - Garder compatibilité avec code existant
 | |
| - Ajouter console.log pour timing
 | |
| - Gestion d'erreur avec try/catch
 | |
| - Fallback Meilisearch → filesystem
 | |
| 
 | |
| **Test**: 
 | |
| ```
 | |
| 
 | |
| curl http://localhost:3000/api/vault/metadata | jq '. | length'
 | |
| 
 | |
| ```
 | |
| 
 | |
| Doit retourner le nombre de fichiers en < 1 seconde.
 | |
| ```
 | |
| 
 | |
| 
 | |
| ### Pour la partie frontend uniquement:
 | |
| 
 | |
| ```markdown
 | |
| **Tâche**: Implémenter VaultService avec lazy-loading
 | |
| 
 | |
| **Fichiers cibles**:
 | |
| - `src/app/services/vault.service.ts`
 | |
| - `src/app.component.ts`
 | |
| 
 | |
| **Architecture**:
 | |
| - Utiliser Angular 19 signals
 | |
| - HttpClient avec firstValueFrom
 | |
| - Gestion d'état avec computed signals
 | |
| 
 | |
| **Interface Note attendue**:
 | |
| ```
 | |
| 
 | |
| interface Note {
 | |
| id: string;
 | |
| title: string;
 | |
| filePath: string;
 | |
| content: string;  // Vide initialement
 | |
| createdAt: string;
 | |
| updatedAt: string;
 | |
| tags?: string[];
 | |
| frontmatter?: any;
 | |
| }
 | |
| 
 | |
| ```
 | |
| 
 | |
| **Méthodes requises**:
 | |
| 1. `initializeVault()`: charge `/api/vault/metadata`
 | |
| 2. `ensureNoteContent(noteId)`: charge `/api/files?path=...`
 | |
| 3. `getNoteById(noteId)`: retourne note du signal
 | |
| 
 | |
| Référence: CODE_EXAMPLES_PHASE1.md section 2.1
 | |
| ```
 | |
| 
 | |
| 
 | |
| ### Pour les tests de performance:
 | |
| 
 | |
| ```markdown
 | |
| **Tâche**: Créer script de benchmark pour mesurer l'amélioration
 | |
| 
 | |
| **Créer**: `scripts/test-performance.mjs`
 | |
| 
 | |
| **Mesures à effectuer**:
 | |
| 1. Temps de réponse `/api/vault/metadata` vs `/api/vault`
 | |
| 2. Taille du payload (bytes)
 | |
| 3. Temps de parsing côté client
 | |
| 4. Utilisation mémoire
 | |
| 
 | |
| **Format de sortie**:
 | |
| ```
 | |
| 
 | |
| === Performance Comparison ===
 | |
| Metadata endpoint: XXXms (XXXKB)
 | |
| Full vault endpoint: XXXms (XXXMB)
 | |
| Improvement: XX% faster, XX% smaller
 | |
| 
 | |
| ```
 | |
| 
 | |
| Réfère-toi à CODE_EXAMPLES_PHASE1.md section 3.1 pour l'implémentation.
 | |
| ```
 | |
| 
 | |
| 
 | |
| ## 🎨 Conseils d'Utilisation avec Windsurf
 | |
| 
 | |
| ### Configuration optimale pour Claude Haiku 4.5:[^4][^5][^6]
 | |
| 
 | |
| 1. **Dans Windsurf Settings**:
 | |
|     - Provider: Anthropic
 | |
|     - Model: `claude-haiku-4-5`
 | |
|     - Mode: Cascade (pour exécution agentic)
 | |
| 2. **Stratégie de prompting**:[^7][^8]
 | |
|     - Prompts courts et spécifiques
 | |
|     - Indiquer fichier exact et lignes approximatives
 | |
|     - Utiliser `<default_to_action>` pour comportement proactif
 | |
|     - Activer `<use_parallel_tool_calls>` pour vitesse maximale
 | |
| 3. **Workflow itératif**:[^5]
 | |
|     - Faire un checkpoint avant chaque changement majeur
 | |
|     - Tester immédiatement après chaque étape
 | |
|     - Utiliser slash commands pour tâches répétitives
 | |
|     - Rollback rapide si problème
 | |
| 4. **Performance optimale**:[^6]
 | |
|     - Haiku 4.5 offre 90% de la performance de Sonnet 4.5
 | |
|     - 2-4x plus rapide que Sonnet 4.5
 | |
|     - 1/3 du coût
 | |
|     - Idéal pour tâches de codage iteratives
 | |
| 
 | |
| ## 🔄 Workflow Recommandé
 | |
| 
 | |
| 1. **Initialisation**:
 | |
| 
 | |
| ```
 | |
| /quick-fix target=server/index.mjs task="Ajouter endpoint metadata"
 | |
| ```
 | |
| 
 | |
| 2. **Vérification**:
 | |
|     - Checkpoint après chaque fichier modifié
 | |
|     - Tests unitaires si disponibles
 | |
|     - Mesures de performance
 | |
| 3. **Itération**:
 | |
|     - Si résultat incomplet: clarifier le prompt
 | |
|     - Si trop lent: vérifier exécution parallèle
 | |
|     - Si erreur: rollback au checkpoint
 | |
| 4. **Validation finale**:
 | |
|     - Tester avec 1000+ fichiers
 | |
|     - Mesurer métriques avant/après
 | |
|     - Vérifier expérience utilisateur
 | |
| 
 | |
| ## 📊 Métriques de Succès Attendues[^2][^1]
 | |
| 
 | |
| Avec cette approche optimisée pour Haiku 4.5:
 | |
| 
 | |
| 
 | |
| | Métrique | Avant | Après | Amélioration |
 | |
| | :-- | :-- | :-- | :-- |
 | |
| | Démarrage | 15-30s | 2-5s | **75-80%** |
 | |
| | Payload | 5-10MB | 0.5-1MB | **90%** |
 | |
| | Mémoire | 200-300MB | 50-100MB | **75%** |
 | |
| | Interactivité | 20-35s | 3-5s | **85%** |
 | |
| 
 | |
| Ce prompt est optimisé pour tirer parti des forces de Claude Haiku 4.5: rapidité d'exécution, efficacité pour le code, et capacité à gérer des workflows itératifs avec checkpoints. L'utilisation de balises structurées `<default_to_action>` et `<use_parallel_tool_calls>` exploite les capacités natives du modèle pour un développement plus rapide et efficace.[^8][^4][^5][^6]
 | |
| <span style="display:none">[^10][^11][^12][^13][^14][^15][^16][^17][^18][^19][^20][^21][^22][^23][^24][^25][^26][^9]</span>
 | |
| 
 | |
| <div align="center">⁂</div>
 | |
| 
 | |
| [^1]: PERFORMANCE_OPTIMIZATION_STRATEGY.md
 | |
| 
 | |
| [^2]: RESUME_OPTIMISATION_PERFORMANCE.md
 | |
| 
 | |
| [^3]: README_PERFORMANCE.md
 | |
| 
 | |
| [^4]: https://intelligence-artificielle.developpez.com/actu/376774/Anthropic-lance-Claude-Haiku-4-5-la-variante-la-plus-compacte-de-cette-generation-de-LLM-d-Anthropic-et-promet-des-performances-proches-de-celles-du-modele-d-IA-GPT-5-d-OpenAI/
 | |
| 
 | |
| [^5]: https://skywork.ai/blog/terminal-workflows-haiku-4-5-claude-code-best-practices-2025/
 | |
| 
 | |
| [^6]: https://www.anthropic.com/news/claude-haiku-4-5
 | |
| 
 | |
| [^7]: https://www.mintlify.com/blog/6-tips-every-developer-should-know-when-using-cursor-and-windsurf
 | |
| 
 | |
| [^8]: https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
 | |
| 
 | |
| [^9]: IMPLEMENTATION_PHASE1.md
 | |
| 
 | |
| [^10]: ARCHITECTURE_DIAGRAMS.md
 | |
| 
 | |
| [^11]: CODE_EXAMPLES_PHASE1.md
 | |
| 
 | |
| [^12]: https://www.reddit.com/r/ClaudeAI/comments/1mfi3yg/a_few_megaprompts_optimized_for_claude_4_sonnet/
 | |
| 
 | |
| [^13]: https://www.youtube.com/watch?v=IvYWAukjVpI
 | |
| 
 | |
| [^14]: https://www.youtube.com/watch?v=Xx0ZRhg86Uo
 | |
| 
 | |
| [^15]: https://www.youtube.com/watch?v=B_Xu4N6qQbc
 | |
| 
 | |
| [^16]: https://www.youtube.com/watch?v=ds7FiTaUuxI
 | |
| 
 | |
| [^17]: https://blog.promptlayer.com/claude-prompt-generator/
 | |
| 
 | |
| [^18]: https://www.datacamp.com/tutorial/windsurf-ai-agentic-code-editor
 | |
| 
 | |
| [^19]: https://www.youtube.com/watch?v=Qc5DNu6kUj4
 | |
| 
 | |
| [^20]: https://www.reddit.com/r/windsurf/comments/1nxqk45/why_claude_sonnet_45_in_windsurf_is_stupider_than/
 | |
| 
 | |
| [^21]: https://docs.windsurf.com/best-practices/use-cases
 | |
| 
 | |
| [^22]: https://sider.ai/blog/ai-tools/prompt-strategies-that-work-best-with-claude-haiku-4_5
 | |
| 
 | |
| [^23]: https://www.zdnet.fr/actualites/anthropic-lance-un-modele-gratuit-plus-rapide-que-sonnet-4-483542.htm
 | |
| 
 | |
| [^24]: https://docs.windsurf.com/windsurf/models
 | |
| 
 | |
| [^25]: https://uibakery.io/blog/windsurf-ai-rules
 | |
| 
 | |
| [^26]: https://www.reddit.com/r/ClaudeAI/comments/1o7gk6o/introducing_claude_haiku_45_our_latest_small_model/
 | |
| 
 |