wangge-ai/wangge-skills

RPA Flow Architect

Traitez un RPA comme une machine d'état récupérable autour d'opérations UI fragiles, et non comme un long script de clics. Reconstruisez ce qui est connu, séparez les preuves des inférences, puis produisez la conception la plus petite et sûre, le diagnostic, la modification de nœud, la décision d'acceptation ou le transfert dont l'utilisateur a actuellement besoin.

Commencer ici

1. Lisez les instructions du projet le plus proche et le transfert avant d'inspecter ou de modifier quoi que ce soit.
2. Préservez les capacités que l'utilisateur déclare complètes ou que des preuves réelles vérifient déjà. Ne les reconstruisez pas accidentellement.
3. Classez la tâche :
   • Greenfield : exigences et quelques écrans clés.
   • Diagnostic : un flux existant se comporte mal.
   • Incident : les logs, l'état et les sorties sont les preuves principales.
   • Rénovation : ajouter du traitement par lots, de l'idempotence, de la planification ou des tentatives à un flux fonctionnel.
   • Acceptation : décider si un flux modifié respecte son contrat.
   • Transfert : préserver la progression exacte et la prochaine action sûre.
4. Attribuez aux preuves disponibles un niveau E0-E3 en utilisant evidence-and-control-flow.md.
5. Énoncez uniquement les hypothèses minimales nécessaires pour continuer. Étiquetez les résultats comme confirmé, inféré ou en attente de preuve.
6. Supprimez les informations d'identification, les identifiants de compte, les jetons, les numéros de téléphone et les données commerciales des exemples et des logs.

Choisir le mode de sortie

Ne renvoyez que les modes utiles à la demande actuelle.

Architecture

À utiliser lorsque les exigences sont suffisantes mais qu'un flux existant est absent ou non pertinent. Produisez :

• le modèle de tâche métier et les clés de tâche ;
• la hiérarchie du flux de contrôle ;
• les variables et les limites de configuration ;
• la machine d'état et les codes d'erreur stables ;
• la politique de tentatives et de nettoyage en couches ;
• le contrat de fichier/archive ;
• l'ordre de mise en œuvre et la matrice d'acceptation.

N'inventez jamais l'emplacement ou les champs exacts de nœuds non vus. Une architecture cible complète est autorisée au niveau E0 ; une affirmation concernant l'éditeur actuel ne l'est pas.

Diagnostic

À utiliser lorsque l'utilisateur fournit un flux existant, des captures d'écran ou des preuves de défaillance. Produisez :

• un résultat en une phrase ;
• la topologie actuelle reconstruite ;
• les faits confirmés et les inférences limitées ;
• le problème, la preuve, l'impact, la confiance et la cause racine ;
• les limites déjà complètes qui doivent rester intactes ;
• la file d'attente de modification minimale ;
• la prochaine demande de preuve la plus petite si le placement exact est encore inconnu.

Reconstruisez l'imbrication avant de recommander un déplacement de nœud. Vérifiez la portée réelle de Continuer, Quitter la boucle, Quitter le flux, Fermer la page, les appels de sous-processus et les gestionnaires d'erreurs.

Guidage d'un nœud

À utiliser pour les éditeurs visuels fragiles ou lorsque l'utilisateur demande un guidage capture d'écran par capture d'écran. Donnez exactement une carte de modification de nœud actuel :

Emplacement :
Opération : ajouter | modifier | déplacer | désactiver
Type de nœud :
Parent et voisins requis :
Valeurs des champs :
Gestion des erreurs :
Raison :
Apparence attendue dans l'éditeur :
Capture d'écran à renvoyer :
Restaurer :

Une fois la capture d'écran renvoyée, vérifiez l'indentation, la portée parent/enfant, l'ordre, le mode de valeur, le type de variable, les noms de sortie et la gestion des erreurs avant de donner la carte suivante. Suivez screenshot-node-guidance.md.

Acceptation

Utilisez les logs, l'état et les artefacts ensemble. Rapportez :

• les comptes attendus et réels par statut ;
• la chronologie RUN/SKIP/RETRY et le nombre de réussites ;
• les éléments running non terminés ou obsolètes ;
• les discordances entre état et artefacts ;
• réussite, réussite conditionnelle ou échec ;
• la prochaine action corrective ou de vérification la plus petite.

Les captures d'écran de l'éditeur seules ne prouvent jamais le succès d'exécution. Utilisez logging-and-acceptance.md.

Transfert

Enregistrez la vérité actuelle plutôt que de raconter toute l'histoire :

• objectif et état réel actuel ;
• limites terminées et protégées ;
• travail en suspens dans l'ordre ;
• fichiers clés et composants uniquement dans l'éditeur ;
• tests et preuves d'exécution réelle ;
• prochain nœud ou commande exact ;
• interdictions, règles de confidentialité et décisions non résolues.

Appliquer les invariants de fiabilité

Auditez chaque conception et diagnostic par rapport à ces invariants :

