jorgemiranda-alt/cloudapper

Que fait cloudapper ?

CloudApper est une plateforme no-code : les applications sont constituées de formulaires (modèle de données), de menus (navigation), de rôles, de workflows UI (côté client), de workflows backend (automatisation) et de rapports DevExpress, le tout édité dans App Studio (/design/... pour les formulaires et menus, /studio/... pour les workflows) et utilisé dans l'application runtime (/<clientId>/app/<appId>/...).

Ce fichier contient les règles qui s'appliquent à chaque tâche. Lisez la référence qui correspond à la tâche avant d'agir :

Tâche	Lire
Comprendre le fonctionnement de la plateforme (formulaires, champs, workflows, rapports, mise en cache)	references/platform-model.md
Appeler les API (enregistrements, workflows, formulaires, menus, rôles, workflows UI, rapports)	references/api-reference.md
Créer ou modifier un workflow ; déboguer un workflow qui "ne se déclenche pas" ou est lent	references/workflow-patterns.md
Piloter le navigateur avec le Playwright MCP	references/playwright-efficiency.md
Copier des fonctionnalités ou une application entière d'une application/compte à un autre	references/copy-between-apps.md
Créer une nouvelle application ou un nouveau formulaire dans le designer	references/building-apps.md
Concevoir, nommer ou réviser quoi que ce soit (SOLID sur CloudApper, conventions de nommage, conventions de workflow/config/rapport)	references/conventions.md
Concevoir une architecture de solution ou d'intégration (UKG, REST, webhooks, SFTP, middleware ; passage à l'échelle et efficacité)	references/architecture.md
Documenter une application (guide technique / de dépannage, ou guide de passation PM)	references/documentation.md
Réviser une application ou rédiger ses conclusions / recommandations	references/app-review-checklist.md
Travailler avec les connecteurs UKG (Pro, WFM, Recruiting, HRSD)	references/integrations-ukg.md
L'utilisateur demande comment travailler avec vous sur CloudApper, ou ce qui appartient à cette compétence	references/learning-and-prompting.md

Environnements : demandez avant de modifier quoi que ce soit

La plupart des clients CloudApper ont une application Production et une application UAT (test), souvent sous des comptes différents. Avant toute modification (enregistrement d'un formulaire, édition ou activation/désactivation d'un workflow, modification d'enregistrements, importation d'un rapport, changement de menus), confirmez pour quel environnement la modification est destinée, sauf si l'utilisateur l'a déjà précisé dans cette conversation :

• Demandez : "Est-ce pour la Production ou l'UAT ?" et nommez le compte/l'application sur lequel/laquelle vous êtes connecté, afin que l'utilisateur puisse détecter une incohérence.
• Par défaut, considérez l'UAT. Traitez la Production en lecture seule : pas de modifications, pas d'exécution de workflows, et pas de connexions ou de lectures sauf si l'utilisateur demande explicitement cette action spécifique. Copier depuis la Production est une lecture ; copier vers la Production est une modification.
• Vérifiez l'ID client de l'URL avant chaque écriture (/<clientId>/app/<appId>). Un script qui écrit doit refuser de s'exécuter lorsque la page se trouve sur le mauvais client.
• Les faits du projet (comptes, IDs client/application, quelle application est la Production) ne sont pas stockés dans cette compétence. Recherchez-les dans les notes ou documents propres au projet et dans la mémoire ; s'ils manquent, demandez à l'utilisateur.

Règles de sécurité qui s'appliquent à chaque tâche

• N'exécutez, n'activez et ne déclenchez jamais un workflow par vous-même. L'utilisateur lance les exécutions. Vous pouvez enregistrer les définitions et activer/désactiver uniquement lorsque cela vous est demandé ; indiquez clairement lorsqu'une activation/désactivation modifie le comportement en direct.
• Sauvegardez avant de modifier. Enregistrez la définition actuelle de chaque workflow/formulaire que vous allez modifier dans un dossier local daté, et conservez-la jusqu'à ce que l'utilisateur confirme le résultat. (Une sauvegarde supprimée trop tôt a déjà rendu une restauration impossible.)
• Secrets. Les connecteurs de workflow contiennent des identifiants (UKG, autres API de fournisseurs, clés). Ne les imprimez, ne les journalisez et ne les mettez jamais dans la documentation. Lors de l'inspection du JSON d'un workflow, masquez les clés comme password/secret/apikey/token/clientId, et imprimez uniquement la structure. Supprimez les vidages bruts contenant des secrets une fois terminé, et indiquez à l'utilisateur quels dossiers locaux en contiennent encore.
• L'utilisateur se connecte. Ne tapez jamais de mots de passe. Demandez à l'utilisateur de se connecter dans le navigateur Playwright et de vous dire quand c'est fait.
• Données personnelles. Floutez les noms, adresses e-mail et identifiants dans les captures d'écran que vous conservez ou partagez.
• Rapportez fidèlement. Si un test montre que quelque chose n'a pas fonctionné, dites-le avec les preuves (horodatages, statuts, lignes de journal) avant de proposer la correction suivante.

