projectstore-claude 0.28.0 → 0.28.1

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.28.0",
+      "version": "0.28.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.28.0",
+  "version": "0.28.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).
+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.
 
 ---
 
@@ -66,6 +66,14 @@ Open Claude Code in your project and say:
 
 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.
 
+**On Codex**, run one command from a terminal in your project:
+
+```
+npx projectstore-codex install --project "$PWD"
+```
+
+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)).
+
 <details>
 <summary>Prefer to type it yourself?</summary>
 
@@ -88,28 +96,26 @@ npx projectstore-claude install --project "$PWD"
 
 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. Every host command is printed before it runs; naming the harness is the confirmation. 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.
 
-**Codex uses its own rendered plugin root and the same one-command shape.**
-Codex support is **experimental** (see [`docs/harnesses.md`](./docs/harnesses.md)
-for what has been measured and what has not), and its shell is not published
-yet. From this checkout, exercise the exact npx path against the built tarball:
+**Codex has its own shell with the same one-command shape:**
+`npx projectstore-codex install --project "$PWD"`. It carries a canonical
+portable 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. 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. 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:
 
 ```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"
 ```
 
-The Codex shell carries a canonical portable 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. Restart Codex, approve the hooks, and run
-`$projectstore-bind <vault-path>`. After the first explicit npm publication,
-the shorter command is
-`npx projectstore-codex@<version> install --project "$PWD"`; use its `upgrade`
-verb for later releases. 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.
-
 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:
 
 ```
@@ -141,7 +147,7 @@ npx projectstore bind ~/vaults/my-project
 npx projectstore init ~/vaults/new-project --language ru
 ```
 
