evy

a unified-memory, multi-engine, neural-first game engine. selectively forks 16 bevy crates (in evy/forks/); adopts ~20 bevy crates intact from crates.io; replaces 8 with cyber-native primitives. [patch.crates-io] redirects transitive deps on forked crates to our versions. powers cyb and any future cyber-stack game

primary target: Apple Silicon (M-series). portable targets: any UMA platform with NPU + matrix coprocessor (AMD Strix Halo, Qualcomm X Elite, future ARM SoCs). discrete-GPU PC is a degraded-mode target, not a first-class one

0. abstract

evy inverts a decades-old game engine architecture. traditional engines treat the GPU as a remote device behind a copy boundary; evy treats memory as the single shared substrate and compute engines (CPU, AMX, GPU, ANE) as plural peers that operate on it concurrently. presentation is one formally specified protocol (prysm) across 2D and 3D. content is content-addressed particles reached over radio. trust-critical state lives in bbg's polynomial commit. on Apple Silicon, aruminium is the renderer — raster + compute, zero copy, native MTLSharedEvent sync; wgpu is the portable fallback on platforms where Metal is unavailable. intelligence (glia per neuron) is a frame-time-affordable resource

what evy buys from bevy: ~100K LOC of rendering machinery (PBR, post-process, anti-alias, animation, gizmos) that would take a multi-engineer year to reproduce. what evy replaces in bevy: every assumption below the visual stack — storage, scheduler, presentation, scenes, assets, networking, audio. the result is a new engine that uses bevy as its rendering substrate

1. axioms

three axioms generate the engine. change any axiom and the entire system reconfigures

derived: the engine is a multi-engine dispatch graph $\mathcal{D}$ over a single memory pool, with prysm as the universal presentation layer above it

2. invariants

testable constraints. an implementation is not evy until all pass

3. hardware target

evy supports mobile, desktop, console, and XR out of the box. capability varies by platform; the runtime detects what each device offers and the dispatch scheduler routes work to available engines, degrading features that require absent silicon. four target tiers

3.1 first-class (full stack)

every honeycrisp engine available; every feature enabled

macOS distribution is direct (DMG, Homebrew, .app) — no App Store dependency. Apple mobile (iOS/iPadOS) and Vision Pro are not targets (§3.6)

3.2 portable (degraded, supported)

partial engine availability; features that require missing silicon disable

degraded platforms still run the same game content. the engine reports PlatformCapabilities at startup; systems that require absent engines skip, fall back, or fail loudly per FallbackPolicy declared by the system author. content authors target the capability set, not specific platforms

3.3 capability matrix

quick reference for what each platform tier offers

3.4 runtime capability detection

at startup, evy probes the platform and constructs a PlatformCapabilities resource:

struct PlatformCapabilities {
    engines: EnumSet<Engine>,           // which engines available
    has_unimem: bool,                   // IOSurface / AHardwareBuffer / none
    has_amx: bool,
    has_ane: bool,
    npu_kind: Option<NpuKind>,          // ANE | NNAPI | XDNA | Hexagon
    gpu_paths: EnumSet<GpuPath>,        // Wgpu always; Aruminium only on Apple
    memory_class: MemoryClass,          // UMA | UMA_BandwidthLimited | NonUMA
    thermal_budget: ThermalBudget,      // Desktop | Laptop | Tablet | Phone | XR
    tick_rate_hz: u32,                  // suggested tick rate from thermal/battery policy
}

systems and dispatch nodes register fallback policy:

enum FallbackPolicy {
    Required,           // refuse to run if preferred engine missing
    DegradeTo(Engine),  // run on alternate engine with reduced quality
    Skip,               // omit from dispatch if missing
}

a neural material with FallbackPolicy::DegradeTo(Cpu) runs on CPU with reduced batch size when ANE is absent. one with FallbackPolicy::Skip simply doesn't render its neural component, falling through to a baked texture. one with FallbackPolicy::Required refuses to load on platforms without ANE — useful for AI-driven game logic that has no acceptable degradation

3.5 thermal and power policy

mobile targets and laptops on battery have thermal/power limits. evy respects these via:

• tick_rate_hz from PlatformCapabilities — gameplay state cadence (BBG commits) drops on battery
• φ*-budget allocator scales per-particle inference budget by current thermal headroom
• ANE/NPU prefers idle-time burst over sustained dispatch (NPU power efficiency wins when intermittent)
• Android Activity lifecycle: engine checkpoints state on onPause, restores on onResume. checkpoint format = BBG root + ephemeral ShardStore snapshot. background-killed processes restore from checkpoint on next launch

