sk_v4_run's three stops -- "not started", "did not let go of POST's
blocks", "stopped on a fault" -- ended in for (;;) { }: a core spinning at
100%, the thing #151 removed from the prompt. Each now calls sk_v4_stop()
(kernel/src/v4/sk_v4_stop.c): interrupts off, then arch_halt() for ever. Each
still says why first. sk_v4_stop.c added to the loader's and the kernel's v4
sources.
kernel/tests/test_sk_v4_stop.c, with arch_halt and arch_disable_interrupts
faked (the halt jumps back out after three calls; an alarm fails a spin):
against the stop as it was -- "spun for 2 s without halting"; now -- 2
checks, 0 failures: halts in a loop, interrupts off before the first halt.
Built for amd64, aarch64 and riscv64. #177's "seen on the three
architectures": no boot reaches these stops, so it is shown on the host only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
a8824655's evidence log shows its "before" run failing to compile: the copy
of usb_config.c with the old decision was cut at the wrong brace by my script.
The failure the commit describes was real (seen in the session), but the log
did not show it. Rerun with a correct copy:
test_usb_config-before-rerun.log -- 20 checks, 10 failures (wTotalLength 1 to
9 asked for again; the cut unsaid). The first log is kept, as what it is.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
After the configuration descriptor's first 9 bytes the event loop asked for
min(wTotalLength, 128) whatever it was. A wTotalLength of 9 or less was then
asked for again as "short" -- for ever, that slot never leaving enumeration
(#170); 0 also issued a zero-length data stage. A set longer than the 128-byte
buffer was cut without a word, its later interfaces never seen (#171).
The decision is usb_config_request_length() (moved out of the event loop,
then fixed): 9 or less is 0 -- "xhci: a configuration of N bytes has no
interface -- not used", and nothing more is asked; longer than the buffer is
cut and said -- "xhci: config of N bytes cut to 128 -- rest unseen" (at most
53 characters). The buffer stays 128 bytes; its size is #171's to rule.
kernel/tests/test_usb_config.c, seen to fail first against the decision as it
was (10 failures: wTotalLength 1 to 9 asked for again, the cut unsaid), now
20 checks, 0 failures. Both runs in logs/20261112-180140/kernel-tests/. Built for amd64,
aarch64 and riscv64; the boots come with the protocol. #171's other box, a
composite device on the SER5, is Captain Bob's.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
xhci.c's XHCI_XFER_CONFIG_DESC_FULL case walked the descriptor set inline, in
the event loop, where nothing could test it. The walk is now
usb_config_parse() (kernel/src/usb/usb_config.c), returning what it found;
the case acts on it as before -- the same messages, the same decisions: the
first Interface descriptor only, a BOT interface's bulk endpoints (the last of
each direction), a boot keyboard's first interrupt IN endpoint, bLength 0
ending the walk, nothing read past len. One difference, in debug output only:
the bulk endpoints are logged IN then OUT, not in descriptor order.
kernel/tests/test_usb_config.c, 7 checks, pins the walk as moved: a BOT stick
as QEMU presents it, a boot keyboard with its HID descriptor, a mouse before a
drive (the first interface only), a drive with bulk IN only, bLength 0, an
endpoint cut by len, an interface cut before its protocol byte. All pass.
Built for amd64, aarch64, riscv64; the boots come with the protocol (a data
stick enumerates through this path). The fixes for #170 and #171 follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Captain Bob, 2026-11-12: "Build an appropriate test harness! Love the idea."
The kernel had no tests below the boots, so defects QEMU cannot provoke could
not be tested first. Plan: docs/v4.0.0/plans/2026-11-12-kernel-host-tests.md.
kernel/tests/: one host program per kernel source, built with that source as
it is, the kernel's flags (-std=c99 -Wall -Wextra -Werror), and fakes --
the console captured line by line, a deterministic RNG that can fail, and a RAM
disk whose reads, writes or flushes fail at chosen 1 KiB blocks.
make -C kernel/tests test runs them; SRC_<test>= runs a test against other
code, which is how a test is seen to fail against the code before a fix.
test_gpt.c, 12 checks: a table written and read back; 16, 17 and 18 used
entries against max 16 and an entry out of range after the 16th (#180); the
RNG, the first write, a later write and a flush failing (#168). Against gpt.c
before #168 and #180: 4 failures, each defect caught. Now: 0. Both runs in
logs/.../kernel-tests/. Not yet a protocol stage: to rule (the plan, step 5).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-164108/PROTOCOL.md, for the batch #172, #169, #185, #144, #143,
#181, #180 and the #187 test: the four boots 538/538, word_count=318,
dict_hash 0x8c92508f748f99cf on all three -- the new dict-hash stage (#172)
naming each; test-32 39 programs, 1,869,223 checks, 0 failures (the manage
test's 78 among them, #169); the proofs (43 s); the images, no race (#185);
the documents. The tree clean before and after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
gpt_read() stopped at max used entries (16 for the identity code, 4 in the
mint): a disk whose StarshipOS partitions came after the first max read as
having none, and the entries after max were never range-checked.
Now every entry is checked and every used one counted; a good table with more
used entries than max is GPT_MANY (the first max in parts), and the identity
code says "GPT: a USB drive has more than 16 partitions -- not used". Other
callers treat anything but GPT_OK as before.
Tested first, seen to fail: qemu_session.py gpt_many -- a data stick with its
two partitions as entries 17 and 18 after 16 others, and the same with an entry
19 past the usable range: both "not this system's stick" before (silently cut,
entry 19 never checked; logs/20261112-162236). After: "more than 16
partitions" and "a damaged partition table" (logs/20261112-162921).
Regressions: gpt_bad_entries, gpt_foreign PASS. gpt_zuse FAILS, on a stale
expectation unrelated to this change -- an identity-only GPT drive with no
system stick has been held silently as a possible real Zuse since #92 Task 4;
its log is kept here. The gpt_many images are made before the boot: a first
version made them after, failed in sgdisk and left its QEMU running, stopped
by hand (logs/20261112-162003).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
A data stick hot-plugged with every read at its identity partition's first
sector (LBA 2048) failing, after a boot with no drive; it expects a message
naming the identity partition, Artemis let go (both partitions or neither,
#179), no prompt, and the same stick without the fault going on to genesis.
add_stick() takes fail_read_sector for it.
It FAILS today, and is kept so (Captain Bob, 2026-11-12: "keep the test"):
the partition attaches anyway and Zuse is minted onto it, because
blk_format_or_load_disk() ignores the header read's result and takes an
unreadable disk as blank -- filed as #187. #179 is parked: its half-attached
state cannot be reached from a disk fault. The run: logs/20261112-160050.
Not part of acceptance.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
- heat.c call_index(): the comment read as an unfinished thought ("hash-mod or
just take low bits?", "ignore for now? Or clamp?"). It now states the rule
the code follows: indexed by the target, a target past the table not counted,
-1 telling the callers so; the table D-6's stand-in, which ENGINE step 4
Part A1 plans to remove.
- stack.h points 1 and 2 said there was no overflow detection "and there never
will be" and that a depth exceeded corrupted silently -- D-2, which D-16
revised. Now: guarded before every opcode, a mesh node 10 and 9, the host node
32 and 32 (D-17); C code that serves a node checks the depth itself.
- stack.c named an 8-ring and depths 10 and 9 only, and said D-2's rule still
held.
- DATASHEET-F18.md section 13 item 4 (this gap) struck, resolved in place.
Comments only: test_stack and test_heat unchanged at both widths (730,137 and
8,272 checks, 0 failures).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
The kernel build's only warnings were five -Wformat-truncation in mkcapsule's
--resolve: two snprintf copies of a capsule name into the claim registry, and
the capsule's path built from base_dir and its name.
- The names: both are char[CAPSULE_NAME_MAX], and names are checked to fit when
read (line 335) -- copied whole with memcpy, nothing to truncate.
- The path: base_dir may be up to 4095 bytes, so it can be cut, and a cut path
names another file -- now refused, the capsule left unchanged and counted
rejected, with the reason.
Seen to fail first: built with -Werror=format-truncation, 5 errors. After: 0,
and 0 warnings with the kernel's flags; the manifest it writes is
byte-identical, --lint passes. The too-long-path refusal is on --resolve's
interactive conflict path and was not driven by a test. CLAUDE.md's count of
open warnings corrected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
The header said "M6: Infrastructure present (validation deferred)" and "M7:
Not started (VM integration pending)", and "(LithosAnanke branch)" -- there
is no such branch since the split. .claude/CLAUDE.md had warned since
2026-08 not to propagate it instead of it being corrected. Now: M0-M6 and M7
complete, M7.1 in progress (as CLAUDE.md's Architecture section gives them),
v4 the system booted by default; the correction dated in place. The note in
CLAUDE.md's Gotchas goes, as #144 asks. Comments only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
kernel/Makefile gave capsules/v4/sys/map-64.f18 and map-32.f18 one rule with
two plain targets -- in GNU make, two rules sharing a recipe. Under -j both
ran at once: two make -C v4 sysmap built and ran the same v4/build/mkmap-<w>
side by side (Build run 255's RASPI job: "mkmap-32: Permission denied").
Now one grouped target (&:, GNU make 4.3+, as here and in the CI image).
Seen to fail first: the two targets with -j8, mkmap removed each time, 12
runs -- 6 failed ("Text file busy", "Permission denied"). After: 0 of 12.
Both sets of runs in logs/20261112-152711/race-185/. The map files are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
v4_manage_serve took its arguments with v4_dstack_pop and never checked the
stack's depth: a request with too few values acted on stale ring values, and
one whose results did not fit dropped the oldest silently -- around the D-16
guards. Now each request's arity (manage.h) is checked first: fewer values
than it takes, or no room for what it leaves, is error 12 with the stack as it
was -- as a block request is refused (blocks.c).
test_manage.c, written first and seen to fail (12 of 13 requests at both cell
widths; NODE-BORN passed only because the stale value read was below 1): every
request with one value fewer than it takes, and NODE-ME and CAPSULE-CELL on a
stack with no room -- refused, the stack unchanged. After: 78 checks, 0
failures at 32 and 64 bits; all v4 tests at 64 bits, 40 programs, 1,871,313
checks, 0 failures (logs/20261112-152602/v4-test).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
The stick-high stage passed when one distinct dict_hash appeared: an
architecture whose boot left no accept file, no LOG: line, no serial log or no
PARITY:V4_SYSTEM line gave nothing, and two that agreed passed for three.
It is now a stage of its own, scripts/nightly.sh dict-hash, which stick-high
runs: one hash from each of amd64, aarch64 and riscv64, all found and one value;
otherwise refused, naming the architectures with none or the values that
differ. NIGHTLY_OUT points the stages at another directory, for the tests.
scripts/test_nightly_dict_hash.sh, written first and seen to fail (6 of 6, the
stage not existing), then 7 cases: agree -- pass; differ, no PARITY line, no
LOG: line, not booted, no serial log, none at all -- refused. Two of them
caught lookups that ended the script silently under set -e; guarded.
Captain Bob, 2026-11-12: "172 then finish alpha.5".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-124144/PROTOCOL.md: the four boots 538/538, word_count=318,
dict_hash 0x8c92508f748f99cf on all three; test-32 39 programs, 1,869,197
checks, 0 failures; the proofs (StarForth, 37 s); the images; the documents.
The tree clean before and after.
Stage 3 (riscv64) was stopped while booting, when Captain Bob interrupted to
mean the build pipeline; its partial serial log and console output are kept,
labelled, in logs/20261112-124831/. It was rerun on the same commit and
passed (logs/20261112-130801).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
failed() printed "MINT-ZUSE: failed -- nothing changed" on every failure
after YES, though by then gpt_write_one() had rewritten the stick's partition
table and the identity partition's first blocks had been zeroed.
gpt_write_one() now tells the two apart: GPT_EIO when its first write failed
(nothing written), GPT_PART when a later write or flush failed (the disk is
changed). MINT-ZUSE keeps "failed -- nothing changed" for GPT_EIO only, and
says "failed -- the stick was erased; Zuse not minted" for every failure
after the table is written. The marker is still written last.
Tested first, seen to fail: qemu_session.py mint_part_fail (writes fail only
at the identity partition's first sector, LBA 2048) -- "nothing changed",
logs/20261112-122132. After: mint_part_fail PASS; mint_fail (every write
fails) still "nothing changed", PASS; replace (the success path) PASS. Their
logs here. FABRIC-3 XLVIII.20.
Captain Bob, 2026-11-12: "start #168".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-114545/PROTOCOL.md: one stage per foreground command (paused
between stages 2 and 3 for Captain Bob's emergency, then resumed on the same
commit): the four boots 538/538, word_count=318, dict_hash
0x8c92508f748f99cf on all three; test-32 39 programs, 1,869,197 checks, 0
failures; the proofs (StarForth, 44 s); the images; the documents. The tree
clean before and after.
The evidence for the held batch: plan section 8 (the FMEA in the PR review),
the notes, and scripts/ci_litter_check.sh (#129).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Each cleanup #129 set up (Captain Bob, 2026-11-07), and what proves it ran:
the Docker prune's and the package cleanup's logs written in the last 8 days;
no image older than 8 days that no container uses; at most KEEP (5)
lithosananke-runner tags; no artifact older than ARTIFACT_DAYS (30) + 1; no
Nexus snapshot asset older than 8 days (with NEXUS_USER/NEXUS_PASSWORD,
skipped and said so without); a dated disk line appended to HISTORY each run,
so "disk use flat" is a comparison of weeks. PASS:/FAIL:/SKIP:/INFO:,
RESULT:, exit 0 only if nothing fails.
Tested here against fixtures (a stale log, an old artifact, no docker -- each
FAIL; clean -- PASS) and a stand-in docker (one stale unused image of three --
FAIL, the in-use and the recent ones kept). The registry check ran against
the real registry: 2 tags. Not run here: the real Docker, Nexus.
Captain Bob, 2026-11-12: "Correct the issue text and write the check script".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Captain Bob, 2026-11-12: "Is it possible to include the FMEA in the pr
review? That way the items are forced into a manual review beforehand?" --
"Yes, add it to the plan". Each FMEA row names its paths; the PR carries a
review record with a decision for every row its diff touches; a
check_fmea_review.sh beside check_protocol.sh refuses the PR without one, or
with one for another diff. A sixth point to rule. Nothing built.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-001304/PROTOCOL.md: scripts/nightly.sh protocol, one stage per
foreground command: accept amd64, aarch64, riscv64, stick-high -- 538/538,
word_count=318, dict_hash 0x8c92508f748f99cf on all three; test-32 39 programs,
1,869,197 checks, 0 failures; the proofs (StarForth, 36 s); the images (PC,
RASPI, MILKV); the documents (book, fabric, dictionary, vol1-3, api). The tree
clean before and after. Every stage's output in logs/20261112-001304/protocol/,
the boots' serial logs and DoE CSVs beside it.
The first protocol run: the evidence the PR's Acceptance check now asks for.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
scripts/nightly.sh protocol: every stage a PR, the nightly and a release run --
accept amd64, aarch64, riscv64, stick-high, test-32, proofs, images, docs --
in order, never publish; the first failure ends it. protocol <stage>... runs
those only, so each can be its own foreground command (the QEMU rule);
accept-amd64 begins a protocol, recording the commit and whether the tree is
clean. protocol-report writes logs/<TS>/PROTOCOL.md (the commit, the tree,
each stage's result and output, POST and dict_hash per architecture compared,
test-32's totals, the proofs' log, the images' and documents' SHA-256) and
keeps every stage's output in logs/<TS>/protocol/ -- nothing is left only in
build/nightly. PASS only if every stage passed on the commit it began on and
the tree is unchanged but for the evidence.
acceptance.yml: scripts/check_protocol.sh on the PR's head, first, before the
boots. The PR template asks for PROTOCOL.md; .claude/CLAUDE.md names the
protocol as the acceptance a developer runs.
Captain Bob, 2026-11-07 (#135); 2026-11-12: "Keep working on alpha.5".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
scripts/check_protocol.sh [<rev>]: refused (exit 1) unless <rev> carries a
logs/<TS>/PROTOCOL.md naming a commit whose protocol passed on a clean tree,
and that commit differs from <rev> only in the evidence (logs/ and
experiments/bare_metal/runs/, committed after the run). Any other change since
makes the evidence stale: the protocol is run again.
scripts/test_check_protocol.sh, written first and seen to fail (8 of 8, and
tightened so a missing script is not taken for a refusal): no protocol, stale,
failed, dirty, unknown commit -- refused; fresh, fresh among stale ones, other
files in logs/ -- passes. 8 of 8 pass.
Not yet wired into acceptance.yml: that comes with nightly.sh protocol.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Captain Bob, 2026-11-11: "I'm thinking about adding a CAPA & FMEA GATE to our
build pipelines", then yes to writing it up. A nightly.sh quality stage run in
the acceptance gate: every kind/escaped issue has a CAPA record whose
preventive control exists and runs in a stage; every FMEA row over the
threshold has a control in the gate. Seeded with five CAPAs from 2026-11-11.
Five points to rule (section 7).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Every workflow shared the concurrency group qemu. A group keeps one running
and one waiting run, and a run that joins cancels the one waiting: Build
runs 245 and 247 were cancelled at 0 s by PR 164's Acceptance runs.
Captain Bob, 2026-11-11: "It should be global"; the runner has capacity 1.
So the concurrency block is removed from all six workflows (a comment in
each says why): with one runner at capacity 1 every job waits its turn in
Gitea's queue and none is cancelled, and a runner-image rebuild still
blocks the rest. CLAUDE.md's CI section corrected; FABRIC-3 XLVIII.19.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261111-193825/v4-test: make -C v4 test on feb740c5 -- 79 programs,
3,740,484 checks, 0 failures, at V4_CELL_BITS=32 and 64. CI's v4-tests job
(Build run 247) was cancelled at 0 s by the shared qemu concurrency group
(#140), so this is the run of record for that job.
logs/20261111-185352/nightly: what scripts/nightly.sh wrote only under
build/nightly for 9415d7ed's acceptance (d6846b34) -- the four accept
summaries, test-32 (39 programs, 0 failures) and the images stage (PC,
RASPI, MILKV). The test-32 output of the earlier 90c5c140 run was
overwritten in build/nightly before it was kept, and is not recoverable.
Captain Bob, 2026-11-11: all logs are evidence.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
XLVIII.18 records 2026-11-11: the LFS trim (Captain Bob: "they can be
trimmed out"), version.h untracked and BLOCK_MAP.md without its timestamp
(#145), my put-back error and its fix, the acceptance rulings (never in the
background; all logs and CSVs are evidence), the acceptance of 9415d7ed,
and alpha.4's Gitea release marked final.
README: alpha.4's release is no longer a pre-release.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Run one stage at a time in the foreground through scripts/nightly.sh:
20261111-185352 amd64 PASS
20261111-185600 aarch64 PASS
20261111-185950 riscv64 PASS
20261111-190128 stick-high PASS
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, [zuse@Hera] ok>
on every boot; word_count=318 dict_hash=0x8c92508f748f99cf on all three;
test-32 39 programs, 0 failures.
scripts/nightly.sh images -- the stage the version.h put-back had broken --
built PC, RASPI and MILKV and left the tree as committed.
DoE CSVs for every boot (empty, as every v4 acceptance boot's: #141).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
90c5c140 untracked v3/include/version.h, but six places still put it back
with git checkout. Git refuses the whole checkout when one path is unknown:
- scripts/nightly.sh images (set -e): the stage ended there, so the nightly
(images, publish, proofs) and release.yml (images, docs, gitea-release)
would fail. Acceptance does not run images, so it passed.
- scripts/check_images.sh (no -e), demo/build-iso.sh, demo/mint-zuse.sh
(|| true): silently put nothing back, BLOCK_MAP.md and the SBOM included.
- scripts/qemu_session.py: an error after every boot, otherwise harmless.
- boards/BRINGUP.md: the step said to put it back.
BLOCK_MAP.md stays in every put-back: a signed build (CI's) still rewrites
its Signed column. Found while setting up alpha.5; Captain Bob: fix it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
amd64, aarch64, riscv64 (clean qemu), stick-high, test-32, run one at a
time in the foreground through scripts/nightly.sh:
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, [zuse@Hera] ok>
on every boot; PARITY:V4_SYSTEM word_count=318
dict_hash=0x8c92508f748f99cf on all three; test-32 39 programs, 0 failures.
No tracked file changed across the five builds.
20261111-170703 amd64 PASS
20261111-170909 aarch64 PASS
20261111-171235 riscv64 PASS
20261111-171410 stick-high PASS
Also kept as evidence:
20261111-170134 amd64 on aec7ddb5 (before the clean-tree fix), PASS
20261111-170544 amd64 on 90c5c140, stopped by me during boot: it had been
started in the background, against the protocol, and was
rerun in the foreground as 20261111-170703
DoE CSVs for every completed boot (experiments/bare_metal/runs).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
v3/include/version.h is written by every build (kernel/Makefile and
v3/Makefile, both FORCE), with a timestamp and the last build's ARCH; the
committed copy was stale (LITHOS_VERSION 2.1.0). Untracked, and .gitignore's
entry corrected: it said include/version.h, the path before the move to v3/,
and matched nothing.
capsules/BLOCK_MAP.md differed on every build only in mkcapsule's
"Generated ... <timestamp>" header. The timestamp is dropped, so the manifest
changes only when the capsules do; two runs are byte-identical.
mkcapsule's warnings unchanged (5, #143).
Captain Bob, 2026-11-11: untrack version.h and fix the ignore; drop the
manifest timestamp.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Their pointers were committed in a5ed8c3d (2026-08-01) and the objects were
never uploaded: the server answers 404 for all of them, and no copy exists
(Captain Bob, 2026-11-11: "they can be trimmed out").
Removed: 3,827 phase-1 logs (docs/working/archive/legacy/phase-1), 3 in
docs/working/archive/historical, 106 DoE CSVs in experiments/bare_metal/runs,
QEMU_BASELINE.log, docs/SYSTEM_NARRATIVE.log, docs/ontology.log.
Kept: the 5 LaTeX build logs under docs/patent (legal hold) -- excluded from
fetch instead. .lfsconfig excludes every one of these paths, so older commits
check out and LFS fetches run without 404s.
Every LFS pointer left in the tree (1,195) has its object on the server.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
These logs/ files were committed as plain text even though
.gitattributes routes logs/**/*.log through the LFS filter, so every
fresh clone showed them all as modified. Renormalize them so they are
stored as LFS pointers. File contents are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
PublicInquiry files the inquiry as before, then mails it through the wiki's mail service: plain text, the subject fixed but for the topic (line breaks removed), Reply-To the visitor's checked address, a link to the filed entry. If it is not sent the inquiry is filed all the same; a new class field, mailed (E-mailed to Captain Bob), says which, shown on the entry's sheet. Installed on the .org; a guest's test inquiry filed and thanked, mailed 0 -- the wiki has no SMTP account yet (Mail.MailConfig: no host), which Captain Bob sets in Administration > Email.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The design canvas (v17) gains the Documents artboard -- the Book of Fabric and
the Dictionary of v4 first, then the book, the three volumes and the API
reference, each with its SHA-256, and the SSRN paper -- and Downloads and
Documents in every .com nav; Downloads' reading list becomes a pointer to
Documents. site/com/canvas/ copied from it.
site/com/build.py --release TAG --sums SHA256SUMS builds Downloads and
Documents from the release ([TAG], [RELEASE]/<file>, [SHA:<file>]; a file the
release's SHA256SUMS lacks fails the build). Without a release it builds Home,
Try it and Inquiries exactly as before -- byte for byte -- with no link to the
two pages, so they go live only with alpha.4. install.sh installs them when
built.
scripts/nightly.sh gitea-release: the release's SHA256SUMS now covers every
file it attaches -- the images' sums, then the PDFs and the Root CA's
certificate -- so `sha256sum -c SHA256SUMS` checks all of it and Documents
finds each sum. The Nexus artifacts keep their own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
make dictionary -> build/docs/Dictionary.pdf (20 pages): mkdictionary.py checks docs/reference/v4-dictionary.tsv against the booted system's words first, so a stale dictionary fails the build; then Markdown, pandoc, docs/book/dictionary.tex (the books' preamble, its own title page: version and commit). Quoted FORTH tokens set as code, so their quotes print straight. The nightly's docs stage builds it; publish sends classifier dictionary; the Gitea release attaches it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
The names from the system itself (the hosted v4's WORDS, plus the kernel's sk_v4_words[]); the stack notation and description in docs/reference/v4-dictionary.tsv, drafted from the source where it says (54 stacks, 105 descriptions), the rest to write. check refuses a missing, unfinished or stale entry.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
`make fabric` -> build/docs/BookOfFabric.pdf (722 pages): Part I the living
record (FABRIC-3), Part II the closed documents in the order written, Part
III the forward-looking notes; its title page carries the version (git
describe --tags: a release's tag) and the commit. Built from the same pandoc
fragments as the book; the book's preamble moved into docs/book/preamble.tex,
shared by both (the book builds as before, 821 pages).
scripts/nightly.sh: the docs stage builds it ($DOCS/fabric.pdf); publish
sends it as classifier `fabric`; gitea-release attaches every PDF in $DOCS,
so every release carries it. Progress for the rest of alpha.4's documents:
docs/v4.0.0/plans/2026-11-10-alpha4-documents.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Task 5 of plan 2026-10-29-stick-5, accepted in full, and with it #92:
- amd64, aarch64, riscv64: PARITY:V4_POST tests=538 pass=538 fail=0,
POST: PASSED; word_count=318 dict_hash=0x8c92508f748f99cf on the three
- the PC stick as built, loaded high: 538/538, the prompt
- make -C v4 test-32: 39 programs, 0 failures
Sessions: fallback, replace, mint_fail, system_pull_real; regressions:
every Task 4 session, genesis, stick_genesis, screen_dark_until_login,
screen_dark_after_logout, kbd_typeahead, emergency. Verdicts in
logs/20261110-075036/verdicts/. The plan's Task 5 ticked; STICK.md 11
increment 5a done; FABRIC-3 XLVIII.17; the SER5 bench steps in
boards/BRINGUP.md 4.2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Claude