Kiro Crew : Transformer la programmation IA de conversations éphémères en collègue résident

Démontage technique : Analyse des frameworks d’IA — Description, Analyse, Évaluation Technique, Jugement de Valeur, Mise en Œuvre. Auteur : Yongliang

---

title: “Démontage technique 008｜Kiro Crew : Transformer la programmation IA de conversations éphémères en collègue résident” cover: cover.png author: Yongliang digest: ""

Démontage technique : Analyse des frameworks d’IA — Description, Analyse, Évaluation Technique, Jugement de Valeur, Mise en Œuvre. Auteur : Yongliang

---

La plupart des sessions de programmation IA ont un point final commun : fermer la fenêtre de chat efface tous les jugements, corrections et contexte accumulés, pour recommencer de zéro la fois suivante. En juillet 2026, l’équipe Kiro d’Amazon a lancé une réponse ciblée dans la communauté open source : Kiro Crew — un espace de travail de développement persistant fonctionnant sur votre propre matériel, qui se souvient du travail à travers les sessions, solidifie les corrections en leçons, fige les modèles répétitifs en compétences, et continue à travailler selon un horaire même en votre absence. Deux mois après sa création, en septembre 2026, le projet a déjà récolté environ 3 891 étoiles, 213 contributeurs et est passé en version v0.6.0. Cet article décompose six aspects : ce que c’est, les mécanismes centraux jusqu’au niveau du code source, l’évaluation technique, si cela vaut la peine d’être utilisé, comment le déployer, et — si vous voulez écrire votre propre espace de travail persistant similaire, quel est le squelette minimum.

I. Qu’est-ce que c’est

Positionnement en une phrase : Kiro Crew est un espace de travail de développement open source fonctionnant localement ou sur votre propre serveur, dont l’idée centrale est que le travail ne devrait pas s’arrêter avec la fermeture de la fenêtre de chat — sessions, mémoire, planification, points de contrôle de tâches sont tous persistants, les corrections et échecs deviennent des leçons à long terme, et les modèles répétitifs sont solidifiés en compétences réutilisables (README original : persistent, self-learning, and self-evolving).

Clarifions d’abord les faits clés. Dépôt kirodotdev/KiroCrew, créé le 16 juillet 2026, langage principal Python (environ 1 492 fichiers source), frontend est un tableau de bord React + TypeScript + Tailwind avec une coque de bureau Electron (environ 3 712 fichiers source), plus 2 502 fichiers de test. Licence Apache-2.0, mais le fichier NOTICE du dépôt est très clair : le droit d’auteur appartient à Amazon.com, Inc. ou ses sociétés affiliées ; les noms et logos Kiro et Kiro Crew sont des marques déposées et ne sont pas inclus dans la licence logicielle. C’est l’œuvre de la même équipe que le Kiro d’AWS — le runtime agent par défaut est l’outil en ligne de commande kiro-cli de Kiro, piloté par Kiro Crew via le protocole ACP, et on peut voir directement plusieurs comptes d’employés Amazon dans la liste des remerciements du README. Les contributeurs classés par nombre de commits, les quatre premiers totalisent plus de 3 000 commits, et les trois mainteneurs Bolin Chen, Joe Guo, Zezhen Xu sont parmi eux — c’est une vraie équipe qui investit intensément, pas une popularité artificielle.

II. Mécanismes centraux

2.1 Découpage en trois couches : Runtime, Personnalité, Passerelle

La documentation d’architecture de Kiro Crew divise le système en trois couches, cette division est la clé pour tout comprendre.

Au plus bas se trouve kiro-cli, un runtime d’agent (attention, pas un agent) : il détient la connexion LLM, l’exécution d’outils (bash, lecture/écriture de fichiers, grep), la gestion des serveurs MCP, la persistance des sessions, la compression du contexte, et expose l’ACP — Agent Client Protocol, une interface JSON-RPC 2.0 sur stdio, que tout orchestrateur peut piloter. La couche intermédiaire est la configuration de l’agent : fichiers JSON dans ~/.kiro/agents/, décrivant seulement « comment cet agent se comporte » — prompt système, quels outils activer, quels serveurs MCP monter, chaque agent s’exécutant sous la forme kiro-cli acp --agent <nom>. Tout en haut vient Kiro Crew lui-même : un processus asyncio, multiplexant plus d’une douzaine de surfaces d’opération (application de bureau, tableau de bord web, ligne de commande, Slack, Discord, Telegram, Feishu, WeChat, iMessage, etc.) vers le même lot de runtimes, et ajoutant tout ce que le runtime n’exprime pas délibérément au moment de l’exécution : planification, approbation, mémoire, politiques de sécurité, connexions de messages.

