@vitrinka/cli 5.0.1 → 5.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/CHANGELOG.md +42 -0
  2. package/README.md +16 -20
  3. package/package.json +7 -7
package/CHANGELOG.md CHANGED
@@ -3,6 +3,48 @@
3
3
  `vitrinka update` prints the sections newer than your previous version
4
4
  after updating — keep entries short and user-facing.
5
5
 
6
+ ## 5.1.0
7
+
8
+ **One MCP sign-in per origin, and `vitrinka mcp` is gone.** The OAuth grant
9
+ now covers every workspace of your organisation: consent picks a home
10
+ workspace, and every registration names the same `/mcp` endpoint, so
11
+ switching repos never re-authenticates and parallel sessions in different
12
+ workspaces no longer knock each other out. A repo's workspace rides an
13
+ `X-Vitrinka-Workspace` header in its committed entry (`.mcp.json` spells the
14
+ origin `${VITRINKA_URL:-https://app.vitrinka.ai}` so self-hosted clones
15
+ follow one exported variable); to act in another workspace of the
16
+ organisation, name the project `<workspace>/<project>` — in MCP calls and in
17
+ `--project`. Codex registers the same door (`codex mcp login vitrinka`).
18
+
19
+ `--mcp-stdio` no longer exists.
20
+
21
+ **One committed vitrinka file per repo.** The workspace binding, project slug,
22
+ runners and run stacks now live at the top of the root `vitrinka.config.json`,
23
+ beside the index policy. `.vitrinka/` is a machine-local runtime directory
24
+ that ignores itself, so your `.gitignore` needs no vitrinka lines at all — and
25
+ `journeys.json` / `sessions.json` are no longer committed (the task engine is
26
+ their record). The old `.vitrinka/project.json` is still read for this
27
+ release; `doctor` names it until it is gone.
28
+
29
+ **Run `vitrinka setup` once after updating.** It folds
30
+ `.vitrinka/project.json` into the root file, untracks the old manifests,
31
+ removes every `.vitrinka` line from `.gitignore` and `.git/info/exclude`, and
32
+ rewrites stdio-forwarder and `/w/<workspace>/mcp` entries onto the one `/mcp`
33
+ door. `vitrinka doctor` names a leftover forwarder as a dead door.
34
+
35
+ ## 5.0.2
36
+
37
+ `vitrinka setup` now installs the todo hooks it always claimed to. `doctor`
38
+ names setup as the repair when the SessionStart todo rows are missing their
39
+ `startup|clear` matcher or the PreToolUse touch row is absent, but setup only
40
+ ever wrote the task-run hooks — it printed "Claude hooks done" and changed
41
+ nothing. Run `vitrinka setup` once after updating and `vitrinka doctor` goes
42
+ clean.
43
+
44
+ Until a machine does that, its session starts still inject the whole open
45
+ todo list on every start, resume and compaction, instead of the handful of
46
+ todos whose condition actually fired.
47
+
6
48
  ## 5.0.1
7
49
 
8
50
  `vitrinka update` and `vitrinka doctor` are back at the top level, the way
