@deeplake/hivemind 0.7.72 → 0.7.74

package/.claude-plugin/marketplace.json

@@ -6,18 +6,18 @@
   },
   "metadata": {
     "description": "Cloud-backed persistent shared memory for AI agents powered by Deeplake",
-    "version": "0.7.72"
+    "version": "0.7.74"
   },
   "plugins": [
     {
       "name": "hivemind",
       "description": "Persistent shared memory powered by Deeplake — captures all session activity and provides cross-session, cross-agent memory search",
-      "version": "0.7.72",
+      "version": "0.7.74",
       "source": {
         "source": "git-subdir",
         "url": "https://github.com/activeloopai/hivemind.git",
         "path": "claude-code",
-        "sha": "103bb69c8ecb83325c0c3e39029d22691c4f2d4a"
+        "sha": "c36c84a01eeb6ebac5211c6ce485283977e484d1"
       },
       "homepage": "https://github.com/activeloopai/hivemind"
     }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "hivemind",
   "description": "Cloud-backed persistent memory powered by Deeplake — read, write, and share memory across Claude Code sessions and agents",
-  "version": "0.7.72",
+  "version": "0.7.74",
   "author": {
     "name": "Activeloop",
     "url": "https://deeplake.ai"

package/codex/bundle/capture.js

@@ -1846,7 +1846,7 @@ Format: **entity** (type) \u2014 what was done with it, its current state>
 <Anything unresolved, blocked, or explicitly deferred>
 
 ## Next Steps
-<Default to writing exactly: none. Most sessions are DONE when they end \u2014 do not invent a next step just to fill this section. Only name one when the session left GENUINELY SUBSTANTIVE, non-obvious work that a knowledgeable engineer returning later would actually need flagged. Make a real judgment: is there unfinished work truly WORTH resuming? If not, write: none. Write none when the work reached a natural stopping point, is complete, only trivial/obvious follow-ups remain, the "next step" is just continuing an open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI) \u2014 treat all such wrap-up as ALREADY DONE. When a next step IS warranted, write a single concrete imperative line for the substantive work (e.g. "Wire the resume-brief Next Steps fallback and run the tests"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate \u2014 not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES \u2014 work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome \u2014 or a competent engineer would simply re-derive the work from the code, tests, comments, or git state \u2014 write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI \u2014 treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding \u2014 reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.

package/codex/bundle/stop.js

@@ -1126,7 +1126,7 @@ Format: **entity** (type) \u2014 what was done with it, its current state>
 <Anything unresolved, blocked, or explicitly deferred>
 
 ## Next Steps
-<Default to writing exactly: none. Most sessions are DONE when they end \u2014 do not invent a next step just to fill this section. Only name one when the session left GENUINELY SUBSTANTIVE, non-obvious work that a knowledgeable engineer returning later would actually need flagged. Make a real judgment: is there unfinished work truly WORTH resuming? If not, write: none. Write none when the work reached a natural stopping point, is complete, only trivial/obvious follow-ups remain, the "next step" is just continuing an open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI) \u2014 treat all such wrap-up as ALREADY DONE. When a next step IS warranted, write a single concrete imperative line for the substantive work (e.g. "Wire the resume-brief Next Steps fallback and run the tests"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate \u2014 not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES \u2014 work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome \u2014 or a competent engineer would simply re-derive the work from the code, tests, comments, or git state \u2014 write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI \u2014 treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding \u2014 reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.

package/cursor/bundle/capture.js

@@ -1846,7 +1846,7 @@ Format: **entity** (type) \u2014 what was done with it, its current state>
 <Anything unresolved, blocked, or explicitly deferred>
 
 ## Next Steps
-<Default to writing exactly: none. Most sessions are DONE when they end \u2014 do not invent a next step just to fill this section. Only name one when the session left GENUINELY SUBSTANTIVE, non-obvious work that a knowledgeable engineer returning later would actually need flagged. Make a real judgment: is there unfinished work truly WORTH resuming? If not, write: none. Write none when the work reached a natural stopping point, is complete, only trivial/obvious follow-ups remain, the "next step" is just continuing an open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI) \u2014 treat all such wrap-up as ALREADY DONE. When a next step IS warranted, write a single concrete imperative line for the substantive work (e.g. "Wire the resume-brief Next Steps fallback and run the tests"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate \u2014 not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES \u2014 work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome \u2014 or a competent engineer would simply re-derive the work from the code, tests, comments, or git state \u2014 write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI \u2014 treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding \u2014 reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.

package/cursor/bundle/session-end.js

@@ -269,7 +269,7 @@ Format: **entity** (type) \u2014 what was done with it, its current state>
 <Anything unresolved, blocked, or explicitly deferred>
 
 ## Next Steps
-<Default to writing exactly: none. Most sessions are DONE when they end \u2014 do not invent a next step just to fill this section. Only name one when the session left GENUINELY SUBSTANTIVE, non-obvious work that a knowledgeable engineer returning later would actually need flagged. Make a real judgment: is there unfinished work truly WORTH resuming? If not, write: none. Write none when the work reached a natural stopping point, is complete, only trivial/obvious follow-ups remain, the "next step" is just continuing an open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI) \u2014 treat all such wrap-up as ALREADY DONE. When a next step IS warranted, write a single concrete imperative line for the substantive work (e.g. "Wire the resume-brief Next Steps fallback and run the tests"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate \u2014 not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES \u2014 work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome \u2014 or a competent engineer would simply re-derive the work from the code, tests, comments, or git state \u2014 write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI \u2014 treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding \u2014 reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.

package/hermes/bundle/capture.js

@@ -1845,7 +1845,7 @@ Format: **entity** (type) \u2014 what was done with it, its current state>
 <Anything unresolved, blocked, or explicitly deferred>
 
 ## Next Steps
-<Default to writing exactly: none. Most sessions are DONE when they end \u2014 do not invent a next step just to fill this section. Only name one when the session left GENUINELY SUBSTANTIVE, non-obvious work that a knowledgeable engineer returning later would actually need flagged. Make a real judgment: is there unfinished work truly WORTH resuming? If not, write: none. Write none when the work reached a natural stopping point, is complete, only trivial/obvious follow-ups remain, the "next step" is just continuing an open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI) \u2014 treat all such wrap-up as ALREADY DONE. When a next step IS warranted, write a single concrete imperative line for the substantive work (e.g. "Wire the resume-brief Next Steps fallback and run the tests"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate \u2014 not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES \u2014 work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome \u2014 or a competent engineer would simply re-derive the work from the code, tests, comments, or git state \u2014 write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI \u2014 treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding \u2014 reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.

package/hermes/bundle/session-end.js

@@ -267,7 +267,7 @@ Format: **entity** (type) \u2014 what was done with it, its current state>
 <Anything unresolved, blocked, or explicitly deferred>
 
 ## Next Steps
-<Default to writing exactly: none. Most sessions are DONE when they end \u2014 do not invent a next step just to fill this section. Only name one when the session left GENUINELY SUBSTANTIVE, non-obvious work that a knowledgeable engineer returning later would actually need flagged. Make a real judgment: is there unfinished work truly WORTH resuming? If not, write: none. Write none when the work reached a natural stopping point, is complete, only trivial/obvious follow-ups remain, the "next step" is just continuing an open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI) \u2014 treat all such wrap-up as ALREADY DONE. When a next step IS warranted, write a single concrete imperative line for the substantive work (e.g. "Wire the resume-brief Next Steps fallback and run the tests"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate \u2014 not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES \u2014 work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome \u2014 or a competent engineer would simply re-derive the work from the code, tests, comments, or git state \u2014 write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI \u2014 treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding \u2014 reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.

package/openclaw/dist/index.js

@@ -1801,7 +1801,7 @@ function extractLatestVersion(body) {
   return typeof v === "string" && v.length > 0 ? v : null;
 }
 function getInstalledVersion() {
-  return "0.7.72".length > 0 ? "0.7.72" : null;
+  return "0.7.74".length > 0 ? "0.7.74" : null;
 }
 function isNewer(latest, current) {
   const parse = (v) => v.replace(/-.*$/, "").split(".").map(Number);

package/openclaw/openclaw.plugin.json

@@ -54,5 +54,5 @@
       }
     }
   },
