@vitrinka/cli 5.0.2 → 5.1.1

package/CHANGELOG.md

@@ -3,6 +3,45 @@
 `vitrinka update` prints the sections newer than your previous version
 after updating — keep entries short and user-facing.
 
+## 5.1.1
+
+`vitrinka setup` actually performs the 5.1.0 layout migration. In 5.1.0 it
+reported success and changed nothing on any machine whose plugin and MCP were
+already registered — which is every machine with a repo old enough to need
+migrating. Run `vitrinka setup` once in each bound repo and commit what it
+prints: the fold into `vitrinka.config.json`, the untracked manifests and the
+pruned `.gitignore`. An ignore line for a SIBLING path like `.vitrinka-verify/`
+is left alone; only the runtime dir's own lines go.
+
+## 5.1.0
+
+**One MCP sign-in per origin, and `vitrinka mcp` is gone.** The OAuth grant
+now covers every workspace of your organisation: consent picks a home
+workspace, and every registration names the same `/mcp` endpoint, so
+switching repos never re-authenticates and parallel sessions in different
+workspaces no longer knock each other out. A repo's workspace rides an
+`X-Vitrinka-Workspace` header in its committed entry (`.mcp.json` spells the
+origin `${VITRINKA_URL:-https://app.vitrinka.ai}` so self-hosted clones
+follow one exported variable); to act in another workspace of the
+organisation, name the project `<workspace>/<project>` — in MCP calls and in
+`--project`. Codex registers the same door (`codex mcp login vitrinka`).
+
+`--mcp-stdio` no longer exists.
+
+**One committed vitrinka file per repo.** The workspace binding, project slug,
+runners and run stacks now live at the top of the root `vitrinka.config.json`,
+beside the index policy. `.vitrinka/` is a machine-local runtime directory
+that ignores itself, so your `.gitignore` needs no vitrinka lines at all — and
+`journeys.json` / `sessions.json` are no longer committed (the task engine is
+their record). The old `.vitrinka/project.json` is still read for this
+release; `doctor` names it until it is gone.
+
+**Run `vitrinka setup` once after updating.** It folds
+`.vitrinka/project.json` into the root file, untracks the old manifests,
+removes every `.vitrinka` line from `.gitignore` and `.git/info/exclude`, and
+rewrites stdio-forwarder and `/w/<workspace>/mcp` entries onto the one `/mcp`
+door. `vitrinka doctor` names a leftover forwarder as a dead door.
+
 ## 5.0.2
 
 `vitrinka setup` now installs the todo hooks it always claimed to. `doctor`

package/README.md

@@ -47,39 +47,35 @@ process per session; sign in once from inside Claude Code (`/mcp` → vitrinka
 claude mcp add --scope project --transport http vitrinka https://app.vitrinka.ai/w/<workspace>/mcp
 ```
 
-The same command renders the repo's committed `.vitrinka/project.json` into
+The same command renders the repo's committed `vitrinka.config.json` into
 every other harness's project-level file — Cursor (`.cursor/mcp.json`),
 OpenCode (`opencode.json`), VS Code (`.vscode/mcp.json`), Gemini CLI
 (`.gemini/settings.json`) — as a plain remote URL the harness signs into with
 its own OAuth flow; `--harness <csv|all>` picks them (default: Claude Code
 plus whatever is detected), entries merge into existing files, and
-`vitrinka doctor` reports drift. Through a user-level entry (root `/mcp`)
+`vitrinka doctor` reports drift. Every entry names the same root `/mcp`
+endpoint; the repo's workspace rides an `X-Vitrinka-Workspace` header, and
+the committed file spells the origin `${VITRINKA_URL:-https://app.vitrinka.ai}`
+so a self-hosted developer exports one variable and the same file works.
+One OAuth sign-in per origin covers every workspace of your organisation —
+a call may name another as `<workspace>/<project>`. Through a user-level
+entry (root `/mcp`, no header) calls land in the grant's home workspace and
 writes reach only projects that already exist; the bound repo's project file
 is what allows creating them.
 
-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,
-no headers:
-
-```json
-{
-  "mcpServers": {
-    "vitrinka": { "command": "vitrinka", "args": ["mcp"] }
-  }
-}
-```
+Codex registers the same door (`codex mcp add vitrinka --url <origin>/mcp`,
+then `codex mcp login vitrinka`); its registry is global, so the home
+workspace is the default there and `<workspace>/<project>` reaches the rest.
 
-> The old **HTTP + `Authorization: Bearer …` registration is retired** — it
-> baked a credential into client config. `vitrinka doctor` flags it and
-> `vitrinka setup` rewrites it.
+> The **stdio forwarder `vitrinka mcp` is retired** (as is the older HTTP +
+> `Authorization: Bearer …` shape that baked a credential into client
+> config). `vitrinka doctor` flags either and `vitrinka setup` rewrites it.
 
 `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 work watch`) run without the Node launcher idling as
-their parent. Updates still flow through your package manager.
+(`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
 there (open beta), then `vitrinka auth login` signs the CLI in through the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vitrinka/cli",
-  "version": "5.0.2",
+  "version": "5.1.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": "5.0.2",
-    "@vitrinka/cli-darwin-x64": "5.0.2",
-    "@vitrinka/cli-linux-arm64": "5.0.2",
-    "@vitrinka/cli-linux-x64": "5.0.2",
-    "@vitrinka/cli-win32-arm64": "5.0.2",
-    "@vitrinka/cli-win32-x64": "5.0.2"
+    "@vitrinka/cli-darwin-arm64": "5.1.1",
+    "@vitrinka/cli-darwin-x64": "5.1.1",
+    "@vitrinka/cli-linux-arm64": "5.1.1",
+    "@vitrinka/cli-linux-x64": "5.1.1",
+    "@vitrinka/cli-win32-arm64": "5.1.1",
+    "@vitrinka/cli-win32-x64": "5.1.1"
   },
   "keywords": [
     "vitrinka",