Ordine di build e domande aperte
Ordine di build
Non tutto ciò che è descritto in questa documentazione è lavoro della prima fase. Sequenza suggerita:
Phase 0 — Offload, solo configurazione
VS Code Server dietro il Cloudflare Tunnel esistente, con Cloudflare Access davanti.
dev. come hostname singolo; appiattire qualsiasi naming annidato (api-dev.,
worker-dev.) per restare nella copertura del wildcard certificate. Nessun codice
scritto.
Phase 1 — La pipeline come CLI
Schema del risultato e profilo di validazione progettati prima, su carta. Poi snapshot
e hashing, poi check deterministici, poi check / submit. Usata quotidianamente sul
lavoro corrente, che è il modo in cui viene debuggata prima che qualcun altro ne dipenda.
Phase 2 — Piattaforma minima, al primo collaboratore
gateway, task-service, workspace-orchestrator (tramite Coder), vcs-service, audit-service. Review manuale da parte di un umano invece di gate automatizzati. Sufficiente per pagare i collaboratori.
Phase 3 — Hardening, a volume
Isolamento del build-service, gate automatizzati di architettura e sicurezza, check LLM calibrati rispetto a un evaluation set reale, job-runner con streaming.
Phase 4 — Community e credenziali
profile-service, pagine pubbliche, schema Open Badges, documentazione e corpus Q&A — che raddoppia come corpus di training per il support agent.
Domande aperte
| Domanda | Stato |
|---|---|
| Livello di hardening del runtime: Docker semplice, gVisor, o microVM per collaboratore | Aperta |
| Build vs adozione per l'orchestratore (Coder è il candidato principale) | Aperta |
| Dove vive l'evaluation set LLM e chi lo cura | Aperta |
| Se il catalogo challenge viene filtrato per collaboratore dal primo giorno | Aperta |
| Modello di attribuzione se un collaboratore contesta un record di audit | Aperta |