# Raluca și Maria învață Claude construind site-ul vacanței lor

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

## Cum citește Claude fișierul ăsta
Fișierul e versiunea text a planului de la raluca.bgn.ro. Când Raluca și Maria î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 ele; 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 lor.

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

Luni: conturile (GitHub primul, cu emailul către Bogdan), primul artifact în prima oră, rețeta promptului pe ceva construit de voi, și destinația: trei dorințe, o alegere, pagina de o foaie. Marți, saltul: Claude Code și agenții lui Bogdan pe calculatoarele voastre, turul echipei (ce face fiecare agent, trei probe), primul proiect cu reguli (CLAUDE.md) și puncte de salvare (git). Miercuri: Project-ul vostru (un Claude cu memorie) și trackerul v1, prima voastră aplicație cu memorie, cu inițiala celei care bifează. Joi și vineri, Bruce: la ce folosește site-ul înainte, în timpul și după, cum planifică alții, prima hartă a destinației, trei discuții cu oameni reali, PRD-ul cu decizii numerotate și prototipul pe telefon.

Livrabile: conturi Claude și GitHub · destinația aleasă · primul artifact · Project cu bază de cunoștințe · tracker v1 · Claude Code + pachetul BGN instalate · proiect cu CLAUDE.md și git · PRD v1 + prototip HTML · jurnalul săptămânii 1

### T01 · Lu · 1h · Pregătire · Înainte de orice: conturile (GitHub, Claude) și folderul proiectului

Întâi, fără Claude:
- Primul lucru, înainte de orice: contul GitHub, câte unul de fiecare. Pe github.com → Sign up. Alegeți un nume de utilizator pe care l-ați pune și pe un CV (prenume-nume sau ceva apropiat) și activați verificarea în doi pași (Settings → Password and authentication). GitHub e locul unde va sta site-ul vostru, de unde Bogdan vă dă acces la agenții lui și prin care veți lucra amândouă pe același proiect, de pe două laptopuri.
- Al doilea lucru: trimiteți-i lui Bogdan un email cu cele două nume de utilizator GitHub și cereți-i accesul la agenții lui. El vă invită în aceeași zi la pachetul cu agenți (BGN-ro/agenti-bgn); invitația vine pe email, de la GitHub, și o acceptați de acolo, fiecare. Fără ea, marți dimineață nu puteți începe, așa că emailul pleacă acum, nu diseară.
- Contul Claude: în Chrome, pe claude.ai, cont cu „Continue with Google”. Dacă lucrați de pe două laptopuri, fiecare are contul ei; dacă stați la aceeași masă, la același laptop, unul ajunge la început. Abonamentul: inițialele voastre, stânga-jos → Settings → Upgrade. Pro ajunge la început; săptămânile 2–4 folosesc mult Claude Code și dacă dați de limita de folosire, Max o rezolvă. Parolele le scrieți voi, niciodată Claude.
- Puneți două semne de carte în bara Chrome: claude.ai și raluca.bgn.ro (planul ăsta).
- Faceți un folder „vacanta” în Documents (numele de lucru al site-ului îl alegeți în T04). Tot ce descărcați pentru plan și tot ce construiți stă acolo. Descărcați de pe raluca.bgn.ro fișierul „planul ca text” (linkul e în Prezentare) și puneți-l în folder.

Promptul:

```
Salut. Suntem Raluca și Maria, mamă și fiică, și ăsta e primul mesaj pe care ți-l trimitem vreodată. Începem un plan de 4 săptămâni (stă la raluca.bgn.ro) în care învățăm să lucrăm cu tine construind ceva adevărat: site-ul vacanței voastre, într-o destinație pe care ne-o dorim de mult și pe care o alegem chiar săptămâna asta.

Trei întrebări ca să pornim:
1. Ce ești tu, exact, pe înțelesul nostru, și care e diferența dintre tine aici, în browser, aplicația de desktop și ceva numit Claude Code? Le vom folosi pe toate trei în următoarele patru săptămâni.
2. Ce ar trebui să știm despre cum să vorbim cu tine? Ai niște reguli de circulație?
3. Ce se întâmplă cu ce scriem aici: cine poate vedea, și o să-ți amintești mâine conversația asta?
```

De ce funcționează promptul: Observați: chiar primul vostru mesaj respectă deja rețeta: cine sunteți (context), ce faceți (scop), întrebări numerotate (formă). Scriați prompturi corect înainte să știți 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ți întrebarea care îl testează: „La ce ești slab? Cu ce n-ar trebui să ne încredem în tine?”. Salvați răspunsul într-o notă. În retrospectiva din săptămâna 4 (T48) îl comparați cu lista voastră, făcută din patru săptămâni de experiență reală, și vedeți cine îl cunoștea mai bine pe Claude în ziua 1.

### T02 · Lu · 0.5h · Prima victorie · Victorie rapidă: primul vostru artifact (30 de minute de magie)

Promptul:

```
Construiește-ne un artifact HTML foarte simplu (doar HTML + CSS, fără librării) care arată un singur card mare, ca o pagină dintr-un program de vacanță:
- sus, mic, cu majuscule rărite: „ZIUA 1 · SOSIRE”
- titlul „Vacanta” (nume de lucru) cu font mare, gras, și un gradient de la albastru-închis spre turcoaz
- trei rânduri de program, fiecare cu ora în stânga și textul în dreapta: „14:00 · Aterizare și drum spre cazare”, „17:00 · Prima plimbare, fără plan”, „19:30 · Cina (de rezervat)”
- un buton (doar de decor) pe care scrie „Vezi ziua întreagă”
- fundal deschis, design curat și modern, fontul Inter

Fără JavaScript. Doar HTML + CSS.
```

De ce funcționează promptul: Uitați-vă 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 dați scoate o ghicire pe care Claude ar fi făcut-o în locul vostru. Concretețea nu e pedanterie, e predictibilitate. Și nu vă speriați că promptul e plin de cuvinte pe care nu le știți încă (HTML, CSS, artifact): nu trebuie să le înțelegeți ca să le FOLOSIȚI azi. Apăsați pe orice cuvânt punctat pentru ideea într-un rând, parcați restul (vezi parcarea de cuvinte în Prezentare), și miercuri le întrebați cum trebuie. În planul ăsta întâi folosiți, înțelegeți peste câteva zile, la program.

Pune răspunsul la îndoială: Când apare cardul, întrebați: „Ce decizii ai luat pe care noi nu le-am specificat?”. Lista pe care o primiți (mărimi de font, spații, nuanțe) e o avanpremieră a ce ar fi acoperit un prompt cu adevărat complet. Apoi schimbați UN lucru („fă gradientul mai discret”) în loc să cereți de la zero. Iterarea bate repornirea.

### T03 · Lu · 1h · Prompting · Anatomia unui prompt: desfaceți rețeta în bucăți

Promptul:

```
Uite un prompt pe care l-am folosit mai devreme (lipim promptul de la cardul nostru, din T02). Fă trei lucruri:

1. Împarte-l în cele patru părți ale unui prompt complet: context, scop, formă, constrângeri. Arată-ne care propoziție e în care parte și ce lipsește.
2. Arată-ne ce ai fi construit dacă am fi scris doar: „fă-ne un card pentru site-ul vacanței”. Enumeră cele 10 decizii mari pe care ar fi trebuit să le ghicești.
3. Rescrie promptul nostru ca să fie complet, pentru cardul care va fi prima pagină a site-ul vacanței voastre: cineva care primește linkul pe WhatsApp trebuie să înțeleagă în 5 secunde unde mergem, când, și ce să apese.
```

De ce funcționează promptul: Asta e lecția de teorie a planului, comprimată într-o oră: vedeți rețeta aplicată pe ceva ce tocmai ați construit. Punctul 2 e cel mai important: lista deciziilor ghicite e exact ce înseamnă „prompt incomplet”. De acum, când un rezultat vă dezamăgește, nu spuneți „greșit”, vă întrebați care dintre cele patru părți lipsea. Rețeta întreagă e în tab-ul „Rețeta întrebărilor”, țineți-o deschisă.

Pune răspunsul la îndoială: Întrebați: „Ordonează cele patru părți ale promptului nostru după cât de mult a schimbat fiecare rezultatul.” Apoi hotărâți, fiecare separat, dacă sunteți de acord cu ordinea, și comparați. Să-l contraziceți pe Claude, cu voce tare și cu un motiv, e o abilitate pe care planul ăsta v-o va cere mereu.

### T04 · Lu · 1.5h · Discovery · Destinația și călătoria pe o foaie: unde, când, cu cine, și numele de lucru

Promptul:

```
Vrem să alegem destinația și să scriem „pagina de o foaie” a călătoriei noastre, înainte să construim orice. Produsul: site-ul vacanței voastre, pentru noi două și pentru cine vine cu noi. Modelul de la care pornim e site-ul pe care l-a făcut Bogdan, un prieten de-al nostru, pentru vacanța lui în Suedia (suedia26.bgn.ro): program pe zile, cu orele și locurile în ordine; mesele zilei cu link și bifă „rezervat”; lista cu ce trebuie rezervat din timp; topul experiențelor; zborurile; și un jurnal foto în care pozele se pun la locul lor în program.

Ajută-ne să scriem pagina, punându-ne întrebările pe rând (una, aștepți răspunsul, apoi următoarea), nu toate odată:
1. Trei destinații pe care ni le dorim de mult, fiecare cu motivul ei, în cuvintele noastre.
2. Când și cât: date fixe sau „cândva în mai”, și câte zile (7–12 e un interval bun pentru un site cu program pe zile).
3. Cine merge: doar noi două, sau și alții? Ce le place lor?
4. Ce fel de vacanță: ritmul (câte lucruri pe zi, la ce oră cina), ce ne atrage (muzee, natură, mâncare, plajă, orașe), bugetul pe zi și plafonul total.
5. Ce ne-a enervat la felul în care am planificat vacanțele până acum.

Apoi compară cele trei destinații pe criteriile noastre (sezonul în perioada aleasă, zborul din București, bugetul, ce ne place) și recomandă una, cu motiv. Spune la fiecare cifră (preț de zbor, temperatură, cât costă o zi) dacă e verificată sau ipoteză. Decizia e a noastră, nu a ta.

La final, scrie pagina de o foaie (maximum 300 de cuvinte) a călătoriei alese și propune-ne 5 nume de lucru pentru site, cu domeniile .ro sau .com probabil libere. Nu lua nicio decizie în locul nostru: unde nu știm, scrie „de hotărât”.
```

De ce funcționează promptul: „Pune-ne întrebările pe rând” e un tipar pe care îl veți folosi tot planul: transformă un chestionar sufocant într-o discuție. „Recomandă una, cu motiv, decizia e a noastră” e felul corect de a folosi Claude la o alegere care contează: el compară, voi hotărâți. Iar „verificat sau ipoteză la fiecare cifră” e întrebarea nr. 8 din Rețetă, pusă dinainte: prețurile de zbor și vremea sunt exact lucrurile pe care Claude le spune fluent și când nu e sigur. Documentul ăsta e materia primă pentru Bruce, joi.

Pune răspunsul la îndoială: Alegeți destinația acum, amândouă (aveți voie s-o schimbați până vineri, nu după), un nume de lucru, și salvați pagina în folder ca „calatoria-v0.md”. Apoi întrebați: „Ce întrebare ar fi trebuit să ne pui și nu ne-ai pus-o?”. Dacă răspunsul e bun, pagina voastră are o gaură: astupați-o acum.

### T05 · Ma · 1.5h · Pregătire · Instalați Claude Code și pachetul BGN (agenții lui Bogdan)

Întâi, fără Claude:
- Verificați e-mailul: fiecare trebuie să aibă o invitație de la GitHub pentru repo-ul BGN-ro/agenti-bgn (vine după emailul de luni cu numele voastre de utilizator). Acceptați invitația. Dacă n-a venit, scrieți-i lui Bogdan înainte să continuați; până răspunde, puteți face T08, Project-ul din claude.ai, care nu depinde de ea.
- Instalați aplicația Claude pentru Mac (claude.ai/download), pe fiecare laptop pe care veți lucra. Deschideți-o, intrați cu contul vostru și apăsați pe tab-ul „Code”: ăsta e Claude Code. Dacă vă cere să instaleze unelte în plus, lăsați-l; dacă vă cere parola Mac-ului, o scrieți voi.
- Bogdan v-a dat un fișier, „agenti-bgn-instalare-prieteni.md”. Puneți-l în folderul vostru. Porniți o sesiune nouă în tab-ul Code, în folderul vostru, și trageți fișierul în fereastră.
- În timpul instalării: când Claude vă dă un cod și se deschide o pagină GitHub, scrieți codul acolo și apăsați Authorize. Când Claude cere voie să ruleze o comandă, apăsați Allow. Când spune „GATA”, închideți complet aplicația Claude și o deschideți din nou. Dacă sunteți pe două laptopuri, instalarea se face pe amândouă.

Promptul:

```
Instalează după fișierul ăsta. Explică-ne simplu ce faci la fiecare pas, fără termeni tehnici, și cere-ne ceva doar când chiar nu se poate altfel. Înainte să rulezi prima comandă, spune-ne în trei rânduri ce o să se întâmple și ce vom avea la final.
```

De ce funcționează promptul: Azi faceți saltul de la „vorbim cu un AI în browser” la „avem un constructor pe calculatorul nostru”. 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. Observați promptul: chiar și la o instalare cereți planul înainte (întrebarea nr. 6) și explicații în cuvinte obișnuite (asta e în instrucțiunile voastre pentru totdeauna).

Pune răspunsul la îndoială: După repornire, scrieți într-o sesiune nouă: „Ce AI VOIE să faci pe calculatorul nostru fără să ne întrebi, și ce nu?”. Răspunsul ăsta e contractul vostru. Dacă ceva din el nu vă convine, aveți voie să-l schimbați în T07, în CLAUDE.md. Dacă pachetul s-a instalat (vezi turul din T06), tot restul zilei lucrați în Claude Code, nu în browser.

### T06 · Ma · 1h · Agenții · Turul agenților: cine e în echipa voastră, ce știe fiecare și când îl chemați

Întâi, fără Claude:
- Porniți o sesiune nouă în tab-ul Code, în folderul vostru. Prima întrebare, înainte de tur: „Ai primit regulile BGN la pornire și ai skill-urile bruce, supernicu și superboris?”. Dacă răspunsul e „nu” la oricare, reluați T05 înainte să mergeți mai departe.
- Țineți deschis tab-ul „Agenții” de aici: ce vă spune Claude trebuie să se potrivească cu ce scrie acolo. Unde nu se potrivește, notați și întrebați vineri.

Promptul:

```
Tocmai am instalat pachetul BGN al lui Bogdan și vrem să ne facem turul echipei înainte să avem nevoie de ea. Suntem Raluca și Maria, n-am scris cod niciodată, construim site-ul vacanței voastre.

1. Enumeră ce am primit prin pachet: agenți, skill-uri, reguli, design system. Pentru fiecare, un rând: ce e, în cuvinte obișnuite.
2. Pentru fiecare dintre Bruce, SuperNicu și SuperBoris: ce treabă duce de la cap la coadă, în ce moment al unui proiect îl chemăm, cum îl pornim (comanda exactă), ce ne va cere nouă și ce ne dă la final. Dă-ne câte un exemplu concret pe site-ul nostru de vacanță, nu pe un proiect generic.
3. Regulile BGN: alege trei care schimbă vizibil felul în care lucrezi cu noi de acum și spune-ne ce vom observa diferit.
4. Pe care dintre agenți NU ar trebui să-l folosim săptămâna asta și de ce.

Apoi trei probe, pe rând, cu „gata” de la noi între ele:
a) /bruce cu o cerere mică de tot: „merită să punem o hartă interactivă pe site-ul vacanței?”. Vrem să vedem cum cântărește mărimea cererii și dacă pornește procesul întreg pentru ceva mic.
b) Cheamă SuperNicu și întreabă-l doar atât: „ce ai avea nevoie de la noi ca să poți construi?”. Nu construi nimic.
c) Dă-i lui SuperBoris cardul nostru din T02 (lipim HTML-ul) și cere-i o verificare scurtă, doar ca să vedem ce fel de lucruri observă.
```

De ce funcționează promptul: Agenții sunt motivul pentru care primiți pachetul, și cel mai bun moment să aflați cine e în echipă e înainte să aveți nevoie de ea, nu în mijlocul unei probleme. Fiecare agent e un Claude cu un rol și o metodă; voi rămâneți cele care îi dau direcție. Cele trei probe sunt alese ca să vedeți caracterul fiecăruia: Bruce ar trebui să NU facă proces mare pentru o cerere mică, SuperNicu ar trebui să ceară un PRD și un prototip înainte să construiască, iar SuperBoris ar trebui să găsească ceva de zis chiar și la un card simplu. Dacă vreunul se poartă altfel, aveți prima observație pentru review-ul de vineri.

Pune răspunsul la îndoială: Întrebați fiecare agent: „Ce NU faci?”. Un agent care știe ce nu face e mai de încredere decât unul care promite tot. Notați cele trei răspunsuri în parcarea de cuvinte; vineri, după ce ați lucrat cu Bruce două zile, comparați ce a spus că nu face cu ce a făcut de fapt.

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

