Context
`home build` today only emits host-target binaries (Mach-O on macOS, ELF on Linux, PE on Windows). There's no flag to produce freestanding object files suitable for kernel linking.
Audit (2026-05-01) of the home-os kernel found that stages 3 (compile-to-object) and 4 (link kernel image) of the audit could not be tested at all — every kernel module ICEs in host-codegen with errors like:
- `error.FileSystemAccessDenied`
- Double-extension filenames (`foo.home.home`)
- `call to undefined function` for kernel-only intrinsics
- DebugAllocator memory leaks
These are codegen-target mismatches, not per-module bugs. Files that typecheck cleanly (e.g. `arch/arm64/boot.home`) still fail at this stage because the compiler is trying to make them macOS executables.
Proposal
- Add `--target=<triple>` accepting at minimum: `x86_64-freestanding`, `aarch64-freestanding`, plus the existing host targets. Triple format aligned with Zig's target syntax is reasonable.
- Add `--kernel` (shorthand): no libc, no host runtime, freestanding ABI, position-independent if requested. Either implies `--target=<host>_arch>-freestanding` or is composable with `--target`.
- Make output object-file format selectable (`--emit=obj` to produce a `.o`, `--emit=bin` for a binary). Kernel work needs `.o` files that link with `ld`.
- Wire through to the codegen layer — disable host-OS dependent intrinsics, use freestanding entry-point conventions.
Why this matters
Without a freestanding target, home-os cannot be built with the Home compiler at all — the build dispatcher in home-os falls back to Zig as the assembler/linker, but the Home → object step is the broken link.
Audit reference
`~/Desktop/home-os-kernel-audit-2026-05-01.tsv` on the maintainer's machine; section "Limitations" of the audit report explicitly flags this as the blocker for ever moving past stages 1-2.