ROADMAP
La sequenza segue gate tecnici, non date arbitrarie. Ogni fase deve preservare il comportamento dell'oracolo e sbloccare un caso d'uso misurabile.
FATTO
La suite single-site esegue 30.472 test e la multisite 31.278. Ciascuna ha una sola divergenza dichiarata, dovuta a un elenco dei wrapper deliberatamente onesto.
FATTO
L'arco prestazionale ha ridotto la CPU full-suite da circa 4,1× alla banda corrente 2,06–2,11×. WP-72 ha chiuso il residuo misurato per richiesta a 0,0010 KiB/richiesta e ha sbloccato la rotta Axum.
ORA
Poiché la VM contiene stato basato su Rc ed è !Send, ogni worker longevo resta fissato al proprio thread OS. Axum distribuisce le richieste tramite message passing mpsc; il ciclo esplicito è cablato, mentre coda bounded e backpressure restano gate di rilascio.
PROSSIMO GATE
Il RetainSet persistente per thread e il relativo gate iniziale su due richieste sono arrivati. Restano una VM davvero riusata, amplificazione K=10, coppia oracolo fresh-vs-reuse e verifica dell’ordine del lifecycle prima di dichiarare VM persistenti.
DOPO IL CONFINE
Quando il confine di riuso sarà byte-fedele e limitato in memoria, il progetto potrà misurare onestamente code e throughput, proseguire l'hardening, validare Laravel e chiudere i gap di estensione ad alto valore.
VISIONE DI LUNGO PERIODO
La VM resta sincrona. Un driver per-thread potrà in seguito sospendere e riprendere Fiber attorno a I/O realmente non bloccante, dopo aver provato lifecycle residente e driver rete/database rilevanti.
NOTA ARCHITETTURALE
La rotta task_local respinta non poteva offrire riuso reale a una VM non-Send. Il design converge su worker-attore stile php-fpm: thread OS dedicati, dispatch mpsc, un solo proprietario e confine in ordine Zend request_start → run → request_shutdown → request_end. Prima del rilascio, il canale oggi non limitato deve acquisire backpressure esplicita.
I percorsi fresh e riusato devono produrre gli stessi esiti per nome di PHP.
Lo stato di richiesta deve azzerarsi senza crescita residua in amplificazione e carichi sostenuti.
I claim richiedono coppie con l'oracolo, user CPU e ladder del footprint, non aneddoti isolati sul wall-clock.
Eccezioni, shutdown handler, buffer, distruttori e sessioni devono eseguire nell'ordine corretto.
Una coda worker limitata deve fallire in modo prevedibile, senza creare task o thread senza limite.
Pool, preload e async entrano solo quando un workload reale prova sia la necessità sia l'implementazione.
Rotta corrente: NEXT_SESSION_WORDPRESS.md ↗ · evidenza prestazionale: GAP_TREND.md ↗ · architettura async e distribuzione ↗