Détecter la pile du repository (installation SDK)

Avant d'installer quoi que ce soit, vous devez comprendre le projet. Identifiez avec quoi le projet est construit et si LaunchDarkly est déjà présent.

Cette skill est imbriquée sous LaunchDarkly SDK Install (onboarding) ; l'étape parent Step 1 est detect. Suivant : Generate integration plan sauf si l'arbre de décision vous envoie ailleurs.

1. Langage et framework

Cherchez les fichiers indicateurs ci-dessous (et la structure racine associée), puis lisez les manifestes pertinents pour déduire le langage et le framework.

Cherchez ces fichiers pour identifier la pile :

Lisez le fichier de dépendances pour identifier le framework spécifique. Pour package.json, vérifiez à la fois dependencies et devDependencies.

Si vous ne pouvez pas identifier le langage ou le framework :

D5 -- BLOQUANT : Appelez votre outil de question structurée maintenant.

• question: "Je n'ai pas pu détecter le langage ou le framework du projet. Quel SDK souhaitez-vous utiliser ?"
• options: Présentez les SDKs disponibles de SDK recipes comme options sélectionnables.
• ARRÊTEZ. N'écrivez pas la question en tant que texte. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

2. Package manager

Identifiez comment le projet installe les dépendances :

Utilisez le package manager détecté pour toutes les commandes d'installation. Si plusieurs fichiers de lock existent, préférez celui qui a été modifié le plus récemment.

3. Disposition monorepo

Certains repositories hébergent plusieurs packages ou services. Cherchez ces indicateurs :

Quand l'un de ces cas s'applique, ne supposez pas que la racine du repo est la cible d'intégration :

D5 -- BLOQUANT : Appelez votre outil de question structurée maintenant.

• question: "Ceci est un monorepo. Dans quel package, app ou service dois-je intégrer LaunchDarkly ?"
• options: Listez les packages/apps découverts comme options sélectionnables.
• ARRÊTEZ. N'écrivez pas la question en tant que texte. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

Ensuite, exécutez le reste de cette étape detect -- langage, package manager, entrypoint et recherche SDK -- dans ce répertoire cible (et son sous-arbre), pas uniquement à la racine.

4. Point d'entrée de l'application

Trouvez le fichier principal où l'application démarre. Dans un monorepo, appliquez les motifs ci-dessous dans le package choisi après la section 3 Disposition monorepo. Motifs courants :

