@try-works/dsh-memory 0.1.10 → 0.1.12

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.12",
   "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.
@@ -392,9 +400,13 @@ export function readScheduleStore(path) {
  * A task whose kind we do not recognise is SKIPPED, not written: storing it would mean restoring
  * it later without understanding it. It is reported, so the omission is visible.
  */
-export function backupTasks(root, { schedulePath, now = Date.now(), nowIso } = {}) {
+export function backupTasks(root, { schedulePath, now = Date.now(), nowIso, sessions } = {}) {
   const at = nowIso ?? new Date(now).toISOString()
   const live = readScheduleStore(schedulePath ?? defaultSchedulePath())
+  // Read once per pass, not per task: it is a directory walk, and every row asks the same question.
+  // Injectable so a test can state the world instead of inheriting this machine's: `null` means
+  // the question cannot be answered and no row is called orphaned.
+  const sessionSet = sessions === undefined ? sessionIdsOnDisk() : sessions
   const before = listTasks(root)
   if (live.error !== null) {
     // The index is still rewritten, so a page from an earlier pass cannot sit on disk describing a
@@ -421,7 +433,11 @@ export function backupTasks(root, { schedulePath, now = Date.now(), nowIso } = {
     // A held-back task stays held back across every backup: that state is the user's decision, and
     // a routine pass must not overwrite it with a derived one.
     const held = previous && previous.stateKnown && previous.state === TASK_STATES.PAUSED
-    const derived = deriveState({ stored: held ? TASK_STATES.PAUSED : null, live: task, now })
+    // Without this the ORPHANED state exists in the vocabulary and is never produced by any real
+    // pass - reachable from a unit test and from nothing else. `sessions === null` means the
+    // sessions directory is absent and we cannot tell, so the row is left as active.
+    const ownerResolvable = sessionSet === null || task.sessionId === undefined ? true : sessionSet.has(task.sessionId)
+    const derived = deriveState({ stored: held ? TASK_STATES.PAUSED : null, live: task, now, ownerResolvable })
     writeTask(root, record, derived.state, previous ? previous.backedUpAt : at)
     if (previous) refreshed += 1
     else written += 1
@@ -534,3 +550,37 @@ export function planRestore(root, { liveTasks = [], now = Date.now() } = {}) {
   }
   return { add, present, paused, refused, unreadable }
 }
+
+/** The directory DSH keeps session records in, beside the schedule store's home. */
+export function sessionsRoot(home = homedir()) {
+  const configured = process.env.DSH_HOME
+  const dshHome = configured && configured !== '' ? configured : join(home, '.dsh')
+  return join(dshHome, 'sessions')
+}
+
+/**
+ * Every session id that still has a record on disk.
+ *
+ * Used to tell ORPHANED from ACTIVE. A live task is armed against the session that created it, and
+ * the runtime resolves an agent from that id before every delivery (schedule runtime.ts:101) - so
+ * a task whose session is gone is a row that will never fire while still occupying the store. The
+ * backup cannot see the runtime, but it can see whether the session still exists.
+ *
+ * @returns a Set, or null when the sessions directory is absent
+ *
+ * Null rather than an empty set on purpose: no sessions directory means we cannot tell, and an
+ * empty set would mark every task on the machine orphaned. Refusing to guess is the rule here.
+ */
+export function sessionIdsOnDisk(home = homedir()) {
+  const root = sessionsRoot(home)
+  if (!existsSync(root)) return null
+  const ids = new Set()
+  let projects
+  try { projects = readdirSync(root) } catch { return null }
+  for (const project of projects) {
+    let sessions
+    try { sessions = readdirSync(join(root, project)) } catch { continue }
+    for (const id of sessions) ids.add(id)
+  }
+  return ids
+}