-  "version": "0.7.72"
+  "version": "0.7.74"
 }

package/openclaw/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hivemind",
-  "version": "0.7.72",
+  "version": "0.7.74",
   "type": "module",
   "description": "Hivemind — cloud-backed persistent shared memory for AI agents, powered by DeepLake",
   "license": "Apache-2.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@deeplake/hivemind",
-  "version": "0.7.72",
+  "version": "0.7.74",
   "description": "Cloud-backed persistent shared memory for AI agents powered by Deeplake",
   "type": "module",
   "repository": {

package/pi/extension-source/hivemind.ts

@@ -601,6 +601,9 @@ Format: **entity** (type) — what was done with it, its current state>
 ## Open Questions / TODO
 <Anything unresolved, blocked, or explicitly deferred>
 
+## Next Steps
+<Default to writing exactly: none. When in any doubt at all, write none. Do NOT assume any base rate — not that next steps are usually warranted, nor that they usually are not; the right frequency depends entirely on the work and varies by session and use case. Judge THIS session purely on the gate below, never on how often the section "should" be filled. The bar is deliberately EXTREME: name a next step ONLY when failing to surface it would cause the project to MISS SOMETHING IMPORTANT WITH SUBSTANTIAL CONSEQUENCES — work silently lost, a known bug or regression shipping to users, data or state left corrupted/unsafe, a security or data-integrity hole left open, or a critical blocker/decision that a returning engineer would NOT rediscover on their own and would be materially harmed by not knowing. Before you write anything other than none, apply this gate: state to yourself the specific, concrete, substantial bad outcome that follows if the user NEVER sees this line. If you cannot name a concrete bad outcome — or a competent engineer would simply re-derive the work from the code, tests, comments, or git state — write none. A next step is NOT: a nice-to-have, a polish or cleanup item, a "could also" / "consider", the obvious natural continuation of the task, an open-ended exploration, a trivial or mechanical follow-up, or any administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI — treat ALL such wrap-up as ALREADY DONE). It is a flag raised solely because real, describable harm follows from silence. When (rarely) the gate is genuinely passed, write a single concrete imperative line that names the substantive work AND makes the stakes obvious (e.g. "Fix the uint32 class_label scan binding — reads silently return wrong values until corrected"). Administrative actions qualify ONLY when the session's core purpose itself was that release/ops task.>
+
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.
 LENGTH LIMIT: Keep the total summary under 4000 characters.`;