Produs Theta One · Beta acum · GA vizat pentru toamna 2026
Etheria pornește de la o cerință aprobată și le dă inginerilor dumneavoastră un pull request de analizat.
Noi o operăm pe proiectul dumneavoastră. Nu se instalează nimic și nimeni din echipa dumneavoastră nu primește cont. Etheria este în Beta: nu există încă referințe publice de la clienți, iar disponibilitatea generală este vizată pentru toamna 2026.
etheria.ro este site-ul produsului — pipeline-ul pas cu pas, unde se potrivește Etheria și unde nu, și programarea unei prezentări Beta. Pagina aceasta răspunde la cealaltă întrebare: cine este în spatele produsului.
Ce cumpărați, de fapt
Etheria este un mod de a livra software, nu o licență și nu un seat. Un analist conduce sesiunea de cerințe și scrie specificația; cineva o aprobă; un agent AI scrie codul pe baza acelei specificații, pe infrastructura noastră; un Tech Lead verifică ce a ieșit, împreună cu rezultatele testelor; iar modificarea ajunge în repository-ul dumneavoastră ca pull request, pe care inginerii dumneavoastră îl fac merge sau îl resping.
Nu se instalează nimic la dumneavoastră. Platforma este a noastră și noi o operăm, motiv pentru care nu există cont de client — vedeți secțiunea Beta, pentru că este o lipsă reală, nu un principiu de design.
Comercial, intră într-un contract obișnuit de livrare cu Theta One Digiplex S.R.L. și se tarifează pe scope-ul lucrării, nu per seat, per utilizator sau per token.
Cum devine o cerință un pull request
Opt pași, în ordine. Dacă vreunul dintre ei vi se pare vag, spuneți-ne la telefon și vă arătăm ecranul pe care se întâmplă.
Proiectul este indexat înainte să se scrie ceva.
Construim un index de cunoștințe limitat strict la proiectul dumneavoastră: descrierea proiectului, milestone-urile, work item-urile curente și orice documente ne predați — note de arhitectură, contracte de API, specificații existente. Fiecare sursă este hash-uită, așa că o resincronizare reîncarcă doar ce s-a schimbat, iar modificările de fond marchează proiectul ca nesincronizat până la reconstruirea indexului. Indexul este ținut în serviciul de vector store al OpenAI. Este o informație despre prelucrarea datelor și o primiți acum, nu într-un chestionar peste trei săptămâni.
Un analist conduce sesiunea de cerințe cu modelul în cameră.
Technical BA-ul lucrează cerința împreună cu un model care are la dispoziție proiectul dumneavoastră indexat, așa că argumentează pornind de la sistemul dumneavoastră, nu de pe internet. Rezultatul sesiunii este transformat în propuneri structurate de task-uri — titlu, descriere, criterii de acceptanță — pe care analistul le editează, le respinge sau le acceptă. Salvarea propunerilor în backlog este o acțiune explicită a unei persoane cu nume. Nimic nu ajunge în backlog pentru că l-a produs un model.
O persoană mută work item-ul în READY_FOR_DEV. Asta lansează agentul.
Work item-urile trec prin BACKLOG → READY_FOR_DEV → IN_PROGRESS → READY_FOR_REVIEW → DONE. Trecerea în READY_FOR_DEV este cea care pune la coadă o rulare a agentului, iar tranziția o face o persoană, fie direct, fie aprobând un review. Modelul nu decide că o specificație este gata de construit.
Rularea are loc pe infrastructura noastră, pe branch-ul ei propriu.
Serviciul de agent clonează repository-ul, creează un branch numit agent/<task-id> și își aplică acolo modificările. Modificările de cod trec prin Responses API de la OpenAI sau prin Claude agent SDK de la Anthropic, alese per proiect. Rularea este înregistrată ca AgentRun, cu status și log propriu, iar starea ei se reflectă înapoi în work item: o eroare readuce item-ul în IN_PROGRESS, cu motivul atașat, nu într-un punct mort tăcut.
Build-ul și testele rulează într-un container care nu este aplicația.
Comenzile de setup, build și test se execută într-un container de runner ținut separat de API și de baza de date. Accesul la rețea al acelui container este o setare configurată, nu ceva pornit permanent, ceea ce înseamnă că un build care are nevoie să ajungă la un registry de pachete este o decizie luată de cineva și care poate fi arătată.
Rularea se termină la un pull request. Nu există pas de merge în pipeline.
La o rulare reușită, acolo unde engagement-ul este configurat pentru asta, agentul face commit, împinge branch-ul și deschide un pull request pe GitHub. Unde nu este configurat, nimic nu iese din infrastructura noastră și nu se scrie niciodată în repository-ul dumneavoastră. Nu există pas de merge în niciuna dintre configurații. Regulile dumneavoastră de branch protection, aprobările obligatorii, verificările de CI și reviewerii dumneavoastră se aplică acelui pull request exact cum se aplică celui deschis de un contractor.
O persoană cu nume aprobă înainte ca work item-ul să fie gata.
O rulare reușită mută item-ul în READY_FOR_REVIEW și item-ul nu poate ieși singur din starea aceea. Un Tech Lead citește diff-ul și rezultatele testelor și înregistrează APPROVE sau REJECT pe work item. REJECT vine cu un motiv și trimite item-ul înapoi. Apoi inginerii dumneavoastră fac review pull request-ului. Două review-uri, ambele făcute de oameni, ambele înregistrate.
Fiecare scriere este înregistrată, iar ștergerile sunt soft.
Modificările asupra utilizatorilor, clienților, proiectelor, milestone-urilor, work item-urilor, review-urilor și rulărilor de agent scriu fiecare câte o intrare de audit. Înregistrările sunt șterse soft, nu eliminate, așa că istoricul unui item supraviețuiește item-ului. Fișa de livrare a unui work item conține: cerința din care a pornit, specificația aprobată, rularea care a implementat-o, rezultatele testelor, pull request-ul și numele de pe ambele aprobări.
Technical BA și Tech Lead sunt roluri în Etheria, nu oameni diferiți. Într-un engagement dus de un singur practician sunt aceeași persoană în ambele roluri, iar înregistrarea spune exact asta — aprobarea poartă numele celui care a dat-o. Ce nu se schimbă este că aprobarea este un act înregistrat al unei persoane și că inginerii dumneavoastră fac review pull request-ului după aceea.
Ce înseamnă Beta dacă începeți acum
Ce există, ce nu există, ce ne-ar trebui de la dumneavoastră și partea pentru care chiar vă asumați un risc.
Funcționează astăzi
- Spațiul de lucru: acces pe roluri, verificări de apartenență per proiect, clienți, proiecte, milestone-uri și board-ul de work item-uri.
- Sesiuni de cerințe pe un index de cunoștințe limitat la proiect, care produc propuneri structurate de task-uri, salvate în backlog de o persoană.
- Rulări de agent pe modele OpenAI sau Anthropic, într-un container de runner separat, cu branch și commit, iar cu push și pull request pe GitHub acolo unde engagement-ul este configurat pentru asta.
- Gate-ul de review APPROVE / REJECT, cu motivul înregistrat, și traseul de audit de sub el.
- Monitorizarea rulărilor: clustere de task-uri, statusul rulării și log-urile, interogate și vizibile cât timp rularea este în desfășurare.
Încă neconstruit
- Fără cont de client. Etheria are trei roluri — ADMIN, TECH_BA, TECH_LEAD — și toate trei sunt ale noastre. Vedeți lucrul prin repository-ul dumneavoastră, prin pull request-uri și prin fișa de livrare pe care o exportăm și o parcurgem împreună.
- Deocamdată GitHub. Pipeline-ul rulează pe GitHub. Dacă folosiți alt sistem de control al versiunilor, întrebați-ne înainte să excludeți varianta. Este o chestiune de scoping și primiți un răspuns direct la primul apel.
- Nu a fost livrată nicio instalare on-premise. Este posibilă în principiu și reprezintă scope agreat înainte de semnare, cu termen și preț.
- Fără SOC 2, fără ISO 27001 și fără test de penetrare al platformei făcut de un terț.
- Fără SLA publicat și fără pagină de status.
- Fără referințe publice de la clienți. Vedeți ultimul paragraf al acestei secțiuni.
Ce ne-ar trebui de la dumneavoastră
- Un repository pe care îl putem clona și o comandă de build și de test care rulează într-un container, fără să fie cineva de față. Dacă build-ul dumneavoastră are nevoie de VPN, de un licence server sau de un artefact semnat manual, spuneți-ne la primul apel. Constrângerea aceasta decide potrivirea mai repede decât orice altceva de pe pagină.
- O persoană cu nume care poate aproba o specificație și un pull request. Pipeline-ul se oprește la un gate la care nu stă nimeni, iar asta este intenționat.
- Un prim work item care să fie real, dar care să nu stea pe drumul critic.
- Permisiunea ca un cont de mașină să poată clona, să împingă un branch și să deschidă un pull request.
Ce riscați, de fapt
Riscul real este ritmul, nu siguranța. O modificare ajunge pe branch-ul dumneavoastră principal doar printr-un pull request aprobat de inginerii dumneavoastră, după regulile dumneavoastră, exact ca la orice contractor — așa că o modificare neverificată nu este expunerea.
Ce nu garantează Beta este viteza. O rulare poate să eșueze. Un model poate produce un diff care nu merită timpul necesar ca să fie citit. Când se întâmplă asta, răspunsul este că un inginer scrie work item-ul de mână și tot primiți work item-ul, pe aceeași specificație, prin aceleași gate-uri. Ce riscați este ca pipeline-ul să ne economisească mai puțin timp decât ne așteptăm pe codul dumneavoastră și ca livrarea să semene mult cu una obișnuită. Aceea este o dezamăgire comercială, nu un incident.
Riscul acesta îl asumați față de o entitate anume: Theta One Digiplex S.R.L., cu sediul în București, este firma care construiește și operează Etheria și firma cu care semnați contractul.
Documentația de securitate
Un proces automat care are drept de push în sistemul dumneavoastră de control al versiunilor este o întrebare de supply chain, iar gate-urile de review nu sunt un răspuns suficient în sine. Documentul care răspunde corect este în lucru: modelul de acces și ce poate și ce nu poate face credențialul de git, izolarea execuției, lista de subprocesatori, rezidența și perioadele de retenție a datelor, și termenii de antrenare ai furnizorilor de modele pe conturile pe care le folosim efectiv. Nu este gata, așa că pagina aceasta nu îl rezumă. Dacă vă trebuie ca să evaluați un pilot, cereți-l și vi-l trimitem în ziua în care există.
Încă un lucru, pentru că schimbă felul în care ar trebui citit restul acestui site. Logo-urile de clienți de pe thetaone.digital sunt engagement-uri de Technical Business Analysis. Nu sunt clienți Etheria. Etheria nu are încă referințe publice de la clienți. Când va exista una, va purta un nume și acordul scris al clientului.
Etheria este practica de analiză, industrializată
Partea mai mare din Theta One este Technical Business Analysis: cineva stă în echipa de livrare a clientului și scrie specificațiile după care construiește echipa aceea. Așteptarea dintre o cerință aprobată și momentul în care o preia cineva este de obicei mai lungă decât construcția, iar a treia revizuire a unui criteriu de acceptanță cu care nu a fost nimeni de acord costă mai mult decât amândouă.
Etheria ia părțile mecanice ale acelei munci (indexarea a ceea ce se știe deja despre sistem, redactarea propunerilor de task-uri dintr-o conversație despre cerințe, crearea branch-ului, rularea testelor) și le dă unei mașini, lăsând fiecare decizie de judecată legată de un nume. Gate-urile din pipeline sunt gate-urile pe care un analist bun le rulează oricum de mână. Metoda nu este nouă. Nou este că așteptarea dintre gate-uri este aproape zero.
Dacă Beta înseamnă mai mult risc decât doriți
Atunci nu îl luați. Începeți cu un Technical Business Analyst integrat în echipă, pe un contract obișnuit. Aceasta este activitatea noastră principală și nu vă angajează cu nimic în privința AI. Primiți aceeași guvernanță: specificații cu criterii de acceptanță și cazuri limită, o trasabilitate de la cerință până la rezultatul testului și o persoană cu nume responsabilă la fiecare pas. Etheria vine opțional peste asta, mai târziu, pe un work item ales de dumneavoastră. Cea mai mare parte din ce descrie pagina aceasta a început ca o listă de verificare făcută manual, exact într-un astfel de engagement.
etheria.ro este locul în care stă produsul
etheria.ro duce ce nu duce pagina aceasta, în mod deliberat: pipeline-ul pas cu pas, cele patru puncte în care o persoană trebuie să semneze, unde se potrivește Etheria și unde nu, termenii programului Beta, întrebările frecvente despre produs și un calculator de cost. Documentația de securitate și de prelucrare a datelor se publică tot acolo, în momentul în care este gata. Același produs, aceeași firmă. thetaone.digital rămâne sursa autoritară pentru tot ce ține de firmă, de contract și de oameni.
O prezentare înseamnă un screen share cu un work item real dus prin pipeline: sesiunea de cerințe, rularea agentului, rezultatele testelor, gate-ul de aprobare și fișa rezultată. Aproximativ o oră. Nu este nevoie de acces la repository și nici de NDA ca să participați.