Acasă/Metode

Proces · Afirmații despre produs

Poarta de onestitate: nicio funcție promisă fără dovadă în cod

Înainte de orice trimitere la review comparăm fiecare afirmație de pe pagina de planuri, din listare sau din paginile publice cu codul care ar trebui s-o susțină. O afirmație rămâne doar dacă un comerciant poate ajunge la o implementare care funcționează; altfel construim funcția sau ștergem afirmația. Un script prinde cazurile mecanice, restul îl citim de mână.

Actualizat 2026-10-11

Cum am aflat

Pe 13 iulie 2026 unul dintre noi a apăsat în FAQ Genie butonul care pornea perioada de probă de 7 zile și nu s-a întâmplat nimic. Urmărind firul prin aplicațiile noastre Shopify am aflat că butonul de upgrade era mort în 14 din 17 aplicații, că trei aplicații ar fi creat în producție abonamente de test și că vindeam funcții care nu existau.

Patru aplicații nu aveau un produs real. Una afișa metrici de reclame produse de un generator de numere aleatoare, una vindea videoclipuri fără să aibă vreun encoder, una audita evenimente scoase dintr-un generator pseudoaleator, iar una vindea actualizări programate de preț fără niciun planificator. Alte patru aveau un nivel plătit care nu deschidea nimic. TermForge, aflată atunci în review, publica o pagină de protecție a datelor care spunea că nu poate citi comenzi, în timp ce configurația ei cerea acces la comenzi. În mai multe depozite exista un fișier de texte care marca de nepromis exact funcțiile pe care pagina de planuri le vindea apoi.

Nimic din toate astea n-a fost intenționat. Textele s-au scris înaintea produsului și, la final, nimeni nu le-a comparat. Poarta de onestitate e exact comparația asta.

Regula

Niciun punct fără dovadă în cod și nicio pagină fără dovadă în cod. Un punct de pe pagina de planuri, o afirmație din listare sau o frază din paginile de confidențialitate, termeni, întrebări frecvente ori protecția datelor pot exista doar dacă le susține o implementare accesibilă. Accesibilă înseamnă că un comerciant ajunge la ea din interfață sau că un worker, un webhook ori o sarcină programată chiar o rulează. Codul care există, dar nu e apelat niciodată, nu e o funcție.

Când o afirmație nu e adevărată, avem două variante: o construim sau o ștergem. La prima remediere, agenților li s-a cerut să construiască atunci când munca era mică, iar ei au livrat planificatoare reale, exporturi CSV, un web pixel și un generator video. Acolo unde o funcție depindea de o aprobare externă, nu de cod, am scos complet nivelurile plătite, am șters promisiunile din toate paginile publice și am scris un avertisment de date demonstrative chiar în fișierul exportat, pentru că un fișier trăiește mai mult decât un banner.

Jumătatea mecanică: un script

Un script rulează verificări automate pe codul fiecărei aplicații și se oprește cu eroare la orice blocaj. Prima versiune avea 12. Ele caută: un drum de upgrade care înghite semnalul de succes sau nu-și afișează niciodată eroarea; facturarea de test ca valoare implicită; o coadă prioritară plătită care merge invers (în biblioteca noastră de cozi 0 e și valoarea implicită, și prioritatea cea mai mare, iar trei aplicații le dădeau clienților plătitori 1); automat sau programat vândut fără o sarcină repetitivă înregistrată; un apel de model fără contor în față; un indicator de plan pe care nu-l citește nimic; numele aplicației-șasiu scăpat în paginile publice ale unei copii; o pagină de protecție a datelor care contrazice permisiunile declarate; un drept de acces verificat în interfață, dar nu în acțiune sau în worker; o înregistrare citită după id fără să fie restrânsă la magazinul curent.

De atunci, fiecare respingere a devenit o verificare, confirmată pe codul de dinaintea reparației: câmpuri de formular cu nume, dar fără valoare sau handler de schimbare, în care recenzentul nu poate scrie; o rută de autentificare fără componentă, care afișa un simplu null; redirecționarea de facturare care arată un 401 în iframe; un web pixel care apela register fără să-l importe și, prin urmare, nu rula niciodată. Pixelul acela colectase zero evenimente pentru fiecare magazin care îl instalase vreodată, inclusiv patru magazine de review.

O poartă care raportează blocaje pe cod corect ajunge ignorată, și exact așa s-au ascuns erorile reale de la început. Prima versiune a dat patru blocaje false; fiecare corectare e acum un comentariu în script care explică de ce verificarea e îngustă.

