@vitrinka/cli 4.2.0 → 5.0.1

package/CHANGELOG.md

@@ -1,7 +1,75 @@
 # Changelog
 
-`vitrinka update` prints the sections newer than your previous version after
-updating — keep entries short and user-facing.
+`vitrinka update` prints the sections newer than your previous version
+after updating — keep entries short and user-facing.
+
+## 5.0.1
+
+`vitrinka update` and `vitrinka doctor` are back at the top level, the way
+`brew doctor`, `flutter doctor` and `<tool> update` read; `setup update` and
+`setup doctor` are gone (unknown command, exit 2 — no aliases). `setup` keeps
+the bare first run plus `uninstall`, `extension` and `skills`.
+
+`vitrinka task list --json id,title` (a space before the field list) used to
+fail as "unknown command id,title". It now says what it means: the field list
+rides the flag with `=` — `--json=id,title` — and the fix line is the
+corrected command.
+
+## 5.0.0
+
+One vocabulary. The CLI is twenty entries: nouns that group verbs, three
+leaf verbs (status, help, completion), nothing else. Old names are gone —
+they print "unknown command" and exit 2. There are no aliases.
+
+```text
+Old                                New
+install · project setup            setup            (the whole first run)
+doctor · extension doctor          doctor
+update · uninstall                 update · setup uninstall
+extension … · skills …             setup extension … · setup skills …
+set init|push|capture|rename|meta  board init|push|capture|rename|meta
+artifact … · diagram …             board artifact … · board diagram …
+open · edit                        board open · board edit
+run · usertest · pair · session    qa run · qa usertest · qa pair · qa session
+todo · diary · brief · time        me todo · me diary · me brief · me time
+schedule <title> --in …            me schedule add <title> --in …
+schedule list|ripe|move|skip|end   me schedule …
+listen                             work listen
+resolve <url> · query <sql>        search resolve <url> · search query <sql>
+ai <words>                         docs ask <words>
+tidy                               project tidy
+ui                                 (bare `vitrinka` on a terminal)
+login · logout · token             auth login · auth logout · auth token
+push · snap · remote-init          board push · board capture · board init
+name · meta · upload               board rename · board meta · board upload
+board-from-set · journey-from-set  board create · board create --journey
+artifact-init · artifact-from-set  board artifact init · board artifact create
+watch · setup-project · index      work watch · setup · project index
+import · schema                    board diagram import · board diagram schema
+operator · use · smtp              config operator · config bind · admin smtp
+```
+
+### First run
+- **`vitrinka setup`** is the one door: sign in, agent plugin + MCP, detect
+  this repository, review the proposed index (all tracked supported files
+  minus lockfiles, generated, vendored and `.github`), apply, next action.
+  Done steps are skipped on rerun; Back keeps your answers; the key bar
+  survives 80 columns. `--advanced` opens the directory picker.
+- **`vitrinka doctor`** checks the installation and this repository;
+  `--all` adds every registered project. `--fix` shows a target · before ·
+  after plan and applies it after review.
+
+### Agents
+- `--no-input` never prompts (also `VITRINKA_NO_INPUT=1`, `CI=true`);
+  `--yes` accepts the proposed plan; a step that needs a person exits 5
+  `needs_human` with the plan in the envelope and the `--yes` rerun in
+  `next[]`.
+- `--json=id,title` prunes `data` to those fields; `--jq '<expr>'` filters
+  the envelope.
+- Exit codes: 0 · 1 · 2 misuse · 3 nothing found · 4 sign in · 5 needs a
+  human · 130 cancelled.
+- `vitrinka help exit-codes|json|no-input|environment|agents` explain each
+  contract; every command's help carries the same vocabulary.
 
 ## 4.2.0
 

package/README.md

@@ -15,10 +15,10 @@ download, no network surprise in sandboxed CI or behind a corporate proxy.
 
 ```bash
 npm i -g @vitrinka/cli
-vitrinka install        # one-command machine setup
+vitrinka setup        # one-command machine setup
 ```
 
-`vitrinka install` IS the onboarding: it prints a ✓/✗ table of every component,
+`vitrinka setup` IS the onboarding: it prints a ✓/✗ table of every component,
 silently installs the harmless ones (the skills plugin into each runtime CLI it
 finds, a `vitrinka` shim on PATH, shell completion — all reversible), then asks
 `[Y/n]` only for the config-touchers: MCP registration, the write token (silent
@@ -28,7 +28,7 @@ input, → the OS keyring) and the operator name.
 vitrinka doctor          # server, token, operator, skills, shim, MCP
 vitrinka doctor --fix    # repairs the repairable
 vitrinka update          # update the CLI and everything install put here
