v0.5.0-rc3

Six defects found by running the published v0.5.0-rc2 binary end to end on real Windows and macOS hosts — not by testing the source, and not by trusting a green CI run on a clean runner. Every one of them was invisible to both.

This is a pre-release. It does not take the Latest badge.

Highlights

• tan doctor exited 4 on every fresh install — the guaranteed post-bootstrap state was reported as a broken host (#299).
• A host where no build slice could run exited 0 — the opposite failure, exposed by fixing the first one (#299).
• The macOS asset could not make an HTTPS request at all — no CA trust anchors in the freeze (#304, release-blocker).
• tan bootstrap died with "Filename too long" on a fresh Windows install while doctor had just called the host fine (#306, release-blocker).
• doctor and bootstrap stopped recommending a config change that was tried and reverted upstream (#300).
• New clean-host.yml gate runs the shipped artefact on a host with no SDK, no ~/.alp and an empty cwd — the state that hid all six (#278).

Fixed

• tan doctor exited 4 on every fresh install. tan bootstrap deliberately leaves west off PATH, so "west in the venv, absent from PATH" is the guaranteed post-bootstrap state — and the state a GUI-launched VS Code is always in (#299).
• westResolved now fails when west resolves nowhere. west answers "is it on bare PATH" and is never fatal; westResolved answers "can a slice run at all" and owns the exit code (#299).
• macOS releases could not verify any TLS certificate. A PyInstaller freeze bundles its own ssl but no CA bundle and does not fall back to the platform trust store, so every HTTPS call in tan sdk list --online failed CERTIFICATE_VERIFY_FAILED on the published rc2 tan-aarch64-apple-darwin asset (#304).
  • Requests now build their SSLContext through truststore (the OS trust store, so a corporate CA in the machine keychain keeps working), falling back to certifi only if that is unavailable.
  • The error text no longer asserts "usually a TLS-intercepting proxy or a corporate CA" — there was neither on the reporting host, and that wording sends users hunting in the wrong place.
• longPaths checked the registry and nothing else. Windows' LongPathsEnabled governs manifested Win32 calls; it does nothing for git, which west update uses for every module clone and which refuses a long path unless its own core.longpaths is set. doctor said pass moments before bootstrap died inside hal_nxp's tf-psa-crypto tree (#306).
  • longPaths now reads both axes and fails — not warns — when the registry says yes and git does not. The remedy names the exact command: git config --global core.longpaths true.
  • tan bootstrap also forces core.longpaths=true on the west update child's environment, so a fresh install gets past the failure rather than only being warned about it.
• doctor and bootstrap stopped telling users to raise prerequisites.pythonMinVersion — the change alp-sdk#1078 tried and reverted. That key is host-universal while the floor is Zephyr's, so raising it refuses a 3.10/3.11 host for a Yocto-only project that builds today (#300).
• The sdk check names the tier it resolved through, and names a cwd checkout it did not select, so a report describing a different SDK than the one you are standing in is no longer indistinguishable from a wrong answer (#301).

Added

• clean-host.yml — the shipped-artefact gate. Freezes tan per platform and runs tan --version, tan doctor --format json, tan sdk list --online (a real unmocked GitHub API call, the CA-trust canary) and tan bootstrap --dry-run on a host with no alp-sdk checkout, no ~/.alp and an empty cwd — a state no prior job in this repo ever constructed (#278).
• doctor's envelope is checked for self-consistency — ok/exitCode agreeing with checks[], and no <subject> / <subject>Resolved pair disagreeing. That generalises the #299 shape instead of grepping for westResolved by name.

Known issues

• tan bootstrap still refuses the documented quickstart layout (tan.exe and alp-sdk/ in one directory) with "holds more than this checkout", and the remedy it offers moves the user's checkout (#302).
• tan/planner/ is behind alp-sdk's scripts/alp_orchestrate/ (#320, blocks v0.5.0 final). On mproc-mailbox, tan generate's Zephyr conf fragment is 56 lines where alp-sdk emits 63; on rpmsg-imx93, alp-sdk refuses the board as not buildable (SdkRevisionNotBuildable, E1M-NX9101 hw_rev r1) and tan reports ok.

Release assets

Four binaries, each a single-file freeze of the Python tan:

• tan-x86_64-pc-windows-msvc.exe -- Windows x64
• tan-x86_64-apple-darwin / tan-aarch64-apple-darwin -- macOS
• tan-x86_64-unknown-linux-gnu -- Linux x64, frozen on Debian 11.
  It requires GLIBC_2.30 or newer -- measured from the
  binary's own bundled payload at build time, not assumed from the
  build image. Debian 11+ / Ubuntu 20.04+ / RHEL 9+ are comfortably
  above it.

There is no arm64 Windows and no arm64 Linux asset in this release,
and no -musl asset. A frozen binary has to be built on the
architecture it runs on, and this release builds on four runners; if
you need an arm64 Linux or arm64 Windows tan, install from source
(pip install ./python) and say so on the issue tracker.

• Every binary + checksums.txt carries a GitHub build-provenance
  attestation. Verify with:
  gh attestation verify <downloaded-file> --repo alplabai/tan-cli

---

Full detail: CHANGELOG.md · full diff