use install.sh from last release, not main + pin deps in installations

[evgunter]

apparently uv.lock was only working for the dev setup...

also fixes #2391 (but we should cut a new release too so that the new install.sh is live, instead of relying on this PR effectively rolling install.sh back)

admin actions that should happen before merge (see "Security follow-ups" below for more context):

• branch-protect release (the branch install.sh is now read from instead of main). only the update-release-branch job needs to be able to push to release
• restrict v* tag creation (this vulnerability was preexisting)
• (possibly) configure the release environment

also note that the new installer installs imbue-mngr@latest, which technically doesn't match constraints.txt for a moment during the release (or potentially longer if there's an error). i can fix this by having it read a version.txt file instead of using latest if this is undesirable

---

Summary

Ships a lockfile-derived constraints file so end-user installs resolve to the same third-party versions CI tested. Today published wheels carry only loose Requires-Dist ranges, so every end-user install and mngr plugin add does a fresh, unpinned PyPI resolution -- the repo's tested pins never reach users. This is what let mngr plugin add imbue-mngr-azure pull an untested azure-mgmt-resource release that devs (who got the locked version) never saw. It also serves both the installer script and the constraints file from a single CI-managed release branch, so the installer and its constraints are always a matched, published pair tied to the last release.

Fixes the root cause of #2391: because install.sh is now fetched from release (the last-released commit) instead of main, it can never reference CLI subcommands that don't exist in the version it installs -- the version skew that made a fresh install end in Error: No such command 'wizard'.

What changed

• Generate & ship constraints. scripts/make_constraints_file.py runs uv export --all-packages --no-emit-workspace --no-dev --no-hashes to produce third-party-only pins at libs/mngr/constraints.txt, force-included into the wheel at imbue/mngr/constraints.txt.
• Apply at mngr plugin add. The wizard and plugin add/remove builders now append --constraints <shipped file> to uv tool install. The file (one overall constraints file, committed and force-included into the wheel) is present in every real install, so if it is ever missing that means the mngr install itself is broken -- add, the wizard, and remove all abort with a clear error rather than silently resolving unpinned.
• Apply at base install. scripts/install.sh fetches the constraints from the release branch (required, fails naturally under set -euo pipefail) and installs/upgrades in a single constrained resolution: uv tool install imbue-mngr@latest --with <existing plugins> --constraints <file>. It re-lists existing plugins (enumerated from uv tool list --show-with) so an upgrade keeps them -- a bare uv tool install imbue-mngr would reset the tool to just its base package. This deliberately avoids an uv tool upgrade first: uv tool upgrade ignores constraints, so it would briefly resolve and install the newest unpinned dependencies from PyPI (an attack surface for a freshly published malicious release, and a bypass of the exclude-newer cooldown) before a second command could downgrade them. The single constrained install never resolves unpinned, even transiently. Verified against real uv (upgrades base, applies pins, preserves plugins, idempotent).
• Unified regeneration. just regenerate (scripts/regen.py) regenerates the CLI docs, agent-capability doc, and constraints file under one drift-guard test (scripts/regen_test.py).
• release delivery pointer. publish.yml fast-forwards release to each mngr v* release commit; README installer curls repointed at release. The promotion job now runs under a dedicated release deployment environment (see security follow-ups below).
• Advisory exclude-newer. scripts/release.py no longer auto-advances the cooldown cutoff (now ordinary dependency maintenance via a PR to main); it only warns when stale, alongside the consolidated run_advisory_checks(). This keeps the shipped constraints provably identical to what CI tested.

Test plan

• scripts/regen.py --check clean; wheel build confirmed imbue/mngr/constraints.txt present.
• Manually verified the single constrained install against real uv: uv tool install imbue-mngr@latest --with <plugins> --constraints <file> upgrades the base package, applies the pins, and preserves existing plugins in one resolution (idempotent) with no unconstrained window -- whereas a bare constrained install without --with drops the plugins. Crystallized as test_install_sh_installs_at_latest_without_unconstrained_upgrade (asserts @latest --constraints and no uv tool upgrade) and test_install_sh_relists_plugins_when_already_installed (real bash against a mock uv that reports plugins).
• Touched unit tests pass: uv_tool_test, test_install_script, release_test, regen_test, make_agent_capabilities_doc_test.
• Meta ratchets pass (ruff, shellcheck/portability, bash strict-mode). test_no_type_errors is left to CI: ty check OOMs on this local WSL box (5.7 GiB), reporting 0 errors whenever it runs to completion.

Note: test_no_gitignored_files_are_tracked fails on this branch, but the offending .minds/* files are unchanged base→HEAD (pre-existing repo condition, not introduced here).

Security follow-ups

A security pass over this change surfaced a handful of items. The two substantive ones -- a bug where an upgrade dropped all plugins, and an unconstrained uv tool upgrade window that briefly installed unpinned deps -- are already fixed (see the base-install bullet above). The rest:

• [needs a repo admin] Branch-protect release. release now governs both the curl | bash installer and the dependency pins for every fresh install. The automated promotion is already as gated as PyPI publishing: update-release-branch runs only needs: publish (which runs in the pypi environment), and this PR additionally puts it under a release environment. So it opens no new hole in the CI path. What is newly consequential is a direct push to release by anyone with repo write access, bypassing CI entirely -- now that release drives installs, that would poison them. An admin should add a branch-protection rule / ruleset on release that restricts direct pushes to the CI actor and blocks force-push and deletion. (I don't have admin on this repo.)
• [needs a repo admin] v* tag protection. Creating a v* tag triggers the publish + release-branch chain. An admin should restrict v* tag creation to release managers.
• [needs a repo admin] Configure the release environment. This PR adds environment: release to the promotion job; an admin should add required reviewers to that environment so moving the install-governing branch needs a human approval. Until then the environment exists but imposes no gate.
• Known, accepted tradeoff -- installer uses @latest. install.sh installs imbue-mngr@latest while fetching constraints from release. CI advances release immediately after the PyPI publish in the same workflow (needs: publish), so the wheel and its constraints are normally a matched pair. The only skew window is brief and self-healing -- it requires the release-branch push to lag the publish -- and if it occurred, a brand-new transitive dependency in the newer wheel could resolve unpinned until release catches up. We keep @latest rather than parsing an explicit version in the installer, to keep the curl | bash script simple for users to read.

Bootstrap ordering

The release branch now exists, pointing at the last released tag v0.2.17 -- so the repointed README URLs resolve immediately and publish.yml's fast-forward has a base to advance from (v0.2.17 is an ancestor of main). At v0.2.17 the branch carries the old install.sh (which does not fetch constraints, so no 404) and no constraints.txt; both the constraints file and the fetch-enabled installer land on release together at the next release. Net effect: the #2391 fix and constraint pinning for the base installer go fully live at the first release cut after this merges; until then the installer behaves exactly as it does today.

🤖 Generated with Claude Code