¿Qué hace que un buen documento de plan de descuento sea para un proyecto de desarrollo de software? ¿Cuál es la diferencia entre un buen plan y uno excelente? Siempre estoy hablando sin parar de cómo dedico el 85%+ de mi tiempo y energía a las fases de planificación. ¿Y eso qué implica exactamente? Es difícil de explicar de forma abstracta; Necesitas un ejemplo tangible que realmente ilustre los matices. Así que pensé en compartir un buen ejemplo de hoy. Esto también responde a una pregunta reciente que me han estado haciendo sobre mi enfoque. La gente parece pensar que tienes que hacer todo en tu proyecto de una sola vez. Y en mi método, eso es cierto, ¡pero solo para la versión 1! Si decides añadir nuevas funciones 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 la creación de la v1, primero creando un plan de descuento súper detallado y luego convirtiéndolo en cuentas. Te voy a dar un ejemplo de Cass, mi programa Coding Agent Session Search, que es un programa bastante elaborado de Rust que detecta, analiza, almacena e indexa automáticamente todos tus registros de sesiones anteriores de casi todos los agentes de codificación. Ofrece una búsqueda instantánea de menos de 50 ms en todos esos registros y tiene muchas otras funciones interesantes. He decidido que me gustaría añadir una función a Cass que sea similar a una función 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 pueda servir usando GitHub Pages. Puedes ver un ejemplo de BV para 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 sencillo generar y desplegar el sitio exportado usando la utilidad gh. El sitio en sí suele consistir en un archivo sqlite y un montón de typescript y wasm que se ejecutan completamente en el navegador, pero con muy buen rendimiento y buenas características y estilo, como puedes observar en el ejemplo que acabas de dar. Ahora bien, compartir mensajes de correo de agentes MCP o un montón de cuentas es una cosa, pero compartir un montón de registros de sesión de agentes de codificación es muy diferente; estas cosas suelen estar llenas de información sensible, claves de API, insultos/insultos (¡al menos los míos lo están!) y otro material que definitivamente no querrías exponer al mundo. Pero GitHub Pages, por muy bueno que sea, solo funciona para repositorios públicos (por cierto, mis herramientas también soportan Cloudflare Pages, pero GH Pages es mejor y más fácil para este caso). ¿Cómo afrontar estos problemas? La respuesta es el cifrado: el usuario primero selecciona qué agentes de codificación incluir, qué carpetas del proyecto, el periodo de tiempo, etc., y se genera un bundle (tenga en cuenta que este bundle está en el formato canónico al que Cass convierte internamente todos los mensajes del agente de codificación desde sus formatos nativos originales) y luego el usuario proporciona una contraseña para usar en el cifrado de ese bundle. Así que la idea es que, aunque el repositorio y la página web sean públicos, todos excepto tú y otros a quienes les des la contraseña simplemente verán un campo de contraseña y no podrán leer ninguno de los mensajes. Una vez introducida la contraseña, desbloquearía una interfaz preciosa y responsiva que te permite buscar fácilmente entre los mensajes casi tan rápido y eficientemente como Cass. Y si realmente no tienes nada que ocultar, puedes dejar la contraseña desactivada y hacerla pública. ...