- scripts/nightly.sh images builds the PC's USB stick too (make boot_image
TARGET=PC -> pc-stick.img.xz, in SHA256SUMS); publish sends it to Nexus
as classifier pc-stick. pc stays the ISO QEMU boots.
- scripts/nightly.sh gitea-release <tag>: the tag as a Gitea release -- a
pre-release for -alpha.N and the like -- notes from the tag's message with
the checksums, the images, SHA256SUMS, the documents and the StarshipOS
Root CA's certificate attached; run again, it adds only what is missing.
release.yml runs it after the Nexus publish, with the secret RELEASE_TOKEN.
Tested here: images builds pc-stick.img.xz (785 KB); gitea-release against
a stand-in Gitea API made a pre-release with the notes and ten files, and a
second run added nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Since #151 an idle guest halts (1% of a core at the prompt), so the cap no
longer has to hold back spinning sessions. Captain Bob set 1.5 cores for
all sessions together on the server (2026-11-08): one busy visitor a full
core, half a core always left to the wikis and Gitea. Confirmed on the
server with a live session idle for 3 minutes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
An idle StarshipOS kept a CPU core 100% busy: sk_v4_readline(), with
nothing typed, and sk_v4_identity_wait(), headless until Zuse, waited in
arch_relax(). Both now halt until the next interrupt (hlt; wfi on aarch64
and riscv64): the heartbeat's timer, ISR-driven on all three, wakes them at
100 Hz, so a key is still seen within a tick.
Idle at the prompt, QEMU's CPU: 100% -> 1% of a core on amd64, 1% on
aarch64 and riscv64. Acceptance passes: amd64 logs/20261108-005539, aarch64
-005753, riscv64 -010136 (POST 538/538, one dict_hash, 7 ok), the stick
loaded high, test-32 (39 programs, 0 failures). FABRIC-3 XLVIII.5.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The canvas's Home and Inquiries artboards gain a 'Try it' link (canvas
versions 12, 13); canvas/ copies them, build.py rebuilds the pages, and
install.sh put them on the wiki. Checked as a visitor: the home page, the
link, the Try it page in 1.1 s, its framed console Ready. FABRIC-3 XLVIII.4.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
An idle StarshipOS guest keeps a host core 100% busy (measured 2026-11-08:
QEMU at 100% of a core, 148 MiB, the guest idle at its prompt; #151).
starshipos-demo.service: CPUQuota=100% and Nice=19 for all sessions
together, MemoryMax=1G -- sized for this server, where the old 300% and 4G
let two visitors starve both wikis and Gitea. DEPLOY.md says how to apply
it. FABRIC-3 XLVIII.4: Try it deployed and checked from outside; the ttyd
package's own login service; #151, #152.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Ubuntu's ttyd package starts ttyd.service, which runs login on port 7681;
installed by step 1, it took the port, and try.starshipos-f18.com served
the server's login prompt until it was disabled (2026-11-08). Step 4 now
disables it first and checks what listens on 7681. And the check from
outside, done: ready in 1.5 s, 7 ok, 49 ok, the third visitor busy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Five steps on the server after #148: the checkout and amd64 build tools,
the demo's own Zuse, the image and the saved machine at 384 MiB, the
service, TLS and Apache for try.starshipos-f18.com; then the check from
outside and the .com's navigation link (#115, #116, #117).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Today's rulings and work since XLVII.6, kept at the pace of the work
(Captain Bob, 2026-11-07: 'the book of fabric needs to keep pace'): the
alpha.4 list (#147) and what is in it, the developer protocol (#135), the
Book of Fabric (#138), the SDK milestone with the capsule repository (#149)
and the latency DoE (#150), #136 and the demo's guests and busy message,
with what was measured.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: 'Limit guests and have a Busy, try back in a few
minutes.' start-session.sh takes one of DEMO_MAX_GUESTS slots (default 2),
a lock it holds for the session's life (flock -n: two visitors cannot both
take the last one; QEMU and the bridge are started without its descriptor);
with every slot taken, the visitor's terminal says every machine is busy and
to try back in a few minutes, and the session ends without a machine. The
service: DEMO_MAX_GUESTS=2, RuntimeDirectory for the locks, ttyd's
--max-clients 6 so a visitor over the limit reaches the message. The guest:
384 MiB (v4 boots from 256 MiB, refuses at 128; measured, #116). Tested
here: every slot held -> the busy message; slot 1 held -> slot 2 taken.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Run 197's riscv64 failure (#131) could only be read from the run's logs
artifact, which Gitea's API does not list. qemu_session.py's check() now
prints, on a FAIL, the serial lines after the first match of an anchor the
check names, or the log's last lines; control characters as escapes, so a
stray byte or terminal sequence in a line shows instead of only failing a
match. The boot-disk checks anchor on 'Boot successful!'. A passing run
prints as before (riscv64 here, logs/ committed).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
On 50d2bc98 (LithosAnanke v4.0.0-alpha.3), in this session, one QEMU at a
time in the foreground: amd64 logs/20261107-195526, aarch64 -195725,
riscv64 -200055 (POST 538/538, dict_hash=0xfec8c47cfc6f437f on all three),
the stick loaded high, test-32 (39 programs, 0 failures); the proofs
through the capped stage, logs/20261107-195341 (47 s, ~1.8 GiB).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
v4.0.0-alpha.2's release run (200) was killed in the StarForth session:
Isabelle's defaults (Java 4 GiB, a thread per CPU). scripts/nightly.sh
proofs now runs one thread, Java 512 MiB, Poly/ML 900 MiB, through a
settings file of a home made for the run (heaps linked to the user's):
47 s, ~1.8 GiB, logs/20261107-195341. Nothing was published from alpha.2;
its tag stays. LITHOS_VERSION 4.0.0-alpha.3. FABRIC-3.md XLVII.6.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Acceptance run 197 (#130) failed one riscv64 check: no 'Boot disk: not a
StarshipOS stick' line, with POST, the identity and the prompt all passing.
Booted three more times here on the same tree: each printed the line and
passed (4 of 4 with logs/20261107-184616). The Zuse stick has no ESP
(--esp-mib 0), so the firmware cannot have booted from it; the serial
capture losing or garbling the line is what is left to check, against run
197's own log.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The protocol on 04006bff (LithosAnanke v4.0.0-alpha.2), in this session,
one QEMU at a time in the foreground: amd64 logs/20261107-184040, aarch64
-184241, riscv64 -184616 (POST 538/538, dict_hash=0xfec8c47cfc6f437f on all
three), the stick loaded high -184753, test-32 (39 programs, 0 failures),
the Isabelle/HOL proofs (logs/20261107-185450/).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
v4.0.0-alpha.1's release run (196) was killed in the proofs: release.yml's
full `make init` fetched Isabelle into the workspace and pointed isabelle
at it, without the image's prebuilt HOL-Library, so the proofs built it
from scratch. Nothing was published. Ruled: the tag stays; release.yml runs
`init INIT_PROOFS=0`; LITHOS_VERSION 4.0.0-alpha.2, the first published
alpha. FABRIC-3.md XLVII.5, CHANGELOG.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The image runner-image.yml built from master 4f675c8b (run 193): what init
installs, Maven, and the HOL-Library heap fetched prebuilt (checksum OK, 4.8
s), so the proofs build only the StarForth session. Its acceptance run is
this PR's.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: "I also want that rebuilds block other jobs
always." acceptance, nightly and release shared the group qemu; now
runner-image, build and nightly-docs do too, so a rebuild of the runner
image (on the host's Docker daemon) never overlaps another job, whatever
the runner's capacity (#121). On this server every CI run is then one at a
time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The server cannot build it (5.3 GiB from scratch; capped, still 2.6-3.3
GiB against ~2.3 GiB free). The heap built here by the same Isabelle2025-2
is a generic package in this repository's registry (45 MB, SHA-256
bb247846...e999cb339e); the Dockerfile fetches it into Isabelle's system
heaps with the checksum pinned, the token a build secret. Portable: a
fresh Isabelle home with only this heap checks StarForth without
rebuilding HOL-Library. FABRIC-3.md XLVII.4.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The protocol on 4ca935d8: three boots (POST 538/538, one dict_hash), the
stick loaded high, test-32 (39 programs, 0 failures), the proofs. Every
capsule logs 'missing (unsigned)': the kernel reads the new certificate;
CI signs with CAPSULE_SIGN_KEY. FABRIC-3.md XLVII.3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Made on the CI box by ci/pki/make-ca.sh (2026-11-07 16:50 UTC): subject
O=StarshipOS, CN=StarshipOS Capsule Signing; issuer O=StarshipOS,
CN=StarshipOS Root CA; 2026-11-07 to 2036-11-06; CA:TRUE, pathlen:0;
Ed25519. SHA-256 of the DER
13a28dda4098ef4f11cba42823a30a9898fdaffdf0c15130126fd2fe029b9a6c. Its key
is the repository secret CAPSULE_SIGN_KEY; the root's stays on the box.
The snakeoil intermediate leaves the tree (its history is in git).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The acceptance protocol on b7534107 (LithosAnanke v4.0.0-alpha.1), in this
session, one QEMU at a time in the foreground:
- amd64 logs/20261107-150809, aarch64 -151023, riscv64 -151359: [zuse@Hera]
ok>, PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED,
dict_hash=0xfec8c47cfc6f437f on all three
- the PC stick loaded high, logs/20261107-151539: the same, no fault
- make -C v4 test-32: 39 programs, 0 failures
- Isabelle/HOL proofs, logs/20261107-152312/isabelle: Finished StarForth
CHANGELOG and FABRIC-3.md XLVII: the ruling, what was verified, and what
an alpha leaves open (the v4.0.0 milestone; unsigned capsules until the
StarshipOS CA).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: "Kernel is 4.0.0. This is our first alpha
release." LITHOS_VERSION 2.1.0 -> 4.0.0-alpha.1; the engine (VERSION)
stays 3.2.0. The 4.x line is a working line (even major); v3.0.0 is no
longer the next number, and an LTS line takes the next odd major when
FABRIC-3.5.md XXX.5's criteria are met. Recorded in kernel/Makefile's
versioning policy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: "The banner XWiki should not say that." Both
wikis now have a colour theme of their own, FlamingoThemes.StarshipOS (the
stock Iceberg, copied, with the starshipOS wordmark as its logo; Iceberg
untouched), and the browser tab's title ends "- StarshipOS". Installed on
both; checked as a guest on each (logo and title), and the .org's top bar
seen logged in.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Five website commits queued five Build runs (183-187), ~17 minutes of image
builds each on the server both wikis run on; the .org stopped answering.
build.yml now ignores pushes whose changes are all under site/.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: "Menu bar". For guests only, the .com pages and
the .org landing page hide XWiki's top bar, breadcrumb, title block, page
menu, panels, footer and tour, and the design runs the full width (a
velocity check on $isGuest; the stylesheet in a literal block). Logged in,
the wiki is all there. Checked on a phone and a desktop: the chrome is
hidden on Main, Inquiries and TryIt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
- site/colorlock.py: both XWikis force black and white with !important (a
HIGH CONTRAST DARK THEME block in the skin's cssVariablesInit.css). On our
pages only, the design's colours win: each inline colour made !important,
and a stylesheet scoped to the page root (.ssos) for the rest. Used by
site/com/build.py and site/org/build.py; the .com reinstalled with it.
- site/org/inquiries (Captain Bob, 2026-11-07): the .com's inquiries go to an
admin-only master/detail on the .org -- Inquiries.WebHome (Live Data
table), one page per inquiry under Inquiries.Entries with a sheet and a
status, PublicInquiry (public) filing them with its author's rights and
echoing nothing a visitor sends; a hidden trap field for robots. The .com
form posts there. Installed and tested: a guest's inquiry filed and
deleted; one whose name and message were script macros was stored as
text, nothing ran.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The first run on starshipos-f18.org created the dashboards, then XWiki
refused the group and rights objects: a form-encoded POST needs XWiki's
form token (CSRF), an XML one does not. For about two minutes Admin.WebHome
and Contributors.WebHome were readable by guests (links and the names of
secrets, no values). Objects now go as XML, and the spaces' rights are made
before the pages, so a failed run cannot leave a dashboard open. Installed:
Main 200, Admin and Contributors 401 as a guest, 200 as rajames; a second
run changes nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: build the .com from the StarshipOS.com canvas.
canvas/ holds the artboards as drawn; build.py makes Main, Inquiries and
TryIt as {{html}} pages (the wiki's links and domains, the images as
attachments, the real console in Try it, the forms by e-mail); install.sh
puts them on the wiki and checks a guest's view. Installed on
starshipos-f18.com: every page and image reads 200 as a guest, and renders
without a macro error.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: style .org like the StarshipOS.com design canvas.
build.py makes the three pages from one source, as {{html}} blocks in the
canvas's look (navy, orange accent, JetBrains Mono and Exo 2), and the same
pages as the canvas's .org artboards.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Ruled by Captain Bob, 2026-11-07: a generic landing page for anonymous
visitors, a login-protected admin dashboard for him, and a protected
contributors' dashboard. Main.WebHome (everyone), Admin.WebHome
(XWiki.rajames alone), Contributors.WebHome (XWiki.StarshipContributors
and the administrator); CI shown as Gitea's live workflow badges.
install.sh puts them on the wiki through XWiki's REST API, with the group
and the space rights, and checks a guest's view. Not yet run: the .org
XWiki answers 503.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Nightly 174 passed acceptance, then Isabelle was killed building HOL-Library
(exit 137, out of memory on the runner), and the images were never built or
published. The proofs check the theories, not the images: they now run after
the publish, whatever happened before them, and a failure still turns the run
red. Their log stays in the run's logs artifact. A release still runs them
before it publishes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Ruled by Captain Bob, 2026-11-07: "New root CA on the CI box. Valid
StarshipOS rather than snake oil intermediate."
- ci/pki/make-ca.sh makes the StarshipOS Root CA (its key stays on the CI
box) and the StarshipOS Capsule Signing intermediate it issues, and
stores the signing key as the secret CAPSULE_SIGN_KEY.
- The kernel finds the signing certificate by one name,
CAPSULE_SIGNING_CERT_NAME = pki:starshipos-intermediate.der. The
certificate itself lands once make-ca.sh has run; until then the
snakeoil intermediate is in the tree under its old name and the
capsules check as "no root key" (a warning, as "missing" was).
- mkcapsule refuses a signing key that is not that certificate's.
- SIGN_KEY has no default; acceptance, build, nightly and release set it
from the secret.
FABRIC-3.md XLVI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Measured here (Isabelle2025-2, one thread): HOL-Library from scratch takes
~11 minutes and peaks at ~5.3 GiB -- what nightly 174 was killed doing; the
StarForth session on a built HOL-Library takes under a minute and ~2.2 GiB.
The image builds HOL-Library once into Isabelle's own heaps, so every job
finds it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Nightly 174 passed acceptance, then Isabelle was killed building HOL-Library
(exit 137, out of memory on the runner), and the images were never built or
published. The proofs check the theories, not the images: they now run after
the publish, whatever happened before them, and a failure still turns the run
red. Their log stays in the run's logs artifact. A release still runs them
before it publishes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Claude
rajames