## System details

Omarchy on Linux x86_64, kernel `7.2.5-3-omarchy`; `/etc/os-release` reports `VERSION_ID=4.0.4` while `/usr/share/omarchy/version` reports `4.0.0.alpha` (recording both rather than guessing). Mise `2026.9.16`; omp `18.8.2` after recovery.

## What's wrong?

The configured mise omp installation and a standalone executable at `~/.local/bin/omp` can coexist silently. The standalone location is also where Omarchy puts its mise launcher. Updating one owner does not establish that every shell/launcher now resolves the same installation; equal versions can mask the ownership conflict until the next update.

On this workstation, `github:can1357/oh-my-pi = "latest"` was in global mise configuration, while `~/.local/bin/omp` was a standalone ELF rather than Omarchy's launcher. Both later reported 18.8.2. The creator of the standalone file was **not established**. This report does not claim that omp's updater created it, that mise failed to upgrade, or that every standalone installation is wrong. Omp 18.6.3 already routes mise-owned update targets through mise.

This is a proposal for a **non-destructive ownership-drift warning**, based on that verified state, not a request to automatically overwrite user executables.

## Verified behavior and safe reproduction

1. Configure mise to own `github:can1357/oh-my-pi` and install it.
2. Have a separate executable `omp` at the default standalone location, an explicit `PI_INSTALL_DIR`, or another PATH entry.
3. Run a mise update that has no new version to install.
4. There is no ownership warning. The separate executable remains untouched.

I reproduced step 3 in a disposable HOME/config with `github:can1357/oh-my-pi = "18.8.2"`, an already-installed real mise binary, and a non-executed ELF-prefix fixture at the standalone path. Native `mise upgrade github:can1357/oh-my-pi` printed:

```text
mise All tools are up to date
```

No ownership warning was emitted and the fixture was unchanged. I did not rerun a network installer over a live launcher to reproduce the state.

## Proposed official integration

Add an ownership checker at the explicit mise-update workflow seam, not an automatic launcher rewrite:

1. For a tool actually selected/configured as mise-owned, inspect its known standalone path and executable PATH candidates. Start with omp's `github:can1357/oh-my-pi` mapping; do not warn on standalone-only installations without a mise ownership claim.
2. Run it before `mise up` in `omarchy-update-mise`, even when nothing is outdated. An optional named hook such as `pre-update-mise` would also let users extend the check without editing vendor scripts.
3. Include a supported global mise batch-install hook for ordinary installs/real upgrades. For direct mise users, provide an optional guarded update task. Mise's current install hooks do **not** guarantee invocation for no-op upgrades or dry runs; do not advertise them as a universal upgrade hook.
4. Route the update alias/workflow through the guarded seam if an always-check guarantee is wanted. Preserve the native upgrade's arguments, release-age behavior, exit status, and shell activation function.
5. Print stderr warnings naming conflicting paths and owner-specific recovery guidance. Continue the update. Never delete, rewrite, execute, or ask an unrecognized candidate for its version.

Expected diagnostic:

```text
WARNING: omp ownership conflict: mise is configured to own omp.
  ~/.local/bin/omp: standalone executable outside mise's omp installation.
Mise upgrades will not update this separate executable.
Inspect/preserve custom files before deliberately restoring Omarchy's launcher.
```

The checker must accept canonical Omarchy mise launchers, mise's omp versioned binaries/symlinks, and native mise shims that resolve to mise itself. It should support XDG/custom mise data roots, deduplicate repeated PATH entries, and warn even when versions happen to match. Unknown custom wrappers should be described as unrecognized ownership, not falsely asserted to be standalone-installer output. No unbounded filesystem scan is needed.

## Local implementation and verification

[MooseGooseConsulting/coldaine-configurations#52](https://github.com/MooseGooseConsulting/coldaine-configurations/pull/52) contains a scoped opt-in implementation, rationale, and recovery policy. The local canonical launcher and warning kit are already applied. It uses supported mise config fragments, a guarded `mise update` task, and the existing Omarchy `post-update.d` hook (which currently runs before the mise phase); an official checker directly in `omarchy-update-mise` would be the cleaner seam.

- Nine deterministic, isolated regressions passed, including a live-smoke-discovered false positive for native mise shims that was fixed before publication.
- Live guarded no-op update, dry run, no-op native install, and Omarchy hook all emitted the expected foreign-candidate warning.
- Healthy mise launcher/binaries were silent.
- Foreign executable was neither run nor changed; native upgrade exit status was preserved.
- Launcher recovery used `omarchy-mise-install github:can1357/oh-my-pi omp`; it reported `omp/18.8.2` afterward.

This warning mitigates rediscovery/confusion; it does not prevent another installer from replacing a launcher later. The PR documents raw no-op `mise up` limitations instead of concealing them.

## Related sources

- [Omarchy AI manual](https://omarchy.org/manual/ai/) documents the lazy mise-backed agent launchers.
- [Provisioning at 060c57b4](https://github.com/omacom/omarchy/blob/060c57b4aa416022343893c1a2e4eadae255257e/install/user/mise.sh) wires omp through `omarchy-mise-install`.
- [Update orchestration at 060c57b4](https://github.com/omacom/omarchy/blob/060c57b4aa416022343893c1a2e4eadae255257e/bin/omarchy-update) runs `post-update` before `omarchy-update-mise`.
- [Mise hooks](https://mise.jdx.dev/hooks.html) describe install hooks but no no-op-upgrade event.
- #7101 concerns destructive wrapper replacement; this proposal deliberately avoids that approach and does not claim to fix that issue.