# David învață Claude construind o platformă de învățare pentru facultate

Plan de învățare Claude, 4 săptămâni, 4 ore pe zi (luni–vineri). Publicat la https://david.bgn.ro. Pregătit de Bogdan, cu Claude.

## Cum citește Claude fișierul ăsta
Fișierul e versiunea text a planului de la david.bgn.ro. Când David î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.

## Săptămâna 1: Fundații: Claude, conturile și ce construim (Nivel 1: prompturi date)

Conturile și primul artifact în prima oră. Rețeta promptului, pe ceva construit de tine. Project-ul tău (un Claude cu memorie) și trackerul v1, prima ta aplicație cu memorie. Miercuri, saltul: Claude Code și agenții lui Bogdan pe calculatorul tău, primul proiect cu reguli (CLAUDE.md) și puncte de salvare (git). Joi și vineri, Bruce: nevoia, concurența, trei discuții cu oameni reali, PRD-ul cu decizii numerotate și prototipul pe bgn-33.

Livrabile: cont Claude și GitHub · 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 (Claude, GitHub) și folderul proiectului

Întâi, fără Claude:
- 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.
- Contul GitHub: pe github.com → Sign up. Alege un nume de utilizator pe care îl poți pune și pe un CV (prenume-nume sau ceva apropiat), 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.
- Trimite-i lui Bogdan, azi, numele tău de utilizator GitHub. El te invită la pachetul cu agenți (BGN-ro/agenti-bgn); fără invitația acceptată, ziua 3 nu poate începe.
- Pune două semne de carte în bara Chrome: claude.ai și david.bgn.ro (planul ăsta).
- Fă un folder „examino” în Documents (sau cum vrei să-i zici platformei, numele de lucru îl alegi în T04). Tot ce descarci pentru plan și tot ce construiești stă acolo. Descarcă de pe david.bgn.ro fișierul „planul ca text” (linkul e în Prezentare) și pune-l în folder.

Promptul:

```
Salut. Sunt David, am 19 ani, sunt student la Madrid și ăsta e primul mesaj pe care ți-l trimit vreodată. Încep un plan de 4 săptămâni (stă la david.bgn.ro) în care învăț să lucrez cu tine construind un produs adevărat: platforma ta de învățare pentru facultate.

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 tău mesaj respectă deja rețeta: cine ești (context), ce faci (scop), întrebări numerotate (formă). Scriai prompturi corect înainte să știi cuvântul. Ș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 (T47) î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 de magie)

Promptul:

```
Construiește-mi un artifact HTML foarte simplu (doar HTML + CSS, fără librării) care arată un singur card mare cu:
- titlul „Examino” (nume de lucru) cu font mare, gras, și un gradient de la verde-închis spre turcoaz
- un rând de descriere: „Platforma ta de învățare pentru facultate: grile, carduri, simulări de examen”
- un buton (doar de decor) pe care scrie „Începe un test”
- 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 că 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

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 platforma mea”. Enumeră cele 10 decizii mari pe care ar fi trebuit să le ghicești.
3. Rescrie promptul meu ca să fie complet, pentru un card care va fi prima pagină a platforma ta de învățare pentru facultate: un student care are examen la o materie și vrea să se verifice înainte trebuie să înțeleagă în 5 secunde ce e și ce să apese.
```

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 · Platforma ta pe o foaie: ce construim, pentru cine, numele de lucru

Promptul:

```
Vreau să scriu „pagina de o foaie” a produsului meu, înainte să construiesc orice. Produsul: platforma ta de învățare pentru facultate, pentru studenții din anul tău. Modelul de la care pornesc e o aplicație pe care a făcut-o Bogdan, prietenul tatălui meu, pentru colegii lui care dau un examen greu (ccf.bgn.ro): grile cu explicații, carduri de memorat, lecții scurte de teorie, simulări de examen cu timer și un clasament între colegi, cu login cu Google și progresul salvat.

Ajută-mă să scriu pagina, punându-mi întrebări pe rând (una, aștepți răspunsul, apoi următoarea), nu toate odată:
1. Cine e utilizatorul, concret (o persoană, nu „studenții”)? Ce face azi când vrea să se pregătească și ce îl enervează la felul ăla?
2. Care e sursa conținutului: cursurile, slide-urile și notițele tale (și ale colegilor care vor să contribuie)? Ce am voie să folosesc din ea?
3. Care dintre cele cinci module (grile, carduri, teorie, simulare, clasament) contează cel mai mult pentru utilizatorul meu și de ce? Ce las pe mai târziu?
4. Cum arată simularea de examen la mine: format configurabil per materie: de exemplu 30 de întrebări în 45 de minute, prag de trecere 50%, așa cum e examenul real la materia respectivă?
5. În ce limbă e interfața: de hotărât în prima săptămână: colegii tăi din Madrid citesc în spaniolă sau engleză, deci interfața probabil nu va fi în română?

La final, scrie pagina de o foaie (maximum 300 de cuvinte) și propune-mi 5 nume de lucru pentru produs, cu domeniile .ro sau .com probabil libere. 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. Iar „nu lua decizii în locul meu, scrie «de hotărât»” îl oprește pe Claude să umple golurile cu presupuneri plauzibile. 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 „platforma-mea-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 · 1h · Pregătire · Project-ul tău în claude.ai: un Claude cu memorie

Promptul:

```
Vreau să fac un Project în claude.ai dedicat platformei mele. 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 david.bgn.ro (plan-david.md) și pagina de o foaie a produsului (platforma-mea-v0.md).
3. Scrie-mi textul exact de instrucțiuni personalizate pe care să-l lipesc. Trebuie să spună: sunt David, 19 ani, student, n-am scris cod niciodată dar învăț repede; construiesc platforma ta de învățare pentru facultate; 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.
```

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 salva platforma progresul unui utilizator?”). 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?”.

### T06 · Ma · 2h · Tracker · Tracker v1: construiește o aplicație cu memorie (localStorage)

Promptul:

```
Construiește-mi un artifact HTML de sine stătător (HTML + CSS + JS, fără librării externe): un tracker de progres pentru planul meu de 4 săptămâni (atașez lista sarcinilor, din plan-david.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 „david_progres”
- 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 #E8386F, 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. Și da, îți construiești propria unealtă de urmărit progresul: o folosești zilnic patru săptămâni, și o vei muta în cloud în săptămâna 3, ca s-o vadă și Bogdan.

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. Repari limitarea asta singur în T34.

### T07 · Ma · 1h · 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.

### T08 · Mi · 1.5h · Pregătire · Instalează Claude Code și pachetul BGN (agenții lui Bogdan)

Î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ă ce i-ai trimis lui Bogdan numele de utilizator, luni). Acceptă invitația. Dacă n-a venit, scrie-i lui Bogdan înainte să continui.
- Instalează aplicația Claude pentru Mac (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 Mac-ului, o scrii tu.
- Bogdan ți-a dat un fișier, „agenti-bgn-instalare-prieteni.md”. 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 (asta e în instrucțiunile tale pentru totdeauna).

Pune răspunsul la îndoială: După repornire, scrie într-o sesiune nouă: „Verifică pachetul BGN: ai primit regulile BGN la pornire și ai skill-urile bruce, supernicu și superboris?”. Apoi întreabă: „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 T09, în CLAUDE.md.

### T09 · Mi · 1.5h · Claude Code · Primul proiect în Claude Code: folder, regulile tale (CLAUDE.md), primul punct de salvare (git)

Promptul:

```
Pornim proiectul platforma ta de învățare pentru facultate î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.
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); orice ecran se face cu bgn-33; 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 din viața mea de student.
4. Pune în folder pagina de o foaie (platforma-mea-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 prompt-ul 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ă. 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 platforma-mea-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.

### T10 · Mi · 1h · Curaj · Ora întrebărilor curajoase: golește parcarea de cuvinte

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, trackerul, proiectul din Claude Code), 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.

### T11 · Jo · 2h · Bruce · Nevoia · Bruce, partea 1: nevoia (cine are problema și ce vrea să obțină)

Promptul:

```
/bruce hai să definim platforma ta de învățare pentru facultate. Pornesc de la pagina mea de o foaie (platforma-mea-v0.md, în folder). Utilizatorul e un student care are examen la o materie și vrea să se verifice înainte; sursa de conținut e cursurile și notițele tale; modelul e aplicația ccf.bgn.ro a lui Bogdan (grile, carduri, teorie, simulare, clasament, login cu Google).

Vreau să trecem azi doar prin partea de Nevoie: reformularea nevoii, segmentele, cu cine începem, jobul complet, la ce suntem cei mai buni și ce NU facem. Propune tu la fiecare pas, eu confirm sau corectez. Nu trece la research și la produs azi.

Două lucruri despre mine: n-am scris cod niciodată, 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 „cu cine începem” (primul segment), contrazice-l o dată, cu un motiv din viața ta („colegii mei nu fac asta, fac aia”). 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 „Când Claude greșește”).

### T12 · 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 platforma ta de învățare pentru facultate. Nevoia confirmată ieri e în fișierul de lucru. Vreau harta completă a felului în care rezolvă alții problema asta azi: Quizlet, Anki, Brainscape, Knowt, Kahoot și modul în care colegii tăi învață azi (grupuri de WhatsApp, fotografii la notițe, Google Docs partajate).

Pentru fiecare: ce face bine, ce face prost, cât costă, ce ar lua utilizatorul meu de acolo. La final: ce atribute contează pentru utilizatorul meu (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 colegi, 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 pe 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.

### T13 · Vi · 2.5h · Bruce · Produs · Bruce, partea 3: PRD-ul și prototipul (pe care îl atingi)

Promptul:

```
/bruce trecem la Produs pentru platforma ta de învățare pentru facultate. Nevoia și research-ul sunt în fișierul de lucru; uite și ce am aflat de la cei trei colegi (lipesc notițele, cuvânt cu cuvânt).

Vreau:
1. Deciziile de structură, în cuvinte, numerotate (D1, D2…), fiecare cu motivul: ce module intră în prima versiune și ce nu; cum arată o întrebare (câmpurile ei: materie, capitol, text, variante, răspuns corect, explicație, sursă (cursul și pagina)); cum arată simularea (simulare de examen cu regulile fiecărei materii); ce e public fără cont și ce cere login cu Google; în ce limbă e interfața.
2. Propune-mi o referință de layout (o aplicație reală după care ne luăm) și așteaptă „ok”.
3. Apoi prototipul HTML, pe design system-ul bgn-33: ecranele principale, clickabile, cu stările goale și de eroare. Fiecare ecran răspunde la „ce vede utilizatorul, 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 și joacă rolul utilizatorului tău, cu voce tare: „sunt X, am examen peste 3 zile, intru pe site… ce apăs?”. 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 review.

### T14 · Vi · 1h · Review · Review-ul de vineri cu Bogdan (și 15 minute cu fratele tău)

Promptul:

```
Pregătește-mă pentru review-ul de vineri cu Bogdan. 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: produsul e al meu).
5. Parcarea mea de cuvinte, cu ce a rămas neclar.

Apoi: Janos Jr a făcut același drum săptămâna asta pentru platforma pentru examenul auto. Dă-mi 3 întrebări pe care să i le pun ca să aflu ce a decis diferit și de ce.
```

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 cele 15 minute cu fratele tău sunt gratuite și valoroase: construiți același tip de produs pentru lumi diferite, iar deciziile diferite vă arată ce e specific și ce e universal.

