Daemon et runtimes

trackica enregistre et coordonne le travail ; ce sont les ordinateurs connectés qui l'exécutent. Le daemon d'un ordinateur prend en charge les exécutions et invoque les outils de codage IA installés sur cette machine.

Runtime distant Qoder Cloud Agents

Qoder Cloud Agents exécute les tickets assignés dans des sessions QCA distantes. Le serveur trackica supervise un pont qui utilise le protocole de tâches existant du daemon ; aucun daemon local n'est nécessaire pour ce runtime.

Avant de commencer

• Vous devez être administrateur de l'espace de travail. Chaque espace de travail a une seule connexion Qoder.
• Dans Qoder, créez un jeton d'accès personnel (PAT), au moins un environnement et les agents QCA à utiliser. Les modèles, outils et skills se configurent sur l'agent QCA dans Qoder, pas dans trackica.
• Les installations auto-hébergées doivent définir TRACKICA_VCS_SECRET_KEY sur le serveur : une clé de 32 octets encodée en base64, identique d'un redémarrage à l'autre. Sans elle, Qoder Cloud Agents n'apparaît pas dans le menu Ajouter.

Connecter Qoder

1. Sur la page Runtimes, cliquez sur Ajouter et choisissez Qoder Cloud Agents sous Services cloud.
2. Sous Région, choisissez le site qui a émis votre PAT : International (qoder.com) ou Chine (qoder.com.cn). Un PAT ne fonctionne que dans sa propre région ; s'il est refusé, utilisez le bouton qui réessaie sur l'autre site.
3. Collez le PAT dans Jeton d'accès personnel. Une fois vérifié, la liste Environnement est chargée depuis Qoder. Un environnement unique est sélectionné automatiquement ; sinon, choisissez-en un.
4. Facultatif : ouvrez Autorisation GitHub et ajoutez l'URL et un jeton pour chaque dépôt que les agents peuvent cloner. Les agents ne peuvent cloner que les dépôts autorisés ici.
5. Facultatif : ouvrez Exécution pour régler le nombre d'exécutions simultanées (3 par défaut, 10 au maximum) et le délai d'expiration (60 minutes par défaut, de 5 à 240).
6. Cliquez sur Connecter. Qoder Cloud Agents apparaît dans la section cloud de la page Runtimes et passe en ligne en quelques secondes.

Ajouter un agent

Ouvrez Qoder Cloud Agents depuis la page Runtimes et cliquez sur Créer un agent avec, ou créez un agent comme d'habitude en choisissant le runtime Qoder. Dans le formulaire de l'agent, sélectionnez l'agent distant sous Agent QCA. Pour un agent existant, modifiez l'agent QCA ou son dépôt par défaut dans l'onglet Routage. Plusieurs agents trackica peuvent partager une connexion, chacun lié à un agent QCA différent.

Les identifiants de connexion sont chiffrés et partagés dans l'espace de travail. Les administrateurs gèrent la connexion ; les membres peuvent sélectionner les agents QCA accessibles. Les projets choisissent le dépôt et la branche de départ ; le jeton du dépôt est transmis à QCA à la création d'une session de code. Les PAT ne sont jamais renvoyés au navigateur après l'enregistrement.

Sur la page Qoder Cloud Agents, les administrateurs peuvent modifier la connexion et les dépôts, Mettre en pause pour ne plus envoyer de nouvelles tâches en conservant identifiants et agents, ou Déconnecter pour supprimer les jetons enregistrés, retirer le runtime et délier ses agents.

Fonctionnement des exécutions

Au-delà de la limite de simultanéité, les exécutions attendent dans la file. Une relance sur le même ticket reprend la session Qoder précédente de l'agent si elle est inactive. Un agent peut définir un dépôt par défaut, utilisé quand le projet du ticket n'en a pas. L'agent est invité à pousser une branche nommée d'après l'identifiant du ticket et à préfixer le titre de la pull request avec cet identifiant, afin que la pull request soit liée au ticket.

Cette première version prend en charge l'exécution des tickets, le suivi de progression, l'annulation et la reprise à partir d'un journal d'exécution persistant. Le chat interactif, les répertoires locaux, les pièces jointes et la création d'agents QCA distants depuis trackica ne sont pas pris en charge. La page Runtimes sépare les runtimes distants des ordinateurs connectés.

Pour le déploiement du pont autonome et ses limites opérationnelles, consultez le README du runtime Qoder.

Daemon et runtime

