Clarified 2026-08-29 with the author: "no hurry" is wrong for #1 and #2.
- #1 (Hosted StarForth): the provisional will expire before conversion. Its
priority claim is time-boxed (provisional filed ~Dec 2025, window ~Dec
2026); if the non-provisional isn't filed claiming benefit before the
window lapses the priority is lost and the same subject matter can't be
re-staked by refiling thereafter. Hard clock regardless of December scope.
- #2 (full StarshipOS): the December deliverable that keeps the flagship
covered; pending counsel confirmation it may also be the conversion
vehicle for #1's provisional.
Open point to resolve: is #2 (or the December delivery) the conversion vehicle
for #1, or is #1 converted by a filing separate from #2? Decision record only;
no filing made. Authoritative form in ROADMAP.md; FABRIC-3.md tracks it.
The three-product split is treated as three patent applications, each matched
to a trademark (decided 2026-08-29):
- Patent 1 + mark StarForth -> hosted/interpreted runtime
- Patent 2 + marks StarshipOS (canonical spelling; noted as "StarshopOS"
in the decision words) + LithosAnanke -> full standalone OS
- Patent 3 + mark Compudynamics -> Zynq steady-state machinery
with sealed executions, HOL-proven, anchored by the physics-adaptive runtime
Flagged open for counsel (not assumed/filed): the repo already carries a
"Patent pending" USPTO provisional filed Dec 2025 for the Compudynamics
physics-adaptive runtime (docs/patent/). Whether patent 3 is a continuation/
refinement of that provisional, and whether the three product applications are
additive to or fold it in, must be reconciled. Records intent only; no legal
text drafted or filed. Authoritative form in ROADMAP.md; FABRIC-3.md tracks it.
The Zynq FPGA is not a fourth platform to port to — it is the pivot that
forces the project into three distinct products, each with its own host,
delivery, and proof character (decided 2026-08-29):
1. Hosted StarForth - the existing hosted/interpreted StarForth runtime
(3-arch acceptance-tested), delivered as a portable embedded runtime.
2. A full StarshipOS - the standalone OS built on LithosAnanke
(LithosAnanke -> StarshipOS), a self-booting OS on general silicon
(SER5/RasPi/Milk-V line).
3. Hardware steady-state machinery with sealed executions, HOL-proven -
the FPGA-native product: hardware-enforced sealed executions and
steady-state machinery machine-checked in a proof assistant (HOL);
delivery is the bitstream + HOL proof artifacts, not just an OS port.
The coupling is the point: product 3 is born on the FPGA, and its existence
is what cleanly separates 1 from 2 from 3. Product 1 ships hosted on an OS,
product 2 as an OS on general silicon, product 3 as proven hardware. Per-
product gates and the even-major line carrying the three as separate tracks
are scoped at v2.5.0 close / during the coloring-in phase. Complements, and
does not retract, the existing hardware bare-metal release policy.
Authoritative form in ROADMAP.md; FABRIC-3.md tracks the same horizon.
The next big milestone after the three-board bare-metal cut (v2.5.0) is
transferring the battle-tested amd64/aarch64/riscv64 story to a Zynq (AMD
Xilinx) FPGA SoC — configurable silicon with soft/hard CPU cores, PL fabric,
and a non-standard memory map, a genuinely larger step than any prior board
(expected on a new even-major line). Between v2.5.0 and the Zynq sits a
"coloring in" period: hardening that thickens the shape of what exists rather
than adding silicon (USB BOT/xHCI + block robustness, live-entropy and
Zuse-cert hardening on real ASICs, SMP/multi-core + IRQ routing from the HAL
notes, driver breadth) so the FPGA carries a production-honest shape forward.
Authoritative form in ROADMAP.md "Beyond v2.5.0"; FABRIC-3.md tracks the same
horizon in the post-release section and re-points G.6's Next at the
v2.2.0/v2.4.0/v2.5.0 cadence.
Real silicon arrives incrementally (Beelink SER5 in hand now; RasPi 5 + Milk-V
orderable around Mon 2026-08-31), so the hardware release is split per board
in hand, each an even-minor LTS point-in-time cut on the same line:
- v2.2.0 amd64 bare metal — Beelink SER5 (two 16GB sticks: one boots the
thumbdrive image, one mints a real Zuse user)
- v2.4.0 aarch64 bare metal — Raspberry Pi 5
- v2.5.0 all three bare — adds Milk-V (riscv64)
Each closes only when its board's items are proven live (boot to ok>, block-
fence Zuse true, backend entropy non-deterministic), never build-only.
Records the decision in the authoritative Release Versioning Policy
(docs/lithosananke/ROADMAP.md, "Board-by-board hardware rollout, decided
2026-08-29") and re-maps G.4/G.5 in FABRIC-3.md onto the new cadence, noting
v2.0.0 was cut (tag v2.0.0).
Full BOT-spec stall recovery per FABRIC-3.md F.14: new STALL_ERROR handling,
Reset Endpoint + Set TR Dequeue Pointer commands, CLEAR_FEATURE(ENDPOINT_HALT),
escalating to Bulk-Only Mass Storage Reset, capped retries
(XHCI_BOT_STALL_MAX_RECOVERIES=2) mirroring bot_tur_retries, clean terminal
failure via xhci_stall_fail().
Purely additive recovery path off the non-success transfer-event branch; the
normal path is unchanged. Builds clean on amd64/aarch64/riscv64. QEMU amd64
boot regression passes: zero stalls, BOT attach (READ CAPACITY10 -> READ10 ->
home-blocks) completes, normal-path xHCI trace identical to baseline. Live
stall injection is not provable under qemu-xhci; deferred to v2.5.0 hardware.
FABRIC-3.md G.1 documented; ROADMAP release-versioning policy folded in.
- docs/lithosananke/ROADMAP.md + M7.1.md: fixed stale "Branch: lithosananke"
(no such branch post-split), M7.1's "Design Complete" status (shipped
and live, redirected to FABRIC*.md), the M8/success-criteria
self-contradiction (OBSOLETE marking vs. unqualified live criterion),
and the stale AHCI/SATA claim for M9 (real implementation is
virtio_blk.c) -- also corrected BLOCK/BUFFER/UPDATE/FLUSH and block
device abstraction to [x] since both are confirmed live in
src/word_source/block_words.c and block_subsystem.c.
- Top-level ROADMAP.md: marked OBSOLETE (Captain Bob's call -- more than
"stale," the architecture/branch topology/terminology it describes no
longer exist), pointing to docs/lithosananke/ROADMAP.md and
FABRIC*.md for current status.
- docs/03-architecture/word-acl/DESIGN.md: fixed the ACL Phase 7
contradiction -- Phase 7 (LithosAnanke kernel parity) is independently
verified complete per .claude/CLAUDE.md, not "remaining"; removed the
stale lithosananke-branch-parity framing.
- VM-FLEET-ATTRACTOR-DESIGN-20260705.md's doe-campaign.4th "broken" claim:
investigated, ran SMOKE-CAMPAIGN live (completes clean, fleet heat
conserved) -- initially read as contradicting the claim, corrected
directly by Captain Bob: a clean execution trace doesn't disprove the
doc's actual argument (no real controlled-experimental-factor
mechanism). Confirmed accurate, left untouched.
- Isabelle/HOL pipeline-metrics model/C-struct mismatch: confirmed a real
proof-modeling gap (pm_last_accuracy_num/den has no analogue in the
real PipelineGlobalMetrics struct), not stale prose -- tracked here
rather than fixed, matching the .thy file's own scope boundary and
this project's standing caution that each Isabelle gap needs its own
subsystem model.
ACL-RWT DoE overhead re-measurement (the 6th item) intentionally not
started -- a full multi-architecture DoE campaign, not a doc-text fix,
holding for explicit confirmation given the scale.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn
CHANGELOG.md: new 2026-08-18 entry for today's work, plus a post-split
note explaining the branch-tag convention no longer applies (this repo
is now LithosAnanke-only, master as sole production line).
docs/lithosananke/ROADMAP.md: M7.1 section predates all the real
Tripod/Stadium/ACL work and was silently stale -- added a dated
redirect to FABRIC.md/FABRIC-2.md (matching the doc's own existing
pattern for the M8 section) rather than rewriting the whole section.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
FABRIC.md: renumber Artemis-last boundary 4.4 -> 4.5, add new 4.4 REPL item
(console visual design scoped this session -- CANVAS is one shared region
above the REPL strip, 640x480 scroll box centered within it, stroke font,
ANSI color, VM-identity + ACL-identity prompt segments, ~1000-line
scrollback), linked to repl-mockup.png.
ROADMAP.md: mark M8 section OBSOLETE -- replaced by FABRIC.md 4.4, kept for
history only.
ttf_words.c: TTF-TEXT's y argument now Cartesian (origin bottom-left of the
physical framebuffer, y increasing upward) instead of raw framebuffer
coordinates, translated once via fb_height() - y. Verified via amd64
screendump (logs/20260811-070418/), text renders right-side-up with
increasing y moving up the screen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Not implementation -- documentation-only. M8 is tracked outside Stadium
(FABRIC.md §27.5), so this scoping lives in docs/lithosananke/ROADMAP.md
rather than as new FABRIC.md 4.3.x items.
Read the code before scoping, not assumed: the REPL already works
interactively over serial (sk_repl_run(), repl.c) with working
backspace/echo, and its on-screen text already renders via the existing
VT100 console (vt100_init()/font_8x16.c) independent of both the stroke
font and TrueType work -- neither was ever a REPL-strip prerequisite.
What's actually missing: sk_readline()'s console_getc() is
serial-UART-only, never touches KEY-EVENT (4.3.5f); KEY/?TERMINAL
(io_words.c) are dead stubs (KEY calls a getchar() hardcoded to EOF in
shim.c, ?TERMINAL always returns false).
Resolved design decisions: minimal US-QWERTY scancode->ASCII layout
with shift-state tracking (KEY-EVENT carries no modifier state today);
merge keyboard into console_getc()'s poll with serial staying a
co-equal source, not replaced (the entire acceptance/DoE harness
injects over the serial socket -- breaking that breaks make qemu,
DOE_INJECT, and every screendump technique used throughout 4.3.x); wire
KEY/?TERMINAL to the same merged source for FORTH-79 compliance;
CANVAS viewport sizing last, since it's presentation not input
plumbing. Extended scancodes, autorepeat-as-character-repeat, arrow-key
history explicitly out of scope for the "minimal" bar.
FABRIC.md's existing "not yet scoped" notes (4.3.5f's landing-point
note, 4.3.7f's closing note) updated to point here rather than
duplicating the design content.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Robert Allan James