amplifthq/opentag

Que fait opentag ?

OpenTag transforme les mentions dans l'espace de travail telles que @opentag corrige ceci en exécutions d'agents auditées. Utilisez cette compétence pour aider un utilisateur à configurer le chemin entre l'événement de l'espace de travail et le dispatcher, le runner local, l'exécuteur et le callback.

Acheminer la requête

Lisez uniquement la référence nécessaire au chemin de l'utilisateur :

• Test local ou première configuration : references/local-echo.md
• Mentions sur les issues ou PR GitHub : references/github-setup.md
• Mentions sur l'application Slack : references/slack-setup.md
• Exécution de code réelle ou création de PR : references/codex-runner.md
• Exécutions interrompues, callbacks manquants, exécutions rejetées ou erreurs d'authentification : references/troubleshooting.md

Si l'utilisateur demande plusieurs chemins, configurez et vérifiez d'abord la plus petite boucle fonctionnelle, puis ajoutez l'adaptateur suivant.

Règles de travail

• Préférez la boucle d'écho locale avant les agents réels ou les callbacks en direct, sauf si l'utilisateur dispose déjà d'un dispatcher et d'un runner fonctionnels.
• Gardez la configuration explicite : n'inventez pas de propriétaires de dépôt, noms de dépôt, chemins de checkout, jetons, identifiants Slack ou URL de dispatcher.
• N'ajoutez pas de comportement de repli. Les valeurs obligatoires manquantes doivent interrompre la configuration avec une liste claire de ce qui manque.
• Traitez opentagd comme l'autorité d'exécution locale. Il ne doit revendiquer que les dépôts listés dans sa configuration.
• Utilisez echo pour les tests non destructifs et codex uniquement lorsque l'utilisateur souhaite une exécution de code réelle.
• Séparez les couches de validation : santé du dispatcher, enregistrement du runner, liaison dépôt ou Slack, création d'exécution, exécution en démon et livraison du callback.

Workflow de configuration

1. Identifiez la boucle cible. Terminaison : une boucle est nommée : local-echo, github, slack ou codex-runner.

2. Collectez les faits requis. Terminaison : la réponse comprend chaque valeur manquante, ou toutes les valeurs requises sont disponibles.

3. Écrivez ou mettez à jour la configuration minimale. Terminaison : la configuration contient uniquement les champs nécessaires à la boucle sélectionnée et utilise le véritable dépôt/canal/chemins de l'utilisateur.

4. Enregistrez les liaisons avant de créer des exécutions. Terminaison : le runner est enregistré, les dépôts sont liés, et les canaux Slack sont liés lorsque Slack est dans le périmètre.

5. Vérifiez une exécution réelle. Terminaison : l'exécution est visible via le dispatcher, possède des événements d'audit, et se termine comme réussie ou échoue avec une erreur spécifique.

6. Rapportez le résultat. Terminaison : dites à l'utilisateur ce qui a été configuré, quelle commande l'a prouvé, et ce qui reste non configuré.

Commandes par défaut

Utilisez ces valeurs par défaut, sauf si le projet a changé :

• Application Dispatcher : pnpm --filter @opentag/dispatcher-app dev
• Application Démon local : pnpm --filter @opentag/opentagd dev -- <commande>
• Application Événements Slack : pnpm --filter @opentag/slack-events dev
• URL du Dispatcher : http://localhost:3030
• Chemin de l'URL Événements Slack : /slack/events
• Exemple de charge utile d'exécution : examples/github-to-echo/run.example.json

Avant d'exécuter des commandes de package dans ce dépôt, utilisez Node 22.x et installez les dépendances si nécessaire.