• Le daemon est le processus d'arrière-plan de trackica qui tourne sur un ordinateur. Il se connecte au serveur, détecte les outils locaux, prend en charge les exécutions et renvoie les résultats.
• Un runtime représente un environnement d'exécution concret mis à la disposition d'un espace de travail. Il correspond à un ordinateur associé à un outil de codage IA — ou à un profil de runtime personnalisé — sur cet ordinateur.

Par exemple, un ordinateur sur lequel sont installés Claude Code et Codex est connecté à deux espaces de travail. Le daemon enregistre un runtime Claude Code et un runtime Codex pour chaque espace de travail. Redémarrer le daemon met à jour les enregistrements existants ; il ne crée pas de nouveaux runtimes à chaque fois pour la même combinaison.

Lieu d'exécution et périmètre des données

Les outils de codage IA qu'invoque un runtime local, leurs propres identifiants de connexion et vos répertoires de code locaux restent tous sur l'ordinateur connecté. Le serveur trackica n'exécute pas de commandes à la place des outils locaux et ne téléverse pas automatiquement l'intégralité de votre répertoire de travail.

Pour permettre à l'équipe de collaborer, le serveur stocke les tâches, les commentaires, la configuration des agents, le contexte des exécutions, les enregistrements d'exécution et les résultats que les agents renvoient. Ce contenu peut inclure des extraits de code ou d'autres éléments de contexte du projet qu'un agent a choisi de lire et d'inclure dans ses réponses.

Démarrer le daemon

Avec trackica Desktop, l'application démarre le daemon automatiquement — aucune commande supplémentaire n'est nécessaire.

Sur le web, sur un ordinateur distant ou dans un environnement sans interface graphique, installez d'abord le CLI trackica, puis exécutez :

trackica daemon start

Par défaut, le daemon s'exécute en arrière-plan. Commandes courantes :

Pour placer les répertoires de travail des exécutions sur un autre disque, enregistrez une racine pour le profil courant avec trackica config set workspaces_root <path>, ou passez --workspaces-root <path> à daemon start ou daemon restart. L'option prime sur TRACKICA_WORKSPACES_ROOT, qui prime elle-même sur la configuration du profil. Les répertoires d'exécution existants ne sont pas déplacés lorsque la racine change.

Au démarrage, le daemon détecte les outils de codage IA pris en charge présents dans le PATH et enregistre des runtimes pour les espaces de travail auxquels vous êtes autorisé à vous connecter. Si vous venez d'installer un outil ou de vous y connecter, redémarrez le daemon pour qu'il le détecte à nouveau.

Pour démarrer, le daemon a besoin de détecter au moins un outil de codage IA intégré pris en charge. Les méthodes d'installation et les noms des exécutables figurent dans Installer les outils de codage IA.

Distribution et statut en ligne

Une fois enregistré, un runtime maintient une connexion persistante. Lorsqu'une nouvelle exécution entre dans la file d'attente, le serveur prévient le daemon concerné ; le daemon interroge aussi le serveur périodiquement, en filet de sécurité après une interruption de connexion. Ainsi, lorsqu'un runtime est en ligne et dispose de capacité libre, les exécutions démarrent généralement immédiatement.

Le daemon envoie un signal de présence (heartbeat) toutes les 15 secondes. Le serveur combine ces signaux et l'état de la connexion pour déterminer si un runtime est en ligne ; lorsqu'un daemon s'arrête de manière inattendue, le runtime apparaît généralement hors ligne en 3 minutes environ au plus tard.

Lorsqu'un runtime est hors ligne :

• Les exécutions déjà en file d'attente attendent que le runtime revienne. Elles n'échouent qu'une fois que le runtime a cessé d'envoyer des signaux de présence pendant plus longtemps que le délai de grâce de reconnexion et que l'exécution elle-même est en file d'attente depuis aussi longtemps ; ainsi, un runtime simplement occupé conserve sa file, et le travail assigné à un runtime déjà hors ligne bénéficie tout de même d'un délai de grâce complet.
• Les exécutions en cours échouent ; les exécutions de tâche ou de discussion éligibles peuvent être relancées automatiquement.
• Au redémarrage, le daemon réenregistre ses runtimes et récupère les exécutions qui ne se sont pas terminées proprement la dernière fois.
• Un runtime hors ligne depuis plus de 7 jours et auquel aucun agent n'est lié (y compris les agents archivés) est supprimé automatiquement.

