A better build system
Build once.Keep the proof.¶
Oven turns a verified Rust compatibility closure into immutable Loafs, then lets normal Incan build, run, and test commands reuse direct-rustc plans without Cargo on the consumer path.
Alpha means explicit boundaries. A compatible Loaf is reproducible by the same toolchain and inputs.
One system, three ways in.¶
Use Oven through the surface that matches the question you are asking.
incan build →
MODEL
Programmatic surface
See the typed compiler-facing contracts behind every plan.
Read the architecture →
PROOF
Inspect the proof
Explore stored evidence and the reason a plan was reused or rejected.
incan oven store inspect →
The build result should explain itself.
Cargo can compile Incan's generated Rust. The limitation is the contract around that result: a mutable target tree and local fingerprints do not give Incan one durable answer for what was built, why it is compatible, or when it may be reused.
Its identity binds source, dependency lock, compiler, SDK, target, profile, features, artifacts, and integrity evidence.
A publisher may pay the compatibility cost once. Normal commands only select and consume a verified result; a miss stays explicit.
Bounded admission, atomic publication, and active leases keep reuse predictable under concurrency, crashes, and cleanup.
The innovation is not merely calling rustc directly. Oven makes a prepared compatibility closure a first-class Incan artifact—with an identity, a receipt, and an owned lifecycle.
Oven sits behind the commands you already know.
For a supported project, build, run, and test select a receipt-compatible Loaf and its stored direct-rustc plan.
$ incan build
$ incan run
$ incan test
Compiler, target, SDK, feature selection, dependency lock, and relevant source all contribute to identity. Match them and Oven can reuse the sealed result without Cargo on the consumer path. Change one and the normal command reports a miss: prepare a new project result explicitly, or stop if the request sits outside the Alpha envelope.
Make first materialization explicitincan oven bake --project . --format jsonincan build --lib
What an explicit project bake publishes
incan oven bake --project . starts from the toolchain's immutable full-standard-library Loaf. When a project needs locked Rust or provider artifacts outside that base, the explicit bake may invoke Oven's bounded compatibility publisher once and publish a project-extension Loaf that names the exact base it extends.
For each discovered library or executable target and profile, the bake compiles caller-owned final output through direct rustc, seals checked .incnlib metadata and declared provider sidecars, and publishes a completed project-output Loaf for exact replay. Matching build, run, and test commands remain consumer-only and never invoke Cargo.
Use --features, --no-default-features, or --all-features to select the same public package-feature projection used by normal commands. incan oven store inspect --format json reads the store; incan oven store prune --dry-run --format json previews bounded reclamation.
How Oven builds and proves¶
The publisher pays the compatibility cost once. Oven fingerprints the inputs that made the result valid, seals the result and its receipt into one immutable Loaf, then lets a compatible consumer reuse it without Cargo. If those facts no longer match, Oven refuses reuse and tells you why. Alpha ships complete debug and release standard-library Loaf families plus a compiler-suite family. Explicit project bake can add receipt-bound project extensions and completed application, library, and test outputs without turning normal commands into Cargo frontends.
This Oven receipt selects how already-generated Rust is compiled. A separate, earlier receipt selects and records which compiler backend produced that Rust in the first place: see Backend selection & execution receipts.
- 01–02 · PublisherIdentify and prepare once.
Fingerprint source, lock, compiler, SDK, target, profile, and build intent before paying the compatibility cost.
- 03 · SealKeep the result and its explanation.
Package the immutable artifact, direct-
rustcplan, compatibility identity, and build receipt as one Loaf. - 04–05 · ConsumerReuse—or get a precise refusal.
Match the requested environment, reuse locally without Cargo, and inspect the evidence behind the decision.
Publisher inputs
main.incn
lock.json
Consumer outcomes
Every Loaf is bound to its source, dependency lock, compiler, SDK, target, profile, feature projection, and build intent. Project outputs also name the exact base and extension authority that produced them. The proof travels with the result instead of disappearing into a build cache.
A normal command refuses reuse and asks for an explicit bake—or stops—when the requested environment cannot honestly consume the sealed result.
- the toolchain, target, profile, or features differ;
- semantic lock, dependency, or provider evidence changed; or
- the request sits outside the Alpha envelope.
Your own source is the one input that never needs a bake: editing a baked project sets its sealed output aside and compiles the edit from source against the dependency closure that same bake published.
The receipt separates what happened from why reuse was allowed.
Oven keeps preparation, execution, compatibility, and storage evidence distinct. The result is a proof you can inspect instead of a cache entry you have to reverse-engineer.
Evidence fields, limits, and benchmark rules
Do not combine cold publication and prepared replay into one headline number. The approximately-five-minute acceptance target applies to the prepared full-suite replay and is meaningful only with its commit, machine, toolchain, cache state, workload, and storage junctions.
The compiler-suite family is two things with two identities. The suite itself — the roots, the compiler that runs them, the Loaf compatibility they select — is keyed on the compiler's own sources, so every compiler edit misses it and is prepared again. The third-party foundation the suite links, the registry and vendored closure, is keyed on its own inputs only: the private foundation manifest, its lock, the checked-in patches, target, host, profile, the rustc identity and the Cargo version. A compiler edit therefore misses the suite but keeps the foundation key, and preparation selects the existing family by that key — from the compiler-suite store, or from a mirror through the same verifying import a mirrored Loaf uses — before it would ask Cargo to compile anything. Only a changed lock, manifest, patch, target, host, profile or toolchain derives a different key. The planning-only Cargo calls that read the unit graph and metadata still run on a suite miss; what the foundation key removes is the compilation.
Compiler-suite replay reports live case completions and durations on stderr, with captured failure diagnostics and a 30-second heartbeat naming outstanding work. Its JSON report keeps process success separate from complete case evidence: missing records are unknown coverage, never zero-duration successes. Phase progress continues through scratch cleanup and report publication. Every partition retains case durations, full native transcripts and an outer timing record covering archive creation and output cleanup; see the benchmark protocol below for artifact names and timing boundaries.
The current Alpha handoff uses project-extension schema 9, packaged-library schema 7, completed-output schema 14, and project-inspection-authority schema 1. Explicit-bake completed outputs preserve source-current inspection authority for each target and profile. A successful ordinary default executable build also publishes its completed loaf, bound to exact compiler and preparation inputs; it does not publish whole-project inspection authority. New bakes also record a separate dependency authority: development commands can typecheck and compile edited project Incan sources using that bake’s retained inspection closure. Manifests, semantic locks, path-provider sources, vocabulary companions and non-Incan inputs remain exact; changes to those require a bake. The sealed native project output remains reusable only for its original source authority. Older outputs without dependency authority require one bake before code edits can use this development path.
The developer store defaults to $INCAN_HOME/oven/store/v2 (or ~/.incan/oven/store/v2). Its everyday policy allows 12 GiB of aggregate physical allocation, with 12 GiB physical and 6 GiB logical per compatibility domain, enough for two large interop projects to share one home without evicting each other. The compiler-suite policy is 16 GiB aggregate physical, 6 GiB domain physical, and 4 GiB domain logical. Before an explicit bake compiles anything it reserves a 4 GiB staging floor, reclaiming least-recently-used inactive entries to reach it and saying which ones went; an active lease is never reclaimed, and an operator-supplied limit is never silently expanded.
Why Oven beats Cargo-only workflows
One build. A reusable result with receipts.
rustc.Alpha · available now
Useful proof today The current surface is deliberately narrow, but the core reuse contract is real.- Full-standard-library Loaf families
- Project extensions and completed outputs
- Human-readable inspection
- No Cargo on the normal consumer path
North star · planned
Proof that can travel These layers explain where Oven is going; they are not presented as shipped Alpha capabilities.- Trust and signatures
- SBOM and broader provenance
- Portable publication
- Verification chains
A matching receipt permits reuse. A mismatch stops it.
Oven does not infer that yesterday's artifact is “probably fine.” It compares the requested environment with the identity sealed into the Loaf, then returns an explicit reuse decision.
rustc plan.Inspect the surface
$ incan oven store inspect
$ incan oven store prune --dry-run
$ incan oven bake --project .
$ incan inspect oven --receipt receipt.json
Open the CLI reference →
Alpha boundary
Early by design. Explicit by default.
Oven Alpha proves the maintained Incan workflow and the repository's own compiler suite. It does not yet claim:- general Cargo compatibility for arbitrary Rust workspaces;
- every build script, procedural macro, target, or platform dependency shape;
- compressed or remotely distributed
.loafbundles; - the authored
loaf.toml, resolvedoven.lock, workspace, or registry model proposed for later work; or - broad ecosystem readiness from external-library bake-offs.
Always.
Command details¶
Project bake. A project extension's <identity>.loaf/loaf.json names the exact base Loaf it extends. It canonicalizes compiler-owned runtime artifacts, overlapping locked registry units and vocabulary auxiliaries against the verified release cohort, keeps only the project-owned third-party and provider fragment, and binds each direct registry alias to the exact locked package, version, registry and checksum. The final output a bake compiles stays project-owned rather than joining the shared dependency Loaf.
Replay. Completed-output schema 14 admits ordinary executable publication as well as explicit-bake publication. Ordinary default executable builds retain their exact compiler, environment and selected SDK inventory/graph inputs, generated files, executable and report in the same completed-output loaf store. An unchanged later build returns before session discovery, module collection, typechecking or code generation; missing or damaged caller output is restored from verified loaf bytes. An ordinary executable loaf cannot replace an explicit bake's whole-project inspection authority. The schema preserves target identity and profile isolation, keys additional entrypoints by project-relative path, and carries report schema 2 so replay needs no frontend. The report writes project paths as tagged values and machine-specific external paths as opaque slots, so replay restores caller-owned paths without treating another machine's path spelling as authority. Canonical semantic lock authority excludes only the derived dependency fingerprint, and Rust path-dependency authority includes the exact Cargo workspace package and dependency facts selected through workspace = true. A completed output selects its inspection authority before frontend work, so a source-current, feature-matched bake serves later application, library and test consumers without mixing authority from another receipt lineage.
Freshness. Source authority retains the existing named content digests and caches directory child lists in the same local freshness store. Known files and directories are checked by identity, size, nanosecond modification/change times and permissions on Unix. Unchanged directories reuse their child lists; changed directories are enumerated and only changed candidate files are read. A metadata change alone does not force compilation when content authority is unchanged. Missing or malformed records fall back to observation. Symlinks remain refused by the project authority boundary; platforms without replacement-sensitive metadata conservatively enumerate and read. These observations accelerate reconciliation and do not become a second source of build authority.
Selection. Normal build, run and test try the toolchain's immutable full-standard-library Loaf first; a project outside that envelope selects its receipt-bound extension together with the exact base Loaf the extension records. The selection key includes the target, toolchain, profile, Incan runtime, dependency, feature and provider inputs. The receipt stays source-strict: a source change regenerates caller-owned source and receipt, while a compatible project reuses the same base and extension. A release envelope may select registry-source authority independently from its feature-unified linkable closure, so supported standard-library Rust facades can be inspected without mixing direct-rustc artifacts. The retired Cargo flags on normal commands (--cargo-args, --cargo-features and its companions) are rejected, because a normal command never publishes a missing closure.
The release publisher. The internal release publisher is the only Cargo-backed producer for supported Oven Alpha envelopes, and its Cargo run is transitional: it observes registry packages the incan.pub registry does not describe, and a bake whose registry units all have records does not run it. It creates or exactly reuses the release or compiler-suite standard-library Loaf family, and the compiler-suite path also prepares or reuses the suite store. Each loaf.json binds the direct-rustc plan, declared artifacts, compatibility, provenance, digests and byte accounting. The publisher's Cargo may differ from the consumer's rustc; the latter defines the Loaf's toolchain identity. Compiler-suite JSON reports distinguish the complete-suite, selected-complete-roots and exact-diagnostic selection modes and give separate complete_root_success and complete_suite_success verdicts. The publisher writes harvest proposals from the captures it already holds for stdlib/debug and stdlib/release through incan oven legacy-cargo bake-loafs … --harvest-dir <PATH>; --loaf-registry <PATH> and --loaf-registry-commit <SHA> select the registry checkout whose records govern adopted units and refuse a checkout whose HEAD is not the pinned commit.
The runtime foundation. An explicit release-envelope bake materializes the admitted runtime foundation, rebuilds its runtime dependency closure with the retained compiler, and publishes that closure in the same generation. When build, test or run selects a release ToolchainLoaf, it proves the same-generation foundation and closure, verifies their target, toolchain, profile and compiler bindings, then composes the closure into the caller-owned plan. Missing, invalid or mismatched evidence is a refusal: a normal consumer neither bakes the closure nor invokes Cargo.
Store evidence. A closure proof lets later commands skip re-checking every file of a closure, often ten thousand of them, once one command has materialized it in full; it can be deleted and is recreated. incan inspect oven rehashes what it audits instead of trusting a proof. incan oven store inspect reports the full receipt of the compilation that produced a direct-rustc plan because reuse hands a consumer bytes that another invocation produced, and the store manifest records only that receipt's identity, not its content.
Store generations. The aggregate store limit counts the previous committed Loaf generation while its replacement is staged, so an interrupted update never has to delete the last valid generation to make room.
For the complete command surface, see the CLI reference.