项目状态

项	状态
版本	`0.0.2-rc.3`（工作区版本，也是最后一个 tag）。仓库 `HANDOFF.md` 写明：没有计划中的正式发布。
契约版本	`entelechy version` 输出：`api = 1`、`language = 3`、`ir = 1`、`package = 1`
最低 Rust 版本	1.93（`Cargo.toml` 中的 `rust-version`），edition 2024
许可证	MIT
仓库	`Fynn-3D/entelechy`，私有

已验证的平台

以下摘自 HANDOFF.md（“Verified surface, as of main”）：

环境	验证方式
macOS，Apple M4，Metal	每一轮验证
WASI 下的 WebAssembly（`wasmtime`），解释器	在标准输入上提供会话；读写文件的回放（data、mesh、sound、animation、genesis）
浏览器页面：Entelechy 编译为 WebAssembly，在 headless Chrome 中用其 JIT（WebAssembly）和 WebGPU 运行	Web 桥接测试，随 `cargo test --workspace` 运行
解释器、JIT、GPU	所有 `examples//tests/.replay` 在三个后端上运行
36 个语言特性 × 7 种执行形式，8 种窄编码	`crates/backends/conformance`，JIT 与 GPU 对照解释器
随机程序	JIT 逐位一致，GPU 的整数和布尔精确一致（`fuzz.rs`）
变异的文档与协议请求	不会让前端或会话崩溃或挂起（`tests/hostile.rs`）
Blender 5.2、headless Chrome、Godot 4.6、C ABI	`cargo test --workspace`，缺少相应工具时跳过
键盘、指针	手工验证

已知问题（来自 HANDOFF.md）

一台 Windows（RTX 4090）上的浏览器页面打不开一个在 M4 上能打开的大场景；原因未知，需要读取那台机器的浏览器控制台。
浏览器页面的 WebAssembly 内存停留在峰值，大场景约 140 MB；其中约 15 MB 是同时保存在内存和设备上的 Field，大部分是分配器留下的空洞。

只因某个浏览器出错而做的临时处理（浏览器修好后应撤回）：

页面的设备不执行 prefix pass：Apple GPU 上 Chrome 的 WebGPU 在某些逐帧变化的计数下会丢失设备（GpuBackend::declines）。
GPU 把运行时计数的长 builder 循环改写为携带数组的循环：Chrome WebGPU 开启 robustness 时会算错（entelechy_ir::carried_builders）。

有意保留的取舍

在一个 53 个 Kernel 的游戏上测得：check 0.3 s，JIT 首帧 1.8 s，空闲同步 0.23 ms。以下改进被测过但因收益小于复杂度而未采用：JIT 线程池、并行准备一个文档的 Kernel（7%）、每帧一次 GPU 提交（5–20%）。两项成本在真实项目遇到之前保持超线性：数百层深的 use 链，以及含数千个 Kernel 和结构体的单个文档。