runtime: extract engram_text.c, and repair 10 harnesses that could not link #162
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: neuron-technologies/el#162
Reference in New Issue
Block a user
Delete Branch "fix/runtime-extract-text"
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?
Stacked on #161 (which stacks on #160). Base is
fix/runtime-growth-guard. This PR's own diff is 16 files.Root cause
Same shim-never-retired + false-instruction root cause as #160/#161. This is the first concern actually moved out, under the ratchet from #161.
What changed
engram_text.{c,h}— query tokenization, candidate-token hygiene, word-boundary matching, and the text-damage signature. Four functions, moved verbatim: onlystaticwas dropped and each doc comment travelled with the code. They touch no EL value type and no engram store type — plain C over<ctype.h>/<string.h>over char buffers. They were neverel_runtime.c's business.lang/runtime/el_runtime.cBUDGETmax_lines 20527/max_engram_fns 279The move is deliberately small. It exists to prove the mechanism end to end before anything large depends on it — and it did:
lang/runtime/SOURCESwas one line, and every build path picked it up.install.sh's standalone list. The exact class of drift it was written for, on its first real change, before the commit rather than after a broken SDK shipped.Why only 100 lines — and what actually blocks the rest
Measured, not estimated. Of 273 engram-domain functions in
el_runtime.c(~9,700 lines), only 75 (~1,058 lines) can move today, and they are scattered rather than clustered. One fact blocks the rest:So every engram function taking an
EngramNode*— 109 of 273 by direct type reference — cannot compile inengram_store.cuntil those types move to a shared header.That extraction is the real Stage 3 enabler and deserves its own change. It touches the most load-bearing struct in the system, and doing it in the same commit as a code move would make a regression impossible to bisect.
Repaired: 10 engram harnesses that could not link
Not new breakage from this move — verified against unmodified
dev, whereel_runtime.c+engram_store.calone already failed with undefined symbols. They had been dead for as long asel_runtime.chas been calling into the siblings, and nothing noticed because nothing ran them.run_m3_parity,run_m7_traversal,run_m35_hebb_persist,run_interoception_p0..p5— now build from$(scripts/el-runtime-sources.sh)run_wal_tests— its two TUs#include "el_runtime.c"directly, so it links the siblings only; addingel_runtime.cto that link line would define every symbol twice(Worth recording: the runtime does have an
#include'd.c, inengram/test/test_wal.cand the generatedtest_failloud.c.)Verified locally — every one of these was run, not assumed
run_m3_parityrun_m7_traversalrun_m35_hebb_persistrun_interoception_p0..p5run_wal_testsengram/src/server.elAlso fixes a block comment left unterminated by the extraction (the deleted range carried its closing
*/), restoring the compile to its single pre-existing-Wcommentwarning.What remains
EngramNode/EngramEdge/EngramStore/EngramLayer/EngramWal/EngramIdSlotinto a shared header. Unblocks the other ~8,700 lines. Recommended next.BUDGETafter each move.elcemit#include el_seed.hand dropelb's hardcoded runtime path — finishing the 2026-05-03 migration.Coordination
Does not touch
engram/src/server.el,peripheral/, orelp/. Changes underengram/test/only. Nolang/AGENTS.mdchange here, so no interaction with PR #157.First concern moved out of el_runtime.c under the ratchet, and the move is deliberately small: it exists to prove the mechanism end to end before anything large depends on it. engram_text.{c,h} — query tokenization, candidate-token hygiene, word-boundary matching, and the text-damage signature. Four functions, moved verbatim; only `static` was dropped and each doc comment travelled with the code. They touch no EL value type and no engram store type: plain C over <ctype.h>/<string.h> over char buffers. They were never el_runtime.c's business. el_runtime.c 20,527 -> 20,427 lines (BUDGET max_lines ratcheted down) engram fns 279 -> 275 (BUDGET max_engram_fns ratcheted down) The Stage 1 extension point worked as designed: adding the file to lang/runtime/SOURCES was one line, and every build path picked it up. The Stage 2 drift guard then caught that I had NOT added it to install.sh's standalone list — the exact class of drift it was written for, on its first real change, before the commit rather than after a broken SDK shipped. WHY ONLY 100 LINES, AND WHAT ACTUALLY BLOCKS THE REST Measured, not estimated: of 273 engram-domain functions in el_runtime.c (~9,700 lines), only 75 (~1,058 lines) can move today, and they are scattered rather than clustered. The blocker is a single fact: EngramNode, EngramEdge, EngramStore, EngramLayer, EngramWal and EngramIdSlot are typedef'd INSIDE el_runtime.c. No sibling can see them. engram_store.h defines a SEPARATE serializable "node view" struct and maps between the two. So every engram function that takes an EngramNode* — which is most of them, 109 of 273 by direct type reference — cannot compile in engram_store.c until those types move to a shared header. That extraction is the real Stage 3 enabler and it deserves its own change: it touches the most load-bearing struct in the system, and doing it in the same commit as a code move would make a regression impossible to bisect. REPAIRED: 10 engram harnesses that had silently stopped linking Not new breakage from this move — verified against unmodified dev, where el_runtime.c + engram_store.c alone already failed with undefined symbols. They had been dead for as long as el_runtime.c has been calling into the siblings, and nothing noticed because nothing ran them. run_m3_parity, run_m7_traversal, run_m35_hebb_persist, run_interoception_p0..p5 — now build from $(scripts/el-runtime-sources.sh) run_wal_tests — its two TUs #include "el_runtime.c" directly, so it links the SIBLINGS ONLY; adding el_runtime.c to that link line would define every symbol twice (That #include'd .c is worth recording: the runtime does have one, in engram/test/test_wal.c and the generated test_failloud.c.) Verified locally — every one of these was run, not assumed: * m3_parity ............ PASS, incl. ASan+UBSan clean across seed/on/reboot * m7_traversal ......... PASS * m35_hebb_persist ..... PASS (the gate over the original prod hebb bug) * interoception p0..p5 . PASS (all six) * wal_tests ............ 66 passed, 0 failed, + fail-loud exit check * self-host fixpoint ... byte-identical, AND the emitted C is byte-identical to the pre-move compiler output — the move changes nothing the compiler produces * engram/src/server.el . compiles and links * native suites ........ 8 of 13, unchanged from before the move; the same 5 pre-existing failures, no regression * both runtime guards .. green at the new, lower budget Also fixes a block comment left unterminated by the extraction (the deleted range carried its closing */), restoring the compile to its single pre-existing -Wcomment warning.