v0.5.0

tan is now a Python program, not a Rust one — the first stable release of that rewrite, and it changes both what you download and what you unpack.

Cumulative since v0.4.1, the last Rust release. The 0.5.0-rc1 … -rc4 prereleases are folded in here; if you never installed one, everything below is new to you.

Highlights

• The binaries are PyInstaller freezes of python/, not cargo builds of crates/. The Rust tree stays as a frozen reference oracle and ships no asset.
• BREAKING — every asset is an archive now, not a raw binary. Unpack before running.
• BREAKING — tan validate's spawn path exits 2, not 1. Details below; CI and the VS Code extension are affected.
• tan now plans and executes — the planner relocated out of alp-sdk into tan.
• macOS launch is fixed — --version went from 13.25–19.74 s to 0.342 s.
• All seven deferred verbs are real commands: scaffold, completion, diff, pinmux, inspect, trace, support-bundle (#260).
• tan flash auto-signs an Alif Ensemble slot0 ATOC via SETOOLS, so Flow D no longer needs hand-signing outside tan (#353).
• Several data-loss and wrong-hardware-write defects are fixed — read the next section before upgrading from an RC.

Fixed — data loss, wrong writes, and silent success

These are the reason to upgrade rather than stay on an RC.

• tan bootstrap --dry-run moved the user's alp-sdk checkout and rewrote it (#323). A dry run mutated the workspace.
• tan init and tan generate followed symlinked parents and wrote outside the project.
• Flow D could write the wrong file to a board's MRAM. A fix for #289 had set the wrong artefact for the Alif flash path.
• A pending TBD placeholder could reach a flasher (#222) — on both the Python and the Rust side.
• tan init could pin a customer to the WRONG SDK, permanently (#263).
• tan build reported ok: true / exitCode: 0 / issues: [] when every slice had failed.
• Flow D's SETOOLS auto-sign could pass an unsigned ATOC through its own soft-failure guard (#373).
• The macOS release asset shipped with no CA trust anchors at all (#304), so TLS failed everywhere.
• A write could silently replace a hand-filled .vscode/launch.json value.

Breaking

• tan validate's not-yet-ported spawn path now exits 2 (VALIDATION_FAILURE), not 1 (RUNTIME_FAILURE) (#262).
  • Before: a board.yaml with an unresolvable SDK answered validate.spawn-not-implemented at exit 1, indistinguishable from a tan crash. After: exit 2, matching every guard-level refusal.
  • Who must act: CI branching on -eq 1 specifically stops matching. alp-sdk-vscode renders exit 2 as warning and exit 1 as error, so a stale consumer shows a real validation gap as a warning.
  • A genuine tan crash — unreadable board.yaml, internal exception — is unaffected and still exits 5.
• Release assets gained an archive extension (#349).
  • Before: tan-x86_64-unknown-linux-gnu. After: tan-x86_64-unknown-linux-gnu.tar.gz. Target triples are unchanged.
  • Who must act: anything building the URL from the bare triple. alp-sdk-vscode gains its unpack step separately (#268).

Also fixed

• build reported a bare terminated with exit code: 1 when the Zephyr SDK was missing (#419), and validate reported validation failure when nothing had been validated (#350).
• tan doctor exited 4 on every fresh install, and had dropped six checks the oracle emits.
• tan build / tan flash could not find west on hosts that had it, and a bootstrapped venv could be invisible to both (#291).
• A dangling $ZEPHYR_BASE silently dropped a core from a multi-core build.
• install.sh handed musl hosts a binary that cannot exec; it now probes and refuses first.
• tan monitor would have been a dead command in every published binary — pyserial was not bundled.
• tan <cmd> | head exited 1 on Linux and macOS where the oracle exits 0.
• tan/planner/ had drifted from alp-sdk's scripts/alp_orchestrate/, and the test suite did not necessarily test this repo's tan (#423).

Contributors

@alpCaner · @hkngln

Release assets

Four archives, each a PyInstaller --onedir freeze of the Python
tan (tan-cli#349 -- was a single-file --onefile freeze; --onedir
fixes a 13-19s macOS startup regression caused by --onefile
re-extracting its runtime on every invocation). Unpack the archive
and run the tan/tan.exe inside; install.sh/install.ps1 do
this for you.

• tan-x86_64-pc-windows-msvc.zip -- Windows x64
• tan-x86_64-apple-darwin.tar.gz / tan-aarch64-apple-darwin.tar.gz -- macOS
• tan-x86_64-unknown-linux-gnu.tar.gz -- 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 archive + 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