@try-works/dsh-memory 0.1.15 → 0.1.17

package/STATUS.md

@@ -84,15 +84,34 @@ your automated tasks and is in no git repository. The host DELETES a task when i
 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.
+Verified on disk: 396 tests pass, and `@try-works/dsh-memory@0.1.16` is published and installed
+byte-identical.
+
+- `backupTasks` against `E:\dsh-memory`: two cron tasks captured, a second pass `written=0`.
+- The layer is at `global/tasks/`. It first shipped at `<root>/tasks`; every test used a
+  self-consistent temp root and could not see the difference (`learning-0213`).
+- **The emptied-store drill, on a COPY of the real `schedule.json`:** emptied, backed up, restored
+  through the schedule plugin's own `createCronScheduleRecord`. Both tasks came back with their
+  expressions, zones and prompts (3597 and 2678 chars). The SECOND boot reported `add=0 present=2` —
+  which is the property that matters, since `create` mints a fresh id every time and id-based
+  de-duplication would duplicate every task on every boot.
+- The record -> request -> record round trip holds against the plugin's own builder; only the id
+  differs.
+- 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.**
+
+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
+no producer, `skipped` never written while unknown-kind tasks were dropped from the backup, an
+exits table read by nothing and wrong twice, and a manual restore that returned silently while
+reporting success.
 
 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.
@@ -126,7 +145,7 @@ 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
+- [ ] **Restart, then check the tasks layer — THE BLOCKER.** 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
@@ -183,7 +202,7 @@ 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.10`** on npm (0.1.0 was the first release; the Memory tab and the
+**`@try-works/dsh-memory@0.1.16`** 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.15",
+  "version": "0.1.17",
   "description": "Git-backed, workspace-scoped memory for the DeepSeek Harness (global layer + per-workspace layers)",
   "type": "module",
   "main": "src/index.js",

package/src/SYSTEM.template.md

@@ -254,6 +254,45 @@ Sync failures are never swallowed: a failed pull or push is logged, recorded in
 surfaced by `status()`, reported by `memory_sync`, and leaves a `state/CONFLICT.md` marker that
 the next clean sync clears.
 
+## 9b. The scheduled tasks layer
+
+`global/tasks/` is not a memory layer and holds no memories. It is a portable backup of the DSH
+scheduled tasks on this machine, and it exists because the schedule store is the only copy of them:
+it is in no git repository, and the host DELETES a task when the session that owns it stops. A task
+can therefore vanish with nothing to observe.
+
+One JSON file per task, plus a regenerated `index.md`. A file holds the task's record - id, kind,
+title, prompt, and the selector that says when it runs - and its lifecycle state. The owning session
+and the delivery history are deliberately NOT stored: they are machine-local, and carrying a session
+id to another machine would make a restored task fail, because the session it names does not exist
+there.
+
+Because the task files live in this store and are not gitignored, a push carries them to your other
+machines, where they are re-armed on boot.
+
+The states, and what each one means:
+
+| state | meaning |
+| --- | --- |
+| `active` | armed in the live store, waiting for its next occurrence |
+| `pending` | in the backup, not in the live store; a restore re-arms it |
+| `paused` | held back on purpose. Every automatic pass leaves it alone |
+| `stopped` | was armed, and its owning session stopped, so the host deleted it |
+| `failed` | was due and has still not delivered. The host records no failure of its own, so this is what is observable |
+| `orphaned` | armed, but the session that owns it no longer exists, so it can never fire |
+| `skipped` | captured, but its kind is not one we can re-arm, so a restore refuses it |
+| `done` | delivered, or its recurrence is exhausted |
+
+Two cadences, both off the write path. The **backup** runs with the sync cadence and is additive:
+it never deletes, so a stale backup cannot wipe a schedule. The **restore** runs once per process at
+the first real session, because a task needs a live session to own it, and it binds each restored
+task to that session - you are never asked which one. It matches tasks by CONTENT, not by id, since
+the schedule service mints a fresh id on every create.
+
+`memory_tasks` reports the whole picture and can `backup`, `restore`, `pause` or `resume` on
+demand. Holding a task back is a decision, and it outranks every automatic pass: a `paused` task is
+never silently re-armed.
+
 ## 10. Current state of this store
 
 {{storeState}}

package/src/tasks.js

@@ -361,9 +361,14 @@ function scheduleOf(record) {
   if (kind === 'cron') return 'cron ' + String(record.expression ?? '') + zone;
   if (kind === 'weekly') return 'weekly ' + JSON.stringify(record.weekly ?? {}) + zone;
   if (kind === 'daily') return 'daily ' + JSON.stringify(record.daily ?? {}) + zone;
-  if (kind === 'every') return 'every ' + String(record.every_seconds ?? '') + 's';
+  // The same camelCase/snake_case confusion as `after` above, in the same function. Writing a test
+  // to pin ONE of them surfaced the other.
+  if (kind === 'every') return 'every ' + String(record.everySeconds ?? '') + 's';
   if (kind === 'at') return 'at ' + String(record.scheduledAt ?? '');
-  if (kind === 'after') return 'after ' + String(record.after_seconds ?? '') + 's';
+  // `afterSeconds`, not `after_seconds` - the record uses camelCase, the CREATE REQUEST uses
+  // snake_case. The live index printed "after s" with the interval missing, which no test saw
+  // because no test rendered an `after` record.
+  if (kind === 'after') return 'after ' + String(record.afterSeconds ?? '') + 's';
   return kind;
 }