# Musl acceptance follows the helper selected by spt-core

## Status

accepted (2026-07-19)

## Context

The release ships separate GNU-linked and static-musl Linux helpers. The earlier acceptance rule required the musl record to come from a musl-based distribution, even when a real OMP-capable glibc host ran a musl-built spt-core that selected and installed the archive's musl helper.

Distribution branding is not the adapter seam. The compatibility claim concerns the helper that spt-core selects and executes alongside a real OMP installation. Requiring a musl userspace in addition to observed musl-helper selection excluded representative older-glibc hosts without testing another adapter behavior.

## Decision

A host qualifies for the `x86_64-unknown-linux-musl` acceptance record when all of the following are observed on that host:

1. real OMP runs natively;
2. the installed spt-core build selects `x86_64-unknown-linux-musl/omp-spt` from the tagged `adapter.spt`;
3. the installed helper digest exactly matches that archive member; and
4. the complete native endpoint acceptance sequence passes on that selected helper.

The base distribution may use glibc. Merely executing the static helper manually still does not qualify, and a container without real OMP remains invalid.

## Consequences

The musl record proves target selection and runtime compatibility, not generic Alpine support. Release evidence must retain the native OMP and spt-core versions, selected archive member, installed-helper digest, and complete endpoint results. A GNU-helper run and a musl-helper run remain separate records even when both hosts use glibc-based distributions.