Paramètres appliqués en direct, travail durable et surveillance élargie des pull requests
0.7.0Kiro Crew 0.7.0 rend le travail quotidien plus durable et plus facile à maîtriser. La plupart des paramètres s'appliquent dès leur enregistrement, le travail en arrière-plan accepté survit aux redémarrages de la passerelle et les mises à jour attendent la fin du travail en cours. Les longs clavardages gagnent une mini-carte des tours, des titres d'appels d'outils plus clairs ainsi que des contrôles directs du modèle et du niveau d'effort de raisonnement, tandis que la surveillance des pull requests s'étend à GitLab, Bitbucket Cloud et Azure DevOps Services. Windows bénéficie de pods isolés et d'un démarrage plus rapide de la passerelle, et les utilisateurs des fonctionnalités en aperçu peuvent choisir davantage de backends d'agent, laisser Jev acheminer chaque tour ou exécuter des Crews distantes sur AWS Fargate.
La plupart des paramètres atteignent désormais la passerelle en cours d'exécution dès que vous enregistrez config.json ou modifiez une valeur dans Paramètres. Les champs qui nécessitent encore un redémarrage l'indiquent dans l'interface; le champ de commande slash Slack est actuellement le seul paramètre qui s'applique uniquement au démarrage et affiche un badge Les changements nécessitent un redémarrage.
Une mini-carte dans la marge gauche d'un clavardage sur ordinateur affiche un repère par tour chargé, avec un aperçu au survol, une navigation par clic et un embout qui charge l'historique antérieur. La pastille du modèle regroupe désormais le modèle et le niveau d'effort de raisonnement, et Modèles sélectionnables détermine les options affichées. Lorsque l'agent travaille, choisissez Diriger pour réorienter le tour en cours ou Mettre en file pour attendre le suivant; Cmd ou Ctrl plus Entrée exécute l'autre action pour un seul envoi.
Le clavardage latéral s'ouvre avec /side ou /btw pour poser une question éphémère à côté de la conversation principale. Dans une session utilisant le backend Kiro CLI, il peut effectuer des recherches en lecture seule sans approbation; les modifications et les outils MCP sont refusés. Les tableaux peuvent être copiés en Markdown ou en CSV, et les longs blocs de code répètent leurs actions au bas du bloc.
Les tâches de sous-agents acceptées, les étapes du Task Runner et les appels de workflows entrent désormais dans une file d'attente durable avant leur exécution. Un redémarrage de la passerelle restaure le travail en attente au lieu de le supprimer, et la page Système affiche la file active ainsi que la capacité de concurrence en vigueur.
Pour les travaux de longue durée, le journal Crew facultatif consigne par ajouts successifs ce que fait chaque session et alimente un registre durable qui survit à la compaction du contexte. Définissez KIROCREW_CREW_LOG=1 dans ~/.kiro/crew/.env et redémarrez la passerelle pour activer ses vues d'état, d'utilisation, de chronologie, d'outils et d'approbations. Le serveur MCP kirocrew-crew-log offre aux agents un accès en lecture seule.
L'outil de surveillance structurée des pull requests accepte désormais les URL GitHub, GitLab, Bitbucket Cloud et Azure DevOps Services. GitLab utilise glab; Azure DevOps utilise az avec l'extension azure-devops et une session az login ou AZURE_DEVOPS_EXT_PAT; les pull requests Bitbucket privées peuvent utiliser BITBUCKET_EMAIL et BITBUCKET_API_TOKEN.
Azure DevOps Server et Bitbucket Data Center ne sont pas pris en charge. Les surveillances Azure DevOps et Bitbucket privées doivent être lancées depuis une conversation du tableau de bord. Les actions d'arrêt et d'inspection fonctionnent désormais avec les boucles à minuterie, les surveillances de pull requests et les surveillances de workflows, y compris depuis Webex.
OpenCode et goose rejoignent Kiro CLI, Claude Code, Codex et KAS dans le sélecteur de backend d'agent. Crew vérifie le mécanisme d'autorisation de chaque backend avant la première requête et indique les composants manquants dans le sélecteur. Les sessions Codex et OpenCode peuvent compacter leur contexte, et les outils MCP de Crew sont disponibles dans les sessions OpenCode et goose.
Pi est également offert lorsque pi et pi-acp sont installés. Les sessions Pi n'ont pas accès aux outils MCP de Kiro Crew; choisissez donc un autre backend lorsque vous avez besoin des sous-agents Crew, de la planification, de la mémoire ou d'autres fonctionnalités MCP. kirocrew doctor signale cette limite.
Activez Décisions (Jev) sous Paramètres > Développeur > Aperçus des fonctionnalités, puis choisissez Auto (Jev) dans le sélecteur de modèle d'un clavardage pour classer chaque message comme simple, moyen ou complexe et l'acheminer au moyen de decisions.model_route. Choisissez Auto (Jev) sur le bouton d'envoi lorsqu'un tour est en cours pour laisser Jev décider si le nouveau message doit réorienter ce tour ou attendre dans la file. Chaque décision apparaît sur le message qu'elle a influencé, avec des contrôles de rétroaction.
Cette fonctionnalité en aperçu est facultative. L'acheminement du modèle et les décisions d'envoi ne commencent que lorsque vous sélectionnez Auto (Jev) dans le contrôle correspondant. La carte des paramètres explique quel contenu peut être envoyé au fournisseur configuré; des commutateurs de consentement distincts régissent les arguments d'outils, les entrées de compaction et les extraits de mémoire récupérés.
AWS Fargate rejoint SSH et AWS Systems Manager Session Manager (SSM) comme méthode de connexion à une Crew distante. Crew atteint la tâche au moyen de SSM sans règle réseau entrante, en utilisant AWS CLI et le plugiciel Session Manager sur votre ordinateur. Les tâches durent six heures par défaut et le moteur d'exécution en accepte au plus dix à la fois. Modifiez la durée de vie avec fargate.task_ttl_seconds dans cloud.json; le plafond de dix tâches est fixe.
La passerelle vérifie désormais les mises à jour au démarrage et toutes les douze heures. Une mise à jour automatique suspend l'admission de nouveau travail et attend que les tours actifs, les exécutions planifiées, les sous-agents, les étapes du Task Runner et les workflows deviennent inactifs avant de s'appliquer, puis redémarre la passerelle. Si une mise à jour du code source exige une version de Python plus récente que celle de l'environnement virtuel actuel, Crew refuse de déplacer le dépôt et indique l'interpréteur à mettre à niveau.
Les installations gérées peuvent également armer une mise à jour depuis les boîtes de dialogue de mise à jour et Nouveautés, au moyen de la même approbation temporaire de l'hôte que celle affichée sous Paramètres > À propos.
Le workflow de pods isolés fonctionne désormais sous Windows par l'intermédiaire du Planificateur de tâches. kirocrew pod up, down, ls, status, token, url, logs, prune et provision couvrent le cycle de vie d'un pod pour un arbre de travail du code source Kiro Crew. pod api demeure indisponible sous Windows, car son canal de requête privé dépend d'un socket de domaine Unix.
Lorsque Dev Fleet est activé sous Applications > Bibliothèque, un agent peut démarrer ou arrêter le pod d'un arbre de travail et recevoir son adresse, son port et son jeton à courte durée de vie sans quitter le clavardage.
skills.max_triggered prend désormais la valeur par défaut 0. Les sessions reçoivent un index concis des Skills et les agents utilisent skill_search pour charger les instructions pertinentes, au lieu d'injecter automatiquement chaque correspondance de déclencheur. Définissez une valeur positive pour autoriser l'injection d'au plus ce nombre de Skills correspondants par message.