@alan512/experienceengine 0.1.2 → 0.1.3

package/docs/user-guide.md

@@ -11,6 +11,19 @@ In practice, this means:
 - noisy or harmful prior patterns can be cooled or retired
 - the system gradually learns which guidance is actually useful
 
+It also means ExperienceEngine separates:
+
+- `task history`
+  - broad runtime records of what happened
+- `reusable experience`
+  - only the subset of tasks that produced transferable decision guidance
+
+So a task can be recorded without being promoted into learning.
+
+For a focused explanation of what ExperienceEngine stores and how an experience node is governed, see:
+
+- [docs/development/experience-model.md](development/experience-model.md)
+
 For a practical end-to-end workflow on a real repository, see:
 
 - [docs/development/real-repo-playbook.md](development/real-repo-playbook.md)
@@ -48,6 +61,24 @@ When it injects guidance, you will usually see a lightweight notice like:
 
 If there is no intervention, it stays silent.
 
+When ExperienceEngine is less certain but still sees a credible same-family match, it may choose a conservative injection instead of skipping entirely. In that case the injected block stays smaller by default, but mature low-risk nodes can still include a short `Goal / Steps / Avoid` structure when that makes the guidance more actionable.
+
+When you inspect the latest turn, you may also see a learning decision such as:
+
+```text
+Learning status: captured
+Learning reason: provider routing debugging exposed a reusable configuration pattern
+```
+
+or:
+
+```text
+Learning status: rejected
+Learning reason: task stayed in expression-layer refinement: wording, copy, or presentation changes are recorded but not learned
+```
+
+This is intentional. ExperienceEngine now records broad task history, but it only promotes tasks with transferable decision value into the reusable experience pool.
+
 When the host surfaces task-finalization metadata, ExperienceEngine can also show a lightweight feedback reminder after an injected turn so the user can quickly mark whether the hint helped or harmed.
 
 You can also turn inline notices off:
@@ -58,63 +89,187 @@ ee config set notices.inline false
 
 ## Install And First Run
 
-ExperienceEngine installation is now host-native.
+ExperienceEngine installation now starts from the host you want to use.
 
 That means the first installation step belongs to the host you want to use, not to the `ee` CLI.
 
-Install ExperienceEngine through the host-specific flow for:
+Install ExperienceEngine through the host setup flow for:
 
 - `OpenClaw`
-  - planned one-step command:
+  - host-native plugin install:
     - `openclaw plugins install @alan512/experienceengine`
-  - current status:
-    - blocked until the public npm package `@alan512/experienceengine` is published
+  - after installing, restart the gateway before the first real task:
+    - `openclaw gateway restart`
 - `Codex`
-  - planned one-step command:
+  - EE-managed Codex setup:
+    - `ee install codex`
+  - native/manual fallback:
     - `codex mcp add experienceengine --env EXPERIENCE_ENGINE_HOME=$HOME/.experienceengine -- npx -y @alan512/experienceengine codex-mcp-server`
-  - current status:
-    - blocked until the public npm package `@alan512/experienceengine` is published
+  - after either path, start a new Codex session in this repo so the MCP wiring and `AGENTS.md` instruction block are picked up
 - `Claude Code`
-  - add the bundled marketplace from GitHub:
+  - host-native marketplace install:
+    - add the bundled marketplace from GitHub:
     - `/plugin marketplace add https://github.com/Alan-512/ExperienceEngine.git`
   - install the bundled plugin:
     - `/plugin install experienceengine@experienceengine`
   - `ee install claude-code` remains the explicit operator fallback when you need direct hooks + MCP wiring outside the marketplace flow
+  - after installation, start a new Claude Code session so the plugin hooks and bundled MCP config are loaded
+
+Across all three hosts, the intended product journey is the same:
 
