Proiecte construite. 1 inginer.

Back-office pentru administrarea sponsorilor și donațiilor, cu importuri Excel și extrase BT/CEC, matching și deduplicare a tranzacțiilor, reconciliere manuală, statistici și comunicări de mulțumire prin email, PDF și Word.

Soft Donatii Camin Felix centralizează activitatea internă din jurul sponsorilor și donațiilor unei organizații. Sponsorii sunt gestionați împreună cu datele de contact, țara, moneda uzuală, familia sau casa asociată, copiii sponsorizați, starea activă și indicatorul operațional GDPR. Datele istorice pot fi importate din fișiere Excel separate pentru RON și EURO, iar procesul păstrează inclusiv convenții existente din documentele organizației: formatarea celulelor este folosită pentru a identifica sponsori inactivi și înregistrări marcate cu GDPR. Fluxul principal procesează extrase bancare CSV din Banca Transilvania și CEC Bank. Pentru BT, aplicația caută headerul real al exportului, reconstruiește rânduri CSV care pot conține virgule în descrieri, normalizează sume în formate locale precum 1,234.56 sau 1.234,56, păstrează doar încasările și poate detecta moneda RON sau EUR din extras. Pentru CEC există un parser separat care filtrează comisioane, dobânzi, schimburi valutare și transferuri interne și extrage plătitorul din câmpurile textuale ale băncii. Înainte de salvare, utilizatorul primește un preview cu tranzacții asociate, neasociate și duplicate. Matching-ul sponsorului este construit ca un pipeline determinist. Numele sunt normalizate fără diacritice și caractere speciale, apoi sunt comparate exact sau ca set de token-uri pentru cazuri în care ordinea numelui diferă. Dacă potrivirea directă nu reușește, aplicația caută numele în descriere și folosește istoricul tranzacțiilor deja asociate. Pentru intermediari cunoscuți, precum servicii poștale sau organizații prin care poate veni plata, matching-ul folosește termeni semnificativi din descriere și asocierile istorice. Referințele bancare sunt verificate în batch și protejate suplimentar printr-un index unic în baza de date, iar operatorul poate asocia, dezasocia sau corecta manual tranzacțiile rămase ambigue. Dashboard-ul și rapoartele urmăresc sponsori activi, înregistrări fără GDPR, donații pe monedă, tranzacții nealocate și agregări pe sponsori, familii, copii și țări. Pentru relația cu donatorii, aplicația construiește un raport de mulțumire filtrabil după perioadă, țară și familie. Donatorilor cu email li se pot trimite mesaje individual sau în bulk, iar pentru cei fără email sunt generate scrisori personalizate și plicuri în PDF sau DOCX, individual sau într-o arhivă ZIP pentru tipărire. O comandă Artisan separată permite reconcilierea sumelor BT după referința bancară în mod dry-run și aplicarea controlată a corecțiilor.

ERP pentru o carmangerie, construit în jurul loturilor și mișcărilor de stoc: recepții din facturi, rețete și producție, tranșare de carcase, transferuri între gestiuni, comenzi, vânzări, documente PDF și preluarea facturilor de furnizor prin e-Factura.

ERP/Conta Carmangerie centralizează într-o singură aplicație web fluxurile dintre aprovizionare, depozit, producție și vânzare. Modelul de produs păstrează cantitatea, unitatea de măsură, lotul intern și lotul furnizorului, gestiunea, prețurile, TVA-ul, adaosul, data fabricației, expirarea, temperatura și contul contabil, astfel încât marfa să poată fi urmărită ca variantă de stoc în funcție de lot și gestiune. Recepția poate porni dintr-o factură introdusă în aplicație sau din facturile de furnizor preluate prin API-ul iApp/e-Factura. Facturile importate sunt mapate în furnizori, servicii sau produse, iar pentru produsele de stoc sunt create legăturile către factură, intrarea în gestiune și sursa produsului. Aceeași evidență de proveniență este folosită pentru producție, tranșare și transferuri, astfel încât intrările și ieșirile să poată fi raportate după procesul care le-a generat. În producție, rețetele definesc produsele necesare și gestiunile sursă, iar o operațiune consumă stocurile selectate, înregistrează ieșirile și creează produsul rezultat în gestiunea destinație. Fluxul specific carmangeriei are un modul separat de tranșare: o carcasă este consumată din stoc, piesele rezultate devin produse cu lot intern și gestiune, iar sistemul păstrează diferențele dintre greutatea și valoarea procesată și totalul rezultat. Piesele standard pot fi configurate în funcție de tipul carcasei. Transferurile interne mută o variantă concretă de produs între două gestiuni, păstrând caracteristicile lotului și ale prețului. Dacă aceeași variantă există la destinație, cantitatea este cumulată; altfel produsul este clonat pentru noua gestiune. Comenzile verifică stocul variantei selectate și includ o regulă de business care nu permite vânzarea la un preț mai mic sau egal cu prețul de achiziție. Aplicația generează documente PDF pentru facturi, tranșări și transferuri și oferă registre de intrări și ieșiri construite din proveniența fiecărei mișcări. Arhitectura este un monolit Laravel 10 cu Blade și JavaScript în browser, MySQL prin Eloquent și tranzacții SQL în fluxurile care modifică mai multe entități. Integrarea fiscală este izolată într-un client pentru API-ul iApp, iar documentele sunt randate server-side cu DomPDF. Codul reprezintă o personalizare de produs peste scheletul Laravel și o interfață de administrare, cu logică de domeniu implementată în controllere, modele, servicii și scripturi dedicate modulelor.

Platformă web pentru colectarea declarațiilor Formular 230 prin formular public integrabil, semnătură olografă, acord GDPR și procesare în back-office prin PDF, CSV, XML, arhive ZIP și borderouri ANAF.

Formular 230 digitalizează traseul dintre persoana care completează declarația pentru redirecționarea a 3,5% și echipa organizației care pregătește documentele pentru procesare. Fiecare organizație are propriile date juridice și bancare, poate primi un URL de formular public integrabil prin iframe și poate păstra contribuabilii separat prin association_id. Formularul colectează datele de identificare și domiciliu, opțiunea pentru un an sau doi ani, semnătura desenată din browser și consimțământul pentru prelucrarea datelor. La trimitere, backend-ul validează câmpurile, verifică unicitatea CNP-ului în cadrul organizației și folosește un serviciu extern pentru validarea suplimentară a CNP-ului. Înregistrarea este apoi persistată ca formular semnat, iar un job din coadă generează declarația PDF peste un template oficial, completează datele contribuabilului și organizației, inserează semnătura și poate trimite documentul rezultat prin email către contribuabil. Back-office-ul Laravel Livewire oferă dashboard, selecție de organizație, statistici pentru formulare semnate și perioada de redirecționare, urmărirea sursei din care a fost încărcat iframe-ul, listare paginată și filtrată a contribuabililor, plus administrarea organizațiilor și utilizatorilor. Rolurile user, super_user și admin și relația many-to-many dintre utilizatori și organizații modelează accesul operațional, iar interfața sincronizează organizația selectată între componentele Livewire. Procesarea administrativă este mutată în joburi de coadă. Aplicația poate genera exporturi CSV, XML-uri cu structura folosită pentru Formular 230, arhive ZIP care reunesc documentele aferente unui lot și borderouri XML. Pentru borderou, un command Artisan execută DUKIntegrator prin Java, păstrează rezultatul PDF când acesta este produs și salvează erorile de validare pentru consultare în interfață. Un indicator separat permite marcarea manuală a borderoului ca inclus în e-Guvernare; codul nu demonstrează o integrare API directă cu platforma de depunere. Aplicația folosește storage-ul Laravel pentru documentele generate, cache temporar pentru starea joburilor PDF și un worker de queue administrat prin PM2. Repository-ul include un workflow GitHub Actions pornit manual, care se conectează prin SSH la server, rulează migrările, build-ul Vite, restartează workerul și execută optimizările Laravel.

Ecosistem web și mobile pentru un barber shop, cu programări pe sloturi calculate din servicii și program, aprobare administrativă, remindere push, administrarea clienților și serviciilor, statistici și mecanisme de loialitate.

PCUTB este un produs operațional construit în jurul relației dintre client și salon. Clientul se poate înregistra, își verifică emailul și creează o programare alegând serviciul, ziua și ora. Durata și prețul provin din catalogul administrat de salon, iar backend-ul calculează intervalul final, aplică programul săptămânal, zilele speciale și pauzele și respinge sloturile care se suprapun cu programări existente. Programările create de clienți intră în așteptare, iar zona de administrare oferă calendar, ocupare pe zile, filtre, creare manuală, editare, confirmare, respingere și marcarea neprezentărilor. Administratorul poate gestiona serviciile, programul recurent, excepțiile de calendar, utilizatorii, notificările, recenziile și versiunile aplicațiilor. Regulile includ anularea de către client doar cu mai mult de 24 de ore înainte, protecție împotriva programărilor în trecut și verificări de suprapunere cu pauzele și rezervările deja existente. Notificările sunt tratate pe mai multe canale. Evenimente precum programare nouă, confirmare, respingere, modificare sau anulare creează notificări persistente și pot declanșa Expo Push pentru aplicațiile mobile și Web Push pentru browser. Un job cron verifică periodic programările confirmate și trimite remindere în ferestrele de 24 de ore și o oră înainte, folosind flag-uri persistente pentru a evita retrimiterea normală a aceluiași reminder. Produsul are trei suprafețe principale peste același API: site-ul SvelteKit pentru clienți și administrare, aplicația React Native/Expo pentru clienți și aplicația React Native/Expo dedicată administratorului. Pe web, sesiunea folosește cookie-uri HttpOnly și refresh token; pe mobile, tokenurile sunt persistate în SecureStore, iar interceptorul HTTP serializează refresh-ul atunci când mai multe requesturi primesc simultan 401. Tema vizuală este comună, cu paletă dark/light și accent auriu configurabil. Pe lângă booking, backend-ul include statistici operaționale și un strat de loialitate bazat pe puncte, tranzacții și mini-jocuri. Joburile acordă puncte pentru programări finalizate și gestionează resetarea lunară și leaderboard-ul. Site-ul este public la pcutb.ro, aplicația de client este publicată în App Store, iar repository-urile includ deployment automat pentru backend și web plus un pipeline EAS pentru build, OTA update și submit al aplicației administrative.

Aplicație web multiplayer pentru runde TOMAPAN în camere private, cu cod de acces, categorii configurabile, literă comună, timer, scor pentru răspunsuri unice sau duplicate și sincronizare real-time între jucători.

Vedete & Inițiale este proiectul de portofoliu asociat unui experiment multiplayer construit peste jocul TOMAPAN. Utilizatorii autentificați pot crea o cameră, aleg numărul de runde și categoriile folosite, apoi distribuie un cod unic de șase caractere celorlalți participanți. Jucătorii intră în aceeași cameră, își marchează disponibilitatea și urmăresc prezența grupului în timp real. La pornirea partidei, backend-ul devine sursa de adevăr pentru starea jocului: trece camera din waiting în active, creează prima rundă, alege aleator o literă din setul configurat și persistă momentul de start. Fiecare rundă folosește aceleași categorii selectate la crearea camerei — țări, orașe, munți, ape, plante, animale și nume — iar interfața pornește un timer configurabil. La expirarea timpului sau la trimiterea manuală, răspunsurile ajung în backend și sunt persistate per rundă, utilizator și categorie. Validarea actuală este deliberat simplă: serverul verifică dacă răspunsul începe cu litera rundei, fără dicționar extern sau verificare semantică a existenței cuvântului. După ce toți jucătorii rămași au trimis, răspunsurile valide sunt grupate pe categorie și normalizate la lowercase pentru scoring: un răspuns unic primește 10 puncte, iar același răspuns dat de mai mulți participanți primește 5. Scorul cumulat este păstrat pe relația dintre joc și jucător, apoi backend-ul închide runda și fie creează următoarea rundă, fie marchează jocul finished. Sincronizarea folosește Laravel Broadcasting, Echo și Pusher. Camera de joc este un presence channel autorizat server-side numai pentru utilizatorii care aparțin jocului, iar evenimentele transmit pornirea partidei, schimbările de stare și starea ready. Proiectul include separat și un chat real-time pentru utilizatorii autentificați, cu presence, mesaje broadcast și whisper events pentru indicatorul de typing; mesajele nu sunt persistate în baza de date. Frontend-ul este construit cu Vue 3, TypeScript, Inertia și Tailwind și rulează în același monolit Laravel. Autentificarea, profilul și fluxurile standard de cont provin din scaffolding Laravel Breeze, în timp ce lobby-ul, camera de joc, modelele de domeniu, scoring-ul și integrarea real-time reprezintă logica specifică proiectului. Repository-ul disponibil este un backup importat într-un singur commit, astfel că istoricul Git nu permite reconstruirea cronologică a contribuției sau a etapelor de implementare.

Platformă de review management pentru business-uri, cu linkuri și QR-uri UUID per locație sau angajat, feedback privat pentru experiențe slabe, redirecționare către Google pentru evaluări pozitive și dashboard-uri separate pentru administratori și owneri.

Creative Reviews centralizează fluxul prin care un business solicită feedback după interacțiunea cu un client. Fiecare business primește un UUID stabil și poate avea angajați cu UUID propriu, astfel încât același mecanism de review poate atribui experiența fie la nivelul business-ului, fie unei persoane. Linkurile publice sunt potrivite pentru QR-uri fizice și nu depind de slug-ul comercial; vechile URL-uri pe slug sunt redirecționate permanent către ruta pe UUID. Fluxul public separă explicit două cazuri. Pentru 1–3 stele, interfața deschide un formular de feedback intern, cu comentariu obligatoriu în UI și date de contact opționale; backend-ul persistă review-ul împreună cu business-ul, angajatul opțional, IP-ul și user-agent-ul. Pentru 4–5 stele, aplicația înregistrează un ReviewIntent și afișează pagina de mulțumire care redirecționează către linkul Google Review configurat. Un business poate fi configurat și în modul direct_redirect, caz în care accesarea linkului este înregistrată ca intenție cu rating null și vizitatorul este trimis direct către Google. Zona autentificată are două roluri. Administratorul gestionează owneri, business-uri, angajați, review-uri introduse manual, starea business-urilor și alocarea linkurilor pre-generate. Ownerul vede numai business-urile proprii, își gestionează datele operaționale și angajații și urmărește feedback-ul intern, intențiile pozitive, volumele și ratingurile agregate. Dashboard-urile și paginile de detaliu folosesc relațiile Eloquent și contoare separate pentru review-uri interne și review intents. Un flux operațional important permite pre-generarea a până la 500 de business-uri draft cu UUID înainte ca beneficiarul final să fie cunoscut. Aceste identificatoare pot fi transformate în QR-uri și tipărite în avans; ulterior un administrator alocă draftul unui owner, setează numele și linkul Google și îl activează fără să schimbe UUID-ul folosit de materialul fizic. Pentru operațiuni în lot, administratorul poate filtra și selecta business-uri, exporta QR-urile PNG într-o arhivă ZIP sau genera un fișier XLSX cu numele, linkul de review, statusul și ownerul. Aplicația este un monolit Laravel 12 cu Inertia.js 2 și Vue 3/TypeScript, ceea ce păstrează validarea și regulile de business în backend, dar oferă interfețe reactive fără un API REST separat. Laravel Breeze furnizează baza de autentificare/profil, în timp ce modelele Business, Employee, Review și ReviewIntent, rolurile, dashboard-urile, fluxul public, UUID-urile, provisioning-ul QR și exporturile reprezintă logica specifică produsului. Repository-ul nu conține workflow-uri CI/CD sau o configurație de deployment reproductibilă, iar domeniul menționat în documentația internă nu a fost tratat ca URL public verificat.

Aplicație operațională pentru centralizarea clienților, vehiculelor, programărilor, comenzilor de service, lucrărilor, dosarelor RCA/CASCO, documentelor, facturilor, plăților și deconturilor.

