projectstore-claude 0.28.0 → 0.28.2

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.2",
       "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.2",
   "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 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. 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.
@@ -43,14 +45,15 @@ model names and those are harness-specific — is
 
 ## Codex
 
-Experimental, measured on `codex-cli 0.153.4`. The initial spike captured 759
+Experimental, measured on `codex-cli 0.153.4` and, for hook loading, 0.160.0.
+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`, which from 0.28.2 is the shell's only manifest
+(below).
 
 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
@@ -61,7 +64,8 @@ was all the user saw. The core had taken the shell's root for its own. That is
 fixed, and the suite now runs every rendered hook from the built shell. A live
 Codex session firing them from an installed release is still owed.
 
-How 0.153.4 starts a hook was read from its source, not measured: under the
+How 0.153.4 starts a hook was read from its source; on 0.160.0 it was seen
+once, with the hook's `$0` reading `/bin/zsh` and `node` found. Under the
 session's shell as `<shell> -c`, with the environment the Codex process had when
 it built the session's hooks. `$SHELL -lc` (or `/bin/sh -lc`) is the fallback
 when the hooks are built without exactly one ready local environment. So a hook
@@ -70,35 +74,48 @@ 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
-  yet observed.** The canonical portable `plugin.json` selects
-  `./hooks/hooks.json` through `extensions.com.openai`; the compatibility
-  `.codex-plugin/plugin.json` stays inside the current ingestion schema. Five
+- **Hooks load from Codex's default file, so the shell carries no root
+  `plugin.json`.** `.codex-plugin/plugin.json` is its only manifest and names
+  no hooks, so Codex falls back to `hooks/hooks.json`. 0.28.1, and every
+  build from a checkout since rc.3, also carried a root Agent Plugins
+  `plugin.json`, with the hooks under `extensions.com.openai`. Codex picks
+  that manifest first, and since openai/codex#37027 (merged 2026-08-05; in
+  `codex-cli` 0.153.4 and 0.160.0 alike) it loads no hooks from that format.
+  So no hook of ours loaded from those builds on any Codex measured here
+  (0.153.4, 0.160.0). On the maintainer's machine
+  on 2026-10-04, `/hooks` listed none of ours; with that file renamed away in
+  the installed cache, it listed all six, and the app server's `hooks/list`
+  gives 0 for 0.28.1's root and 6 for 0.28.2's. Five
   events: `SessionStart`, `PreToolUse`, `PostToolUse`, `Stop`, `PreCompact`.
   Of the 759 captured firings, 757 came from the earlier inline form, across
   `SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse` and `Stop`,
   and 2 from a file-site `hooks/hooks.json` with an absolute `node` path.
-  `PreCompact` has never been observed firing on Codex, and neither has the
-  `${PLUGIN_ROOT}` form selected through `extensions.com.openai`. The hook process
+  That live `codex-cli` 0.160.0 session ran on a hand-edited 0.28.1 cache, not
+  an installed release. Our SessionStart and PreCompact were observed in it. A
+  throwaway recorder saw PreToolUse, PostToolUse and Stop fire, but ours on
+  PostToolUse, matched to `apply_patch`, still awaits a write. SessionStart ran
+  on the session's first message, not when the window opened. The hook process
   receives `PLUGIN_ROOT` in its environment, naming the shell's root with the
   core beneath it in `node_modules/projectstore/`, and **no project-directory
   variable at all**. The project comes from the payload's `cwd`, which every

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, which from 0.28.2 is the shell's one manifest: Codex picks a root Agent Plugins plugin.json first and has loaded no hooks from that format since openai/codex#37027 (merged 2026-08-05).",
   "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",
@@ -54,7 +54,7 @@
   },
   "hooks": {
     "config_file": "hooks/hooks.json",
-    "config_file_reason": "The canonical portable plugin.json selects ./hooks/hooks.json under extensions.com.openai; the compatibility manifest selects the same root-relative file. This keeps one rendered hook definition for both loaders. The legacy inline form fired 757 events across five event types; the file-selected portable form is gated by the compatibility matrix and fresh-session run.",
+    "config_file_reason": "Codex's default hooks file. A legacy .codex-plugin/plugin.json with no `hooks` key falls back to hooks/hooks.json (DEFAULT_HOOKS_CONFIG_FILE in codex-rs/core-plugins/src/loader.rs at rust-v0.160.0), so the manifest names no hooks at all. The shell ships no root Agent Plugins plugin.json. Codex picks that manifest first and then loads no hooks from it, a runtime boundary since openai/codex#37027 (loader.rs:955 at rust-v0.153.4, 952-962 at rust-v0.160.0). With one, the maintainer's codex-cli 0.160.0 listed none of ours in /hooks on 2026-10-04; with the file renamed away in the installed cache, it listed all six. The app-server's hooks/list agrees: 0 for 0.28.1's root, 6 for 0.28.2's. The spike's inline form fired 757 events across five event types.",
     "events": {
       "SessionStart": "SessionStart",
       "PreToolUse": "PreToolUse",
@@ -192,7 +192,7 @@
       "supported": true,
       "kind": "host",
       "scope": "user",
-      "scope_reason": "Selected by canonical plugin.json and the compatibility manifest, then loaded with the plugin; trust is granted per hook, machine-wide, and cannot be silenced per checkout."
+      "scope_reason": "Loaded with the plugin from its default hooks/hooks.json, which .codex-plugin/plugin.json leaves to Codex by naming no hooks; trust is granted per hook, machine-wide, and cannot be silenced per checkout."
     },
     "mcp": {
       "supported": false,
@@ -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.2",
   "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/node_modules/projectstore/scripts/version-guard.mjs

@@ -68,10 +68,16 @@ export function collectShells(root = ROOT) {
     if (typeof json.version !== "string" || !json.version) return { error: `${rel}: no version found where one is required` };
     const pluginVersions = [];
     if (name === "projectstore-codex") {
-      for (const manifest of ["plugin.json", ".codex-plugin/plugin.json"]) {
+      // A root plugin.json is an Agent Plugins manifest Codex picks first, and
+      // Codex loads no hooks from that format (openai/codex#37027, merged
+      // 2026-08-05): every hook goes missing.
+      if (existsSync(resolve(root, SHELLS_DIR, name, "plugin.json"))) {
+        return { error: `${SHELLS_DIR}/${name}/plugin.json: refused — Codex picks a root Agent Plugins manifest first and loads no hooks from it (openai/codex#37027; codex-rs/core-plugins/src/loader.rs); the shell's manifest is .codex-plugin/plugin.json alone` };
+      }
+      for (const manifest of [".codex-plugin/plugin.json"]) {
         const manifestRel = `${SHELLS_DIR}/${name}/${manifest}`;
         const manifestAbs = resolve(root, manifestRel);
-        if (!existsSync(manifestAbs)) return { error: `${manifestRel}: missing — the Codex shell carries both canonical and compatibility manifests` };
+        if (!existsSync(manifestAbs)) return { error: `${manifestRel}: missing — the Codex shell's one manifest` };
         let parsed;
         try { parsed = JSON.parse(readFileSync(manifestAbs, "utf8")); } catch (e) { return { error: `${manifestRel}: ${e.message}` }; }
         if (typeof parsed.version !== "string" || !parsed.version) return { error: `${manifestRel}: no version found where one is required` };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "projectstore-claude",
-  "version": "0.28.0",
+  "version": "0.28.2",
   "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.2"
   },
   "bundleDependencies": [
     "projectstore"