3.6 non-targets

• Apple mobile (iOS / iPadOS) — distribution requires App Store; deployment policy and review process are unacceptable. macOS desktop direct-distribution path is the Apple-side target
• Apple Vision Pro — same App Store constraint as iOS; deferred indefinitely
• WebGPU browser deployment — possible but unimem doesn't survive translation; deferred
• single-threaded environments — the engine assumes parallel engine dispatch
• discrete-GPU desktop as a first-class target — supported (degraded mode per §3.2) but architectural choices favor UMA platforms

4. memory model (axiom $\mathcal{M}$)

4.1 the pool

all buffers shared between ≥2 engines are allocated via unimem primitives:

cells in a Grid<T> are simultaneously:

• a &T in Rust
• a slot in an MTLBuffer for aruminium raster + compute (Apple Silicon)
• an input surface for rane ANE inference
• a tile source for acpu AMX/NEON ops

no copy, no upload, no extract. one IOSurface, many views

4.2 the storage interface

evy adopts bbg's ShardStore trait verbatim (bbg/specs/storage.md). there is no separate "ECS storage." components live in shards. the same trait serves authenticated cybergraph state, ephemeral render buffers, and everything between

trait ShardStore {
    fn get(&self, dimension: u8, key: &[u8; 32]) -> Option<&[FieldElement]>;
    fn put(&mut self, dimension: u8, key: &[u8; 32], value: &[FieldElement]);
    fn dirty_entries(&self) -> impl Iterator<Item = (u8, [u8; 32], &[FieldElement])>;
    fn commit(&mut self) -> [u8; 32];
}

quoting bbg's spec: "the polynomial commitment provides authentication. the local data structure provides access. they are INDEPENDENT — the store doesn't know about polynomials, the polynomial doesn't know about storage." this separation is the keystone. evy inherits it

4.3 backends

five backend implementations of ShardStore, selected per-shard by hardware capability + access pattern + tier policy:

backend selection is per-shard, not per-component-class. on Apple Silicon, a component touched by GPU defaults to unimem; on non-Apple-Silicon, the same component defaults to memory with explicit upload at access. the component definition does not change. there are no storage classes — only backends and dimensions

4.4 the canonical state schema

evy state partitions into 13 namespaces: 10 public dimensions of BBG_poly + 2 private polynomial commitments + 1 ephemeral domain. components register into one

component registration declares one namespace. ephemeral is the default for engine-internal components. authenticated namespaces (everything except ephemeral) participate in BBG_root and emit zheng proofs at tick boundaries (§6.2)

4.5 component → namespace mapping

plain english: pick the namespace your data semantically belongs to (or ephemeral); the backend is resolved from hardware + tier policy. no class hierarchy, no storage taxonomy beyond what bbg already defines

4.6 stable addresses come from the backend

bevy_ecs's Table storage uses swap_remove on archetype change (storage/table/mod.rs:214), which moves component bytes. this is incompatible with GPU buffer descriptors holding addresses

resolution: backend choice. the unimem backend implements ShardStore over slot-pooled IOSurface cells where addresses do not move. the memory backend implements ShardStore over BlobVec with swap-remove semantics. components do not pick a class — they pick a backend (or accept auto-selection), and the backend's allocator determines address stability

cells in the unimem backend carry a generation tag (index: u32, gen: u16). cell reuse bumps the generation. GPU buffers holding stale (index, gen) pairs fail validation on read. this prevents the swap-remove hazard without sacrificing GPU access stability

cost: 6 bytes per shader-visible cell. one extra indirection per query (L1 cache hit, single-digit ns)

4.7 IOSurface lifetimes

per unimem design: IOSurface is locked at creation, unlocked at drop. cells within an IOSurface-backed shard are addressable for the shard's lifetime. cross-process IOSurface sharing works (zero-copy IPC) but is out of v1 scope. cross-engine sharing within process is the load-bearing case

4.8 tier routing

cyb/soma-equivalent policy layer (deferred to v2) sets routing: which shards stay hot (unimem/memory), which demote to ssd, which archive to hdd. evy executes the mechanism; focus (φ*) IS the cache priority. high focus = stay hot; low focus = migrate cold. for v1, default policy: ephemeral + recently-touched authenticated = hot; rest = ssd

5. engine model (axiom $\mathcal{E}$)

