Stage 02 · Runtime
From a broad vision to one dependable runtime
The initial vision was an interpreter spanning Lasso 1.x through 8.6. The practical release target became the final Lasso 8 generation.
Why 8.6 came first
The surviving 8.6 guide, its 8.5 foundation, open-source applications, and production-era frameworks provide enough evidence for a defensible compatibility contract. Earlier generations remain valuable research material, but claiming them before equivalent evidence exists would weaken the project.
State belongs to the worker
Lasso applications expect globals, caches, startup hooks, sessions, connection pools, and site state to survive in order. LaiRu Legacy therefore uses one canonical stateful worker fed by a bounded request queue. Connections may arrive concurrently, but application execution stays ordered.
Could version selection return?
A future release could offer an explicit version-selection option if earlier Lasso generations gain reliable documentation and application fixtures. It would be a deliberate compatibility feature with separately tested behavior, not a claim inferred from syntax alone. The current release stays focused on Lasso 8.6.
Failure boundaries
A runtime panic is contained, recorded, and followed by worker reconstruction. Queue saturation returns 503. Parse, compile, and evaluation diagnostics travel on the FastCGI error stream instead of being injected into the public page.