Pune răspunsul la îndoială: În review, când Bogdan îți dă o părere despre produs, 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.

### T15 · 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 aplicație: schelet, date separate de cod, server local. Primele 20 de întrebări, scrise cu Claude și verificate de tine la sursă. GitHub, apoi Vercel: marți seara platforma e pe internet și o deschizi de pe telefon. Carduri cu repetiție spațiată, simularea de examen cu toate stările ei. Ziua de Debug: trei defecte plantate, tu le găsești. Auditul de design. Vineri: trei colegi folosesc site-ul sub ochii tăi, PRD v2.

Livrabile: aplicația pe localhost și pe o adresă publică · 20 de întrebări verificate · repo pe GitHub, deploy automat · grile, carduri, simulare funcționale · tracker v2 · PRD v2 · jurnalul săptămânii 2

### T16 · Lu · 2h · Schelet · De la prototip la proiect adevărat: scheletul aplicației și serverul local

Promptul: (completează spațiile)

```
Trecem de la prototipul HTML făcut cu Bruce la aplicația reală, î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 din bgn-33 (o singură copie a fișierului, în rădăcină), codul aplicației (app.js) și DATELE separate de cod, într-un folder date/ (întrebările în JSON)
- pornești un server local și îmi spui adresa la care văd aplicația în Chrome; explică-mi de ce nu deschidem fișierul direct
- primul ecran care merge cap-coadă: [ECRANUL PE CARE L-AI ALES CA PRIORITATE ÎN PRD, DE EXEMPLU GRILELE SAU SIMULAREA], cu 5 întrebări 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. Întrebările nu sunt „în program”, 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ă.

Pune răspunsul la îndoială: Deschide fișierul date/intrebari.json singur, în editor, și schimbă manual textul unei întrebări. Reîncarcă pagina. S-a schimbat? Tocmai ai editat o aplicație 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ă.

### T17 · Lu · 2h · Conținut · Banca de întrebări: schema unei întrebări și primele 20, verificate la sursă

Promptul: (completează spațiile)

```
Hotărâm cum arată o întrebare în platforma mea și scriem primele 20.

1. Propune schema unei întrebări (câmpurile și ce înseamnă fiecare): materie, capitol, text, variante, răspuns corect, explicație, sursă (cursul și pagina). Explică-mi de ce fiecare câmp merită să existe și ce se întâmplă dacă lipsește.
2. Apoi scriem 20 de întrebări din sursa mea: [SURSA EXACTĂ PE CARE O FOLOSEȘTI AZI: DE EXEMPLU „CURSUL 3, PAGINILE 10–25” SAU „OUG 195/2002, ART. 50–60”]. Le lipesc / le atașez. Propui câte 5 odată, în JSON, fiecare cu explicație și cu sursa exactă (pagina sau articolul).
3. Eu verific fiecare întrebare la sursă și îți spun „bun”, „greșit: …” sau „ambiguu: …”. Doar cele cu „bun” intră în date/intrebari.json, cu câmpul „verificat: true”.
4. La final, un rezumat: câte propuse, câte bune din prima, ce tip de greșeli ai făcut.

Reguli pentru întrebări: [REGULILE TALE DE CALITATE: O SINGURĂ IDEE PE ÎNTREBARE? VARIANTE DE ACEEAȘI LUNGIME? FĂRĂ „TOATE DE MAI SUS”? CE TE-A ENERVAT LA GRILELE PE CARE LE-AI DAT TU?].
```

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 la utilizatori. Deschizi cursul sau slide-ul citat și confirmi că răspunsul și explicația sunt exact ce scrie acolo; o întrebare fără sursă nu intră în platformă. Punctul 4 e oglinda: după 20 de întrebări știi exact ce tip de greșeală face Claude pe materia ta, și îl poți preveni în prompturile următoare.

Pune răspunsul la îndoială: Alege una dintre întrebările „bune” și cere-i lui Claude: „Ce ar spune un profesor sever despre întrebarea asta?”. Dacă găsește o ambiguitate pe care tu n-ai văzut-o, standardul tău de „bun” era prea jos. Ridică-l și reverifică celelalte 19.

### T18 · Ma · 1.5h · GitHub · Codul tău în cloud: repo privat pe GitHub

Promptul: (completează spațiile)

```
Vreau să pun proiectul pe GitHub, ca repo privat, ca să am o 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 de GitHub din terminal (gh) și faci primul push
3. îmi arăți în browser repo-ul și îmi explici ce văd: commit-uri, fișiere, istoricul
4. 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: Mac-ul tău. Dacă îl vărsai cu cafea, pierdeai tot. De azi există în două locuri și, mai important, GitHub e punctul de plecare pentru publicare: Vercel va lua codul de acolo, nu de la tine. Întrebarea despre chei și parole e esențială acum, cât n-ai niciuna: în săptămâna 3 vei avea, și regula trebuie să fie deja reflex.

Pune răspunsul la îndoială: Șterge un fișier mic de pe Mac (de exemplu README.md), apoi cere-i lui Claude să-l aducă înapoi de pe GitHub. Verifică tu că e identic. Abia acum „copie de siguranță” e un lucru pe care l-ai văzut funcționând.

### T19 · Ma · 1.5h · Vercel · Publicare: platforma ta pe internet, cu Vercel (și de pe telefon)

Promptul: (completează spațiile)

```
Vreau să public platforma 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 facem:

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 telefon și fac [UN TEST CONCRET PE CARE ÎL ALEGI TU: DE EXEMPLU RĂSPUND LA 5 GRILE]; apoi schimbăm un text, push, și vedem în cât timp apare schimbarea
4. îmi explici diferența dintre adresa de pe Vercel și un domeniu al meu (îl cumpăr în săptămâna 4)

Nu publicăm nimic ce n-am verificat întâi pe localhost.
```

De ce funcționează promptul: Ziua 7 și ai un produs 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 site-ul și ce ar apăsa. Dacă răspunsul lui nu seamănă cu PRD-ul tău, ai găsit prima problemă reală a produsului, la 48 de ore după ce ai început să-l construiești. Asta e viteza care contează.

### T20 · Ma · 1h · Tracker · Tracker v2: stări, momentul bifării, export JSON

Promptul: (completează spațiile)

```
Îmbunătățesc 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
- [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.
```

De ce funcționează promptul: JSON e formatul în care trăiesc datele pe internet: întrebările tale, progresul, 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ă manual 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.

### T21 · Mi · 2h · Carduri · Cardurile de memorat și repetiția spațiată (de ce funcționează Anki)

Promptul: (completează spațiile)

```
Construim ecranul de carduri (față: întrebare sau termen; verso: răspuns) cu repetiție spațiată. Înainte de cod, explică-mi în 10 rânduri ce e repetiția spațiată și propune-mi cel mai simplu algoritm care are efect (de exemplu cutiile lui Leitner), cu un exemplu concret pe trei zile.

Apoi:
- 30 de carduri din [CAPITOLUL SAU TEMA PE CARE O ALEGI], propuse câte 10, verificate de mine la sursă ca la grile
- ecranul: un card, două butoane („știam” / „nu știam”), contorul zilei, și ce revine mâine
- progresul cardurilor se ține deocamdată în localStorage (se mută în cloud săptămâna viitoare), în același format ca grilele, ca migrarea să fie ușoară
- design cu bgn-33, și pe telefon întâi: [CE E IMPORTANT PE TELEFON PENTRU UTILIZATORUL TĂU: DEGET MARE? UN SINGUR CARD PE ECRAN?]

Punct de salvare după fiecare pas care merge.
```

De ce funcționează promptul: „Explică-mi algoritmul înainte de cod” e diferența dintre a avea o funcție și a o înțelege. Și observă constrângerea „același format ca grilele, ca migrarea să fie ușoară”: gândești cu două săptămâni înainte, iar Claude construiește altfel când știe încotro mergi. Asta înseamnă să dai direcție, nu doar comenzi.

Pune răspunsul la îndoială: Întreabă: „Ce ar spune cineva care a folosit Anki cinci ani despre varianta noastră?”. Vei primi o listă de lucruri care lipsesc. Nu le construi pe toate: alege unul, cu un motiv, și notează restul în PRD la „mai târziu”. A spune nu cu motiv e o decizie de produs.

### T22 · Mi · 2h · Simulare · Simularea de examen: timer, reguli, rezultat, revizuirea greșelilor

Promptul: (completează spațiile)

```
Construim simularea de examen, ecranul pentru care există platforma. Regulile: format configurabil per materie: de exemplu 30 de întrebări în 45 de minute, prag de trecere 50%, așa cum e examenul real la materia respectivă.

Înainte de cod, arată-mi planul și lista stărilor prin care trece utilizatorul (înainte de start, în timpul testului, timp expirat, terminat cu succes, picat, revizuire). Așteaptă „ok”.

Apoi:
- selecția întrebărilor: [CUM SE ALEG: ALEATORIU DIN TOATĂ BANCA? CÂTE DIN FIECARE CATEGORIE?]
- timerul vizibil, cu avertisment la [CÂND VREI AVERTISMENT]
- ecranul de rezultat: scorul, trecut/picat după regula reală, și lista greșelilor cu explicația și sursa fiecăreia
- ce se întâmplă dacă închid pagina la mijloc: [TU HOTĂRĂȘTI: SE PIERDE? SE REIA?] și de ce
- rezultatele se salvează local, în același format ca restul progresului

Testăm împreună un examen complet, de la start la rezultat, î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 (timpul a expirat exact când apăsai; ai închis tab-ul). Le enumeri înainte, și Claude le construiește pe toate. Iar „testăm un examen complet î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ă: Fă o simulare în care răspunzi intenționat greșit la toate. Apoi una în care lași timpul să expire. Ce îți spune aplicația în fiecare caz? Dacă vreun mesaj te-ar face să te simți prost ca utilizator, rescrie-l tu, în cuvintele tale, și cere-i lui Claude să-l pună.

### T23 · 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 aplicație 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ă, unul care face un calcul greșit (de exemplu scorul). Apoi fă commit pe ramura aia și spune-mi doar: „gata, găsește-le”.

Eu 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 utilizator și de ce?”. Răspunsul e, de obicei, calculul greșit: aplicația arată bine și minte. Asta e motivul pentru care în săptămâna 4 scrii teste automate pentru punctaj.

### T24 · Jo · 2h · Design · Auditul de design cu bgn-33: stări, telefon, consecvență între ecrane

Promptul: (completează spațiile)

```
Fă un audit de design al aplicației contra design system-ului bgn-33 și contra ei însăși. Nu repara nimic înainte să-mi arăți lista.

Verifică, ecran cu ecran:
- folosește componentele din bgn-33 (butoane, carduri, câmpuri, pilule) sau a inventat altele? listează fiecare abatere
- stările: gol (nicio întrebare încă), încărcare, eroare, succes; care lipsesc?
- pe telefon: [LĂȚIMEA TELEFONULUI TĂU ȘI CE TE-A DERANJAT CÂND L-AI FOLOSIT ACOLO]
- consecvența: același lucru arată la fel peste tot? (butonul principal, felul în care se afișează o întrebare, mesajele de eroare)
- contrastul textului și mărimea țintelor de apăsat

