@try-works/dsh-memory 0.1.16 → 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.16",
+  "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/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;
 }