Le voyage complet d’un message est : d’abord passer par les crochets de la passerelle (réponse automatique, transformation, injection, rejet), être routé vers une session, le ContextBuilder assemble le contexte (mémoire, compétences, leçons, historique), envoyé en tant que prompt ACP à kiro-cli, le modèle renvoie le texte et les appels d’outils en flux, la passerelle renvoie le flux d’événements à la surface d’opération, tout en l’ajoutant au journal de session au format JSONL, et déclenche de manière asynchrone une consolidation de la mémoire. Un détail vaut la peine d’être souligné : les appels d’outils ne passent pas directement de la passerelle au runtime — chaque appel d’outil doit d’abord passer par le point de contrôle PreToolUse de Kiro Crew, avant que kiro-cli ne soit autorisé à l’exécuter réellement. La limite de sécurité est tracée au niveau de l’orchestration, plutôt que de compter sur la conscience du prompt.

2.2 Persistance : Cinq types de stockage aux rôles distincts

La « persistance » dans Kiro Crew n’est pas un slogan, c’est cinq types de stockage à structure distincte.

Le premier type est la mémoire markdown lisible par l’homme. MemoryStore dans memory.py gère trois fichiers : preferences.md (préférences utilisateur), projects.md (contexte des projets en cours), et des résumés nommés par jour dans le répertoire history/ (YYYY-MM-DD.md). Accompagné d’un index de texte complet SQLite FTS5 pour la recherche par mots-clés. L’historique a un gradient d’atténuation clair : le contenu des 14 derniers jours est injecté en entier, celui de 15 à 60 jours seulement le titre plus la première entrée plus le nombre d’entrées restantes, 61 à 180 jours s’effondre en une ligne de date et de nombre de sessions, au-delà de 180 jours n’est plus lu, et le service heartbeat effacera les fichiers de plus de 365 jours du disque. La mémoire n’est pas meilleure quand elle est plus complète, ce gradient est une déclaration de compromis technique.

Le deuxième type est la mémoire vectorielle. VectorMemoryStore dans vector_memory.py repose également sur SQLite, divisé en trois types de lignes : clé-valeur sémantique, enregistrement de scénario, leçons, les vecteurs d’embeddings sont stockés dans la base de données sous forme de BLOB. La récupération est un score hybride — _hybrid_score dans le code source combine le score de mots-clés et le score de cosinus vectoriel, sans vecteur il dégrade automatiquement en mots-clés purs. Les enregistrements de scénario ont各自的 taux d’atténuation configurés par étiquette, l’importance participe au tri. Le calcul de l’embedding est effectué dans le processus, utilisant llama-cpp-python empaqueté, pas besoin de service d’embedding indépendant ; le prix est que lors du changement de modèle, l’espace vectoriel entier devient invalide, le code source implémente donc reconcile_embedding_space : après changement de modèle, les anciens embeddings sont tous invalidés et recalculés, évitant de mélanger deux espaces vectoriels dans le tri.

Le troisième type est les leçons. LessonStore dans learn.py est un fichier JSONL en ajout-seulement (append-only), chaque leçon un enregistrement, ajout seulement sans modification. L’utilisateur dit « Non, à l’avenir lance d’abord le check frontend avant d’appeler », cette phrase sera stockée avec une portée de niveau espace de travail, et récupérée lors de l’injection du prompt dans les sessions futures. Les leçons sont aussi vectorisées en stockage de clés sémantiques, le chemin d’écriture a des règles complètes de déduplication et de remplacement : après confirmation qu’une nouvelle valeur remplace une ancienne, les souvenirs de scénario référençant l’ancienne valeur seront retirés — une note de mesure reste dans les commentaires du code source : dans un stockage activé pendant quelques heures, sur 101 souvenirs de scénario, 21 ont été retirés, dont 14 provenant de cette règle. Le même commentaire explique aussi pourquoi au plus 3 enregistrements sont retirés à chaque consolidation : les valeurs remplacées devraient retirer quelques enregistrements qui les reformulent, pas couper une tranche du stock.