Livrează lista ordonată după cât de mult deranjează utilizatorul, cu efortul estimat pentru fiecare. Eu aleg ce reparăm azi: [CÂT TIMP AI PENTRU REPARAȚII].
```

De ce funcționează promptul: Un design system există ca să nu iei de 40 de ori aceeași decizie și ca produsul să arate făcut de aceeași mână. Auditul contra lui e mecanic și Claude îl face bine; partea ta e prioritizarea: „cât deranjează utilizatorul” bate „cât de urât e”. Observă că promptul interzice reparatul înainte de listă: altfel Claude repară primul lucru găsit și uită restul.

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.

### T25 · Vi · 1.5h · Utilizatori · Mom Test cu produsul în mână: trei colegi folosesc site-ul, tu taci

Promptul: (completează spațiile)

```
Am dat adresa publică la trei colegi și i-am privit folosind platforma, fără să-i ajut, câte 10 minute. 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. Un tabel: coleg / 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, „aș folosi-o sigur”) ș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 TU CĂ TE TENTEAZĂ SĂ CREZI, DAR N-AI DOVADĂ].
```

De ce funcționează promptul: Până acum ai discutat despre produs; azi l-ai văzut folosit. Diferența dintre „ar fi util” și „n-a găsit butonul de start” 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.

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 colegii?”. Claude e surprinzător de cinstit la întrebarea asta. Tu ești?

### T26 · Vi · 1.5h · PRD v2 · PRD v2: corectat cu ce te-a învățat construcția și ce au arătat colegii

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 colegi. Versiunea 1 rămâne neatinsă în folder; v2 e fișier nou, cu data.

1. Compară PRD-ul v1 cu aplicația care există azi: listează fiecare nepotrivire (ce zice documentul / ce face aplicația) și întreabă-mă, pe rând, care câștigă.
2. Deciziile noi din săptămâna asta (din jurnalul de decizii și din T25) 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, cu numele meu ca autor, ș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 produsul 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 fratelui tău și cere-i să-ți spună, fără să vadă aplicația, ce ar construi din el. Unde descrie altceva decât ai tu, documentul e neclar. Repară documentul, nu explica.

### T27 · Vi · 1h · Review · Review-ul de vineri și jurnalul săptămânii 2

Promptul: (completează spațiile)

```
Pregătește-mă pentru review-ul cu Bogdan, în 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 ecranele pe adresa publică, în 5 minute, pornind de la [CE VREI SĂ VADĂ BOGDAN PRIMA DATĂ ȘI DE CE]
- ce i-aș arăta lui Janos Jr: o decizie pe care am luat-o diferit față de el și ce aș vrea să aflu de la 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 produs pe internet, deci review-ul devine demo. Un demo bun e o poveste în 5 minute, nu un tur al tuturor butoanelor: „uite utilizatorul, uite problema lui, uite ce face la noi”. Alegi tu începutul, pentru că tu știi ce ai vrea să i se întâmple lui Bogdan în primele 30 de secunde.

Pune răspunsul la îndoială: În review, roagă-l pe Bogdan să folosească el aplicația, pe telefonul lui, fără să-i spui nimic. 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)

Platforma capătă memorie în cloud: Supabase, tabele proiectate înainte de cod, reguli de acces (RLS) din prima zi. Login cu Google, parcurs până la capăt. Profiluri și clasament calculat pe server. Prima ta funcție pe server și primul API: Claude intră în produs, cu cheia la loc sigur și cu limită. Trackerul v3 în cloud, cu vederea lui Bogdan. Primul audit SuperBoris, pe securitate. Vineri: conținut la scară și întrebarea despre drepturi de autor.

Livrabile: Supabase cu RLS · login cu Google funcțional pe localhost și public · clasament · funcția API cu Claude · tracker v3 în cloud · raport de audit · conținutul la scară · jurnalul săptămânii 3

### T28 · Lu · 2h · Bază de date · Prima ta bază de date: Supabase, tabelele și cele două chei

