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
Epic #201 defines the next capability-rich implementation phase. Issues #202–240 and the retained Angular umbrella #44 form a concrete 41-ticket planned backlog. The context, logging and clock surface already delivered in #10 remains the baseline.
The sequence starts with exact versioned contracts, durable grants and a sealed broker. Shared I/O ownership, provider pools and descendant reservations then support real external providers and isolated local service calls. Web ingress and renderer work depend on those foundations and the existing package/lifecycle boundary. SDK and operator work must exercise the actual implementations.
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 support requires a selected and measured renderer profile; it does not assume that the current generic Wasm backend can execute arbitrary Node.js applications. Browser and SSR package schemas already exist in Phase 2, while actual HTTP serving, renderer execution and hydration integration remain Phase 3 work. No application-owned listener or idle renderer is introduced by a package.
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.
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.