Self-load fix: relevance-ranked graph projection + architecture docs (clean re-merge) #155

Merged
will.anderson merged 9 commits from merge-pr149-v2 into main 2026-08-15 23:41:00 +00:00
Showing only changes of commit e60ca8123b - Show all commits
+15
View File
@@ -54,6 +54,21 @@ fn ise_post(content: String) -> Void {
let fail_raw: String = state_get("soul.ise_fail_count")
let fail_n: Int = if str_eq(fail_raw, "") { 0 } else { str_to_int(fail_raw) }
state_set("soul.ise_fail_count", int_to_str(fail_n + 1))
// el_from_float on a LITERAL is correct and is NOT the double-wrap bug
// (checked and dismissed 2026-08-02 self-review — recording the result
// so this call site is not "fixed" again by the next reader).
// The compiler treats el_from_float as the boxing intrinsic: both
// `el_from_float(0.3)` and a bare `0.3` emit exactly one
// el_from_float(0.3) in dist/awareness.c. Verified byte-identical
// codegen either way.
// The real bug fixed in server.el on 2026-08-01 was different: there
// the arguments came from json_get_float(), i.e. values ALREADY boxed
// as el_val_t. Wrapping THOSE a second time reinterprets the boxed
// bits as a raw double, fails engram_decode_score's range check, and
// silently clamps to defaults.
// The sweep criterion is therefore "el_from_float applied to an
// already-boxed expression", never "el_from_float applied to a
// literal". Grepping for the call name alone produces false positives.
let discard: String = engram_node_full(
content, "InternalStateEvent", "state-event",
el_from_float(0.3), el_from_float(0.3), el_from_float(0.8),