Marketplace vintage & second-hand - Maria Alexandra Bobea
Analiza tehnica si de produs a platformei eClassify raportata la cerintele marketplace-ului.
Analiza consolidata pe build si medii testate
- CONFIRMAT DEFECT — există o problemă sau un risc demonstrat în cod ori în runtime.
- CONFIRMAT INCOMPLET — configurarea, integrarea sau livrarea este începută, dar nu este finalizată.
Ce ofera
Functiile existente sunt grupate pe departamente pentru ca Maria sa inteleaga baza reutilizabila si adaptarile necesare pentru marketplace.
Conturi si profiluri
Platforma include inregistrare, autentificare si profiluri. Baza permite aceleiasi persoane sa descopere produse si sa publice anunturi, dar regulile buyer/seller, permisiunile si scenariile de aprobare trebuie definite pentru proiect.
Anunturi, media si categorii
Exista publicare cu imagini/video, categorii si campuri personalizate. Pentru vintage si second-hand trebuie configurate taxonomia, starea produsului, brandul, marimea, atributele si campurile obligatorii.
Cautare, filtre si locatie
Sunt disponibile cautarea, filtrarea si localizarea. Pentru Romania, experienta poate fi extinsa cu judet, localitate, raza, pret si URL-uri indexabile, astfel incat rezultatele sa fie utile si pentru SEO.
Favorite, chat si review-uri
Platforma contine favorite, profil, chat, notificari, review-uri, report/block si seller verification. Pentru valoare comerciala sunt necesare reguli de moderare, review legat de tranzactie si escaladarea sesizarilor.
Promovare si continut
Promovarea, pachetele, blogul, reels si jobs pot sustine cresterea si monetizarea. Pentru Maria trebuie stabilite ofertele, preturile in RON, TVA-ul, perioadele, limitele si rapoartele.
Limbi si monede
Mecanismele pentru limbi si monede permit pregatirea pietei din Romania. Sunt necesare traduceri finale, RON implicit, formate locale pentru preturi si documente.
Ce nu ofera complet
Aceste domenii au componente sau integrari disponibile, dar nu formeaza inca un flux comercial marketplace complet si demonstrabil end-to-end.
Comanda, cos si checkout
Nu exista flux complet pentru comanda, cos, checkout, adresa si starea comenzii. Implementarea trebuie sa stabileasca produsul, rezervarea, disponibilitatea, taxele, anularea si auditul fiecarei stari.
Plata, comision si payout
Gateway-urile pot fi integrate, dar incasarea, comisionul, soldul sellerului, payout-ul si reconcilierea nu sunt legate intr-un flux financiar unic. Stripe Sandbox poate valida tehnic modelul.
Livrare, AWB si tracking
Lipseste fluxul end-to-end pentru adresa, curier, AWB, tracking si pickup. Acesta trebuie conectat la curierii alesi si la regulile comerciale ale Mariei.
Retur, refund si disputa
Returul, rambursarea, disputele si buyer protection nu sunt un workflow complet cu termene, dovezi, aprobari, notificari si decizii pentru produse second-hand.
Trust, safety si moderare
Report/block este baza, nu sistemul complet. Sunt necesare KYC, reguli anti-abuz, roluri, SLA-uri, motive de respingere, jurnal de decizii si traseu de apel.
Administrare si reconciliere
Back-office-ul trebuie sa unifice aprobarea, refund-ul, payout-ul, reconcilierea si auditul, cu permisiuni explicite si jurnal de modificari pentru echipa.
Ce a fost testat concret
Auditul backend a folosit schema izolata, cinci fixture-uri de rol si HTTP separat: 27 scenarii API si 21 grupuri admin cu index, create, show, mutatii goale, ownership si deny. Statusul fiecarui rezultat este in dosarul tehnic, iar lipsa unui payload pozitiv valid nu este marcata functional.
1. Cerinte Maria - clasificare pe baza testelor
Cerinta | Status strict | Rezultat confirmat |
|---|---|---|
Buyer si seller pe acelasi cont | CONFIRMAT INCOMPLET | Contul User poate accesa informatiile de cont si contul Seller poate publica; modelul permite roluri separate, dar comutarea aceluiasi cont intre cumparare si vanzare nu este implementata ca flux distinct. |
Listing seller si propagare discovery | CONFIRMAT INCOMPLET | Seller a creat, actualizat si sters un anunt in baza izolata; Guest poate cere lista publica. CRUD-ul este confirmat, dar propagarea in toate suprafetele de discovery nu este inca demonstrata. |
Search, categorii, filtre, locatie | CONFIRMAT INCOMPLET | Categorii si lista raspund 200; filtrarea completa si nearest nu sunt inchise, iar get-location are defect confirmat: 200 text/html/body gol pentru parametrii folositi, in loc de contract JSON. |
Favorite, profil, chat, notificari | CONFIRMAT INCOMPLET | Favorite add/remove, profil seller si chat bilateral au fost confirmate; notificarea externa FCM nu a fost validata pe dispozitiv. |
Checkout, plata, comision, payout | CONFIRMAT INCOMPLET | Gateway-urile si payment settings sunt confirmate; order, tranzactie sandbox, comision, payout si reconciliere nu sunt implementate complet. |
Shipping, AWB, tracking, pickup | CONFIRMAT LIPSA | Nu exista workflow backend complet confirmat pentru AWB, tracking si pickup. |
Retur, refund, disputa, protectie | CONFIRMAT LIPSA | Nu exista rute si workflow complet confirmat pentru aceste operatii. |
Reviews legate de tranzactie | CONFIRMAT FUNCTIONAL | Anuntul a fost marcat sold out pentru User; review cu rating 5 a fost creat si Seller a primit average 5; duplicatul a fost respins. |
Trust & safety | CONFIRMAT INCOMPLET | Block a impiedicat trimiterea mesajului, unblock si follow/unfollow au functionat; report, moderare si KYC nu sunt inchise. |
Admin multi-rol | CONFIRMAT INCOMPLET | Login Super Admin si rutele CRUD reprezentative au raspuns 200; User/Seller/Staff/Admin/Super Admin au fost create, dar matricea completa de permisiuni pe fiecare mutatie nu este inchisa. |
Multi-country, limbi, monede | CONFIRMAT INCOMPLET | API-ul de limbi exclude ro, /ro/landing livreaza lang en, iar hosturile mobile si tara implicita sunt India. |
Design premium Maria | CONFIRMAT INCOMPLET | Exista mockupuri transmise partial in discutia cu Maria; directia vizuala este confirmata, dar setul complet de ecrane si starile responsive nu sunt inca inchise prin acceptanta. |
1A. Matrice de implementare pentru cerintele Mariei
Estimarea de mai jos este legata de modulele identificate in copia instalata si de regulile comerciale definite pentru marketplace. „Reutilizabil” inseamna cod existent care poate fi pastrat dupa validare, nu doar un nume de ruta sau un package prezent.
Cerinta | Ce se reutilizeaza concret | Regula comerciala / lipsa | Solutie si zone de modificat | Timp |
|---|---|---|---|---|
Buyer + seller pe acelasi cont | Auth Sanctum, User, SellerController si profilurile existente | Un utilizator publica si cumpara fara conturi duplicate; comutarea rolului si drepturile trebuie definite explicit. | Unificare capability buyer/seller in User, Policy si API; selector de mod in Web/Flutter; teste de ownership. `app/Models/User.php`, `app/Http/Controllers/SellerController.php`, `routes/api.php` | 12-20 h |
Listing seller -> database -> discovery | ItemController, ItemApiResource, add/update/delete item, upload media | Sellerul creeaza produsul real; produsul se salveaza automat si devine vizibil doar dupa starea de moderare stabilita. | Pastrare CRUD si adaugare pipeline de status, indexuri, propagare in lista/categorii/search si refresh cache. `app/Http/Controllers/ItemController.php`, `app/Http/Resources/ItemApiResource.php`, `web/features/*`, `mobile/.../item*` | 16-28 h |
Search, categorii, filtre, locatie | CategoryController, PlaceController, item list API, filtre Web/Flutter | Cautare dupa mobilier/decor/vintage, categorie, pret, stare, localitate si distanta; nearest necesita coordonate valide. | Contract JSON pentru LocationApiController, query builder paginat si indexat, teste pentru filtre combinate si Bucuresti/Ilfov. `app/Http/Controllers/Api/LocationApiController.php`, `app/Http/Controllers/ItemController.php`, `routes/api.php` | 16-26 h |
Favorite, profil seller, chat, notificari | Favorite API, SellerController, AdminChat, NotificationService, FCM | Buyerul salveaza produse, contacteaza sellerul si primeste notificare pentru evenimente relevante. | Se pastreaza modulele; se adauga contracte de notificare, idempotency, FCM pe mediu si teste buyer/seller. `app/Services/NotificationService.php`, `app/Http/Controllers/Api/*`, `mobile/lib/*chat*` | 18-32 h |
Checkout, plata, comision, payout | PaymentService si adaptoarele Stripe/PayPal/Razorpay; payment settings | Comanda produs, plata in sandbox, comision marketplace, sold seller si eliberare payout dupa confirmare. | Introducere Order/Payment/Wallet/Commission state machines, webhook idempotent si reconciliere admin. `app/Services/Payment/*`, `app/Http/Controllers/WebhookController.php`, migrations, Web/Flutter checkout | 80-130 h |
Shipping, AWB, tracking, pickup | Location/Place si notificari; nu exista shipment domain complet | Livrare nationala, cost si AWB sau ridicare locala pentru mobilier; stari vizibile buyer/seller/admin. | Modele Shipment/Carrier/Pickup, adaptoare curieri, tracking events, tarife si politici; integrarea curierului se estimeaza separat dupa API. `app/Models/*`, `routes/api.php`, Admin/Web/Flutter orders | 100-160 h |
Retur, refund, disputa, protectie | Payment refund hooks si report/block ca baza; nu exista workflow order-after-sale | Termene, dovezi, responsabilitati si decizie pentru retur/refund/disputa; protectia cumparatorului trebuie definita. | State machine dispute, evidence storage, refund partial/total, SLA si audit log; legare la Order si Payment. `app/Services/Payment/*`, controllers, migrations, notifications | 60-100 h |
Reviews legate de tranzactie | Review/seller review controllers si rating models | Reviewul se publica numai dupa o tranzactie eligibila si nu poate fi duplicat. | Pastrare rating existent; adaugare order_id, eligibility query, migration si UI status. `app/Http/Controllers/*Review*`, `app/Models/*Review*`, migrations | 8-16 h |
Trust & safety | ReportReason, UserReport, block/unblock, seller verification | Raportarea, moderarea, suspendarea si verificarea sellerului trebuie sa aiba roluri, dovezi si audit. | Matrice moderation queue, Policies, reason taxonomy, KYC provider optional si notificari. `app/Http/Controllers/ReportReasonController.php`, `UserVerificationController.php`, permissions | 28-48 h |
Admin multi-rol | Spatie Permission, RoleController, controllerele CRUD existente | Staff opereaza limitat; Super Admin gestioneaza setari; fiecare actiune are allow/deny demonstrabil. | Completare metode lipsa, Policies/Form Requests, test matrix pe 5 roluri. `app/Http/Controllers/*`, `app/Policies/*`, `config/permission.php`, `routes/web.php` | 40-64 h |
Multi-country, limbi, monede | LanguageController, CurrencyController, PlaceController, translation traits | Lansare initiala RO/RON, ulterior tari/limbi/monede; continutul nu trebuie afisat in limba gresita. | Adaugare locale ro, RON, fallback, formatter si URL strategy Web; configurare tara/telefon Romania. `app/Http/Controllers/LanguageController.php`, `CurrencyController.php`, Web i18n, Mobile config | 24-40 h |
Design premium Maria | Layouturile Web/Flutter si componentele eClassify | Mockupurile Maria aprobate sunt criteriul vizual; setul transmis este partial si trebuie completat cu ecrane, stari si reguli responsive. | Inventar mockupuri, design tokens, componente marketplace, responsive states si test comparativ. Web `components/`, Flutter `lib/` screens/widgets | 56-88 h |
Total implementare cerinte produs: aproximativ 458-752 ore de lucru efectiv, fara costuri externe. Pentru lucru impreuna, aceasta inseamna aproximativ 12-18 saptamani la program complet sau 18-28 saptamani la program partial. Timpul nu include asteptarea dupa aprobari, credentiale, procesatori sau curieri.
1B. Directia de redesign bazata pe mockupurile Mariei
Redesignul este o axa separata a proiectului, nu o simpla ajustare cosmetica. Maria a transmis partial in discutia de pe Facebook directia vizuala si exemple de ecrane; acestea devin sursa de adevar pentru stil, ierarhie, componente si experienta marketplace. Pana la primirea tuturor mockupurilor, statusul corect este CONFIRMAT INCOMPLET: exista material de lucru, dar nu exista inca acoperire completa pentru toate fluxurile.
Etapa | Ce se livreaza Mariei | Dovada si acceptanta | Timp |
|---|---|---|---|
Inventar si directie | Catalogul mockupurilor primite, ecranele lipsa, user journeys si lista deciziilor vizuale. | Fiecare mockup este mapat la o ruta/ecran; diferentele si presupunerile sunt marcate explicit. | 8-12 h |
Sistem vizual | Tokenuri de culoare, tipografie, spatii, radius, umbre, iconografie, carduri, butoane, formulare, badge-uri si stari. | Componentele reutilizabile sunt documentate si au variante desktop, tablet, mobile, loading, empty si error. | 16-24 h |
Web marketplace | Redesign pentru landing, listare, cautare, categorie, anunt, profil seller, favorite, chat, autentificare si checkout. | Comparatie browser cu mockupul aprobat la viewporturile stabilite; fara overflow si fara componente duplicate. | 24-36 h |
Flutter/mobile | Paritate vizuala pentru onboarding, home, search, listing, item details, chat, notificari si cont. | Build Android si capturi de verificare pentru aceleasi stari ca Web; diferentele acceptate sunt notate. | 24-40 h |
Revizii si handoff | Lista diferentelor, revizia Mariei, inchiderea feedbackului si reguli pentru ecranele noi. | Maria aproba setul de ecrane; fiecare modificare are componenta, fisier si criteriu de acceptanta. | 8-16 h |
Rezultat asteptat: o experienta coerenta intre Web, Admin si Flutter, cu identitate vizuala Maria si cu un sistem reutilizabil pentru dezvoltarea ulterioara a platformei.
Verificare live web - rute si responsive
Testarea a fost executata in Chromium real, fara modificarea datelor. Rutele publice de baza au raspuns HTTP 200 in scenariile reusite, iar /landing redirectioneaza la /. Ruta /ads a avut si o navigare abortata; prin urmare nu este marcata automat functional pentru toate starile UI.
La viewport 390x844 nu s-a observat overflow orizontal pe paginile publice verificate. /profile, /favorites si /chat redirectioneaza Guest-ul la autentificare. Rutele admin redirectioneaza Guest-ul la /login. Dashboard-ul si CRUD-urile pozitive raman distincte si necesita sesiune autorizata persistenta; existenta structurala a rutei nu este considerata dovada de functionalitate completa.
Configurarea Web pentru productie este confirmata: build Next si lint sunt verzi, resolverul de mediu foloseste fallback local, canonicalele si sitemap-urile folosesc aceeasi origine, iar headerele Next de hardening sunt livrate. Catalogul RO nu exista in proiect; /ro/landing aplica limba implicita in mod controlat, fara a pretinde traduceri inexistente.
3. Dosar tehnic individual
Fiecare intrare leaga constatarea de rezultat, cauza, impact, zona de cod, solutie, criteriu de acceptanta si timp estimat.
AUD-001 - Actiuni admin fara handler
Rezultat | Inventarul rutelor identifica 20 actiuni care trimit catre metode inexistente; customer/create reproduce HTTP 500. |
|---|---|
Zona si cauza |
|
Solutie | Implementare handler, Form Request, Policy si persistenta pentru fiecare ruta sau eliminarea explicita a rutei. |
Acceptanta | Zero metode lipsa; CRUD valid, invalid si ID inexistent raspund coerent. |
Estimare | 40-60 h |
AUD-002 - Contract HTTP inconsistent
Rezultat | Mutatii si erori returneaza combinatii de HTTP 200, HTML gol si 500. |
|---|---|
Zona si cauza |
|
Solutie | Schema JSON comuna cu 2xx doar la succes si 422/403/404/500 pentru esec. |
Acceptanta |