Skip to content

Incan Roadmap

This page tracks implementation status, release scope, and sequencing.

Incan development is driven by RFCs (Request for Comments).

  • An RFC captures a design proposal for a feature, including syntax, semantics, and implementation details.
  • RFCs are not necessarily implemented in the order they are written.
  • Milestones track release posture and sequencing. They define scope, not urgency.

See the RFCs page for more information about RFCs.

RFC status table

This table is autogenerated from the RFC files (it reads each RFC’s **Status:** ... line).

Tip: press Esc to clear.

RFC Status Track Title
RFC 000 Done closed / implemented Incan Core Language RFC (Phase 1)
RFC 001 Superseded closed / superseded Test Fixtures
RFC 002 Superseded closed / superseded Parametrized Tests
RFC 003 Superseded closed / superseded Frontend and WebAssembly Support
RFC 004 Done closed / implemented async fixtures
RFC 005 Done closed / implemented Rust Interop
RFC 006 Done closed / implemented Python-style generators
RFC 007 Superseded closed / superseded Inline Tests
RFC 008 Done closed / implemented Const Bindings
RFC 009 Done closed / implemented Numeric type system and builtin type registry
RFC 010 Done closed / implemented Python-style tempfile standard library
RFC 011 Done closed / implemented Precise Error Spans in F-Strings
RFC 012 Superseded closed / superseded JsonValue, enum methods, and enum trait adoption
RFC 013 Done closed / implemented Rust Crate Dependencies
RFC 014 Rejected closed / rejected user-facing runtime error behavior for generated code
RFC 015 Done closed / implemented hatch-like tooling (project lifecycle CLI)
RFC 016 Done closed / implemented loop and break <value> (Loop Expressions)
RFC 017 Done closed / implemented Validated newtypes with implicit coercion (pydantic-like feel)
RFC 018 Done closed / implemented language primitives for testing
RFC 019 Done closed / implemented test runner, CLI, and ecosystem
RFC 020 Done closed / implemented offline / locked / reproducible builds (Cargo policy + generated project contract)
RFC 021 Done closed / implemented Model field metadata and schema-safe aliases
RFC 022 Done closed / implemented Namespaced stdlib modules and compiler→stdlib handoff
RFC 023 Done closed / implemented Compilable Stdlib & Rust Module Binding
RFC 024 Done closed / implemented extensible derive protocol
RFC 025 Done closed / implemented multi-instantiation trait dispatch
RFC 026 Superseded closed / superseded User-Defined Trait Bridges
RFC 027 Done closed / implemented incan-vocab — Library Vocabulary Registration Crate
RFC 028 Done closed / implemented trait-based operator overloading
RFC 029 Done closed / implemented union types and type narrowing
RFC 030 Done closed / implemented std.collections — extended collection types
RFC 031 Done closed / implemented Incan Library System — Phase 1 (Local Path Dependencies)
RFC 032 Blocked (by RFC 033) proposed / active value enums — StrEnum and IntEnum
RFC 033 Planned proposed / active ctx — typed configuration context
RFC 034 Superseded closed / superseded incan.pub — The Incan Package Registry
RFC 035 Done closed / implemented First-Class Named Function References
RFC 036 Done closed / implemented user-defined decorators
RFC 037 Planned proposed / active native web stdlib redesign
RFC 038 Done closed / implemented Variadic Args and Unpacking (*args / **kwargs)
RFC 039 Done closed / implemented race for awaitable concurrency
RFC 040 Done closed / implemented Scoped DSL Surface Forms
RFC 041 Done closed / implemented First-Class Rust Interop Authoring
RFC 042 Done closed / implemented Traits Are Always Abstract
RFC 043 Done closed / implemented Rust Trait Implementation from Incan
RFC 044 Done closed / implemented Open-Ended Trait Methods
RFC 045 Done closed / implemented Scoped DSL symbol surfaces
RFC 046 Done closed / implemented Computed properties (property name -> Type)
RFC 047 Done closed / implemented Lightweight directed graph types (stdlib)
RFC 048 Done closed / implemented Checked contract metadata, Incan emit, and interrogation tooling
RFC 049 Done closed / implemented if let and while let pattern control flow
RFC 050 Done closed / implemented Enum methods and enum trait adoption
RFC 051 Done closed / implemented JsonValue for std.json
RFC 052 Done closed / implemented Module Static Storage
RFC 053 Done closed / implemented Formatter vertical spacing (three blank-line buckets)
RFC 054 Done closed / implemented Explicit call-site generic arguments for function and method calls
RFC 055 Done closed / implemented std.fs — pathlib-shaped filesystem APIs with chunked file I/O
RFC 056 Done closed / implemented std.io — in-memory byte streams and binary parsing helpers
RFC 057 Done closed / implemented @rust.allow(...) — targeted Rust lint suppression for generated code
RFC 058 Done closed / implemented std.datetime — temporal values, intervals, and runtime timing
RFC 059 Done closed / implemented std.regex — regular expressions, matches, captures, and replacement
RFC 060 Done closed / implemented std.uuid — UUID parsing, generation, and formatting
RFC 061 Done closed / implemented std.compression — codec-based compression and decompression
RFC 062 Planned proposed / active std.archive — archive container creation and extraction
RFC 063 Planned proposed / active std.process — process spawning and command execution
RFC 064 Done closed / implemented std.encoding — binary-text encoding and decoding utilities
RFC 065 Done closed / implemented std.hash — stable hashing primitives for data and integrity workflows
RFC 066 Planned proposed / active std.http — Incan-first HTTP client and request/response surface
RFC 067 Rejected closed / rejected std.ci — deterministic CI and automation scripting primitives
RFC 068 Done closed / implemented protocol hooks for core language syntax
RFC 069 Done closed / implemented list.repeat Helper for Fixed-Length Initialization
RFC 070 Done closed / implemented Result Combinators for Result[T, E]
RFC 071 Done closed / implemented Pattern alternation in match and if let
RFC 072 Done closed / implemented std.logging — logger acquisition, configuration, and structured events
RFC 073 Planned proposed / active environment matrices and toolchain constraints
RFC 074 Planned proposed / active template rendering and boilerplate provenance
RFC 075 Planned proposed / active starter profiles and mixes
RFC 076 Planned proposed / active project mutation policy and recovery
RFC 077 Done closed / implemented workspace and multi-package projects
RFC 078 Planned proposed / active tool execution and typed workflow actions
RFC 079 Planned proposed / active loaves.pub artifact graph
RFC 080 Planned proposed / active Declared AI assets
RFC 081 Done closed / implemented Language-shaped DSL embeddings
RFC 082 Planned proposed / active Checked API documentation generation
RFC 083 Done closed / implemented Symbol and method aliases
RFC 084 Done closed / implemented RHS partial callable presets
RFC 085 Planned proposed / active Field metadata and type-shaped constraints
RFC 086 Deferred proposed / active Schema descriptors and adapters
RFC 087 Planned proposed / active Reusable field contracts and model contract composition
RFC 088 Done closed / implemented Iterator adapter surface
RFC 089 Done closed / implemented std.environ runtime environment access
RFC 090 Planned proposed / active typed CLI framework
RFC 091 Planned proposed / active Integer storage carriers
RFC 092 Rejected closed / rejected Interactive Runtime Stdlib Contracts
RFC 093 Planned proposed / active std.telemetry — OpenTelemetry-aligned observability
RFC 094 Planned proposed / active Context managers
RFC 095 Planned proposed / active span vocabulary blocks
RFC 096 Planned proposed / active Declaration metadata blocks
RFC 097 Planned proposed / active Rust-hosted Incan caller
RFC 098 Planned proposed / active Native associated types for traits
RFC 099 Planned proposed / active Generic trait-targeted methods
RFC 100 Planned proposed / active std.re — Pythonic regular expressions
RFC 101 Done closed / implemented std.collections.OrdinalMap — deterministic compact key-to-ordinal lookup
RFC 102 Planned proposed / active Incan Semantic Layer Inspection Surface
RFC 103 Planned proposed / active std.secrets — Secret strings, secret bytes, and redaction-safe values
RFC 104 In Progress proposed / active Ambient Runtime Capabilities and Receipts
RFC 105 Planned proposed / active oven architect rule engine for design, safety, idiom, maintainability, and risk findings
RFC 106 In Progress proposed / active Compiler-backed agent context graph
RFC 107 Planned proposed / active Type-directed library APIs and compile-time type tokens
RFC 108 Planned proposed / active Import-scoped extensions
RFC 109 Planned proposed / active Receiver chain combinators (tap and then)
RFC 110 Planned proposed / active Three-way comparison with __cmp__
RFC 111 Planned proposed / active Proof-aware agentic contract feedback
RFC 112 Done closed / implemented Crash-safe local publication and file coordination
RFC 113 Done closed / implemented std.registry and declaration descriptors
RFC 114 Done closed / implemented Compiled providers, SDK components, and package features
RFC 115 Done closed / implemented Fallible iteration and combinators
RFC 116 Done closed / implemented Typed C ABI interop
RFC 117 Planned proposed / active loaf.toml and Oven's language-neutral project model
RFC 118 Planned proposed / active Incan and Oven command-line surfaces
RFC 119 In Progress proposed / active Oven-native Rust build facets and Cargo interoperation
RFC 120 Done closed / implemented canonical source symbol identity
RFC 121 Planned proposed / active Unified Incan/Rust type substrate
RFC 122 Planned proposed / active Composable model construction with fieldmethods and new
RFC 123 In Progress proposed / active Package executable representation
RFC 124 Planned proposed / active Oven store unit identity and cross-plan artifact sharing
RFC 125 Planned proposed / active loaves.pub Loaf registry and baked asset distribution
RFC 126 Planned proposed / active Evidence-backed investigations
RFC 127 Planned proposed / active The Incan lint catalog: clippy-conformant rules, loaf.toml configuration, incan architect as engine and fixer, incan fmt as canonicalizer
RFC 128 Planned proposed / active One Callable[(A, B) -> R] trait over function types
RFC 129 Planned proposed / active Shared or copied bindings and the mut parameter contract
RFC 130 Planned proposed / active Implicit None return annotations
RFC 131 Planned proposed / active First-class error declarations
RFC 132 Planned proposed / active Frozen classes and models
RFC 133 Planned proposed / active Literal types and compile-time value sets
RFC 134 Planned proposed / active Pattern bindings with exiting fallbacks
RFC 135 Planned proposed / active Lazy Option defaults with or
RFC 136 Planned proposed / active Chained comparisons
RFC 137 Planned proposed / active Named enum payload fields
RFC 138 Planned proposed / active Chained pattern conditions
RFC 139 Planned proposed / active Sequence patterns
RFC 140 Planned proposed / active Typed holes
RFC 141 Planned proposed / active Type matching with infer and named type operations
RFC 142 Planned proposed / active Async composition, iteration, and streams
RFC 143 Planned proposed / active Cloning with field overrides
RFC 144 Planned proposed / active Trait fields and type-owned constants
RFC 145 Planned proposed / active Oven storage lifecycle, retention and compact evidence
RFC 146 Planned proposed / active Typed JSON decoding and complete validation
RFC 147 Planned proposed / active Result matching with except
RFC 148 Planned proposed / active Must-use values and deliberate discard
RFC 149 Planned proposed / active Non-exhaustive public contracts
RFC 150 Planned proposed / active Deprecation diagnostics
RFC 151 Planned proposed / active Final classes
RFC 152 Planned proposed / active Recursion that never overflows the stack
RFC 153 Planned proposed / active Async closures
RFC 154 Planned proposed / active Retained capturing callables
RFC 155 Planned proposed / active Relaxed floating-point arithmetic
RFC 156 Planned proposed / active Typed MCP servers
RFC 157 Planned proposed / active Chained pattern guards
RFC 158 Planned proposed / active Incremental XML records over split and compressed inputs
RFC 159 Planned proposed / active Cloves (C-library Loaves) and the managed C toolchain
RFC 160 Planned proposed / active Vocabulary in Incan and native desugarers
RFC 161 Planned proposed / active The semantic core (SCIR)
RFC 162 Planned proposed / active File syntax: vocabularies, dialects and frontends
RFC 163 Planned proposed / active Cross-target builds and toolchain target support
RFC 164 Planned proposed / active Explicit ownership and borrowing contracts
RFC 165 Planned proposed / active Typed embedded storage with std.db
RFC 166 Planned proposed / active Indexed graphs and snapshot-bound graph access
RFC 167 Planned proposed / active Debugging and diagnostics for Incan programs and tools
RFC 168 Planned proposed / active std.primitives
RFC 169 Planned proposed / active Typed record sets and record streams
RFC 171 In Progress proposed / active Retire @rust.allow, @rust.extern and rust.module
RFC 172 In Progress proposed / active Async syntax without an import
RFC 173 Planned proposed / active Walking and reconstructing typed values
RFC 174 Planned proposed / active Overloaded functions and methods
RFC 175 Planned proposed / active Bidirectional controls and confusable identifiers
RFC 176 Planned proposed / active Visibility
RFC 177 Planned proposed / active Comprehensions