Les états détaillés et les règles de relance figurent dans Exécutions.

Limites de parallélisme

Par défaut, un daemon traite au maximum 20 exécutions simultanées, et chaque agent au maximum 6. Le parallélisme effectif correspond à la plus petite de ces deux valeurs.

Une fois une limite atteinte, les nouvelles exécutions restent en file d'attente. Vous pouvez ajuster le parallélisme d'un agent donné dans ses paramètres, et le plafond global de la machine via TRACKICA_DAEMON_MAX_CONCURRENT_TASKS. Les exécutions en parallèle se disputent en même temps la capacité de la machine, le quota du compte de l'outil et le même répertoire de travail.

Runtimes privés et publics

Un runtime local est privé par défaut : seul le propriétaire du runtime peut y créer des agents. Les propriétaires et administrateurs de l'espace de travail ne font pas exception — le runtime est l'ordinateur de quelqu'un d'autre, et y exécuter un agent consomme sa machine et ses identifiants d'outils.

Seul le propriétaire du runtime peut le rendre public — les administrateurs de l'espace de travail peuvent renommer ou supprimer un runtime, mais le partager relève de la décision du propriétaire. Les autres membres de l'espace de travail peuvent alors eux aussi sélectionner ce runtime ; cela ne partage pas les identifiants de connexion de l'outil de codage IA sous-jacent — cela permet seulement aux membres d'acheminer les exécutions de leurs agents vers cet ordinateur.

Lorsque le propriétaire rend un runtime public à nouveau privé, trackica affiche d'abord les agents et les exécutions actives concernés, y compris les conversations de création d'agents avec Agent Builder. La confirmation dissocie les agents de ces autres membres, annule leurs exécutions en file d'attente, distribuées, en cours, en attente d'un répertoire local ou différées avec le motif runtime_access_revoked, et met en pause les automatisations actives assignées aux agents dissociés. Les agents et exécutions du propriétaire ne sont pas affectés. Si le plan change, une nouvelle confirmation est nécessaire ; des modifications simultanées de la discussion peuvent nécessiter de réessayer. Pour reprendre le travail, associez l'agent à un runtime accessible, puis reprenez explicitement ses automatisations en pause.

L'annulation conserve l'historique de discussion et enregistre sur le serveur les données de restauration du brouillon et des pièces jointes. Les versions web et bureau utilisent l'interface de restauration existante ; la version mobile ne propose pas encore cette interface. Une exécution démarrée sans sortie attend l'accusé d'annulation du daemon ou la fin du délai de finalisation du serveur avant de décider si la saisie doit être restaurée. Un daemon connecté reçoit l'annulation lors de sa vérification habituelle. Si l'ordinateur est hors ligne, l'accès côté serveur est tout de même révoqué immédiatement, mais le processus local peut continuer jusqu'à sa reconnexion et à la réception de l'annulation ; le serveur ne peut pas garantir un arrêt à distance immédiat.

Profils de runtime personnalisés

Si votre équipe utilise un wrapper interne, un exécutable à version figée, ou a besoin d'arguments supplémentaires fixes pour un outil compatible, créez un profil de runtime personnalisé.

Un profil personnalisé n'ajoute pas de nouveau protocole de communication. Vous choisissez toujours l'une des familles de protocoles que trackica prend déjà en charge (le type de protocole d'intégration de l'outil ; voir Comparatif des outils de codage IA), et la commande elle-même doit être compatible avec cette famille.

Environnement du runtime pendant une exécution

Lorsque le daemon démarre l'exécution d'un agent, il injecte le contexte de l'exécution dans le processus du runtime. Ces valeurs appartiennent au daemon : l'environnement personnalisé d'un agent ne peut remplacer aucune variable TRACKICA_ ni les variables de répertoire temporaire de l'exécution.

Le tableau liste les variables que les runtimes personnalisés peuvent utiliser aujourd'hui. Il n'est volontairement pas exhaustif et ne constitue pas une surface d'API versionnée. Ne construisez vos intégrations que sur les cinq variables marquées contrat d'intégration ; considérez les autres comme des informations indicatives susceptibles de changer.

Le serveur détermine l'auteur des requêtes effectuées avec TRACKICA_TOKEN ; les écritures telles que les commentaires de tâche sont attribuées à l'agent assigné et à l'exécution en cours. Pour tout savoir sur le rattachement du jeton, ses permissions, l'attribution, sa durée de vie maximale de 24 heures et son nettoyage, consultez Jetons temporaires pour les exécutions d'agents.

