fix-doxygen-unicode.py protected the first argument of each
\doxynewunicodechar{...} from its replacements, then turned every
non-ASCII character left in the file -- the protected ones too -- into
"?" and wrote the file as ASCII. refman.tex's \doxynewunicodechar{⁻},
{²} and {³} became \doxynewunicodechar{?}, and newunicodechar stopped
the build: "ASCII character requested".
The "?" fallback now applies to the unprotected parts of each line
only, and the file is written as UTF-8.
make -C docs/formal doxygen, from clean, with doxygen 1.9.8: exit 0,
build/doxygen/StarForth-API-Reference.pdf, 3561 pages.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
isabelle build -v -D proof/ with Isabelle2025-2 (installed by make init):
HOL-Library built (0:04:42), then the StarForth session's 52 theories,
every one in proof/ROOT (0:00:24); 0:05:24 in all, exit 0, nothing
FAILED. No sorry or oops in any proof (the words appear only in
comments) and quick_and_dirty is not set. The two explicit axioms are
both in StarForth_Transition.thy, the inventory StarForth_Correctness.thy
gives.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Neither is packaged. make ARCH=<arch> init now downloads both to
build/cache/downloads, checks each archive's SHA-256, unpacks it into
build/cache/tools (both kept by make clean) and links it into
/usr/local/bin:
- syft 1.52.0, the version sbom.spdx was made with (make sbom,
boot_image); sums from the release's checksums.txt;
- Isabelle2025-2, the version proof/COVERAGE.md names (isabelle build
-D proof/), from the release's own site (the /dist mirror answered
503); Isabelle publishes no sums, so these are of the archives as
downloaded on 2026-11-06.
An archive already there with the right sum is not downloaded again;
a download with the wrong sum is deleted and init stops. The host's
build is chosen by uname -m (amd64 or arm64).
Checked on Ubuntu 24.04 (x86_64): both fetched, checked and run (syft
1.52.0, Isabelle2025-2); a wrong sum is refused and deleted; isabelle
build -n -D proof/ finds the StarForth session.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
One ISA or several (ARCH=amd64,aarch64,riscv64, for the full
acceptance), on Debian/Ubuntu with apt-get, sudo when not root:
- common: the build, the disk-image tools (scripts/mkdiskimage.sh;
sfdisk is in fdisk), git-lfs for the logs and DoE CSVs, and the
documents -- docs/book/Makefile's own list, and pdflatex, doxygen and
graphviz for docs/formal;
- per ISA: its QEMU, its UEFI firmware at kernel/Makefile's paths, and
its compiler (aarch64's loader also needs clang and lld-link).
Then git lfs install --local, so a log or CSV committed from this
checkout goes into LFS (the 1003 plain files fixed in 027b144e came
from a checkout without it). Not installed: syft (make sbom), which is
not packaged.
Checked on Ubuntu 24.04: init for all three ISAs, then make docs and
make -C docs/formal vols build. make -C docs/formal doxygen fails in
LaTeX on "newunicodechar Error: ASCII character requested" with every
package present -- a separate fault, not a missing dependency.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The acceptance runs of .claude/CLAUDE.md, one QEMU at a time, in order,
each with clean (scripts/qemu_session.py, QEMU_DISPLAY=none):
amd64 zuse 20261106-004933 PASS
aarch64 zuse 20261106-005153 PASS
riscv64 zuse 20261106-005530 PASS
amd64 stick_zuse 20261106-005712 PASS (--target qemu-stick-high)
Each: [zuse@Hera] ok>, `3 4 + .` -> 7 ok, PARITY:V4_POST tests=538
pass=538 fail=0, POST: PASSED. PARITY:V4_SYSTEM word_count=317
dict_hash=0xfec8c47cfc6f437f on all three architectures.
make -C v4 test-32: 39 test programs, 1868561 checks, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
.gitattributes has routed logs/**/*.log, *.log and the DoE run CSVs
through LFS since the initial commit, and 3944 of them are pointers.
1003 were committed as plain files instead (from a checkout without
git-lfs), so every fresh clone showed them as modified. git add
--renormalize moves them to LFS like the rest. Content unchanged: each
pointer's oid is the sha256 of the file it replaces.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
- hosted (v4/tools/hosted.c): a line longer than the buffer is read to its
end and refused as too long. Before, fgets handed it over in 1025-byte
pieces and the last piece ran as a line of its own.
- bare metal (kernel/src/v4/sk_v4.c): the line editor takes 1024
characters, as the boot does, and a line typed past that is refused as
too long instead of being cut at 255 and run. V4_BOOT_LINE_TOO_LONG is
now reported at the prompt and while a line waits.
- engine (v4/src/exec.c): a store the node itself refuses (to "any port",
"which port", How or Have) left the opcode running on: !+ advanced A,
against node.h's FAULTS, and !p advanced P past the handler, into the
next fault kind's entry. A refused store now does nothing more; a store
that raises an error (D-18) still counts as made, but P stays the
handler's.
- test_port.c: both cases; they fail on the old exec.c (A 1017, P 901).
Engine-level tests (all v4/tests/test_*.c but test_host_*) pass at 32 and
64 bits; test_port also under ASan/UBSan. Not yet run: make -C v4 test,
test-32, hosted-check, and the three QEMU acceptance boots.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
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>
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>
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>
scripts/write_stick.sh refuses a device that is not a whole, removable USB disk, that holds the
running system, that is smaller than the image, or that has a mounted partition (it prints the
udisksctl lines); shows the stick and asks for its name typed back; writes with conv=fsync,
flushes, reads the stick back and compares it with the image byte for byte; powers it off. On
Windows/macOS it points to balenaEtcher or Rufus. Captain Bob, 2026-10-28, after a terminal line
break dropped dd's bs=4M conv=fsync on the first SER5 stick.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
KernelArgs gains screen_boot; cmdline.c parses screen=boot (with or without --; any other value:
off). With it, the v4 boot keeps the console mirrored to the framebuffer after POST, with the TTF
font, and says 'Screen: the console stays on until login (screen=boot)'; login and logout work as
without it, and nothing can be typed without Zuse. Without it, unchanged. For the SER5, which has
no known serial port (ruled 2026-10-28). BRINGUP.md: the smoke test's stick and starforth.cfg.
Tests: screen_boot (new) failed on amd64 and aarch64 before, passes on all three ISAs after;
screen_dark_until_login, screen_dark_after_logout, zuse pass. 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 5.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
uefi.h: the UEFI device path and Block I/O protocols, a typed LocateDevicePath, and BootDisk
{gpt, is_stick, disk_guid[16]} appended to BootInfo after args (boot_info_offsets.h unchanged).
The loader, before ExitBootServices, cuts its image's device path at the partition's HardDrive
node, locates the whole disk's Block I/O (whole path consumed, not a logical partition, 512-byte
blocks), reads it as 1 KiB blocks through a loader-side blkio adapter, and runs the kernel's own
gpt_read: is it a StarshipOS stick (identity and Artemis partitions), and its DiskGUID
(gpt_disk_guid, new). No HardDrive node (an ISO/CD boot), no GPT, or any failure: not a stick.
Monolithic builds only (the non-monolithic loader does not link gpt.c, and does not build today:
kernel/src/vm/vm_core.c -- reported, not fixed).
The kernel prints 'Boot disk: a StarshipOS stick' or '... not a StarshipOS stick', and on a stick
system=v3 gives 'System: v3 is not on this stick -- StarForth v4' and boots v4.
Tests: stick_v3 (new), stick_boot and zuse x3 failed on the new lines before, pass after; v3_keys
still boots v3 off a stick. 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 3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
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>
sk_v4_block_chain calls rng_init() after pci_init, with v3's two lines ("entropy: ready" / "entropy:
not available (continuing without)"); genesis on a fresh stick (increment 5) needs it. amd64 QEMU
runs -cpu qemu64,+rdrand (qemu, qemu-stick, qemu-esp) and the amd64 qemu target drops virtio-rng,
so QEMU takes the PC's RDRAND path; aarch64 and riscv64 keep virtio-rng, their only backend.
qemu_session.py: mode entropy (rdrand on amd64, both targets; virtio-rng on aarch64/riscv64; then
entropy: ready). system=v3 sessions get Zuse's raw identity image: v3 never reads a GPT, so the
Zuse stick (Task 1) left v3_keys headless -- found here; CLAUDE.md says so for v3 boots.
Tests: entropy FAIL x4 before, PASS x4 after; v3_keys PASS (rng: backend = rdrand). 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 2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
Review of the stick's increment 3 (a4221d8b..c416c805), on Captain Bob's word:
- check_images.sh deletes both images before building and makes each build a
check: a failed build left last run's lithos-pc.img in place, and every stick
check passed against it.
- mkartemis takes --first-lba and --sectors as plain decimal numbers only:
"abc", "-2", "2048x" and the like formatted at LBA 0, over the GPT.
- mkartemis --format reopens the image read-only and reads the volume back:
blk_commit_format ignores its own write errors, so a header that never
landed was reported formatted. The header is read from the disk and judged
as attach judges it (magic, version 2, BAM size); blk_get_volume_meta gives
the in-memory geometry of a blank disk, magic included, so --check no longer
relies on it either.
check_images.sh keeps each case as a check (40, PASS). stick_boot and datastick
on amd64/aarch64/riscv64 PASS on the rebuilt tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
The stick's increment 3, Task 1 (docs/v4.0.0/plans/2026-10-27-stick-3-images.md;
STICK.md 4). make boot_image TARGET=PC now writes the 2 GiB stick: ESP 64 MiB
(BOOTX64.EFI, startup.nsh, starforth.cfg), StarshipOS identity 500 MiB (zeros),
StarshipOS Artemis to the end. make -f kernel/Makefile ARCH=<arch> datastick
writes the 1.5 GiB data stick, identity and Artemis, fresh every time. Sizes in
kernel/Makefile; every partition on whole MiB.
tools/mkartemis formats and signs an Artemis partition at build with the
kernel's own code -- v3's block_subsystem.c (blk_subsys_confirm_format) and
artemis_sig.c (artemis_sig_genesis_stamp) -- through a blkio device over a byte
range of the image; --check reads one back the same way (read-only). disk_uuid
from getrandom(2): each image its own. mkdiskimage.sh gains --starship,
--mkartemis, --esp-mib; Milk-V and the Pi images are unchanged. The kernel is
not changed.
Red: scripts/check_images.sh FAIL (no datastick, the PC image one partition).
Green: 23/23. Mutation: --check on a range shifted by one block fails.
Accepted: suite EXIT 0; 133146, 133417, 133815, POST 538/538, dict_hash
0xfec8c47cfc6f437f; test-32, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
kernel/Makefile wrote the boot arguments with printf '$(KERNEL_ARGS)\n', so
arguments starting with '-' were taken for an option -- "printf: Illegal
option --", the build stops; the Makefile's own documented example,
KERNEL_ARGS="--doe --log-level=info", hit it -- and a '%' in them would be a
conversion. Now printf '%s\n' '$(KERNEL_ARGS)', as the board images already
write theirs, at all four places (the amd64, aarch64 and riscv64 qemu
recipes, and qemu-esp).
Red: the stick's increment 2 sessions with KERNEL_ARGS=--log-level=info
failed in make. Green: amd64 203627, aarch64 203833, riscv64 204237 --
starforth.cfg holds "--log-level=info" and the boot shows INFO lines after
POST. Accepted: 214300, 214507, 214911; test-32 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The stick, increment 2 (plan 2026-10-26-stick-2-gpt-reader; docs/v4.0.0/
STICK.md 3 and 4: GPT for boot media and installed disks). kernel/src/gpt.c:
a CRC-32; gpt_read(), which checks the protective MBR, the primary header and
the partition-entry array (both CRCs, the revision, the sizes, the geometry);
and a partition as a blkio device, refusing blocks past its end. The two
StarshipOS partition types: identity 23BEBFE1-4817-4CF3-A537-9069BF159788,
Artemis BCD7B586-1C8E-4EEF-86A3-273A8D8EE624.
The v4 drive path: a GPT disk is used only through its StarshipOS identity
partition, and that partition -- never the disk -- is given to the block
subsystem, in a raw identity drive's place; a GPT disk with no StarshipOS
partition, or a damaged table ("GPT: a USB drive has a damaged partition
table -- not used"), is not attached (Captain Bob's ruling on the plan); a
disk with no GPT is read raw, as always. Pulling the drive detaches the
partition and ends her session. Reads only.
Red (amd64): gpt_zuse 193158, gpt_hotplug 193804, gpt_foreign 194713,
gpt_bad_crc 194947. Green: 195409, 195627, 195854, 200136; gpt_zuse aarch64
200424, riscv64 200839 (the 64 MiB partition attached, 48724 user blocks,
not the 72 MiB disk); the identity gate's and increment 1's sessions,
201119-203403, all pass.
Accepted (with the KERNEL_ARGS fix that follows): suite EXIT 0; 214300,
214507, 214911, POST 538/538, dict_hash 0xfec8c47cfc6f437f; test-32, 39
modules, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
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>
From the fresh review of the stick's increment 1 (With fixes):
- Critical: after logout Zuse's last screen, her prompt included, could be
drawn back on a headless machine. The logout clear (ESC[2J) blanked the
pixels only: Alt+TAB, still read while headless, redrew the terminal
from its saved text; and if she had Alt+TABbed to the graphics view
before the pull, the clear did nothing and her session stayed on screen
(and the console did not draw at her next login). Now vt100_reset()
forgets everything the terminal has shown -- the on-screen text, the
scrollback and their boot snapshots -- makes it visible again and fills
the screen; and Alt+TAB does nothing while the screen is off (v3's never
is, so v3 is unchanged).
- Important: an EMERGENCY_CONSOLE_ENABLED build no longer clears the screen
when Zuse's drive is pulled: its console goes on running.
Red: alttab_after_logout 183308 (4515 lit), alttab_before_pull 183529
(4539 lit; the console not redrawn), emergency_pull 183759 (0 lit).
Green: 184115, 184328, 184552; regression 184805-185956 (screens,
keyboard, hotplug, emergency, v3 typed by keyboard) all pass.
Accepted: 190111, 190312, 190710, POST 538/538, dict_hash
0xfec8c47cfc6f437f; test-32, 39 modules, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The stick, increment 1, task 2 (plan 2026-10-26-stick-1-screen-and-keyboard;
docs/v4.0.0/STICK.md 2, 5.3, 5.4). On the v4 path:
- the framebuffer is brought up after POST, cleared and dark: console text
goes to serial only ("splash only, log on serial") until Zuse logs in;
then the screen is the console (TTF, a blinking cursor, as v3's), and
when she logs out it is cleared and dark again (console_fb_mirror(),
console_fb_clear(); the mirror is on by default, so v3 is unchanged);
- the line editor and the node's KEY read every keyboard -- PS/2, USB, the
virtio keyboard -- through the shared bridge (sk_input_getc()); the
headless wait drops keyboard input as well as serial bytes;
- an EMERGENCY_CONSOLE_ENABLED build has the screen from the start.
The framebuffer setup is one helper both paths call (kernel_main.c).
Red (before): screen_dark_until_login 153051 (10835 lit), console/keys
153309, logout 153609, kbd_typeahead 153918, virtio_kbd aarch64 154245
and riscv64 154718; no_framebuffer 155546 passed before and after.
Green: 155926 (0 lit), 160156, 160409 (0 lit after logout), 160630,
virtio_kbd 161414 and 161820, no_framebuffer 161206; usb_kbd with the USB
keyboard the only one (-machine i8042=off) 164548, v3 control 164757;
the identity gate's sessions 162245-163802 all pass; v3 typed by keyboard
164009, 164115. (usb_kbd 160857 and 164313 failed in the harness:
input-send-event's device names a display, not a keyboard.)
Accepted: suite EXIT 0; three clean qemu boots, POST 538/538, dict_hash
0xfec8c47cfc6f437f unchanged (174704, 174911, 175315); test-32, 39
modules, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On riscv64 a system=v3 boot never reached its prompt: Artemis's writes
"timed out" and Zuse was never confirmed (logs/20261026-134850). vblk_io()
bounded its wait by ~1M polling iterations, which on riscv64 under TCG is
about one heartbeat tick of real time -- shorter than a write that allocates
space in a sparse host image. Instrumented, the request was seen completing
just after the give-up ("used idx=409 last=408"), and every later request
then took its predecessor's completion for its own and returned before its
own I/O was done (a stale used index at each later request), reusing the
descriptor chain while the device still owned it: silent read and write
corruption from that point on. FABRIC-3.md's 2026-09-09 "request that never
gets a used-ring completion" is this same early give-up.
Now: the wait is for this request's own completion (the used index
reaching the avail index it was given), bounded by 5 s of real time on the
CPU's counter (timer_now_ns(), which needs no interrupts); a request that
truly never completes takes the disk out of service instead of letting a
later request reuse the chain.
Red (riscv64 system=v3, with temporary instrumentation): 151003, 151100 --
a timeout then dozens of stale completions each. Green: 151238, 151332 --
none; Zuse confirmed; the keyboard line answered. system=v3 with the fix:
riscv64 151438, amd64 151528, aarch64 151610, no timeouts. Accepted (v4):
151722, 151916, 152247, POST 538/538, dict_hash 0xfec8c47cfc6f437f;
test-32, 39 modules, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The stick, increment 1, task 1 (plan 2026-10-26-stick-1-screen-and-keyboard).
repl.c's keyboard bridge -- the key tables, Shift/Alt/Caps Lock/Num Lock and
their lights, the keypad, Alt+TAB, and the per-tick USB keyboard servicing --
moves unchanged to kernel/src/hal/kbd_input.c as sk_input_getc() (and
sk_input_drop()), so that the v4 boot's console reads the same keyboards
(docs/v4.0.0/STICK.md 5.4). v3's behaviour is unchanged.
scripts/qemu_session.py: the typed-QEMU-session harness, kept in the repo
from here on (the identity gate's sessions, and v3_keys: system=v3 typed on
QEMU's keyboard with send-key).
Yardstick, system=v3 typed by keyboard: before, amd64 PS/2 134805 PASS,
aarch64 virtio keyboard 135549 PASS; after, 135746 and 135835 PASS.
(riscv64 134850: v3 never reached its prompt -- Artemis virtio_blk writes
time out; v3's block path, before this change; being investigated.)
Accepted: suite EXIT 0; three clean qemu boots to [zuse@Hera] ok>, POST
538/538, dict_hash 0xfec8c47cfc6f437f (145722, 145859, 150231); test-32,
39 modules, 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
From the fresh whole-branch review of the identity gate (With fixes; no
Critical, four Important):
1. A drive pulled while a line ran: the drives are looked at before every
prompt (sk_v4_identity_check_now), so no prompt is shown once she is
gone and what was typed after the pull does not run as Zuse.
2. Pulled while a line WAITS: the wait is ended at logout, by an empty
line, and not carried into her next session (Captain Bob, 2026-10-26:
"end the waiting line at logout"); re-attaching brings the prompt back.
3. EMERGENCY_CONSOLE_ENABLED: v4 honours it as v3 does -- a bring-up build
has a prompt with no drive (boards/BRINGUP.md A2).
4. Keys typed at a headless machine are read and dropped, not run as
whoever logs in next. (v3 has the same gap, sk_repl_headless_wait;
reported, not changed.)
Each a QEMU session red then green (amd64): midpull 111650 -> 112953,
waitpull 111907 -> 113154, emergency 112524 -> 113609, typeahead
112248 -> 113359; headless 113800 and hotplug 114043 still pass.
Accepted: three clean qemu boots to [zuse@Hera] ok>, POST 538/538,
dict_hash 0xfec8c47cfc6f437f on all three; hotplug on aarch64 and
riscv64; make -C v4 test test-32 sanitize hosted-check EXIT 0;
make -C v4 test-32 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The identity gate on the v4 boot (plan 2026-10-26-engine-step4-identity-gate,
task G2; ENGINE.md 2, ruled 2026-10-20). As v3, by the kernel with no v3 VM:
after POST and the block chain, Zuse's public key from the genesis marker,
every xHCI controller brought up, the heartbeat started; then headless until
her drive is attached and checked (capsule_zuse_boot_check, G1). A drive that
arrives is given to the block subsystem by the kernel (Artemis is the
kernel's); her session is kept in the kernel for Hera, never in a node's
memory. The prompt is v3's, [zuse@Hera] ok>; pulling her drive ends the
session and the system goes headless; putting it back brings the prompt.
A blank pair stays headless: genesis writes Artemis's disk, Phase 5 (D2).
kernel/Makefile: ARTDISK and ZUSEDISK default to the minted pair,
disk/zuse-scratch/ (D4); .claude/CLAUDE.md's acceptance says so.
Fixed with it, at Captain Bob's word:
- kernel/Makefile: the ROM-and-map rule is a grouped target (&:). As two
targets of one plain rule its recipe ran twice at once under -j and the
copies met ("cp: cannot create regular file ... File exists"): 3 of 20
parallel builds failed, now 0 of 20.
- The v4 boot drops the logger to --log-level after POST, as v3 does
(sk_log_level_after_post, shared by both paths); INFO lines after POST,
3 before, 0 now.
Accepted: three clean qemu boots as built to [zuse@Hera] ok>, POST 538/538,
dict_hash 0xfec8c47cfc6f437f on all three (unchanged), 0 INFO after POST;
the hot-plug session (attach, line, detach, headless, re-attach) on amd64,
aarch64 and riscv64; headless with no drive; make -C v4 test test-32
sanitize hosted-check EXIT 0; make -C v4 test-32 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
capsule_zuse_boot_check() makes the check capsule_zuse_boot_try_attach()
made -- the genesis marker, the drive's identity record (magic, version,
CRC-64, public key) -- and says HERS, GENESIS or NOT_HERS, with no VM;
capsule_zuse_boot_root_pubkey() reads the marker's key. try_attach and
load_root_pubkey call them; their behaviour and messages are unchanged.
The v4 boot will make the same check (identity gate plan, D1).
Shown on v3 (system=v3, amd64): the minted pair, "Zuse: identity
confirmed" and [zuse@Hera] ok> (logs/20261026-083603); a blank pair,
"Zuse: genesis minted onto attached thumbdrive" (logs/20261026-084729).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
disk/zuse-scratch/artemis.img and zuse-thumb-ident.img, minted from blank
by a system=v3 amd64 boot (genesis minted) and confirmed by a second
(identity confirmed); both logs included. The genesis marker is on the
Artemis disk, so the two are a pair. The committed artemis.img and
thumbdrives/zuse-thumb-ident.img are not touched.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Three boots through the top-level Makefile: POST 538/538, dict_hash
0xfec8c47cfc6f437f on amd64, aarch64, riscv64; '3 4 + .' answers 7.
make -C v4 test-32: 0 failures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Top-level 'qemu' fell through to v3/Makefile, which has no such rule.
qemu, qemu-esp and qemu-gdb now go to kernel/Makefile; with ARCH given on
the command line and no TARGET, 'clean' is the kernel's for that ISA.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
