A Stack de Memória para Agentes de IA que Todos Devem Usar em 2026 (Guia do Desenvolvedor)

Seu modelo e sua estrutura não importam mais.

o que importa mais é.....

seu contexto pessoal/memória compartilhada que sim

Introdução

vou te mostrar como construir uma memória compartilhada para seus agentes de codificação... para que a próxima ferramenta possa encontrar as decisões que você já tomou.

a conversa sobre arquitetura no Claude, a sessão de depuração no Codex, a explicação enterrada no Cursor... trabalho útil que ainda deveria estar disponível quando você muda de ferramentas, inicia outra sessão ou volta ao projeto depois de um mês.

TLDR; se você não quer ler todas as 3.845 palavras, apenas dê este repositório GitHub para seu agente ➡️ https://github.com/codejunkie99/agentic-stack-desktop

construí tudo isso usando Kimi K3 no Codex Harness. O vídeo foi feito e editado usando Kimi K3 com Cua para Computer Use

este é um guia prático para o agentic stack desktop, desde sua primeira importação até um fluxo de trabalho onde um agente pode recuperar uma decisão anterior, verificá-la com o código atual, fazer uma alteração delimitada e deixar algo útil para trás.

aqui está o que você vai receber:

1. a base: o que sobrevive quando você troca de ferramentas
2. o caminho mais rápido: construa um espaço de trabalho que você possa avaliar
3. a configuração funcional: separe investigação de implementação
4. o exercício do projeto: pegue um bug recorrente e passe por todo o ciclo
5. a camada compartilhada: traga a recuperação para suas outras ferramentas
6. a camada durável: o que merece se tornar uma lição
7. as regras operacionais: breves, delimitadas, inspecionáveis
8. a construção personalizada: mude o espaço de trabalho em torno de um ponto de atrito real
9. escalando: adicione cobertura onde o ciclo anterior expôs uma lacuna
10. a ficha técnica

1. a base: o que sobrevive quando você troca de ferramentas

imagine que você passou uma tarde escolhendo como um recurso deveria funcionar. você explorou alternativas, encontrou uma restrição, rejeitou a solução óbvia e finalmente chegou a algo que se encaixa.

a implementação é commitada. a explicação fica em uma conversa.

uma semana depois, outro agente olha para o código e propõe a mesma abordagem que você já havia rejeitado. pode até ser uma sugestão razoável com base nas informações disponíveis para ele. a peça que falta é a discussão que te fez escolher de forma diferente.

torne o raciocínio recuperável

comece aqui: torne essa discussão recuperável, então faça o próximo agente verificá-la antes de agir.

o agentic stack fornece um espaço de trabalho nativo para macOS com histórico pesquisável e selecionado do Claude Code, Codex, OpenCode e Cursor. Claude Code e Codex também executam através de suas CLIs oficiais; Cursor e OpenCode atualmente fornecem apenas contexto. visão geral do repositório

o fluxo de trabalho abaixo é como eu usaria essas capacidades. os briefs, a divisão de responsabilidades e o exercício do projeto são práticas operacionais sugeridas que você pode adaptar.

2. o caminho mais rápido: construa um espaço de trabalho que você possa avaliar

comece com um repositório que você entende. escolha algo onde você conhece os arquivos importantes, lembra de uma decisão recente e consegue reconhecer uma recomendação ruim.

um projeto familiar te dá um ponto de referência. se você começar com código desconhecido e histórico desconhecido, estará tentando validar a ferramenta e aprender o sistema ao mesmo tempo.

para uma compilação a partir da fonte, os requisitos documentados incluem macOS 14+, Python 3.10+, Xcode Command Line Tools e um toolchain Swift 6. instale e faça login na CLI de codificação que você deseja executar. requisitos

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

abra seu repositório no aplicativo e conclua a configuração guiada. esta é uma prévia com assinatura ad hoc, então o macOS pode exigir confirmação no primeiro lançamento. configuração

