Files
LithosAnanake/docs
rajamesandClaude Opus 5.5 01c447f9ab feat(v4.0.0): a node is handed a line -- ENGINE.md step 1
A v4 node no longer reads its own command line or prints a prompt.  Its
host puts a line of text in the node's input buffer and starts it at
(LINE); the node interprets it and stops at (IDLE), leaving in
(LINE-STATUS) how it ended: completed, an error, or QUIT.  The host says
" ok" or " ERROR" and prompts, as the kernel's REPL does for a v3 VM.  A
line may be 1024 characters, a block, as v3's.  Ruled 2026-10-05
(V3-PARITY.md 1b); design ENGINE.md 3.1.

- quit.v4: (REPL), the node's prompt loop, is gone; (LINE) (IDLE) (DONE)
- image.h/.c: v4_line_begin, v4_line_done, v4_line_status; the node is
  idle at switch-on
- boot.c: v4_boot_line, the one loop the hosted binary, the kernel and the
  capsule loader hand a line with; the code that took " ok" and the prompt
  back out of the node's output is gone
- hosted.c, sk_v4.c: the prompt and the line editing are the host's
- test_host_quit.c: the tests are the node's host; two tests of the old
  80-character prompt line now test a whole line, 1024 and 1025 characters

Verified: make -C v4 test passes at both widths; hosted-check passes on
three ISAs; clean qemu with STARFORTH_V4=1 on amd64, aarch64 and riscv64
passes POST (550 of 550) with the same hashes as hosted, and three lines
typed at each bare-metal prompt through the serial port are answered
correctly (logs/20261005-180922, -181152, -181541).

Still the lone node: kernel_main.c starts it before the fleet tables.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 18:17:37 -04:00
..

StarForth / LithosAnanke Documentation

This is the lithosananke branch: the bare-metal StarKernel side of the project (contrast master, which is the hosted-VM-only side). Documentation follows the two-tier model described in docs/CLAUDE.md: formal/ is the polished, citable LaTeX tier; working/ is living design notes and drafts that feed it. Everything else in this directory is branch- or subsystem-specific material that doesn't fit either tier.

Layout

  • formal/ — Three-volume LaTeX documentation set (research volumes, practitioner books, standalone reports) plus the scraps/ fragment library it's assembled from. Audience: patent counsel, SSRN reviewers, licensees, hobbyists with hardware in hand. See formal/CLAUDE.md for authoring conventions.
  • working/ — Living documents: architecture design notes, DoE experiment logs, hardware/platform notes, draft specs, academic-paper source material, and an archive of superseded docs. Source material for formal/.
  • 03-architecture/ — Tripod VM architecture constraints (Hera/Hermes/Artemis) and the word-level ACL system design.
  • lithosananke/ — LithosAnanke kernel branch documentation: milestone roadmap, system architecture, HAL reference, kernel command-line argument design, and the amd64 APIC-timer ISR postmortem.
  • birthing/ — VM birthing plan and status for the Hera-spawns- Hermes/Artemis constellation, plus three-architecture QEMU acceptance logs.
  • patent/ — Provisional patent application source. Legal hold — ask Bob before touching anything in this directory.
  • api/ — Generated Doxygen tag file and warnings log (gitignored; not part of the tracked doc tree).
  • pptx/ — Elevator-pitch and deep-dive slide decks for different audiences (technical, non-technical, academic, PhD-level).

Current Active Work

  • LithosAnanke M7/M7.1 — VM parity validation and init capsule architecture. See lithosananke/README.md and lithosananke/M7.1.md.
  • Word-level ACL system — Phase 6 complete on master; Phase 7 (LithosAnanke parity) is the next step. See 03-architecture/word-acl/README.md.
  • Tripod VMs — Hera (governor), Hermes (messenger), Artemis (memory/block storage). See 03-architecture/tripod/README.md and birthing/.

Contributing

  • Place new material in working/ first; promote to formal/ only when it's ready to be cited (see formal/CLAUDE.md for promotion criteria).
  • Never touch patent/, formal/patent/, formal/scraps/legal/, or working/legal/ without Bob's explicit instruction.
  • Add a README.md to any new category-level subdirectory, following the format used throughout this tree: orientation paragraph + bullet list of real files with one-line descriptions.