package/README.md CHANGED
@@ -47,39 +47,35 @@ process per session; sign in once from inside Claude Code (`/mcp` → vitrinka
47
47
  claude mcp add --scope project --transport http vitrinka https://app.vitrinka.ai/w/<workspace>/mcp
48
48
  ```
49
49
 
50
- The same command renders the repo's committed `.vitrinka/project.json` into
50
+ The same command renders the repo's committed `vitrinka.config.json` into
51
51
  every other harness's project-level file — Cursor (`.cursor/mcp.json`),
52
52
  OpenCode (`opencode.json`), VS Code (`.vscode/mcp.json`), Gemini CLI
53
53
  (`.gemini/settings.json`) — as a plain remote URL the harness signs into with
54
54
  its own OAuth flow; `--harness <csv|all>` picks them (default: Claude Code
55
55
  plus whatever is detected), entries merge into existing files, and
56
- `vitrinka doctor` reports drift. Through a user-level entry (root `/mcp`)
56
+ `vitrinka doctor` reports drift. Every entry names the same root `/mcp`
57
+ endpoint; the repo's workspace rides an `X-Vitrinka-Workspace` header, and
58
+ the committed file spells the origin `${VITRINKA_URL:-https://app.vitrinka.ai}`
59
+ so a self-hosted developer exports one variable and the same file works.
60
+ One OAuth sign-in per origin covers every workspace of your organisation —
61
+ a call may name another as `<workspace>/<project>`. Through a user-level
62
+ entry (root `/mcp`, no header) calls land in the grant's home workspace and
57
63
  writes reach only projects that already exist; the bound repo's project file
58
64
  is what allows creating them.
59
65
 
60
- For Codex, headless machines (`vitrinka setup --mcp-stdio`) and any MCP
61
- client without OAuth, the CLI's own stdio forwarder `vitrinka mcp` does the
62
- same job: it resolves the deployment origin, the workspace, the token (OS
63
- keyring) and the operator at runtime, so the entry carries no URL, no token,
64
- no headers:
65
-
66
- ```json
67
- {
68
- "mcpServers": {
69
- "vitrinka": { "command": "vitrinka", "args": ["mcp"] }
70
- }
71
- }
72
- ```
66
+ Codex registers the same door (`codex mcp add vitrinka --url <origin>/mcp`,
67
+ then `codex mcp login vitrinka`); its registry is global, so the home
68
+ workspace is the default there and `<workspace>/<project>` reaches the rest.
73
69
 
74
- > The old **HTTP + `Authorization: Bearer …` registration is retired** — it
75
- > baked a credential into client config. `vitrinka doctor` flags it and
76
- > `vitrinka setup` rewrites it.
70
+ > The **stdio forwarder `vitrinka mcp` is retired** (as is the older HTTP +
71
+ > `Authorization: Bearer …` shape that baked a credential into client
72
+ > config). `vitrinka doctor` flags either and `vitrinka setup` rewrites it.
77
73
 
78
74
  `vitrinka setup` also links `~/.local/bin/vitrinka` straight to the Go
79
75
  binary this package ships (on npm and bun; pnpm gets a copy that `vitrinka
80
76
  update` refreshes) and puts it first on PATH, so long-running commands
81
- (`vitrinka mcp`, `vitrinka work watch`) run without the Node launcher idling as
82
- their parent. Updates still flow through your package manager.
77
+ (`vitrinka work watch`) run without the Node launcher idling as their
78
+ parent. Updates still flow through your package manager.
83
79
 
84
80
  vitrinka is an authenticated service at `https://app.vitrinka.ai` — sign up
85
81
  there (open beta), then `vitrinka auth login` signs the CLI in through the
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vitrinka/cli",
3
- "version": "5.0.1",
3
+ "version": "5.1.0",
4
4
  "description": "vitrinka CLI — capture and publish artifact sets, drive the annotation-board work queue. Thin npm launcher for the single-binary Go CLI.",
5
5
  "bin": {
6
6
  "vitrinka": "bin/vitrinka.js"
@@ -15,12 +15,12 @@
15
15
  "node": ">=18"
16
16
  },
17
17
  "optionalDependencies": {
18
- "@vitrinka/cli-darwin-arm64": "5.0.1",
19
- "@vitrinka/cli-darwin-x64": "5.0.1",
20
- "@vitrinka/cli-linux-arm64": "5.0.1",
21
- "@vitrinka/cli-linux-x64": "5.0.1",
22
- "@vitrinka/cli-win32-arm64": "5.0.1",
23
- "@vitrinka/cli-win32-x64": "5.0.1"
18
+ "@vitrinka/cli-darwin-arm64": "5.1.0",
19
+ "@vitrinka/cli-darwin-x64": "5.1.0",
20
+ "@vitrinka/cli-linux-arm64": "5.1.0",
21
+ "@vitrinka/cli-linux-x64": "5.1.0",
22
+ "@vitrinka/cli-win32-arm64": "5.1.0",
23
+ "@vitrinka/cli-win32-x64": "5.1.0"
24
24
  },
25
25
  "keywords": [
26
26
  "vitrinka",