Depois de alguns dias explorando o Pi Durable, comecei a usá-lo de uma maneira mais próxima do que eu imaginava quando iniciei o experimento: não como um agente que fica aberto o dia inteiro esperando uma pergunta, mas como uma pequena rotina que observa o trabalho e me entrega contexto nos momentos certos.

A experiência tem sido interessante justamente porque o sistema não tenta fazer tudo. Ele não abre pull requests, não altera arquivos, não faz deploy e não escreve automaticamente no vault. Por enquanto, ele observa, compara e resume.

Essa limitação é importante. A ideia não é colocar mais um agente autônomo para acompanhar. É fazer com que uma parte do contexto do trabalho esteja pronta quando eu começo o dia e quando termino.

O que fica rodando em background

A automação foi feita com dois timers de usuário do systemd. Eles são instalados pelo script pi-durable-lab/scripts/install-user-timers.sh, que copia as unidades para ~/.config/systemd/user, executa systemctl --user daemon-reload e habilita os timers.

Existem dois pares de arquivos: um .timer, que define o horário, e um .service, que define o trabalho a ser executado.

O timer da manhã dispara às 09:00 e executa o comando:

npm run dev -- briefing-morning

O timer do fim do dia dispara às 17:00 e executa:

npm run dev -- briefing-closing

Os serviços usam Type=oneshot. Isso significa que não existe um processo do Pi Durable consumindo recursos continuamente. No horário configurado, o systemd inicia o serviço, o programa abre o runtime e o SQLite, coleta os snapshots dos workspaces, gera o relatório, salva o arquivo, tenta enviar uma notificação desktop e encerra.

Essa distinção acabou sendo uma das coisas mais importantes do experimento: o que fica em background não é um agente permanentemente ativo, mas o agendamento. O trabalho só acontece quando o timer dispara.

Também configurei os timers com Persistent=true. Se o computador estiver desligado no horário previsto, o systemd tenta executar a tarefa quando a sessão voltar. Para acompanhar o que está configurado, uso:

systemctl --user list-timers 'pi-durable-*' --all
journalctl --user -u pi-durable-morning.service -n 50 --no-pager
journalctl --user -u pi-durable-closing.service -n 50 --no-pager

Os relatórios são gravados em pi-durable-lab/reports/. Além do arquivo datado, o programa mantém latest-morning.md, latest-closing.md e um notification.json com o caminho e o tipo do relatório gerado.

O briefing matinal

O relatório da manhã se chama Briefing matinal. Ele compara o estado atual com a execução anterior e organiza o que merece atenção no começo do dia.

Prioridades de hoje

Esta seção transforma o snapshot em uma ordem possível de investigação. Ela não deveria ser uma lista genérica de tudo que existe, mas destacar o que está mais próximo de exigir uma decisão.

Por exemplo, uma working tree suja em uma branch compartilhada pode aparecer antes de um repositório limpo. Uma tarefa que aparece em vários repositórios também pode ganhar prioridade, porque talvez ainda falte confirmar se todas as partes foram validadas.

A lista não substitui meu julgamento. Ela funciona mais como uma primeira hipótese sobre onde vale olhar antes de começar a trabalhar.

Bloqueios

Aqui ficam os impedimentos explícitos ou as limitações que podem evitar que uma tarefa avance. Um bloqueio pode ser uma dependência que ainda não chegou, uma validação que falta ou uma informação que o agente não conseguiu obter.

Até agora, uma descoberta útil é que “nenhum bloqueio explícito” não significa que o trabalho esteja completamente livre. O relatório também informa quando a coleta é limitada, por exemplo quando sabe apenas que há arquivos alterados, mas não sabe quais são.

Riscos

Os riscos são situações que ainda não impediram o trabalho, mas podem causar retrabalho, perda de contexto ou uma decisão equivocada.

Uma alteração local sem identificação, uma branch antiga ou uma mudança cuja validação não aparece no snapshot são bons exemplos. O relatório também pode chamar atenção para uma configuração que merece revisão, sem transformar automaticamente essa suspeita em um problema confirmado.

Essa diferença entre fato, inferência e risco é importante. Um bom briefing não deve fingir que sabe mais do que os dados permitem.

Próximos passos

Esta seção sugere verificações pequenas e concretas para começar o dia. Como o sistema está em modo somente leitura, os próximos passos são observações: consultar o diff, confirmar o estado de uma tarefa, verificar uma branch ou revisar um commit.

