will.anderson
86e269fa91
Two fixes, one found by making the other. 1. HEBBIAN WRITE-BACK. This daemon learned 1,198 associations in 23h48m and kept none of them: it syncs FROM the engram server and never pushes, and mem_save() is unreachable in HTTP mode by design (soul.el only sets soul_snapshot_path inside `is_genesis && safe_to_seed`, false whenever ENGRAM_URL is set, because the server owns persistence). So the one process that runs idle cognition -- where essentially all co-activation happens -- was the one process that could not remember what it learned. hebb_consolidate() now drains the runtime's write-back queue on every heartbeat and POSTs it as ONE batch to /api/edges/batch. One request, one durable write, not one 60MB snapshot per edge. Also drains on clean shutdown, so an exit between beats doesn't take the last 8 minutes of learning with it. _auth is required and its absence is silent: check_auth_ok exempts GET and /api/neuron/state-events (which is why ise_post works keyless) but gates every other mutation on "_auth" in the BODY -- http_serve surfaces no headers, so there is no Bearer path. An unauthorized reply is NON-EMPTY, so the obvious `if resp == "" return 0` check would have reported delivery of edges that were refused, after the drain had already destroyed them. Caught before it shipped. Gauges hebb_wb_pending/_drained/_dropped/_sent go into the heartbeat so a consolidation path that stops delivering is visible in the stream. 2. A READ ROUTE MUST NEVER WRITE THE CANONICAL SNAPSHOT. GET /api/graph/edges serialized this process's graph straight over $HOME/.neuron/engram/snapshot.json -- the engram SERVER's durable store -- and read the edges back out of it. I triggered it myself this morning fetching edges for the census above: snapshot.json went from the server's 41,213 edges to the soul's 42,431, and the next engram restart loaded the soul's graph as canonical. It happened to be a superset (Knowledge 1198->1218, Memory 1238->1242, no durable type down), so nothing was lost. That was luck. Had the soul been running a partial load -- the exact failure soul.el's safe_to_seed guard exists to catch -- one GET would have destroyed the store, with no write-side guard able to see it coming. The engram server fixed this same class of bug on 2026-07-21 by routing exports to a dotted sidecar; the soul kept the original pattern. Same fix: exports go to .soul-edges-export.json. Also stops a 60MB serialize-and-reread per GET. Verified: boot 26 loaded 42,432 edges with hebb_max 0.4941 carried across the restart -- the first time this daemon has ever started knowing what it learned.