Commit Graph
224 Commits
Author SHA1 Message Date
rajamesandClaude Opus 5.5 728b0a54eb docs(plan): the stick, increments 5 and 5a -- the proxy Zuse, growth, MINT-ZUSE and the fixed screen
Five tasks, each closed by full acceptance: the proxy Zuse (a stick's first boot mints its own;
genesis marker version 2), Artemis grown to fill the stick (metadata only), acceptance on a fresh
data stick, MINT-ZUSE onto a second stick (read back before the marker names her), and the fixed
screen whose only action is a replacement that kills the old stick.

R1 ruled (Captain Bob, 2026-10-29: "256 GiB is ruled"): Artemis grows to at most 256 GiB, not
STICK.md §5a's 2 TiB -- the block map costs two bytes of the 2 GiB kernel heap per 1 KiB block.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-29 08:23:40 -04:00
rajamesandClaude Opus 5.5 248179257a docs(stick): plug and play -- a proxy Zuse on every stick's first boot, the real Zuse on a second stick
Captain Bob, 2026-10-29: "i want this a plug & play solution" -- "plug it in, it boots to the
prompt, no setup". STICK.md amended (§2, §3, §4, §6, new §6a, §7, §9, §10, §11), each change
saying what the text said before:

- A stick's first boot mints its own proxy Zuse (§6's genesis, minted at first boot, not at
  build, so no two sticks share a key): full Zuse "until the real one is minted".
- MINT-ZUSE mints the real Zuse onto a second stick, after a typed YES, read back before the
  genesis marker (version 2: the proxy's key and the real Zuse's) records her.
- With a real Zuse, the system stick alone gives a fixed screen whose only action is minting a
  replacement ("the later"); a replacement kills the old stick "for good".
- Amends R2 ("only this system's stick is used") for the real Zuse stick, and supersedes "Zuse's
  identity is on the same stick that boots". The open risk -- the system stick stays a master
  key through the fallback -- is written down in §6a.
- §11: the proxy goes into increment 5; the real Zuse stick is a new increment 5a.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-29 08:15:53 -04:00
rajamesandClaude Opus 5.5 d6ea592c08 fix(amd64): the image runs wherever the firmware loads it -- -fpie, every symbol hidden; qemu-stick-high in acceptance
The SER5 stopped at the loader's "Loading kernel from ESP...": built -fno-pic -fno-pie with
ImageBase 0, the image carried ~9,000 32-bit absolute addresses, and the firmware loaded it above
2 GiB, where the sign-extended ones (R_X86_64_32S) point into unmapped memory -- a page fault in
debug_checkpoint() before [CKPT 001]. Reproduced on QEMU's pc machine at 3 GiB (#PF, CR2 =
FFFFFFFFBD316542, the right address sign-extended); q35 always loads it below 2 GiB, so no QEMU
boot ever showed it.

amd64 now builds -fpie with kernel/include/starkernel/pie_hidden.h force-included (#pragma GCC
visibility push(hidden)), so globals are RIP-relative and none is reached through a GOT -- the
2026-08-06 bug that put -fno-pic there. The link refuses any object carrying a 32-bit absolute or
GOT relocation (4,531 on the old objects, none now). test_runner.c's visibility("default") on
global_test_stats is kept for the -fPIC ISAs only. make -f kernel/Makefile ARCH=amd64
qemu-stick-high boots the PC stick on pc with 3 GiB and is part of acceptance (.claude/CLAUDE.md).
Captain Bob, 2026-10-29; FABRIC-3.md XLIV.

