Ce face un document bun pentru un plan de remarcare pentru un proiect de dezvoltare software? Care este diferența dintre un plan bun și unul grozav? Tot vorbesc la nesfârșit despre cum petrec 85%+ din timpul și energia mea în fazele de planificare. Ei bine, ce presupune asta exact? Este greu de explicat în abstract; Ai nevoie de un exemplu concret care să ilustreze cu adevărat nuanțele. Așa că m-am gândit să împărtășesc un exemplu bun de azi. Aceasta răspunde și la o întrebare recentă pe care am primit-o despre abordarea mea. Oamenii par să creadă că trebuie să faci totul în proiect dintr-o singură dată. Și în abordarea mea, asta este adevărat, dar doar pentru versiunea 1! Dacă decizi că vrei să adaugi funcții noi sau să schimbi modul în care funcționează lucrurile, evident că poți face asta odată ce ai un v1 funcțional. Și modul în care faci asta este la fel cum creezi v1, creând mai întâi un plan de reducere foarte detaliat și apoi transformându-l în mărgele. Îți voi da un exemplu din Cass, programul meu Coding Agent Session Search, care este un program Rust destul de elaborat ce detectează, analizează, stochează și indexează automat toate jurnalele tale de sesiuni anterioare de la aproape orice agent de programare. Oferă sub 50ms "căutare instantanee pe măsură ce tastezi" pe toate acele jurnale și are multe alte funcții interesante. Am decis că aș dori să adaug o funcție în Cass care este similară cu una pe care o am deja în MCP Agent Mail și în beads_viewer (bv): posibilitatea de a exporta configurația ca un site static care poate fi servit folosind GitHub Pages. Puteți vedea un exemplu pentru bv chiar pentru acest proiect, care este rezultatul final al procesului de planificare pe care îl voi descrie în această postare: Această funcționalitate face foarte rapidă și ușoară generarea și implementarea site-ului exportat folosind utilitarul gh. Site-ul în sine constă de obicei într-un fișier sqlite și o mulțime de typescript și wasm care rulează complet în browser, dar cu performanțe foarte bune și funcții și stilizare plăcute, pe care le puteți observa în exemplul menționat. Acum, să partajezi mesaje MCP Agent Mail sau o grămadă de mărgele este un lucru, dar să partajezi o grămadă de jurnale de sesiuni ale agenților de codare este foarte diferit; aceste lucruri sunt adesea pline de informații sensibile, chei API, înjurături/invective (cel puțin ale mele sunt!) și alte materiale pe care cu siguranță nu ai vrea să le expui lumii. Dar GitHub Pages, oricât de plăcut ar fi, funcționează doar pentru repozitorii publice (apropo, uneltele mele suportă și Cloudflare Pages, dar GH Pages este mai bun și mai ușor pentru acest caz de utilizare). Deci, cum să gestionezi aceste probleme? Răspunsul este criptarea: utilizatorul selectează mai întâi ce agenți de codare să includă, ce foldere de proiect, perioada de timp etc., iar un pachet este generat (rețineți că acest pachet este în formatul canonic în care Cass convertește intern toate mesajele agenților de codare din formatele lor native originale), iar apoi utilizatorul oferă o parolă pentru criptarea acelui pachet. Ideea este că, deși repository-ul și pagina web sunt publice, toți, în afară de tine și de cei cărora le dai parola, vor vedea pur și simplu un câmp de parolă și nu vor putea citi niciunul dintre mesaje. Odată ce parola este introdusă, deblochează o interfață frumoasă și receptivă care îți permite să cauți ușor prin mesaje aproape la fel de rapid și eficient ca Cass. Și dacă chiar nu ai nimic de ascuns, poți lăsa parola dezactivată și să faci totul public. ...