@try-works/dsh-memory 0.1.21 → 0.1.23

package/STATUS.md

@@ -62,6 +62,8 @@ Observed in the running host. Each row names the effect that was seen, not a cla
 | `memory_recover` is wired | calling it no longer answers "unavailable in this context"; it reaches output validation |
 | Session logs are searchable in principle | zstd, not encrypted; 368 logs, 740MB compressed, ~2.96GB plaintext |
 | `memory/map` events carry `ignorable: true` | the live session log's own event is marked, and both dsh-memory logs pass the harness's `validateStoredEvents` — the exact check that refused session-cc4795a7 with "unknown to this harness and not marked ignorable" |
+| 0.1.21 guard is LOADED | the 2026-10-11 06:01+08 restart booted the installed 0.1.21; `map-publish ok:true` events follow boot, so the guarded publisher runs. The suppression branch itself cannot be observed on this harness — it only fires on one that does not stamp the marker |
+| Boot tasks backup + restore ran live | at boot (2026-10-10T22:03:14Z) the log records `tasks-backup ok:true written:0 refreshed:5` and `tasks-restore ok:true owner:session-6e8d9a10 present:5 added:0 paused:0` — the restore reached the schedule service, found everything present, and duplicated nothing |
 
 ## WRITTEN but NOT LOADED
 
@@ -73,6 +75,7 @@ Implemented and tested on disk. The running host predates them, so none of this
 | `hostExtras(host)` as one source | `index.js` and the wiring test shared a copied list that drifted | the test now derives extras from the host object |
 | `memory_recover` report omits its `entries` field rather than blanking it | the old line added `entries: undefined`, which is NOT valid JSON, so the harness rejected the whole result | the new guard round-trips every tool output; reintroducing it fails with `value.entries is undefined` |
 | Publisher stops when the harness does not stamp `ignorable` (0.1.21) | ≤0.1.19 appended `memory/map` WITHOUT the marker into ten real session logs, so every later load of those sessions failed ("unknown to this harness and not marked ignorable"). The guard checks the RETURN VALUE of `session.append` and suppresses publishing for that session at the first refusal, instead of poisoning the log | 403 tests pass; the new test drives a harness-shaped stub that returns an unstamped event and asserts the next turn appends nothing, even with a changed store and a passed throttle |
+| Git runner resolves the subprocess service lazily (0.1.22) | `makeGitRunner` probed `ctx.get('subprocess')` ONCE at wire time; cordis `get()` only returns services whose providing fiber is ACTIVE (vendor/cordis reflect.ts), so during mount it returns undefined, git stayed null forever, and every git path was dead: zero sync events ever recorded, and `history-check` threw `Cannot read properties of null (reading 'run')` hourly since 2026-10-06. The runner now re-probes at use and reports an honest reason while absent | 405 tests pass; the new test pins no-probe-at-mount, an honest refusal while the service is absent, and working ingest after it appears |
 
 How to tell loaded from not: ask the host. `memory_recover` used to reply *"unavailable in this
 context"* and now replies *"returned invalid output: value is not lossless JSON"*. The change of
@@ -102,12 +105,12 @@ byte-identical.
 - No task file leaks into memory search, checked by building the index over a store holding the layer.
 - `SYSTEM.md` names the layer, its path, `memory_tasks`, and all eight states.
 
-**NOT verified, and the log proves it.** `E:\dsh-memory\logs\memory.log` holds 3976 entries and
-ZERO `tasks-backup` or `tasks-restore` ones, while the running host is 3h24m old and predates every
-install from 0.1.10 on. The plugin is alive — it is injecting, capturing and consolidating — it has
-simply never executed this code. The cadence and the boot restore have only ever run inside the
-wiring tests, where the schedule service is a stub and the store is temporary. **Calling the module
-directly is not the same claim as the plugin calling it.**
+**VERIFIED live, 2026-10-11 boot.** `logs/memory.log` at 2026-10-10T22:03:14Z records a real
+`tasks-backup ok:true written:0 refreshed:5` and a real `tasks-restore ok:true present:5 added:0
+paused:0` from the running host — the cadence and the boot restore executed outside the test
+harness for the first time, reached the schedule service, found all five tasks present, and
+duplicated nothing (`added: 0`, which is the de-duplication property the drill cared about). The
+paragraph below is retained as the record of what "unverified" looked like before this boot.
 
 Seven defects were found by asking what the REAL path does, and not one by an existing test: the
 empty-string config fallback, the wrong directory, a fixture-coincidence assertion, `orphaned` with