5.1 the four engines

an engine is a distinct dispatch context the scheduler must track, not distinct silicon. NEON is part of Cpu because any thread issues NEON instructions in the same stream as scalar, sharing the SIMD register file (v0–v31). AMX is its own engine because per-thread AmxCtx must be initialized before AMX instructions can issue. ANE is its own engine because dispatch goes through rane's MIL bytecode queue, not through the issuing thread. Gpu is one engine with one driver per platform: aruminium (raster + compute, hand-written MSL, zero copy) on Apple Silicon; wgpu (cross-vendor Vulkan/D3D12) on portable targets

each engine has its own dispatch primitive and (where applicable) its own worker context. engines share memory but not state

5.2 one renderer per platform

within engine Gpu, exactly one driver is active per platform — they do not coexist:

aruminium is the renderer on Apple Silicon because the wgpu abstraction taxes ~9–13 ms of frame budget for the same Metal hardware (per-draw-call CPU overhead 5–8 µs vs 1–2 µs; mesh upload BW 25 GB/s vs 70–100 GB/s direct IOSurface; lost MTLSharedEvent cross-engine sync; WGSL→MSL translation cost). on a 16.6 ms frame, that's the difference between 60 FPS and 30. on Apple Silicon evy is Apple-first; portability overhead is paid only where Metal isn't available

wgpu does not coexist with aruminium on Apple Silicon. an earlier draft of this spec proposed sharing MTLDevice between the two drivers; that was reverted (commit 48f1bc8 in honeycrisp/aruminium). on every platform evy ships, exactly one Gpu driver is active

5.3 engine routing rules

a workload routes to an engine by these defaults:

routing is per-node in the dispatch graph, not per-system. one logical Bevy system can spawn work on multiple engines

6. dispatch model (the unified DAG)

6.1 one DAG, two execution semantics

evy's dispatch DAG and bbg's signal DAG are the same DAG. they share infrastructure (ShardStore reads/writes, scheduler, topology). they differ in execution semantics: each node declares a commit policy. some nodes' writes trigger BBG commitment (polynomial recommit + zheng proof + radio gossip). others stay ephemeral and never touch the commit path

trait DispatchNode {
    fn engine(&self) -> Engine;
    fn reads(&self) -> &[ShardRef];
    fn writes(&self) -> &[ShardRef];
    fn dispatch(&mut self, ctx: &mut DispatchCtx);
    fn commit_policy(&self) -> CommitPolicy;
}

enum CommitPolicy {
    None,                  // ephemeral: render output, scratch compute, frame-local state
    BbgDimension(u8),      // writes update a BBG_poly dimension; recommit at tick boundary
    BbgPrivate,            // writes extend A(x) commitment polynomial
}

enum Engine { Cpu, Amx, Gpu(GpuPath), Ane }
enum GpuPath { Wgpu, Aruminium }

bevy_render's existing RenderGraphNodes map to DispatchNode with engine() == Engine::Gpu(Wgpu) and commit_policy() == None. mir's tier passes implement Engine::Gpu(Aruminium) with None. glia per-particle inferences implement Engine::Ane. AMX-batched transform propagation implements Engine::Amx. a gameplay signal handler (currency transfer, cyberlink creation, ownership change) implements CommitPolicy::BbgDimension(d) or BbgPrivate

the render graph is the subset of the dispatch DAG where commit_policy() == None. it is not a separate construct

6.2 the scheduler

per frame, the scheduler:

1. collects all enabled DispatchNodes (render + gameplay)
2. topo-sorts by ShardRef read/write dependencies
3. batches by engine: Wgpu nodes record into one command buffer; Aruminium nodes dispatch to its queue; Ane nodes submit to rane queue; Amx nodes dispatch on pinned threads
4. inserts cross-engine sync primitives at DAG edges that cross engine kinds (§6.3)
5. submits per-engine work in parallel
6. at tick boundary (subset of frames; e.g. every 6th frame at 60Hz → 10Hz tick): collects writes from nodes with CommitPolicy::BbgDimension/BbgPrivate, calls ShardStore::commit() on affected shards, recomputes BBG_root, generates zheng proof, gossips via radio
7. awaits cross-engine sync barriers before next frame

frame ≠ tick. frame is render swap cadence (60–120Hz). tick is gameplay state cadence (10–30Hz). render nodes run per frame; BBG-committing nodes run per tick. one scheduler, two cadences

6.3 cross-engine synchronization

