multiversa

Overview ¶

Multiversa detect — host scanner with dual rendering surface.

When stdout is an interactive TTY this command runs a Bubble Tea program built on top of the shared `internal/tui` primitives (Header, Selector, Verbosity). When stdout is piped/redirected/CI, it falls back to the plain v0.3.0 renderer so existing scripts and the `/lab-setup` Claude Code skill keep working unchanged.

The scan itself is read-only — see internal/detect. Cancelling the TUI (q/Esc) exits with status 0 because there is nothing to roll back: the user just dismissed a report.

Multiversa lab — the consultive meta-wizard. It composes the individual command flows (detect, stack, init, workspace, usb) into a single cinematic experience organized by layer:

Capa Técnica       → detect · stack · init
Capa Identitaria   → workspace
Capa Operacional   → usb · credits

The lab is the public face of Multiversa Lab — what a prospect sees first. Consistency with the per-command TUIs is critical, so the lab consumes the same internal/tui primitives every other wizard uses, and the same `profile` for adaptive verbosity.

Architecturally the lab is a hub: it renders a sidebar of layers, a selector inside the focused layer, and lets the user launch any step. Launching a step exits the lab cleanly via tea.Quit, the cobra RunE then invokes the chosen run* function, and on return the lab is re-entered with refreshed state. The user experiences a single continuous flow; the implementation keeps each wizard self-contained.

multiversa mcp serve — the CLI as a native MCP server.

Phase 2 of the agent bridge: the same read-only surfaces exposed via --json (schemas multiversa.*/v1) become typed MCP tools over stdio, so Claude Code, Claude Desktop, Codex, or any MCP client can drive the orchestrator natively. Mutating operations are deliberately NOT exposed: the MCP surface proposes, the human decides at the TUI.

multiversa tenant — isolated, replicable tenant profiles.

Each tenant is one directory under ~/.multiversa/tenants/<slug>/ holding its DNA (multiversa.toml), its vault (0700, opaque to every Multiversa surface), its graph, and its memory. `tenant new` scaffolds from neutral project defaults, `tenant use` switches context atomically, and everything is readable by agents via --json (schema multiversa.tenant/v1).

multiversa tenant exec — run a process with one tenant's vault as its environment, and with the operator's ambient credentials stripped out.

This is the piece that makes "un vault por perfil" true for everything that is not the LLM router: an MCP server, a deploy script, a migration, a curl. Before this, a backend key lived in one global place (~/.multiversa/secrets.env or a repo file) and every profile shared it. Now each profile carries its own, and a process launched for Cintia cannot see Andrea's key — not because it is asked not to look, but because it is not in its environment.

Secrets go from the vault straight into the child's environment. They never touch argv, stdout, a log line, or the manifest.

multiversa updates — the release watcher for the curated ecosystem.

Checks the latest upstream release of every curated engine plus the CLI itself. The default remains read-only; --apply is the explicit decision to replace only the CLI binary with a checksum-verified release.

Multiversa usb — encrypted bootable USB lab with dual rendering surface and a two-gate confirmation pattern.

This is the MOST DESTRUCTIVE command in the CLI: the embedded script wipes the target device and writes a LUKS container (Linux) or drives a guided VeraCrypt + balenaEtcher flow (macOS). The user experience is structured around two independent gates that BOTH must pass before any byte is written:

Gate 1 (this file, in the Go TUI): user types EXACTLY "i understand".
                                   Anything else cancels with exit 2.
Gate 2 (the embedded bash script):  user types the device path TWICE.

Both gates are intentional and complementary. Gate 1 catches the "I hit enter on the wrong terminal" mistake before the script even loads. Gate 2 catches the "I typed the wrong device" mistake the only way that is robust — by making the user re-type the path. The bash scripts already implement gate 2; do not remove or weaken it.

When stdout is a TTY and --show is NOT passed → run the Bubble Tea program. When --show is passed → print the embedded script body. When stdout is not a TTY → fall back to the v0.3.0 stdin Y/N flow. On Windows → print a friendly notice and exit 0.

Exit codes:

0 success (script ran, or --show, or Windows notice)
1 prereq missing, unsupported OS, or script failure
2 user cancel (gate 1 declined, esc, ctrl+c, or stdin no)

Multiversa workspace — MultiversaGroup private workspace setup.

v0.4.0 unifies the UX behind the shared internal/tui primitives. When stdout is a TTY and --show is not passed, the command launches a Bubble Tea program that explains what will happen, checks prerequisites, and asks for a strict confirmation. Once the user confirms, the TUI exits cleanly and we hand control over to the embedded bash script — which needs raw stdin/stdout for its own interactive prompts (passphrases, etc.). Running a long interactive shell script inside a Bubble Tea AltScreen corrupts the terminal, so the consultive front and the executor live in separate phases.

Exit codes:

0  success (or --show, or non-TTY abort)
1  prerequisites missing OR script failure
2  user cancel (Esc or n at the confirm prompt)