Panoramica — dev.vinovalab.ai
Documento di riferimento per la piattaforma di sviluppo remoto: come è decomposta in servizi, cosa possiede ciascuno e dove si trovano i confini di fiducia.
Bozza di design. Non tutto ciò che è descritto qui viene costruito nella prima fase — vedi "Ordine di build" alla fine.
Il vincolo di design che modella tutto
La piattaforma permette a collaboratori esterni di lavorare su porzioni isolate di un codebase proprietario, assistiti da un LLM, e di essere pagati per ogni challenge completato. I collaboratori sono verificati (CV, colloquio, documenti, contratto) ma non sono dipendenti e non sono affidabili con l'intero sistema.
Due conseguenze guidano l'intera architettura:
I quality gate non sono controlli di sicurezza. I check di coerenza, architettura e test rilevano errori onesti. Non fermano l'intento ostile — chiunque voglia aggirarli può fare il mock dei test, scrivere codice che si comporta diversamente sotto CI, o inviare un Dockerfile ostile. Mantieni i gate per la qualità; metti il confine di sicurezza altrove.
Il confine di sicurezza è al livello di esecuzione. La domanda non è "questo codice è permesso" ma "cosa può raggiungere questo processo". Tutto ciò che segue deriva da questo.
Tier di privilegio
I servizi sono raggruppati per quello che possono raggiungere, non per quello che fanno. Questa è la decomposizione primaria; il raggruppamento funzionale è secondario.
| Tier | Può raggiungere | Raggiungibile da |
|---|---|---|
| Tier 0 — Non fidato | Solo il proprio workspace montato | Nessuno (è lui a iniziare) |
| Tier 1 — Mediazione | Servizi applicativi, ACL store | Tier 0, solo su API autenticata |
| Tier 2 — Applicazione | I propri dati, altri servizi Tier 2 | Solo Tier 1 |
| Tier 3 — Privilegiato | Host, credenziali, registry, VCS | Solo Tier 1, via structured intent |
La regola che non deve mai essere violata: un workspace Tier 0 parla solo al gateway. Mai direttamente al database, al servizio VCS, al servizio di build o all'orchestratore.