-Then use the `ee` CLI for validation and operations:
+1. install ExperienceEngine through the host-specific setup path
+2. initialize shared ExperienceEngine state with `ee init`
+3. restart or open a fresh host session until the repo is `Ready`
+4. keep routine review and feedback inside the host agent when the host supports it cleanly
+5. use `ee` as the operator fallback for validation, repair, and deeper inspection
+
+The host-specific differences are real, but they sit underneath one shared model:
+
+- installation mechanics differ by host
+- routine interaction should feel similar wherever the host supports it
+- CLI remains the explicit fallback and operator surface
+
+Then continue using your host agent normally.
+
+For most users, ExperienceEngine should stay in the background and be inspected through the host agent itself. Typical prompts are:
+
+- "What did ExperienceEngine just inject?"
+- "Why did that ExperienceEngine hint match?"
+- "Mark the last ExperienceEngine intervention as helpful or harmful."
+
+OpenClaw also supports these additional phase-2 routine questions in-session:
+
+- "Is ExperienceEngine ready here?"
+- "Is ExperienceEngine still warming up in this repo?"
+- "Why didn't ExperienceEngine inject anything just now?"
+
+For `OpenClaw`, `Codex`, and `Claude Code`, these routine follow-ups should stay in the host session first.
+
+Use the `ee` CLI only when you need explicit validation, repair, or operator-style troubleshooting:
 
 ```bash
+ee init
 ee doctor <openclaw|claude-code|codex>
 ee status
 ```
 
+Use `ee init` once to initialize ExperienceEngine's shared distillation, embedding, and secret state. New host installations should reuse that same shared EE state instead of asking you to re-enter the same API key per host window.
+
+In practical terms, the routine loop currently looks like this:
+
+- `Codex`
+  - ask the host agent first for recent injections, matching reasons, and helped / harmed feedback
+- `Claude Code`
+  - ask the host agent first for recent injections, matching reasons, and helped / harmed feedback
+- `OpenClaw`
+  - ask the host agent first for recent injections, matching reasons, readiness, warm-up progress, recent silence, and helped / harmed feedback
+  - keep CLI/operator fallback for deeper inspection, repair, and advanced management
+
+For onboarding and first value, ExperienceEngine now uses a two-layer product model:
+
+- `Setup state`
+  - `Installed`
+  - `Initialized`
+  - `Ready`
+- `Value state`
+  - `Warming up`
+  - `First value reached`
+
+These are not one linear state machine.
+
+Examples:
+
+- a repo can already be `Ready` while still `Warming up`
+- a repo can be `Ready` and already have reached first value
+
+In practice:
+
+- installation into a host gets you to `Installed`
+- `ee init` moves the shared product state toward `Initialized`
+- a restart or new host session usually completes `Ready`
+- real task activity moves the value layer from `Warming up` toward `First value reached`
+
+`First value reached` must be tied to visible output from real work, such as:
+
+- a visible real task record
+- a visible learning decision
+- a visible intervention
+
+These do **not** count by themselves:
+
+- a static onboarding message
+- a generic warm-up explanation
+- a recommendation not tied to a real observed task run
+
 You do **not** need to clone the repository or run `pnpm build` for normal user installation.
 
 ### Operational CLI
 
-After a host-native installation succeeds, `ee` becomes the shared operational surface.
+After the host setup succeeds, the host agent remains the primary interaction surface.
 
-Use it for:
+Use `ee` for:
 
+- one-time shared initialization after the first host setup
 - installation validation
 - repair guidance
 - runtime status checks
 - learning and intervention inspection
 - quick helped / harmed feedback
 
