Repository documentation

Native FreeBSD installed SDK qualification

Use the Native FreeBSD SDK qualification workflow to renew the 1.3.1 patch program's installed public retained-SDK acceptance on an actual FreeBSD 15.1 guest. It builds a wheel from one exact commit, installs it non-editably and runs the consumer as an unprivileged account in a disposable VM on hosted Linux. No configured FreeBSD worker is currently available; this is the platform cell that the aligned worker fleet cannot cover.

The original 14.3 guest could not install current packages: that release reached end of life on June 30, 2026, and its userland is older than the package repository requires. The workflow uses normal package OS-version checks. The retained 14.4 run 40641794273 passes the actual SDK scenario and 39 of 40 owner controls; payload publication correctly refuses because that image lacks the required native no-replace API. It remains an overall failed qualification, not a skipped or waived test.

The positive cell now selects 15.1: its release source exports renameat2 and defines AT_RENAME_NOREPLACE. Before expensive SDK work, five installed publication controls must pass without skips, including actual native publication and a destination created after prechecks. Symbols, filesystem support and behavior must agree; selecting a version alone does not prove capability. The same canonical SDK scenario and all 40 owner controls remain mandatory. The 14.4 evidence is retained with its partial boundary; older unsupported systems keep the production refusal with no replacing fallback. No release goal is moved or deferred.

FreeBSD distributes Python's SQLite standard binding as a separate flavored package. The guest installs the SQLite package matching its pip/interpreter flavor and checks an actual in-memory query before building wheel dependencies. Installing Python and pip alone did not provide _sqlite3 in the observed base image.

The 15.1 image has a ZFS root. Setup leaves it intact and mounts a private sparse vnode-backed UFS volume for the workspace and its TMPDIR, with POSIX.1e ACLs enabled. The backing file remains root-owned outside the consumer's home and is not exported; disposal of the ephemeral VM owns its teardown. Root/backing storage and the mounted workspace must both pass their free-space checks. Root setup exercises the installed reversible ACL backend on a root-owned temporary resource, projecting the actual consumer UID, and retains its streams and terminal status before transferring the result directory to the consumer. Failed probes, unsupported filesystems and incomplete restoration fail qualification. The SDK scenario and owner controls still run unprivileged. Private-inspector owner tests use a mocked workspace and do not prove native private allocation; the separate disabled-UFS refusal and enabled-UFS acceptance requirements remain unchanged.

Run and inspect

Push the candidate first, then supply its complete 40-character commit ID:

gh workflow run native-sdk-qualification.yml --ref main \
  -f candidate_revision=FULL_40_CHARACTER_COMMIT_ID

The workflow validates the selector before building. Its wheel metadata binds the candidate revision, wheel hash, test-source archive hash and qualification-harness revision separately. The installed framework must report that same candidate.

Inspect the run and download its freebsd-native-sdk-qualification artifact:

gh run view RUN_ID
gh run download RUN_ID --name freebsd-native-sdk-qualification

result.json is the final scoped verdict; stage stdout, stderr and terminal records explain failures. A timeout retains partial streams and a failed terminal record. An unfinished or failed run provides diagnostic evidence only.

The guest exit trap exports its original status and the reviewed diagnostic whitelist before the VM action copies files back. The VM transport step can therefore succeed after a guest failure; the separate Require copied-back native qualification success step still fails the workflow on a nonzero guest status, incomplete collection, changed diagnostics or missing/failed acceptance. guest-terminal.json retains the original status and copied file hashes. Symlinked evidence and private SSH key files are not exported. A forcibly killed VM may prevent copyback; host logs and wheel metadata remain available, and a missing terminal record fails qualification.

On an architecture refusal, inspect the expected/observed values and the retained host-elf-header.stdout diagnostic. That header describes the guest's /bin/sh and its actual readelf spelling; it is diagnostic context, not SDK acceptance. The SDK's own observed image, target and byte checks must still pass.

What a passing result proves

• The installed public CLI initializes an owned consumer using the published v1.3.0 parent, without source imports or tool-bootstrap side effects.
• Fresh loopback SSH credentials authenticate acquisition of the exact Git SDK fixture. A real CMake producer builds its C ABI and Python binding; source, license, selection and snapshot identities remain bound to the consumer.
• Public retained execution refuses both missing authorizations, then completes authorized build, three test cases, documentation and independent acceptance with withheld product operands and invalid operands.
• The accepted executable needs the reviewed SDK loader context: running without it fails rather than silently using an ambient library.
• Forty installed owner controls also pass without skips. Those controls may use fixture injection; the separate canonical public-CLI scenario uses no discovery, transport, producer, command or acceptance mocks. Every imported production module must remain inside the non-editable installed prefix.

The host compiler and linker are observed bootstrap tools. This microfixture does not admit a source-built compiler SDK, a complete operating system, a product release or a software release. The consumer's original authority and full receipt policy remain intact; the retained receipt is not release authorization.

The guest checks storage before package installation and execution. Fresh SSH private keys stay in the disposable guest's private home; artifact upload copies only the explicit report/log whitelist. It does not alter a host's SSH settings.

Development source acceptance can close its narrowly evidenced roadmap work. Final prepared-candidate lifecycle, package and native release qualification remain mandatory in the 1.3.1 execution checklist.