Misiunea: Fă-ți cont pe Supabase, creează proiectul bazei de date al platformei și proiectează tabelele împreună cu Claude, ÎNAINTE să scrii vreun rând de cod în aplicație. 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 platforma azi în localStorage (progres la grile, carduri, rezultate la simulări) și că vrei să le muți în cloud ca să se vadă de pe orice aparat
- 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 profiluri, progres, raspunsuri, rezultate_simulari), cu câmpurile fiecăreia ș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 aplicație (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 platformei din localStorage într-o bază de date în cloud, pe Supabase, ca progresul să se vadă de pe orice aparat și ca mai mulți utilizatori să poată avea fiecare progresul lui. Azi facem DOAR contul, proiectul și tabelele, fără să atingem aplicația.

Înainte de orice pas: explică-mi ce e o bază de date relațională (tabele, rânduri, chei primare, legături) cu o comparație din viața de student, și cum arată datele mele de azi din localStorage mutate în tabele.

Apoi propune-mi tabelele, cu câmpurile fiecăreia și legăturile dintre ele, și așteaptă „ok”. Abia apoi mă ghidezi în panoul Supabase, pas cu pas, cu „gata” de la mine: cont, proiect în regiunea Europa (spune-mi de ce contează), tabelele, și unde găsesc adresa proiectului și cele două chei.

Explică-mi diferența dintre cheia anon și cheia de serviciu și spune-mi explicit care din ele are voie în fișierele proiectului și care nu, niciodată. Scrie regula asta în CLAUDE.md.
```

De ce funcționează promptul: Nivelul 3 începe azi: tu scrii promptul, lista de mai sus e doar ce trebuie să acopere. Pe fond: tabelele se proiectează înainte de cod, pentru că o tabelă greșită se repară greu după ce are date. Iar regula celor două chei e singura regulă de securitate pe care trebuie s-o știi pe de rost: una e adresa poștală (publică), cealaltă e cheia de la casă (secretă).

Pune răspunsul la îndoială: După ce ai tabelele, întreabă: „Ce întrebare NU va putea răspunde baza asta de date, pe care utilizatorul meu ar vrea-o?” (de exemplu: la ce capitol greșesc cel mai des?). Dacă lipsește un câmp, adaugă-l acum, cât tabelele sunt goale.

### T29 · Lu · 2h · Progres în cloud · Progresul în cloud: aplicația citește și scrie în Supabase (cu RLS de la început)

Misiunea: Mută progresul (grile, carduri, simulări) din localStorage în Supabase, fără să pierzi ce ai deja, și cu regulile de acces (RLS) activate din prima zi. Până la login-ul de mâine, utilizatorul e „anonim” cu un identificator local.

Promptul tău trebuie să acopere:
- constrângerea de a păstra formatul datelor pe care l-ai ales în săptămâna 2 (migrarea ușoară pe care ai pregătit-o în T21)
- ce se întâmplă cu progresul existent din localStorage la prima pornire (se importă o dată, apoi sursa de adevăr e cloud-ul)
- cererea ca RLS să fie activ pe fiecare tabelă de la început, cu reguli scrise pe înțelesul tău („un utilizator își vede doar rândurile lui”), și explicația de ce fără RLS cheia anon ar fi periculoasă
- ce face aplicația când internetul pică la mijlocul unei simulări (salvezi local și sincronizezi după? arăți un mesaj?), decizia ta
- un test cap-coadă: răspunzi la grile pe laptop, deschizi pe telefon, vezi același progres
- punct de salvare și o notă în README despre unde stau datele acum

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Conectăm aplicația la baza de date din Supabase. Progresul (grile, carduri, rezultate la simulări) se citește și se scrie de acum în tabele, nu în localStorage; formatul datelor rămâne cel ales în săptămâna 2.

Reguli:
- RLS activ pe fiecare tabelă de la început; scrie-mi regulile în cuvinte obișnuite înainte de SQL și explică-mi ce s-ar putea întâmpla fără ele cu cheia anon publică
- la prima pornire, progresul existent din localStorage se importă o singură dată; după aceea cloud-ul e sursa de adevăr
- până mâine, când facem login-ul, utilizatorul e anonim, cu un identificator generat local; gândește structura ca mâine să legăm identificatorul de contul Google fără să pierdem datele
- dacă pică internetul în timpul unei simulări: salvezi local și sincronizezi la revenire, cu un mesaj discret
- înainte de cod, planul; după fiecare pas care merge, punct de salvare

Testul final îl facem împreună: răspund la 5 grile pe laptop, deschid platforma pe telefon și trebuie să văd același progres.
```

De ce funcționează promptul: Azi aplicația ta devine „cu backend”: datele trăiesc în altă parte decât pagina. Trei lucruri de observat în prompt: RLS de la început (securitatea pusă după e de zece ori mai scumpă), gândirea cu o zi înainte (identificatorul anonim care devine cont Google) și testul cap-coadă pe două aparate, singura dovadă care contează.

Pune răspunsul la îndoială: Cere-i lui Claude să-ți arate cum ar citi un străin tabela ta DACĂ RLS ar fi oprit (poate folosi un apel cu cheia anon din terminal, pe o tabelă de test). Vezi cu ochii tăi datele expuse, apoi pornește RLS și repetă. De acum, „are RLS?” e prima ta întrebare la orice tabelă.

### T30 · Ma · 2h · Login cu Google · Login cu Google: OAuth explicat, configurat și parcurs până la capăt

Misiunea: Adaugă „Continuă cu Google” prin Supabase Auth, leagă progresul anonim de contul utilizatorului și parcurge fluxul până la capăt într-un browser real (nu doar până la pagina Google). Vizitatorii fără cont pot încerca în continuare o parte din platformă.

Promptul tău trebuie să acopere:
- cererea unei explicații, înainte de pași, a ce e OAuth și ce se întâmplă între aplicația ta, Google și Supabase când apeși butonul (fără ca aplicația să vadă vreodată parola)
- ghidajul în Google Cloud Console pentru clientul OAuth, cu adresele de întoarcere (redirect) corecte pentru localhost și pentru adresa de pe Vercel, și de ce o adresă lipsă dă eroarea „redirect_uri_mismatch”
- ce se întâmplă cu progresul anonim de până acum la primul login (se leagă de cont, nu se pierde)
- ce rămâne accesibil fără cont și ce cere login (decizia ta din PRD)
- criteriul de „gata”: un login complet, din Chrome, până la pagina de după, cu numele tău afișat, pe localhost ȘI pe adresa publică
- ce date despre om primești de la Google (nume, e-mail, poză) și pe care le ții, ca să le poți scrie în pagina de confidențialitate din săptămâna 4

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Adăugăm login cu Google prin Supabase Auth. Înainte de orice: explică-mi ce e OAuth, ca și cum ai explica unui prieten de ce butonul „Continuă cu Google” e mai sigur decât o parolă la mine, și desenează-mi (în text) drumul unei apăsări: aplicația mea → Google → Supabase → înapoi la mine.

Apoi, pas cu pas, cu „gata” de la mine:
1. clientul OAuth în Google Cloud Console; adresele de întoarcere pentru localhost și pentru adresa publică de pe Vercel; explică-mi ce înseamnă eroarea „redirect_uri_mismatch” ca s-o recunosc
2. configurarea în Supabase
3. în aplicație: butonul, starea „logat / nelogat”, și legarea progresului anonim de cont la primul login, fără pierdere
4. ce e accesibil fără cont (conform PRD): grilele de probă și teoria; restul cere login
5. spune-mi exact ce date primesc de la Google și care se salvează la mine; le notăm pentru pagina de confidențialitate

Gata înseamnă: fac login complet din Chrome, pe localhost și pe adresa publică, și îmi văd numele pe ecran. Nu „se încarcă pagina Google”.
```

De ce funcționează promptul: Login-ul e primul flux care iese din aplicația ta către un furnizor din afară, și prima lecție despre ce înseamnă „verificat”: nu când se deschide pagina Google, ci când te-ai întors logat. Setările OAuth se propagă cu întârziere și dau erori criptice; să știi dinainte ce înseamnă „redirect_uri_mismatch” îți economisește o după-amiază. Iar punctul 5 e GDPR-ul care începe discret: știi ce date ții din ziua în care începi să le ții.

Pune răspunsul la îndoială: Deschide o fereastră incognito și fă login cu alt cont Google (al unui prieten, cu el de față). Vede progresul tău? N-ar trebui. Dacă îl vede, RLS-ul de ieri are o gaură, și e cel mai bun moment să o găsești: azi, cu doi utilizatori, nu peste o lună, cu douăzeci.

### T31 · Ma · 2h · Clasament · Profiluri și clasament: calculat pe server, cu reguli despre cine vede ce

Misiunea: Fiecare utilizator are un profil (nume, poză, un rezumat al progresului) și există un clasament între utilizatori. Clasamentul se calculează pe server (în baza de date), nu în browser, și un utilizator nu poate vedea răspunsurile altuia, doar rezumatul public.

Promptul tău trebuie să acopere:
- ce intră în scorul clasamentului și de ce (decizia ta: întrebări corecte? simulări trecute? constanță zilnică?), cu avantajele și dezavantajele fiecărei variante cerute lui Claude înainte
- separarea clară între datele private (răspunsurile, greșelile) și rezumatul public (scor, poziție), în tabele și în RLS
- de ce calculul se face pe server și ce s-ar putea întâmpla dacă s-ar face în browser (un utilizator și-ar putea trimite orice scor)
- ce vede un vizitator nelogat din clasament, ce vede un utilizator logat, ce poate schimba la propriul profil (și opțiunea de a nu apărea în clasament)
- testul cu doi utilizatori reali (tu și cineva) și verificarea că fiecare își vede doar datele lui

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Construim profilurile și clasamentul. Înainte de orice, dă-mi 3 variante de scor pentru clasament (de exemplu: total răspunsuri corecte; simulări trecute; constanță, zile la rând) cu avantajele și dezavantajele fiecăreia pentru studenții din anul tău, și recomandă una. Eu aleg.

Apoi:
- tabela de profiluri cu rezumatul public (nume, poză de la Google, scorul, data ultimei activități) separată de datele private; RLS: rezumatul public îl citește orice utilizator logat, datele private doar proprietarul
- scorul se calculează pe server (o funcție sau un view în baza de date), nu în browser; explică-mi ce ar putea face un utilizator rău dacă scorul ar veni din browser
- utilizatorul poate alege să nu apară în clasament
- ecranul de clasament cu bgn-33: top 20, poziția mea evidențiată, și o stare goală frumoasă când sunt singur

Testăm cu două conturi reale: eu și un coleg, și verificăm că niciunul nu poate citi răspunsurile celuilalt.
```

De ce funcționează promptul: Clasamentul e funcția care aduce oamenii înapoi și, în același timp, prima funcție în care un utilizator ar putea trișa sau ar putea vedea ce nu trebuie. De aici cele două lecții: calculul pe server (browserul e teritoriul utilizatorului, nu al tău) și separarea public/privat în tabele, nu doar în interfață. Întrebarea „ce ar putea face un utilizator rău?” devine de azi parte din orice prompt pentru o funcție nouă.

Pune răspunsul la îndoială: Întreabă: „Cum aș putea eu, ca utilizator, să ajung pe locul 1 fără să învăț nimic?”. Dacă Claude găsește o cale, închide-o azi. Dacă spune că nu există, întreabă-l de ce e sigur (întrebarea nr. 8) și verifică singur un caz.

### T32 · Mi · 2h · API · Ce e un API: prima ta funcție pe server, care vorbește cu Claude

Misiunea: Construiește o funcție serverless pe Vercel (în folderul api/) care primește o cerere din aplicație, vorbește cu Claude prin API-ul lui și întoarce răspunsul. Cheia API stă doar în variabilele de mediu de pe Vercel. Tema funcției: generarea de grile din notițe: utilizatorul lipește un text sau încarcă un PDF, funcția de pe server îl trimite lui Claude cu instrucțiuni stricte de format și întoarce 10 întrebări propuse, marcate „neverificat” până le aprobă un om.

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
- fluxul exact: ce trimite pagina, ce face funcția, ce primește înapoi, în ce format (JSON) și cu ce erori posibile
- cheia API creată de tine în consola Anthropic, pusă în variabilele de mediu Vercel și într-un fișier .env local care e în .gitignore (verificat!)
- o limită de folosire pe utilizator (de exemplu 10 cereri pe zi) și motivul: cheia costă bani la fiecare apel
- testul: funcția apelată din terminal, apoi din aplicație, pe localhost și pe Vercel, cu mesajul de eroare pe înțelesul omului când ceva nu merge
- cât costă un apel, estimat, și cât ar costa 100 de utilizatori pe zi

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Azi construiesc prima mea funcție pe server și prima mea integrare cu un API: o funcție în api/ pe Vercel care vorbește cu Claude. Tema: generarea de grile din notițe: utilizatorul lipește un text sau încarcă un PDF, funcția de pe server îl trimite lui Claude cu instrucțiuni stricte de format și întoarce 10 întrebări propuse, marcate „neverificat” până le aprobă un om.

Înainte de cod, explică-mi: ce e un API, ce e o funcție serverless și DE CE cheia API a lui Claude nu are voie în pagina din browser (ce s-ar întâmpla concret). Apoi desenează-mi în text fluxul: pagina trimite X → funcția face Y → Claude întoarce Z → pagina arată W, cu formatul JSON al fiecărui pas și erorile posibile.

Apoi:
1. îmi spui unde îmi fac cheia (consola Anthropic) și o pun eu: în variabilele de mediu pe Vercel și într-un .env local; verifici cu mine că .env e în .gitignore ÎNAINTE de orice commit
2. funcția, cu instrucțiuni stricte pentru Claude (format de răspuns, lungime, limbă) și cu o limită de 10 cereri pe zi per utilizator logat; explică-mi de ce limita
3. testăm din terminal, apoi din aplicație, pe localhost și pe adresa publică; mesaje de eroare pe înțelesul omului
4. la final: cât costă un apel și cât ar costa 100 de utilizatori activi pe zi, cu calculul arătat
```

De ce funcționează promptul: „Ce e un API” e întrebarea cu care a început planul ăsta, și răspunsul adevărat e unul pe care l-ai construit: o funcție a ta, pe un server, care cere ceva altui program și întoarce răspunsul paginii tale. Cheia în variabile de mediu e a doua regulă de securitate pe de rost (prima e cea a cheilor Supabase). Iar costul calculat e lecția de business: un apel e ieftin, o mie pe zi nu.

Pune răspunsul la îndoială: Cere-i lui Claude să-ți arate ce ar vedea un utilizator curios dacă ar deschide DevTools → Network în timpul unei cereri. Vezi cheia pe undeva? N-ar trebui. Apoi întreabă: „Ce ar putea trimite cineva funcției mele ca să mă coste bani sau să obțină altceva decât am vrut?” și închide ce găsești.

### T33 · Mi · 2h · Conținut asistat · Grile din notițe: Claude propune, un om aprobă

Misiunea: Utilizatorul lipește un text (sau încarcă un PDF) din cursul lui, funcția de ieri îi cere lui Claude 10 grile în formatul platformei, iar întrebările apar marcate „neverificat” până le aprobă un om (tu sau un coleg cu rol de editor). Nimic neverificat nu ajunge în simulări.

Promptul tău trebuie să acopere:
- refolosirea funcției de ieri (nu încă una de la zero) și instrucțiuni stricte pentru Claude: formatul exact, lungimea, limba, și regula de a cita sursa primită, nu una inventată
- rolul de editor și starea „neverificat / verificat / respins” a unei întrebări, cu cine poate schimba starea (RLS)
- ce se întâmplă cu un text prea lung, cu un PDF scanat (imagine) sau cu un text care nu e din curs
- testul cu conținut real: un capitol din cursul tău, 10 grile propuse, câte ai aprobat și ce tip de greșeli a făcut
- ce arată interfața cât timp Claude răspunde (câteva secunde) și dacă răspunsul nu vine

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Extindem funcția de ieri pentru generarea de grile din notițe. Fluxul: utilizatorul lipește un text din curs (sau încarcă un PDF cu text), funcția îi cere lui Claude 10 grile în EXACT formatul întrebărilor din platforma mea, cu explicație și cu sursa „din textul primit, paragraful N”, și le salvează cu starea „neverificat”.

Reguli:
- întrebările neverificate nu apar niciodată în simulări sau în grilele publice; apar doar în ecranul de editor
- rolul de editor: eu și cine mai primește rolul; doar editorii schimbă starea (verificat / respins), prin RLS, nu doar prin interfață
- cazuri: text prea lung (spui limita și tai cu mesaj), PDF scanat fără text (mesaj clar: „nu pot citi imaginea”), text care nu pare din curs (Claude întreabă, nu inventează)
- cât timp răspunde Claude, interfața arată că lucrează; dacă nu vine răspuns în 30 de secunde, mesaj și posibilitatea de a reîncerca
- înainte de cod, planul; punct de salvare la final

Testăm cu un capitol adevărat din cursul meu: vreau să știu câte din cele 10 au fost bune din prima și ce tipuri de greșeli a făcut.
```

De ce funcționează promptul: Aici AI-ul intră în produsul tău, nu doar în procesul tău de construcție, și regula e aceeași ca la T17: Claude propune, omul verifică. Observă cum ai încorporat verificarea în date (starea „neverificat”, semnalul roșu la articol diferit), nu în bunăvoința cuiva. Și observă cazurile: textul prea lung, răspunsul care nu vine. Un produs e făcut în proporție de jumătate din ce se întâmplă când ceva nu merge.

Pune răspunsul la îndoială: Dă funcției un text care nu are nicio legătură cu materia (o rețetă de prăjitură, de exemplu). Ce face? Dacă produce grile despre prăjituri cu seriozitate, ai găsit o gaură: Claude face ce i se cere, nu ce e rezonabil, dacă nu-i spui tu.

### T34 · Jo · 1.5h · Tracker · Tracker v3: în cloud, publicat pe Vercel-ul tău, cu „Vederea lui Bogdan”

Misiunea: Trackerul tău de progres (din T06/T20) se mută în cloud: o tabelă separată în Supabase-ul tău, publicat ca pagină pe contul tău de Vercel, cu un mod de vizualizare doar-citire pentru Bogdan (de exemplu ?vedere=bogdan) care arată progresul și un grafic simplu. Îi trimiți linkul lui Bogdan și fratelui tău.

Promptul tău trebuie să acopere:
- refolosirea a tot ce știi din săptămâna asta (Supabase, RLS, deploy), aplicat pe un proiect mic și al tău: e examenul neanunțat
- o tabelă separată pentru tracker (nu amestecată cu datele platformei) și motivul
- modul de vizualizare pentru Bogdan: doar citire, fără login, cu progresul pe săptămâni și un grafic; ce poate și ce nu poate face cineva cu linkul
- de ce pagina publicată rămâne la zi cu bifele tale deși fișierul nu se schimbă (unde trăiesc datele)
- mesajul către Bogdan și fratele tău cu linkul, scris de tine

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Mut trackerul meu de progres (atașez versiunea curentă, v2) în cloud și îl public. Proiect separat, mic, pe care îl fac cu tot ce am învățat săptămâna asta:

- o tabelă nouă, „tracker”, în același proiect Supabase, separată de datele platformei; RLS: scriu doar eu (logat cu Google), citește oricine are linkul
- pagina publicată pe Vercel, din repo-ul ei; bifele mele se salvează în Supabase, nu în localStorage; importăm o dată progresul de până acum
- un mod de vizualizare „?vedere=bogdan”: fără login, doar citire, progresul pe săptămâni și un grafic simplu cu orele făcute pe zile
- înainte de cod, planul; înainte de publicare, test pe localhost; la final îmi explici de ce pagina publicată va arăta mereu bifele la zi deși fișierul publicat nu se mai schimbă

La sfârșit mă ajuți să scriu mesajul către Bogdan și fratele meu cu linkul, în cuvintele mele.
```

De ce funcționează promptul: E a treia versiune a primului lucru pe care l-ai construit, și e un test: poți face singur, într-o oră și jumătate, ce acum trei săptămâni era magie? Tabela separată e disciplină (datele unei aplicații nu se amestecă cu ale alteia), iar întrebarea finală („de ce rămâne la zi?”) e verificarea că ai înțeles diferența dintre pagină și date.

Pune răspunsul la îndoială: Deschide linkul cu vederea lui Bogdan pe telefonul unui prieten. Încearcă să bifezi ceva de acolo. Nu merge? Bine. Apoi întreabă-l pe Claude: „Cum ai putea, cu linkul ăsta și cheia anon din pagină, să-mi modifici progresul?”. Dacă există o cale, RLS-ul e incomplet.

### T35 · Jo · 2.5h · Audit · Primul audit SuperBoris: securitate și izolarea utilizatorilor

Misiunea: Chemi agentul de audit al lui Bogdan, SuperBoris, pe platforma ta, cu un brief scris de tine: ce verifică, ce înseamnă „bine”, ce nu atinge. Verdictul lui (aprobat / de reparat) și lista de probleme intră în repo; repari ce e grav azi, restul intră în plan.

Promptul tău trebuie să acopere:
- brief-ul de audit scris de tine înainte: scopul (securitatea datelor utilizatorilor și corectitudinea punctajului), limitele (nu designul azi), criteriile da/nu (un utilizator nu poate citi datele altuia; nicio cheie secretă în repo sau în browser; scorul nu poate fi falsificat din browser; funcția API are limită)
- cererea ca SuperBoris să NU repare nimic, doar să raporteze, cu dovada fiecărei probleme (fișier, rând, cum se reproduce)
- ordinea reparațiilor după gravitate, cu Claude Code (nu cu SuperBoris), și re-audit pe ce ai reparat
- salvarea raportului în repo (docs/audit/) cu data, și o listă „acceptat deocamdată” pentru ce nu repari azi, cu motivul

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
/superboris Vreau un audit al platformei mele, cu brief-ul de mai jos. Nu repara nimic: raportează, cu dovadă (fișier, rând, cum reproduc).

Scop: securitatea datelor utilizatorilor și corectitudinea punctajului.
Nu intră azi: designul, textele, performanța.
Criterii da/nu:
1. un utilizator logat nu poate citi sau modifica datele altuia (RLS pe fiecare tabelă, verificat efectiv, nu doar declarat)
2. nicio cheie secretă în repo, în istoricul git sau în fișierele servite browserului
3. scorul din clasament nu poate fi trimis sau modificat din browser
4. funcția API are limită per utilizator și nu poate fi apelată fără login
5. calculul punctajului la simulare (trecut/picat) e corect pe cazurile-limită (exact la prag, timp expirat, întrebare fără răspuns)

Livrează: verdict (aprobat / de reparat), problemele ordonate după gravitate, și ce ai verificat efectiv pentru fiecare criteriu. Raportul îl salvez în docs/audit/ cu data de azi.
```

De ce funcționează promptul: Un audit e o verificare făcută de cineva care n-a construit lucrul și care primește criterii, nu păreri. Brief-ul scris de tine e jumătate din valoare: „scorul nu poate fi falsificat din browser” e verificabil; „e sigur?” nu e. Observă și separarea rolurilor: SuperBoris raportează, Claude Code repară, SuperBoris re-verifică. Așa lucrează echipa lui Bogdan, și de azi așa lucrezi și tu.

Pune răspunsul la îndoială: Alege problema pe care SuperBoris a marcat-o cea mai gravă și întreabă-l pe Claude Code (nu pe SuperBoris): „Ești de acord că e gravă? Argumentează contra.” Doi agenți care nu sunt de acord sunt mai utili decât unul sigur pe el. Tu decizi, cu motivul notat în raport.

### T36 · Vi · 2.5h · Conținut · Conținut la scară: 100 de întrebări verificate la o singură materie (cea cu examen cel mai aproape), grupate pe capitole, plus 30 de carduri cu definițiile-cheie

Misiunea: Platforma are conținut cât să fie utilă cu adevărat: 100 de întrebări verificate la o singură materie (cea cu examen cel mai aproape), grupate pe capitole, plus 30 de carduri cu definițiile-cheie. Procesul e cel din T17, industrializat: Claude propune în loturi, tu verifici la sursă, marchezi verificat; nimic neverificat nu intră în simulări. Și clarifici, cu Claude, ce ai voie să folosești: notițele tale sunt ale tale; slide-urile profesorului sunt ale lui, deci în platformă intră întrebări formulate de tine din ele, nu slide-urile copiate. Întreabă-l pe Claude ce înseamnă „drept de autor” pentru materialele de curs în Spania și ce ai voie să refolosești.

Promptul tău trebuie să acopere:
- un proces pe loturi (de exemplu 15 întrebări o dată), cu un fișier de lucru în care Claude scrie propunerile și tu verdictele, ca să nu pierzi nimic între sesiuni
- distribuția pe capitole/categorii decisă de tine înainte (câte din fiecare și de ce; la examen real, proporțiile contează)
- lista greșelilor tipice ale lui Claude din T17, dată ca regulă de evitat în prompt
- întrebarea despre drepturi de autor pusă explicit, cu cererea de articol de lege și verificarea lui de către tine
- un script sau o comandă care îți spune oricând câte întrebări verificate ai pe capitol, rulat la final, cu numărul copiat în jurnal
- punct de salvare după fiecare lot verificat

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Facem conținut la scară pentru platformă: ținta de azi e 100 de întrebări verificate la o singură materie (cea cu examen cel mai aproape), grupate pe capitole, plus 30 de carduri cu definițiile-cheie. Sursa: cursurile, slide-urile și notițele tale (și ale colegilor care vor să contribuie).

Înainte: întreb despre drepturi. Notițele tale sunt ale tale; slide-urile profesorului sunt ale lui, deci în platformă intră întrebări formulate de tine din ele, nu slide-urile copiate. Întreabă-l pe Claude ce înseamnă „drept de autor” pentru materialele de curs în Spania și ce ai voie să refolosești. Spune-mi ce crezi, cu articolul de lege, și eu verific.

Procesul:
1. propun eu distribuția pe capitole (lipesc) și tu îmi spui dacă proporțiile se potrivesc cu examenul real
2. lucrăm în loturi de 15: tu scrii propunerile într-un fișier de lucru (continut/lot-N.json), eu scriu verdictul lângă fiecare (bun / greșit: motiv / ambiguu); doar „bun” trece în date/intrebari.json cu „verificat: true”
3. regulile de evitat, din greșelile tale de la T17: răspunsuri „toate de mai sus”, variante de lungimi diferite, întrebări cu două idei și ce mai adaug eu
4. 30 de carduri cu definițiile-cheie, același proces
5. la final: o comandă care îmi tipărește câte întrebări verificate am pe fiecare capitol și totalul; numărul ăsta îl copiez în jurnal

Punct de salvare după fiecare lot.
```

De ce funcționează promptul: Un produs de învățare fără conținut e o demonstrație. Azi devine util. Două discipline de observat: fișierul de lucru (ca o sesiune întreruptă să nu piardă nimic) și numărul tipărit de o comandă, nu ținut minte (regula lui Bogdan: o cifră într-un raport vine din ieșirea comenzii care a produs-o). Iar întrebarea despre drepturi, pusă înainte, e ce separă un produs de un necaz.

Pune răspunsul la îndoială: După ce ai terminat, dă 10 întrebări la întâmplare fratelui tău sau unui prieten și roagă-l să răspundă. La câte a avut nevoie de clarificări? Fiecare clarificare e o întrebare ambiguă care a trecut de tine. Verificarea ta are o rată de scăpare; află-o.

### T37 · Vi · 1.5h · Review · Review-ul de vineri, jurnalul săptămânii 3 și jurnalul de decizii

Misiunea: Review-ul cu Bogdan în formatul știut, cu demo pe adresa publică (login real, progres în cloud, clasament, funcția cu Claude), jurnalul săptămânii 3 și, în plus, deciziile din săptămâna asta trecute în jurnalul de decizii al PRD-ului, numerotate, cu motive. Plus linkul la tracker-ul în cloud, ca Bogdan să-l deschidă în review.

Promptul tău trebuie să acopere:
- formatul review-ului (rezumat, cel mai bun prompt, o greșeală a lui Claude și cum ai prins-o, 3 întrebări deschise, parcarea)
- demo-ul în 5 minute ca poveste, pornind de la login-ul real
- deciziile săptămânii (scorul clasamentului, ce e public/privat, limita API, ce rămâne „acceptat deocamdată” din audit) în jurnalul de decizii, cu data și motivul
- jurnalul scris împreună, în cuvintele tale

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Pregătește-mă pentru review-ul cu Bogdan ca în săptămânile trecute (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). Demo-ul de 5 minute pornește de la login cu Google pe adresa publică și arată progresul în cloud, clasamentul și funcția cu Claude; îi dau și linkul la tracker-ul meu.

Apoi trecem în jurnalul de decizii din PRD, numerotate în continuare, cu data și motivul: scorul clasamentului, ce e public și ce cere login, limita funcției API, și ce am lăsat „acceptat deocamdată” din auditul SuperBoris.

La final, jurnal/saptamana-3.md, împreună, cu cele 5 întrebări, și punct de salvare.
```

De ce funcționează promptul: A treia vineri, și produsul tău are utilizatori posibili: cont, date, inteligență. Jurnalul de decizii e ce îl va salva peste o lună, când nu mai ții minte de ce ai ales scorul X: motivul e scris lângă decizie, cu data. Observă că review-ul e mereu același format; ritualurile sunt plictisitoare și de asta funcționează.

Pune răspunsul la îndoială: Întreabă-l pe Bogdan, în review, care a fost cea mai bună decizie a ta din săptămâna asta și care e cea pe care ar lua-o altfel. Notează-le pe amândouă în jurnalul de decizii ca „părerea lui Bogdan”, nu ca decizie: produsul rămâne al tău.

## Săptămâna 4: Lansarea: utilizatori reali, calitate, predare (Nivel 3: scrii singur prompturile)

Pe telefon ca o aplicație. Stările goale și erorile, cu texte scrise de tine. Teste automate pentru ce nu are voie să se strice și regulile de producție în CLAUDE.md. Pagina de confidențialitate și ștergerea contului. Domeniul tău, cu login-ul mutat fără să se strice. Auditul final: PRD-ul față în față cu produsul. Joi, lansarea la 10 oameni și primul tău skill. Vineri: README cinstit, pagina ta de învățare, retrospectiva și demo-ul final, cu fratele tău.

Livrabile: PWA · teste automate cu „N din N trecute” · pagină de confidențialitate + ștergere cont · domeniu propriu cu HTTPS · raport de audit final · platforma lansată la 10 utilizatori · un skill · README + pagina de învățare · demo final

### T38 · Lu · 2h · Mobil · Pe telefon ca o aplicație: PWA, iconiță, viteză

Misiunea: Platforma se adaugă pe ecranul de start al telefonului ca o aplicație (PWA), se deschide repede și se folosește cu o mână. Testată pe telefonul tău și pe al unui prieten cu alt 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 bgn-33), ecranul de pornire
- o măsurătoare de viteză înainte și după (Lighthouse din DevTools) și ce ai schimbat ca să fie mai rapidă
- testul pe două telefoane diferite, cu ce a mers și ce nu pe fiecare
- ce se întâmplă fără internet: măcar un mesaj clar, ideal continuă simularea începută

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Vreau ca platforma să se poată pune pe ecranul de start al telefonului ca o aplicație. Î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 prietenilor 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 bgn-33), ecranul de pornire, și ce e nevoie ca Chrome și Safari să ofere „adaugă pe ecranul de start”
3. fără internet: cel puțin un mesaj clar; dacă se poate simplu, simularea începută continuă și se sincronizează la revenire (avem deja salvarea locală din T29)
4. măsurăm din nou și îmi explici ce a schimbat cifra
5. testez pe telefonul meu și pe al unui prieten cu celălalt sistem; notăm ce diferă

