05 - Stato e prossimi passi

Cosa abbiamo fatto¶

Parte	Risultato sostenuto dalle evidenze
Fondamenta	Progetti, rete, SQL, archivi, code di base e identità predisposti; state bootstrap/stage separati
Access	Backend e migratore distribuiti, IAM di prima creazione ristretto, tracce e metriche ricevute
Farm, aggiornamento 10 novembre	Rollout, SQL, cinque casi S2S e cleanup riusciti; finestra IAM chiusa. Metriche e una traccia ricevute, no-op migratore verificato con i limiti documentati. Dettaglio
Pipeline comune	Rilascio ordinario Access e retry reale SQL-free verificati; stesso candidato/artefatti dopo il guasto, vecchio errore conservato e richiesta duplicata rifiutata. Cleanup completato, piani finali senza differenze
Accessi team	Gruppi e grant configurati e riletti; ogni operatore verifica le azioni assegnate nel normale primo uso. Nessuna sessione dedicata Lorenzo richiesta per procedere
Profili ulteriori	Profili di accesso SQL, eventi, Job ed edge predisposti in parte nel codice; mancano collaudi cloud. La delivery di ulteriori scrittori dello stesso schema richiede anche un'estensione.

Access e il backend minimo Farm sono online nello stage privato; il secondo sistema ha superato il collaudo di delivery e accessi previsto. È registrata anche la fixture temporanea access-recovery con pipeline separata, usata per collaudare il recupero e poi rimossa: non è un nuovo prodotto. Gli altri sistemi completano l'enrollment durante lo sviluppo. Console ha preparazione e identità, ma non è online. Evidenze e limiti.

L'allineamento infra è unito nelle PR #26 e #27; la doc è allineata con la PR #90 e i risultati pubblicati con la PR #91, commit 8519f8e43160. Sono passati 82 test Python, 63 test Terraform bootstrap e 93 test stage. Sono state applicate con successo 2 aggiunte bootstrap e 4 stage, tutte IAM, senza aggiornamenti o cancellazioni. I piani successivi a d5904b non mostrano differenze. Il kit reale è verificato e le letture Service/Job/Execution di Jacopo funzionano senza impersonazione. Fonti e ricevute. Nessuna prova effettiva dell'account di Lorenzo o chiusura dell'intera base è ancora dichiarata.

Access PR #30 è unita a 99f7c780: 14 verifiche offline, 98 test Rust e Compose riusciti; ambiente locale di prova ripulito. Il publisher cloud 31b73c94-d3d6-49d7-913d-8c15ba992019 e la preparazione dfc9b103-8920-4a1e-a107-cd78bcfbf3e6 sono riusciti. Riaprire il comando ha ritrovato il publisher originale senza crearne un altro.

Il nuovo rollout access-stage-0001 della release access-0b88f714f6c8e3f668343ac04ccdeedb7f83f582a3b9f04d è riuscito: migratore access-migrate-k57km concluso alle 17:47:36 UTC, prima del deploy del backend alle 17:47:39 UTC. Nessuna migrazione mancante, grant SQL stage rieseguiti; revisione access-backend-mw9jv7nr Ready, immagine/identità verificate e 100% del traffico. La nuova sonda ha completato 360 richieste HTTP 200; tracce e metriche sono ricevute, Job/identità/grant temporanei rimossi. Collaudo completo e limiti.

Un secondo rilascio dello stesso commit è riuscito con revisione access-backend-mw9le435. Il tentativo controllato di interrompere il predeploy si è fermato prima di inviare cancellazioni: è quindi un'altra release ordinaria, non un retry positivo. La seconda revisione ha completato richieste, telemetria e cleanup; la sonda ha richiesto una ripetizione dopo un primo 403 di causa non accertata. La scheda 09 separa i due run: il retry Cloud Deploy non è stato eseguito in quei run; la successiva prova positiva è nella scheda 10.

Consegna iniziale e completamento dei profili¶

La consegna iniziale rende autonomo il rilascio delle API: standard verificato, procedura Access, onboarding del backend e del migratore Farm già disponibili, accessi SQL/S2S pertinenti e operatività minima. Farm verifica un secondo sistema reale; una sonda temporanea in Platform ne prova separatamente l'accesso fra progetti. Non occorre completare il prodotto Farm o Console.

