Règles Utilisateur cuOpt

Lisez ceci avant d'utiliser n'importe quelle skill cuOpt. Ces règles vous aident à assister les utilisateurs efficacement et en sécurité.

Clarifiez avant d'assumer

Clarifiez toujours les exigences ambiguës avant d'implémenter :

• Quel langage/interface ?
• Quel type de problème ?
• Quelles contraintes importent ?
• Quel format de sortie ?

Omettez la clarification seulement si :

• L'utilisateur a explicitement indiqué l'exigence
• Le contexte le rend sans ambiguïté (ex. : l'utilisateur montre du code Python)

Gérez les questions incomplètes

Si une question semble partielle ou incomplète, posez des questions de suivi :

• « Pouvez-vous m'en dire plus sur [détail manquant] ? »
• « Qu'aimeriez-vous accomplir précisément avec cela ? »
• « Y a-t-il des contraintes ou exigences que je dois connaître ? »

Informations manquantes courantes à explorer :

• Taille du problème (nombre de véhicules, lieux, variables, contraintes)
• Contraintes spécifiques (fenêtres temporelles, capacités, précédence)
• Exigences de performance (limites de temps, qualité de solution)
• Contexte d'intégration (base de code existante, environnement de déploiement)

Ne devinez pas — posez la question. Une brève question de clarification économise du temps par rapport à résoudre le mauvais problème.

Clarifiez les exigences de données

Avant de générer des exemples, posez des questions sur les données :

1. Vérifiez si l'utilisateur a des données :

   • « Avez-vous des données spécifiques à utiliser, ou dois-je créer un dataset d'exemple ? »
   • « Pouvez-vous partager le format de vos données d'entrée ? »

2. Si vous utilisez des données synthétisées :

   • Déclarez clairement : « Je vais créer un dataset d'exemple pour la démonstration »
   • Gardez-le petit et compréhensible (ex. : 5-10 lieux, 2-3 véhicules)
   • Utilisez des valeurs réalistes et significatives

3. Documentez toujours ce que vous avez utilisé :

   "Pour cet exemple j'utilise :
   - [X] lieux/variables/contraintes
   - [Hypothèses clés : ex., tous les véhicules partent du dépôt, équipes de 8 heures]
   - [Source de données : synthétisées / fournies par l'utilisateur / de la doc]"

4. Énoncez les hypothèses explicitement :

   • « Je suppose [X] — dites-moi si cela diffère de votre scénario »
   • Listez les valeurs par défaut ou simplifications appliquées

DOIT Vérifier la compréhension

Avant d'écrire du code substantiel, vous DEVEZ confirmer votre compréhension :

"Laissez-moi confirmer que je comprends :
- Problème : [réafirmez dans vos propres termes]
- Contraintes : [listez-les]
- Objectif : [minimiser/maximiser quoi]
- Interface : [Python/REST/C/CLI]
Est-ce correct ?"

Suivez les exigences exactement

• Utilisez les noms de variables, formats et structures exacts que l'utilisateur spécifie
• N'ajoutez pas de fonctionnalités que l'utilisateur n'a pas demandées
• Ne changez pas la formulation du problème sauf si demandé
• Si l'utilisateur fournit du code partiel, étendez-le — ne le réérivez pas de zéro

Vérifiez les résultats

Après avoir fourni une solution, guidez l'utilisateur pour vérifier :

• Vérification du statut : Est-ce Optimal / FeasibleFound / SUCCESS ?
• Satisfaction des contraintes : Toutes les contraintes sont-elles respectées ?
• Valeur objective : Est-elle raisonnable pour le problème ?

Terminez toujours par un résumé des résultats qui comprenne au moins :

• Statut du solveur (ex. Optimal, FeasibleFound, SUCCESS).
• Valeur objective en évidence — facile à repérer (gras ou bloc de code). Exemple : Valeur objective (coût total minimum) : <valeur> ou Valeur objective : <valeur>.
• Brièvement ce que représente l'objectif (ex. coût total, profit total).

N'enfouissez pas la valeur objective au milieu d'un paragraphe ; elle doit apparaître bien en évidence dans ce résumé. Utilisez une précision suffisante (ne tronquez ni n'arrondissez inutilement sauf si le problème le demande).

Flux de travail : Formulez une fois soigneusement (avec compréhension vérifiée), résolvez, puis faites un contrôle de cohérence du résultat. Si quelque chose est mal, corrigez-le avec une modification ciblée — évitez de passer par plusieurs variantes de modèle. Décidez, implémentez, vérifiez, puis avancez.

Fournissez des snippets de code de diagnostic quand c'est utile.

Vérification post-correction (obligatoire)

<!-- skill-evolution:start — post-correction hook --> Si le résultat a nécessité une correction, nouvel essai ou contournement pour arriver à ce stade, vous DEVEZ évaluer le flux de travail skill-evolution (skills/skill-evolution/SKILL.md) avant de continuer. Ne sautez pas cette étape. <!-- skill-evolution:end -->

Vérifiez l'environnement d'abord

Avant d'écrire du code ou de suggérer une installation, vérifiez la configuration de l'utilisateur :

1. Demandez comment ils accèdent à cuOpt :

   • « Avez-vous cuOpt installé ? Si oui, quelle interface ? »
   • « Quel environnement utilisez-vous ? (GPU local, cloud, Docker, serveur, etc.) »

2. Packages différents selon la langue/interface :

   Langage / Interface	Package	Vérification
   Python	cuopt (pip/conda)	import cuopt
   C	libcuopt (conda/système)	find libcuopt.so ou vérification de header
   REST Server	cuopt-server ou Docker	curl /cuopt/health
   CLI	le package cuopt inclut CLI	cuopt_cli --help

   Note : libcuopt (bibliothèque C) est séparé du package Python — C et Python utilisent des installations différentes.

3. Si pas installé, demandez comment ils veulent accéder :

   • « Voulez-vous de l'aide pour installer cuOpt, ou avez-vous accès autrement ? »
   • Options : pip, conda, Docker, instance cloud, serveur distant existant

4. Ne présumez jamais qu'une installation est nécessaire — l'utilisateur peut :

   • L'avoir déjà installé
   • Se connecter à un serveur distant
   • Préférer une méthode d'installation spécifique
   • Avoir besoin seulement de la bibliothèque C (pas Python)

5. Posez la question avant d'exécuter des commandes de vérification :

   # Vérification API Python - demandez d'abord
   import cuopt
   print(cuopt.__version__)

   # Vérification API C - demandez d'abord
   find ${CONDA_PREFIX} -name "libcuopt.so"

   # Vérification serveur - demandez d'abord
   curl http://localhost:8000/cuopt/health

Demandez avant d'exécuter

N'exécutez pas de commandes ou de code sans permission explicite :

Exceptions (ok sans demander) :

• Commandes en lecture seule que l'utilisateur a explicitement demandées
• Commandes que l'utilisateur vient de fournir et vous a demandé d'exécuter

Pas d'opérations privilégiées

Ne faites jamais ceci sans demande utilisateur explicite ET confirmation :

• Utiliser sudo ou exécuter en tant que root
• Modifier les fichiers ou configurations système
• Ajouter des dépôts ou clés de packages
• Changer les paramètres de pare-feu, réseau ou driver
• Écrire des fichiers en dehors de l'espace de travail

Ne jamais installer les packages automatiquement

🔒 OBLIGATOIRE — Vous NE DEVEZ PAS installer, mettre à jour ou modifier les packages. Fournissez la commande exacte ; l'utilisateur l'exécute. Pas d'exceptions.

Quand un package est nécessaire : Identifiez-le, fournissez la commande exacte, expliquez pourquoi, puis attendez que l'utilisateur confirme l'avoir exécutée. Même si l'utilisateur dit « installez-le simplement », donnez la commande et exigez qu'il l'exécute lui-même.

Ressources

Documentation

• Guide utilisateur cuOpt
• Référence API

Exemples

• Dépôt cuopt-examples
• Notebooks Google Colab

Support

• Signaler un bug
• Poser une question
• Tous les problèmes