Research InkUI architecture and Linux delivery options

docs/research/gpu.md

@@ -1,115 +0,0 @@
-# GPU driver evidence and performance workloads
-
-Research for [Establish GPU driver evidence and performance workloads](https://git.bongbetic.com/xavierk/odin/issues/3). All sources were inspected on **2026-09-25**. These are conditional recommendations for the workload decision, not an adopted suite or support guarantee. No drivers were installed, settings changed, device queries executed, or benchmarks run.
-
-## Decision summary
-
-Odin can establish **which device and API worked for a specified operation under the current session**. It cannot certify one universally “correct” driver from a package name, loaded module, advertised API version or benchmark score. Keep discovery, successful execution, output validation, presentation and performance as distinct evidence.
-
-The strongest initial options are a small **headless Vulkan compute profile** using a qualified clpeak build, plus **API-specific rendering workloads** where supported. vkmark and glmark2 offer useful scenes, but their backend requirements and relatively infrequent releases need qualification. No candidate alone measures compute throughput, rendering, compositor behavior, video acceleration and browser usability.
-
-Visible GPU windows remain a decision for **Choose Odin’s workload suite and run profiles**. The user's approval of headed/headless browser modes does not settle GPU presentation. Terminal orchestration can support headless workloads without opening a window; it cannot thereby prove the desktop presentation path works.
-
-## 1. Evidence to collect per device
-
-| Stage | Evidence | Justified conclusion |
-| --- | --- | --- |
-| Hardware and kernel path | DRM/sysfs device, associated PCI or platform identity, bound kernel driver, accessible render node | Device and kernel path are present; userspace API operation is still unproven |
-| API discovery | Vulkan physical-device properties/features/queues; OpenGL vendor/renderer/version from the actual context; OpenCL platform/device type | This implementation advertises these capabilities in this environment |
-| Execution | Bounded allocation, command submission, completion and error outcome on the selected device | The tested operation completed; report device loss, allocation failure and timeout distinctly |
-| Correctness | A known-output compute or rendering check with a defined tolerance | The sampled operation returned an expected result; throughput alone does not supply this proof |
-| Presentation | Successful creation and presentation to a particular X11/Wayland surface, if this mode is selected | That surface/session path worked; headless success is a different finding |
-
-Linux render nodes permit non-global rendering without DRM-master authentication, subject to ordinary filesystem permissions. They do not grant modesetting rights. Treat denied access as capability coverage, not “bad GPU,” and do not respond by elevating the entire TUI or changing device permissions. DRM discovery must include platform devices: ARM GPUs need not be PCI devices. [1]
-
-Vulkan properties include device type, vendor/device identifiers, device UUID, and driver identification. `deviceType=CPU` identifies a typically host-processor implementation; the specification calls device type informational, so combine it with driver/renderer evidence. `driverVersion` is vendor-specified, not universal semantic versioning. `conformanceVersion` describes the implementer's prior conformance testing, not a test of this installation. Where supported, `VK_EXT_physical_device_drm` connects API devices to DRM node major/minor numbers. [2]
-
-**vulkaninfo** is a useful discovery candidate. Its `--summary` covers enumerated devices; `--json=<index>` writes a Vulkan Profiles JSON file for one device. Plain `--json` defaults to the first device, so one successful invocation does not inventory every GPU. Use a private output directory and record the tool/schema version. The inspected SDK tag is `vulkan-sdk-1.4.357.0`, with Apache-2.0 project licensing. [3]
-
-Mesa LLVMpipe/Softpipe are software renderers. Zink is an OpenGL implementation over Vulkan and can use a hardware Vulkan driver: the word “Mesa” or “Zink” is not evidence of software rendering. Mesa and the Vulkan loader also expose selection/override variables, including `LIBGL_ALWAYS_SOFTWARE`, `DRI_PRIME`, `MESA_VK_DEVICE_SELECT` and `VK_DRIVER_FILES`. Record relevant effective overrides and selected devices; do not silently change the user's stack during baseline measurement. Vulkan/OpenCL CPU devices and mock drivers must not contribute a hardware-GPU score. [4][5][6]
-
-## 2. Driver and architecture scope
-
-| Hardware family | Paths worth supporting conditionally | Boundary |
-| --- | --- | --- |
-| Intel | Appropriate Linux kernel driver plus Mesa OpenGL/ANV; an independently available compute runtime | Working OpenGL does not establish Vulkan or OpenCL support. Discover generation-specific capabilities rather than prescribe one package universally |
-| AMD | Supported kernel/userspace combination, commonly amdgpu plus Mesa RADV for Vulkan | RADV and ROCm serve different purposes. ROCm has its own hardware/OS/firmware compatibility matrix; absence of ROCm does not mean ordinary graphics is broken |
-| NVIDIA | NVIDIA's supported userspace/kernel stack, or Mesa NVK and applicable OpenGL path | NVK is a legitimate Vulkan implementation. NVIDIA's open kernel modules still require matching NVIDIA userspace and GSP firmware; “open module installed” does not establish compatibility |
-| ARM SoCs | Panfrost/PanVK for supported Mali, Freedreno/Turnip for supported Adreno, other model-specific Mesa/vendor paths | aarch64 names the CPU architecture, not the GPU API capability. Some devices support GLES without Vulkan; experimental support must not be force-enabled automatically |
-
-Mesa documents RADV's separation from the kernel driver and hardware limitations; Panfrost lists distinct API support by GPU and explicitly warns about experimental PanVK enablement. NVIDIA's inspected `615.71.09` open-module release supports x86_64/aarch64 and Turing-or-later hardware, with corresponding-release userspace/firmware requirements. These examples justify capability probing, not a universal driver recommendation. [7][8][9]
-
-Qualify **x86_64/glibc, x86_64/musl, aarch64/glibc and aarch64/musl** independently for the chosen executable and transitive libraries. Source availability does not certify a binary across that matrix. Void explicitly states proprietary NVIDIA drivers do not support musl; packaging Odin differently cannot erase that driver limitation. Mesa-based paths can be candidates where that GPU and distribution support them. Current ROCm support is also a specific matrix, not a promise for every Linux distribution or libc. [8][10]
-
-## 3. Workload candidates and concrete tradeoffs
-
-| Candidate and inspected version | Measurements, footprint and control | Conditional role |
-| --- | --- | --- |
-| **clpeak 2.1.4**, Apache-2.0; released August 27, 2026 | Current code supports Vulkan, OpenCL, CUDA, ROCm/HIP, oneAPI and CPU, among others. CLI has backend/device/test selection and JSON/CSV/XML output. `--max-time` controls each GPU test's timed phase; warmup/calibration add time. C++17/CMake; SDKs/backends are optional but auto-detected by default | Strong first candidate for a deliberately restricted CLI build and selected Vulkan FP32/bandwidth workloads. Pin enabled backends, shaders and compiler; avoid its “run every backend/device/test” default |
-| **vkpeak 20260527**, MIT; source activity in August 2026 | Vulkan peak scalar/vector/matrix arithmetic and transfer tests using ncnn. Select device and scenarios. Small top-level program, substantial transitive shader/runtime dependency. No user time-budget option is documented in the inspected CLI | Alternative focused compute candidate. Its README explicitly says peak metrics do not represent real-world use. Source returns zero for some unsupported features **and failures**, so zero cannot be interpreted as measured zero performance |
-| **vkmark 2025.01**, LGPL-2.1-or-later | Configurable Vulkan rendering scenes, dimensions, present mode, duration and device UUID selection. C++17, Vulkan, GLM and Assimp; optional XCB/Wayland/DRM/GBM dependencies | Candidate graphics profile after backend qualification. The released source includes a headless plugin requiring `VK_EXT_headless_surface`; its manpage backend list omits that plugin. Generic Vulkan support alone is insufficient |
-| **glmark2 2023.01**, GPLv3 | OpenGL 2.0/GLES2 scenes; per-scene duration, off-screen mode, frame-end/swap controls, output validation and CSV/XML results. Build flavors include X11, Wayland, DRM and GBM; GL/EGL/GLES and image libraries/assets | Useful compatibility and rendering candidate; its older API workloads are not a complete modern-GPU assessment. GBM source can use a selected render node; `--off-screen` on an X11 build does not imply display-server independence |
-
-Primary released READMEs, manuals, licenses and implementation sources support this comparison. glmark2's latest inspected tag remains 2023.01 with main activity in September 2025; vkmark's latest tag is 2025.01 with main activity in September 2025. These are maturity/maintenance observations, not evidence of current hardware certification. clpeak and vkpeak show more recent source/release activity, but still require qualification. [11–14]
-
-Two implementation traps matter immediately:
-
-- clpeak's Vulkan instance requests Vulkan 1.0 or 1.1 depending on compiled optional features. Its reported capability floor therefore depends on the build. Its timing code performs warmup and calibration before the timed batch; `--max-time` is not an end-to-end timeout. Its Vulkan backend distinguishes CPU and integrated/discrete GPU device types. [11]
-- vkpeak adapts work and reports peak results, with memory sizing based partly on device heap information. A selected subset is more controllable than its complete default suite, but a wrapper still needs independent resource and runtime bounds. Neither tool's advertised throughput proves it checks the numerical result required by Odin's correctness stage. [12]
-
-Licenses above describe inspected project code. Bundling requires a separate manifest for assets, embedded dependencies, modifications and any vendor runtime redistribution terms; these source inspections are not a completed distribution-license audit. Installing a large CUDA/ROCm SDK solely to enable baseline benchmarking would weaken the universal deployment objective. Vendor-specific compute paths are better considered optional capability profiles.
-
-## 4. Headless, desktop, multiple GPUs and virtualization
-
-Keep three execution classes distinct: **surface-free compute**, **offscreen rendering**, and **desktop presentation**. Vulkan does not require every physical device or queue to support presentation. Support must be queried for the actual surface. FIFO presentation waits on vertical blanking; an FPS result can therefore reflect display/compositor policy rather than maximum render throughput. Fix and record present mode, resolution and backend. [15]
-
-vkmark's headless plugin still uses a Vulkan surface/swapchain extension; glmark2's GBM backend opens a render node and creates a GBM surface. These are different requirements and workloads. A KMS/direct-display backend may need display ownership and disturb the session, so it is not an automatic fallback when X11/Wayland fails. An SSH terminal can have usable GPU compute without a display socket; classify presentation as unavailable in that session rather than infer a missing graphics driver. [1][13][14]
-
-Enumerate all devices, map them to stable identifiers where available, and let the run profile select the display GPU, another named GPU or separate per-GPU runs. Do not treat index zero as “best GPU.” Mesa's selection variables can reorder enumeration; vkmark's UUID selector and NVIDIA's documented UUID/PCI-ID selection illustrate stronger identity mechanisms. Avoid summing overlapping APIs or independently averaging all installed GPUs into one unexplained number. [2][5][9][13]
-
-Virtual hardware needs its own label. Mesa Venus serializes Vulkan through virtio-gpu to a host renderer and can operate over hardware **or Lavapipe**; guest enumeration does not establish physical passthrough. A VM result measures that guest path, while its host telemetry may be hidden. Passthrough must be established from the recorded environment and device evidence. Containers similarly need device access and compatible userspace libraries; missing exposure is not proof the host has no GPU. [6][16]
-
-## 5. Reproducibility, safety and diagnosis
-
-Before scoring, freeze workload version, scene/kernel code, input size, precision/vector width, backend, device, output format, build flags and compiler. Record kernel, userspace driver identity, power source, thermal state, display mode and concurrent load. Warmup/cache policy must be explicit. Compare repeated runs under the same policy; do not compare shader compilation included in one result with warmed execution in another.
-
-Compute FLOPS, transfer bandwidth and scene FPS answer different questions. A CUDA FP16 matrix peak cannot replace a Vulkan FP32 score; software rendering cannot replace the hardware result; unavailable features are not zeros. Preserve upstream metrics and chosen aggregation rules. glmark2/vkmark aggregate FPS does not automatically supply frame-time percentiles. Small rendering scenes can also be CPU/driver limited, so unexpectedly low throughput is evidence to investigate, not automatic proof of defective hardware.
-
-Recommended safety boundaries are one GPU workload at a time, bounded memory demand with system/VRAM reserve, an independent wall-clock watchdog, staged process-group cancellation, and refusal of unbounded “run forever” modes. Include initialization/calibration in the overall budget. Stop on device loss, repeated API errors or meaningful driver-reported critical thermal findings; retain partial results. Killing a client cannot guarantee immediate recovery from a kernel/driver hang. Do not automatically overclock, alter fan/power limits, reset a GPU or replace drivers. Resource limits and safe cancellation remain acceptance tests for the selected workload.
-
-Telemetry is supporting evidence, with provider-specific meaning:
-
-- NVIDIA `nvidia-smi` documents unsupported values as `N/A`, separate errors for permission denial, unloaded driver and missing NVML, and stable UUID/PCI selection. Its utility success does not test Vulkan/OpenGL presentation. Read-only query adapters must preserve unavailable/error outcomes. [9]
-- amdgpu exposes temperature, load, power and other sysfs metrics, but support varies. Its APU power reading includes CPU power, so it is not interchangeable with discrete-GPU-only power. [17]
-- Linux DRM fdinfo defines per-client engine-busy counters, capacities and accounting rules; availability depends on the driver and accessible process descriptors. These can help attribute work without assuming one vendor's utilization meaning applies everywhere. [18]
-
-Advice should name the evidence: “Vulkan userspace driver could not load,” “render-node access denied,” “software renderer selected,” “this feature is unsupported,” or “workload lost the device.” A package/version mismatch needs concrete loader or vendor evidence; a successful fallback may be intentional. Present a distro-appropriate investigation step with confidence and tradeoffs, rather than an unconditional “install proprietary drivers.”
-
-## 6. Decisions and limits carried forward
-
-The workload decision must choose: headless compute and graphics requirements; whether visible GPU presentation is allowed; selected tool/build and minimum API features; treatment of software/virtual/unsupported paths; default multi-GPU selection; memory/runtime budgets; and the correctness check and scoring eligibility rules.
-
-Before a supported release, qualify the four architecture/libc lanes, real Intel/AMD/NVIDIA hardware, representative ARM SoCs, X11/Wayland/headless sessions, multiple GPUs, denied permissions, software rendering, VM acceleration/passthrough, and cancellation/device-loss fixtures. No such execution evidence was produced here. No package-size estimates or full vendor conformance/redistribution audit were established.
-
-Context7 resolution preceded documentation lookup. Its glmark2 queries yielded no relevant main-project documentation; clpeak was unindexed; vkpeak resolved to an unrelated speech tool and was rejected; NVIDIA NVML searches produced unrelated/wrapper results. Official tagged source and vendor documentation supplied those gaps. The guessed Mesa Lavapipe page returned 404; software/virtual-path claims use inspected Mesa driver documentation and API/device evidence instead. Current Mesa pages contain evolving and occasionally differing generation summaries, so no exhaustive model support table is inferred from them.
-
-## Sources
-
-1. [Linux DRM userspace API, render nodes](https://docs.kernel.org/gpu/drm-uapi.html).
-2. [Vulkan device/queue specification](https://github.com/KhronosGroup/Vulkan-Docs/blob/main/chapters/devsandqueues.adoc), physical-device, driver, UUID and DRM properties.
-3. Vulkan Tools SDK tag: [vulkaninfo documentation](https://github.com/KhronosGroup/Vulkan-Tools/blob/vulkan-sdk-1.4.357.0/vulkaninfo/vulkaninfo.md), [license](https://github.com/KhronosGroup/Vulkan-Tools/blob/vulkan-sdk-1.4.357.0/LICENSE.txt).
-4. Mesa [platforms/drivers](https://docs.mesa3d.org/systems.html), [LLVMpipe](https://docs.mesa3d.org/drivers/llvmpipe.html), [Zink](https://docs.mesa3d.org/drivers/zink.html).
-5. [Mesa environment variables](https://docs.mesa3d.org/envvars.html), [Vulkan loader driver discovery](https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderDriverInterface.md).
-6. [OpenCL device enumeration](https://github.com/KhronosGroup/OpenCL-Registry/blob/main/specs/unified/refpages/man/html/clGetDeviceIDs.html), [Vulkan Guide support/null-driver discussion](https://github.com/KhronosGroup/Vulkan-Guide/blob/main/chapters/checking_for_support.adoc), inspected through Context7.
-7. Mesa [ANV](https://docs.mesa3d.org/drivers/anv.html), [RADV](https://docs.mesa3d.org/drivers/radv.html), [NVK](https://docs.mesa3d.org/drivers/nvk.html), [Panfrost](https://docs.mesa3d.org/drivers/panfrost.html), [Freedreno/Turnip](https://docs.mesa3d.org/drivers/freedreno.html).
-8. [ROCm current compatibility matrix](https://rocm.docs.amd.com/en/latest/compatibility/compatibility-matrix.html).
-9. NVIDIA [open-module 615.71.09 README](https://github.com/NVIDIA/open-gpu-kernel-modules/blob/615.71.09/README.md), [nvidia-smi documentation](https://docs.nvidia.com/deploy/nvidia-smi/index.html).
-10. [Void musl compatibility](https://docs.voidlinux.org/installation/musl.html).
-11. clpeak 2.1.4: [README](https://github.com/krrishnarraj/clpeak/blob/2.1.4/README.md), [CLI options](https://github.com/krrishnarraj/clpeak/blob/2.1.4/src/common/options.cpp), [Vulkan timing/instance implementation](https://github.com/krrishnarraj/clpeak/blob/2.1.4/src/vulkan/vk_peak.cpp), [device mapping](https://github.com/krrishnarraj/clpeak/blob/2.1.4/src/vulkan/vulkan_device.cpp), [build options](https://github.com/krrishnarraj/clpeak/blob/2.1.4/CMakeLists.txt), [license](https://github.com/krrishnarraj/clpeak/blob/2.1.4/LICENSE).
-12. vkpeak 20260527: [README](https://github.com/nihui/vkpeak/blob/20260527/README.md), [implementation](https://github.com/nihui/vkpeak/blob/20260527/vkpeak.cpp), [build/dependency configuration](https://github.com/nihui/vkpeak/blob/20260527/CMakeLists.txt), [license](https://github.com/nihui/vkpeak/blob/20260527/LICENSE).
-13. vkmark 2025.01: [README](https://github.com/vkmark/vkmark/blob/2025.01/README.md), [manual](https://github.com/vkmark/vkmark/blob/2025.01/doc/vkmark.1), [headless implementation and license notice](https://github.com/vkmark/vkmark/blob/2025.01/src/ws/headless_native_system.cpp), [backend build](https://github.com/vkmark/vkmark/blob/2025.01/src/meson.build).
-14. glmark2 2023.01: [README/license declaration](https://github.com/glmark2/glmark2/blob/2023.01/README), [manual](https://github.com/glmark2/glmark2/blob/2023.01/doc/glmark2.1.in), [GBM implementation](https://github.com/glmark2/glmark2/blob/2023.01/src/native-state-gbm.cpp), [build flavors](https://github.com/glmark2/glmark2/blob/2023.01/meson_options.txt).
-15. [Vulkan WSI specification](https://github.com/KhronosGroup/Vulkan-Docs/blob/main/chapters/VK_KHR_surface/wsi.adoc), surface support, headless surfaces and present modes.
-16. [Mesa Virtio-GPU Venus](https://docs.mesa3d.org/drivers/venus.html).
-17. [Linux amdgpu thermal/power monitoring](https://docs.kernel.org/gpu/amdgpu/thermal.html).
-18. [Linux DRM usage-statistics ABI](https://docs.kernel.org/gpu/drm-usage-stats.html).

docs/research/portability-ui.md

@@ -0,0 +1,141 @@
+# Establish InkUI architecture and Linux delivery options
+
+Research for [Establish InkUI architecture and Linux delivery options](https://git.bongbetic.com/xavierk/odin/issues/6), part of [Find the way to Odin’s build-ready specification](https://git.bongbetic.com/xavierk/odin/issues/1).
+
+Access date: **2026-09-25**. This report records evidence and conditional recommendations, not an architecture decision. No dependencies were installed, application code built, or benchmarks run. InkUI is a user requirement throughout.
+
+## Decision summary
+
+The strongest initial candidate is a TypeScript/React terminal application using **copied InkUI components**, a maintained Node runtime, and separately supervised workload processes. Node 24 provides a maintained baseline today. Ink 7.1.1 offers useful mouse-layout and terminal-lifecycle primitives, but moving InkUI beyond its declared Ink 6 range requires a focused compatibility proof. Staying on Ink 6.8.0 avoids that version change while leaving more application work around positioning and terminal ownership.
+
+Bun is a credible alternative delivery/runtime candidate because it publishes glibc and musl binaries for both requested architectures and supports compiled executables. Its documented Node compatibility differences mean it needs an explicit subprocess, terminal, and asset-loading qualification before adoption. Neither runtime choice makes every benchmark available on every machine. **Capability coverage**, operating-system support, and comparable **performance measurements** need separate contracts.
+
+## 1. Exact InkUI identity and maturity
+
+The requested project is **kamlesh723/InkUI**, not the separate `vadimdemedes/ink-ui` library. Its installer is `@inkui-cli/inkui`; npm reports **0.5.0**, published May 4, 2026. GitHub’s latest release is still **v0.4.0**, published April 12. The inspected main commit is `e3110d89b3f0933bcb297a6af33318124c889f36`, also May 4. Pin the actual source commit and installer version rather than treating those release signals as interchangeable. [1][2]
+
+InkUI copies `.tsx` source and shared theme code into the consuming project. Individual component packages also exist. The source-copy route fits adapting mouse handling, accessible output, and Bongbetic themes, but transfers responsibility for reviewing upstream fixes and maintaining local changes. Its MIT notice must accompany copied/substantial source. Upstream documentation specifies Node ≥20, React `^19.0.0`, and Ink `^6.0.0`; its CI covers Ubuntu with Node 20, not a Linux/libc/terminal matrix. These facts establish an early component project with useful source, not broad deployment certification. [1][3]
+
+Verified component capabilities:
+
+- **Themes:** semantic color tokens, dark/light defaults, custom colors, and border styles. A global theme context is application code in the guide, not automatic global behavior.
+- **Keyboard:** input components use Ink input handlers; hooks provide indexed focus cycling and key bindings. Odin still owns modal focus, consistent shortcuts, and cancellation.
+- **Graphs:** Sparkline uses Unicode blocks, averages samples when downsampling, and can display latest/min/max values. Its declared `height` parameter is unused in the inspected implementation. Gauge supports bar, ring, and arc forms with thresholds. These are small displays, not a complete plotting/interaction system.
+- **Fallback:** ASCII borders exist, but graph glyphs remain Unicode. Terminal sizing tracks resize events and defaults to 80×24.
+- **Mouse/accessibility:** inspection found no terminal mouse implementation or ARIA annotations in InkUI components; mouse references in the repository belong to its website. The README’s accessibility description is not evidence of complete accessible interactions. [4]
+
+## 2. Runtime choices and support floors
+
+| Candidate | Evidence and fit | Decision condition |
+| --- | --- | --- |
+| Node 24 + React 19 + Ink 6.8.0 | Ink 6.8 requires Node ≥20 and React ≥19; it satisfies InkUI’s declared major range. Node 24 remains supported through April 2028. | Prefer if preserving the declared InkUI range matters most and the interaction proof can supply the missing mouse/terminal behavior cleanly. |
+| Node 24 + React ≥19.2 + Ink 7.1.1 | The released Ink 7.1.1 manifest requires Node ≥22 and React ≥19.2. It adds public element coordinates and terminal controls useful to Odin. | Prefer if copied InkUI components pass adaptation tests; do not force installation past peer constraints and call that compatibility. |
+| Node 26 | Scheduled Current release today, with LTS due October 28, 2026. Official Linux builds also require `libatomic`, unlike the Node 24 build documentation. | Consider as a forward-compatibility lane or release baseline after qualification; “newest” alone is insufficient. |
+| Bun 1.4.2 | Latest inspected release; official x64/arm64 glibc/musl artifacts and executable compilation. Node `tty` is documented as implemented, with behavioral differences; `child_process` and `process` remain partially compatible. | Candidate only after the same terminal, process-tree cancellation, signals, and dependency-asset tests as Node. No InkUI-on-Bun certification was established here. |
+
+Node 20 reached its scheduled EOL on April 30, 2026; Node 22 is maintained until April 2027, while Node 25 is already EOL. React’s current registry version is 19.3.0, but an actual runtime/renderer pair must be pinned together. The released Ink 7.1.1 manifest differs from its evolving main branch, so use release-tag evidence for implementation. [5][6][7]
+
+**Node 24’s official Linux baseline** is kernel ≥4.18, glibc ≥2.28, and libstdc++ providing `GLIBCXX_3.4.25`, for x64 and arm64 Tier 1 platforms. Older kernels may run but are not the documented official-binary baseline. Upstream also excludes vendor-EOL operating systems. x64 musl appears as Experimental; arm64 musl is absent from that platform table. Unofficial musl builds exist for both architectures but explicitly disclaim rigorous testing and guarantees. [8]
+
+Void supplies downstream Node builds: its inspected package recipe is Node 24.18.0 with distribution library dependencies and cross-build handling. That is a viable source of a musl runtime, not proof that an arbitrary downloaded Node binary works on musl. Void itself supports glibc and musl variants. The handbook specifically states that proprietary NVIDIA drivers do not support musl; Odin must explain that limitation rather than attempting to hide it with packaging. [9]
+
+Bun’s current documentation specifies glibc ≥2.17, x64 SSE4.2/Nehalem or newer, official musl alternatives, and both requested architectures. It recommends kernel ≥5.6 while claiming operation down to 3.10 with degraded newer syscalls. Current x64 documentation says one binary selects AVX paths at runtime; old advice about choosing separate baseline/modern builds is stale. The inspected installation page does not establish a precise musl version floor. Certify the chosen release and artifact; do not interpret a runtime boot floor as Odin’s complete feature floor. [7]
+
+## 3. Mouse, terminal behavior, and accessibility
+
+**Mouse is the main UI feasibility gate.** Xterm defines reporting modes and SGR mouse encoding; enabling reporting is only the transport. Odin also needs event decoding, click/wheel semantics, clipping, focus transfer, hit testing, and restoration of modes. A small established input adapter is worth assessing before custom parsing, but this investigation does not endorse an unexamined package. InkUI remains the component source. [10]
+
+Ink 6’s public measurement API returns only dimensions. Ink 7.1.1 returns `x`, `y`, width, and height after layout. Its documentation explicitly warns that these coordinates are relative to the live layout, not the terminal viewport. Static output above the live region, scroll offsets, borders, and resizing must be accounted for before comparing mouse coordinates. Neither inspected Ink API supplies a complete mouse interaction system. The proof should cover clicking a scrolled table row, scrolling inside a panel, overlapping dialogs, resizing, and keyboard parity. [5][11]
+
+Ink 7.1.1 documents alternate-screen ownership, noninteractive output, render-rate control, terminal suspension, and screen-reader mode. Noninteractive rendering emits only the final non-static frame at unmount, which is not a sufficient progress/reporting policy by itself. Ink’s basic screen-reader mode supports a subset of ARIA and `INK_SCREEN_READER=true`; Odin must add meaningful labels, numeric graph alternatives, state descriptions, and restrained updates. Release-tag documentation says raw-mode setters can throw when unsupported; indexed main-branch documentation described newer behavior. Do not mix these contracts. [11]
+
+Recommended terminal contract for the subsequent UX decision:
+
+- Full interactive layout in certified terminals; keyboard access to every action; mouse where reporting is available. Mouse absence should not make a run unusable.
+- An explicit plain mode for redirected output, unavailable raw input, `TERM=dumb`, and accessibility preferences. Keep readable progress, result summaries, and noninteractive arguments for Bash automation. Bash support means a normal executable and stable exit behavior; orchestration should not depend on users’ shell aliases or startup files.
+- Independent controls for color, Unicode decoration, animation, and interactive layout. `NO_COLOR` concerns ANSI color and explicitly does not disable bold/underline; it is not an ASCII or screen-reader switch. Graph numbers and health states must remain understandable without color. [12]
+- No unsupported claim that `$TERM` alone proves capability. Qualify an xterm-compatible/VTE terminal, a modern enhanced-protocol terminal, SSH with a PTY, tmux with mouse on/off, Linux console, and pipes. tmux mediates events and terminal features; its configuration and remote terminfo are part of the compatibility environment. [13]
+- On normal exit, cancellation, exceptions, SIGTERM, and terminal handoff: restore raw mode, mouse reporting, cursor, and screen state. SIGKILL cannot execute application cleanup; qualify recovery behavior and a readable rerun, without promising impossible restoration guarantees.
+
+## 4. Distribution and offline execution
+
+Treat **xbps, deb, and rpm as delivery formats**, not interchangeable dependency namespaces or compatibility guarantees. A native payload still carries architecture, libc, shared-library, and CPU constraints. Debian’s policies distinguish absolute dependencies from recommendations and require generated shared-library dependencies; RPM records requirements and package signatures; Void separates architecture/libc repositories and requires signed remote repositories. [14]
+
+Three delivery options merit a final choice:
+
+| Delivery | Advantage | Ownership cost / qualification |
+| --- | --- | --- |
+| Native packages using a maintained distro Node | Distro security updates, conventional dependency ownership, natural Void musl integration. | Supported distro releases must provide the selected runtime range; package names and versions vary. JS-only files can be architecture-independent, but included runtime/helper binaries cannot. |
+| Portable archive containing pinned Node plus built JS/assets | Predictable runtime without npm on the target; simple inspection and Bash launcher. | Separate x64/arm64 and glibc/musl artifacts; Bongbetic owns runtime security updates, signatures, licenses, and musl build provenance. A bundled runtime still has system-library requirements. |
+| Bun compiled executable | Documented targets cover the four architecture/libc combinations and can embed assets. | A separate binary per target still needs qualification. Current docs enable `.env`/`bunfig.toml` autoloading by default; deterministic execution should disable or explicitly control that behavior. Subprocess compatibility remains a gate. |
+
+Node 24’s single-executable feature is in active development and embeds a CommonJS script; ESM dependencies, bundled assets, and cross-platform code-cache restrictions add work. It should not be the default merely to produce one file. A portable directory can be a complete product. [15]
+
+Recommend separating acquisition from a **benchmark run**. Core UI, manifests, fixtures, and chosen baseline workloads should run offline once prepared. Optional tools, browser engines, language toolchains, and large datasets need declared versions, origins, digests, licenses, sizes, and cache locations. Distribution packages or a verified offline bundle can supply them. Installation should be an explicit preparation action; a timed measurement must not fetch “latest,” upgrade drivers, or change kernel settings.
+
+When a dependency is unavailable, record a precise capability-coverage reason. Do not replace a workload silently and reuse its score identity. Decide later whether the default installer acquires the full standard run profile or a smaller core with optional packs. Keep package-manager scripts and network access out of privileged measurement operations.
+
+## 5. Measurement and privilege boundaries
+
+A UI runtime does not need to be the workload implementation language. Node’s asynchronous child-process API can orchestrate existing executables without a shell, so the evidence does not require a second application language now. A native helper becomes justified if a selected workload needs precise memory access, direct kernel APIs, or a small enforceable watchdog/privilege boundary that existing tools do not provide. That choice belongs after workload requirements are known. [16]
+
+Proposed ownership boundaries:
+
+1. An unprivileged InkUI process owns navigation, branding, readable progress, and reports.
+2. A runner owns the run manifest, executable identity, timing, output limits, process lifecycle, and persisted measurements. Use explicit arguments and controlled environment variables, not shell command construction.
+3. Privileged operations, when required, receive narrowly validated operation/target requests. Do not elevate the complete React/Bun/Node application or expose a generic root command executor. Validate device identity, paths, ownership, and temporary-file boundaries; retain original-user ownership of local results. Read-only diagnostics and storage writes require distinct authorization/safety rules.
+
+UI graphs, animation timers, garbage collection, logging, and synchronous parsing can perturb CPU, memory, and I/O measurements. Separate processes prevent event-loop coupling but still share hardware. Recommend pausing decorative updates during timed windows, buffering bounded observations, and reporting afterward. If live charts remain necessary, cap their sampling/render rate and quantify UI-on versus quiet-mode overhead on low-end hardware. Do not silently reserve a core or change affinity/governors: these alter the benchmark’s execution conditions. Record any chosen isolation policy in the run manifest.
+
+Cancellation is more than calling `child.kill()`: Node documents that killing a parent does not kill Linux descendants. A runner needs process-group ownership, staged termination, exit collection, and orphan handling after UI failure. cgroup v2 can provide stronger group limits and termination, but controller availability and delegation permissions must be probed. Kernel documentation states that controller exposure depends on configuration and hierarchy ownership; `cgroup.kill` and memory limits cannot be presumed available on every system. No systemd dependency is necessary for the core model. [16][17]
+
+For dangerous pressure profiles, refuse execution when required containment or the independent watchdog cannot be established; explain the unavailable capability. A plain performance run can use a simpler supervision path if its workload contract allows it. Discover actual kernel interfaces such as PSI files rather than assuming them from version numbers; record missing features without inventing zero pressure. [17][18]
+
+## 6. Proposed certification matrix
+
+These are future release gates, not completed tests. Use exact image/artifact digests and record kernel, architecture, libc, runtime, terminal, and relevant permissions.
+
+| Lane | Suggested coverage | What it establishes |
+| --- | --- | --- |
+| Native packages | Void glibc + musl; maintained Debian/Ubuntu; maintained Fedora and enterprise RPM family. | Install, upgrade/remove, dependency declarations, offline start, paths/ownership, normal-user behavior. |
+| Architecture/libc | x86_64/glibc, x86_64/musl, aarch64/glibc, aarch64/musl. At least Void and Alpine as distinct musl environments if both are claimed. | Loader/runtime and transitive-asset compatibility. Native ARM hardware is required before treating emulation success as ARM performance evidence. |
+| Kernel/permissions | Oldest promised supported ABI; supported LTS and current distro kernels; runit and systemd; cgroup v2 delegated/denied/absent; restricted proc/sys access. | Capability probing, fallback, supervision, explicit refusal where safe containment is unavailable. |
+| Terminal/input | Local VTE/xterm-compatible terminal, a modern terminal, SSH PTY, tmux, Linux console, 80×24 and narrow resize, Unicode/ASCII, no color, screen reader, piped output. | Input, readable numeric alternatives, output contract, cleanup, no raw-mode crash. |
+| Failures | Cancel each workload phase, terminate UI/runner, missing tool, permission denial, low disk space, invalid persisted result. | Process/resource cleanup, bounded logs, durable result state, useful failure explanations. |
+| Physical measurement | Intel/AMD x86_64 and ARM; AMD/Intel/NVIDIA graphics where supported; NVMe/SATA/HDD; laptops with thermal/power transitions. | Device visibility, real drivers, SMART interpretation paths, thermal effects, representative performance and UI-overhead measurement. |
+
+VMs are suitable for package/ABI/terminal/failure-path qualification and measuring the VM itself. Virtual storage, virtual GPUs, host scheduling, and hidden hardware telemetry cannot certify physical drive replacement advice, native GPU performance, or host memory health. Passthrough creates a separate recorded environment, not an exemption from those distinctions. Real faults should be covered with parser fixtures and controlled validation; do not deliberately damage hardware to prove a health rule.
+
+## 7. Decisions still required
+
+1. Node 24 versus another maintained runtime; Ink 6 compatibility versus adapting copied components to Ink 7; exact version pin and upgrade policy.
+2. Native-package dependencies, portable runtime archives, or both; who maintains and certifies musl builds; minimum OS/kernel/libc/CPU contract.
+3. A mouse/focus/terminal-lifecycle prototype retaining InkUI, plus the accessible/plain output acceptance criteria.
+4. Core versus optional offline workload packs, licensing and size limits, and dependency acquisition policy.
+5. Per-workload privilege/containment requirements, behavior after UI death, and the quantitative UI-overhead acceptance threshold.
+6. Exact release certification matrix and which capabilities can be certified only on physical hardware.
+
+Evidence limits: no compatibility or performance claim was established by execution; no universal Node/Bun/InkUI bundle was produced; installed Void package availability on every target was not checked; Bun’s precise musl floor and InkUI-on-Ink-7/Bun behavior remain unverified. Browser/driver/workload selection and scoring are separate investigations.
+
+## Sources and method
+
+All sources below were inspected on **2026-09-25**. Context7 library resolution preceded documentation queries for Node, Ink, Bun, XBPS/Void, Debian Policy, RPM, and tmux. Two earlier exact-InkUI searches returned unrelated libraries and were rejected; the requested repository was inspected directly. Context7 results tracking `master` were checked against released source where version behavior mattered. No quota error occurred.
+
+1. [InkUI README at inspected commit](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/README.md), [installer manifest](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/apps/cli/package.json), [npm registry](https://registry.npmjs.org/@inkui-cli%2Finkui).
+2. [InkUI v0.4.0 release](https://github.com/kamlesh723/InkUI/releases/tag/v0.4.0), [inspected commit](https://github.com/kamlesh723/InkUI/commit/e3110d89b3f0933bcb297a6af33318124c889f36).
+3. [InkUI MIT license](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/LICENSE), [installation guide](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/apps/docs/content/getting-started/installation.mdx), [CI](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/.github/workflows/ci.yml).
+4. InkUI inspected source: [themes](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/packages/core/src/theme.ts), [hooks](https://github.com/kamlesh723/InkUI/tree/e3110d89b3f0933bcb297a6af33318124c889f36/packages/hooks/src), [Sparkline](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/packages/sparkline/src/Sparkline.tsx), [Gauge](https://github.com/kamlesh723/InkUI/blob/e3110d89b3f0933bcb297a6af33318124c889f36/packages/gauge/src/Gauge.tsx).
+5. [Ink 6.8.0 README](https://github.com/vadimdemedes/ink/blob/v6.8.0/readme.md), [Ink 7.1.1 manifest](https://github.com/vadimdemedes/ink/blob/v7.1.1/package.json), [Ink npm metadata](https://registry.npmjs.org/ink), [React registry](https://registry.npmjs.org/react/latest).
+6. [Node official release schedule](https://github.com/nodejs/Release/blob/main/schedule.json), [Node 26 platform/build document](https://github.com/nodejs/node/blob/v26.x/BUILDING.md).
+7. [Bun 1.4.2 release](https://github.com/oven-sh/bun/releases/tag/bun-v1.4.2), [installation/platform requirements](https://bun.com/docs/installation), [Node API compatibility](https://bun.com/docs/runtime/nodejs-compat).
+8. [Node 24 supported platforms and official binary requirements](https://github.com/nodejs/node/blob/v24.x/BUILDING.md), [unofficial-builds limitations and targets](https://github.com/nodejs/unofficial-builds/blob/main/README.md).
+9. [Void Node package recipe](https://github.com/void-linux/void-packages/blob/master/srcpkgs/nodejs/template), [Void musl support and incompatible software](https://docs.voidlinux.org/installation/musl.html).
+10. [Xterm control sequences: mouse tracking and SGR encoding](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking).
+11. [Ink 7.1.1 released README](https://github.com/vadimdemedes/ink/blob/v7.1.1/readme.md), [released measurement implementation](https://github.com/vadimdemedes/ink/blob/v7.1.1/src/measure-element.ts).
+12. [NO_COLOR informal standard and FAQ](https://no-color.org/).
+13. [tmux getting started](https://github.com/tmux/tmux/wiki/Getting-Started), [modifier keys and terminfo](https://github.com/tmux/tmux/wiki/Modifier-Keys), [tmux manual source](https://github.com/tmux/tmux/blob/master/tmux.1).
+14. [Void repositories](https://docs.voidlinux.org/xbps/repositories/index.html), [Void signing](https://docs.voidlinux.org/xbps/repositories/signing.html), [Debian package relationships](https://www.debian.org/doc/debian-policy/ch-relationships.html), [Debian shared-library dependencies](https://www.debian.org/doc/debian-policy/ch-sharedlibs.html), [RPM dependency tags](https://github.com/rpm-software-management/rpm/blob/master/docs/manual/tags.md), [RPM package signatures](https://github.com/rpm-software-management/rpm/blob/master/docs/manual/format_v4.md).
+15. [Bun executable targets, embedding, and autoload controls](https://bun.com/docs/bundler/executables), [Node 24 single-executable applications](https://github.com/nodejs/node/blob/v24.x/doc/api/single-executable-applications.md).
+16. [Node child-process API: spawn, detached processes, signals, and descendant caveat](https://nodejs.org/docs/latest-v24.x/api/child_process.html).
+17. [Linux cgroup v2: delegation, controllers, memory limits, and cgroup.kill](https://docs.kernel.org/admin-guide/cgroup-v2.html).
+18. [Linux pressure stall information](https://docs.kernel.org/accounting/psi.html).