Platforma de livrare Wizeri
Fiecare rol dintr-o echipă de livrare, jucat de un agent — separarea responsabilităților prin design, cu omul păstrat doar la cele două decizii care contează.
Șase etape, un singur pipeline
Fiecare rol dintr-o echipă de livrare, codificat ca o poartă pe care lucrarea trebuie s-o treacă — niciodată un singur agent care decide că e gata.
- 1
Specificație și arhitectură
Transformă o cerere în limbaj natural într-o specificație structurată cu criterii de acceptare verificabile, pornind de la codul real. Se oprește pentru aprobare.
- 2
Implementare și review
Implementează conform specificației, în stilul propriu al proiectului, apoi un agent independent revizuiește fiecare diff ca un inginer senior exigent — logică, cazuri limită, convenții.
- 3
Securitate și audit
Rulează necondiționat la fiecare modificare — lacune de autentificare, scurgeri în izolarea datelor, riscuri de injecție — cel mai ieftin bug de prevenit, cel mai scump de livrat.
- 4
Testare și end-to-end
Scrie teste unitare și de integrare, apoi pornește aplicația reală și o parcurge într-un browser — așa cum un inginer QA validează o versiune.
- 5
Vânătoare adversarială de bug-uri
O ultimă trecere independentă care caută ce nu dovedesc celelalte porți: race conditions, stări abandonate, bug-uri de limită, regresii silențioase.
- 6
Deploy — la comanda ta
Verificări preliminare, un plan declarat și o oprire deliberată. Punerea în producție este o acțiune umană confirmată, niciodată un efect secundar al testelor trecute.
Cum începe o colaborare
Nimic de instalat, nimic de rulat de partea clientului. Un singur acces minimal acordat, iar restul operăm noi.
- 1
Un token GitHub cu scop limitat
Un token fine-grained limitat la un singur repository, cu exact două permisiuni: Contents și Pull requests, ambele read/write.
- 2
O specificație structurată
Fiecare colaborare pornește de la o specificație informată de cod, cu criterii de acceptare verificabile — propusă mai întâi, implementată doar după aprobare.
- 3
Pull Request-uri în propriul tău repo
Fiecare modificare ajunge ca Pull Request revizuit în repository-ul propriu al clientului — niciodată push direct, niciodată auto-merge.
- 4
Clientul păstrează butonul de merge
Review-ul și merge-ul rămân decizia clientului, în ritmul clientului.
- 5
Deploy în producție — opțional
Disponibil ca mod per colaborare. Când este activ, o modificare integrată intră în producție doar după o acțiune de deploy separată, explicită și aprobată de un om — niciodată automat.
Securitate prin construcție
Fiecare afirmație de mai jos corespunde unui mecanism, nu unui certificat.
Izolare per client, instanță dedicată
Fiecare client rulează pe o instanță dedicată, single-tenant — propriul container, propria bază de date, propria configurație. Fără bază de date partajată, fără tenant ID-uri, fără nicio cale de date între clienți.
Livrare doar prin PR, fără auto-merge
Fiecare modificare ajunge ca Pull Request în repo-ul propriu al clientului — niciodată push direct pe branch-ul principal, niciodată auto-merge.
ip-guard verifică fiecare diff
Înainte de orice push, un filtru dedicat scanează întregul diff livrat și îl blochează dacă găsește fișiere din tooling-ul nostru sau o valoare de token în conținut.
Token GitHub minimal, fine-grained
Limitat la Contents (read/write) și Pull requests (read/write) pe un singur repository — nimic mai mult, fără acces la nivel de organizație sau de cont.
Aprobări atribuite unui om
Deciziile de aprobare nu sunt luate niciodată automat de cod — fiecare este o acțiune umană explicită, înregistrată cu un eveniment de aprobare marcat temporal.
Backup-uri în regiunea UE
Backup-urile nocturne sunt stocate exclusiv în object storage din regiunea UE — niciodată rutate în afara UE.
Nu un asistent de programare — o echipă. Nu se vinde ca produs pe abonament; este prezentată aici ca dovada proprie de capabilitate a Wizeri.
Vezi-o live →