test: empty commit — is dev CI red independent of any change?

Baseline probe. #89 shows red on dev CI and this Gitea instance does not serve
Actions logs (404/500 on every route), so the only way to learn whether dev CI is
broken on its own is to run it against dev with no change at all.

Reproduced locally first: control (dev head) and treatment (dev + #89) produce
BYTE-IDENTICAL test results — both build the self-hosted compiler and elb, both
fail the same three timezone tests (earth-zone, dst-spring-forward,
rhythm-grounding). That exonerates #89 locally. This probe asks the same question
of the real runner.

Close once it reports.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -0,0 +1,154 @@
+# El
+
+**A self-hosting, statically-typed language that compiles to C — built around a graph-native runtime instead of a database driver.**
+
+El is the execution substrate for the Neuron agent runtime, the DHARMA network, and the Engram knowledge graph. This repository is the monorepo for the whole stack: the language itself, the graph memory engine it's built to talk to natively, and the tools (package manager, IDE, UI framework, diagramming) built on top of it.
+
+---
+
+## Why El exists
+
+Every other language treats persistent, associative state as something you reach for through a driver — a SQL client, an ORM, a Redis library bolted on from outside. El inverts that: graph operations (`engram_*`) are runtime primitives, on the same footing as string or list operations. There is no separate database driver because the database is not separate.
+
+El has four defining properties:
+
+1. **Self-hosting compiler.** The compiler (`lexer.el`, `parser.el`, `codegen.el`, `compiler.el`) is written in El. It compiles El source to C, which `cc` compiles against a fixed runtime into a native binary. A Rust genesis compiler bootstrapped the first iteration; the self-hosted binary at `lang/dist/platform/elc` has been the canonical compiler ever since — every binary in `dist/platform/` was produced by an earlier version of itself compiling `el-compiler/src/`. The chain is auditable: source is the ground truth, not the binary. See [lang/BOOTSTRAP.md](lang/BOOTSTRAP.md) for the full recovery path if that binary is ever lost.
+2. **C compilation target.** Every compiled program is plain C11. Every El value is `el_val_t` (`int64_t`); strings are heap pointers cast through it. Functions become C functions; top-level statements become `main()`.
+3. **Graph-native runtime.** The runtime provides first-class graph operations over an in-process Engram store — no separate DB driver, no ORM.
+4. **DHARMA-aware identity.** A `cgi` block declares a program's DHARMA identity at compile time. The runtime resolves identity before user code runs, so `dharma_*` calls have a stable principal and channel surface throughout.
+
+---
+
+## Architecture map
+
+```
+                     ┌─────────────┐
+                     │    lang     │   El compiler + C runtime
+                     │ (El itself) │   everything below is written in it,
+                     └──────┬──────┘   or compiles down through it
+                            │
+              ┌─────────────┼─────────────┐
+              │             │             │
+       ┌──────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
+       │   engram   │ │    epm    │ │    ide    │
+       │ graph/mem  │ │  package  │ │  editor + │
+       │  substrate │ │  manager  │ │    LSP    │
+       └──────┬─────┘ └───────────┘ └───────────┘
+              │
+      ┌───────┼────────────────┬─────────────────────┐
+      │       │                │                     │
+┌─────▼───┐ ┌─▼──────────┐  ┌──▼──────────┐    ┌─────▼──────┐
+│   elp   │ │ ql         │  │  ui         │    │   arbor    │
+│  NLG /  │ │engram-el.  │  |spreading-   │    |arbor       │
+│ 31 langs│ │studio+tests│  |activation UI│    |diagram lang│
+└─────────┘ └────────────┘  └─────────────┘    └────────────┘
+```
+
+`lang` is the foundation — the compiler and C runtime everything else builds on. `engram` is the graph-native memory/state engine that gives El its identity (property 3 above). Everything else is either a tool for working with El (`epm`, `ide`) or a system built on top of Engram's graph model (`elp`, `ql`, `ui`, `arbor`).
+
+---
+
+## Repository layout
+
+### [lang/](lang/) — the El language
+
+The compiler and runtime. Self-hosting: `elc-cli.el` → `compiler.el` → `lexer.el` / `parser.el` / `codegen.el` / `codegen-js.el`, textually inlined and compiled in one pass. Compiles to C11 and links against `el-compiler/runtime/el_seed.c`, a hand-maintained OS-boundary layer (libcurl HTTP, pthreads, filesystem, arena allocation) — everything else in the runtime is native El (`runtime/*.el`).
+
+Two layers to know: **El programs** (`.el` files — where nearly all work belongs) and **the C seed** (`el_seed.c` — edit only for genuine OS-level access; never re-implement what El can already express).
+
+Current status (single source of truth: [lang/spec/language.md](lang/spec/language.md)): lexer/parser/codegen and the C runtime's core (I/O, strings, math, lists, maps, filesystem, args) are implemented. In flight: `%` operator, match-statement codegen, `?` nil-propagation, `cgi` block parsing + DHARMA identity resolution, VBD role enforcement (`@manager`/`@engine`/`@accessor`), the real `engram_*` and `dharma_*` runtimes (currently stubs), and libcurl-backed `http_get`/`http_post`/`http_serve`. Bitwise operators, `??`, and `as` casts are explicitly **not** in this language.
+
+Key docs: [AGENTS.md](lang/AGENTS.md) (agent-facing orientation), [BOOTSTRAP.md](lang/BOOTSTRAP.md) (compiler recovery from scratch), [spec/language.md](lang/spec/language.md), [spec/codegen-js.md](lang/spec/codegen-js.md).
+
+### [engram/](engram/) — graph intelligence substrate
+
+**A local-first memory substrate for accumulating intelligence**, and the reason El's runtime doesn't need a database driver. Rust core (`engram-core`, `engram-ffi`) exposed to El and other languages (Kotlin, TypeScript/WASM, Go bindings).
+
+The model: retrieval is **spreading activation**, not query. You name seed nodes and a query embedding; activation propagates outward through weighted edges, attenuating multiplicatively per hop (`strength = parent_strength × edge_weight × target_salience × cosine_sim`), gets pruned below a threshold, and the top-N nodes by activation strength come back. Storage and retrieval are the same structure — the way long-term potentiation works in biological memory, not the way a relational or vector database works.
+
+Nodes live in four tiers (Working / Episodic / Semantic / Procedural, mirroring prefrontal / hippocampal / neocortical / cerebellar memory) and migrate between them based on **salience decay** — `importance × recency-decay × log(activation_count)`. Forgetting is adaptive pruning, not a bug: unreinforced memories stop competing for attention without being deleted.
+
+Backed by `sled` (embedded, local-first, no daemon) with flat cosine scan for vector search — deliberately simple until scale demands an HNSW layer. Full API and design rationale in [engram/README.md](engram/README.md).
+
+### [elp/](elp/) — Engram Language Protocol
+
+Bidirectional engine mapping between Engram semantic forms and natural-language surface text, across **31 languages** — from Spanish and Japanese through historical/liturgical languages (Old Norse, Sanskrit, Sumerian, Coptic, Akkadian, Ge'ez). Compilation order runs `language-profile` + `vocabulary` → per-language `morphology-*` → `grammar` → `realizer` → `semantics` → `elp`. This is what lets an Engram graph node round-trip to and from readable text in any of those languages.
+
+### [epm/](epm/) — El Package Manager
+
+Manages **vessels** (El's package unit): publish, install, resolve dependencies. Vessels are stored in Engram as graph nodes, not files in a registry index — `epm` reads the local `manifest.el`, talks to Engram over HTTP, and writes resolved vessels to `.epm/vessels/`. Source: `registry.el`, `install.el`, `update.el`, `manifest.el`.
+
+### [ide/](ide/) — El IDE
+
+Three vessels: **el-ide-server** (HTTP backend — file ops, build/run, LSP bridge, plugin host, settings), **el-lsp** (the language server — completion, hover, diagnostics, outline, format, type graph), and **el-plugin-host** (first-party plugin lifecycle: install/remove/enable/disable). `ide/projects/` and `ide/examples/` hold sample projects, including the canonical `hello-friends` first-program walkthrough.
+
+### [ql/](ql/) — engram-el
+
+The El-native integration layer for a *live* Engram server — not a library (no importable modules, no build artifact), a set of standalone `.el` programs run directly via `el run-file`. Three components: **Studio** (`studio/studio.el`, a full terminal graph explorer), a **Hebbian field-model** proof of concept, and El builtin / LLM-builtin smoke test suites. This is the reference for correct patterns when an El program uses Engram as its substrate. Spec: [ql/spec/elql.md](ql/spec/elql.md).
+
+### [ui/](ui/) — el-ui
+
+A frontend framework where **component state is an Engram graph and reactivity is spreading activation** — not virtual-DOM diffing (React), Proxy-based dependency tracking (Vue), or compile-time analysis (Svelte). Re-renders are activated and propagated the same way associative memory retrieval works in `engram/`.
+
+~15 vessels covering the full frontend surface: `el-platform` (env/fs/network/clock abstraction), `el-config`, `el-html` (SSR emit primitives), `el-layout`, `el-style` (design tokens/themes), `el-i18n`, `el-auth` / `el-identity` (JWT, sessions, OAuth PKCE — Engram-native), `el-services` (REST/gRPC/WebSocket bindings), `el-aop` (`@authenticate`/`@authorize`/`@cache`/`@rate_limit` decorators), `el-secrets`, `el-graph` (graph rendering/editor), `el-publish` (App Store / Play Store automation), and `el-ui-compiler` (El→JS component compiler; currently a stub pending a JS backend in `elc`). Spec: [ui/spec/framework.md](ui/spec/framework.md).
+
+### [arbor/](arbor/) — diagram language
+
+A `.arbor` diagram language and toolchain: `arbor-core` (NodeId/shape/edge-kind types), `arbor-parse` (recursive-descent parser), `arbor-diagram` (IR + Mermaid serializer + architecture-diagram builders), `arbor-layout` (hierarchical layout — rank assignment, positioning, group bounds), `arbor-render` (SVG renderer), `arbor-cli`. (The architecture map above is the kind of diagram this is for.)
+
+---
+
+## Getting started
+
+Install the El SDK from the latest release:
+
+```bash
+bash lang/install.sh
+# EL_VERSION=v1.0.0   bash lang/install.sh   # pin a specific release tag
+# EL_PREFIX=/opt/el   bash lang/install.sh   # custom install prefix
+```
+
+Or build the compiler from source and verify the self-hosting chain:
+
+```bash
+cd lang
+./dist/platform/elc elc-cli.el > elc-new.c
+cc -std=c11 -I el-compiler/runtime -lcurl -lpthread \
+   -o dist/platform/elc-new \
+   elc-new.c el-compiler/runtime/el_seed.c
+
+# Confirm the new binary reproduces itself exactly
+./dist/platform/elc-new elc-cli.el > elc-verify.c
+diff elc-new.c elc-verify.c   # should be identical
+
+mv dist/platform/elc-new dist/platform/elc
+```
+
+Run your first program:
+
+```bash
+./lang/dist/platform/elc lang/examples/hello.el > hello.c
+cc -std=c11 -I lang/el-compiler/runtime -lcurl -lpthread \
+   -o hello hello.c lang/el-compiler/runtime/el_seed.c
+./hello
+```
+
+More examples in [lang/examples/](lang/examples/), including a full starter project at `lang/examples/hello-project/`.
+
+If the compiler binary is ever lost or corrupted, [lang/BOOTSTRAP.md](lang/BOOTSTRAP.md) is the authoritative recovery path.
+
+---
+
+## Development workflow
+
+Branching follows `dev → stage → main`: work lands on `dev`, promotes to `stage` for integration testing, and is promoted to `main` for release (visible directly in the git history of this repo). CI is defined per-subproject under `.gitea/workflows/` — `lang`/`epm`/`ide` share the root pipeline; `engram` and `ql` carry their own (`ci-dev`, `ci-stage`, and a release workflow each).
+
+- Language/runtime specs live at `*/spec/*.md` (`lang/spec/`, `ql/spec/`, `ui/spec/`) and are the single source of truth for implemented-vs-planned status — code and docs are expected to agree with the spec's status markers, not the other way around.
+- Agent-facing orientation guides live at `*/AGENTS.md` (currently `lang/AGENTS.md`); more subprojects may grow their own as they need agent-specific conventions documented.
+- Tagged releases live under `lang/releases/`, each with its own `RELEASE.md`.
+
+---
+
+## Status
+
+This is an actively developed, internal monorepo — not yet published under an open license. Treat everything here as proprietary to Neuron Technologies unless told otherwise.

lang/AGENTS.md

@@ -31,46 +31,34 @@ This is where almost all work belongs. El programs are source files that get com
 
 This is the self-contained C OS-boundary layer. It provides the `__`-prefixed primitives that compiled El programs call: libcurl HTTP, pthreads, filesystem I/O, arena allocation, etc. It is **not generated** — it is maintained by hand.
 
-The runtime is native El (`runtime/*.el`) over a C OS-boundary. **Status (verified 2026-08-15):** the migration to a seed-only boundary is *in progress, not done*. Two files exist:
-- `el-compiler/runtime/el_runtime.c` (~516 KB) — **LIVE**. Holds the engram store (`EngramStore engram_global`) plus the `http_*`/`json_*`/`state_*`/`engram_*` impls. It is the authoritative single-file link target for the compiler, and `tools/install.sh` compiles it into `libel.a`. This is where a new C builtin's *implementation* must currently live to be linkable.
-- `el-compiler/runtime/el_seed.c` — the intended hand-maintained `__`-prefixed seed (thin wrappers over the above). It is compiled alongside `el_runtime.c` by `tools/install.sh`, but does **not** compile standalone yet (see the build-path caveat under "Rebuilding the Compiler").
-- `el-compiler/runtime/legacy/el_runtime.c` (~419 KB) — **DEAD**. Archived duplicate; no build script references it.
+The old `el_runtime.c` has been archived to `el-compiler/runtime/legacy/`. The runtime is now native El (`runtime/*.el`). `el_seed.c` replaces `el_runtime.c` as the sole C compilation dependency.
 
-**Only edit these when you genuinely need OS-level access** (raw sockets, GPU calls, new libcurl features, a new engram store op). For everything else, write El.
+**Only edit `el_seed.c` when you genuinely need OS-level access** (raw sockets, GPU calls, new libcurl features). For everything else, write El.
 
-When you add a C builtin (verbatim-emit recipe — the El name is emitted as the exact C symbol; `builtin_arity` is an arity guard only, not a dispatch table):
-1. Implement the C function in `el_runtime.c` (and declare it in `el_runtime.h`).
-2. Add a `__`-prefixed thin wrapper in `el_seed.c` and declare it in `el_seed.h`.
-3. Add the name to `builtin_arity` in `el-compiler/src/codegen.el` — add **both** the plain and `__`-prefixed spellings.
-4. Rebuild the elc binary (see below) and confirm the self-host fixpoint is byte-identical.
-
-Worked example: the `engram_assert_json` (op_assert seam) and `engram_node_full_in`/`engram_connect_in` (purview write-side) primitives added 2026-08-15 follow exactly this recipe.
+When you do add a C builtin:
+1. Add the C function to `el_seed.c`
+2. Declare it in `el_seed.h`
+3. Add it to the `builtin_arity` table in `el-compiler/src/codegen.el` (so the compiler knows the arg count)
+4. Rebuild the elc binary (see below)
 
 ---
 
 ## Rebuilding the Compiler
 
-After changing any `.el` source in `el-compiler/src/` (run from the `lang/` dir):
+After changing any `.el` source in `el-compiler/src/`:
 
 ```bash
-# 1. Stage2: current elc compiles the (modified) compiler to C
+cd /Users/will/Development/neuron-technologies/foundation/el
 ./dist/platform/elc elc-cli.el > elc-new.c
-# 2. Build the new compiler. The C link target is el_runtime.c — it holds the
-#    engram store + http/json/state impls the compiler output calls. el_runtime.c
-#    self-hosts elc on its own; el_seed.c is the (aspirational) seed layer and does
-#    NOT compile standalone under clang (missing prototypes for the el_runtime.c
-#    symbols it wraps — see caveat below), so link el_runtime.c here.
 cc -std=c11 -I el-compiler/runtime -lcurl -lpthread \
    -o dist/platform/elc-new \
-   elc-new.c el-compiler/runtime/el_runtime.c
-# 3. Verify self-hosting FIXPOINT (stage3 == stage2 output, byte-identical):
+   elc-new.c el-compiler/runtime/el_seed.c
+# Verify self-hosting:
 ./dist/platform/elc-new elc-cli.el > elc-verify.c
-diff elc-new.c elc-verify.c   # must be identical
+diff elc-new.c elc-verify.c   # should be identical
 mv dist/platform/elc-new dist/platform/elc
 ```
 
-> **Build-path caveat (verified 2026-08-15).** `el_seed.c` is the intended hand-maintained OS-boundary seed, but it does **not** compile standalone under modern clang: it wraps ~16 unprefixed `el_runtime.c` symbols (`http_serve`, `json_*`, `state_*`, `http_response`) without prototypes, and clang treats implicit declarations as errors (C99+). The productionised install (`tools/install.sh`) builds `libel.a` from **both** `el_seed.o` + `el_runtime.o` together, which is why linking succeeds there. To make `el_seed.c` build on its own, add prototypes for those symbols (or `#include "el_runtime.h"`, reconciling the `__http_serve` return-type mismatch first). Until then, `el_runtime.c` is the authoritative single-file link target for the compiler.
-
 After changing `el_seed.c` only (no El source changes), rebuild downstream programs but do NOT need to rebuild the compiler binary itself — the seed is linked at the application level, not the compiler level.
 
 ---

lang/el-compiler/runtime/el_runtime.c

@@ -8410,59 +8410,6 @@ el_val_t engram_activate_json(el_val_t query, el_val_t depth) {
     return el_wrap_str(jb_finish(&b));
 }
 
-/* op_assert seam (realizer promotion, bl-53/#57).
- * Gathers the grounded ASSERTION ENVELOPE for a subject node —
- *   { "subject": <node|null>, "grounding": [ {node,edge,hops}... ] }
- * i.e. the self-geometry a realizer renders as faithful first-person text.
- * Read-only: realization (geometry->text) stays in the faculty/realizer;
- * this native primitive produces its structured input from proven paths
- * (engram_emit_node_json + engram_neighbors_json). arity 2 (node_id, depth). */
-el_val_t engram_assert_json(el_val_t node_id, el_val_t depth) {
-    const char* sid = EL_CSTR(node_id);
-    JsonBuf b; jb_init(&b);
-    jb_puts(&b, "{\"subject\":");
-    EngramNode* n = (sid && *sid) ? engram_find_node(sid) : NULL;
-    if (n) engram_emit_node_json(&b, n); else jb_puts(&b, "null");
-    jb_puts(&b, ",\"grounding\":");
-    el_val_t nb = engram_neighbors_json(node_id, depth, EL_STR("both"));
-    const char* nbs = EL_CSTR(nb);
-    jb_puts(&b, (nbs && *nbs) ? nbs : "[]");
-    jb_putc(&b, '}');
-    return el_wrap_str(jb_finish(&b));
-}
-
-/* Parametric mutation (purview write-side bounding, keystone 56ecbec6).
- * The mutation verbs travel with a TARGET MANIFOLD (purview) instead of the
- * implicit global singleton. purview==0 (EL_NULL) is the DEGENERATE/DEFAULT
- * case: G = live, behaviour identical to the base op. A non-zero purview is a
- * bounded target that the engine cannot yet resolve (multi-manifold store is a
- * promotion item), so we REFUSE rather than silently mutate the live set —
- * write-side bounding must never leak into G=live. */
-el_val_t engram_node_full_in(el_val_t purview,
-                             el_val_t content, el_val_t node_type, el_val_t label,
-                             el_val_t salience, el_val_t importance, el_val_t confidence,
-                             el_val_t tier, el_val_t tags) {
-    if (purview == 0) {
-        return engram_node_full(content, node_type, label, salience, importance,
-                                confidence, tier, tags);
-    }
-    fprintf(stderr, "[engram] purview write-side not yet resolvable (G != live); "
-                    "refusing to append to live store (purview=%lld)\n",
-            (long long)purview);
-    return EL_STR("");
-}
-
-void engram_connect_in(el_val_t purview,
-                       el_val_t from_id, el_val_t to_id, el_val_t weight, el_val_t relation) {
-    if (purview == 0) {
-        engram_connect(from_id, to_id, weight, relation);
-        return;
-    }
-    fprintf(stderr, "[engram] purview write-side not yet resolvable (G != live); "
-                    "refusing to connect in live store (purview=%lld)\n",
-            (long long)purview);
-}
-
 el_val_t engram_stats_json(void) {
     EngramStore* g = engram_get();
     char buf[128];

lang/el-compiler/runtime/el_runtime.h

@@ -639,14 +639,6 @@ el_val_t  engram_scan_nodes_by_type_json(el_val_t node_type, el_val_t limit, el_
 el_val_t  engram_neighbors_json(el_val_t node_id, el_val_t max_depth, el_val_t direction);
 el_val_t  engram_activate_json(el_val_t query, el_val_t depth);
 el_val_t  engram_stats_json(void);
-/* op_assert seam: grounded assertion envelope {subject,grounding} for the realizer. */
-el_val_t  engram_assert_json(el_val_t node_id, el_val_t depth);
-/* Parametric mutation (purview write-side): purview==0 => G=live (default), else refuse. */
-el_val_t  engram_node_full_in(el_val_t purview, el_val_t content, el_val_t node_type, el_val_t label,
-                              el_val_t salience, el_val_t importance, el_val_t confidence,
-                              el_val_t tier, el_val_t tags);
-void      engram_connect_in(el_val_t purview, el_val_t from_id, el_val_t to_id,
-                            el_val_t weight, el_val_t relation);
 el_val_t  engram_list_layers_json(void);
 /* engram_compile_layered_json — produce a prompt-ready text block split
  * into "[LAYER 0 — STRUCTURAL]" (non-suppressible layers, sacred fire)

lang/el-compiler/runtime/el_seed.c

@@ -1095,15 +1095,6 @@ el_val_t __engram_activate_json(el_val_t query, el_val_t depth) {
 }
 
 el_val_t __engram_stats_json(void)                         { return engram_stats_json(); }
-el_val_t __engram_assert_json(el_val_t node_id, el_val_t depth) { return engram_assert_json(node_id, depth); }
-el_val_t __engram_node_full_in(el_val_t purview, el_val_t content, el_val_t node_type, el_val_t label,
-                               el_val_t salience, el_val_t importance, el_val_t confidence,
-                               el_val_t tier, el_val_t tags) {
-    return engram_node_full_in(purview, content, node_type, label, salience, importance, confidence, tier, tags);
-}
-void __engram_connect_in(el_val_t purview, el_val_t from_id, el_val_t to_id, el_val_t weight, el_val_t relation) {
-    engram_connect_in(purview, from_id, to_id, weight, relation);
-}
 el_val_t __engram_list_layers_json(void)                   { return engram_list_layers_json(); }
 
 el_val_t __engram_compile_layered_json(el_val_t intent, el_val_t depth) {

lang/el-compiler/runtime/el_seed.h

@@ -233,12 +233,6 @@ el_val_t  __engram_scan_nodes_by_type_json(el_val_t node_type, el_val_t limit, e
 el_val_t  __engram_neighbors_json(el_val_t node_id, el_val_t max_depth, el_val_t direction);
 el_val_t  __engram_activate_json(el_val_t query, el_val_t depth);
 el_val_t  __engram_stats_json(void);
-el_val_t  __engram_assert_json(el_val_t node_id, el_val_t depth);
-el_val_t  __engram_node_full_in(el_val_t purview, el_val_t content, el_val_t node_type, el_val_t label,
-                                el_val_t salience, el_val_t importance, el_val_t confidence,
-                                el_val_t tier, el_val_t tags);
-void      __engram_connect_in(el_val_t purview, el_val_t from_id, el_val_t to_id,
-                              el_val_t weight, el_val_t relation);
 el_val_t  __engram_list_layers_json(void);
 el_val_t  __engram_compile_layered_json(el_val_t intent, el_val_t depth);
 

lang/el-compiler/src/codegen.el

@@ -2579,9 +2579,6 @@ fn builtin_arity(name: String) -> Int {
     if str_eq(name, "__engram_neighbors_filtered") { return 3 }
     if str_eq(name, "__engram_activate") { return 2 }
     if str_eq(name, "__engram_activate_json") { return 2 }
-    if str_eq(name, "__engram_assert_json") { return 2 }
-    if str_eq(name, "__engram_node_full_in") { return 9 }
-    if str_eq(name, "__engram_connect_in") { return 5 }
     if str_eq(name, "__engram_scan_nodes_json") { return 2 }
     if str_eq(name, "__generate") { return 1 }
     // Filesystem
@@ -2679,9 +2676,6 @@ fn builtin_arity(name: String) -> Int {
     if str_eq(name, "engram_neighbors_json") { return 3 }
     if str_eq(name, "engram_activate_json") { return 2 }
     if str_eq(name, "engram_stats_json") { return 0 }
-    if str_eq(name, "engram_assert_json") { return 2 }
-    if str_eq(name, "engram_node_full_in") { return 9 }
-    if str_eq(name, "engram_connect_in") { return 5 }
     // LLM
     if str_eq(name, "llm_call") { return 2 }
     if str_eq(name, "llm_call_system") { return 3 }