@try-works/dsh-memory 0.1.10 → 0.1.11

package/STATUS.md

@@ -76,6 +76,27 @@ How to tell loaded from not: ask the host. `memory_recover` used to reply *"unav
 context"* and now replies *"returned invalid output: value is not lossless JSON"*. The change of
 ERROR is the proof the first fix is loaded and the tool now executes — a different failure, one
 layer further along. The report fix in the last row is what remains pending.
+### The tasks layer (new since the last restart)
+
+A fifth layer, `tasks`, global only: `global/tasks/` holds one JSON file per DSH scheduled task
+plus a regenerated `index.md`. It backs up the schedule store, which is otherwise the only copy of
+your automated tasks and is in no git repository. The host DELETES a task when its owning session
+stops, so a task can vanish with nothing to observe; the backup runs on the sync cadence and a
+restore re-arms what is missing at the first session after boot.
+
+Verified on disk: 386 tests pass. `backupTasks` pointed at `E:\dsh-memory` wrote the layer for
+real — a second pass reported `written=0`, so it converges. `planRestore` against that layer and
+the live `schedule.json` returned `add=0 present=2`, which is the correct answer rather than an
+empty one: both tasks are in the live store, so a restore finds nothing to do.
+
+NOT verified until a restart: that the plugin itself runs either pass. The cadence
+(`maybeBackupTasks`) and the first-session restore (`maybeRestoreTasks`) have only been exercised
+through the wiring tests, where the schedule service is a stub and the store is temporary. Writing
+those files by calling the module is not the same claim as the plugin writing them.
+
+Known limitation, by design: the host deletes a task when its owning session stops, so a restored
+task lives as long as the session that adopted it. The boot restore is what re-arms them.
+
 ## NOT VERIFIED — treat these as unknown
 
 | item | what is actually known | what would settle it |
@@ -105,6 +126,12 @@ the flag on did not change what the user sees.
 
 ### Blocked on a restart
 
+- [ ] **Restart, then check the tasks layer.** It writes to ANOTHER plugin's storage through
+      that plugin's service, so it deserves a real observation rather than a passing suite. After
+      the restart, ask for `memory_tasks` and expect a report with `live: 2`, `backedUp: 2` and
+      `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.
@@ -156,7 +183,8 @@ Kept because the pattern matters more than the list: every one of these was foun
 | A test edit silently discarded | my own script re-read and overwrote the file before writing |
 ## Published
 
-**`@try-works/dsh-memory@0.1.0`** on npm. The unscoped name `dsh-memory` was already taken by an
+**`@try-works/dsh-memory@0.1.10`** on npm (0.1.0 was the first release; the Memory tab and the
+tasks layer each added several). The unscoped name `dsh-memory` was already taken by an
 unrelated DeepSeek Harness memory plugin, so the package publishes under the existing `@try-works`
 scope.
 

package/package.json

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

package/src/tasks.js

@@ -22,6 +22,7 @@ import { createHash } from 'node:crypto'
 import { existsSync, mkdirSync, readFileSync, readdirSync, writeFileSync } from 'node:fs'
 import { homedir } from 'node:os'
 import { join } from 'node:path'
+import { globalDir } from './store.js'
 import { slugify } from './workspace-key.js'
 
 /** Directory, under a scope root, holding one file per task plus the index. */
@@ -78,8 +79,15 @@ export function readState(value) {
   return STATES.includes(value) ? value : null;
 }
 
-/** The directory holding the task files for a scope root. */
-export function tasksDir(root) { return join(root, TASKS_DIR) }
+/**
+ * Where the task files live: under the GLOBAL scope, not the store root.
+ *
+ * The layer is global-only by design - DSH tasks are not repository-scoped - so it belongs beside
+ * global/semantic.md and the rest. Resolving it against the root instead put it at <root>/tasks,
+ * a directory nothing else in the store knows about and no index or sync rule covers. Caught by
+ * looking for global/tasks in a real store and finding nothing there.
+ */
+export function tasksDir(root) { return join(globalDir(root), TASKS_DIR) }
 
 /**
  * The fields that say WHEN a task runs. Used to tell one task from another.