Autoservice App transpune într-o singură interfață fluxurile zilnice ale unui service auto: evidența clienților și vehiculelor, programări, fișe de intrare, comenzi de lucru, manoperă și piese, documente, dosare de daună, facturare, plăți, deconturi și raportare. Navigarea leagă entitățile între ele, astfel încât un client poate fi urmărit spre vehiculele, comenzile, dosarele și documentele sale, iar o programare confirmată poate fi convertită direct într-o comandă service. Fluxul de service folosește statusuri de la comandă nouă până la predarea vehiculului, prioritate, kilometraj, constatare și linii de lucru pentru servicii, manoperă, piese și consumabile. Costurile liniilor includ cantitate, preț unitar, discount și TVA, iar timpul estimat și timpul real pot fi urmărite separat. Regula de predare împiedică trecerea unei comenzi la „Predată” înainte ca aceasta să fi ajuns într-o stare finalizată sau facturată. Modulul RCA/CASCO modelează dosarul de daună separat de comanda service. Păstrează asiguratorul, polița, datele evenimentului, inspectorul, valorile financiare și un status operațional detaliat. Numărul dosarului este verificat ca unic per asigurator, iar închiderea poate fi blocată dacă lipsesc devizul, constatarea sau factura ori dacă există sold neclarificat. Devizele sunt versionate, iar o versiune nouă creată după o aprobare existentă intră automat în starea „necesită reaprobare”. Suplimentările și timeline-ul completează istoricul operațional al dosarului. Documentele pot fi încărcate multiplu pentru client, vehicul, comandă sau dosar, cu tip, notițe, autor, timestamp și versiune pentru devize și constatări. Interfața validează extensiile PDF/JPG/PNG/DOCX și o limită de 20 MB, apoi păstrează fișierul ca Data URL în browser. Facturile și plățile calculează starea neachitat/parțial/achitat, iar deconturile pentru dosarele de daună urmăresc valorile solicitate, aprobate și plătite. Căutarea globală și filtrele contextuale fac legătura între module, iar rapoartele agregă indicatori operaționali, RCA/CASCO și financiari și permit export CSV. Versiunea analizată este construită ca SPA React 19 + TypeScript + Vite, cu persistență locală printr-un strat KV peste Web Storage. Datele demo sunt generate pe domenii și reseed-uite controlat printr-o versiune a datasetului. Patru roluri — administrator, recepție, tehnician și contabilitate — controlează vizibilitatea modulelor și a unor acțiuni, inclusiv costuri și tipuri de documente. Aceste permisiuni și autentificarea sunt însă exclusiv client-side în repository-ul actual: parola demo nu este verificată, iar localStorage nu reprezintă o barieră de securitate pentru date reale. Istoricul Git arată că proiectul a pornit dintr-un prototip generat cu GitHub Spark și a fost extins ulterior cu generatoare de date pe module, navigare contextuală, fluxuri de documente, reguli de acces pe rol, audit pentru acțiuni și căutare globală. Documentația din repository definește separat contractul și direcția unui backend server-side; acel backend nu este prezent în codul analizat și nu este revendicat ca rezultat implementat.

Platformă pentru organizarea programului de lucru, pontaj, ore de recuperat și statistici, completată de PWA offline, alarme mobile sincronizate, notificări Web Push, administrare pe roluri și un modul BBD pentru urmărirea produselor și loturilor.

Program Lucru a evoluat dintr-un viewer de ture într-un produs operațional multi-user. Fiecare angajat are un calendar propriu cu zile de lucru, libere sau concediu, ore de început și final și observații. Programul poate fi editat punctual sau în bloc pe lună, este disponibil în vizualizări pentru azi, săptămână și lună și alimentează statisticile lunare, pontajul și exportul calendarului în format ICS. Implementarea actuală persistă turele explicit pe zile; repository-ul nu implementează o regulă formală de recurență care să genereze automat programul. Pontajul leagă timpul efectiv de programul planificat. Utilizatorul poate marca intrarea și ieșirea, poate vedea istoricul lunar, iar sistemul calculează ora estimată de ieșire și statistici precum întârzierile față de ora programată. Înregistrările manuale sunt suportate pentru corecții, cu control de ownership pentru utilizator și acces administrativ pentru vizualizarea sau operarea datelor altor conturi. Separat, orele de recuperat au propriul flux CRUD, cu motiv, număr de ore, stare pending/rezolvat și dată de rezolvare, iar totalurile sunt incluse în statisticile lunare. Produsul are trei suprafețe conectate la același API. PWA-ul React oferă interfața principală responsive, instalabilă, cu Service Worker, cache pentru utilizare offline și Web Push. Aplicația React Native/Expo reproduce fluxurile esențiale pe mobil și adaugă alarme locale exacte: regulile de alarmă sunt păstrate server-side per utilizator, iar clientul sincronizează programul următoarelor 14 zile și programează local alarmele prin Notifee. Backend-ul include și un scheduler de mesaje Web Push adaptate fazei turei sau tipului de zi, plus administrarea mesajelor și a utilizatorului țintă. Rolurile confirmate sunt consultant, merch și admin. Administratorul poate gestiona utilizatorii și rolurile, poate inspecta pontajul, poate vedea statistici agregate și poate intra temporar în interfața unui angajat prin impersonare controlată server-side. Accesul la modulul BBD este restricționat la consultant și admin. BBD urmărește produse pe brand și loturi cu lună/an de expirare, cantitate și stare rezolvată, oferă căutare și filtrare server-side, scanare de coduri de bare, note la nivel de brand, istoric pentru cumpărător și export Excel grupat. Backend-ul este o aplicație Express/TypeScript cu o bază SQLite încărcată prin sql.js și persistată pe disc. Schema a trecut prin migrări incrementale pentru multi-user, sesiuni cu expirare, loturi BBD și mutarea stării de rezolvare la nivel de lot. Autentificarea folosește tokenuri de sesiune generate criptografic, parole bcrypt și migrare transparentă de la hash-uri SHA-256 vechi, iar login-ul este protejat cu rate limiting. Deployment-ul web și backend rulează automat la push pe main prin GitHub Actions și SSH către VPS, cu build Node.js, Nginx și PM2; baza de date are un script separat de backup zilnic cu retenție de șapte zile. Arhitectura este potrivită pentru un produs intern cu volum moderat și deployment single-instance, dar codul nu este prezentat ca o soluție horizontal scalabilă. Persistența sql.js exportă baza în fișier după mutații, scheduler-ul push trăiește în procesul API, iar unele scripturi vechi — în special importatorul JSON pentru schema single-user — au rămas în urmă față de modelul curent. Aceste limite sunt importante în evaluarea tehnică și definesc direcțiile naturale de evoluție: tranzacții și validare mai strictă pentru scrieri bulk, persistență server-side convențională pentru concurență mai mare și izolarea cache-urilor offline pe identitatea utilizatorului.

Portal B2B Laravel conectat la ERP ManFin pentru sincronizarea catalogului și localităților, prețuri diferențiate per client, feed-uri XML/CSV/JSON, comenzi online și export asincron al comenzilor în ERP.

DeltaPlus Integrare ERP conectează un portal B2B modern cu sistemul ERP ManFin folosit ca sursă operațională pentru produse, categorii, localități și înregistrarea comenzilor. Integrarea nu tratează ERP-ul ca pe un API generic: serviciul dedicat folosește PDO/FreeTDS și stored procedures specifice ManFin, verifică un endpoint primar și unul fallback și expune operațiile necesare pentru catalog, parametri tehnici, ecotaxă, clienți și comenzi. Catalogul local este sincronizat prin joburi Laravel Queue. Produsele sunt aduse după CodStoc și actualizate împreună cu denumirea, prețurile de listă și promo, stocul, EAN-ul, imaginea, specificațiile, garanția și alți indicatori ERP. Parametrii tehnici sunt reîmprospătați per produs, asocierea de categorie este sincronizată, iar ecotaxa este rezolvată separat și persistată pentru exportul corect al comenzilor. Categoriile folosesc relația ierarhică din ERP, iar județele și localitățile sunt importate în bulk în loturi de 500 de rânduri pentru checkout. Pe partea de client, aplicația oferă autentificare, dashboard, catalog filtrabil și paginat, pagină de produs, coș, checkout și istoric de comenzi. Prețul afișat pornește din prețul de listă sau promo configurat pe cont și aplică discountul ori adaosul comercial al clientului. Stocul expus în portal și feed este plafonat la 50 de unități, iar căutarea catalogului acoperă denumire, SKU și EAN. Checkout-ul suportă persoană fizică sau juridică și selectarea județului/localității din datele sincronizate din ERP. Comanda este persistată local înainte de integrarea externă, iar exportul către ManFin rulează asincron. Jobul creează clientul ERP, antetul comenzii și liniile de produs, convertește prețurile la valoarea fără TVA folosită de ERP, separă ecotaxa în linii proprii și poate adăuga liniile tehnice pentru transport și ramburs. Exportul are trei încercări cu backoff de 60 de secunde și evită relansarea atunci când ID-ul ERP a fost deja salvat local. Codul nu implementează însă un mecanism distribuit de idempotency sau locking între crearea comenzii în ERP și salvarea ID-ului local, deci această zonă rămâne una dintre direcțiile importante de hardening. Aplicația expune și un API v1 protejat cu Laravel Sanctum. Utilizatorii autentificați pot obține feed-ul personalizat în XML, CSV sau JSON, iar feed-ul generat este salvat per cont. Există și un endpoint intern pentru regenerarea CSV, protejat suplimentar prin restricție de IP. Separat, o comandă CLI poate genera toate cele trei formate pentru un utilizator sau pentru toate conturile. Generarea este corect personalizată pe prețul clientului, dar în implementarea actuală încarcă întregul catalog activ în memorie pentru fiecare utilizator, fără streaming sau chunking. Panoul de administrare Filament gestionează utilizatori, produse, categorii și comenzi și include o pagină dedicată sincronizării ERP. Administratorul poate verifica reachability pentru hostul primar și fallback, poate trimite în coadă sincronizarea categoriilor, localităților și produselor și poate retrimite manual o comandă spre ERP atunci când aceasta nu are încă ID extern. Accesul la Filament este limitat conturilor active cu flag de administrator; portalul și login-ul API folosesc autentificarea standard, dar codul actual nu adaugă explicit filtrul is_active la autentificarea clienților. Repository-ul include o cale de migrare din vechile tabele wpke_erp_* către schema erp_*, ceea ce indică modernizarea unui flux existent, nu un proiect demonstrat ca fiind construit complet de la zero. Totodată, manifestele curente cer PHP 8.2 și Laravel 12, în timp ce imaginea Docker legacy pornește de la PHP 8.0, iar compose-ul denumit prod este practic identic cu cel local și nu definește worker de queue, scheduler, healthcheck sau CI/CD. Testele existente sunt doar exemplele Laravel implicite. În consecință, seed-ul tratează integrarea, modelul de date și fluxurile B2B ca funcționalități confirmate, dar nu revendică deployment automatizat, acoperire reală de teste, plăți online, sincronizare programată, email/SMS, analytics sau AI.

Platformă de ticketing pentru evenimente, construită pe un MVC PHP propriu, cu categorii de bilete, checkout și plăți, emitere QR, validare la acces, refund și raportare operațională.

Portal Evenimente & Bilete este un proiect client construit în jurul ciclului complet al unui eveniment cu acces pe bază de bilet: configurarea evenimentului și a capacității, definirea categoriilor de bilete, checkout-ul, plata, emiterea biletului, validarea la intrare și operațiunile ulterioare precum refund-ul și raportarea. Documentația legacy din portofoliul Tigidal descrie aplicația ca fiind construită înainte de adoptarea Laravel, pe un framework PHP MVC propriu sub namespace-ul hthepaul/. Arhitectura documentată include routing cu parametri URL, layout-uri și partiale PHP, acces la MySQL prin PDO și un strat de query/ORM simplificat, autentificare bazată pe sesiuni și protecție CSRF. Aceeași documentație indică un frontend clasic HTML/CSS/JavaScript, Bootstrap și jQuery. Fluxul de ticketing permite organizarea mai multor evenimente și configurarea mai multor categorii de bilete, fiecare cu preț, cantitate și perioadă de vânzare. După checkout și confirmarea plății, biletul este emis cu un cod QR unic și poate fi trimis cumpărătorului prin email. Pentru controlul accesului, scanarea QR verifică token-ul biletului și îl marchează ca folosit, astfel încât aceeași intrare să nu poată fi validată repetat. Zona operațională documentată include roluri distincte pentru administrare, organizare și validare, dashboard-uri cu vânzări și starea biletelor, export Excel al participanților și module pentru tranzacții. Datele legacy din frontend mai menționează payouts, cupoane, social și notificări în structura mai largă a produsului. Scope-ul actual furnizat pentru proiect confirmă suplimentar capacitatea, refund-ul și raportarea ca părți importante ale fluxului. Pentru că repository-ul original HthePaul/alex nu este disponibil în instalarea GitHub conectată acum, aceste detalii arhitecturale sunt prezentate ca documentație istorică păstrată în Tigidal, nu ca o revalidare linie-cu-linie a codului sursă curent. Nu este atribuit un provider concret de plată, un deployment sau alte integrări care nu apar în materialele disponibile.

Tool Python pentru colectarea și normalizarea anunțurilor Storia, cu scraping paralel, deduplicare pe ID-ul anunțului, stocare relațională, API REST filtrabil și calcul de distanțe pietonale, auto și transport public.

Imobiliare Scraper este un proiect de studiu construit pentru a transforma listările imobiliare într-un set de date interogabil, nu doar într-un export punctual. Fluxul Django pornește de la paginile de rezultate Storia, detectează automat numărul de pagini din __NEXT_DATA__, extrage preview-urile anunțurilor și apoi deschide paginile de detaliu pentru a prelua titlul, descrierea, prețul, suprafața, etajul, coordonatele, cartierul, strada, datele publice ale vânzătorului, caracteristicile, facilitățile, imaginile și timestamp-urile furnizate de sursă. Scraperul folosește o sesiune requests cu connection pooling și retry pentru răspunsuri 429 și erori 5xx, delay-uri scurte randomizate și ThreadPoolExecutor cu număr configurabil de workers pentru procesarea paralelă a paginilor de detaliu. Întreruperea prin Ctrl+C este tratată explicit atât în varianta standalone, cât și în comanda Django. Persistența principală este modelată relațional în Django: Listing păstrează câmpurile de interogare frecventă, iar Characteristic, Feature, Image și Distance sunt tabele separate cu relații, constrângeri de unicitate și indexuri dedicate. Re-scraping-ul folosește update_or_create pe ad_id, astfel încât același anunț este actualizat în loc să fie duplicat. Caracteristicile, facilitățile și imaginile asociate sunt reconstruite și inserate bulk pentru a păstra o reprezentare coerentă a stării curente. Pe lângă distanța geodezică Haversine, serviciul de distanțe poate interoga OSRM pentru trasee pietonale și auto și, dacă există o cheie configurată, Google Maps Directions pentru transport public. Rezultatele sunt persistate per anunț și punct de referință și pot fi folosite direct în filtrele API. Django REST Framework expune listare paginată și detaliu complet, filtrare după tipul vânzătorului, tipul advertiserului, cartier, interval de preț și duratele de deplasare, plus filtre multi-select pentru facilități și caracteristici. Endpointuri separate întorc valorile disponibile pentru filtre, recalculează distanțele unui anunț și pot declanșa manual un nou scraping. Acest trigger rulează sincron în procesul API; repository-ul nu conține un worker Celery activ. Repository-ul păstrează și o etapă anterioară a proiectului în directorul base/: scraper BeautifulSoup, procesare paralelă și persistență SQLite, cu export JSON/CSV și un script shell de administrare. Scriptul face referire la o interfață web locală, dar fișierul start_web.py nu este prezent în backup, iar repository-ul actual nu conține componente frontend. Din structura API-ului și a filtrelor se poate deduce intenția unui instrument de selecție a locuințelor după cost, zonă, facilități și timp de deplasare, însă acel UI nu este revendicat ca implementat. Versiunea analizată este un proiect de dezvoltare, nu o configurație production-ready: setările Django păstrează DEBUG activ, un secret de dezvoltare și credențiale MySQL în cod, nu există autentificare sau autorizare pentru acțiunile POST, iar request-urile OSRM dezactivează verificarea TLS. Acestea sunt limite de securitate care trebuie remediate înainte de expunerea serviciului pe internet.

Backend de integrare care preia nomenclatoare Farmadati prin SOAP, descarcă dataset-uri paginate, parsează XML în streaming, normalizează schema și persistă produse, producători, descrieri și metadate de imagini pentru consum prin API.

Farmadati Laravel API este un serviciu backend construit pentru a transforma dataset-urile Farmadati într-o structură locală mai ușor de consumat de aplicații web sau servicii interne. Integrarea pornește de la serviciul SOAP Farmadati: aplicația poate interoga seturile de date activate, poate cere schema unui set și poate descărca paginile de date aferente. Credențialele furnizorului sunt citite din environment, nu sunt hardcodate în repository. Fluxul principal de import este un pipeline ETL. Pentru fiecare dataset, aplicația descarcă răspunsul binar ca arhivă ZIP, îl extrage în storage, citește XML-ul cu XMLReader și mapează cheile tehnice ale furnizorului către denumiri englezești. Denumirile sunt apoi normalizate pentru coloanele SQL, iar înregistrările sunt scrise în batch-uri prin upsert. Importul de produse folosește loturi de 2.500 de înregistrări, iar descrierile lungi folosesc loturi mai mici de 100, ceea ce arată o ajustare explicită pentru payload-uri mai grele. Modelul local separă produsele de producători, descrieri scurte, descrieri lungi și metadatele imaginilor. Product leagă descrierea lungă, producătorul și imaginea prin cheile provenite din nomenclator, iar codurile principale sunt protejate prin constrângeri unique în migrări. API-ul expune lookup exact după product_code și o listare paginată care face eager loading pentru relațiile folosite în răspuns. Importul descrierilor scurte există și persistă datele separat, însă relația nu este conectată în răspunsul principal Product din snapshotul analizat. Importul complet orchestrează secvențial produsele, producătorii, imaginile și cele două tipuri de descriere și reconectează baza de date între etape. Procesarea XML este streaming, iar scrierile sunt bulk upsert în tranzacții, evitând atât încărcarea întregului fișier XML în memorie, cât și inserările individuale per rând. Pe de altă parte, importurile rulează direct în request-uri HTTP cu timeout extins, nu prin queue workers, nu există retry/backoff formal pentru apelurile SOAP și nu există locking pentru două importuri concurente. Versiunea salvată în repository trebuie tratată ca un backend de integrare funcțional/prototipal, nu ca o suprafață publică hardenată. Rutele de import, schema și chiar execuția unei comenzi Artisan sunt expuse în web routes fără autentificare sau rate limiting dedicat. În plus, clientul SOAP folosește endpoint HTTP, iar ramurile de eroare pot afișa request/response-ul SOAP atunci când trace este activ. Pentru producție, pașii naturali sunt izolarea operațiilor administrative în CLI/queue, autentificare și autorizare, allowlist pentru operații, validarea parametrilor de paginare, HTTPS pentru furnizor dacă este disponibil și eliminarea datelor sensibile din output-ul de eroare. Repository-ul nu conține CI/CD, Docker sau o configurație de deployment reproductibilă. Laravel oferă endpointul standard /up, iar Vite și pagina welcome există ca scaffolding, dar nu există un frontend Farmadati custom în codul analizat. De asemenea, istoricul disponibil este un singur commit de backup, astfel încât contribuția poate fi descrisă prin logica custom prezentă în service, controllere, modele, migrări și rute, nu printr-o cronologie completă a dezvoltării.

