pika-orch-incus-cleanup-23

The old RunnerKind enum (HostLocal, RemoteLinuxVm, TartLocal) encoded both where a job runs and what virtualisation backend it uses in a single value. This branch splits it into two independent enums:

pub enum JobPlacementKind { Local, RemoteSsh }
pub enum JobRuntimeKind  { HostProcess, Incus, Tart }

These are paired inside JobExecutionConfig, which exposes three canonical constants (HOST_LOCAL, REMOTE_SSH_INCUS, LOCAL_TART) for the combinations that are currently supported. The run_job_on_runner dispatcher now performs a two-level match — first on runtime_kind(), then on placement_kind() — and returns explicit bail!() errors for combinations that are not yet implemented (e.g. remote-SSH Tart, local Incus). This makes it straightforward to add new placement×runtime pairs later without touching existing arms.

JobSpec gains three new fields:

The old magic string comparison job.id == "tart-env-probe" for deciding whether to mount the Rust toolchain is replaced by a clean job.mount_host_rust_toolchain() accessor at crates/pikaci/src/executor.rs:1516. Every test helper (remote_incus_job_base(), host_local_job_base(), tart_job_base()) is updated to supply the correct JobExecutionConfig constant so that tests compile and correctly exercise each combination.

Previously JobSpec stored an Option<StagedLinuxRustLane> — an enum variant that encoded both which lane runs and how to run it. The branch replaces this with Option<StagedLinuxCommandConfig>, a plain data struct:

pub struct StagedLinuxCommandConfig {
    pub snapshot_profile: StagedLinuxSnapshotProfile,
    pub prepare_node_prefix: &'static str,
    pub prepare_description: &'static str,
    pub payload_specs: [StagedLinuxRustTargetPayloadSpec; 2],
    pub execute_wrapper_command: &'static str,
    pub workspace_output_system: &'static str,
}

This means the executor module (crates/pikaci/src/executor.rs) no longer needs to know anything about lane identity — it only consults the command config for the wrapper binary path, snapshot profile, and payload specs. The compiled_guest_command function, the Incus device configuration, and the remote snapshot directory logic all switch from .staged_linux_rust_lane() to .staged_linux_command().

The new crates/pikaci/src/catalog.rs (424 lines) defines:

• PikaStagedLinuxTarget — the 9 build-target variants (e.g. PreMergePikaRust, PreMergePikachatRust).
• PikaStagedLinuxLane — the ~27 individual lane variants, each mapping to a target and a command config.
• PikaStagedLinuxTargetConfig — per-target metadata (Nix installable paths, snapshot profile, shadow recipe).
• PikaStagedLinuxTargetInfoJson — a JSON-serialisable projection used by the --json CLI flag.

Each lane's command_config() method constructs a StagedLinuxCommandConfig by combining the target's shared settings with a lane-specific execute_wrapper_command path. This keeps the full catalog close to the binary entry point (main.rs) while the library crate (lib.rs) re-exports only the execution-time types.

The lib.rs public API now exports JobExecutionConfig, JobPlacementKind, JobRuntimeKind, StagedLinuxCommandConfig, StagedLinuxRustPayloadRole, StagedLinuxRustTargetPayloadSpec, and StagedLinuxSnapshotProfile — but no longer exports StagedLinuxRustLane or StagedLinuxRustTarget.

A new crates/pikaci/src/forge_manifest.rs module reads ci/forge-lanes.toml (located relative to CARGO_MANIFEST_DIR) and parses it with the toml crate (added as a workspace dependency).

The TOML structure is:

version = 1

[[branch.lanes]]
staged_linux_target = "pre-merge-pika-rust"
paths = ["rust/**", "Cargo.lock", ...]

The function branch_lane_paths_for_staged_target(target_id) returns Option<Vec<String>> — the path glob list for a given target, or None if the target isn't in the manifest.

In main.rs, the staged_linux_target_spec() helper drops its filters: &'static [&'static str] parameter. It now calls branch_lane_paths_for_staged_target and fails with a clear error if the manifest entry is missing. This removes approximately 200 lines of inline filter arrays from the match arms in target_spec(). Non-staged targets (e.g. tart-beachhead, android-sdk-probe) keep their inline filter lists via a static_filters() conversion helper.

Two tests in forge_manifest.rs verify that the manifest loads correctly for pre-merge-pika-rust and returns None for unknown targets.

The TargetSpec.filters field changes from a borrowed static slice to an owned Vec<String>, since the TOML-loaded paths are heap-allocated. A static_filters() helper converts the remaining &'static [&'static str] literals for non-staged targets.

Three factory functions in main.rs construct canonical base JobSpec values:

• remote_incus_job_base() — REMOTE_SSH_INCUS placement+runtime
• host_local_job_base() — HOST_LOCAL placement+runtime
• tart_job_base() — LOCAL_TART with a default host_setup_command for Xcode developer directory setup

All job definitions in the match arms now use struct update syntax (..remote_incus_job_base()) instead of repeating boilerplate fields. The Tart TART_HOST_SETUP_COMMAND constant is extracted at the top of the file so it can be shared across all Tart job specs.

TestPikaciJobFixture in crates/pika-git/src/pikaci_store.rs now sets placement: Some(JobPlacementKind::RemoteSsh) and runtime: Some(JobRuntimeKind::Incus) on every generated JobRecord. These Option-wrapped fields allow the serialised record format to remain backwards-compatible with older run bundles that lack the new fields.

In the executor test module, remote_incus_job_base() and host_local_job_base() mirror the main binary's factories. Every inline JobSpec literal in the test suite now uses ..remote_incus_job_base() or ..host_local_job_base() to fill in the execution config, replacing the old staged_linux_rust_lane: None field.

The Incus test helper build_snapshot_mount_plan_for_test adds the three new fields (execution, host_setup_command, mount_host_rust_toolchain) directly.

Two new files enforce structural consistency:

1. invariants/invariants.toml — declares the set of staged-Linux target IDs and the path to the forge-lanes manifest.
2. scripts/check_invariants.py — a Python script (runnable in CI) that:
   • Parses the invariants file to get the expected target list.
   • Parses ci/forge-lanes.toml to get the actual staged_linux_target entries.
   • Asserts that every expected target is present and that the manifest contains no unexpected targets.

This closes the loop: the Rust catalog.rs defines what targets exist, the TOML manifest provides their path filters, and the invariants script ensures neither side can add or remove a target without updating the other.

The log line emitted when a remote Linux VM job starts now includes the resolved guest command string as a trailing field. Previously it logged only the workspace_output_system (derived from the lane); now the compiled_guest_command() result is called at the top of run_remote_linux_vm_job and appended to the message. The label source also changes from lane.workspace_output_system() to workspace_output_system, a local variable derived from the staged_linux_command() config (or the literal "direct_guest_command" for non-staged jobs). This gives operators immediate visibility into what binary path will be invoked inside the VM.