Contexto organizado para continuar o projeto

Guarda o que muda a próxima decisão

Regista a informação que altera a forma de continuar o trabalho: objetivo, limites, decisões confirmadas, resultado atual e dúvidas por resolver. Não precisas de copiar toda a conversa para preservar o contexto. Precisas de selecionar o que outra sessão teria de saber para avançar sem reabrir escolhas já feitas ou repetir trabalho concluído.

Imagina que estás a construir um portal para aprovar propostas. Decidiste que só o responsável comercial pode dar aprovação final, que a equipa prepara os documentos e que o cliente recebe apenas a versão aprovada. Estas regras afetam as próximas alterações e devem ficar registadas fora das mensagens em que surgiram.

Neste exemplo hipotético, não interessa conservar cada tentativa de nome para um botão no resumo principal. Já interessa saber que a aprovação pertence a uma função específica e que uma alteração ao conteúdo exige nova revisão. A seleção deve seguir o efeito da informação no produto, e não a quantidade de tempo que passaste a discuti-la.

O princípio de dar contexto à IA com critério aplica-se também à continuidade. Um registo curto com decisões verificáveis pode ser mais útil do que páginas de conversa sem distinção entre sugestões, testes e escolhas aceites. Guarda o detalhe onde possa ser consultado quando houver uma razão para o recuperar.

Para preparar o próximo passo, consulta Desenvolver aplicações com IA.

Separa as regras do estado da tarefa

As regras estáveis dizem como o projeto deve funcionar; o estado da tarefa diz onde o trabalho ficou. Mantém estas duas camadas identificáveis para evitar que uma pendência temporária se transforme numa instrução permanente. O plano pode ligar ambas, mostrando o objetivo, as decisões em vigor e a próxima etapa autorizada.

Uma regra pode indicar que textos públicos precisam de revisão antes de serem enviados. O estado pode dizer que o formulário está implementado localmente, mas falta conferir o envio de notificações. Misturar essas frases num bloco sem títulos torna mais difícil perceber o que deve continuar válido e o que desaparecerá quando a tarefa terminar.

O hábito de planear uma aplicação antes de começar a programar cria uma base para essa separação. Mantém os requisitos e decisões no plano, aponta para os ficheiros que orientam o agente e guarda resultados de execução num registo próprio. A estrutura pode ser simples, desde que cada parte tenha uma função compreensível.

Também distingue proposta de decisão. Se o assistente sugeriu acrescentar pagamentos, mas ainda não aceitaste essa funcionalidade, o registo deve mantê-la como hipótese. Uma sessão seguinte não pode receber uma lista de ideias e tratá-la como autorização para desenvolver tudo, só porque a conversa anterior terminou sem objeções.

Fecha a sessão com um estado que possa ser conferido

Antes de parar, pede um registo do que foi alterado, do que foi verificado e do que continua pendente. Inclui a localização dos resultados e as limitações conhecidas. O resumo deve permitir conferir os factos no projeto, distinguindo trabalho implementado de trabalho testado, aprovado ou colocado em utilização por outras pessoas.

No portal de propostas, pode estar pronto o ecrã de revisão sem que as permissões tenham sido testadas. Escrever apenas que o portal está concluído faria a sessão seguinte partir de uma certeza indevida. Uma descrição mais útil identifica o ecrã existente, os casos verificados e a parte que ainda precisa de avaliação.

Contexto, plano, construção e validação do projeto

Ao terminar a sessão, regista em que etapa está cada parte do projeto e que evidência existe para continuar.

Guarda caminhos de ficheiros, nomes de documentos e referências de versões quando forem necessários para localizar o trabalho. Evita copiar credenciais ou dados de clientes para o resumo. A continuidade depende de saber onde obter acesso autorizado e consultar a informação relevante, sem transformar a documentação numa cópia indiscriminada de tudo o que o agente viu.

Se uma tentativa falhou, regista a causa conhecida e a incerteza que permanece. Não é necessário conservar todas as mensagens de erro no documento principal, mas pode ser útil apontar para o resultado técnico guardado. Assim, a próxima sessão consegue investigar sem repetir exatamente a mesma experiência por desconhecer que já foi feita.

Retoma pela leitura dos registos e pela realidade do projeto

Ao iniciar uma nova sessão, indica os documentos de referência e pede que o estado descrito seja comparado com os ficheiros atuais. Confirma a próxima tarefa e as condições que a limitam. Ter documentação disponível ajuda a recuperar contexto, mas a sua existência não prova que foi lida ou que continua atualizada.

O carregamento de instruções depende da ferramenta e da configuração utilizada. Não pressuponhas que qualquer ficheiro com um nome familiar será considerado em todos os ambientes. Confirma quais as instruções aplicáveis e pede ao agente que identifique decisões relevantes para a tarefa antes de começar a alterar o projeto.

Pode existir uma diferença entre o registo e a realidade porque outra pessoa trabalhou entretanto ou porque uma operação ficou incompleta. Quando isso acontece, resolve a divergência antes de avançar com base no resumo antigo. O documento deve orientar a investigação, sem prevalecer automaticamente sobre evidência mais recente que mostre um estado diferente.

A preparação da primeira sessão de trabalho continua a oferecer critérios úteis para retomar: objetivo, ambiente e acessos precisam de estar claros. A diferença é que agora existe trabalho acumulado a preservar. A nova sessão deve começar por o compreender e identificar onde pode continuar com segurança.

Atualiza a referência quando uma decisão muda

Quando mudas uma decisão, atualiza o registo que orienta o trabalho e identifica a regra anterior como substituída. Mantém o motivo da alteração onde fizer sentido consultar o histórico. Acrescentar uma nova frase sem resolver a contradição pode deixar duas instruções incompatíveis disponíveis para a sessão seguinte interpretar por conta própria.

Se a aprovação final passa a exigir duas pessoas, por exemplo, o projeto precisa de refletir essa mudança no plano e nos critérios de validação. O registo histórico pode explicar a decisão anterior, mas não deve apresentar ambas como regras em vigor. A equipa precisa de uma referência clara sobre o funcionamento atual.

Revê também os apontadores e as pendências. Uma tarefa concluída deve deixar de aparecer como próximo passo, e um ficheiro que mudou de localização precisa de ter a referência corrigida. Pequenas atualizações no momento da mudança evitam que o resumo de continuidade se transforme, aos poucos, numa descrição de um projeto que já não existe.

A documentação útil cresce com o trabalho, mas também é simplificada quando o contexto muda. Preserva decisões e evidência sem obrigar cada sessão a reconstruir toda a história. O critério é conseguir retomar a próxima tarefa com clareza sobre o que está decidido, o que foi feito e o que ainda exige atenção.