gm-skill 2.0.2495 → 2.0.2496
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/gm-plugkit/package.json +1 -1
- package/gm.json +1 -1
- package/package.json +1 -1
- package/skills/agent-memory/SKILL.md +27 -0
package/gm-plugkit/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "gm-plugkit",
|
|
3
|
-
"version": "2.0.
|
|
3
|
+
"version": "2.0.2496",
|
|
4
4
|
"description": "Bootstrap and daemon-spawn tool for gm plugkit binary. Downloads the correct platform wasm, verifies SHA256, and launches agentplug-runner (the native wasm host) as the spool watcher daemon.",
|
|
5
5
|
"main": "index.js",
|
|
6
6
|
"bin": {
|
package/gm.json
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "gm-skill",
|
|
3
|
-
"version": "2.0.
|
|
3
|
+
"version": "2.0.2496",
|
|
4
4
|
"description": "Canonical universal harness — AI-native software engineering via skill-driven orchestration; bootstraps plugkit for task execution and session isolation. Install in any AI coding agent host.",
|
|
5
5
|
"author": "AnEntrypoint",
|
|
6
6
|
"license": "MIT",
|
|
@@ -62,6 +62,33 @@ Zero-config works for basic capability. Production tuning groups: `capture`, `ex
|
|
|
62
62
|
|
|
63
63
|
Use the migration tool documented at `MemoryCore/scripts/migrate-v2-to-v3/README.md` in the repo. New installs skip this.
|
|
64
64
|
|
|
65
|
+
### 4. Migrating gm's own memories into the `tencentdb_backend` store
|
|
66
|
+
|
|
67
|
+
Distinct from #3 above (that's the standalone system's own internal format
|
|
68
|
+
evolution). This is for a project that already has gm-native memories
|
|
69
|
+
(`.gm/memories/*.md`, written by `memorize`/`memorize-fire` before
|
|
70
|
+
`memory.tencentdb_backend` was enabled) and wants them carried over once a
|
|
71
|
+
namespace opts into the Tencent-compatible backend, so recall doesn't go
|
|
72
|
+
cold on the switch.
|
|
73
|
+
|
|
74
|
+
Dispatch the `tencentdb-memory-import` verb: `{"source_namespace":
|
|
75
|
+
"default", "dest_namespace": "<routed-namespace>", "kind": "l1"}`. It reads
|
|
76
|
+
every `.md` doc in the source namespace, re-embeds through gm's own
|
|
77
|
+
384-dim pipeline, and writes into the destination via
|
|
78
|
+
`tencentdb_memory::write_cfg`. It refuses up front unless
|
|
79
|
+
`dest_namespace`'s resolved `memory.tencentdb_backend.vectors_db_dims` is
|
|
80
|
+
exactly `384` -- gm's embedder cannot produce vectors at any other width,
|
|
81
|
+
and a namespace configured for externally-embedded 768-dim content (the
|
|
82
|
+
default) cannot safely receive them (recall queries that namespace through
|
|
83
|
+
the project-resolved dim, not a per-import override, so a dim mismatch
|
|
84
|
+
there is a real defect, not a formality). A project wanting both kinds of
|
|
85
|
+
content needs two separate `tencentdb_backend`-routed namespaces, each at
|
|
86
|
+
its own dim.
|
|
87
|
+
|
|
88
|
+
This is a one-way copy, not a move: the source `.md` files and their
|
|
89
|
+
`rssearch_vectors` index rows are untouched, so the default backend keeps
|
|
90
|
+
working for any namespace not also switched over.
|
|
91
|
+
|
|
65
92
|
## Verification (do this before declaring setup done)
|
|
66
93
|
|
|
67
94
|
1. Confirm version prerequisites: `node -v` (`>=22.16`), and `openclaw --version` (`>=2026.3.13`) if using the OpenClaw plugin path.
|