@korulang/unikraft — declare a Unikraft unikernel image from the program. Unikraft builds an image from a GNU make tree plus a Kconfig. Both are artifacts the program already has the information to produce, so the library writes them — the same move `koru/docker:image` makes for a Dockerfile. ~unikraft:image(name: "koru") { APPKORU_CFLAGS-y += -DKORU_UNIKERNEL=1 } ~unikraft:kconfig { CONFIG_OPTIMIZE_SIZE: 'y' CONFIG_OPTIMIZE_DEADELIM: 'y' } Then: koruc main.k unikraft gen -> Makefile.uk + Kraftfile WHY THE NAME IS THE LIBRARY'S TO SPELL, not the author's. A Unikraft library registers with `$(eval $(call addlib,<name>))` and then feeds sources through variables named after the SAME name, uppercased and prefixed. A wrong prefix is NOT an error: `addlib` succeeds, nothing attaches, and the image links Unikraft's weak `main`, boots, prints nothing, and exits zero. That is the exact failure the first hand-written seam hit (2026-08-05: "weak main() called. Symbol was not replaced!"), and it is the whole reason `image` derives three lines from one name instead of passing a block through. WHY IT IS `image` AND `kconfig`, NOT `app` AND `config`. `app` is a reserved default import alias (koru's config.zig seeds paths app -> {{ ENTRY }}), and `config` collides with the existing `std/build:config` comptime tor. A first cut of this module used those names in `std/` and failed only when BOTH blocks appeared in one program — each compiled alone. `image` also lines this module up with `koru/docker:image`, which is the same idea for a Dockerfile.