@@ -147,11 +150,14 @@ the flag on did not change what the user sees.
 
 ### Blocked on a restart
 
-- [ ] **Publish 0.1.21, install, restart.** The guard against unmarked `memory/map` events is
-      written and tested (403 pass) but the publish needs npm credentials that were not available
-      in this session (`npm publish` → ENEEDAUTH). Installed 0.1.20 already appends WITH the
-      marker, so nothing is at risk while this waits; the guard only protects against a harness
-      older than the `append(type, data, { ignorable: true })` option.
+- [ ] **Restart to load 0.1.22.** The lazy git-runner fix is published; install is pending the
+      registry finishing its staged publish (E409 "previously staged version" on retry). Once the
+      profile install lands and the host restarts, the hourly `history-check ok:false null.run`
+      should become either a working ingest or an honest `reason` — and git sync gets its first
+      real chance to run ever.
+- [x] **Restart to load 0.1.21 — DONE 2026-10-11 06:01+08.** The host booted the installed 0.1.21;
+      `map-publish ok:true` events follow boot and the boot tasks backup/restore ran live (see
+      LIVE table).
 - [x] **Restart, then check the tasks layer — DONE 2026-10-09.** The restart confirmed it. See the
       tasks-layer section above for the two log entries and the counts. It writes to ANOTHER plugin's storage through
       that plugin's service, so it deserves a real observation rather than a passing suite. After
@@ -159,13 +165,14 @@ the flag on did not change what the user sees.
       `pending.present: 2`. Then check `logs/memory.log` for a `tasks-backup` entry and a
       `tasks-restore` entry: the first should say `refreshed: 2`, the second `present: 2, added: 0`.
       An `added` above zero would mean de-duplication failed and it duplicated a task.
-- [ ] **Restart again.** The previous restart worked: `memory_recover` went from "unavailable in
-      this context" to executing. It now fails one layer further on, at output validation, which
-      is fixed on disk. Confirm by calling `memory_recover({})` and getting a report, not an error.
+- [x] **Restart again — DONE 2026-10-11.** After the 06:01+08 restart, `memory_recover({})` answers
+      with a report: 75 candidates stopped with missing material, 75 recoverable now, 0 need
+      approval. The output-validation fix is live.
 
 ### Recovery (needs the restart)
 
-- [ ] `memory_recover({})` — report only, no cost.
+- [x] `memory_recover({})` — DONE 2026-10-11: report-only call returned a clean report (75
+      recoverable, 0 oversized), no error.
 - [ ] `memory_recover({ limit: 1 })` — **prove it end to end on one** before spending on 76.
 - [ ] Then the rest in batches of ~10. Cost is roughly 76-150 model calls plus consolidation,
       against **52 MB** of logs. All 76 are under the 8 MB approval threshold, so nothing will

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@try-works/dsh-memory",
-  "version": "0.1.21",
+  "version": "0.1.23",
   "description": "Git-backed, workspace-scoped memory for the DeepSeek Harness (global layer + per-workspace layers)",
   "type": "module",
   "main": "src/index.js",

package/src/host.js