Le quatrième type est le grand livre de session, c’est la conception la plus rigide de la « continuité inter-sessions ». session_ledger.py maintient un grand livre de travail pour chaque session, les champs d’état incluent goal (objectif), phase (étape), next_step (prochaine étape), tried_approach et tried_rejected_because (ce qui a été essayé, pourquoi rejeté), artifacts (produits). La fonction record() qui écrit dans le grand livre a une discipline stricte, texte original du code source : a phase must never move without a logged, classified reason — une phase ne doit jamais avancer sans une raison enregistrée et classée, la rotation à vide et les sauts d’étape sont refusés par la structure de données elle-même. Chaque cycle d’exécution, le grand livre est rendu en un petit bloc [work ledger] réinjecté dans le prompt, l’agent peut voir à chaque tour ce qu’il avait déterminé de faire auparavant. Le grand livre est écrit dans un répertoire protégé par un fichier de verrouillage dédié, ce qui est verrouillé est l’inode et non le chemin — empêchant qu’après suppression du répertoire, un rédacteur en attente obtienne un verrou déjà retiré et écrive dans un fichier fantôme. agent_state.py utilise un JSON sidecar plus un verrouillage de fichier consultatif inter-processus pour résoudre la concurrence lecture-écriture entre le processus du tableau de bord et le processus CLI sur le même état.

Le cinquième type est la banque de mémoire à isolement multi-membres. memory_stores.py implémente un mécanisme de banques de mémoire nommées : chaque membre peut posséder sa propre banque de mémoire, avec une liste de propriété pour empêcher d’autres membres ou processus reconstruits de reprendre les anciennes données, le retrait a une marque dédiée, la distinction générationnelle entre l’ancienne banque V1 et la nouvelle V2 est écrite dans la logique de chargement. L’explication du code source sur ce mécanisme est très directe : si le même prédicat peut dériver silencieusement du code qui l’a créé, mieux vaut ne pas avoir ce prédicat — l’échec silencieux est pire que pas de prédicat. Ce type de commentaire a une densité très élevée dans le dépôt, les décisions de conception avec leurs raisons restent à côté du code.

2.3 Planification et boucle d’exécution : Trois « alarmes » pour chaque type de surveillance sans intervention

Le mode sans surveillance n’est pas un simple « faire tourner une boucle en arrière-plan », dans le code source c’est trois mécanismes.

Le premier type est les tâches programmées. CronService dans cron.py stocke les tâches dans crons.json, supporte trois expressions : every, at, cron, le fuseau horaire utilise les noms IANA analysés par ZoneInfo — des besoins comme « 9h du matin en semaine » sont enregistrés selon le fuseau horaire du créateur. Chaque déclenchement a une décomposition de budget : porte de déclenchement, examen à la réclamation, file d’attente de pool de sessions, réveil complet, quatre étapes ayant chacune un quota de temps limité, un deadline total couvre tout le tour, dépassement du budget = échec, les tâches échouant consécutivement sont mises en pause automatiquement au lieu de réessayer indéfiniment.

Le deuxième type est le heartbeat. HeartbeatService dans heartbeat.py maintient une liste de tâches HEARTBEAT.md, se réveille périodiquement pour les exécuter une par une. Si la réponse de l’agent contient la sentinelle HEARTBEAT_KEEP, cette tâche est jugée incomplète, laissée au cycle suivant — « pas fini, on revient au prochain tour » est fait en un signal lisible par machine, plutôt que de compter sur la conscience du modèle pour répéter l’état. La lecture-écriture de la liste passe par un verrou inter-processus, la transaction finale « lire → remplacer » du service heartbeat n’écrasera pas une tâche nouvellement ajoutée par un autre processus.

Le troisième type est le rappel automatique. AutoNudgeService dans autonudge.py gère les boucles de rappel liées aux sessions : une session peut suspendre une boucle d’objectif, la minuterie d’inactivité arrivée à échéance la pousse à faire un pas de plus, la boucle a un budget d’horloge murale, s’arrête automatiquement si le budget est dépassé, la raison de l’arrêt est entièrement enregistrée sur disque, après redémarrage de la passerelle la boucle reprend depuis l’état disque. Accompagné de moniteurs structurés — l’agent dit « surveille ce déploiement, dis-moi quand c’est bon », le système analysera cette phrase en une boucle de surveillance avec état de sonde, plutôt que d’espérer que l’agent se souvienne de revenir regarder.