defina a primeira verificação de aceitação

antes de importar qualquer coisa, escreva a pergunta que você quer que o primeiro agente responda. algo como: por que nosso job de exportação processa registros em lotes, e a implementação atual ainda precisa desse limite?

essa pergunta se torna sua primeira verificação de aceitação. você está procurando a decisão correta, o código de suporte correto e uma explicação honesta de tudo o que o agente não puder estabelecer.

2.1 a primeira importação: dê a ela uma decisão que valha a pena encontrar

Abra Knowledge Graph → Graph → Import memory, visualize as fontes e selecione o material que deseja incluir.

o gráfico usa pesquisa de texto completo do SQLite, com conexões baseadas em tópicos, links de repositório e proveniência; os armazenamentos de chat originais permanecem inalterados. comportamento de importação

eu começaria com uma conversa concluída contendo uma decisão que você lembra. especialmente uma onde você rejeitou algo atraente por causa de uma restrição que não seria óbvia a partir do código final.

pesquise por essa decisão após a importação. abra o resultado e inspecione a fonte. certifique-se de que está olhando para a conversa que você pretendia trazer, com explicação contextual suficiente para entender o que aconteceu.

teste se você consegue encontrá-la novamente

então tente uma segunda pesquisa usando o vocabulário que você naturalmente usaria no próximo mês. você pode lembrar do nome do recurso enquanto a conversa usava um nome de módulo interno. encontrar essa incompatibilidade agora ajuda você a entender como recuperar o material mais tarde.

eu manteria a primeira coleção pequena o suficiente para inspecionar manualmente. uma resposta correta de uma fonte conhecida é uma evidência útil de que o fluxo de trabalho funciona.

um grande número de importações informa quanto material entrou no sistema, deixando sua utilidade para ser testada.

expanda a coleção quando outra tarefa te der um motivo para isso.

2.2 a primeira sessão de trabalho: torne o experimento pequeno o suficiente para terminar

eu daria à configuração inicial uma linha de chegada antes de abrir outra tela de configuração. ao final da sessão, você deve ter recuperado uma decisão conhecida, verificado-a com o repositório e produzido uma revisão que você pode explicar para outra pessoa.

escolha um exemplo com um limite estreito. um único comportamento de exportação é mais fácil de inspecionar do que toda a plataforma de dados. uma escolha anterior sobre um componente é mais fácil de verificar do que uma pergunta ampla sobre se a arquitetura é boa.

mantenha uma pequena nota ao lado do exercício: a pergunta, a fonte esperada, a implementação atual e a parte que precisa de julgamento. esta é sua referência para avaliar a resposta.

diagnostique a falha correta

• se o revisor recuperar a conversa errada, trabalhe na recuperação.
• se ele encontrar a conversa certa, mas interpretar mal o código, trabalhe na investigação.
• se as conclusões forem sólidas, mas a implementação perder o requisito, melhore o handoff.

essa separação é importante porque cada falha pede uma correção diferente. adicionar mais memória não vai necessariamente corrigir um brief pouco claro, e reescrever o brief não vai recuperar uma fonte que nunca foi importada.

termine o menor ciclo completo, registre o que falhou e use essa evidência para escolher a próxima melhoria.

3. a configuração funcional: separe investigação de implementação

minha primeira configuração sugerida tem um revisor somente leitura e um implementador com acesso de edição ao projeto. dê a cada um uma entrega clara e torne o handoff algo que você possa ler antes que qualquer alteração comece.

os perfis de agente suportam um runner, modelo, esforço, instruções e acesso a arquivos. as conversas pertencem a projetos, e os follow-ups retomam suas sessões CLI subjacentes. modelo de conversa

1. agente 1: o revisor recebe a primeira pergunta: o que decidimos, o que o código faz agora e há uma lacuna que vale a pena abordar?
2. agente 2: o implementador recebe a resposta revisada mais uma solicitação delimitada: faça essa mudança de comportamento, neste escopo, e verifique-a desta forma.

