LithosAnanake/CHANGELOG.md

# Changelog

Milestone-level achievements only — not a commit log. For full history see
`git log` on the relevant branch. Two products share this file:
**StarForth** (hosted FORTH-79 VM, `master`) and **LithosAnanke** (bare-metal
UEFI kernel, `lithosananke`). Entries are tagged by which branch(es) they
landed on.

## 2026-07-24 — Kernel 3-arch acceptance test re-run; amd64 dict_hash non-determinism root-caused (`lithosananke`)

Re-ran the standing kernel acceptance test (`ARCH={amd64,aarch64,riscv64}
clean qemu`) after this session's changes. All three booted cleanly to `ok>`
with `PARITY:OK` and Hera/Hermes/Artemis E2E PASS, but amd64's `dict_hash`
didn't match aarch64/riscv64 (which matched each other and the established
reference exactly). Root-caused rather than dismissed: `capsule_dict_hash_hook()`
(`src/starkernel/capsule/capsule_vm_hooks.c`) folds each word's
`execution_heat` into the hash, and amd64's own boot log says its timer
falls back to "RELATIVE mode (no determinism guarantees)" under this
QEMU/hypervisor setup (no invariant TSC) — aarch64/riscv64 get proper
deterministic hardware timers. Heartbeat tick count during boot, and
therefore `dict_hash`, can legitimately vary run-to-run on amd64 from host
scheduling jitter alone. Pre-existing, self-documented in the boot log,
consistent with already-recorded ACL-RWT campaign data (amd64's baseline
tick count was already distinct from aarch64/riscv64's). Not a regression
from any change this session. Logs and DoE run data committed as usual.

## 2026-07-24 — amd64 ISR `.hidden` fix extended to aarch64/riscv64; hosted `blk_ram` sizing bug fixed (`lithosananke`)

Surveyed both branches for ASM files and C99 fallback layers on request;
confirmed via SHA-256 that all six ASM-optimization headers plus
`arch_detect.h` are byte-identical between `master` and `lithosananke`, but
found `amd64/isr.S` had genuinely diverged — `lithosananke` carries a real
fix (`.hidden` directives preventing GOT-indirection corruption of the
runtime ASLR-relocation-delta computation) that `master` never received.
Ported it there (see `master`'s entry below). Investigated whether the same
GOT-indirection bug class applies to aarch64/riscv64: it doesn't structurally
(`interrupts.c` on those architectures only *calls* the vector-install
function via PC-relative branches; nothing reads an asm-defined symbol's
address from C) — added `.hidden` anyway as defensive hardening on request,
working around a real ELF-vs-PE/COFF assembler incompatibility for the
aarch64 loader (`.hidden` guarded with `#ifndef _WIN32`, since that loader
is assembled via `clang-18 --target=aarch64-pc-windows-msvc`). Verified with
full three-arch QEMU acceptance.

Separately, discovered and fixed (with explicit sign-off) a severe
pre-existing bug: the hosted StarForth VM could not start at all on
`lithosananke`, on any architecture. `src/main.c`'s block-I/O RAM buffer was
hardcoded to the old `1024*1024`-byte size, stale relative to a deliberate
`BLK_RAM_BLOCKS=2080` block-subsystem redesign (moving the RAM/ramdrive
boundary to user-visible LBN 2048) that the kernel-side bootstrap already
correctly followed. Fixed to derive the buffer size from the same shared
constants; verified across all three hosted architectures via QEMU
(native amd64, `qemu-aarch64-static`, `qemu-riscv64-static`).

## 2026-07-24 — pgo build option removed; hosted 3-arch acceptance test documented (both)

Removed the `TARGET=pgo` profile and its associated `pgo`/`pgo-build`/
`pgo-perf`/`pgo-valgrind`/`bench-compare` targets from the hosted `Makefile`
on both branches, plus the now-orphaned `scripts/pgo-workload.sh`. Verified
`make TARGET=pgo` now errors cleanly on each branch.

Also proved out and documented, for the first time, that the hosted VM
starts cleanly not just on amd64 but on aarch64 and riscv64 too (cross-built,
run under `qemu-{aarch64,riscv64}-static` user-mode emulation) —
`docs/lithosananke/hosted-acceptance-test/README.md`. This is what surfaced
the `blk_ram` sizing bug above.

## 2026-07-07 – 2026-07-08 — Kconfig build-configuration system (both, committed on `lithosananke`)

A Linux-kernel-style Kconfig system replaces the two Makefiles' scattered,
drifting `?=` knobs with one discoverable, optional configuration tree.
Vendored the real `scripts/kconfig` tooling (`conf`/`mconf`/`qconf` —
headless, ncurses, and Qt frontends) into `tools/kconfig/`, wrote a ~40-symbol
tree (`Kconfig.arch`/`variant`/`physics`/`heartbeat`/`kernel`), and bridged it
into both Makefiles via `mk/Kconfig.mk`. Entirely opt-in: nothing changes for
a plain `make` until a developer generates a per-architecture
`build/$(ARCH)/.config`, and command-line overrides always win regardless.
Found and reported two real, previously-invisible drift bugs along the way
(`TRANSITION_WINDOW_SIZE` diverging live in kernel builds, `MINIMUM_PREFETCH_ROI`
off by an order of magnitude in its Q48.16 encoding); the latter was fixed on
request. Documented in `docs/working/architecture/getting-started/DEVELOPER.md`.

## 2026-07-07 — Artemis/riscv64 determinism gap closed (`lithosananke`)

Root-caused a `dict_hash` divergence on riscv64 that had been mis-attributed
to an architecture quirk: Loop #3 heat decay was reading real wall-clock
nanoseconds instead of the heartbeat's execution-driven tick counter, making
it sensitive to a riscv64-specific I/O busy-wait. Converted decay to be
purely tick-based across all six call sites touching it. All four VM
identities (Hera, Artemis, Hermes ×2, Mama) now byte-identical across
amd64/aarch64/riscv64.

## 2026-07-05 – 2026-07-07 — VM Fleet Attractor experiment concluded (`lithosananke`)

Multi-week investigation into giving the L8 Jacquard mode selector a real
per-VM physics channel (dynamic fleet heat replacing hardcoded
`compudynamics.4th`/`fleet-k.4th` constants) reached a validated end state:
a 180-run, three-architecture DoE campaign found the self-tuning inference
loop was starved by a shared-counter bug, replaced a log-linear regression
estimator with direct rate recovery once fixed, and closed with L8 wired
into a real causal channel into fleet tuning — the pathway earlier iterations
had found architecturally missing. Three-arch acceptance confirmed throughout.

## 2026-07-04 — K-PUSH dictionary-shadowing corruption fixed (`lithosananke`)

Multi-day trap-and-debug campaign closed: FORTH-79 word shadowing broke
under the dictionary's heat-based reorganization, corrupting `K-PUSH`.
Root-caused and fixed; three-arch confirmed.

## 2026-07-03 — Artemis BAM storage subsystem, Phase 1 (`lithosananke`)

Block Allocation Map storage for the Artemis VM accepted: Q48.16 block heat
tracking, `ART-COOL`/`ART-REAP` reclamation words.

## 2026-06-27 – 2026-06-30 — Hermes inter-VM messaging complete (`lithosananke`)

17-block message/channel layer between VMs finished and verified: 16/16
inter-VM smoke tests passing, three-arch. Follow-on "completion steps" batch
(async delivery, channel negotiation, K-FLEET integration) landed the same
week. `INPUT_BUFFER_SIZE` restored to 1025 on this branch with the correct
line-vs-block-buffer rationale (see note below on master's divergence).

## 2026-06-23 – 2026-06-25 — Tripod (Hermes/Artemis) scaffold stood up (`lithosananke`)

Named multi-VM roles (Hermes, Artemis) with dedicated prompts and
`CONNECT-HERMES`/`CONNECT-ARTEMIS` wiring; verified booting live,
pre-REPL, on all three architectures. Compudynamics — the physics-runtime
tuning discipline — ported into FORTH itself via `VM-EXEC`/`VM-STEP`
primitives, the first self-hosted physics orchestration. K≡1.0 conservation
wired end-to-end (Phase 6+7) with Artemis block storage passing
`PHASE6-TEST` green.

## 2026-06-17 — LaTeX publication system completed (`master`)

Three-volume formal documentation system finished: 11 publications, 209
source scraps at 100% coverage, clean build. StarForth version bumped to
v3.1.0 / LithosAnanke to v1.5.3 in the same window.

## 2026-06-16 — LithosAnanke v1.5.1-FINAL — framebuffer/VT100 console milestone (`lithosananke`)

Closed the framebuffer terminal milestone; three-arch re-acceptance.
ACL-RWT DoE campaign confirmed the same day as the first genuinely
ACL-active campaign (an interpreter-hook bug that had silently bypassed ACL
checks in every prior run was fixed just before this one) — all nine cells
of a 3×3 Latin square (seeds × architectures), **+0.0054%–+0.0088% overhead,
CV = 0.000%**. Report finalized for patent support material.

## 2026-06-13 – 2026-06-14 — Word-level ACL system, Phases 1–7 complete (both)

C infrastructure (`acl_ttl`/`acl_allow`/`acl_mode`/`acl_pinned` fields on
every dictionary entry), the `ACL.4th` FORTH policy layer, the `zuse`
bootstrap superuser, Isabelle/HOL proof stubs, and LithosAnanke kernel
parity all landed — all three kernel architectures boot to `zuse)ok>`.
Phase 8 (Ed25519 PKI / thumbdrive challenge-response) is the only remaining
item on the ACL roadmap.

## 2026-06-11 – 2026-06-12 — Bare-metal ACL baseline DoE campaign (`lithosananke`)

3×3 Latin-square baseline campaign (seeds × architectures, 30 replicates
each) completed across all nine cells. Analysis report drafted, revised
through a peer-review pass, and prepared for SSRN submission.

---

**Known issue surfaced while compiling this changelog, not yet resolved:**
`master`'s `include/vm.h` currently defines `INPUT_BUFFER_SIZE` as `256`,
violating the project's own documented invariant (it must be `1025` — `LOAD`
copies up to 1024 bytes of block content through the same `vm_interpret()`
path interactive REPL lines use, so anything past byte 255 is silently
dropped under the 256 cap). `lithosananke` has the correct value. Not fixed
as part of this changelog/README pass; flagged for a future session.