Tale v0.5.21

0.5.21 is a fix release on the 0.5 line with one fix, in the CLI: managed deployments complete again. Every tale deploy --bundle since 0.5.20's CLI started keeping its backend-local state under the backend's data volume ended after the runtime had already rolled, with the backend-local provisioning phase refused by its own ownership check. No migration, no config-file change, no platform image change beyond the version stamp. The Known issues from 0.5.20 are unchanged.

Highlights

Managed deployments complete again (#3330)

tale deploy --bundle copies the CLI into the backend container and runs deploy provision there through docker exec, which uses the image's default user: root, kept so the entrypoint can fix volume ownership before it drops to the app user. The phase keeps its private state under /app/data/ops/tale-deployments/<name>/ and refuses any path component the current account does not own, and the entrypoint hands /app/data to the app user on every boot. So as root the very first component was refused, the inner CLI exited non-zero, and the host saw only The backend-local Tale CLI did not complete provisioning. Its previous receipts are retained for recovery. — after the compose roll, so the instance served the new version while the deployment never reached ready. The credential export phase shared the fault. Reproduced inside the 0.5.20 platform image; the ops end-to-end shard on a fresh droplet failed the same way.

• Backend-local phases run as the backend's own user. The CLI reads the owner of the backend's data directory from the container, hands the copied bundle to that account and runs deploy provision and deploy export-client-native as it.
• The failure names itself. A failing backend-local phase now repeats the inner CLI's own JSON summary in the deploy result (… It reported: <summary> (exit <code>)); stderr still never surfaces.
• A stranded deployment can be taken over after review. A failed deployment keeps its recovery point — the pre-deployment snapshot bound to the bundle it was applying — and refuses any other bundle on retry; a new CLI pin always changes the bundle, so a fault in this phase left a host stuck until someone with shell access removed the intent. The deployment specification takes supersedesPendingBundle with the pending bundle's sha256, which the refusal now names: the newly reviewed bundle takes over the same snapshot and the ready receipt lists it under supersededBundles.

Behaviour changes

• deploy provision and deploy export-client-native run inside the backend as the owner of its data directory, on a copy of the bundle owned by that account.
• A failing backend-local phase reports the inner summary in the deploy result.
• The pending-bundle refusal names the pending bundle's sha256 and points at supersedesPendingBundle.
• New optional deployment specification field supersedesPendingBundle; new optional supersededBundles list in the pending intent and the ready receipt. Workspace tale deploy is unchanged.

Known issues

• Unchanged from v0.5.20, where each is described in full: the es/co-cc Colombian cédula detector still ships switched off and a locale-agnostic PII toggle still widens national-ID matching to every locale; thinking-block replay on the native Anthropic connector is not done and the live Max-plus-tool-call check is still owed; rag_search embedding calls inside a harness turn are unmetered; the product edit dialog cannot clear a field; the app's skill editor still carries the retired private visibility.

Migration notes

• No database migrations, no config-file changes, no new environment variables. The platform, proxy, database and sandbox images change only in their version stamp.
• Managed deployments whose last run ended in the provisioning failure keep a pending intent on the host. The first deploy with the fixed CLI refuses with A different deployment bundle is pending (<sha256>); declare that sha256 as supersedesPendingBundle in the deployment specification, deploy again, and remove the declaration once the ready receipt lists it under supersededBundles. Nothing on the host needs manual repair.

Upgrading

• On the 0.5 line (0.5.0 – 0.5.20):

  tale update
  tale deploy

• Managed deployments move by pinning the CLI and the runtime to this release's commit, preparing a new bundle and applying it with the pinned CLI — see Managed deployments on the CLI install page.

• New install:

  curl -fsSL https://raw.githubusercontent.com/tale-project/tale/main/scripts/install-cli.sh | bash
  mkdir tale-05 && cd tale-05
  tale init
  tale deploy

What's Changed

• fix(cli): run backend-local phases as the backend user by @larryro in #3330

Full Changelog: v0.5.20...v0.5.21