mantenha os papéis distintos

você pode escolher o mesmo runner para ambos os papéis.

a distinção útil está em sua responsabilidade e acesso, com uma revisão explícita entre investigação e edição.

eu evitaria criar um catálogo de especialistas antes que qualquer um deles tenha concluído um trabalho útil. comece com as responsabilidades que você realmente consegue distinguir. se você não consegue explicar o que um papel possui ou como é sua saída finalizada, aperte o papel antes de adicionar outro agente.

3.1 o revisor: um brief que torne a incerteza visível

selecione o revisor e anexe a conversa relevante usando @Claude, @Codex, @OpenCode ou @Cursor. as referências selecionadas se tornam contexto congelado para a execução e vão para o agente escolhido quando a tarefa começa. referências

copie este brief e preencha os campos:

1Revise a decisão anterior sobre [recurso ou subsistema] usando a
2conversa anexada e o repositório atual.
3
4Explique a decisão original e sua razão declarada. Verifique o
5código relevante e identifique o que ainda se aplica, o que mudou
6e o que não pode ser verificado a partir das evidências disponíveis.
7
8Cite os arquivos que suportam suas conclusões. Proponha a menor
9mudança necessária para [comportamento desejado], com um plano de
10verificação.
11
12Não edite arquivos. Trate a conversa como evidência histórica
13e sinalize conflitos com as instruções atuais do projeto.

inspecione a revisão

leia a resposta com o repositório aberto.

1. siga uma citação.
2. inspecione a condição que o agente diz que ainda existe.
3. procure uma separação clara entre algo que a conversa afirmou e algo que o código demonstra hoje.

se a resposta for vaga, restrinja a pergunta. peça para identificar a condição exata que controla o comportamento, ou a dependência que tornou a alternativa anterior inadequada.

uma investigação útil pode terminar com evidências faltando. isso te diz o que fornecer em seguida. uma resposta que suaviza a lacuna torna a próxima decisão mais difícil.

3.2 o handoff: transforme descobertas em um brief executável

depois que você concordar com a revisão, escreva a solicitação de implementação em torno do comportamento observável. inclua a restrição que a conversa anterior estabeleceu, mas explique sua relevância para esta mudança.

aqui está um brief que eu usaria:

1Implemente [comportamento específico] usando as descobertas revisadas abaixo.
2
3Mantenha [comportamento existente] intacto. Limite as edições a [escopo permitido].
4Se a mudança exigir trabalho fora desse escopo, explique o porquê antes de
5expandi-lo.
6
7Verifique as instruções atuais do repositório antes de editar. Verifique
8[resultado esperado] com [teste relevante ou verificação manual], incluindo
9[caso de falha importante].
10
11Retorne um relato conciso do que mudou, das verificações realmente executadas
12e de qualquer limitação não resolvida. Não publique ou faça deploy.
13
14Descobertas revisadas:
15[cole as descobertas que você verificou]

torne o handoff específico

aqueles colchetes merecem respostas reais. "melhorar" deixa o agente inventar o alvo. "mostrar a exportação falha com uma ação de repetição, preservando o erro original" dá a ambos algo concreto para inspecionar.

mantenha a descoberta revisada próxima à tarefa. se a restrição importante estiver enterrada dentro de uma longa transcrição, explicite-a no brief e anexe a conversa de suporte.

a fonte explica de onde veio a restrição. sua solicitação atual explica como ela governa o trabalho de hoje.

4. o exercício do projeto: pegue um bug recorrente e passe por todo o ciclo

aqui está um exercício hipotético para tornar o fluxo de trabalho concreto. imagine que seu projeto ocasionalmente cria exportações duplicadas após uma interrupção de rede, e uma conversa mais antiga contém uma investigação sobre o comportamento de repetição.