Modul WordPress care preia seturi de date Farmadati prin SOAP, normalizează schema XML și îmbogățește produse WooCommerce cu prețuri, descrieri, producător, metadate farmaceutice și imagini.

Farmadati Import este un modul de administrare WordPress construit pentru integrarea unui catalog Farmadati într-un magazin WooCommerce. Interfața este disponibilă administratorilor printr-o pagină dedicată din wp-admin și permite salvarea credențialelor Farmadati, aplicarea unui adaos numeric la prețurile importate și lansarea manuală a sincronizării. Fluxul pornește prin serviciul SOAP Farmadati: codul cere lista seturilor de date active, descarcă datele cu GetDataSet și citește schema fiecărui set cu GetSchemaDataSet. Fișierele primite sunt salvate ca ZIP, extrase local și procesate cu XMLReader. Schema furnizorului este tradusă din denumirile italiene într-un model intern stabil, astfel încât date provenite din tabele diferite să poată fi corelate după codurile de produs sau companie. TE001 furnizează produsul de bază, iar implementarea analizată limitează explicit această etapă la primele 20 de înregistrări. Pentru aceste produse, TS067 completează producătorul folosit drept Brand, TR039 adaugă descrierea scurtă, TE008 adaugă descrierea extinsă, iar TE009 atașează numele documentelor de imagine. Tabelele auxiliare sunt parcurse streaming și sunt corelate prin structuri asociative indexate după cod, evitând încărcarea lor integrală în colecții intermediare. Persistența finală se face direct prin API-ul WooCommerce. Produsele existente sunt căutate după meta-câmpul product_code și actualizate, iar cele noi sunt create ca WC_Product_Simple. Sunt salvate denumirea, descrierile, prețurile, codurile Farmadati, tipul produsului, codul ATC/GMP, flag-ul comercial, datele de preț, TVA-ul și producătorul. Imaginile sunt descărcate din serviciul Farmadati prin WordPress Media API, prima imagine devine featured image, iar producătorul este creat sau actualizat în taxonomia custom brand și asociat produsului. Codul are și câteva limite importante ale snapshot-ului analizat. XML-urile extrase sunt refolosite dacă există deja local, fără o regulă de invalidare a cache-ului, iar importul rulează sincron în request-ul de admin, fără queue, retry, locking sau procesare în background. Upsert-ul pe product_code reduce duplicatele în rulări secvențiale, dar nu există constrângere unică sau protecție pentru importuri concurente. Acțiunile POST nu folosesc nonce-uri WordPress, credențialele sunt păstrate în options, WSDL-ul SOAP este configurat pe HTTP, iar răspunsurile de diagnostic pot include request-ul SOAP în caz de eroare. Butonul de ștergere operează CPT-ul pharmaceutics, în timp ce importul scrie produse WooCommerce, iar un WP_Error întors de media_sideload_image nu este numărat corect în sumarul final deoarece obiectul este truthy. Repository-ul nu conține teste, CI/CD sau bootstrap-ul complet al pluginului, deci aceste elemente nu sunt revendicate ca livrabile demonstrate.

Concept tehnic pentru centralizarea comenzilor din mai multe magazine WooCommerce și declanșarea generării AWB dintr-un singur panou, reutilizând integrarea de curier existentă în fiecare magazin în locul reconstruirii ei în backend-ul central.

Proiectul a fost conceput pentru un operator care administrează mai multe magazine WooCommerce și pierde timp intrând separat în fiecare wp-admin pentru a verifica comenzile și a genera documentele de transport. Direcția definită în repository este o aplicație centrală read-only: comenzile sunt agregate într-un singur dashboard, iar acțiunea principală este „Generează AWB”. Comanda rămâne sursa de adevăr în WooCommerce, astfel încât adresele, metoda de plată și opțiunile de livrare nu sunt editate în aplicația centrală. Arhitectura propusă evită duplicarea API-ului de curier. Fiecare magazin păstrează pluginul oficial Sameday Courier, care știe deja să autentifice contul, să sincronizeze servicii, pickup points, lockere/easybox, să estimeze costul, să genereze și să șteargă AWB-uri, să producă PDF-ul, să adauge colete și să citească istoricul de status. Aplicația centrală urma să trimită către magazin doar identificatorul comenzii printr-un endpoint WordPress custom; pluginul/site-ul sursă ar fi reconstruit payload-ul din WC_Order și meta-datele locale, apoi ar fi executat operația de AWB în contextul magazinului. Repository-ul conține două livrabile proprii de proiectare: o specificație tehnică și o prezentare HTML pentru varianta cu buget restrâns. Ele descriu un flux complet de la comandă la AWB, modelele propuse Site, Order și Awb, un OrderIngestService pentru webhook sau pull periodic, un AwbService și o politică simplă de retry. Pentru comunicația dintre aplicația centrală și WordPress este documentată autentificarea cu HMAC-SHA256, timestamp și cheie separată per site, iar rollout-ul era gândit întâi pe un magazin pilot și apoi replicat. Important pentru evaluarea portofoliului: aplicația centrală Laravel + Vue/Inertia, endpointul REST custom, HMAC-ul, webhook-ul/pull-ul de ingest și retry-ul nu sunt prezente ca implementare în codul salvat. Lista de fișiere din commitul de backup conține prototipul HTML, documentația și pluginul oficial Sameday, nu modele Laravel, migrări, controllere, componente Vue sau workflow-uri ale unei aplicații centrale. Din acest motiv proiectul este prezentat ca soluție de integrare proiectată pentru un client real, nu ca produs final livrat. Baza third-party analizată este un plugin WordPress/WooCommerce matur. Codul său folosește PHP, JavaScript/jQuery, WP_List_Table, tabele MySQL prin wpdb și SDK-ul PHP Sameday. Sunt implementate în plugin generarea AWB cu unul sau mai multe colete, alegerea serviciului și pickup point-ului, locker/easybox prin listă sau hartă interactivă, estimarea costului, extra fee și free-shipping rules, COD/repayment, open-package, PDF AWB, ștergerea AWB-ului și istoricul coletelor. Aceste capabilități explică de ce soluția propusă reutiliza pluginul în loc să dubleze această logică în aplicația centrală. Frontend-ul propriu existent este o pagină de prezentare/prototip, nu dashboard-ul final. Folosește Inter și o paletă albastru deschis cu accente semantice verde/amber/roșu, carduri, timeline și secțiuni pentru scope, flux, livrabile și riscuri. Capturile incluse din plugin arată UI-ul WordPress moștenit: formular de configurare, selector de servicii, modal de generare AWB și tabel de istoric. Pentru produsul final, direcția logică era păstrarea clarității operaționale într-un dashboard modern, nu copierea vizuală a wp-admin. Din perspectiva operării, proiectarea accepta explicit compromisuri pentru MVP: aplicație read-only, apel sincron către WordPress, fără queue, logging de bază și fără monitorizare avansată. Aceste limite reduc costul și aria de risc în pilot, dar înseamnă că operațiile bulk, idempotency, locking, rate limiting, reconcilierea periodică și observabilitatea ar fi trebuit definite înainte de utilizare la volum mai mare. Pluginul moștenit are propriile verificări de rol administrator/shop_manager și nonce pentru operațiile sensibile, însă endpointul custom documentat nu poate fi considerat securizat până când HMAC-ul, anti-replay-ul și autorizarea pe site/comandă nu sunt implementate și testate.

Plugin WordPress pentru importul în batch al produselor din feed-uri JSON în WooCommerce, actualizare după SKU, imagini și categorii, rescriere OpenAI, progres în admin și automatizare prin endpointuri REST și scripturi cron.

Feed2WooAI este un plugin WordPress construit pentru administrarea unui catalog WooCommerce alimentat din feed-uri externe. Suprafața principală este un panou din WordPress Admin în care administratorul poate adăuga sau elimina URL-uri de feed, porni importul pentru un feed, urmări progresul, căuta produsele importate după ID sau SKU și vedea dacă un produs a fost deja rescris cu AI. Separat există pagini pentru configurarea OpenAI și pentru consultarea logurilor operaționale. Importatorul curent consumă feed-uri JSON și procesează catalogul în batch-uri. Pentru fiecare intrare validă, SKU-ul este cheia de reconciliere cu WooCommerce: un SKU existent este actualizat în loc să fie duplicat, iar un SKU nou creează un WC_Product_Simple publicat. Sunt sincronizate prețul recomandat, stocul, statusul de stoc, categoria, imaginea principală, galeria și câmpurile suplimentare din feed, acestea din urmă fiind persistate ca meta date cu prefix propriu. Categoriile WooCommerce sunt create la nevoie, iar imaginea categoriei poate fi adusă din storage-ul furnizorului atunci când feed-ul include un imageId. Procesarea este controlată prin cozi persistate în WordPress Options API. Coada de import reține feed-ul curent, offsetul, numărul de produse noi, totalul și starea de finalizare, iar interfața AJAX cere succesiv câte un batch și actualizează bara de progres. Importul folosește și un transient de lock pentru a evita două batch-uri simultane. Acest mecanism nu este o coadă distribuită și are limite importante: intrările fără SKU nu avansează offsetul, un lock poate rămâne activ atunci când coada lipsește, iar inițializarea automată din endpointul REST reutilizează handlerul AJAX care cere nonce, ceea ce face cronul REST dependent de o coadă deja inițializată sau de corectarea acestui flux. Rescrierea AI este implementată separat prin OpenAI Chat Completions. Administratorul configurează cheia și template-ul de prompt, iar produsul trimite titlul și descrierea curentă către model. Răspunsul este interpretat în format Titlu/Descriere, apoi numele și descrierea WooCommerce sunt actualizate și produsul primește meta flag-ul _f2wai_ai_rewritten. Rescrierea poate fi pornită pentru toate produsele importate care nu au flag-ul sau individual, direct din tabel. Coada AI procesează câte un produs pe iterație, însă nu are lock propriu, retry limitat sau backoff; dacă o rescriere eșuează, offsetul nu avansează și același produs poate bloca progresul. Imaginile sunt descărcate prin API-urile WordPress Media și atașate produselor. Pentru a reduce costul de procesare, pluginul dezactivează generarea thumbnail-urilor intermediare pe durata sideload-ului și păstrează un cache de URL-uri doar în interiorul batch-ului curent. Codul redenumește fișierele descărcate cu extensia .webp fără conversie efectivă a formatului, deci această zonă trebuie tratată ca o optimizare incompletă, nu ca un pipeline real de conversie media. Automatizarea este pregătită prin două endpointuri REST — import și AI rewrite — protejate cu o cheie salvată în opțiunile WordPress, plus generatoare de scripturi Bash și PowerShell pentru rulare din cPanel sau alt cron extern. Repository-ul conține scripturi Bash configurate pentru un site real, ceea ce confirmă folosirea practică a fluxului, dar acestea includ o cheie REST în clar și trebuie regenerate cu secretul rotit. Endpointurile folosesc cheia în query string și permission_callback public, astfel că securitatea depinde în prezent de acel secret. Pluginul nu definește tabele proprii și folosește structurile native WordPress/WooCommerce: opțiuni pentru configurare și cozi, post meta pentru marcajele și câmpurile importate, taxonomia product_cat pentru categorii și Media Library pentru imagini. Administrarea interactivă folosește jQuery și API-ul AJAX WordPress cu nonce și verificare manage_options pentru operațiile principale. Nu există suită de teste, CI/CD sau workflow-uri GitHub în repository-ul analizat, iar istoricul disponibil este un singur commit de backup pentru portofoliu.

Platformă pentru centralizarea codurilor poștale din România: import Excel în background, normalizarea adreselor, lookup după localitate, stradă și număr, validare prin API și administrarea cheilor de acces.

Zip Code Platform este o aplicație Laravel construită pentru a transforma un fișier operațional de coduri poștale într-o bază de date interogabilă și într-un API reutilizabil de aplicații e-commerce sau alte sisteme care au nevoie de validarea și completarea adreselor. Repository-ul include o suprafață publică simplă, conturi de utilizator, un panou administrativ și API-ul protejat prin chei. Fluxul de date pornește din admin, unde poate fi încărcat un fișier Excel .xlsx/.xls. Controllerul îl salvează local, determină numărul de rânduri și lansează un Laravel Job pe queue-ul configurat în baza de date. Importul citește fișierul în ferestre de câte 500 de rânduri și limitează coloanele procesate la cod poștal, localitate/județ și stradă. Pentru fiecare rând sunt separate localitatea și județul, sunt interpretate sectoarele Bucureștiului și sunt transformate expresiile de numere în intervale sau valori individuale. Scrierea se face în batch-uri, după verificarea combinațiilor deja existente. Progresul este păstrat temporar în Laravel Cache și interfața admin îl interoghează periodic fără a ține request-ul de upload deschis pe toată durata procesării. API-ul expune patru operații dedicate: căutarea codului poștal pornind de la adresă, lista localităților, validarea unui cod poștal și normalizarea unei adrese. Căutarea normalizează diacriticele și abrevierile județelor, încearcă variante ale denumirii străzii și aplică o succesiune de fallback-uri: potrivire cu număr, potrivire pe stradă, potrivire fuzzy și, în final, localitate + județ. Accesul este filtrat de un middleware de API key care verifică existența, starea activă și data de expirare. Panoul administrativ acoperă trei zone principale: coduri poștale, utilizatori și chei API. Tabelele permit filtrare, sortare și paginare, iar administratorul poate genera chei pentru un utilizator, poate seta expirarea și le poate activa sau dezactiva. Utilizatorul autentificat are propriul dashboard pentru datele contului și cheile asociate. UI-ul este server-rendered cu Blade și Tailwind, cu Alpine.js pentru interacțiunile de navigație/modal și JavaScript simplu pentru polling-ul progresului de import. Codul conține și începutul unui flux comercial cu Stripe Checkout, un webhook care ar genera o cheie temporară după checkout și o rută de download pentru un plugin. Aceste zone nu sunt complete în snapshotul analizat: configurația Stripe lipsește din services.php, webhook-ul este plasat în grupul web autentificat, formularul de plată nu apelează ruta de procesare, plățile nu sunt persistate de acest flux, iar arhiva pluginului nu există în repository. Din acest motiv ele sunt tratate ca direcție de produs, nu ca rezultat livrat. Pentru producție, următoarele îmbunătățiri importante sunt hardening-ul API-ului și al importului: validare explicită pentru request-uri, rate limiting per cheie, stocarea hash-uită a cheilor cu afișare o singură dată, parametrizarea completă a fallback-ului fuzzy, constrângeri unique/upsert pentru deduplicare concurentă, indexuri aliniate cu interogările reale și retry/cleanup explicit pentru jobul de import. Repository-ul nu conține workflow-uri CI/CD, Docker sau configurație de deployment reproductibilă; există însă endpointul standard Laravel /up și scripturile locale pentru build, test și worker de queue.

Concept Vue 3 pentru un portal HR self-service: dashboard de angajat, program de lucru pe echipă, calendar de concedii, documente și vizualizări de pontaj, overtime și payroll, într-o interfață responsive personalizată.

