Auto-select Detected Agents in Enable Flow · Entire

What I changed

The entire enable first‑run flow had a shortcut: when exactly one built‑in agent was detected, it auto‑selected it and skipped the picker entirely — so you couldn't add more agents without re‑running. (The multi‑agent case already showed the picker with detected agents pre‑checked.)

I removed that early‑return so a single detected agent now falls through to the same multi‑select form, where it's already pre‑selected via the existing preSelectedSet → hookAgentOptions → opt.Selected(true) machinery. You see the detected agent checked and can just hit enter, or tick more first.

cmd/entire/cli/setup.go (detectOrSelectAgent):

• The len(detected) == 1 case now only prints Detected agent: <name> and falls through to the picker instead of return detected, nil.
• Kept the selectFn == nil && isBuiltInAgent(...) guard so --yes (non‑interactive) still uses the caller's selection logic, and a lone external agent still isn't announced/pre‑selected (unchanged, matches the existing external‑detection test).
• Updated the doc comment to describe the new first‑run behavior.

cmd/entire/cli/setup_test.go:

• Added TestDetectOrSelectAgent_FirstRun_SingleBuiltIn_PromptsWithDetectedPreSelected — with a TTY and one detected built‑in agent, the selection path runs (picker shown) and honors a user selection of more than the detected agent. This guards against re‑introducing an unconditional skip‑the‑picker shortcut.
• Added a clarifying comment to TestDetectOrSelectAgent_AgentDetected noting it exercises the no‑TTY fallback (single detected agent used without a picker), which is still correct.

Applied (2 cleanups)

1. Trimmed the history-narrating comment (setup.go, single-detected-agent case) — dropped the "Previously a lone built-in agent was used automatically…" narration (belongs in git history) and kept the two load-bearing facts: it's pre-selected in the form below, and --yes skips the announcement. 6 lines → 4.
2. Fixed the now-inconsistent re-run doc bullet — my diff added a "(when a TTY is available)" caveat + non-interactive sub-bullet to the first-run bullets, which made the adjacent re-run bullet's "Always shows the interactive multi-select" read as inaccurate (the no-TTY re-run path keeps installed agents without a picker). Added the matching TTY qualifier and non-interactive sub-bullet.

Skipped (with reasons)

• Reuse: clean. (One out-of-scope note: the agentTypes-building loops duplicate config.go's agentDisplayNames, but they're pre-existing and untouched by this diff.)
• Efficiency: nothing material — entire enable is a one-shot interactive path; the fall-through adds only bounded in-memory registry lookups, no new I/O or expensive closures.
• Altitude Finding 1 (pre-select detected external agents too): skipped — the built-in-only pre-selection is pre-existing code and a deliberate, tested policy (external-only detection intentionally isn't auto-selected). Changing it alters intended behavior.
• Altitude Finding 2 (drop the announcement / unify announced vs pre-selected set): skipped — the announcement is the only feedback on the non-interactive path (no picker there), and two existing non-TTY tests assert it prints. Removing it would break behavior and tests. The multi-agent announcement it also flags is pre-existing and untouched.
• Simplification Findings 2 & 3 (switch shape; test precondition guard): confirmed already appropriately simple — the switch idiomatically emits singular/plural messages, and the first-run precondition assertion is a cheap, worthwhile guard against fixture drift.

The core change itself was validated as the right altitude (special-case shortcut removed in favor of the shared picker, with the per-path difference now expressed as data via preSelectedSet). mise run fmt, mise run lint, and the detectOrSelectAgent tests all pass.

Review target:

— continue: collect altitude + simplification review findings, apply fixes

You are improving the quality of the changed code, not hunting for bugs. Review it for reuse, simplification, efficiency, and altitude issues, then fix what you find. Do not look for correctness bugs — that is what /code-review is for.