[INSTALL-05] [P1] Declare binary runtime requirements and remove the accidental Linux libc barrier #555

Goal

A developer selecting the correct OS/CPU download should either receive a binary that runs on the documented baseline or get an actionable compatibility message before installation.

Priority: P1 · Classification: Measured release requirement and missing compatibility contract

Reviewed baseline: main 56ad6438653f, 6 October 2026. Published distribution inspected: v0.8.0 (CLI build commit 615e501). Recheck these installation surfaces against the current branch before implementing.

Current behavior and evidence

v0.8.0's Linux semaprax archive was downloaded and matched SHA-256 246c8e981a12cedaac10f102ce1e6c76a8835cbc647b8d44a2e34fbd9918affe. Its ELF version-needs table contains GLIBC_2.39 with Flags: none. Dynamic imports include weak pidfd_spawnp@GLIBC_2.39 and pidfd_getpid@GLIBC_2.39; the requirement must be assessed from the version-needs table, not by treating weak imports as an executed failure.

The archive passed the core CLI journey on Ubuntu 24.04.3/glibc 2.39. This review did not execute it with an older loader, so it does not claim a reproduced crash on a particular older distribution.

The shipped daemon has a different observed maximum GLIBC requirement (2.34). A package-level requirement therefore needs to account for both executables and their selected workflows.

The current install guide labels the download simply Linux x86-64 and omits OS/libc requirements. CI builds the binary on Ubuntu 24.04 and smokes it on that same host, so it has no intentional minimum-runtime contract.

• Exact inspected Linux archive
• Release build-host matrix
• Current target-only admission
• Per-archive metadata omits runtime requirements
• Prerequisites are tools, not binary runtime requirements
• Broad platform labels

Implementation scope

1. Establish a documented minimum GNU/Linux glibc baseline for the default CLI/daemon distribution. Target compatibility with glibc 2.35 or older for the ordinary interpreter/project path if the toolchain permits, and prove the chosen baseline with actual artifact execution. Resolve the optional pidfd spawn references through the build environment/library linkage rather than editing ELF version metadata.
2. Build against the selected baseline or an equivalent pinned sysroot so the hosted runner's newer libc cannot silently raise the download requirement. Advanced host features may have separate requirements; gate those features explicitly instead of needlessly preventing ordinary CLI startup.
3. Record each archive's OS version, CPU, libc family/version and actual runtime library dependencies in the owning release metadata schema, and surface them in the installation/download tables. Inspect macOS deployment metadata and Windows imports before declaring their minimums.
4. Verify both executables and the basic generated-project workflow at the declared minimum. Keep current newer-host smoke coverage as well. A successful build on a recent runner alone must not establish older-host support.
5. Have Unix/Windows bootstraps consume the compatibility contract and explain an unsupported environment before replacing an existing installation. Explicitly distinguish GNU/Linux from musl-based environments.
6. Preserve semantics and existing supported host operations. Do not claim Alpine/musl, legacy macOS or native Windows ARM64 support solely because a filename can be constructed.

Acceptance criteria

• Every published binary has an intentional, visible and test-backed runtime baseline, separate from the Rust version needed to build from source.
• The Linux core installation journey runs at the selected older baseline; the resulting executable's required GLIBC versions agree with that baseline.
• If a lower baseline is blocked by a concrete required dependency, document the exact blocker and retain a clear unsupported-host result; this is not grounds to label untested environments supported.
• The requirement accounts for semaprax and semapraxd, and optional native/host features state their additional prerequisites separately.
• The installer refuses a known incompatible runtime before activation and gives a useful supported alternative.
• Future release metadata and tests detect an unintended increase in minimum OS/libc requirements.

Verification

• Retain readelf --version-info and dynamic dependency summaries for Linux artifacts, plus equivalent native dependency inspection on macOS/Windows.
• Execute the exact packaged binary, not a local rebuild, in the declared minimum GNU/Linux runtime with no source toolchain on its execution path.
• Test one known unsupported runtime using the preflight path and prove the prior installation is retained.
• Reuse the install journey from INSTALL-06 for runtime execution; keep this issue responsible for the baseline and build/linkage changes.

Existing issues and boundaries

• #454 covers named harness host behavior; it does not define the minimum libc of this downloadable CLI.
• #144 supplies source-installed tests. This is a concrete release compatibility gap, not another generic stability sweep.
• INSTALL-02/03 can initially report the measured current requirements; they need not wait for all target baselines to improve.

Delivery notes

Implement in the existing owning modules and test harnesses. Follow AGENTS.md and the relevant release/editor contracts. Keep fixes focused, preserve unrelated behavior, and attach the actual verification results. Do not replace existing signing, publication, project generation or harness setup with a second system.