Delivere the unified install/configure/update operation model with a per-project manifest.

[AlexSkrypnyk]

Deliver the unified operation model the Vortex CLI was designed around. .vortex/cli/docs/commands.md (committed on feature/customizer-tui) specifies it; the parts below were never built, so the shipped CLI approximates them with different mechanisms.

#2846 adds the command verbs. This issue is the model underneath them: one operation, one screen, and a per-project record of what a project was built from.

Sequenced after #2842, since the version control is a control on the interactive screen.

Per-project manifest

• A per-project manifest in the consumer repository records that project's answers and the template version it currently sits on
• It is written on every run that changes the project
• Detecting whether a directory holds a Vortex project reads the manifest rather than inferring it from a README badge
• Pre-filling a form for an existing project reads the manifest, falling back to discovery from project files for projects that predate it and for values the manifest does not hold
• A project that predates the manifest gains one on its first run, without the user doing anything
• Decide whether the manifest is committed by the consumer, and say so in the documentation either way
• The manifest is clearly distinguished from the CLI's own question definitions, which never ship to consumers

One operation, three names

• install, configure and update resolve to a single internal operation that takes a template version and an answer set and writes files; the verbs differ only in the inputs they start from
• Empty directory → latest version, fresh answers. Existing project, version unchanged → current version, answers reloaded. Existing project, version changed → newly chosen version, answers reloaded
• Writing over an existing repository touches only template-managed files, leaving git diff as the review surface

Version selection on the screen

• The interactive screen shows the project's current template version and allows changing it inline
• Changing that version and submitting is what makes a run an update rather than a configure — the distinction is the control on the screen, not a separate menu or a flag the user must know
• Invoking a verb explicitly still works and opens the screen already in that mode, with an explicitly named target version preselected
• A fresh install defaults to the latest version and does not make the control prominent

Reconcile the specification

• Bring .vortex/cli/docs/commands.md and what ships back into agreement — today it describes the manifest, the inline version selector and a command that no longer exists
• Fold whatever remains accurate into the published documentation, so the design is not only readable inside the package

Out of scope

• repo:setup, the non-interactive GitHub preset from the original scope decision, is separate work
• No change to the questions, the handlers, or the way answers are processed

Acceptance

• The handler snapshot fixtures are byte-identical
• A project created by the CLI, then reopened, pre-fills every answer from its own manifest
• A project created before the manifest existed still opens, pre-fills and gains a manifest
• Moving a project between template versions is reachable without knowing a flag
• composer lint and composer normalize --dry-run pass
• The template's functional test suite passes

Reference

.vortex/cli/docs/commands.md on feature/customizer-tui (PR #2828) is the specification. The branch implements the verbs and the one screen, but detects projects from the README badge, pre-fills purely by discovery, and exposes version selection only as an update --to flag. Background in .artifacts/installer-to-cli-handover.md.

[coderabbitai]

🔗 Related PRs

#2516 - [#131] Added Diffy visual regression workflow with PR label gate. [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]
#2858 - [#2843] Suppressed Composer output of the initial tooling install and adopted the standard progress helpers. [open]
#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 after #2842. Depends on #2846 for the verbs it unifies.