Cosa rende un buon documento di piano markdown per un progetto di sviluppo software? Qual è la differenza tra un buon piano e uno grande? Parlo sempre di come trascorro oltre l'85% del mio tempo e delle mie energie nelle fasi di pianificazione. Ma cosa comporta esattamente? È difficile spiegarlo in astratto; hai bisogno di un esempio tangibile per illustrare davvero le sfumature. Quindi ho pensato di condividere un buon esempio di oggi. Questo affronta anche una domanda recente che ho ricevuto riguardo al mio approccio. La gente sembra avere l'impressione che devi fare tutto nel tuo progetto in un colpo solo. E nel mio approccio, questo è vero, ma solo per la versione 1! Se decidi di voler aggiungere nuove funzionalità o cambiare il modo in cui funzionano le cose, puoi ovviamente farlo una volta che hai una v1 funzionante. E il modo in cui lo fai è lo stesso modo in cui crei la v1, creando prima un piano markdown super dettagliato e poi trasformandolo in beads. Quindi ti darò un esempio da Cass, il mio programma di ricerca delle sessioni di Coding Agent, che è un programma Rust piuttosto elaborato che rileva, analizza, memorizza e indicizza automaticamente tutti i tuoi log di sessione precedenti da quasi tutti gli agenti di codifica là fuori. Offre una "ricerca mentre digiti" istantanea sotto i 50 ms su tutti quei log e ha molte altre belle funzionalità. Ho deciso che mi piacerebbe aggiungere a Cass una funzionalità simile a una che ho già in MCP Agent Mail e in beads_viewer (bv): la possibilità di esportare la tua configurazione come un sito web statico che può essere servito utilizzando GitHub Pages. Puoi vedere un esempio per bv per questo stesso progetto, che è il risultato finale del processo di pianificazione che descriverò in questo post: Questa funzionalità rende molto veloce e facile generare e distribuire il sito esportato utilizzando l'utilità gh. Il sito stesso di solito consiste in un file sqlite e un mucchio di typescript e wasm che gira interamente nel browser, ma con prestazioni molto buone e belle funzionalità e stili, che puoi osservare nell'esempio appena fornito. Ora, condividere i messaggi di MCP Agent Mail o un mucchio di beads è una cosa, ma condividere un mucchio di log di sessione di agenti di codifica è molto diverso; queste cose sono spesso piene di informazioni sensibili, chiavi API, insulti/invettive (almeno i miei lo sono!), e altro materiale che sicuramente non vorresti esporre al mondo. Ma GitHub Pages, per quanto sia bello, funziona solo per repo pubblici (tra l'altro, i miei strumenti supportano anche le pagine Cloudflare, ma GH Pages è migliore e più facile per questo caso d'uso). Quindi come gestire questi problemi? La risposta è la crittografia: l'utente prima seleziona quali agenti di codifica includere, quali cartelle di progetto, il periodo di tempo, ecc. e viene generato un pacchetto (nota che questo pacchetto è nel formato canonico in cui Cass converte internamente tutti i messaggi degli agenti di codifica dai loro formati nativi originali) e poi l'utente fornisce una password da utilizzare per la crittografia di quel pacchetto. Quindi l'idea è che, sebbene il repo e la pagina web siano pubblici, tutti tranne te e gli altri a cui dici la password vedranno semplicemente un campo per la password e non saranno in grado di leggere nessuno dei messaggi. ...