Adde the Vortex CLI commands beyond 'install': routing, 'update', 'configure' and 'doctor'.

[AlexSkrypnyk]

Grow the Vortex CLI from a single-purpose installer into a multi-verb tool. The relocation in #2841 carries the installer's own command surface across unchanged; this adds the commands and behaviours that only make sense once it is a CLI.

Sequenced after #2841 and before #2842, so the engine swap lands against a settled command surface rather than being followed by another round of feature work.

Commands to add or reshape

• A default command that routes a bare invocation by the state of the target directory: an existing Vortex project is reconfigured, anything else is a fresh install
• update as a first-class verb rather than re-running install over an existing project, including a way to name the target template version directly
• configure for reconfiguring an existing project in place, without downloading a template — collecting answers by default, and writing them to the project on --apply
• doctor replacing check-requirements as the user-facing diagnostics verb
• Decide whether build stays a standalone command, folds into an option on install, or both

Behaviour requirements

• doctor loses nothing that check-requirements reported: every tool it checked, whether each is installed and running, the per-tool install instructions, the version summary, and the ability to check a named subset
• update keeps refusing a destination whose major differs from the build's own, and keeps naming the matching release
• configure operates on the project directory as both source and destination, and resolves a relative path before anything derives a value from it
• configure --apply writes the collected answers to the project on both paths, interactive and scripted. The branch honours it only on the scripted path: an interactive run collects answers, prints them as JSON and changes nothing, and the code is excluded from coverage so no test catches it. A bare invocation that routes to configure must actually change the project
• Both configure paths have test coverage; neither is excluded from it
• Discovery pre-fills answers from an existing project when updating or reconfiguring. Recording those answers in a per-project manifest, and detecting a project from it, is Delivere the unified install/configure/update operation model with a per-project manifest. #2847
• The agent surface is reachable from every entry point an agent would actually use, including a bare invocation in an empty directory — a downloaded binary run with no arguments must be able to describe its own questions
• Guidance printed after a run is suppressed whenever the run is not interactive, so a caller's stdout is never polluted

Consumers

• .vortex/tooling/src/vortex-update calls the update verb rather than re-running an install, and its unit tests follow
• The template functional test harness exercises whichever verbs it depends on
• Documentation covers the full command surface, not just installation

Out of scope

• The interaction engine stays whatever Relocated the installer into the 'drevops/vortex-cli' package without changing behaviour. #2841 left in place; replacing it is Replace 'laravel/prompts' with 'drevops/tui' in the Vortex CLI. #2842
• The per-project manifest, the single internal operation the three verbs resolve to, and inline version selection on the screen are Delivere the unified install/configure/update operation model with a per-project manifest. #2847
• No change to the questions, the handlers, or the way answers are processed

Acceptance

• The handler snapshot fixtures are byte-identical — this change adds verbs, it does not change what a given answer set produces
• Every new command has functional test coverage
• composer lint and composer normalize --dry-run pass
• The PHAR builds; each verb runs from it
• The template's functional test suite passes

Reference

All of these exist on the branch feature/customizer-tui (PR #2828) and are described in .artifacts/installer-to-cli-handover.md under "Command surface".

Two branch behaviours that should not be repeated: its doctor is thinner than check-requirements, and its configure ignores --apply when run interactively.

[coderabbitai]

🔗 Related PRs

#2510 - [#2174] Added cross-tool aliases for Ahoy commands. [merged]
#2681 - [#2665] Added installer prompt to make the in-container theme build optional. [merged]
#2761 - [#2598] Stripped unselected options' configuration from generated projects. [merged]
#2811 - Fixed 'vortex-tooling.sh' aborting when an older tooling package directory is present. [merged]
#2860 - Added a user-facing CLI reference page to the documentation. [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[AlexSkrypnyk]

Sequenced between #2841 (relocation) and #2842 (interaction engine).