+`ee status` and `ee doctor` now also summarize recent retrieval health in product language. They still show the raw counters, but they additionally explain whether ExperienceEngine is mostly injecting, mostly staying conservative, or still skipping too many close-match tasks in the current repo.
+
+Their roles are intentionally different:
+
+- `ee status`
+  - daily progress view
+  - current setup/value state
+  - next practical step
+- `ee doctor <host>`
+  - explicit validation and troubleshooting
+  - install and wiring verification
+  - repair-oriented next steps
+
+The most useful inspection command during product debugging is still:
+
+```bash
+ee inspect --last
+```
+
+That output now tells you both:
+
+- what was injected
+- whether the finalized task was learned, rejected from learning, or only kept as runtime history
+- whether the intervention was a normal injection or a conservative one
+- why ExperienceEngine acted that way in plain language instead of only raw gate fields
+- how trustworthy the selected guidance currently is
+
+When you inspect a specific node, ExperienceEngine now also shows a lightweight quality judgment layer:
+
+- a `quality band` (`strong`, `building`, or `risky`)
+- the short drivers behind that judgment
+- a compact applicability profile covering best fit, scope validity, confidence, risk, and when to avoid reuse
+
 ## How MCP Interaction Works
 
 For `Codex` and `Claude Code`, ExperienceEngine is designed to work mainly through MCP.
 
 That means after installation, you usually do not leave the agent session to manage ExperienceEngine. Instead, you ask the agent naturally and the agent can call ExperienceEngine MCP resources, prompts, and tools for you.
 
+This is one host-specific implementation of the same shared product model described above:
+
+- host-native install or wiring gets the repo to `Installed`
+- shared `ee init` state gets the product to `Initialized`
+- a fresh host session gets the repo to `Ready`
+- routine inspection and feedback stay inside the host when the host supports them cleanly
+- CLI remains the explicit fallback and operator path
+
 Typical examples:
 - "What did ExperienceEngine just inject?"
+- "Why did that ExperienceEngine hint match?"
 - "Show the recent injected turns."
 - "List active warning nodes."
 - "Pause ExperienceEngine for this project."
-- "Mark the last ExperienceEngine intervention as harmful."
-- "Record quick feedback for the last ExperienceEngine intervention."
+- "Mark the last ExperienceEngine intervention as helpful or harmful."
 - "Create a backup of ExperienceEngine state."
 - "Rollback ExperienceEngine to backup `<id>`."
 
@@ -155,104 +310,17 @@ Today, ExperienceEngine's minimal governance surface is:
 
 A dedicated standalone review UI is still deferred. The current product shape is intentionally CLI/MCP-first rather than UI-first.
 
-## Experience Pack v1
-
-Experience Pack v1 is a **local shared-directory registry** for reusable experience assets.
-
-It lets you take a group of already-validated nodes and move them through a minimal lifecycle:
-
-```text
-draft -> review -> publish -> rollback
-```
-
-Pack v1 is intentionally local-first:
-
-- packs live under `~/.experienceengine/packs`
-- packs are host-agnostic assets, not host-specific config fragments
-- multiple local repos can reuse the same published pack
-- there is no team sync, remote distribution, or UI workflow in v1
-
-Current CLI surface:
-
-```bash
-ee pack list
-ee pack inspect <pack-id>
-ee pack status <pack-id> [version] [agents|codex|github|claude] [repo-path]
-ee pack draft create <pack-id> <node-id[,node-id...]> [name...]
-ee pack review <pack-id> <description...>
-ee pack publish <pack-id>
-ee pack compile <pack-id> [version]
-ee pack compile <pack-id> [version] codex
-ee pack compile <pack-id> [version] github
-ee pack compile <pack-id> [version] claude
-ee pack deploy <pack-id> [version] [agents|codex|github|claude] [repo-path] [--dry-run] [--force] [--status-only]
-ee pack rollback <pack-id> <version>
-```
-
-Use this when you want to turn a set of proven nodes into a managed local asset instead of leaving them only in SQLite state.
-
-### Compiler v1
-
-Compiler v1 turns a published or rolled-back Experience Pack into host-friendly static artifacts.
-
-It is intentionally conservative:
-
-- it only reads Pack files that already exist in the local registry
-- it only exports a static artifact
-- it does **not** auto-write into your repo root
-
-Example:
-
-```bash
-ee pack compile auth-debug-pack
-ee pack compile auth-debug-pack codex
-ee pack compile auth-debug-pack github
-ee pack compile auth-debug-pack claude
-ee pack deploy auth-debug-pack agents /path/to/repo --dry-run
-ee pack deploy auth-debug-pack codex /path/to/repo
-ee pack deploy github-pack github /path/to/repo --force
-ee pack deploy auth-debug-pack claude /path/to/repo
-ee pack deploy auth-debug-pack agents /path/to/repo --status-only
-ee pack status auth-debug-pack agents /path/to/repo
-```
-
-Default output location:
-
-```text
-~/.experienceengine/packs/<pack-id>/compiled/<target>/<version>/
-```
-
-Artifacts produced:
-
-- `AGENTS.md` for `agents` target
-- `CODEX.md` for `codex` target
-- `CLAUDE.md` for `claude` target
-- `<pack-id>.agent.md` for `github` target
-- `compile-report.json`
-
-Deploying compiled artifacts:
-
-- `agents` target writes to `<repo>/AGENTS.md`
-- `codex` target writes to `<repo>/CODEX.md`
-- `claude` target writes to `<repo>/CLAUDE.md`
-- `github` target writes to `<repo>/.github/agents/<pack-id>.md`
-
-Use `--dry-run` to preview the destination without writing files. Existing files are protected by default; use `--force` only when you intentionally want to overwrite the destination. Use `--status-only` to inspect whether the destination is `missing`, `up_to_date`, or `drifted` without writing anything.
-
-If you only want the deployment state without invoking the deploy command shape, use:
-
-```bash
-ee pack status <pack-id> [version] [agents|codex|github|claude] [repo-path]
-```
-
-Compiler visibility is also exposed through:
-
-- `ee pack list`
-- `ee pack inspect <pack-id>`
-- `ee inspect learning`
-- `ee doctor <adapter>`
+That does not mean every host surface is identical today:
 
