The target, in the owner's words

"compile busybox. then, we can have a qemu with random kernel on random cpu with busybox with shell and self-hosting compiler running a simple kiosk application."

This is an umbrella. Do not claim it — claim a rung. It exists so the rungs inherit the owner's priority through the dependency edges, and so nobody re-derives the decomposition.

Why this target is worth its rank

It is the first thing that would exercise the whole stack end to end at once: the C frontend on real syscall-heavy source, crtl (the thin layer), the self-host, a cross target, and the runtime under a real kernel rather than qemu-user. Every existing corpus proves one layer. This proves they compose.

The rungs, in order

busybox cat, standalone — ~~feature-c-corpus-busybox-applet~~ DONE 2026-08-31. Byte-identical to a gcc-built binary across 12 input cases on x86-64 AND aarch64 under tools/run_target.sh, and equal to upstream's own separately-linked busybox_CAT. Repeatable: tools/busybox_diff.sh --applets cat. Cost three compiler fixes and the aarch64 IR_ALLOCA port; see the resolved ticket.
busybox multi-applet + ash — the shell half. DONE 2026-09-01 at twelve applets, 61 translation units, 114 cases, byte-identical to the gcc oracle on x86-64 AND aarch64. Cost fifteen compiler/runtime fixes, every one found by ATTEMPTING the target.

2b. The userland, built busybox's own way — DONE 2026-09-02. feature-c-corpus-busybox-userland-by-separate-compilation [C] dropped the unity for separate compilation, and then the applet set kept going:

applets TUs objects cases

rung 2 (unity) 12 61 — 114

unity, widened 26 82 — 154

separate 80 149 149 261

All byte-identical to the gcc oracle, which now builds separately too — a unity oracle would have capped this mode at the unity's own ceiling, and that ceiling is gcc's rather than pxx's (busybox's struct globals pattern is one namespace claim per applet).

Getting from 12 to 80 cost, all found by attempting it and all closed: x & 0 never folding a constant-false branch; sizeof yielding a fixed 64-bit type where size_t is pointer-width; the #if evaluator being purely signed where C99 6.10.1 wants intmax_t/uintmax_t; a macro call being silently mis-expanded past sixteen arguments (and hanging the compiler on busybox's own factor.c); static on a C function being ignored by the object writer; crtl being defined globally in every object (frankA); and sixteen crtl gaps enumerated in one measured pass.

x86-64 only for the separate build — --emit-obj has no object writer for aarch64 ([[feature-a-object-output-for-arm32-and-aarch64]]). aarch64 is proven at 26 applets by unity build, which is the honest cross claim today. feature-c-corpus-busybox-multi-applet [C]. FIRST BAR MET 2026-09-01 (2789f87a7): cat+echo+the multiplexer, NUM_APPLETS 2 with the dispatch table compiled IN, byte-identical to gcc over 28 cases on x86-64 and aarch64, argv[0] and busybox <applet> both. Cost one compiler fix — a constant left operand of &&/|| survived every -O level including -O3 (88ef1232f). The ash-and-TU-surface caveat that used to close this paragraph — "still open, which is why the rung is not resolved" — is spent: ash is in the 258-applet set, the TU surface is 400 of libbb's ~145-plus-applets rather than 28, and all three rung-1/2 tickets are in done/. feature-eliah-shell is done/ and is our own shell, a separate artifact; this rung is busybox's. Rung 1 says explicitly what it does NOT establish: cat reaches 25 of libbb's ~145 TUs, and the ones it misses are where pwd/grp/statfs/ getrlimit are actually called — stubs-by-omission today.
qemu-system + a kernel. DONE 2026-09-04, [[feature-b-a-bootable-image-with-the-busybox-userland-on-it]]. The 258-applet pxx busybox is PID 1 (the guest hashes /proc/1/exe) and the 621-case list runs inside the guest byte-identical to the host gcc oracle. Kernel: Alpine v3.21 vmlinuz-virt, 6.12.81-0-virt, fetched. tools/mkkiosk.sh --busybox= --cases=.
The compiler self-hosting inside the image. x86-64 half DONE the same day — --busybox --selfhost reaches stage1 == stage2 in a VM where PID 1, the shell and every tool are pxx-built. The cross-CPU half is what is left, and it is the strictly stronger claim: blocked on [[feature-a-object-output-for-arm32-and-aarch64]] (no aarch64 --emit-obj, so no aarch64 busybox) and on a SECOND TICKET THIS PARAGRAPH NAMED AND THAT DOES NOT EXIST: bug-a-the-compiler-cannot-cross-build-itself-for-aarch64 has never been a file in this repo (git log --diff-filter=A over every branch finds nothing), and the nearest real work, [[feature-cross-selfhost-aarch64]], is in done/. A bare slug in prose is invisible to check, which reads blocked-by: — so this one read as a live blocker for as long as anyone believed it. Whether the compiler cross-builds itself for aarch64 today is NOT settled by removing the citation; it is unmeasured, and saying so is the honest state. Related and not identical: bug-a-the-cross-self-host-proof-runs-a-different-configuration-than-the-native-one.
The kiosk application — MET on x86-64, and deliberately NOT filed. examples/kiosk.pas is pxx-built, ships in the image, and answers about, sum N and primes N in the booted VM. The rung was left unfiled until the image existed because its shape depended on what the image could do; the image can do it, so there is no work here to coordinate, rank or remember. A ticket would be bookkeeping for something already true.

	applets	TUs	objects	cases