Le support côté session est aussi dans le code source : derrière une session active se trouve soit un processus kiro-cli ACP dédié, soit un handle de session sur un runtime multiplexé partagé — la session est une frontière d’isolement logique, pas forcément égale à un processus système, les sessions inactives vont dans un warm pool attendant d’être réutilisées.

2.4 Auto-amélioration : Consolidation en trois niveaux de la correction à la compétence

L’« auto-amélioration » est divisée en trois niveaux, chaque niveau ayant son propre stockage et conditions de déclenchement.

Le premier niveau est les leçons : les corrections entrent en base immédiatement (LessonStore), lors de l’écriture dans la zone de leçons de la mémoire vectorielle elles passent par une déduplication sémantique — la soumission répétée de la même règle ne s’empile pas.

Le deuxième niveau est la consolidation : un consolidateur LLM tournant de manière asynchrone compresse les journaux de session en préférences, contexte de projet et résumés quotidiens, les conditions de déclenchement sont le nombre de messages (environ 30 messages pour préférences et projets) et la durée d’inactivité (environ 3 heures d’inactivité pour l’historique quotidien).

Le troisième niveau est les compétences : les modèles de travail répétitifs sont automatiquement solidifiés en un fichier SKILL.md, avec dans l’en-tête YAML l’enregistrement de la source (généré automatiquement, de quelle session, temps de création et de raffinement, nombre de réutilisations), la classe de preuve de source s’appelle AutoSkillProvenance. Les compétences ne s’arrêtent pas à la génération — les compétences avec répétition au niveau octet sont dédupliquées, celles référencées par des tâches programmées sont exemptées d’élimination, toutes les compétences sont visibles, éditables et supprimables dans le tableau de bord.

En comptant tout : ce mécanisme est actuellement soutenu par environ 1 492 fichiers source Python, 2 502 fichiers de test, plus que le code source — pour un projet créé il y a deux mois, cette proportion indique elle-même où l’équipe place la fiabilité.

III. Évaluation technique

D’abord la forme de base de la conclusion : ce projet n’a pas de benchmark, ni de chiffres de performance à citer, l’évaluation ne peut regarder que l’achèvement technique et la qualité de gouvernance. Et ces deux points sont précisément ses parties les plus solides.

Voir l’achèvement technique, deux indicateurs. Premièrement, la densité de décision dans les commentaires du code source : la raison de verrouiller l’inode dans session_ledger.py, la base de mesure de « limite de retrait à 3 » dans vector_memory.py, la discipline de lecture-écriture « illisible ne veut pas dire sans opinion » dans agent_state.py — presque chaque fonction non triviale porte une explication de « pourquoi faire ainsi », c’est la trace que laissent les mainteneurs à long terme. Deuxièmement, le ratio de tests : 2 502 fichiers de test contre 1 492 fichiers source, la configuration a des fichiers de base, des fichiers de base de codes d’erreur, les règles de sécurité ont un répertoire de scan semgrep. Voir la qualité de gouvernance : le dépôt a dix principes de conception classés (TENETS, le premier Safety first, en cas de conflit le premier gagne et le compromis doit être écrit), un processus RFC écrit, une déclaration de séparation des marques et de la licence logicielle — ce texte de gouvernance est une configuration surdimensionnée pour un projet de deux mois.

Comparé aux solutions similaires, les solutions leaders dans cette direction sont grossièrement en trois catégories : outils de programmation en paire terminal, frameworks d’orchestration d’agents généraux, services d’agents hébergés dans le cloud. Kiro Crew n’est pas dans la même case qu’eux : il sous-traite le « runtime » à kiro-cli et ne gère que l’orchestration et l’état, les cinq pièces d’état (sessions et journaux, mémoire, approbation, limite de gouvernance, bus d’événements) sont détenues en dernier ressort par la plateforme, tout le reste des interfaces est fait en app remplaçables — son dixième principe mot pour mot est everything is an app, si une surface ne fait pas bien l’app, c’est un défaut de la plateforme, pas une licence pour fourrer la surface dans le cœur. Le prix est tout aussi clair : le système entier dépend fortement de kiro-cli, agent.provider est fixé à acp, sans entrer dans l’écosystème Kiro ça ne tourne pas.