TigidalHR este un proiect de studiu orientat spre experiența unui portal HR în care angajații și coordonatorii ar putea vedea într-un singur loc programul, concediile, documentele și indicatorii personali. Implementarea verificată este un prototip frontend Vue 3 + Vite, fără backend sau persistență: datele despre utilizatori, program, concedii, documente și payroll sunt definite local în componente și servesc demonstrației de produs. Dashboard-ul reunește un rezumat al zilelor lucrate, documente și assignment-uri, profilul angajatului, overtime, zile de concediu disponibile și o masă de payroll. O vizualizare separată de schedule folosește Chart.js pentru intervale orare și tratează inclusiv ture care traversează miezul nopții, împărțind vizual intervalul între două zile și adaptând lățimea graficului la fereastra de ore relevantă. Zona Team Schedule modelează o planificare săptămânală pentru mai mulți membri. Datele locale sunt combinate pe angajat și zi, sunt diferențiate turele normale, zilele libere și concediul medical, iar interfața calculează totalul de ore al săptămânii și agregări per angajat pentru săptămâna și luna curentă. Navigarea între săptămâni folosește date-fns cu localizare română. Calendarul de concedii construiește dinamic zilele lunii și proiectează intervalele de leave pentru membrii echipei, marcând începutul și sfârșitul perioadelor continue și evidențiind separat angajatul conectat în scenariul demonstrativ. Pagina de documente oferă paginare locală și stări vizuale precum Sent, Pending, Ready și Rejected; butonul de adăugare emite un eveniment, însă fluxul de creare nu este conectat la persistență. Accesul are un ecran dedicat de login și un al doilea pas cu un cod de șase cifre, dar validarea este hardcodată în browser și rutele nu au guard-uri de autentificare. Este deci o demonstrație de UX pentru autentificare în doi pași, nu o implementare de securitate sau 2FA. În mod similar, payroll-ul și valorile financiare sunt conținut demonstrativ și nu rezultatul unui motor de salarizare. Interfața pornește de la Argon Dashboard 2 de la Creative Tim, lucru confirmat de README, package metadata și fișierele originale păstrate în repository. Personalizarea se vede în aplicația separată my-vue-project: structură Vue, routing lazy-loaded, componente HR, logo Tigidal, fonturi și paletă proprie navy/albastru-gri, carduri translucide și layout-uri adaptate pentru ecrane înguste. Vite este configurat pentru gzip și manual chunking al dependențelor. Repository-ul este un snapshot de portofoliu cu un singur commit de backup, deci istoricul Git nu poate demonstra evoluția incrementală sau separa contribuțiile pe commituri. Nu există modele, migrări, controllere, servicii, queue workers, webhooks, audit/GDPR, upload real de documente sau CI de build/test pentru aplicația Vue. Scopul final care reiese din UI este un portal HR self-service și de workforce management; aceste capabilități lipsă sunt tratate ca direcție de produs, nu ca funcționalități deja construite.

Platformă pentru fotografi și organizatori care centralizează sesiunile foto, upload-ul și procesarea imaginilor și oferă clienților galerii accesibile prin cod unic, cu parolă opțională și download individual sau ZIP.

Photo Archive este o aplicație web construită pentru livrarea controlată a fotografiilor de eveniment către clienți. Administratorul creează câte o sesiune cu nume, descriere și dată de eveniment, iar backend-ul generează un cod unic de opt caractere. Sesiunea poate fi activată sau dezactivată și poate primi o parolă suplimentară, stocată ca hash bcrypt. Interfața administrativă afișează numărul de fotografii, volumul stocat și accesările înregistrate și permite copierea codului sau deschiderea directă a galeriei. Upload-ul este realizat prin Multer cu stocare directă pe disk. Pentru fiecare imagine acceptată, Sharp validează formatul și dimensiunile, citește metadatele tehnice de bază și generează două versiuni derivate: thumbnail pătrat de 300 × 300 pentru listare și imagine de galerie de maximum 1200 × 1200, JPEG progresiv la calitate 85. Originalul este păstrat separat, iar MySQL persistă numele inițial, căile fișierelor, dimensiunea, rezoluția și momentul upload-ului. Procesarea este făcută secvențial în requestul de upload; codul nu introduce queue workers sau batching asincron separat. Clientul ajunge în galerie folosind codul primit de la fotograf sau organizator. Pagina citește informațiile sesiunii, solicită parola atunci când sesiunea este protejată și încarcă fotografiile paginat, câte 20. Galeria oferă mod grid sau listă, căutare după numele fișierului, preview într-un modal și download al originalului. O rută separată construiește on-demand o arhivă ZIP cu toate originalele folosind archiver și stream-uiește răspunsul către browser. Accesările publice sunt înregistrate cu IP și user-agent, iar aceeași combinație sesiune/IP nu este relogată în mod normal mai des de o dată pe oră pe rutele principale de galerie. Frontend-ul este un SPA React 19 + Vite 7 + Tailwind CSS 4, cu o identitate vizuală light bazată pe gradient albastru–indigo–mov, carduri albe translucide și iconografie Lucide. Backend-ul Express rulează separat pe Node.js, folosește pool MySQL, JWT pentru administrare și un flux client separat disponibil la nivel API, iar deployment-ul documentat folosește PM2 și Nginx pe un VPS HestiaCP. Repository-ul nu conține GitHub Actions și nici o suită automată de teste; există doar un script utilitar pentru verificarea limitelor de upload. Din perspectiva hardening-ului, codul analizat are câteva probleme care trebuie tratate înainte de a prezenta platforma ca depozit privat de fotografii: rate limiting este dezactivat în server, există fallback-uri pentru secretul JWT și parola admin, iar repository-ul conține materiale TLS care nu ar trebui versionate. În plus, protecția cu parolă a sesiunii este aplicată pe endpointul paginat principal, dar nu este verificată consecvent pe toate endpoint-urile publice de fotografie/căutare/recent/download. Seed-ul prezintă funcționalitatea reală fără a transforma aceste mecanisme într-o afirmație de securitate completă.

Aplicație React + Express care centralizează date de time tracking importate, completează ore manuale, aplică reguli de raportare și generează filtre, grafice, rapoarte de ore și calcule de facturare pe grupuri de proiecte.

Time Tracker este un proiect personal construit ca instrument intern de analiză peste date de time tracking deja colectate. Frontend-ul React 19 încarcă prin API setul principal de intrări și un set separat de ore suplimentare, le combină cronologic și calculează statistici pe proiect, limbaj și zi. Dacă API-ul nu este disponibil, citirea are fallback către fișierele JSON statice incluse în aplicație. Pipeline-ul de raportare nu folosește doar timpul brut. Pentru fiecare proiect, cu excepția intrărilor marcate Unknown Project, utilitarul de calcul adaugă un overhead fix de 50% pentru testare/procesare și îl distribuie între intrările proiectului, păstrând separat timpul original și timpul adăugat. Proiectele configurate ca excluse sunt apoi eliminate din statistici și rapoarte. Aceasta este o regulă explicită a snapshotului analizat, nu un model configurabil din UI. Dashboard-ul oferă filtre rapide pentru ziua curentă, săptămână, lună, luna anterioară, ultimele 7 sau 30 de zile, interval custom, proiecte, limbaje și căutare text. Datele filtrate pot fi exportate CSV. Recharts este folosit pentru topul proiectelor, distribuția pe limbaje și activitatea zilnică, iar o componentă tabelară cu sortare și paginare există în cod, deși este dezactivată în ecranul principal. Pentru raportare financiară, proiectele pot fi grupate și asociate cu un tarif orar. Raportul de grup identifică intrările proiectelor, calculează orele și valoarea rezultată, apoi cere cursul EUR de la BNR prin backend pentru o conversie orientativă în RON. Atât raportul de facturare pe grupuri, cât și raportul de ore au layout-uri dedicate pentru printare. Zona administrativă include adăugare manuală de intrări, CRUD pentru grupuri de proiecte, import JSON în masă care înlocuiește dataset-ul principal, administrarea proiectelor excluse și editarea sau ștergerea orelor suplimentare. O parte dintre aceste operații sunt accesate prin shortcut-uri de tastatură, ca interfață internă, nu ca admin separat cu autorizare pe roluri. Backend-ul Express persistă datele direct în fișiere JSON din public/, fără ORM sau bază de date. Autentificarea folosește JWT cu expirare la 24 de ore și un registru in-memory pentru tokenurile active. Deployment-ul este pregătit pentru un singur proces PM2 cu restart automat și loguri pe fișiere. PWA-ul este configurat prin vite-plugin-pwa cu auto-update și cache pentru resurse statice/fonturi, dar codul nu implementează Background Sync sau o coadă de scrieri offline. Snapshotul trebuie tratat ca tool personal/prototip operațional, nu ca produs multi-user hardenat. O extindere către utilizare multi-user ar necesita hardening suplimentar pentru stocarea credentialelor, autorizare per rol și resursă, persistență concurentă/atomică și validare automată prin teste și CI/CD.

Prototip Laravel 12 + Livewire pentru o platformă personală de management al colaborărilor, cu autentificare, roluri admin/client, CRUD reactiv de clienți și structură pregătită pentru proiecte, taskuri și facturi.

Project Management este un proiect personal construit ca bază pentru centralizarea relației cu clienții și, în direcția sugerată de interfață, pentru legarea ulterioară a clienților de proiecte, taskuri și facturi. Starea actuală a repository-ului este însă una de prototip parțial: modulul Clients este funcțional, iar paginile Projects, Tasks și Invoices sunt doar ecrane placeholder accesibile administratorului. Aplicația folosește Laravel 12 pe PHP 8.2+, Livewire 3 și Livewire Volt, cu Blade și Tailwind CSS pentru interfață. Pentru interacțiunile de business nu există un framework JavaScript separat: componenta Livewire Clients păstrează starea formularului, căutării, modului de editare și paginării, validează datele pe server și persistă direct prin Eloquent. Căutarea filtrează după nume, companie, email sau telefon, iar rezultatele sunt ordonate descrescător după creare și paginate câte 10. Modelul Client și migrarea aferentă acoperă date personale și de companie: nume, firmă, CUI, registrul comerțului, adresă, oraș, țară, telefon, email, persoană de contact și notițe. UI-ul actual expune majoritatea acestor câmpuri într-un modal de creare/editare. Există însă o problemă funcțională în fluxul de creare: componenta pornește hasCompany pe false și curăță câmpurile companiei înainte de save, dar formularul nu oferă un control care să activeze hasCompany. Ca urmare, datele de firmă introduse pentru un client nou nu sunt păstrate în forma actuală. Câmpul country există în model și DB, dar nu este expus în componentă. Autentificarea și zona de profil provin în mare parte din scaffolding-ul Laravel Breeze/Livewire Volt și includ login, logout, resetare parolă, confirmare parolă și actualizarea/ștergerea profilului. Login-ul are rate limiting la cinci încercări pe cheia email + IP. Aplicația definește două roluri, admin și client, printr-un câmp role pe users și două Gate-uri Laravel. Rutele Clients, Projects, Tasks și Invoices sunt protejate de auth + can:admin; rolul client este definit, dar nu are încă un flux propriu în produs. Migrarea setează implicit rolul admin, ceea ce trebuie revizuit înaintea unei eventuale înregistrări publice. Frontend-ul este un dashboard desktop-first cu sidebar fix, header sticky, carduri albe pe fundal gri și identitate vizuală indigo. Logo-ul propriu folosește #6366F1 și #A5B4FC și reprezintă schematic un panou de lucru. Pagina de start descrie aplicația drept o platformă personală pentru gestionarea proiectelor și colaborare cu clienții, iar dashboard-ul indică direcția clienți → proiecte → taskuri → facturi. Aceste texte susțin scopul final, dar nu sunt dovadă că modulele lipsă sunt implementate. Persistența implicită din .env.example este SQLite. Sesiunile, cache-ul și queue-ul sunt configurate pe driver database, iar scriptul Composer de development pornește serverul Laravel, un queue listener, Pail și Vite în paralel. Nu există însă joburi custom, events de business, webhook-uri, integrări externe, uploaduri, căutare dedicată, notificări de proiect, comentarii, board Kanban, audit trail sau relații project/task/invoice în schema actuală. Mailer-ul implicit este log, deci repository-ul nu demonstrează livrare email printr-un furnizor extern. Lista de clienți este paginată, însă căutarea folosește LIKE cu wildcard pe patru coloane și tabela clients nu definește indexuri suplimentare. Nu există cache de business, batching, locking sau idempotency custom. Ștergerea clientului este hard delete și nu există soft delete, relații care să blocheze ștergerea, audit sau confirmare explicită în codul componentei. Repository-ul nu conține .github/workflows, Docker/Compose, scripturi de deploy sau configurație Nginx/PM2/Supervisor. Laravel expune health endpoint-ul standard /up, iar pachetele includ Laravel Sail ca dependență de development, fără fișiere Docker versionate. Testele prezente acoperă în principal scaffolding-ul de autentificare și profil; nu există teste pentru Clients sau pentru autorizarea modulelor custom. RegistrationTest încă așteaptă ruta /register, deși routes/auth.php nu o mai definește, deci suita salvată nu este complet aliniată cu rutele curente. Istoricul Git disponibil conține un singur commit, „Initial commit — portfolio backup", care introduce întregul repository. Din acest motiv contribuția poate fi descrisă prin codul custom existent — modulul Clients, modelul și migrarea Client, rolurile și Gate-urile, shell-ul dashboard și paginile de direcție — dar istoricul nu permite demonstrarea unei evoluții feature-by-feature sau atribuirea întregului scaffolding Laravel ca implementare de la zero.

Website React pentru un service auto din Brașov, cu pagini dedicate serviciilor și daunelor RCA/CASCO, portofoliu before/after, blog, FAQ, recenzii, formulare de contact și infrastructură SEO locală.

CarFix Paint Site este un website multi-rută orientat spre prezentarea serviciilor unui service auto și transformarea vizitatorilor în contacte. Aplicația acoperă servicii de tinichigerie, vopsitorie, mecanică, diagnoză și gestionare daune, iar homepage-ul combină hero cu CTA-uri, beneficii, procesul de daună, lucrări, recenzii și un CTA final. Experiența publică este construită ca SPA React 19 cu React Router. Sunt implementate rute dedicate pentru Acasă, Servicii, Daune RCA/CASCO, Portofoliu și detalii de proiect, Despre, Recenzii, FAQ, Blog și detalii de articol, Contact, plus pagini legale. Header-ul responsive include navigație desktop și drawer mobil, iar Framer Motion este folosit pentru apariții, hover states și micro-interacțiuni. Conversia este susținută de click-to-call, buton WhatsApp persistent cu mesaj precompletat, bară de apel fixă pe mobil și formular de contact cu acord GDPR. În snapshotul analizat formularul nu trimite date către un server: cererile sunt serializate în localStorage prin hook-ul propriu useKV, deci funcționează ca prototip de flux, nu ca sistem de lead management centralizat. Conținutul principal este modelat tipizat în TypeScript și păstrat în data.ts: servicii, proiecte before/after, FAQ, recenzii și articole de blog. Există și un panou /admin pentru CRUD de bloguri, proiecte și testimoniale, însă acesta este un editor local fără autentificare; datele sunt persistate doar în browser și paginile publice continuă să citească dataset-ul static. De aceea este tratat ca prototip de CMS, nu ca CMS de producție. Pentru SEO local, componenta SEOHead actualizează title, description, keywords, canonical, Open Graph, Twitter Cards, robots și meta geo în funcție de rută, iar StructuredData injectează JSON-LD pentru tipuri precum AutoRepair, FAQPage, Review, BlogPosting, Service și ContactPage. Implementarea este client-side și repository-ul curent nu conține sitemap.xml sau robots.txt, deci infrastructura SEO este funcțională la nivel de SPA, dar nu echivalează cu metadata server-rendered. UI-ul urmează o direcție premium auto workshop: antracit, alb și accent roșu, fonturi Outfit și Inter, carduri responsive și componente Radix UI. Portofoliul și blogul au pagini de detaliu, inclusiv fallback pentru ID-uri inexistente. Imaginile și conținutul demonstrativ sunt în mare parte statice; afirmațiile comerciale și metricile din copy nu sunt folosite ca rezultate verificabile în acest case study. Istoricul Git arată explicit caracterul AI-assisted al construcției: primul site a fost generat și iterat prin GitHub Spark, apoi au fost adăugate rutele și SEO-ul per pagină, remediate imagini și pagini de detaliu și introdus panoul admin. Refactorizarea finală a eliminat dependențele și configurarea Spark, a introdus hook-ul local useKV și a lăsat proiectul ca aplicație Vite independentă. O documentație ulterioară pregătește direcția de producție: migrare la Next.js App Router, Payload CMS, PostgreSQL, media persistence, autentificare reală pentru admin și stocarea cererilor în backend. Aceasta reprezintă etapa următoare intenționată, nu starea actuală a codului.

Prezență digitală premium pentru o florărie din zona Brașov: site responsive cu portofoliu floral, servicii, blog, giveaway-uri și administrare completă prin Payload CMS integrat direct în Next.js.