-`projectstore-claude`, `projectstore-codex` and `projectstore-opencode` are this package's per-harness shells — the core pinned and bundled, the harness fixed. Codex's shell is experimental and stays private until a live run has exercised every surface it installs, from an installed release ([`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 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.
 </details>
 
 ## Upgrading

package/node_modules/projectstore/docs/harnesses.md

@@ -23,8 +23,10 @@ and the measurements in the manifest came from that run.
 **experimental** means `verified` is `null`. Every field that was not measured
 is absent or `null` rather than guessed. It is enough to run on; it is not enough
 to promise. An experimental harness is never the source layout. A generated
-adapter may exist while it is experimental, but its distribution shell stays
-private until the complete built artifact passes the live gate.
+adapter may exist while it is experimental. Its distribution shell may
+publish before the live run that sets `verified`, but only by the maintainer's
+decision (Codex's does, from 0.28.1); the label stays experimental until that
+run.
 
 The label is not prose. It is derived from the manifest, and
 `tests/portability.test.mjs` fails if this table and `verified` disagree.
@@ -47,10 +49,10 @@ Experimental, measured on `codex-cli 0.153.4`. The initial spike captured 759
 hook firings. The 2026-09-30 gate then built the npm shell from a packed core,
 passed Codex's plugin validator, installed and upgraded it through an isolated
 `CODEX_HOME`, verified the materialised cache by version and digest, and loaded
-`$projectstore-status` in a fresh Codex session. The validator (the
+the `projectstore-status` skill in a fresh Codex session. The validator (the
 plugin-creator skill's `validate_plugin.py`) reads only
-`.codex-plugin/plugin.json`, so the canonical root `plugin.json` has not been
-validated.
+`.codex-plugin/plugin.json`. The canonical root `plugin.json` was validated
+separately on 2026-10-04, against the schema it declares (Agent Plugins 1.0.0).
 
 That run exercised one skill, not every installed surface, so `verified` stays
 `null`. The hooks are the reason it matters. On 2026-10-03 the first real
@@ -70,23 +72,25 @@ zsh reads `.zshenv` for a `-c` command, not `.zprofile` or `.zshrc`, so a Codex
 not started from a terminal can miss a `node` that only `.zprofile` puts on
 `PATH`.
 
-The shell is not published. Build it and install the tarball through npx from
-this checkout:
+The shell is published as `projectstore-codex` from 0.28.1, ahead of that live
+run, by the maintainer's decision:
+
+```sh
+npx projectstore-codex install --project "$PWD"
+```
+
+For later releases, `npx projectstore-codex@<version> upgrade --project "$PWD"`.
+Installation is user-global because Codex stores marketplace registrations and
+plugin caches in `CODEX_HOME`; the agents block in `AGENTS.md` remains
+project-local. Ordinary uninstall leaves the global plugin in place; add
+`--global` only when you mean to remove it for every project. From this
+checkout, the same flow runs against a built tarball:
 
 ```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"
 ```
 
-The shell package is release-gated until its first npm publication. From this
-repository, the same flow is exercised against the packed tarball. Installation
-is user-global because Codex stores marketplace registrations and plugin caches
-in `CODEX_HOME`; the agents block in `AGENTS.md` remains project-local. After
-the first explicit npm publication, the shorter registry form is
-`npx projectstore-codex@<version> install --project "$PWD"` (or `upgrade`). Ordinary
-uninstall leaves the global plugin in place; add `--global` only when you mean
-to remove it for every project.
-
 What is known, and how:
 
 - **Hooks are rendered; their live firing from an installed release is not

package/node_modules/projectstore/harnesses/codex.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "Harness capability manifest — Codex. The committed adapters/codex tree renders the source commands, roles, passive skills and hooks into Codex vocabulary. Measurements began with 759 captured hook firings on 2026-09-07/08; the complete built shell, isolated marketplace install, upgrade, validator and fresh-session skill load passed on codex-cli 0.153.4 on 2026-09-30. The validator reads only .codex-plugin/plugin.json; the canonical root plugin.json has not been validated.",
+  "_comment": "Harness capability manifest — Codex. The committed adapters/codex tree renders the source commands, roles, passive skills and hooks into Codex vocabulary. Measurements began with 759 captured hook firings on 2026-09-07/08; the complete built shell, isolated marketplace install, upgrade, validator and fresh-session skill load passed on codex-cli 0.153.4 on 2026-09-30. The validator reads only .codex-plugin/plugin.json; the canonical root plugin.json was validated separately on 2026-10-04 against the schema it declares (Agent Plugins 1.0.0).",
   "id": "codex",
   "display_name": "Codex",
   "emit": true,
@@ -7,7 +7,7 @@
   "output_dir": "adapters/codex",
   "docs": "https://developers.openai.com/codex/",
   "verified": null,
-  "verified_reason": "Null, restored 2026-10-03. docs/harnesses.md calls a harness supported only when every installed surface has been exercised end to end, and contract 16 of the generation spec (Generated harness surfaces: manifests, the generator and the three invariants) derives that label from this field. The 2026-09-30 run (session 01a0f079-7ecd-7331-95a9-2471def3cb22) exercised one surface: a fresh `codex exec` session loaded projectstore-status from the materialised cache. The hooks were not exercised, and the first real install showed why that matters. Its cached hooks, run by hand through `zsh -lc` (a form the failure did not depend on: read from source, 0.153.4 runs a hook as `<session shell> -c` with the Codex process's environment, and `$SHELL -lc` only as a fallback), could not load the vault in any session; in the first, the failure sat beneath the welcome. The core had taken the shell's root for its own. That is fixed and pinned by a test that runs every rendered hook from the built shell. This block is set by a live run that exercises every installed surface: the hooks once registration has settled, including PreCompact, and the skill flows.",
+  "verified_reason": "Null, restored 2026-10-03. docs/harnesses.md calls a harness supported only when every installed surface has been exercised end to end, and contract 16 of the generation spec (Generated harness surfaces: manifests, the generator and the three invariants) derives that label from this field. The 2026-09-30 run (session 01a0f079-7ecd-7331-95a9-2471def3cb22) exercised one surface: a fresh `codex exec` session loaded projectstore-status from the materialised cache. The hooks were not exercised, and the first real install showed why that matters. Its cached hooks, run by hand through `zsh -lc` (a form the failure did not depend on: read from source, 0.153.4 runs a hook as `<session shell> -c` with the Codex process's environment, and `$SHELL -lc` only as a fallback), could not load the vault in any session; in the first, the failure sat beneath the welcome. The core had taken the shell's root for its own. That is fixed and pinned by a test that runs every rendered hook from the built shell. This block is set by a live run that exercises every installed surface: the hooks once registration has settled, including PreCompact, and the skill flows. The shell is published from 0.28.1, ahead of that run, by the maintainer's decision of 2026-10-04; publication does not set this block.",
   "runtime": {
     "detect_env": [
       "PLUGIN_ROOT",
@@ -290,7 +290,8 @@
   "rewrites": [],
   "install": {
     "mechanism": "the package's portable plugin root, registered through its distribution shell and Codex's own marketplace CLI",
-    "shell_reason": "The built `projectstore-codex` shell carries the rendered Codex skills and hooks plus an exact bundled core, fixes --harness codex, stages a stable marketplace under CODEX_HOME, and asks Codex itself to install it. The `shell` key is deliberately absent until its first npm publication, so generated guidance cannot send users to the reserved placeholder package.",
+    "shell": "projectstore-codex",
+    "shell_reason": "The built `projectstore-codex` shell carries the rendered Codex skills and hooks plus an exact bundled core, fixes --harness codex, stages a stable marketplace under CODEX_HOME, and asks Codex itself to install it. It is published from 0.28.1, by the maintainer's decision of 2026-10-04. Until then this key was absent, so generated guidance could not send users to the reserved 0.0.1 placeholder; the core alone is not Codex's plugin root and cannot register it.",
     "why_not_scripted": "The shell does not edit Codex's registry or cache. It atomically stages the plugin source, previews the host commands, then runs `codex plugin marketplace add` and `codex plugin add`; a read-back verifies the installed version and payload digest. The global plugin survives ordinary project uninstall; `uninstall --global` is the explicit destructive form.",
     "steps": [
       "npx projectstore-codex install --project \"$PWD\"",

package/node_modules/projectstore/package.json

@@ -1,6 +1,6 @@
 {
   "name": "projectstore",
-  "version": "0.28.0",
+  "version": "0.28.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.",
   "keywords": [
     "project-management",

package/node_modules/projectstore/scripts/install-harness.mjs

@@ -271,14 +271,17 @@ function planAgentsBlock(ctx, key, s) {
 // One host command as a plan step: the verbatim argv (the manifest's
 // subcommand with its placeholders filled), why it runs, and the host-owned
 // files it is known to touch (measured 2026-09-05 — the manifest's cli.verified).
+// A portable registration keeps its marketplace and enablement stanzas in one
+// global config (registry.global_config; Codex's config.toml, measured
+// 2026-09-07), so the preview names that file wherever a step rewrites it.
 function hostStep(a, s, name, fill, why) {
   const template = s.cli.commands[name];
   if (!Array.isArray(template) || !template.length) throw new Error(`${s.format}: host operation ${name} is not declared`);
   const argv = template.map((t) => t.replace(/\{(\w+)\}/g, (_, k) => fill[k] ?? `{${k}}`));
   const p = a.paths;
   const touches = {
-    validate: [], marketplace_add: [p.marketplaces, p.projectSettings], marketplace_update: [p.marketplaces], marketplace_remove: [p.marketplaces, p.projectSettings],
-    install: [p.installed, p.projectSettings, p.cacheDir], update: [p.installed, p.cacheDir], uninstall: [p.installed, p.projectSettings], disable: [p.projectSettings], enable: [p.projectSettings],
+    validate: [], marketplace_add: [p.marketplaces, p.globalConfig, p.projectSettings], marketplace_update: [p.marketplaces], marketplace_remove: [p.marketplaces, p.globalConfig, p.projectSettings],
+    install: [p.installed, p.globalConfig, p.projectSettings, p.cacheDir], update: [p.installed, p.cacheDir], uninstall: [p.installed, p.globalConfig, p.projectSettings], disable: [p.projectSettings], enable: [p.projectSettings],
   }[name] || [];
   return { kind: "host", name, bin: s.cli.bin, argv, why, touches: touches.filter(Boolean) };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "projectstore-claude",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "description": "Installs projectstore for Claude Code from npm: the core pinned and bundled, the harness fixed — npx projectstore-claude install --project \"$PWD\".",
   "keywords": [
     "projectstore",
@@ -37,7 +37,7 @@
     "README.md"
   ],
   "dependencies": {
-    "projectstore": "=0.28.0"
+    "projectstore": "=0.28.1"
   },
   "bundleDependencies": [
     "projectstore"