Strategic Direction

Incan's current direction is:

Python-readable at the base, domain-native at the edges, compiler-inspectable all the way down.

That means Incan should not compete as a small systems language or as a generic Python clone. The compiler, standard library, and tooling should make domain packages, capability metadata, policy, generated artifacts, diagnostics, and backend facts inspectable by humans and agents.

The completed releases below show how Incan reached its current compiler and project foundation. The forward roadmap is split into five release lanes:

  • 0.6: backend cutover.
  • 0.7: broader feature reopening after the compiler architecture is no longer split between old and new semantic paths.
  • 0.8: evidence-backed investigations across Rust and Incan, alongside freestanding and ownership foundations.
  • 0.9: kernel capability proof.
  • 1.0: stabilization and public contracts.

Release Milestones

The completed release lines are kept here as a compact history. Expand a release for its outcome and boundary; follow the release-note link for the complete change inventory. The active roadmap begins with 0.6 below.

Completed release history

0.1 — The first published Incan release

Outcome: establish a usable language, compiler, CLI, and documentation baseline.

Incan 0.1 shipped the core Python-shaped language surface, typed models and control flow, Result/Option, modules, early Rust interop, incan build / run / fmt / test, generated language reference material, and the first multi-file typed web applications. It proved that Incan could be used as a language rather than only explored as a compiler experiment.

