Dove siamo, voce per voce

L'oggetto server, le applicazioni che ospita, come una richiesta ne trova una, avvio e spegnimento ordinati.

• server.py 130 stmt · 99% · asgi_server.py 97% · pool.py 100% · lifespan.py 98% · request_registry.py 99%
• test_contract.py, test_demux.py, test_pool.py, test_lifespan.py, test_request_registry.py
• Gli stati di vita del server — running, quitting, stopping — e il drenaggio limitato delle richieste in volo (lifespan.py)

L'albero da cui ogni voce legge le proprie parole: strati, pila di lettura, sottoscrittori.

• config/handler.py 147 stmt · 100% · elements.py 100% · builder.py 100% · default_config.py 98%
• test_config.py — 82 casi, il file più esercitato del progetto — e test_config_env.py

RoutedApplication e l'albero di rotte che serve REST e MCP insieme.

• application.py 100% · routed_application.py 95%
• test_routed_application.py, test_package.py

L'albero, la passeggiata filtrata, e i plugin armati sopra di esso.

• plugin_mixin.py 100% — cinque plugin di libreria: auth, env, channel, pydantic, logging
• test_plugins.py (32 casi)

La catena uniforme che ogni richiesta attraversa, ordinata da un numero.

• otto moduli: errors 99% · session 100% · cors 96% · logging 85% · wellknown 100%
• test_middleware.py e test_middleware_std.py (27)

Stato per utente sul server fra una richiesta e l'altra.

• session/store.py 100% · session.py 100% · mixin.py 100%
• test_session.py (50), test_login_flow.py (28)

401 all'anonimo, 403 a chi è già noto. Password con blocco progressivo, OIDC con PKCE, basic, bearer, JWT, chiavi API.

• auth/core.py 95% · oidc_method.py 97% · user_store.py 94% · api_key_store.py 95%
• test_auth.py (46), test_oidc.py (27), test_user_store.py, test_api_key_store.py

L'unico accesso al filesystem, attraverso nodi di storage. Pinnato sincrono.

• storage_mixin.py 100% — set_sync() imposto dal mixin
• test_storage_mixin.py

Il contratto minimo per un database montato dalla ricetta. Nessun backend nel core, per disegno.

• db.py 17 stmt · 100% · test_db.py

Il lavoro che non è una richiesta HTTP: pianificazione in tre forme, spool su file, esecuzione.

• tasks/spool.py 148 stmt · 100% · schedule.py 98% · scheduler.py 91% · store.py 94% · manager.py 97% · executor.py 100%
• cinque file di test, fra cui test_task_spool.py (28)

Vedere un batch muoversi, e fermarlo con garbo.

• manager.publish_progress (manager.py:160) scrive progress.json e pubblica sul canale vivo in una chiamata sola
• letto da tasks_section.py:230 e da applications/mcp.py:262

Montata su ogni server, mai configurata: login, utenti, credenziali, task, monitor, inspector.

• server_app.py 100% · sezioni auth, users, tokens, tasks tutte al 100%

Guidare le installazioni dalla shell. Un config.py più genroasgi serve sono un'unità di rilascio completa.

• __main__.py 291 stmt · 98% — verbi serve, apps, stop, remove
• test_cli.py (50 casi)

Il soft quit e il soft start: uscendo tutti gli utenti vengono parcheggiati congelati, rientrando le mappe tornano al loro posto e il risveglio è pigro.

• SpaCommander.quit e adopt_frozen_registers (spa_commander.py:1306) · freeze_handler.py 110 stmt · 99%
• il rinominare la cartella È la prova di completezza: reboot_temp → reboot_data
• sotto serve --reload ogni uscita salva — verificato dal vivo: stesso cookie, processo nuovo, nessun nuovo login

Il secondo trasporto del motore unico: stesso albero di rotte, stessi plugin, stessa autorizzazione di HTTP.

• Scritto e provato nel prototipo genro-asgi-legacy: src/genro_asgi/wsx/ — 690 righe su quattro moduli (protocol.py, handler.py, registry.py) — con 68 casi su quattro file di test
• WSX sta per WebSocket eXtended: un messaggio porta il prefisso WSX:// e poi il JSON con id, method, path, headers, cookies, query e data — semantica HTTP sopra il WebSocket
• Su develop non è ancora stato trasportato: BaseServer.on_websocket (server.py:287) accetta nulla e chiude con codice 1000, e non c'è una sola occorrenza di websocket.accept in src/

