@try-works/dsh-memory 0.1.22 → 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,12 +150,14 @@ the flag on did not change what the user sees.
 
 ### Blocked on a restart
 
-- [ ] **Restart to load 0.1.21.** Published and installed: 0.1.21 is on npm (tarball byte-identical to
-      source) and installed in the profile (host.js byte-identical, guard at host.js:727/753). The
-      profile's minimumReleaseAge gate needed its dsh-memory exclusion extended to 0.1.21 in
-      pnpm-workspace.yaml, the same convention as every earlier version. The host half loads at
-      boot, so the guard only takes effect after a restart; installed 0.1.20 already appends WITH
-      the marker, so nothing is at risk while this waits.
+- [ ] **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
@@ -160,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.22",
+  "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

@@ -611,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)