Boundary: the package and standard-library model was still young, Rust interop used a narrower known-good surface, and several compiler/library capabilities were explicitly incomplete.

Read the 0.1 release notes

0.2 — Explicit modules, libraries, and a serious Rust boundary

Outcome: turn the first language surface into a more coherent platform.

Incan 0.2 moved standard-library and decorator surfaces under explicit std.* modules, separated Incan dependencies from Rust crate dependencies, introduced experimental Incan libraries, strengthened rust:: interop and rusttype, added module-owned static state, and made generic call sites and package boundaries more explicit. The release replaced ambient compiler magic with named, import-driven capabilities.

Boundary: libraries remained experimental and the release did not yet provide a complete package ecosystem or remove generated-Rust ownership friction.

Read the 0.2 release notes

0.3 — Real application code, broader stdlib, and stronger tooling

Outcome: make larger programs feel deliberate instead of improvised.

Incan 0.3 expanded expression-oriented control flow, typed numerics, enums, protocols, decorators, partial callables, generators, lazy iteration, and Result combinators. It also broadened the source-authored standard library across collections, graphs, JSON, regex, datetime, logging, encoding, hashing, compression, filesystem, I/O, and UUIDs while strengthening tests, formatting, locks, Rust interop, and generated-output discipline.

Boundary: real programs became credible, but installation, first-contact diagnostics, machine-readable inspection, and cross-boundary parity still needed a dedicated release.