Gosto desse formato porque ele reduz a distância entre o relatório e a ação. Em vez de apenas dizer que existe uma pendência, o briefing indica qual é a próxima pergunta que precisa ser respondida.

Lacunas

As lacunas mostram o que o sistema ainda não consegue saber. Podem faltar nomes de arquivos alterados, informações sobre CI, divergência em relação ao remoto, estado de pull requests ou datas mais precisas dos snapshots.

Essa talvez seja uma das seções mais valiosas. Sem ela, um relatório bem escrito pode passar uma falsa sensação de completude. As lacunas deixam claro onde a análise termina e onde ainda é necessário investigar manualmente.

O fechamento do dia

No fim do expediente, o relatório se chama Fechamento do dia. Ele usa a mesma base de observação, mas organiza a informação a partir do que mudou desde a manhã e do que precisa continuar amanhã.

Concluído hoje

Esta seção registra o que avançou: commits novos, marcos identificados e tarefas que parecem ter chegado a algum ponto importante.

Como a coleta atual é baseada principalmente em estado de repositórios e histórico recente, nem toda conclusão pode ser confirmada diretamente. Por isso, o relatório diferencia o que foi observado do que é apenas uma inferência a partir dos commits e branches.

Pendente

Aqui ficam as tarefas que continuam abertas ao final do dia. A seção ajuda a separar o que não foi feito do que foi deliberadamente deixado para depois.

Também é onde reaparecem itens persistentes, como uma alteração local que não mudou durante o dia ou uma branch cujo destino ainda não foi confirmado. Ver a mesma pendência em mais de um relatório é útil: ela deixa de depender apenas da memória.

Bloqueios e riscos

O fechamento junta esses dois tópicos porque, no fim do dia, é importante saber tanto o que impediu o avanço quanto o que pode complicar a retomada amanhã.

Um bloqueio pode exigir uma ação de outra pessoa ou uma informação externa. Um risco pode ser apenas uma situação que merece cuidado. Manter os dois visíveis evita que eu confunda “não avancei” com “não há problema”.

Para retomar amanhã

Esta é a parte mais prática do fechamento. Em vez de encerrar o dia com uma lista vaga de pendências, o relatório tenta deixar uma sequência de verificações para o próximo início.

O objetivo não é planejar todo o dia seguinte. É reduzir o custo de voltar ao trabalho: lembrar em qual repositório olhar, qual hipótese confirmar e qual tarefa precisa de uma decisão.

Lacunas

Assim como no briefing matinal, o fechamento lista o que não foi possível confirmar. A repetição é intencional. Uma lacuna que aparece no fim do dia pode se transformar na primeira pergunta da manhã seguinte.

Isso também ajuda a identificar melhorias futuras no sistema. Se sempre falta a mesma informação, talvez seja um sinal de que o snapshot precisa consultar outra fonte — ou de que uma integração futura poderia resolver o problema.

Uma rotina pequena, mas útil

Minha experiência diária com o Pi Durable ainda está no começo. Os relatórios podem repetir informações, algumas conclusões ainda precisam ser verificadas e o snapshot não conhece tudo o que acontece fora dos repositórios.

Mesmo assim, a rotina já mudou uma coisa importante: não preciso começar o dia reconstruindo sozinho o que aconteceu antes. Recebo uma síntese com prioridades, riscos e lacunas. No fim do dia, deixo uma trilha mais clara para retomar o trabalho.

O valor não está em o agente tomar decisões por mim. Está em manter uma memória operacional simples, persistente e observável entre dois momentos do dia.

Por enquanto, é isso que eu quero do Pi Durable: que ele observe o suficiente para me ajudar a começar e terminar melhor, sem transformar uma automação útil em mais um sistema que eu precise vigiar o tempo todo.

Um ponto de partida público

Organizei o experimento em um repositório público no Codeberg: Pi Durable Lab. A versão publicada abstrai os caminhos específicos do meu ambiente, recebe os workspaces e modelos por variáveis de ambiente e mantém o fluxo somente de leitura como padrão.

A intenção não é apresentar o projeto como uma solução pronta. Ele é um ponto de partida para quem quiser testar a ideia de briefings duráveis, adaptar os coletores ao próprio trabalho ou contribuir com uma evolução mais geral. Se você experimentar, encontrar um problema ou tiver uma ideia de integração, fique à vontade para abrir uma issue ou enviar um pull request.