Apple Silicon has no universal barrier. each engine pair has its own sync primitive

scheduler encodes all seven pairs. nodes whose engine pair has no direct sync route through Cpu

6.4 ExtractSchedule collapses

bevy's ExtractSchedule copies MainWorld components into RenderWorld each frame. for unimem-backed shards, the bytes are already shared between worlds via IOSurface. extract becomes a no-op for these shards. for memory-backed shards used across worlds, the original extract path remains valid. result: extract cost scales with the number of shader-visible-but-not-unimem-backed shards, which v1 expects to be near zero

6.5 frame budget

a 60Hz frame is 16.6ms. allocation across engines, default policy:

engines run concurrently. the 31.6ms theoretical sum compresses to 16.6ms wall time because they execute on independent silicon. Ane runs without contending with Gpu — that is the structural advantage evy extracts from Apple Silicon

at tick boundary (every Nth frame), an additional commit cost: ~50μs for BBG polynomial recommit + proof generation. amortized across frames it is invisible; if a single tick batches many signals it can spike. tick rate is tunable per game (10–30Hz typical)

7. presentation model (axiom $\mathcal{P}$)

7.1 prysm is the UI engine

prysm is a formal layout protocol with 14 theorems formalized in Lean 4. evy adopts prysm directly. bevy_ui is replaced

prysm provides:

• layout algorithm: pure function (element tree × viewport → coordinates). O(n), single-pass, deterministic, ≤2ms for 10K organelles
• atoms: glass, text, ion, saber, images
• molecules: 22 composed widgets (button, hud, input, content, neuron-card, ...)
• cells: 3 regional compositions (oracle-cell, sphere-cell, ...)
• aips: 10 full-screen applications
• emotion: computed color signal layer, 4 evaluation rules, formal thresholds, fallback policy
• responsive: fold protocol with optimal conformation selection (theorem T6)
• motion: one duration, one curve, single-pass
• semantic: accessibility layer with formal Semantic role tagging

every prysm spec includes a Bevy-shaped ECS section (Components, Systems). implementation is mechanical transcription of those sections into Rust

7.2 2D and 3D as modes

prysm spans 2D and 3D in one protocol (prysm/layout §11). atoms have identical semantics in both modes; what differs is the renderer

mir is not a separate UI system. mir is prysm's 3D-mode renderer. the same glass atom in 2D draws a translucent quad; in 3D, the same atom occupies depth $s_d$ and z-position $p_z$ driven by gravity. one protocol, two drawers

7.3 prysm crate layout

total: ~11K LOC. implementation work is bounded by the spec, not by design

8. content model

8.1 particle = entity

entity identity IS its particle. spawning a new entity for content that is already a particle returns the existing entity (idempotent). entities without explicit content get an anonymous local particle (hemera hash of session UUID + spawn counter)

implications:

• save/load by particle is structural: World::checkpoint() → root_particle, World::restore(root_particle)
• cross-machine entity reference works without an entity mapper
• duplicate spawn detection is automatic
• entity ID stability across sessions and machines

8.2 component = cyberlink

a component instance is conceptually a cyberlink ask(ν, p, q, τ, a, v, t):

• ν: neuron — who set this component
• p: from-particle — the entity
• q: to-particle — the component value
• τ: type — dialect for this component
• a: stake — 0 for ephemeral components
• v: valence — +1 default
• t: time — tick

Bbg-backed components store the full cyberlink record. Grid and Table components store only the value; the cyberlink metadata is implicit

8.3 .cyb particles as scene format

bevy_scene is deleted. scenes are .cyb particles containing a section of cyberlinks. loading a scene = fetching the particle and replaying its cyberlinks as ECS commands. .cyb format is fixed (TOML frontmatter + ~~~name separators) and supports binary asset sections in-line

8.4 assets are particles

bevy_asset is replaced. asset references use radio://<particle> URIs. the radio adapter (see §9) resolves the particle → bytes via local cache, peers, or fallback relay. .cyb is the universal container; loaders inspect frontmatter and dispatch to type-specific sub-loaders (image, mesh, model, glTF as a section type)

hot-reload happens when a reference resolves to a new particle: gossip notifies subscribers, asset server invalidates handles

9. networking model

9.1 radio as content + replication

radio (built on iroh: QUIC + BAO + gossip + Willow) provides content addressing, streaming verification, P2P discovery, and CRDT-style replication. evy consumes radio as an out-of-engine service

architecture:

