The CLI is a product, not an afterthought

The web app is the right place to browse projects, review version history, and manage devices. But the moment you actually need your environment restored, you are often somewhere a browser is a nuisance: an SSH session into a remote box, a fresh WSL install, a container, a CI job.

That is the CLI's job, and it is why we treat it as a product with its own design goals rather than a generated client.

What "first-class" means here

• Runs where you actually are. Windows, macOS, Linux, WSL, SSH, cloud VMs, CI. No assumption that a GUI or a browser is reachable.
• Authenticates without a password in the terminal. A device-code flow you approve in a browser on any device — see Logging in without typing a password into your terminal.
• Stores credentials in the OS keychain, not a plaintext dotfile.
• Explains itself. Project detection tells you which Git remote matched which project, so it is never magic — see Finding the right project from your Git remote.
• Is scriptable. Meaningful exit codes, a non-interactive mode, output that is readable and greppable.
• Never overwrites local files silently. A prompt and a backup, always.

One domain model, two surfaces

The CLI and the web app talk to the same versioned API and share the same validation and crypto primitives. That is a deliberate constraint: business logic is not allowed to live in one surface and not the other. A file pushed from the CLI is indistinguishable from one pushed via the web, because the same code encrypted it.

If the CLI and the web app can disagree about what a "project" is, you have two products and a support problem.

The workflow we are optimising for

git clone git@github.com:acme/portfolio-analytics.git
cd portfolio-analytics
nvault init      # detects the repo, matches the project
nvault pull      # restores .env, .env.local, .env.production

Four commands from nothing to a working environment on a new machine. Getting that to feel effortless — and safe — is the whole point.