Créer un profil

Seuls les propriétaires et administrateurs de l'espace de travail peuvent créer, modifier ou supprimer des profils de runtime personnalisés :

1. Ouvrez Runtimes et accédez à un ordinateur sur lequel la commande est installée.
2. Cliquez sur Ajouter un runtime personnalisé.
3. Choisissez la famille de protocoles avec laquelle la commande est réellement compatible.
4. Renseignez le nom, la commande et les arguments fixes, puis enregistrez.

Le profil est partagé dans tout l'espace de travail. Chaque ordinateur connecté recherche la commande de son côté ; seuls les ordinateurs capables de la résoudre dans le PATH enregistrent le runtime correspondant. Créer un profil n'installe pas la commande et ne connecte pas les autres membres à l'outil.

Le champ de commande accepte un exécutable et des arguments, pas un script shell. Les arguments simples, les guillemets et les échappements par barre oblique inverse fonctionnent ; les tubes, les redirections, &&, ;, les accents graves (backticks) et l'expansion de variables d'environnement ne fonctionnent pas. Si vous avez besoin de ces comportements, placez-les dans un script d'encapsulation et utilisez ce script comme commande.

Ordre de vos arguments

Tout ce que vous saisissez dans le champ de commande reste directement après l'exécutable, avant les arguments ajoutés par trackica :

<your command> <your fixed arguments> <trackica's protocol arguments> <the agent's custom arguments>

C'est ce qui permet à un wrapper à sous-commandes de fonctionner. Si votre commande est ccms start q36, l'outil voit d'abord start q36 et peut sélectionner sa sous-commande avant que n'arrivent le -p de trackica et le reste — c'est le seul ordre qu'accepte ce type de wrapper.

Auparavant, vos arguments étaient ajoutés en dernier. La plupart des commandes à options les analysent de la même façon dans les deux cas, mais pas toutes — une commande qui distingue les options globales des options de sous-commande peut être sensible à la position d'une option. Si vous avez déjà un profil avec des arguments fixes, lancez une exécution dessus après la mise à jour pour vérifier qu'il fonctionne toujours.

Deux autres conséquences à connaître :

• Les valeurs de trackica l'emportent en cas de conflit. Si vos arguments fixes définissent une option que trackica définit aussi, la valeur de trackica arrive plus tard et prend effet. Surtout, un modèle choisi sur l'agent remplace un --model figé dans le profil. Pour imposer un modèle à tout le monde, laissez vide le champ du modèle des agents.
• Les options critiques pour le protocole sont ignorées. -p, --output-format, --input-format, --permission-mode et leurs équivalents pour les autres familles sont retirés de vos arguments fixes, car les remplacer romprait la connexion du daemon à l'outil. Les sous-commandes et les autres arguments positionnels sont toujours transmis.

Si un daemon lancé par Desktop ne trouve pas une commande que votre terminal peut exécuter, définissez un chemin absolu pour l'ordinateur courant :

trackica runtime profile set-path <profile-id> --path /absolute/path/to/command

Supprimer le remplacement de chemin :

trackica runtime profile unset-path <profile-id>

Modifier un profil n'affecte que les exécutions prises en charge par la suite. Avant de supprimer un profil, occupez-vous des agents actifs encore liés à ses runtimes. Supprimer uniquement l'instance de runtime sur un ordinateur ne supprime pas le profil — un daemon en cours d'exécution le réenregistrera.

Dépanner un runtime hors ligne

Vérifiez dans cet ordre :

1. Exécutez trackica daemon status pour confirmer que le daemon tourne.
2. Exécutez trackica daemon logs -f pour rechercher des erreurs d'authentification, de réseau ou de détection d'outils.
3. Exécutez command -v <tool-command> dans le même environnement pour confirmer que le daemon peut trouver l'outil.
4. Ouvrez la page Runtimes de trackica et vérifiez que l'ordinateur cible et l'outil de codage IA correspondant apparaissent en ligne.
5. Après l'installation d'un outil, une modification du chemin ou la mise à jour d'un profil, exécutez trackica daemon restart.

Si le problème persiste, consultez Dépannage.

Étapes suivantes

• Installer les outils de codage IA — installer et vérifier un outil de codage IA pris en charge.
• Comparatif des outils de codage IA — comparer les modèles, la reprise de session, MCP et la prise en charge des skills.
• Exécutions — file d'attente, arrêt et relances.