Commencez par une tâche concrète.

Utilise SMART pour découvrir les modèles d’application auxquels j’ai accès. Demande le nom du projet et les composants nécessaires, décris le modèle adapté et présente les fichiers prévus avant toute création.

Examine d’abord le dépôt et ses fichiers d’instructions. S’il ne contient que métadonnées ou documentation, découvre les structures d’application prises en charge et propose un monorepo avec l’UI, les services, contrats partagés, tests et configurations de déploiement nécessaires avant de créer des fichiers. Si une application existe, préserve sa topologie et ses conventions, trouve les composants responsables et étends-les sans créer une autre application ni remplacer la configuration racine. Si le projet est incompatible, explique pourquoi et demande une décision de migration avant toute restructuration.

Utilise SMART pour découvrir le profil de framework applicable et charger les instructions pertinentes à la révision renvoyée. Respecte les contrats SOKit et SOKit UI, les dépendances explicites du monorepo et les conventions Quarkus du projet pour injection, validation, persistance, transactions, configuration et tests. Réutilise les contrats générés et les outils épinglés ; n’invente pas d’API, ne copie pas d’anciens fichiers de build et ne change pas silencieusement les versions. Signale les instructions, accès ou dépendances manquants. Utilise des données fictives et aucun secret dans les exemples.

Utilise SMART pour examiner l’architecture de ce dépôt. Identifie les frontières des composants, les problèmes de dépendances et les trois améliorations prioritaires. Cite les fichiers concernés. Ne modifie pas le code.

Utilise les guides SMART correspondant à la version SOKit UI de ce projet pour ajouter un formulaire avec un nom obligatoire et une adresse e-mail. Examine d’abord les conventions existantes, confirme l’API d’envoi, puis implémente et teste la validation.

Examine d’abord le dépôt et ses fichiers d’instructions. S’il ne contient que métadonnées ou documentation, découvre les structures d’application prises en charge et propose un monorepo avec l’UI, les services, contrats partagés, tests et configurations de déploiement nécessaires avant de créer des fichiers. Si une application existe, préserve sa topologie et ses conventions, trouve les composants responsables et étends-les sans créer une autre application ni remplacer la configuration racine. Si le projet est incompatible, explique pourquoi et demande une décision de migration avant toute restructuration.

Utilise SMART pour découvrir le profil de framework applicable et charger les instructions pertinentes à la révision renvoyée. Respecte les contrats SOKit et SOKit UI, les dépendances explicites du monorepo et les conventions Quarkus du projet pour injection, validation, persistance, transactions, configuration et tests. Réutilise les contrats générés et les outils épinglés ; n’invente pas d’API, ne copie pas d’anciens fichiers de build et ne change pas silencieusement les versions. Signale les instructions, accès ou dépendances manquants. Utilise des données fictives et aucun secret dans les exemples.