-vitrinka uninstall       # remove it all (--purge: token too)
+vitrinka setup uninstall       # remove it all (--purge: token too)
 ```
 
 Installing with `--omit=optional` / `--no-optional` skips the binary by design.
@@ -38,7 +38,7 @@ failing as "command not found".
 ## MCP
 
 The MCP surface is served by the vitrinka server at `/mcp` and per workspace
-at `/w/<workspace>/mcp`, with OAuth 2.1 built in. `vitrinka install` registers
+at `/w/<workspace>/mcp`, with OAuth 2.1 built in. `vitrinka setup` registers
 it for you. For Claude Code that is a **remote HTTP entry** — no local
 process per session; sign in once from inside Claude Code (`/mcp` → vitrinka
 → authenticate):
@@ -57,7 +57,7 @@ plus whatever is detected), entries merge into existing files, and
 writes reach only projects that already exist; the bound repo's project file
 is what allows creating them.
 
-For Codex, headless machines (`vitrinka install --mcp-stdio`) and any MCP
+For Codex, headless machines (`vitrinka setup --mcp-stdio`) and any MCP
 client without OAuth, the CLI's own stdio forwarder `vitrinka mcp` does the
 same job: it resolves the deployment origin, the workspace, the token (OS
 keyring) and the operator at runtime, so the entry carries no URL, no token,
@@ -73,12 +73,12 @@ no headers:
 
 > The old **HTTP + `Authorization: Bearer …` registration is retired** — it
 > baked a credential into client config. `vitrinka doctor` flags it and
-> `vitrinka install` rewrites it.
+> `vitrinka setup` rewrites it.
 
-`vitrinka install` also links `~/.local/bin/vitrinka` straight to the Go
+`vitrinka setup` also links `~/.local/bin/vitrinka` straight to the Go
 binary this package ships (on npm and bun; pnpm gets a copy that `vitrinka
 update` refreshes) and puts it first on PATH, so long-running commands
-(`vitrinka mcp`, `vitrinka watch`) run without the Node launcher idling as
+(`vitrinka mcp`, `vitrinka work watch`) run without the Node launcher idling as
 their parent. Updates still flow through your package manager.
 
 vitrinka is an authenticated service at `https://app.vitrinka.ai` — sign up
@@ -96,7 +96,7 @@ browser. Self-hosted deployments point the CLI at their own host with
 
 ## Trustworthy project index
 
-`vitrinka setup-project` or `vitrinka index configure` creates the
+`vitrinka setup` or `vitrinka project index configure` creates the
 repository-owned `vitrinka.config.json`. The interactive picker chooses
 extension groups and any depth of directory tree, then shows the exact file
 manifest before approval. Choosing "later" writes an explicit disabled policy
@@ -110,10 +110,10 @@ untracked files require an explicit advanced opt-in; credential/key filenames
 and binary/generated assets are blocked by both client and server safety floors.
 
 ```bash
-vitrinka index configure              # edit, preview, approve, then refresh
-vitrinka index status                 # policy + local approval/upload receipt
-vitrinka index --dry-run              # exact paths, no network request
-vitrinka index --explain path/to/file # winning selection or deny rule
+vitrinka project index configure              # edit, preview, approve, then refresh
+vitrinka project index status                 # policy + local approval/upload receipt
+vitrinka project index --dry-run              # exact paths, no network request
+vitrinka project index --explain path/to/file # winning selection or deny rule
 ```
 
 The config schema is served by the deployment at
@@ -124,9 +124,9 @@ The config schema is served by the deployment at
 
 `~/.config/vitrinka/desktop-app` is the ONE canonical "is Vitrinka.app installed
 here" answer (content = the app path). `apps/desktop`'s `make install` stamps it;
-`doctor` and `setup-project` re-sync it to reality. `vitrinka open` uses it to
+`doctor` and `setup-project` re-sync it to reality. `vitrinka board open` uses it to
 open boards in the app (pass `--browser` to force the browser), and
-`vitrinka edit [path]` focuses the resident app on a file or project.
+`vitrinka board edit [path]` focuses the resident app on a file or project.
 
 ## Development
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vitrinka/cli",
-  "version": "4.2.0",
+  "version": "5.0.1",
   "description": "vitrinka CLI — capture and publish artifact sets, drive the annotation-board work queue. Thin npm launcher for the single-binary Go CLI.",
   "bin": {
     "vitrinka": "bin/vitrinka.js"
@@ -15,12 +15,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@vitrinka/cli-darwin-arm64": "4.2.0",
-    "@vitrinka/cli-darwin-x64": "4.2.0",
-    "@vitrinka/cli-linux-arm64": "4.2.0",
-    "@vitrinka/cli-linux-x64": "4.2.0",
-    "@vitrinka/cli-win32-arm64": "4.2.0",
-    "@vitrinka/cli-win32-x64": "4.2.0"
+    "@vitrinka/cli-darwin-arm64": "5.0.1",
+    "@vitrinka/cli-darwin-x64": "5.0.1",
+    "@vitrinka/cli-linux-arm64": "5.0.1",
+    "@vitrinka/cli-linux-x64": "5.0.1",
+    "@vitrinka/cli-win32-arm64": "5.0.1",
+    "@vitrinka/cli-win32-x64": "5.0.1"
   },
   "keywords": [
     "vitrinka",