Il faut refroidir un peu les données de popularité. Environ 3 891 étoiles, 213 contributeurs, les deux chiffres ne sont pas bas, mais les issues et PR non fermés totalisent 1 548, un ratio très élevé pour le nombre d’étoiles — beaucoup de testeurs, le polissage n’est pas fini. Les canaux de distribution sont aussi spéciaux : pas de PyPI ni npm, le paquet bureau et le script d’installation passent par le CDN propre du projet, l’image conteneur est sur GHCR, pas de statistique publique de téléchargement ; les comptes d’employés Amazon occupent une place visible dans la liste des contributeurs, la contribution de la communauté externe est encore petite. L’échelle d’utilisation réelle est limitée, ce jugement doit être mis sur la table.

IV. Jugement de valeur

Le vrai problème est réel : l’agent oublie après avoir fini le travail, les corrections se répètent, la planification et l’approbation sont dispersées dans les fenêtres de chat — c’est la perte que chaque équipe utilisant sérieusement la programmation IA en 2026 subit. La réponse de Kiro Crew est de traiter l’état de l’espace de travail comme une infrastructure : cinq types de stockage, trois alarmes, trois niveaux de consolidation, tout sur le matériel qu’on contrôle, mémoire locale prioritaire, pas de renvoi par défaut. Pour le positionnement de « collègue », l’explication technique qu’il donne est assez complète.

Les limites sont tout aussi claires. Premièrement, l’attachement écosystémique : dépendance stricte de kiro-cli et du système de compte Kiro, ceux qui n’utilisent pas AWS Kiro seront découragés dès la première étape, c’est la chaîne la plus lourde pour un projet open source général. Deuxièmement, la limite d’architecture : la passerelle est un modèle de processus unique avec session, runtime et état sur la même machine, l’extension horizontale et le déploiement multi-machine ne sont pas actuellement dans le plan. Troisièmement, la différence de plateforme : Windows n’a pas de bac à sable équivalent au niveau système d’exploitation, le choix du code source est échec = fermeture — pas de déclaration de sortie, pas d’exécution hors bac à sable. Quatrièmement, la marque est entre les mains d’Amazon, le code peut être forké, le nom ne peut pas être emporté. Quand l’utiliser : déjà dans l’écosystème Kiro, veut un espace de travail de développement résident inter-sessions, et les données doivent rester sur sa propre machine — c’est la réponse toute prête. Quand ne pas l’utiliser : les équipes n’utilisant pas kiro-cli, les scénarios nécessitant une orchestration multi-machine, ou ceux qui veulent juste une coque de chat légère — pour les deux premiers il ne satisfait pas l’architecture, pour le dernier il est trop lourd inutilement.

V. Comment déployer

Installation en une ligne, après installation ouvrir http://localhost:5476 c’est le tableau de bord :

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

La condition préalable unique : installer kiro-cli sur la machine de la passerelle et se connecter séparément, le premier démarrage vérifie automatiquement et donne le guide. L’installateur utilise par défaut CPython 3.12 géré intégralement (guidé par uv), ne touche pas l’interpréteur système ; pour le rendre résident faire kirocrew service install, Linux installe un service systemd, macOS installe launchd. Le chemin conteneur est aussi prêt :

docker run -d --name kirocrew -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew ghcr.io/kirodotdev/kirocrew:stable

L’usage quotidien cinq commandes couvrent la plupart des scénarios : kirocrew chat pour dialogue interactif, kirocrew run TASK.md pour lancer une tâche avec points de contrôle, kirocrew cron pour gérer les tâches programmées, kirocrew spawn run “tâche” pour lancer des sous-agents parallèles, kirocrew security pour voir l’audit. Côté ops retenir trois : kirocrew doctor pour le check-up, kirocrew logs pour voir les logs, dans les Settings du tableau de bord on peut couper le heartbeat d’utilisation anonyme une fois par jour. Suggestions de choix deux : spécifier explicitement le répertoire de données avec KIROCREW_HOME et l’inclure dans la sauvegarde — mémoire, leçons, compétences sont toutes dedans ; pour exposer le tableau de bord vers l’extérieur passer impérativement par la configuration distante avec authentification par jeton, le lien par défaut à la boucle locale est la ligne de base de sécurité pas la valeur par défaut.

VI. Comment faire soi-même un ensemble similaire

« Écrire son propre ensemble » est particulièrement faisable sur ce sujet, car Kiro Crew a lui-même prouvé que le runtime et la couche d’état peuvent être séparés. Squelette minimum en sept étapes :