[ Bevy app, single thread, deterministic ]
       │
       │ channel handles
       ▼
[ evy_radio adapter, owned tokio runtime ]
       │
       │ iroh API
       ▼
[ iroh endpoint: blobs, gossip, docs, willow ]
       │
       │ QUIC
       ▼
[ peer mesh ]

evy_radio runs its own tokio runtime in a dedicated thread. Bevy holds Res<RadioClient> which is a channel handle. async iroh operations are submitted as messages; completions arrive on a return channel polled at frame start. this isolates iroh's select!-heavy async code from Bevy's executor (compliance with established select! cancel-safety lessons)

9.2 what radio handles

9.3 multiplayer model

no client/server distinction. every player is an iroh node. world canonicality is determined by foculus (collective focus theorem) — the φ* distribution over signals converges to a stable attractor that defines consensus. signals from any neuron propagate via gossip; each node validates and applies independently

cheating is structurally detectable: invalid signals fail verification on receipt; deviating state diverges from the consensus root. recovery is local — out-of-consensus nodes resync from the canonical root

9.4 offline tolerance

every networked operation has a local-cache fallback. fetch returns from cache if available; gossip subscriptions buffer offline and replay on reconnect; signals queue and submit on reconnect. UI never blocks waiting for network. this is invariant N2

10. rendering model

10.1 hybrid raster + inference

a frame composes raster, compute, and neural paths into the same framebuffer. on Apple Silicon all three share one Metal device (aruminium); on portable targets, raster + compute go through wgpu and neural is unavailable

on Apple Silicon, all three paths share buffers via unimem. raster reads positions from a Grid; compute writes positions into the same Grid; neural reads features from a Grid that mir's compute populated. one memory, three pipelines, one device — no cross-driver sync. on portable targets the model degrades per §3.2: same pipelines, no zero copy, fewer engines

10.2 neural materials

a NeuralMaterial is a bevy Material trait impl that, instead of a shader-only pipeline, takes:

• standard inputs (UV, view, normal, light)
• a Model handle (glia model loaded from a .model particle)
• graph context inputs (nearby cyberlinks, cyberank, current path)

and produces radiance via a glia forward pass on ANE. mesh raster (wgpu) handles vertex transform; per-pixel evaluation routes to a precomputed feature map produced by an ANE pass earlier in the frame DAG

constraint: ANE inferences batch per draw call, not per pixel. one inference produces a feature map that the raster shader samples. the feature map is a Grid texture. ~100μs ANE dispatch overhead is amortized across millions of pixels

10.3 φ*-driven render budget

tru produces φ*, the focus distribution over particles. evy consumes φ* as a render budget allocator:

• particles in top focus quantile: full neural material + tier-3 detail + per-frame inference
• mid quantile: cached neural material (inference every N frames) + tier-2 detail
• low quantile: impostor billboard + tier-1 detail
• edge-of-frustum: label-only atom

implementation: a PhiBudget resource holds per-particle render policy. systems consult it before scheduling work. evy_phi_budget crate

10.4 generative cache

an asset that resolves to "particle exists but has no bytes" triggers generation:

generated assets are published back to radio as new particles. peers exploring the same context retrieve the cached generation. evy_generative_cache crate

10.5 speculative graph inference

unexplored regions of the cybergraph get LLM-speculated cyberlinks, signed with low stake. two players exploring the same region see identical speculations (deterministic from context). canonical content from neurons overrides speculations. unresolved game-design question: what does a player who explored a speculation later see when canonical content arrives (open question OQ-6)

11. what bevy provides — adopted intact

these crates are used unmodified from crates.io. ~52K LOC of substrate

12. what bevy provides — adopted with modification

these crates are forked. upstream tracking is loose

13. what bevy provides — replaced or deleted

14. new crates — no bevy equivalent

these crates do not exist in bevy. they are the substance of evy

total landed: 9 crates, ~4.5K LOC, 143 tests. total planned new: ~33K LOC.

15. crate inventory roll-up

ratio: ~10× more bevy code is involved than evy new code. the engine is mostly bevy with surgical replacements at load-bearing seams. that is what makes the project feasible

landed crates have 143 tests passing across 9 crates as of 2026-05-21; end-to-end smoke test in evy_engine_core exercises every subsystem

16. dependencies on soft3 components

v1 ships with: working soft3 components + spec-done prysm. partial components (mir, glia, tru) ship in their current form; defer foculus + mudra to v2

17. open questions

