Write commands report success and persist nothing (pattern-store, trajectory-*, workers create/dispatch); workers cleanup deletes records the read commands cannot see

Summary

Several write commands print a success message and persist nothing. They exit 0, so a script cannot tell the difference between working and not working. One of them (workers cleanup) deletes records that no read command can see, which is worse than a no-op.

Verified on agentic-flow 2.1.0, node v22.23.0, darwin arm64, in an empty directory.

1. hooks intelligence pattern-store discards the pattern

$ npx agentic-flow hooks intelligence pattern-store \
    --task "zorblatt marker task" --resolution "zorblatt marker resolution" --score 0.95
💾 Pattern Stored
   Task: zorblatt marker task...
   Score: 95%
   Index: HNSW (150x faster retrieval)

$ npx agentic-flow hooks intelligence pattern-search "zorblatt marker"
   Found: 0 patterns

$ grep -rl zorblatt . ~/.agentic-flow
(no matches)

"zorblatt" is a nonsense token, so this cannot be a false negative from fuzzy matching — the string is absent from every file the tool writes. .agentic-flow/intelligence.json's patterns count is unchanged across the call.

2. hooks intelligence trajectory-* records nothing, and validates nothing

trajectory-start returns ID: 0 and the id never increments. trajectory-step prints "📍 Step Recorded". trajectory-end prints "🏁 Trajectory Completed — Learning: EWC++ consolidation applied".

After a full start → 2 steps → end cycle, .agentic-flow/intelligence.json has no trajectories key at all (keys are patterns, sequences, memories, dirPatterns, errorPatterns, metrics, pretrained), and hooks intelligence stats reports Trajectories: 0, Active: 0.

The decisive case — ending a trajectory that was never started:

$ npx agentic-flow hooks intelligence trajectory-end 987654 --success --quality 0.9
🏁 Trajectory Completed
   ✅ Success
   Quality: 90%
   Learning: EWC++ consolidation applied

No lookup, no error. "EWC++ consolidation applied" is printed for a trajectory that does not exist, so it is a literal string rather than a report.

3. workers create does not persist, which deadlocks workers run

$ npx agentic-flow workers create zorblatt-check --preset security-scan --triggers "zorblatt,vuln"
✅ Created custom worker: zorblatt-check
Phases: file-discovery → security-analysis → secret-detection → dependency-discovery → report-generation

$ npx agentic-flow workers triggers | grep zorblatt      # absent
$ grep -rl zorblatt-check .agentic-flow ~/.agentic-flow   # no matches

The consequence is that workers run can never execute anything:

$ npx agentic-flow workers run quick-scan
"quick-scan" is a preset. Create a worker first: workers create my-worker --preset quick-scan

$ npx agentic-flow workers run ultralearn
Custom worker not found: ultralearn
Available workers: none

run accepts only custom workers; custom workers come only from create; create does not persist. Available workers: none is therefore permanent.

Worth noting the non-persistence is the only thing wrong here — preset resolution, trigger expansion and validation all work correctly, including a good error for an unknown preset.

4. workers dispatch reports a worker id that no read command recognises

$ npx agentic-flow workers dispatch "ultralearn how authentication works"
⚡ Background Workers Spawned:
  • ultralearn: worker-01KZ2P51

$ npx agentic-flow workers status
│ No workers found │
$ npx agentic-flow workers status worker-01KZ2P51
Worker not found: worker-01KZ2P51
$ npx agentic-flow workers status --json
[]

No process is spawned (pgrep shows nothing), and AGENTIC_FLOW_WORKERS_ENABLED=true AGENTIC_FLOW_MAX_WORKERS=10 makes no difference. dispatch-prompt behaves the same and returns {"dispatched":true,...}, which is the form a hook would consume.

The trigger parsing itself is correct — it extracts keyword and topic and resolves the right preset config. Only the spawn is missing.

5. workers cleanup deletes records the read commands cannot see

This is the one I would prioritise:

$ npx agentic-flow workers cleanup --age 24
✅ Cleaned up 1 old worker records

status, results and stats all report empty ([], [], Total Workers: 0) both before and after. So worker records do exist somewhere, cleanup can enumerate and delete them, and every read path is blind to them. Whatever store cleanup operates on is not the one the read commands query — meaning data is being silently deleted that users cannot inspect first.

(Minor: "1 old worker records" is pluralised on a count of 1.)

Why this is hard to notice

Every one of these exits 0 and prints a checkmark. The read commands are honest — status, results, stats and pattern-search all correctly report empty — so the failure is only visible if you compare a write against a subsequent read. A user following the README sees nothing but success messages.

Suggested fix

Beyond the underlying persistence, two cheap changes would have surfaced all of this:

1. Exit non-zero when a write does not land, and do not print a success glyph for it.
2. Validate ids before acting on them. trajectory-end on an unknown id should error, as workers status <id> already correctly does with "Worker not found".

A likely common root cause is filed separately: npm run build fails in a clean clone with 12 TypeScript errors and emits no dist/, while the published package's build script wraps every stage in || true.

Start by reproducing the pattern-store, trajectory, and workers create/dispatch/cleanup commands, then compare their output with pattern-search, stats, status, results, and triggers. Trace the command entry points and persistence paths to determine why writes are invisible to reads. Done means successful writes are readable, unknown trajectory IDs are rejected, dispatch creates observable workers, cleanup targets the same store, and failed writes do not report success.