Înainte de cod, planul. Punct de salvare la final.
```

De ce funcționează promptul: Utilizatorii tăi învață în autobuz, nu la birou. „Ca o aplicație” înseamnă iconiță, viteză și comportament decent fără semnal; nimic din astea nu cere App Store. Măsurătoarea înainte/după e obiceiul de luat: „e mai rapid” e o părere, cifra din Lighthouse e un fapt.

Pune răspunsul la îndoială: Dă telefonul cu platforma instalată unui prieten și roagă-l să facă o simulare în timp ce merge pe stradă (în siguranță). Ce l-a enervat? Butoanele prea mici și textul prea mic se văd doar așa, nu la birou.

### T39 · Lu · 2h · Stări și texte · Jumătatea nevăzută a produsului: stările goale, erorile, textele

Misiunea: Fiecare ecran are o stare goală bună (ce vede un utilizator nou, fără niciun progres), fiecare eroare are un mesaj pe înțelesul omului cu un pas următor, și toate textele din interfață sună ca scrise de un om, în limba utilizatorilor tăi.

Promptul tău trebuie să acopere:
- inventarul complet al ecranelor și al stărilor fiecăruia (gol, încărcare, eroare, succes), cerut ca listă înainte de orice schimbare
- pentru fiecare stare goală: ce îi spui utilizatorului nou și ce îl inviți să facă (nu „nu există date”)
- pentru fiecare eroare posibilă (fără internet, login eșuat, Claude nu răspunde, limita zilnică atinsă): mesajul în cuvintele tale și pasul următor
- o trecere prin toate textele interfeței, cu tonul decis de tine (cum vorbești cu un coleg), și consecvența termenilor (același lucru se numește la fel peste tot)
- testul: cont nou, de la zero, parcurs cap-coadă

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Ne ocupăm de jumătatea nevăzută: stările goale, erorile și textele. Întâi fă inventarul: fiecare ecran, cu stările lui (gol / încărcare / eroare / succes) și textul care apare azi în fiecare. Nu schimba nimic până nu văd lista.

Apoi:
1. stările goale: pentru un utilizator nou, fiecare ecran spune ce e aici și ce să facă primul; niciun „nu există date”
2. erorile: fără internet, login eșuat, Claude nu răspunde, limita zilnică atinsă, sesiune expirată; pentru fiecare, mesajul îl scriu eu, în cuvintele mele, tu îl pui și adaugi pasul următor (buton de reîncercare, link)
3. toate textele interfeței într-un singur fișier, ca să le pot citi și corecta pe rând; tonul: cum vorbesc cu un coleg; aceiași termeni peste tot (verifică: „test” / „simulare” / „examen” nu se amestecă)
4. test: îmi fac un cont nou, cu alt e-mail, și parcurg totul de la zero; notăm fiecare moment în care n-aș ști ce să fac

Punct de salvare la final.
```

