La pile de mémoire pour agents IA que tout le monde devra utiliser en 2026 (Guide du développeur)

Votre modèle et votre harnais n'ont plus d'importance.

Ce qui compte vraiment, c'est...

votre contexte personnel / mémoire partagée

Introduction

Je vais vous montrer comment construire une mémoire partagée pour vos agents de codage... afin que l'outil suivant puisse retrouver les décisions que vous avez déjà prises.

La conversation d'architecture dans Claude, la session de débogage dans Codex, l'explication enfouie dans Cursor... un travail utile qui devrait encore être disponible lorsque vous changez d'outils, démarrez une autre session, ou revenez au projet après un mois d'absence.

TLDR ; si vous ne voulez pas lire les 3 845 mots, donnez simplement ce dépôt GitHub à votre agent ➡️ https://github.com/codejunkie99/agentic-stack-desktop

J'ai construit tout cela en utilisant Kimi K3 dans Codex Harness. La vidéo a été réalisée et montée avec Kimi K3 et Cua pour l'utilisation sur ordinateur.

Ceci est un guide de construction pour Agentic Stack Desktop, depuis votre première importation jusqu'à un flux de travail où un agent peut retrouver une décision antérieure, la vérifier par rapport au code actuel, apporter une modification limitée, et laisser quelque chose d'utile derrière lui.

Voici ce que vous allez obtenir :

1. Les fondations : ce qui survit lorsque vous changez d'outils
2. Le chemin le plus rapide : construire un espace de travail que vous pouvez évaluer
3. La configuration de travail : séparer l'investigation de l'implémentation
4. L'exercice du projet : traiter un bogue récurrent à travers tout le cycle
5. La couche partagée : intégrer la récupération dans vos autres outils
6. La couche durable : ce qui mérite de devenir une leçon
7. Les règles de fonctionnement : concises, limitées, inspectables
8. La construction personnalisée : modifier l'espace de travail autour d'un point de friction réel
9. La mise à l'échelle : ajouter une couverture là où le cycle précédent a exposé une lacune
10. La fiche de construction

1. Les fondations : ce qui survit lorsque vous changez d'outils

Imaginez que vous avez passé un après-midi à choisir comment une fonctionnalité devrait fonctionner. Vous avez exploré des alternatives, trouvé une contrainte, rejeté la solution évidente, et finalement atterri sur quelque chose qui convient.

L'implémentation est validée. L'explication reste dans une conversation.

Une semaine plus tard, un autre agent regarde le code et propose la même approche que vous aviez déjà rejetée. C'est peut-être même une suggestion raisonnable compte tenu des informations dont il dispose. Ce qui manque, c'est la discussion qui vous a fait choisir différemment.

Rendez le raisonnement récupérable

Commencez ici : rendez cette discussion récupérable, puis faites en sorte que le prochain agent la vérifie avant d'agir.

Agentic Stack fournit un espace de travail macOS natif avec un historique consultable et sélectionné provenant de Claude Code, Codex, OpenCode et Cursor. Claude Code et Codex s'exécutent également via leurs CLI officielles ; Cursor et OpenCode fournissent actuellement uniquement le contexte. Aperçu du dépôt

Le flux de travail ci-dessous est la façon dont j'utiliserais ces capacités. Les briefs, la répartition des responsabilités et l'exercice du projet sont des pratiques opérationnelles suggérées que vous pouvez adapter.

2. Le chemin le plus rapide : construire un espace de travail que vous pouvez évaluer

Commencez avec un dépôt que vous comprenez. Choisissez quelque chose dont vous connaissez les fichiers importants, dont vous vous souvenez d'une décision récente, et où vous pouvez reconnaître une mauvaise recommandation.

Un projet familier vous donne un point de référence. Si vous commencez avec un code inconnu et un historique inconnu, vous essaierez de valider l'outil et d'apprendre le système en même temps.

Pour une construction à partir des sources, les exigences documentées incluent macOS 14+, Python 3.10+, les outils en ligne de commande Xcode et une chaîne d'outils Swift 6. Installez et connectez-vous à la CLI de codage que vous souhaitez exécuter. Exigences

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

Ouvrez votre dépôt dans l'application et terminez la configuration guidée. Il s'agit d'un aperçu avec une signature ad hoc, donc macOS peut demander une confirmation au premier lancement. Configuration

