Engineering roadmap
Phase 0: executable spike — Phase 1 authorized
Repository contracts, one Rust echo capsule, one fixed cell pool, Wasmtime
component loading, timeout/trap containment, baseline measurements, native
Linux calibration, hot-path profiling, and a long-running resource soak are
implemented. Fresh native-Linux calibration, profiling, and soak packages from
commit 52ac4754… were independently rebuilt from their raw evidence and bound
to a fresh full baseline at b932a935…. The retained August 30
receipt
records pass, authorized, and no blockers. See
the completion gate.
The underlying measurements remain single-host observational evidence. Neither an issue closure nor such an observation alone authorizes Phase 1. The full receipt authorizes only because it validates the matched raw archives, execution identity, profiling, resource soak, and fresh-baseline checks together. Phase 1 builds on the retained runtime and invariants; Phase 0 does not claim production readiness or Phase 1 API compatibility.
Phase 1: single-node stateless fabric — complete
The following features and their acceptance evidence are delivered:
- Executable build and generated bindings (#2) and cross-layer contracts (#36).
- Manifest codecs and schema-backed validation (#3).
- Durable local release catalog (#4).
- Embedded deployment catalog and immutable local routing (#5).
- Resource budgets, deadlines, and cancellation primitives (#6).
- Bounded single-node admission and overload control (#7).
- Fixed class pools and bounded tenant-fair scheduling (#8).
- Generic Wasmtime execution and bounded canonical values (#9).
- Activation context, structured logging, and clock capabilities (#10).
- Stateless activation lifecycle, bounded journal/status, and scoped cancellation (#11).
- Shared telemetry, redacted lifecycle/guest observations, and bounded node inventory (#13).
- Generic invocation, cancellation, and retained-status service adapters (#12).
- Release, deployment, route, and node management service adapters (#37).
- Configured standalone Linux node, loopback RPCs, durable restart and bounded shutdown (#14).
- Bounded developer/operator CLI and scriptable local echo workflow (#15).
- Bounded deterministic conformance, child resource observations and diagnostic report validation, with retained clean CI evidence.
- Explicit scale, mixed-workload soak and benchmark collectors, with all four scales, three full soaks and seven benchmark runs retained.
- Seven controlled historical/current pairs with the original executables, semantic controls, productionization differences and complete raw evidence (#94).
- SDK caller identity and cancellation contracts with executable fixtures across six languages (#65).
The completion review maps the collective evidence to all fifteen gate #16 criteria and records the completion decision and merged CI evidence for the Phase 1 epic. Status is recorded as of September 8, 2026. The standalone node and operator CLI support the local release-to-invocation workflow through generated RPC clients; see the scriptable quickstart.
At 100,000 releases/deployments, service-specific execution resources remain absent and fixed node topology remains constant, while catalog metadata RSS grows explicitly. Reclamation satisfies the declared finite policy; paired measurements report additional current runtime overhead. Delivery does not mean constant RSS, arbitrary-duration leak freedom, a production SLO or a claim of no performance regression. The retained Phase 0 demonstration and historical native receipts keep their original scope. Clustering, general capabilities, state/effects and workflows remain the later phases below.
The completed Phase 1 performance extension records the merged prioritized optimizations and Docker/Kubernetes comparisons, separately from the original functional completion decision. Resident Echo met its 2 ms useful-success target in #103; distinct 100k catalog RSS fell 58.90% in #107. These results do not establish a universal latency SLO, all-shape memory ceiling or isolated orchestration cost. Phase 2 builds on that completed handoff under the scope below; local catalog/build foundations remain Phase 1.
Phase 2: packaging and supply chain — complete
Epic #139 and the Phase 2 milestone track the completed package-to-execution and operator workflow. The completion review records the collective acceptance decision for gate #158, including all eighteen delivery dependencies (#140–157), currentness and offline checks, the fixed dormant-resource profile and retained limitations.
The Phase 2 delivery notes summarize current features, migration and recovery boundaries and identify their release status.
| Delivered surface | Contract and scope |
|---|---|
| Package format and deterministic build/inspection (#140–141) | Exact OCI package identity, capsule/browser/SSR package formats and bounded packaging from supplied bytes. Web formats do not implement a web runtime. |
| OCI distribution (#142) | Scoped authenticated transfer, exact immutable descriptors and bounded detached referrer discovery. |
| Publisher, builder and SBOM evidence (#143–145) | Separate publisher trust and builder/source policy, plus observed inventory and SBOM associations. The maintained build remains nonhermetic. |
| Enforced admission and compatibility (#146–147) | Current tenant/supply-chain admission, actual runtime requirements and conservative exact-pair contract comparison. Transfer and diagnostic verification create no execution grant. |
| Durable release lifecycle (#148) | Admission, revocation, retirement and evidence renewal, owner-bound current capabilities, bounded operation outcomes and fail-closed recovery in local and enforced modes. |
| Replaceable raw cache (#149) | Digest-verified file/buffer ownership, bounded staging, pins and explicit reclamation. It cannot delete authoritative catalog content or confer trust. |
| Isolated compilation and native reuse (#150–151) | Trusted-local Linux x86_64 producer and opt-in persistent loading, protected local receipts, exact engine/source identity, child ownership through reap and page-rounded image permits. |
| Durable audit and observation (#152) | Typed attempts, outcomes and diagnostics, one bounded worker, scoped queries, explicit loss/uncertainty and no per-invocation durable enqueue. |
| Rollout, canary and rollback (#153–155) | Combined atomic catalog publication, sealed full-window promotion and explicit original-base restoration through new monotonic generations. |
| Operator workflows (#156) | Package build/inspect/verify/push/pull and authenticated control workflows, exact managed deployment receipts, finite reconciliation and lossless CLI output. |
The standalone node remains single-node and stateless. Supply-chain enforcement requires explicit configuration; trusted-local mode retains real lifecycle checks without inventing signing proof. Native reuse, durable audit and rollout management have their own opt-in owners and limits. Native loading never turns cached bytes into current permission.
Phase 2 extends the local deployment format through combined rollout state and managed-operation history while retaining earlier decoding and omitted-field semantics. Replay returns retained history; it never renews a grant, repeats an evicted operation or restores a revoked release. Catalog durability, audit acknowledgement and client outcome certainty remain distinct.
The retained Phase 0/1 measurements keep their original execution identities and limitations. Phase 2 adds a bounded 32-release resource observation on its recorded WSL2 host; it makes no new 100k-scale, latency or production SLO claim. Its evidence set preserves exact identities, actual outcomes and failed or superseded attempts.
Phase 3: capabilities and application hosting
Status: complete for the declared standalone profiles.
All six guest SDKs, the packaged developer workflow, native distribution and complete learning site are delivered. The maintainer accepted the 27-topic guide review; final runtime CI, both real VM profiles, public tool downloads, 18-project creation and protected live-site checks passed. The completion decision records the exact evidence and remaining platform/security limits. The alpha.4 release and matching guides are public. Runtime tags and historical measurements remain immutable.
Epic #201 tracks the delivered capability and application-hosting implementation, including the architecture/security audit requirements and the retained Angular umbrella #44. The tracker records scoped delivery, dependencies and acceptance evidence. The context, logging and clock surface already delivered in #10 remains the baseline.
Exact versioned contracts, durable grants and a sealed broker govern capability use. Shared I/O ownership, provider pools and descendant reservations support external providers and isolated local service calls. Web ingress and rendering use those foundations and the package/lifecycle boundary. The linked gate keeps the original implementation, SDK and operator execution evidence.
Every provider must preserve exact tenant/grant/owner identity and fail closed across revocation and configuration changes. Buffers, handles, connections, streams, waits and descendants need finite shared reservations that survive cancellation until actual cleanup. Provider responses and secret values cannot escape into unrestricted logs or audit payloads. Pools, ingress listeners and consumer loops belong to the node, not dormant services.
Angular uses the selected and measured renderer profile, with actual HTTP serving, renderer execution and browser hydration qualified by the reference workflow. It does not support arbitrary Node.js applications. Static/CSR sites use the shared listener without a guest activation. Neither package type creates an application-owned listener or idle renderer.
First integration feedback: delivered scope
The original #626–#643 tickets deliver the static-schema correction, larger bounded site inventory, XML sitemaps, public-document navigation, framework CSP recipes, static/API composition, released-binary publication and recoverable route sets. See website delivery for the application workflow and container operation for the non-root local node, private CI/probes, HTTPS/gzip, coupled backup and ownership handover. The CLI's bounded authentication/network controls were qualified with a real local Harbor registry. No Azure resources or cloud simulation were used.
The accepted CORS work establishes design and browser feasibility; native asset grants remain #660. Capacity planning and maintenance are delivered; committed-history deletion remains #662. The intermittent Go guest trap remains under investigation #675. These boundaries remain explicit in the alpha.5 release description and guides.
Phase 4: state and effects
Transactional keyed state, optimistic concurrency, durable outbox, effect dispatcher, idempotency and entity-key routing. Phase 3 external HTTP/event operations do not claim an atomic guest-state transaction or exactly-once effects.
Phase 5: cluster
Separate control plane, route watches, direct node invocation, mTLS identity, artifact prefetch, state affinity and multi-zone placement. Phase 3 service calls are isolated local calls; they do not establish distributed routing or remote delegation.
Before cluster implementation begins, carry RFC-0004 and its implementation/conformance handoff into the Phase 5 plan. Phase 3 ticket #274 delivers this design only: separate route retention from finite publication authorization, preserve local guarded start, define clock/replay/restart/reconnect behavior, and explicitly bound availability during a partition. Phase 5 owns the wire/storage/control-plane implementation and executed multi-node fault evidence; local tests do not prove remote-revocation freshness.
Phase 6: durable workflows
Explicit workflow state machines, durable timers, continuations, awaited effects, replay and compensation. Ordinary provider deadlines, retries or consumer cursors do not supply workflow suspension or replay.
Phase 7: research promotion candidates
User-space state paging, continuation eviction, call-graph fusion, immutable shared blobs, adaptive materialization, native software fault isolation and hardware capability backends. These remain research candidates rather than requirements of the Phase 2 or Phase 3 completion gates.