1. D’abord couper les couches : choisir un runtime d’agent existant (kiro-cli, adaptateur ACP de claude-code, ou tout runtime pilotable par stdio JSON-RPC), n’écrire que la passerelle — routage de messages, table de sessions, stockage d’état. Ce coup de couteau réduit la difficulté de moitié.
2. Grand livre de session : un transcript JSONL append-only par session, plus un fichier d’état pour goal, phase, next_step, tried_approach. Écriture avec fichier temporaire plus rename pour écriture atomique, ajout de verrou consultatif inter-processus pour scénarios multi-lecture multi-écriture. Faire de « l’avancement de phase doit porter une raison » une validation d’écriture, c’est la discipline clé pour que le mode sans surveillance ne dérive pas.
3. Mémoire à double index : fichiers markdown pour lecture humaine, SQLite FTS5 pour mots-clés, vecteurs stockés BLOB dans la même base pour recherche sémantique, score hybride, dégradation en mots-clés sans vecteur. Embedding avec solution type llama-cpp dans le processus suffit, lors du changement de modèle invalidation complète des anciens vecteurs.
4. Consolidateur : lancer une boucle asynchrone, déclenchée par nombre de messages ou durée d’inactivité, laisser le modèle compresser le transcript en trois niveaux : préférences, projet, résumé quotidien, le résumé avec fenêtre d’atténuation (14 jours texte entier / 60 jours abrégé / 180 jours une ligne).
5. Banque de leçons : un JSONL append-only suffit, filtrer par portée avant injection dans le prompt, faire déduplication sémantique et retrait des vieux enregistrements de valeurs remplacées lors de l’écriture.
6. Trois alarmes : expression cron pour planification avec fuseau horaire et budget temps par étape, fichier heartbeat avec signal sentinelle pour exprimer « pas fini », boucle d’objectif avec budget horloge murale et raison d’arrêt enregistrée sur disque.
7. Porte de sécurité : tous les appels d’outils passent d’abord par son propre point de contrôle avant d’être autorisés, avec répertoire de rejet, protection de chemins sensibles et masquage des identifiants. Cette étape ne peut être sautée — le mode sans surveillance amplifie les permissions, pas l’intelligence.

En sept étapes, une équipe de deux personnes peut livrer une version utilisable en un trimestre. Les plus de deux mille fichiers de test de Kiro Crew rappellent l’autre moitié de la vérité : un squelette qui tourne ne vaut rien, polir les verrous, les limites, les modes d’échec un pouce à la fois, c’est ça qui vaut de l’or.

Conclusion

Kiro Crew redéfinit l’espace de travail de programmation IA de « une conversation » à « un état persistant » : cinq types de stockage, trois alarmes, trois niveaux de consolidation, tout local prioritaire, et chaque couche a une explication technique au niveau du code source. C’est l’œuvre open source de l’équipe Amazon Kiro, liée fermement à kiro-cli, l’échelle d’utilisation réelle reste à valider — mais pour les équipes déjà dans l’écosystème Kiro et voulant que l’agent se souvienne du travail inter-sessions, c’est la réponse prête la plus aboutie actuellement ; pour ceux qui veulent construire leur propre ensemble, son code source est un manuel plus honnête que n’importe quel blog.

Références

• Dépôt GitHub Kiro Crew (README, TENETS, GOVERNANCE, NOTICE, MAINTAINERS) : https://github.com/kirodotdev/KiroCrew
• Documentation d’architecture Kiro Crew (docs/architecture/overview.md : division en trois couches, flux de messages, cycle de vie de la mémoire, diagramme des composants backend) : https://github.com/kirodotdev/KiroCrew/blob/main/docs/architecture/overview.md
• Code source Kiro Crew : src/kiro_crew/agent.py (spécification agent et projection gouvernance), session.py (pool de sessions et cycle de vie), memory.py (MemoryStore, markdown + FTS5), vector_memory.py (VectorMemoryStore, récupération hybride et coordination espace vectoriel), memory_stores.py (banques de mémoire nommées et propriété), learn.py (LessonStore, JSONL append-only), session_ledger.py (grand livre de travail et discipline record), agent_state.py (état sidecar et verrou inter-processus), cron.py (CronService planification et décomposition budget), heartbeat.py (HeartbeatService et sentinelle HEARTBEAT_KEEP), autonudge.py (AutoNudgeService boucle objectif), skills.py (chargement compétences, preuve source et déduplication), session_summary.py (résumé et désensibilisation)
• Métadonnées du dépôt GitHub et liste des contributeurs (api.github.com, septembre 2026) ; dernière release v0.6.0 (2026-09-11)
• kiro.dev (site officiel Kiro et kiro-cli)