Mechanical sweep of all .sx sources and plan docs (PLAN.md, current/,
.agents/) for the sx language rename (s8/s16/s32/s64 -> i8/i16/i32/i64).
Verified: make build + make test, 14/14.
The June stdlib restructure deleted the flat library modules; the old
paths kept resolving only through a stale zig-out/library install
snapshot. Verified green with that snapshot removed. Drop the empty
src/infra/ — the planned hash/json/cli shims shipped as sx std modules
instead.
`dist ci publish` now seeds the Repo from a pre-existing <store>/db.json
before find-or-create, so separate CLI invocations share state: a new
version accumulates under the single found app, and re-publishing the same
release id is rejected by the P2.3 integrity transaction (db.json left
unchanged). An absent db.json still starts empty. The loaded model grows
through its owning allocator (context.allocator), per the long-lived rule.
Wiring db.load into the dist program (which already links manifest.sx)
exposed two latent issues, both fixed:
- db.sx's load-path helpers (dup_str/obj_find/req_obj/req_arr/
artifact_from_json) collided by name with manifest.sx's same-named
helpers; sx resolves bare top-level names across the whole program, so
load_into bound to manifest's versions and failed the LoadErr error-set
check. Renamed db.sx's five helpers with a db_ prefix (load-path only;
save path and public API untouched).
- publish's `existing!.id` (only reachable once an app is found, i.e. never
before this change) read garbage: sx miscompiles postfix-`!` chained with
`.field`. Bound the unwrap to a local first, matching the codebase idiom.
tests/publish_persist.sx drives build/dist twice into one store: publish A,
then a different version B accumulates (two releases, one app, both objects),
then re-publishing A's id fails and leaves db.json unchanged. Fails on the
pre-fix write-only persistence, passes after.