De ce funcționează promptul: Un utilizator nou vede doar stări goale: dacă ele sunt proaste, nu ajunge niciodată la funcțiile frumoase. Iar erorile sunt singurele momente în care produsul vorbește cu omul când omul e deja nervos; de asta mesajele le scrii tu, nu Claude. Fișierul unic de texte e un truc profesionist: îl poți da unui prieten care scrie bine, sau îl poți traduce.

Pune răspunsul la îndoială: Cere-i lui Claude: „Citește toate textele cu vocea unui utilizator obosit, la 11 noaptea, înainte de examen. Unde ar înjura?”. Repară acele locuri primele.

### T40 · Ma · 2h · Teste · Teste automate pentru ce nu are voie să se strice: punctajul, repetiția, pragul

Misiunea: Logica de care depinde încrederea în platformă (calculul scorului, trecut/picat la prag, algoritmul de repetiție spațiată, selecția întrebărilor pentru simulare) are teste automate care rulează cu o comandă (npm test) și tipăresc numărul de teste trecute. Niciun push fără ele verzi. CLAUDE.md primește regulile de producție: de azi ai utilizatori reali.

Promptul tău trebuie să acopere:
- explicația a ce e un test automat și de ce merită pentru exact aceste bucăți (ce s-ar întâmpla dacă pragul de trecere ar fi calculat greșit timp de o săptămână)
- lista cazurilor-limită decisă de tine înainte (exact la prag, cu o greșeală peste, timp expirat cu întrebări fără răspuns, card greșit de trei ori la rând)
- o singură comandă care rulează tot și tipărește pe ultimul rând „N din N trecute”
- testul că testele prind ceva: strici intenționat calculul și vezi că pică
- regulile de producție în CLAUDE.md: teste înainte de push, nimic nu se publică nevăzut, schimbările la tabele se anunță, ce faci dacă un utilizator raportează o problemă

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
De azi platforma are utilizatori reali în curând, deci punem plasa de siguranță. Întâi explică-mi ce e un test automat și de ce îl vreau fix pentru: calculul scorului, trecut/picat la prag, repetiția spațiată, selecția întrebărilor la simulare. Dă-mi un exemplu concret de ce s-ar întâmpla dacă pragul ar fi greșit o săptămână fără să știe nimeni.

Apoi:
1. cazurile-limită, lista mea (lipesc): exact la prag, o greșeală peste prag, timp expirat cu întrebări fără răspuns, card greșit de trei ori la rând, bancă de întrebări mai mică decât numărul cerut la simulare; tu completezi ce lipsește și explici de ce
2. testele, cu o singură comandă (npm test) care tipărește pe ultimul rând „N din N trecute”
3. dovada că prind ceva: strică intenționat calculul pragului, rulează, arată-mi că pică, apoi repară
4. CLAUDE.md: secțiunea „reguli de producție”: npm test înainte de orice push; nimic publicat nevăzut pe localhost; schimbările la tabele se anunță și se fac în ordinea corectă; ce facem când un utilizator raportează o problemă
5. punct de salvare

Când cineva îți zice „am testat”, de acum întreb „ce comandă și ce a tipărit?”.
```

De ce funcționează promptul: Testul automat e răspunsul la întrebarea nr. 7 din Rețetă („ce ai testat efectiv?”), transformată în comandă: nu mai depinzi de ce spune Claude, rulezi și citești. Pasul 3 e esențial și des sărit: un test care nu pică niciodată nu dovedește nimic. Și regulile de producție în CLAUDE.md sunt momentul în care proiectul tău își schimbă statutul: nu mai e exercițiu, e un lucru de care depind alți oameni.

Pune răspunsul la îndoială: Rulează testele pe telefon? Nu, dar întreabă: „Ce NU acoperă testele astea și ar putea strica experiența unui utilizator?”. Lista (interfața, login-ul, rețeaua) îți arată de ce există și testarea manuală, și de ce înainte de lansare parcurgi tu, cu mâna, drumul complet.

### T41 · Ma · 2h · Confidențialitate · Datele oamenilor: pagina de confidențialitate și ștergerea contului (GDPR)

Misiunea: Platforma ține date despre oameni (e-mail, nume, poză de la Google, istoricul răspunsurilor). Până la lansare: o pagină de confidențialitate scrisă pe înțelesul unui prieten (ce ții, de ce, cât timp, cine mai vede), un buton „șterge-mi contul” care chiar șterge tot, și un export al datelor proprii. Fără jargon juridic copiat de pe internet.

Promptul tău trebuie să acopere:
- inventarul exact al datelor personale pe care le ții (din tabelele tale, nu din memorie), cu scopul fiecăreia
- explicația a ce cere GDPR de la o aplicație mică ca a ta, în 10 rânduri, și ce NU cere (nu ai nevoie de un avocat pentru asta, dar ai nevoie de onestitate)
- pagina de confidențialitate în cuvintele tale, cu Claude ca secretar, inclusiv ce trimiți la Claude prin API (textul utilizatorului) și la Google (login)
- ștergerea contului: ce se șterge, din ce tabele, în ce ordine, și dovada (contul șters nu mai apare nicăieri, nici în clasament)
- exportul datelor proprii ca JSON (ai deja tot ce trebuie din T20)

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Înainte să lansez, mă ocup de datele oamenilor. Întâi: citește tabelele din Supabase și fă-mi inventarul exact al datelor personale pe care le țin (nu din memorie, din schema reală), cu scopul fiecăreia și cât timp e nevoie de ele. Apoi explică-mi în 10 rânduri ce cere GDPR de la o aplicație mică ca a mea și ce nu cere.

Apoi:
1. pagina de confidențialitate, scrisă împreună, în cuvintele mele, ca pentru un prieten: ce țin, de ce, cine mai vede (Supabase, Vercel, Google la login, Anthropic când folosești funcția cu Claude: ce anume ajunge acolo), cât timp, și cum îți ștergi contul; fără fraze copiate de pe internet
2. butonul „șterge-mi contul”: ce se șterge, din ce tabele, în ce ordine; testăm cu un cont de probă și verificăm că nu mai apare nicăieri, nici în clasament
3. „descarcă-mi datele”: JSON cu tot ce am despre utilizator
4. linkul spre pagina de confidențialitate la login și în subsol
5. punct de salvare

Dacă găsești date pe care le țin fără motiv, spune-mi: le scoatem.
```

