nx doctor "Generation layout" check flags uv-managed ~/.local/bin/python3* symlinks as taken-back nexus shims

[hhildebrand-conductor]

Summary

After nx self install converged a legacy uv-tool install onto the generation layout (7.21.0), nx doctor reports:

Generation layout: python3.12 in /Users/.../.local/bin are symlinks, not nexus-owned shims — uv has taken them back (a stray `uv tool upgrade conexus` does this) ...
Fix: nx self install

~/.local/bin/python3 and ~/.local/bin/python3.12 here are uv-managed interpreter links (uv python install), not nexus entrypoints:

python3    -> ~/.local/share/uv/python/cpython-3.12-macos-aarch64-none/bin/python3.12
python3.12 -> ~/.local/share/uv/python/cpython-3.12-macos-aarch64-none/bin/python3.12

The four nexus shims (nx, nx-mcp, nx-mcp-catalog, nx-session-end-launcher) are correct and resolve to current. No uv tool upgrade was run after the converge.

Expected

The check should only consider the entrypoints the generation owns, not every executable name that also exists in the generation's bin/ (the venv's own python3.12). Running the suggested fix would overwrite the user's default python3 on PATH.

Environment

conexus 7.21.0, generation gen-20260829T014646Z (base interpreter uv cpython 3.12), macOS arm64.

[hhildebrand-conductor]

Follow-up from 7.21.0 -> 7.22.0 on the same box: nx upgrade printed

Precondition [uv-takeover]: shims python3.12 in ~/.local/bin were uv symlinks: rewriting them to gen-20260829T024315Z

so the precondition targets the same uv-managed interpreter links, not only doctor. In this run the links were unchanged afterwards (still -> ~/.local/share/uv/python/cpython-3.12-.../bin/python3.12), so either the rewrite is skipped for non-nexus targets or it failed silently; either way the log line reads as if a user's default python3 was replaced.

[Hellblazer]

Confirmed and fixed on develop at b953cfd (bead nexus-50hm9); ships in the next client release.

Root cause: both nx doctor's Generation layout row and repair_uv_takeover (the nx upgrade uv-takeover precondition and nx self install) derived the owned shim names from a listing of <current>/bin minus a never-shim list. The generation venv's own python3.12 is in that listing, so uv's interpreter link of the same name in ~/.local/bin read as a reclaimed shim. One correction to the report's framing, which matters for severity: the shell writer (nx_write_shims) derives its own set from the distribution's declared console scripts and never wrote a python3.12 shim, so the "rewriting them" line described a write that did not happen — which is why the links were unchanged afterwards. The defect was a false-positive FATAL doctor row plus a misleading message, not a hijack.

Fix: the Python side now asks the generation's own interpreter which console scripts the distribution declares (the same query the installer runs) and mirrors the writer's rule exactly (declared + mineru/mineru-api, minus never-shimmed names, present in the generation's bin/). A generation that cannot answer makes doctor WARN and the repair leave shims untouched, never a guess. Covered by tests for exactly your box's shape (uv-managed python3/python3.12 links beside correct shims: doctor green, precondition silent).