Memory CRUD: add /api/neuron/memory/delete and /api/neuron/memory/update #4
Reference in New Issue
Block a user
Delete Branch "feat/memory-delete-update"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The UI needs full memory CRUD. The soul has create (handle_api_remember) plus the older /memory/forget and /memory/evolve, but nothing matching the UI's delete/update contract. This adds two endpoints, handlers in neuron-api.el next to the existing memory handlers, routes wired in routes.el following the existing /api/neuron/* dispatch.
POST /api/neuron/memory/delete - body {"id":"..."}
Hard delete. I checked the engram primitives: engram_forget (el_runtime.c) is a true delete - it removes the node and all incident edges from the store - so no soft-delete fallback was needed. Two differences from /memory/forget: the node's existence is verified first via engram_get_node_json (engram_forget silently no-ops on unknown ids, and a bad id should return an error, not fake success), and the response includes deleted:true. Protected identity/values nodes are blocked, same as the other accumulation-path handlers.
POST /api/neuron/memory/update - body {"id":"...","content":"..."}
Evolve-style update. The runtime exposes no in-place node mutation primitive (only node-create, strengthen, forget, connect - confirmed in el_runtime.h and lang/runtime/engram.el), so update creates a new Memory node and wires a supersedes edge to the prior one, same pattern as handle_api_evolve_knowledge. Unlike /memory/evolve, id is required and must reference an existing node; the create+link is delegated to handle_api_evolve_memory. Returns {"id":"","supersedes":"","ok":true}.
Verification: both files syntax-checked with elc --target=c (exit 0, no stderr; generated C contains the new handlers and route dispatch). Compile-verified only - local builds here cannot run the soul, so this needs Will's build to verify runtime behavior. The auto-generated .elh headers were left untouched; elc resolves imports from the .el source.
🤖 Generated with Claude Code
The UI needs full memory CRUD; the soul had create (handle_api_remember) and the older /memory/forget + /memory/evolve, but no endpoints matching the UI's delete/update contract. POST /api/neuron/memory/delete {"id"} Hard delete. engram_forget is a true delete primitive (removes the node and all incident edges from the engram store), so no soft-delete fallback is needed. Unlike /memory/forget, this checks the node exists first - engram_forget silently no-ops on unknown ids, and a bad id must return an error, not fake success. Protected identity/values nodes are blocked, same as the other accumulation-path handlers. POST /api/neuron/memory/update {"id","content"} Evolve-style update. The engram runtime has no in-place node mutation primitive (only node-create, strengthen, forget, connect), so update creates a new Memory node and wires a supersedes edge to the prior one, same pattern as handle_api_evolve_knowledge. Unlike /memory/evolve, id is required and must reference an existing node; create+link delegates to handle_api_evolve_memory. Returns {id, supersedes, ok}. Both files syntax-checked with elc --target=c (exit 0, no stderr). Compile-verified only - local builds cannot run the soul; needs Will's build for runtime verification. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>Approved. Building.