Read the 0.3 release notes

0.4 — Tooling, inspection, and first contact

Outcome: make the stack tryable without cloning the compiler repository or reverse-engineering its internals.

Incan 0.4 delivered the canonical installer and zero-clone starter flow, stable machine-readable diagnostics, incan explain, build reports, generated-Rust inspection, compiler-backed codegraph export, visible build/test preparation, and compact boundary-parity fixtures. A new evaluator could install Incan, create and run a project, understand failures, inspect generated artifacts, and export compiler facts for tools and agents.

Boundary: 0.4 deliberately did not reopen broad language/runtime scope, replace the backend, establish a public Rust ABI, or turn downstream Encero proof lanes into product releases.

Read the 0.4 release notes

0.5 — Compiler-owned foundations and checked project boundaries

Outcome: give ordinary applications, libraries, workspaces, packages, and native integrations one checked compiler view.

Incan 0.5 moved critical commands onto shared CompilationSession analysis and landed the backend-neutral foundations for stable compiler identities, semantic facts, IncanType, initial HIR, ABI hooks, and backend migration. Those foundations deprecate generated Rust as semantic authority without pretending the backend cutover is complete.

The same release made package and project boundaries materially stronger:

  • implemented rooted and virtual multi-package workspaces with deterministic member selection, shared dependency and environment inheritance, portable locking, inspection, and lifecycle fan-out (RFC 077);
  • added compiled providers, SDK components, package-owned features, typed registries, declaration descriptors, crash-safe local publication, and more stable cross-machine identities;
  • delivered operational standard-library surfaces and fallible iteration needed by representative applications and downstream proof lanes;
  • delivered an experimental, deliberately bounded typed C ABI with checked signatures, ownership, layouts, artifacts, and target evidence (RFC 116); and
  • introduced Oven Alpha as a narrow evidence-backed build path inside the documented 0.5 envelope, not as the release's primary story or a claim of general Cargo-workspace replacement.

