Qu'est-ce qui constitue un bon document de planification en markdown pour un projet de développement logiciel ? Quelle est la différence entre un bon plan et un excellent ? Je parle toujours de la façon dont je passe plus de 85 % de mon temps et de mon énergie sur les phases de planification. Eh bien, qu'est-ce que cela implique exactement ? C'est difficile à expliquer de manière abstraite ; vous avez besoin d'un exemple tangible pour vraiment illustrer les nuances. Alors j'ai pensé que je partagerais un bon exemple d'aujourd'hui. Cela répond également à une question récente que j'ai reçue concernant mon approche. Les gens semblent avoir l'impression que vous devez tout faire dans votre projet d'un seul coup. Et dans mon approche, c'est vrai, mais seulement pour la version 1 ! Si vous décidez que vous souhaitez ajouter de nouvelles fonctionnalités ou changer le fonctionnement des choses, vous pouvez évidemment le faire une fois que vous avez une v1 fonctionnelle. Et la façon de le faire est la même que celle que vous utilisez pour créer la v1, en créant d'abord un plan markdown super détaillé, puis en le transformant en beads. Je vais donc vous donner un exemple de Cass, mon programme de recherche de sessions d'agent de codage, qui est un programme Rust assez élaboré qui détecte, analyse, stocke et indexe automatiquement tous vos journaux de session précédents de presque tous les agents de codage disponibles. Il offre une recherche instantanée "recherche au fur et à mesure que vous tapez" en moins de 50 ms sur tous ces journaux et possède de nombreuses autres fonctionnalités intéressantes. J'ai décidé que j'aimerais ajouter une fonctionnalité à Cass qui est similaire à une fonctionnalité que j'ai déjà dans MCP Agent Mail et dans beads_viewer (bv) : la possibilité d'exporter votre configuration en tant que site web statique pouvant être servi via GitHub Pages. Vous pouvez voir un exemple pour bv pour ce projet, qui est le résultat final du processus de planification que je vais décrire dans ce post : Cette fonctionnalité rend très rapide et facile la génération et le déploiement du site exporté à l'aide de l'utilitaire gh. Le site lui-même consiste généralement en un fichier sqlite et un tas de typescript et wasm qui s'exécutent entièrement dans le navigateur, mais avec de très bonnes performances et de belles fonctionnalités et un bon style, que vous pouvez observer dans l'exemple donné ci-dessus. Maintenant, partager des messages de MCP Agent Mail ou un tas de beads est une chose, mais partager un tas de journaux de session d'agent de codage est très différent ; ces choses sont souvent pleines d'informations sensibles, de clés API, de jurons/invectives (du moins les miens le sont !), et d'autres éléments que vous ne voudriez certainement pas exposer au monde. Mais GitHub Pages, aussi agréable soit-il, ne fonctionne que pour les dépôts publics (au fait, mes outils prennent également en charge les pages Cloudflare, mais GH Pages est meilleur et plus facile pour ce cas d'utilisation). Alors, comment gérer ces problèmes ? La réponse est le chiffrement : l'utilisateur sélectionne d'abord quels agents de codage inclure, quels dossiers de projet, la période, etc., et un bundle est généré (notez que ce bundle est au format canonique dans lequel Cass convertit en interne tous les messages des agents de codage à partir de leurs formats natifs d'origine) et ensuite l'utilisateur fournit un mot de passe à utiliser pour le chiffrement de ce bundle. Donc, l'idée est que bien que le dépôt et la page web soient publics, tout le monde sauf vous et les autres à qui vous donnez le mot de passe verra simplement un champ de mot de passe et ne pourra pas lire aucun des messages. ...