Définissez la première vérification d'acceptation

Avant d'importer quoi que ce soit, notez la question à laquelle vous voulez que le premier agent réponde. Quelque chose comme : pourquoi notre tâche d'exportation traite-t-elle les enregistrements par lots, et l'implémentation actuelle a-t-elle encore besoin de cette limite ?

Cette question devient votre première vérification d'acceptation. Vous recherchez la bonne décision, le bon code de support, et une explication honnête de tout ce que l'agent ne peut pas établir.

2.1 La première importation : donnez-lui une décision qui vaut la peine d'être trouvée

Ouvrez Knowledge Graph → Graph → Import memory, prévisualisez les sources, et sélectionnez le matériel que vous souhaitez inclure.

Le graphique utilise la recherche en texte intégral SQLite, avec des connexions basées sur les sujets, les liens vers le dépôt et la provenance ; les magasins de chat d'origine restent inchangés. Comportement d'importation

Je commencerais par une conversation terminée contenant une décision dont vous vous souvenez. Surtout une où vous avez rejeté quelque chose d'attrayant à cause d'une contrainte qui ne serait pas évidente à partir du code final.

Recherchez cette décision après l'importation. Ouvrez le résultat et inspectez la source. Assurez-vous de regarder la conversation que vous aviez l'intention d'importer, avec suffisamment d'explications contextuelles pour comprendre ce qui s'est passé.

Testez si vous pouvez la retrouver

Ensuite, essayez une deuxième recherche en utilisant le vocabulaire que vous utiliseriez naturellement le mois prochain. Vous vous souvenez peut-être du nom de la fonctionnalité alors que la conversation utilisait un nom de module interne. Trouver ce décalage maintenant vous aide à comprendre comment récupérer le matériel plus tard.

Je garderais la première collection suffisamment petite pour pouvoir l'inspecter manuellement. Une réponse correcte provenant d'une source connue est une preuve utile que le flux de travail fonctionne.

Un nombre d'importations élevé vous indique la quantité de matériel entré dans le système, tout en laissant son utilité à tester.

Développez la collection lorsqu'une autre tâche vous en donne une raison.

2.2 La première session de travail : faites en sorte que l'expérience soit suffisamment petite pour être terminée

Je donnerais à la configuration initiale une ligne d'arrivée avant d'ouvrir un autre écran de configuration. À la fin de la session, vous devriez avoir récupéré une décision connue, l'avoir vérifiée par rapport au dépôt, et avoir produit une révision que vous pouvez expliquer à quelqu'un d'autre.

Choisissez un exemple avec une limite étroite. Un seul comportement d'exportation est plus facile à inspecter que l'ensemble de la plateforme de données. Un choix antérieur concernant un composant est plus facile à vérifier qu'une question large sur la qualité de l'architecture.

Gardez une courte note à côté de l'exercice : la question, la source attendue, l'implémentation actuelle, et la partie qui nécessite un jugement. C'est votre référence pour évaluer la réponse.

Diagnostiquez le bon échec

• Si le réviseur récupère la mauvaise conversation, travaillez sur la récupération.
• S'il trouve la bonne conversation mais interprète mal le code, travaillez sur l'investigation.
• Si les conclusions sont solides mais que l'implémentation ne répond pas à l'exigence, améliorez la transmission.

Cette séparation est importante car chaque échec demande une correction différente. Ajouter plus de mémoire ne corrigera pas nécessairement un brief peu clair, et réécrire le brief ne récupérera pas une source qui n'a jamais été importée.

Terminez le cycle complet le plus petit, enregistrez ce qui a échoué, et utilisez cette preuve pour choisir la prochaine amélioration.

3. La configuration de travail : séparer l'investigation de l'implémentation

Ma première configuration suggérée comprend un réviseur en lecture seule et un implémenteur ayant accès à l'édition du projet. Donnez à chacun un livrable clair, et faites en sorte que la transmission soit quelque chose que vous puissiez lire avant que tout changement ne commence.

Les profils d'agent prennent en charge un exécuteur, un modèle, un effort, des instructions et un accès aux fichiers. Les conversations appartiennent à des projets, et les suivis reprennent leurs sessions CLI sous-jacentes. Modèle de conversation