Verified: qemu-stick-high with Zuse's pair, ok> and 7 ok, RIP sampled inside .text at base
0xBD297000 (logs/20261029-070253); acceptance amd64 -070508, aarch64 -070715, riscv64 -071138,
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, dict_hash=0xfec8c47cfc6f437f on all;
make -C v4 test-32, 39 suites, 0 failures. Not yet booted on the SER5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-29 07:34:11 -04:00
rajamesandClaude Opus 5.5 1e8a6fed34 feat(kernel): Artemis and Zuse from one disk -- the stick; virtio Artemis leaves v4
sk_v4_identity.c: a USB drive is this system's stick if its GPT has both StarshipOS partitions and
it is the disk the loader booted from (BootDisk's DiskGUID), or, when the boot was not from a
stick, the first such disk while none is attached. Then: its Artemis partition must carry a good
artemis_sig ('Artemis: the stick's signature is bad -- not used' otherwise), is attached first --
the first disk slot -- ('Artemis: the stick's partition attached'), Zuse's key is read from its
genesis marker, and its identity partition is checked and attached as before. Any other drive,
raw or GPT: 'USB: a drive that is not this system's stick -- not used'. On a pull the identity
partition is detached, then Artemis. sk_v4_identity_boot / sk_v4_run take the loader's BootDisk.
kernel_main.c: no virtio Artemis on the v4 path. kernel/Makefile: ARTDISK= attaches no virtio disk
(every QEMU target); ARTDISK stays for system=v3.

STICK.md 4 amended as ruled (R2): on v4 only this system's stick is used; users' drives minted by
this system's Zuse come with the users design after INSTALL. BRINGUP.md: Secure Boot off on every
PC (ruled 2026-10-28), RDRAND in QEMU, the SER5 smoke-test stick, A4 not on v4.

Tests: new stick_artemis (x3, no virtio disk), stick_zuse, two_sticks (replaces datastick),
artemis_unsigned, raw_ident; changed stick_boot, gpt_zuse, gpt_hotplug, midpull (replug) -- all
failed before, pass after (two test defects found and fixed: the signature's offset, the 63-char
log cut). Regression 20/20. Acceptance: amd64, aarch64, riscv64 to [zuse@Hera] ok>, POST 538/538,
dict_hash 0xfec8c47cfc6f437f; v4 suite and test-32 0 failures.

Plan: docs/v4.0.0/plans/2026-10-27-stick-4-one-disk.md, Task 4.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 16:10:33 -04:00
rajamesandClaude Opus 5.5 a321c537f7 docs(outreach): the drafts move to studio/ (outside git), on Captain Bob's word
SPONSOR_PAGE, DEVLOG_01 and VIDEO_01 now live in studio/posts/drafts/, his gitignored workspace for
posts and video; git history keeps the committed versions (26c58879).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 11:18:23 -04:00
rajamesandClaude Opus 5.5 26c588792e docs(outreach): drafts of a sponsorship page, devlog #1 and video #1
For Captain Bob to edit into his own voice: the sponsorship pitch and tiers, the first devlog
('Building an OS that keeps its own receipts'), and a 5-7 minute video script with an OBS setup.
Claims limited to what is true today: QEMU on three ISAs, the stick in progress, hardware next.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 11:12:34 -04:00
rajamesandClaude Opus 5.5 4ed572058d docs(patent): SSM-001 claim-support map, toward the non-provisional due 2026-12-16
Each of the 20 filed claims mapped to its support in the provisional as filed (final_provisional/,
43 pages): claims 1-19 solid or adequate, claim 20 thin. Findings: the K-statistic's definition
contradicts the specification's own data and figures; Solid vs Steady State Machine; claims 10-12
depend on a method as 'the system'; drawings need redoing to 37 CFR 1.84; result invariance and
the Jacquard detail are not disclosed. Recommendations for the non-provisional. Drafting aid, not
legal advice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 11:03:17 -04:00
rajamesandClaude Opus 5.5 f5866d39cc docs(patent): the second provisional's outline -- the OS-and-proofs method, with explicit epistemic status
The outline for approval before drafting (target filing 2026-12-01..14, citing SSM-001): the method
that produces an operating system and its machine-checked proofs together, parameterised by
language; image and proofs bound by content hash; the self-tuning runtime proven not to change
results. Added 2026-10-28: explicit epistemic status of every claim -- proofs, the method of
construction, and the SDK's book capsule (6.9, and the claims' structure).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 09:31:19 -04:00
rajamesandClaude Opus 5.5 38b2b9693a test(build): Zuse's minted pair as a stick -- the acceptance boots and the sessions use it
mkdiskimage.sh --starship-from IDENT ART lays a minted pair out as a StarshipOS stick: an identity
partition holding IDENT's bytes and an Artemis partition holding ART's, each exactly its file's
size (Artemis's signature and fence are placed from the volume's size). kernel/Makefile: a
zusestick target, made fresh for every boot, is ZUSEDISK's default (ZUSE_PAIR names the pair);
STICK_PAIR puts the pair in the PC stick. qemu_session.py's Zuse drive is the pair as a stick.
check_images.sh checks both forms byte for byte against the pair (60 PASS).

On today's kernel all 23 sessions pass on the Zuse stick, and acceptance: amd64, aarch64,
riscv64 to [zuse@Hera] ok>, POST 538/538, dict_hash 0xfec8c47cfc6f437f; v4 suite and test-32
0 failures. The plan gains Task 5, screen=boot (ruled 2026-10-28).

Plan: docs/v4.0.0/plans/2026-10-27-stick-4-one-disk.md, Task 1 (R1 as recommended).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 08:41:51 -04:00
rajamesandClaude Opus 5.5 55f7c4f842 docs(v4): the plan for the stick's increment 4 -- Artemis and Zuse from one disk
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 06:11:59 -04:00
rajamesandClaude Opus 5.5 c416c805cb feat(build): QEMU boots the stick; the data stick over USB
qemu-stick boots the amd64 stick image (build/boards/pc/lithos-pc.img,
copied per run) as a USB drive on q35, exactly as hardware would.
DATASTICK=1 adds the data stick to any qemu run as a second USB drive.
qemu_session.py gains --target and the stick_boot and datastick modes.

Checks: stick_boot (the stick's own identity partition attaches, headless
on a blank identity); datastick on amd64/aarch64/riscv64 (both drives
found, the data stick's 500 MiB identity attaches); the seven GPT modes,
the identity-gate and increment 1 sessions, emergency; the suite; three
acceptance boots to [zuse@Hera] ok> with POST 538/538 and
dict_hash=0xfec8c47cfc6f437f; test-32 0 failures.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-27 16:31:27 -04:00
rajamesandClaude Opus 5.5 a4221d8b8c docs(v4): the plan for the stick's increment 3 -- the images
Ruled (Captain Bob, 2026-10-27): the data stick is built and wired behind
DATASTICK=1, off by default; increment 5 turns it on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-27 12:29:45 -04:00
rajamesandClaude Opus 5.5 2e71f7aa0d fix(kernel): a GPT disk with a bad header, or an unreadable first block, is not used
The increment 2 final review's minors 1-4 (Captain Bob, 2026-10-27: "fix 1-4"):
1. A protective MBR with no "EFI PART" header is GPT_BAD, not GPT_NONE: the
   MBR says it is a GPT disk, and a GPT disk is never attached whole.
2. A disk whose block 0 cannot be read is GPT_EIO: "GPT: a USB drive could
   not be read -- not used", nothing attached (it was read raw, attached
   whole, and a raw Zuse drive behind it logged her in).
3. The entry array's LBA is checked against the disk's size directly.
4. gpt_bad_entries: the entry array changed, the header valid -- refused.
Harness modes gpt_no_header, gpt_read_error (blkdebug EIO on sector 0),
gpt_bad_entries. The plan carries the amendment.

Red (amd64): gpt_no_header 070335, gpt_read_error 070717 FAIL;
gpt_bad_entries 070048 PASS (existing check, now pinned). Green: every GPT
mode on amd64 071113-072933; gpt_zuse, gpt_read_error, gpt_no_header on
aarch64 073222-074047 and riscv64 074526-075535; the identity gate's and
increment 1's sessions 080036-082345, emergency 083130 (082635 was run
without EMERGENCY_CONSOLE_ENABLED=1 -- a harness invocation error).
Accepted: suite EXIT 0; 093121, 093352, 093750, POST 538/538, dict_hash
0xfec8c47cfc6f437f; test-32, 0 failures.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-27 12:17:00 -04:00
rajamesandClaude Opus 5.5 03099f2c51 docs(v4): the stick's sizes -- a minimum, and Artemis grows to fill the stick
Captain Bob, 2026-10-26: sized for an off-the-shelf thumb drive, "a minimum
and then ... no max or reasonable max size"; "all to Artemis, identity stays
at 500 MiB". The image is 2 GiB (ESP 64 MiB, identity 500 MiB, Artemis the
rest); the minimum stick 8 GB; at first boot Artemis grows to fill the stick,
up to 2 TiB, writing metadata only (GPT, volume header, free map, fence); a
stick under 8 GB is not grown. With genesis, increment 5; the GPT writer is
INSTALL's too.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 19:50:32 -04:00
rajamesandClaude Opus 5.5 f9a313f44b docs(v4): the stick's identity partition starts at 500 MiB
Captain Bob, 2026-10-26: "64 megabytes does not need to be an engraved in
stone size ... start maybe 500 megabytes." Sizes are set in kernel/Makefile
and are not fixed by the formats.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 19:46:48 -04:00
rajamesandClaude Opus 5.5 7f297f4e99 docs(v4): the stick, increment 2 plan: the GPT reader
Approved by Captain Bob 2026-10-26, with his ruling on review: a GPT disk is
never attached whole -- the identity partition is attached in the raw
identity drive's place; a GPT disk with no StarshipOS partition, or a damaged
one, is not attached.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 19:28:42 -04:00
rajamesandClaude Opus 5.5 6f96502fdf docs(v4): the stick, increment 1 plan: v4's screen and keyboard
Approved by Captain Bob 2026-10-26.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 13:47:11 -04:00
rajamesandClaude Opus 5.5 1a54f9ef59 docs(v4): the x86_64 StarshipOS stick, designed
One GPT stick that is the whole OS: ESP, a StarshipOS identity partition and
a StarshipOS Artemis partition; a splash until Zuse logs in, automatically;
each stick mints its own Zuse on first boot; try-it writes persist on the
stick until INSTALL; pulling it goes headless. GPT comes back for boot media
and installed disks (overturns FABRIC-2.md F.8 for those); system=v3 is
refused on a stick; every clean qemu boot uses a GPT data stick over USB,
virtio Artemis leaves v4. Approved by Captain Bob 2026-10-26. First of three
designs (then INSTALL, then DOE/SDK/demos); ahead of ENGINE step 4 Part A.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 13:44:33 -04:00
rajamesandClaude Opus 5.5 5b181458df docs(v4): the identity gate before Part A
Captain Bob, 2026-10-26: "Gate first." Its own plan, with D1-D4 ruled as
recommended: the Zuse check split from the v3 VM; v4 recognises a minted
Zuse only (genesis with Artemis's writes, Phase 5); [zuse@Hera] ok> now;
the minted pair is QEMU's default.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 08:35:13 -04:00
rajamesandClaude Opus 5.5 eef6c15c28 docs(v4): ENGINE step 4 under MACHINE.md; Q1-Q5 and the identity gate ruled
MACHINE.md stands: v3 goes after parity; Hera, Hermes, Artemis (and
Hestia) are kernel functions. ENGINE.md section 2 amended with the rulings,
section 6's step-3 rows struck (R2). The step 4 plan rewritten: Part A
(hook at call, called in-line words) and Phases 1-8 to parity. No identity
thumbdrive, headless; work goes ahead only with Zuse attached.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-20 15:29:52 -04:00
rajamesandClaude Opus 5.5 6cb8f1285f feat(v4): the system hands no GONE on; (GONE-HOOK) goes (MESH step 7, increment 2)
Ruling 7 as amended: the kernel tells a node's going, so the system's
hand-on is not used.  (GONE-HOOK), (DOWN) and (RUN) go from quit.f18, and
COLD's hook-clearing from system.f18; the cell is free again.  The tests of
the hand-on go with it (mesh: the hand-on checks and the fourth disturbed
exchange; depth sweep: path 10, as before 529ba0fc).  A believed GONE going
no further is still checked.  test_host_unit.c's message for GONE down the
graph now says the kernel tells.  MESH.md: 9a.6 items 5 and 7, and step 7's
record of both increments.

Suite EXIT 0; depth sweep 230 runs, 0 failures; mkcapsule lint 0
violations.  Hosted and bare metal, all three ISAs: word_count=317
dict_hash=0xfec8c47cfc6f437f.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-20 13:05:45 -04:00
rajames 5707b07abf safety commit 2026-10-19 06:35:46 -04:00
rajamesandClaude Opus 5.5 63434f3762 docs: FABRIC-4 §3 as a null hypothesis
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 20:41:55 -04:00
rajamesandClaude Opus 5.5 0195631315 docs: FABRIC-4 §3, information state over information moment (Captain Bob's theory)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 20:41:25 -04:00
rajamesandClaude Opus 5.5 9382df69e5 docs(v4): MESH step 7 done -- a second unit, PAUSE, RESUME, KILL; acceptance
MESH.md step 7: what was built, the tests, the (DOWN) mend, the traced
(LOST) finding; 9a.5: a centre killed mid-birth, and birth authority not
yet tied to identity.  v4/README.md: births follow v3.

Acceptance at this commit's code: amd64, aarch64, riscv64 clean qemu, v4:
ok>, POST 538/538, dict_hash=0x248b4edc47f4357e on all three; test-32 0
failures.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 17:46:49 -04:00
rajamesandClaude Opus 5.5 bf97f339f6 docs(v4): MESH.md 9a, the rulings made while planning step 7
Fixed request numbers; NODE-BORN takes the number; GONE handed on through
the system's (GONE-HOOK), so dict_hash changes; a reader per asker.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 08:57:00 -04:00
rajamesandClaude Opus 5.5 f4f566bb37 docs(v4): the implementation plan for MESH step 7
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 08:52:27 -04:00
rajamesandClaude Opus 5.5 5283e67ded docs(v4): MESH.md 9a, step 7's design -- a second unit, PAUSE, RESUME, KILL
Ruled 2026-10-16: Hera births the second centre and it births its own unit;
hera.4th split into centre.4th (BIRTH-AS, BIRTH, UNIT) and Hera's own
(KILL, PAUSE, RESUME, UNIT-KILL, CENTRE); the kernel keeps the registry and
checks who may ask; centres face each other on port 6; GONE goes down the
birth graph.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 08:31:32 -04:00
rajamesandClaude Opus 5.5 ba9d432a01 docs(v4): MESH.md ruling 7 points to the births ruling
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 08:15:02 -04:00
rajamesandClaude Opus 5.5 9842b9cd50 docs(v4): births follow v3 -- any node may birth, KILL stays Hera's
MESH.md ruling 7 and section 9 said only Hera's requests are honoured.
Ruled 2026-10-16: v4 births behave as v3's (any VM may BIRTH, the child's
parent is its birther, its ACLs are copied from the parent's at birth,
KILL is Hera's alone).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 08:14:49 -04:00
rajamesandClaude Opus 5.5 924c48cece docs(v4): the ROMs' shared entries, and the mesh ROM as built
DATASHEET-F18.md lists all 19 entries of the host ROM, the six shared ones
with the registers they use.  MACHINE.md 2.2: built; 277 words, not the
estimated 150-200; the system's words are address, push and ;.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 20:32:23 -04:00
rajamesandClaude Opus 5.5 473e105a69 docs(v4): the mesh ROM's implementation plan
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 19:23:31 -04:00
rajamesandClaude Opus 5.5 99c46eeda8 docs(v4): MACHINE.md's status line says what is built
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 19:14:10 -04:00
rajamesandClaude Opus 5.5 a6da45df53 docs(v4): the mesh ROM's design, MACHINE.md 2.2
Shared math in a small ROM for mesh nodes: UM*, UM/MOD, D+, DNEGATE,
Q.* and Q./ as entries 0-5 of both ROMs, from one source; the host
ROM's assembler entries follow, and its start moves from 12 to 18.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 18:58:59 -04:00
rajamesandClaude Opus 5.5 a73580e949 feat(v4): the machine boots from its ROM; the prebuilt nucleus is gone
The host node starts in its ROM (entry 12), and the boot feeds it the
system's source through the console: capsules/v4/sys/map-64.f18, the
fourteen .f18 blobs and end.f18, each found, hash-checked and
signature-checked as any capsule, then EOT.  The ROM assembles the system
and starts it at (IDLE); the host reads the image record
(v4_image_from_node) for what only the assembled system knows.  A ROM
error is reported with its blob, line and meaning, then PARITY:FAIL.

Deleted: v4/tools/mkimage.c, capsules/v4/nucleus-64.f18, v4/capsule/*.v4,
v4/tools/v4tof18.py.  The .f18 files are the source now.

- text.c speaks the rest of the ROM's language (set, here, store, start;
  v4_text_value, v4_text_start), so the oracle reads the same source:
  test_host_rom_nucleus compares the ROM against text.c on the .f18 files,
  word for word, image record included.  Host tests load the .f18 files.
- mkmap image writes v4_map_image (the map's description of the system);
  hosted and the kernel link the ROM and the map instead of v4_image_64.c.
- Hera (Captain Bob's ruling, option 1): births stream the system the ROM
  assembled, as assembled code; hera.4th is unchanged.
  test_host_unit's host builds the system with the ROM.
- New parity lines: PARITY:V4_F18 per blob, PARITY:V4_ROM words=2049
  rom_hash=0xa6c792b5821010b7 instructions=60725216.

Acceptance: amd64, aarch64, riscv64 boot to ok> with PARITY:V4_POST
tests=538 pass=538 fail=0, POST: PASSED, and PARITY:V4_SYSTEM
word_count=317 dict_hash=0xe5a57f3eb72ff94a on all three -- the same hash
as the prebuilt nucleus gave.  make -C v4 test test-32 hosted-check: all
pass.  Logs: logs/20261015-141648, -141938, -142350.

Startup cost under QEMU TCG, the ROM's assembly (last V4_F18 line to
V4_ROM): amd64 26.7 s of 132 s to ok>; aarch64 41.0 s of 195 s; riscv64
20.5 s of 101 s.  Hosted native: +0.85 s.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 14:26:02 -04:00
rajamesandClaude Opus 5.5 32753f5479 feat(v4): the machine has a ROM -- read and run, never written
A read-only range of V4_ROM_WORDS words at V4_ROM_BASE, above RAM
(MACHINE.md 2, DATASHEET-F18.md 5).  Instruction fetch, @p and data fetches
read it; a running programme's store there is an address fault.  Attached by
the owner like every device; a reset detaches it.  The host node's range is
4096 words.  text.c places branches by the whole address space.  The
nucleus image is byte-identical.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 11:25:24 -04:00
rajamesandClaude Opus 5.5 42f8a13914 docs(v4.0.0): the ROM is shared code, GA144-style -- an entry table, a permanent state area
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 11:10:08 -04:00
rajamesandClaude Opus 5.5 1ed56b93b4 docs(v4.0.0): DATASHEET-F18.md -- the machine: registers, stacks, memory, instruction word, opcodes, control unit, faults, I/O
As built in the golden model (v4/src), with what is not yet as intended listed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 06:20:25 -04:00
rajamesandClaude Opus 5.5 952df0f44a docs(v4.0.0): plan for MACHINE.md steps 1-2 -- the ROM, and the .f18 trailer
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 06:01:54 -04:00
rajamesandClaude Opus 5.5 d0b0eee54b docs(v4.0.0): MACHINE.md -- what it is for: a multi-user, multitasking OS that init.4th brings up
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 05:52:47 -04:00
rajamesandClaude Opus 5.5 884721783a docs(v4.0.0): MACHINE.md -- forth79.4th names all 130 words; init.4th is the system's init
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 05:50:18 -04:00
rajamesandClaude Opus 5.5 528bed0874 docs(v4.0.0): MACHINE.md -- rulings: the VM is a machine; .f18 pretty-printed text; v3 deleted at parity; the whole system loads before POST
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 05:46:56 -04:00
rajamesandClaude Opus 5.5 3eca84e433 docs(v4.0.0): MACHINE.md -- the ROM is whatever size it takes; not a question
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 05:43:42 -04:00
rajamesandClaude Opus 5.5 e429d30a7e docs(v4.0.0): MACHINE.md -- the three .4th layers: forth79.4th (100 percent FORTH-79), starforth.4th, anything else
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 05:41:15 -04:00
rajamesandClaude Opus 5.5 58f3837498 docs(v4.0.0): MACHINE.md -- the machine, its ROM, and the capsule: one prebuilt F18 binary, the rest source
For review; nothing built.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 05:35:38 -04:00
rajamesandClaude Opus 5.5 3b49cb15a2 boards: the amd64 target is PC -- a generic x86-64 UEFI PC, not the SER5
Captain Bob, 2026-10-14: "change to PC, not SER5. it's not supposed to be
specific, but PC generic."  boards/ser5 -> boards/pc, TARGET=PC,
lithos-pc.img; the image was never specific to one machine (the generic
UEFI/ACPI path, FABRIC-3 III).  The Beelink SER5 stays named where the text
means the unit on the bench (its Secure Boot, BIOS, serial header) and in
the records.  Built: lithos-pc.img, system=v4, with its SBOM.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 17:22:32 -04:00
rajamesandClaude Opus 5.5 79db0e8d88 build: v4 is the default build -- every kernel boots v4; acceptance is v4 on three ISAs and the 32-bit build
Captain Bob, 2026-10-14: "v4 is the default build", "no, qemu to v4
too ... we are effectively trying to retire v3", "the 32 bit build needs
to go into the acceptance test too", "i don't care about v3".

- STARFORTH_V4 defaults on (Kconfig default y) and V4_DEFAULT=1
  everywhere: every kernel carries v4 and v3 and boots v4; system=v3 boots
  v3; STARFORTH_V4=0 builds v3 alone.  Board images write system=v4.
- Acceptance (CLAUDE.md): the three ISAs as built (v4, POST passed,
  V4_SYSTEM dict_hash equal) and make -C v4 test-32.  v3 is not part of
  it.

Acceptance run: amd64, aarch64, riscv64 -- PARITY:V4_POST 538/538,
dict_hash=0xe5a57f3eb72ff94a on all three, no unknown word; test-32: 30
suites, 0 failures.  The SER5 image under OVMF boots v4 as built, v3 after
the one-word edit.  README, BRINGUP, FABRIC-3 XLIII, the register updated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 17:21:13 -04:00
rajamesandClaude Opus 5.5 f8fbc37698 docs: the 12 duplicates deleted; README rewritten to the system as it is
Captain Bob's rulings, 2026-10-14: "delete" -- the duplicates listed in
DELETE-CANDIDATES.md are removed (the list stays as the record; the
formal tier's provenance comments repointed at the maintained copies) --
and "rewrite" the README: v2.1.0, the Tripod as Hera/Artemis/Hestia,
kernel-Hermes, identities on thumbdrives, the corrected ACL overhead,
1052-test POST and the current parity line, keyboards and storage, board
images carrying both systems and how to switch, and docs/README.md as
the way in.  The book is left as it is, to be reworked later.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 16:45:39 -04:00
rajamesandClaude Opus 5.5 776c89457e docs: the map, a fresh index, and a register of dead ideas and revised claims
docs/CLAUDE.md Phase 1 output, after the reorganisation.

- docs/README.md: rewritten as the map -- where each kind of document
  lives, which one to believe (CLAUDE.md, FABRIC, v4.0.0, reference/,
  BRINGUP, code), how to retire a document.
- docs/INDEX.md: regenerated from the tracked tree, 489 rows, every
  document with a status (the 2026-06-16 snapshot was stale).
- docs/DEAD-AND-REVISED.md (new): what was abandoned (L4Re, the hal_*
  contract, ACL RWT, the Hermes VM, elevation, the knowledge factor, ...)
  and what was corrected (ACL overhead, versions, block rules, parity
  baseline, ...), each with its date and record.
- docs/DELETE-CANDIDATES.md: 12 duplicates, awaiting a ruling; nothing
  deleted.
- CLAUDE.md: versions corrected (3.2.0 / 2.1.0).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 16:06:59 -04:00
rajamesandClaude Opus 5.5 7aed588f78 docs: reorganise -- current reference gathered, finished work archived, superseded and dead ideas marked as such
docs/CLAUDE.md Phase 2, 2026-10-14.  All moves by git mv; every archived
file carries a header saying what it is, why, and where to look instead.

- docs/reference/ (new): roadmap and versioning policy, M7.1, word-ACL
  design, kernel args, hosted acceptance test, dictionary, primitives,
  ontology, L8 table -- previously spread over docs/, docs/lithosananke/
  and docs/03-architecture/.
- docs/working/archive/historical/: finished work (session plan, test-gap
  audit, birthing plan, fix write-ups, the January architecture draft).
- docs/working/archive/superseded/: the Hermes-VM Tripod docs and July
  Hermes designs (-> FABRIC-3.5/3.6), the StarForth roadmap, every working
  doc already flagged superseded or obsolete.
- docs/working/archive/dead/: the hal_* target contract (never adopted),
  L4Re, metrics-and-knobs.
- Papers and proposals into docs/working/papers/.
- References rewritten across the repo (not logs/, not docs/patent/);
  CLAUDE.md's documentation section rewritten.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 16:03:56 -04:00