Jumătatea manuală: tabelul afirmațiilor

Niciun script nu poate spune dacă o frază e adevărată. Pentru fiecare afirmație scriem un rând: afirmația, verdictul și dovada, sub formă de fișier și linie. Verdictul e funcționează (implementat, accesibil și face ce spun cuvintele), parțial (real, dar mai restrâns decât cuvintele) sau lipsește. Judecăm cuvintele, nu intenția. Unele cuvinte mint mai des decât altele: nelimitat, fiecare, tot catalogul, automat, programat, prioritar, alerte, mai multe magazine, export.

Numărul de potriviri dintr-o căutare nu e o dovadă. Un simbol poate exista ca tip, ca schelet sau ca cod mort. Un astfel de schelet întorcea textul literal draft-order-deposits-coming-soon, în timp ce pagina de planuri vindea funcția. Deschidem fișierul și urmărim lanțul de apeluri până la un punct de intrare din interfață sau până la un worker. Un număr din text trebuie să fie numărul din cod: o aplicație vindea modificări în bloc pe fiecare pagină auditată și le limita la 500, iar „istoricul complet” păstra 365 de audituri. O coloană din baza de date pe care n-o citește nimic nu e o funcție, iar o gardă care depinde de un câmp pe care nu-l scrie nimic nu va rula niciodată.

Cea mai grea clasă e funcția apelată, legată până în interfață, care raportează succes pentru o muncă pe care n-a făcut-o. Una dintre aplicațiile noastre avea un modul de integrare al cărui antet descria fiecare funcție drept schelet; aplicația afișa o insignă verde de sincronizare și contoriza o unitate facturabilă pentru exact funcția după care se numea. Scriptul a trecut-o cu zero blocaje. Pentru orice afirmație care mută bani sau atinge un sistem extern citim acum corpul funcției care o îndeplinește și căutăm pe fiecare drum promis cuvintele stub, TODO, scaffold și coming soon.

Dovedim efectul, nu codul

Codul poate fi corect, iar efectul să lipsească. Pagina de solduri a TermForge citea rânduri pe care webhook-ul de comenzi trebuia să le scrie. La sursă sosiseră 72 de webhook-uri și toate fuseseră ignorate, deci funcția de bază nu rulase niciodată. Acum întrebăm despre fiecare panou ce scrie rândurile pe care le citește și numărăm webhook-urile primite față de rândurile salvate.

Testele pot consfinți o eroare. O încasare pica la fiecare încercare pentru că o cheie de idempotență avea 40 de caractere, față de o limită a platformei de 32, iar testul unitar verifica tocmai forma de 40 de caractere. Simulările pot fi mai îngăduitoare decât platforma. Într-unul dintre add-on-urile noastre pentru Google Workspace, o simulare răspundea la un apel pe care permisiunea declarată îl refuză, iar suita a rămas verde în timp ce Outline nu funcționa pentru nimeni, pe niciun document: 13 instalări și zero deschideri în 10 zile. Simulările noastre țin acum o listă de metode permise pentru fiecare obiect și aruncă eroarea platformei la orice altceva, iar le verificăm prin mutație: punem eroarea înapoi și suita trebuie să se înroșească.

De aceea, pentru tot ce atinge bani sau o platformă, ultimul pas e fluxul real pe un magazin real: plasăm comanda, vedem rândul apărând, apăsăm butonul de încasare și vedem comanda marcată ca plătită.

Unde am greșit

Am crezut că un audit atent e suficient. A doua zi, o nouă trecere, cu 11 aplicații deja în review, a găsit încă șase erori reale. Printre ele: o aplicație al cărei produs întreg nu putea fi creat, pentru că extensia și permisiunile ei nu ajunseseră pe platformă; o funcție plătită de prim-plan pe care oricine o putea folosi în continuare după ce anula perioada de probă; un comerciant care putea citi înregistrările altuia; consumul de model fără limită superioară, pentru că apelurile eșuate erau gratuite, iar eșecul putea fi provocat de comerciant; o pagină care descria o verificare de siguranță ce nu rula niciodată. Prima trecere nu prinsese niciuna.

