RFC (draft): Interactive installer for first-time setup

[SamuelDenani]

Draft. Depends on the unified config (config RFC) and on connector and toolchain provider detection (connectors RFC). Not ready to grill until those settle.

Summary

Replace the current non-interactive install with a TUI that walks through first-time setup: detected stack and connector, toolchain provider, runtime level, changesets, and the GitHub setup that setup.sh does today. The TUI only writes .loopwright/config.yml; that file remains the source of truth, and everything the TUI asks can also be passed non-interactively.

Motivation

The number of first-time decisions is growing: connector (confirm what was detected), toolchain provider, bundled mise or not, runtime level, automatic changesets. Today install.sh makes them silently through detect-stack.mjs and setup.sh runs as a second step. Silent defaults are fine for one or two choices, not for five, and a wrong guess is only discovered later by reading the config.

Goals / Non-goals

Goals:

• One guided flow that shows what was detected, proposes defaults, and lets the user confirm or change each choice. Each config section maps to one step.
• Fully scriptable: every question has a flag/env equivalent, plus --yes to accept all defaults. Agents and CI never hit a prompt.
• Re-runnable to change settings later, reading current values as defaults and preserving comments in the file.
• Works when piped (curl ... | bash), by reading prompts from /dev/tty, and falls back to non-interactive when no TTY exists.

Non-goals:

• A persistent dashboard or app. This is setup, not a UI for the loop.
• Replacing the config file as the source of truth.

Proposed approach

Draft-level only. Candidate implementations:

Option	Pros	Cons
gum (Charm) called from bash	Single binary, keeps install.sh in bash, can be installed through the bundled mise	One more downloaded binary before setup starts; bash writing YAML needs care
Node prompts (@clack/prompts)	Engine is Node today, can reuse the engine's YAML loader and schema	Ties setup to Node, against the connectors direction
Small dedicated binary (Go + Bubble Tea, or similar)	Best UX, no runtime dependency on the host	Build and release per platform, much more to maintain

Leaning: gum via the bundled mise for the prompts, with the engine's config loader doing the actual write, so validation and comment preservation live in one place.

Open questions

1. Which tool (table above)?
2. Does setup.sh (labels, branch protection, baseline) fold into the TUI as its last step?
3. How does the TUI handle a monorepo with several detected connectors?
4. Does the TUI ever edit the gate: section, or only feature sections, leaving gate tuning to hand edits?

---

Generated by Claude Code

---

Boundary document

The core/detail boundary this RFC is argued against is #5, refined into
docs/loopwright/principles.md (task #11). Core opinions are cited as P<n>,
detail territory as T<n>.