De ce funcționează promptul: Nu e birocrație, e respect: oamenii îți dau e-mailul și istoricul greșelilor lor. Regula e simplă: știi ce ții, spui ce ții, și poți șterge tot la cerere. Observă primul pas: inventarul din schema reală, nu din memorie. După trei săptămâni de construit, nimeni nu mai ține minte exact ce coloane are. Iar „ce ajunge la Anthropic” e genul de propoziție pe care un produs cinstit o spune singur.

Pune răspunsul la îndoială: Dă pagina de confidențialitate mamei tale sau unui prieten care nu știe nimic despre programare și întreabă-l ce a înțeles că faci cu datele lui. Dacă răspunsul diferă de ce faci, pagina minte fără să vrea. Rescrie.

### T42 · Mi · 1.5h · Domeniu · Adresa ta: cumpără un domeniu, îndreaptă-l spre Vercel, mută login-ul fără să-l strici

Misiunea: Platforma are un domeniu al tău (cumpărat de tine, pe numele tău), cu HTTPS, servit de Vercel. Login-ul cu Google merge pe domeniul nou, iar adresa veche de pe Vercel rămâne funcțională ca rezervă până ai verificat un login complet pe cea nouă.

Promptul tău trebuie să acopere:
- compararea a 3 registrari cu prețul de reînnoire (nu doar primul an) și motivul alegerii
- ce e DNS, în cuvinte simple, și ce înregistrare adaugi ca domeniul să arate spre Vercel
- ordinea sigură: domeniul nou adăugat în Vercel și în clientul OAuth Google ÎNAINTE de a anunța pe cineva, adresa veche păstrată, și comutarea abia după un login complet reușit pe domeniul nou (setările Google se propagă cu întârziere)
- verificarea HTTPS și a redirecționării de la adresa veche la cea nouă
- actualizarea pretutindeni: PRD, README, pagina de confidențialitate, trackerul

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Cumpăr un domeniu pentru platformă. Întâi: compară 3 registrari pentru numele pe care îl vreau, cu prețul din primul an ȘI prețul de reînnoire, și recomandă unul cu motiv. Cumpăr eu, cu cardul meu, pe numele meu.

Apoi explică-mi ce e DNS în cuvinte simple și ce înregistrare pun ca domeniul să arate spre Vercel. Ordinea pe care o vreau, pentru că login-ul cu Google depinde de adresă:
1. adaug domeniul în Vercel și în clientul OAuth din Google (adresele de întoarcere pentru domeniul nou), fără să scot nimic din cele vechi
2. aștept HTTPS-ul, deschid domeniul nou și fac un login complet cu Google acolo; dacă dă „redirect_uri_mismatch”, așteptăm, nu schimbăm altceva
3. abia după un login reușit pe domeniul nou, adresa veche de pe Vercel redirecționează spre cea nouă
4. actualizăm adresa peste tot: PRD, README, pagina de confidențialitate, tracker

Spune-mi la fiecare pas ce verific cu ochii mei înainte de următorul.
```

De ce funcționează promptul: Lecția de azi e ordinea: când schimbi ceva ce se propagă cu întârziere (DNS, OAuth), lași calea veche funcțională și comuți abia după ce un drum complet a reușit pe cea nouă. E regula pe care echipa lui Bogdan a învățat-o pe pielea ei (login-ul de pe ccf.bgn.ro a fost dat înapoi odată exact din cauza asta). Și prețul de reînnoire e lecția de business de 5 minute: primul an e momeala.

Pune răspunsul la îndoială: Scrie adresa nouă pe telefon, fără „https://” și fără „www”. Merge? Și cu „www”? Și adresa veche te duce la cea nouă? Trei verificări de 10 secunde pe care utilizatorii le vor face toate, fără să știe că le fac.

### T43 · Mi · 2.5h · Audit final · Auditul final SuperBoris: PRD-ul față în față cu produsul

Misiunea: Al doilea audit, cu brief scris de tine: de data asta întrebarea e dacă produsul face ce spune PRD-ul v2 (fiecare decizie numerotată: făcută / parțial / lipsă), plus re-verificarea criteriilor de securitate din T35 și a reparațiilor de atunci. Verdictul și lista intră în repo; ce nu repari azi devine prima listă a lunii următoare, cu motiv.

Promptul tău trebuie să acopere:
- brief-ul: scopul (conformitate cu PRD v2 și re-verificarea securității), criteriile da/nu, ce nu intră
- cererea ca fiecare decizie din PRD să primească un verdict cu dovada (ecranul, fișierul) și ca nepotrivirile să fie listate în ambele sensuri (PRD zice și produsul nu face; produsul face și PRD nu zice)
- ordinea reparațiilor după efectul asupra utilizatorului, cu Claude Code, și re-audit pe ce ai reparat
- raportul în docs/audit/ cu data, și lista „luna următoare” cu motivul fiecărui lucru amânat

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
/superboris Auditul final înainte de lansare, cu brief-ul de mai jos. Nu repara nimic; raportează cu dovadă.

Scop: produsul face ce spune PRD v2? Și mai sunt valabile criteriile de securitate din auditul anterior (docs/audit/), inclusiv pe ce s-a reparat atunci?
Criterii:
1. fiecare decizie numerotată din PRD v2: făcută / parțial / lipsă, cu dovada (ecran, fișier)
2. nepotrivirile în ambele sensuri: PRD spune și produsul nu face; produsul face și PRD nu spune
3. cele 5 criterii de securitate din primul audit, re-verificate efectiv
4. testele automate: rulează npm test și copiază ultimul rând
5. drumul unui utilizator nou, cap-coadă, pe domeniul nou: login, o simulare, clasament, ștergere cont
Nu intră: performanța și textele (le-am făcut separat).

Livrează: verdict (aprobat / de reparat), lista ordonată după efectul asupra utilizatorului, și ce ai verificat efectiv la fiecare punct. Salvez raportul în docs/audit/ cu data.
```

De ce funcționează promptul: Primul audit a întrebat „e sigur?”; al doilea întreabă „e ce am promis?”. Nepotrivirile în ambele sensuri sunt partea prețioasă: vei descoperi că produsul face lucruri pe care nu le-ai scris nicăieri (decizii luate pe fugă) și promite lucruri pe care nu le face. Ambele se repară: una în cod, cealaltă în document. Iar lista „luna următoare” cu motive e ce te face să te oprești din construit și să lansezi.

Pune răspunsul la îndoială: Dintre problemele raportate, alege una pe care o consideri exagerată și una pe care SuperBoris a subestimat-o. Argumentează-le pe amândouă lui Bogdan vineri. Să nu fii de acord cu un audit, cu motive, e exact ce înseamnă să fii proprietarul produsului.

### T44 · Jo · 2h · Lansare · Lansarea: 10 colegi de an, înainte de o sesiune de examene

Misiunea: Platforma ajunge la primii utilizatori adevărați: 10 colegi de an, înainte de o sesiune de examene. Mesajul de invitație e scris de tine; există un loc unde îți pot spune ce nu merge; și ai o cifră, din baza de date, care îți spune peste 3 zile dacă au revenit.

Promptul tău trebuie să acopere:
- mesajul de invitație în cuvintele tale (ce e, de ce le-ar folosi, ce vrei de la ei, cât durează), verificat cu Claude doar pentru claritate
- canalul de feedback: cel mai simplu care funcționează (un grup, un formular, un buton „ceva nu merge” care trimite un e-mail), decizia ta
- cifrele de urmărit, citite din baza ta de date, nu dintr-un serviciu extern de analytics: câți au făcut login, câți au terminat o simulare, câți au revenit a doua zi; o comandă sau un ecran de administrare doar pentru tine
- ce faci în primele 48 de ore (verifici de două ori pe zi, răspunzi la fiecare mesaj, notezi tot, nu construiești funcții noi)
- planul pentru cazul în care ceva se strică cu utilizatori pe platformă (cum te întorci la versiunea de dinainte în 5 minute)

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Lansez la 10 colegi de an, înainte de o sesiune de examene. Ajută-mă fără să scrii în locul meu:

1. mesajul de invitație îl scriu eu (lipesc); tu îmi spui doar unde e neclar sau prea lung pentru cineva care îl citește pe telefon, între două lucruri
2. feedback: propune-mi 3 variante (grup de WhatsApp, formular, buton „ceva nu merge” în aplicație care trimite un e-mail) cu avantajele pentru 10 oameni; eu aleg
3. cifrele mele, din baza de date, fără servicii externe de analytics: câți au făcut login, câți au terminat o simulare, câți au revenit a doua zi; vreau un ecran de administrare simplu, doar pentru contul meu (RLS!), sau o comandă
4. regulile primelor 48 de ore: le scriu eu, tu le pui în CLAUDE.md; nicio funcție nouă până vineri
5. exercițiu înainte de a trimite mesajul: ne prefacem că versiunea publicată s-a stricat; arată-mi cum mă întorc la versiunea de dinainte pe Vercel în 5 minute, și facem asta o dată, pe bune

Trimit invitația abia după punctul 5.
```

De ce funcționează promptul: Lansarea nu e un buton, e o promisiune față de 10 oameni că le răspunzi. Observă ce ai cerut: cifrele din baza ta (nu Google Analytics, nu ai nevoie și ai avea de explicat în pagina de confidențialitate), un ecran doar pentru tine (cu RLS, reflex), și exercițiul de întoarcere la versiunea anterioară făcut ÎNAINTE să fie nevoie. Regula de a nu construi nimic nou 48 de ore e cea mai grea și cea mai importantă.

Pune răspunsul la îndoială: După 24 de ore, întreabă-l pe Claude: „Uite cifrele și mesajele primite (lipesc). Ce îmi spun ele și ce vreau eu să cred că îmi spun?”. Diferența dintre cele două răspunsuri e Mom Test aplicat pe propriul produs.

### T45 · Jo · 2h · Skill · Primul tău skill: un prompt care a absolvit

Misiunea: Un skill în Claude Code, „genereaza-grile”, care primește un text din curs și produce întrebări în exact formatul platformei tale, cu regulile de calitate învățate în T17 și T36 încorporate, testat pe trei texte diferite. Îl poți da unui coleg care are alt curs.

Promptul tău trebuie să acopere:
- ce e un skill și prin ce diferă de un prompt lipit (fișier, refolosibil, testabil, se dă mai departe), cerut înainte
- regulile de calitate pe care le-ai învățat, scrise de tine ca listă, intrate în skill
- testul pe mai multe intrări diferite, cu ce a produs și ce ai corectat în skill după fiecare
- instalarea skill-ului la fratele tău (sau un coleg) și o rulare la el, cu feedback

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Vreau să fac primul meu skill în Claude Code: „genereaza-grile”. Întâi explică-mi ce e un skill și prin ce diferă de promptul pe care îl lipesc de trei săptămâni (fișier, refolosibil, testabil, se poate da mai departe).

Skill-ul primește un text din curs și produce întrebări în EXACT formatul platformei mele (schema din T17), cu regulile mele de calitate (lipesc lista din T17 și T36) și cu sursa „paragraful N din textul primit”. Construim: folosește skill-creator dacă ajută.

Testăm pe trei texte diferite (un capitol tehnic, unul narativ, unul cu formule): după fiecare, îmi arăți ce a produs, eu spun ce nu-mi place, corectăm skill-ul, nu rezultatul. La final îl instalăm la Janos Jr, pe materia lui, și vedem dacă merge fără mine.
```