rung 2 (unity)	12	61	—	114
unity, widened	26	82	—	154
separate	80	149	149	261

Host dependency: RESOLVED 2026-08-30

The owner granted sudo and qemu-system is installed, verified running (10.2.1). Coverage is better than the target needs — every pxx backend has a system emulator:

qemu-system-aarch64  qemu-system-arm      qemu-system-riscv32
qemu-system-riscv64  qemu-system-xtensa   qemu-system-x86_64  qemu-system-i386

/dev/kvm is present, so the x86-64 image runs at native speed and the cross images run emulated. "Random kernel on random CPU" is now a real choice rather than an aspiration — and qemu-system-xtensa in particular is new ground for Track S, which had qemu-user only.

Kernel + rootfs: SETTLED, by measurement on 2026-08-30 and unchanged by rung 3 — fetch Alpine's netboot vmlinuz-virt (12 MB, one second) rather than build one (hours, and it teaches nothing about pxx). No rootfs at all on x86-64: an initramfs of our own binaries plus, since the pxx busybox is dynamic, ld.so and libc. This paragraph read as open for three days after it was closed, and rung 3 was filed against it — the actual gap was one line of tools/mkkiosk.sh booting DEBIAN's busybox as PID 1.

decide-install-qemu-system-and-a-freebsd-image-on-plexus [p55] asked for this emulator and a FreeBSD image. The emulator half is now done; the multi-GB FreeBSD image is a separate call and stays open.

2026-09-11 — rung 4's unmeasured half is MEASURED: the compiler DOES cross-build itself for aarch64

Rung 4 above says, correctly and deliberately, that removing the phantom citation did not settle the question and that "it is unmeasured, and saying so is the honest state." Measured now, at compiler 71cc6d89b954, tree 7203485eb:

./compiler/pascal26 --target=aarch64 compiler/compiler.pas <out>     rc=0
file <out>   ELF 64-bit LSB executable, ARM aarch64, statically linked   17073012 bytes
tools/run_target.sh aarch64 <out> --version   prints generation 26 and its frontend list

It builds, and the result runs and answers --version under the aarch64 runner. So the compiler cross-building itself for aarch64 is not a blocker on anything, and the old cpreproc.inc:2105 LoadFile expects a managed-string destination failure is gone.

THE RANKING CHANGE, WHICH IS THE POINT: rung 4's cross-CPU half was described as blocked on two things, one of which was the phantom ticket. It is blocked on ONE: [[feature-a-object-output-for-arm32-and-aarch64]] — no aarch64 --emit-obj, so no aarch64 busybox, so no aarch64 userland to self-host inside. A rung blocked on one known feature is a different proposition from one blocked on a compiler that allegedly cannot build itself.

WHERE THE STALE CLAIM WAS STILL LIVE, AND WHY THAT MATTERS MORE THAN THE MEASUREMENT. This paragraph retired the citation; tools/mkkiosk.sh kept it, as a six-line hazard block at :128 asserting the failure as "a measured gap rather than a choice", plus a runtime echo at :222 telling anyone who boots a non-x86-64 image the same thing. Fixed in this commit. A stale hazard block is the expensive kind because obeying one produces no signal — it exists to stop a reader, it succeeds, and a reader who stops generates nothing that could reveal it was wrong. It stopped two sessions on 2026-09-10/11: this seat read it and relayed it to Track D as current fact, and Track D declined to publish it on the grounds that the underlying ticket had resolved. It was one edit from entering public docs as a documented limitation.

What is still NOT measured, so this note does not create a new phantom: nobody has booted an aarch64 guest with a pxx compiler in it. tools/mkkiosk.sh still ships none, which is now a payload decision with a cost rather than an impossibility.