-These surfaces show which targets the current Pack version has already compiled, whether a published Pack is stale, and the latest compile target/time.
+- `Codex` and `Claude Code` use MCP-native host interaction for routine use
+- `OpenClaw` now supports six in-session routine interaction families through the plugin path:
+  - what was injected
+  - why it matched
+  - helped / harmed feedback
+  - readiness in the current repo
+  - warm-up / first-value progress
+  - recent silence on the latest turn
+- advanced operator actions still remain more explicit in CLI across all hosts
 
 ## Host-Specific Setup
 
@@ -264,6 +332,14 @@ Before installing ExperienceEngine into any host, make sure the host CLI itself
 
 ExperienceEngine wires itself into an existing host environment. It does not install the host CLI for you.
 
+If you are installing ExperienceEngine into a repo for the first time, prefer:
+
+```bash
+ee install codex
+```
+
+That command wires the shared MCP server and writes the local `AGENTS.md` instruction block for the current repo.
+
 If you are operating or debugging the product directly, the explicit fallback commands still exist:
 
 ```bash
@@ -278,6 +354,12 @@ These are operator-facing controls, not the preferred public onboarding path.
 
 ExperienceEngine now supports a multi-provider embedding stack for semantic retrieval.
 
+Retrieval is now hybrid by default:
+
+- semantic retrieval remains the main recall path
+- lexical retrieval and query normalization help preserve engineering intent when the prompt wording shifts
+- reranking can promote a better-matching candidate above older score advantages, especially when an external reranker is configured
+
 Default behavior (`embeddingProvider = "api"`):
 
 - ExperienceEngine first tries API embeddings for better retrieval quality
@@ -463,6 +545,11 @@ Even though MCP is the main user interaction model for Claude/Codex, the `ee` CL
 
 Use MCP first for normal day-to-day interaction inside Claude/Codex.
 
+For the common routine loop, keep these actions in the host session first:
+- ask what ExperienceEngine just injected
+- ask why it matched
+- mark the last intervention as helped or harmed
+
 Use `ee` directly when:
 - the host session cannot currently access MCP
 - you are scripting or automating locally
@@ -494,7 +581,11 @@ ee rollback <backup-id>
 
 ## Doctor, Repair, and Upgrade
 
-Use doctor first if something looks wrong:
+If something feels wrong in normal use, ask the host agent to inspect ExperienceEngine first.
+
+Use the `ee` CLI when you need explicit local validation or the host cannot currently surface enough state.
+
+CLI fallback:
 
 ```bash
 ee doctor openclaw
