Route hosted fs/time/rand exe builds through the capable direct backend

[WalterGropius]

Summary

• zero run / zero build --emit exe for hosted std.fs/std.time/std.rand programs rejected with CGEN004 even on direct emitters that fully lower those operations.
• The bare direct-exe path is now permitted for hosted programs when the selected emitter can lower them; the ELF64 x86-64 backend already lowers fs/time/rand as inline syscalls and produces a self-contained static executable (no manual cc, no generated C).
• Emitters without that lowering (e.g. AArch64 Mach-O) still report CGEN004 at emit time, so unsupported targets stay honest.

Source

Addresses P0-3. Reproduction confirmed against main @ 5b91e7f (host darwin-arm64).

Before this change, on the unmodified compiler:

• zero build --emit exe --target linux-musl-x64 conformance/native/pass/std-fs.0 → CGEN004: direct backend does not support target 'linux-musl-x64' for --emit exe
• zero build --emit obj --target linux-musl-x64 conformance/native/pass/std-fs.0 → succeeds (1944-byte ELF64 object; the ELF64 emitter lowers all std.fs operations as inline syscalls).

Root cause: the exe path's default_direct_exe gate calls self_host_subset_compatible(), which returns false whenever any host capability (fs/time/rand/net/proc/web) is used. ir_needs_zero_runtime_object() only recognizes JSON/HTTP, so fs/time/rand programs never reach the runtime-link plan either and fall through to CGEN004, despite the ELF64 exe emitter being fully capable of producing a self-contained static binary for them.

Changes

• native/zero-c/src/main.c: add direct_exe_emitter_handles_hosted_runtime() / direct_exe_supports_hosted_program(); use them in the default_direct_exe decision at the build dispatch and the parallel target-readiness diagnostic. Gated to zero-elf64-exe (the only emitter with inline-syscall fs/time/rand lowering). Updated the CGEN004 zero explain rationale.
• conformance/run.mjs: add assertHostedDirectExe and register std-fs.0, std-fs-bytes.0, std-fs-fallible.0; asserts a self-contained ELF64 executable (generatedCBytes:0, valid ET_EXEC x86-64) and runs it on linux-x64 hosts via the existing canRunLinuxMuslX64 gating. Append-only.
• docs-site/articles/cli-reference.md: document direct-backend behavior for hosted std.fs/std.time/std.rand in the Run section.

Conformance

• Fixtures: conformance/native/pass/std-fs.0, conformance/native/pass/std-fs-bytes.0, conformance/native/pass/std-fs-fallible.0 (registered via new assertHostedDirectExe).
• ZERO_NATIVE_TEST_ALLOW_LOCAL=1 pnpm run conformance:local → green (conformance ok, provenance guardrails ok).
• ZERO_NATIVE_TEST_ALLOW_LOCAL=1 pnpm run command-contracts:local → green (command contract snapshots ok).
• ZERO_NATIVE_TEST_ALLOW_LOCAL=1 pnpm run native:test:local → fails at a pre-existing, environment-only point: line 133 builds the JSON program std-json-duplicate-keys.0 for linux-musl-x64, which uses the unrelated runtime-link plan and requires zig (not installed on this host). Verified identical failure at the same line on unmodified main; not introduced by this change. Sandbox variant unavailable here (VERCEL_OIDC_TOKEN not present).

Regression checks: darwin-arm64 host std.fs still correctly CGEN004 (Mach-O AArch64 has no fs lowering); hello.0 host run, std-args.0 exe, and std-http-fetch.0 runtime-link run all unchanged.

Proposed CHANGELOG line

• Hosted std.fs/std.time/std.rand programs build as self-contained direct executables on backends that lower them (ELF64 x86-64), instead of failing with CGEN004.

🤖 Generated with Claude Code

[vercel]

@WalterGropius is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.