From e60ca8123b41b43126f216938757c5c57f13135c Mon Sep 17 00:00:00 2001 From: "will.anderson" Date: Sun, 2 Aug 2026 08:50:00 -0500 Subject: [PATCH] self-review 2026-08-02: record that el_from_float on a literal is not the double-wrap bug Investigated awareness.el ise_post's local-fallback engram_node_full call as a suspected instance of the score-mangling double-wrap fixed in server.el on 2026-08-01. It is not one. Removing the wrapper produces byte-identical codegen: the compiler treats el_from_float as the boxing intrinsic, so both `el_from_float(0.3)` and a bare `0.3` emit exactly one el_from_float(0.3). The server.el bug was different in kind - there the arguments came from json_get_float(), already boxed as el_val_t, and 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. Comment only, no behavior change. Recording the negative result at the call site so the sweep criterion is right: look for el_from_float applied to an already-boxed expression, never to a literal. Grepping the call name alone produces false positives, which is what happened here. --- awareness.el | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/awareness.el b/awareness.el index 9eed32c..6c69745 100644 --- a/awareness.el +++ b/awareness.el @@ -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),