ci: stop routing CI's cargo through the sandbox wrapper

[kjgbot]

Repairs the break I introduced in #153. Every PR on main currently fails.

What broke

Run sh ../ops/cargo.sh test --workspace
error: rustup could not choose a version of cargo to run, because one wasn't
specified explicitly, and no default is configured

ops/cargo.sh unconditionally redirects RUSTUP_HOME to $HOME/.relayflows-toolchain/rustup. On a runner that directory is empty, so the rustup shim has no toolchain to resolve. Seen on run 33815895797 (PR #139).

Why #153's verification missed it

Every command in that PR's local evidence had RUSTUP_TOOLCHAIN=stable in front of it:

$ cd kernel && PATH="$HOME/.cargo/bin:$PATH" RUSTUP_TOOLCHAIN=stable sh ../ops/cargo.sh test --workspace

and the workflow — and the report, and the PR body — recorded it without the prefix. The env var supplied the toolchain the empty RUSTUP_HOME could not, and my machine had one installed there from a prior bootstrap. So the tests I ran were real, but they were not the command I shipped. That's the whole defect: the evidence and the artifact diverged by one environment variable.

The fix

Kernel step: plain cargo test --workspace, matching the adjacent cargo build --locked --release whose passing runs already demonstrate the configuration works. The wrapper exists for a cloud sandbox — where the propagated tree drops files over a per-file size cap and each step must be able to obtain a toolchain itself. A GitHub runner has neither constraint, and dtolnay/rust-toolchain has already installed a default toolchain into the standard home.

SDK step: same problem, reached through npm test → test:prep → ops/cargo.sh build. Expanded npm test to its constituents and dropped test:prep. Its only real product is the relayflowd binary that tests/live-kernel.test.ts execs, and this job has already built one — so RELAYFLOWD_BIN now points at the release binary from the build step rather than compiling a second debug copy through a wrapper that cannot run here. live-kernel.test.ts:39 reads that variable directly.

test:prep's other half — chmod +x on the preflight CLI fixtures — is kept inline. The fixtures are committed 100755 so actions/checkout restores them anyway, but the guard is one line and the failure it prevents is an opaque EACCES deep inside a preflight test.

Verification

The honest statement: this one is verified by its own CI run on this PR, not by a local run. That is deliberate — the failure was environment-specific to the runner, so a local pass is exactly the evidence that already misled once here. The checks on this PR are the proof.

The coverage #153 intended is unchanged: the full kernel suite and all 26 SDK test files still run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR

[coderabbitai]

Warning

Review limit reached

Next included review available in 46 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: 1e8d4e9e-9914-4005-9e98-a840c9724801

📥 Commits

Reviewing files that changed from the base of the PR and between 3725025 and 70314b6.

📒 Files selected for processing (1)

• .github/workflows/cloud-runtime-artifact.yml

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing.

_{Comment @coderabbitai help to get the list of available commands.}

[kjgbot]

The toolchain fix works. CI is now red for a real reason.

Run 33816284259: cargo resolves, the kernel suite compiles and executes, and 33 of 34 tests in crash_resume pass. One fails:

worker_capacity::default_capacity_one_reopens_only_after_durable_completion_or_crash
crash_resume/worker_capacity.rs:149
  left: String("lane-a")   right: "lane-b"
test result: FAILED. 33 passed; 1 failed

That is a pre-existing regression on main, not something this PR causes. Bisected and filed as #155: #137 replaced first-runnable-step dispatch with a batch of every dependency-free step, so a capacity-1 worker now races between two independent lanes. 60/60 runs pass immediately before #137; ~15% fail at and after it.

So this PR is a judgement call, and it is yours

main is red either way right now — before this PR it fails at rustup could not choose a version of cargo, which is my bug from #153. The three options:

1. Merge this. CI runs the suites and reports one genuine failure. Every PR stays blocked until P1: #137 made dispatch order to a capacity-1 worker nondeterministic (60/60 → ~15% failure) #155 is fixed, but blocked for a true reason.
2. Merge this + revert kernel: dispatch runnable steps in parallel #137. Unblocks everything and removes the regression, at the cost of losing parallel dispatch until it is repaired properly.
3. Revert ci: run the kernel and full SDK suites #153 entirely. CI goes green immediately and goes back to testing four SDK files and no kernel at all — green because it looks at nothing.

I have not merged. My standing flows autonomy is "green and no PR feedback", and this is not green; more to the point, #155 is a regression in a PR I merged, so choosing how to unblock it is not mine to make quietly at 01:30.

My recommendation is 1 — a red CI naming a real bug is worth more than a green one that never runs the test. But 2 is defensible if the lane needs to keep moving tonight.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR