O que faz um bom documento de plano de desconto para um projeto de desenvolvimento de software? Qual a diferença entre um bom plano e um ótimo? Estou sempre falando sem parar sobre como gasto 85%+ do meu tempo e energia nas fases de planejamento. Bem, o que isso implica exatamente? É difícil explicar de forma abstrata; Você precisa de um exemplo concreto para realmente ilustrar as nuances. Então achei que seria bom para compartilhar um bom exemplo de hoje. Isso também responde a uma pergunta recente que venho recebendo sobre minha abordagem. As pessoas parecem achar que você precisa fazer tudo no seu projeto de uma vez só. E na minha abordagem, isso é verdade, mas só para a versão 1! Se você decidir adicionar novos recursos ou mudar como as coisas funcionam, obviamente pode fazer isso depois de ter uma v1 funcionando. E a forma de fazer isso é a mesma que cria a v1, criando primeiro um plano de marcação super detalhado e depois transformando em contas. Vou te dar um exemplo do Cass, meu programa Coding Agent Session Search, que é um programa Rust bem elaborado que detecta, analisa, armazena e indexa automaticamente todos os seus logs de sessões anteriores de praticamente todos os agentes de codificação disponíveis. Ele oferece uma busca instantânea abaixo de 50ms enquanto você digita" em todos esses registros e tem muitos outros recursos legais. Decidi que gostaria de adicionar um recurso ao Cass que seja semelhante a um 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 de vaginosidade bacteriana para este mesmo projeto, que é o resultado final do processo de planejamento que vou descrever neste post: Essa funcionalidade torna muito rápido e fácil gerar e implantar o site exportado usando o utilitário gh. O site geralmente consiste em um arquivo sqlite e um monte de typescript e wasm que rodam inteiramente no navegador, mas com desempenho muito bom e recursos e estilos legais, que você pode observar no exemplo que acabou de mencionar. Agora, compartilhar mensagens de MCP Agent Mail ou um monte de contas é uma coisa, mas compartilhar vários logs de sessão de agentes de codificação é bem diferente; essas coisas geralmente estão cheias de informações sensíveis, chaves de API, palavrões/invectivas (pelo menos as minhas são!), e outro material 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 (aliás, minhas ferramentas também suportam páginas Cloudflare, mas o GH Pages é melhor e mais fácil para esse caso). Então, como lidar com esses problemas? A resposta é criptografia: o usuário primeiro seleciona quais agentes de codificação incluir, quais pastas do projeto, o período de tempo, etc., e um bundle é gerado (note que esse bundle está no formato canônico para o qual o Cass converte internamente todas as mensagens do agente de codificação a partir de seus formatos nativos originais) e então o usuário fornece uma senha para usar na criptografia desse bundle. Então, a ideia é que, embora o repositório e a página da web sejam públicos, todos, exceto você e outras pessoas a quem você informar a senha, simplesmente verão um campo de senha e não conseguirão ler nenhuma das mensagens. Uma vez que a senha seja inserida, ela desbloqueia uma interface linda e responsiva que permite que você pesquise facilmente as mensagens quase tão rápido e eficientemente quanto Cass. E se você realmente não tem nada a esconder, pode deixar a senha desligada e tornar tudo realmente público. ...