@@ -29,15 +29,28 @@ const TASKS_BACKUP_MS = 30 * 60 * 1000
 const IDLE_TICK_MS = 60_000
 
 function makeGitRunner(ctx) {
-  const subprocess = ctx.get('subprocess')
-  if (!subprocess || typeof subprocess.resolveExecutable !== 'function' || typeof subprocess.spawn !== 'function') return null
+  // The subprocess service is NOT resolvable during apply. cordis ctx.get() only returns an
+  // implementation whose PROVIDING FIBER IS ACTIVE (vendor/cordis reflect.ts _getImpl), and no
+  // fiber is active while the composition is still mounting. The first version probed here,
+  // once, at wire time - it cached undefined, returned null, and every git path was dead
+  // forever: zero sync events ever recorded, and the history hook threw "Cannot read
+  // properties of null (reading 'run')" every hour. The service exists by first USE (an agent
+  // pre-step, minutes after boot), so resolve lazily and keep re-probing until it appears.
+  let subprocess
+  const probe = () => {
+    const svc = ctx.get('subprocess')
+    if (svc && typeof svc.resolveExecutable === 'function' && typeof svc.spawn === 'function') subprocess = svc
+    return subprocess
+  }
   let executablePromise
   const run = async (argv, opts = {}) => {
-    if (!executablePromise) executablePromise = subprocess.resolveExecutable('git', undefined, undefined).catch(() => null)
+    const svc = probe()
+    if (!svc) return { exitCode: 127, stdout: '', stderr: 'subprocess service unavailable' }
+    if (!executablePromise) executablePromise = svc.resolveExecutable('git', undefined, undefined).catch(() => null)
     const executable = await executablePromise
     if (!executable) return { exitCode: 127, stdout: '', stderr: 'git unavailable' }
     try {
-      const handle = subprocess.spawn({
+      const handle = svc.spawn({
         argv: [executable, ...argv],
         cwd: opts.cwd,
         stdio: { stdin: 'ignore', stdout: { maxBytes: 4 * 1024 * 1024 }, stderr: { maxBytes: 16 * 1024 } },
@@ -52,7 +65,9 @@ function makeGitRunner(ctx) {
       return { exitCode: 1, stdout: '', stderr: String(error) }
     }
   }
-  return new GitRunner(run)
+  const runner = new GitRunner(run)
+  runner.available = () => Boolean(probe())
+  return runner
 }
 
 function resolveTarget(agent) {
@@ -235,6 +250,9 @@ export function wireHost(ctx, store, cfg) {
     if (!workspace) return { ok: false, reason: 'no workspace for this session', added: 0 }
     const path = readAssociations(store.root)[workspace]?.path
     if (!path) return { ok: false, reason: 'no local folder associated with ' + workspace, added: 0 }
+    // Report the honest reason instead of throwing: a hook that throws hourly because a service
+    // was probed too early must never look like a repository with no commits.
+    if (!git.available()) return { ok: false, reason: 'subprocess service unavailable', added: 0 }
     return ingestHistory(store.root, workspace, path, (argv, opts) => git.run(argv, opts), { limit })
   }
 
@@ -570,6 +588,9 @@ export function wireHost(ctx, store, cfg) {
   }
 
   async function runSync(force = false) {
+    // Not a git failure: no CONFLICT marker, no status record - the capability simply is not
+    // there yet. available() re-probes, so this is true only while the host is still mounting.
+    if (!git.available()) return { initialized: false, committed: false, synced: false, error: 'subprocess service unavailable' }
     const branch = cfg.gitBranch || 'main'
     const hasGit = existsSync(join(store.root, '.git'))
     if (!hasGit) {
@@ -590,6 +611,20 @@ export function wireHost(ctx, store, cfg) {
       catch (error) { ctx.logger.warn('dsh-memory: commit failed: ' + (error && error.message)) }
     }
     if (cfg.gitRemote && (force || scheduler.shouldSync())) {
+      // The origin is CONFIGURED, not necessarily INSTALLED. remoteAdd ran only on the fresh-repo
+      // path above, so a store that already had a .git - which every store that has ever committed
+      // does - went straight to `pull origin` with no origin at all and failed on 'no such remote',
+      // leaving memory.json and the profile config both claiming a remote git had never heard of.
+      const configured = await git.remoteGet(store.root).catch(() => null)
+      const installed = configured && configured.exitCode === 0 ? String(configured.stdout ?? '').trim() : ''
+      if (installed !== cfg.gitRemote) {
+        const applied = installed === ''
+          ? await git.remoteAdd(store.root, cfg.gitRemote).catch(() => null)
+          : await git.remoteSet(store.root, cfg.gitRemote).catch(() => null)
+        if (!applied || applied.exitCode !== 0) {
+          return failSync('remote', { ok: false, reason: (applied && (applied.stderr || applied.stdout)) || 'could not set origin to ' + cfg.gitRemote }, committed)
+        }
+      }
       const pulled = await git.pull(store.root, branch).catch((error) => ({ code: -1, stderr: String((error && error.message) || error) }))
       const pullVerdict = classifyGitResult(pulled)
       if (!pullVerdict.ok) return failSync('pull', pullVerdict, committed)
@@ -764,7 +799,7 @@ export function wireHost(ctx, store, cfg) {
   }
 
   function maybeSync() {
-    if (syncInFlight || !git) return
+    if (syncInFlight || !git.available()) return
     if (!scheduler.shouldCommit() && !scheduler.shouldSync()) return
     syncInFlight = true
     // Sync wrote its outcome only to state/sync.json, so the log could not answer whether the