1. passo 1: primeiro, recupere essa conversa. peça ao revisor para identificar o que a investigação anterior estabeleceu, depois verifique o caminho de repetição atual com base nisso.
2. passo 2: suponha que a discussão antiga diga que as solicitações podem ser repetidas após uma resposta incerta. o revisor deve estabelecer se a implementação atual ainda permite isso, qual código controla isso e se já existe um mecanismo destinado a prevenir duplicatas.
3. passo 3: se as evidências suportarem uma mudança, faça um brief para o implementador em torno do caso de falha. especifique o que uma solicitação repetida deve fazer, qual comportamento de exportação existente deve permanecer e como você verificará uma resposta interrompida.
4. passo 4: então inspecione a mudança e exercite o caminho relevante. verifique tanto a exportação bem-sucedida quanto a repetição após incerteza. se o ambiente não puder reproduzir a interrupção, registre essa limitação e decida qual verificação adicional é necessária.
5. passo 5: finalmente, revise a lição que você pode reter: as condições que causaram a duplicata, o mecanismo que a aborda e as evidências que suportam a correção.

este exemplo é um exercício proposto, não uma afirmação sobre um bug no agentic stack. substitua por uma falha real do seu próprio projeto e mantenha a mesma sequência.

5. a camada compartilhada: traga a recuperação para suas outras ferramentas

o desktop pode instalar a integração através de Tools → Connections → Use @ in tools → Enable in all four tools. o comando equivalente é:

1agentic-stack context install

reinicie as ferramentas depois. a entrada MCP expõe pesquisa de conversas, leitura de chat selecionado e pesquisa de memória compartilhada. integração

o comportamento do seletor depende do cliente; onde a conclusão de recurso não está disponível, o agente pode pesquisar e apresentar conversas correspondentes. comportamento do cliente

teste a continuidade entre ferramentas

minha primeira verificação seria pedir a outra ferramenta para encontrar a mesma decisão que você acabou de revisar. dê a ela o tópico, peça para apresentar a fonte correspondente e confirme a seleção antes de pedir uma análise.

então compare o resultado com a fonte que você inspecionou no desktop. você está testando a continuidade do contexto entre ferramentas, então mantenha a pergunta estável enquanto muda o lugar onde você a faz.

eu também incluiria a fonte no brief da tarefa final sempre que uma decisão afetar materialmente o trabalho. "nós discutimos isso antes" dá ao agente um problema de pesquisa. "use esta conversa revisada e verifique esta condição" dá a ele uma responsabilidade específica.

6. a camada durável: o que merece se tornar uma lição

a recuperação traz material antigo de volta à vista. você ainda tem que decidir que autoridade esse material deve carregar.

uma conversa pode conter um plano abandonado, um diagnóstico incorreto ou uma resposta que era razoável antes do projeto mudar. preservá-la permite que você inspecione o raciocínio mais tarde; aceitar uma lição é uma decisão separada.

Tasks contém registros de execução. Knowledge → Lessons suporta preparar, aceitar, rejeitar e revisitar lições com razões, enquanto o histórico importado permanece separado das lições aceitas. ciclo de vida da revisão

escreva uma lição que você possa desafiar

eu escreveria uma lição proposta com detalhes suficientes para ser desafiada: a condição à qual se aplica, o comportamento que recomenda, a razão e a evidência.

para o bug de exportação hipotético, "sempre repetir com segurança" é muito vago para ajudar. uma nota útil identifica o que torna uma repetição incerta e como a implementação deste projeto deve reconhecer trabalho repetido.

então pergunte o que tornaria a lição obsoleta. um backend diferente, um contrato alterado ou um subsistema substituído podem remover a restrição original. inclua esse limite para que a revisão futura tenha um ponto de partida.

é assim que eu manteria uma correção útil de se tornar uma regra que sobrevive à sua razão.

6.1 a estrutura da memória: coloque cada tipo de conhecimento em seu lugar

abaixo do desktop, a arquitetura portátil .agent/ separa estado de trabalho, episódios anteriores, padrões duráveis e preferências pessoais. skills fornecem procedimentos reutilizáveis, enquanto protocols descrevem permissões e delegação. arquitetura