De ce funcționează promptul: Skill-ul e promptul tău care a absolvit: trei săptămâni de reguli învățate pe pielea ta, puse într-un fișier pe care îl poate rula oricine. Observă disciplina „corectăm skill-ul, nu rezultatul”: dacă repari rezultatul, mâine ai aceeași problemă. Iar instalarea la altcineva e testul adevărat: dacă merge fără tine, ai făcut o unealtă; dacă nu, ai făcut un prompt cu pretenții.

Pune răspunsul la îndoială: Întreabă: „Ce ar trebui să conțină skill-ul ăsta ca să-l poată folosi cineva peste un an, când eu nu mai țin minte nimic din săptămânile astea?”. Răspunsul e documentația; scrie-o acum, cât mai ții minte.

### T46 · Vi · 1.5h · README · README-ul cinstit și pagina ta de învățare (cele patru jurnale, publicate)

Misiunea: README-ul platformei spune cinstit ce e gata, ce e simplificat, ce ai face diferit și cum pornește un străin proiectul. Cele patru jurnale săptămânale devin o pagină publică de învățare pe domeniul tău (sau pe un subdomeniu), cu cele 20 de cuvinte pe care le poți explica acum, fiecare cu un exemplu din platforma ta: rețeta TA de întrebări.

Promptul tău trebuie să acopere:
- README cu secțiunile: ce e, pentru cine, cum pornești local, unde stau datele, ce e gata / simplificat / lipsă (din auditul final), ce aș face diferit
- pagina de învățare: cele patru jurnale, în cuvintele tale, și 20 de cuvinte explicate cu exemple din platforma ta, nu definiții generale
- rețeta ta personală: întrebările pe care le pui acum lui Claude, fiecare cu povestea momentului în care ai învățat-o
- publicarea pe un subdomeniu al domeniului tău (de exemplu invat.domeniul-tau), cu linkul trimis lui Bogdan

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Două documente, azi, amândouă în cuvintele mele, cu tine ca secretar:

1. README-ul platformei: ce e, pentru cine, cum pornește un străin proiectul local, unde stau datele, ce e gata / simplificat / lipsă (din auditul final din docs/audit/), ce aș face diferit dacă aș lua-o de la capăt. Fără laude; dacă ceva e făcut pe fugă, scriem că e făcut pe fugă.

2. pagina mea de învățare: cele patru jurnale (jurnal/), plus 20 de cuvinte pe care acum le pot explica, fiecare cu un exemplu DIN PLATFORMA MEA (nu definiții din dicționar), plus rețeta mea de întrebări: întrebările pe care le pun acum lui Claude, fiecare cu povestea momentului în care am învățat-o. Pagină simplă, HTML, bgn-33, publicată pe un subdomeniu al domeniului meu.

Pune-mi întrebările pe rând și lasă-mă să scriu eu; corectează doar ortografia. Punct de salvare la final, și linkul îl trimit lui Bogdan.
```

De ce funcționează promptul: README-ul cinstit e cadoul pentru tine-de-peste-un-an și pentru oricine preia proiectul: adevărul despre ce e solid și ce e cârpit valorează mai mult decât orice laudă. Pagina de învățare e examenul de absolvire: dacă poți explica 20 de cuvinte cu exemple din ce ai construit, nu le-ai memorat, le ai. Iar rețeta ta personală e versiunea ta a tab-ului „Rețeta întrebărilor”: a devenit a ta.

Pune răspunsul la îndoială: Dă pagina de învățare unui prieten care vrea și el să învețe Claude. Ce întrebare îți pune după ce o citește? Dacă răspunsul la întrebarea lui nu e în pagină, adaugă-l. Tocmai ai început să-i înveți pe alții; e singurul semn sigur că ai învățat.

### T47 · Vi · 1h · Retrospectivă · Retrospectiva: cine îl cunoștea mai bine pe Claude în ziua 1?

Misiunea: Compari lista „la ce sunt slab” pe care ți-a dat-o Claude în T01 cu lista ta, făcută din patru săptămâni, și scrii cele trei momente concrete în care l-ai prins greșind și ce ai făcut. Plus: ce ai face diferit în plan, pentru următorul care îl parcurge.

Promptul tău trebuie să acopere:
- cele două liste față în față, cu ce a nimerit Claude despre el însuși și ce a ratat
- trei momente concrete, cu data și sarcina, în care Claude a greșit și cum ai prins (sau n-ai prins) greșeala
- trei lucruri pe care le-ai schimba în planul ăsta, pentru următorul care îl face, trimise lui Bogdan
- ce faci singur în luna următoare: lista „luna următoare” din auditul final, ordonată de tine

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Retrospectiva celor patru săptămâni. Lipesc răspunsul pe care mi l-ai dat în ziua 1 la „la ce ești slab?”. Pune-l față în față cu lista mea (lipesc), făcută din experiență: ce ai nimerit despre tine și ce ai ratat. Fii cinstit, nu modest.

Apoi, din jurnale și din conversații, ajută-mă să scot cele trei momente concrete (data, sarcina) în care ai greșit și cum le-am prins; și unul în care NU le-am prins și am aflat mai târziu.

La final, două liste scurte: ce aș schimba în planul ăsta pentru următorul care îl parcurge (i le trimit lui Bogdan) și ce fac singur luna viitoare, din lista „luna următoare” a auditului final, în ordinea mea.
```

De ce funcționează promptul: Planul a început cu o întrebare pusă lui Claude despre el însuși și se termină cu răspunsul tău. Diferența dintre cele două liste e ce ai învățat cu adevărat: nu HTML sau Supabase, ci când să te încrezi și când să verifici. Iar lista pentru următorul care parcurge planul e felul în care îi dai înapoi lui Bogdan ce ți-a dat el.

Pune răspunsul la îndoială: Întreabă-l pe Claude: „Ce ai învățat tu despre mine în patru săptămâni? Cum îți vorbesc acum altfel decât în ziua 1?”. Răspunsul e portretul tău de supervizor. Dacă nu-ți place ceva din el, știi ce exersezi luna viitoare.

### T48 · Vi · 1.5h · Demo final · Demo-ul final: Bogdan, tatăl vostru și fratele tău, în aceeași cameră

Misiunea: O prezentare de 15 minute, pe domeniul tău, cu utilizatori reali deja înăuntru: povestea utilizatorului, produsul, cifrele din primele zile, ce ai învățat, ce urmează. Fratele tău face același lucru pentru platforma lui; la final, 10 minute în care vă întrebați unul pe altul ce ați face diferit.

Promptul tău trebuie să acopere:
- structura celor 15 minute ca poveste (utilizatorul, problema, produsul în mâna lui, cifrele, lecțiile, ce urmează), nu ca tur de butoane
- demo-ul cu un cont real și date reale (cu acordul persoanei) sau cu un cont de demonstrație pregătit
- trei întrebări pregătite pentru fratele tău despre deciziile lui diferite
- planul tău pentru luna următoare, în 5 rânduri, spus cu voce tare în fața lor

Promptul de referință (de comparat după ce l-ai scris pe al tău):

```
Pregătesc demo-ul final de 15 minute, pentru Bogdan, tata și Janos Jr. Ajută-mă să-l structurez ca poveste, nu ca tur al aplicației: utilizatorul meu (cine, ce problemă), produsul în mâna lui (un drum complet, pe telefon, pe domeniul meu), cifrele din primele zile de la lansare (din ecranul meu de administrare), trei lucruri pe care le-am învățat despre lucrul cu tine, și ce fac luna viitoare.

Apoi: repetăm. Eu prezint, tu ești publicul: Bogdan (întreabă de produs și de decizii), tata (întreabă de ce contează și dacă e sigur), Janos Jr (întreabă de ce am ales altfel decât el). Pune-mi întrebările lor cele mai grele și spune-mi unde răspunsul meu a fost vag.

La final, cele 3 întrebări pe care i le pun eu lui Janos Jr despre platforma lui.
```

De ce funcționează promptul: Demo-ul final e primul moment în care vorbești despre produsul tău ca proprietar, în fața oamenilor care contează. Repetiția cu Claude în rolul publicului e un truc pe care îl vei folosi toată viața: întrebările grele le afli înainte, nu în cameră. Și cele 10 minute cu fratele tău închid cercul: ați construit același tip de produs pentru lumi diferite, și fiecare știe acum ceva ce celălalt nu știe.

Pune răspunsul la îndoială: După demo, întreabă-i pe cei trei: „Ce ați crezut la început că n-o să reușesc?”. Răspunsurile sunt cel mai bun cadou de absolvire, și primul rând din jurnalul lunii următoare.

## 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 primul ecran cu grile.
- **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 PRD-ul platformei; poți întreba „ce vrea de la mine sarcina T17?”.
- **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 că simulare de examen cu regulile fiecărei materii e un ecran separat, cu timer.
- **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 învățare pentru facultate” 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 3 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 „genereaza-grile” transformă orice text într-un set de întrebări în formatul platformei tale.
- **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 care numără răspunsurile corecte la simulare 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: O întrebare din platforma ta arată așa: {"materie": "Microeconomie", "capitol": "Elasticitate", "tex…
- **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 răspuns dat de un utilizator la o grilă e un rând în tabela „raspunsuri”.
- **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: Progresul utilizatorilor și clasamentul 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 ta salvează progresul în Supabase, Supabase e backend-ul ei.
- **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: Platforma pentru facultate îi cere lui Claude, prin API-ul lui, 10 grile din textul primit și primește răspunsul ca JSON.
- **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 platforma 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 3 î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 3, 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ă timer la simulare” 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 platformei de la ziua 3 î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 platforma pe Vercel și o 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: Platforma ta ș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: david.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://platforma-ta.ro/simulare e un URL: domeniul platforma-ta.ro, pagina /simulare.
- **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, un utilizator își vede propriul progres și clasamentul, dar nu poate citi răspunsurile altuia.
- **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” de pe platforma ta 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 de grile cu bgn-33” și Claude folosește cardurile, butoanele și pilulele din catalog.
- **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: studenții din anul tău fac o simulare completă și revin a doua zi, 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: Un student care are examen la o materie și vrea să se verifice înainte angajează platforma ta ca să „știe sigur că trece”, deci concurența include și „nu mă pregătesc deloc”.
- **repetiție spațiată**: Metoda de memorat în care un card revine la intervale tot mai mari dacă l-ai știut și mai des dacă l-ai greșit. Pe scurt, SRS. E motivul pentru care Anki funcționează. Exemplu: Cardurile din platforma ta: știut = revine peste 3 zile, greșit = revine mâine.
- **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ă platforma 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 platformei, 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 prieten își face cont, platforma ta 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 platformei tale î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.