Symphony Elixir : orchestrer Codex à travers les trackers de tickets
Ce service transforme le travail de suivi des problèmes en exécutions de mise en œuvre isolées et permet aux équipes de définir une automatisation spécifique au projet via un fichier de workflow.
En bref
- De quoi s’agit-il ?
- Un prototype Elixir/OTP qui transforme les tickets de suivi en espaces de travail Codex isolés, avec un avertissement clair qu'il est destiné à l'évaluation uniquement.
- À qui s’adresse-t-il ?
- Le dépôt se présente explicitement comme un logiciel prototype et recommande d'implémenter une version durcie basée sur SPEC.md. La documentation couvre la boucle de répartition, la configuration des workflows, cinq adaptateurs de trackers, un tableau de bord Phoenix et des tests de bout en bout en direct.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 6 jours.
- En quel langage est-il écrit ?
- Principalement Elixir, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Statut de prototype et avertissement explicite
Le dépôt présente Symphony Elixir comme un logiciel prototype destiné à l'évaluation uniquement, fourni tel quel. Le README avertit les lecteurs d'implémenter leur propre version durcie basée sur SPEC.md à la racine du dépôt. C'est la première chose que la documentation énonce, et cela façonne la façon dont le reste du projet doit être lu : le code est une implémentation de référence d'un concept d'orchestration, pas un service de production. (Repère openai-symphony-deep-analysis-1-1.)
La boucle de répartition
Symphony interroge un tracker configuré pour obtenir des travaux candidats. Les adaptateurs pris en charge sont Linear, GitHub Issues, Jira Cloud, Asana et GitLab. Pour chaque ticket, il crée un espace de travail, lance Codex en mode App Server dans cet espace, envoie une invite de workflow et laisse Codex travailler jusqu'à ce que le ticket soit terminé. Si un ticket réclamé passe dans un état terminal (Done, Closed, Cancelled, Duplicate), Symphony arrête l'agent actif et nettoie les espaces de travail correspondants. Lorsque Codex signale qu'une saisie de l'opérateur, une approbation ou une sollicitation MCP est requise, Symphony garde le ticket réclamé et le marque comme bloqué dans l'état d'exécution, l'API JSON et le tableau de bord. La carte des blocages n'existe qu'en mémoire ; un redémarrage la vide. (Repère openai-symphony-deep-analysis-2-1.)
Fichiers de workflow et configuration
Symphony lit un fichier WORKFLOW.md avec un front-matter YAML pour la configuration et un corps Markdown utilisé comme invite de session Codex. Le chemin du fichier est par défaut ./WORKFLOW.md et peut être remplacé par un argument CLI. Les drapeaux optionnels incluent --logs-root et --port, ce dernier activant le service d'observabilité Phoenix. Le README liste les valeurs par défaut pour les champs Codex liés à la sécurité : approval_policy par défaut une carte de rejet, thread_sandbox à workspace-write, et turn_sandbox_policy une politique workspaceWrite enracinée dans l'espace de travail du ticket. Les variables d'environnement telles que LINEAR_API_KEY peuvent être référencées comme $VAR pour que les jetons restent hors de l'espace de travail. Si le fichier de workflow est manquant ou contient du YAML invalide au démarrage, Symphony ne démarre pas. (Repère openai-symphony-deep-analysis-3-1.)
Adaptateurs de trackers et leurs outils
Chaque adaptateur de tracker expose un outil natif du fournisseur à Codex pendant les sessions app-server : linear_graphql pour Linear, github_api pour GitHub Issues, jira_rest pour Jira Cloud, asana_api pour Asana et gitlab_api pour GitLab. Symphony exécute ces outils côté hôte avec l'authentification configurée et retire les variables d'environnement de jeton de tracker déclarées du processus enfant Codex. Le README donne une configuration détaillée pour chaque adaptateur, y compris les champs requis, les variables d'environnement par défaut et les règles de portée. Par exemple, l'adaptateur GitHub exige un dépôt sous la forme owner/repo et traite les pull requests renvoyées par l'API Issues comme non répartissables. L'adaptateur Linear accepte soit une chaîne de requête brute, soit un objet avec query et variables. (Repère openai-symphony-deep-analysis-4-1.)
Tableau de bord d'observabilité et API JSON
L'interface d'observabilité fonctionne sur une pile Phoenix minimale avec LiveView pour le tableau de bord à / et une API JSON sous /api/v1/*. Les points de terminaison incluent /api/v1/state, /api/v1/<issue_identifier> et /api/v1/refresh. Les identifiants de tickets de tracker sont liés à l'URL fournie par le tracker lorsqu'elle utilise http ou https. L'état d'exécution inclut les tickets bloqués, qui ne sont conservés qu'en mémoire ; un redémarrage de l'orchestrateur vide cette carte, de sorte que tout ticket de tracker encore actif peut redevenir un candidat à la répartition. (Repère openai-symphony-deep-analysis-5-1.)
Tests, versions et licence
Le README décrit l'exécution de make all pour la suite de tests et des tests de bout en bout en direct optionnels pour chaque tracker, qui créent des ressources jetables et lancent une véritable session codex app-server. Symphony fournit des exécutables autonomes construits avec Burrito pour macOS et Linux sur arm64 et x86_64, intégrant Erlang/OTP, Elixir et Symphony, mais attendant toujours codex, git et les identifiants de tracker sur la machine cible. Le projet est sous licence Apache 2.0. L'extrait de licence accorde une licence de droit d'auteur perpétuelle, mondiale, non exclusive, gratuite et sans redevance pour reproduire, préparer des œuvres dérivées, afficher publiquement, exécuter, sous-licencier et distribuer l'œuvre. Il ne traite pas du support, de la garantie ou des garanties de sécurité. (Repère openai-symphony-deep-analysis-6-1.)
Pour openai-symphony-deep-analysis, les commandes, chemins et noms de configuration cités dans le README délimitent la manière dont le dépôt peut être évalué. Il faut les reprendre tels quels dans un environnement contrôlé et observer leurs sorties avant d'en tirer une conclusion. Le projet décrit une capacité précise, mais la documentation ne permet pas d'inférer une garantie pour les données ou les charges absentes des exemples. (Repère openai-symphony-deep-analysis-6-2.)
La maintenance dépendra des versions indiquées par le dépôt, des dépendances et de l'accès aux services mentionnés. Les chiffres de popularité décrivent l'audience du code, pas sa pertinence pour une intégration donnée. Cette réserve est particulièrement importante lorsqu'un exemple utilise un modèle distant, un fournisseur de données ou une authentification externe. (Repère openai-symphony-deep-analysis-6-3.)
Le dernier point concerne spécifiquement openai-symphony-deep-analysis et doit être relu avec la configuration réellement utilisée. (Repère openai-symphony-deep-analysis-6-4.)
Conclusion éditoriale
Le dépôt se présente explicitement comme un logiciel prototype et recommande d'implémenter une version durcie basée sur SPEC.md. La documentation couvre la boucle de répartition, la configuration des workflows, cinq adaptateurs de trackers, un tableau de bord Phoenix et des tests de bout en bout en direct. La licence Apache 2.0 accorde des droits d'auteur et de brevet étendus, mais ne dit rien sur le support ou la garantie.
Notes de la communauté