honest gaps that need resolution before or during implementation

18. non-goals

what evy explicitly is not

• a cross-platform game engine with feature parity on every platform — capability tiers (§3.3) make platform differences explicit, not hidden
• a drop-in replacement for bevy that bevy games can port to
• compatible with the bevy plugin ecosystem
• optimal for AAA discrete-GPU PC rasterization workloads
• a research project on every layer simultaneously — adopts soft3 components as-is, forks bevy at chosen seams
• a WebGPU browser engine — unimem doesn't survive WebGPU translation
• self-contained — depends on unimem/acpu/aruminium/rane from honeycrisp and ~15 soft3 components

19. order of attack

implementation sequence. earlier steps unblock later ones

1. ✓ evy_platform_caps + evy_ecs_storage: probe + FallbackPolicy + bbg::ShardStore adapter. memory + unimem backends. ~3 sessions, landed
2. ✓ bevy_tasks extension: AmxTaskPool + AneTaskPool. ~1 session, landed as separate crate evy_engine_tasks (spec deviation; bevy_tasks moves from FORK to INTACT)
3. ⏳ aruminium gains raster support — RenderPipelineState + RenderPassDescriptor + RenderEncoder + render-target Texture, so aruminium is a complete renderer (not just compute) on Apple Silicon. ~3–4 sessions. proposal drafted at ~/cyber/honeycrisp/aruminium/.claude/plans/raster-support.md. The earlier device-sharing constructors (commit 26ba16b) were reverted (48f1bc8) because the wgpu+aruminium coexistence model they enabled costs 9–13 ms/frame on Apple Silicon
4. ◐ evy_engine_dispatch: DispatchNode trait, scheduler, commit-policy, capability-aware fallback. ~4 sessions, sessions 1-2 landed (trait + scheduler skeleton + engine pool routing); sessions 3-4 (parallel layer + real cross-engine sync) blocked on step 3
5. ⛔ bevy_mesh + bevy_image on unimem ShardStore; meshes/textures stop uploading. ~3 sessions, blocked on step 3
6. ⛔ bevy_transform with AMX propagation. first visible perf win. ~2 sessions, blocked on step 4 complete
7. ◐ prysm core + atoms implementation. ~5 sessions, core protocol landed (Π + Φ + K + fold + motion + emotion in evy_prysm_core, 47 tests). atoms blocked on render path
8. ⛔ evy_glia_runtime + evy_neural_material — the wow demo. ~6 sessions, blocked on steps 3+4
9. ⛔ mir tier passes as DispatchNodes. ~4 sessions, blocked on step 3
10. ⛔ BBG signal handlers as DispatchNodes; tick-boundary commit scheduling; cybergraph + nox integration. ~5 sessions, blocked on step 4 complete
11. ◐ evy_radio adapter + ShardStore network-backend impl serving radio://. ~3 sessions, session 1 landed (channel bridge + stub daemon, 6 tests); session 2 = real iroh; session 3 = AssetSource wiring
12. ⛔ prysm molecules + cells + aips. ~10 sessions, blocked on step 7 atoms
13. ⛔ evy_phi_budget + evy_generative_cache. ~4 sessions, blocked on step 8
14. ⛔ bevy_pbr + post-process REWRITE. ~6 sessions, blocked on steps 3+4+5
15. ⛔ Android bring-up. ~5 sessions, blocked on step 4 complete
16. ⛔ evy_nnapi_runtime. ~5 sessions, blocked on step 4 + Android
17. ✓ PMU-backed evy_diagnostic + thermal/power telemetry. ~3 sessions, landed (370 LOC, 11 tests, PMU upgrade path with Wall fallback)

plus landed extras: evy_dialect (300 LOC, 14 tests; particle-identified component schemas), evy_engine_core (340 LOC, 9 tests; assembly + end-to-end smoke test)

progress: 11 of 17 steps complete or substantially started. step 3 reframed: aruminium gains raster (proposal drafted) — the earlier device-sharing path was abandoned after numbers showed wgpu+aruminium coexistence taxes 9–13 ms/frame on Apple Silicon. ~25 sessions of downstream work (steps 4.3-4.4, 5, 6, 8, 9, 10, 14) unblock once aruminium raster lands.

estimated total: ~69 sessions (~180–210 pomodoros, 35–42 days of focused work). this is the substantial-but-tractable scope of v1 including Android-out-of-the-box

20. license

cyber license: don't trust. don't fear. don't beg