Gas City : un SDK de construction d'orchestration pour les flux de travail de codage multi-agents
gastownhall/gascity offre une implémentation open source exploitable en conditions réelles avec une structure réutilisable.
En bref
- De quoi s’agit-il ?
- Gas City extrait l'infrastructure d'orchestration réutilisable de Gas Town dans une boîte à outils configurable avec des fournisseurs d'exécution, un suivi de travail basé sur les beads et une configuration de ville déclarative.
- À qui s’adresse-t-il ?
- Le README de Gas City décrit un modèle d'orchestration primitif d'abord, un guide de migration pour les utilisateurs de Gas Town, et une structure de référentiel qui sépare les préoccupations CLI, runtime, configuration et beads, le tout sous licence MIT. gc init et gc start vérifient tmux, git, jq, pgrep et lsof. Le fournisseur Beads demande dolt 2.1.0 et bd 1.0.0 ; GC_BEADS=file permet un stockage fichier.
- Puis-je l’utiliser commercialement ?
- Oui. MIT 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 1 jour.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Extraire l'infrastructure réutilisable de Gas Town
Gas City est un SDK de construction d'orchestration pour les flux de travail de codage multi-agents, écrit en Go. Le README le décrit comme l'extraction de l'infrastructure réutilisable de Gas Town dans une boîte à outils configurable. Cette boîte à outils comprend des fournisseurs d'exécution, le routage du travail, des formules, des ordres, une patrouille de santé et une configuration de ville déclarative. Le projet se positionne comme un modèle primitif d'abord, avec un guide séparé pour les utilisateurs venant de Gas Town qui mappe les rôles, commandes, plugins, convois et habitudes de répertoire de Town sur le modèle de Gas City.
Gas City fournit un contrôleur qui rapproche l’état déclaré dans city.toml de processus réellement actifs. Les fournisseurs incluent tmux, subprocess, exec, ACP, Kubernetes et herdr, tandis que les packs et overrides organisent plusieurs projets.
La boîte à outils incluse
La liste « What You Get » du README nomme cinq éléments : configuration de ville déclarative dans city.toml ; plusieurs fournisseurs d'exécution (tmux, subprocess, exec, ACP, Kubernetes et herdr) ; suivi de travail basé sur les beads, formules, molécules, attentes et courrier ; une boucle contrôleur/superviseur qui réconcilie l'état souhaité avec l'état en cours ; et des packs, overrides et orchestration à portée de rig pour les configurations multi-projets. Ce sont les capacités documentées ; le README ne détaille pas comment chaque fournisseur se comporte ni comment la boucle de réconciliation est implémentée au-delà de cette description.
gc init et gc start vérifient tmux, git, jq, pgrep et lsof. Le fournisseur Beads demande dolt 2.1.0 et bd 1.0.0 ; GC_BEADS=file permet un stockage fichier. Ces paramètres donnent un premier scénario de validation réellement lié à Gas City.
Prérequis système et dépendances des fournisseurs
Le guide d'installation liste les outils requis : tmux, git, jq, pgrep et lsof sont toujours requis. Le fournisseur de beads bd ajoute dolt (2.1.0 ou plus récent), bd (1.0.0) et flock. La CLI GitHub gh est optionnelle pour les portes GitHub, et les outils CLI comme claude, codex ou gemini dépendent du fournisseur. Le README note que tmux est le backend de session par défaut et de secours, donc il reste requis même si les agents s'exécutent sur un autre backend. Pour un stockage basé sur fichier, GC_BEADS=file ou [beads] provider = "file" dans city.toml évite dolt, bd et flock.
Chemins d'installation
Le démarrage rapide montre deux voies d'installation. Les utilisateurs de Homebrew peuvent exécuter brew install gascity puis gc version. La construction à partir des sources nécessite make, Go 1.26.4 ou plus récent, et ICU pour une dépendance CGO transitive de Dolt ; le README donne make install et une petite séquence de commandes pour initialiser une ville, ajouter un rig, créer un bead et s'attacher à une session. Les commandes exactes apparaissent dans le README et sont répétées dans la référence du tutoriel, mais le README n'explique pas ce que fait chaque commande au-delà de cet extrait.
Construction sur les machines Nix et Flox
Le README signale un mode d'échec spécifique sur les toolchains Linux gérées par NixOS et Flox : les répertoires system include et lib ne sont pas recherchés, donc la construction échoue avec fatal error: unicode/uregex.h: No such file or directory. La solution consiste à pointer CGO vers les en-têtes de développement ICU du magasin Nix et la bibliothèque d'exécution correspondante, et à désactiver le repli /usr/lib du Makefile avec SYS_USR_CGO_FALLBACK=0. Le README donne un exemple avec des chemins de magasin et note que les tests adossés à CGO utilisent les mêmes trois variables CGO_*.
Structure du référentiel et orientation des contributeurs
La carte du référentiel liste onze chemins. cmd/gc/ contient les points d'entrée CLI, le câblage du contrôleur, l'assemblage de l'exécution et les gestionnaires de commandes ; internal/runtime/ contient les implémentations de fournisseurs ; internal/config/ gère le schéma city.toml et la composition des packs ; internal/beads/ couvre l'abstraction de stockage ; et internal/session/, internal/orders/, internal/convergence/ et internal/api/ traitent respectivement les métadonnées de session, l'analyse des ordres, les boucles d'affinage et les gestionnaires d'API HTTP. La documentation se trouve dans docs/, les documents d'ingénierie pour les contributeurs dans engdocs/, plus examples/, contrib/ et test/. Le README oriente les contributeurs vers des fichiers spécifiques pour le comportement CLI, le travail d'exécution, la configuration, la distribution du travail et les sessions superviseur.
Documentation, contribution et licence
Le projet pointe vers docs.gascityhall.com pour la documentation en ligne, qui utilise une structure Mintlify enracinée dans docs/. Les directives de contribution se trouvent dans CONTRIBUTING.md et engdocs/contributors/index.md ; les commandes utiles incluent make setup, make check, make check-docs et make test-integration. La licence est MIT, détenue par Steve Yegge (le README ne mentionne pas le droit d'auteur, mais l'extrait de licence le fait). La licence MIT accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies, et déclare que le logiciel est fourni « tel quel » sans garantie d'aucune sorte. La licence ne dit rien sur le support, la sécurité ou les engagements de maintenance.
Conclusion éditoriale
Le README de Gas City décrit un modèle d'orchestration primitif d'abord, un guide de migration pour les utilisateurs de Gas Town, et une structure de référentiel qui sépare les préoccupations CLI, runtime, configuration et beads, le tout sous licence MIT. gc init et gc start vérifient tmux, git, jq, pgrep et lsof. Le fournisseur Beads demande dolt 2.1.0 et bd 1.0.0 ; GC_BEADS=file permet un stockage fichier. Ces paramètres donnent un premier scénario de validation réellement lié à Gas City.
Notes de la communauté