@vitrinka/cli 5.18.0 → 5.20.0

package/CHANGELOG.md

@@ -3,6 +3,52 @@
 `vitrinka update` prints the sections newer than your previous version
 after updating — keep entries short and user-facing.
 
+## 5.20.0
+
+**The plugin is four plugins.** `vitrinka` (core: publish, artifact,
+brainstorming, listen, resolve), `vitrinka-pm` (pickup, handoff, tasks,
+release, me — and the session hooks of the work loop, so a Claude Code
+marketplace install gets them without `setup`), `vitrinka-qa` (usertest,
+review, sessions, pair, spot) and the opt-in, Claude Code only
+`vitrinka-experimental` (build-idea, make-idea, test, cleanup). A session
+on a repo that only needs boards no longer pays for the task engine's
+skills and tools. `vitrinka setup` installs core + pm + qa (`--modules`
+picks, `--experimental` adds the fourth); this `vitrinka update` installs
+pm and qa once on a machine set up before the split, and respects a
+choice `vitrinka setup modules` has recorded. Codex keeps one bundle with
+every module.
+
+`vitrinka setup modules list|enable|disable <module>` adds or removes the
+plugin that ships a module (pm, me, qa, experimental; core is always on)
+and re-registers Claude Code's MCP door as `/mcp?modules=…`, so the tool
+catalogue and its instructions shrink with the plugins you have.
+`vitrinka setup skills show|hide <skill>` hides one optional skill
+without dropping its module. `vitrinka doctor` shows a `plugin·claude`
+and `plugin·codex` row per runtime and a `hooks·claude` row.
+
+Six MCP doors the skills used to reach with raw calls: `undo` (revert
+your newest batch on a board), `refresh` (re-parse a living-source card),
+`import` (a truth source — openapi, sqlddl, compose, pgschema — as one
+refreshable diagram), `review_verify` (link a fresh capture to a failed
+judgment), `get_card_image {annotation}` and `update {kind: "session"}`.
+`spot` moved to the qa module; five doors nobody called moved to `rare`.
+Every skill was rewritten against the doors that exist — no `/api/v1/`
+route anywhere; the ladder is the MCP tool, then the CLI, then stop.
+
+In Claude Code type the bare `/pickup`, `/publish`, …; the qualified
+`/vitrinka-pm:pickup` always works. Codex keeps `$pickup`.
+
+## 5.19.0
+
+**A task says which issue it tracks.** `vitrinka task links add <id>
+<url>` attaches the GitHub, GitLab or Jira issue a task tracks (or a
+Confluence page it refers to); `task links <id>` lists them and `task
+links rm <id> <link-id>` detaches one. `vitrinka task find <url>` answers
+which task tracks an issue — exactly, and `links: []` when none does.
+`task create … --link <url>` files a task already linked. An issue has one
+owner task: attaching it to a second answers `link_owned` with the task
+that tracks it.
+
 ## 5.18.0
 
 **A write made offline is not lost.** When the deployment cannot be

package/package.json

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