Flower Power este un proiect pentru un client real construit ca aplicație Next.js monolitică, în care site-ul public, panoul de administrare Payload CMS și API-urile rulează în același codebase. Scopul produsului este prezentarea vizuală a creațiilor florale și transformarea conținutului care s-ar modifica manual într-un flux administrabil: servicii, galerie, articole, giveaway-uri, hero și informații generale ale florăriei. Frontendul folosește App Router și separă suprafața publică de rutele Payload. Conținutul important este încărcat server-side prin Payload Local API, iar componentele interactive rămân client-side doar acolo unde este nevoie: caruselul hero, meniul mobil, filtrarea galeriei, lightbox-ul și formularele. Designul are un sistem vizual propriu bazat pe verde petrol închis, accente aurii și fundal crem, cu Playfair Display pentru titluri, Inter pentru text și Cormorant Garamond pentru accente editoriale. Hero-ul full-screen combină imagini reale, tranziții fade și efect Ken Burns și respectă prefers-reduced-motion. Payload CMS gestionează utilizatorii de admin, media, articolele de blog, serviciile, galeria, giveaway-urile și înscrierile la acestea, plus globale pentru setările site-ului, hero și pagina Despre. Media poate fi citită public pentru randarea site-ului, în timp ce înscrierile la giveaway sunt vizibile și modificabile doar utilizatorilor autentificați din CMS. Galerie publică este organizată pe categorii și folosește un masonry grid cu lightbox; repository-ul include un set curatat de fotografii reale pentru buchete, aranjamente, nunți și botezuri, decoruri, cadouri și colecții sezoniere. Fluxul de giveaway este unul dintre puținele fluxuri cu persistență operațională: pagina publică trimite numele, emailul și telefonul către un endpoint Next.js, acesta rezolvă giveaway-ul după slug, verifică dacă aceeași adresă de email este deja înscrisă la aceeași campanie și persistă participarea în Payload împreună cu momentul și IP-ul raportat de infrastructură. Duplicarea este prevenită la nivel de aplicație prin verificare înainte de create, însă nu există o constrângere unică de bază de date sau locking, deci implementarea nu revendică idempotency strictă în concurență. Formularul de contact validează câmpurile obligatorii și formatul emailului și poate trimite mesajele prin Resend către adresa configurată în CMS. Trimiterea emailului este intenționat non-blocking pentru răspunsul API: dacă providerul nu este configurat sau trimiterea eșuează, eroarea este logată și endpoint-ul răspunde în continuare cu succes. Codul nu persistă mesajele de contact și nu include rate limiting, CAPTCHA sau coadă de retry, aspecte care ar trebui întărite înaintea unui trafic public ridicat. SEO-ul este tratat la nivel de aplicație prin metadata per pagină, canonical URLs, sitemap dinamic pentru blog și giveaway-uri, robots și JSON-LD pentru florist și articole. Există și un health endpoint. Suita Playwright acoperă navigarea, formularele și experiența mobilă, dar unele aserțiuni și slugs din teste au rămas în urma ultimelor modificări de UI/CMS, astfel că prezența testelor nu este prezentată ca dovadă că build-ul curent este verde. Din perspectiva securității, aplicația setează headere precum X-Frame-Options, X-Content-Type-Options, Referrer-Policy și Permissions-Policy și protejează citirea/modificarea înscrierilor în CMS prin autentificare. În același timp, configurația are un fallback hardcodat pentru PAYLOAD_SECRET, SQLite este fallback-ul implicit, endpoint-urile publice nu au rate limiting, iar datele personale din formulare necesită o politică explicită de retenție și logging pentru producție. Acestea sunt limitări identificate din cod, nu funcționalități mascate în prezentarea proiectului. Istoricul Git arată că repository-ul a pornit din boilerplate create-next-app, apoi a primit paginile și designul custom, SEO și imaginile reale, formularele, auditul de contrast și responsive, testele E2E, caruselul cinematic și în final integrarea Payload/Resend. Dependențe și fișiere Sanity au rămas ca reziduu al unei etape anterioare, în timp ce traseele curente de conținut folosesc Payload. Proiectul este așadar mai apropiat de un website operațional cu CMS și campanii decât de un CRUD simplu sau de un e-commerce.

Discovery tehnic pentru migrarea unui magazin Avanticart în WooCommerce: inventarierea modelului de date, maparea produselor și variațiilor, analiza prețurilor și relațiilor și utilitare PHP pentru verificarea imaginilor din CDN.

Proiectul surprinde etapa de analiză și pregătire a unei migrări reale din Avanticart către WooCommerce. Snapshot-ul documentat al bazei sursă include un catalog cu produse părinte și variații, prețuri regular/sale, categorii ierarhice, producători, atribute, clienți, adrese, comenzi, istoric de status și review-uri. Repository-ul păstrat pentru portofoliu nu include dump-urile SQL, astfel încât aceste volume sunt cele documentate în analiza realizată pe backup, nu valori recalculate din repository. Partea centrală a lucrării este mapping-ul semantic dintre modelul Avanticart și ținta WooCommerce. Produsele părinte și variațiile sunt separate prin product_parent_id, mărimea și culoarea sunt identificate ca atribute candidate pentru variații, celelalte atribute rămân metadata de produs, iar producătorii sunt proiectați către o taxonomie de brand. Analiza urmărește și prețurile publice, stocul, SKU-urile, categoriile multiple, descrierile și SEO slugs, astfel încât ordinea de import propusă să respecte dependențele dintre date. O zonă care a necesitat investigație separată a fost media. Avanticart păstra referințe de imagini în baza de date, în timp ce fișierele erau servite din CDN. Un script PHP testează formate de URL pe un subset de imagini, iar un al doilea utilitar oferă o interfață web de inspecție cu paginare și filtre. Acesta grupează imaginile pe produs și, pentru variațiile fără imagini proprii, face un al doilea query bulk pentru părinții necesari și atașează galeria părintelui. Pattern-ul documentat și folosit în viewer este bazat pe seo_name, picture_id și sufixul CDN "-2.webp". Viewer-ul este un instrument intern, nu un frontend de magazin: PHP randat server-side, HTML/CSS inline și puțin JavaScript pentru marcarea imaginilor care nu se încarcă. Filtrele sunt GET, pagina este convertită explicit la integer, iar output-ul textual principal este escap-at cu htmlspecialchars. În schimb, nu există autentificare, observabilitate, retry/backoff sau un strat de servicii; erorile de conectare la DB sunt afișate direct, iar URL-ul imaginii include date provenite din baza legacy fără escaping HTML explicit. Din punct de vedere al performanței, codul evită un N+1 evident pentru moștenirea imaginilor: parent IDs sunt colectate și imaginile părinților sunt încărcate într-un singur query IN. Totuși, query-ul principal aplică LIMIT/OFFSET peste join-ul produs-imagine, nu peste lista de produse distincte. În consecință, numărul de carduri pe pagină poate varia, iar galeria unui produs poate fi tăiată între pagini. O implementare de producție ar pagina întâi ID-urile produselor, apoi ar încărca relațiile pentru acel set. Documentația propune fazele următoare — configurarea WooCommerce, importul master data, produse, media, variații și opțional clienți/comenzi, plus review-uri — dar repository-ul analizat nu conține scripturile finale de import, joburi, reconciliere automată, redirects sau deployment. Din acest motiv, proiectul este prezentat ca analiză tehnică și prototip de validare care reduce riscul unei migrări complexe, nu ca o migrare finalizată.

Aplicație Laravel + Livewire pentru administrarea stocului unei florării, cu produse, cantități, furnizor, cost și preț de vânzare, profit unitar, termene de expirare, imagini și operații CRUD într-o interfață reactivă.

ERP Florărie este un proiect de studiu construit ca bază pentru digitalizarea operațiunilor interne ale unei florării. Snapshotul analizat nu reprezintă încă un ERP complet: partea implementată este un modul coerent de catalog și stoc, în care un utilizator autentificat poate căuta, sorta, adăuga, modifica și șterge produse din aceeași interfață Livewire. Modelul FlowerProduct păstrează numele, descrierea, categoria, cantitatea, costul de achiziție, prețul de vânzare, data intrării în stoc, data expirării, furnizorul ca atribut text, imaginea și starea activ/inactiv. Eloquent aplică tipuri pentru date, booleeni și prețuri, iar modelul include metode pentru verificarea stocului, expirării și calculul profitului unitar. În interfața curentă este afișat direct profitul ca diferență dintre prețul de vânzare și costul de achiziție. Fluxul principal este implementat într-o componentă Livewire clasică, FlowerProductsTable. Căutarea este executată în baza de date după nume, categorie sau furnizor, rezultatele sunt paginate câte 10 și pot fi sortate după coloanele principale. Formularele de adăugare și editare validează câmpurile înainte de persistare, iar imaginile sunt validate ca fișiere image de maximum 1 MB și sunt salvate pe discul public. La înlocuirea sau ștergerea unui produs, aplicația elimină și imaginea veche atunci când aceasta există. Frontend-ul folosește Blade, Livewire și Tailwind CSS, cu layout responsive, modale pentru CRUD, navigație desktop/mobile și dark mode păstrat în localStorage. Interacțiunile Livewire elimină nevoia unui SPA separat: starea formularului, căutarea, sortarea și paginarea sunt gestionate server-side, iar Alpine este folosit în componentele de interfață și pentru comportamente precum meniurile și tema. Autentificarea și profilul provin în mare parte din scaffolding-ul Laravel Breeze + Livewire Volt: înregistrare, login, resetare parolă, verificare email, actualizare profil și logout. Login-ul este protejat prin rate limiting, însă modulul Flower Products cere doar autentificare, nu email verificat. Repository-ul nu definește roluri, policies sau ownership la nivel de produs, astfel încât orice cont autentificat poate opera asupra întregului catalog. Pentru un deployment public, înregistrarea liberă și lipsa autorizării granulare ar trebui restrânse. Din punct de vedere al datelor, aplicația pornește implicit pe SQLite și are o singură tabelă de domeniu pentru flower_products, fără relații către tabele separate de furnizori, comenzi sau rețete. Nu există indexuri dedicate pentru câmpurile de căutare/sortare, constrângeri pentru duplicate, tranzacții în fluxurile CRUD, locking sau mecanisme de audit. Paginarea limitează volumul transferat către UI, iar modelul simplu evită probleme N+1 în forma actuală, dar căutările cu wildcard și lipsa indexurilor ar trebui revizuite înaintea unui volum mare de date. Configurația Laravel include infrastructură standard pentru queue, cache, mail și S3, însă repository-ul nu conține joburi, workers de business, integrare cloud activă, webhook-uri, plăți, SMS, analytics, AI sau API-uri externe. Există un health endpoint Laravel la /up și o comandă Artisan custom care creează symlink-ul de storage și directorul public pentru imaginile produselor. Istoricul Git disponibil conține un singur commit de tip portfolio backup, deci nu oferă o cronologie suficientă pentru a demonstra cine a implementat fiecare etapă sau dacă proiectul a fost greenfield. Ce poate fi separat clar în snapshot este scaffolding-ul Laravel/Breeze/Volt de logica de domeniu personalizată: modelul și migrarea FlowerProduct, componenta Livewire și tabelul de administrare, seed-ul de produse, ruta dedicată, integrarea în navigație și comanda pentru storage. Draftul legacy descria o țintă mai amplă de ERP cu comenzi, furnizori, rapoarte și alerte de expirare; acestea sunt tratate doar ca direcție de evoluție, nu ca funcții implementate.

Mini-CMS construit cu Laravel, Inertia și Vue pentru crearea paginilor din blocuri configurabile, ordonare drag-and-drop, upload de imagini și randare publică optimizată prin cache și încărcare lazy a secțiunilor.

CMS Sections este un proiect personal de studiu construit ca un page builder compact peste Laravel 12, Inertia.js 2 și Vue 3. În locul unui model rigid de pagină, conținutul este compus din secțiuni ordonate, fiecare având un tip și un payload JSON. Un registry TypeScript definește schema de editare pentru fiecare tip, iar aceeași cheie de tip este folosită de frontendul public pentru alegerea componentei Vue corespunzătoare. Editorul permite crearea paginilor cu titlu și slug unic, marcarea unei singure pagini ca home, adăugarea secțiunilor dintr-un catalog, editarea conținutului într-un modal și reordonarea prin drag-and-drop. Registry-ul confirmă 11 tipuri de secțiuni: hero, carousel, features, testimonials, team, pricing, FAQ, CTA, statistics, gallery și contact. Câmpurile pot fi text, textarea, imagine sau repeatere recursive, ceea ce permite structuri precum slide-uri, planuri de preț, membri de echipă, întrebări FAQ și galerii fără câte un formular hardcodat separat pentru fiecare secțiune. Persistența folosește două entități principale: Page și PageSection. Page păstrează metadata de bază, iar PageSection leagă pagina de tipul secțiunii, ordinea ei și conținutul JSON. La salvare, actualizarea paginii și înlocuirea setului de secțiuni sunt executate într-o tranzacție, astfel încât structura paginii să nu rămână parțial actualizată dacă apare o excepție. Este o abordare simplă și potrivită pentru un proiect de studiu, cu compromisul că secțiunile sunt recreate la fiecare salvare și nu există istoric de versiuni sau optimistic locking. Media este gestionată printr-un endpoint autentificat de upload. Imaginile sunt validate ca fișiere image de maximum 2 MB, primesc nume randomizate și sunt salvate pe disk-ul public Laravel; URL-ul rezultat este injectat în conținutul secțiunii. Acest flux este folosit inclusiv în câmpurile nested din repeatere. Frontendul public rezolvă pagina home sau pagina după slug și cache-uiește payload-ul pregătit timp de 10 minute. Cache-ul este invalidat explicit după editare și poate fi curățat manual din zona de administrare. Hero-ul este încărcat eager, iar celelalte componente de secțiune folosesc defineAsyncComponent și IntersectionObserver pentru a fi montate când se apropie de viewport. Galeria include lightbox și navigare din tastatură, carousel-ul și testimonials au autoplay, iar componentele publice folosesc layout responsive și stiluri Tailwind. Autentificarea provine în mare parte din Laravel Breeze: register, login, resetare parolă, verificare email și profil. Funcționalitatea CMS personalizată se află în modelele Page/PageSection, controllerele de pagini și upload, registry-ul de secțiuni, editorul Vue, componentele publice și logica de cache/randare. Scope-ul repository-ului rămâne de prototip/studiu. Nu există versionare de conținut, status draft/published pe pagini, preview separat de pagina live, management SEO, policies/roluri editoriale sau pipeline CI/CD. Formularul din secțiunea Contact simulează submit-ul doar în browser, iar harta este un placeholder pentru o integrare Maps neconfigurată. Din acest motiv proiectul este prezentat ca un page builder funcțional și extensibil, nu ca un CMS production-ready.

Aplicație Laravel + Livewire care combină un constructor de mese cu valori calorice și macronutrienți, obiective și jurnal personal, grupuri recurente și o suită de calculatoare pentru BMR/TDEE, greutate, compoziție corporală, proteine și calorii arse.

Calculator Calorii este o aplicație web de nutriție care merge dincolo de o formulă izolată. Suprafața principală permite căutarea alimentelor, alegerea metodei de preparare, introducerea cantității și calcularea valorilor de calorii, proteine, carbohidrați și grăsimi proporțional cu porția. Utilizatorii neautentificați pot compune temporar o masă, iar conturile verificate pot salva mesele, pot crea alimente proprii și le pot organiza în grupuri. Modelul de date separă alimentul de metodele sale de preparare, deoarece aceeași materie primă poate avea valori diferite în funcție de modul de gătire. Meal și MealItem păstrează jurnalul alimentar, MealGroup organizează mesele și poate defini repetare săptămânală sau lunară, iar CalorieGoal păstrează obiectivul activ pentru perioade zilnice, săptămânale sau lunare. Valorile nutriționale sunt calculate din cantitate raportată la 100 g, iar dashboard-ul agregă mesele pe perioade și include logică pentru a proiecta virtual grupurile recurente fără a materializa copii ale meselor în baza de date. Aplicația include pagini distincte pentru slăbit, creștere în greutate, grăsime corporală, greutate ideală, proteine, macronutrienți și calorii arse. BMR-ul folosește formula Mifflin–St Jeor, TDEE aplică multiplicatori de activitate, iar calculatorul de calorii arse folosește valori MET și formula bazată pe greutate și durată. Modul de distanță estimează timpul din distanță și viteză și interpolează valoarea MET pentru mers, alergare sau ciclism. Calculatorul de grăsime corporală folosește formula US Navy și oferă suplimentar BMI și masă slabă, iar cel de greutate ideală compară formulele Robinson, Miller, Devine și Hamwi. Interfața este server-driven prin Livewire 3, cu Blade pentru markup, Alpine.js pentru interacțiuni locale și Tailwind CSS pentru layout responsive și dark mode. Calculatorul principal are o structură în două coloane pe desktop și un slide-over pentru sumarul mesei pe mobil. Căutarea alimentelor este debounced, rezultatele sunt limitate, există quick-add și selectarea automată a metodei implicite pe categorie. Sumarul mesei poate fi randat într-un layout dedicat și exportat local ca PNG prin html2canvas încărcat la cerere. Conturile folosesc autentificarea Laravel, verificare de email prin URL semnat și resetare de parolă. Un middleware separat blochează utilizatorii dezactivați, iar zona admin este protejată prin flag-ul is_admin. Administratorul poate gestiona catalogul de alimente și categorii, metodele de preparare, utilizatorii, articolele de blog și setările SEO. Layout-ul citește metadatele per pagină din baza de date și poate activa Google Analytics atunci când un ID este configurat. Persistența folosește MySQL și relații Eloquent cu foreign keys și cascade acolo unde modelul de domeniu o cere. Lista de mese este paginată și încarcă relațiile nutriționale folosite în UI. Pentru căutarea alimentelor se folosește LIKE cu wildcard la început și inRandomOrder pentru quick-add, iar agregarea grupurilor recurente iterează datele în PHP; acestea sunt suficiente pentru dimensiunea aplicației din snapshot, dar ar necesita strategie de căutare/indexare și preagregare dacă volumul ar crește semnificativ. Snapshotul include și infrastructură de operare legacy: manifest cPanel, health endpoint Laravel și endpointuri pentru webhook GitHub / execuție administrativă. Nu există GitHub Actions, Docker sau o suită de teste pentru formulele nutriționale; testele prezente acoperă în principal scaffolding-ul de autentificare și profil. Auditul a identificat și configurații sensibile comise în repository, rute de debug accesibile public și câteva verificări de ownership incomplete. Aceste elemente nu sunt prezentate ca avantaje ale produsului și trebuie hardenate înaintea unei reutilizări de producție.

