projectstore-claude 0.29.4 → 0.30.1

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(["setup","plan","install","uninstall","upgrade","agents"]);
+const HARNESS_VERBS = new Set(["setup","configure","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.4",
+      "version": "0.30.1",
       "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.4",
+  "version": "0.30.1",
   "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,64 @@ 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:
+**What it needs:**
+
+- Node.js 20 or later, always. The plugin's hooks, its MCP server and the status line run as `node` inside the agent session.
+- npm, for Codex only: setup fetches the Codex plugin through npm. Claude Code alone needs no npm.
+- The agent's own CLI on PATH (`claude`, `codex`), and git for a new vault.
+- A terminal outside every Claude Code and Codex session: inside one, the registration waits and the plan says so.
+- macOS or Linux. Windows is not verified yet.
+
+Other package runners start setup the same way. Each was observed running it with Claude Code and Codex:
 
 ```
-npx projectstore-codex install --project "$PWD"
+bunx projectstore@latest 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)).
+```
+pnpm dlx projectstore@latest setup
+```
 
-<details>
-<summary>Prefer to type it yourself?</summary>
+```
+deno run -A npm:projectstore@latest setup
+```
+
+`pnpm dlx` needs pnpm 6.13 or later. Without npm on PATH, a runner sets up Claude Code and refuses Codex, naming npm. The runner only fetches the package: setup copies the plugin into the agents' own directories, so clearing the runner's cache later breaks nothing.
+
+`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:
+
+```
+npm install -g projectstore
+projectstore setup
+```
+
+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:
+
+```
+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 +143,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 +197,107 @@ 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>
 
+## Configure
+
+Setup asks only what a first install needs. Everything after it is one command, from a terminal in your project:
+
+```
+npx projectstore configure
+```
+
+At a terminal it shows every setting with its current value and where it lives:
+
+- each agent's model, per harness;
+- the status line and the band above the prompt (Claude Code);
+- the vault's template language, the default author and tags;
+- the vault's spec policy and lifecycle gates.
+
+It asks which to change, then shows one plan and asks once. Without a terminal it prints the same view and writes nothing. To change a setting there, name it with `--set`; naming it is the confirmation:
+
+```
+npx projectstore configure --set agents.critic=fable --set statusline=on
+```
+
+`--dry-run` shows the plan and writes nothing, and `--json` returns the settings as one envelope. In a project that uses two harnesses, an agent's model names its overlay with `--harness <id>`.
+
+Each setting has exactly one writer, and the plan says which file it changes:
+
+- **The agents' models** live in `.projectstore/harness/<harness>.json`. That file is committed, so a change there is a team change.
+- **The status line, the band, the language and the other binding keys** live in `.projectstore/projectstore.json`, which stays on this machine.
+- **The spec policy and the lifecycle gates** live in the vault's `.projectstore.json`, which commits with the vault. Setting `spec_policy=required` records when it took effect; stories closed before then are exempt.
+
+The vault itself is changed by `bind --rebind`, which configure names when asked. In a Claude Code session, `/projectstore:statusline` and `/projectstore:agents configure` run the same writers.
+
 ## 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 +328,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 +338,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 +383,62 @@ 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
+```
+
+**What a removal keeps:**
+
+- the vault;
+- the binding `.projectstore/projectstore.json`, with the status-line choice, so a later setup wires the line again;
+- the agents' models in `.projectstore/harness/`, which is committed team configuration;
+- Codex's user-wide registration, until `--global` removes it.
+
+`--global` removes the Codex plugin for every other project on this machine too. Their `AGENTS.md` blocks stay and name agents that no longer load: uninstall Codex in each of them as well, or set them up again.
+
+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.
+
+### Reinstalling clean
+
+Keeping the vault and the binding, uninstall and set up again. The second setup finds both:
+
+```
+npx projectstore uninstall
+```
+
+```
+npx projectstore setup
+```
+
+To start as if the project was never bound, remove only the machine-local half after the uninstall. `.projectstore/harness/` and `.projectstore/.gitignore` are committed; keep them. The binding also carries the template language, the default author and tags, the skills switch, the band and the status-line choice, and removing it drops them. Setup then asks for the vault again.
+
+```
+rm -f .projectstore/projectstore.json
+```
+
+```
+rm -rf .projectstore/state
+```
+
+To point the project at another vault, no reinstall is needed. From a terminal in your project:
+
+```
+npx projectstore bind ~/vaults/other --rebind
+```
 
 ## Extending
 
@@ -322,7 +463,17 @@ One formatting-only commit is listed in `.git-blame-ignore-revs`. GitHub skips i
 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: `git rebase <the commit before it>` (real conflicts, resolved as usual), then `git rebase --onto <it> <the commit before it>`, where every conflict is formatting only: take your side, run `npx prettier --write <file>`, `git add` it and continue.
+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
 

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 one later stamp in step 11 (`statusline`), which `Edit`s 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. The settings later steps change — the vault policy (step 7.5) and the status line (step 11) — go through `configure --set`, each key's one writer. The interview's `--lang` is the verb's `--language`.
 
 Parse `$ARGUMENTS`:
 - First positional arg: vault path. Expand `~` if present.
@@ -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. Step 11 below `Edit`s the file this step wrote; keep it 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.
 
 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.
 
@@ -97,7 +97,7 @@ Steps:
    - If it already exists with a `spec_policy` key — respect it, print the current policy, do not re-ask.
    - **New bind into a vault with no artifacts** (a vault `init` just made counts: its folders and README indexes are not artifacts): ask via AskUserQuestion — "Enable spec-first policy for this vault (every story must be covered by a spec; doctor enforces it)?" with options **Yes, `spec_policy: required` (Recommended)** / **Not yet, `optional`**. Second question: "Enable lifecycle gates (plan/close sections + evidence checks on stories)?" — **Yes, `lifecycle_gates: on` (Recommended)** / **Off for now**.
    - **Bind to an existing vault with artifacts**: default to `spec_policy: optional`, `lifecycle_gates: off` and say doctor will suggest enabling once specs appear. Do not impose the gate on an existing backlog.
-   - On any choice, write `<vault>/.projectstore.json` (vault ROOT — deliberately not inside `<vault>/.projectstore/`, whose .gitignore would keep the policy out of git):
+   - On any choice, run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set spec_policy=<required|optional> --set lifecycle_gates=<on|off> --dry-run --project "${CLAUDE_PROJECT_DIR}"` and show its PLAN, then ask via AskUserQuestion: "Record this policy in the vault? [Yes / No]". On **Yes**, run the same command without `--dry-run`; a non-zero exit is a refusal — relay it and go on to step 8 (the binding is already written). It writes `<vault>/.projectstore.json` — vault ROOT, deliberately not inside `<vault>/.projectstore/`, whose .gitignore would keep the policy out of git — and keeps any other key in it:
 
    ```json
    {
@@ -107,7 +107,7 @@ Steps:
    }
    ```
 
-   `spec_policy_since` is stamped ONLY when spec_policy is set to `required` — it anchors the legacy exemption (stories done before it stay exempt; stories in progress/review at enable time are in scope).
+   configure stamps `spec_policy_since` whenever spec_policy becomes `required` — it anchors the legacy exemption (stories done before it stay exempt; stories in progress/review at enable time are in scope).
 
 8. **Agent registration** (v0.13, ADR-002): ask via AskUserQuestion — "Register projectstore's agents in CLAUDE.md/AGENTS.md so every session routes to them (critic after authoring artifacts, planner before implementing, reviewer before commit)? [Yes (Recommended) / No]". On Yes, run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" install --harness claude-code --surface agents_block --project "${CLAUDE_PROJECT_DIR}"` and print its output (it renders from the layout's roster, migrates rather than duplicates, previews every write, and applies because the harness is named). On a rebind where a block already exists the verb reports it current or replaces it in place — do not re-ask blindly.
 
@@ -121,4 +121,4 @@ Steps:
 
     (for `ru`: `[PS#<version>] 📚 Супер-фича в супер-продукте › Ручка для туалетной бумаги (in-progress)`; every bundled language ships its own example pair)
 
-    Ask via AskUserQuestion: "Show your current epic/story in the status line, composed above any existing HUD? [Yes / No]". On Yes: Edit `projectstore.json` → `"statusline": { "enabled": true }` (approval-gated), then run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" install --harness claude-code --surface statusline --project "${CLAUDE_PROJECT_DIR}"` and print its output (it writes the `settings.local.json` entry and the launcher, previewed), and report: "Enabled — restart Claude Code in this project to apply. A fresh session shows: `[PS#<version>] 📚 <statusline_no_work>`."
+    First run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set statusline=on --dry-run --project "${CLAUDE_PROJECT_DIR}"` and show its PLAN; a non-zero exit is a refusal (a foreign status line, an unparseable settings file) — relay it and skip this step. Then ask via AskUserQuestion: "Show your current epic/story in the status line, composed above any existing HUD? [Yes / No]". On Yes, run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set statusline=on --project "${CLAUDE_PROJECT_DIR}"` and print its output — a non-zero exit is a refusal to relay (it records `statusline.enabled: true` and writes the `settings.local.json` entry and the launcher, in one plan), and report: "Enabled — restart Claude Code in this project to apply. A fresh session shows: `[PS#<version>] 📚 <statusline_no_work>`."

package/node_modules/projectstore/commands/statusline.md

@@ -1,5 +1,5 @@
 ---
-description: Enable/disable the projectstore status line (current epic & story in the HUD). Flips a flag and runs the install verb, which wires it behind a preview; the SessionStart hook keeps an existing entry current across plugin updates.
+description: Enable/disable the projectstore status line (current epic & story in the HUD). Runs `configure --set statusline=on|off`, which records the flag and wires or removes the entry behind a preview; the SessionStart hook keeps an existing entry current across plugin updates.
 argument-hint: "on | off | status"
 ---
 
@@ -7,7 +7,7 @@ You are toggling the projectstore status line for THIS project. When enabled, `i
 
 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.
+This command runs `configure --set statusline=on|off` (the configure spec, contracts 6 and 9): install's own items record `statusline.enabled` and write or remove the `settings.local.json` entry and the launcher, in one plan. The command never writes `projectstore.json` itself. The SessionStart hook only refreshes an entry that is already ours and removes it when the flag is off — it never creates one.
 
 ## 1. Require a bound project
 
@@ -21,15 +21,15 @@ Read `.projectstore/projectstore.json`. If missing → "No vault bound. Run `/pr
 
 ## 3. `on`
 
-1. **Foreign status line check** (read-only): read `.claude/settings.local.json` if present. If it has a `statusLine` whose `command` is **not** ours (ours contains either `.projectstore/state/<harness>/statusline.mjs` — the launcher; a not-yet-migrated project's legacy launcher is `.claude/.projectstore/statusline.mjs`, also ours — or `scripts/statusline.mjs` — an older or dev wiring), warn — the hook will **not** clobber a foreign local status line, so enabling would silently do nothing (and `statusline.mjs` composes only over a base in `.claude/settings.json` or `~/.claude/settings.json`, never one in `settings.local.json`). AskUserQuestion: **Proceed anyway / Help me clear it / Cancel**. If a base HUD lives in `~/.claude/settings.json` (e.g. oh-my-claudecode), that's fine — we compose over it; no warning needed.
-2. **AskUserQuestion** (Yes / No): "Wire the status line for this project?" On Yes, run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" install --harness claude-code --surface statusline --project "${CLAUDE_PROJECT_DIR}"` and print its output verbatim — it previews and writes the `statusLine` entry and the launcher (`.projectstore/state/claude-code/statusline.mjs`, provenance-stamped). A non-zero exit is a refusal (a foreign status line, an unparseable settings file) — relay it and stop, leaving the flag as it was.
-3. On success, read `.projectstore/projectstore.json`, set `statusline.enabled = true`. **Preserve `statusline.position`** if present (don't drop it); keep all other keys. Preview the change, then Write.
+1. **Foreign status line check** (read-only): read `.claude/settings.local.json` if present. If it has a `statusLine` whose `command` is **not** ours (ours contains either `.projectstore/state/<harness>/statusline.mjs` — the launcher; a not-yet-migrated project's legacy launcher is `.claude/.projectstore/statusline.mjs`, also ours — or `scripts/statusline.mjs` — an older or dev wiring), warn — configure refuses to enable over a foreign local status line (and `statusline.mjs` composes only over a base in `.claude/settings.json` or `~/.claude/settings.json`, never one in `settings.local.json`). AskUserQuestion: **Help me clear it / Cancel**. If a base HUD lives in `~/.claude/settings.json` (e.g. oh-my-claudecode), that's fine — we compose over it; no warning needed.
+2. **Preview**: run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set statusline=on --dry-run --project "${CLAUDE_PROJECT_DIR}"` and print its PLAN. A non-zero exit is a refusal — relay it and stop; nothing is asked or written.
+3. **AskUserQuestion** (Yes / No): "Wire the status line for this project?" On Yes, run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set statusline=on --project "${CLAUDE_PROJECT_DIR}"` and print its output verbatim — it records `statusline.enabled: true` (keeping `statusline.position` and every other key) and writes the `statusLine` entry and the launcher (`.projectstore/state/claude-code/statusline.mjs`, provenance-stamped), in one plan. A non-zero exit is a refusal (a foreign status line, an unparseable settings file, a layout still to move) — relay it and stop; nothing was written.
 4. Report: "Enabled. `📚 <epic> › <story>` renders above your existing HUD. **Restart Claude Code in this project** to apply now (statusLine loads at session start). If `.claude/settings.local.json` is tracked in git, add it to `.gitignore` — the entry carries a machine-specific absolute path."
 
 ## 4. `off`
 
-1. **AskUserQuestion** (Yes / No): "Remove the projectstore status line from this project?" On Yes, read `.projectstore/projectstore.json` and set `statusline.enabled = false` (keep `statusline.position` + other keys) — write it **even if the flag was absent**, so the hook removes any managed `statusLine` entry it previously wrote. Preview, then Write.
-2. Run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" uninstall --harness claude-code --surface statusline --project "${CLAUDE_PROJECT_DIR}"` and print its output — it removes our `statusLine` entry and the launcher, previewed, and leaves a foreign entry alone.
+1. **Preview**: run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set statusline=off --dry-run --project "${CLAUDE_PROJECT_DIR}"` and print its PLAN. A non-zero exit is a refusal — relay it and stop.
+2. **AskUserQuestion** (Yes / No): "Remove the projectstore status line from this project?" On Yes, run `node "${CLAUDE_PLUGIN_ROOT}/bin/projectstore.mjs" configure --set statusline=off --project "${CLAUDE_PROJECT_DIR}"` and print its output — it records `statusline.enabled: false` (even if the flag was absent, so the hook keeps it off) and removes our `statusLine` entry and the launcher, and leaves a foreign entry alone.
 3. Report: "Disabled; restart to apply."
 
 ## 5. `status`
@@ -42,5 +42,5 @@ Report, read-only:
 ## Notes
 
 - Every write goes through AskUserQuestion. Never write without approval.
-- The command writes `.projectstore/projectstore.json` and runs the install verb for the `statusline` surface; the SessionStart hook only refreshes an entry that is already ours (and removes it when the flag is off) — it never creates one, and never touches a foreign status line.
+- The command runs `configure --set statusline=on|off`, whose install items are the flag's one writer; the SessionStart hook only refreshes an entry that is already ours (and removes it when the flag is off) — it never creates one, and never touches a foreign status line.
 - Config shape: `.projectstore/projectstore.json` → `"statusline": { "enabled": true, "position": "above", "show_version": true }`. `position` is `above` (default) or `below` — the side our 📚 line sits relative to the base HUD; `show_version` toggles the `[PS#…]` badge.