1. Agent 1 : le réviseur reçoit la première question : qu'avons-nous décidé, que fait le code maintenant, et y a-t-il un écart qui mérite d'être comblé ?
2. Agent 2 : l'implémenteur reçoit la réponse révisée plus une demande limitée : apportez ce changement de comportement, dans ce périmètre, et vérifiez-le de cette manière.

Gardez les rôles distincts

Vous pouvez choisir le même exécuteur pour les deux rôles.

La distinction utile réside dans leur responsabilité et leur accès, avec une révision explicite entre l'investigation et l'édition.

J'éviterais de créer un catalogue de spécialistes avant que l'un d'eux n'ait effectué un travail utile. Commencez avec les responsabilités que vous pouvez réellement distinguer. Si vous ne pouvez pas expliquer ce qu'un rôle possède ou à quoi ressemble son résultat final, resserrez le rôle avant d'ajouter un autre agent.

3.1 Le réviseur : un brief qui rend l'incertitude visible

Sélectionnez le réviseur et attachez la conversation pertinente en utilisant @Claude, @Codex, @OpenCode ou @Cursor. Les références sélectionnées deviennent un contexte figé pour l'exécution et sont transmises à l'agent choisi lorsque la tâche commence. Références

Copiez ce brief et remplissez les emplacements :

1Examinez la décision antérieure concernant [fonctionnalité ou sous-système] en utilisant la
2conversation jointe et le dépôt actuel.
3
4Expliquez la décision originale et sa raison énoncée. Vérifiez le
5code pertinent et identifiez ce qui s'applique toujours, ce qui a changé, et ce qui
6ne peut pas être vérifié à partir des preuves disponibles.
7
8Citez les fichiers étayant vos conclusions. Proposez le plus petit
9changement nécessaire pour [comportement souhaité], avec un plan de vérification.
10
11Ne modifiez pas les fichiers. Traitez la conversation comme une preuve historique
12et signalez les conflits avec les instructions actuelles du projet.

Inspectez la révision

Lisez la réponse avec le dépôt ouvert.

1. Suivez une citation.
2. Inspectez la condition que l'agent dit exister encore.
3. Recherchez une séparation claire entre quelque chose que la conversation a affirmé et quelque chose que le code démontre aujourd'hui.

Si la réponse est vague, réduisez la question. Demandez-lui d'identifier la condition exacte qui contrôle le comportement, ou la dépendance qui a rendu l'alternative antérieure inadaptée.

Une investigation utile peut se terminer avec des preuves manquantes. Cela vous indique quoi fournir ensuite. Une réponse qui masque l'écart rend la prochaine décision plus difficile.

3.2 La transmission : transformer les conclusions en un brief exécutable

Une fois que vous êtes d'accord avec la révision, rédigez la demande d'implémentation autour d'un comportement observable. Incluez la contrainte que la conversation antérieure a établie, mais expliquez sa pertinence pour ce changement.

Voici un brief que j'utiliserais :