• Node.js (serveur) : Vérifiez le champ "main" de package.json, ou cherchez index.js, server.js, app.js, src/index.ts
• NestJS : Cherchez src/main.ts ou src/main.js
• Python : Cherchez app.py, main.py, manage.py, wsgi.py, ou la section [tool.poetry.scripts]
• Go : Cherchez main.go ou cmd/*/main.go
• Java : Recherchez public static void main ou @SpringBootApplication
• Ruby : Cherchez config.ru, config/application.rb
• React/Vue/Angular : Cherchez src/index.tsx, src/main.tsx, src/App.tsx, src/main.ts
• Next.js : App Router -- app/layout.tsx ou app/layout.js (layout racine). Pages Router -- pages/_app.tsx ou pages/_app.js
• React Native : Cherchez App.tsx, App.js, index.js (avec AppRegistry.registerComponent)
• Electron : Vérifiez "main" dans package.json ; les chemins courants incluent main.js ou src/main.ts
• JavaScript (navigateur) : Cherchez index.html, src/index.js, ou l'entrée du bundler dans webpack.config.js / vite.config.ts
• Flutter : Cherchez lib/main.dart
• Swift/iOS : Cherchez AppDelegate.swift, SceneDelegate.swift, ou une struct @main
• Android : Cherchez MainActivity.java ou MainActivity.kt

5a. Classer la confiance de l'espace de travail

Après les sections 1-4, classifiez l'espace de travail dans l'un des trois états avant de continuer. Cette classification détermine comment le reste du flux se déroule.

Les preuves faibles ne doivent pas être traitées comme une confirmation. Exemples de preuves faibles :

• Un package.json sans section scripts et sans fichiers source d'application
• Un seul requirements.txt dans un répertoire de fichiers de données ou de notebooks
• Répertoires de config, de thème ou de fixture avec manifestes qui ne représentent pas un service exécutable
• Racines de monorepo où les vraies apps vivent dans des sous-répertoires mais aucune n'a été sélectionnée

Branchement par état :

• App claire → continuez vers section 6 (Existing LaunchDarkly SDK) puis confirmation SDK.

• Unclear / weak evidence :

D5-UNCLEAR -- BLOQUANT : Appelez votre outil de question structurée maintenant.

• question: "J'ai trouvé des fichiers de projet, mais je ne suis pas certain d'avoir identifié la bonne application à intégrer. Pouvez-vous me montrer le dossier d'app correct ?"
• context: Décrivez brièvement ce que vous avez trouvé et pourquoi c'est ambigu (ex. "Il y a un package.json à la racine, mais il n'a pas de script de démarrage et aucun fichier source d'application").
• options:
  • Présentez les dossiers candidats que vous avez détectés comme options sélectionnables
  • "C'est ailleurs -- je vais vous dire le chemin"
  • "Il n'y a pas d'app encore -- aidez-moi à créer une démo"
• ARRÊTEZ. Ne faites pas de modifications de code, n'installez pas de packages, ou ne générez pas un plan d'intégration jusqu'à ce que l'utilisateur confirme la cible. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

Une fois que l'utilisateur pointe vers le dossier correct, relancez la détection (sections 1-4) limitée à ce dossier.

• Aucune app trouvée :

Dites clairement à l'utilisateur : "Je n'ai pas trouvé d'application exécutable dans cet espace de travail." Ensuite, proposez deux chemins :

D5-NOAPP -- BLOQUANT : Appelez votre outil de question structurée maintenant.

• question: "Je n'ai pas trouvé d'application exécutable dans cet espace de travail. Comment souhaitez-vous procéder ?"
• options:
  • "Montrez-moi le bon dossier -- l'app est ailleurs"
  • "Créer une app démo minimale pour que je puisse essayer LaunchDarkly"
• ARRÊTEZ. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

Si l'utilisateur choisit "montrez-moi le bon dossier," relancez la détection limitée au chemin qu'il fournit. S'il choisit "créer une app démo," créez une app exécutable minimale dans un nouveau sous-dossier (ex. launchdarkly-demo/) en utilisant la pile la plus simple que vous pouvez créer (Node.js + Express ou une page HTML statique sont de bons défauts), puis continuez la détection à partir de ce sous-dossier.

Ne déclarez pas l'onboarding complet sauf si la cible d'app a été confirmée et que l'app peut réellement s'exécuter.

6. SDK LaunchDarkly existant

Recherchez dans la base de code une utilisation existante de LaunchDarkly :

Cherchez : launchdarkly, ldclient, ld-client, LDClient, @launchdarkly, launchdarkly-

Vérifiez :

• Le SDK est-il déjà dans le fichier de dépendances ?
• Y a-t-il du code d'initialisation ?
• Est-il correctement configuré ou partiellement configuré ?
• Y a-t-il déjà des évaluations de feature flag ?

Confirmation SDK

Après avoir détecté la pile, confirmez le choix SDK avec l'utilisateur :

• Si un SDK est clairement le bon choix : Présentez votre recommandation et obtenez une confirmation :

D5 -- BLOQUANT : Appelez votre outil de question structurée maintenant.

• question: "En me basant sur ce que j'ai trouvé, je recommande le SDK [SDK name]. Cela vous semble correct ?"

• options:

  • "Oui, procédez avec ce SDK" -> continuez vers plan
  • "Non, je veux un différent" -> laissez l'utilisateur spécifier

• ARRÊTEZ. N'écrivez pas la question en tant que texte. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

• Si plusieurs SDKs pourraient s'appliquer (ex. un projet Next.js avec composants serveur et client) :

  • Si l'utilisateur a déjà demandé les deux (ex. "frontend et backend," "serveur + navigateur," "API et SPA") : Traitez cela comme une portée dual-SDK. Procédez vers Generate integration plan avec les deux SDKs en portée -- ne planifiez ou n'implémentez que l'un et ne supposez pas que l'autre est "couvert."
  • Si la portée n'est pas claire :

D5 -- BLOQUANT : Appelez votre outil de question structurée maintenant.

• question: "Ce projet a à la fois des surfaces côté serveur et côté client. Lequel voulez-vous intégrer ?"
• options:
  • "Côté serveur uniquement"
  • "Côté client uniquement"
  • "À la fois côté serveur et côté client"
• ARRÊTEZ. N'écrivez pas la question en tant que texte. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

S'ils choisissent les deux, le plan doit inclure deux intégrations concrètes (voir plan: Dual SDK integrations).

• Si vous ne pouvez pas déterminer le bon SDK : Présentez les options disponibles de SDK recipes comme options sélectionnables dans votre outil de question et utilisez le même motif bloquant ci-dessus.

Arbre de décision

Après détection et confirmation :

• Aucune app trouvée ou unclear --> Déjà géré par D5-NOAPP / D5-UNCLEAR dans section 5a. Ne procédez pas vers plan jusqu'à ce que l'utilisateur confirme une vraie cible d'app.
• SDK déjà installé et initialisé --> Allez vers Create first feature flag (parent Step 6)
• SDK installé mais non initialisé --> Allez vers Apply code changes (ajoutez simplement le code d'init)
• SDK non présent --> Continuez vers Generate integration plan
• Plusieurs cibles détectées (ex. frontend + backend) --> Si l'utilisateur veut les deux SDKs (confirmé via D5 ci-dessus), continuez vers Generate integration plan avec portée dual-SDK (deux packages, deux entrypoints). S'il veut une surface uniquement, planifiez pour ce SDK unique.
• Langage non détecté --> Déjà géré par la question D5 bloquante dans section 1.

À l'achèvement (chemin normal) : Generate integration plan