@nithin554/code-crawler 0.1.69 → 0.1.71

package/README.md

@@ -295,8 +295,23 @@ workspace roots, or the project this session already selected, and keeps that gr
 `<project>/.code-crawler/index.db` — one database per repository, the same layout the CLI
 uses. `CODECRAWLER_DB` still pins a single file when you want one.
 
-The same skill is published to [ClawHub](https://clawhub.ai) as `code-crawler`, versioned by
-the release tag: release `v0.1.67` publishes `code-crawler@0.1.67`.
+The same skill is published to [ClawHub](https://clawhub.ai) as `code-crawler`, and the
+plugin is published there too:
+
+- **Skill** — `clawhub install code-crawler`. ClawHub assigns this version by bumping the
+  patch digit of whatever it already published, so it advances one release at a time instead
+  of copying the npm version; a release whose skill publish fails leaves the two numbers one
+  apart until the next publish.
+- **Plugin** — published as the `code-crawler` bundle plugin, versioned from the release tag:
+  release `v0.1.67` publishes the bundle at `0.1.67`.
+
+Publishing is restricted to `main`. Both jobs deploy through the `clawhub-publish`
+environment, whose deployment branch policy rejects any other ref, so a manual dispatch from
+a feature branch stops before it can upload. The `CLAWHUB_TOKEN` secret lives on that
+environment rather than on the repository, so a publish can only read it after the gate has
+accepted the ref; the environment-bound `guard` job is what passes it to the publish call,
+because a job that calls a reusable workflow cannot declare an environment and therefore
+cannot read an environment secret itself.
 
 ### One command
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nithin554/code-crawler",
-  "version": "0.1.69",
+  "version": "0.1.71",
   "mcpName": "io.github.nithin554/code-crawler",
   "description": "Static and dynamic call tracing MCP server backed by a SQLite property graph of your codebase",
   "type": "module",