Promptul:

```
Pornim proiectul site-ul vacanței voastre în folderul ăsta. Vrem să înțelegem fiecare pas, deci: înainte de fiecare comandă, spune-ne într-un rând ce face și de ce, și așteaptă „ok”.

1. Când ne întrebi pentru cine e proiectul, răspunsul e: „altul” (e al nostru), prototip, design system bgn-33 pentru început (în săptămâna 2 ne facem stilul nostru, inspirat de destinație).
2. Scrie fișierul CLAUDE.md cu regulile noastre de lucru, în română. Trebuie să conțină: cine suntem (două persoane, Raluca și Maria, care lucrează pe același proiect, uneori de pe laptopuri diferite) și ce construim; explică termenii la prima apariție; arată-ne planul înainte de orice schimbare mare; nu șterge și nu rescrie fișiere întregi fără să ne întrebi; după fiecare pas care merge, propune un punct de salvare (commit); nimic din program nu intră fără un link verificat de una dintre noi; răspunde-ne în română.
3. Pornește git în folder și fă primul punct de salvare. Explică-ne ce e un commit folosind o comparație cu planificarea unei călătorii.
4. Pune în folder pagina de o foaie (calatoria-v0.md) și fă al doilea commit.
5. La final, arată-ne istoricul punctelor de salvare și spune-ne cum ne-am întoarce la primul dacă stricăm ceva.
```

De ce funcționează promptul: CLAUDE.md e cel mai important fișier din proiect: e prompt-ul permanent al constructorului vostru, scris de voi, în limba voastră. Tot ce vă displace la felul în care lucrează Claude se repară acolo, o dată. Observați regula despre linkul verificat: e regula de conținut a site-ului, pusă din prima zi, ca Claude s-o știe înainte să scrie primul rând de program. Iar git e motivul pentru care puteți îndrăzni: cu puncte de salvare, orice greșeală costă o comandă, nu o zi.

Pune răspunsul la îndoială: Stricați ceva intenționat: cereți-i lui Claude să șteargă o propoziție din calatoria-v0.md, apoi cereți-i să revină la punctul de salvare de dinainte. Verificați voi, cu ochii voștri, că propoziția s-a întors. Abia acum credeți în git, pentru că l-ați văzut, nu pentru că vi s-a spus.

### T08 · Mi · 1h · Pregătire · Project-ul vostru în claude.ai: un Claude cu memorie

Promptul:

```
Vrem să facem un Project în claude.ai dedicat site-ului vacanței. Ghidează-ne pas cu pas, așteptând „gata” de la noi după fiecare pas:

1. Cum creăm Project-ul în interfața claude.ai.
2. Ce documente urcăm în baza lui de cunoștințe. Avem două fișiere în folderul nostru: planul ăsta de învățare, descărcat de pe raluca.bgn.ro (plan-raluca.md) și pagina de o foaie a călătoriei (calatoria-v0.md).
3. Scrie-ne textul exact de instrucțiuni personalizate pe care să-l lipim. Trebuie să spună: suntem Raluca și Maria, mamă și fiică, n-am scris cod niciodată dar învățăm repede; construim site-ul vacanței voastre în [destinația aleasă]; definește orice termen tehnic la prima apariție; înainte de orice lucru mare, arată-ne planul; nicio întrebare de-a noastră nu e prea simplă; când greșim, spune-ne direct; la orice cifră despre călătorie (preț, orar, distanță) spune dacă e verificată sau ipoteză.
```

De ce funcționează promptul: Instrucțiunile personalizate sunt un prompt permanent: scrieți o dată cine sunteți și cum vreți răspunsurile, și fiecare conversație din Project pornește de acolo. Asta e diferența dintre „folosim Claude” și „avem Claude-ul nostru”. Observați și „așteaptă «gata» după fiecare pas”: îl transformă pe Claude dintr-un furtun într-un ghid răbdător. Dacă aveți conturi separate, Project-ul îl face una dintre voi și îl folosiți pe rând; în săptămâna 3 toate datele adevărate ale site-ului se mută oricum în cloud, unde le vedeți amândouă.

Pune răspunsul la îndoială: Testați: în noul Project, puneți o întrebare al cărei răspuns va conține termeni tehnici („cum ar ține site-ul minte ce am rezervat?”). A definit termenii fără să i-o cereți? A spus la vreo cifră „ipoteză”? Dacă nu, întrebați: „Ce parte din instrucțiunile noastre ar trebui întărită ca să faci asta mereu?”.

### T09 · Mi · 2h · Tracker · Tracker v1: construiți o aplicație cu memorie (localStorage)

Promptul:

```
Construiește-ne un artifact HTML de sine stătător (HTML + CSS + JS, fără librării externe): un tracker de progres pentru planul nostru de 4 săptămâni (atașăm lista sarcinilor, din plan-raluca.md).

FUNCȚIONALITATE:
- arată lista sarcinilor grupate pe săptămână și zi
- fiecare sarcină: o bifă, codul (T01…), numele și orele estimate
- la bifare alegem cine a făcut-o: R (Raluca), M (Maria) sau amândouă; inițiala apare lângă bifă
- starea se salvează în localStorage sub cheia „raluca_progres”
- când reîncărcăm pagina, bifele sunt tot acolo
- sus: „X din Y ore făcute săptămâna asta”, un procent general și câte sarcini a dus fiecare dintre noi

DESIGN:
- accent #1B7A8C, 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 deschidem în Chrome și merge.
```

De ce funcționează promptul: Promptul are secțiuni etichetate (FUNCȚIONALITATE și DESIGN) și Claude vă oglindește structura. Să scrieți prompturi pe blocuri e cel mai ieftin upgrade al rezultatelor voastre. Observați și ultimul rând: descrierea experienței finale („îl deschidem în Chrome și merge”) e și ea o constrângere. Și da, vă construiți propria unealtă de urmărit progresul: o folosiți zilnic patru săptămâni, și o veți muta în cloud în săptămâna 3, ca s-o vedeți amândouă de pe orice aparat, și Bogdan la fel.

Pune răspunsul la îndoială: Înainte să-l acceptați, întrebați: „Dacă deschidem fișierul ăsta pe celălalt laptop, sau pe telefon, bifele noastre 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 voastră lecție adevărată de sisteme. Pentru două persoane, limitarea asta e chiar deranjantă, și de asta o reparați în T35.

### T10 · Mi · 0.5h · Iterare · Schimbați fără să stricați: iterare pe tracker

Promptul:

```
Uite trackerul nostru care funcționează (atașăm versiunea curentă). Vrem O SINGURĂ schimbare:

Adaugă fiecărei sarcini un câmp mic de notițe, un loc unde putem scrie scurt („ne-a luat două sesiuni”, „întrebăm pe Bogdan”), salvat în localStorage împreună cu bifele.

Reguli:
- păstrează absolut tot ce merge acum: bifele, inițialele, procentul, designul
- nu rescrie fișierul de la zero; spune-ne exact ce ai schimbat și unde
- înainte de cod, spune-ne în două rânduri cum ai de gând să faci.
```

De ce funcționează promptul: „Păstrează tot ce merge” și „spune-ne ce ai schimbat” sunt cele două propoziții care vă apără de cel mai frecvent accident cu Claude: cereți o schimbare mică și primiți o rescriere care strică trei lucruri care mergeau. Iar „înainte de cod, planul” e întrebarea nr. 6 din Rețetă, pe care o veți pune la orice cerere mare, pentru totdeauna.

Pune răspunsul la îndoială: După ce primiți versiunea nouă, întrebați: „Ce ai schimbat ce NU ți-am cerut?”. Aproape întotdeauna există ceva: o culoare, un spațiu, un text. Hotărâți voi dacă schimbările nepoftite rămân. Voi sunteți supervizorii.

### T11 · Mi · 0.5h · Curaj · Întrebările curajoase: goliți parcarea de cuvinte (30 de minute)

Promptul:

```
Uite parcarea noastră de cuvinte, adunate din primele trei zile (lipim lista). Explică-ne fiecare cuvânt în două-trei rânduri, folosind ca exemplu ceva ce AM CONSTRUIT NOI săptămâna asta (cardul, proiectul din Claude Code, trackerul), nu exemple generale. După fiecare trei cuvinte, oprește-te și întreabă-ne dacă e clar; dacă spunem „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 folosiți câteva zile, apoi îl explicați cu un exemplu din ce ați 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ă: aveți voie să spuneți „tot nu e clar” de cinci ori.

Pune răspunsul la îndoială: Alegeți cuvântul care vi se pare cel mai bine explicat și spuneți-i lui Claude: „Acum explică-ni-l ca și cum am avea 10 ani.” Dacă explicația de 10 ani e mai clară decât prima, ceva din prima era umplutură. Învățați să cereți de la început versiunea de 10 ani. Și o întrebare între voi: care dintre voi a înțeles mai repede, și de ce?

### T12 · Jo · 2h · Bruce · Nevoia · Bruce, partea 1: nevoia (la ce folosește site-ul înainte, în timpul și după vacanță)

Promptul:

```
/bruce hai să definim site-ul vacanței voastre. Pornim de la pagina noastră de o foaie (calatoria-v0.md, în folder). Utilizatorii suntem noi două și cei care vin cu noi; modelul e site-ul lui Bogdan pentru Suedia (suedia26.bgn.ro): program pe zile, mese cu bifă de rezervare, lista de rezervat din timp, topul experiențelor, zboruri, jurnal foto.

Vrem să trecem azi doar prin partea de Nevoie: ce treabă face site-ul în fiecare din cele trei momente (înainte de plecare, când hotărâm împreună; în vacanță, pe telefon, când vrem să știm ce urmează, unde mâncăm și ce e rezervat; după, când vrem pozele la locul lor), cine îl folosește în fiecare moment, la ce trebuie să fie cel mai bun și ce NU facem. Propune tu la fiecare pas, noi confirmăm sau corectăm. Nu trece la research și la produs azi.

Două lucruri despre noi: n-am scris cod niciodată, deci explică termenii; și vrem să vedem motivul fiecărei propuneri, nu doar propunerea.
```

De ce funcționează promptul: Bruce e un Claude cu o metodă: nu vă lasă să săriți la ecrane înainte să știți pentru cine și pentru ce. Observați că îi dați VOI limitele: „doar Nevoia azi”, „propune tu, noi confirmăm”. Un agent bun primește direcție, nu doar o idee. Cele trei momente (înainte, în timpul, după) sunt felul în care un site de vacanță își arată adevărata treabă: în vacanță nu e „frumos”, e „se deschide repede pe telefon, în soare, și îmi spune unde e cina”.

Pune răspunsul la îndoială: Când Bruce propune la ce trebuie să fie site-ul cel mai bun, contraziceți-l o dată, cu un motiv din vacanțele voastre („noi nu facem așa, noi facem așa”). Vedeți dacă își schimbă propunerea cu un argument sau doar cedează. Dacă cedează instantaneu, întrebați: „Ai greșit sau doar ești de acord cu noi?” (semnul nr. 3 din „Semne că Claude ar putea greși”).

### T13 · Jo · 2h · Bruce · Research · Bruce, partea 2: cum planifică alții o vacanță, și prima hartă a destinației

Promptul:

```
/bruce continuăm cu research-ul pentru site-ul vacanței voastre. Nevoia confirmată ieri e în fișierul de lucru. Două jumătăți:

A. Cum rezolvă oamenii problema asta azi: Google Docs și notițe pe telefon, Wanderlog, TripIt, șabloanele de Notion, listele salvate în Google Maps, ghidurile tipărite, postările salvate pe Instagram, și felul în care am făcut-o noi până acum. Pentru fiecare: ce face bine, ce face prost, cât costă, ce am lua de acolo. La final: ce atribute contează pentru noi (ordonate), unde e golul și la ce ar trebui să fim cele mai bune.

B. Prima hartă a destinației noastre: cum e vremea în perioada aleasă, în ce zone se stă, 5–7 lucruri pe care nu le putem rata, cu orarul și prețul fiecăruia, și cum se ajunge de la aeroport. Spune la fiecare afirmație dacă e verificată (cu sursa, linkul) sau ipoteză.

Apoi pregătește-ne 5 întrebări pentru discuții față în față cu trei oameni care au fost acolo sau care călătoresc mult, după regulile Mom Test: despre viața lor, nu despre ideea noastră; 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 orare și prețuri fluent chiar când nu e sigur, și la o destinație străină nu aveți cum să simțiți greșeala) și Mom Test. Tema pentru vineri: puneți cele 5 întrebări la trei oameni reali, față în față sau pe telefon, și notați 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ți afirmația cea mai spectaculoasă din harta destinației (un preț, un orar, „e închis lunea”) și verificați-o voi la sursă, pe site-ul oficial al locului, 10 minute. Dacă era greșită, spuneți-i lui Bruce și cereți-i să corecteze harta. Tocmai ați făcut ce face un supervizor, și ați aflat de ce regula din CLAUDE.md cere link verificat.

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

Promptul:

```
/bruce trecem la Produs pentru site-ul vacanței voastre. Nevoia și research-ul sunt în fișierul de lucru; uite și ce am aflat de la cei trei oameni (lipim notițele, cuvânt cu cuvânt).

Vrem:
1. Deciziile de structură, în cuvinte, numerotate (D1, D2…), fiecare cu motivul: capitole (pe orașe sau zone) și zile; cum arată un rând din program (câmpurile lui: ora, locul, de ce merită, linkul oficial, orarul, cât se merge de la rândul dinainte, prețul, dacă trebuie rezervat); mesele zilei; lista de rezervat din timp; topul experiențelor; zborurile; jurnalul foto; ce e public pentru oricine are linkul și ce cere să fii una dintre noi; în ce limbă e site-ul.
2. Propune-ne o referință de layout (o pagină reală după care ne luăm; suedia26.bgn.ro e candidatul evident, dar spune-ne și alta) și așteaptă „ok”.
3. Apoi prototipul HTML, pe design system-ul bgn-33 deocamdată: ecranele principale, clickabile, pe lățime de telefon întâi, cu stările goale (o zi fără program încă) și de eroare. Fiecare ecran răspunde la „ce vede omul, ce poate apăsa, ce se întâmplă”.
4. La final: PRD-ul (scurt, în limbaj obișnuit, cu deciziile numerotate) și jurnalul de decizii, salvate în folder și cu punct de salvare.
```

De ce funcționează promptul: Azi aveți primul livrabil adevărat: un prototip pe care îl puteți arăta cuiva și un PRD pe care îl veți corecta în fiecare vineri. Observați ordinea pe care o impuneți: decizii în cuvinte → referință confirmată → abia apoi ecrane. E ordinea care evită cel mai scump accident: ecrane frumoase pentru un produs nedefinit. Și „pe lățime de telefon întâi” nu e un detaliu: site-ul ăsta se va folosi pe stradă, cu o mână, nu la birou.

Pune răspunsul la îndoială: Deschideți prototipul pe telefon și jucați, cu voce tare, ziua a treia a vacanței: „e 12:40, am ieșit de la muzeu, ne e foame… ce apăsăm?”. Fiecare moment în care ezitați e o problemă de produs, nu de design. Notați trei astfel de momente și cereți-i lui Bruce să le rezolve înainte de review.

### T15 · Vi · 1h · Review · Review-ul de vineri cu Bogdan (și 15 minute între voi două)

Promptul:

```
Pregătește-ne pentru review-ul de vineri cu Bogdan. Din conversațiile și fișierele săptămânii, scrie-ne:
1. Un rezumat de 5 rânduri a ce am construit (cardul, trackerul, proiectul, PRD-ul și prototipul) și destinația aleasă, cu motivul.
2. Cel mai bun prompt al nostru 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 avem nevoie de părerea lui Bogdan (nu de decizia lui: site-ul e al nostru).
5. Parcarea noastră de cuvinte, cu ce a rămas neclar.

Apoi, pentru cele 15 minute dintre noi două: dă-ne 3 întrebări pe care să ni le punem una alteia ca să aflăm ce ar fi hotărât fiecare diferit săptămâna asta ș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 vă face bune: 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 dintre voi sunt gratuite și valoroase: ați luat aceleași decizii din două vieți diferite, iar locurile unde ați fi ales altfel vă arată ce e gust personal și ce e produs.

Pune răspunsul la îndoială: În review, când Bogdan vă dă o părere despre site, nu o acceptați pe loc: întrebați „de ce?” și notați motivul lângă decizie în jurnal. O decizie fără motiv notat se va lua din nou peste două săptămâni, de la zero.

### T16 · Vi · 0.5h · Jurnal · Jurnalul săptămânii 1 (5 rânduri, în repo)

Promptul:

```
Creează în folder fișierul jurnal/saptamana-1.md și scrie-l ÎMPREUNĂ cu noi, nu în locul nostru: pune-ne pe rând cele 5 întrebări de mai jos, răspundem fiecare în cuvintele ei (două răspunsuri scurte la fiecare întrebare), 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 nostru ș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 voastre, pentru că asta e dovada că ați înțeles, nu că ați citit. Două răspunsuri la fiecare întrebare, pentru că sunteți două: peste patru săptămâni, diferențele dintre ele vor fi partea cea mai interesantă. „Scrie-l împreună cu noi, nu în locul nostru” e o instrucțiune pe care o veți da des: există lucruri la care vreți ca Claude să fie secretar, nu autor. În săptămâna 4, cele patru jurnale devin pagina voastră publică de învățare.