Boundary: generated Rust remains inspectable backend output; the replacement-backend cutover belongs to 0.6. Oven remains Alpha. The Hees.ai work validates the compiler, standard library, runtime, and tooling as a downstream proof lane; it is not a Hees.ai product release.

The original foundation trackers—#634, #646, #647, #648, #649, #650, #282, and #224—are complete. The release notes retain the full user-facing and issue-level inventory.

Test-drive Incan 0.5 · Read the complete 0.5 release notes

Forward roadmap

0.6 Release: backend cutover

The 0.6 milestone removes the Rust-source backend from the normal compiler path. The direct route, which lowers Body IR inside the pinned rustc, should preserve supported behavior, report compatibility and migration details, and retire generated Rust as the semantic handoff.

Only runtime/DSL RFC scope that stress-tests or supports the new backend belongs here.

Core tracking issues:

  • #652: backend parity cutover.
  • #1337: the direct route through the pinned rustc.
  • #653: Body IR v0 and backend-owned lowering.
  • #654: remove Rust-source backend and generated-Rust semantic handoff.
  • #655: backend compatibility report and migration notes.
  • #225: semantic facts adoption on backend cutover paths.
  • #656: Rust-facing ABI and Cargo-native Incan package direction.
  • #752: RFC 107 type-directed library APIs and compile-time type tokens.
  • RFC 092: interactive runtime stdlib contracts (rejected, covered by RFC 104/036/117-119).
  • RFC 093: std.telemetry.
  • RFC 094: context managers.
  • RFC 107: type-directed library APIs and compile-time type tokens.
  • RFC 095: span vocabulary blocks.

Read the 0.6 development release note · Browse the 0.6 delivery map

0.7 Release: feature reopening

The 0.7 milestone is the broader feature reopening lane after the backend replacement is complete. This is where deferred language, package, registry, lifecycle, interop, docs-generation, editor, and product-surface work can resume.

Examples of deferred lanes:

  • incan.pub and package registry/product identity.
  • IncQL and Pallay toolchain dogfood.
  • source-local feature metadata.
  • Python interop research.
  • checked API docs generation.
  • Windows/package-manager/self-upgrade convenience work.
  • trait/newtype language features not required by backend cutover.
  • broader editor and package lifecycle work.

The investigation design gate #1639 is an explicit v0.7 exit criterion: RFC 126 must reach Planned with all design questions resolved, required owner-contract changes accepted, and focused native/runtime feasibility evidence recorded. Merging the Draft alone does not satisfy the gate. This is design closure for v0.8, not delivery of the complete debugger in v0.7.

The gate should consume the source/context, action, and receipt foundations assigned to v0.6 and the metadata, advice, telemetry, secrets, and agent-facing work assigned to v0.7. Milestone placement is not proof of implementation. Only the bounded interfaces needed for investigation acceptance become prerequisites; the complete RFC 121 roadmap and optional providers must not become hidden blockers.

0.7 should not absorb freestanding/kernel primitives by default. That work needs its own release lanes so feature reopening does not become the place where unsafe, layout, target, runtime, and kernel proof work all land at once.

0.8 Release: evidence-backed investigations and runtime foundations

Humans and agents should be able to investigate unexpected behavior, test competing explanations, and verify repairs across Oven-managed Rust and Incan projects, with inspectable evidence throughout. RFC 126 defines the proposed investigation contract; it remains Draft until the v0.7 design-closure gate is satisfied. Existing freestanding, ownership-planning, GPU, and deferred syntax work remains in scope according to its own issues and acceptance boundaries.

The investigation program is governed by #1638, with five outcome tracks:

  • #1640: native debugging across Rust, Incan, and mixed calls.
  • #1641: durable sessions, exact artifacts, captures, and human/agent control.
  • #1642: bounded experiments, counterexample reduction, and repair verification.
  • #1643: supported runtime captures and domain evidence.
  • #1644: editor/MCP integration and end-to-end conformance.

Acceptance must demonstrate wrong-result investigation, hung or cancelled work, and reopening a captured failure on the agreed support matrix. The investigation must preserve the distinction between checked facts, advisory findings, proof assumptions, observations, and hypotheses. Full deterministic replay and arbitrary foreign-runtime support are separately qualified capabilities, not universal release promises.