• a investigação atual pertence ao trabalho em andamento.
• seu relato concluído se torna evidência do que aconteceu.
• um padrão verificado pode se tornar uma lição durável.
• uma preferência sobre como você quer que os resultados sejam apresentados pertence às suas preferências.

manter esses significados claros torna a revisão posterior mais fácil. uma solução alternativa temporária deve explicar quando pode ser removida. uma preferência pessoal de escrita não deve acidentalmente se tornar uma regra arquitetural.

transforme um procedimento verificado em uma skill

o mesmo se aplica a skills. eu criaria uma skill quando um procedimento é útil o suficiente para ser repetido e específico o suficiente para ser seguido. inclua as entradas que precisa, as etapas que importam, a saída esperada e as condições que exigem outra decisão.

para o exemplo de exportação, a investigação pode produzir um procedimento útil de verificação de regressão. salve isso apenas depois de confirmar que as etapas funcionam no seu projeto. uma transcrição copiada dá ao próximo agente uma história; um procedimento revisado dá a ele um método que você pode avaliar.

7. as regras operacionais: breves, delimitadas, inspecionáveis

aqui estão as regras que eu colocaria em torno do fluxo de trabalho desde o primeiro projeto.

1. regra 1: todo brief nomeia a entrega. uma revisão retorna descobertas com evidências. uma implementação retorna uma mudança de comportamento com verificações. uma proposta de lição retorna uma afirmação que você pode aceitar ou rejeitar.
2. regra 2: o acesso segue o trabalho. a investigação começa com acesso somente leitura; a implementação obtém o escopo necessário para a mudança acordada. mantenha publicação, deploy e outras ações consequentes explícitas na solicitação.
3. regra 3: peça verificação real. o relatório deve dizer o que foi executado e o que aconteceu. se uma verificação não estava disponível, torne isso visível em vez de tratar silenciosamente o resultado ausente como sucesso.
4. regra 4: mantenha o contexto histórico subordinado às evidências atuais e às instruções aplicáveis do projeto. uma conversa recuperada pode explicar uma decisão anterior, mas ainda assim estar desatualizada.
5. regra 5: revise o resultado antes de reter a conclusão. uma explicação de um agente sobre seu próprio trabalho é algo a ser inspecionado junto com o diff e o comportamento observado.

estas são práticas operacionais para a configuração que estou descrevendo. ajuste-as ao seu projeto, mas mantenha as responsabilidades claras o suficiente para que outra pessoa possa dizer se uma tarefa cumpriu seu brief.

7.1 a fila de revisão: torne o trabalho fácil de aceitar ou devolver

eu pediria a cada implementação para terminar no mesmo formato:

• o que mudou,
• o que foi verificado,
• o que permanece incerto,
• e se propõe uma lição reutilizável.

isso te dá uma maneira consistente de ler o trabalho concluído sem reconstruir toda a conversa cada vez. o detalhe de suporte pode permanecer disponível para a parte que você precisa inspecionar.

quando você devolver algo, anexe a correção ao requisito que foi perdido. "isso está errado" inicia outra rodada de adivinhação. "a repetição cria uma segunda exportação sob esta condição; preserve a identidade da solicitação original e execute novamente esta verificação" identifica a lacuna.

decida o que merece sobreviver

depois que a correção passar, decida se ela representa uma restrição recorrente ou um detalhe daquela tarefa. salve a primeira quando tiver evidências por trás dela. a última pode ficar no histórico da tarefa.

eu resistiria a transformar cada comentário de revisão em memória permanente. algumas correções são úteis uma vez. outras revelam uma regra que deve moldar o trabalho posterior. fazer essa distinção faz parte da manutenção do sistema.

a pergunta útil ao final de uma revisão é: o que um agente futuro deve saber antes de tentar uma tarefa semelhante, e onde ele pode verificar esse conhecimento?

