runtime: restore engram_recall_json + cgi_* accessors (unblocks the soul build) #126
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: neuron-technologies/el#126
Reference in New Issue
Block a user
Delete Branch "fix/elc-rebuildable-compiler-builtins"
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?
neuron's soul calls
engram_recall_jsonandcgi_principal; both existed in the runtime neuron vendored (v1.0.0-20260501) and were absent here, so the soul could not link against current el at all.The trap this avoids. They look like redundant wrappers over one impl:
Not interchangeable. Documented at neuron-api.el:613 — search stays lexical because ~40 internal call sites pass a KEY and seven of them delete every record returned. Point those at a semantic matcher and they delete fuzzy matches. Conversely, pointing recall at search silently downgrades the mind's whole retrieval surface from semantic to lexical, with no error.
Implemented over
engram_activate(), which already IS the semantic path the oldwith_legs=1branch built by hand. Output shape matches search (flat array viaengram_emit_node_json) because callers parse search's shape.Verified: the soul compiles, links, boots, and serves
/healthagainst current el.Follow-up, not decided here: current el ships
engram_retrieve_geometric_json, apparently the intended successor. Repointing recall at it would remove the two-wrapper shape entirely and may be the right end state — but it's a behavioral change that must be measured againstneuron/tools/retrieval-eval/'s gold set, not assumed. This commit preserves existing behavior exactly.neuron's soul calls engram_recall_json (neuron-api.el:618, memory.el:80) and cgi_principal (studio.el:72). Both existed in the runtime neuron vendored (v1.0.0-20260501) and were absent here, so the soul could not link against current el at all. The dangerous part is what the obvious "fix" would have done. These look like redundant wrappers over one impl: engram_search_json(q, limit) -> eg_search_json_impl(q, limit, 0) LEXICAL engram_recall_json(q, limit) -> eg_search_json_impl(q, limit, 1) SEMANTIC They are not interchangeable, and the split is documented at neuron-api.el:613: search stays LEXICAL because ~40 internal call sites pass a KEY and seven of them DELETE every record returned. Point those at a semantic matcher and they delete fuzzy matches. Conversely, pointing recall at search silently downgrades the mind's entire retrieval surface from semantic to lexical — no error, just permanently worse recall. Implemented over engram_activate(), which in this runtime already IS the semantic path the old with_legs=1 branch built by hand (embeds the query via eg_embed_fetch, scores by cosine, then spreads activation one hop). Output shape matches engram_search_json — a flat array via engram_emit_node_json — because callers parse search's shape, not activate's envelope. Verified: neuron's soul now compiles and links against current el, boots, and serves /health with layers initialized. NOTE for follow-up: current el also ships engram_retrieve_geometric_json, a structure-first retrieval that appears to be the intended successor to recall. Repointing the two recall call sites at it may well be the right end state and would remove the two-wrapper shape entirely — but that is a behavioral change that must be measured against neuron/tools/retrieval-eval/'s gold set, not assumed. This commit preserves existing behavior exactly; it does not decide that question.