# Șerban învață Claude construind o platformă de analiză a companiilor Plan de învățare Claude, 4 săptămâni, 4 ore pe zi (luni–vineri). Publicat la https://serban.bgn.ro. Pregătit de Bogdan, cu Claude. ## Cum citește Claude fișierul ăsta Fișierul e versiunea text a planului de la serban.bgn.ro. Când Șerban întreabă „ce vrea de la mine T17?”, răspunsul e sarcina T17 de mai jos: misiunea sau promptul, de ce funcționează, provocarea. Sarcinile de nivel 1 au promptul dat; cele de nivel 2 au spații [ÎN MAJUSCULE] pe care le scrie el; cele de nivel 3 au o misiune și o listă de acoperit, iar promptul de referință se arată doar după ce și l-a scris pe al lui. ## Testul de pornire și probele rapide La început, Șerban răspunde cu da sau nu la opt întrebări. Un „da” trece sarcinile legate de subiectul acela pe proba rapidă: un lucru concret de făcut, mai scurt, care arată că știe. Dacă proba nu iese din prima, se face sarcina întreagă. Sarcinile despre proiect (nevoia, PRD-ul, funcțiile, auditurile, lansarea) nu au probă. - Folosești deja Claude (sau alt asistent AI) cel puțin o dată pe săptămână, la muncă sau acasă? Dacă da, probă rapidă la: T01, T03. - Ai făcut vreodată cu Claude un artifact: o mini-pagină sau o mini-aplicație care apare lângă conversație? Dacă da, probă rapidă la: T02, T09. - Ai un Project în claude.ai, cu documente urcate și instrucțiuni personalizate? Dacă da, probă rapidă la: T08. - Ai lucrat în Claude Code (tab-ul Code din aplicația Claude sau în terminal)? Dacă da, probă rapidă la: T05, T07. - Ai cont GitHub și ai urcat acolo măcar un proiect (commit, push)? Dacă da, probă rapidă la: T19. - Ai publicat vreodată un site pe internet (pe Vercel, Netlify sau altundeva)? Dacă da, probă rapidă la: T20, T43. - Ai lucrat cu o bază de date sau cu un login cu Google într-un proiect al tău (Supabase, Firebase)? Dacă da, probă rapidă la: T29, T31. - Ai chemat vreodată un API cu o cheie (de exemplu API-ul lui Claude sau al OpenAI)? Dacă da, probă rapidă la: T33. ## Săptămâna 1: Fundații: Claude, conturile și ce construim (Nivel 1: prompturi date) Luni: conturile (GitHub primul, cu mesajul către Bogdan), primul artifact în prima oră, rețeta promptului pe ceva construit de tine, și proiectul pe o foaie. Marți, saltul: Claude Code și agenții lui Bogdan pe calculatorul tău, turul echipei (ce face fiecare agent, trei probe), primul proiect cu reguli (CLAUDE.md) și puncte de salvare (git). Miercuri: Project-ul tău (un Claude cu memorie) și trackerul v1, prima ta aplicație cu memorie. Joi și vineri, Bruce: nevoia, cum rezolvă alții problema, trei discuții cu oameni reali, PRD-ul cu decizii numerotate și prototipul pe telefon. Livrabile: conturi Claude și GitHub · pagina de o foaie · primul artifact · Project cu bază de cunoștințe · tracker v1 · Claude Code + pachetul BGN instalate · proiect cu CLAUDE.md și git · PRD v1 + prototip HTML · jurnalul săptămânii 1 ### T01 · Lu · 1h · Pregătire · Înainte de orice: conturile (GitHub, Claude) și folderul proiectului Proba rapidă (pentru cine știe deja; 0.5h în loc de 1h): Ai deja cont Claude plătit și vorbești cu el săptămânal? Atunci fă din lista de mai jos doar pașii care îți lipsesc: contul GitHub cu verificarea în doi pași, mesajul către Bogdan cu numele tău de utilizator, semnele de carte și folderul cu planul în el. Din prompt trimite doar întrebarea 3, apoi fă provocarea: nota cu „la ce ești slab” îți trebuie în T48. Întâi, fără Claude: - Primul lucru, înainte de orice: contul GitHub. Pe github.com → Sign up. Alege un nume de utilizator pe care l-ai pune și pe un CV (prenume-nume sau ceva apropiat) și activează verificarea în doi pași (Settings → Password and authentication). GitHub e locul unde va sta codul tău și de unde Bogdan îți dă acces la agenții lui. - Al doilea lucru: trimite-i lui Bogdan numele tău de utilizator GitHub (pe WhatsApp sau pe email) și cere-i accesul la agenții lui. El te invită la pachetul cu agenți (BGN-ro/agenti-bgn); invitația vine pe email, de la GitHub, și o accepți de acolo. Fără ea nu poți începe ziua a doua, așa că mesajul pleacă acum, nu diseară. - Contul Claude: în Chrome, intră pe claude.ai și fă-ți cont (cel mai simplu cu „Continue with Google”). Apoi abonamentul: inițialele tale, stânga-jos → Settings → Upgrade. Pro ajunge la început; săptămânile 2–4 folosesc mult Claude Code și dacă dai de limita de folosire, Max o rezolvă. Parolele le scrii doar tu, niciodată Claude. - Pune două semne de carte în bara Chrome: claude.ai și serban.bgn.ro (planul ăsta). - Fă un folder „analize” în Documents (numele de lucru al proiectului îl alegi în T04). Tot ce descarci pentru plan și tot ce construiești stă acolo. Descarcă de pe serban.bgn.ro fișierul „planul ca text” (linkul e în Prezentare) și pune-l în folder. Promptul: ``` Salut. Sunt Șerban, analizez companii în care s-ar putea investi. Încep un plan de 4 săptămâni (stă la serban.bgn.ro) în care învăț să lucrez cu tine construind ceva adevărat: platforma mea de analiză a companiilor. Trei întrebări ca să pornim: 1. Ce ești tu, exact, pe înțelesul meu, și care e diferența dintre tine aici, în browser, aplicația de desktop și ceva numit Claude Code? Le voi folosi pe toate trei în următoarele patru săptămâni. 2. Ce ar trebui să știu despre cum să vorbesc cu tine? Ai niște reguli de circulație? 3. Ce se întâmplă cu ce scriu aici: cine poate vedea, și o să-ți amintești mâine conversația asta? ``` De ce funcționează promptul: Observă: chiar primul mesaj respectă deja rețeta: cine ești (context), ce faci (scop), întrebări numerotate (formă). Și întrebarea 3 e pusă intenționat: „ce e privat și ce se ține minte” e prima întrebare bună de pus oricărei unelte, nu ultima. Pune răspunsul la îndoială: Răspunsul la întrebarea 1 va fi sigur pe el și ordonat. Pune întrebarea care îl testează: „La ce ești slab? Cu ce n-ar trebui să mă încred în tine?”. Salvează răspunsul într-o notă. În retrospectiva din săptămâna 4 (T48) îl compari cu lista ta, făcută din patru săptămâni de experiență reală, și vezi care dintre voi îl cunoștea mai bine pe Claude în ziua 1. ### T02 · Lu · 0.5h · Prima victorie · Victorie rapidă: primul tău artifact (30 de minute) Proba rapidă (pentru cine știe deja; 0.25h în loc de 0.5h): Fără să citești promptul nostru: scrie tu promptul pentru un card cu titlul proiectului, trei rânduri de text și un buton, și obține-l dintr-o singură încercare. Apoi compară promptul tău cu al nostru: ce a spus al nostru și al tău nu? Dacă diferența e mică, treci mai departe. Dacă al nostru era vizibil mai precis, fă și T03 întreagă, nu proba ei. Promptul: ``` Construiește-mi un artifact HTML foarte simplu (doar HTML + CSS, fără librării) care arată un singur card mare: - sus, mic, cu majuscule rărite: „ANALIZA COMPANIILOR” - titlul „Analize” (nume de lucru) cu font mare, gras, și un gradient de la albastru-închis (#1B2B5E) la albastru (#2F5FD0) - trei rânduri de text, unul sub altul: „Piața și concurenții”; „Cifrele pe trei ani”; „Lista de verificări” - un buton (doar de decor) pe care scrie „Deschide analiza” - fundal deschis, design curat și modern, fontul Inter Fără JavaScript. Doar HTML + CSS. ``` De ce funcționează promptul: Uită-te cât de concret e promptul: texte exacte, culori exacte, structură exactă și o constrângere explicită (fără JavaScript). Fiecare detaliu pe care îl dai scoate o ghicire pe care Claude ar fi făcut-o în locul tău. Concretețea nu e pedanterie, e predictibilitate. Și nu te speria dacă promptul e plin de cuvinte pe care nu le știi încă (HTML, CSS, artifact): nu trebuie să le înțelegi ca să le FOLOSEȘTI azi. Apasă pe orice cuvânt punctat pentru ideea într-un rând, parchează restul (vezi parcarea de cuvinte în Prezentare), și miercuri le întrebi cum trebuie. În planul ăsta întâi folosești, înțelegi peste câteva zile, la program. Pune răspunsul la îndoială: Când apare cardul, întreabă: „Ce decizii ai luat pe care eu nu le-am specificat?”. Lista pe care o primești (mărimi de font, spații, nuanțe) e o avanpremieră a ce ar fi acoperit un prompt cu adevărat complet. Apoi schimbă UN lucru („fă gradientul mai discret”) în loc să ceri de la zero. Iterarea bate repornirea. ### T03 · Lu · 1h · Prompting · Anatomia unui prompt: desfă rețeta în bucăți Proba rapidă (pentru cine știe deja; 0.5h în loc de 1h): Scrie din cap, pe o foaie, ce trebuie să conțină un prompt complet. Apoi deschide tab-ul „Rețeta întrebărilor” și compară cu cele patru părți (context, scop, formă, constrângeri). Dacă le aveai pe toate patru, chiar cu alte nume, rulează doar punctul 3 din prompt și provocarea. Dacă îți lipsea una, fă lecția întreagă: e cea mai importantă oră a săptămânii. Promptul: ``` Uite un prompt pe care l-am folosit mai devreme (lipesc promptul de la cardul meu, din T02). Fă trei lucruri: 1. Împarte-l în cele patru părți ale unui prompt complet: context, scop, formă, constrângeri. Arată-mi care propoziție e în care parte și ce lipsește. 2. Arată-mi ce ai fi construit dacă aș fi scris doar: „fă-mi un card pentru proiectul meu”. Enumeră cele 10 decizii mari pe care ar fi trebuit să le ghicești. 3. Rescrie promptul meu ca să fie complet, pentru cardul care va fi prima pagină a proiectului (platforma mea de analiză a companiilor): numele platformei, o frază despre ce e, și trei companii analizate. ``` De ce funcționează promptul: Asta e lecția de teorie a planului, comprimată într-o oră: vezi rețeta aplicată pe ceva ce tocmai ai construit. Punctul 2 e cel mai important: lista deciziilor ghicite e exact ce înseamnă „prompt incomplet”. De acum, când un rezultat te dezamăgește, nu spui „greșit”, te întrebi care dintre cele patru părți lipsea. Rețeta întreagă e în tab-ul „Rețeta întrebărilor”, ține-o deschisă. Pune răspunsul la îndoială: Întreabă: „Ordonează cele patru părți ale promptului meu după cât de mult a schimbat fiecare rezultatul.” Apoi decide dacă ești de acord cu ordinea. Să-l contrazici pe Claude, cu voce tare și cu un motiv, e o abilitate pe care planul ăsta ți-o va cere mereu. ### T04 · Lu · 1.5h · Discovery · Proiectul tău pe o foaie: ce construim, pentru cine, numele de lucru Promptul: ``` Vreau să scriu „pagina de o foaie” a proiectului meu, înainte să construiesc orice. Proiectul: platforma mea de analiză a companiilor, adică un site în care stă structura mea de analiză a unei companii (piața, concurenții, cifrele, echipa, riscurile, lista de verificări) și analizele făcute după ea, în care Claude adună și pune în formă, iar eu verific fiecare cifră la sursă și trag concluzia. Ajută-mă să scriu pagina, punându-mi întrebările pe rând (una, aștepți răspunsul, apoi următoarea), nu toate odată: 1. Cum analizezi azi o companie, pas cu pas? Povestește ultima analiză, concret: de unde ai pornit, ce ai citit, cât a durat. 2. Ce capitole are analiza ta și în ce ordine? Ce e deja scris undeva și ce e doar în capul tău? 3. Care pași sunt muncă de adunat și de pus în formă, pe care i-ai da lui Claude, și care sunt judecata ta, pe care n-ai da-o nimănui? 4. De unde iei cifrele și cum îți dai seama că o cifră e greșită? 5. Cine altcineva ar folosi platforma și ce ar trebui să poată face fără tine? 6. Ce NU vreau să fie platforma (o bază de date cu toate firmele, un robot care dă verdicte, un loc pentru date confidențiale)? 7. Cum arată succesul peste o lună, măsurat în ceva ce pot număra? La final, scrie pagina de o foaie (maximum 300 de cuvinte) și propune-mi 5 nume de lucru pentru proiect, cu domeniile .ro sau .com probabil libere. Spune la fiecare cifră sau fapt pe care îl aduci tu dacă e verificat sau ipoteză. Nu lua nicio decizie în locul meu: unde nu știu, scrie „de hotărât”. ``` De ce funcționează promptul: „Pune-mi întrebările pe rând” e un tipar pe care îl vei folosi tot planul: transformă un chestionar sufocant într-o discuție. „Nu lua decizii în locul meu, scrie «de hotărât»” îl oprește pe Claude să umple golurile cu presupuneri plauzibile. Iar „verificat sau ipoteză” e întrebarea nr. 8 din Rețetă, pusă dinainte. Documentul ăsta e materia primă pentru Bruce, joi: cu cât e mai cinstit (mai multe „de hotărât”), cu atât Bruce lucrează mai bine. Pune răspunsul la îndoială: Alege un nume de lucru (îl poți schimba oricând) și salvează pagina în folderul tău ca „proiectul-meu-v0.md”. Apoi întreabă: „Ce întrebare ar fi trebuit să-mi pui și nu mi-ai pus-o?”. Dacă răspunsul e bun, pagina ta are o gaură: astup-o acum. ### T05 · Ma · 1.5h · Pregătire · Instalează Claude Code și pachetul BGN (agenții lui Bogdan) Proba rapidă (pentru cine știe deja; 0.5h în loc de 1.5h): Ai deja Claude Code? Sari peste instalarea aplicației și fă doar pachetul BGN: acceptă invitația de la GitHub, trage ghidul de instalare într-o sesiune nouă, lasă-l să termine și repornește aplicația. Provocarea rămâne: întrebarea despre ce are voie Claude să facă fără să te întrebe. Întâi, fără Claude: - Verifică e-mailul: trebuie să ai o invitație de la GitHub pentru repo-ul BGN-ro/agenti-bgn (vine după mesajul de luni cu numele tău de utilizator). Acceptă invitația. Dacă n-a venit, scrie-i lui Bogdan înainte să continui; până răspunde, poți face T08, Project-ul din claude.ai, care nu depinde de ea. - Instalează aplicația Claude pentru Windows (claude.ai/download). Deschide-o, intră cu contul tău și apasă pe tab-ul „Code”: ăsta e Claude Code. Dacă îți cere să instaleze unelte în plus, lasă-l; dacă îți cere parola calculatorului, o scrii tu. - Descarcă de pe serban.bgn.ro „ghidul de instalare a agenților” (linkul e în Prezentare) și pune-l în folderul tău. Pornește o sesiune nouă în tab-ul Code, în folderul tău, și trage fișierul în fereastră. - În timpul instalării: când Claude îți dă un cod și se deschide o pagină GitHub, scrii codul acolo și apeși Authorize. Când Claude cere voie să ruleze o comandă, apeși Allow. Când spune „GATA”, închizi complet aplicația Claude și o deschizi din nou. Promptul: ``` Instalează după fișierul ăsta. Explică-mi simplu ce faci la fiecare pas, fără termeni tehnici, și cere-mi ceva doar când chiar nu se poate altfel. Înainte să rulezi prima comandă, spune-mi în trei rânduri ce o să se întâmple și ce voi avea la final. ``` De ce funcționează promptul: Azi faci saltul de la „vorbesc cu un AI în browser” la „am un constructor pe calculatorul meu”. Claude Code lucrează în terminal, creează fișiere adevărate și rulează comenzi; pachetul BGN îi dă patru agenți (Bruce, SuperNicu, SuperBoris, Louis), regulile de lucru ale lui Bogdan și design system-ul bgn-33. Observă promptul: chiar și la o instalare ceri planul înainte (întrebarea nr. 6) și explicații în cuvinte obișnuite. Pune răspunsul la îndoială: După repornire, scrie într-o sesiune nouă: „Ce AI VOIE să faci pe calculatorul meu fără să mă întrebi, și ce nu?”. Răspunsul ăsta e contractul vostru. Dacă ceva din el nu-ți convine, ai voie să-l schimbi în T07, în CLAUDE.md. Dacă pachetul s-a instalat (vezi turul din T06), tot restul zilei lucrezi în Claude Code, nu în browser. ### T06 · Ma · 1h · Agenții · Turul agenților: cine e în echipa ta, ce știe fiecare și când îl chemi Întâi, fără Claude: - Pornește o sesiune nouă în tab-ul Code, în folderul tău. Prima întrebare, înainte de tur: „Ai primit regulile BGN la pornire și ai skill-urile bruce, supernicu și superboris?”. Dacă răspunsul e „nu” la oricare, reia T05 înainte să mergi mai departe. - Ține deschis tab-ul „Agenții” de aici: ce îți spune Claude trebuie să se potrivească cu ce scrie acolo. Unde nu se potrivește, notează și întreabă-l pe Bogdan vineri. Promptul: ``` Tocmai am instalat pachetul BGN al lui Bogdan și vreau să-mi fac turul echipei înainte să am nevoie de ea. Sunt Șerban, nu sunt programator, construiesc platforma mea de analiză a companiilor. 1. Enumeră ce am primit prin pachet: agenți, skill-uri, reguli, design system. Pentru fiecare, un rând: ce e, în cuvinte obișnuite. 2. Pentru fiecare dintre Bruce, SuperNicu și SuperBoris: ce treabă duce de la cap la coadă, în ce moment al unui proiect îl chem, cum îl pornesc (comanda exactă), ce îmi va cere mie și ce îmi dă la final. Dă-mi câte un exemplu concret pe proiectul meu, nu pe unul generic. 3. Regulile BGN: alege trei care schimbă vizibil felul în care lucrezi cu mine de acum și spune-mi ce voi observa diferit. 4. Pe care dintre agenți NU ar trebui să-l folosesc săptămâna asta și de ce. Apoi trei probe, pe rând, cu „gata” de la mine între ele: a) /bruce cu o cerere mică de tot: „vreau ca numele companiei să fie scris cu litere mai mari în fișa ei”. Vreau să văd cum cântărește mărimea cererii și dacă pornește procesul întreg pentru ceva mic. b) Cheamă SuperNicu și întreabă-l doar atât: „ce ai avea nevoie de la mine ca să poți construi?”. Nu construi nimic. c) Dă-i lui SuperBoris cardul meu din T02 (lipesc HTML-ul) și cere-i o verificare scurtă, doar ca să văd ce fel de lucruri observă. ``` De ce funcționează promptul: Agenții sunt motivul pentru care primești pachetul, și cel mai bun moment să afli cine e în echipă e înainte să ai nevoie de ea, nu în mijlocul unei probleme. Fiecare agent e un Claude cu un rol și o metodă; tu rămâi cel care îi dă direcție. Cele trei probe sunt alese ca să vezi caracterul fiecăruia: Bruce ar trebui să NU facă proces mare pentru o cerere mică, SuperNicu ar trebui să ceară un PRD și un prototip înainte să construiască, iar SuperBoris ar trebui să găsească ceva de zis chiar și la un card simplu. Dacă vreunul se poartă altfel, ai prima ta observație pentru vineri. Pune răspunsul la îndoială: Întreabă fiecare agent: „Ce NU faci?”. Un agent care știe ce nu face e mai de încredere decât unul care promite tot. Notează cele trei răspunsuri în parcarea de cuvinte; vineri, după ce ai lucrat cu Bruce două zile, compari ce a spus că nu face cu ce a făcut de fapt. ### T07 · Ma · 1.5h · Claude Code · Primul proiect în Claude Code: folder, regulile tale (CLAUDE.md), primul punct de salvare (git) Proba rapidă (pentru cine știe deja; 0.5h în loc de 1.5h): Fără promptul nostru: pornește proiectul în folder, scrie CLAUDE.md cu tot ce cere punctul 2 (verifică lista, mai ales regula de conținut a proiectului), pune proiectul-meu-v0.md în folder, fă două commit-uri și întoarce-te la primul după o stricăciune făcută intenționat. Dacă te-ai întors fără să cauți comanda, știi git cât trebuie pentru planul ăsta. Promptul: ``` Pornim proiectul (platforma mea de analiză a companiilor) în folderul ăsta. Vreau să înțeleg fiecare pas, deci: înainte de fiecare comandă, spune-mi într-un rând ce face și de ce, și așteaptă „ok”. 1. Când mă întrebi pentru cine e proiectul, răspunsul e: „altul” (e al meu), prototip, design system bgn-33 pentru început (în săptămâna 2 îmi fac stilul meu). 2. Scrie fișierul CLAUDE.md cu regulile mele de lucru, în română. Trebuie să conțină: cine sunt și ce construiesc; explică termenii la prima apariție; arată-mi planul înainte de orice schimbare mare; nu șterge și nu rescrie fișiere întregi fără să mă întrebi; după fiecare pas care merge, propune un punct de salvare (commit); regula de conținut a proiectului: nicio cifră și nicio afirmație despre o companie nu intră în platformă fără sursa ei, deschisă și comparată de un om; răspunde-mi în română. 3. Pornește git în folder și fă primul punct de salvare. Explică-mi ce e un commit folosind o comparație cu versiunile unui model din Excel („model_v7_final”), dar ținute ordonat, fiecare cu un rând despre ce s-a schimbat. 4. Pune în folder pagina de o foaie (proiectul-meu-v0.md) și fă al doilea commit. 5. La final, arată-mi istoricul punctelor de salvare și spune-mi cum m-aș întoarce la primul dacă stric ceva. ``` De ce funcționează promptul: CLAUDE.md e cel mai important fișier din proiect: e promptul permanent al constructorului tău, scris de tine, în limba ta. Tot ce îți displace la felul în care lucrează Claude se repară acolo, o dată. Observă regula de conținut: e pusă din prima zi, ca Claude s-o știe înainte să scrie primul rând din proiect. Iar git e motivul pentru care poți îndrăzni: cu puncte de salvare, orice greșeală costă o comandă, nu o zi. Pune răspunsul la îndoială: Strică ceva intenționat: cere-i lui Claude să șteargă o propoziție din proiectul-meu-v0.md, apoi cere-i să revină la punctul de salvare de dinainte. Verifică tu, cu ochii tăi, că propoziția s-a întors. Abia acum crezi în git, pentru că l-ai văzut, nu pentru că ți s-a spus. ### T08 · Mi · 1h · Pregătire · Project-ul tău în claude.ai: un Claude cu memorie Proba rapidă (pentru cine știe deja; 0.25h în loc de 1h): Fă Project-ul fără ghid: urcă cele două fișiere (planul ca text și proiectul-meu-v0.md), scrie instrucțiunile personalizate cu tot ce cere punctul 3, apoi rulează testul din provocare. Dacă Claude a definit termenii fără să i-o ceri, ai terminat. Promptul: ``` Vreau să fac un Project în claude.ai dedicat proiectului meu. Ghidează-mă pas cu pas, așteptând „gata” de la mine după fiecare pas: 1. Cum creez Project-ul în interfața claude.ai. 2. Ce documente urc în baza lui de cunoștințe. Am două fișiere în folderul meu: planul ăsta de învățare, descărcat de pe serban.bgn.ro (plan-serban.md) și pagina de o foaie a proiectului (proiectul-meu-v0.md). 3. Scrie-mi textul exact de instrucțiuni personalizate pe care să-l lipesc. Trebuie să spună: sunt Șerban, analizez companii în care s-ar putea investi, nu sunt programator; construiesc platforma mea de analiză a companiilor; definește orice termen tehnic la prima apariție; înainte de orice lucru mare, arată-mi planul; nicio întrebare de-a mea nu e prea simplă; când greșesc, spune-mi direct; la orice cifră sau fapt spune dacă e verificat sau ipoteză. ``` De ce funcționează promptul: Instrucțiunile personalizate sunt un prompt permanent: scrii o dată cine ești și cum vrei răspunsurile, și fiecare conversație din Project pornește de acolo. Asta e diferența dintre „folosesc Claude” și „am Claude-ul meu”. Observă și „așteaptă «gata» după fiecare pas”: îl transformă pe Claude dintr-un furtun într-un ghid răbdător. Pune răspunsul la îndoială: Testează: în noul Project, pune o întrebare al cărei răspuns va conține termeni tehnici („cum ar ține minte platforma ce am făcut ieri?”). A definit termenii fără să i-o ceri? Dacă nu, întreabă: „Ce parte din instrucțiunile mele ar trebui întărită ca să faci asta mereu?”. ### T09 · Mi · 2h · Tracker · Tracker v1: construiește o aplicație cu memorie (localStorage) Proba rapidă (pentru cine știe deja; 0.75h în loc de 2h): Scrie tu promptul trackerului, pe blocuri (FUNCȚIONALITATE, DESIGN), fără să-l citești pe al nostru, și cere-l dintr-o singură încercare. Trackerul îți trebuie oricum, pe el înveți JSON și baza de date mai târziu. Apoi compară cele două prompturi și fă provocarea. Promptul: ``` Construiește-mi un artifact HTML de sine stătător (HTML + CSS + JS, fără librării externe): un tracker pentru planul meu de 4 săptămâni (atașez lista sarcinilor, din plan-serban.md). FUNCȚIONALITATE: - arată lista sarcinilor grupate pe săptămână și zi - fiecare sarcină: o bifă, codul (T01…), numele și orele estimate - apăs bifa = făcută; starea se salvează în localStorage sub cheia „serban_tracker” - când reîncarc pagina, bifele sunt tot acolo - sus: „X din Y ore făcute săptămâna asta” și un procent general DESIGN: - accent #2F5FD0, fontul Inter, carduri curate și moderne, umbre discrete, colțuri rotunjite - bife stilizate (nu cele implicite din browser) Rezultatul final: un singur fișier HTML pe care îl deschid în Chrome și merge. ``` De ce funcționează promptul: Promptul are secțiuni etichetate (FUNCȚIONALITATE și DESIGN) și Claude îți oglindește structura. Să scrii prompturi pe blocuri e cel mai ieftin upgrade al rezultatelor tale. Observă și ultimul rând: descrierea experienței finale („îl deschid în Chrome și merge”) e și ea o constrângere. De ce un tracker, când planul are deja bife? Pentru că e prima ta aplicație cu memorie, și pe ea înveți trei lucruri la rând: localStorage (azi), JSON (T21) și baza de date în cloud (T35). Bifa pe care o vede Bogdan rămâne cea din plan; trackerul e al tău, cu notițele tale. Pune răspunsul la îndoială: Înainte să-l accepți, întreabă: „Dacă deschid fișierul ăsta pe telefon în loc de laptop, bifele mele vor fi acolo?”. Răspunsul e nu, și a-l face pe Claude să explice DE CE (localStorage trăiește într-un singur browser, pe un singur aparat) e prima ta lecție adevărată de sisteme. Apoi întreabă-l de ce bifele din planul ăsta SE văd și pe telefon. Diferența dintre cele două răspunsuri e tot ce construiești în săptămâna 3. ### T10 · Mi · 0.5h · Iterare · Schimbă fără să strici: iterare pe tracker Promptul: ``` Uite trackerul meu care funcționează (atașez versiunea curentă). Vreau O SINGURĂ schimbare: Adaugă fiecărei sarcini un câmp mic de notițe, un loc unde pot scrie scurt („mi-a luat două sesiuni”, „întreb pe Bogdan”), salvat în localStorage împreună cu bifele. Reguli: - păstrează absolut tot ce merge acum: bifele, procentul, designul - nu rescrie fișierul de la zero; spune-mi exact ce ai schimbat și unde - înainte de cod, spune-mi în două rânduri cum ai de gând să faci. ``` De ce funcționează promptul: „Păstrează tot ce merge” și „spune-mi ce ai schimbat” sunt cele două propoziții care te apără de cel mai frecvent accident cu Claude: ceri o schimbare mică și primești o rescriere care strică trei lucruri care mergeau. Iar „înainte de cod, planul” e întrebarea nr. 6 din Rețetă, pe care o vei pune la orice cerere mare, pentru totdeauna. Pune răspunsul la îndoială: După ce primești versiunea nouă, întreabă: „Ce ai schimbat ce NU ți-am cerut?”. Aproape întotdeauna există ceva: o culoare, un spațiu, un text. Decide tu dacă schimbările nepoftite rămân. Tu ești supervizorul. ### T11 · Mi · 0.5h · Curaj · Întrebările curajoase: golește parcarea de cuvinte (30 de minute) Promptul: ``` Uite parcarea mea de cuvinte, adunate din primele trei zile (lipesc lista). Explică-mi fiecare cuvânt în două-trei rânduri, folosind ca exemplu ceva ce AM CONSTRUIT EU săptămâna asta (cardul, proiectul din Claude Code, trackerul), nu exemple generale. După fiecare trei cuvinte, oprește-te și întreabă-mă dacă e clar; dacă spun „nu”, explică altfel, nu mai pe larg. ``` De ce funcționează promptul: Cuvintele noi vin mai repede decât pot fi explicate, intenționat. Regula planului: un cuvânt necunoscut nu blochează niciodată o sarcină. Îl folosești câteva zile, apoi îl explici cu un exemplu din ce ai construit, și explicația prinde de zece ori mai bine decât în ziua 1. „Explică altfel, nu mai pe larg” e întrebarea nr. 3 din Rețetă: ai voie să spui „tot nu e clar” de cinci ori. Pune răspunsul la îndoială: Alege cuvântul care ți se pare cel mai bine explicat și spune-i lui Claude: „Acum explică-mi-l ca și cum aș avea 10 ani.” Dacă explicația de 10 ani e mai clară decât prima, ceva din prima era umplutură. Învață să ceri de la început versiunea de 10 ani. ### T12 · Jo · 2h · Bruce · Nevoia · Bruce, partea 1: nevoia (cine are problema și ce vrea să obțină) Promptul: ``` /bruce hai să definim platforma mea de analiză a companiilor. Pornesc de la pagina mea de o foaie (proiectul-meu-v0.md, în folder). Ce știu până acum: când analizez o companie parcurg cam aceiași pași de fiecare dată, dar structura e împrăștiată prin fișiere și în capul meu; mult timp se duce pe adunat informații despre piață și concurenți și pe mutat cifre din situațiile financiare în tabele; vreau ca partea de adunat s-o pregătească Claude, iar eu să verific și să judec. Vreau să trecem azi doar prin partea de Nevoie. Propune tu la fiecare pas, eu confirm sau corectez. Nu trece la research și la produs azi. Două lucruri despre mine: nu sunt programator, deci explică termenii; și vreau să văd motivul fiecărei propuneri, nu doar propunerea. ``` De ce funcționează promptul: Bruce e un Claude cu o metodă: nu te lasă să sari la ecrane înainte să știi pentru cine și pentru ce. Observă că îi dai TU limitele: „doar Nevoia azi”, „propune tu, eu confirm”. Un agent bun primește direcție, nu doar o idee. Teoriile din spate (Jobs to Be Done, segmentare, poziționare) sunt în bibliotecă; tu le simți ca întrebări bune. Pune răspunsul la îndoială: Când Bruce propune la ce trebuie să fie proiectul cel mai bun, contrazice-l o dată, cu un motiv din viața ta („la noi nu se face așa, se face așa”). Vezi dacă își schimbă propunerea cu un argument sau doar cedează. Dacă cedează instantaneu, întreabă: „Ai greșit sau doar ești de acord cu mine?” (semnul nr. 3 din „Semne că Claude ar putea greși”). ### T13 · Jo · 2h · Bruce · Research · Bruce, partea 2: cum rezolvă alții problema (și temă: trei oameni reali) Promptul: ``` /bruce continuăm cu research-ul pentru proiectul meu (platforma mea de analiză a companiilor). Nevoia confirmată ieri e în fișierul de lucru. Vreau harta completă a felului în care se rezolvă azi problema asta: tabelele și modelele din Excel, șabloanele de notă de investiție din Word sau PowerPoint, listele de verificări de due diligence, bazele de date financiare cu plată (de exemplu PitchBook sau Capital IQ), site-urile publice cu situațiile financiare ale firmelor, un Project în claude.ai sau ChatGPT cu documentele urcate. Pentru fiecare: ce face bine, ce face prost, cât costă, ce aș lua de acolo. La final: ce atribute contează pentru utilizatorii mei (ordonate), unde e golul și la ce ar trebui să fim cei mai buni. Spune-mi la fiecare afirmație dacă e verificată (cu sursa) sau ipoteză. Apoi pregătește-mi 5 întrebări pentru discuții față în față cu trei oameni care analizează companii: colegi sau prieteni din domeniu, după regulile Mom Test: despre viața lor, nu despre ideea mea; despre ce au făcut concret ultima dată, nu despre ce ar face. ``` De ce funcționează promptul: Două lucruri de furat pentru totdeauna: „verificat sau ipoteză, la fiecare afirmație” (Claude spune prețuri și cifre fluent chiar când nu e sigur, întrebarea nr. 8) și Mom Test. Tema pentru vineri: pune cele 5 întrebări la trei oameni reali, față în față sau la telefon, și notează răspunsurile cuvânt cu cuvânt. Fără asta, PRD-ul de mâine e o poveste frumoasă. Pune răspunsul la îndoială: Alege afirmația cea mai spectaculoasă din research (un preț, un număr de utilizatori, o funcție „pe care n-o are nimeni”) și verific-o tu la sursă, 10 minute. Dacă era greșită, spune-i lui Bruce și cere-i să corecteze harta. Tocmai ai făcut ce face un supervizor. ### T14 · Vi · 2.5h · Bruce · Produs · Bruce, partea 3: PRD-ul și prototipul (pe care îl atingi) Promptul: ``` /bruce trecem la Produs pentru proiectul meu (platforma mea de analiză a companiilor). Nevoia și research-ul sunt în fișierul de lucru; uite și ce am aflat de la cei trei oameni (lipesc notițele, cuvânt cu cuvânt). Vreau: 1. Deciziile de structură, în cuvinte, numerotate (D1, D2…), fiecare cu motivul: ce ecrane are platforma și în ce ordine le vede omul, ce capitole are o analiză, cum se vede de unde vine fiecare cifră, cum arată comparația între companii, ce NU face prima versiune. 2. Propune-mi o referință de layout (o pagină sau o aplicație reală după care ne luăm) și așteaptă „ok”. 3. Apoi prototipul HTML, pe design system-ul bgn-33 deocamdată: ecranele principale, clickabile, pe lățime de telefon întâi, cu stările goale și de eroare. Fiecare ecran răspunde la „ce vede omul, ce poate apăsa, ce se întâmplă”. 4. La final: PRD-ul (scurt, în limbaj obișnuit, cu deciziile numerotate) și jurnalul de decizii, salvate în folder și cu punct de salvare. ``` De ce funcționează promptul: Azi ai primul livrabil adevărat: un prototip pe care îl poți arăta cuiva și un PRD pe care îl vei corecta în fiecare vineri. Observă ordinea pe care o impui: decizii în cuvinte → referință confirmată → abia apoi ecrane. E ordinea care evită cel mai scump accident: ecrane frumoase pentru un produs nedefinit. Și observă că „bgn-33” e o singură vorbă pentru tine, dar pentru Claude înseamnă un catalog întreg de componente gata făcute. Pune răspunsul la îndoială: Deschide prototipul pe telefon și joacă, cu voce tare, rolul omului care îl folosește: ai o oră până la o discuție despre o companie și vrei să vezi pe o singură pagină cifrele ei, ce ai verificat deja și ce a rămas de întrebat. Fiecare moment în care eziți e o problemă de produs, nu de design. Notează trei astfel de momente și cere-i lui Bruce să le rezolve înainte de vineri seara. ### T15 · Vi · 1h · Review · Review-ul de vineri: cu Claude ca public, și rezumatul pentru Bogdan Promptul: ``` Pregătește review-ul meu de vineri. Îl fac cu tine ca public sceptic, iar lui Bogdan îi trimit rezumatul, pe WhatsApp. Din conversațiile și fișierele săptămânii, scrie-mi: 1. Un rezumat de 5 rânduri a ce am construit (cardul, trackerul, proiectul, PRD-ul și prototipul). 2. Cel mai bun prompt al meu din săptămâna asta și de ce a fost bun (după rețeta celor 4 părți). 3. Un moment în care ai greșit sau ai presupus ceva ce n-am spus, și cum l-am prins (sau nu). 4. Cele 3 întrebări deschise din PRD la care am nevoie de părerea lui Bogdan (nu de decizia lui: proiectul e al meu). 5. Parcarea mea de cuvinte, cu ce a rămas neclar. Apoi fii tu publicul sceptic: pune-mi cele trei întrebări pe care le-ar pune cineva care vede prototipul prima oară, și spune-mi unde răspunsul meu a fost slab. ``` De ce funcționează promptul: Review-ul nu e examen, e ritual: demo, cel mai bun prompt, o greșeală a lui Claude. Punctul 3 e cel care te face bun: săptămână de săptămână, lista „unde a greșit Claude și cum l-am prins” devine instinct. Iar Claude ca public sceptic e un truc de profesionist: întrebările grele le auzi întâi de la cineva care nu contează. Pune răspunsul la îndoială: Când Bogdan îți răspunde la rezumat cu o părere despre proiect, nu o accepta pe loc: întreabă „de ce?” și notează motivul lângă decizie în jurnal. O decizie fără motiv notat se va lua din nou peste două săptămâni, de la zero. ### T16 · Vi · 0.5h · Jurnal · Jurnalul săptămânii 1 (5 rânduri, în repo) Promptul: ``` Creează în folder fișierul jurnal/saptamana-1.md și scrie-l ÎMPREUNĂ cu mine, nu în locul meu: pune-mi pe rând cele 5 întrebări de mai jos, eu răspund în cuvintele mele, tu doar corectezi ortografia și pui textul în fișier. 1. Ce am construit săptămâna asta (în cuvinte pentru un prieten care nu știe nimic despre programare)? 2. Ce cuvânt nou înțeleg acum și pot explica? 3. Unde l-am prins pe Claude greșind? 4. Cel mai bun prompt al meu și de ce. 5. Ce schimb săptămâna viitoare în felul în care lucrez? La final, punct de salvare cu mesajul „Jurnal săptămâna 1”. ``` De ce funcționează promptul: Jurnalul e în cuvintele tale, pentru că asta e dovada că ai înțeles, nu că ai citit. „Scrie-l împreună cu mine, nu în locul meu” e o instrucțiune pe care o vei da des: există lucruri la care vrei ca Claude să fie secretar, nu autor. În săptămâna 4, cele patru jurnale devin pagina ta publică de învățare. Pune răspunsul la îndoială: Recitește răspunsul la întrebarea 1. Dacă prietenul imaginar ar întreba „adică?”, rescrie-l. Testul e simplu: fără niciun cuvânt punctat în el. ## Săptămâna 2: De la prototip la site public (Nivel 2: completezi spațiile) Prototipul devine proiect: schelet, datele separate de cod (analize.json), server local. Primul conținut, scris cu Claude și verificat de tine la sursă. GitHub, apoi Vercel: marți seara proiectul e pe internet și îl deschizi de pe telefon. Primele două funcții mari: lista de verificări și indicatori și comparație. Ziua de Debug: trei defecte plantate, tu le găsești. Stilul tău, scris ca reguli înainte de cod. Vineri: trei oameni folosesc proiectul pe telefon sub ochii tăi, PRD v2. Livrabile: proiectul pe localhost și pe o adresă publică · primul conținut verificat · repo pe GitHub, deploy automat · lista de verificări, indicatori și comparație · stil.md aplicat · tracker v2 · PRD v2 · jurnalul săptămânii 2 ### T17 · Lu · 2h · Schelet · De la prototip la proiect adevărat: scheletul și serverul local Promptul: (completează spațiile) ``` Trecem de la prototipul HTML făcut cu Bruce la proiectul real (platforma mea de analiză a companiilor), în folderul proiectului. Înainte de orice fișier, arată-mi planul și așteaptă „ok”. Ce vreau: - o structură simplă, pe care s-o pot explica unui prieten: o pagină principală (index.html), stilurile (stil.css), codul (app.js) și DATELE separate de cod, într-un folder date/: analizele stau în JSON (analize.json) - pornești un server local și îmi spui adresa la care văd proiectul în Chrome; explică-mi de ce nu deschid fișierul direct - prima bucată care merge cap-coadă, citită din analize.json: [CE COMPANIE ANALIZEZI PRIMA, DE EXEMPLU UNA PE CARE O CUNOȘTI DEJA BINE], cu 4–5 analize de probă - fiecare ecran respectă prototipul; unde te abați, spune-mi de ce - la final: punct de salvare și, în trei rânduri, ce e „schelet” și ce lipsește încă față de PRD Context despre mine: [CE AI ÎNVĂȚAT SĂPTĂMÂNA TRECUTĂ DESPRE CUM VREI SĂ-ȚI VORBEASCĂ: DE EXEMPLU „EXPLICĂ COMENZILE ÎNAINTE SĂ LE RULEZI”]. ``` De ce funcționează promptul: Două idei mari într-o sarcină. Prima: datele separate de cod. Analizele nu sunt „în site”, sunt într-un fișier pe care îl poți deschide, citi și da altcuiva; când înțelegi asta, înțelegi cum sunt construite toate aplicațiile. A doua: serverul local, adresa localhost care există doar pentru tine. De acum, „merge la mine” și „merge pe internet” sunt două lucruri diferite, și vei învăța să le verifici pe amândouă. De aici încolo poți chema și SuperNicu pentru bucăți întregi, dar săptămâna asta construiești pas cu pas, ca să vezi din ce e făcut. Pune răspunsul la îndoială: Deschide date/analize.json singur, în editor, și schimbă de mână un cuvânt. Reîncarcă pagina. S-a schimbat? Tocmai ai editat un site fără să scrii cod. Apoi întreabă-l pe Claude: „Ce s-ar strica dacă aș greși o virgulă în fișierul ăla?” și pune-l să-ți arate eroarea în consolă. ### T18 · Lu · 2h · Conținut · Primul conținut adevărat: forma lui și regula „verificat la sursă” Promptul: (completează spațiile) ``` Hotărâm cum arată un element de conținut (analiză) și scriem primele trei analize, pentru companii din același sector. 1. Propune forma (câmpurile și ce înseamnă fiecare): numele companiei și codul ei fiscal, sectorul, ce face și cine o deține, piața, concurenții, cifrele pe ultimii trei ani (fiecare cu sursa ei), echipa, riscurile, lista de verificări și „verificat: da/nu”. Explică-mi de ce fiecare câmp merită să existe și ce se întâmplă dacă lipsește. 2. Apoi scriem primele trei analize, pentru companii din același sector, după regulile mele: [CE CAPITOLE ARE ANALIZA TA, ÎN CE ORDINE ȘI CÂT DE LUNG E FIECARE]. Propui câte puțin odată, în JSON, fiecare cu „verificat: nu”. 3. Eu verific fiecare analiză la sursă (situațiile financiare depuse și rapoartele publicate de companie): pun fiecare cifră lângă documentul din care vine și o compar, iar la afirmațiile despre piață și concurenți deschid sursa citată și văd dacă spune chiar asta. Îți spun „bun” sau „greșit: …”. Doar ce a primit „bun” primește „verificat: da” și rămâne în analize.json. 4. La final, un rezumat: câte ai propus, câte au fost bune din prima, ce tip de greșeli ai făcut (cifre din alt an sau în altă monedă? concurenți care nu sunt de fapt concurenți? mărimea pieței fără sursă?). Reguli pentru conținut: [CE TE ENERVEAZĂ LA ANALIZELE FĂCUTE ÎN GRABĂ SAU DE UN AI: CIFRE FĂRĂ SURSĂ, „PIAȚĂ ÎN CREȘTERE” FĂRĂ NICIUN NUMĂR, CONCURENȚI ALEȘI LA ÎNTÂMPLARE? SCRIE-LE CA REGULI]. ``` De ce funcționează promptul: Aici înveți cel mai important lucru despre conținut făcut cu AI: Claude propune, omul verifică la sursă, și doar ce e verificat ajunge în proiect. Claude știe foarte multe, iar o parte e veche, aproximativă sau pur și simplu inventată cu încredere. Verificarea ta e singura apărare. Punctul 4 e oglinda: după prima porție de conținut știi exact ce tip de greșeală face Claude pe subiectul tău, și o poți preveni în prompturile următoare. Pune răspunsul la îndoială: Alege bucata de conținut de care ești cel mai mulțumit și întreabă: „Ce ar spune despre asta cineva care se pricepe cu adevărat?”. De multe ori primești o obiecție la care nu te-ai gândit. Dacă găsește ceva ce tu n-ai văzut, standardul tău de „bun” era prea jos. Ridică-l și reverifică restul. ### T19 · Ma · 1.5h · GitHub · Proiectul în cloud: repo privat pe GitHub Proba rapidă (pentru cine știe deja; 0.5h în loc de 1.5h): Urcă proiectul pe GitHub fără ghid: repo privat, .gitignore verificat (întreabă-l pe Claude ce ar fi trebuit exclus și n-ai exclus), README de 5 rânduri, primul push. Apoi fă provocarea: ștergi un fișier și îl aduci înapoi. Dacă ai făcut tot în 30 de minute, treci mai departe. Promptul: (completează spațiile) ``` Vreau să pun proiectul pe GitHub, ca repo privat, din două motive: copie de siguranță și ca Vercel să-l poată publica de acolo. Explică-mi înainte: ce e un „remote”, de ce repo-ul e privat deși site-ul va fi public, și ce NU trebuie să ajungă niciodată pe GitHub (chei, parole). Pașii, cu „ok” de la mine după fiecare: 1. verifici că există .gitignore și că exclude [CE CREZI TU CĂ NU TREBUIE URCAT; DACĂ NU ȘTII, SCRIE „NU ȘTIU, PROPUNE TU ȘI EXPLICĂ”] 2. creezi repo-ul privat pe contul meu din terminal (gh) și faci primul push 3. îmi arăți pe github.com unde văd fișierele, istoricul punctelor de salvare și ce s-a schimbat la fiecare 4. îmi arăți regula de lucru: când termin un pas care merge, îl salvez (commit) și îl trimit (push); și cum aduc proiectul pe alt calculator (clone), pe un exemplu mic 5. scrii în README.md ce e proiectul, în 5 rânduri, pentru un om care îl deschide prima oară ``` De ce funcționează promptul: Până azi, proiectul exista într-un singur loc: laptopul tău. De azi există în două, iar GitHub e cel care ține adevărul. Dacă laptopul dispare mâine, pierzi o oră, nu trei săptămâni. Întrebarea despre chei și parole e esențială acum, cât n-ai niciuna: în săptămâna 3 vei avea, și obiceiul trebuie să existe înaintea lor. Pune răspunsul la îndoială: Șterge un fișier mic de pe laptop (de exemplu README.md), apoi cere-i lui Claude să-l aducă înapoi de pe GitHub. Verifică tu că e identic. Abia acum „am copie de siguranță” e un lucru pe care l-ai văzut funcționând, nu unul pe care îl crezi. ### T20 · Ma · 1.5h · Vercel · Publicare: proiectul tău pe internet, cu Vercel (și de pe telefon) Proba rapidă (pentru cine știe deja; 0.5h în loc de 1.5h): Publică fără ghid: import din GitHub, regula din vercel.json ca doar ramura principală să publice (punctul 2, pe ăsta nu-l sări), testul de pe telefon și un push care apare singur pe adresa publică. Apoi fă provocarea cu prietenul: e partea care contează. Promptul: (completează spațiile) ``` Vreau să public proiectul pe internet cu Vercel, direct din repo-ul de GitHub, ca fiecare push pe ramura principală să publice singur versiunea nouă. Ghidează-mă pas cu pas, cu „gata” de la mine, și explică-mi scopul fiecărui pas într-un rând înainte să-l fac: 1. cont Vercel (intru cu GitHub), import repo, primul deploy; îmi spui adresa publică 2. o regulă în vercel.json ca doar ramura principală să publice (Bogdan cere asta la toate proiectele lui: urcările de pe ramurile de lucru nu creează publicări) 3. verificare: deschid adresa de pe telefonul meu și fac [UN TEST CONCRET PE CARE ÎL ALEGI TU: DE EXEMPLU DESCHIZI FIȘA UNEI COMPANII ȘI GĂSEȘTI ÎNDATORAREA EI ÎN MAI PUȚIN DE UN MINUT]; apoi schimb un text, push, și văd în cât timp apare schimbarea 4. îmi explici diferența dintre adresa de pe Vercel și un domeniu al meu (îl aleg în săptămâna 4) Nu public nimic ce n-am verificat întâi pe localhost. ``` De ce funcționează promptul: Ziua 7 și ai un site pe internet. Lanțul pe care l-ai construit (Claude Code → commit → push → GitHub → Vercel → adresă publică) e exact lanțul pe care îl folosesc echipele profesioniste; diferența e doar cât de multe verificări pun între pași. Ultima propoziție a promptului e prima dintre ele: nimic nu se publică nevăzut local. În săptămâna 4 adaugi teste automate ca a doua verificare. Pune răspunsul la îndoială: Trimite adresa unui prieten care nu știe nimic despre proiect și roagă-l să-ți spună în două rânduri ce crede că e și ce ar apăsa. Dacă răspunsul lui nu seamănă cu PRD-ul tău, ai găsit prima problemă reală a proiectului, la 48 de ore după ce ai început să-l construiești. Asta e viteza care contează. ### T21 · Ma · 1h · Tracker · Tracker v2: stări, momentul bifării, export JSON Promptul: (completează spațiile) ``` Îmbunătățim trackerul (atașez versiunea curentă). De data asta scriu eu specificația: - fiecare sarcină are o stare: [CELE 3 STĂRI PE CARE LE VREI, DE EXEMPLU NEÎNCEPUTĂ / ÎN LUCRU / FĂCUTĂ] și momentul când am bifat-o - un buton „Exportă” care copiază tot progresul ca JSON în clipboard și un buton „Importă” care îl primește înapoi (așa îmi trec bifele de pe laptop pe telefon, până la cloud) - [O FUNCȚIE PE CARE O VREI TU, DIN FOLOSIREA DE O SĂPTĂMÂNĂ: CE ȚI-A LIPSIT?] - păstrezi tot ce merge; spui ce ai schimbat Înainte de cod: explică-mi ce e JSON folosind ca manual chiar exportul trackerului meu, și apoi analize.json al proiectului. ``` De ce funcționează promptul: JSON e formatul în care trăiesc datele pe internet: conținutul proiectului tău, progresul tău, răspunsurile de la API-uri. Îl înveți pe propriile date, de asta prinde. Exportul e și primul pas spre săptămâna 3: când trackerul se mută în cloud, exact acest JSON e ce va călători pe rețea. Pune răspunsul la îndoială: Deschide exportul într-un editor și schimbă de mână o stare, apoi importă-l. A mers? Acum strică intenționat o virgulă și importă din nou. Ce îți spune aplicația? Dacă nu spune nimic util, cere-i lui Claude un mesaj de eroare pe înțelesul omului. Tocmai ai proiectat o stare de eroare. ### T22 · Mi · 2h · Lista de verificări · Lista de verificări, notele și concluzia ta (și de ce bifa nu se vede pe celălalt aparat) Promptul: (completează spațiile) ``` Construim prima funcție mare a proiectului. Înainte de cod, arată-mi planul și așteaptă „ok”. - în pagina unei analize, lista de verificări: [PUNCTELE TALE DE VERIFICAT, ÎN ORDINEA ÎN CARE LE PARCURGI], fiecare cu bifă și cu data bifării - la fiecare capitol al analizei pot scrie o notă a mea, despărțită vizibil de textul analizei - fiecare companie are concluzia mea: de continuat, de urmărit sau de lăsat, cu motivul într-o frază; pe lista de companii se vede câte puncte din listă sunt bifate - starea fiecărei companii (bifele din lista de verificări, notele și concluzia mea) se ține deocamdată în localStorage, cu data la care s-a schimbat - [O REGULĂ A TA PENTRU FUNCȚIA ASTA, DIN CE AI VĂZUT LA ALTERNATIVELE DIN RESEARCH (T13)] - design pe telefon întâi; punct de salvare după fiecare pas care merge La final, răspunde-mi cinstit: dacă bifez un punct pe laptop, la birou, îl văd bifat și pe telefon? De ce nu, și când reparăm asta? ``` De ce funcționează promptul: Ultima întrebare e lecția zilei: ai construit o funcție care pe un singur aparat e perfectă și pe două e aproape inutilă, pentru că localStorage trăiește într-un singur browser. Săptămâna viitoare, exact starea asta devine motivul pentru care înveți ce e o bază de date în cloud. O limitare simțită pe pielea ta se înțelege altfel decât una citită. Și observă regula scrisă de tine: research-ul din săptămâna 1 nu era temă, era materie primă. Pune răspunsul la îndoială: Bifează toate punctele unei companii fără să scrii nicio notă și fără concluzie. Ce arată lista de companii? Dacă arată „complet”, platforma spune că analiza e gata când tu n-ai hotărât nimic. Hotărăște ce înseamnă pentru tine „analiză terminată” (toate bifele? concluzie cu motiv?) și cere-i lui Claude să-ți spună ce a presupus el. ### T23 · Mi · 2h · Indicatori și comparație · Toate companiile: lista, indicatorii calculați, comparația și fișa de o pagină Promptul: (completează spațiile) ``` Construim a doua funcție mare. Înainte de cod, arată-mi planul și lista stărilor prin care trece o analiză (ciornă, în verificare, verificată, închisă cu o concluzie) și așteaptă „ok”. Apoi: - lista companiilor, cu [COLOANELE LA CARE TE UIȚI ÎNTÂI CÂND COMPARI DOUĂ COMPANII]; analizele neverificate apar marcate, nu dispar - indicatorii se calculează din cifrele din analize.json, nu se scriu de mână: creșterea de la an la an, marjele și îndatorarea, după formulele mele: [FORMULELE TALE, SCRISE CA ÎNTR-UN EXCEL] - comparația: aleg două-trei companii și le văd indicatorii unul lângă altul, pe aceiași ani - fișa de o pagină a unei companii, de tipărit sau de trimis: capitolele pe scurt, indicatorii și sursa fiecărei cifre - [CE SE ÎNTÂMPLĂ ÎN STAREA LA CARE NU S-A GÂNDIT NIMENI: SCRIE TU UNA ȘI CE VREI SĂ ARATE PROIECTUL ATUNCI] - fiecare ecran respectă prototipul; unde te abați, spui de ce Testăm împreună, pe telefon, o companie de la listă până la fișa de o pagină, cu o cifră urmărită înapoi până la sursa ei, înainte de punctul de salvare. ``` De ce funcționează promptul: Lista stărilor e cea mai subestimată unealtă de produs: majoritatea bug-urilor și a ecranelor urâte vin din stări la care nimeni nu s-a gândit (ce arată ecranul când nu e nimic de arătat? când e prea mult? când omul revine după o lună?). Le enumeri înainte, și Claude le construiește pe toate. Iar „testăm pe telefon înainte de commit” e regula pe care o vei păstra: funcția e gata când a fost parcursă, nu când a fost scrisă. Pune răspunsul la îndoială: Pune la o companie un an cu pierdere și un an în care o cifră lipsește. Ce arată creșterea și marja? O creștere calculată pornind de la un profit negativ, sau „0%” acolo unde cifra lipsește, arată bine și minte. Întreabă-l pe Claude ce indicatori n-ar trebui calculați deloc în cazurile astea și ce ar trebui să scrie platforma în locul lor. ### T24 · Jo · 2h · Ziua de Debug · Ziua de Debug: Claude te va bate (trei defecte plantate, tu le găsești) Promptul: (completează spațiile) ``` Azi învăț să repar. Fă o ramură nouă în git, numită „debug-day”, și plantează în proiect TREI defecte de tipuri diferite, fără să-mi spui care: unul care dă eroare în consolă, unul care face ceva să nu se vadă (de exemplu o companie dispare din listă), unul care face un calcul greșit (de exemplu marja luată din alt an). Apoi fă commit pe ramura aia și spune-mi doar: „gata, găsește-le”. Le caut singur, cu DevTools deschis. Când mă blochez, îți dau ce văd (mesajul exact din consolă, captura de ecran, ce am apăsat) și tu îmi pui întrebări, nu-mi dai soluția, până o găsesc eu. La final: ștergem ramura și îmi explici ce e o ramură și de ce am făcut asta pe una separată. Apoi scriem împreună, în CLAUDE.md, secțiunea „când ceva nu merge”: [REGULILE PE CARE LE-AI ÎNVĂȚAT AZI, ÎN CUVINTELE TALE]. ``` De ce funcționează promptul: Lucrurile se strică, la program. Diferența dintre un om blocat o zi și unul blocat zece minute e o rutină: citește mesajul exact din consolă, dă-i lui Claude ce vezi, nu ce crezi, și cere întrebări, nu soluții. Ramura separată e lecția bonus: un loc unde poți face prostii fără să atingi versiunea care merge. Întrebarea nr. 9 din Rețetă („explică ce era greșit înainte să repari”) se naște azi. Pune răspunsul la îndoială: După ce le-ai găsit pe toate trei, întreabă: „Care defect ar fi fost cel mai greu de observat de un om care doar folosește proiectul, și de ce?”. Răspunsul e, de obicei, calculul greșit: fișa arată la fel de îngrijit, iar tu compari două companii pe o marjă falsă. Asta e motivul pentru care în săptămâna 4 scrii teste automate. ### T25 · Jo · 2h · Design · Stilul tău: un mic design system, scris ca reguli Promptul: (completează spațiile) ``` Până acum proiectul e pe bgn-33, design system-ul lui Bogdan. Azi îmi fac stilul meu. Nu schimba nimic în cod înainte să-mi arăți regulile. 1. Uite trei referințe vizuale: [TREI LINKURI SAU CAPTURI: UN RAPORT DE ANALIZĂ CARE ÎȚI PLACE CUM ARATĂ, UN SITE FINANCIAR PE CARE ÎL CITEȘTI UȘOR, UN TABEL DE-AL TĂU DE CARE EȘTI MULȚUMIT]. Scoate din ele o paletă de 5–6 culori (cu numele lor și la ce le folosim), două fonturi (titluri și text), colțurile, umbrele, spațiile, și cum arată un rând din lista de companii, un tabel de indicatori, fișa de o pagină. Scrie totul într-un fișier stil.md, în cuvinte obișnuite, cu motivul fiecărei alegeri. 2. Verifică contrastul fiecărei perechi text/fundal pentru felul în care se va citi proiectul (la birou, pe un monitor mare, și pe telefon, între două întâlniri) și spune-mi care pică. 3. Așteaptă „ok” pe reguli. Abia apoi aplică-le în stil.css, ecran cu ecran, și arată-mi diferența pe telefon. 4. Pune în CLAUDE.md: „orice ecran nou respectă stil.md”, ca regula să rămână după azi. Ce NU vreau: [CE ÎȚI DISPLACE LA PLATFORMELE FINANCIARE: PREA MULTE CIFRE PE ECRAN? CULORI ȚIPĂTOARE? TABELE CARE NU ÎNCAP PE TELEFON?]. ``` De ce funcționează promptul: Un design system există ca să nu iei de 40 de ori aceeași decizie și ca proiectul să arate făcut de aceeași mână, de la primul ecran la ultimul. Azi îl scrii tu, mic, în cuvinte, și abia apoi în cod: ordinea asta e toată lecția. Iar contrastul nu e pedanterie: proiectul tău se va citi în condiții reale, nu pe monitorul pe care l-ai construit. Pune răspunsul la îndoială: Alege ecranul cel mai bun și întreabă: „Dacă ar trebui să scoți un element de pe ecranul ăsta, care ar fi și de ce?”. De cele mai multe ori există unul. Scoate-l. Designul bun e mai des scădere decât adunare. ### T26 · Vi · 1.5h · Utilizatori · Mom Test cu proiectul în mână: trei oameni îl folosesc pe telefon, tu taci Promptul: (completează spațiile) ``` Am dat adresa publică la trei oameni (trei oameni care analizează companii: colegi sau prieteni din domeniu) și i-am privit folosind proiectul pe telefonul lor, fără să-i ajut, câte 10 minute: le-am cerut să găsească compania cu cea mai mare îndatorare și să spună de unde vine cifra. Uite notițele mele, cuvânt cu cuvânt, plus unde s-au blocat și ce au întrebat (lipesc). Ajută-mă să fac sinteza, fără să îndulcești nimic: 1. Ce au făcut fără ajutor și ce n-au reușit. Pentru fiecare persoană: a reușit / s-a blocat la / a spus. 2. Care probleme sunt de produs (nu înțeleg ce e sau de ce) și care sunt de interfață (nu găsesc butonul)? 3. Ce au spus politicos și ar trebui ignorat (complimente, „ce frumos”) și ce au făcut concret, care contează. 4. Cele 3 schimbări cu cel mai mare efect, cu motiv, pentru săptămâna viitoare. Reguli: [CE AI OBSERVAT CĂ TE TENTEAZĂ SĂ CREZI, DAR N-AI DOVADĂ]. ``` De ce funcționează promptul: Până acum ai discutat despre proiect; azi l-ai văzut folosit. Diferența dintre „e drăguț” și „n-a găsit ce căuta” e tot ce contează în produs. Regula de a tăcea e cea mai grea și cea mai valoroasă: în secunda în care explici, pierzi informația. Punctul 3 e Mom Test aplicat la propriile notițe: și tu vrei să auzi complimentele, mai ales de la oameni dragi. Pune răspunsul la îndoială: Dintre cele 3 schimbări propuse, întreabă: „Pe care ai propus-o pentru că vrei să ai dreptate și nu pentru că au arătat-o oamenii?”. Claude e surprinzător de cinstit la întrebarea asta. Tu ești? ### T27 · Vi · 1.5h · PRD v2 · PRD v2: corectat cu ce te-a învățat construcția și ce au arătat oamenii Promptul: (completează spațiile) ``` Rescriem PRD-ul ca versiune 2, pe baza a două săptămâni: ce am construit, ce a mers altfel decât am crezut, ce au arătat cei trei oameni. Versiunea 1 rămâne neatinsă în folder; v2 e fișier nou, cu data. 1. Compară PRD-ul v1 cu proiectul care există azi: listează fiecare nepotrivire (ce zice documentul / ce face proiectul) și întreabă-mă, pe rând, care câștigă. 2. Deciziile noi din săptămâna asta (din jurnalul de decizii și din T26) intră numerotate în continuare, fiecare cu data și motivul. 3. Secțiunea „ce NU facem” se actualizează: [CE AI TĂIAT CONȘTIENT SĂPTĂMÂNA ASTA ȘI DE CE]. 4. La final, un „ce s-a schimbat de la v1” de 10 rânduri și punct de salvare. ``` De ce funcționează promptul: Un PRD care nu se schimbă e un PRD pe care nu-l mai citește nimeni. Al tău se corectează în fiecare vineri, cu versiune nouă și istoric, exact cum fac echipele bune. Pasul 1 e esențial și neplăcut: documentul și proiectul s-au îndepărtat în două săptămâni, garantat, iar tu hotărăști care are dreptate, nu Claude. Pune răspunsul la îndoială: Dă PRD-ul v2 cuiva care n-a văzut proiectul și cere-i să-ți spună ce ar construi din el. Unde descrie altceva decât ai tu, documentul e neclar. Repară documentul, nu explica. ### T28 · Vi · 1h · Review · Review-ul de vineri și jurnalul săptămânii 2 Promptul: (completează spațiile) ``` Pregătește review-ul meu de vineri. Îl fac cu tine ca public sceptic, iar lui Bogdan îi trimit rezumatul, pe WhatsApp. Același format ca săptămâna trecută (rezumat în 5 rânduri, cel mai bun prompt, o greșeală a ta și cum am prins-o, 3 întrebări deschise, parcarea de cuvinte), plus două lucruri noi: - demo-ul: ordinea în care arăt proiectul pe adresa publică, de pe telefon, în 5 minute, pornind de la [CE VREI SĂ VADĂ OMUL PRIMA DATĂ ȘI DE CE] - un lucru pe care l-am făcut săptămâna asta fără promptul din plan, și ce am învățat din el Apoi jurnalul: jurnal/saptamana-2.md, împreună, ca săptămâna trecută, cu aceleași 5 întrebări. Punct de salvare „Jurnal săptămâna 2”. ``` De ce funcționează promptul: A doua săptămână are un site pe internet, deci review-ul devine demo. Un demo bun e o poveste în 5 minute, nu un tur al tuturor butoanelor: „uite un om care are problema asta, uite ce face cu proiectul meu”. Alegi tu începutul, pentru că tu știi ce ai vrea să i se întâmple celui care se uită în primele 30 de secunde. Pune răspunsul la îndoială: Trimite-i lui Bogdan adresa publică odată cu rezumatul și roagă-l să-ți scrie primul lucru pe care a încercat să-l apese. Apoi dă telefonul cuiva de lângă tine și taci două minute. Ce notezi în cele două minute valorează cât o săptămână de păreri. ## Săptămâna 3: Date adevărate: bază de date, login cu Google, API (Nivel 3: scrii singur prompturile) Proiectul capătă memorie în cloud: Supabase, tabele proiectate înainte de cod, reguli de acces (RLS) din prima zi, și ce faci pe un aparat apare pe celălalt. Login cu Google, parcurs până la capăt. Documente. Prima ta funcție pe server și primul API: „Întreabă analizele”, cu cheia la loc sigur și cu limită, apoi ciorne de analiză, cu aprobarea unui om. Trackerul v3 în cloud. Primul audit SuperBoris, pe securitate. Vineri: conținutul complet, verificat. Livrabile: Supabase cu RLS · datele pe două aparate · login cu Google cu listă de acces · documente · „Întreabă analizele” prin API · tracker v3 în cloud · raport de audit · conținutul complet și verificat · jurnalul săptămânii 3 ### T29 · Lu · 2h · Bază de date · Prima ta bază de date: Supabase, tabelele și cele două chei Proba rapidă (pentru cine știe deja; 1h în loc de 2h): Scrie tu, pe o foaie, tabelele proiectului: numele, câmpurile, cheile primare și legăturile. Abia apoi cere-i lui Claude părerea („ce ai schimba și de ce?”) și creează-le în Supabase, în Europa. Nu sări regula cheii de serviciu și desenul din docs/baza-de-date.md: îți trebuie la audit. Misiunea: Fă-ți cont pe Supabase, creează proiectul bazei de date și proiectează tabelele împreună cu Claude, ÎNAINTE să scrii vreun rând de cod în proiect. La final știi să explici unui prieten ce e o tabelă, un rând, o cheie primară și de ce există două chei de acces. Promptul tău trebuie să acopere: - contextul: ce date are proiectul azi în localStorage (bifele din lista de verificări, notele și concluziile mele) și de ce pe două aparate asta nu merge - cererea de a-ți explica, înainte de pași, ce e o bază de date relațională, cu o comparație din viața ta, și ce e o cheie primară - propunerea de tabele (de exemplu verificari, note, concluzii), cu câmpurile fiecăreia (cine, când, la ce analiză) și legăturile dintre ele, pe care tu o aprobi înainte de creare - ghidaj pas cu pas în panoul Supabase, cu „gata” de la tine, inclusiv regiunea (Europa) și de ce contează - explicația cheii anon față de cheia de serviciu și REGULA: cheia de serviciu nu ajunge niciodată în fișierele din GitHub sau în pagina din browser - cum salvezi adresa proiectului și cheia anon în proiect (fișier de configurare public, ca în orice aplicație) și de ce e în regulă să fie public Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau să mut datele proiectului din localStorage într-o bază de date în cloud, pe Supabase, ca bifele din lista de verificări, notele și concluziile mele să se vadă pe toate aparatele mele și, mai târziu, ale celor cărora le dau acces. Azi facem DOAR contul, proiectul și tabelele, fără să atingem proiectul. Înainte de pași, explică-mi: ce e o bază de date relațională (cu o comparație cu un tabel de Excel partajat, sau alta mai bună), ce e o cheie primară, și de ce Supabase are două chei de acces și una dintre ele e secretă. Apoi: 1. Propune tabelele: ce țin azi în localStorage și ce voi avea săptămâna asta (de exemplu verificari, note, concluzii). Câmpurile fiecăreia și legăturile dintre ele. Așteaptă „ok”. 2. Ghidează-mă în panoul Supabase: cont, proiect în Europa, tabelele, cu „gata” de la mine după fiecare pas. 3. Spune-mi unde găsesc adresa proiectului și cheia anon, unde le pun în proiect, și regula pentru cheia de serviciu. 4. La final: un desen în text al tabelelor și legăturilor, salvat în docs/baza-de-date.md, și punct de salvare. ``` De ce funcționează promptul: Azi nu scrii cod, și e intenționat: cea mai scumpă greșeală într-o aplicație e un tabel prost gândit, descoperit după ce aplicația l-a umplut. Vei observa că promptul pune explicația înaintea pașilor și aprobarea ta înaintea creării: la nivelul 3, asta trebuie să vină de la tine, nu din plan. Și motivul pentru care faci baza de date e unul pe care l-ai simțit în T22: starea de pe un aparat nu se vedea pe celălalt. Pune răspunsul la îndoială: Întreabă: „Ce se întâmplă dacă peste o lună vreau ca încă un om să poată scrie în proiect? Ce tabel ar trebui să se schimbe?”. Dacă răspunsul e „niciunul, e prevăzut”, tabelele sunt bune. Dacă e „am adăuga o coloană”, cere să fie adăugată azi, cât tabelul e gol. ### T30 · Lu · 2h · Date în cloud · Bifele, notele și concluziile în cloud: platforma citește și scrie în Supabase (cu RLS de la început) Misiunea: Mută bifele din lista de verificări, notele și concluziile din localStorage în Supabase, astfel încât o schimbare făcută pe un aparat să apară pe celălalt în câteva secunde, cu regulile de acces (RLS) activate din prima zi. Până la login-ul de mâine, fiecare aparat e „anonim”, cu un identificator local. Promptul tău trebuie să acopere: - constrângerea de a păstra formatul datelor din săptămâna 2 (ce există deja se mută, nu se pierde) - cererea ca RLS să fie activ din prima zi, cu regula: oricine are linkul poate citi, dar doar cine e autentificat poate scrie (iar până mâine, un identificator anonim per aparat, explicit temporar) - citirea în timp real sau la reîncărcare: alegerea ta, cu avantajele fiecărei variante cerute lui Claude înainte - testul cu două aparate: bifez un punct pe laptop și apare pe telefon; scriu o notă pe telefon și apare pe laptop - ce se întâmplă fără internet: schimbarea se ține local și se trimite la revenire, sau se refuză cu un mesaj clar; decizia ta, notată în jurnal - punct de salvare și o propoziție în README despre unde stau acum datele Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Mutăm bifele din lista de verificări, notele și concluziile din localStorage în Supabase. Tabelele există de azi dimineață (docs/baza-de-date.md). Înainte de cod, planul, și așteaptă „ok”. Reguli: 1. RLS activ din prima zi: oricine are linkul poate citi; doar un utilizator autentificat poate scrie. Până mâine, când facem login, folosim un identificator anonim per aparat, și vreau să-mi spui clar că asta e temporar și ce riscă. 2. Ce e deja în localStorage se mută în Supabase la prima deschidere, fără să se piardă. 3. Explică-mi întâi cele două variante de a vedea schimbarea făcută pe alt aparat (timp real sau la reîncărcare), cu avantaje și dezavantaje, și recomandă una pentru proiectul meu. 4. Fără internet: [decizia mea, după explicația ta: se ține local și se trimite la revenire / se refuză cu mesaj]. 5. Testăm cu două aparate: bifez un punct pe laptop și apare pe telefon; scriu o notă pe telefon și apare pe laptop. Înainte de punctul de salvare. 6. La final, o propoziție în README: unde stau datele acum și ce mai e în browser. ``` De ce funcționează promptul: Aici se vede de ce ai făcut tabelele dimineață: codul de azi e simplu când schema e bună. Două reflexe de nivel 3 trebuie să apară în promptul tău fără să ți le dicteze nimeni: RLS din prima zi (nu „îl punem la final”, pentru că nu se pune niciodată) și testul pe două aparate înainte de commit. Pune răspunsul la îndoială: Deschide proiectul pe telefon fără internet (modul avion), schimbă ceva, apoi repornește internetul. Ce s-a întâmplat cu schimbarea? Dacă răspunsul te surprinde, decizia de la punctul 4 n-a fost implementată cum credeai. Cere-i lui Claude să-ți arate exact unde în cod se ia decizia asta. ### T31 · Ma · 2h · Login cu Google · Login cu Google: OAuth explicat, configurat și parcurs până la capăt Proba rapidă (pentru cine știe deja; 1h în loc de 2h): Ai mai făcut login cu Google? Configurează-l fără ghid (Google Cloud, Supabase, adresele de întoarcere), dar nu sări două lucruri: lista celor cu drept de scriere ținută în tabel, cu regula RLS care o folosește, și provocarea cu prietenul care nu e în listă. Dacă prietenul nu poate schimba nimic, ai terminat. Misiunea: Adaugă „Continuă cu Google” prin Supabase Auth, cu regula de acces a proiectului tău (oricine are linkul citește analizele; scriu doar eu și colegii pe care îi pun pe listă), leagă datele anonime de contul tău și parcurge fluxul până la capăt într-un browser real (nu doar până la pagina Google). Promptul tău trebuie să acopere: - cererea unei explicații, înainte de pași, a ce e OAuth și ce se întâmplă între proiectul tău, Google și Supabase când apeși butonul (fără ca proiectul să vadă vreodată parola) - configurarea în Google Cloud (proiect, ecran de consimțământ, client OAuth) și în Supabase, pas cu pas, cu „gata”, și explicația adreselor de întoarcere (redirect) - regula de acces: oricine are linkul citește analizele; scriu doar eu și colegii pe care îi pun pe listă; lista celor cu drept de scriere (adresa mea și ale colegilor cu care lucrez la analize) ținută în baza de date, nu în cod, și regula RLS care o folosește - ce se întâmplă cu datele făcute anonim ieri: se leagă de contul care se autentifică primul pe aparatul ăla - fluxul parcurs cap-coadă pe localhost și pe adresa publică, cu o captură de ecran a stării autentificate - ce rămâne vizibil fără login: toate analizele, fără butoanele de scris Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Adăugăm „Continuă cu Google” prin Supabase Auth. Regula proiectului: oricine are linkul citește analizele; scriu doar eu și colegii pe care îi pun pe listă. Înainte de orice pas, explică-mi ce e OAuth: ce se întâmplă, în ordine, între proiectul meu, Google și Supabase când apăs butonul, și de ce proiectul nu vede niciodată parola. Apoi, cu „gata” de la mine după fiecare pas: 1. Google Cloud: proiect, ecran de consimțământ, client OAuth, adresele de întoarcere pentru localhost și pentru adresa publică. Explică-mi de ce există adresele astea și ce eroare primesc dacă lipsește una. 2. Supabase: pornim furnizorul Google cu datele de la pasul 1. 3. O listă de adrese de email cu drept de scriere, într-un tabel, nu în cod: [adresa mea și ale colegilor cu care lucrez la analize]. Regula RLS: scrii doar dacă ești autentificat ȘI ești în listă. 4. Datele anonime de pe un aparat se leagă de contul care intră primul pe aparatul ăla, o singură dată, cu confirmare. 5. Ecranul: butonul de login, poza și numele după login; fără login se vede: toate analizele, fără butoanele de scris. 6. Testăm cap-coadă pe localhost și pe adresa publică. Punct de salvare după. ``` De ce funcționează promptul: Login cu Google e locul în care cei mai mulți începători se blochează o zi întreagă, aproape mereu din cauza unei adrese de întoarcere greșite. De asta promptul tău trebuie să ceară explicația înainte de click-uri. Lista celor cu drept de scriere e decizia de produs a zilei: cine citește și cine scrie e o regulă a proiectului, nu un detaliu tehnic. Și „verificat” înseamnă parcurs până la starea finală, nu „s-a deschis pagina Google”. Pune răspunsul la îndoială: Roagă un prieten care nu e în listă să intre cu Google-ul lui. Ce vede? Dacă poate schimba ceva, RLS-ul tău nu folosește lista. Dacă vede un mesaj clar („poți citi, nu poți scrie”), ai făcut-o bine, și tocmai ai verificat securitatea cu un om, nu cu o presupunere. ### T32 · Ma · 2h · Documente · Documentele companiei: situațiile financiare și rapoartele, în PDF, puse la analiza lor Misiunea: Cine e pe lista celor cu drept de scriere poate pune la o analiză documentele din care vin cifrele ei: situațiile financiare depuse, raportul anual, o prezentare publicată. Fișierele se țin în Supabase Storage, le vede oricine are linkul și le poate șterge doar cine le-a pus. Fiecare document are anul, felul lui și adresa de unde a fost luat, iar analizele au un identificator stabil (codul fiscal al companiei), ca documentele să nu-și piardă locul când schimbi numele unei companii. Promptul tău trebuie să acopere: - cererea unei explicații a ce e un „bucket” de fișiere față de o tabelă, și de ce PDF-urile nu stau în baza de date - tipurile de fișiere acceptate și mărimea maximă, alese de tine, și ce vede omul când un fișier e refuzat - identificatorul stabil al fiecărei analize (codul fiscal al companiei) și regula în CLAUDE.md: când se schimbă numele companiei, identificatorul rămâne - ce se notează la fiecare document: anul, felul lui, adresa de unde l-ai luat și data; intră doar documente publice - regulile de acces pe bucket: citește oricine are linkul, scrie doar cine e în listă, șterge doar cine a pus fișierul - ecranul și testul: butonul „+” la analiză, starea „se trimite”, documentul apărut ca link, ștergere cu confirmare; pe două aparate, cu internet slab și cu un PDF mare Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Construim documentele companiei: din pagina unei analize apăs „+”, aleg un PDF (situațiile financiare, raportul anual), și el apare la analiza aia, ca link, pentru oricine deschide platforma. Înainte de cod, planul și o explicație: ce e Supabase Storage față de tabelele de ieri, și de ce PDF-urile nu stau în baza de date. Reguli: 1. Fiecare analiză are un identificator stabil: codul fiscal al companiei. Scrie în CLAUDE.md că la orice schimbare a unei analize identificatorul rămâne, altfel documentele își pierd locul. 2. Se acceptă doar [tipurile de fișiere alese de mine], de cel mult [mărimea aleasă de mine, după explicația ta]. Un fișier refuzat primește un mesaj clar, cu motivul. 3. La fiecare document notez anul, felul lui (situații financiare, raport anual, prezentare) și adresa de unde l-am luat. Intră doar documente publice. 4. Accesul pe bucket: oricine are linkul citește, scriu doar adresele din listă, șterge doar cine a pus fișierul. 5. Ecranul: „+” la fiecare analiză (doar pentru cine poate scrie), stările „se trimite / a reușit / a eșuat, încearcă din nou”, documentele ca linkuri, ștergere cu confirmare. 6. Testăm pe două aparate, cu internet slab și cu un PDF mare, inclusiv închiderea platformei în mijlocul trimiterii. Ce rămâne în bucket atunci? Punct de salvare după. ``` De ce funcționează promptul: E prima dată când proiectul tău primește fișiere, nu doar text: alt fel de stocare, alte reguli, alt fel de erori. Două lucruri trebuie să vină de la tine la nivelul 3: identificatorul stabil (codul fiscal, nu numele companiei) și sursa notată la fiecare document. Fără ea, peste o lună nu mai știi din ce raport ai luat o cifră, iar regula ta de conținut rămâne fără obiect. Pune răspunsul la îndoială: Pune un document la o companie, apoi schimbă-i numele în analize.json, fără să atingi codul fiscal. Documentul e tot acolo? Acum pune același PDF a doua oară. Ce a făcut platforma: l-a refuzat, l-a dublat, l-a înlocuit? Hotărăște tu ce e corect și întreabă-l pe Claude cum ar recunoaște un fișier urcat deja. ### T33 · Mi · 2h · API · Ce e un API: prima ta funcție pe server, care vorbește cu Claude („Întreabă analizele”) Proba rapidă (pentru cine știe deja; 1.25h în loc de 2h): Ai mai chemat un API cu cheie? Construiește funcția fără explicațiile de la început, dar nu sări trei lucruri: dovada că cheia nu e în git și nu ajunge în browser (cere-i lui Claude să-ți arate cum verifici), calculul costului pe apel cu cifre și limita zilnică, și provocarea cu întrebarea fără răspuns. Misiunea: Construiește o funcție serverless pe Vercel (în folderul api/) care primește o întrebare din proiect („care dintre companiile analizate are cea mai mare îndatorare și din ce an e cifra?”), îi dă lui Claude conținutul tău ca text și întoarce răspunsul, cu analizele pe care s-a bazat. Cheia API stă doar în variabilele de mediu de pe Vercel, iar funcția are o limită zilnică. Promptul tău trebuie să acopere: - cererea unei explicații, înainte de cod, a ce e un API (cu comparația chelnerului sau alta a ta), ce e o funcție serverless și de ce cheia lui Claude NU poate sta în pagina din browser - crearea cheii în consola Anthropic de către tine, cu Claude ghidând, și punerea ei ca variabilă de mediu pe Vercel și local (fără să apară vreodată în git) - contextul pe care îl primește Claude: analize.json ca text, și instrucțiunea să răspundă doar din conținutul tău și să spună când nu știe - limita zilnică de întrebări și de ce există (cost pe apel, calculat împreună, cu cifre) - ecranul: o întrebare, răspunsul, și analizele pe care s-a bazat, ca linkuri - testul cap-coadă pe localhost și pe adresa publică, cu o întrebare la care conținutul are răspuns și una la care n-are Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau o funcție „Întreabă analizele”: scriu o întrebare în proiect („care dintre companiile analizate are cea mai mare îndatorare și din ce an e cifra?”), iar Claude răspunde din conținutul meu. Înainte de cod, explică-mi: ce e un API, ce e o funcție serverless pe Vercel și de ce cheia lui Claude nu poate sta în pagina din browser. Apoi planul, și „ok” de la mine. Reguli: 1. Cheia o fac eu în consola Anthropic, cu tine ghidând; o pun ca variabilă de mediu pe Vercel și local; nu apare niciodată în git. Spune-mi cum verific asta. 2. Funcția primește întrebarea, îi dă lui Claude analize.json ca text și instrucțiunea: răspunde doar din conținutul ăsta, scurt, și spune „nu scrie în analizele tale” când nu știe; întoarce și identificatorii pentru analizele pe care s-a bazat. 3. Calculăm împreună cât costă un apel (tokeni de intrare cu tot conținutul, tokeni de ieșire) și punem o limită de [numărul ales de mine] întrebări pe zi, pe tot proiectul. 4. Ecranul: câmpul de întrebare, răspunsul, sursele ca linkuri, și starea „limita de azi s-a terminat”. 5. Testăm pe localhost și pe adresa publică: o întrebare cu răspuns în conținut, una fără. Punct de salvare după. ``` De ce funcționează promptul: Azi Claude intră în produsul tău, nu doar în construirea lui, și înveți singurul lucru care nu se negociază la un API: cheia stă pe server, niciodată în browser, pentru că din browser oricine o poate citi și folosi pe banii tăi. „Răspunde doar din conținutul meu și spune când nu știi” e felul în care îl ții cinstit pe un Claude care altfel ar inventa. Iar calculul costului pe apel, cu cifre, e ce te face să pui limita din prima zi, nu după prima factură. Pune răspunsul la îndoială: Pune o întrebare al cărei răspuns nu e în conținutul tău („cât valorează compania asta?”). Dacă răspunde sigur pe el, instrucțiunea ta nu ține: a inventat sau a scos din memoria lui, fără nimic verificat de tine. Repară instrucțiunea până spune „nu scrie în analizele tale”. ### T34 · Mi · 2h · Ciorne de analiză · Ciorna unei analize noi: Claude o scrie din documentele companiei, un om o aprobă Misiunea: Cine poate scrie dă numele unei companii noi și lipește textul documentelor ei publice (situațiile financiare, raportul anual). Funcția de ieri îi cere lui Claude să scrie ciorna analizei în formatul platformei, capitol cu capitol, cu sursa fiecărei cifre, iar analiza apare marcată „ciornă, neverificat” până o aprobă un om, după ce a comparat-o cu documentele. Nimic neaprobat nu intră în analize.json. Promptul tău trebuie să acopere: - contextul: regula de conținut a platformei și de ce se aplică și la ce scrie Claude din interiorul ei - formatul strict pe care trebuie să-l întoarcă Claude (aceleași câmpuri ca o analiză) și ce face platforma dacă răspunsul nu respectă formatul - regula pentru ce nu e în documente: Claude nu completează din memorie piața, concurenții sau o cifră lipsă; le lasă goale și le trece pe lista „de aflat”, cu locul unde s-ar putea găsi răspunsul - sursa la fiecare cifră: documentul și pagina sau rândul din care vine, ca verificarea ta să dureze minute, nu ore - starea „ciornă” vizibilă, cu butoanele „am verificat, intră” și „nu”, doar pentru cine poate scrie, și locul în care ajung ciornele aprobate (în analize.json prin commit, sau într-un tabel), cu decizia ta - aceeași limită zilnică ca funcția de ieri, costul unui apel cu documente lungi, și testul: o ciornă aprobată după verificare și una respinsă Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Construim „ciorna de analiză”: cine poate scrie dă numele unei companii și lipește textul documentelor ei publice (situațiile financiare, raportul anual), iar funcția de ieri îi cere lui Claude să scrie ciorna analizei în exact formatul din analize.json. Înainte de cod, planul. Reguli: 1. Formatul răspunsului e strict: aceleași câmpuri ca în analize.json. Dacă răspunsul nu respectă formatul, platforma arată o eroare clară și nu afișează nimic pe jumătate. 2. Claude scrie doar din documentele lipite. Fiecare cifră are sursa ei: documentul și pagina sau rândul. Ce nu e în documente (mărimea pieței, concurenții, o cifră lipsă) rămâne gol și intră pe lista „de aflat”, cu locul unde aș putea găsi răspunsul. Nimic din memorie. 3. Ciorna apare marcată „ciornă, neverificat”, cu altă culoare și cu două butoane pentru cine poate scrie: „am verificat, intră” și „nu”. 4. Explică-mi cele două locuri unde pot ajunge ciornele aprobate (în analize.json, prin commit, sau într-un tabel în Supabase), cu avantajele fiecăruia, și așteaptă decizia mea. 5. Explică-mi și dacă funcția ar putea căuta singură pe internet date despre piață și concurenți: cum s-ar face, cât ar costa un apel și ce risc aduce. Hotărăsc eu dacă o pornim sau rămânem pe documentele lipite. 6. Aceeași limită zilnică ca „Întreabă analizele”; calculăm împreună cât costă un apel cu un raport anual întreg. 7. Testăm: o companie nouă, cu ciorna aprobată după ce am comparat cifrele cu documentele, și una respinsă. Punct de salvare după. ``` De ce funcționează promptul: Azi închizi cercul: Claude scrie analiza din interiorul platformei, iar platforma însăși impune regula pe care ai învățat-o în T18: nimic neverificat nu ajunge între analize. Starea „ciornă” nu e un detaliu de design, e regula de conținut făcută vizibilă. Iar regula „doar din documente, restul pe lista de aflat” e cea care desparte o analiză de un text care sună a analiză: un Claude lăsat liber scrie o piață de două miliarde de euro cu aceeași siguranță cu care ar scrie una de două sute de milioane. Pune răspunsul la îndoială: Lipește documentele unei companii din care lipsește un an de cifre și cere ciorna. Ce a scris la anul lipsă? Dacă a pus o cifră, a inventat, oricât de plauzibilă ar fi. Repară instrucțiunea până lasă golul gol și îl trece pe lista „de aflat”. Apoi caută în ciornă o afirmație despre piață: are sursă în documente sau vine din memoria lui? ### T35 · Jo · 1.5h · Tracker · Tracker v3: în cloud, pe toate aparatele tale, cu o vedere doar de citit Misiunea: Trackerul tău de progres se mută din localStorage în Supabase (un tabel separat în același proiect), se vede și se bifează de pe orice aparat al tău, și are un link cu o vedere de citit pentru cine vrei tu: ce ai bifat, când, și notițele tale, fără să poată schimba nimic. Promptul tău trebuie să acopere: - migrarea bifelor existente din exportul JSON (T21), fără să pierzi istoricul - un tabel separat, cu RLS: scrii doar tu; vederea de citit se deschide printr-un link anume (decizi cum: un identificator secret în link sau contul Google al omului) - vederea de citit: pe săptămâni, cu ore făcute din total și ultima activitate - publicarea trackerului ca pagină a proiectului sau ca proiect separat pe Vercel, cu motivul alegerii - testul: bifezi de pe laptop, apare pe telefon; cineva deschide linkul de citit și vede, dar nu poate bifa Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Mutăm trackerul în cloud, pe Supabase, într-un tabel separat de datele proiectului. Vreau: să-l văd și să bifez de pe orice aparat al meu; un link cu o vedere de citit (pe săptămâni, ore făcute din total, ultima activitate), fără drept de a schimba. 1. Întâi planul: tabelul, regulile RLS (scriu doar eu; vederea de citit prin [varianta aleasă de mine: identificator secret în link sau contul Google al omului]) și unde publicăm pagina (în proiect, la o adresă ascunsă, sau separat pe Vercel). Argumentează și așteaptă „ok”. 2. Migrarea: importăm exportul JSON din T21, cu stări și date, fără să pierdem nimic. 3. Construim, testăm de pe două aparate, apoi dau linkul de citit cuiva și îl rog să încerce să bifeze ceva. Nu trebuie să poată. 4. Punct de salvare și un rând în README despre tracker. ``` De ce funcționează promptul: E a treia versiune a aceleiași unelte, și asta e intenționat: trackerul e firul care leagă localStorage (S1), JSON (S2) și baza de date cu reguli de acces (S3). Vederea de citit e primul tău ecran „pentru altcineva”, cu un drept de acces diferit de al tău. Seamănă cu ceva? Exact așa vede Bogdan bifele tale din planul ăsta: o pagină pe care o poate citi și nu o poate schimba. De azi știi cum e făcută. Pune răspunsul la îndoială: Întreabă: „Dacă cineva primește linkul de citit și îl trimite din greșeală altcuiva, ce poate face persoana aia?”. Răspunsul trebuie să fie „să citească”. Dacă e orice altceva, RLS-ul tabelului nou nu e bun. Repară-l înainte de audit, pentru că SuperBoris va întreba exact asta. ### T36 · Jo · 2.5h · Audit · Primul audit SuperBoris: securitatea datelor, cu brief-ul tău Misiunea: Scrie un brief de audit (scop, ce verificăm, criterii da/nu), validează-l cu Claude, apoi dă-l lui SuperBoris pentru o verificare independentă a proiectului: RLS pe toate tabelele, lista celor cu drept de scriere, cheia API, funcțiile cu limită. Repară ce iese „de reparat”, re-verifică, și salvează raportul în repo. Promptul tău trebuie să acopere: - brief-ul scris de tine înainte: scopul (un străin care primește linkul poate doar să citească analizele; doar adresele din listă pot scrie note și bife și pot pune documente; nimeni nu poate șterge documentul altcuiva; nimeni nu poate folosi cheia Claude sau funcțiile în afara limitei zilnice), limitele (ce NU verificăm azi), criteriile da/nu - trimiterea brief-ului către SuperBoris cu /superboris, fără concluziile tale despre cod - citirea raportului cu întrebarea nr. 8: ce e verificat de el cu o dovadă și ce e presupunere - repararea punctelor „de reparat” cu Claude Code și re-auditul, până la „aprobat” sau cel mult trei runde - raportul și brief-ul salvate în docs/audit/, cu data, și punct de salvare - o listă scurtă a ce ai acceptat „deocamdată”, cu motiv și dată Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau primul audit independent al proiectului. Întâi mă ajuți să scriu brief-ul, apoi îl dăm lui SuperBoris, fără părerile mele despre cod. Brief: - Scop: un străin care primește linkul poate doar să citească analizele; doar adresele din listă pot scrie note și bife și pot pune documente; nimeni nu poate șterge documentul altcuiva; nimeni nu poate folosi cheia Claude sau funcțiile în afara limitei zilnice. - Verificăm: RLS pe fiecare tabel (inclusiv lista celor cu drept de scriere și trackerul), variabilele de mediu și ce e în git, limita funcțiilor, și ce vede un utilizator autentificat care NU e în listă. - Nu verificăm azi: designul, textele, viteza. - Criterii: pentru fiecare punct, „da” înseamnă o încercare concretă care a eșuat cum trebuia (de exemplu scrierea ca străin a fost refuzată), nu o citire a codului. Validează brief-ul cu mine, apoi: /superboris cu brief-ul. După raport, îmi arăți ce e verificat cu dovadă și ce e presupunere, reparăm împreună ce e „de reparat”, cerem re-audit. Raportul și brief-ul în docs/audit/ cu data; punct de salvare. ``` De ce funcționează promptul: Până azi, cel care a construit a și verificat. SuperBoris primește brief-ul tău și nimic din ce crezi tu despre cod: așa găsește ce n-ai văzut. Criteriul „o încercare care a eșuat cum trebuia” e diferența dintre un audit și o lectură. Și lista „acceptat deocamdată, cu motiv” e maturitate: nu totul se repară azi, dar nimic nu se uită. Pune răspunsul la îndoială: Alege un punct marcat „aprobat” în raport și cere-i lui SuperBoris: „Arată-mi exact încercarea pe care ai făcut-o și ce răspuns ai primit.” Dacă nu poate, punctul nu era verificat. Un auditor căruia îi ceri dovada e un auditor bun, nu unul jignit. ### T37 · Vi · 2.5h · Conținut · Analizele complete, verificate: șase companii din același sector, cu sursa fiecărei cifre Misiunea: Conținutul proiectului e complet și verificat: cel puțin șase companii din același sector, fiecare cu toate capitolele și cu sursa fiecărei cifre, totul trecut prin verificarea ta la sursă; o comandă tipărește singură „N din M verificate”. Pozele și textele luate din altă parte au drepturi pe care ai voie să le folosești, cu sursa notată. Promptul tău trebuie să acopere: - ritmul: câte o companie odată, cu regula despre ce înseamnă „verificat” (pun fiecare cifră lângă documentul din care vine și o compar, iar la afirmațiile despre piață și concurenți deschid sursa citată și văd dacă spune chiar asta) - o comandă (script) care numără tot conținutul și ce e verificat, și tipărește totalul pe ultimul rând; numărul din README vine din ieșirea ei - pozele și textele: de unde au voie să vină (doar documente publicate de companie sau de o instituție publică, cu adresa de unde le-am luat; fără sigle și fără texte copiate din presă), cu autorul și sursa notate la fiecare - ce faci cu ce rămâne neverificat la final (iese din proiect sau rămâne marcat), decizie notată - o verificare de ansamblu: ce lipsește, ce se repetă, ce se contrazice, citit cap-coadă de tine Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Terminăm conținutul: cel puțin șase companii din același sector, fiecare cu toate capitolele și cu sursa fiecărei cifre, totul verificat. Reguli: 1. Lucrăm în ritmul ăsta: câte o companie odată. Propui în JSON, cu aceleași câmpuri. „Verificat: da” îl pune doar omul, după ce a verificat la sursă (situațiile financiare depuse și rapoartele publicate de companie). 2. După fiecare porție, îmi semnalezi ce se repetă, ce se contrazice cu ce există deja și ce lipsește. Reparăm înainte să trecem mai departe. 3. Pozele și textele din altă parte: doar documente publicate de companie sau de o instituție publică, cu adresa de unde le-am luat; fără sigle și fără texte copiate din presă. La fiecare, autorul și sursa, într-un fișier date/surse.json. 4. Scrii un script care numără tot conținutul și ce e verificat și tipărește pe ultimul rând „N din M verificate”. Numărul ăsta intră în README, copiat din ieșirea scriptului. 5. La final: ce facem cu ce a rămas neverificat: [decizia mea: iese / rămâne marcat], notată în jurnalul de decizii. Punct de salvare. ``` De ce funcționează promptul: Săptămâna asta ai construit motorul; azi pui combustibilul, cu aceeași regulă de la T18: Claude propune, omul verifică la sursă. Scriptul care numără e lecția lui Bogdan despre dovezi: o cifră dintr-un raport vine din ieșirea unei comenzi, nu din memoria cuiva. Iar drepturile pe poze și texte sunt întrebarea „a cui e sursa?”: un proiect public cu lucruri luate de oriunde e un proiect care primește într-o zi un email neplăcut. Pune răspunsul la îndoială: Rulează scriptul, apoi schimbă de mână un „verificat: da” în „nu” și rulează din nou. S-a schimbat cifra? Dacă nu, scriptul minte și README-ul ar minți cu el. Apoi dă cuiva o bucată de conținut și roagă-l să găsească o greșeală. Dacă găsește, standardul tău de „verificat” mai are de crescut. ### T38 · Vi · 1.5h · Review · Review-ul de vineri și jurnalul săptămânii 3 Misiunea: Review-ul săptămânii, cu Claude ca public și rezumatul pentru Bogdan, în formatul știut, plus demo-ul funcțiilor noi pe două aparate și raportul de audit cu ce ai reparat. Apoi jurnalul săptămânii 3. Promptul tău trebuie să acopere: - rezumatul, cel mai bun prompt (de data asta scris de tine, fără referință), o greșeală a lui Claude, trei întrebări deschise, parcarea de cuvinte - demo-ul pe două aparate, în 5 minute, cu o poveste (un om care folosește proiectul), nu un tur al butoanelor - raportul de audit: ce a găsit, ce ai reparat, ce ai acceptat deocamdată și de ce - ce ai face diferit la baza de date dacă ai lua-o de la capăt - jurnalul: jurnal/saptamana-3.md, cu cele 5 întrebări, și punct de salvare Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Pregătește review-ul meu de vineri. Îl fac cu tine ca public sceptic, iar lui Bogdan îi trimit rezumatul, pe WhatsApp. Formatul de până acum (rezumat în 5 rânduri, cel mai bun prompt al meu, o greșeală a ta și cum am prins-o, 3 întrebări deschise, parcarea de cuvinte), plus: - demo-ul pe două aparate, în 5 minute, ca o poveste: un om folosește proiectul, iar ce face pe un aparat apare pe celălalt - raportul de audit în trei rânduri: găsit, reparat, acceptat deocamdată (cu motiv) - un răspuns cinstit: ce aș face diferit la baza de date dacă aș lua-o de la capăt Apoi jurnalul: jurnal/saptamana-3.md, împreună, cu aceleași 5 întrebări. Punct de salvare „Jurnal săptămâna 3”. ``` De ce funcționează promptul: Cel mai bun prompt al săptămânii e, de data asta, unul scris de tine fără prompt de referință: compară-l cu cel din săptămâna 1 și vezi drumul. Întrebarea „ce aș face diferit” nu e autocritică, e proiectare: răspunsul la ea e prima decizie din următorul tău proiect. Pune răspunsul la îndoială: Trimite-i lui Bogdan, odată cu rezumatul, adresa și rugămintea să pună o întrebare funcției „Întreabă analizele”. Dacă răspunsul pe care îl primește e bun, întreabă-l ce l-ar face să aibă încredere în el. Dacă e prost, ai prima sarcină de luni. ## Săptămâna 4: Lansarea: oameni reali, calitate, predare (Nivel 3: scrii singur prompturile) Pe telefon ca o aplicație, cu partea de citit și fără internet. Stările și textele, scrise de tine. Teste automate pentru ce nu are voie să se strice și regula „testele înainte de push” în CLAUDE.md. Cine vede ce: vizibilitatea, nota de confidențialitate, copia ta a datelor. Adresa finală, cu login-ul mutat fără să se strice. Auditul final: PRD-ul față în față cu proiectul. Joi, lansarea la 10 oameni, cu previzualizare pe WhatsApp, și primul tău skill. Vineri: README cinstit, pagina ta de învățare, retrospectiva și demo-ul final. Livrabile: PWA · teste automate cu „N din N trecute” · notă de confidențialitate + export · adresa finală cu HTTPS · raport de audit final · proiectul la 10 oameni · un skill · README + pagina de învățare · demo final ### T39 · Lu · 2h · Mobil · Pe telefon ca o aplicație, și fără internet: PWA, iconiță, viteză măsurată Misiunea: Proiectul se adaugă pe ecranul de start al telefonului ca o aplicație (PWA), se deschide repede, și partea de citit merge și fără internet: analizele și indicatorii se citesc fără internet; bifele, notele, documentele și „Întreabă analizele” cer internet, cu un mesaj clar. Testat pe telefonul tău și pe al unui prieten cu celălalt sistem (iPhone/Android). Promptul tău trebuie să acopere: - explicația a ce e o PWA și ce NU e (nu e în App Store, nu are notificări garantate pe iPhone), cerută înainte - manifestul, iconița (făcută cu Claude, în culorile din stil.md), ecranul de pornire - ce se ține pe telefon pentru folosit fără internet și ce cere internet, cu mesaj clar: analizele și indicatorii se citesc fără internet; bifele, notele, documentele și „Întreabă analizele” cer internet, cu un mesaj clar - o măsurătoare de viteză înainte și după (Lighthouse din DevTools) și ce ai schimbat ca să fie mai rapid - testul pe două sisteme, cu modul avion pornit, și ce a mers și ce nu pe fiecare Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau ca proiectul să se poată pune pe ecranul de start al telefonului ca o aplicație și ca partea de citit să meargă fără internet. Întâi explică-mi ce e o PWA și ce nu e (ce lipsește față de o aplicație din App Store, mai ales pe iPhone), ca să nu promit oamenilor ce nu pot livra. Apoi: 1. măsurăm viteza de acum cu Lighthouse (DevTools) și notăm cifrele 2. manifestul, iconița (fă-o tu, SVG, în culorile din stil.md), ecranul de pornire, și ce e nevoie ca Chrome și Safari să ofere „adaugă pe ecranul de start” 3. fără internet: analizele și indicatorii se citesc fără internet; bifele, notele, documentele și „Întreabă analizele” cer internet, cu un mesaj clar, după decizia din T30 4. măsurăm din nou și îmi explici ce a schimbat cifra 5. testăm pe telefonul meu și pe al unui prieten cu celălalt sistem, cu modul avion pornit; notăm ce diferă Înainte de cod, planul. Punct de salvare la final. ``` De ce funcționează promptul: „Fără internet” nu e un caz rar, e metroul, liftul și semnalul slab de la țară. PWA-ul face proiectul tău să se poarte ca o aplicație și să fie util exact când nu există semnal. Măsurătoarea înainte și după e un reflex de profesionist: „mai rapid” e o părere, cifra e un fapt. Și explicația de la început te ferește de o promisiune falsă, ceea ce e produs, nu tehnică. Pune răspunsul la îndoială: Pune telefonul pe modul avion, deschide aplicația de pe ecranul de start și încearcă ceva ce cere internet. Ce se întâmplă? Dacă e un ecran alb sau o eroare criptică, ai o stare de proiectat în T40. Noteaz-o. ### T40 · Lu · 2h · Stări și texte · Stările și textele: ecranul gol, fără internet, eroarea, scrise de tine Misiunea: Fiecare ecran are starea goală, de încărcare, de eroare și de succes, cu texte scrise de tine, în vocea ta, nu generate. Nimic nu lasă omul să se întrebe „și acum ce fac?”. Promptul tău trebuie să acopere: - inventarul tuturor stărilor, cerut lui Claude înainte de orice text, ecran cu ecran, inclusiv cele găsite în T39 - regula: textele le scrii tu (Claude propune, tu rescrii în vocea ta); fiecare mesaj spune ce s-a întâmplat și ce poate face omul acum - un fișier texte.json cu toate textele, separat de cod, ca să le poți schimba fără Claude - verificarea pe telefon a fiecărei stări, provocată intenționat (modul avion, date șterse, un răspuns care nu vine) - ce ai învățat despre tonul tău: cum vorbește proiectul tău, în două rânduri, puse în stil.md Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Facem inventarul stărilor proiectului și scriem textele lor. Întâi lista: pentru fiecare ecran (lista companiilor, pagina unei analize, comparația, fișa de o pagină, lista de verificări, documentele, „Întreabă analizele”, ciorna de analiză, login), stările goală, de încărcare, de eroare și de succes, plus cele găsite ieri fără internet. Așteaptă „ok” pe listă. Apoi, pentru fiecare stare, propune un text în două rânduri: ce s-a întâmplat și ce poate face omul acum. Eu le rescriu în vocea mea și le punem în texte.json, separat de cod, ca să le schimb singur după. Reguli: fără „oops”, fără „ceva n-a mers”, fără coduri de eroare în fața omului; o stare goală e o invitație („n-ai analizat nicio companie încă; începi cu una pe care o cunoști?”), nu o scuză. La final, două rânduri în stil.md despre cum vorbește proiectul meu, și verificarea fiecărei stări pe telefon, provocată intenționat. Punct de salvare. ``` De ce funcționează promptul: Stările sunt locul unde se vede dacă un proiect a fost gândit pentru oameni sau doar construit. Textele le scrii tu pentru că vocea e a ta, nu a lui Claude: o platformă de analiză spune ce știe și ce nu știe, fără adjective. Iar texte.json e lecția „date separate de cod”, aplicată la cuvinte: schimbi un mesaj fără să atingi nimic altceva. Pune răspunsul la îndoială: Roagă un prieten să citească doar textele de eroare, fără proiect, și să-ți spună ce crede că s-a întâmplat la fiecare. Unde ghicește greșit, textul e neclar. Repară textul, nu explica. ### T41 · Ma · 2h · Teste · Teste automate pentru ce nu are voie să se strice Misiunea: Scrie, cu Claude, teste automate pentru lucrurile care nu au voie să se strice: analize.json se citește fără erori; fiecare analiză are cod fiscal unic și toate capitolele; fiecare cifră are o sursă; marja și creșterea ies corect pe un exemplu calculat de mână; un an fără cifră nu produce niciun indicator. O comandă le rulează pe toate și tipărește „N din N trecute”, iar CLAUDE.md spune că înainte de push se rulează testele. Promptul tău trebuie să acopere: - explicația a ce e un test automat, cu un exemplu din proiectul tău (ce ar fi prins Ziua de Debug din T24) - lista a ce testezi, aleasă de tine după „ce m-ar face să compar două companii pe o cifră greșită”, nu după ce e ușor - comanda unică și ieșirea ei cu totalul pe ultimul rând; numărul din README vine din ieșirea ei - un test care pică intenționat o dată, ca să vezi cum arată eșecul, apoi reparat - regula în CLAUDE.md: testele se rulează înainte de fiecare push, și ce se întâmplă dacă pică Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau teste automate pentru ce nu are voie să se strice. Întâi explică-mi ce e un test automat, cu un exemplu din proiectul meu: care dintre cele trei defecte din Ziua de Debug ar fi fost prins de un test, și cum. Lista mea, după „ce m-ar face să compar două companii pe o cifră greșită”: analize.json se citește fără erori; fiecare analiză are cod fiscal unic și toate capitolele; fiecare cifră are o sursă; marja și creșterea ies corect pe un exemplu calculat de mână; un an fără cifră nu produce niciun indicator. Apoi: o singură comandă care le rulează pe toate și tipărește „N din N trecute” pe ultimul rând. Stricăm intenționat ceva în analize.json, rulăm, vedem cum arată eșecul, reparăm. Punem în CLAUDE.md regula: înainte de push, testele; dacă pică, nu se face push. Numărul din README îl copiem din ieșirea comenzii. Punct de salvare. ``` De ce funcționează promptul: Testele sunt al doilea filtru dintre tine și internet (primul e verificarea pe localhost). Alegi ce testezi după cât ar durea, nu după cât e de ușor. „N din N trecute”, tipărit de comandă, e regula lui Bogdan despre dovezi: cifra din README vine din ieșirea comenzii, nu din memoria cuiva. Și testul care pică intenționat e singurul fel de a ști că testele chiar prind ceva. Pune răspunsul la îndoială: Întreabă: „Ce test ar fi trebuit să scriem și nu l-am scris?”. Vei primi o listă. Alege unul singur, cu un motiv, și scrie-l. Restul merg în README la „ce aș testa dacă aș avea încă o săptămână”. ### T42 · Ma · 2h · Confidențialitate · Cine vede ce: datele oamenilor, vizibilitatea pe Google, copia ta Misiunea: Hotărăște și implementează cine poate vedea proiectul și datele din el (platforma nu apare în Google și e accesibilă doar cu linkul), cu o notă scurtă despre ce date ții (adresele de email din lista cu drept de scriere, numele acționarilor și ale oamenilor din conducerea companiilor analizate) și cum se șterg. Un script exportă oricând analizele, documentele, bifele, notele și concluziile într-un folder al tău, ca datele să fie ale tale și dacă Supabase dispare mâine. Promptul tău trebuie să acopere: - explicația, cerută înainte, a ce e GDPR pentru un proiect mic: ce date personale ai (adresele de email din lista cu drept de scriere, numele acționarilor și ale oamenilor din conducerea companiilor analizate), de ce le ții, și drepturile oamenilor ale căror date sunt - decizia de vizibilitate (platforma nu apare în Google și e accesibilă doar cu linkul) și ce înseamnă ea în practică - pagina sau nota de confidențialitate, în 10 rânduri, în cuvintele tale - un script de export (analizele, documentele, bifele, notele și concluziile) într-un folder local, rulat o dată și pus în README ca procedură - ștergerea: cum își șterge cineva datele lui, și cum scoți pe cineva din lista celor cu drept de scriere Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau să hotărăsc cine vede proiectul și datele din el, și să rămân stăpânul datelor mele. Întâi explică-mi ce înseamnă GDPR pentru un proiect mic: ce date personale am (adresele de email din lista cu drept de scriere, numele acționarilor și ale oamenilor din conducerea companiilor analizate), de ce le țin, și ce drepturi au oamenii ale căror date sunt. Apoi: 1. Vizibilitatea: platforma nu apare în Google și e accesibilă doar cu linkul. Explică-mi ce înseamnă asta în practică: cine poate ajunge la proiect și cine nu, și ce ar trebui schimbat dacă mă răzgândesc. 2. O notă de confidențialitate de 10 rânduri, propusă de tine, rescrisă de mine, legată din subsolul proiectului. 3. Un script care exportă analizele, documentele, bifele, notele și concluziile într-un folder local; îl rulăm o dată acum și punem procedura în README. 4. Ștergerea: cum își șterge un om datele lui; cum scot pe cineva din listă și ce se întâmplă cu ce a pus. Punct de salvare după. ``` De ce funcționează promptul: Un proiect cu datele altor oameni, oricât de mic, are răspunderi: cine le vede, cât stau, cine le poate scoate. Vizibilitatea e o decizie, nu o setare lăsată cum a venit. Iar exportul e regula lui Bogdan despre datele care nu se pot reface: un serviciu gratuit poate dispărea; o copie în folderul tău, făcută cu o comandă, e singura asigurare adevărată. Pune răspunsul la îndoială: Rulează exportul, apoi șterge ceva din proiect și rulează-l din nou. Copia locală a rămas cu ce era sau a dispărut și de acolo? Hotărăște ce vrei (o arhivă care păstrează tot, sau o oglindă a proiectului) și notează decizia. Nu există răspuns corect, există răspuns ales. ### T43 · Mi · 1.5h · Domeniu · Adresa proiectului: un domeniu al tău (sau un subdomeniu de la Bogdan), cu login-ul mutat fără să se strice Proba rapidă (pentru cine știe deja; 0.75h în loc de 1.5h): Ai mai legat un domeniu? Fă-o fără explicații, dar nu sări capcana: adresele de întoarcere OAuth din Google Cloud și din Supabase, actualizate, și login-ul parcurs pe bune pe adresa nouă. Apoi cele trei verificări din provocare. Misiunea: Hotărăște adresa finală a proiectului: un domeniu cumpărat de tine sau un subdomeniu pe bgn.ro, cerut lui Bogdan. Leagă-l de Vercel prin DNS, cu HTTPS, și mută login-ul cu Google pe adresa nouă fără să se strice. Adresa veche redirecționează. Promptul tău trebuie să acopere: - explicația, înainte, a ce e un domeniu, ce e DNS și ce se întâmplă când cineva scrie adresa în browser - decizia între domeniu propriu (cost, cine îl deține, pe numele cui e cardul) și subdomeniu de la Bogdan, cu motivul - pașii: cumpărare sau cerere către Bogdan, înregistrarea în DNS, legarea de Vercel, HTTPS verificat - actualizarea adreselor de întoarcere OAuth (Google Cloud și Supabase) și testul login-ului pe adresa nouă - redirecționarea adresei vechi și o propoziție în README cu adresa finală Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau o adresă finală pentru proiect. Întâi explică-mi ce e un domeniu, ce e DNS și ce se întâmplă când cineva scrie adresa în browser, în cuvinte obișnuite. Apoi ajută-mă să hotărăsc: domeniu propriu (.ro sau .com; cât costă pe an, pe numele cui e, ce se întâmplă dacă nu-l reînnoiesc) sau un subdomeniu pe bgn.ro de la Bogdan (gratuit, dar al lui). Recomandă, cu motiv; decizia e a mea. Pașii, cu „gata” după fiecare: cumpărarea sau cererea; înregistrarea DNS; legarea de Vercel; HTTPS verificat. Apoi, atenție: adresele de întoarcere OAuth din Google Cloud și Supabase trebuie actualizate; testăm login-ul pe adresa nouă înainte să declarăm gata. Adresa veche redirecționează spre cea nouă. O propoziție în README cu adresa finală. Punct de salvare. ``` De ce funcționează promptul: Domeniul e ultimul pas pe drumul de la „la mine” la „pe internet, al meu”. Decizia nu e tehnică, e de proprietate: un domeniu cumpărat de tine e al tău; un subdomeniu e împrumutat. Iar „login-ul mutat fără să se strice” e capcana clasică a mutării de adresă: tot ce depinde de adresa veche (OAuth, în primul rând) trebuie găsit și actualizat, iar singurul fel de a ști că a mers e să intri, pe bune, pe adresa nouă. Pune răspunsul la îndoială: Deschide adresa veche pe telefon. Ajunge pe cea nouă? Apoi deschide adresa nouă fără „https” în față. Tot pe https ajunge? Apoi login. Dacă oricare dintre cele trei nu merge, mutarea nu e gata, oricât de verde ar fi panoul Vercel. ### T44 · Mi · 2.5h · Audit final · Auditul final SuperBoris: PRD-ul față în față cu proiectul, înainte de oameni Misiunea: Al doilea audit independent, cu brief-ul tău: de data asta SuperBoris verifică dacă proiectul face ce spune PRD-ul v2 (fiecare decizie numerotată are o dovadă în produs), dacă securitatea din T36 a rămas în picioare după tot ce ai adăugat, și dacă proiectul e gata pentru oameni care nu ești tu. Repari, re-verifici, salvezi raportul. Promptul tău trebuie să acopere: - brief-ul cu trei părți: PRD față în față cu produsul (decizie cu decizie), re-verificarea securității după schimbările din săptămânile 3–4, și „gata pentru străini” (stări, texte, telefon, fără internet) - criteriile da/nu pentru fiecare parte, scrise de tine - raportul citit cu întrebarea nr. 8 și lista „acceptat deocamdată” actualizată - reparațiile cu Claude Code și re-auditul, cel mult trei runde - docs/audit/ cu al doilea raport, datat, și punct de salvare Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Auditul final, înainte să dau proiectul oamenilor. Mă ajuți să scriu brief-ul, apoi /superboris, fără părerile mele. Brief: - Partea 1, PRD față în față cu produsul: pentru fiecare decizie numerotată din PRD v2, dovada că proiectul o respectă (ecranul, comportamentul) sau abaterea, cu „intenționat” / „uitat”. - Partea 2, securitatea din nou: tot ce s-a verificat în T36, re-încercat acum, după PWA, texte, domeniu nou, export. Criteriul e tot o încercare care a eșuat cum trebuia. - Partea 3, gata pentru străini: un om care primește linkul azi, pe telefon, fără internet bun: are toate stările, toate textele, nicio fundătură. - Nu verificăm: viteza dincolo de cifra din T39. După raport: ce e verificat cu dovadă, ce e presupunere; reparăm; re-audit. Lista „acceptat deocamdată” se actualizează cu motiv și dată. Raportul în docs/audit/ cu data; punct de salvare. ``` De ce funcționează promptul: Primul audit a verificat securitatea; al doilea verifică promisiunea: PRD-ul e ce ai spus că faci, proiectul e ce ai făcut, și diferența trebuie să fie intenționată și scrisă, nu uitată. „Gata pentru străini” e criteriul care contează mâine, la lansare: nu tu, care știi unde e fiecare buton, ci un om cu telefonul în mână. Pune răspunsul la îndoială: Alege o abatere marcată „intenționat” în raport și scrie în jurnalul de decizii de ce ai abătut-o, cu data. Dacă nu poți scrie motivul în două rânduri, nu era intenționat, era uitat. Repară sau reclasifică, cinstit. ### T45 · Jo · 2h · Lansare · Lansarea: proiectul la 10 oameni, previzualizarea pe WhatsApp, și ce faci cu ce îți spun Misiunea: Trimite linkul la 10 oameni reali (colegi și prieteni care analizează companii sau investesc), cu o previzualizare frumoasă pe WhatsApp (titlu, poză, descriere), și urmărește ce fac: ce deschid, unde se opresc, ce întreabă. Primele reparații în aceeași zi, din ce au arătat, nu din ce au spus. Promptul tău trebuie să acopere: - imaginea și textele de previzualizare (Open Graph) pentru WhatsApp și iMessage, făcute cu Claude în stilul tău, și testate într-un chat înainte de trimitere - lista celor 10 și mesajul de trimitere, scris de tine, scurt, cu ce să încerce - cum afli ce au făcut: o întrebare la 24 de ore (Mom Test), nu „ți-a plăcut?”, și eventual ce îți spune Vercel despre vizite - reparațiile din aceeași zi, alese după ce au făcut oamenii, cu punct de salvare pentru fiecare - ce rămâne pe lista „după curs”, cu motiv Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Lansez. Întâi previzualizarea pe WhatsApp: când trimit linkul, să apară o poză în stilul meu, titlul proiectului și un rând de descriere. Explică-mi ce e Open Graph, fă imaginea (din paleta din stil.md), punem textele, și testez într-un chat cu mine înainte să trimit altcuiva. Atenție: WhatsApp ține minte previzualizarea pe adresă, deci o facem bine din prima. Apoi: lista celor 10 oameni (colegi și prieteni care analizează companii sau investesc) și mesajul, scris de mine, scurt, cu o cerere concretă („deschide analiza unei companii pe care o știi și spune-mi ce cifră ai verifica prima”). Îmi pregătești întrebarea pe care le-o pun la 24 de ore, după regulile Mom Test: ce au făcut, nu ce cred. Ce îmi spune Vercel despre vizite, dacă îmi spune ceva. Reparațiile din aceeași zi, alese după ce au făcut oamenii, fiecare cu punct de salvare. Ce rămâne pe lista „după curs”, cu motiv, în README. ``` De ce funcționează promptul: Lansarea nu e un buton, e un moment în care proiectul iese din mâinile tale. Previzualizarea pe WhatsApp e primul ecran pe care îl vede toată lumea, înainte să apese: de asta se face cu grijă și se testează. Iar întrebarea de la 24 de ore e Mom Test până la capăt: „ce ai făcut cu el?” îți spune adevărul, „ți-a plăcut?” îți spune ce vrei să auzi. Primele reparații în aceeași zi sunt viteza care deosebește un produs viu de un proiect de școală. Pune răspunsul la îndoială: Dintre cei 10, alege-l pe cel care n-a deschis deloc linkul. Întreabă-l de ce, fără supărare. Răspunsul („n-am avut timp”, „am crezut că e reclamă”, „nu știam ce e”) e o problemă de produs sau de mesaj, și e cea mai ieftină lecție de marketing pe care o vei primi vreodată. ### T46 · Jo · 2h · Skill · Primul tău skill: „analizează-o-companie”, pe care îl poate folosi și altcineva Misiunea: Scrie un skill pentru Claude Code (un fișier de instrucțiuni refolosibile) care primește numele unei companii și documentele ei publice și întoarce ciorna analizei în exact formatul din analize.json, cu sursa fiecărei cifre și cu lista „de aflat” pentru ce nu e în documente, și testează-l dându-l cuiva care îl folosește fără tine. Promptul tău trebuie să acopere: - explicația a ce e un skill față de un prompt (un prompt care a absolvit: fișier, testabil, de dat mai departe) și unde stă în proiect - conținutul: formatul strict din analize.json, regulile tale din T18, „verificat: nu” pe tot ce produce, verificat/ipoteză la fiecare cifră sau fapt - trei teste ale tale (o companie cu documente complete, una din care lipsește un an și una dintr-un sector pe care nu-l cunoști), cu ce a ieșit prost și ce ai corectat în skill - testul cu altcineva: un coleg îl folosește pe o companie aleasă de el, fără tine, și îți spune ce a ieșit - un rând în README despre skill și cum se folosește Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Vreau să fac din ce am învățat un skill: „analizează-o-companie”. Întâi explică-mi ce e un skill față de un prompt și unde stă în proiect. Conținutul: skill-ul primește numele unei companii și documentele ei publice și întoarce ciorna analizei în exact formatul din analize.json, cu sursa fiecărei cifre și cu lista „de aflat” pentru ce nu e în documente. Respectă regulile mele de conținut din T18; tot ce produce e marcat „verificat: nu”; la fiecare cifră sau fapt spune verificat sau ipoteză; și se termină cu lista a ce trebuie verificat de un om. Îl testăm de trei ori (o companie cu documente complete, una din care lipsește un an și una dintr-un sector pe care nu-l cunoști) și corectăm skill-ul după fiecare. Apoi îl dau cuiva: un coleg îl folosește pe o companie aleasă de el, fără mine, și notez ce a ieșit. Un rând în README despre skill. Punct de salvare. ``` De ce funcționează promptul: Un skill e un prompt care a absolvit: nu mai e o conversație, e un fișier pe care îl poți testa, îmbunătăți și da altcuiva. Scriindu-l, pui în cuvinte tot ce ai învățat în patru săptămâni despre cum se cere un lucru bine făcut, și descoperi ce știai fără să știi că știi. Testul cu altcineva e singura dovadă că skill-ul e al tuturor, nu doar al tău. Pune răspunsul la îndoială: Dă skill-ul unui prieten care n-a văzut planul ăsta și roagă-l să-l folosească. Dacă trebuie să-i explici ceva ca să meargă, explicația aia lipsește din skill. Pune-o și testează din nou, fără să spui nimic. ### T47 · Vi · 1.5h · README · README-ul cinstit și pagina ta de învățare (rețeta ta de întrebări) Misiunea: README-ul spune, cinstit, ce e proiectul, ce e gata, ce e pe jumătate, ce ai face diferit și cum se pornește; cifrele din el vin din comenzi (testele, conținutul verificat). Și pagina de învățare: cele patru jurnale, 20 de cuvinte explicate cu exemple din proiectul tău și rețeta ta de întrebări, publicată ca pagină a proiectului sau separat. Promptul tău trebuie să acopere: - structura README-ului: ce e, pentru cine, cum se pornește local, unde stau datele, ce e gata / pe jumătate / după curs, ce ai face diferit, procedura de export - cifrele doar din ieșirea comenzilor (testele, scriptul de conținut verificat), copiate, cu comanda alături - pagina de învățare: cele patru jurnale, 20 de cuvinte din vocabular explicate de tine cu exemple din proiect, și rețeta ta de întrebări (versiunea ta a tab-ului „Rețeta întrebărilor”, cu ce ai adăuga și ce ai scoate) - decizia unde se publică pagina (în proiect, la o adresă proprie, sau separat) și de ce - punct de salvare și adresa pusă în README Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Două documente de predare. Întâi README-ul, cinstit: ce e proiectul și pentru cine; cum se pornește local; unde stau datele (Supabase, Vercel) și ce e în browser; ce e gata, ce e pe jumătate, ce e „după curs” (cu motiv); ce aș face diferit; procedura de export. Cifrele (teste trecute, conținut verificat) doar din ieșirea comenzilor, copiate, cu comanda alături. Apoi pagina mea de învățare: cele patru jurnale, 20 de cuvinte din vocabularul planului explicate de mine, fiecare cu un exemplu din proiectul meu, și rețeta mea de întrebări: versiunea mea a tab-ului „Rețeta întrebărilor”, cu ce aș adăuga după patru săptămâni și ce aș scoate, cu motiv. Propune-mi unde o publicăm (în proiect, la o adresă proprie, sau separat) și așteaptă decizia. Punct de salvare, adresa în README. ``` De ce funcționează promptul: README-ul e primul lucru pe care îl citește cineva care deschide proiectul peste un an, poate chiar tu. Cinstea lui („pe jumătate”, „după curs”) e mai valoroasă decât orice listă de funcții. Pagina de învățare e examenul de absolvire al planului: rețeta ta de întrebări, scrisă de tine, e dovada că n-ai copiat o metodă, ai făcut-o a ta. Pune răspunsul la îndoială: Dă README-ul cuiva care n-a văzut proiectul și roagă-l să-l pornească local, singur, după instrucțiuni. Cronometrează. Unde s-a blocat, README-ul minte prin omisiune. Repară-l, nu explica. ### T48 · Vi · 1h · Retrospectivă · Retrospectiva: cine îl cunoștea mai bine pe Claude în ziua 1 Misiunea: O oră de retrospectivă, cu Claude ca secretar: ce a mers, ce nu, ce ai schimba în plan, și comparația dintre lista ta de „la ce e slab Claude”, făcută din patru săptămâni, și răspunsul lui din T01. Scrisă în jurnalul de decizii, nu într-un chat pierdut. Promptul tău trebuie să acopere: - cele trei liste (a mers / n-a mers / aș schimba), cu exemple concrete, nu generalități - comparația cu T01: răspunsul lui Claude din ziua 1 despre slăbiciunile lui față de ce ai văzut tu; cine a avut dreptate și unde - cele trei momente în care l-ai prins pe Claude greșind, ca poveste de spus la demo - ce ai învățat despre felul în care lucrezi tu, în două rânduri, cinstit - un rând despre ce urmează: dacă folosesc platforma la analizele de la muncă, și ce ar trebui schimbat ca să pot pune în ea date confidențiale Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Retrospectiva celor patru săptămâni, cu tine ca secretar, nu ca autor: îmi pui întrebările, eu răspund, tu notezi în jurnalul de decizii. 1. Ce a mers, ce n-a mers, ce aș schimba în plan, cu exemple concrete. 2. Uite răspunsul tău din ziua 1 despre la ce ești slab (lipesc nota din T01) și uite lista mea de acum. Compară-le cinstit: unde ai avut dreptate, unde eu, ce n-a văzut niciunul. 3. Cele trei momente în care te-am prins greșind, ca povești de 3 rânduri, pentru demo. 4. Ce am învățat despre felul în care lucrez eu. 5. Ce urmează: dacă folosesc platforma la analizele de la muncă, și ce ar trebui schimbat ca să pot pune în ea date confidențiale. La final, punct de salvare „Retrospectivă”. ``` De ce funcționează promptul: Retrospectiva e locul unde învățarea devine a ta, nu a planului. Comparația cu ziua 1 e cea mai cinstită măsură a drumului: în ziua 1 îl credeai pe Claude pe cuvânt despre el însuși; azi ai dovezi. Pune răspunsul la îndoială: Întreabă-l pe Claude: „Ce ai fi făcut diferit dacă ai fi fost tu profesorul în planul ăsta?”. Compară cu lista ta de la punctul 1. Unde coincid, planul are o problemă reală; spune-i lui Bogdan, planul se îndoaie. ### T49 · Vi · 1.5h · Demo final · Demo-ul final: o poveste de 10 minute, în fața unui om și filmată pentru Bogdan Misiunea: Un demo de 10 minute, repetat o dată cu Claude ca public: analiza unei companii noi, de la zero (lipesc documentele, Claude scrie ciorna, verific trei cifre la sursă, aprob, compar compania cu celelalte, bifez lista de verificări, întreb analizele), apoi cele trei momente în care l-ai prins pe Claude, pagina de învățare și ce urmează. Nu un tur al butoanelor. Îl ții în fața unui om care n-a văzut proiectul și îl filmezi (ecranul telefonului și vocea ta), ca să i-l trimiți lui Bogdan. Promptul tău trebuie să acopere: - scenariul demo-ului, scris de tine, minut cu minut - repetiția cu Claude ca public sceptic: te întrerupe cu întrebările grele - cele trei povești cu Claude prins greșind, de 3 rânduri fiecare - ce urmează: dacă folosesc platforma la analizele de la muncă, și ce ar trebui schimbat ca să pot pune în ea date confidențiale - un mulțumesc scris pentru cei 10 oameni care au deschis linkul, trimis după demo Promptul de referință (de comparat după ce l-ai scris pe al tău): ``` Pregătim demo-ul final, 10 minute. Scenariul îl scriu eu: analiza unei companii noi, de la zero (lipesc documentele, Claude scrie ciorna, verific trei cifre la sursă, aprob, compar compania cu celelalte, bifez lista de verificări, întreb analizele); apoi pagina de învățare și ce urmează. Minut cu minut. Apoi tu ești publicul sceptic: mă întrerupi cu întrebările grele („de ce nu Excel și un șablon?”, „de unde știu că cifrele sunt corecte?”, „ce se întâmplă cu datele unei tranzacții adevărate?”) și îmi spui unde răspunsul meu a fost slab. Repetăm o dată. La final, un mesaj scurt de mulțumire pentru cei 10 oameni care au deschis linkul, în cuvintele mele, de trimis după demo. ``` De ce funcționează promptul: Un demo bun e o poveste: un om, o problemă, proiectul tău, totul merge. Repetiția cu Claude ca public sceptic e un truc de profesionist: întrebările grele le auzi întâi de la cineva care nu contează. Iar mulțumirea pentru cei 10 e ultima lecție de produs: oamenii care ți-au dat timpul lor sunt primii tăi utilizatori, și se țin minte. Pune răspunsul la îndoială: După demo, pune o singură întrebare celui care l-a văzut (și lui Bogdan, când îi trimiți filmarea): „Ce ai fi vrut să vezi și n-ai văzut?”. Notează răspunsul în jurnalul de decizii, cu data. E prima sarcină a următorului tău proiect, oricare ar fi. ## Vocabular - **prompt**: Mesajul pe care i-l dai lui Claude: context, scop, formă, constrângeri. Să scrii prompturi complete e meseria pe care o învață tot planul ăsta. Exemplu: „Construiește-mi un tracker… FUNCȚIONALITATE: … DESIGN: …” e un prompt cu secțiuni etichetate. - **artifact**: În claude.ai, un artifact e o mini-pagină sau mini-aplicație pe care Claude o construiește lângă conversație: o vezi funcționând imediat, fără să instalezi nimic. Exemplu: Trackerul tău începe ca artifact; la fel cardul din prima zi. - **Project**: Un spațiu în claude.ai cu memorie: urci documente și scrii instrucțiuni o singură dată, iar fiecare conversație de acolo pornește deja informată. Exemplu: Project-ul tău are planul ăsta și pagina de o foaie a proiectului; poți întreba „ce vrea de la mine sarcina T18?”. - **instrucțiuni personalizate**: O notă permanentă către Claude, în interiorul unui Project: cine ești și cum vrei răspunsurile. Scrisă o dată, aplicată în fiecare conversație de acolo. Exemplu: Ale tale spun: „am 19 ani, n-am scris cod, explică termenii la prima apariție, arată-mi planul înainte de ceva mare”. - **PRD**: Product Requirements Document, documentul-sursă al unui produs: pentru cine e, ce face, ecran cu ecran. Al tău îl scrii împreună cu Bruce în prima săptămână și îl corectezi pe măsură ce construiești. Exemplu: PRD-ul spune ce face fiecare ecran și, la fel de important, ce NU face prima versiune. - **prototip**: O machetă care arată cum va arăta și cum se va folosi produsul, înainte să existe cu adevărat. Se face repede, se strică fără regrete, și se discută pe ea, nu pe idei abstracte. Exemplu: Prototipul HTML făcut cu Bruce vineri devine site-ul adevărat în săptămâna 2. - **Bruce**: Agentul lui Bogdan pentru definirea produsului: ascultă nevoia, caută cum rezolvă alții problema, propune cu motiv și termină cu PRD-ul și prototipul. Un agent e un Claude cu instrucțiuni și un proces anume, împachetat ca să-l poți chema cu o comandă. Exemplu: „/bruce hai să definim platforma ta de analiză a companiilor” pornește procesul Nevoie → Research → Produs. - **SuperNicu**: Agentul lui Bogdan pentru construcție: ia PRD-ul și prototipul, propune arhitectura, construiește, își verifică munca și cheamă auditul. Exemplu: În săptămâna 2 îl folosești ca să treci de la prototip la aplicația reală. - **SuperBoris**: Agentul lui Bogdan pentru audit: nu scrie cod, verifică independent ce a construit altcineva (sau Claude) și dă verdict „aprobat” sau „de reparat”. Exemplu: În săptămâna 3, SuperBoris îți verifică regulile de securitate ale bazei de date. - **agent**: Un Claude căruia i s-a dat un rol, un proces și unelte, ca să ducă singur o sarcină de la cap la coadă. Bruce, SuperNicu și SuperBoris sunt agenți. Exemplu: Spui „/bruce” și Claude nu mai e un chat, e un product manager cu metodă. - **plugin**: Pachetul în care se livrează agenții și skill-urile pentru Claude Code: îl instalezi o dată, se actualizează singur. Exemplu: Pachetul BGN pe care îl instalezi în ziua 2 e un plugin cu patru agenți. - **skill**: Un fișier de instrucțiuni refolosibile pe care Claude îl aplică de fiecare dată când se potrivește: un prompt care a absolvit. Fiind fișier, poate fi testat, îmbunătățit și dat mai departe. Exemplu: Skill-ul tău „analizează-o-companie” e un fișier pe care îl poate folosi și altcineva. - **HTML**: Limbajul care descrie conținutul și structura unei pagini web: titluri, paragrafe, butoane. Exemplu: Primul tău artifact din ziua 1 e HTML plus CSS. - **CSS**: Limbajul care descrie cum arată o pagină web: culori, fonturi, spații, așezare. Exemplu: „Buton principal plin, Inter, colțuri rotunjite” devine câteva rânduri de CSS. - **JavaScript**: Limbajul care face paginile web interactive: ce se întâmplă când apeși, scrii sau când sosesc date. Exemplu: Logica din spatele unui buton care ține minte ce ai apăsat e JavaScript. - **JSON**: Un format simplu de text în care programele notează date structurate (nume, valori, liste), citibil și de om, și de calculator. Exemplu: Analizele stau în analize.json: câte un bloc între acolade pentru fiecare, cu numele câmpului și valoarea lui. - **localStorage**: O memorie mică din browser în care o pagină își poate nota lucruri pentru ea: per browser, per aparat. Închizi tab-ul, revii: tot acolo. Deschizi de pe alt aparat: nimic. Exemplu: Trackerul v1 ține bifele în localStorage, de asta nu le vezi pe telefon. - **bază de date**: Un depozit organizat de date, ca un tabel Excel cu reguli stricte, din care aplicațiile citesc și în care scriu. Tabelele au rânduri; fiecare înregistrare e un rând. Exemplu: Fiecare schimbare făcută de un om (bifele din lista de verificări, notele și concluziile) e un rând într-o tabelă: cine, când, la ce analiză. - **Supabase**: Un serviciu online care îți dă o bază de date adevărată în cloud, gratuit la început, plus login și un API gata făcute. Îți faci cont, el îți dă baza și o adresă prin care vorbești cu ea. Exemplu: Datele pe care le vezi pe toate aparatele și lista celor care au voie să scrie stau în Supabase. - **backend**: Jumătatea nevăzută a unei aplicații: baza de date și logica de pe server. Cealaltă jumătate, ce vezi și apeși, e frontend-ul. Exemplu: Când platforma salvează ceva în Supabase, Supabase e backend-ul. - **frontend**: Jumătatea pe care o vezi și o atingi: pagini, butoane, formulare, în browser. Jumătatea nevăzută e backend-ul. Exemplu: Tot ce construiești în primele două săptămâni e frontend. - **API**: Application Programming Interface: felul în care un program cere altui program informații sau acțiuni, ca un chelner care duce comanda de la masă la bucătărie și aduce farfuria înapoi. Exemplu: „Întreabă analizele” îi trimite lui Claude, prin API-ul lui, întrebarea și conținutul tău, și primește răspunsul. - **cheie API**: Parola cu care aplicația ta se prezintă la un serviciu (Claude, Supabase). Se ține doar pe server, în variabile de mediu; dacă ajunge în pagina din browser, oricine o poate folosi pe banii tăi. Exemplu: Cheia pentru Claude stă în setările proiectului de pe Vercel, nu în fișierele din GitHub. - **variabilă de mediu**: O setare pe care o citește programul de la locul unde rulează, nu din cod: așa aceeași aplicație poate avea chei diferite pe calculatorul tău și pe server, iar cheile nu ajung în GitHub. Exemplu: ANTHROPIC_API_KEY e o variabilă de mediu setată în Vercel. - **funcție serverless**: O bucată de cod care rulează pe serverul furnizorului doar când e chemată, fără să ții tu un server pornit. Pe Vercel, un fișier în folderul api/ devine automat o adresă. Exemplu: api/intreaba.js primește întrebarea utilizatorului, vorbește cu Claude și întoarce răspunsul. - **server local**: Un program mic de pe calculatorul tău care îți servește aplicația cât o construiești: o vezi doar tu, se actualizează instant când se schimbă codul. Exemplu: „Pornește serverul local” și deschizi localhost:3000 ca să vezi proiectul cum crește. - **localhost**: Adresa calculatorului tău, văzută de el însuși. O aplicație pe localhost rulează doar la tine: nimeni altcineva din lume nu o poate deschide. Exemplu: http://localhost:3000 merge pe Mac-ul tău și nicăieri altundeva. - **terminal**: Fereastra în care vorbești cu calculatorul prin comenzi scrise, nu prin click-uri. Claude Code trăiește acolo: tu scrii românește, el scrie comenzi. Exemplu: În ziua 2 îl vezi pe Claude creând fișiere din terminal. - **Claude Code**: Claude care lucrează direct pe calculatorul tău, din terminal: creează fișiere, rulează comenzi, face commit-uri. Diferența dintre a discuta cu un AI și a conduce un constructor. Exemplu: Din ziua 2, aproape tot ce construiești se face în Claude Code. - **CLAUDE.md**: Fișierul cu regulile unui proiect în Claude Code: Claude îl citește la începutul fiecărei sesiuni și îl respectă fără să i se reamintească. Exemplu: Al tău spune: explică-mi termenii, arată-mi planul înainte de schimbări mari, nu șterge nimic fără să întrebi, bgn-33 pentru orice ecran. - **git**: Un sistem de puncte de salvare pentru proiect. Fiecare commit e o fotografie la care te poți întoarce oricând, deci poți experimenta fără frică. Exemplu: Ai stricat ceva marți? Te întorci la punctul de salvare de luni cu o comandă. - **commit**: Un punct de salvare în git, cu un mesaj scurt care spune ce s-a schimbat. Exemplu: „Adaugă căutarea” e mesajul unui commit; commit-ul ține proiectul exact cum era în acel moment. - **repository**: Un folder de proiect urmărit de git: codul plus tot istoricul punctelor de salvare. Pe scurt, „repo”. Exemplu: Repo-ul tău ține minte fiecare versiune a proiectului de la ziua 2 încolo. - **GitHub**: Site-ul unde îți ții repo-urile în cloud: copie de siguranță, istoric, și locul de unde Vercel îți ia codul ca să-l publice. Contul ți-l faci în ziua 1. Exemplu: Fiecare push trimite commit-urile tale pe GitHub, iar Vercel publică automat versiunea nouă. - **push**: Comanda prin care trimiți commit-urile de pe calculatorul tău pe GitHub. Exemplu: Faci commit, faci push, iar peste un minut schimbarea e pe adresa publică. - **deploy**: Să copiezi aplicația de pe calculatorul tău pe o mașină mereu pornită, ca oricine s-o poată deschide la o adresă web. „Publicat” = live pe internet. Exemplu: În ziua 7 publici proiectul pe Vercel și îl deschizi de pe telefon. - **Vercel**: Un serviciu de găzduire care îți ia aplicația de pe GitHub și o pune pe internet, gratuit pentru proiecte mici. Publică singur la fiecare push pe ramura principală. Exemplu: Proiectul tău și acest plan stau pe Vercel. - **găzduire**: Închirierea de spațiu pe calculatoarele mereu pornite ale cuiva, ca site-ul tău să fie accesibil zi și noapte. Exemplu: Vercel îți găzduiește aplicația; un registrar îți închiriază numele de domeniu. - **domeniu**: Adresa ta pe internet, de felul numele-tau.ro. O închiriezi anual de la un registrar; așa te găsesc oamenii. Exemplu: În săptămâna 4 cumperi un domeniu și îl îndrepți către aplicația de pe Vercel. - **subdomeniu**: O secțiune cu nume în fața domeniului, gratuită odată ce ai domeniul. Exemplu: serban.bgn.ro e un subdomeniu al bgn.ro. - **DNS**: Agenda de adrese a internetului: traduce un nume de domeniu în calculatorul la care trebuie să te conectezi. „Îndrepți domeniul către Vercel” înseamnă că editezi DNS-ul. Exemplu: Când DNS-ul domeniului tău arată spre Vercel, scrii adresa și se deschide aplicația. - **URL**: O adresă web completă: domeniul plus calea către o pagină anume. Exemplu: https://proiectul-tau.ro/despre e un URL: domeniul proiectul-tau.ro, pagina /despre. - **cheie anon**: Cheia publică a Supabase, ca adresa poștală a bazei de date: poate s-o știe toată lumea, pentru că reguli separate hotărăsc ce are voie să facă un vizitator. Sora ei, cheia de serviciu, e cheia universală și rămâne secretă. Exemplu: Pagina ta folosește cheia anon; cheia de serviciu nu iese niciodată din panoul Supabase. - **RLS**: Row Level Security: regulile din Supabase care hotărăsc ce rânduri din tabel poate vedea sau schimba fiecare utilizator. RLS e ce face sigur ca cheia anon să fie publică. Exemplu: Cu RLS, oricine are linkul poate citi, dar doar cei din lista ta pot scrie. - **login cu Google**: Utilizatorul intră în aplicația ta cu contul lui de Google, fără să-și facă încă o parolă. Tehnic se numește OAuth: Google confirmă cine e omul și îi dă aplicației tale un bilet de intrare, fără să-i dea parola. Exemplu: Butonul „Continuă cu Google” din proiectul tău e login cu Google prin Supabase. - **OAuth**: Protocolul din spatele butoanelor „Continuă cu Google”: un serviciu de încredere confirmă identitatea și dă aplicației un bilet de acces, fără să-i dezvăluie parola. Exemplu: Când login-ul dă eroare „redirect_uri_mismatch”, e OAuth care îți spune că adresa de întoarcere nu e în lista aprobată. - **design system**: Setul de reguli și componente gata făcute (culori, fonturi, butoane, câmpuri, tabele) din care se construiesc toate ecranele unei aplicații, ca să arate ca făcute de aceeași mână. Exemplu: bgn-33 e design system-ul pe care îl folosești: nu inventezi butoane, iei butonul din el. - **bgn-33**: Design system-ul lui Bogdan: o foaie de stil și un catalog de componente. Îl primești odată cu pachetul BGN; Claude îl aplică singur când ecranul e pentru un proiect BGN sau „altul” cu bgn-33. Exemplu: „Fă ecranul cu bgn-33” și Claude folosește cardurile, butoanele și pilulele din catalog. Din T25 ai stilul tău. - **DevTools**: Panoul de inspecție din Chrome (Cmd+Option+I). Tab-ul Console arată ce face pagina și mesajele exacte de eroare când se strică ceva. Exemplu: În Ziua de Debug citești primul tău mesaj de eroare adevărat în Console. - **mock**: O imitație realistă. Un login mock te lasă să intri fără Google; o bază de date mock întoarce date inventate. Profesioniștii construiesc întâi cu imitații și conectează serviciile reale după. Exemplu: Până în săptămâna 3, progresul e mock: se ține în localStorage. - **MVP**: Minimum Viable Product: cel mai mic produs care testează cea mai riscantă presupunere. Nu un produs mic, ci o întrebare mare la care răspunzi ieftin. Exemplu: MVP-ul tău: zece oameni primesc linkul și unul dintre ei revine a doua zi fără să-l rogi, sau nu. - **Mom Test**: Regulile lui Rob Fitzpatrick pentru discuțiile cu utilizatorii: vorbești despre viața lor, nu despre ideea ta; întrebi ce au făcut concret în trecut, nu ce ar face; ignori complimentele, chiar și mama ta te-ar minți politicos. Exemplu: „Când ai învățat ultima oară pentru un test și cum?” bate „ai folosi o aplicație ca asta?”. - **JTBD**: Jobs to Be Done: oamenii nu cumpără produse, le „angajează” ca să facă o treabă. Întrebi care e treaba și concurența adevărată apare singură. Exemplu: Oamenii „angajează” proiectul tău ca să scape de o grijă anume; concurența include și „mă descurc cum m-am descurcat până acum”. - **PWA**: Progressive Web App: un site care se poate pune ca iconiță pe ecranul telefonului și merge ca o aplicație, fără App Store. Exemplu: În săptămâna 4, prietenii tăi adaugă proiectul pe ecranul de start ca pe o aplicație. - **README**: Documentul de la intrarea unui proiect: ce e, cum se pornește, la ce să fii atent. Primul lucru pe care îl citește orice om care deschide repo-ul. Exemplu: README-ul tău din săptămâna 4 spune cinstit ce e gata, ce e imitație și ce ai face diferit. - **GDPR**: Regulamentul european de protecție a datelor: dacă aplicația ta ține date despre oameni (un e-mail, un nume, un istoric de răspunsuri), le spui ce ții, de ce, și le dai voie să-și șteargă contul. Exemplu: Pagina ta de confidențialitate și butonul „șterge-mi contul” există din cauza GDPR. - **token**: Bucățile mici de text (cam fragmente de cuvinte) pe care le citesc și le scriu modelele AI. Abonamentele Claude măsoară folosirea în tokeni, de asta săptămânile grele de construit pot atinge limita. Exemplu: O sesiune lungă de Claude Code folosește milioane de tokeni; dacă dai de limită, spune-i lui Bogdan. - **cloud**: „Cloud” = calculatoarele mereu pornite ale altora, închiriate prin internet. Datele din cloud se văd de pe orice aparat, spre deosebire de cele ținute într-un singur browser. Exemplu: Când trackerul tău se mută în cloud, îl vezi și de pe telefon, și Bogdan îl vede din Cluj. - **schelet**: Scheletul gol-dar-funcțional al unei aplicații noi: foldere, configurare, o pagină, generate întâi ca să poată începe construcția. Ca structura casei înainte de camere. Exemplu: În ziua 6 Claude face scheletul proiectului, apoi umpli ecranele săptămână de săptămână. - **producție**: Versiunea live, reală, a unei aplicații, pe care o ating utilizatori adevărați, spre deosebire de copia de lucru de pe calculatorul tău. „Gata de producție” înseamnă destul de solid pentru străini. Exemplu: Din ziua în care primul om primește linkul, proiectul tău e în producție și regulile se înăspresc. - **audit**: O verificare independentă, făcută de cineva care n-a construit lucrul verificat, cu o listă clară de ce înseamnă „bine”. Exemplu: SuperBoris face auditul proiectului tău în săptămânile 3 și 4. - **consolă**: Tab-ul Console din DevTools: locul unde pagina își scrie mesajele și erorile. Prima oprire când ceva nu merge. Exemplu: „Uncaught TypeError: cannot read properties of undefined” e un mesaj din consolă, și Claude îl înțelege dacă i-l lipești întreg.