Design a maintainable guard for workflow Rust toolchain pinning

[pawellisowski]

Context

PR #490 fixed the two current workflow jobs that bypassed cli/rust-toolchain.toml. Its custom guard was intentionally removed before merge because review showed it was becoming an incomplete model of shell and GitHub Actions behavior.

Problem

A future workflow edit could reintroduce a floating or alternate Rust toolchain. A useful guard must cover more than literal cargo commands: actions such as Swatinem/rust-cache invoke Cargo internally, environment overrides can exist at workflow, job, container, and step scope, and nested tracked toolchain files can override the repository pin.

Desired outcome

Design a small, maintainable enforcement mechanism that:

• covers direct Cargo steps and known Cargo-running actions;
• accounts for supported GitHub Actions environment scopes, including container.env and Windows case-insensitive keys;
• considers tracked repository toolchain files without scanning ignored worktrees;
• avoids hand-parsing arbitrary shell;
• fails clearly when a new workflow shape requires an explicit policy decision.

Acceptance

• The guard rejects a floating installer, a literal alternate version, a late installer, a known Cargo-running action before installation, RUSTUP_TOOLCHAIN overrides, and tracked nested toolchain files.
• It accepts ignored/untracked worktrees.
• Its implementation remains deliberately bounded and reviewable.

Related: #490

[pawellisowski]

🤖 Picked up by the morning issue routine on cloud-issue-routine-aware at 2026-09-09T04:36:08Z.

Another machine reading this issue will skip it while this claim is live (it expires after 14h). The claim is released when the run finishes, whatever the outcome.

---

Generated by Claude Code

[pawellisowski]

🤖 Morning issue routine on cloud-issue-routine-aware: shipped in #506, merged as 09829008. Claim released; labelled qa-ready rather than closed, since a merged fix is ready to test.

The guard is cli/tests/toolchain_pin_gate.rs, and it takes the shape PR #490 arrived at rather than the one it started with: the pin reader is an exact contract, compared verbatim, so no shell is parsed. Every acceptance criterion was verified by planting the mutation into the real workflows, running the suite, and restoring the tree:

Acceptance	Result
floating installer (@stable)	rejected
literal alternate version (toolchain: 1.88.0)	rejected
late installer, and producer after consumer	rejected
known Cargo-running action before installation (Swatinem/rust-cache above Install Rust)	rejected, naming the step and its uses:
RUSTUP_TOOLCHAIN at workflow, job, container.env, step scope, and lowercase	rejected in all five
rustup override set stable, cargo +toolchain in any spelling or layout	rejected
tracked nested toolchain file, even one agreeing with the pin	rejected
git-ignored .claude/worktrees checkout	accepted, correctly
unclassified action	rejected, naming it and where to classify it

On "covers known Cargo-running actions". Naming Swatinem/rust-cache closes today's instance; it does not stop the next such action being assumed inert. So every uses: in every workflow must be classified as the installer, Cargo-running, or Cargo-inert, and an unlisted one fails the build asking for the decision. That is also the issue's "fails clearly when a new workflow shape requires an explicit policy decision" clause. The repo uses nine distinct actions, so the lists are nine lines.

Two lines of ci.yml changed, both required by the contract: shell: bash on the two pin steps that lacked it, and the POSIX-sed note moved out of the script into a YAML comment so the four steps can be byte-identical.

Review. Codex reviewed five times and raised four findings, every one real, every one reproduced against the real workflows before being fixed and fixed at the root: a bash line continuation hiding a selector; cargo.exe not counting as Cargo; the PowerShell and cmd continuations; and a continuation splitting the word itself, which on the previous head meant such a job was not recognised as a Cargo job at all. Each was two of the guard's own notions disagreeing — what Cargo is called, what "adjacent" means, which text is read — so each fix made them one shared definition instead of patching the instance. The fifth review was clean on the merged commit, with all 14 CI checks green on it.

Where it stops, written into the file's doc rather than left to be rediscovered: it sees a selector a contributor wrote, in any layout, which is the accident this guard exists for. It does not see one the shell assembles at run time (c=cargo; $c +nightly), and nothing that reads YAML can — chasing that is what took the previous guard to twenty-eight findings.

One defect of mine, for the record. The squash body on 09829008 ends with two stray XML tag lines from how I passed it to the merge API. main is append-only so it stays; the commit's content is unaffected.

---

Generated by Claude Code

[pawellisowski]

Shipped in v0.135.0 (npm @aware-aeco/cli@0.135.0) — update and test; close on pass or label qa-rejected if it fails.

Note: the fix for this one (#506) is a CI guard rather than shipped CLI behavior, so verification is on the workflow contract, not the installed binary.

---

Generated by Claude Code