Vad gör ett bra markdown-plandokument för ett mjukvaruutvecklingsprojekt? Vad är skillnaden mellan en bra plan och en riktigt bra sådan? Jag tjatar alltid om hur jag lägger 85%+ av min tid och energi på planeringsfaserna. Vad innebär det egentligen? Det är svårt att förklara abstrakt; Du behöver ett konkret exempel för att verkligen illustrera nyanserna. Så jag tänkte dela med mig av ett bra exempel från idag. Detta besvarar också en nylig fråga jag fått om mitt tillvägagångssätt. Folk verkar tro att man måste göra allt i sitt projekt på en gång. Och enligt min metod är det sant, men bara för version 1! Om du bestämmer dig för att lägga till nya funktioner eller ändra hur saker fungerar, kan du såklart göra det när du har en fungerande version 1. Och sättet du gör det på är samma sätt som du skapar v1, genom att först skapa en superdetaljerad markdown-plan och sedan göra om den till pärlor. Så jag ska ge dig ett exempel från Cass, mitt Coding Agent Session Search-program, som är ett ganska avancerat Rust-program som automatiskt upptäcker, tolkar, lagrar och indexerar alla dina tidigare sessionsloggar från nästan alla kodningsagenter där ute. Den erbjuder under 50 ms omedelbar "sökning medan du skriver" över alla dessa loggar och har många andra trevliga funktioner. Jag bestämde mig för att jag vill lägga till en funktion i Cass som liknar en funktion jag redan har i MCP Agent Mail och i beads_viewer (bv): möjligheten att exportera din setup som en statisk webbplats som kan levereras via GitHub Pages. Du kan se ett exempel för bv för just detta projekt, vilket är slutresultatet av planeringsprocessen jag kommer att beskriva i detta inlägg: Denna funktionalitet gör det mycket snabbt och enkelt att generera och distribuera den exporterade webbplatsen med hjälp av gh-verktyget. Själva sidan består vanligtvis av en sqlite-fil och en massa typescript och wasm som körs helt i webbläsaren, men med mycket bra prestanda och fina funktioner och stil, vilket du kan se i exemplet som just gavs. Att dela MCP Agent Mail-meddelanden eller en massa pärlor är en sak, men att dela en massa kodningsagent-sessionsloggar är något helt annat; dessa saker är ofta fulla av känslig information, API-nycklar, förbannelser/invektiv (åtminstone mina är det!), och annat material som du definitivt inte vill exponera för världen. Men GitHub Pages, hur bra det än är, fungerar bara för publika repos (förresten, mina verktyg stödjer också Cloudflare Pages, men GH Pages är bättre och enklare för detta användningsområde). Så hur hanterar man dessa problem? Svaret är kryptering: användaren väljer först vilka kodagenter som ska inkluderas, vilka projektmappar, tidsperiod osv. och ett paket genereras (observera att detta paket är i det kanoniska format som Cass internt konverterar alla kodningsagentmeddelanden till från deras ursprungliga originalformat) och sedan tillhandahåller användaren ett lösenord för kryptering av det paketet. Så idén är att även om repot och webbsidan är offentliga, kommer alla utom du och de du berättar lösenordet till bara att se ett lösenordsfält och inte kunna läsa något av meddelandena. När lösenordet är inmatat låser det upp ett vackert, responsivt gränssnitt som låter dig enkelt söka bland meddelandena nästan lika snabbt och effektivt som Cass gör. Och om du verkligen inte har något att dölja kan du lämna lösenordet avstängt och göra allt faktiskt offentligt. ...