Wat maakt een goed markdown-plan document voor een softwareontwikkelingsproject? Wat is het verschil tussen een goed plan en een geweldig plan? Ik blijf maar zeggen dat ik meer dan 85% van mijn tijd en energie aan de planningsfasen besteed. Maar wat houdt dat precies in? Het is moeilijk om dat abstract uit te leggen; je hebt een tastbaar voorbeeld nodig om de nuances echt te illustreren. Dus ik dacht dat ik een goed voorbeeld van vandaag zou delen. Dit behandelt ook een recente vraag die ik heb gekregen over mijn aanpak. Mensen lijken de indruk te hebben dat je alles in je project in één keer moet doen. En in mijn aanpak is dat waar, maar alleen voor versie 1! Als je besluit dat je nieuwe functies wilt toevoegen of hoe dingen werken wilt veranderen, kun je dat uiteraard doen zodra je een functionele v1 hebt. En de manier waarop je dat doet, is dezelfde manier waarop je v1 creëert, door eerst een supergedetailleerd markdown-plan te maken en dat vervolgens om te zetten in beads. Dus ik geef je een voorbeeld van Cass, mijn Coding Agent Session Search-programma, dat een vrij uitgebreid Rust-programma is dat automatisch al je eerdere sessielogs van bijna elke coding agent daarbuiten detecteert, parseert, opslaat en indexeert. Het biedt sub 50ms instant "zoeken terwijl je typt" over al die logs en heeft veel andere leuke functies. Ik besloot dat ik een functie aan Cass wilde toevoegen die vergelijkbaar is met een functie die ik al heb in MCP Agent Mail en in beads_viewer (bv): de mogelijkheid om je setup als een statische website te exporteren die kan worden gehost met GitHub Pages. Je kunt een voorbeeld voor bv voor dit specifieke project zien, wat het eindresultaat is van het planningsproces dat ik in deze post zal beschrijven: Deze functionaliteit maakt het heel snel en eenvoudig om de geëxporteerde site te genereren en te implementeren met de gh-tool. De site zelf bestaat meestal uit een sqlite-bestand en een aantal typescript en wasm die volledig in de browser draaien, maar met zeer goede prestaties en leuke functies en styling, die je kunt observeren in het zojuist gegeven voorbeeld. Nu, het delen van MCP Agent Mail-berichten of een aantal beads is één ding, maar het delen van een aantal coding agent sessielogs is heel anders; deze dingen zitten vaak vol met gevoelige informatie, API-sleutels, scheldwoorden/uitdrukkingen (tenminste die van mij!), en ander materiaal dat je absoluut niet aan de wereld wilt blootstellen. Maar GitHub Pages, hoe leuk het ook is, werkt alleen voor openbare repos (overigens ondersteunen mijn tools ook Cloudflare-pagina's, maar GH Pages is beter en gemakkelijker voor deze use case). Dus hoe ga je met deze problemen om? Het antwoord is encryptie: de gebruiker selecteert eerst welke coding agents moeten worden opgenomen, welke projectmappen, de tijdsperiode, enzovoort, en er wordt een bundel gegenereerd (let op dat deze bundel in het canonieke formaat is dat Cass intern alle coding agent-berichten omzet vanuit hun oorspronkelijke native formaten) en vervolgens geeft de gebruiker een wachtwoord op dat gebruikt zal worden voor de encryptie van die bundel. Dus het idee is dat hoewel de repo en de webpagina openbaar zijn, iedereen behalve jij en anderen aan wie je het wachtwoord vertelt, gewoon een wachtwoordveld zullen zien en niet in staat zullen zijn om een van de berichten te lezen. ...