O que faz um bom documento de plano em markdown para um projeto de desenvolvimento de software? Qual é a diferença entre um bom plano e um ótimo? Estou sempre a falar sobre como passo mais de 85% do meu tempo e energia nas fases de planejamento. Bem, o que isso realmente envolve? É difícil explicar de forma abstrata; você precisa de um exemplo tangível para realmente ilustrar as nuances. Então, pensei em compartilhar um bom exemplo de hoje. Isso também aborda uma pergunta recente que tenho recebido sobre a minha abordagem. As pessoas parecem ter a impressão de que você tem que fazer tudo no seu projeto de uma só vez. E na minha abordagem, isso é verdade, mas apenas para a versão 1! Se você decidir que quer adicionar novos recursos ou mudar como as coisas funcionam, você pode, obviamente, fazer isso uma vez que tenha uma v1 funcional. E a maneira de fazer isso é a mesma que você cria a v1, criando primeiro um plano em markdown super detalhado e depois transformando-o em beads. Então, vou dar um exemplo do Cass, meu programa de Pesquisa de Sessão do Agente de Codificação, que é um programa Rust bastante elaborado que detecta, analisa, armazena e indexa automaticamente todos os seus registros de sessão anteriores de praticamente todos os agentes de codificação disponíveis. Ele oferece uma pesquisa instantânea "à medida que você digita" em menos de 50ms em todos esses registros e tem muitos outros recursos interessantes. Decidi que gostaria de adicionar um recurso ao Cass que é semelhante a um recurso que já tenho no MCP Agent Mail e no beads_viewer (bv): a capacidade de exportar sua configuração como um site estático que pode ser servido usando o GitHub Pages. Você pode ver um exemplo para bv para este projeto, que é o resultado final do processo de planejamento que descreverei neste post: Essa funcionalidade torna muito rápido e fácil gerar e implantar o site exportado usando a ferramenta gh. O site em si geralmente consiste em um arquivo sqlite e um monte de typescript e wasm que roda inteiramente no navegador, mas com um desempenho muito bom e recursos e estilos agradáveis, que você pode observar no exemplo dado. Agora, compartilhar mensagens do MCP Agent Mail ou um monte de beads é uma coisa, mas compartilhar um monte de registros de sessão de agentes de codificação é muito diferente; essas coisas estão frequentemente cheias de informações sensíveis, chaves de API, palavrões/invectivas (pelo menos as minhas estão!), e outros materiais que você definitivamente não gostaria de expor ao mundo. Mas o GitHub Pages, por mais legal que seja, só funciona para repositórios públicos (a propósito, minhas ferramentas também suportam páginas do Cloudflare, mas o GH Pages é melhor e mais fácil para este caso de uso). Então, como lidar com esses problemas? A resposta é criptografia: o usuário primeiro seleciona quais agentes de codificação incluir, quais pastas de projeto, o período de tempo, etc. e um pacote é gerado (note que este pacote está no formato canônico que o Cass converte internamente todas as mensagens dos agentes de codificação a partir de seus formatos nativos originais) e então o usuário fornece uma senha para usar na criptografia desse pacote. Então, a ideia é que, embora o repositório e a página da web sejam públicos, todos, exceto você e outros a quem você contar a senha, verão simplesmente um campo de senha e não poderão ler nenhuma das mensagens. ...