v0.5.0-rc2

Everything the first real v0.5.0-rc1 run turned up, plus what reviewing those fixes turned up in turn. Six release-blockers — and one theme: almost every defect was a check measuring a proxy instead of the thing it claimed to measure.

Still a pre-release. Nothing on the stable alp-sdk-vscode channel upgrades onto this. Delivery is unchanged from rc1: the extension's odd-minor pre-release channel, prerelease: true / make_latest: false, and both installers resolve latest, which excludes prereleases.

Highlights

• tan build and tan flash could not find west on a host that had bootstrapped successfully (#289) — every GUI-launched VS Code, which is the extension's normal environment. New shared tan/core/venv.py resolver; five scattered private copies deleted.
• A bootstrapped venv could be invisible to build and flash (#291) — creation picked the executable directory from disk, resolution picked it from the host, so a Git Bash Scripts/ venv was created and then not found.
• typer>=0.12 was unbounded across a change in what typer is (#293) — now >=0.26,<0.28, both ends measured by wheel inspection.
• tan init pinned a relative SDK root later invocations could not resolve (#263).
• tan bootstrap moved the alp-sdk checkout before it could refuse (#284), and reported complete. after a step had already failed (#285).
• doctor had silently dropped six checks the oracle emits (#286, #290, #294), each reintroducing a closed defect — found by one audit rather than one field at a time.
• tan build reported ok: true when every slice was skipped (#283), and sat silent for 234 s during CMake configure (#287).

Fixed

• Flow D could write the wrong file to a board's MRAM. flash_args.atoc was the one input never resolved against the build root, so a relative atoc: — which the repo's own fixtures use — silently changed which file was flashed.
  • Root cause worth naming: grep -rn "FLOW_D" crates/ returns nothing. Flow D is Python-only, so the Rust oracle's cwd-safety audit was inherited without ever covering the one backend that writes on-die MRAM.
• tan bootstrap emitted relative paths a consumer could not resolve — data.sdkRoot, workspaceDir, venvDir and zephyrBase all came back relative from --sdk-root ./alp-sdk, reintroducing #217. --print-env was emitting export ZEPHYR_BASE="./zephyr" under a heading reading "Add to your shell profile" — and a profile is sourced from $HOME.
• tan bootstrap --print-env wrote to stderr, so tan bootstrap --print-env > env.sh left the file empty while the block still appeared on the terminal.
• doctor refused hosts that work — a bootstrapped host with no board.yaml in cwd exited 4; an inconclusive venv probe failed closed where the oracle fails open; an Apple-silicon Mac on an x86_64 Python was told to build on Linux.
• NO_COLOR was checked two different ways and faultdecode diverged from the spec and the oracle (#288).
• tan bootstrap --non-interactive exited 2 — the literal first-blink command in the docs.
• Smaller: the published asset filename leaking into --help (#280); python_repr on nested mappings (#277); the TBD sentinel (#276); a venv_has_usable_pip flake (#250); zephyr_board.py escaping PINNED_HASHES (#279); and getting-started.yml smoke-testing the Rust tan while the release ships a PyInstaller freeze (#278).

Changed

• doctor --build is accepted and inert. The check set is unconditional now, so there is no build-gated half.
• doctor gained sdkProvenance and data.missingPrerequisites — two envelope keys that did not exist in rc1. The latter restores the extension's one-click dependency install.
• --fix is still not accepted (#295). alp-sdk-vscode calls tan bootstrap instead — accepting the flag as a no-op would give users a Fix button that reports success having repaired nothing.

Requires

alp-sdk v0.15.0-rc1. Pairs with alp-sdk-vscode on the pre-release channel.

Full detail: CHANGELOG.md · full diff

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