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
The workflows' containers are now lithosananke-runner:72b6cf370db1, built
and published by runner-image.yml, with everything init installs and Maven
already in it; the install steps are gone, except the documents' packages in
nightly-docs.yml and release.yml. The registry refuses anonymous pulls, so
each job pulls with PACKAGES_TOKEN.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
build.yml off master (#119); the runner image recipe (part of #120); the Try-it page in the .com landing page style.
Accepted by acceptance.yml, run 166, on 7be2047a.
demo/: the demo Zuse, the saved machine, the session, the ttyd service, an Apache example and the XWiki page. Closes#112, #113, #114.
Accepted by acceptance.yml, run 163, on 4f6a267b.
Captain Bob, 2026-11-06: "I want the try it as it's very own page and
use the landing page we designed earlier ... as a baseline."
The landing page is the .com's Main.WebHome. The Try-it page follows
it: a floating box -- Your Machine, in place of Quick Facts -- a linked
title, == sections, {{info}} and {{warning}}. It goes at TryIt on the
.com (/bin/view/TryIt/), with the console embedded and links back to
the landing page and the source.
The page is on the .com now, so apache-demo.conf lets the .com frame
the console (frame-ancestors), and the demo's host is
try.starshipos-f18.com.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-06: a small server, a little sluggish. Each change
cost about an hour of runner time; the gate itself is about 15 minutes.
#119 -- build.yml runs on pushes to the working branch only. What
reaches master arrives through a PR whose content just passed
acceptance; checking it again cost ~23 minutes after every merge.
#120, first step -- ci/runner-image/Dockerfile: gitea/runner-images'
Ubuntu 24.04 (with Node, for the actions) plus what
make ARCH=amd64,aarch64,riscv64 init INIT_DOCS=0 installs -- run from
the Makefile itself, not a copied list -- and Maven for publishing.
.gitea/workflows/runner-image.yml builds it and publishes it to the
package registry as lithosananke-runner:<commit>. The workflows switch
to it in a later change, once it is published and has passed
acceptance. It needs the runner to lend jobs its Docker daemon
(container.docker_host: automount) and a PACKAGES_TOKEN secret, unless
the Actions token may publish packages.
make init does git lfs install --local only inside a checkout: the
image build is not one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-06: a terminal with QEMU amd64 for people to play
with; "Mint Zuse for demo console" (#111); "Make the most recent of
builds that's green the demo"; a Try-it XWiki page with the console
embedded.
demo/ -- see its README:
mint-zuse.sh a Zuse of the demo's own, as a stick: blank pair,
system=v3 genesis, a second boot to confirm, make
zusestick. Never anyone's real Zuse
build-iso.sh the amd64 ISO, packed as make qemu packs it
make-snapshot.sh boot once to [zuse@Hera] ok>, save the machine
start-session.sh one visitor: the saved machine resumed, ended on
hang-up, close or time-out
console.py joins the visitor's terminal only once the machine
runs; keys typed while it loads are discarded
qemu-args.sh the machine, shared by save and resume
starshipos-demo.service, apache-demo.conf, xwiki-try-it.xwiki
Every session is a copy: no network, read-only image, the Zuse stick's
writes discarded, QEMU's seccomp sandbox, an unprivileged user, a
fenced systemd unit, 30 minutes at most.
Tested here, from the sources master accepted (run 153): the Zuse
minted (logs/20261106-192626, -192739); the saved machine at POST
538/538 and [zuse@Hera] ok>; a session through ttyd's websocket ready
in 0.2 s, 3 4 + . -> 7 ok, 7 SQUARE . -> 49 ok; QEMU gone at once on
hang-up, close and time-out. Found and fixed on the way: a machine
saved stopped resumes stopped; a prompt matched as a regex; QEMU left
behind by a hang-up; keys lost while the machine loads. Not tested
here: Apache, several sessions at once (#116).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
master's only commit not on the branch is c809de73, the merge of #30, whose tree is the
branch's own 0fd7648a. Nothing changes in the tree; the branch protection's up-to-date
rule is satisfied.
Merges StarForth-v4.0.0 into master: StarForth v4 as the default system, the tree reorganised
(v3/, kernel/, boards/), the stick and the identity gate, and the day's CI -- the acceptance gate,
the nightlies and release to Nexus. Closes#19, #18.
Accepted by acceptance.yml, run 153, on 0fd7648a: amd64, aarch64, riscv64 to [zuse@Hera] ok>, the
PC stick loaded high (the three agree on dict_hash), make -C v4 test-32 -- the first acceptance
run in CI. The quick checks (run 152) passed too.
Issues follow the record's Found / Ruled / Built / Verified
(docs/fabric/FABRIC-3.md): the reporter writes what was found and its
evidence; Captain Bob rules; the commits build it; the acceptance logs
verify it. A finding is not a request to fix it (.claude/CLAUDE.md).
.gitea/ISSUE_TEMPLATE/
1-bug.yaml Found, where, system (v4/v3), seen on (ISA, stick,
hardware), evidence (the log lines), how found
2-work.yaml what, why (the ruling or design section), done when
(with the acceptance protocol and its logs), area,
priority
3-ruling.yaml the question, the options and their costs, a
recommendation, where the ruling will be recorded,
what waits on it
4-board.yaml board, the image booted (Nexus version or commit),
what happened, the serial log, the BRINGUP.md item
config.yaml blank issues still allowed; the XWiki linked for
design and discussion
.gitea/pull_request_template.md what and why, Closes #, acceptance
(the check runs itself; hand-run logs; hardware), the
record (FABRIC-3.md, CHANGELOG), no unrequested fixes
Gitea reads these from the default branch: they apply once on master.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The day's record, in FABRIC-3.md's own form (ruled, found, built,
verified, open): the review's three v4 bugs; the logs and DoE CSVs put
into LFS; make init with syft and Isabelle2025-2; the Doxygen fix; the
nightlies, the release and the Nexus coordinates
(org.starship:kernelImage and :documentation, classifier by board); the
runner's Debian 11 default found and every job moved to Ubuntu 24.04;
the acceptance gate and master's protection; the StarForth repository
archived as a tag and deleted, this one renamed LithosAnanke; Gitea's
labels, milestones, issues #4-#29 and PR #30; what is still open.
CHANGELOG.md: the same, in one paragraph.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-06: what a developer runs, what CI runs and what
the nightly runs are one process, and "failures should not be allowed
to be merged to master".
acceptance.yml runs on every PR into master (opened, pushed to,
reopened): .claude/CLAUDE.md's acceptance protocol through the same
scripts/nightly.sh stages -- amd64, aarch64, riscv64 to [zuse@Hera]
ok>, the PC stick loaded high (and the three agree on dict_hash), then
make -C v4 test-32 -- one QEMU at a time, in one job. Its logs and DoE
CSVs are kept, pass or fail. master's branch protection requires it.
acceptance, nightly and release share the concurrency group qemu, so
the runner never runs two of them at once: CLAUDE.md's one-QEMU rule
holds in CI too. build.yml becomes the quick check on pushes only.
.claude/CLAUDE.md's Hard Rules: commit and push directly on the working
branch; master only through a PR that passed acceptance, no direct
pushes; no approval required while there is one developer. Named: the
Captain Bob method.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
build.yml, as master had it, could not run here: it called
Makefile.starkernel and make T=<board> (the tree has kernel/Makefile
and TARGET=<board>), listed a Pi 4 with no port, published "releases"
under org/f18 on every push, installed Isabelle2024 (the proofs need
Isabelle2025-2) from a mirror that answered 503, and duplicated the
nightlies with its own 02:00 schedule. Now it is the check on every
push to master and StarForth-v4.0.0 and every PR into master: each
board's image (make boot_image TARGET=PC|RASPI|MILKV, xz'd, kept with
its SBOM) and make -C v4 test, both cell widths. It publishes nothing;
the nightlies and release.yml do.
Every job of every workflow now names its container,
gitea/runner-images:ubuntu-24.04-v26.11.03: the runner maps
ubuntu-latest to node:20-bullseye, Debian 11, where every job of PR
#30's runs failed at its first apt-get, and which has no
qemu-efi-riscv64 and a far older QEMU and compilers than the Ubuntu
24.04 all of this was tested on. Node is needed in the image:
actions/checkout and upload-artifact run inside the job's container.
The dated tag keeps a run from changing under an image update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Claude
rajames