projectstore-claude 0.29.3 → 0.30.0

package/README.md

@@ -1,25 +1,26 @@
 # projectstore-claude
 
-The Claude Code installer for [projectstore](https://www.npmjs.com/package/projectstore): the core, pinned at exactly this version and bundled inside this tarball, with the harness fixed. One command, from a terminal **outside** a Claude Code session:
+> **To install ProjectStore, run `npx projectstore setup` from a terminal in your project.** This package is a release artifact; you do not need it.
+
+The Claude Code distribution shell of [projectstore](https://www.npmjs.com/package/projectstore): the core, pinned at exactly this version and bundled inside this tarball, with the harness fixed to Claude Code.
+
+From a terminal in your project:
 
 ```sh
-npx projectstore-claude install --project "$PWD"
+npx projectstore setup
 ```
 
-It registers the plugin for that checkout at the host's local scope. It prints its plan first — every write and every host command, verbatim — and at a terminal asks `◆ Apply N changes? [Y/n]` before anything runs; then each step as it runs, and what to do next. Without a terminal (a script, CI, an agent's tool) naming the shell is the confirmation; `--json` never asks. Restart Claude Code afterwards.
-
-- See before you write: `npx projectstore-claude plan --project "$PWD"` prints the same plan and writes nothing; `--verbose` adds every row's reasoning; `npx projectstore-claude <verb> --help` lists a verb's options with examples.
+Setup finds the coding agents the project uses, Claude Code among them, and installs ProjectStore for each, with a vault for the project's notes. It asks a few questions, prints one plan — every write and every host command, verbatim — and asks once before anything runs. For Claude Code it registers the plugin for that checkout at the host's local scope, through a small local marketplace under your Claude home. Restart Claude Code afterwards.
 
-- Upgrade, or pin: `npx projectstore-claude@<version> upgrade --project "$PWD"` — the version you name is the version you run.
-- Behind a registry mirror: if `npx` answers `could not determine executable to run`, the mirror's index knows only the reserved `0.0.1` placeholder — name the version, and if needed the public registry: `npx --registry https://registry.npmjs.org projectstore-claude@<version> install --project "$PWD"`.
-- Uninstall: `npx projectstore-claude uninstall --project "$PWD"` — forgets the registration for that checkout and nothing else; your vault is plain markdown and stays yours.
-- `doctor`, `status`, `search` and the other read verbs pass through unchanged: `npx projectstore-claude doctor --json`.
+Upgrade, or pin, from the same place; the version you name is the version you run:
 
-This shell is `projectstore <verb> --harness claude-code` and nothing more. `bin/projectstore-claude.mjs` locates the bundled core under `node_modules/projectstore/` and execs it; the core's low-level form — `npx projectstore install --harness claude-code --project "$PWD"` — is exactly what runs. A different `--harness` is refused (exit 2). The shell carries no plugin of its own: the plugin Claude Code loads is the bundled core, registered through a small local marketplace under your Claude home.
+```sh
+npx projectstore@<version> upgrade
+```
 
-Why from a terminal: the host CLI and a live session both rewrite the same settings files, so the core defers the registration inside a session and says so.
+This shell's bin is `projectstore <verb> --harness claude-code` and nothing more. `bin/projectstore-claude.mjs` locates the bundled core under `node_modules/projectstore/` and execs it; a different `--harness` is refused (exit 2). The shell carries no plugin of its own: the plugin Claude Code loads is the bundled core.
 
-- Docs: https://github.com/SmartAndPoint/ProjectStore#install--one-message
+- Docs: https://github.com/SmartAndPoint/ProjectStore#install
 - Source: https://github.com/SmartAndPoint/ProjectStore
 - Issues: https://github.com/SmartAndPoint/ProjectStore/issues
 

package/bin/projectstore-claude.mjs

@@ -24,7 +24,7 @@ const HARNESS = "claude-code";
 // scripts/cli.mjs; the packaging test pins it). Any other verb — doctor,
 // status, search, --version — passes through untouched: the core refuses an
 // option a verb does not declare, so a blanket insert would break `doctor`.
-const HARNESS_VERBS = new Set(["plan","install","uninstall","upgrade","agents"]);
+const HARNESS_VERBS = new Set(["setup","plan","install","uninstall","upgrade","agents"]);
 
 // The bundled core, by path — never by package resolution: a hoisted or global
 // copy at another version is exactly the pairing the pin exists to prevent,
@@ -57,7 +57,7 @@ function fixHarness(argv) {
     }
   }
   const other = given.find((g) => g !== HARNESS);
-  if (other !== undefined) return { error: `installs for ${HARNESS} only — \`--harness ${other}\` names another harness. Run that harness's shell, or the core: npx projectstore <verb> --harness ${other} …` };
+  if (other !== undefined) return { error: `installs for ${HARNESS} only — \`--harness ${other}\` names another harness. Run the core: npx projectstore <verb> --harness ${other} …` };
   if (given.length) return { argv }; // named already: pass through, never twice (the core's option repeats)
   const at = scan.findIndex((a) => !a.startsWith("-"));
   if (at === -1 || !HARNESS_VERBS.has(scan[at])) return { argv };

package/node_modules/projectstore/.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "projectstore",
       "displayName": "projectstore",
       "description": "📚 Your agent runs the project through a verified loop: task → artifact (ADR · spec · epic · story) → adversarial critic → backlog → planner → reviewer → done. Plain markdown in an Obsidian-friendly vault, every write approved by you — and any model can pick the project up tomorrow.",
