¿Qué hace que un buen documento de plan de markdown para un proyecto de desarrollo de software sea bueno? ¿Cuál es la diferencia entre un buen plan y uno excelente? Siempre estoy hablando de cómo paso más del 85% de mi tiempo y energía en las fases de planificación. Bueno, ¿qué implica eso exactamente? Es difícil de explicar en abstracto; necesitas un ejemplo tangible para ilustrar realmente las sutilezas. Así que pensé en compartir un buen ejemplo de hoy. Esto también aborda una pregunta reciente que he estado recibiendo sobre mi enfoque. La gente parece tener la impresión de que tienes que hacer todo en tu proyecto de una sola vez. Y en mi enfoque, eso es cierto, ¡pero solo para la versión 1! Si decides que quieres agregar nuevas características o cambiar cómo funcionan las cosas, obviamente puedes hacerlo una vez que tengas una v1 funcional. Y la forma de hacerlo es la misma que creas v1, creando primero un plan de markdown súper detallado y luego convirtiéndolo en beads. Así que te daré un ejemplo de Cass, mi programa de búsqueda de sesiones de Coding Agent, que es un programa de Rust bastante elaborado que detecta, analiza, almacena e indexa automáticamente todos tus registros de sesiones anteriores de casi todos los agentes de codificación que existen. Ofrece una búsqueda instantánea de "buscar mientras escribes" en menos de 50 ms a través de todos esos registros y tiene muchas otras características agradables. Decidí que me gustaría agregar una característica a Cass que es similar a una característica que ya tengo en MCP Agent Mail y en beads_viewer (bv): la capacidad de exportar tu configuración como un sitio web estático que se puede servir utilizando GitHub Pages. Puedes ver un ejemplo para bv de este mismo proyecto, que es el resultado final del proceso de planificación que describiré en esta publicación: Esta funcionalidad hace que sea muy rápido y fácil generar y desplegar el sitio exportado utilizando la utilidad gh. El sitio en sí generalmente consiste en un archivo sqlite y un montón de typescript y wasm que se ejecuta completamente en el navegador, pero con un rendimiento muy bueno y características y estilos agradables, que puedes observar en el ejemplo dado. Ahora, compartir mensajes de MCP Agent Mail o un montón de beads es una cosa, pero compartir un montón de registros de sesiones de agentes de codificación es muy diferente; estas cosas a menudo están llenas de información sensible, claves API, maldiciones/invectivas (¡al menos las mías lo están!), y otro material que definitivamente no querrías exponer al mundo. Pero GitHub Pages, por muy bonito que sea, solo funciona para repositorios públicos (por cierto, mis herramientas también son compatibles con Cloudflare pages, pero GH Pages es mejor y más fácil para este caso de uso). Entonces, ¿cómo manejar estos problemas? La respuesta es la encriptación: el usuario primero selecciona qué agentes de codificación incluir, qué carpetas de proyectos, el período de tiempo, etc., y se genera un paquete (ten en cuenta que este paquete está en el formato canónico en el que Cass convierte internamente todos los mensajes de los agentes de codificación desde sus formatos nativos originales) y luego el usuario proporciona una contraseña para usar en la encriptación de ese paquete. Así que la idea es que aunque el repositorio y la página web sean públicos, todos menos tú y otros a quienes les digas la contraseña simplemente verán un campo de contraseña y no podrán leer ninguno de los mensajes. ...