04 — Deployment Targets

Where Zero runs today, what is shipping, built, framed, or aspirational. The same engine library (zero_serve()) is everywhere; only the shell and the capability profile differ. Honesty markers match [../roadmap/consolidation.md](../roadmap/consolidation.md).

The principle: one engine, many doors

The engine is a single library. A platform is a thin native shell — a window, a view surface, and the engine — plus a door (the trust model) and a capability profile (what this device is). Desktop shells *spawn* the engine as a child; mobile, where child processes are forbidden, calls zero_serve() in-process on a worker thread. Same call, same store, same DSL, everywhere. (kernel/embed.h, ../mobile/ARCHITECTURE.md)

Status by target

armv7 caveat (verbatim from the roadmap): the linux-armv7 cross-compile and its CI job are written to the standard armhf-multiarch pattern but were not locally compiled — the dev box has no ARM cross toolchain. The Makefile expansion and the platform-key canonicalization are verified; the first tag build confirms the link. The aarch64 / x86_64 / darwin / windows paths are unchanged.

On "boot-up OS to app" and microcontrollers

The vision is one engine spanning boot-up OS → app, across desktop, mobile, server, microcontroller, and custom hardware. Be precise about where that is today:

• App-to-server is real and shipping across desktop, mobile (Android), and Linux

(incl. ARM/Pi).

• Custom-hardware surfaces (scanner, payment terminal) are *framed and gated* — the

capability-profile + native-primitive pattern exists; specific hardware integrations are future work, not shipped.

• Microcontroller / bare-metal / "boot-up OS" is aspirational: there is no

embedded target, RTOS port, or boot path in the codebase. What makes it *credible* rather than hand-waving is that the engine is ~2,400 LOC, dependency-light (libcurl + system crypto), and already links as a static library with a static dispatch table (no dlsym) — i.e. the same property that let it into a sandboxed mobile app is the property a microcontroller port would need. Treat it as a roadmap destination with an honest runway, not a current capability.

State it this way in any external setting: "runs today from edge devices to servers; designed to scale down to microcontrollers and up to a boot OS."

Runtime auto-assembly — why every target stays slim

An app never ships fat. The engine binary is the tiny floor; behavior (store classes) and speed (compiled-view libs) arrive on demand:

1. A class the machine lacks is hydrated (fetch_dir) — its .action/.data and,

if published, only this platform's compiled-view lib.

2. loadchain dlopens the lib (POSIX desktop/server); run() prefers the compiled

view live.

3. The engine itself auto-updates in place (zero update / shell first-launch fetch);

store content refreshes silently.

So each target gets new behavior, new speed, and a new engine on independent channels, none forcing a reinstall. (../roadmap/consolidation.md, "Runtime auto-assembly")

Mobile/Windows caveat: dynamic-loading of compiled views is POSIX desktop/server only; static-dispatch builds keep the in-binary/interpreted path (notarization forbids dlopen/-rdynamic). They still auto-update the engine and hydrate store content — they just don't dynamic-load compiled libs.

Release model — three components, three tag namespaces

One repo, three independent release cadences sharing one contract (manifest + store):

A component rebuilds only when its tag is pushed — "no update where none is needed." (../roadmap/consolidation.md, "Release model")