Project status

Item	Status
Version	0.0.2-rc.3 (the workspace version and the last tag). HANDOFF.md: no release is planned.
Contract versions	entelechy version: api = 1, language = 3, ir = 1, package = 1
Minimum Rust	1.93 (rust-version in Cargo.toml), edition 2024
License	MIT
Repository	Fynn-3D/entelechy, private

Verified surface

From HANDOFF.md (“Verified surface, as of main”):

Where	How
macOS, Apple M4, Metal	every round
WebAssembly under WASI (wasmtime), the interpreter	a session served on stdin; the replays that read and write files
A page: Entelechy as WebAssembly in headless Chrome, on its JIT (WebAssembly) and WebGPU	the web bridge’s test, from cargo test --workspace
Interpreter, JIT, GPU	examples/*/tests/*.replay on all three
36 language features × 7 execution forms, 8 narrow encodings	crates/backends/conformance, JIT and GPU against the interpreter
Random programs	the JIT bit for bit, the GPU’s integers and booleans exactly (fuzz.rs)
Mutated documents and protocol requests	never crash or hang the front end or a session (tests/hostile.rs)
External host and DCC bridges, headless Chrome, C ABI	cargo test --workspace, each skipped when its tool is absent
Keyboard, pointer	by hand

Linux and Windows

HANDOFF.md does not list native Linux or Windows among the surfaces verified every round. While writing these docs the CLI was built on Linux (x86_64) with cargo build --release -p entelechy, and new, check, run, replay, graph and serve were run. Building entelechy-player on Linux needs the system library libudev (and pkg-config).

Known issues (from HANDOFF.md)

1. A page on Windows (an RTX 4090) did not open a large scene that a page on the M4 opens; nothing is known of why until that machine’s browser console is read.
2. A page’s WebAssembly memory stays at its peak, about 140 MB for a large scene: some 15 MB of Fields kept both in memory and on the device, most of the rest the allocator’s gaps.

Workarounds for one browser, to be taken back once it no longer fails:

• A page’s device declines prefix passes: Chrome’s WebGPU on Apple GPUs loses the device running them over a count that changes frame to frame (GpuBackend::declines).
• The GPU runs a long builder holding a loop counted at run time as a loop carrying its array: Chrome’s WebGPU, robustness on, computes it wrong (entelechy_ir::carried_builders).

Trade-offs kept by choice

Measured on a 53-Kernel game: check 0.3 s, a first frame 1.8 s on the JIT, an idle sync 0.23 ms. Left out as small gains for new complexity: a JIT thread pool, preparing a document’s Kernels in parallel (7%), one GPU submission a frame (5–20%). Two costs stay super-linear until a real project meets them: a use chain hundreds of libraries deep, and a document of thousands of Kernels and structs.