Backend Kernel
The Backend Kernel is the core modular infrastructure that enables Shinro Studio to work. Written in Zig — chosen for compile speed and cross-compilation reach.
It is a Studio kernel. It manages the Studio Runtime Layer during development. It is not a runtime imposed on the deployed robot.
No runtime on the robot
The deliberate contrast with runtime-imposing frameworks is that they require their runtime to run on the deployed robot. Shinro does not. The developer chooses what runs on the robot — often nothing from Shinro at all.
Deployed binaries carry no Shinro runtime. The kernel orchestrates build and deployment; the running robot executes native code only. Determinism, scheduling, and execution policy are decided per module, by the module’s author, with no framework-level mandate.
Multi-language compilation
The kernel orchestrates toolchains that compile C, C++, Rust, Python, and others via toolchain modules. The choice of language is the module author’s — develop in whatever fits your target and your team.
Cross-platform reach
Windows, Linux, macOS, Android, iOS, ESP32, Jetson, FPGA (via HDL toolchain modules such as Vivado), and any other target a toolchain module can describe.
The kernel is self-hosting — Shinro builds Shinro. Adding a new target is itself a Shinro module.
On the word “middleware”
Use with care. The Backend Kernel is middleware only in the narrow sense that it enables modules to work together. Shinro Studio is not middleware — it is a developer tool sitting on top of the kernel. The kernel-as-middleware framing is included here precisely so a careful technical reader can stop wondering whether Shinro is being positioned as middleware. It isn’t.
Kernel API
The kernel exposes a small surface for module load, swap, and capability lookup. The canonical API is documented separately.
CLI
The Shinro CLI manages kernel initialization, module installation, composition, and deployment. The reference command listing is documented separately.