O aplicație utilă, cu dovezi că funcționează
© liviu.ai · Parcurs propus pentru noua serie · 4 zile × 3 ore · 11 septembrie 2026
Rezultatul final înaintea conținutului
La finalul celor 12 ore, fiecare dintre cele două echipe mixte livrează o aplicație funcțională pe tema aleasă, realizată cu AI: un utilizator poate parcurge o sarcină completă, regulile sunt verificate, rezultatul este păstrat după reîncărcare și o modificare după feedback este demonstrată. Fiecare participant explică o regulă și prezintă o contribuție proprie verificabilă.
Temele nu sunt încă precizate. În ora 1, fiecare echipă alege utilizatorul, sarcina principală și trei criterii concrete. Standardul comun cere un flux de la intrare la rezultat, cel puțin o intrare sau acțiune nevalidă respinsă și informații păstrate. Datele, stările și regulile sunt specifice temei. Trainerul ajută la limitarea scopului astfel încât funcția principală să poată fi construită în timpul cursului.
Aplicația de gestionare a cererilor rămâne un exemplu de referință și o variantă de pornire pentru echipele indecise. Produsul, cantitatea 1–10 și traseul Nouă → În lucru → Finalizată sunt reguli ale acelui exemplu. Echipele nu sunt obligate să le copieze.
Livrabilul echipei cuprinde aplicația, criteriile, probele, o modificare verificată după feedback și limitele explicate. Recomandăm pentru cele 12 ore un proiect de bază demonstrabil local. Conturi, plăți, backend, sincronizare între utilizatori și servicii AI integrate rămân extensii; dacă apar în viziunea temei, se separă de rezultatul de curs. Orice simulare este etichetată explicit.
Filmele și exercițiile rulează din fișiere HTML5/CSS/JavaScript, deschise prin dublu clic pe index.html, fără server local sau API. Pentru construcția aplicației folosim instrumentul AI accesibil cursantului; nu presupunem chei API individuale. Înainte de curs, trainerul verifică accesul și pregătește o bază de pornire pentru cei care au nevoie de sprijin. Exercițiile locale rămân accesibile fără cont.
Structura: 48 de tutoriale, 12 rezultate intermediare
4 zile × 3 ore × 4 tutoriale = 48 de unități video planificate. Fiecare unitate are o competență, un exemplu, o decizie a cursantului și o probă în proiect. Cele patru filme ale unei ore se distribuie între secvențele practice, nu se vizionează ca un bloc continuu.
48 dintre cele 48 de tutoriale au filme disponibile în parcursul video, inclusiv pilotul de idempotență reutilizat în V43. Toate pozițiile au un film asociat. Validarea învățării se face prin probele cursanților în proiect, separat de verificarea tehnică a filmelor.
Harta detaliată a celor 48 de tutoriale include obiectivul, situația vizuală, întrebarea, aplicarea, dovada, dependențele și familiile de active pentru fiecare unitate. Manifestul editorial păstrează aceeași structură pentru automatizarea producției.
| Zi | Ore | Rezultatul demonstrabil al zilei |
|---|---|---|
| 1. De la problemă la primul flux funcțional | 1–3 | Fiecare echipă are tema și scopul alese, trei criterii și primul flux funcțional în aplicația sa. |
| 2. Date corecte, stări explicite, informații păstrate | 4–6 | Fiecare proiect aplică reguli de date și acțiune și păstrează rezultatul după reîncărcare. |
| 3. Verificăm, explicăm și reparăm | 7–9 | Fiecare echipă reproduce și repară un defect și alege o îmbunătățire din feedbackul celeilalte echipe. |
| 4. Modificăm cu control și demonstrăm rezultatul | 10–12 | Cele două aplicații sunt predate cu probe, o modificare verificată și limite explicate; fiecare participant contribuie la demonstrație. |
Ziua 1 — De la problemă la primul flux funcțional
| Ora | Cele patru tutoriale | Ce rămâne în proiect |
|---|---|---|
| 1. Alegem o țintă care poate fi demonstrată | V01: Cui îi economisește timp aplicația?; V02: Ce încape în prima versiune?; V03: «Ușor de folosit» devine o cerință; V04: Proba se gândește înaintea soluției | Fiecare echipă alege tema, completează fișa proiectului și scrie trei criterii. |
| 2. Lucrăm cu AI în pași pe care îi putem verifica | V05: AI propune; tu stabilești criteriul; V06: Contextul care schimbă răspunsul; V07: Un pas mic, de la capăt la capăt; V08: Păstrează o versiune și verifică diferența | Prima cerere de implementare, contextul proiectului și o versiune de revenire. |
| 3. Construim un traseu complet, de la intrare la rezultat | V09: Ce vezi și ce se întâmplă în aplicație; V10: HTML, CSS și JavaScript într-o singură acțiune; V11: Primul traseu care chiar funcționează; V12: Ce vede omul când lista este goală sau apare o eroare? | Primul flux funcțional al fiecărei echipe, fără obligația de a copia formularul exemplului. |
Ziua 2 pornește de la fluxul fiecărei echipe și introduce intrări și acțiuni neașteptate.
Ziua 2 — Date corecte, stări explicite, informații păstrate
| Ora | Cele patru tutoriale | Ce rămâne în proiect |
|---|---|---|
| 4. Definim contractul datelor | V13: Din formular în model de date; V14: Lipsă, text și număr nu înseamnă același lucru; V15: De ce 2,5 trece o regulă și pică alta?; V16: La limită se văd greșelile | Câmpuri, tipuri, limite și mesaje relevante temei; un caz valid, unul invalid și unul la limită. |
| 5. Controlăm ce se poate întâmpla | V17: Starea descrie unde suntem acum; V18: Nu orice salt este permis; V19: Regula trebuie să existe și în logică; V20: Ce înseamnă «finalizată» în acest proiect? | O acțiune permisă și una blocată de starea sau precondiția stabilită de echipă. |
| 6. Păstrăm aceeași înregistrare după reîncărcare | V21: De ce dispare cererea când reîncarci?; V22: Aceeași cerere are aceeași identitate; V23: Salvează și reconstruiește aceeași stare; V24: «Salvat aici» nu înseamnă «salvat oriunde» | Rezultatul relevant proiectului este salvat și restaurat, fără pierderea identității. |
Ziua 3 folosește aceleași probe, dar le privește prin ochii unui coleg care încearcă să găsească un defect.
Ziua 3 — Verificăm, explicăm și reparăm
| Ora | Cele patru tutoriale | Ce rămâne în proiect |
|---|---|---|
| 7. Construim probe care pot contrazice aplicația | V25: Așteptat și observat sunt două lucruri diferite; V26: Un exemplu bun, unul greșit, unul la limită; V27: O probă trebuie să poată fi repetată; V28: După o schimbare, ce trebuie reverificat? | Fișă de probe: intrare, pași, așteptare, rezultat observat. |
| 8. Găsim cauza unui defect | V29: Descrie defectul ca să-l poți reproduce; V30: Urmărește valoarea, nu ghici fișierul; V31: O ipoteză se verifică printr-o schimbare; V32: Repară puțin și dovedește efectul | Un defect reprodus, o cauză verificată și o remediere retestată. |
| 9. Privim aplicația din roluri diferite | V33: Proprietarul: ce merită făcut acum?; V34: Utilizatorul: poate termina fără explicațiile tale?; V35: Analistul și QA: aceeași regulă, rezultate compatibile?; V36: Responsabilul datelor: de ce colectăm acest câmp? | Feedback concret de la cealaltă echipă și o singură îmbunătățire prioritară. |
Ziua 4 începe cu îmbunătățirea aleasă și urmărește impactul ei până la livrare.
Ziua 4 — Modificăm cu control și demonstrăm rezultatul
| Ora | Cele patru tutoriale | Ce rămâne în proiect |
|---|---|---|
| 10. Schimbăm o regulă fără să pierdem controlul | V37: O regulă schimbată are mai multe consecințe; V38: Cererea de modificare are și limite; V39: Compară versiuni și păstrează revenirea; V40: O schimbare este gata când probele sunt actualizate | O schimbare relevantă temei, probe actualizate și versiune de revenire. |
| 11. Pregătim livrarea și înțelegem limitele | V41: Ce trebuie să conțină pachetul predat?; V42: Acțiunea și confirmarea sunt momente diferite; V43: Idempotență: repetăm cererea, nu efectul; V44: Explică limitele înainte de utilizare | Pachet portabil verificat; diferența dintre salvare locală și reîncercări într-un serviciu. |
| 12. Demonstrăm, transferăm și predăm | V45: Demonstrația urmărește o cerere reală; V46: Colegul repetă proba, autorul observă; V47: Transferă regula într-un context nou; V48: Predă rezultatul și alege următorul pas | Aplicație, fișă de probe, modificare demonstrată și limite explicate. |
Următorul proiect pornește de la aceeași metodă, cu complexitate aleasă explicit.
Ritmul unei ore: timpul este pentru construcție
| Activitate | Minute |
|---|---|
| Reactivare: o probă sau o întrebare din ora anterioară | 5 |
| Patru filme scurte, cu comenzile de vizionare | 6 |
| Predicții, decizii și feedback imediat, distribuite între filme | 8 |
| Aplicare în proiectul echipei, în perechi mixte, după tutoriale | 30 |
| Verificarea dovezilor de către alt membru sau cealaltă echipă | 6 |
| Pauză | 5 |
| Total | 60 |
Rezultă 180 de minute pe zi și 720 în total, cu pauzele incluse. Ținta de montaj este aproximativ un minut per tutorial; 45–90 de secunde sunt acceptabile dacă explicația o cere și totalul video încape în cele șase minute ale orei. Un tutorial mai lung se segmentează la o decizie naturală. În ora 12, fiecare echipă are o demonstrație de aproximativ cinci minute; timpul de aplicare rămas acoperă probele reciproce și explicațiile individuale.
Începutul zilelor 2–4 recuperează din memorie o regulă din ziua precedentă, într-o situație ușor schimbată. Dacă o probă de bază nu reușește, participantul primește sprijinul ghidat înainte de extensii.
Continuitate fără aceeași poveste peste tot
Continuitatea principală este progresul celor două proiecte alese. Filmele folosesc un club media, înscrierea la un eveniment, un atelier de reparații, rezervarea unei săli și exemple din proiectele echipelor. Nu cerem construirea a cinci aplicații. După fiecare exemplu, echipa răspunde: «Ce înseamnă această idee în tema noastră? Ce schimbăm? Cum verificăm?».
- Ziua 1 introduce cererea și scopul într-un club media; evenimentul ilustrează colaborarea cu AI, iar atelierul primul flux funcțional.
- Ziua 2 folosește locurile la eveniment pentru numere întregi, reparația unei lămpi pentru stări și revenirea la echipament pentru identitate și persistență.
- Ziua 3 folosește calendarul unei săli pentru testare, cererea de service pentru depanare și proiectele echipelor pentru evaluarea reciprocă.
- Ziua 4 revine la clubul media pentru schimbarea unei reguli; pilotul de magazin explică reîncercările, apoi accentul cade pe livrarea celor două proiecte.
Se refolosesc materiale, iluminare, camere, înregistrări, comportamente și obiecte care au sens în scenă. Biletele, echipamentele, lampa și calendarul au funcții explicative diferite. Culoarea, tipografia și felul în care urmărim identitatea oferă continuitate; decorul și povestea se aleg după concept. Nu folosim aceeași poartă, aceeași tabletă sau același produs în toate explicațiile.
Echipe mixte, cu participare reală
Organizarea de lucru este în două echipe care combină începători și avansați. În interiorul fiecărei echipe, lucrăm în perechi mixte când este posibil. La o echipă de cinci membri, două perechi lucrează pe sarcini delimitate, iar al cincilea verifică integrarea și dovezile; rolul se rotește. O singură persoană integrează modificările unei versiuni la un moment dat, pentru a evita suprascrierile. Nu cerem colaborare simultană în același fișier.
| Rol temporar | Ce face concret | Dovadă individuală |
|---|---|---|
| Analist al sarcinii | Clarifică regula, exemplul și rezultatul așteptat | O cerință și un contraexemplu explicate |
| Operator al instrumentului AI | Formulează cererea, aplică o schimbare și pornește aplicația | O modificare delimitată, verificată |
| Verificator | Încearcă proba, observă efectul și raportează contradicția | O probă reproductibilă cu rezultat efectiv |
Rolurile se schimbă cel puțin o dată pe oră. Persoana avansată poate explica și ghida, dar lasă colegul să opereze, să formuleze și să verifice. Începătorii nu sunt limitați la prezentare sau documentare; avansații trebuie să poată explica deciziile, nu doar să producă implementarea.
Înaintea discuției, fiecare participant formulează scurt propria predicție. La finalul fiecărei zile, fiecare execută o probă sau explică o regulă din proiect, iar trainerul notează sprijinul necesar. Produsul echipei și învățarea fiecărui membru se urmăresc separat. Până la final, fiecare trebuie să fi definit o regulă, să fi operat o schimbare cu AI și să fi verificat un rezultat.
Fișa proiectului și registrul de lucru al echipei păstrează tema, traseul ales, deciziile, contribuțiile și dovezile. Se completează separat pentru fiecare echipă. Nu solicităm date personale în materialele distribuite.
Competențe, sprijin și probe
| Competență | Dovadă urmărită |
|---|---|
| S1: Definește o problemă, un rezultat observabil și un scop realizabil. | P1 |
| S2: Transformă cerințele în exemple și criterii de acceptare. | P1 |
| S3: Colaborează cu AI prin context, schimbări mici și verificarea rezultatului. | P2, P5 |
| S4: Modelează datele și aplică reguli explicite de validare. | P2 |
| S5: Modelează stări și tranziții cu precondiții. | P3 |
| S6: Păstrează identitatea și datele; explică limitele stocării locale. | P4, P6 |
| S7: Reproduce un defect, localizează cauza și verifică remedierea. | P5, P6 |
| S8: Îmbunătățește, livrează și demonstrează o aplicație cu dovezi. | P5, P6 |
Codurile probelor sunt definite mai jos și în harta tutorialelor.
Sprijin ghidat: exemplu rezolvat, proiect de pornire, termeni explicați la nevoie și o probă ghidată. Participantul aplică personal regula și demonstrează efectul. Parcurs independent: aceeași țintă și aceleași probe, cu mai puține indicații. Extensie: teste automate, versionare cu Git sau proiectarea verificării pe server pentru cei care au terminat proba comună. Extensiile nu sunt obligatorii și nu introduc server în livrarea de bază.
Adaptarea urmează răspunsul și rezultatul observat. O greșeală deschide un exemplu rezolvat; reușita deschide un contraexemplu sau un context nou. Nu atribuim stiluri de învățare după vârstă sau facultate.
Evaluarea finală
| Probă | Ce trebuie prezentat |
|---|---|
| P1 | Fișa temei alese de echipă: utilizator, sarcină, limite și trei criterii verificabile. |
| P2 | Un flux complet în aplicația echipei: intrare, acțiune și rezultat; un caz valid și unul invalid demonstrate. |
| P3 | O acțiune permisă și una respinsă de o precondiție sau stare relevantă proiectului. |
| P4 | Rezultatul salvat este regăsit după reîncărcare, cu identitatea și informațiile relevante păstrate. |
| P5 | O schimbare delimitată după feedback, cu probe înainte și după. |
| P6 | Pachetul aplicației, probe reproductibile și explicația limitelor. |
- Echipa demonstrează fluxul principal cu o intrare introdusă în timpul prezentării.
- Respinge o intrare sau acțiune nevalidă și explică regula specifică temei.
- Demonstrează o acțiune permisă și una blocată de starea ori precondiția stabilită.
- Reîncarcă și regăsește rezultatul cu identitatea și informațiile relevante păstrate.
- Arată schimbarea făcută după feedback și probele înainte/după, inclusiv efectul asupra datelor existente.
- Cealaltă echipă reproduce o probă; fiecare participant explică o contribuție și o limită.
Rubrică pe competență: 0 = fără dovadă; 1 = reușește cu sprijin și explicație parțială; 2 = reușește independent și explică rezultatul. O probă făcută în aplicația demonstrativă nu înlocuiește demonstrația în proiectul propriu. Nu declarăm competența dobândită doar din vizionare sau răspunsuri la quiz.
Ordinea de producție și standardul vizual
Lotul de evaluare cuprinde V15 (contractul datelor și locurile la atelier), V18 (stări și repararea unei lămpi) și V23 (persistență și împrumutul unei camere). Filmele și experimentele disponibile sunt legate mai sus. Verificăm noul stil față de pilot, pronunția și proba cursantului înainte de extinderea producției în loturi de patru lecții pe oră.
Inventariem activele existente înainte de modelare. Refolosim imaginile și vocile acceptate când sensul rămâne potrivit. Ama și Corina păstrează tonul conversațional. © liviu.ai rămâne discret în dreapta jos, cu padding; pentru documente, în subsol.
Fișa fiecărui tutorial leagă obiectivul de probă, scenariu, regie și active. Planul stabilește ce trebuie produs; nu dovedește încă atractivitatea sau eficiența învățării. Acestea se verifică prin vizionarea materialului, decizia cursantului și transferul în proiect.
Ontologiile, RAG, grafurile și alte teme din atlas pot deveni resurse suplimentare când proiectul le cere. Principiul 80/20 este folosit ca euristică pentru alegerea funcțiilor și probelor importante, fără a pretinde o proporție măsurată. Fishbone sau alte metode apar doar când ajută o decizie concretă; nu adăugăm un inventar de metodologii peste timpul de construcție.