fed-sx-m1: Step 3b substrate fix #3 — atom_to_list/integer_to_list as Erlang charlists; list_to_* accept both (+9 net eval, 759/759)

next/README.md

@@ -103,16 +103,16 @@ The kernel calls into these host primitives: `crypto:hash/2`,
 
 These three gaps block the remaining unchecked deliverables:
 
-1. **Term codec** (`3b`/`3c`) — **substrate fixes #1 + #2 done 2026-06-04:**
-   `erlang:binary_to_list/1` and `erlang:list_to_binary/1` are registered
-   in `lib/erlang/runtime.sx` (`list_to_binary` is iolist-aware); the
-   tokenizer's `$X` branch now emits the decimal char code, so `[$h, $i | T]`
-   patterns and `list_to_binary([$f,$e,$d])` work end-to-end. 750/750
-   conformance, +9 ffi + +12 eval tests. Step 3b on-disk segment writer
-   has a complete byte-level term ↔ binary path. Still parked (low priority
-   for Milestone 1): `atom_to_list`/`integer_to_list` return SX-strings
-   (an opaque OCaml-string type), not Erlang charlists — only blocks code
-   that wants charlist arithmetic on atom/integer names.
+1. **Term codec** (`3b`/`3c`) — **all three substrate fixes done 2026-06-05:**
+   `erlang:binary_to_list/1` and `erlang:list_to_binary/1` registered in
+   `lib/erlang/runtime.sx` (iolist-aware); the tokenizer's `$X` branch
+   emits the decimal char code; `atom_to_list/1` and `integer_to_list/1`
+   now return Erlang charlists (standard Erlang semantics) with `list_to_atom`/
+   `list_to_integer` accepting both charlists and SX strings for back-compat.
+   759/759 conformance. The full term-codec primitive set is in place —
+   Step 3b on-disk segment writer can encode arbitrary Erlang activity
+   terms (atoms, ints, binaries, tuples, lists) into byte sequences using
+   only Erlang-native primitives.
 
 2. **SX-source eval bridge** — There's no BIF that lets Erlang call into the
    SX evaluator on a parsed source string. Blocks evaluating the `:schema` /