Proof-aware contracts (#787) and ownership-planner work (#1611) retain their owners. GPU work (#1041) retains its independent capability scope. The Rust-syntax proposal (#1612) remains proposal/RFC refinement in 0.8 with planning for 0.9 or later; this program does not accelerate its implementation.

Freestanding foundations

The freestanding lane defines the compiler, runtime, ABI, and package foundations needed for freestanding targets. It should make low-level targets possible without promising a production kernel or stabilizing every low-level surface.

The release should answer how Incan code can compile without assuming hosted std, a process environment, filesystem access, threads, default allocator availability, or ordinary hosted panic behavior.

Expected scope:

  • freestanding target profiles and capability manifests;
  • runtime layering across core, alloc, hosted std, and future kernel-facing APIs;
  • no-std/freestanding build mode;
  • panic strategy and allocator hooks;
  • ABI/layout/repr/alignment/calling-convention controls;
  • an explicit unsafe model for raw pointers, volatile access, MMIO, and low-level intrinsics;
  • package metadata for freestanding compatibility.

Core tracking issues:

  • #681: RFC proposal for freestanding targets and runtime layering.
  • #682: RFC proposal for unsafe blocks and low-level operations.
  • #683: RFC proposal for representation, layout, and calling convention controls.
  • #684: stdlib/runtime layer inventory for freestanding foundations.
  • #685: freestanding target profiles and runtime requirement reports.
  • #686: no-std freestanding build mode and restricted artifact smoke test.
  • #687: unsafe low-level operation surface v0.
  • #688: layout, repr, and calling-convention metadata v0.
  • #689: panic strategy and allocator hooks for freestanding targets.

The freestanding lane is successful when Incan can compile a restricted freestanding artifact and report which runtime, allocator, panic, target, and ABI capabilities it requires. The overall release must also satisfy the investigation acceptance program and the independently tracked commitments above.

0.9 Release: kernel capability proof

The 0.9 milestone is the vertical proof that the freestanding foundations work under real low-level pressure. It should boot a tiny Incan-authored kernel under an emulator, not ship a production operating system.

Expected scope:

  • minimal architecture support layer;
  • linker and boot configuration;
  • QEMU runner and smoke harness;
  • serial output;
  • panic halt/report path;
  • allocator hookup;
  • MMIO/volatile/raw pointer use;
  • one interrupt, timer, or simple task proof.

Core tracking issues:

  • #690: QEMU tiny kernel capability proof.

0.9 is successful when Incan can build and boot a tiny freestanding kernel under QEMU with Incan-authored init logic and a concrete low-level capability proof.

1.0 Release: stabilization and public contracts

The 1.0 milestone consolidates the post-cutover compiler architecture, ABI/package direction, tooling contracts, stdlib maturity, ecosystem workflows, freestanding lessons, and documentation into a coherent public surface.

1.0 should describe what Incan is, what it guarantees, how packages and generated artifacts are consumed, where Rust-facing interop boundaries are stable, and which freestanding/kernel-facing surfaces are stable, experimental, or intentionally deferred.

Status by Area

  • Core language: see RFC 000 / RFC 008.
  • Testing surface: see RFC 018 / RFC 019 / RFC 004.
  • Tooling and first-contact: install, starter, diagnostics, explain, codegraph, artifact inspection, and build reports are the immediate release surface. Codegraph exports Incan records only; Rust graph records are later work.
  • Rust interop: see RFC 005 / RFC 013 and the Rust Interop guide. Rust-hosted consumption should be reframed through ABI and Cargo-native package direction instead of generated Rust as the public semantic path.
  • Web and interactive runtime: see the Web Framework guide, RFC 092 (rejected, covered by RFC 104/036/117-119), and related runtime/DSL RFCs.
  • Standard library: stdlib work is allowed in the backend-foundation lane where it helps real programs and dogfood paths validate compiler/runtime direction.

Deferred / Later

The following items remain intentionally deferred until they have a focused RFC or implementation lane:

  • SSR/SSG for frontend: Server-Side Rendering / Static Site Generation for the WASM/UI stack (render pages ahead of time or on the server, then hydrate).
  • Desktop/mobile via wgpu: using the wgpu graphics stack to run Incan apps as native desktop/mobile apps instead of browser-only.
  • CRDT/collab features: real-time collaboration primitives (Conflict-free Replicated Data Types) for collaborative editing, shared state, and similar workflows.

Guides

Interested in contributing?

See the Contributing page for more information about contributing to Incan.