Per SQL chiudiamo il percorso un backend + un migratore separato per sistema, già provato con Access. Il runtime non modifica la struttura; il migratore applica le modifiche versionate e la nuova revisione del backend viene distribuita solo dopo il successo del predeploy. Un altro sistema con questo profilo richiede la propria registrazione e verifica, non l'estensione per scrittori aggiuntivi.

Un secondo componente scrivente sullo stesso schema, come un consumer di Access, usa i profili service-runtime-sql e job-runtime-sql (11 novembre), con il controllo dello schema all'avvio e l'ordine dei rilasci per componente. Restano da collaudare dal vivo, con i primi rilasci dopo il reset dello stage; non serve un nuovo orchestratore né il rilascio simultaneo di tutti i componenti. Decisioni e lavoro residuo SQL.

Il completamento progressivo dei profili resta nel piano: readonly, Pub/Sub push, Scheduler HTTP, Job senza SQL e componenti SQL aggiuntivi. Non blocca l'uso ordinario dei profili già accettati; ciascuna estensione va chiusa prima dell'uso ordinario che la richiede.

Web staff, client finali e produzione sono consegne separate. Nuove combinazioni, come Job applicativi con SQL o altre toolchain, richiedono un'estensione esplicita; non sono automaticamente supportate.

Stato dei quattro passi e lavoro residuo¶

Aggiornamento configurazione Farm, 10 novembre: il collaudo registrato riguarda il commit fc5d06e, non ogni versione successiva di main. Il nuovo backend richiede configurazione di Access, archivi e Secret Manager che il vecchio manifest non forniva. L'allineamento comprende manifest, permessi mirati e un controllo comune dei requisiti prima del rilascio. La prova del binario in un container senza rete verifica la configurazione; IAM e funzionamento applicativo si verificano separatamente. Una nuova release Farm resta necessaria dopo questo allineamento: gli aggiornamenti Terraform non distribuiscono il backend. La scheda Farm descrive i limiti, senza riaprire o invalidare le prove del primo onboarding.

Passaggio	Cosa fare concretamente	Finito quando
1. Standard comune	Allineamento eseguito fra modello, documentazione e strumenti: mantenerlo quando si estende un profilo.	Campi, validazioni e limiti sono espliciti; non servono schede complete di tutti i sistemi.
2. Rilascio autonomo	Flusso ordinario, telemetria, ripresa e retry SQL-free provati. Comando di approvazione implementato, testato e incluso nel kit aggiornato, verificato offline. Registrare il suo primo uso reale al prossimo rilascio.	Prove del flusso e del recupero registrate; il guard rifiuta i conflitti coperti dai test. Azioni individuali verificate al normale primo uso, senza promettere un lock distribuito.
3. Nuovo componente e accessi	Completato nel perimetro Farm: rollout, SQL, cinque casi S2S, cleanup e kit successivo. Metriche/traccia e no-op verificati con i limiti riportati. Stato concreto.	Primo rilascio Farm e migrazione riusciti, poi chiamata tra progetti provata con identità/audience non autorizzate negate. La prova di rete rimane distinta dalla riuscita del deploy.
4. Consegna operativa	Residuo concreto: implementare le soglie proposte, provare ricezione allarmi e restore isolato. Fix/revert compatibile su main è definito; i test verificano il rifiuto di migrazioni applicate sconosciute, senza alterare il ledger.	Notifiche ricevute e restore verificato con tempi, punto recuperato e cleanup. Le soglie e gli obiettivi della scheda 12 diventano risultati misurati.

La consegna iniziale chiude tutti e quattro i passi. Access e Farm già online consentono di usare il profilo accettato mentre si completano i controlli operativi residui. Il completamento dei prodotti Farm, Releases e Console non è una dipendenza. Sonde e grant temporanei sono rimossi nei collaudi registrati; il backend Farm è un servizio reale e resta distinto dalle fixture da eliminare.