Utilitar desktop Python care verifică periodic un endpoint, descarcă documente PDF, păstrează local istoricul și starea lor și le trimite automat sau manual către imprimante Windows prin SumatraPDF.

PDF Auto-Print este o aplicație desktop pentru un flux operațional în care documentele PDF publicate de un endpoint trebuie preluate și tipărite pe un PC Windows fără verificare manuală repetitivă. Interfața PyQt5 centralizează adresa endpointului, intervalul de verificare, imprimanta selectată și folderul local de descărcare, iar aceste setări sunt persistate într-un fișier JSON. Fluxul automat pornește un QTimer cu interval configurabil între 10 și 3600 de secunde. La fiecare ciclu, aplicația face un request POST către endpoint, tratează răspunsul ca listă JSON de URL-uri, descarcă documentele în folderul configurat și înregistrează fiecare URL în SQLite. Tabela locală păstrează URL-ul unic, calea fișierului, momentul descărcării, statusul de print și momentul imprimării. Imprimarea este realizată secvențial prin SumatraPDF în mod command-line, folosind -print-to pentru imprimanta aleasă și setarea fit. Lista imprimantelor este citită din Windows prin pywin32, incluzând imprimante locale și conexiuni, iar aplicația poate deschide direct coada sistemului pentru imprimanta curentă. Idempotency-ul este parțial și explicit la nivel de stare: URL-ul are constrângere UNIQUE, inserarea folosește INSERT OR IGNORE, iar numai rândurile cu printed=0 intră în fluxul automat de print. Dacă imprimarea eșuează, rândul rămâne neprintat și va fi încercat din nou la un ciclu ulterior. Nu există însă un job queue separat, backoff, limită de retry sau contor de încercări, iar PDF-urile sunt descărcate din nou înainte de deduplicarea din bază. Pe lângă automatizare, UI-ul oferă un flux manual: listarea documentelor disponibile la endpoint, descărcarea și imprimarea lor cu progres vizibil, căutare după numele fișierului, selectarea rândurilor, reprintarea documentelor neprintate, schimbarea manuală a statusului, copiere din tabel și ștergerea sincronizată a fișierului local și a înregistrării din SQLite. La pornire, aplicația reconciliază baza locală cu discul și elimină intrările ale căror fișiere nu mai există. Opțional, poate crea sau elimina un shortcut în folderul Windows Startup, astfel încât utilitarul să pornească odată cu sesiunea utilizatorului. Repository-ul include și un spec PyInstaller pentru build windowed, plus un endpoint PHP minimal folosit pentru testarea listării de PDF-uri. Snapshotul analizat este funcțional ca utilitar desktop local, dar nu este hardenat ca agent enterprise. Endpointul configurat în repository folosește HTTP, nu există autentificare sau semnare a răspunsului, requests nu setează timeout, tipul și dimensiunea fișierelor descărcate nu sunt validate, iar page_size și orientation există în config fără să fie aplicate la comanda de print. De asemenea, două URL-uri diferite cu același nume de fișier pot indica aceeași cale locală.

Tool operațional WordPress pentru găsirea și actualizarea în masă a paginilor localizate, cu suport Elementor/Gutenberg/Classic, rescriere prin Gemini și generare de imagini prin Vertex AI Imagen.

Page Content Extractor este un plugin WordPress construit pentru administrarea unui set de pagini de servicii care urmează convenții de slug și includ variații geografice. În loc ca fiecare pagină să fie deschisă și modificată manual, administratorul introduce un pattern de slug și un fragment de text sau un nume de imagine, iar pluginul identifică paginile relevante și extrage localitatea din slug pentru operațiile ulterioare. Fluxul de text detectează editorul folosit de fiecare pagină — Elementor, Gutenberg sau editorul clasic — și caută conținutul printr-o normalizare word-by-word care elimină diferențele de HTML, spațiere și capitalizare. Algoritmul recunoaște și placeholder-e de tip {{localitate}}, iar pentru Gutenberg parcurge recursiv blocurile. Paginile cu match sunt prezentate ca carduri în admin, împreună cu tipul editorului și localitatea extrasă. Pentru localizare asistată de AI, pluginul trimite textul către Gemini 2.0 Flash și cere reformulare păstrând sensul, introducând referințe naturale la localitate și marcaj HTML limitat pentru evidențiere. Sugestiile pot fi generate individual sau în batch; interfața procesează batch-uri de câte 10 pagini și afișează progresul, iar fiecare sugestie poate fi aplicată separat sau în masă. Aplicarea conținutului este editor-aware. Pentru Elementor, pluginul citește _elementor_data, traversează recursiv elementele și salvează JSON-ul modificat în post meta, apoi curăță cache-ul Elementor. Pentru Gutenberg, parsează blocurile, modifică blocurile care conțin textul și serializează structura înapoi în post_content. Pentru editorul clasic folosește înlocuire directă în post_content. Snapshotul nu implementează tranzacții sau rollback explicit, iar logica de înlocuire a unui match poate substitui întregul câmp/bloc în care a fost găsită fraza, motiv pentru care operațiile destructive sunt precedate în UI de confirmări. Fluxul de imagini caută paginile care folosesc un anumit fișier și oferă două strategii: traversarea structurii editorului sau un mod direct în baza de date, introdus ca variantă cu consum redus de memorie. Modul DB caută în post_content și în _elementor_data, identifică URL-ul și attachment ID-ul, apoi afișează pentru fiecare pagină imaginea curentă alături de zona de preview pentru o imagine nouă. Generarea imaginilor folosește Vertex AI Imagen 3. Pluginul construiește un JWT din service-account-ul configurat, obține un access token Google OAuth, apelează endpointul Vertex AI, decodează imaginea Base64 și o salvează în WordPress Media Library. Pentru răspunsurile PNG există conversie la JPG prin GD. Numele fișierului include localitatea și un timestamp, iar imaginea rezultată poate fi aplicată individual sau în batch. Înlocuirea imaginilor actualizează atât post_content, cât și datele Elementor, inclusiv URL-uri și attachment IDs. Codul include mai multe fallback-uri pentru structuri Gutenberg/media-text și o cale directă prin wpdb atunci când update-ul standard nu produce rezultatul așteptat. După modificări, pluginul invalidează cache-ul postului, cache-ul Elementor și poate curăța cache-uri de la WP Super Cache, W3 Total Cache, WP Rocket, Autoptimize și LiteSpeed. Snapshotul păstrează și instrumente de diagnostic pentru structura blocurilor, utilizarea memoriei și loguri. Există însă și cod legacy sau incomplet: fișierul de shortcode nu este încărcat de bootstrap, câteva handlere JavaScript vechi nu au endpointuri PHP active, iar biblioteca Google Cloud declarată în Composer nu este folosită deoarece autoloader-ul este comentat. Repository-ul nu conține teste automate, workflow-uri CI/CD sau configurație de deploy. Din perspectivă de hardening, versiunea analizată ar beneficia de verificări current_user_can pe toate endpointurile AJAX destructive/AI, sanitizarea strictă a HTML-ului întors de model înainte de preview și persistare, mutarea credențialelor sensibile din wp_options într-un secret store/config sigur și eliminarea debug-ului activ implicit. debug.log este inclus în snapshot și conține informații despre mediul local, deși nu au fost identificate chei API, tokenuri Bearer sau chei private în fișierul analizat.

Tool full-stack simplu pentru distribuția aplicațiilor printr-un singur QR: definește linkurile iOS/Android, generează un QR către o adresă stabilă și redirecționează utilizatorul mobil către store-ul potrivit.

QR Generator este un proiect personal construit pentru un caz concret de distribuție a aplicațiilor: în loc ca materialele tipărite sau mesajele să conțină QR-uri diferite pentru iOS și Android, fiecare aplicație primește o singură adresă stabilă de forma qr.tigidal.ro/<nume-aplicație>. QR-ul codifică această adresă, iar serverul decide destinația finală în funcție de User-Agent. Suprafața de administrare este o pagină HTML/CSS/JavaScript fără framework. Formularul permite introducerea numelui aplicației, activarea separată a linkului App Store și Google Play și setarea unei parole pentru editare. Câmpurile de URL sunt activate sau dezactivate din UI în funcție de checkbox-uri, iar submit-ul trimite datele prin Fetch API către endpointul POST /api/apps. Backend-ul este un server Express care servește fișierele statice și persistă configurația aplicațiilor într-un fișier apps.json. Pentru fiecare intrare sunt păstrate linkurile disponibile și parola. Nu există ORM sau bază de date; fișierul este citit și rescris sincron la creare și actualizare, o alegere suficientă pentru un prototip cu volum redus, dar vulnerabilă la blocarea event loop-ului și la lost updates în acces concurent. Endpointul GET /api/qr/:appName generează server-side un QR prin pachetul qrcode. Codul setează explicit lățimea la 512 px și margin la 2 și returnează imaginea ca data URL, ceea ce permite afișarea imediată în browser și descărcarea ca PNG din pagina aplicației. Error correction level, culorile, logo-ul și stilizarea modulelor nu sunt configurate explicit în cod, iar repository-ul nu conține teste automate de scanabilitate. Ruta publică /:appName încarcă mapping-ul aplicației și inspectează User-Agent-ul. Pentru iPhone/iPad încearcă linkul iOS, pentru Android linkul Android, iar dacă destinația relevantă există răspunde cu redirect HTTP. Dacă platforma nu are un link configurat, afișează un mesaj explicit; pentru desktop afișează o pagină dedicată cu QR-ul și buton de download. Pagina desktop include și editarea configurației. Implementarea actuală verifică parola numai în browser: descarcă întregul obiect prin GET /api/apps și compară parola local, după care PUT /api/apps/:name actualizează datele fără o verificare server-side a parolei. În consecință, mecanismul este doar o barieră de UI, nu autentificare reală. Mai mult, endpointul GET /api/apps expune parolele în clar, iar apps.json din snapshot conține o parolă demonstrativă în clar. Acestea sunt principalele probleme de securitate ale versiunii analizate. Validarea backend este minimă: serverul acceptă name, linkurile și parola fără schemă de validare, nu restricționează domeniile de redirect și nu verifică unicitatea înainte de overwrite. UI-ul folosește input type=url și required pentru anumite câmpuri, dar aceasta este validare de browser, nu o garanție la nivel API. Numele aplicației este interpolat direct în HTML și JavaScript pe pagina dinamică, deci înainte de expunere publică ar trebui adăugate escaping contextual și validare strictă pentru slug. Repository-ul conține un singur commit numit „Initial commit — portfolio backup”, care adaugă simultan sursele active, fișierul de date și o arhivă ZIP. Din acest motiv se poate demonstra starea actuală a produsului, dar nu o cronologie de dezvoltare, refactorizări sau bugfixuri. Nu există Docker, PM2 config, workflow-uri GitHub Actions, health checks ori scripturi de deploy în snapshot.

Plugin WordPress/WooCommerce care importă în batch un nomenclator de coduri poștale din Excel, normalizează județe, străzi și intervale de numere și poate completa manual codurile poștale de facturare și livrare ale comenzilor.

ZIP Code Manager este un plugin WordPress construit pentru un flux operațional WooCommerce în care codurile poștale din comenzi trebuie verificate sau completate pe baza unui nomenclator local. Administratorul încarcă un fișier Excel din WordPress Admin, vede o previzualizare a primelor rânduri și confirmă importul; procesarea continuă prin cereri AJAX succesive, astfel încât un fișier mare nu este tratat ca o singură cerere web de lungă durată. Importul folosește PhpSpreadsheet și un IReadFilter care citește numai coloanele necesare din sursă: cod poștal, localitate și stradă. Fluxul AJAX procesează câte 500 de rânduri, iar UI-ul primește pentru fiecare chunk numărul de intrări procesate, inserate, actualizate și deja existente. Pentru preview sunt citite maximum 50 de rânduri. Snapshot-ul permite selectarea .xls și .xlsx, însă procesorul de chunk-uri folosește explicit readerul Xlsx; de aceea suportul legacy XLS trebuie considerat incomplet. Înainte de persistență, localitatea este separată de abrevierea județului printr-o hartă completă a județelor din România, cu tratament separat pentru București și sectoare. Strada este apoi analizată pentru segmente de tip nr., intervale precum 13-17, capete deschise de forma 26-T, numere singulare și sufixe de tip bis/A/B. Când o stradă conține mai multe intervale, fiecare interval devine un rând utilizabil pentru lookup, iar structura completă poate fi păstrată ca JSON în multiple_ranges. Datele sunt salvate într-o tabelă WordPress dedicată, wp_*_zip_codes, cu cod poștal, localitate, județ, stradă, început și sfârșit de interval, flag pentru interval infinit, metadata pentru intervale multiple și created_at. Schema are index compus pe cod poștal + stradă și un index pe capetele intervalului. Importul încearcă să identifice o înregistrare existentă prin combinația cod poștal, stradă, number_start și number_stop; intrările noi sunt grupate într-un INSERT comun, iar cele existente primesc update pentru localitate, județ și metadata de interval. Nu există însă constrângere UNIQUE în DB, deci integritatea împotriva duplicatelor se bazează pe logica aplicației. Integrarea WooCommerce este orientată către operator. În lista de comenzi și în ecranul de editare apare acțiunea «Actualizează cod poștal». La apăsare, pluginul citește separat adresa de facturare și cea de livrare, normalizează diacriticele și abrevierile de județ, extrage numărul stradal, sectorul și blocul și încearcă să găsească un cod poștal în tabela importată. Căutarea are trei trepte: potrivire pe localitate/județ + stradă și interval numeric, apoi un LIKE mai relaxat pe stradă, apoi fallback la primul cod distinct pentru localitate/județ. Dacă găsește rezultate, actualizează billing_postcode și, când este cazul, shipping_postcode prin obiectul WooCommerce Order și salvează comanda. Pluginul declară compatibilitate WooCommerce HPOS și verifică prezența WooCommerce și PhpSpreadsheet înainte de utilizare. AJAX-ul pentru import și acțiunea de actualizare a comenzilor folosesc nonce WordPress. Totuși, snapshot-ul are câteva puncte de hardening: formularul inițial de upload nu are nonce propriu, handler-ele AJAX nu fac un current_user_can explicit, fișierul temporar de import nu este șters la final, MIME-ul uploadului este verificat direct din request, iar logarea de debug scrie adrese și query-uri în error_log. Acestea sunt observații de cod, nu funcționalități prezentate ca avantaje. Frontend-ul proiectului este intenționat nativ WordPress Admin, nu o aplicație separată. Uploadul și preview-ul folosesc componentele vizuale WordPress, iar jQuery conduce procesarea chunk-urilor și mesajele de progres. Există un fișier CSS pentru butonul de actualizare a codului poștal, însă snapshot-ul nu îl înregistrează prin wp_enqueue_style; progresul importului este în principal textual, fără un design system propriu. Repository-ul conține un singur commit de backup pentru portofoliu și nu include teste, workflow-uri GitHub, Docker sau scripturi de deployment.

Plugin WordPress pentru sincronizarea produselor WooCommerce cu OLX: mapping de categorii și atribute, imagini și locații, autentificare OAuth, creare/actualizare anunțuri și curățarea legăturii la ștergere sau duplicare.

OLX Import este o integrare WordPress/WooCommerce construită pentru un client real, cu scopul de a transforma produsul administrat în WooCommerce în sursa operațională pentru anunțul OLX. Fluxul nu importă anunțuri OLX în magazin; direcția demonstrată de cod este WooCommerce → OLX Partner API. Pe pagina de editare a produsului, administratorul primește un meta box «Import to olx». Bifarea și salvarea produsului pregătesc payload-ul din datele WooCommerce și creează anunțul dacă produsul nu are încă un _advert_id. La salvările ulterioare, același ID este folosit pentru update. Pluginul persistă în post meta ID-ul anunțului, URL-ul OLX și flag-ul _imported_to_olx, iar linkul către anunț este afișat direct în meta box. Transformarea datelor include titlu, descriere, preț, SKU, imagini, categorii, atribute WooCommerce și metadate client-specific pentru magazin și contact. Codul mapează explicit categoriile de Bijuterii și Electronice către taxonomia OLX, selectează subcategorii pentru telefoane, tablete și foto și traduce atribute obligatorii precum starea produsului sau publicul țintă în codurile așteptate de OLX. Locația anunțului este construită dintr-un cod de agenție stocat pe produs. Pentru locațiile configurate sunt definite date operaționale precum adresa, programul, numărul de telefon, sectorul și denumirea magazinului. Orașul și sectorul sunt apoi rezolvate prin endpointurile OLX pentru cities și districts, iar payload-ul anunțului include city_id, district_id și coordonatele returnate de API. Integrarea folosește două tipuri de token: client credentials pentru endpointuri de catalog precum categorii, atribute și locații și authorization code/refresh token pentru operațiile asupra anunțurilor. Tokenurile și configurația sunt păstrate în WordPress Options. Pagina proprie «OLX Import» permite configurarea credențialelor și afișează starea conexiunii. Lifecycle-ul produsului este sincronizat și în sensul eliminării. Debifarea importului, mutarea produsului în coș sau ștergerea lui încearcă mai întâi dezactivarea anunțului atunci când starea OLX o cere, apoi DELETE și curățarea metadatelor locale. La duplicarea unui produs WooCommerce, _advert_id și _advert_url sunt eliminate și flag-ul de import este resetat, astfel încât copia să nu reutilizeze intenționat legătura anunțului original. Interfața de administrare adaugă în lista de produse o coloană «Imported to OLX», sortare și filtru Da/Nu. Erorile OLX sunt păstrate temporar prin WordPress Transients și prezentate ca admin notices după redirect. Nu există suită de teste, CI/CD, coadă de joburi, batching sau cache pentru metadatele OLX în snapshotul analizat. Baza pluginului păstrează mult din WordPress Plugin Boilerplate: loader, i18n, clase public/admin și fișiere demonstrative. Personalizarea substanțială se află în clasa de admin, unde sunt implementate integrarea OLX, mapping-ul de business și sincronizarea cu WooCommerce. Repository-ul conține un singur commit de backup, deci istoricul nu permite separarea cronologică a fiecărei contribuții. Există și un mecanism de refresh zilnic bazat pe WP-Cron în cod, însă plasarea registration hook-urilor în fișierul clasei admin și reinstanțierea clasei în callback fac funcționarea lui neconfirmată și fragilă. În plus, verificarea conexiunii este executată în constructorul admin și poate produce apeluri externe sincrone la încărcarea pluginului, ceea ce este o zonă clară de optimizare înainte de o versiune hardenată.

