Tim Lingo f34270d63d
El SDK Release / build-and-release (pull_request) Failing after 25s
runtime: fs_read length hint must be paired with its buffer — fixes truncated HTTP responses
The binary-safe fs_read length (_tl_fs_read_len) was consumed by the HTTP
response path for ANY body, even when the handler wrapped the file into a
larger reply. Content-Length then lied AND the send stopped short: the
safety-contact routes returned 178 of 208/218 bytes, cut mid-'set_at' —
unparseable JSON. The desktop app read that as failure: fresh installs
trapped at 'Set your safety contact' (POST reply mangled) and configured
users saw the gate re-appear every launch (GET reply mangled). Worse, a
stale hint LARGER than a later body would over-read heap memory out the
socket.

Fix: pair the hint with the exact buffer pointer it describes; consume it
only when the response IS that buffer (binary file serving keeps working,
the hint follows the worker's copy); reset both at request start. Also
ports engram_get_node_by_label (from releases/v1.0.0) needed by soul.el
session continuity in local mode — not-found returns "" (matches shipped
behavior; '{}' flips the truthiness check upstream).

Verified: genesis boot + byte-math E2E on :7797 sandbox — safety-contact
GET/POST/GET all Content-Length==body, json-parse clean; /health,
/api/config regressions match.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 18:25:21 -05:00
S
Description
The Engram programming language — types as knowledge nodes, quantum-sealed prod target
147 MiB
2026-07-15 21:41:18 +00:00
Languages
Emacs Lisp 74.6%
C 21.9%
HTML 1.5%
Objective-C 0.6%
Shell 0.6%
Other 0.8%