Pune răspunsul la îndoială: Recitiți răspunsurile la întrebarea 1. Dacă prietenul imaginar ar întreba „adică?”, rescrieți-le. Testul e simplu: fără niciun cuvânt punctat în ele.

## Săptămâna 2: De la prototip la site public, cu amândouă pe același cod (Nivel 2: completați spațiile)

Prototipul devine site: schelet, programul separat de cod (program.json), server local. Primele trei zile de program, scrise cu Claude și verificate de voi la sursă, link cu link. GitHub cu amândouă (pull, push, primul conflict provocat intenționat), apoi Vercel: marți seara site-ul e pe internet și îl deschideți de pe telefoane. Mesele și bifa „rezervat”, toate zilele cu „azi” evidențiată, zborurile, topul. Ziua de Debug: trei defecte plantate, voi le găsiți, fiecare pe laptopul ei. Stilul vostru, inspirat de destinație, scris ca reguli înainte de cod. Vineri: trei oameni folosesc site-ul pe telefon sub ochii voștri, PRD v2.

Livrabile: site-ul pe localhost și pe o adresă publică · trei zile de program verificate · repo pe GitHub cu două colaboratoare, deploy automat · mese, rezervări, toate zilele · stil.md aplicat · tracker v2 · PRD v2 · jurnalul săptămânii 2

### T17 · Lu · 2h · Schelet · De la prototip la proiect adevărat: scheletul site-ului și serverul local

Promptul: (completează spațiile)

```
Trecem de la prototipul HTML făcut cu Bruce la site-ul real, în folderul proiectului. Înainte de orice fișier, arată-ne planul și așteaptă „ok”.

Ce vrem:
- o structură simplă, pe care s-o putem explica unui prieten: o pagină principală (index.html), stilurile (stil.css), codul (app.js) și DATELE separate de cod, într-un folder date/: programul vacanței în JSON (program.json), zi cu zi, rând cu rând
- pornești un server local și ne spui adresa la care vedem site-ul în Chrome; explică-ne de ce nu deschidem fișierul direct
- prima zi care merge cap-coadă, citită din program.json: [ZIUA PE CARE O FACEȚI PRIMA, DE EXEMPLU ZIUA SOSIRII], cu 4–5 rânduri de program de probă
- fiecare ecran respectă prototipul; unde te abați, spune-ne 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 noi: [CE AȚI ÎNVĂȚAT SĂPTĂMÂNA TRECUTĂ DESPRE CUM VREȚI SĂ VĂ 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. Programul vacanței nu e „în site”, e într-un fișier pe care îl puteți deschide, citi și da altcuiva; când înțelegeți asta, înțelegeți cum sunt construite toate aplicațiile, și cum una dintre voi poate scrie programul în timp ce cealaltă schimbă culorile. A doua: serverul local, adresa localhost care există doar pentru voi. De acum, „merge la noi” și „merge pe internet” sunt două lucruri diferite, și veți învăța să le verificați pe amândouă.

Pune răspunsul la îndoială: Deschideți date/program.json singure, în editor, și schimbați de mână ora unui rând. Reîncărcați pagina. S-a schimbat? Tocmai ați editat un site fără să scrieți cod. Apoi întrebați-l pe Claude: „Ce s-ar strica dacă am greși o virgulă în fișierul ăla?” și puneți-l să vă arate eroarea în consolă.

### T18 · Lu · 2h · Conținut · Primele trei zile de program: forma unui rând și regula linkului verificat

Promptul: (completează spațiile)

```
Hotărâm cum arată un rând din program și scriem primele trei zile.

1. Propune forma unui rând (câmpurile și ce înseamnă fiecare): ora, locul, de ce merită (un rând), linkul oficial, orarul, cât se merge de la rândul dinainte și cu ce, prețul, dacă trebuie rezervat, și „verificat: da/nu”. Explică-ne de ce fiecare câmp merită să existe și ce se întâmplă dacă lipsește.
2. Apoi scriem zilele [NUMERELE ZILELOR, DE EXEMPLU 1–3] în [ORAȘUL SAU ZONA DE ÎNCEPUT], după ritmul nostru: [CÂTE LUCRURI PE ZI, LA CE ORĂ MICUL DEJUN, PRÂNZUL ȘI CINA, CÂT MERS PE JOS E OK]. Propui câte o zi odată, în JSON, fiecare rând cu link și orar, și cu „verificat: nu”.
3. Noi deschidem fiecare link, ne uităm la orar și preț pe site-ul oficial și îți spunem „bun”, „greșit: …” sau „închis atunci: …”. Doar rândurile cu „bun” primesc „verificat: da” și rămân în program.json.
4. La final, un rezumat: câte rânduri propuse, câte bune din prima, ce tip de greșeli ai făcut (orare vechi? locuri închise? distanțe subestimate?).

Reguli pentru program: [CE V-A ENERVAT LA VACANȚELE TRECUTE: PREA MULTE ÎNTR-O ZI? COZI? TRAVERSĂRI INUTILE ALE ORAȘULUI? SCRIEȚI-LE CA REGULI].
```

De ce funcționează promptul: Aici învățați cel mai important lucru despre conținut făcut cu AI: Claude propune, omul verifică la sursă, și doar ce e verificat ajunge pe site. La o destinație străină, Claude știe foarte multe și unele sunt de acum trei ani: muzeul s-a mutat, restaurantul s-a închis, orarul de vară nu e cel de iarnă. Linkul deschis de voi e singura apărare. Punctul 4 e oglinda: după trei zile de program știți exact ce tip de greșeală face Claude pe destinația voastră, și o puteți preveni în prompturile următoare.

Pune răspunsul la îndoială: Alegeți rândul cel mai tentant din cele trei zile și întrebați: „Ce ar spune cineva care locuiește acolo despre rândul ăsta?”. De multe ori primiți „e plin de turiști la ora aia” sau „e la 40 de minute de mers, nu la 15”. Dacă găsește ceva ce voi n-ați văzut, standardul vostru de „bun” era prea jos. Ridicați-l și reverificați restul.

### T19 · Ma · 1.5h · GitHub · Site-ul în cloud și lucrul în două: repo privat pe GitHub, cu amândouă

Promptul: (completează spațiile)

```
Vrem să punem proiectul pe GitHub, ca repo privat, din trei motive: copie de siguranță, Vercel să-l poată publica de acolo, și să putem lucra amândouă pe el, fiecare de pe laptopul ei. Explică-ne î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 noi după fiecare:
1. verifici că există .gitignore și că exclude [CE CREDEȚI VOI CĂ NU TREBUIE URCAT; DACĂ NU ȘTIȚI, SCRIEȚI „NU ȘTIM, PROPUNE TU ȘI EXPLICĂ”]
2. creezi repo-ul privat pe contul lui [CARE DINTRE VOI E PROPRIETARA REPO-ULUI] din terminal (gh) și faci primul push
3. o inviți pe [CEALALTĂ] ca colaboratoare; ea acceptă invitația, clonează repo-ul pe laptopul ei și deschide același proiect în Claude Code
4. ne arăți regula de aur a lucrului în două: înainte să începi, iei ultima versiune (pull); când termini un pas, îl trimiți (push); și ce se întâmplă dacă amândouă schimbăm același rând (un conflict), pe un exemplu mic, provocat intenționat
5. scrii în README.md ce e proiectul, în 5 rânduri, pentru un om care îl deschide prima oară
```

De ce funcționează promptul: Până azi, proiectul exista într-un singur loc. De azi există în trei: două laptopuri și GitHub, iar GitHub e cel care ține adevărul. Asta e lecția pe care băieții din planul-frate n-o au: cum lucrează doi oameni pe același cod fără să-și strice munca unul altuia. Răspunsul e disciplina pull–lucrezi–push, și un conflict văzut o dată, pe ceva mic, ca să nu vă sperie când apare pe ceva mare. Întrebarea despre chei și parole e esențială acum, cât n-aveți niciuna: în săptămâna 3 veți avea.

Pune răspunsul la îndoială: Ștergeți un fișier mic de pe un laptop (de exemplu README.md), apoi cereți-i lui Claude să-l aducă înapoi de pe GitHub. Verificați că e identic. Apoi testul în două: una schimbă ora cinei din ziua 2, face push; cealaltă face pull și vede schimbarea fără să fi atins nimic. Abia acum „lucrăm împreună” e un lucru pe care l-ați văzut funcționând.

### T20 · Ma · 1.5h · Vercel · Publicare: site-ul vacanței pe internet, cu Vercel (și de pe telefon)

Promptul: (completează spațiile)

```
Vrem să publicăm site-ul pe internet cu Vercel, direct din repo-ul de GitHub, ca fiecare push pe ramura principală să publice singur versiunea nouă. Ghidează-ne pas cu pas, cu „gata” de la noi, și explică-ne scopul fiecărui pas într-un rând înainte să-l facem:

