feature - implement governed std.process for Oven execution

[dannymeijer]

Area

• Incan Language (syntax/semantics)
• Tooling (CLI/formatter/test runner)
• Runtime / Core crates (stdlib/core/derive)
• Documentation

Problem statement

RFC 063 / #341 defines std.process, but no implementation issue currently delivers the constrained process capability needed for Incan-authored Oven. Oven must invoke and supervise direct rustc and test workers without shell-string execution, inherited Cargo state, opaque output handling, or unaccounted host authority.

Without this surface, Oven's planner may be authored in Incan but the operation that makes its plan real remains an ad-hoc Rust escape hatch. That prevents a clear Cargo-free authorship boundary and weakens diagnostics, cancellation, and receipt evidence.

Proposed solution

Implement the bounded, capability-governed std.process surface required by Oven and usable by ordinary Incan automation:

• argument-vector-first commands with an explicit executable, working directory, and environment overlay;
• streamed stdout/stderr with retained structured exit status and command diagnostics;
• explicit timeout, cancellation, and process-group termination semantics suitable for compiler and test-worker trees;
• no implicit shell and no inherited Cargo compilation environment unless the caller explicitly grants and records it;
• capability checks and structured receipts compatible with RFC 104 / RFC 104 - full ambient runtime capabilities and receipts #662;
• a typed host-kernel capability usable by an Incan-authored Oven planner, rather than arbitrary Rust Command access.

The first implementation need not deliver the full shell DSL or every pipeline convenience proposed by RFC 063. It must be sufficient to run, observe, cancel, and explain Oven's supported direct-rustc and test-worker commands.

Alternatives considered

• Keep process spawning inside Rust-only Oven commands. Rejected because it leaves normal Oven execution outside the Incan authoring boundary.
• Use shell strings. Rejected because quoting, portability, environment provenance, and cancellation become ambiguous.
• Expose arbitrary Rust process APIs through rust::. Rejected because the host capability boundary would be neither stable nor governable.

Scope / acceptance criteria

• In scope:
  • Typed command, output, failure, timeout, cancellation, and receipt models.
  • Command execution with explicit cwd and environment overlay.
  • Streaming/captured stdout and stderr sufficient for rustc JSON diagnostics and test-worker output.
  • Process-group cancellation and bounded waiting on supported Unix-like hosts.
  • Capability grants/denials and redacted structured receipts.
  • Incan-authored acceptance coverage for successful execution, non-zero exit, timeout, cancellation, environment isolation, and Cargo-environment exclusion.
  • One Oven integration proof using the public Incan API to supervise a supported direct-rustc or test-worker command.
• Out of scope:
  • Shell DSL syntax and broad interactive shell compatibility.
  • Arbitrary pipelines, remote execution, or Windows-native process semantics.
  • Cargo delegation or emulation.
• Done when:
  • An Incan module can run and supervise the bounded Oven command shape through std.process.
  • The command's authority, invocation identity, output/diagnostics, termination result, and redactions are available as structured receipts.
  • Oven can use the same capability without a Cargo subprocess in the normal supported path.

Related work

• feature - Oven: Cargo-free Incan/Rust toolchain and native Rust facets #975 — Oven: Cargo-free Incan/Rust toolchain
• feature - Incan-authored Oven and toolchain components #870 — Incan-authored Oven and toolchain components
• RFC 104 - full ambient runtime capabilities and receipts #662 — ambient runtime capabilities and receipts
• RFC 063 / rfc proposal - RFC 063: std.process — process spawning and command execution #341 — std.process contract