gm-skill 2.0.2502 → 2.0.2503

package/bin/plugkit-slim.wasm.sha256

@@ -1 +1 @@
-09cc6e9455e21eaffd40f86d32471f1487d0e6f034d36de93016b52bedac0793  plugkit-slim.wasm
+be3e9b6f26f95cb356628bafa84532dbd209182cfa3b40039e9d9104bdcbe7c9  plugkit-slim.wasm

package/bin/plugkit.version

@@ -1 +1 @@
-0.1.1192
+0.1.1194

package/bin/plugkit.wasm.sha256

@@ -1 +1 @@
-cb16c2345dfca7a309227741af44431281122616b0bfac87f4be8da58f2ed354  plugkit.wasm
+8c5318d25e2a6710bb3992155f9c76460da9aed04247c4ebf9aaa502bc6b62a8  plugkit.wasm

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.2502",
+  "version": "2.0.2503",
   "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.",
   "main": "index.js",
   "bin": {

package/gm-plugkit/plugkit-slim.wasm.sha256

@@ -1 +1 @@
-09cc6e9455e21eaffd40f86d32471f1487d0e6f034d36de93016b52bedac0793  plugkit-slim.wasm
+be3e9b6f26f95cb356628bafa84532dbd209182cfa3b40039e9d9104bdcbe7c9  plugkit-slim.wasm

package/gm-plugkit/plugkit.version

@@ -1 +1 @@
-0.1.1192
+0.1.1194

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.2502",
+  "version": "2.0.2503",
   "description": "Spool-dispatch orchestration engine with unified state machine, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",
@@ -17,5 +17,5 @@
   "publishConfig": {
     "access": "public"
   },
-  "plugkitVersion": "0.1.1192"
+  "plugkitVersion": "0.1.1194"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.2502",
+  "version": "2.0.2503",
   "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.",
   "author": "AnEntrypoint",
   "license": "MIT",

package/scripts/migrate-memory-to-tencentdb.mjs

@@ -13,7 +13,7 @@
 // namespace|text content-hash key scheme gm's memorize verb uses.
 //
 // Usage:
-//   node scripts/migrate-memory-to-tencentdb.mjs --project <path> [--namespace default] [--dry-run]
+//   node scripts/migrate-memory-to-tencentdb.mjs --project <path> [--namespace default] [--dry-run] [--archive]
 //
 // Requires the target project to have a live gm-plugkit spool watcher
 // (boots one if .gm/exec-spool is missing, same as any other gm session)
@@ -21,13 +21,29 @@
 // listed in gm.config.json -- this script drives the memorize verb, never
 // writes .gm/tencentdb-memory files directly, so the write always goes
 // through the same dedup/embed/index path a live agent dispatch would.
+//
+// This is the batch/CLI-driven migration path -- useful for migrating a
+// whole namespace outside a live agent session, and it applies the
+// derivable-state discard filter below (the verb-based path does not).
+// The `tencentdb-memory-import` verb (rs-plugkit's
+// wasm_dispatch/verbs.rs::tencentdb_memory_import) is the single-dispatch
+// alternative for use from within an already-running agent session; both
+// write through the same tencentdb_memory::write_cfg path and share the
+// same --archive/archive_source opt-in archiving behavior (see below).
+//
+// --archive (default off, matches the verb's archive_source default) moves
+// each successfully-migrated source .md file to
+// .gm/memories-archive-tencentdb/<namespace>/<filename> instead of leaving
+// it in place -- opt-in because the default stays a pure one-way copy (the
+// old backend keeps working for any namespace not also switched over).
 
-import { existsSync, readFileSync, readdirSync, statSync } from "node:fs";
-import { join } from "node:path";
+import { existsSync, readFileSync, readdirSync, statSync, mkdirSync, renameSync } from "node:fs";
+import { join, dirname } from "node:path";
 import { execFileSync } from "node:child_process";
 
 const args = process.argv.slice(2);
 const DRY_RUN = args.includes("--dry-run");
+const ARCHIVE = args.includes("--archive");
 const projectIdx = args.indexOf("--project");
 const PROJECT = projectIdx >= 0 ? args[projectIdx + 1] : process.cwd();
 const nsIdx = args.indexOf("--namespace");
@@ -37,6 +53,7 @@ const SPOOL_IN = join(PROJECT, ".gm", "exec-spool", "in");
 const SPOOL_OUT = join(PROJECT, ".gm", "exec-spool", "out");
 const MEMORIES_DIR = join(PROJECT, ".gm", "memories");
 const RS_LEARN_DB = join(PROJECT, ".gm", "rs-learn.db");
+const ARCHIVE_DIR = join(PROJECT, ".gm", "memories-archive-tencentdb", NAMESPACE);
 
 // Mirrors rs-plugkit's orchestrator/memorize.rs::is_derivable_state exactly
 // (pattern list kept in sync by hand -- both are small and rarely change;
@@ -143,6 +160,7 @@ function main() {
   let kept = 0;
   let discarded = 0;
   let errored = 0;
+  let archived = 0;
   const discardedSamples = [];
 
   for (const path of files) {
@@ -169,6 +187,16 @@ function main() {
       const resp = dispatchVerb("memorize", { text: parsed.text, namespace: NAMESPACE, kind: "l0" });
       if (resp.ok) {
         kept++;
+        if (ARCHIVE) {
+          try {
+            const dest = join(ARCHIVE_DIR, path.slice(path.lastIndexOf("/") + 1));
+            mkdirSync(dirname(dest), { recursive: true });
+            renameSync(path, dest);
+            archived++;
+          } catch (e) {
+            console.log(`[migrate]   WARN: migrated ${parsed.key} but failed to archive source ${path}: ${e.message}`);
+          }
+        }
       } else {
         errored++;
         console.log(`[migrate]   ERROR migrating ${parsed.key}: ${resp.error || JSON.stringify(resp)}`);
@@ -179,7 +207,7 @@ function main() {
     }
   }
 
-  console.log(`[migrate] summary: kept=${kept} discarded=${discarded} errored=${errored} total=${files.length}`);
+  console.log(`[migrate] summary: kept=${kept} discarded=${discarded} errored=${errored} archived=${archived} total=${files.length}`);
   if (discardedSamples.length) {
     console.log(`[migrate] sample of discarded entries (up to 10):`);
     for (const s of discardedSamples) {

package/skills/agent-memory/SKILL.md

@@ -71,23 +71,40 @@ evolution). This is for a project that already has gm-native memories
 namespace opts into the Tencent-compatible backend, so recall doesn't go
 cold on the switch.
 
-Dispatch the `tencentdb-memory-import` verb: `{"source_namespace":
-"default", "dest_namespace": "<routed-namespace>", "kind": "l1"}`. It reads
-every `.md` doc in the source namespace, re-embeds through gm's own
-384-dim pipeline, and writes into the destination via
-`tencentdb_memory::write_cfg`. It refuses up front unless
-`dest_namespace`'s resolved `memory.tencentdb_backend.vectors_db_dims` is
-exactly `384` -- gm's embedder cannot produce vectors at any other width,
-and a namespace configured for externally-embedded 768-dim content (the
-default) cannot safely receive them (recall queries that namespace through
-the project-resolved dim, not a per-import override, so a dim mismatch
-there is a real defect, not a formality). A project wanting both kinds of
+Two ways to run this migration -- same underlying write path
+(`tencentdb_memory::write_cfg`), pick whichever fits the situation:
+
+- **From within a live agent session**: dispatch the
+  `tencentdb-memory-import` verb: `{"source_namespace": "default",
+  "dest_namespace": "<routed-namespace>", "kind": "l1"}`. It reads every
+  `.md` doc in the source namespace and re-embeds through gm's own 384-dim
+  pipeline.
+- **Batch/CLI, outside an agent session**: `node
+  scripts/migrate-memory-to-tencentdb.mjs --project <path> --namespace
+  <ns> [--dry-run] [--archive]`. Same write path, but also applies the
+  derivable-state discard filter (git-log-derivable facts, dated audit
+  entries, historical framing) the verb does not -- prefer this for a bulk
+  migration where discarding superfluous content matters, and the verb for
+  a single dispatch from an already-running session.
+
+Both refuse up front unless the destination namespace's resolved
+`memory.tencentdb_backend.vectors_db_dims` is exactly `384` -- gm's
+embedder cannot produce vectors at any other width, and a namespace
+configured for externally-embedded 768-dim content (the default) cannot
+safely receive them (recall queries that namespace through the
+project-resolved dim, not a per-import override, so a dim mismatch there
+is a real defect, not a formality). A project wanting both kinds of
 content needs two separate `tencentdb_backend`-routed namespaces, each at
 its own dim.
 
-This is a one-way copy, not a move: the source `.md` files and their
-`rssearch_vectors` index rows are untouched, so the default backend keeps
-working for any namespace not also switched over.
+By default this is a one-way copy, not a move: the source `.md` files and
+their `rssearch_vectors` index rows are left untouched, so the default
+backend keeps working for any namespace not also switched over. Pass
+`archive_source: true` (verb) or `--archive` (script) to opt into moving
+each successfully-migrated source file to
+`.gm/memories-archive-tencentdb/<namespace>/<filename>` instead of leaving
+it in place -- content stays inspectable, but the live `.gm/memories/`
+corpus no longer duplicates what the new backend now serves.
 
 ## Verification (do this before declaring setup done)