Un middleware dedicato che limita per indirizzo, distinto dal blocco progressivo per identità.

• zero occorrenze di rate_limit in src/
• il blocco progressivo per identità esiste ed è operativo (D28), ed è un'altra cosa

Una porta sola e stabile verso il sito ospitato, senza stato nella porta: cookie, demux a due stadi, traduzione HTTP.

• applications/spa_app.py 106 stmt · 99% · test_spa_application.py
• un rifiuto esce 503 con Retry-After, un sito che fallisce dentro il proprio processo esce 502

Molti utenti con stato vivo, distribuiti su più processi e mai spezzati. La catena è commander → gruppo → worker.

• spa_commander.py 490 stmt · 97% · spa_worker.py 921 · 97% · group_handler.py 207 · 97% · worker_handler.py 172 · 97% · envelope_handler.py 100%
• 27 file sotto tests/orchestration/
• il gruppo che dichiara engine_factory possiede un processo template: costruisce il motore una volta, congela l'heap, e ogni worker è un suo fork (template_entry.py, template_connector.py)
• la ricetta di un gruppo dichiara executable: il processo del server e i worker di ogni gruppo possono stare su interpreti diversi (worker_handler.py:425, template_connector.py:133)
• i massimali sono worker_max_number e worker_max_users; la memoria è una cascata di percentuali e solo il fondo è in byte

Il filo: frame con prefisso di lunghezza, hub, corsia. Zero dipendenze esterne.

• channel/hub.py 202 stmt · 90% · client.py 91% · frame.py 94% · local.py 92%
• test_channel.py, test_channel_hub.py, test_channel_local.py

Un solo stato condiviso, con lettura-e-scrittura sicura. Un master sul commander e nessuna replica: un worker legge con una chiamata sulla corsia e scrive attraverso la concessione.

• spa/global_store.py 66 stmt · 94% · test_spa_global_store.py
• store_get è una chiamata; la concessione porta con sé il contenuto del master, e le modifiche atterrano tutte al rilascio
• prove di contratto: fasi 10, 12, 13 sotto tests/orchestration/

Quello che una pagina cambia, le altre lo devono vedere. Consegna indirizzata attraverso il DeliveryDesk, mai una fotografia per processo.

• subscription_index.py 44 stmt · 100% · il banco vive sul commander (spa_commander.py:251)
• la consegna è a richiesta: nulla viene mai spinto dal banco
• prove di contratto: fasi 3, 8, 13

Il database ha cambiato una tabella, e la pagina lo deve sapere. La sottoscrizione è attiva appena depositata, quindi chi sottoscrive e committa nella stessa richiesta si ritrova servito.

• prova di contratto: fase 4 · code con età limitata, esclusione dell'origine dal fan-out

Chiedere a un pool vivo le domande che nessuno aveva previsto, servite come strumenti MCP.

• applications/spa_console.py 33 stmt · 88% · test_orchestration_console.py
• eval in un processo qualunque del pool — commander o un worker per nome — attraverso la corsia che il commander già tiene

Che cosa il sito ospitato deve fornire e che cosa può consumare: la callable WSGI dietro WsgiSeam, il sito che battezza la propria connessione mentre serve, i verbi del piano dati.

• spa/environ.py 60 stmt · 85% — l'ambiente WSGI sintetizzato, invocato in-processo su un pool di thread dedicato
• l'identità è quella del sito: il cookie spa_connection_id porta il connection id che il sito stesso ha coniato

Gruppi come oggetti vivi — aggiunti, aggiornati e rimossi a server acceso — ciascuno agganciato a un bundle applicativo immutabile costruito dalla CI dell'applicazione e distribuito su S3.

• nessuna riga: le cinque occorrenze di «bundle» in src/ sono i bundled plugins di genro-routes, altro significato
• fonte: codex/progetto-distribuzione-bundle-applicativi-s3-2026-08-20.md, 791 righe, decisioni D1–D7, che dichiara di non autorizzare alcuna modifica al codice

Il cluster esegue, il commander decide. Se ne prendono i muscoli e non il giudizio.

• nessuna riga · proposta non ratificata

Autorità delegata lungo la catena: radice → subcommander → gruppo → worker.

• nessuna riga · proposta non ratificata
• il protocollo del canale è disegnato dall'inizio per due collocazioni, in-processo e su rete; oggi ne esiste una