-      "version": "0.29.3",
+      "version": "0.30.0",
       "author": {
         "name": "Evgenii Konev",
         "email": "ekonev@smartandpoint.com",

package/node_modules/projectstore/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "projectstore",
   "displayName": "projectstore",
-  "version": "0.29.3",
+  "version": "0.30.0",
   "description": "Your agent runs the project through a verified loop: task → artifact (ADR / spec / epic / story) → adversarial critic → backlog → planner → reviewer → done. Plain markdown in git — any model can pick the project up tomorrow.",
   "author": {
     "name": "Evgenii Konev @ SmartAndPoint",

package/node_modules/projectstore/README.md

@@ -4,7 +4,7 @@
 
 [![release](https://img.shields.io/github/v/release/SmartAndPoint/ProjectStore?label=release)](https://github.com/SmartAndPoint/ProjectStore/releases) [![license](https://img.shields.io/github/license/SmartAndPoint/ProjectStore?label=license)](./LICENSE) [![Star on GitHub](https://img.shields.io/badge/%E2%AD%90-star_us-yellow?logo=github)](https://github.com/SmartAndPoint/ProjectStore/stargazers)
 
-A project workflow plugin for [Claude Code](https://claude.com/claude-code) and [OpenAI Codex](https://developers.openai.com/codex/) (experimental). Both are released together at one version, and each installs with one command.
+A project workflow plugin for [Claude Code](https://claude.com/claude-code) and [OpenAI Codex](https://developers.openai.com/codex/) (experimental). Both are released together at one version, and one command sets a project up for either or both: see [Install](#install).
 
 ---
 
@@ -75,24 +75,40 @@ In Claude Code a band above the prompt goes further (experimental): the session'
 
 Open the vault in [Obsidian](https://obsidian.md) and you get the graph view and the board for free. Don't use Obsidian? Everything renders on GitHub and in any editor.
 
-## Install — one message
+## Install
 
-Open Claude Code in your project and say:
+From a terminal in your project:
 
-> Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.
+```
+npx projectstore setup
+```
 
-That's the whole setup. Claude adds the marketplace, installs the plugin, and walks you through binding a vault, scaffolding it and wiring the status line — every step previewed, nothing written without your Yes.
+Setup finds the coding agents the project uses — Claude Code, Codex or both — and installs ProjectStore for each, with a vault for the project's notes. At a terminal it asks a few questions: which folder is the project, which agents to install for, where the vault lives (an existing folder is bound; a missing or empty one becomes a new vault, with its own git repository and the layout's folders) and whether to show ProjectStore in the status line. Then it prints one plan — every file it writes and every host command, verbatim — and asks once before it writes anything. Restart the agent afterwards; Codex asks you to approve the ProjectStore hooks once.
 
-**On Codex**, run one command from a terminal in your project:
+`npx projectstore setup --dry-run` shows the questions and the plan and writes nothing. Without a terminal (a script, CI, an agent's tool) nothing is asked: `--harness <id>` names an agent and is the confirmation, and `--vault <path>` names the vault. `npx projectstore setup --help` lists the rest.
+
+If you prefer a global command:
 
 ```
-npx projectstore-codex install --project "$PWD"
+npm install -g projectstore
+projectstore setup
 ```
 
-Then restart Codex, approve the ProjectStore hooks when it asks, and run `$projectstore-bind ~/Documents/my-project-vault`. Codex support is newer and still labelled experimental: [`docs/harnesses.md`](./docs/harnesses.md#codex) says what has been verified and what has not. A project can be worked from both agents: they share the binding in `.projectstore/`, and each keeps its own overlay and session state beside it ([running both over one project](./docs/harnesses.md#running-both-over-one-project)).
+Behind a registry mirror (often a company's), `npx` runs the newest `projectstore` the mirror knows. That can be a release older than setup, which answers that `setup` is an unknown verb, or no release at all. Name the version, and if that is not enough, the public registry:
 
-<details>
-<summary>Prefer to type it yourself?</summary>
+```
+npm_config_registry=https://registry.npmjs.org npx projectstore@<version> setup
+```
+
+npm reads that variable wherever it runs, so the Codex plugin setup fetches comes from the same registry.
+
+### In a Claude Code session
+
+Open Claude Code in your project and say:
+
+> Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.
+
+Claude adds the git marketplace, installs the plugin, and walks you through binding a vault, scaffolding it and wiring the status line — every step previewed, nothing written without your Yes. Or type it yourself:
 
 ```
 /plugin marketplace add SmartAndPoint/ProjectStore
@@ -103,49 +119,31 @@ Then restart Codex, approve the ProjectStore hooks when it asks, and run `$proje
 
 One switch worth flipping: Claude Code does **not** auto-update third-party plugins by default — `/plugin` → **Marketplaces** → **SmartAndPoint** → toggle **auto-update** on. If you skip it, `/projectstore:doctor` will remind you later with the exact setting.
 
-Contributors: `git clone` this repo, then `claude --plugin-dir ./ProjectStore`.
-
-**Or from npm, in one command** — from a terminal, not inside a Claude Code session:
+Contributors: `git clone` this repo, then run Claude Code from the clone's parent folder:
 
 ```
-npx projectstore-claude install --project "$PWD"
+claude --plugin-dir ./ProjectStore
 ```
 
-The same tree is published to npm as [`projectstore`](https://www.npmjs.com/package/projectstore) — one source package carrying every harness's manifest — and `projectstore-claude` is its Claude Code shell: the core pinned at the same version and bundled inside, the harness fixed, so the one command has the same shape on every harness. It registers the plugin with Claude Code: it writes a small local marketplace of its own under your Claude home, then drives `claude plugin marketplace add` / `plugin install` **at local scope**, so the registration lands in this checkout's `.claude/settings.local.json` and nowhere else. It prints its plan first — every file it writes and every host command, verbatim — and at a terminal asks `◆ Apply N changes? [Y/n]`; then it shows each step as it runs and what to do next. Without a terminal (a script, CI, an agent's tool) naming the harness is the confirmation. `plan` prints the same plan and writes nothing; `--verbose` adds every row's reasoning; `npx projectstore-claude <verb> --help` lists a verb's options with examples. Restart Claude Code afterwards. A git-marketplace copy already enabled for the checkout is silenced there (not globally) so the plugin does not load twice; `uninstall` turns it back on. Pin or upgrade with `npx projectstore-claude@<version> upgrade --project "$PWD"` — the version you name is the version you run. The core's low-level form, `npx projectstore <verb> --harness claude-code …`, is exactly what the shell runs. bun works the same on the packed bin.
+<details>
+<summary>What setup does for each agent, the low-level verbs, the CLI and MCP</summary>
 
-**Codex has its own shell with the same one-command shape:**
-`npx projectstore-codex install --project "$PWD"`. It carries a Codex
-plugin manifest, namespaced workflow and role skills, lifecycle hooks, and
-the exact bundled core. It stages a stable marketplace under `CODEX_HOME`,
-drives `codex plugin marketplace add` and `codex plugin add`, then reads the
-installation back and verifies its version and payload digest. Before it
-changes anything it asks Codex for that read-back (`codex plugin list --json`),
-so a Codex too old to answer stops the registration before it changes anything
-and tells you to upgrade Codex. Restart Codex,
-approve the hooks, and run `$projectstore-bind <vault-path>`. For later
-releases, `npx projectstore-codex@<version> upgrade --project "$PWD"`. Because
-Codex's plugin registry is user-global, ordinary uninstall removes only the
-project's agents block; `uninstall --global` is the explicit machine-wide
-removal. If `npx` answers `could not determine executable to run`, your
-registry (often a company mirror) serves a stale index that knows only the
-reserved `0.0.1` placeholder: name the version, and if that is not enough, the
-public registry: `npx --registry https://registry.npmjs.org
-projectstore-codex@<version> install --project "$PWD"` (the same holds for
-`projectstore-claude`). Codex is **experimental** until a live session has exercised every
-surface it installs; [`docs/harnesses.md`](./docs/harnesses.md) says what has
-been measured and what has not. From a checkout, the same npx path runs against
-a built tarball:
+**Claude Code.** Setup registers the plugin from the npm package [`projectstore`](https://www.npmjs.com/package/projectstore) — one source package carrying every harness's manifest. It writes a small local marketplace of its own under your Claude home, then drives `claude plugin marketplace add` / `plugin install` **at local scope**, so the registration lands in this checkout's `.claude/settings.local.json` and nowhere else. The host CLI and a live session both rewrite the same settings files, so inside a Claude Code session the registration is deferred, and the plan says so: run setup from a terminal outside the session. When the checkout already loads ProjectStore from the git marketplace, setup asks whether to switch this project to the npm install or keep the git marketplace. A switch silences the git-marketplace copy for this checkout only (not globally), so the plugin does not load twice; `uninstall` turns it back on.
+
+**Codex.** The Codex plugin ships in a package of its own; setup fetches it at setup's own version and plans Codex in the same plan as everything else. It stages a stable marketplace under `CODEX_HOME`, drives `codex plugin marketplace add` and `codex plugin add`, then reads the installation back and verifies its version and payload digest. Before it changes anything it asks Codex for that read-back (`codex plugin list --json`), so a Codex too old to answer stops the registration before it changes anything and tells you to upgrade Codex. Codex's plugin registry is user-global; the agents block in `AGENTS.md` stays project-local. Codex is **experimental** until a live session has exercised every surface it installs: [`docs/harnesses.md`](./docs/harnesses.md#codex) says what has been verified and what has not. A project can be worked from both agents: they share the binding in `.projectstore/`, and each keeps its own overlay and session state beside it ([running both over one project](./docs/harnesses.md#running-both-over-one-project)).
+
+**The low-level verbs.** Setup composes verbs that also run on their own. One agent's install, with no questions about the project or the vault:
 
-```sh
-npm run shells:build -- --only projectstore-codex --dev --out dist
-npx --package "./dist/projectstore-codex-$(node -p 'require("./package.json").version').tgz" projectstore-codex install --project "$PWD"
 ```
+npx projectstore install --harness claude-code   # shows the plan, asks at a terminal, then writes; without a terminal naming the harness is the confirmation — there is no --yes
+```
+
+`plan` prints the same plan and writes nothing; `--verbose` adds every row's reasoning; `npx projectstore <verb> --help` lists a verb's options with examples. bun works the same on the packed bin.
 
-The package also carries a `bin`. Without a session — in CI, or in a shell — the same core answers token-free, with a `--json` envelope on every verb:
+Without a session — in CI, or in a shell — the same core answers token-free, with a `--json` envelope on every verb:
 
 ```
 npx projectstore doctor --json
-npx projectstore install --harness claude-code   # the low-level form the shell runs: shows the plan, asks at a terminal, then writes; without a terminal naming the harness is the confirmation — there is no --yes
 npx projectstore reconcile --write --only kanban
 ```
 
@@ -175,43 +173,76 @@ npx projectstore init ~/vaults/new-project --language ru
 npx projectstore scaffold --write
 ```
 
-`projectstore-claude`, `projectstore-codex` and `projectstore-opencode` are this package's per-harness shells — the core pinned and bundled, the harness fixed. The Claude Code and Codex shells are published at the core's version; Codex stays labelled experimental until a live run has exercised every surface it installs ([`docs/harnesses.md`](./docs/harnesses.md)). The opencode shell publishes after its plugin root is rendered. The other `projectstore-*` names are reserved placeholders pointing back here. One source package, one version, N tarballs.
+`projectstore-claude`, `projectstore-codex` and `projectstore-opencode` are release artifacts: per-harness packages that carry the core, pinned at the same version and bundled, with the harness fixed. Nobody needs to type their names. Setup fetches the Codex one, which carries the Codex plugin; the Claude Code one is published at the core's version too; the opencode one publishes after its plugin root is rendered. The other `projectstore-*` names are reserved placeholders pointing back here. One source package, one version, N tarballs. How a release builds and publishes them, and how to run a checkout's own build: [`packaging/README.md`](./packaging/README.md).
 </details>
 
 ## Upgrading
 
-`/plugin update` (or auto-update) and a restart, then one command per project
-bound before 0.28. What an existing project sees afterwards, and why:
+Installed with setup or from npm: from a terminal in your project, name the version you want to run (`latest` is the newest):
+
+```
+npx projectstore@<version> upgrade
+```
+
+It upgrades every agent the project uses — each one whose own directory (`.claude/`, `.codex/`) or `.projectstore/state/<id>/` is there — in one plan, and fetches the Codex plugin at the same version. `npx projectstore setup` converges a project the same way and asks its questions again. Installed from the git marketplace in a Claude Code session: `/plugin update` (or auto-update) and a restart.
+
+A bare upgrade selects agents by those directories, so on Codex name it, which upgrades Codex even in a project where no Codex session has run yet:
+
+```
+npx projectstore@<version> upgrade --harness codex
+```
+
+With the global command, update it first, then run it in the project:
+
+```
+npm install -g projectstore@latest
+projectstore upgrade
+```
+
+A project bound before 0.28 needs one more command. What an existing project sees afterwards, and why:
 
 - **The project's files move to `.projectstore/`.** `.claude/projectstore.json`
   and `.claude/.projectstore/` become `.projectstore/projectstore.json`,
   `.projectstore/harness/claude-code.json` and `.projectstore/state/`. Nothing
   breaks before you move them: every reader falls back to the old paths through
-  0.29, and the startup line names the command until the move is done. Close
-  every Claude Code session in the project, run that command from a terminal,
-  then restart. The command depends on how you installed:
-  - **From the git marketplace** (every 0.27.x install): the installed copy's
-    own `bin/projectstore.mjs`, with its path spelled out in the startup line —
-    `node "<plugin cache>/bin/projectstore.mjs" upgrade --harness claude-code --no-register --project "$PWD"`.
-    `--no-register` leaves your plugin registration as it is.
-  - **From npm**: `npx projectstore-claude@<version> upgrade --no-register --project "$PWD"`.
-
-  Both forms move only the project's files, so neither touches your plugin
-  registration. The same run re-stamps the status-line launcher at its new path
-  and re-registers the agents block, whose template is now v4. A plain
-  `npx projectstore-claude upgrade` on a git-marketplace install does more: it
+  0.30, and the startup line names the command until the move is done. Close
+  every Claude Code session in the project, run that command from a terminal in
+  the project, then restart. The command depends on how you installed. From the
+  git marketplace (every 0.27.x install), it is the installed copy's own
+  `bin/projectstore.mjs`, with its path spelled out in the startup line:
+
+  ```
+  node "<plugin cache>/bin/projectstore.mjs" upgrade --harness claude-code --no-register
+  ```
+
+  From npm:
+
+  ```
+  npx projectstore@<version> upgrade --harness claude-code --no-register
+  ```
+
+  `--no-register` leaves your plugin registration as it is: both forms move
+  only the project's files. The same run re-stamps the status-line launcher at
+  its new path and re-registers the agents block, whose template is now v4. An
+  upgrade without `--no-register` on a git-marketplace install does more: it
   also registers the plugin from npm for this checkout and turns the
   git-marketplace copy off here, so `/plugin update` stops reaching the
-  checkout. The 0.28.0-rc.1 and rc.2 startup lines named that shell form
-  (`npx projectstore-claude@<version> upgrade`, without `--no-register`), so on
-  those, update first and run what the new startup line names. If it already
-  happened,
-  `npx projectstore-claude@<version> uninstall --surface plugin --project "$PWD"`
-  (0.28.0 or later) turns the git-marketplace copy back on. That copy must be 0.28 or later — an
-  older one reads a moved project as unbound — so update it first if it is not.
-  Restart, then run
-  `/projectstore:doctor --fix` in the new session, which re-stamps the status
-  line against that copy.
+  checkout. The 0.28.0-rc.1 and rc.2 startup lines named that form, without
+  `--no-register`, so on those, update first and run what the new startup line
+  names. If it already happened, this turns the git-marketplace copy back on
+  (0.28.0 or later), from a terminal in the project:
+
+  ```
+  npx projectstore@<version> uninstall --harness claude-code --surface plugin
+  ```
+
+  That copy must be 0.28 or later — an older one reads a moved project as
+  unbound — so update it first if it is not. Restart, then in the new session,
+  to re-stamp the status line against that copy:
+
+  ```
+  /projectstore:doctor --fix
+  ```
 - **The status line keeps rendering.** A launcher written by an earlier version
   still works, but it carries no file stamp and its embedded fallback root is
   frozen at the old version; the move above re-stamps it. Nothing rewrites that
@@ -242,9 +273,9 @@ bound before 0.28. What an existing project sees afterwards, and why:
   move once more, and the move re-stamps the launcher. If a session already
   re-stamped the status line or re-registered the agents block before the move
   (rc.2's `/projectstore:doctor --fix` did both), 0.27.x reports a foreign
-  status line and a v4 block and leaves both alone — unless you run its
-  `/projectstore:agents register`, which rewrites the block; the status line
-  still renders, and the move settles both.
+  status line and a v4 block and leaves both alone — unless you run
+  `/projectstore:agents register` in it, which rewrites the block; the status
+  line still renders, and the move settles both.
 - **Rolling back** to 0.27.x after the move: 0.27.x looks for its binding under
   `.claude/`, finds none and offers `bind`. Do not accept. A re-bind writes
   `.claude/projectstore.json` again, and 0.28's `install` and `upgrade` refuse
@@ -252,11 +283,11 @@ bound before 0.28. What an existing project sees afterwards, and why:
   `.claude/projectstore.json`, then run the command the startup line names
   once more: a 0.27.x session writes its welcome marker back under `.claude/`.
 - **Installed from npm?** Then `/plugin update` has nothing to fetch: the
-  registration is refreshed by the package itself — from a terminal outside
-  the session, `npx projectstore-claude@<version> upgrade --project "$PWD"`
-  rewrites the local marketplace and runs the host's
-  `plugin update` for this checkout. `/projectstore:doctor` says when the
-  registration is behind the package, and names that command.
+  package itself refreshes the registration. The upgrade at the top of this
+  section, run from a terminal outside the session, rewrites the local
+  marketplace and runs the host's `plugin update` for this checkout.
+  `/projectstore:doctor` says when the registration is behind the package, and
+  names the command.
 
 ## When an agent starts a task, it can find its way
 
@@ -297,7 +328,25 @@ The deep dive — real session files, measured payloads, how every mechanism wor
 
 ## Uninstalling
 
-`/plugin uninstall projectstore@SmartAndPoint` for a Claude git-marketplace install; `npx projectstore-claude uninstall --project "$PWD"` for its npm registration. For Codex, `npx projectstore-codex uninstall --project "$PWD"` removes only project-owned wiring; add `--global` only to remove the user-global Codex plugin and marketplace. Your vault is yours — plain markdown, untouched. One leftover of a host-managed plugin path can be the agents block in `CLAUDE.md`/`AGENTS.md`; remove it with the harness's agents unregister skill, or delete everything between `<!-- projectstore:agents … -->` and `<!-- /projectstore:agents -->` by hand. A one-harness `uninstall` leaves a block that lives in `AGENTS.md`, because that file is read by other coding agents too. Claude Code's then removes the `CLAUDE.md` import when that file holds nothing else; Codex's keeps it, so Claude Code still sees the block. `uninstall --surface agents_block` removes the block as well. A bare core `npx projectstore uninstall --project "$PWD"`, with no `--harness`, covers every harness the project uses — each one whose own directory (`.claude/`, `.codex/`) or `.projectstore/state/<id>/` is there. Once every harness that can read the block's file is among them (for `AGENTS.md`, Claude Code and Codex), the block goes too, and the `CLAUDE.md` import with it unless your own text keeps both files.
+From a terminal in your project:
+
+```
+npx projectstore uninstall
+```
+
+With no `--harness` it covers every agent the project uses — each one whose own directory (`.claude/`, `.codex/`) or `.projectstore/state/<id>/` is there — and removes what install wrote, and only that. For Codex that is the project-owned wiring: its plugin and marketplace are user-global, and removing them for every project is explicit:
+
+```
+npx projectstore uninstall --harness codex --global
+```
+
+A Claude Code install from the git marketplace is removed in the session:
+
+```
+/plugin uninstall projectstore@SmartAndPoint
+```
+
+Your vault is yours — plain markdown, untouched. One leftover of a host-managed plugin path can be the agents block in `CLAUDE.md`/`AGENTS.md`; remove it with the harness's agents unregister skill, or delete everything between `<!-- projectstore:agents … -->` and `<!-- /projectstore:agents -->` by hand. A one-harness `uninstall`, with `--harness <id>`, leaves a block that lives in `AGENTS.md`, because that file is read by other coding agents too. Claude Code's then removes the `CLAUDE.md` import when that file holds nothing else; Codex's keeps it, so Claude Code still sees the block. `uninstall --surface agents_block` removes the block as well. Once every harness that can read the block's file is among those uninstalled (for `AGENTS.md`, Claude Code and Codex), the block goes too, and the `CLAUDE.md` import with it unless your own text keeps both files.
 
 ## Extending
 
@@ -307,6 +356,33 @@ See [`docs/extending.md`](./docs/extending.md) for adding layouts, templates, an
 
 Issues and discussions: https://github.com/SmartAndPoint/ProjectStore/issues. PRs welcome — adding a layout is a good first contribution (see `scaffold/layouts/engineering.json` for the format).
 
+The published package has no dependencies; the linter and the formatter are dev-only, pinned in `package-lock.json`. Every pull request runs the tests, ESLint and Prettier:
+
+```sh
+npm test              # Node 20+, no install needed
+npm ci                # once, for the lint tools (Node 20.19+, 22.13+ or 24+)
+npm run lint
+npm run format        # rewrites; npm run format:check only reports
+```
+
+One formatting-only commit is listed in `.git-blame-ignore-revs`. GitHub skips it in blame by itself; a local clone needs this once:
+
+```sh
+git config blame.ignoreRevsFile .git-blame-ignore-revs
+```
+
+A branch opened before that commit rebases in two steps, so that the lint fixes before it are kept. First onto the commit before it, resolving real conflicts as usual:
+
+```sh
+git rebase <the commit before it>
+```
+
+Then onto the formatting commit itself, where every conflict is formatting only: take your side, format the file with `npx prettier --write <file>` and `git add` it, then continue.
+
+```sh
+git rebase --onto <it> <the commit before it>
+```
+
 ## License
 
 MIT — see [`LICENSE`](./LICENSE).

package/node_modules/projectstore/commands/bind.md

@@ -3,7 +3,7 @@ description: Bind this project to an Obsidian vault (or any markdown directory)
 argument-hint: <vault-path> | --inherit [--layout engineering] [--lang en|ru|es|de|fr|zh]
 ---
 
-You are binding the current project to a markdown vault for projectstore. The config is written by the core's `bind` / `init` verbs (roadmap A8); this interview decides the values, previews them, and asks — it never writes `projectstore.json` itself, except on the inherit path (step 0a), which copies the parent's file verbatim, and the two later stamps in steps 11–12 (`autoupdate_asked`, `statusline`), which `Edit` the file the verb wrote. The interview's `--lang` is the verb's `--language`.
+You are binding the current project to a markdown vault for projectstore. The config is written by the core's `bind` / `init` verbs (roadmap A8); this interview decides the values, previews them, and asks — it never writes `projectstore.json` itself, except on the inherit path (step 0a), which copies the parent's file verbatim, and the one later stamp in step 11 (`statusline`), which `Edit`s the file the verb wrote. The interview's `--lang` is the verb's `--language`.
 
 Parse `$ARGUMENTS`:
 - First positional arg: vault path. Expand `~` if present.
@@ -48,10 +48,10 @@ Steps:
 
    It prints `{state, worktree, mainCheckout, vaultPath}` and writes nothing.
    - `state` is **not** `inheritable` → say why in one line (not a worktree, its parent is unbound too, or git could not answer) and fall through to step 1, which needs a vault path; if none was given, ask for one.
-   - `state` is `inheritable` → read the parent's `<mainCheckout>/.projectstore/projectstore.json` (or, in a checkout not yet migrated, the legacy `<mainCheckout>/.claude/projectstore.json`), show it **verbatim as a code block** — but for a `channel_switch` key, which is left out (below) — and ask via AskUserQuestion: "Adopt the binding of `<mainCheckout>` (vault `<vaultPath>`)?" — Yes / No.
-   - On **Yes**: Write that JSON verbatim, without `channel_switch`, to `<project>/.projectstore/projectstore.json`, **and write `<project>/.projectstore/.gitignore` beside it** with the two lines `projectstore.json` and `state/` under a comment saying they are machine-local (the verb writes them itself on every other path; this one bypasses the verb, and without them the worktree commits an absolute vault path into the index it shares with its parent). If that file already exists, add any missing line and leave the rest — it is line-merged. Then **jump straight to step 10** (the summary). Steps 1–9 and 11–12 are decisions the parent already made and the copied config already carries — layout, language, statusline, agent models, auto-update. Do not re-ask them, and do not scaffold: the vault exists and is shared.
+   - `state` is `inheritable` → read the parent's `<mainCheckout>/.projectstore/projectstore.json` (or, in a checkout not yet migrated, the legacy `<mainCheckout>/.claude/projectstore.json`), show it **verbatim as a code block** — but for the `channel_switch` and `channel_keep` keys, which are left out (below) — and ask via AskUserQuestion: "Adopt the binding of `<mainCheckout>` (vault `<vaultPath>`)?" — Yes / No.
+   - On **Yes**: Write that JSON verbatim, without `channel_switch` and `channel_keep`, to `<project>/.projectstore/projectstore.json`, **and write `<project>/.projectstore/.gitignore` beside it** with the two lines `projectstore.json` and `state/` under a comment saying they are machine-local (the verb writes them itself on every other path; this one bypasses the verb, and without them the worktree commits an absolute vault path into the index it shares with its parent). If that file already exists, add any missing line and leave the rest — it is line-merged. Then **jump straight to step 10** (the summary). Steps 1–9 and 11 are decisions the parent already made and the copied config already carries — layout, language, statusline, agent models. Do not re-ask them, and do not scaffold: the vault exists and is shared.
    - Copy the **binding only** (`projectstore.json`). Never copy `.projectstore/state/` — per-session state belonging to the other checkout — and never `harness/`: the overlays are committed and arrive from git.
-   - **Never copy `channel_switch`.** It records that the parent checkout was switched to the npm install — a machine-local fact of that checkout, not of the binding it shares. Every other key is copied verbatim.
+   - **Never copy `channel_switch` or `channel_keep`.** They record which channel the parent checkout chose — switched to the npm install, or kept on the git marketplace — a machine-local fact of that checkout's own registry rows, not of the binding it shares. Every other key is copied verbatim.
    - Do not add a provenance key to the config. The parent is resolvable from git at any time; a key would be a second source of truth for the same fact.
 
 1. **Validate the vault path** read-only first: `ls -A "<path>"` (the verb has no dry run — running it on a fresh project would write the config before step 4's approval). If it does not exist, or exists and is empty, ask the user (via AskUserQuestion) whether to create the vault there; on Yes, step 5 runs `init` instead of `bind`. `init` creates the whole vault and binds: the directory (unless it is there and empty), its git repository with no commit, and the layout's folders and READMEs. Never `mkdir` it yourself. A directory that already holds files is bound with `bind`; `init` would bind it too, but never scaffolds or `git init`s inside it.
@@ -81,7 +81,7 @@ Steps:
    node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" bind "<vault-path>" [--layout <name>] [--language <code>] [--rebind]
    ```
 
-   `init "<vault-path>" …` instead when step 1 chose to create the vault — it creates the whole vault, so step 7 has nothing to offer after it; `--rebind` only when step 0 ended on **Replace bind**. Naming the vault is the verb's confirmation (there is no `--yes`); the interview's AskUserQuestion in step 4 is the in-session gate. Print the verb's output. A non-zero exit is a refusal or a usage error — relay it and stop — except an `init` whose output reports `git init failed` or `Scaffold failed`: the binding is written, so relay the remedy line it prints and continue. Steps 11 and 12 below `Edit` the file this step wrote; keep them after it.
+   `init "<vault-path>" …` instead when step 1 chose to create the vault — it creates the whole vault, so step 7 has nothing to offer after it; `--rebind` only when step 0 ended on **Replace bind**. Naming the vault is the verb's confirmation (there is no `--yes`); the interview's AskUserQuestion in step 4 is the in-session gate. Print the verb's output. A non-zero exit is a refusal or a usage error — relay it and stop — except an `init` whose output reports `git init failed` or `Scaffold failed`: the binding is written, so relay the remedy line it prints and continue. Step 11 below `Edit`s the file this step wrote; keep it after it.
 
 6. **Check `.gitignore`**: read `<project>/.gitignore` if it exists. Our own files are self-ignored inside `.projectstore/` — the verb writes that `.gitignore` itself, carrying `projectstore.json` and `state/`, with `harness/` committed on purpose (the layout ADR); on the inherit path of step 0a, which bypasses the verb, you wrote both by hand. Unless `.claude/` is ignored wholesale, the one machine-specific entry left is the host's `.claude/settings.local.json`. If it is missing, offer (AskUserQuestion) to append it. If the user declines, skip silently.
 
@@ -115,18 +115,7 @@ Steps:
 
 10. **Print summary**: confirm the bind, list the layout's folders, suggest next commands (`/projectstore:status`, `/projectstore:adr "<first decision>"`, `/projectstore:epic <ID> "<title>"`).
 
-11. **Auto-update reminder** (v0.7+, only on first successful bind in this project): After Step 5 (config write), check whether the newly-written config has `autoupdate_asked: true`. If not, ask the user via AskUserQuestion:
-
-   > "Claude Code does not auto-update third-party marketplaces by default. Want to enable auto-update for the SmartAndPoint marketplace so you'll be notified about future projectstore releases?"
-
-   Options:
-   - **Yes, show me how** (Recommended) — respond with: "Open `/plugin` → **Marketplaces** tab → **SmartAndPoint** → toggle **auto-update** on. New releases (v0.7+) will be detected at Claude Code startup; you'll need to run `/reload-plugins` after the notification to activate them."
-   - **No, I'll handle it manually** — respond with: "OK. To pull the latest version at any time, run `/plugin marketplace update SmartAndPoint`, then `/reload-plugins`."
-   - **Already enabled** — respond with: "Great. New releases will be detected at the next Claude Code startup."
-
-   After the question is answered (regardless of choice), Edit `<project>/.projectstore/projectstore.json` to add `"autoupdate_asked": true` to the JSON object. This guarantees we ask only once per project.
-
-12. **Status line offer** (v0.13, ADR-006 — the final step, language is known by now): read `${CLAUDE_PLUGIN_ROOT}/templates/<lang>/strings.json` (fall back to `en`) and the plugin version, then show the fully rendered example:
+11. **Status line offer** (v0.13, ADR-006 — the final step, language is known by now): read `${CLAUDE_PLUGIN_ROOT}/templates/<lang>/strings.json` (fall back to `en`) and the plugin version, then show the fully rendered example:
 
     > `[PS#<version>] 📚 <statusline_example_epic> › <statusline_example_story> (in-progress)`
 

package/node_modules/projectstore/commands/doctor.md

@@ -66,20 +66,25 @@ You are running projectstore diagnostics (ADR-005: umbrella doctor).
      The verbs refuse it in code; this clause is the belt.
    - `version-drift` → report only: name both versions and where each was
      read; the fix is the host's update path (`/plugin update` for a git-marketplace
-     copy; for the npm registration, the `projectstore-claude` shell's `upgrade`
-     from a terminal — the `plugin-registration` finding spells the command),
+     copy; for the npm registration, the package's `upgrade` from a terminal
+     in the project — the `plugin-registration` finding spells the command),
      not ours.
    - `layout-legacy` (warn; the startup line carries it as an offer) → the project
      still holds the pre-0.28 layout (`.claude/projectstore.json`,
-     `.claude/.projectstore/` — legacy, read through 0.29). The migration is one
+     `.claude/.projectstore/` — legacy, read through 0.30). The migration is one
      previewed `layout` item of `upgrade`, run **from a terminal outside this
      session** (it moves files this session reads and writes; the verb defers
      inside one). The finding names the form for the channel this plugin was
      installed through: the installed copy's own `bin/projectstore.mjs` for a
-     git-marketplace install or a checkout, the `projectstore-claude` shell for
-     the npm registration. Relay the finding's command verbatim and never
-     substitute the other form — the shell, run for a git-marketplace install,
-     would also move this checkout to the npm channel. When the finding carries
+     git-marketplace install or a checkout, the package's `upgrade` for the npm
+     registration. Relay the finding's command verbatim, with the directory its
+     words name, and never substitute the other form or drop its
+     `--no-register`. Both forms carry that flag, so neither changes the
+     channel: the named form runs the copy this project loads, so the move
+     re-stamps the launcher that copy renders, while the other form runs a
+     different copy. The package's `upgrade` without `--no-register` would
+     register the npm copy and turn a git-marketplace copy off for this
+     checkout. When the finding carries
      advice instead of a command — the installed copy predates the move, or
      predates `--no-register` — relay the advice and never compose a command
      yourself. Never move the files yourself. While this finding is in the report, its command is also the one

package/node_modules/projectstore/commands/statusline.md

@@ -5,7 +5,7 @@ argument-hint: "on | off | status"
 
 You are toggling the projectstore status line for THIS project. When enabled, `install-harness.mjs` points the project's `.claude/settings.local.json` at a launcher it writes at `.projectstore/state/claude-code/statusline.mjs`. That path carries no version, so it never goes stale: the launcher resolves the *currently installed* plugin on every render, and an update is reflected on the spot instead of one restart later. (A dev checkout or `--plugin-dir` root is wired straight to its `scripts/statusline.mjs` — those paths have no version to drift.) The line renders `[PS#<version>] 📚 <epic> › <story> (<status>)` **composed above** any existing HUD (e.g. oh-my-claudecode), never replacing it. While this session's band above the prompt is drawing (`/projectstore:bar`), the line gives way to it — your base HUD stays — and it comes back within 30 s of the band stopping.
 
-Resolution is **per-session with zero cross-session and zero vault reads** (ADR-006): the 📚 segment comes from this session's pointer (`.projectstore/state/sessions/<session_id>.json`, maintained by the PreToolUse hook); a fresh session shows an explicit localized cold-start line ("No epic or story in this session yet" / «Эпик и стори ещё не в работе в этой сессии») — never a silent blank; a corrupt pointer shows an error-marked string. Strings localize via `templates/<lang>/strings.json` (en fallback). The version badge is controlled by `statusline.show_version` (default true).
+Resolution is **per-session with zero cross-session and zero vault reads** (ADR-006): the 📚 segment comes from this session's pointer (`.projectstore/state/sessions/<session_id>.json`, maintained by the tool hooks — a write's patch after the write — by `story close`, and at session start; a done, closed or parked story leaves the segment); a fresh session shows an explicit localized cold-start line ("No epic or story in this session yet" / «Эпик и стори ещё не в работе в этой сессии») — never a silent blank; a corrupt pointer shows an error-marked string. Strings localize via `templates/<lang>/strings.json` (en fallback). The version badge is controlled by `statusline.show_version` (default true).
 
 This command flips the flag in `.projectstore/projectstore.json` and then runs the install verb, which writes `settings.local.json` and the launcher behind a preview. The SessionStart hook only refreshes an entry that is already ours and removes it when the flag is off — it never creates one.
 

package/node_modules/projectstore/commands/story.md

@@ -92,11 +92,11 @@ the two cannot collide).
      <baseline-path>`), the derived targets (`kanban`, plus `indexes=<epic
      folder>` when status changed), and the doctor pre-state line. On a clean
      report (`verbatim: true`, `stopped_at: null`, doctor no worse than the
-     pre-state) skip steps 6-6b — the clerk's report is the write evidence. On a
+     pre-state) skip steps 6-6b and run step 6c — the clerk's report is the write evidence. On a
      stopped report: fix what diverged, then re-delegate (the resume rule: after
      the copy, the ceremony restarts at reconcile, not at the race gate) or
      finish the remaining steps yourself (the copy is idempotent).
-   - No clerk available → perform steps 6-6b yourself. There is no fallback
+   - No clerk available → perform steps 6-6c yourself. There is no fallback
      agent: a general-purpose writer is an unpinned procedure.
 
 6. **On Yes** (undelegated path): Write the full file. On a `plan`, finish by
@@ -111,3 +111,16 @@ the two cannot collide).
    — a close is not done while doctor got worse. Then suggest the reviewer's
    proposed `code_refs` via `/projectstore:codemap set` (the reviewer computes it
    from `scripts/diff-refs.mjs --since <started_at>`).
+
+6c. **(close only, both paths) Refresh this session's story**, here in the
+   main thread, after the clerk's clean report or after 6b:
+
+   ```bash
+   node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" session refresh "<story-path>" --json --project "${CLAUDE_PROJECT_DIR}"
+   ```
+
+   `<story-path>` is the absolute `path` the compute script returned in
+   step 2. The copy went through Bash, which no hook sees, so without this the
+   session's band and status line keep naming the closed story. The core finds
+   the session itself; with none it writes nothing and exits 0. A non-zero
+   exit is reported and never undoes the close.

package/node_modules/projectstore/docs/extending.md

@@ -49,12 +49,17 @@ vault-side layout or template override):
 4. **Checklist entry** — `scaffold/checklists.json`, consumed by
    `/projectstore:review` and the `projectstore-peer-reviewer` skill. English-only by design.
 
-5. **Command prompt** — `commands/<kind>.md`, a prompt (not code) that calls
-   `node "${CLAUDE_PLUGIN_ROOT}/scripts/draft.mjs" <kind> "$ARGUMENTS"`, previews,
-   and gates every write behind AskUserQuestion. Copy `commands/research.md`
-   for a plain kind, `commands/adr.md` for one that renders the draft's
-   `collision`/`warnings` fields and updates an index, `commands/spec.md`
-   for one with status transitions.
+5. **Command prompt** — `commands/<kind>.md`, a prompt (not code). It renders
+   the draft with the line below, previews it, and gates every write behind
+   AskUserQuestion:
+
+   ```
+   node "${CLAUDE_PLUGIN_ROOT}/scripts/draft.mjs" <kind> "$ARGUMENTS"
+   ```
+
+   Copy `commands/research.md` for a plain kind, `commands/adr.md` for one
+   that renders the draft's `collision`/`warnings` fields and updates an
+   index, `commands/spec.md` for one with status transitions.
 
 6. **Folder strings** — `templates/<lang>/strings.json` → `folders.<kind>`,
    a `name` and a one-line `description`, in **every** bundled language's