@deeplake/hivemind 0.7.74 → 0.7.75

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.74"
+    "version": "0.7.75"
   },
   "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.74",
+      "version": "0.7.75",
       "source": {
         "source": "git-subdir",
         "url": "https://github.com/activeloopai/hivemind.git",
         "path": "claude-code",
-        "sha": "c36c84a01eeb6ebac5211c6ce485283977e484d1"
+        "sha": "46a3c497a22fbd89125eb0922d1648c6fc48eeaf"
       },
       "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.74",
+  "version": "0.7.75",
   "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. 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.>
+<Decide in two steps. STEP 1 \u2014 is the work this session set out to do actually finished? If it ended mid-task \u2014 a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging \u2014 then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step \u2014 never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 \u2014 if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be 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). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 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. 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.>
+<Decide in two steps. STEP 1 \u2014 is the work this session set out to do actually finished? If it ended mid-task \u2014 a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging \u2014 then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step \u2014 never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 \u2014 if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be 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). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 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. 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.>
+<Decide in two steps. STEP 1 \u2014 is the work this session set out to do actually finished? If it ended mid-task \u2014 a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging \u2014 then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step \u2014 never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 \u2014 if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be 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). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 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. 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.>
+<Decide in two steps. STEP 1 \u2014 is the work this session set out to do actually finished? If it ended mid-task \u2014 a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging \u2014 then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step \u2014 never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 \u2014 if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be 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). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 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. 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.>
+<Decide in two steps. STEP 1 \u2014 is the work this session set out to do actually finished? If it ended mid-task \u2014 a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging \u2014 then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step \u2014 never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 \u2014 if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be 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). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 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. 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.>
+<Decide in two steps. STEP 1 \u2014 is the work this session set out to do actually finished? If it ended mid-task \u2014 a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging \u2014 then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step \u2014 never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 \u2014 if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be 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). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 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.74".length > 0 ? "0.7.74" : null;
+  return "0.7.75".length > 0 ? "0.7.75" : 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.74"
+  "version": "0.7.75"
 }

package/openclaw/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hivemind",
-  "version": "0.7.74",
+  "version": "0.7.75",
   "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.74",
+  "version": "0.7.75",
   "description": "Cloud-backed persistent shared memory for AI agents powered by Deeplake",
   "type": "module",
   "repository": {

package/pi/extension-source/hivemind.ts

@@ -602,7 +602,7 @@ Format: **entity** (type) — what was done with it, its current state>
 <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.>
+<Decide in two steps. STEP 1 — is the work this session set out to do actually finished? If it ended mid-task — a feature only half-implemented, a build or test still failing, a fix written but not yet verified, a plan agreed but not executed, a blocker hit and unresolved, or an explicit "still need to.../next I'll..." left hanging — then it is NOT finished and you MUST write a single concrete imperative line naming the unfinished work (e.g. "Finish wiring the uint32 class_label scan binding and run its test"). The session's LAST messages are the strongest signal: if they describe or show work still in progress or something left to do, that IS the next step — never suppress a genuinely unfinished task, and do not demand "substantial consequences" for it. STEP 2 — if the core work IS finished, default to exactly: none and do not invent a follow-up to fill the section. Write none when the work reached a natural stopping point, only trivial/obvious/optional polish or cleanup remains, the "next step" would just be open-ended exploration, or the only thing left is administrative wrap-up (committing, pushing, opening/merging a PR, deploying, monitoring CI — treat ALL such wrap-up as ALREADY DONE). The sole exception that still warrants a next step on otherwise-finished work is a separate, important, non-obvious item a returning engineer would NOT realize on their own and would be materially harmed by missing.>
 
 IMPORTANT: Be exhaustive. Extract EVERY entity, decision, and fact.
 PRIVACY: Never include absolute filesystem paths in the summary.