Cartes

Une carte est à la fois un élément de travail et l’emplacement durable de ses sessions agent, messages, fichiers, état Git, commentaires et historique.

Créer une carte

Cliquez sur Nouvelle carte ou sur le plus d’une colonne. Le prompt décrit l’objectif de l’agent ; le titre est optionnel et peut être généré depuis ce prompt.

La fenêtre permet de configurer :

• colonne de destination et labels ;
• identifiant, agent fournisseur, modèle, effort de raisonnement et, pour Claude Code et OpenCode, compaction ;
• dépôt principal ou worktree Git isolé avec branche personnalisée ;
• mode Auto et choix de pipeline propres à la carte ;
• Boucle planifiée qui relance la carte sur place ;
• exécution Agent structurée ou Terminal interactif.

Joignez les fichiers d’entrée nécessaires. Utilisez les mentions @ de fichiers et commandes ou skills / lorsque l’agent choisi les prend en charge. Ne collez jamais mot de passe ou token dans le prompt normal : le cadenas de la zone de saisie le joint au message en cours, au même titre qu’un fichier, et la demande part avec lui. Le cadenas permet aussi de désigner un secret du coffre du projet et, dans l’app desktop, d’en lire un dans 1Password, Bitwarden ou les Identifiants Windows. La conversation n’en garde que le libellé ; l’agent reçoit un fichier privé, jamais la valeur.

Écrire un bon prompt

Décrivez le résultat attendu, les contraintes importantes, fichiers ou composants pertinents et la manière de vérifier la fin. N’imposez pas des détails d’implémentation inutiles. Une bonne carte laisse l’agent inspecter le dépôt avant d’arrêter son plan.

Ouvrir et suivre le travail

Cliquez sur une carte pour ouvrir son panneau. Les principaux onglets sont :

• Conversation — messages utilisateur, réponses agent, appels d’outils, questions et zone de saisie ;
• Diff — fichiers changés dans le worktree ou dépôt actif ;
• Coûts — ce que les runs de la carte auraient coûté au tarif API public des fournisseurs ;
• Historique — sessions et événements importants de la carte.

L’en-tête expose statut/colonne, contrôles d’exécution et actions supplémentaires. Plusieurs panneaux peuvent rester ouverts, dans la limite choisie par l’utilisateur et de la largeur disponible.

Coûts

Les coûts des runs sont désactivés sur un nouveau serveur : l’opérateur les active dans Réglages serveur › Coûts. Les tokens sont consignés dans tous les cas, l’historique est donc complet depuis le premier run.

L’onglet Coûts affiche l’équivalent API de la carte : ce que les tokens consommés par ses agents auraient coûté au tarif API public de chaque fournisseur, quel que soit l’identifiant qui les a servis. Un abonnement n’est pas facturé ainsi : c’est une valeur de comparaison, pas une facture.

• Chaque run est chiffré au tarif en vigueur le jour de son démarrage, à la vitesse à laquelle il a tourné (le fast mode double Opus 5.5, par exemple) et au palier de prix de chaque requête (les paliers de contexte long se décident requête par requête).
• Un run se déplie sur ses agents : le principal, puis chaque sous-agent — un workflow ou un Ultracode — sur son propre modèle. Quand les totaux par modèle du runner dépassent les requêtes que Stib a vues (Claude Code), le reste ferme la liste en Non attribué.
• Économisé grâce au cache compare aux mêmes tokens facturés sans cache ; Et si… rechiffre la carte sans fast mode ou sans cache.
• Quand le runner annonce son propre montant (Claude Code, OpenCode, Grok…), il est affiché à côté de celui de Stib pour le recouper.
• Sur une carte qui a tourné avant le suivi par run, cet usage antérieur tient sur une ligne, chiffrée au prix actuel.
• Le pied de page nomme ce que le montant laisse de côté ou approche — un modèle sans tarif publié, un runner qui ne fournit pas de tokens, des écritures du cache sans durée — et renvoie aux sources des prix avec leur date de vérification.

Les coûts du projet sur une période — par modèle, membre ou runner, les cartes les plus coûteuses, et le prix mensuel de chaque abonnement face à ce qu’il a servi — s’ouvrent depuis le menu du projet dans la barre latérale, Coûts. Le prix mensuel d’un abonnement se saisit dans les réglages de son identifiant : Stib ne peut pas le connaître.

Statut et activation

Les états d’exécution usuels comprennent inactif, en cours, en attente d’une réponse, terminé, en erreur et annulé. Déplacer une colonne et changer un statut d’exécution sont deux choses différentes : une session terminée ne déplace pas forcément la carte sans mode Auto ou automatisation.

Vous pouvez activer un travail différé, annuler un agent, relancer une session, envoyer un nouveau message ou déplacer la carte. Les contrôles se désactivent lorsqu’un verrou, une permission ou un état incompatible rend l’action dangereuse.

Déplacer, archiver et supprimer

Glissez les cartes ou utilisez leurs actions. L’entrée dans une colonne active peut lancer le travail ; la sortie peut mettre en pause, reprendre, remettre le contexte à zéro, nettoyer le worktree, archiver ou déclencher des hooks selon les réglages.

L’archive masque le travail terminé sans effacer son historique. Les cartes supprimées passent dans la corbeille si la rétention projet est active et restent restaurables jusqu’à la suppression définitive. La corbeille ne remplace pas une sauvegarde.

Cartes externes et project-agent

Les intégrations peuvent importer des tickets externes sous forme de cartes liées. Certains boards affichent aussi du travail project-agent avec les cartes Kanban. Leurs actions et champs faisant autorité peuvent différer ; Stib affiche l’état de synchronisation et ses erreurs au lieu d’écraser silencieusement une modification non prise en charge.

Suite : Agents, Pipeline et Intégration Git.