Koru Standard Library: the `new` part of rings.kz — a named ring with a Koru declaration surface. Joined via `~part new` in rings.kz. std/rings:new(feed, capacity: 256) { value: u64 } std/rings:new(feed, capacity: 256) { reading: Reading } The `{ }` body is the shared declaration grammar — `name: Type` entries, the same shape `std/proto` writes its fields and `std/channel:new` writes its kinds. A ring declares exactly ONE: the element. The name labels the element for diagnostics and generated units; the type is a proto name or a scalar — protos collapse to structs and scalars ride the same machinery (the degenerate one-word element). What the declaration emits into the ring's home module: - `pub const <Proto> = struct { ... }` when the element is a proto and no other consumer derived it yet (the one-name-one-layout ruling). - `__KoruRingT_<n>` / `__koru_ring_<n>` — the typed MpmcRing cell. - `__ring_<n>_enqueue` { value: Elem } | ok | full - `__ring_<n>_dequeue` {} | some Elem | none - a `__rings_decl_<n>` marker line carrying `elem=<name>` so the chain steps validate the ring without re-reading this item. The ops are name-addressed (`std/rings:enqueue(feed, v)`) — a ring exists to be shared across flows and threads, so it is a named static, not a flow-bound handle: the std/list handle model refuses a handle that crosses a flow boundary, which is precisely where a ring does its work. No top-level imports — part files share the merged module's consts; a second `const std` per part lands as a duplicate member in the emitted program. Shared helpers — the channel.kz set, cut to what rings needs.