v0.7.15 — skilify: fix pull layout + add unpull with manifest-tracked installs

Summary

• Pulled skills are now visible to Claude Code. Previously pull wrote to <root>/<projectKey>/<name>/SKILL.md, but CC's skill loader scans <root>/<dir>/SKILL.md (single depth), so pulled skills appeared in ls but never reached the agent. New layout writes to <root>/<name>--<author>/SKILL.md flat — a teammate's deploy and your locally-mined deploy coexist as deploy--alice/ and deploy/.
• New hivemind skilify unpull command removes pull-installed skills with --user, --users, --not-mine, --dry-run, --all, --legacy-cleanup filters.
• Manifest at ~/.deeplake/state/skilify/pulled.json is the authoritative record of what pull wrote. unpull only touches entries in the manifest, so user-authored variant skills with -- in the name (e.g. deploy--blue-green) are never removed accidentally.
• Visibility wired into all 6 agents (Claude Code, Codex, Cursor, Hermes, Pi, OpenClaw) via SessionStart inject + hivemind --help USAGE block, so the agent suggests unpull spontaneously.
• Fixed a real production bug caught by a unit test: loadManifest() was returning a shared module-level constant, so every recordPull would have permanently corrupted it across calls.

Layout reference

Origin	Path on disk
Locally mined (your own skill)	<root>/<name>/SKILL.md
Pulled (someone else's skill)	<root>/<name>--<author>/SKILL.md
Manifest	~/.deeplake/state/skilify/pulled.json

<root> is ~/.claude/skills for --to global, <cwd>/.claude/skills for --to project. Atomic write (tmp + rename), 0o600 perms, parent dirs auto-created.

Trade-offs called out in code comments

• Same (name, author) pulled from two different projects collides on disk under the new flat layout — more recent pull wins, prior SKILL.md is preserved as .bak. The row stays in the Deeplake skills table, recoverable via re-pull from the source project.
• --all and --legacy-cleanup opt-in flags do an additional disk walk for things NOT in the manifest (locally-mined skills and pre-suffix-author <projectKey>/ dirs from skilify ≤ 0.7.13). Always documented as destructive in --help.

Commits in this branch

1. feat(skilify-pull) — flat <name>--<author>/ layout + pulled.json manifest
2. feat(skilify-unpull) — new unpull command with manifest-driven removal + filters
3. feat(skilify) — expose unpull to agents via SessionStart inject + --help
4. build(bundles) — regenerate cli.js + per-agent session-start.js
5. docs(readme) — document pull / unpull and the new layout

Test plan

• Unit: 69 tests across skilify-pull.test.ts (43 updated) + skilify-manifest.test.ts (15 new) + skilify-unpull.test.ts (11 new). HOME isolated via mkdtempSync per test.
• Full suite: npx vitest run — 2103/2104 pass; the single pre-existing failure is in deeplake-api-retry.test.ts (retry timing test, unrelated to skilify).
• Build: npm run build → Built: 12 CC + 10 Codex + 9 Cursor + 9 Hermes + 1 OpenClaw + 1 MCP + 1 CLI + 1 standalone-daemon bundle.
• Live e2e against activeloop/hivemind: verified round-trip
  • pull --user d --to global → disk + manifest both populated
  • unpull --user d → both cleared
  • pull --user d again → re-installs cleanly (idempotent)
  • pull --users d,sasun → 2 entries, then unpull --user d removes only Davit and leaves sasun on both disk and manifest
  • Manual deploy--blue-green/ directory survived every default unpull invocation
  • Orphan handling: pull then rm -rf the dir manually then unpull → reports manifest-orphan and prunes the entry
• CC skill loader confirmation: after pull --all-users, the SessionStart-loaded skills list shows pulled entries with their proper <name>--<author> identifiers (meta-harness-continual-learning--d, photon-design-feedback--sasun, etc.), proving CC actually picks them up at agent decision time.

Migration

Users on skilify ≤ 0.7.13 with the pre-existing <projectKey>/ layout can clean up legacy directories with:

hivemind skilify unpull --legacy-cleanup --dry-run
hivemind skilify unpull --legacy-cleanup

Otherwise the old directories are left alone (CC ignored them anyway because of the depth-2 issue this PR fixes).

Summary by CodeRabbit

• New Features

  • Added hivemind skilify unpull command to remove previously shared skills with filtering options (--user, --not-mine, --dry-run).
  • Skills now support author-based organization and removal by install scope.

• Documentation

  • Updated command reference and help text to document the new unpull functionality and available flags across all tools.

v0.7.14 — fix(release): pin clawhub publish to --family code-plugin

Summary

Adds --family code-plugin to the clawhub package publish invocation in release.yml. Was meant to land in PR #107 but the merge happened before this commit got included — the family-fix commit (5759109) was pushed to that branch but the merge was finalized using an earlier tip. Re-opening it stand-alone here.

Why

After PR #107 merged, the next Release run is going to hit this on the ClawHub publish step:

ConvexError: Package "hivemind" already exists as a code-plugin;
family changes are not allowed
    at handler (../convex/packages.ts:4305:8)

The existing hivemind package on ClawHub was originally registered with family=code-plugin (verified via clawhub package inspect hivemind → Family: Code Plugin). The clawhub CLI's auto-detection on this openclaw plugin layout picks a different default (bundle-plugin), so without an explicit --family flag it tries to publish as the wrong family and ClawHub refuses.

Fix

One-line change in .github/workflows/release.yml:

-        run: clawhub package publish ./openclaw
+        run: clawhub package publish ./openclaw --family code-plugin

Plus a comment block explaining why.

Verified locally

Test publish run from this machine using the @kaghni token (matches what 1Password now hands CI):

$ clawhub package publish /home/ubuntu/al-projects/hivemind/openclaw \
    --family code-plugin --name hivemind --version 0.0.1-test --tags test
- Preparing hivemind@0.0.1-test
✔ OK. Published hivemind@0.0.1-test (rd7d1frmgts4j1z9mpv9bqk4jd8697hg)

Without --family code-plugin the same auth/data hits family changes are not allowed every time. With it, publish succeeds. Latest tag on ClawHub stayed at 0.6.56 (test publish only set a test tag). Ownership/auth verified working under @kaghni.

Test plan

• CI passes on this PR
• On merge: auto-bump fires (0.7.11 → 0.7.12), Release workflow runs, the publish job clears all upstream gates (build, npm publish), and the clawhub publish step now finds the right family and succeeds — ClawHub's latest tag bumps from 0.6.56 to 0.7.12

Summary by CodeRabbit

• Bug Fixes
  • Corrected package publishing configuration to resolve deployment issues during the release process.

v0.7.13 — fix(release): pin clawhub publish to --family code-plugin

Summary

Adds --family code-plugin to the clawhub package publish invocation in release.yml. Was meant to land in PR #107 but the merge happened before this commit got included — the family-fix commit (5759109) was pushed to that branch but the merge was finalized using an earlier tip. Re-opening it stand-alone here.

Why

After PR #107 merged, the next Release run is going to hit this on the ClawHub publish step:

ConvexError: Package "hivemind" already exists as a code-plugin;
family changes are not allowed
    at handler (../convex/packages.ts:4305:8)

The existing hivemind package on ClawHub was originally registered with family=code-plugin (verified via clawhub package inspect hivemind → Family: Code Plugin). The clawhub CLI's auto-detection on this openclaw plugin layout picks a different default (bundle-plugin), so without an explicit --family flag it tries to publish as the wrong family and ClawHub refuses.

Fix

One-line change in .github/workflows/release.yml:

-        run: clawhub package publish ./openclaw
+        run: clawhub package publish ./openclaw --family code-plugin

Plus a comment block explaining why.

Verified locally

Test publish run from this machine using the @kaghni token (matches what 1Password now hands CI):

$ clawhub package publish /home/ubuntu/al-projects/hivemind/openclaw \
    --family code-plugin --name hivemind --version 0.0.1-test --tags test
- Preparing hivemind@0.0.1-test
✔ OK. Published hivemind@0.0.1-test (rd7d1frmgts4j1z9mpv9bqk4jd8697hg)

Without --family code-plugin the same auth/data hits family changes are not allowed every time. With it, publish succeeds. Latest tag on ClawHub stayed at 0.6.56 (test publish only set a test tag). Ownership/auth verified working under @kaghni.

Test plan

• CI passes on this PR
• On merge: auto-bump fires (0.7.11 → 0.7.12), Release workflow runs, the publish job clears all upstream gates (build, npm publish), and the clawhub publish step now finds the right family and succeeds — ClawHub's latest tag bumps from 0.6.56 to 0.7.12

Summary by CodeRabbit

• Bug Fixes
  • Corrected package publishing configuration to resolve deployment issues during the release process.

v0.7.12 — fix(release): pin clawhub publish to --family code-plugin

Summary

Adds --family code-plugin to the clawhub package publish invocation in release.yml. Was meant to land in PR #107 but the merge happened before this commit got included — the family-fix commit (5759109) was pushed to that branch but the merge was finalized using an earlier tip. Re-opening it stand-alone here.

Why

After PR #107 merged, the next Release run is going to hit this on the ClawHub publish step:

ConvexError: Package "hivemind" already exists as a code-plugin;
family changes are not allowed
    at handler (../convex/packages.ts:4305:8)

The existing hivemind package on ClawHub was originally registered with family=code-plugin (verified via clawhub package inspect hivemind → Family: Code Plugin). The clawhub CLI's auto-detection on this openclaw plugin layout picks a different default (bundle-plugin), so without an explicit --family flag it tries to publish as the wrong family and ClawHub refuses.

Fix

One-line change in .github/workflows/release.yml:

-        run: clawhub package publish ./openclaw
+        run: clawhub package publish ./openclaw --family code-plugin

Plus a comment block explaining why.

Verified locally

Test publish run from this machine using the @kaghni token (matches what 1Password now hands CI):

$ clawhub package publish /home/ubuntu/al-projects/hivemind/openclaw \
    --family code-plugin --name hivemind --version 0.0.1-test --tags test
- Preparing hivemind@0.0.1-test
✔ OK. Published hivemind@0.0.1-test (rd7d1frmgts4j1z9mpv9bqk4jd8697hg)

Without --family code-plugin the same auth/data hits family changes are not allowed every time. With it, publish succeeds. Latest tag on ClawHub stayed at 0.6.56 (test publish only set a test tag). Ownership/auth verified working under @kaghni.

Test plan

• CI passes on this PR
• On merge: auto-bump fires (0.7.11 → 0.7.12), Release workflow runs, the publish job clears all upstream gates (build, npm publish), and the clawhub publish step now finds the right family and succeeds — ClawHub's latest tag bumps from 0.6.56 to 0.7.12

Summary by CodeRabbit

• Bug Fixes
  • Corrected package publishing configuration to resolve deployment issues during the release process.

v0.7.11 — fix(openclaw): drop npm scope from openclaw plugin name for ClawHub publish

Summary

Restores openclaw/package.json:name to bare hivemind (its original value), so clawhub package publish ./openclaw succeeds. Sequel to PR #106 — both PRs together unblock the auto-publish flow end-to-end.

What's wrong

After PR #106's fixes landed and the publish job actually got far enough to reach clawhub package publish ./openclaw, ClawHub rejected:

ConvexError: Publisher "@deeplake" not found
    at handler (../convex/publishers.ts:389:23)

ClawHub treats the leading @scope in a package name as a publisher namespace and looks it up in its database. There is no @deeplake publisher registered on ClawHub — the existing package on ClawHub is clawhub:hivemind (bare name, owned by the authenticated user's namespace).

openclaw/package.json had name: "@deeplake/hivemind" — the npm scope leaked into the openclaw plugin manifest. Git history shows this was a regression:

-  "name": "hivemind",                          (original)
+  "name": "@activeloop/hivemind",
-  "name": "@activeloop/hivemind",
+  "name": "@deeplake/hivemind",                (current main)

What changes

One field. openclaw/package.json:name:

-  "name": "@deeplake/hivemind",
+  "name": "hivemind",

That's it. The two registries have different namespacing conventions and the manifest already separates plugin identity (name) from code distribution channel (openclaw.install.npmSpec). I'm honoring that separation:

Field	Value	Used for
name	hivemind	ClawHub plugin identity (publish + install lookup)
openclaw.install.npmSpec	@deeplake/hivemind	npm package the runtime fetches

Both fields can have different values — that's the whole point of the manifest having two of them.

Effect

• clawhub package publish ./openclaw publishes hivemind under whichever publisher owns the CLAWHUB_TOKEN. That account is already established as the publisher of clawhub:hivemind (currently at v0.6.56), so this auto-publish picks up the same package and bumps it forward.
• openclaw plugins install clawhub:hivemind (the existing install command) keeps working — same plugin name on ClawHub.
• Once installed, openclaw resolves npmSpec: @deeplake/hivemind → fetches the code from npm. Unaffected.
• Root package.json (npm publish) untouched. Still ships as @deeplake/hivemind.

Verified

• Grep across the codebase: nothing reads openclaw/package.json:name as a load-bearing string. openclaw.install.npmSpec retains the npm scope, so install logic is untouched.
• Live ClawHub state: https://clawhub.ai/plugins/hivemind shows hivemind (bare) by @kaghni, install via openclaw plugins install clawhub:hivemind. The bare name was the original convention.

Test plan

• CI passes on this PR
• On merge, the auto-bump triggers release.yml. The publish job now completes all steps: install → build → quality gate → pack-check → npm publish (provenance succeeds) → clawhub package publish (bare name resolves under token owner)
• Confirm the version on https://clawhub.ai/plugins/hivemind advances past 0.6.56

Summary by CodeRabbit

• Package Updates
  • Updated package name to improve accessibility and ease of installation.

v0.7.9 — fix(release): unblock publish job (build-before-test + repository field)

Summary

The publish job in release.yml has been broken since it landed on main — every Release run that actually exercises it has failed. Two independent bugs were gating it; this PR fixes both.

#	Bug	Failure mode	Fixed by
1	Build runs AFTER quality gate	vitest ENOENT on openclaw/dist/index.js	reorder steps in release.yml
2	package.json has no repository field	npm publish --provenance rejected with HTTP 422 (Sigstore can't verify source URL)	add repository to package.json

Without both fixes, the publish flow can't ship a release end-to-end. Bug #1 is what's failing right now (run 25484806027 on 5a38c50); bug #2 is what failed run 25482668127 on df5ced18 — the first run that actually got past the quality gate, before PR #98 landed.

Bug #1 — build-before-test

Publish job step order was:

1. npm ci                   # install deps
2. npm run ci               # typecheck + dup + test     ← TESTS RUN HERE
3. npm run build            # build bundles               ← BUILD RUNS AFTER
4. npm run pack:check
5. npm publish --provenance

Bundle-scan tests in claude-code/tests/skilify-session-start-injection.test.ts (added by PR #98) read openclaw/dist/index.js and openclaw/dist/skilify-worker.js directly. openclaw/dist/ is gitignored — only exists after npm run build. Step 2 failed with ENOENT, publish aborted.

Same root cause as 64cac0b (ci: replace typecheck step with full build...) which fixed it for ci.yml's Typecheck and Test job. That fix never propagated to the publish job in release.yml (added later in a436373).

Fix: pure step reorder. Move npm run build before npm run ci.

Bug #2 — provenance verification

npm publish --provenance requires package.json.repository.url to match the source URL claimed by the GitHub Actions OIDC token. package.json on main has no repository field at all, so npm rejects:

npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/@deeplake%2fhivemind
- Error verifying sigstore provenance bundle: Failed to validate repository information:
  package.json: "repository.url" is "", expected to match
  "https://github.com/activeloopai/hivemind" from provenance

Bug #1 was masking bug #2 once PR #98 landed (the gate failed before the provenance check could run). Before PR #98 landed, run #95 hit bug #2 directly.

Fix: add the standard npm repository shape:

"repository": {
  "type": "git",
  "url": "git+https://github.com/activeloopai/hivemind.git"
}

Format follows npm's recommended shape — git+ prefix + .git suffix, both required for provenance to verify.

Test plan

• CI passes on this PR (the publish job doesn't run on PRs — it's gated on: push: branches: [main] — so confidence here is by inspection: build is a strict superset of typecheck, and the repository field is mechanically required by npm)
• On merge: auto-bump triggers release.yml, the bump pushes a chore: bump version commit which retriggers Release, which runs the publish job. Build runs first → quality gate finds openclaw/dist/ → vitest passes → build → pack-check → npm publish → provenance verifies (repository field now present) → ClawHub publish
• Look for npm notice publish Provenance statement published to transparency log: https://search.sigstore.dev/... followed by HTTP 201 (not 422)

v0.7.8 — ci: publish to npm and ClawHub on merge to main

Summary

• Adds a publish job to release.yml that fires after the existing version-bump flow and publishes @deeplake/hivemind to npm and the openclaw bundle to ClawHub
• Gated by a production GitHub Environment with required reviewer — each version still gets explicit per-publish approval (so this CD does not bypass the existing manual gate, just routes it through GitHub's UI)
• npm publish uses --provenance --access public (Sigstore via GitHub OIDC), so even if NPM_TOKEN later leaks, consumers can verify the package was built by this workflow on this commit
• Adds a npm pack --dry-run regression guard (scripts/pack-check.mjs, wired into both ci.yml and the publish job) that hard-fails if a PR widens the files allowlist to include .npmrc, .env, .github/, secrets/, etc.

Token-leak defenses, layered

1. Environment-scoped secrets — NPM_TOKEN and CLAWHUB_TOKEN are stored on the production environment, not the repo. PRs from forks and unprotected branches cannot read them; only the gated publish job can.
2. Minimum-privilege permissions — workflow stays contents: read at top, only the publish job adds id-token: write (needed for OIDC provenance). No pull-requests, no broader contents: write.
3. Ephemeral .npmrc — actions/setup-node@v4 writes a temporary ~/.npmrc referencing ${NODE_AUTH_TOKEN}; passed only on the npm publish step's env:. The runner's $HOME is discarded when the job ends.
4. Sigstore provenance — defense-in-depth even if NPM_TOKEN leaks. npm view @deeplake/hivemind --json | jq .dist.attestations will show the signature.
5. GitHub auto-masking — anything flowing through ${{ secrets.* }} is *** in logs. We don't set -x or echo env on token-bearing steps.
6. Concurrency guard — hivemind-publish group prevents two merges from racing two publishes of the same version.
7. Tarball regression guard — scripts/pack-check.mjs runs in PR CI, so a broken files array trips on PR review, never on a release run where tokens are reachable.

Required one-time setup before merging

The repo owner must do these in GitHub UI before the first publish run reaches the gate:

1. Settings → Environments → New environment named production
   • Required reviewers: add your account
   • (Optional) Deployment branches: restrict to main
2. Add environment secrets to that environment:
   • NPM_TOKEN — recommended: granular automation token, scope @deeplake/hivemind only, Read and write, 90-day expiry. Created at https://www.npmjs.com/settings/~/tokens/granular-access-tokens.
   • CLAWHUB_TOKEN — generate via clawhub login and pull the token, or via clawhub.ai web UI.
3. Settings → Actions → General → Workflow permissions: confirm id-token: write is allowed (some org policies disable it by default).

How it fires after merge

push to main
   ↓
release job  (existing)
   ├─ first run:  bump patch + push back ──► retriggers
   └─ bump-commit run: GitHub Release ──► publish job (new)
                                              ↓
                                       [GATE: production env approval]
                                              ↓
                                       npm publish --provenance
                                       clawhub login --token
                                       clawhub package publish ./openclaw

The publish job's if: requires startsWith(head_commit.message, 'chore: bump version'), so it runs exactly once per released version.

Test plan

• One-time setup steps above are done before merging this PR
• On first merge, reject the production environment gate to confirm the gate works without publishing
• On second merge, approve the gate; verify npm view @deeplake/hivemind version matches the GitHub Release tag
• npm view @deeplake/hivemind --json | jq .dist.attestations shows a sigstore attestation (Provenance badge on npmjs.com)
• clawhub:hivemind is installable and verify-install.sh passes against it
• gh run view --log <run-id> | grep -E 'npm_[A-Za-z0-9_]{20,}|CLAWHUB_[A-Za-z0-9]{20,}' returns nothing

Confidence

Confidence: 80%, because the npm side is grounded in real package.json + release.yml + standard provenance/Environments practice, and the ClawHub side is grounded in clawhub --help output (clawhub login --token + clawhub package publish <folder> are real subcommands of the published clawhub v0.12.3 package).

Untested:

• Whether clawhub package publish ./openclaw auto-detects the package name hivemind from openclaw/openclaw.plugin.json's id field, or whether --name hivemind needs to be passed explicitly
• Whether ClawHub has a "trusted publisher" config that would force --manual-override-reason "Automated CD" to be added — first real publish will surface this if so
• Whether id-token: write is allowed by the org's current Actions permissions (rules 3 above), since policy may differ per repo
• The interaction between the existing release job's git push and the publish job's checkout — current architecture splits across two workflow invocations (the bump-push retriggers), so the publish job sees the bumped commit on ref: main, but worth visually confirming on the first real run before approving the gate
• Whether existing per-bundle E2E (verify-install.sh against installed @deeplake/hivemind) should be wired into the publish job before npm publish; currently the human reviewer at the gate is the E2E checkpoint

Summary by CodeRabbit

• Chores
  • Enhanced CI pipeline with additional validation during pull request testing to safeguard package integrity.
  • Implemented automated publishing workflow that handles both npm and ClawHub distribution with environment-based access controls.
  • Added validation tooling to verify package contents before publishing.

v0.7.7 — ci: publish to npm and ClawHub on merge to main

Summary

• Adds a publish job to release.yml that fires after the existing version-bump flow and publishes @deeplake/hivemind to npm and the openclaw bundle to ClawHub
• Gated by a production GitHub Environment with required reviewer — each version still gets explicit per-publish approval (so this CD does not bypass the existing manual gate, just routes it through GitHub's UI)
• npm publish uses --provenance --access public (Sigstore via GitHub OIDC), so even if NPM_TOKEN later leaks, consumers can verify the package was built by this workflow on this commit
• Adds a npm pack --dry-run regression guard (scripts/pack-check.mjs, wired into both ci.yml and the publish job) that hard-fails if a PR widens the files allowlist to include .npmrc, .env, .github/, secrets/, etc.

Token-leak defenses, layered

1. Environment-scoped secrets — NPM_TOKEN and CLAWHUB_TOKEN are stored on the production environment, not the repo. PRs from forks and unprotected branches cannot read them; only the gated publish job can.
2. Minimum-privilege permissions — workflow stays contents: read at top, only the publish job adds id-token: write (needed for OIDC provenance). No pull-requests, no broader contents: write.
3. Ephemeral .npmrc — actions/setup-node@v4 writes a temporary ~/.npmrc referencing ${NODE_AUTH_TOKEN}; passed only on the npm publish step's env:. The runner's $HOME is discarded when the job ends.
4. Sigstore provenance — defense-in-depth even if NPM_TOKEN leaks. npm view @deeplake/hivemind --json | jq .dist.attestations will show the signature.
5. GitHub auto-masking — anything flowing through ${{ secrets.* }} is *** in logs. We don't set -x or echo env on token-bearing steps.
6. Concurrency guard — hivemind-publish group prevents two merges from racing two publishes of the same version.
7. Tarball regression guard — scripts/pack-check.mjs runs in PR CI, so a broken files array trips on PR review, never on a release run where tokens are reachable.

Required one-time setup before merging

The repo owner must do these in GitHub UI before the first publish run reaches the gate:

1. Settings → Environments → New environment named production
   • Required reviewers: add your account
   • (Optional) Deployment branches: restrict to main
2. Add environment secrets to that environment:
   • NPM_TOKEN — recommended: granular automation token, scope @deeplake/hivemind only, Read and write, 90-day expiry. Created at https://www.npmjs.com/settings/~/tokens/granular-access-tokens.
   • CLAWHUB_TOKEN — generate via clawhub login and pull the token, or via clawhub.ai web UI.
3. Settings → Actions → General → Workflow permissions: confirm id-token: write is allowed (some org policies disable it by default).

How it fires after merge

push to main
   ↓
release job  (existing)
   ├─ first run:  bump patch + push back ──► retriggers
   └─ bump-commit run: GitHub Release ──► publish job (new)
                                              ↓
                                       [GATE: production env approval]
                                              ↓
                                       npm publish --provenance
                                       clawhub login --token
                                       clawhub package publish ./openclaw

The publish job's if: requires startsWith(head_commit.message, 'chore: bump version'), so it runs exactly once per released version.

Test plan

• One-time setup steps above are done before merging this PR
• On first merge, reject the production environment gate to confirm the gate works without publishing
• On second merge, approve the gate; verify npm view @deeplake/hivemind version matches the GitHub Release tag
• npm view @deeplake/hivemind --json | jq .dist.attestations shows a sigstore attestation (Provenance badge on npmjs.com)
• clawhub:hivemind is installable and verify-install.sh passes against it
• gh run view --log <run-id> | grep -E 'npm_[A-Za-z0-9_]{20,}|CLAWHUB_[A-Za-z0-9]{20,}' returns nothing

Confidence

Confidence: 80%, because the npm side is grounded in real package.json + release.yml + standard provenance/Environments practice, and the ClawHub side is grounded in clawhub --help output (clawhub login --token + clawhub package publish <folder> are real subcommands of the published clawhub v0.12.3 package).

Untested:

• Whether clawhub package publish ./openclaw auto-detects the package name hivemind from openclaw/openclaw.plugin.json's id field, or whether --name hivemind needs to be passed explicitly
• Whether ClawHub has a "trusted publisher" config that would force --manual-override-reason "Automated CD" to be added — first real publish will surface this if so
• Whether id-token: write is allowed by the org's current Actions permissions (rules 3 above), since policy may differ per repo
• The interaction between the existing release job's git push and the publish job's checkout — current architecture splits across two workflow invocations (the bump-push retriggers), so the publish job sees the bumped commit on ref: main, but worth visually confirming on the first real run before approving the gate
• Whether existing per-bundle E2E (verify-install.sh against installed @deeplake/hivemind) should be wired into the publish job before npm publish; currently the human reviewer at the gate is the E2E checkpoint

Summary by CodeRabbit

• Chores
  • Enhanced CI pipeline with additional validation during pull request testing to safeguard package integrity.
  • Implemented automated publishing workflow that handles both npm and ClawHub distribution with environment-based access controls.
  • Added validation tooling to verify package contents before publishing.

v0.7.6 — fix(auth-login): validate workspace on switch; reset stale workspace on org switch

Closes #92.

Summary

• hivemind workspace <id> no longer silently saves an unknown id. It now lists workspaces, validates id-or-name (case-insensitive), and exits 1 with the available list on miss — same UX as hivemind org switch.
• hivemind org switch now resets the active workspace to default (with a warning) when the previously-saved workspace doesn't exist in the new org. Previously the saved workspaceId carried over silently, leaving the user pointing at a workspace that didn't exist in their new org.
• The workspace command surface is restructured into workspace list and workspace switch <name-or-id>, mirroring org list / org switch. The bare-target shortcut (workspace <id>) is removed.

Why

Two related bugs in the auth-login CLI dispatcher:

1. switchWorkspace accepted any string and persisted it to credentials with no existence check. e.g. hivemind workspace k7 printed Switched to workspace: k7 even when k7 was not a real workspace in the current org.
2. switchOrg saved { orgId, orgName } without touching workspaceId. After hivemind org switch <new-org>, you were still scoped to the previous workspace id — which often didn't exist in the new org, so subsequent commands ran against a phantom workspace.

Combined, a user who typed hivemind org switch <other-org> (forgetting to also fix the workspace) ended up silently misconfigured, and even an attempt to fix it with hivemind workspace <id> produced no feedback that the id was wrong.

What changed

src/commands/auth-login.ts

• org switch handler: after the switch, calls listWorkspaces(creds.token, apiUrl, <new-org-id>) and, if the carried-over workspaceId isn't in the result, calls switchWorkspace("default") and prints a warning + the available list.
• workspace handler: split into two subcommands.
  • workspace list mirrors the existing top-level workspaces command.
  • workspace switch <target> does the validate-then-switch, exiting 1 with the available list on miss.
  • Anything else under workspace (including the previously-supported bare target) is rejected with usage.
• Docstring updated.

src/cli/index.ts

• hivemind --help now documents workspace list and workspace switch <name-or-id> instead of the bare workspace <id> form.

claude-code/tests/auth-login-dispatch.test.ts

• Existing org switch tests updated to mock the new listWorkspaces call.
• Added 10 cases covering:
  • workspace switch <unknown> exits 1 with the available list, never calls switchWorkspace.
  • workspace switch <id> and workspace switch <name> (case-insensitive) both resolve correctly.
  • workspace switch (no target) exits 1 without hitting the API.
  • workspace list is read-only — never calls switchWorkspace.
  • workspace <target> (the removed bare form) is rejected without API calls — explicit regression guard.
  • org switch resets the workspace to default when the carried-over id isn't in the new org's list.
  • org switch does NOT reset the workspace when the carried-over id (or name) IS still present in the new org.
  • listWorkspaces is called with the NEW org id, not the stale one from creds.

Bundles (bundle/cli.js, claude-code/bundle/commands/auth-login.js, codex/bundle/commands/auth-login.js, cursor/bundle/commands/auth-login.js, hermes/bundle/commands/auth-login.js)

• Rebuilt via npm run build. Second commit is a pure rebuild — no source edits.

Test plan

• npx vitest run claude-code/tests/auth-login-dispatch.test.ts → 42/42 pass
• npm run build → all bundles rebuild cleanly
• Local install + smoke tests (overlaid bundle/cli.js onto the global @deeplake/hivemind install):
  • hivemind workspace list → lists current org's workspaces
  • hivemind workspace switch <real-name> → switches successfully
  • hivemind workspace switch <bogus> → exits 1 with available list, no state mutation
  • hivemind workspace switch (no arg) → exits 1 with subcommand usage, no API call
  • hivemind workspace <bare-name> → exits 1 with the new usage line
  • hivemind workspace (no args) → exits 1 with the new usage line
  • hivemind whoami after each → confirms credentials state is consistent with the last successful switch
• Reviewer to verify in a multi-org account: hivemind org switch <other-org> from a workspace not present in the target org → resets to default with the warning message. (Needs an account with at least two orgs to repro; the unit tests cover the dispatcher logic deterministically.)

Breaking change

hivemind workspace <id> (the bare-target shortcut) no longer switches; it now exits 1 with usage. Replace with hivemind workspace switch <id>. The plural hivemind workspaces command and the /hivemind_switch_workspace OpenClaw slash command are unaffected.

Summary by CodeRabbit

Release Notes

• New Features

  • Added workspace list and workspace switch <name-or-id> subcommands for improved workspace management.
  • Implemented automatic workspace validation during organization switches; resets to default if the workspace is unavailable in the new organization.

• Documentation

  • Updated CLI usage documentation to reflect new workspace management subcommands.

v0.7.5 — fix(auth-login): validate workspace on switch; reset stale workspace on org switch

Closes #92.

Summary

• hivemind workspace <id> no longer silently saves an unknown id. It now lists workspaces, validates id-or-name (case-insensitive), and exits 1 with the available list on miss — same UX as hivemind org switch.
• hivemind org switch now resets the active workspace to default (with a warning) when the previously-saved workspace doesn't exist in the new org. Previously the saved workspaceId carried over silently, leaving the user pointing at a workspace that didn't exist in their new org.
• The workspace command surface is restructured into workspace list and workspace switch <name-or-id>, mirroring org list / org switch. The bare-target shortcut (workspace <id>) is removed.

Why

Two related bugs in the auth-login CLI dispatcher:

1. switchWorkspace accepted any string and persisted it to credentials with no existence check. e.g. hivemind workspace k7 printed Switched to workspace: k7 even when k7 was not a real workspace in the current org.
2. switchOrg saved { orgId, orgName } without touching workspaceId. After hivemind org switch <new-org>, you were still scoped to the previous workspace id — which often didn't exist in the new org, so subsequent commands ran against a phantom workspace.

Combined, a user who typed hivemind org switch <other-org> (forgetting to also fix the workspace) ended up silently misconfigured, and even an attempt to fix it with hivemind workspace <id> produced no feedback that the id was wrong.

What changed

src/commands/auth-login.ts

• org switch handler: after the switch, calls listWorkspaces(creds.token, apiUrl, <new-org-id>) and, if the carried-over workspaceId isn't in the result, calls switchWorkspace("default") and prints a warning + the available list.
• workspace handler: split into two subcommands.
  • workspace list mirrors the existing top-level workspaces command.
  • workspace switch <target> does the validate-then-switch, exiting 1 with the available list on miss.
  • Anything else under workspace (including the previously-supported bare target) is rejected with usage.
• Docstring updated.

src/cli/index.ts

• hivemind --help now documents workspace list and workspace switch <name-or-id> instead of the bare workspace <id> form.

claude-code/tests/auth-login-dispatch.test.ts

• Existing org switch tests updated to mock the new listWorkspaces call.
• Added 10 cases covering:
  • workspace switch <unknown> exits 1 with the available list, never calls switchWorkspace.
  • workspace switch <id> and workspace switch <name> (case-insensitive) both resolve correctly.
  • workspace switch (no target) exits 1 without hitting the API.
  • workspace list is read-only — never calls switchWorkspace.
  • workspace <target> (the removed bare form) is rejected without API calls — explicit regression guard.
  • org switch resets the workspace to default when the carried-over id isn't in the new org's list.
  • org switch does NOT reset the workspace when the carried-over id (or name) IS still present in the new org.
  • listWorkspaces is called with the NEW org id, not the stale one from creds.

Bundles (bundle/cli.js, claude-code/bundle/commands/auth-login.js, codex/bundle/commands/auth-login.js, cursor/bundle/commands/auth-login.js, hermes/bundle/commands/auth-login.js)

• Rebuilt via npm run build. Second commit is a pure rebuild — no source edits.

Test plan

• npx vitest run claude-code/tests/auth-login-dispatch.test.ts → 42/42 pass
• npm run build → all bundles rebuild cleanly
• Local install + smoke tests (overlaid bundle/cli.js onto the global @deeplake/hivemind install):
  • hivemind workspace list → lists current org's workspaces
  • hivemind workspace switch <real-name> → switches successfully
  • hivemind workspace switch <bogus> → exits 1 with available list, no state mutation
  • hivemind workspace switch (no arg) → exits 1 with subcommand usage, no API call
  • hivemind workspace <bare-name> → exits 1 with the new usage line
  • hivemind workspace (no args) → exits 1 with the new usage line
  • hivemind whoami after each → confirms credentials state is consistent with the last successful switch
• Reviewer to verify in a multi-org account: hivemind org switch <other-org> from a workspace not present in the target org → resets to default with the warning message. (Needs an account with at least two orgs to repro; the unit tests cover the dispatcher logic deterministically.)

Breaking change

hivemind workspace <id> (the bare-target shortcut) no longer switches; it now exits 1 with usage. Replace with hivemind workspace switch <id>. The plural hivemind workspaces command and the /hivemind_switch_workspace OpenClaw slash command are unaffected.

Summary by CodeRabbit

Release Notes

• New Features

  • Added workspace list and workspace switch <name-or-id> subcommands for improved workspace management.
  • Implemented automatic workspace validation during organization switches; resets to default if the workspace is unavailable in the new organization.

• Documentation

  • Updated CLI usage documentation to reflect new workspace management subcommands.