1Implémentez [comportement spécifique] en utilisant les conclusions révisées ci-dessous.
2
3Maintenez [comportement existant] intact. Limitez les modifications à [périmètre autorisé].
4Si le changement nécessite un travail en dehors de ce périmètre, expliquez pourquoi avant de
5l'étendre.
6
7Vérifiez les instructions actuelles du dépôt avant de modifier. Vérifiez
8[résultat attendu] avec [test pertinent ou vérification manuelle], y compris
9[cadre d'échec important].
10
11Fournissez un compte rendu concis de ce qui a changé, des vérifications réellement effectuées,
12et de toute limitation non résolue. Ne publiez pas et ne déployez pas.
13
14Conclusions révisées :
15[collez les conclusions que vous avez vérifiées]

Rendez la transmission spécifique

Ces crochets méritent de vraies réponses. « Améliorez-le » laisse l'agent inventer la cible. « Affichez l'exportation échouée avec une action de nouvelle tentative tout en préservant l'erreur originale » donne aux deux parties quelque chose de concret à inspecter.

Gardez la conclusion révisée proche de la tâche. Si la contrainte importante est enfouie dans une longue transcription, explicitez-la dans le brief et joignez la conversation de support.

La source explique d'où vient la contrainte. Votre demande actuelle explique comment elle régit le travail d'aujourd'hui.

4. L'exercice du projet : traiter un bogue récurrent à travers tout le cycle

Voici un exercice hypothétique pour concrétiser le flux de travail. Imaginez que votre projet crée occasionnellement des exportations en double après une interruption réseau, et qu'une conversation plus ancienne contient une investigation sur le comportement de nouvelle tentative.

1. Étape 1 : Tout d'abord, récupérez cette conversation. Demandez au réviseur d'identifier ce que l'investigation antérieure a établi, puis vérifiez le chemin de nouvelle tentative actuel par rapport à cela.
2. Étape 2 : Supposons que l'ancienne discussion indique que les requêtes peuvent être répétées après une réponse incertaine. Le réviseur doit établir si l'implémentation actuelle permet encore cela, quel code le contrôle, et s'il existe déjà un mécanisme destiné à empêcher les doublons.
3. Étape 3 : Si les preuves soutiennent un changement, briefez l'implémenteur autour du cas d'échec. Spécifiez ce qu'une requête répétée devrait faire, quel comportement d'exportation existant doit rester, et comment vous vérifierez une réponse interrompue.
4. Étape 4 : Ensuite, inspectez le changement et exécutez le chemin pertinent. Vérifiez à la fois l'exportation réussie et la nouvelle tentative après incertitude. Si l'environnement ne peut pas reproduire l'interruption, enregistrez cette limitation et décidez quelle vérification supplémentaire est nécessaire.
5. Étape 5 : Enfin, examinez la leçon que vous pourriez retenir : les conditions qui ont causé le doublon, le mécanisme qui y remédie, et les preuves étayant le correctif.

Cet exemple est un exercice proposé, pas une affirmation concernant un bogue dans Agentic Stack. Remplacez-le par un échec réel de votre propre projet et conservez la même séquence.

5. La couche partagée : intégrer la récupération dans vos autres outils

Le bureau peut installer l'intégration via Tools → Connections → Use @ in tools → Enable in all four tools. La commande équivalente est :

1agentic-stack context install

Redémarrez les outils par la suite. L'entrée MCP expose la recherche de conversation, la lecture de chat sélectionné et la recherche de mémoire partagée. Intégration

Le comportement du sélecteur dépend du client ; lorsque la complétion de ressource n'est pas disponible, l'agent peut rechercher et présenter les conversations correspondantes. Comportement du client

Testez la continuité entre les outils

Ma première vérification serait de demander à un autre outil de trouver la même décision que vous venez de réviser. Donnez-lui le sujet, demandez-lui de présenter la source correspondante, et confirmez la sélection avant de demander une analyse.

Comparez ensuite le résultat avec la source que vous avez inspectée dans le bureau. Vous testez la continuité du contexte entre les outils, alors gardez la question stable tout en changeant l'endroit où vous la posez.

J'inclurais également la source dans le brief de la tâche finale chaque fois qu'une décision affecte matériellement le travail. « Nous avons discuté de cela auparavant » donne à l'agent un problème de recherche. « Utilisez cette conversation révisée et vérifiez cette condition » lui donne une responsabilité spécifique.

6. La couche durable : ce qui mérite de devenir une leçon

La récupération ramène l'ancien matériel à la vue. Vous devez toujours décider quelle autorité ce matériel doit porter.

Une conversation peut contenir un plan abandonné, un diagnostic incorrect, ou une réponse qui était raisonnable avant que le projet ne change. La préserver vous permet d'inspecter le raisonnement plus tard ; accepter une leçon est une décision distincte.

Tasks contient les enregistrements d'exécution. Knowledge → Lessons prend en charge la mise en attente, l'acceptation, le rejet et la révision des leçons avec des raisons, tandis que l'historique importé reste séparé des leçons acceptées. Cycle de vie de la révision

Rédigez une leçon que vous pouvez contester

Je rédigerais une leçon proposée avec suffisamment de détails pour être contestée : la condition à laquelle elle s'applique, le comportement qu'elle recommande, la raison et les preuves.

Pour le bogue d'exportation hypothétique, « toujours réessayer en toute sécurité » est trop vague pour être utile. Une note utile identifie ce qui rend une nouvelle tentative incertaine et comment l'implémentation de ce projet devrait reconnaître le travail répété.

Demandez ensuite ce qui rendrait la leçon obsolète. Un backend différent, un contrat modifié ou un sous-système remplacé pourrait supprimer la contrainte d'origine. Incluez cette limite afin que la future révision ait un point de départ.

C'est ainsi que je garderais une correction utile de devenir une règle qui survit à sa raison d'être.

6.1 La structure de la mémoire : placez chaque type de connaissance à sa place

Sous le bureau, l'architecture portable .agent/ sépare l'état de travail, les épisodes antérieurs, les modèles durables et les préférences personnelles. Les compétences fournissent des procédures réutilisables, tandis que les protocoles décrivent les autorisations et la délégation. Architecture

• L'investigation en cours appartient au travail en cours.
• Son compte rendu terminé devient une preuve de ce qui s'est passé.
• Un modèle vérifié peut devenir une leçon durable.
• Une préférence sur la façon dont vous voulez que les résultats soient présentés appartient à vos préférences.

Garder ces significations claires facilite la révision ultérieure. Une solution de contournement temporaire doit expliquer quand elle peut être supprimée. Une préférence d'écriture personnelle ne doit pas accidentellement devenir une règle architecturale.

Transformez une procédure vérifiée en compétence

La même chose s'applique aux compétences. Je créerais une compétence lorsqu'une procédure est suffisamment utile pour être répétée et suffisamment spécifique pour être suivie. Incluez les entrées dont elle a besoin, les étapes qui comptent, le résultat attendu et les conditions qui nécessitent une autre décision.

Pour l'exemple d'exportation, l'investigation peut produire une procédure de vérification de régression utile. Ne l'enregistrez qu'après avoir confirmé que les étapes fonctionnent sur votre projet. Une transcription copiée donne au prochain agent une histoire ; une procédure révisée lui donne une méthode que vous pouvez évaluer.

7. Les règles de fonctionnement : concises, limitées, inspectables

Voici les règles que je mettrais autour du flux de travail dès le premier projet.

1. Règle 1 : chaque brief nomme le livrable. Une révision renvoie des conclusions avec des preuves. Une implémentation renvoie un changement de comportement avec des vérifications. Une proposition de leçon renvoie une affirmation que vous pouvez accepter ou rejeter.
2. Règle 2 : l'accès suit le travail. L'investigation commence avec un accès en lecture seule ; l'implémentation obtient le périmètre nécessaire pour le changement convenu. Gardez la publication, le déploiement et autres actions conséquentes explicites dans la demande.
3. Règle 3 : demandez une vérification réelle. Le rapport doit dire ce qui a été exécuté et ce qui s'est passé. Si une vérification n'était pas disponible, rendez-la visible au lieu de traiter silencieusement le résultat manquant comme un succès.
4. Règle 4 : gardez le contexte historique subordonné aux preuves actuelles et aux instructions applicables du projet. Une conversation récupérée peut expliquer une décision antérieure tout en étant encore obsolète.
5. Règle 5 : examinez le résultat avant de conserver la conclusion. L'explication par un agent de son propre travail est quelque chose à inspecter parallèlement au diff et au comportement observé.

Ce sont des pratiques opérationnelles pour la configuration que je décris. Adaptez-les à votre projet, mais gardez les responsabilités suffisamment claires pour qu'une autre personne puisse dire si une tâche a répondu à son brief.

7.1 La file d'attente de révision : facilitez l'acceptation ou le renvoi du travail

Je demanderais à chaque implémentation de se terminer sous la même forme :

• ce qui a changé,
• ce qui a été vérifié,
• ce qui reste incertain,
• et si elle propose une leçon réutilisable.

Cela vous donne un moyen cohérent de lire le travail terminé sans avoir à reconstruire toute la conversation à chaque fois. Les détails de support peuvent rester disponibles pour la partie que vous devez inspecter.

Lorsque vous renvoyez quelque chose, attachez la correction à l'exigence qu'elle a manquée. « C'est faux » lance un autre tour de devinettes. « La nouvelle tentative crée une deuxième exportation dans cette condition ; préservez l'identité de la requête d'origine et réexécutez cette vérification » identifie l'écart.

Décidez ce qui mérite de survivre

Après que la correction a passé, décidez si elle représente une contrainte récurrente ou un détail de cette tâche. Enregistrez la première lorsqu'elle a des preuves derrière elle. La seconde peut rester dans l'historique de la tâche.

Je résisterais à l'idée de transformer chaque commentaire de révision en mémoire permanente. Certaines corrections sont utiles une fois. D'autres révèlent une règle qui devrait façonner le travail ultérieur. Faire cette distinction fait partie de la maintenance du système.

La question utile à la fin d'une révision est : que devrait savoir un futur agent avant de tenter une tâche similaire, et où peut-il vérifier cette connaissance ?

7.2 La discipline de coût : donnez à chaque exécution une condition d'arrêt

J'inclurais une condition d'arrêt dans toute tâche qui pourrait continuer à s'étendre. Pour une révision, cela pourrait être un compte rendu écrit du comportement pertinent et des questions non résolues. Pour une implémentation, cela pourrait être le changement convenu réussissant ses vérifications nommées.

Si l'agent découvre un problème plus vaste, demandez-lui d'expliquer la conclusion et sa relation avec la tâche d'origine avant d'absorber ce travail dans le changement actuel.

Décidez si cela appartient à la tâche actuelle.

Comparez les résultats et appliquez les limites

Choisissez l'exécuteur et le modèle en utilisant les options réellement disponibles dans votre compte, puis jugez-les sur vos propres exemples limités. Je comparerais la qualité des conclusions, les corrections requises et la vérification fournie avant de faire d'une configuration la valeur par défaut.

Gardez l'expérience équitable en maintenant la tâche et le matériel source stables. Si chaque essai change la question, le contexte et les critères d'acceptation, la comparaison sera difficile à interpréter.

Et mettez tous les contrôles de dépenses là où ils sont réellement appliqués par vos outils ou votre fournisseur. Une phrase demandant à un agent d'être économique est une préférence ; inspectez les contrôles disponibles avant de vous fier à une limite.

8. La construction personnalisée : modifier l'espace de travail autour d'un point de friction réel

Une fois que vous avez terminé le cycle de base, vous aurez une meilleure idée de ce que vous voulez du bureau lui-même. Peut-être qu'une étape de navigation répétée vous dérange, ou qu'une vue de tâche rend un champ plus difficile à inspecter qu'il ne le devrait.

Notez la friction avant de proposer une fonctionnalité. Décrivez l'action que vous essayez d'effectuer, où vous perdez du temps, et ce que le comportement amélioré vous permettrait de faire.

Ouvrez ensuite le dépôt source et donnez à votre agent une demande de changement limitée. Incluez comment vous avez l'intention d'inspecter le résultat dans l'application.

Construisez et inspectez le changement

Le dépôt documente ces commandes de développement et d'empaquetage :

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

Commandes de développement

Les modifications SwiftUI nécessitent une reconstruction et un redémarrage pour être inspectées. Flux de travail du bureau

Je testerais l'interaction qui a motivé le changement et un cas voisin qui pourrait casser. Si vous améliorez le filtrage des tâches, inspectez les résultats filtrés, un ensemble de résultats vide, et le chemin de retour vers la liste complète.

Utilisez la même norme que vous avez appliquée à l'exercice d'exportation : un avant concret, un changement limité, et un après observé.

8.1 L'option à distance : décidez où le travail doit vivre

Une fois que le flux de travail local fonctionne, vous voudrez peut-être une exécution sur un serveur persistant. Le chemin d'auto-hébergement connecte l'application native à un service mono-propriétaire qui possède ses projets, sa mémoire, son historique de tâches et ses connexions CLI ; changer d'hôte ne transfère pas automatiquement les données ou les identifiants de votre Mac. Guide d'hébergement

Je ferais ce changement pour une raison concrète, comme garder un projet et son environnement d'exécution sur une machine que vous gérez déjà. Notez cette raison avant d'entreprendre le travail de déploiement.

Suivez le guide d'hébergement pour la configuration prise en charge, les étapes d'authentification et de vérification. Traitez le serveur comme un autre environnement de travail avec son propre état à inspecter.

vérifiez l'environnement sélectionné

Ensuite, répétez-y une tâche familière. Vérifiez le projet sélectionné, confirmez que l'agent peut accéder à la source prévue, et vérifiez que le résultat appartient à l'environnement serveur que vous avez choisi.

Utiliser une tâche connue facilite l'évaluation de la transition. Si vous changez l'hôte, le projet et le flux de travail simultanément, il devient plus difficile d'identifier quel changement a provoqué un résultat surprenant.

Le local suffit pour apprendre le modèle de base. Développez l'infrastructure lorsque le travail vous en donne une raison.

9. passage à l'échelle : ajoutez une couverture là où le cycle précédent a révélé une lacune

Je développerais cette configuration en fonction du contexte manquant que vous rencontrez lors de tâches réelles.

• si une révision nécessitait une discussion d'architecture antérieure, importez cette discussion.
• si l'implémentation nécessitait à plusieurs reprises la même procédure, développez et vérifiez une compétence.
• si une décision est constamment rouverte, rédigez une leçon ciblée avec les preuves qui la soutiennent.

Conservez une petite collection de questions dont vous connaissez déjà les réponses. Utilisez-les après avoir modifié vos importations ou votre flux de travail : trouvez cette décision, expliquez cette contrainte, identifiez le code qui l'implémente, et signalez la partie qui n'est plus d'actualité.

Développez lorsque le travail le justifie

Je n'ajouterais un autre rôle d'agent que lorsque sa responsabilité est clairement définie par le travail. Une révision documentaire récurrente peut justifier un briefing dédié. Une demande ponctuelle peut très bien convenir à un rôle existant.

Développez les parties qui ont gagné leur place. Gardez le reste suffisamment simple pour comprendre ce qui ne va pas.

9.1 l'habitude de maintenance : révisez les connaissances lorsque le système change

Je réviserais les leçons pertinentes chaque fois qu'un sous-système change suffisamment pour modifier leurs hypothèses. Utilisez le changement lui-même comme déclencheur : une nouvelle dépendance, une couche de stockage remplacée, un environnement de déploiement différent, ou une exigence produit révisée.

Demandez quelles leçons existantes dépendent de l'ancien comportement, puis inspectez ces sources parallèlement au changement. Conservez ce qui tient toujours, révisez ce qui nécessite un champ d'application plus restreint, et retirez ce qui ne s'applique plus via le flux de travail de révision disponible.

L'important est de préserver l'explication. Un futur constructeur doit pouvoir comprendre pourquoi la règle précédente existait et ce qui a suffisamment changé pour la remplacer.

Actualisez les procédures et résolvez les conflits

Pour les compétences, exécutez à nouveau la procédure après un changement qui affecte ses entrées ou ses commandes. Si une étape ne fonctionne plus, mettez à jour la procédure en fonction de l'échec observé et répétez la vérification pertinente.

Cela maintient la maintenance connectée aux événements réels du projet. Vous révisez les connaissances les plus susceptibles d'être devenues obsolètes, avec des preuves actuelles déjà sous vos yeux.

Lorsqu'une tâche révèle des notes contradictoires, faites de la résolution de ce conflit une partie de la révision. Identifiez quelle déclaration s'applique à la version actuelle, et laissez le résultat suffisamment clair pour que le prochain agent puisse suivre le raisonnement sans répéter toute l'investigation.

Laissez une passation utile

Avant la prochaine session, laissez une courte passation décrivant le résultat vérifié, la question ouverte, et la source qu'un autre agent devrait lire en premier. Restez spécifique à l'état du projet que vous avez réellement inspecté.

Cela donne au travail de demain un point de départ traçable, surtout lorsque vous revenez via un outil différent ou après une absence, avec le raisonnement original toujours disponible.

10. la fiche de construction

1. choisissez un dépôt familier et une décision que vous pouvez reconnaître.
2. construisez le bureau, terminez la configuration et importez une conversation terminée contenant cette décision.
3. recherchez-la, inspectez la source et attachez-la à une révision en lecture seule du code actuel.
4. vérifiez vous-même les résultats, puis briefez une implémentation délimitée avec une condition d'acceptation visible.
5. inspectez le diff et exécutez la vérification pertinente, y compris le cas d'échec qui a motivé le travail.
6. rédigez une leçon uniquement lorsque le résultat la soutient, avec la portée et la raison enregistrées.
7. transformez une procédure en compétence lorsque vous avez vérifié qu'elle mérite d'être répétée.
8. essayez la même récupération depuis un autre outil, puis développez votre contexte ou votre infrastructure lorsqu'une tâche réelle l'exige.

commencez par une décision cette semaine, et menez-la à travers tout le cycle avant d'importer tout votre historique.

Le prochain agent doit hériter de votre jugement.