7.2 a disciplina de custo: dê a cada execução uma condição de parada

eu incluiria uma condição de parada em qualquer tarefa que pudesse continuar se expandindo. para uma revisão, isso pode ser um relato escrito do comportamento relevante e das perguntas não resolvidas. para implementação, pode ser a mudança acordada passando em suas verificações nomeadas.

se o agente descobrir um problema maior, peça a ele para explicar a descoberta e sua relação com a tarefa original antes de absorver esse trabalho na mudança atual.

decida se isso pertence à tarefa atual.

compare resultados e imponha limites

escolha o runner e o modelo usando as opções realmente disponíveis em sua conta, depois julgue-os em seus próprios exemplos delimitados. eu compararia a qualidade das descobertas, as correções necessárias e a verificação entregue antes de tornar uma configuração o padrão.

mantenha o experimento justo, mantendo a tarefa e o material de origem estáveis. se cada tentativa mudar a pergunta, o contexto e os critérios de aceitação, a comparação será difícil de interpretar.

e coloque quaisquer controles de gastos onde eles são realmente aplicados por suas ferramentas ou provedor. uma frase pedindo a um agente para ser econômico é uma preferência; inspecione os controles disponíveis antes de confiar em um limite.

8. a construção personalizada: mude o espaço de trabalho em torno de um ponto de atrito real

depois de concluir o ciclo básico, você terá uma ideia melhor do que deseja do próprio desktop. talvez uma etapa de navegação repetitiva te incomode, ou uma visualização de tarefa torne um campo mais difícil de inspecionar do que deveria.

escreva o atrito antes de propor um recurso. descreva a ação que você está tentando realizar, onde você perde tempo e o que o comportamento melhorado te permitiria fazer.

então abra o repositório de origem e dê ao seu agente uma solicitação de mudança delimitada. inclua como você pretende inspecionar o resultado no aplicativo.

construa e inspecione a mudança

o repositório documenta estes comandos de desenvolvimento e empacotamento:

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

comandos de desenvolvimento

mudanças no SwiftUI exigem uma reconstrução e reinicialização para inspecionar. fluxo de trabalho do desktop

eu testaria a interação que motivou a mudança e um caso próximo que poderia quebrar. se você melhorar a filtragem de tarefas, inspecione os resultados filtrados, um conjunto de resultados vazio e o caminho de volta para a lista completa.

use o mesmo padrão que você aplicou ao exercício de exportação: um antes concreto, uma mudança delimitada e um depois observado.

8.1 a opção remota: decida onde o trabalho deve viver

depois que o fluxo de trabalho local funcionar, você pode querer a execução em um servidor persistente. o caminho de self-hosting conecta o aplicativo nativo a um serviço de proprietário único que possui seus projetos, memória, histórico de tarefas e logins CLI; trocar de host não transfere automaticamente os dados ou credenciais do seu Mac. guia de hospedagem

Eu faria essa mudança por um motivo concreto, como manter um projeto e seu ambiente de execução em uma máquina que você já gerencia. Anote esse motivo antes de assumir o trabalho de implantação.

Siga o guia de hospedagem para as etapas de configuração, autenticação e verificação suportadas. Trate o servidor como outro ambiente de trabalho com seu próprio estado a ser inspecionado.

Verifique o ambiente selecionado

Em seguida, repita uma tarefa familiar lá. Verifique o projeto selecionado, confirme que o agente pode acessar a fonte pretendida e verifique se o resultado pertence ao ambiente de servidor que você escolheu.

Usar uma tarefa conhecida facilita a avaliação da transição. Se você alterar o host, o projeto e o fluxo de trabalho simultaneamente, fica mais difícil identificar qual mudança causou um resultado inesperado.

O ambiente local é suficiente para aprender o padrão central. Expanda a infraestrutura quando o trabalho lhe der um motivo.

9. Escalonamento: adicione cobertura onde o ciclo anterior revelou uma lacuna