@@ -511,7 +602,7 @@ What doctor tells you:
 - how many raw task records / task runs / pending candidates / formal nodes exist today
 - the next step to reach first durable value when the system is still warming up
 
-Use repair when host wiring drifted:
+Use repair when host wiring drifted and you need an explicit local recovery step:
 
 ```bash
 ee repair openclaw
@@ -558,7 +649,7 @@ Managed artifacts live under:
 
 Use backup when you want a restorable checkpoint of current ExperienceEngine state.
 
-In an MCP-capable host, ask the agent to create a backup. The agent should first show you a plan and only execute after you confirm.
+In an MCP-capable host, ask the agent to create a backup first. The agent should show a plan and only execute after you confirm.
 
 CLI fallback:
 
@@ -587,6 +678,8 @@ Import restores a valid ExperienceEngine snapshot directory.
 
 Before import overwrites current ExperienceEngine state, the system creates a safeguard backup automatically.
 
+In MCP-capable hosts, prefer asking the agent to plan the import first.
+
 CLI fallback:
 
 ```bash
@@ -599,6 +692,8 @@ Rollback restores one of the managed backups.
 
 Before rollback overwrites current ExperienceEngine state, the system also creates a safeguard backup automatically.
 
+In MCP-capable hosts, prefer asking the agent to plan the rollback first.
+
 CLI fallback:
 
 ```bash
@@ -618,6 +713,11 @@ For risky changes:
 
 ### Review what happened last
 
+For normal day-to-day usage in Claude Code or Codex, ask the host agent first:
+
+- "What did ExperienceEngine just inject?"
+- "Why did that ExperienceEngine hint match?"
+
 Fallback CLI:
 
 ```bash
@@ -629,11 +729,11 @@ This view now also shows:
 - origin record ids when they exist
 - the node evidence summary attached to each injected hint
 
-In MCP-capable hosts, ask:
+### Review recent injected turns
 
-- "What did ExperienceEngine just inject?"
+In MCP-capable hosts, ask:
 
-### Review recent injected turns
+- "Show the recent injected ExperienceEngine turns."
 
 Fallback CLI:
 
@@ -641,12 +741,10 @@ Fallback CLI:
 ee inspect recent injected 10
 ```
 
-In MCP-capable hosts, ask:
-
-- "Show the recent injected ExperienceEngine turns."
-
 ### Review current node inventory
 
+In MCP-capable hosts, ask for the current active strategies or warnings first.
+
 Fallback CLI:
 
 ```bash
@@ -658,6 +756,8 @@ ee inspect node <id>
 
 ### Manually correct feedback
 
+In MCP-capable hosts, prefer asking the agent to mark the last intervention as helpful or harmful.
+
 Fallback CLI:
 
 ```bash
@@ -673,6 +773,8 @@ ee feedback node <id> harmed
 
 ### Temporarily pause interventions
 
+In MCP-capable hosts, prefer asking the agent to pause or resume ExperienceEngine for the current scope.
+
 Fallback CLI:
 
 ```bash
@@ -687,12 +789,13 @@ What is already mature enough to use:
 - real runtime integration on Claude Code
 - real runtime integration on Codex
 - MCP-native inspect/control workflows on Claude/Codex
+- in-session routine review and feedback workflows on OpenClaw
 - managed state backup and restore over MCP `plan + confirm`
 
 What is still intentionally simpler:
-- OpenClaw does not yet have the same MCP-native user interaction layer as Claude/Codex
+- OpenClaw does not use the same MCP-native interaction shape as Claude/Codex
 - user-facing docs are lighter than a full product site
-- CLI fallback is still more complete than some host-native surfaces
+- CLI fallback is still more complete than some host-side surfaces
 
 ## If Something Feels Wrong
 

package/openclaw.plugin.json

