Voost Control · 20 iulie 2026 · staging izolat, date reale de producție
Valul de 8 PR-uri: merită merge pe main și deploy?
10 agenți de test, sute de verificări pe copia datelor reale. Izolarea a ținut la toate cele 6 probe adversariale. S-au găsit 3 probleme: 2 reparate și retestate live, 1 e decizie de produs (mai jos). Producția a fost atinsă doar cu citiri.
Cum s-a testat, în 3 propoziții
Un server separat pe 127.0.0.1:4141, pe un branch cu toate cele 8 PR-uri îmbinate, cu o copie completă a bazei de producție (59 MB, luată doar prin citire). Serverul nu are nicio cheie de provider — SmartBill, WhatsApp, Telegram, ClickPhone, Necesit sunt neconfigurate, deci orice încercare de trimitere moare din construcție. Agenții au avut voie să scrie orice pe staging și să compare cu producția doar prin citiri.
Ce PR-uri sunt în val
#1327 (--select funcțional), #1328 (erori oneste la id-uri greșite pe calls), #1329 (corecția datei apelurilor — al tău), #1330 (conversațiile text devin „message”, nu „call” — al tău), #1331 (search cu extrase scurte, nu documente întregi), #1332 (voost today slăbit sub bugetul de 50KB), #1333 (filtre invalide resping zgomotos), #1334 (referințe de entități exacte-sau-refuz).
Câștigurile, măsurate pe datele tale
Fiecare byte din răspunsuri e context plătit de agenți la fiecare comandă. Apasă butonul și compară.
„voost today” e prima comandă a fiecărei sesiuni de agent — o plătești de zeci de ori pe zi. Căutarea „București” returna 11.574.552 de bytes pentru că băga documente întregi în rezultate; acum returnează extrase de maxim 250 de caractere. Proiecția completă rămâne disponibilă la cerere (--include projection) — nimic nu s-a pierdut, s-a mutat pe opt-in.
Un fix de încredere, nu doar de mărime
Azi, dacă un agent greșește un identificator, primește clientul greșit cu aer de succes. Încearcă:
Pe staging s-a găsit și un caz real: doi clienți amândoi „Rowsen”. Valul refuză să ghicească și listează ambele UUID-uri. Înainte, alegea silențios primul.
Ce a găsit staging-ul (și de-asta există)
Fix-ul inițial curăța coloanele de path, dar path-urile scrise în text liber (descrieri de proiect) tot apăreau. 7 scurgeri în 20 de căutări.
Retestat live pe staging după fix: 0 scurgeri, înregistrările rămân găsibile inclusiv căutând path-ul întreg.
Regexul cerea doar versiunile 1–5 de UUID; Postgres acceptă și nil/v6/v7/v8. Lărgit în toate cele 3 locuri (CLI Node, CLI Go, server), cu validatorii de scriere lăsați intenționat stricți.
PR-ul #1330 include o migrare care schimbă și cele 3 conversații WhatsApp existente (cu Bogdan de la Red Angels) din „call” în „message” — nu doar importurile viitoare.
Partea importantă: migrarea implementează exact punctul 3 din issue-ul #1315 așa cum a fost aprobat („optional one-off backfill”). Iar pe datele reale s-a dovedit chirurgicală: apelul telefonic real rămâne „call”, mesajele preexistente rămân neatinse, doar cele 3 conversații text sunt retipizate.
Recomandare: accept-o. Istoricul devine corect (o conversație WhatsApp chiar nu e un apel). Alternativa: scoatem migrarea din val și rămâne doar pentru importurile noi — spune-mi la merge.
Izolarea, dovedită adversarial
Un agent a avut misiunea inversă: să spargă izolarea. A eșuat la toate 6 probele — apasă pe fiecare pentru dovadă.
Paritate: nimic altceva nu s-a schimbat
| Verificare | Rezultat |
|---|---|
| Suprafețele neatinse de val (clients, projects, conta, opportunities…) | structură identică cu producția |
| calls inbox — 20 de apeluri | byte-identic: 3.056.505 B |
| Numărătorile pe filtrele de propuneri (5 statusuri) | identice cu producția |
| Căutare: seturi de rezultate pe 6 query-uri identice | aceleași înregistrări găsite |
| 16 pagini de UI pe staging | toate 200, zero erori 500 |
| Funcțiile noi (corecția datei, import „message”, gate-ul de evidență) | toate au trecut end-to-end |
Testul tău, aplicat
Ai cerut trei lucruri. Iată-le bifate cu dovezi, nu cu promisiuni:
Producția a fost atinsă doar prin citiri (pg_dump + comenzi de comparație). Proba tare: numărătorile din 4 tabele de producție, înainte și după scrierile de test pe staging — identice.
Serverul de staging nu are nicio credențială de provider în mediu. Verificat în procesul viu, nu doar în fișiere. Zero conexiuni în afara mașinii pe toată durata testelor.
−81% la comanda de start de sesiune, −99,9% la căutarea grea, id-urile greșite nu mai aduc clientul greșit, erorile spun adevărul. Plus: staging-ul și-a făcut treaba găsind 3 probleme înainte de producție.
Pașii de merge (rezoluțiile de conflict sunt documentate pe fiecare PR): #1334 → #1331 → #1333 → #1327 → #1332 → #1328 → #1330 → #1329, regenerare inventory după fiecare, apoi pnpm run deploy. Decizia R2 se ia la merge-ul lui #1330.