Fulling v3 : ce que le dépôt contient réellement avant de l'adopter

Le problème visé n'est pas celui que le slogan annonce

La description du dépôt parle d'un agent ingénieur full-stack propulsé par Claude. Le README, lui, décrit autre chose : des espaces de travail IA dédiés, soit des environnements persistants combinant compétences, fichiers, mémoire, scripts et runtime. La branche main ne livre pas cet ensemble. Elle fournit la couche d'identité et la frontière de credentials Kubernetes que ce modèle exige. Autrement dit, le dépôt public est en avance sur son propre récit. Le public visé est donc étroit : une équipe qui veut construire un produit où chaque utilisateur dispose de son propre accès à un cluster, et qui préfère partir d'une base d'authentification et de validation de credentials plutôt que de l'écrire. Si vous cherchez un outil à installer pour générer du code, le dépôt ne répond pas à cette demande en l'état.

De GitHub à SelfSubjectReview : la chaîne d'authentification

Le mécanisme visible est une chaîne courte. L'utilisateur se connecte uniquement via GitHub, à travers Better Auth. Les utilisateurs, les comptes fournisseurs et les sessions sont stockés dans PostgreSQL, ce qui suppose Prisma pour le schéma et les migrations. Une fois authentifié, l'utilisateur atteint une entrée d'espace de travail protégée et peut enregistrer un kubeconfig, un seul, stocké en clair. La validation ne se fait pas hors ligne : le serveur interroge l'API Kubernetes avec SelfSubjectReview pour vérifier que les identifiants sont authentifiés. Le client Kubernetes est ensuite scopé à l'utilisateur. Cette validation en direct est le point intéressant du dépôt : elle rejette les plugins de credentials exécutables, les plugins auth-provider, les champs pointant vers un fichier local, la configuration de proxy, les serveurs API non HTTPS, les redirections et les identités anonymes. Le README précise aussi que la frontière SSRF côté requêtes sortantes reste une décision de déploiement explicite, puisqu'un utilisateur authentifié peut pointer vers n'importe quelle adresse réseau en HTTPS.

Le kubeconfig en clair est un choix assumé, pas un détail

Le README l'écrit sans détour : les kubeconfigs sont stockés en clair dans PostgreSQL, et un accès en lecture à la base donne accès aux credentials Kubernetes des utilisateurs. Ce n'est pas une faiblesse accidentelle documentée à moitié, c'est la conception actuelle. Les APIs exposées au navigateur ne renvoient jamais le contenu enregistré, et les journaux ne doivent contenir ni jetons, ni clés, ni certificats, ni contenu de kubeconfig. Ces deux règles protègent la fuite par l'interface et par les logs, pas par la base. Toute personne qui évalue Fulling doit donc traiter la base comme un coffre, avec les contraintes que cela implique sur les sauvegardes, les réplicas de lecture et les accès d'exploitation. Le README indique également que le kubeconfig au niveau utilisateur n'est pas le modèle définitif de propriété du Workspace Runtime, ce qui laisse entendre une migration à venir sur ce point précis.

Démarrer en local, et la rupture de schéma v2 vers v3

Node.js 24 avec son npm 11 embarqué est la seule exigence pour l'application publique, qui se lance sans PostgreSQL ni fournisseur OAuth. Les commandes tiennent en deux lignes : npm ci puis npm run dev, et la connexion est désactivée. Pour exercer l'espace de travail authentifié hérité, il faut copier .env.template vers .env.local, renseigner la base, Better Auth et GitHub, exécuter npm run prisma:migrate, puis relancer npm run dev sur le port 3000. Le callback OAuth GitHub doit être configuré sur ${BETTER_AUTH_URL}/api/auth/callback/github, et le README renvoie à docs/github-oauth-verification.md pour tester une vraie application OAuth avant publication. La contrainte la plus lourde est ailleurs : cette version utilise un schéma de référence neuf et ne migre pas les données v2. Il faut une base neuve ou explicitement réinitialisée. Et réinitialiser la base Fulling ne supprime pas les ressources Kubernetes créées par la v2, d'où le renvoi à docs/v2-resource-inventory.md avant de remplacer un déploiement existant.