Experiență web în limba română pentru generarea și distribuirea unei urări personalizate, cu 5 teme cromatice, animații cu confetti, mesaj aleator stabil, control audio, link shareable și export al felicitării ca imagine.

La Mulți Ani este o mini-experiență web construită în Next.js 11 și React 17 pentru a crea rapid o felicitare personalizată de ziua de naștere. Utilizatorul alege una dintre cinci teme cromatice, introduce numele sărbătoritului și este direcționat către o rută shareable care codifică numele și tema aleasă. Ecranul rezultat combină titlu animat literă cu literă, confetti pe canvas, o urare aleasă aleator și controale pentru muzică, revenire și, în fluxul creatorului, copierea linkului și descărcarea felicitării ca PNG. Repository-ul nu reprezintă o implementare integrală de la zero. Fișierul CONTRIBUTING și licența indică explicit proiectul open-source gouravkhunger/nextjs-birthday-wish ca bază. Compararea codului curent cu upstream-ul arată că structura principală Next.js, hook-ul de teme, componentele Button/CopyLinkButton, animația de titlu, confetti-ul și mecanismul de export prin html-to-image + file-saver provin din acea bază. Personalizarea verificabilă constă în localizarea completă în română, înlocuirea și rescrierea mesajelor, adaptarea titlului "La Mulți Ani", eliminarea brandingului upstream din interfață, integrarea PWA, asset-uri și capturi proprii, schimbarea fluxului audio și câteva corecții de comportament în pagina felicitării. Fluxul principal este complet client-side. Pagina "/" menține local numele și tema selectată; validarea blochează valoarea goală sau un nume care începe cu spațiu, apoi Next Router navighează la "/{nume}" pentru tema albastră implicită sau "/{nume}/{themeId}" pentru celelalte teme. Ruta catch-all "[...name].js" extrage numele și ID-ul culorii din URL, aplică tema prin custom hook și setează culoarea într-o variabilă CSS globală. Nu există API, controller, serviciu backend, bază de date, conturi sau date persistate pe server. Mesajul de felicitare este ales aleator o singură dată la montarea componentei și păstrat în state. Aceasta este o diferență relevantă față de upstream, unde mesajul era recalculat la render și putea deveni inconsistent între ecran și imaginea exportată. În versiunea analizată, același mesaj este folosit atât în experiența vizibilă, cât și în template-ul temporar randat pentru export. Funcția de descărcare a fost de asemenea mutată într-un React.useCallback și declanșată prin efect atunci când se activează starea downloading, eliminând apelul cu side effects direct din render prezent în upstream. Titlul este construit caracter cu caracter pentru a aplica o animație ondulată CSS. Prefixul românesc "La Mulți Ani, " și numele sunt separate dinamic pe baza lungimii prefixului, nu prin pragul hardcodat folosit de versiunea upstream în engleză. Numele primit din URL este randat ca text React, fără dangerouslySetInnerHTML, astfel încât React face escaping pentru conținutul introdus. Tema este aleasă doar din lista fixă de cinci variante: albastru, verde, violet, galben și roșu. Audio-ul a fost modificat din autoplay-ul upstream într-un control explicit "Pornește muzica" / "Oprește muzica", conectat la un element audio prin useRef. Oprirea face pause și resetează currentTime la zero. Asset-ul audio este livrat local din public/media. Pagina de creare scrie și un flag "playMusic" în localStorage înainte de navigare, însă snapshot-ul curent nu îl citește nicăieri, deci flag-ul este cod rezidual și nu influențează comportamentul real. Sharing-ul folosește Clipboard API pentru copierea URL-ului curent și oferă feedback temporar "Link copiat!". Butoanele de copiere și export sunt afișate doar când istoricul intern arată că utilizatorul a ajuns la felicitare din homepage; o deschidere directă a linkului primește experiența de destinatar, cu buton de creare a unei urări noi și control audio. Această separare este o regulă de UX bazată pe stare locală, nu un mecanism de autorizare și se pierde la refresh. Exportul vizual folosește html-to-image pentru a transforma un container dedicat într-un PNG și file-saver pentru salvarea fișierului "birthday-wish.png". În modul de export, animația este eliminată din titlu și fundalul folosește asset-ul static de confetti, astfel încât rezultatul capturat să fie o felicitare curată, nu canvas-ul animat din experiența interactivă. Aplicația este configurată ca PWA prin next-pwa, manifest web și set complet de iconuri între 48×48 și 512×512. Manifestul include capturi wide și mobile ale UI-ului român și rulează în display standalone. Configurația next-pwa folosește register și skipWaiting. Repository-ul conține și service worker / Workbox generate; snapshot-ul comis demonstrează în special configurarea PWA, nu o strategie offline matură, deoarece service worker-ul salvat folosește NetworkFirst doar pentru start URL și NetworkOnly pentru celelalte rute în acel artifact. Frontend-ul este responsive și minimalist: fundal alb, tipografie system/Roboto, formă tip pill pentru input și butoane și accent controlat prin CSS custom property. Pe desktop interfața este foarte aerisită și centrată; pe mobil titlul se sparge pe două rânduri, selectorul de temă rămâne vizibil ca cinci puncte colorate, iar formularul se reorganizează vertical. Capturile versionate confirmă această adaptare responsive. Din punct de vedere al securității, repository-ul nu conține secrete sau fișiere .env versionate; .gitignore exclude fișierele de mediu locale și certificatele PEM. Nu există autentificare, acces la date sensibile sau endpoint-uri de server care să introducă riscuri de IDOR, SQL injection, mass assignment ori webhook forgery. Suprafața de risc rămâne cea a unei aplicații browser-only: Clipboard API poate eșua în contexte nesigure sau fără permisiune, URL-urile pot deveni foarte lungi deoarece numele nu are limită explicită, iar erorile de clipboard / export / audio nu au UI de fallback. Repository-ul nu conține teste automatizate, GitHub Actions, Docker, configurație de deployment, analytics sau error monitoring. Scripturile disponibile sunt dev, build, export, start și lint. Next.js este pornit cu openssl-legacy-provider pentru compatibilitate cu toolchain-ul vechi, iar start rulează pe portul 3001. Istoricul Git disponibil conține un singur commit de backup, astfel încât evoluția modificărilor nu poate fi demonstrată feature-by-feature; contribuțiile de mai sus sunt atribuite prin comparația directă dintre snapshot și upstream, nu prin numărul de commituri.

Concept de landing page pascală cu direcție vizuală inspirată din noaptea Învierii: aur bizantin, burgundy liturgic, tipografie ceremonială, simboluri ortodoxe și animații discrete, proiectată pentru o experiență statică rapidă și accesibilă.

Paste Fericit este un studiu personal pentru o experiență web sezonieră dedicată Paștelui Ortodox Românesc. Repository-ul verificat nu conține aplicația finală în branch-ul main; conține însă un design brief detaliat, deciziile tehnice și istoricul de lucru care descriu foarte clar produsul urmărit. Din acest motiv proiectul este prezentat ca un concept/prototip documentat, nu ca un site finalizat sau un produs lansat. Direcția de produs evită estetica generică de Paște occidental și construiește experiența în jurul momentului de la miezul nopții: fundal albastru-negru și burgundy, aur inspirat din icoane, lumină de lumânare, cruce ortodoxă cu trei bare, ou roșu cu motive geometrice românești și elemente florale discrete. Pagina a fost gândită ca un scroll vertical continuu cu patru zone: hero fullscreen, mesaj de felicitare, secțiune decorativă și footer minimal. Design system-ul documentat definește tokeni pentru culori, tipografie, spacing, umbre, tranziții și breakpoints. Fonturile propuse sunt Cinzel Decorative pentru mesajele monumentale, Cinzel pentru subtitluri și Cormorant Garamond pentru text. Brief-ul include o abordare mobile-first, un container îngust pentru lizibilitate și scale tipografice diferite pentru telefon, tabletă și desktop. Interacțiunile planificate sunt deliberate și lightweight: glow de lumânare, particule aurii, reveal pentru heading, shimmer discret și apariții la scroll prin IntersectionObserver. Documentația cere explicit respectarea prefers-reduced-motion și evitarea animațiilor agresive, audio-ului automat și efectelor care ar distrage de la mesaj. Arhitectura decisă a evoluat de la un scaffold Vanilla Vite către Astro + Tailwind CSS, pentru generare statică și minimum de JavaScript livrat către browser. Istoricul menționează existența temporară a unui scaffold Vite și a unor fișiere CSS/JS, dar acestea nu sunt prezente în commitul curent, deci nu sunt tratate ca implementare livrată. Deployment-ul a fost planificat pentru Hetzner: build static în dist/ și copiere pe server pentru paste.tigidal.ro. În repository nu există însă workflow CI/CD, script de deploy, configurare Nginx, build output sau commit care demonstrează publicarea efectivă. URL-ul nu este folosit ca link public în portofoliu deoarece nu a putut fi verificat ca site disponibil în momentul analizei.

Experiență Vue 3 de Revelion cu urare personalizată din URL, countdown până la miezul nopții, mesaje rotative și fundal video adaptat separat pentru mobil și desktop.

An Nou Fericit este un mini-proiect front-end construit ca experiență full-screen de Revelion. Vizitatorul poate deschide ruta principală, care folosește implicit numele Tigidal, sau o rută de forma /:name pentru a integra numele destinatarului direct în urare. Parametrul este urmărit reactiv prin Vue Router, normalizat printr-un computed pentru capitalizare și randat prin interpolarea Vue. Interfața combină un countdown actualizat la fiecare secundă, o urare centrală, un separator vizual și o listă de 20 de mesaje pozitive care se rotesc automat la fiecare trei secunde. Countdown-ul este fixat pentru 1 ianuarie 2026, ora 00:00 în România, prin conversia explicită la UTC+2 pentru data respectivă. Fundalul este un video HTML5 autoplay, muted și loop. Codul alege clip_mobile.mp4 pentru ferestre de maximum 768 px și clip_desktop.mp4 pentru ecrane mai mari, iar selecția este recalculată la resize. Layout-ul folosește 100dvh, object-cover, overlay negru semitransparent, text alb cu shadow și un gradient portocaliu-roz pentru mesajul principal. Aplicația este exclusiv client-side: Vue 3, Vue Router și state local cu ref/computed/watch. Nu există backend, bază de date, autentificare, API, joburi, queue, webhook-uri sau persistență. Deși manifestul include biblioteci precum Firebase, Vuex, Axios, Capacitor și notificări locale, acestea nu sunt folosite de implementarea analizată și nu sunt prezentate ca funcționalități ale proiectului. Metadata SEO/social este definită atât în index.html, cât și prin @vueuse/head, incluzând title, description, Open Graph și Twitter Card. Canonical și og:url indică domeniul general tigidal.ro; nu există în repository o rută publică dedicată sau configurație de deployment care să permită verificarea unei adrese live pentru acest mini-proiect. Snapshot-ul are și limitări clare. Fișierele video sunt excluse explicit din Git, astfel încât repository-ul singur nu reproduce fundalul media. După expirarea countdown-ului, funcția încearcă să oprească un identificator countdownInterval care nu este definit, ceea ce produce o eroare înainte de setarea textului EXPIRED. Listener-ul de resize și intervalele nu au cleanup la unmount, iar handlerul de ended este combinat cu loop și nu reprezintă un mecanism robust de tranziție între clipuri. Istoricul Git disponibil conține un singur commit de tip portfolio backup, deci demonstrează starea aplicației, nu o cronologie completă a dezvoltării. Contribuția verificabilă în snapshot este experiența Vue: personalizarea route-based, countdown-ul, rotația mesajelor, alegerea video responsive, styling-ul și metadata.

Experiență web sezonieră în Remix, cu mesaj de Crăciun personalizat din rută, scenă parallax în straturi, ninsoare animată pe canvas, countdown și assets responsive pentru desktop și mobil.

Tigidal Crăciun este un proiect de studiu/personal construit ca experiență web sezonieră full-screen. Ruta principală afișează mesajul implicit „Tigidal vă urează, Crăciun Fericit!”, iar ruta dinamică /$name reutilizează același ecran și injectează parametrul de URL în mesajul de felicitare. Numele este randat prin interpolarea React, nu prin HTML brut, astfel încât textul din rută rămâne escap-at de React. Interfața este compusă din cinci straturi grafice cu adâncimi diferite, animate cu jquery.parallax pentru efect de perspectivă. Peste scenă este adăugat un canvas de ninsoare cu particule generate și animate prin requestAnimationFrame, un loader cu fulg rotativ, un brad poziționat central și un countdown prezentat în ornamente grafice. CSS-ul definește o paletă rece albastru-cyan, text alb și fonturi decorative Parisienne/Lobster, iar pentru ecrane mici sau joase sunt folosite seturi separate de imagini parallax-mobile și reguli responsive pentru text, countdown și brad. Arhitectura este hibridă. Remix 2 + React 18 oferă structura de routing, metadata și shell-ul aplicației, iar experiența vizuală este condusă în mare parte de jQuery și plugin-uri statice pentru countdown și parallax, plus Bootstrap și CSS custom. Repository-ul păstrează și configurare Tailwind, însă ecranul analizat nu folosește utilitare Tailwind în markup. Nu există loader/action Remix, API, bază de date, servicii, autentificare, state management global, joburi, queue, webhook-uri sau integrare cu furnizori. Countdown-ul este hardcodat la 25 decembrie 2023, în timp ce metadata include keyword-ul 2024, ceea ce arată că snapshot-ul nu a fost actualizat pentru o campanie sezonieră curentă. În plus, scripturile, stylesheet-urile și imaginea bradului sunt referențiate prin căi app/assets relative la runtime, deși assets-urile se află în sursa aplicației, nu în public; această structură trebuie verificată/corectată pentru un deployment Remix/Vite de producție fiabil. README-ul este cel generic Remix și nu documentează un pipeline de publicare. Repository-ul conține un singur commit „Initial commit”, fără istoric incremental, teste automate sau workflow-uri GitHub Actions. Din cod se poate demonstra experiența personalizabilă și integrarea vizuală, dar nu se poate demonstra că toate assets-urile sau template-ul grafic au fost create de la zero în acest repository. De aceea proiectul este prezentat ca microsite/remix personalizat, nu ca design original integral sau produs lansat cu backend.

Aplicație Remix/React instalabilă ca PWA, construită în jurul unui ceas seven-segment configurabil, cu timezone, 12/24h, meteo local, cronometru, timer, alarme, fullscreen și gesturi mobile.

Digital Clock este un proiect personal care extinde un ceas digital fullscreen într-un utilitar web instalabil. Ecranul principal redă ora într-un display seven-segment construit din componente React și CSS, actualizat la fiecare secundă și configurabil pentru format 12/24h, format de dată, timezone, dimensiune, temă cromatică și animație. Preferințele sunt persistate în localStorage și propagate printr-un ClockContext comun. Produsul are patru moduri în aceeași suprafață: Clock, Stopwatch, Timer și Alarm. Stopwatch-ul măsoară minute, secunde și sutimi, timerul acceptă ore/minute/secunde și declanșează notificare locală la final, iar modul Alarm permite mai multe alarme, etichete, activare/dezactivare și repetare zilnică. Alarmele sunt păstrate local și sunt sincronizate către un API Express care menține o copie în memorie. Experiența este gândită pentru desktop și mobil: controalele se rearanjează responsive, dublu-tap-ul comută fullscreen, swipe-urile schimbă modul, iar un gest de shake parcurge temele disponibile. Un screensaver poate muta display-ul prin viewport cu efect de bounce și viteză configurabilă. Codul include și suport pentru Wake Lock, deși hook-ul nu este conectat efectiv în fluxul principal analizat. În modul Clock, aplicația poate cere geolocația browserului, folosește Nominatim pentru reverse geocoding și Open-Meteo pentru temperatura curentă, apoi reîmprospătează informația periodic. Dacă geolocația sau requesturile eșuează, componenta meteo se ascunde fără să blocheze funcția principală de ceas. Aplicația este configurată ca PWA prin Remix + Vite și @vite-pwa/remix, cu manifest, iconuri pentru mai multe platforme, screenshots declarate, mod fullscreen/standalone, service worker și strategie NetworkFirst. Root-ul înregistrează service worker-ul, verifică update-uri și încearcă să mențină o subscripție Web Push asociată unui userId local. Serverul custom Express expune endpointuri pentru sincronizarea alarmelor, citirea alarmelor, verificarea celor active, înregistrarea subscripțiilor push și publicarea cheii VAPID. Un interval server-side verifică minutele curente și încearcă să trimită notificări prin web-push. În snapshotul analizat, starea este însă ținută doar în Map-uri în memorie, cheile VAPID sunt regenerate la restart, timezone-ul selectat în UI nu este trimis serverului, iar service worker-ul custom încearcă să folosească localStorage — indisponibil în context de Service Worker. Din aceste motive, partea de alarmă background trebuie considerată implementare experimentală, nu un scheduler persistent de producție. Deployment-ul este pregătit pentru hosting Node/cPanel: build-ul Remix produce bundle client/server, loader.cjs pornește serverul custom, iar repository-ul include un script FTP care urcă build-ul într-un subdirector. Snapshotul nu conține workflow-uri CI/CD sau teste automate. Tot în zona de deployment există datorie de securitate: repository-ul conține credențiale FTP și chei VAPID hardcodate, care trebuie revocate și mutate în secret management înainte de reutilizare.

