Alpha hardening roadmap

Direction recorded September 7, 2026. This roadmap describes accepted development priorities. It does not announce new compiler features as shipped. Availability must be established by the documented compiler revision and tests.

Janus aims to combine readable programs with inspectable ownership, effects, resource authority, and compiler evidence. The next phase makes those contracts dependable across complete applications. Documentation and teaching accompany delivery under the completion procedure.

Language direction

• Preserve the profile ladder and the profile/target compatibility rules. Freestanding kernels, drivers, and firmware belong to :sovereign.
• Keep :core general-purpose with explicit allocation and separately checked allocation-free paths. Optional managed memory is a development direction.
• Retain AOT as the default outside the planned native-JIT scripting mode. AOT scripting remains supported in that direction.
• Select ARC/ORC for eligible shared heap objects at the application/runtime- domain boundary. ORC means ARC plus cycle collection. Ordinary values, owned buffers, borrows, and regions retain their ownership meanings.
• Choose memory policy from ownership graphs and resource/latency requirements, independently of AOT/JIT. ARC cannot reclaim strong cycles. Resources require explicit cleanup, and prompt reference-count destruction is not a time bound.
• Preserve the effect/resource-authority distinction: abstract requests disclose effects, concrete handlers and direct APIs require valid resource capabilities. A manifest bounds grants; it does not mint them.
• Keep termination, panic freedom, determinism, timing guarantees, and resource budgets separately evidenced. Content identity is not execution authority.

ARC/ORC and native-JIT defaults above are planned contracts, not documentation of newly available flags or a promise that every target supports every policy.

Milestone 1: coherent AOT alpha

Establish a compiler-revision/configuration baseline and connect advertised guarantees to tests, public references, and lessons. Reconcile conflicting effect/capability enforcement and harden values, views, aggregates, slices, errors, generics, callbacks, cleanup, and supported foreign interfaces.

Qualify a constrained hosted service, a CPU astrophysics kernel checked against numerical reference results, and a Nexus-facing component using explicit handles. Separate hosted, emulated, and native-device evidence. Start with Linux-class embedded environments and qualify native Nexus integration separately.

Publish measured startup, binary size, memory use, and workload performance. Only advertise configurations whose guarantees pass their checks. Native JIT, cycle collection, accelerator breadth, and distributed expansion are later work.

Milestone 2: embedded scripting and managed memory

Deliver native JIT and application-selected ARC/ORC while preserving AOT compatibility, ownership meanings, static handler semantics, and scoped host authority. Dependencies inherit the managed-domain policy; ARC builds reject dependencies requiring automatic cycle reclamation.

Verify closures, callbacks, persistent state, cleanup, cancellation, domain disposal, cycle handling, and AOT/JIT behavioral parity. Keep compilation separate from authorized execution through typed callables or opaque handles. Qualify each architecture independently.

Compare equivalent Janus and Python embedded workloads, including cold start, repeated execution, complete installation footprint, peak memory, required libraries, and deployment effort.

Milestone 3: Monastery WASM prototype

Develop a bounded Janus-authored lesson execution engine targeting WebAssembly. Establish real compilation/execution, diagnostics, capability boundaries, cancellation, resource limits, and native/WASM conformance on a named corpus. The compiler/runner/browser-host boundary is part of that engineering work; WASM output alone does not supply a browser source compiler or WASI host.

Monastery can remain in mock/prelaunch mode during this prototype. The engine does not block the first two milestones, and the prototype is not a launch.

Milestone 4: Monastery readiness

Replace mock execution for the verified curriculum after its results and diagnostics pass, resource and capability controls hold, and progress records real outcomes. Identify unsupported/native-only lessons, and verify recovery without converting mock history into verified achievement.

Launch readiness follows evidence rather than a calendar deadline. Teaching content is created and verified natively throughout milestones 1–2, so useful lessons do not wait for the browser engine.