Long reconciliation arc across both kernels today. Six PRs landed, one persistent class of misdiagnosis got named, and the practical 1MB ELF size cap that has shadowed JefeOS for months finally fell — sqlite3 boots and runs end-to-end via exec_linux.

Smoke baseline volatility, defeated

Cron-fired smoke jobs had been silently scoring against half-booted or wedged VMs, eroding the score across consecutive runs. Three PRs put it down: restore-network.ps1 -RestartVMs now covers JefeRust and waits 60s for DHCP before discovery (PR #37); the smoke pipeline triggers a VM Refresh inline on probe failure and re-probes (jenkins-pipelines #2); the 30-minute pipeline cap that aborted Syscall Coverage mid-run got bumped to 75 (jenkins-pipelines #3). The harness no longer kicks off a run against a known-dead VM.

JefeRust DHCP/APIPA: a fix in the symmetry

JefeRust would silently disappear from the host network after every Windows reboot. Hyper-V's NAT-DHCP can take longer than the 15-second boot retry budget to start answering on a freshly-rotated Default Switch subnet, so JefeRust fell back to APIPA (169.254.x.y/16) — but the APIPA path forgot to send a gratuitous ARP, which the DHCP-success path right above it does call. The host vSwitch ARP table never learned the link-local mapping, so no scan or ping found us. PR #42 mirrors the symmetry and adds a 30-second background retry task that re-attempts DHCP for ten minutes; on success, the lease installs itself via net::set_config() and the task exits. Two subagents handled it: one diagnosed in a worktree, the second implemented in another worktree, both behind the "one thread per kernel" rule.

The 1MB ELF cap was an allocator scalability problem

Task #60 — the long-standing "kernel can't load ELFs over ~1MB" cap — was diagnosed as heap fragmentation, but the real story was nastier: the heap is first-fit under an IRQ-disabling spinlock, and every kmalloc(>~70KB) walked a long freelist with all interrupts off. Network IRQs starved, SSH wedged. Bumping the heap (PR #38) made it worse; bumping the NTFS dir cap (PRs #39, #40) hit the same wedge mechanism through a different door. The fix that actually shipped (PR #43): kmalloc routes any request ≥ 64KB straight to pmm::alloc_pages with a 32-byte magic header so kfree can dispatch back. Heap freelist stays small, IRQ-disabled windows stay short. Verified live: exec_linux /programs/sqlite3 loads 835KB, reports "4 segment(s), 373 pages," and drops into the SQLite prompt.

The phantom panic

Three concurrent smoke jobs against a single JefeOS VM produce identical-looking failure signatures regardless of kernel correctness — "Host key not in manually configured list" cascades from a VM Refresh bouncing the kernel mid-run, not a kernel panic. Tracked the difference today: a 10-minute serial capture during an isolated PMM-bypass smoke run produced 104,000 lines of healthy SSH/TCP activity and zero PANIC/EXCEPTION/RIP markers, while concurrent runs the day prior had falsely accused the same kernel of crashing. Don't let the queue muddle your experiments.

NTFS dir scan, also closed

The companion to PR #43 was PR #41: resolve_path previously kmalloc'd a full DirEntry buffer per path component just to find one name. Replaced with a streaming find_dir_entry_by_name() that walks the $INDEX inline, matches each entry, and early-terminates on hit. Allocation drops from 72KB+ to nothing. list_directory_by_mft stays as-is for ls; lookups are now decoupled from NTFS_MAX_DIR_ENTRIES.

What's Next

• Python interpreter as the next workload (#81), now unblocked by the >1MB cap removal.
• Mirror the JefeOS #131 keyboard drain-loop fix into JefeRust (#146) — same Hyper-V Gen1 8042 quirk hits the Rust kernel too.
• Tier 4 chroot+busybox once those two land.