1. cont Vercel (intrăm cu GitHub, pe contul proprietarei repo-ului), import repo, primul deploy; ne 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: deschidem adresa de pe telefoanele noastre și facem [UN TEST CONCRET PE CARE ÎL ALEGEȚI VOI: DE EXEMPLU CITIM ZIUA 2 PE STRADĂ, ÎN SOARE]; apoi schimbăm un text, push, și vedem în cât timp apare schimbarea
4. ne explici diferența dintre adresa de pe Vercel și un domeniu al nostru (îl alegem î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 aveți un site pe internet. Lanțul pe care l-ați 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 adăugați teste automate ca a doua verificare.

Pune răspunsul la îndoială: Trimiteți adresa unui prieten care nu știe nimic despre proiect și rugați-l să vă spună în două rânduri unde crede că mergeți și ce ar apăsa. Dacă răspunsul lui nu seamănă cu PRD-ul vostru, ați găsit prima problemă reală a site-ului, la 48 de ore după ce ați început să-l construiți. Asta e viteza care contează.

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

Promptul: (completează spațiile)

```
Îmbunătățim trackerul (atașăm versiunea curentă). De data asta scriem noi specificația:

- fiecare sarcină are o stare: [CELE 3 STĂRI PE CARE LE VREȚI, DE EXEMPLU NEÎNCEPUTĂ / ÎN LUCRU / FĂCUTĂ] și momentul când am bifat-o, pe lângă cine a făcut-o
- un buton „Exportă” care copiază tot progresul ca JSON în clipboard și un buton „Importă” care îl primește înapoi (așa ne trecem bifele de pe un laptop pe celălalt, până la cloud)
- [O FUNCȚIE PE CARE O VREȚI VOI, DIN FOLOSIREA DE O SĂPTĂMÂNĂ: CE V-A LIPSIT?]
- păstrezi tot ce merge; spui ce ai schimbat

Înainte de cod: explică-ne ce e JSON folosind ca manual chiar exportul trackerului nostru, și apoi program.json al site-ului.
```

De ce funcționează promptul: JSON e formatul în care trăiesc datele pe internet: programul vacanței, progresul vostru, răspunsurile de la API-uri. Îl învățaț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ți exportul într-un editor și schimbați de mână o stare, apoi importați-l. A mers? Acum stricați intenționat o virgulă și importați din nou. Ce vă spune aplicația? Dacă nu spune nimic util, cereți-i lui Claude un mesaj de eroare pe înțelesul omului. Tocmai ați proiectat o stare de eroare.

### T22 · Mi · 2h · Mese și rezervări · Mesele zilei și bifa „rezervat” (și de ce bifa nu se vede pe celălalt telefon)

Promptul: (completează spațiile)

```
Construim mesele zilei și rezervările, ca pe suedia26.bgn.ro. Înainte de cod, arată-ne planul și așteaptă „ok”.

- fiecare zi are rânduri de masă intercalate la ora lor în program: [ORELE VOASTRE: DE EXEMPLU CAFEA ȘI MIC DEJUN 9:00, PRÂNZ 13:00, CINA 19:30], fiecare cu numele localului, un rând despre el, linkul, o poză mică și fundal colorat după tipul mesei
- fiecare rând care are „de rezervat” (mese, bilete, tren) are o bifă „Rezervat”; starea bifei se ține deocamdată în localStorage, cu data la care am bifat
- o secțiune „De rezervat din timp” se generează singură din toate rândurile cu „de rezervat”, ordonate după [CUM VREȚI SĂ FIE ORDONATE: CÂT DE GREU SE PRINDE LOC? DATA?], cu bifele aceleași ca în program
- localurile le propui tu, câte trei variante per masă, cu motivul și linkul, și noi alegem: [CE FEL DE LOCALURI VREȚI: FĂRĂ MENIU FIX? CU TERASĂ? BUGETUL PE MASĂ?]; nimic nu intră fără link verificat de noi, ca la T18
- design pe telefon întâi; punct de salvare după fiecare pas care merge

La final, răspunde-ne cinstit: dacă Raluca bifează „rezervat” pe telefonul ei, vede Maria bifa pe al ei? De ce nu, și când reparăm asta?
```

De ce funcționează promptul: „Propui trei variante, noi alegem” e felul corect de a folosi Claude la gust: el caută, voi hotărâți, și linkul se verifică oricum. Iar ultima întrebare e lecția zilei: ați construit o funcție care pentru o singură persoană e perfectă și pentru două e aproape inutilă, pentru că localStorage trăiește într-un singur telefon. Săptămâna viitoare, exact bifa asta devine motivul pentru care învățați ce e o bază de date în cloud. O limitare simțită pe pielea voastră se înțelege altfel decât una citită.

Pune răspunsul la îndoială: Întrebați: „Ce ar spune cineva care a folosit site-ul lui Bogdan în Suedia două săptămâni despre varianta noastră?”. Veți primi o listă de lucruri care lipsesc (orarul bucătăriei, telefonul localului, „rezervarea e pe numele cui”). Nu le construiți pe toate: alegeți unul, cu un motiv, și notați restul în PRD la „mai târziu”. A spune nu cu motiv e o decizie de produs.

### T23 · Mi · 2h · Toate zilele · Toate zilele, cronologic: teme, „azi”, zilele trecute, zborurile și topul

Promptul: (completează spațiile)

```
Construim restul site-ului în jurul programului. Înainte de cod, arată-ne planul și lista stărilor prin care trece o zi (fără program încă, viitoare, azi, trecută) și așteaptă „ok”.

Apoi:
- toate zilele vacanței, grupate pe capitole [ORAȘELE SAU ZONELE, ÎN ORDINE], fiecare zi cu o temă de un rând: [TEMA FIECĂREI ZILE, DE EXEMPLU „SOSIRE ȘI CARTIERUL VECHI”]; zilele pe care nu le-am scris încă apar cu starea „fără program încă”, nu dispar
- „azi” se evidențiază singură după data telefonului, iar zilele trecute se strâng, cu un buton de desfăcut
- o secțiune „Zboruri” (sau tren) cu orele, aeroporturile și ce trebuie să știm la fiecare capăt, și o secțiune „Topul experiențelor”: [CELE 5–7 LUCRURI PENTRU CARE MERGEM, ÎN ORDINEA VOASTRĂ]
- un comutator „Cu poze / Compact”, ținut minte în browser, pentru când suntem pe stradă și vrem doar orele
- fiecare secțiune respectă prototipul; unde te abați, spui de ce

Testăm împreună, pe telefon, o zi de la cafea până la cină, înainte de punctul de salvare.
```

De ce funcționează promptul: Lista stărilor e cea mai subestimată unealtă de produs: majoritatea bug-urilor și a ecranelor urâte vin din stări la care nimeni nu s-a gândit (ce arată site-ul în a opta zi, când primele șapte au trecut? ce arată luni, când ziua de marți e goală?). Le enumerați înainte, și Claude le construiește pe toate. Iar „testăm o zi întreagă pe telefon înainte de commit” e regula pe care o veți păstra: funcția e gata când a fost parcursă, nu când a fost scrisă.

Pune răspunsul la îndoială: Schimbați data telefonului la o zi din mijlocul vacanței și deschideți site-ul. Ce vedeți prima dată? Dacă nu e ziua de azi, cu ora următoare, aveți o problemă de produs. Apoi puneți data după vacanță. Ce ar trebui să arate site-ul atunci? Hotărâți voi, și notați decizia în jurnal.

### T24 · Jo · 2h · Ziua de Debug · Ziua de Debug: Claude vă va bate (trei defecte plantate, voi le găsiți)

Promptul: (completează spațiile)

```
Azi învățăm să reparăm. Fă o ramură nouă în git, numită „debug-day”, și plantează în site TREI defecte de tipuri diferite, fără să ne spui care: unul care dă eroare în consolă, unul care face ceva să nu se vadă (de exemplu o masă dispare dintr-o zi), unul care face un calcul greșit (de exemplu minutele de mers sau totalul de rezervat). Apoi fă commit pe ramura aia și spune-ne doar: „gata, găsiți-le”.

Le căutăm singure, cu DevTools deschis, fiecare pe laptopul ei, fără să ne spunem una alteia ce am găsit până la final. Când ne blocăm, îți dăm ce vedem (mesajul exact din consolă, captura de ecran, ce am apăsat) și tu ne pui întrebări, nu ne dai soluția, până o găsim noi.

La final: ștergem ramura și ne 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-AȚI ÎNVĂȚAT AZI, ÎN CUVINTELE VOASTRE].
```

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 puteți face prostii fără să atingeți versiunea care merge. Întrebarea nr. 9 din Rețetă („explică ce era greșit înainte să repari”) se naște azi. Și căutați separat intenționat: două perechi de ochi găsesc defecte diferite, iar comparația de la final e o lecție despre cum vede fiecare dintre voi.

Pune răspunsul la îndoială: După ce le-ați găsit pe toate trei, întrebați: „Care defect ar fi fost cel mai greu de observat în vacanță și de ce?”. Răspunsul e, de obicei, calculul greșit: site-ul arată bine și minte, și voi ajungeți la restaurant cu 25 de minute întârziere. Asta e motivul pentru care în săptămâna 4 scrieți teste automate pentru program.

### T25 · Jo · 2h · Design · Stilul vostru: un mic design system inspirat de destinație, scris ca reguli

Promptul: (completează spațiile)

```
Până acum site-ul e pe bgn-33, design system-ul lui Bogdan. Azi ne facem stilul nostru, ca pe suedia26.bgn.ro, care are un stil scos din fotografiile și galeriile de artă ale cuiva. Nu schimba nimic în cod înainte să ne arăți regulile.

1. Uite trei referințe vizuale: [TREI LINKURI SAU POZE: UN LOC DIN DESTINAȚIE, UN SITE CARE NE PLACE, O POZĂ CU CULORILE PE CARE LE VREM]. Scoate din ele o paletă de 5–6 culori (cu numele lor și la ce le folosim), două fonturi (titluri și text), colțurile, umbrele, spațiile, și cum arată un rând de program, un rând de masă, un card de zi. Scrie totul într-un fișier stil.md, în cuvinte obișnuite, cu motivul fiecărei alegeri.
2. Verifică contrastul fiecărei perechi text/fundal pentru citit în soare, pe stradă, și spune-ne care pică.
3. Așteaptă „ok” pe reguli. Abia apoi aplică-le în stil.css, ecran cu ecran, și arată-ne diferența pe telefon.
4. Pune în CLAUDE.md: „orice ecran nou respectă stil.md”, ca regula să rămână după azi.

Ce NU vrem: [CE VĂ DISPLACE LA SITE-URILE DE CĂLĂTORII: POZE URIAȘE? PREA MULTE CULORI? TEXT GRI DESCHIS PE ALB?].
```

De ce funcționează promptul: Un design system există ca să nu luați de 40 de ori aceeași decizie și ca site-ul să arate făcut de aceeași mână, oricare dintre voi ar fi construit ecranul. Azi îl scrieți voi, mic, în cuvinte, și abia apoi în cod: ordinea asta e toată lecția. Iar contrastul în soare nu e pedanterie: site-ul vostru se va citi pe stradă, la prânz, pe un ecran cu luminozitatea la jumătate ca să țină bateria.

Pune răspunsul la îndoială: Alegeți ecranul cel mai bun și întrebați: „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ți-l. Designul bun e mai des scădere decât adunare. Apoi întrebați-vă una pe alta: care dintre voi ar fi păstrat elementul, și de ce?

### T26 · Vi · 1.5h · Utilizatori · Mom Test cu site-ul în mână: trei oameni îl folosesc pe telefon, voi tăceți

Promptul: (completează spațiile)

```
Am dat adresa publică la trei oameni (dintre cei care ar veni cu noi sau care călătoresc mult) și i-am privit folosind site-ul pe telefonul lor, fără să-i ajutăm, câte 10 minute: le-am cerut să găsească unde luăm cina în ziua 2 și ce trebuie rezervat din timp. Uite notițele noastre, cuvânt cu cuvânt, plus unde s-au blocat și ce au întrebat (lipim).

Ajută-ne să facem sinteza, fără să îndulcești nimic:
1. Ce au făcut fără ajutor și ce n-au reușit. Un tabel: persoana / a reușit / s-a blocat la / a spus.
2. Care probleme sunt de produs (nu înțeleg ce e sau de ce) și care sunt de interfață (nu găsesc butonul)?
3. Ce au spus politicos și ar trebui ignorat (complimente, „ce frumos”) și ce au făcut concret, care contează.
4. Cele 3 schimbări cu cel mai mare efect, cu motiv, pentru săptămâna viitoare.

Reguli: [CE AȚI OBSERVAT CĂ VĂ TENTEAZĂ SĂ CREDEȚI, DAR N-AVEȚI DOVADĂ].
```

De ce funcționează promptul: Până acum ați discutat despre site; azi l-ați văzut folosit. Diferența dintre „e drăguț” și „n-a găsit cina” e tot ce contează în produs. Regula de a tăcea e cea mai grea și cea mai valoroasă: în secunda în care explicați, pierdeți informația. Punctul 3 e Mom Test aplicat la propriile notițe: și voi vreți să auziți complimentele, mai ales de la oameni dragi.

Pune răspunsul la îndoială: Dintre cele 3 schimbări propuse, întrebați: „Pe care ai propus-o pentru că vrei să ai dreptate și nu pentru că au arătat-o oamenii?”. Claude e surprinzător de cinstit la întrebarea asta. Voi sunteți?

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

Promptul: (completează spațiile)

```
Rescriem PRD-ul ca versiune 2, pe baza a două săptămâni: ce am construit, ce a mers altfel decât am crezut, ce au arătat cei trei oameni. Versiunea 1 rămâne neatinsă în folder; v2 e fișier nou, cu data.

1. Compară PRD-ul v1 cu site-ul care există azi: listează fiecare nepotrivire (ce zice documentul / ce face site-ul) și întreabă-ne, pe rând, care câștigă.
2. Deciziile noi din săptămâna asta (din jurnalul de decizii și din T26) intră numerotate în continuare, fiecare cu data și motivul.
3. Secțiunea „ce NU facem” se actualizează: [CE AȚI 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 noastre ca autoare, ș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 vostru 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 site-ul s-au îndepărtat în două săptămâni, garantat, iar voi hotărâți care are dreptate, nu Claude.

Pune răspunsul la îndoială: Dați PRD-ul v2 cuiva care n-a văzut site-ul și cereți-i să vă spună ce ar construi din el. Unde descrie altceva decât aveți voi, documentul e neclar. Reparați documentul, nu explicați.

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

Promptul: (completează spațiile)

```
Pregătește-ne 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ăm site-ul pe adresa publică, de pe telefon, în 5 minute, pornind de la [CE VREȚI SĂ VADĂ BOGDAN PRIMA DATĂ ȘI DE CE]
- un lucru pe care fiecare dintre noi l-a făcut singură săptămâna asta, și ce a învățat de la cealaltă

Apoi jurnalul: jurnal/saptamana-2.md, împreună, ca săptămâna trecută, cu aceleași 5 întrebări și câte două răspunsuri. Punct de salvare „Jurnal săptămâna 2”.
```

De ce funcționează promptul: A doua săptămână are un site pe internet, deci review-ul devine demo. Un demo bun e o poveste în 5 minute, nu un tur al tuturor butoanelor: „uite-ne în ziua 3, e prânz, uite ce facem”. Alegeți voi începutul, pentru că voi știți ce ați vrea să i se întâmple lui Bogdan în primele 30 de secunde.

Pune răspunsul la îndoială: În review, rugați-l pe Bogdan să folosească el site-ul, pe telefonul lui, fără să-i spuneți nimic. Tăceți două minute. Ce notați î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, jurnal foto, API (Nivel 3: scrieți singure prompturile)

Site-ul capătă memorie în cloud: Supabase, tabele proiectate înainte de cod, reguli de acces (RLS) din prima zi, și bifa pusă pe un telefon apare pe celălalt. Login cu Google doar pentru cei din călătorie, parcurs până la capăt. Jurnalul foto: poze de pe telefon, micșorate, la rândul lor din program. Prima voastră funcție pe server și primul API: ghidul care răspunde din programul vostru, cu cheia la loc sigur și cu limită, apoi planul B pentru ploaie, cu aprobarea unui om. Trackerul v3 în cloud, cu vederea lui Bogdan. Primul audit SuperBoris, pe securitate. Vineri: programul complet, toate linkurile verificate, pozele cu licențele lor.

Livrabile: Supabase cu RLS · bife și note pe două telefoane · login cu Google cu listă de acces · jurnal foto · ghidul și planul B prin API · tracker v3 în cloud · raport de audit · programul complet și verificat · jurnalul săptămânii 3

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

Misiunea: Faceți-vă cont pe Supabase, creați proiectul bazei de date a site-ului și proiectați tabelele împreună cu Claude, ÎNAINTE să scrieți vreun rând de cod în site. La final știți să explicați 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 site-ul azi în localStorage (bifele „rezervat”, comutatorul cu poze / compact) și de ce pentru două persoane pe două telefoane asta nu merge
- cererea de a vă explica, înainte de pași, ce e o bază de date relațională, cu o comparație din viața voastră, și ce e o cheie primară
- propunerea de tabele (de exemplu rezervari, note, poze), cu câmpurile fiecăreia (cine a bifat, când, la ce rând din program) și legăturile dintre ele, pe care voi o aprobați înainte de creare
- ghidaj pas cu pas în panoul Supabase, cu „gata” de la voi, 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 salvați adresa proiectului și cheia anon în site (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):

```
Vrem să mutăm datele site-ului din localStorage într-o bază de date în cloud, pe Supabase, ca bifele „rezervat” și notele să se vadă pe amândouă telefoanele noastre și pe ale celor care vin cu noi. Azi facem DOAR contul, proiectul și tabelele, fără să atingem site-ul.

Înainte de pași, explică-ne: ce e o bază de date relațională (cu o comparație cu un tabel de Excel partajat, sau alta mai bună), ce e o cheie primară, și de ce Supabase are două chei de acces și una dintre ele e secretă.

Apoi:
1. Propune tabelele: ce ținem azi în localStorage (bifele, cu data; comutatorul cu poze) și ce vom avea săptămâna asta (note la rânduri, poze în jurnal, cine a făcut fiecare lucru). Câmpurile fiecăreia și legăturile dintre ele. Așteaptă „ok”.
2. Ghidează-ne în panoul Supabase: cont, proiect în Europa, tabelele, cu „gata” de la noi după fiecare pas.
3. Spune-ne unde găsim adresa proiectului și cheia anon, unde le punem în site, și regula pentru cheia de serviciu.
4. La final: un desen în text al tabelelor și legăturilor, salvat în docs/baza-de-date.md, și punct de salvare.
```

De ce funcționează promptul: Azi nu scrieți cod, și e intenționat: cea mai scumpă greșeală într-o aplicație e un tabel prost gândit, descoperit după ce aplicația l-a umplut. Veți observa că promptul pune explicația înaintea pașilor și aprobarea voastră înaintea creării: la nivelul 3, asta trebuie să vină de la voi, nu din plan. Și motivul pentru care faceți baza de date e unul pe care l-ați simțit: bifa de pe un telefon nu se vedea pe celălalt.

Pune răspunsul la îndoială: Întrebați: „Ce se întâmplă dacă peste o lună vrem ca și prietena care vine cu noi să poată bifa? Ce tabel ar trebui să se schimbe?”. Dacă răspunsul e „niciunul, e prevăzut”, tabelele sunt bune. Dacă e „am adăuga o coloană”, cereți să fie adăugată azi, cât tabelul e gol.

### T30 · Lu · 2h · Rezervări în cloud · Bifele și notele în cloud: site-ul citește și scrie în Supabase (cu RLS de la început)

Misiunea: Mutați bifele „rezervat” și adăugați note la rândurile din program (cine a rezervat, pe ce nume, numărul de confirmare), ținute în Supabase, astfel încât o bifă pusă pe un telefon să apară pe celălalt în câteva secunde, cu regulile de acces (RLS) activate din prima zi. Până la login-ul de mâine, fiecare aparat e „anonim” cu un identificator local.

Promptul tău trebuie să acopere:
- constrângerea de a păstra formatul datelor din săptămâna 2 (bifele existente se mută, nu se pierd)
- cererea ca RLS să fie activ din prima zi, cu regula: oricine are linkul poate citi, dar doar cine e autentificat poate scrie (iar până mâine, un identificator anonim per aparat, explicit temporar)
- citirea în timp real sau la reîncărcare: alegerea voastră, cu avantajele fiecărei variante cerute lui Claude înainte
- testul cu două telefoane: bifa pusă pe unul apare pe celălalt; nota scrisă pe unul se citește pe celălalt
- ce se întâmplă fără internet: bifa se pune local și se trimite la revenire, sau se refuză cu un mesaj clar; decizia voastră, notată în jurnal
- punct de salvare și o propoziție în README despre unde stau acum datele

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

```
Mutăm bifele „rezervat” din localStorage în Supabase și adăugăm note la rândurile din program (pe numele cui e rezervarea, numărul de confirmare, telefonul localului). Tabelele există de azi dimineață (docs/baza-de-date.md). Înainte de cod, planul, și așteaptă „ok”.

Reguli:
1. RLS activ din prima zi: oricine are linkul site-ului poate citi bifele și notele; doar un utilizator autentificat poate scrie. Până mâine, când facem login, folosim un identificator anonim per aparat, și vreau să-mi spui clar că asta e temporar și ce riscă.
2. Bifele deja puse în localStorage se mută în Supabase la prima deschidere, fără să se piardă.
3. Explică-ne întâi cele două variante de a vedea schimbarea celuilalt (timp real sau la reîncărcare), cu avantaje și dezavantaje, și recomandă una pentru un site folosit pe stradă, cu internet slab.
4. Fără internet: [decizia noastră, după explicația ta: se pune local și se trimite la revenire / se refuză cu mesaj].
5. Testăm cu două telefoane: Raluca bifează, Maria vede; Maria scrie o notă, Raluca o citește. Înainte de punctul de salvare.
6. La final, o propoziție în README: unde stau datele acum și ce mai e în browser.
```

De ce funcționează promptul: Aici se vede de ce ați făcut tabelele ieri: codul de azi e simplu când schema e bună. Două reflexe de nivel 3 trebuie să apară în promptul vostru fără să vi le dicteze nimeni: RLS din prima zi (nu „îl punem la final”, pentru că nu se pune niciodată) și testul în două, pe două telefoane, înainte de commit. Și observați întrebarea despre internet slab: în vacanță asta e situația normală, nu excepția.

Pune răspunsul la îndoială: Deschideți site-ul pe un telefon fără internet (modul avion), bifați ceva, apoi reporniți internetul. Ce s-a întâmplat cu bifa? Dacă răspunsul vă surprinde, decizia de la punctul 4 n-a fost implementată cum credeați. Cereți-i lui Claude să vă arate exact unde în cod se ia decizia asta.

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

Misiunea: Adăugați „Continuă cu Google” prin Supabase Auth, cu o listă scurtă de adrese care au voie să scrie (voi două și cei care vin cu voi), legați bifele și notele anonime de conturile voastre și parcurgeți fluxul până la capăt într-un browser real (nu doar până la pagina Google). Site-ul rămâne de citit pentru oricine are linkul.

Promptul tău trebuie să acopere:
- cererea unei explicații, înainte de pași, a ce e OAuth și ce se întâmplă între site-ul vostru, Google și Supabase când apeși butonul (fără ca site-ul să vadă vreodată parola)
- configurarea în Google Cloud (proiect, ecran de consimțământ, client OAuth) și în Supabase, pas cu pas, cu „gata”, și explicația adreselor de întoarcere (redirect)
- lista de adrese cu drept de scriere (allowlist), ținută în baza de date, nu în cod, și regula RLS care o folosește
- ce se întâmplă cu bifele și notele făcute anonim ieri: se leagă de contul care se autentifică primul pe aparatul ăla
- fluxul parcurs cap-coadă pe localhost și pe adresa publică, cu o captură de ecran a stării autentificate, fiecare dintre voi cu contul ei
- ce rămâne vizibil fără login: tot programul, cu bifele, dar fără butoanele de scris

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

```
Adăugăm „Continuă cu Google” prin Supabase Auth, ca doar noi două și cei care vin cu noi să putem bifa și scrie note, iar oricine are linkul să poată citi în continuare. Înainte de orice pas, explică-ne ce e OAuth: ce se întâmplă, în ordine, între site-ul nostru, Google și Supabase când apăsăm butonul, și de ce site-ul nu vede niciodată parola.

Apoi, cu „gata” de la noi după fiecare pas:
1. Google Cloud: proiect, ecran de consimțământ, client OAuth, adresele de întoarcere pentru localhost și pentru adresa publică. Explică-ne de ce există adresele astea și ce eroare primim dacă lipsește una.
2. Supabase: pornim furnizorul Google cu datele de la pasul 1.
3. O listă de adrese de email cu drept de scriere, într-un tabel, nu în cod: [adresele noastre și ale însoțitorilor]. Regula RLS: scrii doar dacă ești autentificat ȘI ești în listă. Oricine altcineva citește.
4. Bifele și notele anonime de pe un aparat se leagă de contul care intră primul pe aparatul ăla, o singură dată, cu confirmare.
5. Site-ul: butonul de login, poza și numele după login, butoanele de scris ascunse pentru cine nu e în listă.
6. Testăm cap-coadă, fiecare cu contul ei, pe localhost și pe adresa publică. Punct de salvare după.
```

De ce funcționează promptul: Login cu Google e locul în care cei mai mulți începători se blochează o zi întreagă, aproape mereu din cauza unei adrese de întoarcere greșite. De asta promptul vostru trebuie să ceară explicația înainte de click-uri. Lista de adrese cu drept de scriere e decizia de produs a zilei: site-ul e public de citit (prietenii primesc linkul), dar îl scriu doar cei din călătorie. Și regula din planul băieților e și a voastră: „verificat” înseamnă parcurs până la starea finală, pe două conturi, nu „s-a deschis pagina Google”.

Pune răspunsul la îndoială: Rugați un prieten care nu e în listă să intre cu Google-ul lui. Ce vede? Dacă poate bifa ceva, RLS-ul vostru nu folosește lista. Dacă vede un mesaj clar („poți citi, nu poți scrie”), ați făcut-o bine, și tocmai ați verificat securitatea cu un om, nu cu o presupunere.

### T32 · Ma · 2h · Jurnal foto · Jurnalul foto: poze de pe telefon, la locul lor în program, cu reguli despre cine vede și cine șterge

Misiunea: Oricare dintre voi poate pune o poză de pe telefon la un rând din program (cafeaua de dimineață, muzeul, cina), direct din site, în câteva secunde, chiar cu internet slab. Pozele se țin în Supabase Storage, se văd pentru oricine are linkul, și le poate șterge doar cine le-a pus. Rândurile din program au un identificator stabil, ca pozele să nu-și piardă locul când schimbați programul.

Promptul tău trebuie să acopere:
- cererea unei explicații a ce e un „bucket” de fișiere față de o tabelă, și de ce pozele nu stau în baza de date
- micșorarea pozei pe telefon înainte de trimitere (o poză de 4 MB nu pleacă pe internet slab), cu limita aleasă de voi
- identificatorul stabil al fiecărui rând din program (de exemplu z03-muzeu) și regula în CLAUDE.md: când se schimbă programul, identificatorii existenți nu se schimbă
- regulile de acces pe bucket: citește oricine, scrie doar cine e în lista de ieri, șterge doar autorul
- ecranul: butonul „+” pe fiecare rând, alegerea pozei, starea „se trimite”, poza apărută la rând, lightbox, ștergere cu confirmare
- testul pe două telefoane, cu internet slab (o bară), și ce se întâmplă dacă închideți site-ul la mijlocul trimiterii

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

```
Construim jurnalul foto: de pe telefon, apăsăm „+” la un rând din program, alegem o poză, și ea apare la rândul ăla pentru oricine deschide site-ul. Înainte de cod, planul și o explicație: ce e Supabase Storage față de tabelele de ieri, și de ce pozele nu stau în baza de date.

Reguli:
1. Fiecare rând din program primește un identificator stabil (de exemplu z03-muzeu); scrie în CLAUDE.md că la orice schimbare a programului identificatorii existenți rămân, altfel pozele își pierd locul.
2. Poza se micșorează pe telefon înainte de trimitere, la cel mult [latura și calitatea alese de noi, după explicația ta], pentru internet slab.
3. Accesul pe bucket: oricine citește, scriu doar adresele din lista de ieri, șterge doar cine a pus poza.
4. Ecranul: „+” la fiecare rând (doar pentru cine poate scrie), stările „se trimite / a reușit / a eșuat, încearcă din nou”, pozele la rând, lightbox la apăsare, ștergere cu confirmare.
5. Testăm pe două telefoane, cu internet slab, inclusiv închiderea site-ului în mijlocul trimiterii. Ce rămâne în bucket atunci? Punct de salvare după.
```

De ce funcționează promptul: Jurnalul foto e funcția care face site-ul să trăiască după vacanță, și e prima dată când aplicația voastră primește fișiere, nu doar text: alt fel de stocare, alte reguli, alt fel de erori. Două lucruri trebuie să vină de la voi la nivelul 3: micșorarea pozei înainte de trimitere (pentru că știți cum e internetul în vacanță) și identificatorul stabil al rândurilor, lecția pe care Bogdan a învățat-o la site-ul lui când a mutat o cină și pozele au rămas orfane.

Pune răspunsul la îndoială: Puneți o poză, apoi schimbați în program.json ora rândului și textul lui, fără să atingeți identificatorul. Poza e tot acolo? Acum schimbați identificatorul. Ce s-a întâmplat? Întrebați-l pe Claude cum ar putea site-ul să vă avertizeze când faceți asta din greșeală.

### T33 · Mi · 2h · API · Ce e un API: prima voastră funcție pe server, care vorbește cu Claude („Întreabă ghidul”)

Misiunea: Construiți o funcție serverless pe Vercel (în folderul api/) care primește o întrebare din site („unde luăm prânzul mâine?”, „cât e de la hotel la muzeu?”), îi dă lui Claude programul vostru ca text și întoarce răspunsul, cu rândurile din program pe care s-a bazat. Cheia API stă doar în variabilele de mediu de pe Vercel, iar funcția are o limită zilnică.

Promptul tău trebuie să acopere:
- cererea unei explicații, înainte de cod, a ce e un API (cu comparația chelnerului sau alta a voastră), ce e o funcție serverless și de ce cheia lui Claude NU poate sta în pagina din browser
- crearea cheii în consola Anthropic de către voi, cu Claude ghidând, și punerea ei ca variabilă de mediu pe Vercel și local (fără să apară vreodată în git)
- contextul pe care îl primește Claude: program.json ca text, cu data de azi, și instrucțiunea să răspundă doar din program și să spună când nu știe
- limita zilnică de întrebări și de ce există (cost pe apel, calculat împreună, cu cifre)
- ecranul: o întrebare, răspunsul, și rândurile din program pe care s-a bazat, ca linkuri spre ziua respectivă
- testul cap-coadă pe localhost și pe adresa publică, cu o întrebare la care programul are răspuns și una la care n-are

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

```
Vrem o funcție „Întreabă ghidul”: scriem o întrebare în site („unde luăm prânzul mâine?”), iar Claude răspunde din programul nostru. Înainte de cod, explică-ne: ce e un API, ce e o funcție serverless pe Vercel și de ce cheia lui Claude nu poate sta în pagina din browser. Apoi planul, și „ok” de la noi.

Reguli:
1. Cheia o facem noi în consola Anthropic, cu tine ghidând; o punem ca variabilă de mediu pe Vercel și local; nu apare niciodată în git. Spune-ne cum verificăm asta.
2. Funcția primește întrebarea și data de azi, îi dă lui Claude program.json ca text și instrucțiunea: răspunde doar din program, scurt, și spune „nu e în program” când nu știe; întoarce și identificatorii rândurilor pe care s-a bazat.
3. Calculăm împreună cât costă un apel (tokeni de intrare cu tot programul, tokeni de ieșire) și punem o limită de [numărul ales de noi] întrebări pe zi, pe tot site-ul.
4. Ecranul: câmpul de întrebare, răspunsul, rândurile folosite ca linkuri spre ziua respectivă, și starea „limita de azi s-a terminat”.
5. Testăm pe localhost și pe adresa publică: o întrebare cu răspuns în program, una fără. Punct de salvare după.
```

De ce funcționează promptul: Azi Claude intră în produsul vostru, nu doar în construirea lui, și învățați singurul lucru care nu se negociază la un API: cheia stă pe server, niciodată în browser, pentru că din browser oricine o poate citi și folosi pe banii voștri. „Răspunde doar din program și spune când nu știi” e felul în care îl țineți cinstit pe un Claude care altfel ar inventa un restaurant. Iar calculul costului pe apel, cu cifre, e ce vă face să puneți limita din prima zi, nu după prima factură.

Pune răspunsul la îndoială: Întrebați ghidul ceva ce nu e în program („unde e cea mai bună înghețată?”). Dacă răspunde cu un loc, cu adresă, instrucțiunea voastră nu ține: a inventat sau a scos din memoria lui, fără link verificat. Reparați instrucțiunea până spune „nu e în program; vrei să caut și să-ți propun, ca să verifici tu?”.

### T34 · Mi · 2h · Conținut asistat · Plan B pentru ploaie: Claude propune o zi alternativă, un om o aprobă

Misiunea: Din site, pentru orice zi, puteți cere „un plan B pentru ploaie” (sau „o variantă mai lejeră”): funcția de ieri îi cere lui Claude rânduri alternative în formatul programului vostru, cu linkuri, iar ele apar marcate „propunere, neverificat” până le aprobă una dintre voi, după ce a deschis linkurile. Nimic neaprobat nu intră în program.json.

Promptul tău trebuie să acopere:
- contextul: regula de conținut a site-ului (nimic fără link verificat de un om) și de ce ea se aplică și la ce propune Claude din interiorul site-ului
- formatul strict pe care trebuie să-l întoarcă Claude (aceleași câmpuri ca un rând din program) și ce face site-ul dacă răspunsul nu respectă formatul
- starea „propunere” vizibilă (culoare, etichetă), cu butoanele „am verificat, intră” și „nu”, doar pentru cine poate scrie
- unde ajung propunerile aprobate: în program.json prin commit, sau într-un tabel, cu avantajele fiecărei variante și decizia voastră
- limita comună cu funcția de ieri (aceeași limită zilnică)
- testul: o zi cu plan B cerut, două rânduri aprobate după verificare, unul respins, și programul recitit pe celălalt telefon

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

```
Construim „Plan B pentru ploaie”: la orice zi din program, cine poate scrie apasă un buton, funcția de ieri îi cere lui Claude 3–5 rânduri alternative pentru ziua aia (locuri acoperite, în aceeași zonă, în același ritm), în exact formatul rândurilor noastre, cu link și orar. Înainte de cod, planul.

Reguli:
1. Formatul răspunsului e strict: aceleași câmpuri ca în program.json. Dacă răspunsul nu respectă formatul, site-ul arată o eroare clară și nu afișează nimic pe jumătate.
2. Propunerile apar marcate „propunere, neverificat”, altă culoare, și au două butoane pentru cine poate scrie: „am verificat, intră” și „nu”. Regula din CLAUDE.md se aplică și aici: se apasă „intră” doar după ce s-a deschis linkul.
3. Explică-ne cele două locuri unde pot ajunge propunerile aprobate (în program.json, prin commit, sau într-un tabel în Supabase), cu avantajele fiecăruia, și așteaptă decizia noastră.
4. Aceeași limită zilnică ca „Întreabă ghidul”.
5. Testăm: cerem plan B pentru ziua [X], aprobăm două rânduri după verificare, respingem unul, și recitim programul pe celălalt telefon. Punct de salvare după.
```

De ce funcționează promptul: Azi închideți cercul: Claude propune conținut din interiorul produsului, și produsul însuși impune regula pe care ați învățat-o în T18: nimic neverificat nu ajunge în program. Starea „propunere” nu e un detaliu de design, e regula de conținut făcută vizibilă. Și decizia de la punctul 3 (fișier sau tabel) e prima voastră decizie de arhitectură adevărată: amândouă sunt corecte, și motivul pentru care alegeți una e ce contează.

Pune răspunsul la îndoială: Cereți un plan B și aprobați un rând FĂRĂ să deschideți linkul, intenționat. Apoi deschideți-l. Era corect? Dacă da, ați avut noroc. Întrebați-l pe Claude: „Cum ar putea site-ul să facă mai greu să aprobi fără să fi deschis linkul?”. Alegeți cea mai simplă variantă și puneți-o.

### T35 · Jo · 1.5h · Tracker · Tracker v3: în cloud, pe amândouă laptopurile, cu vederea lui Bogdan

Misiunea: Trackerul vostru de progres se mută din localStorage în Supabase (un tabel separat în același proiect), se vede și se bifează de pe orice aparat al vostru, iar Bogdan are un link cu o vedere de citit: ce ați bifat, cine, când, și notițele voastre, fără să poată schimba nimic.

Promptul tău trebuie să acopere:
- migrarea bifelor existente din export-ul JSON (T21), fără să pierdeți istoricul și inițialele
- un tabel separat, cu RLS: scriu doar adresele voastre, citește Bogdan printr-un link anume (decideți cum: un identificator secret în link sau contul lui Google)
- vederea pentru Bogdan: pe săptămâni, cu ore făcute din total, cine a dus fiecare sarcină, și ultima activitate
- publicarea trackerului ca pagină a site-ului sau ca proiect separat pe Vercel, cu motivul alegerii
- testul: bifați de pe laptopul uneia, apare pe al celeilalte; Bogdan deschide linkul și vede, dar nu poate bifa

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

```
Mutăm trackerul în cloud, pe Supabase, într-un tabel separat de datele site-ului. Vrem: să-l vedem și bifăm de pe oricare laptop sau telefon al nostru; Bogdan să aibă un link cu o vedere de citit (pe săptămâni, ore făcute din total, cine a dus fiecare sarcină, ultima activitate), fără drept de a schimba.

1. Întâi planul: tabelul, regulile RLS (scriem doar noi; Bogdan citește prin [varianta aleasă de noi: identificator secret în link sau contul lui Google]) și unde publicăm pagina (în site, la o adresă ascunsă, sau separat pe Vercel). Argumentează și așteaptă „ok”.
2. Migrarea: importăm exportul JSON din T21, cu inițiale și date, fără să pierdem nimic.
3. Construim, testăm de pe două aparate, apoi trimitem linkul lui Bogdan și îl rugăm să încerce să bifeze ceva. Nu trebuie să poată.
4. Punct de salvare și un rând în README despre tracker.
```

De ce funcționează promptul: E a treia versiune a aceleiași unelte, și asta e intenționat: trackerul e firul care leagă localStorage (S1), JSON (S2) și baza de date cu reguli de acces (S3). Pentru două persoane, abia azi trackerul e cu adevărat al vostru comun. Vederea lui Bogdan e primul vostru ecran „pentru altcineva, doar de citit”, cu un drept de acces diferit de al vostru: exact tiparul din site-ul public cu scriere restrânsă, la scară mică.

Pune răspunsul la îndoială: Întrebați: „Dacă Bogdan primește linkul și îl trimite din greșeală altcuiva, ce poate face persoana aia?”. Răspunsul trebuie să fie „să citească”. Dacă e orice altceva, RLS-ul tabelului nou nu e bun. Reparați-l înainte de audit, pentru că SuperBoris va întreba exact asta mâine.

### T36 · Jo · 2.5h · Audit · Primul audit SuperBoris: securitatea datelor și a pozelor, cu brief-ul vostru

Misiunea: Scrieți un brief de audit (scop, ce verificăm, criterii da/nu), îl validați cu Claude, apoi îl dați lui SuperBoris pentru o verificare independentă a site-ului: RLS pe toate tabelele, lista de adrese cu drept de scriere, regulile bucket-ului de poze, cheia API, funcțiile cu limită. Reparați ce iese „de reparat”, re-verificați, și salvați raportul în repo.

Promptul tău trebuie să acopere:
- brief-ul scris de voi înainte: scopul (un străin cu linkul poate doar să citească; cine e în listă poate scrie; nimeni nu poate folosi cheia Claude pe banii voștri), limitele (ce NU verificăm azi), criteriile da/nu
- trimiterea brief-ului către SuperBoris cu /superboris, fără concluziile voastre despre cod
- citirea raportului cu întrebarea nr. 8: ce e verificat de el cu o dovadă și ce e presupunere
- repararea punctelor „de reparat” cu Claude Code și re-auditul, până la „aprobat” sau cel mult trei runde
- raportul și brief-ul salvate în docs/audit/, cu data, și punct de salvare
- o listă scurtă a ce ați acceptat „deocamdată”, cu motiv și dată

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

```
Vrem primul audit independent al site-ului. Întâi ne ajuți să scriem brief-ul, apoi îl dăm lui SuperBoris, fără părerile noastre despre cod.

Brief:
- Scop: un străin care primește linkul poate doar să citească programul, bifele și pozele; doar adresele din listă pot scrie și pune poze; nimeni nu poate șterge poza altcuiva; nimeni nu poate folosi cheia Claude sau funcțiile în afara limitei zilnice.
- Verificăm: RLS pe fiecare tabel (rezervari, note, lista de adrese, tracker), regulile bucket-ului de poze, variabilele de mediu și ce e în git, limita funcțiilor, și ce vede un utilizator autentificat care NU e în listă.
- Nu verificăm azi: designul, textele, viteza.
- Criterii: pentru fiecare punct, „da” înseamnă o încercare concretă care a eșuat cum trebuia (de exemplu scrierea ca străin a fost refuzată), nu o citire a codului.

Validează brief-ul cu noi, apoi: /superboris cu brief-ul. După raport, ne arăți ce e verificat cu dovadă și ce e presupunere, reparăm cu tine ce e „de reparat”, cerem re-audit. Raportul și brief-ul în docs/audit/ cu data; punct de salvare.
```

De ce funcționează promptul: Până azi, cel care a construit a și verificat. SuperBoris primește brief-ul vostru și nimic din ce credeți voi despre cod: așa găsește ce n-ați văzut. Criteriul „o încercare care a eșuat cum trebuia” e diferența dintre un audit și o lectură. Și lista „acceptat deocamdată, cu motiv” e maturitate: nu totul se repară azi, dar nimic nu se uită.

Pune răspunsul la îndoială: Alegeți un punct marcat „aprobat” în raport și cereți-i lui SuperBoris: „Arată-mi exact încercarea pe care ai făcut-o și ce răspuns ai primit.” Dacă nu poate, punctul nu era verificat. Un auditor căruia îi ceri dovada e un auditor bun, nu unul jignit.

### T37 · Vi · 2.5h · Conținut · Programul complet, verificat: toate zilele, toate linkurile, pozele cu drepturile lor

Misiunea: Toate zilele vacanței au program complet și verificat: fiecare rând cu link deschis de una dintre voi, orar și preț confirmate, mers calculat; o comandă tipărește singură „N rânduri, toate verificate” (sau câte nu sunt). Pozele de pe site (nu cele din jurnal) au licențe pe care aveți voie să le folosiți, cu sursa notată.

Promptul tău trebuie să acopere:
- ritmul: Claude propune câte o zi, voi verificați împreună sau pe rând, cu reguli despre ce e „verificat” (link deschis, orar citit pe site-ul oficial, preț, zi de închidere)
- o comandă (script) care numără rândurile și pe cele verificate, și tipărește totalul pe ultimul rând; numărul din README vine din ieșirea ei
- pozele: de unde au voie să vină (Wikimedia Commons cu licență potrivită, pozele voastre, nimic de pe Instagram sau Google Images), cu autorul și licența notate la fiecare
- ce faceți cu rândurile neverificate la final (ies din program sau rămân marcate), decizie notată
- o verificare a drumurilor: mersul între rânduri, pe hartă, pentru fiecare zi, și corectarea zilelor cu traversări inutile

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

```
Terminăm programul: toate zilele, verificate. Reguli:
1. Propui câte o zi, în JSON, cu aceleași câmpuri. Pentru fiecare rând, noi deschidem linkul și confirmăm orarul, prețul și ziua de închidere pe site-ul oficial. „Verificat: da” îl pune doar omul.
2. După fiecare zi, verifici drumurile pe hartă: mersul între rânduri, cu minutele, și ne semnalezi traversările inutile ale orașului. Le reparăm înainte să trecem mai departe.
3. Pozele de pe site (nu cele din jurnal): doar de pe Wikimedia Commons cu licență care permite folosirea, sau ale noastre; nimic de pe Instagram sau Google Images. La fiecare poză, autorul și licența într-un fișier date/poze.json.
4. Scrii un script care numără rândurile și pe cele verificate și tipărește pe ultimul rând „N din M verificate”. Numărul ăsta intră în README, copiat din ieșirea scriptului.
5. La final: ce facem cu rândurile neverificate: [decizia noastră: ies / rămân marcate], notată în jurnalul de decizii. Punct de salvare.
```

De ce funcționează promptul: Săptămâna asta ați construit motorul; azi puneți combustibilul, cu aceeași regulă de la T18: Claude propune, omul verifică la sursă. Scriptul care numără e lecția lui Bogdan despre dovezi: o cifră dintr-un raport vine din ieșirea unei comenzi, nu din memoria cuiva. Iar pozele cu licență sunt întrebarea „a cui e sursa?”, pusă la imagini: un site public cu poze luate de pe Instagram e un site care primește într-o zi un email neplăcut.

Pune răspunsul la îndoială: Rulați scriptul, apoi schimbați de mână un „verificat: da” în „nu” și rulați din nou. S-a schimbat cifra? Dacă nu, scriptul minte și README-ul ar minți cu el. Apoi dați unui prieten o zi din program și rugați-l să găsească un link greșit. Dacă găsește, standardul vostru de „verificat” mai are de crescut.

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

Misiunea: Review-ul cu Bogdan, în formatul știut, plus demo-ul funcțiilor noi pe două telefoane (bifa care apare pe celălalt, poza din jurnal, ghidul, planul B) și raportul de audit cu ce ați reparat. Apoi jurnalul săptămânii 3, împreună, câte două răspunsuri.

Promptul tău trebuie să acopere:
- rezumatul, cel mai bun prompt (de data asta scris de voi, fără referință), o greșeală a lui Claude, trei întrebări deschise, parcarea de cuvinte
- demo-ul pe două telefoane, în 5 minute, cu o poveste (o zi din vacanță), nu un tur al butoanelor
- raportul de audit: ce a găsit, ce ați reparat, ce ați acceptat deocamdată și de ce
- ce ați face diferit la bazele de date dacă ați lua-o de la capăt
- jurnalul: jurnal/saptamana-3.md, cu cele 5 întrebări și două răspunsuri la fiecare, și punct de salvare

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

```
Pregătește-ne pentru review-ul cu Bogdan, în formatul de până acum (rezumat în 5 rânduri, cel mai bun prompt al nostru, o greșeală a ta și cum am prins-o, 3 întrebări deschise, parcarea de cuvinte), plus:
- demo-ul pe două telefoane, în 5 minute, ca o poveste: o zi din vacanță în care una bifează, cealaltă vede, apare o poză, întrebăm ghidul, cerem plan B
- raportul de audit în trei rânduri: găsit, reparat, acceptat deocamdată (cu motiv)
- un răspuns cinstit: ce am face diferit la baza de date dacă am lua-o de la capăt

Apoi jurnalul: jurnal/saptamana-3.md, împreună, cu aceleași 5 întrebări și câte două răspunsuri. Punct de salvare „Jurnal săptămâna 3”.
```

De ce funcționează promptul: Cel mai bun prompt al săptămânii e, de data asta, unul scris de voi fără prompt de referință: comparați-l cu cel din săptămâna 1 și vedeți drumul. Întrebarea „ce am face diferit” nu e autocritică, e proiectare: răspunsul la ea e prima decizie din următorul vostru proiect.

Pune răspunsul la îndoială: În review, cereți-i lui Bogdan să pună o întrebare ghidului vostru, pe telefonul lui. Dacă răspunsul e bun, întrebați-l ce l-ar face să aibă încredere în el în vacanță. Dacă răspunsul e prost, aveți prima sarcină de luni.

## Săptămâna 4: Lansarea: oameni reali, calitate, predare (Nivel 3: scrieți singure prompturile)

Pe telefon ca o aplicație, cu programul citibil fără internet. Stările și textele, scrise de voi. Teste automate pentru ce nu are voie să se strice (orele, linkurile, rezervările) și regula „testele înainte de push” în CLAUDE.md. Cine vede ce: nelistat de Google, nota de confidențialitate, copia voastră a pozelor. Adresa finală, cu login-ul mutat fără să se strice. Auditul final: PRD-ul față în față cu site-ul. Joi, lansarea la 10 oameni, cu previzualizare pe WhatsApp, și primul vostru skill. Vineri: README cinstit, pagina voastră de învățare, retrospectiva și demo-ul final, pe două telefoane.

Livrabile: PWA cu program fără internet · teste automate cu „N din N trecute” · notă de confidențialitate + export · adresa finală cu HTTPS · raport de audit final · site-ul la 10 oameni · un skill · README + pagina de învățare · demo final

### T39 · Lu · 2h · Mobil · Pe telefon ca o aplicație, și fără internet: PWA, iconiță, programul în buzunar

Misiunea: Site-ul se adaugă pe ecranul de start al telefonului ca o aplicație (PWA), se deschide repede, și programul se citește și fără internet (în avion, în metrou, într-o țară fără roaming). Testat pe telefoanele voastre și pe al unui prieten cu celălalt sistem (iPhone/Android).

Promptul tău trebuie să acopere:
- explicația a ce e o PWA și ce NU e (nu e în App Store, nu are notificări garantate pe iPhone), cerută înainte
- manifestul, iconița (făcută cu Claude, în culorile din stil.md), ecranul de pornire
- programul, stilul și pozele mici ținute pe telefon pentru citit fără internet; bifele și jurnalul foto cer internet, cu mesaj clar
- o măsurătoare de viteză înainte și după (Lighthouse din DevTools) și ce ați schimbat ca să fie mai rapid
- testul pe două sisteme, cu modul avion pornit, și ce a mers și ce nu pe fiecare

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

```
Vrem ca site-ul să se poată pune pe ecranul de start al telefonului ca o aplicație și ca programul să se citească fără internet. Întâi explică-ne 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 promitem celor care vin cu noi ce nu putem livra.

Apoi:
1. măsurăm viteza de acum cu Lighthouse (DevTools) și notăm cifrele
2. manifestul, iconița (fă-o tu, SVG, în culorile din stil.md), ecranul de pornire, și ce e nevoie ca Chrome și Safari să ofere „adaugă pe ecranul de start”
3. fără internet: programul, stilul și pozele mici se țin pe telefon; bifele și jurnalul foto arată un mesaj clar („fără internet, se trimite când revine” sau „nu se poate acum”), după decizia din T30
4. măsurăm din nou și ne explici ce a schimbat cifra
5. testăm pe telefoanele noastre și pe al unui prieten cu celălalt sistem, cu modul avion pornit; notăm ce diferă

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

De ce funcționează promptul: În vacanță, „fără internet” nu e un caz rar, e marți la prânz în metrou. PWA-ul face site-ul vostru să se poarte ca o aplicație și, cu programul ținut pe telefon, să fie util exact când nu există semnal. Măsurătoarea înainte și după e un reflex de profesionist: „mai rapid” e o părere, cifra e un fapt. Și explicația de la început vă ferește de o promisiune falsă către însoțitori, ceea ce e produs, nu tehnică.

Pune răspunsul la îndoială: Puneți telefonul pe modul avion, deschideți aplicația de pe ecranul de start, mergeți la ziua 5 și apăsați pe o poză din jurnal. Ce se întâmplă? Dacă e un ecran alb sau o eroare criptică, aveți o stare de proiectat mâine, în T40. Notați-o.

### T40 · Lu · 2h · Stări și texte · Stările și textele: ziua goală, fără internet, poza care n-a plecat, scrise de voi

Misiunea: Fiecare ecran are starea goală, de încărcare, de eroare și de succes, cu texte scrise de voi, în vocea voastră, nu generate: ziua fără program, lipsa internetului, poza care n-a reușit să plece, rândul fără link, ghidul fără răspuns. Nimic nu lasă omul să se întrebe „și acum ce fac?”.

Promptul tău trebuie să acopere:
- inventarul tuturor stărilor, cerut lui Claude înainte de orice text, ecran cu ecran, inclusiv cele găsite în T39
- regula: textele le scrieți voi (Claude propune, voi rescrieți în vocea voastră); fiecare mesaj spune ce s-a întâmplat și ce poate face omul acum
- un fișier texte.json cu toate textele, separat de cod, ca să le puteți schimba fără Claude
- verificarea pe telefon a fiecărei stări, provocată intenționat (modul avion, link șters, poză uriașă)
- ce ați învățat despre tonul vostru: cum vorbește site-ul vostru, în două rânduri, puse în stil.md

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

```
Facem inventarul stărilor site-ului și scriem textele lor. Întâi lista: pentru fiecare ecran (ziua, mesele, rezervările, jurnalul foto, ghidul, planul B, login), stările goală, de încărcare, de eroare și de succes, plus cele găsite ieri fără internet. Așteaptă „ok” pe listă.

Apoi, pentru fiecare stare, propune un text în două rânduri: ce s-a întâmplat și ce poate face omul acum. Noi le rescriem în vocea noastră și le punem în texte.json, separat de cod, ca să le schimbăm singure după.

Reguli: fără „oops”, fără „ceva n-a mers”, fără coduri de eroare în fața omului; o stare goală e o invitație („ziua asta n-are program încă; vrei un plan B?”), nu o scuză. La final, două rânduri în stil.md despre cum vorbește site-ul nostru, și verificarea fiecărei stări pe telefon, provocată intenționat. Punct de salvare.
```

De ce funcționează promptul: Stările sunt locul unde se vede dacă un site a fost gândit pentru oameni sau doar construit. Textele le scrieți voi pentru că vocea e a voastră, nu a lui Claude: un site de vacanță al unei familii nu vorbește ca o bancă. Iar texte.json e lecția „date separate de cod”, aplicată la cuvinte: schimbați un mesaj fără să atingeți nimic altceva.

Pune răspunsul la îndoială: Rugați un prieten să citească doar textele de eroare, fără site, și să vă spună ce crede că s-a întâmplat la fiecare. Unde ghicește greșit, textul e neclar. Reparați textul, nu explicați.

### T41 · Ma · 2h · Teste · Teste automate pentru ce nu are voie să se strice: programul, orele, rezervările

Misiunea: Scrieți, cu Claude, teste automate pentru lucrurile care nu au voie să se strice: program.json e valid, orele fiecărei zile sunt în ordine, fiecare rând are link și identificator unic, fiecare rând „de rezervat” apare în lista de rezervat, minutele de mers se adună corect. O comandă le rulează pe toate și tipărește „N din N trecute”, iar CLAUDE.md spune că înainte de push se rulează testele.

Promptul tău trebuie să acopere:
- explicația a ce e un test automat, cu un exemplu din site-ul vostru (ce ar fi prins Ziua de Debug din T24)
- lista a ce testați, aleasă de voi după „ce ne-ar strica o zi de vacanță dacă ar fi greșit”, nu după ce e ușor
- comanda unică și ieșirea ei cu totalul pe ultimul rând; numărul din README vine din ieșirea ei
- un test care pică intenționat o dată, ca să vedeți cum arată eșecul, apoi reparat
- regula în CLAUDE.md: testele se rulează înainte de fiecare push, și ce se întâmplă dacă pică

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

```
Vrem teste automate pentru ce nu are voie să se strice. Întâi explică-ne ce e un test automat, cu un exemplu din site-ul nostru: care dintre cele trei defecte din Ziua de Debug ar fi fost prins de un test, și cum.

Lista noastră, după „ce ne-ar strica o zi de vacanță dacă ar fi greșit”: program.json se citește fără erori; orele fiecărei zile sunt crescătoare; fiecare rând are link, orar și identificator unic; fiecare rând „de rezervat” apare în lista de rezervat; minutele de mers ale unei zile se adună corect; ziua de „azi” se alege corect pentru trei date diferite (înainte, în timpul, după vacanță).

Apoi: o singură comandă care le rulează pe toate și tipărește „N din N trecute” pe ultimul rând. Stricăm intenționat o oră din program, rulăm, vedem cum arată eșecul, reparăm. Punem în CLAUDE.md regula: înainte de push, testele; dacă pică, nu se face push. Numărul din README îl copiem din ieșirea comenzii. Punct de salvare.
```

De ce funcționează promptul: Testele sunt al doilea filtru dintre voi și internet (primul e verificarea pe localhost). Alegeți ce testați după cât ar durea, nu după cât e de ușor: o oră greșită în program vă costă o rezervare pierdută într-un oraș străin. „N din N trecute”, tipărit de comandă, e regula lui Bogdan despre dovezi: cifra din README vine din ieșirea comenzii, nu din memoria cuiva. Și testul care pică intenționat e singurul fel de a ști că testele chiar prind ceva.

Pune răspunsul la îndoială: Întrebați: „Ce test ar fi trebuit să scriem și nu l-am scris?”. Veți primi o listă. Alegeți unul singur, cu motivul „ne-ar strica o zi”, și scrieți-l. Restul merg în README la „ce am testa dacă am avea încă o săptămână”.

### T42 · Ma · 2h · Confidențialitate · Cine vede ce: pozele cu oameni, site-ul nelistat de Google, copia voastră a jurnalului

Misiunea: Hotărâți și implementați cine poate vedea site-ul și pozele: nelistat de Google (ca site-ul lui Bogdan), accesibil doar cu linkul, cu o notă scurtă despre ce date țineți (adrese de email ale celor din listă, poze, bife) și cum se șterg. Un script exportă oricând jurnalul foto și bifele într-un folder al vostru, ca pozele să fie ale voastre și dacă Supabase dispare mâine.

Promptul tău trebuie să acopere:
- explicația, cerută înainte, a ce e GDPR pentru un site mic de familie: ce date personale aveți (emailuri, poze cu oameni, nume), de ce le țineți, și dreptul celor din poze
- decizia: site nelistat de Google (meta noindex) și ce înseamnă „accesibil cu linkul” în practică
- pagina sau nota de confidențialitate, în 10 rânduri, în cuvintele voastre
- un script de export (poze + bife + note) într-un folder local, rulat o dată și pus în README ca procedură
- ștergerea: cum își șterge cineva din listă pozele puse de el, și cum scoateți pe cineva din listă

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

```
Vrem să hotărâm cine vede site-ul și pozele, și să rămânem stăpânele datelor noastre. Întâi explică-ne ce înseamnă GDPR pentru un site mic de familie: ce date personale avem (adresele de email din lista cu drept de scriere, pozele cu oameni, numele), de ce le ținem, și ce drepturi au oamenii din poze.

Apoi:
1. Site-ul nu apare în Google (meta noindex și ce mai trebuie), rămâne accesibil cu linkul. Explică-ne ce înseamnă asta în practică: cine poate ajunge la el și cine nu.
2. O notă de confidențialitate de 10 rânduri, propusă de tine, rescrisă de noi, legată din subsolul site-ului.
3. Un script care exportă jurnalul foto, bifele și notele într-un folder local, cu numele zilei și al rândului în numele fiecărei poze; îl rulăm o dată acum și punem procedura în README.
4. Ștergerea: cine a pus o poză o poate șterge (avem din T32); cum scoatem pe cineva din listă și ce se întâmplă cu ce a pus.
Punct de salvare după.
```

De ce funcționează promptul: Un site cu poze de oameni, chiar al unei familii, are răspunderi: cine le vede, cât stau, cine le poate scoate. Nelistat de Google e decizia pe care a luat-o și Bogdan la site-ul lui: public pentru cine are linkul, invizibil pentru restul lumii. Iar exportul e regula lui despre datele care nu se pot reface: pozele din vacanță sunt de neînlocuit, și un serviciu gratuit poate dispărea; o copie în folderul vostru, făcută cu o comandă, e singura asigurare adevărată.

Pune răspunsul la îndoială: Rulați exportul, apoi ștergeți o poză de pe site și rulați-l din nou. Copia locală a rămas cu poza veche sau a dispărut și de acolo? Hotărâți ce vreți (o arhivă care păstrează tot, sau o oglindă a site-ului) și notați decizia. Nu există răspuns corect, există răspuns ales.

### T43 · Mi · 1.5h · Domeniu · Adresa site-ului: un domeniu al vostru (sau subdomeniul primit), cu login-ul mutat fără să se strice

Misiunea: Hotărâți adresa finală a site-ului: un domeniu cumpărat de voi (numele vacanței .ro sau .com) sau subdomeniul pe care vi-l dă Bogdan pe bgn.ro. Îl legați de Vercel prin DNS, cu HTTPS, și mutați login-ul cu Google pe adresa nouă fără să se strice. Adresa veche redirecționează.

Promptul tău trebuie să acopere:
- explicația, înainte, a ce e un domeniu, ce e DNS și de ce nu trebuie să vedeți nimic „tehnic” din asta ca utilizatoare
- decizia între domeniu propriu (cost, cine îl deține, pe numele cui e cardul) și subdomeniu de la Bogdan, cu motivul
- pașii: cumpărare sau cerere către Bogdan, înregistrarea în DNS, legarea de Vercel, HTTPS verificat
- actualizarea adreselor de întoarcere OAuth (Google Cloud și Supabase) și testul login-ului pe adresa nouă, pe amândouă conturile
- redirecționarea adresei vechi și o propoziție în README cu adresa finală

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

```
Vrem o adresă finală pentru site. Întâi explică-ne ce e un domeniu, ce e DNS și ce se întâmplă când cineva scrie adresa în browser, în cuvinte obișnuite.

Apoi ajută-ne să hotărâm: domeniu propriu (numele vacanței, .ro sau .com; cât costă pe an, pe numele cui e, ce se întâmplă dacă nu-l reînnoim) sau un subdomeniu pe bgn.ro de la Bogdan (gratuit, dar al lui). Recomandă, cu motiv; decizia e a noastră.

Pașii, cu „gata” după fiecare: cumpărarea sau cererea; înregistrarea DNS; legarea de Vercel; HTTPS verificat. Apoi, atenție: adresele de întoarcere OAuth din Google Cloud și Supabase trebuie actualizate; testăm login-ul pe adresa nouă cu amândouă conturile înainte să declarăm gata. Adresa veche redirecționează spre cea nouă. O propoziție în README cu adresa finală. Punct de salvare.
```

De ce funcționează promptul: Domeniul e ultimul pas pe drumul de la „la noi” la „pe internet, al nostru”. Decizia nu e tehnică, e de proprietate: un domeniu cumpărat de voi e al vostru; un subdomeniu e împrumutat. Iar „login-ul mutat fără să se strice” e capcana clasică a mutării de adresă: tot ce depinde de adresa veche (OAuth, în primul rând) trebuie găsit și actualizat, iar singurul fel de a ști că a mers e să intri, pe bune, pe adresa nouă.

Pune răspunsul la îndoială: Deschideți adresa veche pe telefon. Ajunge pe cea nouă? Apoi deschideți adresa nouă fără „https” în față. Tot pe https ajunge? Apoi login. Dacă oricare dintre cele trei nu merge, mutarea nu e gata, oricât de verde ar fi panoul Vercel.

### T44 · Mi · 2.5h · Audit final · Auditul final SuperBoris: PRD-ul față în față cu site-ul, înainte de oameni

Misiunea: Al doilea audit independent, cu brief-ul vostru: de data asta SuperBoris verifică dacă site-ul face ce spune PRD-ul v2 (fiecare decizie numerotată are o dovadă în produs), dacă securitatea din T36 a rămas în picioare după tot ce ați adăugat, și dacă site-ul e gata pentru oameni care nu sunteți voi. Reparați, re-verificați, salvați raportul.

Promptul tău trebuie să acopere:
- brief-ul cu trei părți: PRD față în față cu produsul (decizie cu decizie), re-verificarea securității după schimbările din săptămânile 3–4, și „gata pentru străini” (stări, texte, telefon, fără internet)
- criteriile da/nu pentru fiecare parte, scrise de voi
- raportul citit cu întrebarea nr. 8 și lista „acceptat deocamdată” actualizată
- reparațiile cu Claude Code și re-auditul, cel mult trei runde
- docs/audit/ cu al doilea raport, datat, și punct de salvare

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

```
Auditul final, înainte să dăm site-ul oamenilor. Ne ajuți să scriem brief-ul, apoi /superboris, fără părerile noastre.

Brief:
- Partea 1, PRD față în față cu produsul: pentru fiecare decizie numerotată din PRD v2, dovada că site-ul o respectă (ecranul, rândul, comportamentul) sau abaterea, cu „intenționat” / „uitat”.
- Partea 2, securitatea din nou: tot ce s-a verificat în T36, re-încercat acum, după PWA, texte, domeniu nou, export. Criteriul e tot o încercare care a eșuat cum trebuia.
- Partea 3, gata pentru străini: un om care primește linkul azi, pe telefon, fără internet bun: are toate stările, toate textele, nicio fundătură.
- Nu verificăm: viteza dincolo de cifra din T39.

După raport: ce e verificat cu dovadă, ce e presupunere; reparăm; re-audit. Lista „acceptat deocamdată” se actualizează cu motiv și dată. Raportul în docs/audit/ cu data; punct de salvare.
```

De ce funcționează promptul: Primul audit a verificat securitatea; al doilea verifică promisiunea: PRD-ul e ce ați spus că faceți, site-ul e ce ați făcut, și diferența trebuie să fie intenționată și scrisă, nu uitată. „Gata pentru străini” e criteriul care contează mâine, la lansare: nu voi, care știți unde e fiecare buton, ci un om cu telefonul în mână, în soare.

Pune răspunsul la îndoială: Alegeți o abatere marcată „intenționat” în raport și scrieți în jurnalul de decizii de ce ați abătut-o, cu data. Dacă nu puteți scrie motivul în două rânduri, nu era intenționat, era uitat. Reparați sau reclasificați, cinstit.

### T45 · Jo · 2h · Lansare · Lansarea: site-ul la 10 oameni, previzualizarea pe WhatsApp, și ce faceți cu ce vă spun

Misiunea: Trimiteți linkul la 10 oameni reali (cei care vin cu voi, familia, prietenii care au fost sau vor merge acolo), cu o previzualizare frumoasă pe WhatsApp (titlu, poză, descriere), și urmăriți ce fac: ce deschid, unde se opresc, ce întreabă. Primele reparații în aceeași zi, din ce au arătat, nu din ce au spus.

Promptul tău trebuie să acopere:
- imaginea și textele de previzualizare (Open Graph) pentru WhatsApp și iMessage, făcute cu Claude în stilul vostru, și testate într-un chat înainte de trimitere
- lista celor 10 și mesajul de trimitere, scris de voi, scurt, cu ce să încerce (o zi anume, ghidul)
- cum aflați ce au făcut: o întrebare la 24 de ore (Mom Test), nu „v-a plăcut?”, și eventual ce vă spune Vercel despre vizite
- reparațiile din aceeași zi, alese după ce au făcut oamenii, cu punct de salvare pentru fiecare
- ce rămâne pe lista „după curs”, cu motiv

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

```
Lansăm. Întâi previzualizarea pe WhatsApp: când trimitem linkul, să apară o poză în stilul nostru, titlul vacanței și un rând de descriere. Explică-ne ce e Open Graph, fă imaginea (SVG sau PNG, din paleta din stil.md), punem textele, și testăm într-un chat cu noi două înainte să trimitem altcuiva. Atenție: WhatsApp ține minte previzualizarea pe adresă, deci o facem bine din prima.

Apoi: lista celor 10 oameni și mesajul, scris de noi, scurt, cu o cerere concretă („deschide ziua 4 și spune-ne unde ai lua prânzul”). Ne pregătești întrebarea pe care le-o punem la 24 de ore, după regulile Mom Test: ce au făcut, nu ce cred.

Ce ne spune Vercel despre vizite, dacă ne spune ceva. Reparațiile din aceeași zi, alese după ce au făcut oamenii, fiecare cu punct de salvare. Ce rămâne pe lista „după curs”, cu motiv, în README.
```

De ce funcționează promptul: Lansarea nu e un buton, e un moment în care site-ul iese din mâinile voastre. Previzualizarea pe WhatsApp e primul ecran pe care îl vede toată lumea, înainte să apese: de asta se face cu grijă și se testează. Iar întrebarea de la 24 de ore e Mom Test până la capăt: „ce ai făcut pe site?” vă spune adevărul, „ți-a plăcut?” vă spune ce vreți să auziți. Primele reparații în aceeași zi sunt viteza care deosebește un produs viu de un proiect de școală.

Pune răspunsul la îndoială: Dintre cei 10, alegeți-l pe cel care n-a deschis deloc linkul. Întrebați-l de ce, fără supărare. Răspunsul („n-am avut timp”, „am crezut că e reclamă”, „nu știam ce e”) e o problemă de produs sau de mesaj, și e cea mai ieftină lecție de marketing pe care o veți primi vreodată.

### T46 · Jo · 2h · Skill · Primul vostru skill: „planifică-o-zi”, pe care îl poate folosi altcineva pentru altă destinație

Misiunea: Scrieți un skill pentru Claude Code (un fișier de instrucțiuni refolosibile) care, primind un oraș, o temă de zi și ritmul vostru, propune o zi de program în exact formatul vostru (JSON cu câmpurile din program.json), cu linkuri, orare marcate „neverificat” și distanțe estimate, și îl testați dându-l cuiva care îl folosește pentru altă destinație, fără voi.

Promptul tău trebuie să acopere:
- explicația a ce e un skill față de un prompt (un prompt care a absolvit: fișier, testabil, de dat mai departe) și unde stă în proiect
- conținutul: formatul strict al rândurilor, regulile voastre din T18 (ritm, mese, fără traversări), „verificat: nu” pe tot, verificat/ipoteză la fiecare cifră
- trei teste ale voastre pe trei orașe diferite, cu ce a ieșit prost și ce ați corectat în skill
- testul cu altcineva: o persoană (poate unul dintre băieții din planul-frate) îl folosește pentru destinația lui, fără voi, și vă spune ce a ieșit
- un rând în README despre skill și cum se folosește

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

```
Vrem să facem din ce am învățat la program un skill: „planifică-o-zi”. Întâi explică-ne ce e un skill față de un prompt și unde stă în proiect.

Conținutul: primește un oraș, o temă de zi și ritmul nostru (din regulile din T18); întoarce o zi în exact formatul rândurilor noastre (câmpurile din program.json), cu link la fiecare rând, orar și preț marcate „neverificat”, distanțe estimate cu minutele, mesele la orele noastre, fără traversări inutile; la fiecare cifră spune verificat sau ipoteză; și se termină cu lista a ce trebuie verificat de un om.

Îl testăm pe trei orașe diferite (unul din vacanța noastră, două străine) și corectăm skill-ul după fiecare. Apoi îl dăm cuiva să-l folosească pentru destinația lui, fără noi, și notăm ce a ieșit. Un rând în README despre skill. Punct de salvare.
```

De ce funcționează promptul: Un skill e un prompt care a absolvit: nu mai e o conversație, e un fișier pe care îl poți testa, îmbunătăți și da altcuiva. Scriindu-l, puneți în cuvinte tot ce ați învățat în patru săptămâni despre cum se cere o zi de program bună, și descoperiți ce știați fără să știți că știți. Testul cu altcineva, pe altă destinație, e singura dovadă că skill-ul e al tuturor, nu doar al vostru.

Pune răspunsul la îndoială: Dați skill-ul unui prieten care n-a văzut planul ăsta și rugați-l să-l folosească pentru orașul lui preferat. Dacă trebuie să-i explicați ceva ca să meargă, explicația aia lipsește din skill. Puneți-o și testați din nou, fără să spuneți nimic.

### T47 · Vi · 1.5h · README · README-ul cinstit și pagina voastră de învățare (rețeta voastră de întrebări)

Misiunea: README-ul spune, cinstit, ce e site-ul, ce e gata, ce e pe jumătate, ce ați face diferit și cum se pornește; cifrele din el vin din comenzi (testele, rândurile verificate). Și pagina de învățare: cele patru jurnale, 20 de cuvinte explicate cu exemple din site-ul vostru și rețeta voastră de întrebări, publicată ca pagină a site-ului sau separat.

Promptul tău trebuie să acopere:
- structura README-ului: ce e, pentru cine, cum se pornește local, unde stau datele, ce e gata / pe jumătate / după curs, ce ați face diferit, procedura de export
- cifrele doar din ieșirea comenzilor (testele, scriptul de rânduri verificate), copiate, cu comanda alături
- pagina de învățare: cele patru jurnale, 20 de cuvinte din vocabular explicate de voi cu exemple din site, și rețeta voastră de întrebări (versiunea voastră a tab-ului „Rețeta întrebărilor”, cu ce ați adăuga și ce ați scoate)
- decizia unde se publică pagina (în site, la o adresă proprie, sau separat) și de ce
- punct de salvare și adresa pusă în README

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

```
Două documente de predare. Întâi README-ul, cinstit: ce e site-ul și pentru cine; cum se pornește local; unde stau datele (Supabase, Storage, Vercel) și ce e în browser; ce e gata, ce e pe jumătate, ce e „după curs” (cu motiv); ce am face diferit; procedura de export. Cifrele (teste trecute, rânduri verificate) doar din ieșirea comenzilor, copiate, cu comanda alături.

Apoi pagina noastră de învățare: cele patru jurnale, 20 de cuvinte din vocabularul planului explicate de noi, fiecare cu un exemplu din site-ul nostru, și rețeta noastră de întrebări: versiunea noastră a tab-ului „Rețeta întrebărilor”, cu ce am adăuga după patru săptămâni și ce am scoate, cu motiv. Propune-ne unde o publicăm (în site, la o adresă proprie, sau separat) și așteaptă decizia. Punct de salvare, adresa în README.
```

De ce funcționează promptul: README-ul e primul lucru pe care îl citește cineva care deschide proiectul peste un an, poate chiar voi, înainte de următoarea vacanță. Cinstea lui („pe jumătate”, „după curs”) e mai valoroasă decât orice listă de funcții. Pagina de învățare e examenul de absolvire al planului: rețeta voastră de întrebări, scrisă de voi, e dovada că nu ați copiat o metodă, ați făcut-o a voastră.

Pune răspunsul la îndoială: Dați README-ul cuiva care n-a văzut site-ul și rugați-l să-l pornească local, singur, după instrucțiuni. Cronometrați. Unde s-a blocat, README-ul minte prin omisiune. Reparați-l, nu explicați.

### T48 · Vi · 1h · Retrospectivă · Retrospectiva: cine îl cunoștea mai bine pe Claude în ziua 1, și ce ați învățat una de la alta

Misiunea: O oră de retrospectivă, cu Claude ca secretar: ce a mers, ce nu, ce ați schimba în plan, și două comparații: lista voastră de „la ce e slab Claude”, făcută din patru săptămâni, față de răspunsul lui din T01; și ce a învățat fiecare dintre voi de la cealaltă. Scrisă în jurnalul de decizii, nu într-un chat pierdut.

Promptul tău trebuie să acopere:
- cele trei liste (a mers / n-a mers / am schimba), cu exemple concrete, nu generalități
- comparația cu T01: răspunsul lui Claude din ziua 1 despre slăbiciunile lui față de ce ați văzut voi; cine a avut dreptate și unde
- cele trei momente în care l-ați prins pe Claude greșind, ca poveste de spus la demo
- ce a învățat fiecare dintre voi de la cealaltă, în două rânduri, cinstit
- un rând despre ce faceți cu site-ul după vacanță

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

```
Retrospectiva celor patru săptămâni, cu tine ca secretar, nu ca autor: ne pui întrebările, noi răspundem fiecare, tu notezi în jurnalul de decizii.
1. Ce a mers, ce n-a mers, ce am schimba în plan, cu exemple concrete.
2. Uite răspunsul tău din ziua 1 despre la ce ești slab (lipim nota din T01) și uite lista noastră de acum. Compară-le cinstit: unde ai avut dreptate, unde noi, ce n-a văzut niciunul.
3. Cele trei momente în care te-am prins greșind, ca povești de 3 rânduri, pentru demo.
4. Ce a învățat fiecare dintre noi de la cealaltă.
5. Ce facem cu site-ul după vacanță.
La final, punct de salvare „Retrospectivă”.
```

De ce funcționează promptul: Retrospectiva e locul unde învățarea devine a voastră, nu a planului. Comparația cu ziua 1 e cea mai cinstită măsură a drumului: în ziua 1 îl credeați pe Claude pe cuvânt despre el însuși; azi aveți dovezi. Și întrebarea 4 e motivul pentru care planul ăsta a fost pentru două persoane.

Pune răspunsul la îndoială: Întrebați-l pe Claude: „Ce ai fi făcut diferit dacă ai fi fost tu profesorul în planul ăsta?”. Comparați cu lista voastră de la punctul 1. Unde coincid, planul are o problemă reală; spuneți-i lui Bogdan, planul se îndoaie.

### T49 · Vi · 1.5h · Demo final · Demo-ul final cu Bogdan: o zi din vacanță, pe două telefoane, în 10 minute

Misiunea: Un demo de 10 minute pentru Bogdan, repetat o dată cu Claude ca public: povestea unei zile din vacanță, pe două telefoane, de la cafea la cină, cu bifa, poza, ghidul și planul B, apoi cele trei momente în care l-ați prins pe Claude, pagina de învățare și ce urmează. Nu un tur al butoanelor.

Promptul tău trebuie să acopere:
- scenariul demo-ului, scris de voi, cu cine ține care telefon și ce spune fiecare, minut cu minut
- repetiția cu Claude ca public sceptic: vă întrerupe cu întrebările pe care le-ar pune Bogdan
- cele trei povești cu Claude prins greșind, de 3 rânduri fiecare
- ce urmează: vacanța propriu-zisă, ce faceți cu site-ul după, și dacă vreți un al doilea proiect
- un mulțumesc scris pentru cei 10 oameni care au deschis linkul, trimis după demo

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

```
Pregătim demo-ul final cu Bogdan, 10 minute. Scenariul îl scriem noi: o zi din vacanță, pe două telefoane, de la cafea la cină: una bifează cina, cealaltă o vede; apare o poză în jurnal; întrebăm ghidul; cerem un plan B pentru ploaie; pagina de învățare; ce urmează. Cine ține care telefon, cine spune ce, minut cu minut.

Apoi tu ești publicul sceptic: ne întrerupi cu întrebările pe care le-ar pune Bogdan („de ce nu e în App Store?”, „ce se întâmplă dacă vă fură telefonul?”, „cât costă pe lună?”) și ne spui unde răspunsul nostru a fost slab. Repetăm o dată.

La final, un mesaj scurt de mulțumire pentru cei 10 oameni care au deschis linkul, în cuvintele noastre, de trimis după demo.
```

De ce funcționează promptul: Un demo bun e o poveste, și povestea voastră e simplă: două telefoane, o zi, totul merge. Repetiția cu Claude ca public sceptic e un truc de profesionist: întrebările grele le auziți întâi de la cineva care nu contează. Iar mulțumirea pentru cei 10 e ultima lecție de produs: oamenii care v-au dat timpul lor sunt primii voștri utilizatori, și se țin minte.

Pune răspunsul la îndoială: După demo, întrebați-l pe Bogdan un singur lucru: „Ce ai fi vrut să vezi și n-ai văzut?”. Notați răspunsul în jurnalul de decizii, cu data. E prima sarcină a următorului vostru proiect, oricare ar fi.

## Vocabular
- **prompt**: Mesajul pe care i-l dați lui Claude: context, scop, formă, constrângeri. Să scrieți prompturi complete e meseria pe care o învață tot planul ăsta. Exemplu: „Construiește-ne 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 vedeți funcționând imediat, fără să instalați nimic. Exemplu: Cardul „Ziua 1 · Sosire” din prima zi e un artifact; la fel trackerul.
- **Project**: Un spațiu în claude.ai cu memorie: urcați documente și scrieți instrucțiuni o singură dată, iar fiecare conversație de acolo pornește deja informată. Exemplu: Project-ul vostru are planul ăsta și pagina de o foaie a călătoriei; puteți întreba „ce vrea de la noi sarcina T18?”.
- **instrucțiuni personalizate**: O notă permanentă către Claude, în interiorul unui Project: cine sunteți și cum vreți răspunsurile. Scrisă o dată, aplicată în fiecare conversație de acolo. Exemplu: Ale voastre spun: „suntem mamă și fiică, n-am scris cod, explică termenii, la orice cifră despre călătorie spune dacă e verificată sau ipoteză”.
- **PRD**: Product Requirements Document, documentul-sursă al unui produs: pentru cine e, ce face, ecran cu ecran. Al vostru îl scrieți împreună cu Bruce în prima săptămână și îl corectați pe măsură ce construiți. Exemplu: PRD-ul spune că lista „De rezervat din timp” se generează singură din rândurile marcate „de rezervat”.
- **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 puteți chema cu o comandă. Exemplu: „/bruce hai să definim site-ul vacanței noastre” 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 puteți folosi ca să treceți de la prototip la site-ul 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 verifică dacă un străin cu linkul poate doar să citească, nu să scrie.
- **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: Spuneți „/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 instalați o dată, se actualizează singur. Exemplu: Pachetul BGN pe care îl instalați în ziua 2 e un plugin cu patru agenți.
- **skill**: Un fișier de instrucțiuni refolosibile pe care Claude îl aplică de fiecare dată când se potrivește: un prompt care a absolvit. Fiind fișier, poate fi testat, îmbunătățit și dat mai departe. Exemplu: Skill-ul vostru „planifică-o-zi” propune o zi de program în formatul vostru, pentru orice oraș.
- **HTML**: Limbajul care descrie conținutul și structura unei pagini web: titluri, paragrafe, butoane. Exemplu: Primul vostru artifact din ziua 1 e HTML plus CSS.
- **CSS**: Limbajul care descrie cum arată o pagină web: culori, fonturi, spații, așezare. Exemplu: Paleta din stil.md devine câteva rânduri de CSS.
- **JavaScript**: Limbajul care face paginile web interactive: ce se întâmplă când apăsați, scrieți sau când sosesc date. Exemplu: Logica care alege „ziua de azi” după data telefonului 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: Un rând din program arată așa: {"ora": "10:00", "loc": "Muzeul…", "link": "https://…", "verificat": true}.
- **localStorage**: O memorie mică din browser în care o pagină își poate nota lucruri pentru ea: per browser, per aparat. Închideți tab-ul, reveniți: tot acolo. Deschideți de pe alt aparat: nimic. Exemplu: Bifa „rezervat” pusă de Raluca pe telefonul ei nu se vede pe al lui Maria, până la săptămâna 3.
- **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 bifă „rezervat” e un rând în tabela „rezervari”: la ce rând din program, cine, când.
- **Supabase**: Un serviciu online care vă dă o bază de date adevărată în cloud, gratuit la început, plus login, fișiere și un API gata făcute. Vă faceți cont, el vă dă baza și o adresă prin care vorbiți cu ea. Exemplu: Bifele, notele, lista de acces și pozele din jurnal stau în Supabase.
- **backend**: Jumătatea nevăzută a unei aplicații: baza de date și logica de pe server. Cealaltă jumătate, ce vedeți și apăsați, e frontend-ul. Exemplu: Când site-ul salvează o bifă în Supabase, Supabase e backend-ul lui.
- **frontend**: Jumătatea pe care o vedeți și o atingeți: pagini, butoane, formulare, în browser. Jumătatea nevăzută e backend-ul. Exemplu: Tot ce construiți în primele două săptămâni e frontend.
- **API**: Application Programming Interface: felul în care un program cere altui program informații sau acțiuni, ca un chelner care duce comanda de la masă la bucătărie și aduce farfuria înapoi. Exemplu: „Întreabă ghidul” îi trimite lui Claude, prin API-ul lui, întrebarea și programul vostru, și primește răspunsul.
- **cheie API**: Parola cu care aplicația voastră 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 voștri. 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 vostru ș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ă țineți voi un server pornit. Pe Vercel, un fișier în folderul api/ devine automat o adresă. Exemplu: api/ghid.js primește întrebarea, vorbește cu Claude și întoarce răspunsul.
- **server local**: Un program mic de pe calculatorul vostru care vă servește site-ul cât îl construiți: îl vedeți doar voi, se actualizează instant când se schimbă codul. Exemplu: „Pornește serverul local” și deschideți localhost:3000 ca să vedeți site-ul cum crește.
- **localhost**: Adresa calculatorului vostru, văzută de el însuși. Un site pe localhost rulează doar la voi: nimeni altcineva din lume nu îl poate deschide. Exemplu: http://localhost:3000 merge pe Mac-ul vostru și nicăieri altundeva.
- **terminal**: Fereastra în care vorbiți cu calculatorul prin comenzi scrise, nu prin click-uri. Claude Code trăiește acolo: voi scrieți românește, el scrie comenzi. Exemplu: În ziua 2 îl vedeți pe Claude creând fișiere din terminal.
- **Claude Code**: Claude care lucrează direct pe calculatorul vostru, din terminal: creează fișiere, rulează comenzi, face commit-uri. Diferența dintre a discuta cu un AI și a conduce un constructor. Exemplu: Din ziua 2, aproape tot ce construiți 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 vostru spune: explică-ne termenii, arată-ne planul înainte de schimbări mari, nimic în program fără link verificat, respectă stil.md.
- **git**: Un sistem de puncte de salvare pentru proiect. Fiecare commit e o fotografie la care vă puteți întoarce oricând, deci puteți experimenta fără frică. Și felul în care doi oameni lucrează pe același cod fără să-și strice munca. Exemplu: Ați stricat ceva marți? Vă întoarceți 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ă mesele zilei 3” 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 vostru ține minte fiecare versiune a site-ului de la ziua 2 încolo, cu cine a schimbat ce.
- **GitHub**: Site-ul unde vă țineți repo-urile în cloud: copie de siguranță, istoric, locul de unde Vercel vă ia codul ca să-l publice, și locul unde codul vostru de pe două laptopuri se întâlnește. Conturile vi le faceți în ziua 1. Exemplu: Fiecare push trimite commit-urile voastre pe GitHub, iar Vercel publică automat versiunea nouă.
- **push**: Comanda prin care trimiteți commit-urile de pe calculatorul vostru pe GitHub. Sora ei, pull, aduce la voi ce a trimis cealaltă. Exemplu: Faceți commit, faceți push, iar peste un minut schimbarea e pe adresa publică și pe laptopul celeilalte, după pull.
- **deploy**: Să copiați site-ul de pe calculatorul vostru pe o mașină mereu pornită, ca oricine să-l poată deschide la o adresă web. „Publicat” = live pe internet. Exemplu: În ziua 7 publicați site-ul pe Vercel și îl deschideți de pe telefoane.
- **Vercel**: Un serviciu de găzduire care vă ia site-ul de pe GitHub și îl pune pe internet, gratuit pentru proiecte mici. Publică singur la fiecare push pe ramura principală. Exemplu: Site-ul vacanței, site-ul lui Bogdan din Suedia și acest plan stau pe Vercel.
- **găzduire**: Închirierea de spațiu pe calculatoarele mereu pornite ale cuiva, ca site-ul vostru să fie accesibil zi și noapte. Exemplu: Vercel vă găzduiește site-ul; un registrar vă închiriază numele de domeniu.
- **domeniu**: Adresa voastră pe internet, de felul numele-vacantei.ro. O închiriați anual de la un registrar; așa vă găsesc oamenii. Exemplu: În săptămâna 4 alegeți: un domeniu al vostru sau subdomeniul primit de la Bogdan.
- **subdomeniu**: O secțiune cu nume în fața domeniului, gratuită odată ce ai domeniul. Exemplu: raluca.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. „Îndreptați domeniul către Vercel” înseamnă că editați DNS-ul. Exemplu: Când DNS-ul domeniului vostru arată spre Vercel, scrieți adresa și se deschide site-ul.
- **URL**: O adresă web completă: domeniul plus calea către o pagină anume. Exemplu: https://vacanta-voastra.ro/ziua-3 e un URL: domeniul vacanta-voastra.ro, pagina /ziua-3.
- **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 voastră folosește cheia anon; cheia de serviciu nu iese niciodată din panoul Supabase.
- **RLS**: Row Level Security: regulile din Supabase care hotărăsc ce rânduri din tabel poate vedea sau schimba fiecare utilizator. RLS e ce face sigur ca cheia anon să fie publică. Exemplu: Cu RLS, oricine cu linkul citește bifele, dar doar adresele din lista de acces le pot schimba.
- **login cu Google**: Utilizatorul intră în aplicația voastră 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 voastre un bilet de intrare, fără să-i dea parola. Exemplu: Butonul „Continuă cu Google” de pe site e login cu Google prin Supabase, doar pentru cei din călătorie.
- **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 vă spune că adresa de întoarcere nu e în lista aprobată.
- **lista de acces**: Lista scurtă de adrese de email care au voie să scrie pe site (bife, note, poze). Oricine altcineva, chiar logat cu Google, doar citește. Se ține în baza de date, nu în cod, ca s-o puteți schimba fără Claude. Exemplu: Lista de acces are adresele voastre și ale celor care vin cu voi; un prieten cu linkul citește tot, dar nu poate bifa.
- **design system**: Setul de reguli și componente gata făcute (culori, fonturi, butoane, câmpuri, carduri) din care se construiesc toate ecranele unui site, ca să arate ca făcute de aceeași mână. Exemplu: stil.md e design system-ul vostru, mic, scris în T25 din trei referințe vizuale ale destinației.
- **bgn-33**: Design system-ul lui Bogdan: o foaie de stil și un catalog de componente. Îl primiți odată cu pachetul BGN; îl folosiți în prima săptămână, până vă scrieți stilul vostru. Exemplu: Prototipul din T14 e pe bgn-33; din T25 site-ul e pe stil.md, al vostru.
- **Supabase Storage**: Partea din Supabase care ține fișiere (poze, documente), nu rânduri de tabel. Fișierele stau în „bucket”-uri (găleți), fiecare cu regulile ei despre cine citește, cine scrie, cine șterge. Exemplu: Pozele din jurnalul foto stau într-un bucket: citește oricine, pun doar cei din lista de acces, șterge doar autorul.
- **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 citiți primul vostru 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, bifele sunt mock: se țin î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 vostru: în ziua 3 a vacanței, la prânz, deschideți site-ul în loc de notițe, sau nu.
- **Mom Test**: Regulile lui Rob Fitzpatrick pentru discuțiile cu utilizatorii: vorbiți despre viața lor, nu despre ideea voastră; întrebați ce au făcut concret în trecut, nu ce ar face; ignorați complimentele, chiar și mama ta te-ar minți politicos. Exemplu: „Cum ți-ai planificat ultima vacanță și unde te-ai încurcat?” bate „ai folosi un site ca ăsta?”.
- **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: În vacanță, site-ul e angajat ca să „știm unde e cina fără să ne certăm”, deci concurența e și notița din telefon, și memoria.
- **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, și care poate funcționa și fără internet. Exemplu: În săptămâna 4, site-ul vostru se deschide din ecranul de start al telefonului și arată programul în metrou, fără semnal.
- **Open Graph**: Setul de etichete dintr-o pagină care spun aplicațiilor de mesaje (WhatsApp, iMessage) ce poză, titlu și descriere să arate când cineva trimite linkul. Exemplu: Previzualizarea frumoasă a site-ului pe WhatsApp, la lansare, vine din etichetele Open Graph; WhatsApp o ține minte, deci o faceți bine din prima.
- **noindex**: O etichetă în pagină care îi spune lui Google să nu listeze site-ul în căutări. Site-ul rămâne accesibil pentru oricine are linkul. Exemplu: Site-ul vostru are noindex, ca al lui Bogdan din Suedia: are poze cu oameni și e al vostru, nu al internetului.
- **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 vostru din săptămâna 4 spune cinstit ce e gata, ce e pe jumătate, unde stau pozele și cum se exportă.
- **GDPR**: Regulamentul european de protecție a datelor: dacă site-ul vostru ține date despre oameni (un e-mail, o poză cu cineva, un nume), le spuneți ce țineți, de ce, și le dați voie să le șteargă. Exemplu: Nota de confidențialitate și ștergerea pozelor există din cauza GDPR, chiar la un site de familie.
- **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, iar fiecare întrebare la ghid costă după câți tokeni are programul. Exemplu: O sesiune lungă de Claude Code folosește milioane de tokeni; dacă dați de limită, spuneți-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 bifele se mută în cloud, le vedeți pe amândouă telefoanele, și Bogdan vede trackerul din Cluj.
- **schelet**: Scheletul gol-dar-funcțional al unui site nou: 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 site-ului, apoi umpleți zilele una câte una.
- **producție**: Versiunea live, reală, a unui site, pe care o ating oameni adevărați, spre deosebire de copia de lucru de pe calculatorul vostru. „Gata de producție” înseamnă destul de solid pentru străini. Exemplu: Din ziua în care primul însoțitor pune o poză, site-ul vostru 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 site-ului vostru î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 lipiți întreg.