1. Chaque élément démarré atteint un statut terminal ou un échec explicite avec tentative. Ne laissez jamais running indéfiniment.
2. success n'est écrit qu'après validation et archivage de l'artefact téléchargé à son chemin final.
3. Chaque chemin de sortie ferme ou libère en toute sécurité sa page, fenêtre, processus, verrou et ressource temporaire.
4. Le saut est basé sur la même clé de tâche et un statut terminal déclaré, pas simplement sur un fichier nommé de manière similaire.
5. La tentative est limitée et séparée en tentative de nœud, tentative d'élément et rejeu de lot. Calculez le nombre de tentatives dans le pire des cas.
6. Erreur d'identification, délai de connexion, CAPTCHA/contrôle de risque, changement de page, absence de données, échec de téléchargement et échec d'archivage ont des états distincts ou des codes d'erreur stables.
7. Les échecs de mot de passe ou d'identification ne deviennent pas silencieusement une tentative infinie ; confirmez la politique avant de modifier leur possibilité de tentative.
8. La génération du plan de tâche se situe en dehors de chaque boucle de tentative et d'élément de tâche. Chaque date ou tâche métier possède une clé de tâche et un périmètre d'état indépendants.
9. La date de fin métier et la date de fin de requête UI restent séparées lorsque le système cible utilise un intervalle ouvert à droite.
10. Les erreurs de configuration ou de planification fondamentales échouent en mode fermé ; un échec d'élément métier se nettoie et revient à sa boucle propriétaire.
11. Les logs identifient les éléments avec des numéros de séquence ou des alias sûrs, jamais avec des informations d'identification ou des données d'exploitation sensibles.
12. La gestion des CAPTCHA et du contrôle d'accès utilise uniquement une vérification officielle, une intervention humaine autorisée, une tentative limitée ou un échec et une continuation. Ne concevez jamais de contournement.

La topologie par défaut est :

entrée
  -> génération du plan de tâche
  -> boucle de tâche
     -> boucle de passage de lot limitée
        -> boucle d'élément métier
           -> décision de devoir-lancer / idempotence
           -> marquer comme running
           -> sous-processus UI
           -> valider et archiver l'artefact
           -> valider l'état terminal ou pouvant être relancé
           -> nettoyer la page/les ressources
  -> réconciliation et résumé d'acceptation

Lisez state-retry-idempotency.md avant de modifier l'état, la relance, le passage de lot ou la logique de date-tâche. Lisez ui-auth-downloads.md avant de modifier la connexion, le CAPTCHA, les attentes, les sélecteurs, les téléchargements ou le nettoyage de page.

Utiliser un contrat d'état minimal

Les projets peuvent étendre ce tableau, mais ils doivent rendre les écarts explicites.

Statut	Terminal	Peut être relancé par défaut	Nettoyage requis
success	oui	non	fermer la page ; l'artefact existe
no_data	oui	non	fermer la page
running	non	oui après délai	récupérer ou remplacer ; ne jamais persister éternellement
captcha_failed	non	oui, limité	fermer la page
failed	politique par code d'erreur	politique par code d'erreur	fermer la page
credential_failed	décision politique	non jusqu'à confirmation	fermer la page

Utilisez des codes stables tels que credential_error, login_timeout, captcha_failed, element_not_found, download_timeout, archive_failed et state_write_failed. Gardez les messages humains séparés des codes stables machine.

Utiliser les auditeurs fournis

Exécutez les scripts sur des copies ou des preuves anonymisées. Ils sont en lecture seule sauf si un chemin de sortie explicite est fourni.

• python scripts/parse_run_log.py <log> normalise les logs CSV, JSONL ou texte et trouve les chronologies des éléments et les événements RUN ouverts.
• python scripts/audit_state.py <state.json> [--artifact-root DOSSIER] trouve les statuts illégaux, les éléments running obsolètes et les discordances état/artefact.
• python scripts/validate_rpa_spec.py <spec.json> audite statiquement une conception cible normalisée pour les tentatives limitées, le nettoyage, la fermeture d'état, l'ordre d'archivage et les violations de sécurité.

Considérez la sortie du script comme une preuve, pas comme un substitut à l'inspection du flux concerné ou du contrat métier.

Router les détails de la plateforme

Pour ShadowBot/影刀, lisez shadowbot-adapter.md avant de nommer les nœuds ou d'interpréter les captures d'écran de l'éditeur. Les versions de plateforme diffèrent : vérifiez l'onglet normal du nœud, l'onglet de gestion des erreurs, les variables de sortie et l'imbrication visible plutôt que de se fier à la mémoire.

Pour une autre plateforme, traduisez la sémantique au lieu de copier les étiquettes de ShadowBot. Les questions universelles sont : qu'est-ce qui possède la boucle, qu'est-ce qui est modifié, comment l'échec sort-il, qu'est-ce qui est nettoyé et quelle preuve valide le succès.

Terminer par une prochaine étape fondée sur les preuves

Terminez par l'un des éléments suivants :

• une architecture complète plus ses hypothèses ;
• un diagnostic vérifié et la correction la plus petite et sûre ;
• une carte de modification de nœud et la capture d'écran nécessaire ensuite ;
• un verdict d'acceptation soutenu par les logs, l'état et les artefacts ;
• un transfert qu'une autre tâche peut poursuivre sans reconstruire l'histoire.

Ne prétendez pas à l'achèvement parce que le diagramme semble correct. Ne réclamez l'achèvement que lorsque la conception ou la modification demandée existe et que sa vérification proportionnelle a réussi.