La trajectoire de Stellary

Nous construisons vers une boucle fermée : contexte structuré → exécution gouvernée → revue humaine → connaissance mise à jour. Les agents et l’automatisation s’y branchent sans remplacer la responsabilité.

Le produit doit ressembler à un centre de commande pour les équipes qui livrent du logiciel : statut lisible, compromis explicites, et une IA qui travaille sur l’état réel du projet—pas un chat générique déconnecté du travail.

À mesure que les agents se généralisent, l’affectation doit passer du 100 % manuel à l’assisté : proposer le bon agent pour une mission selon compétences, charge, coût et historique—sans pilote automatique opaque.

La mémoire doit passer de journaux bruts à une intelligence d’équipe durable : distiller missions, documents et revues en motifs, checklists et playbooks réutilisables.

Un assistant contextuel transversal doit aider sur n’importe quelle surface sans casser le contexte local—utile, ancré, et relié aux permissions et aux actions réelles.

Les équipes mélangent runtimes locaux, MCP et exécution cloud. Stellary doit router l’exécution de façon intelligente avec une gouvernance claire, des comportements explicables et des défauts sûrs.

Stellary et le guide Apps IA locales couvrent déjà une première tranche hybride : catalogues runners partagés dans le workspace, dépôts liés et missions agent via CLIs ou serveurs locaux installés, avec signaux de capacités explicites et un panneau runners plus lisible.

Les serveurs MCP doivent se propager vers les agents sous forme d’outils filtrables et assignables, avec une provenance visible—puissants, mais gouvernés pour éviter que l’explosion d’outils ne devienne un problème de sécurité ou d’UX.

L’exécution cloud gouvernée des agents (environnements persistants, sorties revue-friendly, workflows preview-first) reste sur la roadmap comme prochaine couche runtime majeure.

Les arbitrages critiques deviennent des objets « décision » de premier plan : options, impact, propriétaire, échéance et historique—liés au cockpit et au delivery, pas noyés dans les commentaires.

La documentation doit évoluer vers un espace collaboratif premium : partage, responsabilité éditoriale et, lorsque c’est pertinent, co-édition temps réel entre humains et agents.

La connaissance doit être « vivante » : reliée aux cartes, missions et revues, avec des signaux lorsque les repères deviennent obsolètes.

La réflexion amont et l’idéation doivent avoir leur place dans le projet : capturer des notes brutes, affiner avec une IA structurante, puis convertir en specs, cartes ou décisions quand c’est mûr.

La collaboration externe doit être bornée : invités à périmètre contrôlé, vues publiques en lecture seule lorsque c’est justifié, et outils de revue visuelle pour des retours précis.

Là où design et implémentation se rencontrent, des intégrations plus profondes (par exemple outils de design) doivent relier handoff, previews et validation sans forcer les équipes à vivre en silos.

Le shell desktop et le pont vers les dépôts ne sont plus seulement une hypothèse : Stellary se connecte au cloud, autorise des dépôts locaux et exécute des missions via des runners locaux gouvernés. La suite porte sur une couverture runners plus large, la signature macOS et des workflows codebase plus profonds, pas un produit offline parallèle.

Les ambitions sont arbitrées, explorées et parfois reportées dans notre backlog produit interne. Les sujets passent de la découverte à la planification puis à l’implémentation au fil de l’apprentissage.

Pour l’état actuel du produit, appuyez-vous sur l’expérience dans l’app, la documentation et le changelog produit. Cette page décrit une direction—pas une roadmap figée ni un calendrier.