Possiamo proseguire senza attendere una sessione dedicata di Lorenzo. Le sue azioni effettive si verificano nel normale primo uso, senza sostituire questa evidenza con le prove effettuate usando Jacopo. Il collaudo Platform→Farm ha una propria ricevuta positiva; il recovery Access rimane una prova distinta.

Estensioni da completare quando richieste¶

Readonly, Pub/Sub push, Scheduler HTTP e Job senza SQL hanno un'accettazione separata per profilo. Ulteriori scrittori dello stesso schema e Job operativi con SQL hanno i loro profili (11 novembre) e vanno collaudati prima dell'uso ordinario. Nuove toolchain richiedono un'estensione esplicita.

Queste attività non sono un passaggio intermedio obbligatorio della consegna iniziale: diventano necessarie prima dell'uso ordinario di un servizio che le richiede. Console/staff web, accessi dei clienti e produzione mantengono integrazioni e collaudi propri.

Dettagli operativi da chiudere¶

Kit operatore: il pacchetto Access è già preparato con operator_kit.py da infra d5904b e verificato nella copia operatore. Ogni destinatario deve verificarlo da checkout fidato con l'hash ricevuto separatamente. Ogni run conserva input e ricevute immutabili fuori dal kit; non si condivide lo state. La verifica del pacchetto non prova i privilegi del destinatario.
Ripresa e retry: advance non ritenta il rollout. stage_recovery.py inspect/retry usa fotografia del target e riscontro attribuito della precedente Operation/Execution o del mancato avvio provato. Se l'esito è ancora attivo o incerto, non ritenta; un'incertezza non risolvibile con gli accessi disponibili richiede un amministratore autorizzato. Si ritenta l'esatto job/fase Cloud Deploy con artefatti invariati, senza ignorare la migrazione fallita. La sintassi e il formato --reconciliation sono nel runbook infra. Letture, dinieghi del retry non ammesso e retry positivo dopo un errore di permesso sulla fixture SQL-free sono provati; non è una prova del recupero SQL. Ricevuta dedicata.
Ripristino applicativo v1: fix o revert del codice su main compatibile con lo schema corrente, conservando le migrazioni applicate; normale pipeline e approvazioni. Non è previsto rollback Cloud Deploy verso una vecchia release né restore SQL implicito. Il guard SeaORM contro versioni applicate sconosciute viene provato con regressioni dedicate, senza introdurre guasti nel cloud condiviso. Dettaglio in 02 e 08.
Rilasci dello stesso componente: la CLI dedicata ispeziona il target e ricontrolla un candidato prima dell'approvazione; il retry mantiene i propri controlli. I test rifiutano snapshot scaduti/cambiati, rollout attivi o incerti e candidati Cloud Deploy superati. Non sono un lock distribuito né impediscono approvazioni dalla console: il team concorda ancora un solo rollout in esecuzione per componente/ambiente. I sistemi indipendenti possono procedere separatamente.
Prima creazione: se l'oggetto esiste anche senza essere Ready, applicare grant nominali, chiudere la finestra e aggiornare exists. Questo cambia il contratto: esportare un nuovo kit per le successive esecuzioni CLI, lasciando intatti input e registro del vecchio run. Il retry del rollout esistente è una procedura separata, non un aggiornamento dei suoi JSON.

Cosa chiudiamo e cosa resta successivo¶

La versione iniziale consegna una procedura usabile e un perimetro verificato. Quando si sviluppa un servizio, si completa la sua configurazione e si prova la prima release; un nuovo bisogno può richiedere un'estensione. Un profilo può entrare in collaudo controllato prima di essere dichiarato disponibile.

Jacopo e Lorenzo concordano onboarding, risorse e accessi; ciascuno mantiene codice, Dockerfile, script, test e manifest dei servizi che sviluppa. Le release ordinarie riusano kit e ricette comuni. Entrambi validano le interfacce condivise. Console/staff web, accessi dei clienti, prodotto dati completo e produzione hanno integrazioni proprie ancora da completare. Non vengono dichiarati pronti dalla consegna iniziale API; gli ulteriori profili mantengono la propria accettazione.

Le soglie iniziali, RPO/RTO proposti e la prova isolata sono nella scheda 12. Non sono nuovi allarmi applicati o un restore già eseguito.