Ce que le dépôt ne vous dira pas

L'absence de couche de compatibilité avec le modèle produit précédent est présentée comme intentionnelle, et c'est cohérent avec une réécriture. Cela signifie aussi qu'un déploiement v2 ne se met pas à jour, il se remplace, avec un inventaire de ressources à traiter à la main. Sur le volet agent, le README reste au niveau de l'intention : il mentionne des compétences, une mémoire, des scripts et un runtime dans le modèle Workspace cible, sans décrire leur implémentation dans cette fondation. Le choix de Claude comme modèle n'apparaît pas dans le README fourni, seulement dans la description du dépôt. Deux versions sont publiées, v1.0.0 en janvier 2026 et v2.0.0 en mai 2026, mais la branche main se présente comme une fondation v3 : la numérotation des releases et le contenu de la branche ne se recouvrent donc pas de manière évidente. Le rythme de publication ne dit rien non plus de la stabilité de l'API interne, puisque le schéma de référence a déjà changé une fois.

Face à un chart Helm ou à un opérateur Kubernetes

L'alternative la plus directe n'est pas un autre agent, c'est l'outillage Kubernetes standard. Un chart Helm ou un opérateur qui provisionne un namespace par utilisateur traite le problème d'isolation au niveau du cluster, avec des ServiceAccounts et des RBAC, sans jamais stocker de kubeconfig. La différence d'approche est nette : Fulling fait porter la frontière de sécurité par l'application, qui conserve des credentials en clair et les valide via SelfSubjectReview, tandis que l'approche native délègue au control plane la distribution et la rotation des identités. En contrepartie, l'outillage natif ne fournit ni la connexion GitHub, ni la session applicative, ni l'entrée d'espace de travail. Fulling vend cette partie intégrée. Si votre besoin réel est l'isolation par utilisateur sur un cluster, l'outillage natif est plus court ; si votre besoin est une application web avec identité et espaces de travail, Fulling couvre la partie que Helm ne couvre pas.

Licence MIT et coût de suivi

La licence MIT autorise la réutilisation, la modification et la redistribution, y compris dans un produit propriétaire, avec conservation de l'avis de licence. Elle ne couvre évidemment pas les services tiers dont le projet dépend : GitHub OAuth, une base PostgreSQL, un cluster Kubernetes et, si le modèle Workspace cible se concrétise, un fournisseur de modèle. Sur la maintenance, le point de vigilance est le couplage entre le schéma Prisma et les migrations : le README impose une base neuve pour cette version, ce qui signifie que suivre les évolutions du projet impliquera de traiter chaque rupture de schéma comme un remplacement. Le périmètre de tests est indiqué par les scripts npm test (Vitest) et npm run test:e2e (Playwright), sans chiffre de couverture. Le déploiement Vercel fonctionne sans vercel.json, l'application publique se construit et démarre sans variables d'environnement, mais la connexion GitHub, l'espace de travail adossé à la base et les flux kubeconfig restent désactivés tant que leur configuration complète n'est pas présente. docs/vercel-deployment.md contient la procédure de retour arrière.

Conclusion éditoriale

Adoptez Fulling si vous cherchez une base Next.js pour lier une identité GitHub à un client Kubernetes par utilisateur, et si vous acceptez qu'un accès en lecture à PostgreSQL équivaille à un accès aux kubeconfigs. Passez votre chemin si vous voulez un agent qui écrit du code aujourd'hui : la branche main décrit une fondation, pas le produit. Avant tout déploiement, lisez docs/architecture.md et docs/v2-resource-inventory.md, puis confirmez que votre base est neuve ou réinitialisée, puisque la migration de référence ne reprend pas les données v2.

Sources officielles

1. FullAgent/fulling on GitHub
2. License: MIT
3. Project website
4. README
5. Releases