Eu expandiria essa configuração com base no contexto ausente que você encontrar durante tarefas reais.

• Se uma revisão precisou de uma discussão de arquitetura anterior, importe essa discussão.
• Se a implementação exigiu repetidamente o mesmo procedimento, desenvolva e verifique uma habilidade.
• Se uma decisão continua sendo reaberta, escreva uma lição com escopo definido e as evidências que a sustentam.

Mantenha uma pequena coleção de perguntas cujas respostas você já conhece. Use-as após alterar suas importações ou fluxo de trabalho: encontre esta decisão, explique esta restrição, identifique o código que a implementa e sinalize a parte que não está mais atualizada.

Expanda quando o trabalho justificar

Eu adicionaria outra função de agente apenas quando sua responsabilidade estiver clara a partir do trabalho. Uma revisão de documentação recorrente pode justificar um briefing dedicado. Uma solicitação pontual pode se encaixar perfeitamente em uma função existente.

Expanda as partes que conquistaram seu lugar. Mantenha o resto simples o suficiente para entender quando algo der errado.

9.1 O hábito de manutenção: revise o conhecimento quando o sistema mudar

Eu revisaria as lições relevantes sempre que um subsistema mudar o suficiente para alterar suas premissas. Use a própria mudança como gatilho: uma nova dependência, uma camada de armazenamento substituída, um ambiente de implantação diferente ou um requisito de produto revisado.

Pergunte quais lições existentes dependem do comportamento antigo, depois inspecione essas fontes junto com a mudança. Mantenha o que ainda é válido, revise o que precisa de um escopo mais restrito e retire o que não se aplica mais por meio do fluxo de trabalho de revisão disponível.

A parte importante é preservar a explicação. Um construtor futuro deve ser capaz de entender por que a regra anterior existia e o que mudou o suficiente para substituí-la.

Atualize procedimentos e resolva conflitos

Para habilidades, execute o procedimento novamente após uma mudança que afete suas entradas ou comandos. Se uma etapa não funcionar mais, atualize o procedimento com base na falha observada e repita a verificação relevante.

Isso mantém a manutenção conectada a eventos reais no projeto. Você está revisando o conhecimento com maior probabilidade de estar desatualizado, com evidências atuais já à sua frente.

Quando uma tarefa revelar anotações conflitantes, torne a resolução desse conflito parte da revisão. Identifique qual declaração se aplica à versão atual e deixe o resultado claro o suficiente para que o próximo agente possa seguir o raciocínio sem repetir toda a investigação.

Deixe uma transição útil

Antes da próxima sessão, deixe uma breve transição descrevendo o resultado verificado, a questão em aberto e a fonte que outro agente deve ler primeiro. Mantenha-a específica para o estado do projeto que você realmente inspecionou.

Isso dá ao trabalho de amanhã um ponto de partida que você pode rastrear, especialmente quando você retornar por meio de uma ferramenta diferente ou após um tempo afastado, com o raciocínio original ainda disponível.

10. A folha de construção

1. Escolha um repositório familiar e uma decisão que você possa reconhecer.
2. Monte o desktop, conclua a configuração e importe uma conversa concluída contendo essa decisão.
3. Pesquise por ela, inspecione a fonte e anexe-a a uma revisão somente leitura do código atual.
4. Verifique as descobertas você mesmo, depois prepare uma implementação delimitada com uma condição de aceitação visível.
5. Inspecione o diff e execute a verificação relevante, incluindo o caso de falha que motivou o trabalho.
6. Crie uma lição apenas quando o resultado a apoiar, com o escopo e o motivo registrados.
7. Transforme um procedimento em uma habilidade quando você verificar que vale a pena repeti-lo.
8. Tente a mesma recuperação de outra ferramenta, depois expanda seu contexto ou infraestrutura quando uma tarefa real exigir.

Comece com uma decisão esta semana e execute todo o ciclo antes de importar todo o seu histórico.

O próximo agente deve herdar seu julgamento.