Utilitar Vue 3 + TypeScript care convertește în ambele sensuri între numere întregi și forme textuale românești, cu normalizare a diacriticelor, validare deterministă, interfață responsive și suport PWA offline.

TTN — Text to Number este un proiect personal construit ca utilitar client-side pentru conversia bidirecțională dintre numere întregi și exprimări textuale în limba română. Aplicația nu folosește backend, bază de date sau servicii externe pentru conversie: logica rulează local în browser, ceea ce face fluxul rapid, ușor de distribuit și compatibil cu utilizarea offline prin PWA. Interfața Vue oferă două moduri explicite — Text → Număr și Număr → Text — comutate din același ecran. Inputul poate fi trimis prin buton sau Enter, rezultatul și erorile sunt afișate în aceeași carte centrală, iar schimbarea modului resetează inputul și starea rezultatelor. UI-ul este realizat cu Tailwind CSS și stiluri scoped: fundal gradient animat, card alb semi-transparent, stări de focus, micro-animații pentru rezultat și etichete ARIA pentru controalele principale. Pentru Text → Număr, parserul normalizează mai întâi diacriticele românești, transformă cratimele în spații, compactează whitespace-ul și trece textul în lowercase. Conversia folosește tabele explicite pentru unități, 10–19, zeci și multiplicatori (sute, mii, milioane), apoi procesează tokenurile cu acumulatoare pentru grupul curent și total. Conectorul «și» este permis doar după o valoare de zeci între 20 și 99, iar tokenurile necunoscute, multiplicatorii repetați sau anumite ordini invalide întorc null în loc să producă un rezultat aproximativ. Pentru Număr → Text, formatterul acceptă doar întregi între 0 și 999.999.999 și descompune valoarea în grupuri de milioane, mii și unități. Fiecare grup este formatat din sute, zeci și unități, cu forme dedicate pentru «o/două» și pentru 11–19. Implementarea este deterministă și nu depinde de locale sau de un API extern, dar nu acoperă complet gramatica românească pentru toate combinațiile mari. Repository-ul include Vitest pentru normalizeText și textToNumber: sunt acoperite diacriticele, lowercase, spațiile/cratimele, numerele 0–19, zecile, zecile cu unități, sute, mii, milioane, exemple compuse și input invalid. Totuși, starea actuală a parserului are o problemă structurală: lastMultiplier este coborât la 100 atunci când apare o sută în interiorul unui grup, astfel că un multiplicator ulterior de 1.000 este respins. De aceea exemple valide precum «trei milioane cinci sute de mii» sau «un milion două sute treizeci și patru de mii…», deși apar ca așteptări în teste, nu sunt compatibile cu logica actuală. Testele nu acoperă numberToText. Formatterul are și limite gramaticale verificabile în snapshot: 1.000 este compus prin grupul «mie» fără ramura specială pentru feminin și rezultă «unu mie», iar regula pentru «de» după grupuri mari nu tratează corect toate sutele de mii/milioane. În sens invers, parserul ignoră tokenul «de» indiferent de poziție și acceptă unele secvențe de unități prin simplă adunare, deci validarea sintactică este intenționată, dar nu constituie un parser complet al gramaticii numerale românești. Validarea din UI pentru modul Număr → Text folosește parseInt. Asta înseamnă că șiruri precum «123abc», «12.7» sau «1e3» pot fi trunchiate și interpretate ca întregi în loc să fie respinse integral. Intervalul final este totuși verificat în numberToText, iar valorile negative, peste 999.999.999 sau neîntregi primite direct de funcție întorc null. O versiune de producție ar trebui să valideze strict întregul input înainte de conversie. Aplicația este configurată ca PWA cu vite-plugin-pwa și Workbox. Manifestul definește nume, short name, theme color, mod standalone, iconuri pentru Android/iOS/Windows, screenshots desktop/mobile, shortcut și scope /ttn/. Service worker-ul folosește autoUpdate și strategii CacheFirst pentru JS/CSS, imagini și fonturi, respectiv NetworkFirst pentru HTML. Există și o regulă generică pentru API-uri, deși aplicația actuală nu face request-uri către un API. Configurația PWA declară și protocol handler-ul web+ttn cu un query parameter text, însă App.vue nu citește acel parametru, deci această integrare este doar configurată, nu funcțională end-to-end. Vue Router este instalat și are o singură rută Home către App.vue, dar App.vue este oricum componenta rădăcină și nu conține router-view; în forma actuală routerul nu furnizează o suprafață de navigare reală. Base path-ul Vite este /ttn/, în timp ce createWebHistory este inițializat fără base explicit. Din perspectivă de securitate, suprafața este redusă: nu există autentificare, secrete, formulare persistate, uploaduri sau date personale, iar rezultatele sunt randate prin interpolarea Vue, nu prin HTML injectat. Repository-ul nu conține un fișier .env în arborele analizat; .gitignore exclude *.local, dar nu declară explicit un pattern pentru .env. Principalul hardening relevant este mai degrabă de UX și validare strictă decât de control al accesului. Deployment-ul nu este automatizat în repository: nu există .github/workflows, Docker, scripturi de deploy sau health checks. Configurația /ttn/ și artefactele PWA indică o țintă de hosting subpath/static, dar repository-ul nu demonstrează prin CI/CD cum este publicată aplicația. Singurul commit disponibil este «Initial commit» din 12 iulie 2026, așa că se poate verifica snapshot-ul produsului, nu o cronologie de refactorizări sau bugfixuri.

Zece proiecte WordPress pentru clienți — de la construcții complete și magazine WooCommerce la customizări de teme, blocuri Elementor, fluxuri e-commerce și mentenanță.

Case study umbrelă pentru zece livrări WordPress cu niveluri diferite de ownership. Unele site-uri au fost construite integral, altele au fost preluate pentru schimbări de temă, pagini refăcute, child themes, ACF, componente Elementor custom sau logică PHP/JavaScript în admin și storefront. Lucrările WordPress sunt separate de integrările majore tratate ca proiecte proprii în portofoliu: API/feed-ul distribuitorului pentru Delta Anvelope aparține proiectului DeltaPlus, iar pluginul OLX Import pentru Global Cash are propriul case study. Aici rămâne contribuția efectivă la site-uri, WooCommerce și experiența editorială/administrativă.

Client web full-stack pentru centralizarea soldurilor, facturilor, plăților, contoarelor și operațiunilor disponibile într-un cont e-bloc.ro.

E-Bloc este un proiect personal de produs și integrare care transpune funcțiile utile ale contului e-bloc.ro într-o experiență web proprie. Backend-ul TypeScript intermediază API-ul upstream, gestionează autentificarea și reînnoirea sesiunii, normalizează răspunsurile și sincronizează local asociații, apartamente, facturi și plăți în PostgreSQL. Frontend-ul SvelteKit oferă context rapid pe asociație și apartament, dashboard financiar, istoric de facturi și plăți, contoare, solduri, portofel, tichete și acțiuni controlate pentru numărul de persoane și transmiterea indexurilor.

Aplicație web standalone care sincronizează date MyElectrica într-un model PostgreSQL și centralizează contracte, locuri de consum, facturi, plăți, contoare, autocitiri și statistici de consum.

MyElectrica este un proiect personal construit ca aplicație web standalone peste fluxurile disponibile în contul MyElectrica. În loc să afișeze direct fiecare răspuns al furnizorului, backend-ul sincronizează ierarhia client → contract → loc de consum (NLC), facturile, plățile, contoarele, registrele, citirile, detaliile contractuale și convențiile de consum într-o bază PostgreSQL. Datele locale permit interogări rapide, filtrare, paginare și analiză istorică fără ca fiecare ecran să depindă de un apel live către furnizor. Backend-ul este implementat în TypeScript cu Hono, Drizzle ORM și PostgreSQL. Autentificarea validează credențialele prin API-ul MyElectrica, creează o sesiune proprie și păstrează parola upstream criptată cu AES-256-GCM pentru reautentificarea automată atunci când tokenul furnizorului expiră. Sincronizarea folosește upsert-uri și chei unice pentru entitățile principale, normalizează datele și valorile numerice venite din API și rulează controlat, secvențial, pentru a evita rafalele de request-uri. Facturile au un al doilea nivel de procesare: PDF-ul furnizorului poate fi descărcat server-side, transformat în text cu pdftotext și interpretat într-o structură cu perioadă de facturare, consum, TVA, sold anterior, total de plată, contor, elemente facturate și penalități. Rezultatul este persistat într-un cache JSONB versionat, cu invalidare după modificarea sursei, schimbarea versiunii parserului sau expirarea TTL-ului. Acest strat alimentează atât modalul detaliat al facturii, cât și analizele de cost și consum. Frontend-ul SvelteKit 2 / Svelte 5 este server-rendered și folosește un strat server-side pentru comunicarea cu backend-ul, astfel încât cheia sesiunii rămâne într-un cookie httpOnly. Interfața responsive include dashboard financiar, listă de facturi cu status și inițiere de plată, istoric plăți, contoare și citiri, trimitere de autocitire în fereastra PAC, detalii de contract, editarea convenției de consum și o zonă de statistici. Statisticile agregă costul și consumul lunar, prețul mediu per kWh, structura costurilor, comportamentul plăților, sezonalitatea, comparația între ani, evoluția indexului și consumul real față de convenție. Ca reper funcțional a fost documentată integrarea publică cnecrea/myelectrica pentru Home Assistant. Implementarea analizată aici are însă o suprafață diferită: este o aplicație full-stack standalone cu bază de date proprie, sincronizare și cache, fluxuri de plată/autocitire și dashboard-uri web dedicate. Nu sunt revendicate funcționalități ale integrării Home Assistant și nici API-ul furnizorului ca fiind construit de autorul acestui proiect.

Marketplace auto cu licitații normale și instant, KYC, wallet, publicare de vehicule, Premium și fluxuri pentru verificare, garanție, finanțare și transport.

Cars For Resale este o platformă web orientată spre vânzarea și cumpărarea autoturismelor prin licitații online. Suprafața publică include listarea și filtrarea vehiculelor, pagini detaliate cu galerie și specificații, licitații normale și cu închidere instant, countdown, wishlist și posibilitatea de a urmări licitațiile care urmează să înceapă. Interfața este server-rendered cu Laravel Blade și completează navigarea clasică prin request-uri AJAX pentru filtrare, sortare, paginare și verificarea ofertei curente. Utilizatorul autentificat trece prin verificarea KYC înainte de operațiile sensibile. Poate licita, își poate consulta istoricul ofertelor și al câștigurilor și poate publica propriile autoturisme, cu galerie, descriere, specificații și câmpuri auto configurabile precum seria de șasiu și documentul vehiculului. Anunțurile intră într-un flux de moderare administrativă, iar modelul de licitație păstrează separat produsul, ofertele și înregistrarea câștigătorului. Platforma include și un sold intern cu depuneri, retrageri și jurnal de tranzacții. Depunerile pot trece prin gateway-uri configurabile sau printr-un flux manual de aprobare; integrarea Stripe Checkout prezentă în cod validează semnătura webhook înainte de confirmarea unei plăți. Repository-ul conține adaptoare și pentru alte gateway-uri, însă codul nu demonstrează care dintre ele sunt active în producție. Peste marketplace sunt modelate servicii specifice domeniului auto: abonamente Premium, credite de publicare, solicitări de verificare auto, garanții legate de vehicule câștigate, cereri de finanțare și transport tarifat pe zone/județe. Fiecare dintre aceste fluxuri are formulare, stări și operații administrative dedicate, iar sistemul de notificări reutilizează template-uri configurabile pentru email și SMS. Frontend-ul folosește template-ul Cars For Resale pe Blade, Bootstrap, jQuery și Swiper, cu Poppins, fundaluri dark, logo alb și paleta configurată verde #009f78 / galben #f2ba17. Homepage-ul este centrat pe imagini auto full-width și CTA-uri pentru licitații și vânzare, iar catalogul permite grid 2/3 coloane, filtrare după categorie/preț/tip de licitație și sortare persistentă în browser. Snapshot-ul analizat păstrează și componente generice/moștenite de marketplace, iar istoricul Git disponibil nu separă contribuțiile incremental. Din acest motiv, acest case study prezintă produsul și personalizările verificabile din cod fără a revendica întregul repository ca implementare originală de la zero.

Catalog web responsive pentru produse Chogan, cu acces protejat, variante și prețuri, galerii media, filtrare, coș local, comandă prin WhatsApp și administrare dedicată.

Chogan Catalog este o aplicație web full-stack construită pentru prezentarea și operarea unui catalog comercial care are mai multe categorii de produse, variante cu reguli diferite, imagini și prețuri. Experiența pentru client acoperă accesul protejat la catalog, navigarea pe categorii, căutarea, paginarea, pagina de produs cu galerie și selectarea variantei, produse similare și un coș persistent local. Comanda nu este tratată ca un checkout e-commerce propriu: selecția este transformată într-un mesaj WhatsApp precompletat pentru continuarea conversației cu consultantul. Zona de administrare permite gestionarea produselor, variantelor, tipurilor de produs și galeriilor, iar backend-ul validează regulile de variantă și persistă datele prin Prisma într-o bază SQLite.

Integrare WooCommerce ↔ Nexus ERP pentru asocierea catalogului, sincronizarea prețurilor și stocurilor și operarea comenzilor, cu cache local, automatizări, rezervări de stoc și reconciliere.

Nexus ERP — WooCommerce este un plugin WordPress construit pentru a lega operațional magazinul online de Nexus ERP. Administratorul configurează conexiunea, asociază produsele WooCommerce cu produsele ERP și gestiunea relevantă, apoi poate sincroniza prețurile și disponibilitatea manual sau programat. Interfața include setări și diagnostic, un board dedicat de asociere WC ↔ ERP, o listă de produse cu statusul sincronizării, metabox read-only pe produs și un jurnal operațional. Catalogul ERP nu este interogat separat pentru fiecare produs. Pluginul face pull pentru produse, prețuri și stoc, normalizează datele în trei tabele locale MySQL și face upsert în batch-uri. Prețul și stocul sunt citite apoi din cache-ul local pentru gestiunea asociată fiecărui produs. Stocul disponibil ține cont de cantitatea rezervată în ERP și de comenzile WooCommerce deschise care nu au încă rezervarea reflectată în ERP, iar mecanismul nativ WooCommerce de reduce/restore stock este blocat pentru produsele administrate de integrare ca să evite dublarea ajustărilor. Fluxul de comenzi pornește automat când o comandă ajunge în Processing sau poate fi declanșat manual. Payload-ul este validat, produsele trebuie să aibă asociere ERP, iar liniile sunt grupate după gestiune. Partenerul ERP este rezolvat din datele de facturare, cu reguli distincte pentru persoană fizică și juridică și cu opțiune de creare automată. După trimitere, pluginul poate recupera sau realinia ID-ul și starea comenzii din ERP, actualiza antetul și liniile, rezerva sau elibera stoc și propaga anularea în limitele tranzițiilor permise de API. Pentru operațiile de citire, clientul HTTP reîncearcă doar erorile de transport, cu backoff. Scrierile nu sunt repetate automat, deoarece un retry orb ar putea duplica documente în ERP; în schimb, fluxul folosește identificatori externi, metadata și reconciliere prin read-back. Există și healing pentru comenzile marcate ca trimise dar rămase fără ID ERP, plus protecții best-effort pentru operații concurente de trimitere, anulare și rezervare. UI-ul este integrat în WordPress Admin și folosește componente native, JavaScript vanilla și CSS propriu. Board-ul de asociere oferă căutare, filtre, paginare, mod single/bulk și refresh de catalog, iar metabox-ul comenzii oferă trimitere, verificare status, update și schimbare de stare. Repository-ul include teste PHPUnit/Brain Monkey pentru sincronizare, catalog, răspunsurile API, comenzi, parteneri și reguli de stoc, precum și un script de build care produce arhiva instalabilă WordPress fără fișierele de development.