Claim: the boots page gains 5.1's milestone. The fault guest reads past its RAM, and Glint decodes the exit as 'VM exit: memory fault read 0x1000000'.

Passage: the maintainer's 'more ascii animations of glint as it progresses, please' (ocx-console 40c80385db).

Demonstration: the cast is the file bin/glint-run wrote on x86-1 at trunk a2cd7a25a9 for the command in its entry, which exited 0. Its log shows 'fault guest: started', the VM exit line, and 'Hello from the ESP!'.

Size: one cast, one entry in boots.js.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX check-in: 9937a19808 user: x86-1-glint tags: trunk

Claim: a guest memory fault becomes an architecture-neutral Glint::Access, holding the guest-physical address, read/write/fetch, whether it came from the guest's own page-table walk or the final address, and size and register when the architecture reports them. Svm.decode_fault fills it from EXITINFO1/2; on x86_64 size and register are unknown (0 and -1), because SVM doesn't report them. The VM exit line for a memory fault now names the kind and address. bin/glint-build fault-guest x86_64 builds a second program from guest/test/ that reads guest-physical 0x1000000, the first byte past guest RAM.

Passage: MOS4/5 §3.6.2 ('Page Fault Handling'), paraphrased because the text isn't in the workspace.

Demonstration: on x86-1, bin/glint-run x86_64 --mode hypervisor --guest build/x86_64/guest/fault.efi printed 'fault guest: started', then 'VM exit: memory fault read 0x1000000 rip 0x20110e', then the prompt, and never 'read returned'. spec/access_spec.cr decodes recorded (info1, info2) pairs built from QEMU 11.1.2's bit definitions (cpu.h 345-351, svm.h 144-145, excp_helper.c 524-544). With the vcpu, fault and image-check specs and the phase 2, 3 and 4, backtrace and vcpu boots, all with QEMU set: 40 examples, 3 failures, 8 pending; the failures are the known aarch64 Phase 2 boots. Codex wrote it from docs/tasks/5.1.md; the reviewer made no changes. Review note, outside the task and kept: bin/glint-run now reads for 100 ms after its --expect match instead of stopping at once, so a report or prompt that follows the matched line is in the log. The x86_64 boot specs pass with it.

Size: +102/-23 non-spec lines; largest new image function decode_fault, 319 bytes; BOOTX64.EFI 197,120 to 201,216 bytes. Size and register for x86 wait on the maintainer's answer (glint b142e85cea).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX Leaf check-in: 9249796637 user: x86-1-glint tags: slice/5.1-x86_64

Claim: the boots page gains recordings for 3.6/3.6b (a guest image placed, with its CRC), 4.1 (a breakpoint trap that resumes), 4.3b (hypervisor mode refused without SVM, and why) and 4.6 (a fault in Glint's own code, with its backtrace), in milestone order with the earlier three. Every recording now carries a 'Watch for:' line saying what to look for.

Passage: the maintainer, ocx-console 40c80385db: 'more ascii animations of glint as it progresses, please.' Relayed with the request to record each milestone, in glint c7b925827e.

Demonstration: each cast is the file bin/glint-run wrote on x86-1 at trunk 34d29c2621 for the command its entry names. Three exited 0; fault exits 1 by design, since the boot ends in Glint's panic report. The lines each 'Watch for' names were read from those runs' logs: 'Guest image: ... 8 relocations, crc32 0x4765cbdb', 'Trap: breakpoint at ...' and 'breakpoint: resumed', 'Mode: native (hypervisor requested; SVM not available)', and 'Backtrace:' with four frames.

Size: four casts (784-1,092 lines each); boots.js rewritten for the new entries and one line to show 'Watch for'; one CSS rule in index.html.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX check-in: 8a9569fc4d user: x86-1-glint tags: trunk