Les six faits de la plateforme qui causent le plus de surprises

Appris à la dure ; détails et preuves dans references/workflow-patterns.md.

1. L'ordre des workflows est important (WP-001). Un enregistrement créé/mis à jour par un workflow ne déclenche que les workflows situés plus tard dans la liste des workflows (Séquence supérieure). Un workflow placé après sa cible ne déclenche rien. Maintenez l'ordre de la liste identique entre les environnements.
2. Le designer effectue un travail caché que l'API ne fait pas. Créer un formulaire dans le designer accorde également l'accès au rôle administrateur (privilège 32655). Enregistrer un corps de formulaire via l'API crée le formulaire et ses menus par défaut mais pas le privilège, donc les menus restent masqués dans le runtime. Les sous-formulaires nécessitent également leur propre appel de relation parent-enfant.
3. Un déclencheur de statut nécessite un changement réel (WP-002). Les workflows déclenchés sur Status _IsUpdated ne démarrent pas si la nouvelle valeur est égale à l'ancienne (les enregistrements bloqués sur "En cours" ne peuvent pas être relancés en définissant à nouveau "En cours").
4. Les exécutions déclenchées d'un workflow se déroulent une par une, et une boucle ne les attend pas toujours (WP-005). Une boucle qui a mis à jour 24 enregistrements s'est terminée en secondes tandis que les 24 exécutions de workflow qu'elle a déclenchées se sont exécutées au cours de l'heure suivante ; un deuxième lot démarré entre-temps a perdu ses exécutions déclenchées. Exécutez un lot à la fois.
5. Le runtime met en cache l'application. Après des modifications de conception, cliquez sur l'icône d'actualisation à côté du nom de l'application (ou reconnectez-vous) ; les menus pour les formulaires auxquels le rôle n'a pas accès sont masqués, donc les nouveaux formulaires ont besoin de privilèges de rôle (voir la liste de contrôle de copie).
6. Un Routeur exécute chaque route dont la condition est vraie (WP-009), pas seulement la première. Rendez les conditions de route exclusives lorsqu'un seul résultat est souhaité.

Comment travailler efficacement

• Privilégiez les API plutôt que les clics : elles sont plus rapides, précises et économiques. Utilisez l'interface utilisateur uniquement pour ce qui n'a pas d'API que vous connaissez, et pour confirmer ce que l'utilisateur verra.
• Dans Playwright, exécutez le code à partir de fichiers (browser_run_code_unsafe avec filename), servez les charges utiles volumineuses depuis un localhost d'assistance, et renvoyez des résumés compacts (comptages, noms, statuts), jamais le JSON complet. Voir references/playwright-efficiency.md.
• Avant de modifier un workflow, lisez son arbre de nœuds (noms, types d'action, formulaires) depuis l'API plutôt que d'ouvrir le designer.
• Après chaque modification, vérifiez en relisant (API) et, pour les workflows, ouvrez le générateur une fois pour vérifier qu'il s'affiche correctement.
• Tâches volumineuses ou répétées : écrivez un petit script de génération (Python) qui produit le JSON à partir de modèles extraits de nœuds existants, puis un script d'application protégé. Conservez les deux dans le projet afin que la modification soit reproductible et révisable.

Documentation par défaut

Markdown uniquement (PDF uniquement sur demande), public interne uniquement (pas d'e-mails clients), questions ouvertes dans le document avec le pourquoi/le but, les diagrammes ne montrent que l'application en cours d'exécution et ses utilisateurs/systèmes externes. Méthode complète : references/documentation.md. Lorsqu'une application possède déjà de la documentation ou des notes de projet, lisez-les avant d'explorer à nouveau l'application.

Ajout de connaissances à cette compétence

Lorsque l'utilisateur demande d'ajouter quelque chose à cette compétence ("ajoute ceci à la compétence cloudapper") :

1. Lisez inbox/TEMPLATE.md dans le dossier de cette compétence et rédigez le brouillon dans inbox/<aaaa-mm-jj>-<nom-court>.md avec le statut Hypothese. Rédigez-le de manière générique : pas de noms de client, d'application, de formulaire, de workflow ou de personne, d'identifiants, d'hôtes réels ou d'identifiants.
2. Parcourez references/ à la recherche d'entrées que le brouillon confirme ou contredit, et listez-les dans les notes de révision du brouillon.
3. Ne modifiez pas SKILL.md ou references/ vous-même, sauf si l'utilisateur dit qu'il est un mainteneur appliquant une modification révisée. Dites à l'utilisateur d'ouvrir une pull request avec le brouillon (CONTRIBUTING.md contient le processus).