master (d2a0305) was a strict ancestor of v2.0.1 (72c14cb) -- pure fast-forward, no real merge needed. Fast-forwarded local master, pushed to origin (58c59e8..72c14cb). Verified on a genuinely clean master tree rather than inferring from the fast-forward: hosted build clean, 3-arch kernel acceptance (amd64/aarch64/riscv64, each in the foreground) all reached ok>/zuse)ok> and shut down cleanly, identical to v2.0.1's own last acceptance pass. master and v2.0.1 are now identical on both local and origin. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
5.1 KiB
FABRIC-3.md — bare metal boot
Status: Living working document, opened 2026-09-04 as the successor to FABRIC-2.md
(now closed/archival — see its own header). Topic for this document, per direct instruction:
bare metal boot — getting LithosAnanke to actually boot on real hardware, not just QEMU.
FABRIC-2.md §I.6 (Milestone 8) already named this as the one item that pass couldn't close
from a coding session at all, for exactly this reason — it needs a real machine and a human
physically present. This document is where that work, and everything downstream of it, gets
tracked.
How to use this document going forward. New findings, new punch-list items, and new
decisions for bare-metal-boot work get added here, not to FABRIC-2.md. Same discipline every
prior document in this series used: write the decision and its reasoning down before building,
close items with a dated note citing real evidence, never silently drop a stale claim.
I.1 — Task 1: merge v2.0.1 into master, verify build/function equivalence
Written up before executing, per direct instruction and this series' own standing discipline.
Why this is task 1. FABRIC-2.md's entire 7-step closure pass (§I.1–§I.5, §I.7, plus
today's FABRIC-series rename) happened on the v2.0.1 branch, not master. Before any real
bare-metal-boot work starts, that work needs to land where .claude/CLAUDE.md says the
project's sole production line actually lives: master. Doing this first, cleanly, before
starting new work avoids ever having two divergent lines to reconcile later.
Investigated before writing this up, not assumed:
git merge-base --is-ancestor master v2.0.1— true.master(local HEADd2a0305) is a strict ancestor ofv2.0.1(HEADb031b80) —v2.0.1is exactlymasterplus 47 commits forward, no divergent history on either side. This means the "merge" is a pure fast-forward, not a real three-way merge — nothing to resolve, no conflict possible.origin/mastercarries exactly one commit beyond localmaster(58c59e8, "Initial commit") that localmasterhadn't fetched yet — confirmed already contained inv2.0.1's own history (git merge-base --is-ancestor 58c59e8 v2.0.1— true), so it introduces no discrepancy either.master's own tree still has the oldFABRIC.md/FABRIC-2.md/FABRIC-3.mdnaming (unrenamed) — expected, since today's rename commit (b031b80) only exists onv2.0.1so far. The fast-forward brings the rename tomasteralong with everything else; nothing separate needs doing for it.
Plan:
- Fast-forward
mastertov2.0.1's tip (git checkout master && git merge --ff-only v2.0.1) — refuses loudly instead of silently doing a real merge if the ancestor relationship somehow isn't what the investigation above found, so this step re-verifies its own precondition. - Push
mastertoorigin. - Verify build/function equivalence on a genuinely clean tree, not by inference:
git clean(after confirming nothing untracked-but-wanted is present), then the full acceptance sequence.claude/CLAUDE.mdalready mandates for any kernel change —clean qemuon all three architectures, in the foreground, one at a time, each reachingok>and shutting down cleanly. Since the tree is byte-identical tov2.0.1's post-fast-forward, this is expected to reproduce exactly whatv2.0.1's own last acceptance pass already showed — the point of re-running it here is to confirm that expectation holds onmasteritself, not to assume it from the fast-forward alone. - Return to
v2.0.1as the working branch afterward (.claude/CLAUDE.md's own rule: always return to the correct working branch after any out-of-branch work), unless told otherwise.
DONE 2026-09-04, exactly as planned:
- Committed the write-up above on
v2.0.1first (72c14cb), pushed. This becamev2.0.1's new tip. git checkout master && git merge --ff-only v2.0.1— Fast-forward,d2a0305..72c14cb, confirming the investigated ancestor relationship held exactly as expected; no conflict, no merge commit.git push origin master—origin/mastermoved58c59e8..72c14cb.- Verified on a genuinely clean
mastertree, not inferred from the fast-forward:- Hosted build (
make clean && make): clean compile, zero warnings, same asv2.0.1. - Full 3-arch kernel acceptance (
clean qemu, amd64/aarch64/riscv64, each in the foreground): all three reached(zuse) ok>/ok>and shut down cleanly, zero build errors, zero unexpected warnings — identical outcome tov2.0.1's own last acceptance pass, confirmed directly rather than assumed. Logs:logs/20260904-113208/amd64/,logs/20260904-113320/aarch64/,logs/20260904-113552/riscv64/.
- Hosted build (
masterandv2.0.1are now identical (72c14cbon both,originand local). Returned tov2.0.1as the working branch per plan step 4.
Task 1 closed. master genuinely is the production line again, current through today's
FABRIC-series rename and the full FABRIC-2.md §I closure. Bare-metal-boot work (this
document's actual topic) starts from here.