Cea mai gravă eroare din trecerea aceea a fost a noastră, scrisă în timp ce le reparam pe celelalte. Un webhook de facturare apela o funcție cu o variabilă care nu exista în contextul lui. Build-ul a fost verde pentru că cinci aplicații nu verificau tipurile în rute, codul a ajuns în producție și niciun magazin n-ar fi putut începe să plătească. Un subagent care porta aceeași modificare în altă aplicație a prins-o citind pachetul livrat. De atunci, orice reparație pe un drum de bani primește un al doilea evaluator, iar rutele trebuie să treacă prin verificarea tipurilor.

Și poarta însăși a mai greșit după aceea. A acceptat o verificare de null drept verificare de plan și a semnalat cod funcțional care își ținea logica de anulare în alt fișier. Le-am corectat pe amândouă, pentru că o poartă pe care nu o mai ascultă nimeni e exact locul în care s-au ascuns erorile reale prima dată.

Limite

Poarta arată că lipsesc clasele cunoscute și că fiecare afirmație are o implementare accesibilă. Nu arată că implementarea e corectă, că platforma o acceptă sau că funcția e dorită de cineva. E o verificare automată, nu un oracol. Tabelul afirmațiilor și fluxul real rămân manuale și, până acum, fiecare respingere nouă a adăugat o clasă pe care nu o aveam.

Lista de verificare

Rulăm scriptul pe aplicație și reparăm fiecare blocaj. Scriem tabelul afirmațiilor pentru fiecare punct din planuri, fiecare rând din listare și fiecare pagină publică, cu fișier și linie. Construim sau ștergem fiecare rând parțial sau lipsă. Găsim constanta din spatele fiecărui număr afișat.

Citim corpul fiecărei funcții din spatele unei afirmații despre bani sau despre un sistem extern. Numărăm webhook-urile primite față de rândurile salvate. Apăsăm upgrade-ul într-un browser real până pe pagina de aprobare a Shopify. Cerem altcuiva să verifice reparația pe orice drum de bani. Rulăm din nou poarta după orice schimbare a paginii de planuri, a unei pagini publice, a facturării sau a unui apel de model.

Întrebări și răspunsuri

Cum mă asigur că pagina de prețuri a unei aplicații promite doar funcții care există?

Ca pagina de prețuri a unei aplicații să promită doar funcții reale, fiecare afirmație trebuie comparată cu codul care ar trebui s-o susțină, înainte de trimiterea la review. Fiecare afirmație primește un rând cu verdictul funcționează, parțial sau lipsește și cu dovada sub formă de fișier și linie. Afirmația rămâne doar dacă un comerciant ajunge la o implementare funcțională. Restul se construiește sau se șterge.

Ce înseamnă o funcție reală atunci când verific afirmațiile unei aplicații în cod?

O funcție reală este una la care un comerciant ajunge din interfață sau pe care un worker, un webhook ori o sarcină programată chiar o rulează. Codul care există, dar nu e apelat niciodată, nu e o funcție. Nici o coloană pe care n-o citește nimic nu e o funcție, iar o gardă legată de un câmp pe care nu-l scrie nimic nu rulează. Numărul de potriviri dintr-o căutare nu e dovadă.

Poate un script automat să verifice dacă promisiunile unei aplicații sunt adevărate?

Un script automat prinde cazurile mecanice, dar nu poate spune dacă o frază e adevărată. Verificările automate pot semnala facturarea de test ca valoare implicită, funcții programate fără o sarcină repetitivă înregistrată, indicatori de plan pe care nu-i citește nimic sau pagini de confidențialitate care contrazic permisiunile declarate. Potrivirea dintre afirmație și cod cere totuși un tabel al afirmațiilor completat de mână.

De ce pot testele care trec să ascundă o funcție stricată într-o aplicație?

Testele care trec pot ascunde o funcție stricată pentru că un test poate consfinți o eroare, iar simulările pot fi mai îngăduitoare decât platforma. Un test unitar poate verifica exact valoarea greșită pe care o produce codul, iar o simulare poate răspunde la un apel pe care platforma îl refuză. Simulările trebuie să arunce eroarea platformei, iar fiecare reparație se dovedește punând eroarea înapoi și văzând suita picând.

Cum verific că facturarea și webhook-urile unei aplicații funcționează cu adevărat?

Verificarea facturării și a webhook-urilor unei aplicații înseamnă să dovedești efectul, nu doar codul. Pentru fiecare panou întrebi ce scrie rândurile pe care le citește și numeri webhook-urile primite față de rândurile salvate. Pentru tot ce atinge bani rulezi fluxul real pe un magazin real: plasezi comanda, vezi rândul apărând, apeși butonul de încasare și vezi comanda marcată ca plătită.

Toate metodele