Architecture
Shinro has three layers: the Shinro Studio frontend, the Shinro Backend Kernel, and the module ecosystem the kernel manages. Each is independent. Each has its own contract. Each can be reasoned about in isolation, and each can be replaced without rewriting the others.
1. Shinro Studio frontend
The IDE surface where users blueprint, flow, code, simulate, and deploy. Built in React. The Blueprint Editor uses React Flow for visual composition. The embedded Monaco IDE handles inline code editing. The 3D viewer runs in-browser on Three.js with Rapier physics.
The frontend never speaks directly to a robot. It speaks to the Backend Kernel, which speaks to everything else.
2. Shinro Backend Kernel
The core modular infrastructure that enables the Studio to work. Written in Zig. The kernel manages modules, orchestrates the build and deploy pipeline, and manages the Studio Runtime Layer — the in-Studio execution context where modules run during development.
This is a Studio kernel. It is not a runtime imposed on the deployed robot. Deployed binaries carry no Shinro runtime. The kernel orchestrates the build; the running robot executes native code with nothing of Shinro in the loop. This is the deliberate contrast with runtime-imposing frameworks, which require their runtime to run on the robot itself.
3. Module ecosystem
TOML-defined modules grouped in stores (local and remote), spanning toolchains, libraries, hardware abstractions, and higher-level capabilities. See The Module System for the schema and the composition rules.
Workstream alignment
Two workstreams run in parallel — the Studio frontend and the Backend Kernel. The frontend ↔ kernel integration is the immediate critical path; until it lands, any end-to-end description in these docs is architectural, not operational.