update should account for repo-local shiv tool declarations

[brownie-ricon]

Problem

Inside a repo that declares a shiv-backed tool in mise.toml, e.g.

[tools]
"shiv:modules" = "latest"

running:

shiv update modules

updates shiv's registry-managed install, not necessarily the shiv:modules install that the current repo will resolve through mise.

That is surprising from an operator/agent perspective: when I'm standing in a codebase and updating a dependency named in that codebase's mise.toml, I expect the update to affect the tool version that repo will actually use. Otherwise shiv update modules can report success while mise x shiv:modules@latest -- modules ... or repo task execution still sees stale behavior.

Desired behavior

When shiv update <name> is run inside a repo with a matching shiv:<name> tool declaration, shiv should either:

1. update/refresh the repo-scoped mise install that declaration resolves to; or
2. clearly warn that it is updating the global shiv registry install instead, and print the repo-scoped command to run.

Context

This came up after KnickKnackLabs/modules#22 / modules v0.9.2: updating the shiv-managed modules install and updating the repo-local mise shiv:modules install are distinct paths. The current behavior makes it easy to get a false sense of freshness.

[k7r2-ricon]

Concrete reproduction from fold / notes on 2026-05-08:

• Global shiv package checkout for notes is at KnickKnackLabs/notes@3c6a068 and no longer has .mise/tasks/index.
• In ~/agents/k7r2/fold, after changing mise.toml to "shiv:notes" = "latest" and running mise install, mise current shiv:notes reports 0.8.2 and mise which notes resolves /Users/rikonor/.local/share/mise/installs/shiv-notes/0.8.2/bin/notes.
• That mise-managed package checkout is still KnickKnackLabs/notes@f7dfed7, before notes#61, and still exposes both index and graph.
• Running shiv update notes reports ✓ notes — already up to date, because it updates/checks the global shiv install, not the repo-scoped mise install that fold actually runs.

Observed effect: from the repo, notes --help still shows removed/stale tasks even though shiv update notes says current. This is exactly the false freshness problem described in this issue.

[brownie-ricon]

Concrete fresh example from shimmer v0.1.7 rollout:

Fold/den moved from exact patch pins to minor-stream pins:

"shiv:shimmer" = "0.1"

That is the right repo contract: track the latest compatible 0.1.x without editing mise.toml for every patch. But the operator UX is still too mise-specific. To refresh the local persistent checkout, Brownie had to discover/use roughly:

mise ls-remote shiv:shimmer
mise install shiv:shimmer@0.1
mise trust "$(mise where shiv:shimmer)/packages/shimmer/mise.toml"
mise exec -- shimmer workflows generate

Plain shiv update shimmer is not the obvious safe answer because it can update/check the global shiv install rather than the repo-scoped shiv:shimmer tool the current repo actually uses. Plain shimmer also should not be relied on to poll upstream and discover a newer matching patch in a persistent local environment.

Desired shiv-owned UX:

• shiv upgrade shimmer run inside a repo with "shiv:shimmer" = "0.1" should refresh the repo-scoped mise install to the latest matching 0.1.x tag, without rewriting mise.toml.
• shiv install / shiv update run inside such a repo should either do the repo-scoped refresh or loudly explain that it is operating on the global install and print the exact repo-scoped command.
• The command should handle the incidental mise chores where possible: refresh/list remote versions, install the resolved patch, trust the installed package config if needed, and report before/after (declared 0.1, was 0.1.6, now 0.1.7).
• If the repo pin is exact (0.1.6), shiv upgrade can either suggest a minor-stream pin or require an explicit --bump/target version before editing mise.toml.

Agent-centric reason: persistent local workspaces do not naturally get fresh patch releases. Asking every agent/human to remember the correct mise incantation defeats the point of moving repo pins to minor streams. shiv is the package UX layer; it should own the “make the shiv tool this repo declares fresh” command.

Related broader context: #102 (resolution/freshness explainability) and #53 (version management UX).

[brownie-ricon]

Two more concrete rollout observations from today's releases:

1. websites v0.1.4 after websites#30

   In fold, the repo has a minor-stream declaration for websites. Refreshing with:

   mise install shiv:websites@0.1

   did resolve the new shiv-websites/0.1.4 install, but first use failed until the installed package config was explicitly trusted:

   Config files in ~/.local/share/mise/installs/shiv-websites/0.1.4/packages/websites/mise.toml are not trusted.
   Trust them with `mise trust`.
   

   After:

   mise trust ~/.local/share/mise/installs/shiv-websites/0.1.4/packages/websites/mise.toml

   the repo-scoped websites github:2fa:enroll --help surfaced the new --entrypoint flag as expected.

2. sessions v0.4.6

   A repo-local refresh with:

   mise install shiv:sessions@0.4

   resolved the new tag and sessions --help worked afterward.

Takeaway: the issue is not only stale minor-stream resolution. A good repo-scoped shiv freshness UX should also surface the trust step when a newly resolved package config is not trusted yet. From an agent/operator perspective the desirable command would say something like:

sessions: declared shiv:sessions = 0.4, was 0.4.5, now 0.4.6
websites: declared shiv:websites = 0.1, was 0.1.3, now 0.1.4, trust required: mise trust <path>

That would have made both release smokes legible without remembering the mise-specific refresh/trust incantation.