@@ -1,7 +1,7 @@
 {
   "id": "experienceengine",
   "name": "ExperienceEngine",
-  "version": "0.1.0",
+  "version": "0.1.3",
   "description": "Context-aware experience intervention controller for coding and debugging tasks.",
   "configSchema": {
     "type": "object",

package/package.json

@@ -1,8 +1,9 @@
 {
   "name": "@alan512/experienceengine",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "type": "module",
-  "description": "ExperienceEngine v2 MVP scaffold for OpenClaw companion-layer experience intervention.",
+  "description": "Experience governance for coding agents: learn from real task outcomes, inject reusable hints, and retire low-value guidance.",
+  "license": "MIT",
   "repository": {
     "type": "git",
     "url": "https://github.com/Alan-512/ExperienceEngine.git"

package/plugins/claude-code-experienceengine/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "experienceengine",
   "description": "Context-aware experience intervention controller for Claude Code.",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "author": {
     "name": "ExperienceEngine"
   },

package/plugins/claude-code-experienceengine/.mcp.json

@@ -4,12 +4,13 @@
       "type": "stdio",
       "command": "node",
       "args": [
-        "${CLAUDE_PLUGIN_DATA}/node_modules/@alan512/experienceengine/dist/cli/index.js",
+        "${CLAUDE_PLUGIN_ROOT}/node_modules/@alan512/experienceengine/dist/cli/index.js",
         "mcp-server"
       ],
       "env": {
-        "NODE_PATH": "${CLAUDE_PLUGIN_DATA}/node_modules",
-        "EXPERIENCE_ENGINE_HOME": "${CLAUDE_PLUGIN_DATA}/experienceengine-home"
+        "NODE_PATH": "${CLAUDE_PLUGIN_ROOT}/node_modules",
+        "EXPERIENCE_ENGINE_HOME": "${CLAUDE_PLUGIN_ROOT}/experienceengine-home",
+        "EXPERIENCE_ENGINE_CLAUDE_HOOK_SOURCE": "marketplace"
       }
     }
   }

package/plugins/claude-code-experienceengine/scripts/claude-hook.sh

@@ -1,9 +1,38 @@
 #!/usr/bin/env bash
 set -euo pipefail
 
-PLUGIN_DATA="${CLAUDE_PLUGIN_DATA:?CLAUDE_PLUGIN_DATA is required}"
+PLUGIN_DATA="${CLAUDE_PLUGIN_DATA:-${CLAUDE_PLUGIN_ROOT:-}}"
+if [[ -z "${PLUGIN_DATA}" ]]; then
+  echo "CLAUDE_PLUGIN_DATA or CLAUDE_PLUGIN_ROOT is required" >&2
+  exit 1
+fi
 
 export NODE_PATH="${PLUGIN_DATA}/node_modules${NODE_PATH:+:${NODE_PATH}}"
 export EXPERIENCE_ENGINE_HOME="${EXPERIENCE_ENGINE_HOME:-${PLUGIN_DATA}/experienceengine-home}"
+STATE_PATH="${EXPERIENCE_ENGINE_HOME}/claude-marketplace-state.json"
+
+node - "${STATE_PATH}" <<'NODE'
+const fs = require("node:fs");
+const path = require("node:path");
+
+const [statePath] = process.argv.slice(2);
+let current = {};
+try {
+  current = JSON.parse(fs.readFileSync(statePath, "utf8"));
+} catch {}
+
+const next = {
+  adapter: "claude-code",
+  install_mode: "marketplace",
+  hook_source: "marketplace",
+  package_version: current.package_version,
+  written_at: current.written_at ?? new Date().toISOString(),
+  last_hook_seen_at: new Date().toISOString(),
+  last_mcp_seen_at: current.last_mcp_seen_at
+};
+
+fs.mkdirSync(path.dirname(statePath), { recursive: true });
+fs.writeFileSync(statePath, `${JSON.stringify(next, null, 2)}\n`);
+NODE
 
 exec node --no-warnings "${PLUGIN_DATA}/node_modules/@alan512/experienceengine/dist/cli/index.js" claude-hook "$@"

package/plugins/claude-code-experienceengine/scripts/install-deps.sh

@@ -1,19 +1,54 @@
 #!/usr/bin/env bash
 set -euo pipefail
 
-PLUGIN_DATA="${CLAUDE_PLUGIN_DATA:?CLAUDE_PLUGIN_DATA is required}"
+PLUGIN_DATA="${CLAUDE_PLUGIN_DATA:-${CLAUDE_PLUGIN_ROOT:-}}"
+if [[ -z "${PLUGIN_DATA}" ]]; then
+  echo "CLAUDE_PLUGIN_DATA or CLAUDE_PLUGIN_ROOT is required" >&2
+  exit 1
+fi
 PACKAGE_DIR="${PLUGIN_DATA}/node_modules/@alan512/experienceengine"
+PACKAGE_ENTRY="${PACKAGE_DIR}/dist/cli/index.js"
 STAMP_PATH="${PLUGIN_DATA}/.experienceengine-plugin-version"
-REPO_URL="${EXPERIENCE_ENGINE_PLUGIN_GIT_URL:-https://github.com/Alan-512/ExperienceEngine.git}"
-REPO_REF="${EXPERIENCE_ENGINE_PLUGIN_GIT_REF:-main}"
-PACKAGE_VERSION="0.1.2"
+EXPERIENCE_ENGINE_HOME_PATH="${EXPERIENCE_ENGINE_HOME:-${PLUGIN_DATA}/experienceengine-home}"
+STATE_PATH="${EXPERIENCE_ENGINE_HOME_PATH}/claude-marketplace-state.json"
+PACKAGE_VERSION="0.1.3"
+PACKAGE_SPEC="${EXPERIENCE_ENGINE_PLUGIN_PACKAGE_SPEC:-@alan512/experienceengine@${PACKAGE_VERSION}}"
 
 mkdir -p "${PLUGIN_DATA}"
+mkdir -p "${EXPERIENCE_ENGINE_HOME_PATH}"
+
+write_marketplace_state() {
+  node - "${STATE_PATH}" "${PACKAGE_VERSION}" <<'NODE'
+const fs = require("node:fs");
+const path = require("node:path");
+
+const [statePath, packageVersion] = process.argv.slice(2);
+let current = {};
+try {
+  current = JSON.parse(fs.readFileSync(statePath, "utf8"));
+} catch {}
+
+const next = {
+  adapter: "claude-code",
+  install_mode: "marketplace",
+  hook_source: "marketplace",
+  package_version: packageVersion,
+  written_at: current.written_at ?? new Date().toISOString(),
+  last_hook_seen_at: current.last_hook_seen_at,
+  last_mcp_seen_at: current.last_mcp_seen_at
+};
+
+fs.mkdirSync(path.dirname(statePath), { recursive: true });
+fs.writeFileSync(statePath, `${JSON.stringify(next, null, 2)}\n`);
+NODE
+}
 
-if [[ -f "${STAMP_PATH}" ]] && [[ "$(cat "${STAMP_PATH}")" == "${PACKAGE_VERSION}" ]] && [[ -d "${PACKAGE_DIR}" ]]; then
+if [[ -f "${STAMP_PATH}" ]] && [[ "$(cat "${STAMP_PATH}")" == "${PACKAGE_VERSION}" ]] && [[ -f "${PACKAGE_ENTRY}" ]]; then
+  write_marketplace_state
   exit 0
 fi
 
 rm -rf "${PLUGIN_DATA}/node_modules"
-npm install --prefix "${PLUGIN_DATA}" --no-package-lock --omit=dev "${REPO_URL}#${REPO_REF}"
+npm install --prefix "${PLUGIN_DATA}" --no-package-lock --omit=dev --ignore-scripts "${PACKAGE_SPEC}"
 printf '%s' "${PACKAGE_VERSION}" > "${STAMP_PATH}"
+write_marketplace_state

package/dist/cli/commands/pack.d.ts

@@ -1 +0,0 @@
-export declare const runPackCommand: (args: string[]) => void;