vibex

Vibex est un établi natif, local-first pour le développement logiciel assisté par agents, construit en Rust avec le framework UI GPUI et publié sous licence AGPL-3.0-or-later (version actuelle 0.1.0-rc.2). Le principe énoncé du projet est que le runtime desktop détient l'autorité : les processus d'agents, l'historique des sessions, les fichiers de l'espace de travail, Git, les PTY, les fournisseurs et les permissions résident tous sur la machine de votre choix. Aucun espace de travail hébergé n'est requis pour exécuter le desktop local, et le dépôt, les identifiants ainsi que l'état durable des sessions restent locaux. L'intégration des agents repose sur l'Agent Client Protocol (ACP), que le projet décrit comme son unique transport d'agent en ligne ; ainsi, tout agent compatible ACP peut être connecté en enregistrant un exécutable avec sa commande, ses arguments, son environnement et ses métadonnées d'affichage. Des préréglages intégrés sont listés pour Claude Code, Codex, ZCode et OpenCode, et le catalogue ACP mentionne également Antigravity, Cline, Codebuddy Code, Cursor, Gemini CLI, GitHub Copilot, Devin, Grok, Hermes, Kimi Code, Pi et DeepSeek Harness, dont la disponibilité est vérifiée par rapport au runtime installé, à la configuration du fournisseur et à des sondes de capacité en direct. Les fonctionnalités de flux de travail documentées incluent des sessions d'agents rendues sous forme de chronologie structurée avec Markdown, raisonnement, plans, détails d'outils et de processus, pièces jointes, approbations et formulaires de sollicitation typés, ainsi que les fonctions d'arrêt, de continuation, de bifurcation (fork), de renommage et de reprise, et l'importation d'historiques locaux supportés. Un arbre de fichiers limité à l'espace de travail permet la navigation, la recherche de noms/contenus, des lectures et écritures avec vérification de révision, ainsi qu'une gestion explicite de l'encodage, des fins de ligne et des fichiers volumineux. Le support Git couvre le statut, l'historique, les diffs et le blame, la création et le basculement de branches, le staging, l'unstaging, le revert, le commit, le fetch et le push, ainsi que des worktrees isolés avec récupération gardée pour le merge et le rebase. Des PTY natifs fournissent l'émulation ANSI, des onglets, le redimensionnement, le scrollback, la recherche et la gestion des octets bruts, et l'établi prévisualise le Markdown, les images, les PDF et les documents Office supportés. Un centre de configuration gère les runtimes d'agents, la sélection du modèle et du raisonnement, l'authentification des fournisseurs, les sondes de santé, ainsi que les serveurs MCP, Skills, Prompts et Hooks limités au scope. L'automatisation peut planifier des exécutions d'agents uniques, à intervalle ou quotidiennes, et composer des graphes d'automatisation avec état d'exécution, récupération et historique d'audit. Les notifications desktop suivent les sessions terminées, échouées ou bloquées par une entrée, et l'état de la chronologie est conçu pour survivre aux reconnexions et redémarrages. Trois surfaces natives sont décrites. L'application desktop est l'établi GPUI complet et le DesktopRuntime faisant autorité pour Linux, macOS et Windows. Le compagnon mobile est un client natif GPUI pour iOS et Android qui rend le modèle de session desktop sous forme de chronologie et envoie des mutations distantes typées ; il ne lance pas d'agents locaux, ne possède pas de système de fichiers d'espace de travail, ne mute pas Git localement et ne devient pas une seconde autorité PTY. Le relais auto-hébergé optionnel est un service Rust/Axum qui transfère des trames WebSocket cryptées et ne stocke aucune donnée d'espace de travail, de fournisseur, d'agent ou d'application ; l'appairage peut également utiliser des routes Direct ou Tailnet. Architecturalement, le runtime est divisé en crates : core pour les identifiants sérialisés, DTOs, erreurs, capacités et contrats de protocole distant ; desktop-model pour les projections de session et de chronologie neutres vis-à-vis du framework ; vibex-backend pour les façades de capacités neutres vis-à-vis du fournisseur ; vibex-ui pour les jetons sémantiques et les modèles de composants ; et vibex-remote-client pour l'appairage, la reconnexion, la synchronisation et la sélection de route. La pile inclut le schéma ACP 1.6, Tokio, SQLite via rusqlite, xpty et alacritty_terminal, PDFium, et Rustls avec X25519, HKDF, HMAC et ChaCha20-Poly1305 pour le transport. Le développement nécessite Git avec sous-modules, Node.js 22, pnpm 11.3.0, Rust 1.97.0 fixé par rust-toolchain.toml et un pilote Vulkan fonctionnel ; les exécutions desktop débutent avec pnpm dev:desktop, et les builds mobiles nécessitent l'Android SDK/NDK avec cargo-ndk ou macOS avec Xcode et XcodeGen. Les barrières du dépôt incluent pnpm check, pnpm release:build-smoke et pnpm check:mobile-native. Les notes de confidentialité précisent que les permissions sont limitées par capacités et auditables, que la configuration home du fournisseur n'est pas réécrite par défaut, et que les jetons, clés privées, prompts, contenus de fichiers et octets de terminal sont exclus des logs et des artefacts de diagnostic.