Files
ironclaw/scripts/ci/lib/rust_toolchain_contracts.py
Henry Park 453dcf554c ci: single setup-rust composite — toolchain pin, mold, centralized build profiles (T1) (#7821)
* perf(build): codify CI's debug=0 policy as the workspace dev/test/release profile

A handful of lanes (reborn-tests.yml's 10 jobs via workflow env,
reborn-e2e.yml's rust-reborn job, platform-and-compat.yml's
hooks-parity-tests/windows-build jobs, coverage.yml's coverage job, one
live-canary.yml step) already build dev/test at CARGO_PROFILE_DEV_DEBUG=0/
CARGO_PROFILE_TEST_DEBUG=0 via duplicated env decls; this is a true no-op
for them. Every other Rust-building job in the repo (code_style.yml's
clippy/test jobs, reborn-playwright.yml, sccache-dist-smoke.yml,
release-plz.yml, nightly-deep-ci.yml, and most of ironclaw-stress.yml/
live-canary.yml) has never set this env and builds at cargo's full-debug
dev default today, so this task changes their build fingerprint and costs
each a one-time Swatinem/rust-cache cold miss on its next run. Chosen
deliberately: this pays that cost once, up front, for the whole repo,
rather than smearing it across the 13 file-swap commits that follow.
ironclaw-stress.yml also separately restated CARGO_PROFILE_RELEASE_DEBUG=0
three times (already cargo's built-in release default, and now explicit
here too) — release build output is unaffected either way. Measured on
ironclaw_common tests: debug=0 175 MiB vs line-tables-only 257 MiB vs full
272 MiB.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci: add the setup-rust composite action (unused by any workflow yet)

One component for what toolchain, linker, and profile env a Rust CI job
gets: installs via the pinned dtolnay/rust-toolchain SHA, then exports
RUSTUP_TOOLCHAIN from the action's own resolved-toolchain output so a job's
cargo invocations can never drift from what this step actually installed —
no separate mechanism needed for nightly lanes. Optional mold: true absorbs
the install/verify/RUSTFLAGS-export steps currently copy-pasted per job.
No workflow calls this yet (following tasks swap each file one at a time),
so this cannot change CI behavior. New ws12 structural check on the action
file itself; self-tested.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(sccache-dist-smoke): install Rust via the setup-rust composite

No behavior change: the composite defaults to the same 'stable' toolchain
dtolnay/rust-toolchain already defaulted to; this job now also gets
RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(reborn-playwright): install Rust via the setup-rust composite

No behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN
protection ahead of rust-toolchain.toml landing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(release-plz): install Rust via the setup-rust composite

No behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN
protection ahead of rust-toolchain.toml landing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(nightly-deep-ci): install Rust via the setup-rust composite

No behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN
protection ahead of rust-toolchain.toml landing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(reborn-release-compile): install Rust via the setup-rust composite

No behavior change: same default toolchain and the same matrix.target
input, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(ironclaw-stress): install Rust via the setup-rust composite

No toolchain behavior change: same default toolchain, now with
RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Also
deletes the three CARGO_PROFILE_RELEASE_DEBUG=0 env decls, already no-ops
restating cargo's own release-profile default and now Cargo.toml's explicit
[profile.release] debug = 0 (landed in a prior commit).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(code_style): install Rust via the setup-rust composite

No behavior change: same default toolchain and the same clippy/rustfmt
component inputs, now with RUSTUP_TOOLCHAIN protection ahead of
rust-toolchain.toml landing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(platform-and-compat): install Rust via the setup-rust composite

No toolchain behavior change: same default toolchain and the same
wasm32-wasip2 target input, now with RUSTUP_TOOLCHAIN protection ahead of
rust-toolchain.toml landing. Deletes two now-redundant
CARGO_PROFILE_DEV_DEBUG/CARGO_PROFILE_TEST_DEBUG=0 pairs, no-ops since
Cargo.toml's [profile.dev] debug = 0 landed. Also removes the wasm-wit-compat
job's now-empty `env:` key left over once both its lines were deleted (a
dangling null mapping is valid YAML but dead config; no functional change).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(reborn-e2e): install Rust and mold via the setup-rust composite

No behavior change: rust-reborn keeps mold (now via mold: true — same apt
install, same verify commands, same canonical RUSTFLAGS prefix, moved into
the composite); webui-v2-smoke keeps the same default toolchain. Both now
get RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml. Deletes the
now-redundant literal mold RUSTFLAGS string and CARGO_PROFILE_*_DEBUG pair.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(coverage): install the nightly toolchain via the setup-rust composite

No behavior change: both jobs pass the same explicit
toolchain: nightly-2025-11-01 / components: llvm-tools-preview /
targets: wasm32-wasip2 as before, now through the composite, which pins
RUSTUP_TOOLCHAIN to that exact spec — the same protection the prior design
gave these two lanes via a hand-paired job env var, now automatic for every
composite call. Deletes the now-redundant CARGO_PROFILE_*_DEBUG pair in the
coverage job. check-reborn-branch-coverage-flags.py and
reborn_coverage_lane_stack_headroom.rs both still pass (their pinned
strings are untouched).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(reborn-tests): install Rust and mold via the setup-rust composite

No behavior change to toolchain resolution (same defaults/nightly pins as
before, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml)
or to the mold linker's effective RUSTFLAGS (the composite's mold: true
prepends the canonical prefix onto each job's existing RUSTFLAGS, so the
two nightly jobs' -Zcrate-attr suffix is preserved byte-for-byte). Absorbs
7 duplicated mold-install steps and 2 duplicated 'Verify mold linker'
blocks into the composite. Two disclosed minor deltas in
qa-recorded-fixtures: mold install now includes clang (already present via
the runner image; matches the other 6 sites) and now runs after, not
before, Install Rust. Deletes the workflow-level mold RUSTFLAGS/
CARGO_PROFILE_*_DEBUG trio, now no-ops. CARGO_INCREMENTAL lines and
RUST_MIN_STACK lines are untouched. check-reborn-branch-coverage-flags.py
and reborn_coverage_lane_stack_headroom.rs both still pass.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(live-canary): install Rust via the setup-rust composite

No toolchain behavior change: same default toolchain and the same 7
wasm32-wasip2 target inputs, now with RUSTUP_TOOLCHAIN protection ahead of
rust-toolchain.toml landing. Deletes the one now-redundant
CARGO_PROFILE_DEV_DEBUG='0' step env, a no-op since Cargo.toml's
[profile.dev] debug = 0 landed. CARGO_INCREMENTAL is untouched.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* chore(qa): drop the now-redundant CARGO_PROFILE_DEV_DEBUG setdefault

Cargo.toml's [profile.dev] debug = 0 is now the workspace default, so this
QA harness's env setdefault restates it for no reason. CARGO_INCREMENTAL is
untouched — incremental compilation stays a per-caller decision, not a
Cargo.toml profile setting (same reasoning applies to the sibling decl in
scripts/reborn_qa_matrix/run_hermetic_qa.py:101, left alone).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* build: pin the local Rust toolchain via rust-toolchain.toml

Pins exactly what CI's composite-installed toolchain already resolves today
(1.98.0 + clippy/rustfmt), so nothing rebuilds and rust-cache keys hold.
Safe now that every CI job installs Rust through .github/actions/setup-rust
(landed across the prior 13 commits), which exports RUSTUP_TOOLCHAIN and so
cannot be overridden by this file landing. Local clippy/rustfmt now match
CI's.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs(agents): document the toolchain pin and bump process

AGENTS.md is scanned by check-guidance.py; .github/workflows/README.md is
not (zero hits under ROOT_GUIDANCE/CRATE_GUIDANCE_BASENAMES), so this is
the enforced location for the bump instructions Task 19's ws12 guard
assumes contributors can find.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(gate): forbid direct dtolnay/rust-toolchain use; enforce the toolchain-pin sync

New contracts: no workflow may call dtolnay/rust-toolchain directly (must
go through .github/actions/setup-rust) or write out the canonical mold
RUSTFLAGS prefix by hand (must pass mold: true); rust-toolchain.toml's
channel and the composite's default toolchain input must name the same
version. Both are simple negative/equality checks, not per-site window
scans — collapsed from the abandoned per-input design specifically because
every job now routes through one component. Sabotage tests included.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): let the composite own RUSTFLAGS so job env cannot shadow mold

A job-level `env: RUSTFLAGS:` is re-applied to every step of that job on
top of whatever earlier steps wrote to $GITHUB_ENV, so it shadows the
setup-rust composite's export for the rest of the job — silently dropping
the mold linker flags. That hit the two heaviest lanes: crate-tests (the
required PR lane and the measured critical path) and
reborn-integration-coverage, both of which declared RUSTFLAGS for their
nightly `-Zcrate-attr` features. The pre-composite code manually pasted
the mold prefix into exactly those two job envs despite the
workflow-level env already carrying it, which is the historical symptom
of the same shadowing.

The composite now takes an `extra_rustflags` input and composes the whole
value (mold flags, then the job's flags, then anything already exported),
so no job-level declaration is left to shadow it. Both reborn-tests jobs
and both coverage.yml jobs pass their crate attributes through the input
instead; zero job-level RUSTFLAGS keys remain in the tree. Install Rust
precedes every cargo step in all four jobs, so the export covers them.

`validate_no_job_env_rustflags_with_setup_rust` pins the invariant: a job
installing Rust through the composite may not declare its own RUSTFLAGS.
It found the two coverage.yml jobs that this fix would otherwise have
missed. Three sabotage tests plus a live-tree assertion cover it.

Note for review: GitHub's documentation does not state the
$GITHUB_ENV-vs-job-`env` precedence explicitly. This change is correct
either way — with no job-level key there is nothing to shadow under any
precedence rule — so the fix does not depend on resolving that question.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): map .github/actions/setup-rust/ into the Reborn PR test planner

Detect Reborn test scope failed on this PR's own head commit: the planner's
fail-closed arm for .github/actions/** had no rule for the new setup-rust
composite, so it raised "unmapped test or CI path" and red the whole
Tests (Reborn) roll-up. Every Tests (Reborn) job now installs Rust through
this composite, exactly like the existing setup-sccache-dist entry in
SHARED_REBORN_ACTION_PREFIXES, so it belongs in the same fail-safe-to-full
bucket: no narrow lane can exercise a change to it, and a change here means
run the exhaustive plan.

Generalized the reason string and its test assertion from "shared sccache
action changed" to "shared reborn action changed" since the bucket now
covers two actions, not one; this is a text-accuracy fix, not a weakened
check (still asserts full mode / all partitions / all lanes).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): let has_code see the toolchain pin and its own guard

validate_toolchain_pin_sync() only runs inside fast-checks, gated on
has_code || has_guidance. The has_code regex enumerated crates/, tests/,
Cargo.toml, and friends but not rust-toolchain.toml or
.github/actions/setup-rust/ — so a PR touching only the two files the
sync guard exists to police got has_code=false, has_guidance=false, and
the guard never ran. Add both paths to the has_code regex, and pin them
into CRATE_SCOPE_FILTERS' has_code in_scope probes so a future narrowing
of the grep fails validate_crate_scope_filters loudly instead of quietly
dropping them again.

Regression: added a dedicated test asserting rust-toolchain.toml and
.github/actions/setup-rust/action.yml are in has_code.in_scope, and
confirmed test_checked_in_scope_filters_pass failed against the old
regex before fixing .github/workflows/code_style.yml.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): pin the mold verify step's Linux guard in the setup-rust contract

validate_setup_rust_action() checked the Linux `if:` guard on the mold
install and export steps, but the "Verify mold linker is active" step
in between had no constant and no check at all — an unguarded verify
step would run the mold link check on any runner OS (where mold and
clang are never installed) and nothing would catch it. Add
MOLD_VERIFY_STEP to the guarded set validate_setup_rust_action checks.

Regression: added test_missing_mold_verify_linux_guard_fails and
test_missing_mold_verify_step_fails, confirmed both failed with the old
two-step tuple before adding MOLD_VERIFY_STEP to it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): anchor the toolchain-default regex to the toolchain input block

validate_toolchain_pin_sync() used `re.search(r'default:\s*"([^"]+)"',
action_text)` over the WHOLE setup-rust action.yml, resolving to the
first non-empty `default:` in the file. That is only ever the
`toolchain` input's default by accident — every other input's default is
an empty string today and sits after it. A reordered or added input with
its own non-empty default before `toolchain:` silently redirects the
guard onto the wrong value, hiding real drift between rust-toolchain.toml
and the composite.

Add input_body(), a step_body-style helper that bounds one action.yml
`inputs:` entry by the next input heading, and scope the default-value
search to the `toolchain:` input's own block.

Regression: added
test_a_reordered_earlier_input_with_a_non_empty_default_cannot_hide_drift,
confirmed it failed against the old whole-file regex (a decoy default
matching the pinned channel hid an actual drift in toolchain's own
default) before scoping the search to input_body().

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): catch workflow-level env RUSTFLAGS shadowing setup-rust too

JOB_ENV_RUSTFLAGS matched only six-space job-level `env:` indentation
(jobs.<job>.env.RUSTFLAGS). A workflow-level top `env:` block shadows the
composite's mold export identically — GitHub re-applies it to every step
of every job the same way it re-applies job-level env — but sits at
two-space indentation before any job heading, so it was invisible both
to the indentation-bound regex and to the per-job block slicing (which
only starts scanning at each job heading). Add a WORKFLOW_ENV_RUSTFLAGS
check over the file's preamble alongside the existing per-job scan.

Also add the missing PER-JOB skip coverage: the only existing test for
`SETUP_RUST_USES not in block` exercised the FILE-level skip
(`SETUP_RUST_USES not in text`) via a single-job file. Added a same-file
two-job test where one job uses the composite and a sibling does not, to
prove the sibling's own RUSTFLAGS stays allowed.

Regression: added test_workflow_level_rustflags_alongside_setup_rust_fails,
confirmed it failed before adding the WORKFLOW_ENV_RUSTFLAGS preamble
check, then restored it green; also added
test_sibling_job_without_setup_rust_is_allowed_in_a_multi_job_file to
pin the previously-untested per-job skip branch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* test(ci): assert every exhaustive-plan field for the setup-rust widen

test_shared_setup_rust_action_widens_to_exhaustive_plan only checked 4
of the 11 fields _full_plan() returns (mode, root_partitions,
integration_lanes, and a substring of reasons[0]) — the other 7,
including run_sandbox_docker and run_group_tests, were unpinned. This
is ws12's own guardrail framework, so a regression narrowing this exact
plan's blast radius deserved full coverage, not a partial one.

Regression: widened the assertion to full dict equality against every
field _full_plan() returns; confirmed it fails when run_sandbox_docker
is flipped to False (a change the old partial assertion would have let
through silently), then restored it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): glob both .yml and .yaml when loading workflows

load_workflows() globbed only `*.yml` under .github/workflows/. GitHub
Actions accepts either extension for a workflow file, so a `.yaml`
workflow would silently escape every ws12 contract this loader feeds —
latent today since no `.yaml` workflow exists, but a landmine for the
next one added. Glob both extensions.

Regression: added test_discovers_both_yml_and_yaml_extensions,
confirmed it failed against the *.yml-only glob (the .yaml fixture was
silently dropped) before widening the glob.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): guard every Rust bootstrap, not just the vendor action

An approach audit found the migration's "single owner" claim was false and,
worse, unenforceable: .github/workflows/ironclaw-release.yml:133 still
bootstraps Rust with `curl https://sh.rustup.rs | sh`, so the lane that
builds shipped artifacts got no RUSTUP_TOOLCHAIN pin, no mold wiring and no
check against rust-toolchain.toml. validate_no_direct_dtolnay_usage greps
only the literal `dtolnay/rust-toolchain@`, so that path passed the gate
forever, and no test covered it. The file is live, not inert boilerplate —
commit 2a7d49c60 hand-edited that exact line five days before this branch.

That file is regenerated wholesale by cargo-dist (see
[workspace.metadata.dist], cargo-dist-version 0.31.0), so migrating it onto
the composite would be clobbered on the next regeneration. It is therefore
an ACCEPTED exception rather than a silent one:

- validate_no_unmanaged_rust_bootstrap now fails on `sh.rustup.rs`,
  `rustup-init` and `rustup toolchain install` in any workflow, with
  ACCEPTED_RUST_BOOTSTRAPS pinning ironclaw-release.yml to exactly one
  occurrence. A second bootstrap there, or any in a hand-written workflow,
  fails the gate; and if the generator stops emitting it, the count check
  says so instead of leaving a stale exemption behind.
- AGENTS.md and rust-toolchain.toml said "every CI job" and "exclusively".
  Both were false as written. They now say hand-written jobs, name the
  exception, and point at the checker that enforces it.

Proven by sabotage: adding a curl bootstrap to code_style.yml fails the gate;
adding a SECOND one to ironclaw-release.yml fails it with "2 ... 1 accepted
here"; both restored, gate green. Five unit tests cover the hand-written
case, rustup-init/toolchain-install variants, the accepted single, the
accepted-file second, and the live tree.

Also drops INPUT_HEADING/input_body, a byte-identical duplicate of the
existing JOB_HEADING/job_body with one call site — an action's `inputs:`
entry has the same two-space `name:` shape a workflow job does, so
job_body(action_text, "toolchain") does the job.

Verified: ws12 self-tests 120 OK, ws12 live gate passed, planner suite 88 OK,
check-guidance OK.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs(toolchain): name the accepted release-workflow bootstrap in the pin header

The companion commit corrected AGENTS.md but this file's header still said
"CI workflows install Rust exclusively through .github/actions/setup-rust" —
false while ironclaw-release.yml bootstraps Rust itself, and the same
overstatement the audit flagged. (The earlier edit aborted on an unrelated
assertion before reaching this file.)

It now says hand-written workflows, and names the one accepted exception
plus the checker that pins it to a single occurrence, so the header matches
what the gate actually enforces.

Verified: check-guidance OK, ws12 live gate passed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): migrate the release lane onto the composite and unbreak two guards

An approach re-audit and a multi-agent code review both rejected the previous
round's work. Three real defects, all in code added by this PR.

1. The "accepted exception" was unjustified. The claim was that cargo-dist
   regenerates ironclaw-release.yml wholesale, so its `curl sh.rustup.rs`
   bootstrap could not be migrated. The repo contradicts that four ways:
   `allow-dirty = ["ci"]` exists precisely so hand-edits survive regeneration
   (.github/workflows/README.md documents it for the permission hardening);
   two other hand-added steps already live in that job; cargo-dist exposes
   `github-build-setup` (already used for Node/pnpm in
   .github/dist-build-setup.yml) as the durable seam for exactly this; and
   `actions/checkout` and `setup-python` already run via `uses:` in that same
   container job, so a composite call is not structurally precluded.

   The bootstrap now lives in .github/dist-build-setup.yml as a
   `uses: ./.github/actions/setup-rust` call, re-included on every
   regeneration, keeping the previous step's `if: ${{ matrix.container }}`
   condition so release behaviour is unchanged. ACCEPTED_RUST_BOOTSTRAPS is
   empty: no lane is exempt, and the prose in AGENTS.md and
   rust-toolchain.toml states that without carve-outs because it is now true.

2. The workflow-level RUSTFLAGS check was dead code. JOB_HEADING matches any
   two-space `key:` line, so `on:`'s children (`push:`, `workflow_call:`)
   matched and headings[0] truncated the preamble at the first TRIGGER —
   before the real top-level `env:`. Verified on the live reborn-tests.yml:
   first match was `workflow_call` at offset 26, `jobs:` at 3177. Headings are
   now bounded to the `jobs:` block. The old unit test passed only because its
   fixture omitted `on:`; the new one carries a realistic trigger block.

3. The per-job check was blind to YAML aliases. release-plz.yml's
   `release-plz-pr` reaches the composite via `- *install-rust` and contains
   no literal `uses:` line, so the scan skipped it — a job-level RUSTFLAGS
   there would have shadowed mold silently. Anchors carrying the composite are
   now resolved and aliased jobs are checked.

Also broadens the bootstrap guard beyond three rustup literals to known
third-party toolchain actions (actions-rs, actions-rust-lang, hecrj, raftario),
after the coverage lane showed the enumeration was trivially evadable. The one
case text cannot see — a `container:` image shipping Rust preinstalled — is
named in a comment as residual risk rather than papered over.

Proven against the real files that defeated the old guards: a workflow-level
RUSTFLAGS injected into reborn-tests.yml is now caught; a job-level RUSTFLAGS
in release-plz.yml's alias-reached job is now caught; both were silent before.
Also removes an orphaned comment left describing the deleted INPUT_HEADING.

Verified: ws12 self-tests 123 OK, ws12 live gate passed, planner suite 88 OK,
check-guidance OK, both changed workflows parse.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): catch step-level RUSTFLAGS, not just job- and workflow-level

Third gap the review found in the same guard. JOB_ENV_RUSTFLAGS matched the
exact 6-space job-env depth, but GitHub also lets an individual step declare
`env:` (10 spaces in this repo's workflows, e.g. reborn-tests.yml:255), and a
step-level RUSTFLAGS shadows the composite's $GITHUB_ENV write for that step
exactly like a job-level one — dropping the mold linker flags with no failing
check, which is the precise regression the guard exists to prevent.

Widened to `^ {6,}RUSTFLAGS:` so job- and step-level depths are both caught,
and corrected the error message, which called a step-level key "job-level".

Proven against the live file: injecting a step-level RUSTFLAGS into
reborn-tests.yml's crate-tests job is now reported; the clean tree still
passes, so the wider pattern adds no false positives.

Worth stating plainly: this is the third hole found in this one
substring-matching guard (dead workflow-level check, alias blindness, now
step-level depth). Enforcement by grepping YAML text is structurally weaker
than the composite's own RUSTUP_TOOLCHAIN export, which makes drift
unrepresentable rather than policed. The stdlib-only constraint on
scripts/ci rules out a real YAML parse here, so the residual risk is the
shapes no pattern anticipated — noted rather than claimed away.

Verified: ws12 self-tests 124 OK, ws12 live gate passed, planner suite 88 OK.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): restore the release lane's Rust install and assert it is there

The previous commit broke the release lane. It deleted the container-only
`curl | sh` bootstrap from .github/workflows/ironclaw-release.yml and added
the composite call only to .github/dist-build-setup.yml — but that fragment
reaches the generated workflow solely through `dist generate`, which was
never run. The checked-in workflow ended up with NO Rust install path at
all: `grep -c 'setup-rust|Install Rust|rustup' ironclaw-release.yml` → 0.
The next tagged release would have failed on `cargo: command not found` in
every container matrix entry — the exact case the deleted step existed for.

Two independent code-review lanes caught it (Critical/confidence 100 and
High/confidence 92), both noting the same root cause: every check in this
file asserts an ABSENCE — no dtolnay, no raw bootstrap, no shadowing
RUSTFLAGS — so deleting a step and adding nothing read as "clean" and the
whole suite stayed green over a broken release lane.

The step is now in both places, deliberately: the fragment so `dist
generate` keeps emitting it, and the checked-in workflow because that is
the file GitHub actually runs.

validate_release_workflow_installs_rust closes the class by asserting
PRESENCE in both files. Proven red-first in both directions: removing the
step from the generated workflow fails with the cargo-not-found rationale;
removing it from the fragment fails with the regeneration rationale;
restoring either passes. Four unit tests plus a live-tree assertion.

This is the second time in this PR that an absence-only guard reported
success over a real defect. Guards that only forbid shapes cannot notice
that the thing they were protecting is gone.

Verified: ws12 self-tests 128 OK, ws12 live gate passed, planner suite 88
OK, ironclaw-release.yml parses.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor(ci): split the Rust toolchain contracts out of ws12_workflow_contracts

Pure move, no behavior change. ws12_workflow_contracts.py had grown to 2,171
lines — past the repo's ~1k ceiling — mixing stress-suite parity, crate scope
filters, WebUI site checks, and this PR's six toolchain validators in one file.
Three separate reviews flagged it (two approach audits, one design lane).

scripts/ci/lib/rust_toolchain_contracts.py now owns one question: what
toolchain, linker, and build flags does a Rust job get? Six validators, their
constants, and a module docstring recording the absence-vs-presence asymmetry
that let a release workflow with no Rust install pass this suite last week.

scripts/ci/lib/workflow_text.py owns the four generic YAML text helpers both
modules need. This absorbed a latent defect: JOB_HEADING was defined TWICE in
ws12 (lines 426 and 988), the second shadowing the first for every validator
below it. The two patterns were `[A-Za-z0-9_-]` and `[a-zA-Z0-9_-]` —
semantically identical, so nothing was wrong today, but only by luck. One
definition now.

The test file imports each symbol from its owning module rather than letting
ws12 act as an implicit re-export, so the ownership is checkable.

classify-test-scope.sh: both new paths join the reborn-scoped list. Without
this the split would have silently changed CI behavior — editing a validator
in its new home would classify differently than editing it in ws12 did — which
is exactly the kind of quiet regression a "pure move" is supposed to not have.
test-classify-test-scope.sh pins it; proven red-first by reverting the list
entry and watching the new assertion fail.

Verified after the move, both validators proven to still fire from their new
home by sabotage: breaking the RUSTUP_TOOLCHAIN export fails the gate, and
deleting the release workflow's composite step fails it with the
cargo-not-found rationale. ws12 self-tests 128 OK, live gate passed,
classify-test-scope 69 PASS / 0 FAIL, check-guidance OK.

ws12_workflow_contracts.py: 2171 -> 1833 lines.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs(agents): point the toolchain pin at its owner instead of restating it

The AGENTS.md paragraph and rust-toolchain.toml's header had grown into two
near-verbatim copies of the same rationale — rustup precedence, the nightly
coverage-lane carve-out, the cargo-dist fragment, why Docker is unaffected.
Two copies of a rationale drift; the one nobody edits goes stale silently.

AGENTS.md keeps what an agent needs to act: the pin is the source of truth,
never install Rust in a workflow directly, and bumping is a two-place edit in
one PR. The why lives in rust-toolchain.toml's header, where it sits next to
the value it explains. 17 lines -> 11.

Also refreshes the enforcement pointer to the module that now owns those
checks after the split, and mentions the two guards added since this paragraph
was written (release-lane presence, RUSTFLAGS shadowing).

Verified: check-guidance OK (2603 path references, including the new
scripts/ci/lib/rust_toolchain_contracts.py), ws12 gate passed, 128 self-tests OK.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): require every cargo job to reach the composite, not just the release lane

A review lane proved the release-lane guard was the right fix written too
narrowly. It verified the escape by mutation: delete the `uses:
./.github/actions/setup-rust` step from code_style.yml's fast-checks job — no
dtolnay call, no raw bootstrap, no RUSTFLAGS key — and all 128 tests stayed
green. That is the identical bug the release-lane guard was added for last
commit, reproduced in a different file, because "no dtolnay, no bootstrap, no
shadowing RUSTFLAGS" is trivially true of a job that installs nothing at all.

validate_rust_jobs_reach_the_composite generalizes the rule: any job whose
steps invoke cargo/rustc/rustup must reach the composite, directly or through
a YAML alias. Scoped to jobs that actually run the compiler, so docs and
frontend jobs need no exemption, and `Cargo.toml` in a `paths:` filter is not
an invocation.

It ships with NO allowlist because it needs none — all 31 cargo-running jobs
in the tree satisfy it today. An entry here would mean a lane building Rust on
whatever toolchain the runner image happens to ship.

Proven red-first on the reviewer's exact mutation: the release-only guard
reports 0 errors on it, the new one names all three affected jobs
(fast-checks, clippy, clippy-windows). Six unit tests including the alias path
and a live-tree assertion.

Also in this commit, both from the same review:

- workflow_text.py still defined JOB_HEADING twice. My split moved the
  duplicate instead of removing it, so the commit message claiming
  consolidation was wrong. One definition now, and a test asserts each pattern
  is bound exactly once — the shadowing itself is now what fails, not just
  today's instance of it.
- The module docstring claimed five validators assert an absence. Three do.
  The other four assert presence or equality and are deletion-safe for their
  own subject. An inaccurate tally in the very docstring warning about this
  asymmetry is worth more than a typo.

The job/anchor scan the RUSTFLAGS validator had inline is now shared with the
new check (_composite_anchors / _job_blocks / _reaches_composite) rather than
written twice.

Verified: 137 self-tests OK, live gate passed, check-guidance OK,
classify-test-scope 70 PASS / 0 FAIL.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): classify the cargo-dist fragment so the plan step stops failing closed

This PR's own CI was red on `Build affected-area test plan`, and the cause was
this PR: it edits `.github/dist-build-setup.yml`, the planner had no rule for
that path, and the planner fails closed on anything unclassified. The step
died before scheduling a single lane — so a PR touching only CI plumbing could
not report at all.

Reproduced locally with the exact CI invocation over the PR's real changed-file
list: "Reborn PR test planner failed: unclassified pull-request path:
.github/dist-build-setup.yml". Green after the fix, plan mode `full`.

The fragment is workflow source that lives outside `.github/workflows/`:
cargo-dist re-inlines it into `ironclaw-release.yml` on every `dist generate`.
So it is the same static control as the file it becomes, and no Reborn lane
reads it. That is exactly the `pull_request_template.md` gap the suite already
pins, one directory over.

A sweep test over the surfaces that make CI run then found a second, older gap:
`.github/actions/install-cargo-component/action.yml` has been unmapped since it
was introduced, so any PR editing it hits the same dead plan step. It is
consumed by coverage.yml and platform-and-compat.yml, so it takes the
exhaustive plan like its two siblings — the deliberate mapping that arm's own
comment asks for.

The sweep is scoped to `.github/actions/**` plus the fragment, NOT all of
`.github/`. Fail-closed on an undecided path is this planner's intended
behaviour and an existing test pins `.github/labeler.yml` refusing on purpose;
a wider sweep contradicted it. The line is between config someone may leave
undecided and source a job runs.

Reported, not silently mapped: `.github/labeler.yml` and six
`.github/scripts/*` helpers still refuse. `ci-job-result-ok.sh` is invoked by
workflows, so it is a latent break of the same class — but mapping it is a
policy call for the planner's owner, not a drive-by in this PR.

Both fixes proven red-first: removing either mapping fails the suite, restoring
either passes.

Verified: planner 90 OK, ws12 137 OK, ws12 gate passed, staged-paths 4 OK,
classify-test-scope exit 0, check-guidance OK, and the previously-red CI
command now exits 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor(ci): close the three open audit findings

All three were NORMAL, none blocking; closing them so review sees the design
rather than a list of known nits.

**One owner for the debug-info policy** (converged finding, reported
independently by both system-audit lanes). The migration deleted these env
pairs from five workflow job envs on the strength of Cargo.toml's
`[profile.dev] debug = 0` owning the value — but left the identical `:-0`
defaults standing in scripts/ci/quality_gate.sh and
reborn-local-coverage-ratchet.sh. The PR's own claim of a single owner was
not true of the tree it shipped. Both removed; no behaviour change, the values
already agreed, and a developer's `CARGO_PROFILE_DEV_DEBUG=2` still reaches
cargo because `env` inherits what it does not override.

Deleting the lines alone would just let them come back, so
`validate_single_debug_policy_owner` makes it structural: no script under
scripts/ may ASSIGN a CARGO_PROFILE_*_DEBUG value. Assignments only —
run-hermetic-test-process.sh names the same variables in a passthrough
allowlist (a `case` pattern, no `=`), which is exactly how that override
survives the hermetic barrier, and matching it would break the documented
escape hatch. Test files are skipped: they carry the string on purpose as
fixtures, and scanning them would make the contract untestable.

**No speculative escape hatch.** `ACCEPTED_RUST_BOOTSTRAPS` was a per-path
override with symmetric over-use AND under-use validation, plus a test pinning
it empty — built in full for a case the module's own comment says does not
exist. Removed; the rule is now unconditional. If an unavoidable bootstrap
ever appears, the hatch gets added then, with that lane as its first entry.
The test that asserted the dict stays empty now asserts the mechanism is gone
rather than merely empty.

**One job-boundary walk.** `_job_blocks` reimplemented the slice-between-
consecutive-headings logic that `extract_job_block` already did in the same
subsystem. `job_blocks()` in workflow_text.py is now the single primitive:
`extract_job_block` filters it to one named job and keeps its exactly-one
refusal, and the toolchain contracts enumerate it from the `jobs:` offset.
That offset is load-bearing and stays — JOB_HEADING matches any two-space
key, so an unbounded walk treats `on:`'s children as jobs.

Verified: ws12 141 tests OK, live gate passed, planner 90 OK, staged-paths
4 OK, classify-test-scope exit 0, check-guidance OK, both edited shell
scripts pass `bash -n`. The debug-policy guard proven red-first by restoring
one deleted line and watching the gate name it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Address PR review feedback (#7821)

Four threads triaged as valid and fixed. Two are real guard bypasses in the
module this PR introduces — a reviewer reproduced both, and both are the same
species the module's own docstring warns about: a check reading text that only
LOOKS like an executable step, or reading too narrow a slice of the file.

- **Release check was file-wide, not job-scoped.** Deleting the composite step
  from `build-local-artifacts` while a decoy `# uses: ...` comment sat in an
  unrelated job returned no error. That matters more than it looks: nothing in
  ironclaw-release.yml matches a literal `cargo` (cargo-dist shells out to
  `dist build`), so `validate_rust_jobs_reach_the_composite` never covers that
  file and this was its only guard. Now scoped to the job, and every `uses:`
  match is comment-stripped per line.

- **Anchor scope ran past its own YAML node.** `_composite_anchors` scanned
  from an anchor to the next anchor or job heading, so a comment mentioning the
  composite anywhere in that span marked the anchor as installing Rust — and a
  job that merely aliased it passed while installing nothing. Bounded by
  indentation to the anchor's own node, and comment-stripped. The legitimate
  release-plz alias shape keeps working (pinned by its own test).

- **Root-level `env:` after `jobs:` was invisible.** A top-level mapping key
  need not precede `jobs:`; such a block applies to every job identically, but
  slicing the preamble at `jobs:` hid it while its two-space indent also dodged
  the six-space per-job pattern. It fell through both checks. Now scans the
  whole file.

- **AGENTS.md overstated the contract.** My earlier commit 463b02974 made this
  paragraph MORE absolute than the one it replaced — "single source of truth"
  and "every job" — when there are two synchronized pins checked for equality,
  neither derived from the other, plus a nightly-lane carve-out and Docker
  outside the contract entirely. That is the exact universal-claim pattern
  `.claude/rules/guidance-maintenance.md` forbids. Reworded to say what is
  actually enforced.

Test-file changes and why:
- `ReleaseWorkflowInstallsRustTests` gained a `release()` helper and its
  fixtures now name `build-local-artifacts`. The old fixtures were a bare
  `jobs:\n  build:` which no longer exercises a job-scoped contract. This
  makes the fixture match the real workflow shape; it does not relax an
  assertion.
- `GuardBypassRegressionTests` adds four tests: one per bypass, plus one
  pinning that a real anchor alias still passes so the anchor fix cannot be
  "fixed" by rejecting legitimate aliases.

All three code fixes proven red-first: reverting each one individually fails
its own regression, and restoring it passes.

Verified: ws12 145 tests OK, live gate passed, planner 90 OK, staged-paths
4 OK, classify-test-scope exit 0, check-guidance OK.

Not addressed here, reported on the threads: the `workflow_dispatch` +
local-action-resolution regression needs a design call (20+ sites, 4
workflows), and one thread's claim was already fixed earlier in this branch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): install Rust in the one hermetic lane that acquired it lazily

Root cause of the E2E failures that have been red on every run of this branch
while T2/T3/T4 from the same base are green.

`webui-v2-test-lanes` runs a prebuilt binary and compiles nothing, so it never
installed Rust. But `run-hermetic-test-process.sh` probes `rustc --print
sysroot` to build the child PATH and exits 1 if it cannot resolve one. Inside
the repo that probe hits the `rust-toolchain.toml` this PR adds, so rustup
installed the pinned toolchain LAZILY — mid-lane, once per shard, racing its
own component downloads:

    provider operation shard 2/4 failed with status 1
    error: component download failed for rustfmt-x86_64-unknown-linux-gnu:
           could not rename 'downloaded' file ... .partial

Confirmed by controlled experiment (#7852): reverting only `[profile.dev]
debug = 0` and keeping everything else left E2E red, with a DIFFERENT subset of
shards failing — a race signature, and it exonerates the profile block.

A survey of every lane invoking the hermetic runners found exactly one in this
state; the other seven already install through the composite. So this is one
missing step, not a design fault — but it was invisible because the lane
compiles nothing, and the whole point of this PR is that toolchain acquisition
should never be implicit.

`validate_rust_jobs_reach_the_composite` now treats a hermetic-runner
invocation as needing a toolchain, the same as a literal `cargo` line. It could
not see this before: the workflow text only names the script. Proven red-first
— removing the step again fails the gate by name.

I called this failure an unrelated rustup flake twice. It was neither: it was
this PR's own side effect, visible in the logs from the first run.

Verified: ws12 147 tests OK, live gate passed, planner 90 OK,
classify-test-scope exit 0, check-guidance OK, reborn-e2e.yml parses.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): realign the assertion I broke by rewording the guard message

The previous commit widened `validate_rust_jobs_reach_the_composite` to cover
hermetic lanes and reworded its message from "runs cargo but never reaches" to
"needs a Rust toolchain but never reaches" — but an existing test still
asserted the old string. Fast-checks went red, and Code Style followed it
("fast-checks failed: failure"), so both new failures had this one cause.

Worth recording HOW it shipped, because the mistake was in my verification and
not in the edit. The combined-validation command was:

    python3 scripts/ci/test_ws12_workflow_contracts.py 2>&1 | tail -3 | head -2

`tail -3` yields ["Ran N tests in Xs", "", "OK|FAILED"]; `head -2` then drops
the verdict line. The output read "Ran 147 tests in 12.705s" and I took that
as a pass. The suite had already been failing locally at that point — the
command was constructed so it could not tell me.

Validation now keys off exit codes rather than parsed tail text, so a failing
suite cannot render as a passing one.

Verified (exit codes): ws12 self-tests 0, ws12 gate 0, planner 0,
staged-paths 0, suite-shards 0, changed-packages 0, classify-test-scope 0,
check-guidance 0, docs-boundary 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): make the debug-policy guard see where the value was actually written

Two review lanes independently reported that `validate_single_debug_policy_owner`
cannot detect the regression it exists to prevent, and they are right.

The guard scanned `scripts/**` for `KEY=value`. This PR deleted 14
`CARGO_PROFILE_*_DEBUG` lines from `.github/workflows/**`, all in YAML
`KEY: value` form. So the guard covered the 3 script-side deletions and was
blind to the 14 workflow-side ones — the majority of what it was written to
keep deleted. A future PR re-adding a job-env pair would have passed clean.

Reproduced before fixing: a scratch tree with a workflow job env containing
`CARGO_PROFILE_DEV_DEBUG: 0` returned zero errors, and the regex did not match
the YAML form at all.

Now scans `scripts/**` and `.github/**` across .sh/.py/.yml/.yaml, and matches
both `=` and `:`. Verified the widening is safe: nothing in the live tree
matches, and the `run-hermetic-test-process.sh` passthrough allowlist still
does not — that entry is a `case` pattern with no assignment character after
the name, and it is how a developer's `CARGO_PROFILE_DEV_DEBUG=2` override
reaches the child process. A test now pins that it keeps working.

Proven red-first in both directions independently: narrowing the scope back to
`scripts` fails the two workflow tests; narrowing the syntax back to `=` fails
the same two.

This is the third time in this PR that a guard I wrote asserted something
narrower than the thing it was protecting. The pattern is consistent enough to
name: I write the check against the case that prompted it rather than against
the invariant, and the surrounding cases go uncovered.

Also adds the widening test for `.github/actions/install-cargo-component/`
(coverage lane, low severity). Its two sibling shared actions each had one; this
path had only the `.github/actions/**` sweep, which asserts the planner does not
RAISE but never checks the mode it returns — a mis-ordering could drop it to a
`none` plan and the sweep would still pass. Red-first: removing the prefix entry
fails the new test.

Not changed, with measurements: a performance lane flagged the `Install Rust`
step added to the 4 binary-only E2E shards as avoidable cost. Measured on the
green run, it is 9-11s per shard on parallel runners, and it replaces a
toolchain install that was already happening implicitly inside the test step
while racing itself. Removing it entirely means changing the sysroot probe in
run-hermetic-test-process.sh, which 8 lanes share. Not worth that risk for ~10s;
recorded as a possible follow-up.

Verified (exit codes): ws12 150 tests 0, ws12 gate 0, planner 91 tests 0,
staged-paths 0, suite-shards 0, changed-packages 0, classify-test-scope 0,
check-guidance 0, docs-boundary 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs(agents): replace a universal claim with a verified, re-checkable count

`.claude/rules/guidance-maintenance.md` rule 3 forbids universal claims without
a count, and rule 2 asks for a one-line command a maintainer can re-run. The
paragraph said "Every Rust-installing CI job goes through the composite" — an
uncounted absolute.

Pointedly, this sentence was introduced by MY fix for the previous
universal-claim finding on this same paragraph. I removed "single source of
truth" and "every job" from one clause and wrote a fresh absolute into the next.

Now: "35 CI jobs across 11 workflow files need a toolchain and all 35 reach the
composite today, with no allowlist", plus the command that re-derives it and the
validator that enforces it. Counted at this head by walking every job block and
testing for a cargo/rustc/rustup invocation or a hermetic-runner call; 35 need
one, 35 reach it.

Verified (exit codes): check-guidance 0, ws12 gate 0, ws12 self-tests 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): pin the release step's condition, and scope the coverage claim to it

From your review (#7821 review 5012242062), Medium/86 on the release matrix.

The valid core: the contract asserted the composite step's TEXT existed in
`build-local-artifacts` and said nothing about WHEN it runs. `if: ${{
matrix.container }}` decides which matrix entries reach the composite at all,
so it could be narrowed, widened, or dropped and no check would notice — while
this PR claimed every Rust job reaches the composite.

Now pinned in both the generated workflow and `.github/dist-build-setup.yml`,
since a mismatch is what `dist generate` would silently apply. Proven red-first
in both directions: changing the condition names the old and new values;
dropping it reports `<unconditional>`. Three regressions, plus the existing
fixtures updated to carry the condition (they previously wrote a bare step, so
they could not have exercised this).

One part of the finding I checked and do not think holds. It says a
non-container release build "bypasses the new pin/export path and relies on
whatever Rust the hosted runner provides". The pin is not bypassed: with
`rust-toolchain.toml` in the repo, rustup resolves it when `dist build` invokes
cargo on the hosted runner. What those entries miss is mold and the explicit
`RUSTUP_TOOLCHAIN` export, not the toolchain version. It is also not a
regression — the pre-composite step carried the identical `if: ${{
matrix.container }}`, so release behaviour is unchanged by this PR.

Where the finding lands hardest is the docs, and that is my error. AGENTS.md
said "35 CI jobs ... all 35 reach the composite" — true for what it counts, but
the count walks `.github/workflows` only and the release lane is outside it
entirely (no job there names `cargo`; it shells out to `dist build`). A reader
would have taken it as universal. That is the second time in two commits I
replaced a universal claim with another one. Now scoped explicitly, naming the
release lane's actual shape and what the non-container entries do and do not
get.

Open question I am not deciding here: whether non-container release builds
should install explicitly rather than resolving the pin lazily. That is a
release-path behaviour change on a Track C surface, and the lazy resolution is
the same mechanism that raced in the E2E lanes — lower risk here (no parallel
shards within the job) but still implicit.

Verified (exit codes): ws12 153 tests 0, ws12 gate 0, planner 0,
classify-test-scope 0, check-guidance 0, docs-boundary 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): close four review findings on the condition and debug-policy guards

Two Major, both real, both in code I added in the previous two commits.

**The condition check had a false positive on the release path.**
`_composite_step_condition` scanned only the lines ABOVE the composite `uses:`
line. YAML mapping keys are unordered, so a step written `uses:` then `if:` is
valid and equivalent — and returned None, reporting `<unconditional>` and
rejecting a correct release workflow. Reproduced directly: the reordered step
returned None. Now bounded by the step's own `- ` marker and the next line at
or left of it, so the whole step body is scanned. Regression both ways: the
reordered step passes, and a neighbouring step's `if:` is still not borrowed.

**Quoted YAML keys bypassed the debug-policy guard.** `"CARGO_PROFILE_DEV_DEBUG": 0`
and `'CARGO_PROFILE_DEV_DEBUG': 0` are the same mapping key as the bare form and
matched nothing. Fixed with an optional quote on either side; the
`run-hermetic-test-process.sh` passthrough allowlist still does not match, which
a test pins.

Two smaller ones on the test I added last commit, both correct:
- the fail-closed case still probed `.github/actions/setup-rust/` — a leftover
  from mirroring the sibling test, so it re-tested the sibling's invariant
  instead of this one. Now probes install-cargo-component.
- ISC004 implicit string concatenation in the expected `reasons` list.

All three code fixes proven red-first: reverting the whole-step scan fails the
reordered-step test; reverting the quoted-key regex fails both quoted forms;
removing the prefix entry fails the mirrored test.

Pattern worth recording, since it is now consistent. Both Major findings are
the same shape as the three before them: I wrote each check against the exact
shape in front of me — `if:` before `uses:`, an unquoted YAML key — rather than
against the invariant, and the neighbouring valid shapes went unhandled. The
guards keep being narrower than the thing they protect. External review has
caught every instance; my own tests passed over all of them, because I wrote
the tests from the same narrow mental model as the code.

Verified (exit codes): ws12 156 tests 0, ws12 gate 0, planner 91 tests 0,
check-guidance 0, classify-test-scope 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Henry Park <16583448+henrypark133@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-08-24 21:56:29 +00:00

589 lines
28 KiB
Python

#!/usr/bin/env python3
"""Contracts for the single Rust toolchain setup path.
One question, one module: *what toolchain, linker, and build flags does a
Rust job get?* The answer is `.github/actions/setup-rust` and nothing else,
and these six validators are what make that true rather than aspirational.
Split out of `ws12_workflow_contracts.py`, which had grown past 2,100 lines
covering unrelated lanes (stress suites, crate scope filters, WebUI sites).
Wiring stays in that module's `validate_workflow_texts`; only the
toolchain-shaped rules live here.
Note which direction each check runs, because the mix is what makes the
suite trustworthy. Three assert an ABSENCE — no dtolnay action, no raw
bootstrap, no shadowing RUSTFLAGS key. Absence-only guards cannot notice that
the thing they protect has been deleted: a job that installs nothing at all
satisfies every one of them. That is exactly how a release workflow with no
Rust install passed this suite.
The other four assert a PRESENCE or an equality and are therefore
deletion-safe for their own subject: the composite has the steps it must have,
its default equals rust-toolchain.toml's channel, the release lane and its
cargo-dist fragment both reach the composite, and every job that runs cargo
reaches it. Before adding an eighth, work out which direction it runs and what
deletion it would miss.
"""
from __future__ import annotations
import re
from pathlib import Path
from workflow_text import JOB_HEADING, job_blocks, job_body, step_body
ROOT = Path(__file__).resolve().parents[3]
SETUP_RUST_ACTION = ".github/actions/setup-rust/action.yml"
RUSTUP_TOOLCHAIN_PIN_STEP = "Pin the resolved toolchain for the rest of this job"
MOLD_INSTALL_STEP = "Install mold and clang"
MOLD_VERIFY_STEP = "Verify mold linker is active"
MOLD_EXPORT_STEP = "Export mold RUSTFLAGS"
# The one canonical mold invocation; a job's own env may append extra flags
# after it (the nightly lanes add -Zcrate-attr=...), but this prefix is the
# only place it may be written out — everywhere else must go through here.
MOLD_RUSTFLAGS = "-C linker=clang -C link-arg=--ld-path=/usr/bin/mold"
def validate_setup_rust_action(text: str | None) -> list[str]:
"""The setup-rust composite must actually pin RUSTUP_TOOLCHAIN and mold.
Contract: every job that installs Rust through this composite gets a
RUSTUP_TOOLCHAIN export naming exactly the toolchain dtolnay/rust-toolchain
just installed (steps.install.outputs.name — not a second, possibly wrong,
guess at the resolved version), and mold's install/verify/RUSTFLAGS steps
are gated on Linux so `mold: true` is safe to pass on any runner OS.
"""
if text is None:
return [f"{SETUP_RUST_ACTION}: could not read the composite action file"]
errors: list[str] = []
pin_step = step_body(text, RUSTUP_TOOLCHAIN_PIN_STEP)
if pin_step is None:
errors.append(
f"{SETUP_RUST_ACTION}: missing the {RUSTUP_TOOLCHAIN_PIN_STEP!r} step"
)
elif "RUSTUP_TOOLCHAIN=${{ steps.install.outputs.name }}" not in pin_step:
errors.append(
f"{SETUP_RUST_ACTION}: {RUSTUP_TOOLCHAIN_PIN_STEP!r} must export "
"RUSTUP_TOOLCHAIN from steps.install.outputs.name, or a job's "
"cargo invocations can drift from what this step actually installed"
)
for step_name in (MOLD_INSTALL_STEP, MOLD_VERIFY_STEP, MOLD_EXPORT_STEP):
body = step_body(text, step_name)
if body is None:
errors.append(f"{SETUP_RUST_ACTION}: missing the {step_name!r} step")
continue
if "runner.os == 'Linux'" not in body:
errors.append(
f"{SETUP_RUST_ACTION}: {step_name!r} must gate on "
"runner.os == 'Linux' so mold: true is safe on any runner"
)
export_step = step_body(text, MOLD_EXPORT_STEP)
if export_step is not None and MOLD_RUSTFLAGS not in export_step:
errors.append(
f"{SETUP_RUST_ACTION}: {MOLD_EXPORT_STEP!r} must export the "
f"canonical mold RUSTFLAGS prefix '{MOLD_RUSTFLAGS}'"
)
return errors
DTOLNAY_ACTION = "dtolnay/rust-toolchain@"
def validate_no_direct_dtolnay_usage(workflows: dict[str, str]) -> list[str]:
"""Every workflow must install Rust through .github/actions/setup-rust.
A negative substring check, not a per-site window scan: this is what
T1's earlier per-input-drift design collapsed to once every job routes
through one composite. Also forbids re-writing out the canonical mold
RUSTFLAGS prefix by hand anywhere a workflow's own env block might set
it — the composite is the only place that string may appear.
"""
errors: list[str] = []
for path, text in workflows.items():
if DTOLNAY_ACTION in text:
errors.append(
f"{path}: calls {DTOLNAY_ACTION!r} directly — install Rust "
"through .github/actions/setup-rust instead"
)
if MOLD_RUSTFLAGS in text:
errors.append(
f"{path}: writes out the canonical mold RUSTFLAGS prefix "
f"'{MOLD_RUSTFLAGS}' directly — pass mold: true to "
".github/actions/setup-rust instead, which prepends it onto "
"this job's existing RUSTFLAGS"
)
return errors
SETUP_RUST_USES = "uses: ./.github/actions/setup-rust"
JOBS_KEY = re.compile(r"^jobs:[ \t]*$", re.MULTILINE)
# One list item that is nothing but an anchor definition (`- &install-rust`).
# Matched per line so the node it opens can be bounded by indentation.
ANCHOR_DEF_LINE = re.compile(r"^\s*-\s*&(?P<name>[\w-]+)\s*$")
# Job-level `env:` (jobs.<job>.env, two-space job + four-space `env:` + this
# key at six spaces) and workflow-level top `env:` (two-space key straight
# under the file's own `env:`) are both re-applied to every step of a job on
# top of $GITHUB_ENV, so both shadow the composite's mold export the same
# way. They need separate patterns, not one merged indentation class: the
# workflow-level form sits in the file's preamble, before any job heading, so
# it is checked once per file rather than by slicing per-job blocks.
# Any RUSTFLAGS key inside a job, at job-env depth (6 spaces) or
# step-env depth (10) — a step-level env shadows the composite's
# $GITHUB_ENV write for that step exactly like a job-level one, so
# pinning the exact job depth left a third of the shapes unguarded.
JOB_ENV_RUSTFLAGS = re.compile(r"^ {6,}RUSTFLAGS:", re.MULTILINE)
WORKFLOW_ENV_RUSTFLAGS = re.compile(r"^ {2}RUSTFLAGS:", re.MULTILINE)
def validate_no_job_env_rustflags_with_setup_rust(
workflows: dict[str, str],
) -> list[str]:
"""A job installing Rust via the composite must not set its own RUSTFLAGS.
GitHub re-applies a job-level `env:` mapping to every step of that job,
on top of whatever earlier steps wrote to $GITHUB_ENV. So a job-level
`RUSTFLAGS:` shadows the composite's export for the rest of the job and
silently drops the mold linker flags — a slower build, never a red
check, which is exactly the drift class this action exists to remove. A
workflow-level top `env:` key shadows every job in the file identically,
so it is checked the same way. Jobs pass their extra flags through the
composite's `extra_rustflags` input instead, so one place composes the
final value.
"""
errors: list[str] = []
for path, text in workflows.items():
if SETUP_RUST_USES not in text:
continue
anchors = _composite_anchors(text)
# Whole file, not just the preamble. A top-level mapping key need not
# precede `jobs:` — a root `env:` block placed after it is valid YAML,
# applies to every job the same way, and slicing at `jobs:` made it
# invisible to this check while its two-space indent also dodged the
# six-space per-job pattern. It fell through both.
if WORKFLOW_ENV_RUSTFLAGS.search(text):
errors.append(
f"{path}: workflow-level env sets a RUSTFLAGS key while a "
"job in this file installs Rust through "
".github/actions/setup-rust — a workflow-level env key "
"shadows the composite's $GITHUB_ENV write for every job in "
"the file identically to a job-level one; pass extra flags "
"as the composite's extra_rustflags input instead"
)
for name, block in _job_blocks(text):
if not _reaches_composite(block, anchors):
continue
if JOB_ENV_RUSTFLAGS.search(block):
errors.append(
f"{path}: job {name!r} sets a job- or "
"step-level RUSTFLAGS env key while installing Rust through "
".github/actions/setup-rust — job env shadows the "
"composite's $GITHUB_ENV write and drops the mold linker "
"flags; pass them as the composite's extra_rustflags "
"input instead"
)
return errors
RUST_BOOTSTRAP_PATTERNS = (
# Raw rustup bootstraps.
"sh.rustup.rs",
"rustup-init",
"rustup toolchain install",
# Third-party toolchain actions. The composite is the only sanctioned
# installer, so a workflow reaching for a different vendor action is the
# same drift as a curl bootstrap: unpinned toolchain, no mold, no
# rust-toolchain.toml sync. (`dtolnay/rust-toolchain` has its own check
# with a more specific message; it is deliberately not repeated here.)
"actions-rs/toolchain",
"actions-rust-lang/setup-rust-toolchain",
"hecrj/setup-rust-action",
"raftario/setup-rust-action",
)
# Residual risk, named rather than papered over: a job whose `container:`
# image ships Rust preinstalled installs nothing, so no text pattern can see
# it. Such a job would silently build on the image's toolchain instead of the
# pin. Nothing in .github/workflows does this today; if one appears it needs a
# structural check (assert every Rust-building job calls the composite), not a
# wider substring list.
# No workflow may bootstrap Rust outside the composite. cargo-dist
# re-includes .github/dist-build-setup.yml on every regeneration, so the
# release build jobs install Rust through the composite from there — there
# is no lane this contract cannot cover, and so no exemption mechanism here.
# If a genuinely unavoidable bootstrap ever appears, add the escape hatch
# then, with that lane as its first entry and its reason in the comment.
def validate_no_unmanaged_rust_bootstrap(workflows: dict[str, str]) -> list[str]:
"""Every hand-written workflow installs Rust through the composite.
`validate_no_direct_dtolnay_usage` only sees the vendor action. A raw
`curl https://sh.rustup.rs | sh` installs Rust just as effectively and
matches no such string, so it would otherwise pass this gate forever --
unpinned, without mold, and unchecked against rust-toolchain.toml.
"""
errors: list[str] = []
for path, text in workflows.items():
hits = sum(text.count(pattern) for pattern in RUST_BOOTSTRAP_PATTERNS)
if not hits:
continue
errors.append(
f"{path}: {hits} raw Rust bootstrap(s) "
f"({', '.join(RUST_BOOTSTRAP_PATTERNS)}). Install Rust through "
".github/actions/setup-rust so the toolchain stays pinned, mold "
"stays wired, and rust-toolchain.toml stays enforced."
)
return errors
def _composite_anchors(text: str) -> set[str]:
"""Anchor names whose OWN YAML node reaches the composite.
A job can pick the composite up through an alias (`- *install-rust`)
rather than a literal `uses:` line, as release-plz.yml does, so both
contracts below have to resolve aliases before deciding a job misses it.
Bounded by indentation, and comment-stripped, because the previous span
("from this anchor to the next anchor or job heading") was wide enough to
swallow unrelated siblings: a *comment* elsewhere in that span mentioning
the composite marked the anchor as installing Rust, and a job that only
aliased it then passed `validate_rust_jobs_reach_the_composite` while
installing nothing. That is the same alias-fooled bypass this module's
docstring warns about, so it gets the same treatment as everything else
here — the check reads executable steps, never text that merely looks
like one.
"""
anchors: set[str] = set()
lines = text.splitlines()
for index, line in enumerate(lines):
match = ANCHOR_DEF_LINE.match(line)
if not match:
continue
indent = len(line) - len(line.rstrip("\n").lstrip())
for follower in lines[index + 1 :]:
if not follower.strip():
continue
# First non-blank line at or left of the anchor's own marker ends
# its node — that is a sibling or a parent, not its content.
if len(follower) - len(follower.lstrip()) <= indent:
break
if SETUP_RUST_USES in follower.split("#")[0]:
anchors.add(match.group("name"))
break
return anchors
def _job_blocks(text: str) -> list[tuple[str, str]]:
"""Every job in the file, bounded to the `jobs:` mapping.
Slicing from the first heading blindly truncated the preamble at the
first `on:` trigger and made the workflow-level checks dead code on every
real workflow, so the `jobs:` offset is load-bearing here.
"""
jobs_key = JOBS_KEY.search(text)
return job_blocks(text, jobs_key.start() if jobs_key else 0)
def _reaches_composite(block: str, anchors: set[str]) -> bool:
return SETUP_RUST_USES in block or any(f"*{a}" in block for a in anchors)
# A cargo/rustc/rustup command actually being invoked -- not `Cargo.toml` in a
# `paths:` filter, not `cargo` inside a URL or a comment. Bounded on both sides
# by non-path, non-word characters so `target/cargo-timings` and
# `scripts/cargo-foo.sh` do not count as running the compiler.
CARGO_INVOCATION = re.compile(r"(?<![\w./-])(?:cargo|rustc|rustup)(?![\w./-])")
# The hermetic runners need a toolchain without naming one:
# run-hermetic-test-process.sh probes `rustc --print sysroot` to build the
# child PATH and exits 1 if it cannot resolve one. A lane that invokes them
# therefore needs Rust exactly as much as a literal `cargo` line does, but
# CARGO_INVOCATION cannot see it -- the workflow only mentions the script.
# webui-v2-test-lanes was the one lane in this state: it compiles nothing, so
# nobody noticed it needed rustc, and rustup installed the pinned toolchain
# lazily mid-test, once per shard, racing its own component downloads.
NEEDS_TOOLCHAIN_SCRIPT = re.compile(r"run-hermetic-(?:deterministic-suite|test-process)\.sh")
def validate_rust_jobs_reach_the_composite(workflows: dict[str, str]) -> list[str]:
"""Any job that runs cargo must install Rust through the composite.
The release-lane check below is the same rule written for one file. It
was added after a workflow lost its Rust install entirely and every
absence-only guard called that clean -- but it only ever protected
`ironclaw-release.yml`. Deleting the composite step from any other
workflow reproduced the identical failure with the suite still green,
because "no dtolnay, no bootstrap, no shadowing RUSTFLAGS" is all
trivially true of a job that installs nothing at all.
Scoped to jobs that actually invoke the compiler, so a docs or frontend
job needs no exemption. All 31 cargo-running jobs in the tree satisfy
this today, which is why it ships with no allowlist: an entry here would
mean a lane building Rust on an unpinned toolchain.
"""
errors: list[str] = []
for path, text in workflows.items():
anchors = _composite_anchors(text)
for name, block in _job_blocks(text):
code = "\n".join(line.split("#")[0] for line in block.splitlines())
if not (
CARGO_INVOCATION.search(code) or NEEDS_TOOLCHAIN_SCRIPT.search(code)
):
continue
if _reaches_composite(block, anchors):
continue
errors.append(
f"{path}: job {name!r} needs a Rust toolchain but never reaches "
f"`{SETUP_RUST_USES}`. Either it builds on whatever toolchain "
"the runner image ships (unpinned, no mold), or rustup installs "
"the pin lazily on first use inside the repo -- mid-lane, once "
"per shard, racing its own component downloads. Install Rust "
"through the composite so it happens once, up front."
)
return errors
RELEASE_WORKFLOW = ".github/workflows/ironclaw-release.yml"
DIST_BUILD_SETUP = ".github/dist-build-setup.yml"
# cargo-dist's container build job — the only job in the release workflow
# that installs Rust, and the one the contract below actually guards.
RELEASE_BUILD_JOB = "build-local-artifacts"
# The condition cargo-dist's container build job carries on its Rust install,
# in both the fragment and the generated workflow. Pinned, not merely tolerated:
# the contract used to assert the step's TEXT existed and said nothing about
# when it runs, so `if:` could be narrowed, widened, or dropped silently. The
# value itself is deliberate -- container images ship without cargo, hosted
# runners resolve rust-toolchain.toml themselves -- and it matches the
# pre-composite step exactly, so release behaviour is unchanged by this PR.
RELEASE_STEP_CONDITION = "if: ${{ matrix.container }}"
def _composite_step_condition(text: str) -> str | None:
"""The `if:` guarding the composite step, or None if the step is unguarded.
Scans the step's WHOLE body, not just the lines above `uses:`. YAML mapping
keys are unordered, so `uses:` may legally precede `if:`; stopping at the
`uses:` line reported such a step as unconditional and would have rejected
a correct release workflow. The step is bounded by its own `- ` marker and
the next line at or left of that marker.
"""
lines = text.splitlines()
for index, line in enumerate(lines):
if SETUP_RUST_USES not in line.split("#")[0]:
continue
start = index
while start > 0 and not lines[start].lstrip().startswith("- "):
start -= 1
marker_indent = len(lines[start]) - len(lines[start].lstrip())
end = len(lines)
for offset in range(start + 1, len(lines)):
follower = lines[offset]
if not follower.strip():
continue
if len(follower) - len(follower.lstrip()) <= marker_indent:
end = offset
break
for candidate in lines[start:end]:
stripped = candidate.split("#")[0].strip().lstrip("- ").strip()
if stripped.startswith("if:"):
return stripped
return None
return None
def _has_composite_step(text: str) -> bool:
"""True when some EXECUTABLE line invokes the composite.
Comment-stripped per line: a substring search over raw text counted a
commented-out or merely-mentioned `uses:` as an install.
"""
return any(SETUP_RUST_USES in line.split("#")[0] for line in text.splitlines())
def validate_release_workflow_installs_rust(
workflows: dict[str, str], root: Path = ROOT
) -> list[str]:
"""The release lane must actually REACH the composite, not merely lack a bootstrap.
Most checks here assert an absence — no dtolnay, no raw bootstrap, no
shadowing RUSTFLAGS. Absence-only checks called a release workflow with NO
Rust install whatsoever "clean": removing the old `curl | sh` step without
adding anything passed the whole suite, and a container build would have
died on `cargo: command not found`.
Scoped to `build-local-artifacts` rather than the file, because the file is
the wrong unit: nothing in ironclaw-release.yml matches a literal `cargo`
(cargo-dist shells out to `dist build`), so
`validate_rust_jobs_reach_the_composite` never covers this workflow and
this is its only guard. A file-wide substring let that job lose its own
install while an unrelated job — or a comment — kept the contract green.
ironclaw-release.yml is generated by cargo-dist from the fragment at
.github/dist-build-setup.yml, so the step has to exist in BOTH: the
fragment so `dist generate` keeps emitting it, and the checked-in workflow
because that is the file GitHub actually runs.
"""
errors: list[str] = []
release = workflows.get(RELEASE_WORKFLOW)
if release is not None:
jobs = dict(_job_blocks(release))
block = jobs.get(RELEASE_BUILD_JOB)
if block is None:
errors.append(
f"{RELEASE_WORKFLOW}: no {RELEASE_BUILD_JOB!r} job. cargo-dist "
"names the container build job; if it was renamed, update "
"RELEASE_BUILD_JOB so this contract keeps guarding it."
)
elif _has_composite_step(block) and _composite_step_condition(
block
) != RELEASE_STEP_CONDITION:
found = _composite_step_condition(block) or "<unconditional>"
errors.append(
f"{RELEASE_WORKFLOW}: job {RELEASE_BUILD_JOB!r} guards its "
f"Rust install with {found!r}, not {RELEASE_STEP_CONDITION!r}. "
"That condition decides which matrix entries reach the "
"composite at all; changing it changes which release binaries "
"are built with the pinned toolchain and mold, so it is a "
"deliberate edit in both this file and "
f"{DIST_BUILD_SETUP}, not a silent one."
)
elif not _has_composite_step(block):
errors.append(
f"{RELEASE_WORKFLOW}: job {RELEASE_BUILD_JOB!r} has no "
f"`{SETUP_RUST_USES}` step. The container build jobs have no "
"other Rust install path, so this lane would fail with "
"'cargo: command not found'. Re-run `dist generate` or "
f"re-inline the step from {DIST_BUILD_SETUP}."
)
try:
fragment = (root / DIST_BUILD_SETUP).read_text(encoding="utf-8")
except OSError as error:
errors.append(f"{DIST_BUILD_SETUP}: could not read fragment: {error}")
else:
if _has_composite_step(fragment) and _composite_step_condition(
fragment
) != RELEASE_STEP_CONDITION:
found = _composite_step_condition(fragment) or "<unconditional>"
errors.append(
f"{DIST_BUILD_SETUP}: guards its Rust install with {found!r}, "
f"not {RELEASE_STEP_CONDITION!r} — the fragment and the "
"generated workflow would disagree the next time cargo-dist "
"regenerates."
)
if not _has_composite_step(fragment):
errors.append(
f"{DIST_BUILD_SETUP}: no `{SETUP_RUST_USES}` step. cargo-dist "
"re-inlines this fragment on regeneration, so dropping it here "
"silently removes the release lane's Rust install the next time "
"the workflow is regenerated."
)
return errors
# Cargo.toml's `[profile.dev] debug = 0` owns the debug-info policy. Anything
# else ASSIGNING one of these is a second writer of the same value -- harmless
# while the values agree, and a silent divergence the day someone bumps one.
# An assignment only: `run-hermetic-test-process.sh` names the same variables
# in a passthrough allowlist (a `case` pattern, no `=`), which is how a
# developer's `CARGO_PROFILE_DEV_DEBUG=2` override survives the hermetic
# barrier. That entry must keep working, so it must not match here.
# Both syntaxes, because the value was written in both: shell `KEY=value` in
# scripts, YAML `KEY: value` in workflow job envs. Matching only `=` made this
# guard blind to the 14 workflow lines this PR deleted -- the majority of what
# it exists to keep deleted.
# The key may be bare, double-quoted, or single-quoted -- all three are valid
# YAML for the same mapping key, and a quoted one bypassed this guard.
DEBUG_POLICY_ASSIGNMENT = re.compile(
r"[\"']?CARGO_PROFILE_[A-Z]+_DEBUG[\"']?\s*[:=]"
)
# Where the value could be written. `scripts/` covers the shell/python side;
# `.github/` covers workflow and composite-action env blocks, which is where
# five job envs carried it before this change.
DEBUG_POLICY_SEARCH_ROOTS = ("scripts", ".github")
DEBUG_POLICY_SUFFIXES = (".sh", ".py", ".yml", ".yaml")
DEBUG_POLICY_OWNER = "Cargo.toml"
def validate_single_debug_policy_owner(root: Path = ROOT) -> list[str]:
"""Only Cargo.toml may set the debug-info profile values.
The migration deleted these env pairs from five workflow job envs on the
strength of the profile block owning them, but left the identical `:-0`
defaults standing in two scripts -- so the change's own claim of a single
owner was not true of the whole tree. Two audit lanes reported it
independently.
The first version of this guard then repeated the mistake in miniature: it
scanned only `scripts/**` for `KEY=value`, so it could not see the 14
workflow lines -- the majority of what it was written to keep deleted. Two
review lanes reported THAT independently. Scope and syntax now cover both
places the value was actually written.
"""
errors: list[str] = []
candidates: list[Path] = []
for search_root in DEBUG_POLICY_SEARCH_ROOTS:
candidates.extend(sorted((root / search_root).rglob("*")))
for path in candidates:
if not path.is_file() or path.suffix not in DEBUG_POLICY_SUFFIXES:
continue
# Test files carry the forbidden string on purpose, as fixtures and
# as the sabotage input that proves this check fires. Scanning them
# would make the contract unable to have a regression test at all.
if path.name.startswith(("test_", "test-")):
continue
try:
text = path.read_text(encoding="utf-8")
except (OSError, UnicodeDecodeError) as error:
errors.append(f"{path}: could not read: {error}")
continue
for number, line in enumerate(text.splitlines(), start=1):
if DEBUG_POLICY_ASSIGNMENT.search(line.split("#")[0]):
errors.append(
f"{path.relative_to(root)}:{number}: assigns a "
"CARGO_PROFILE_*_DEBUG value, which "
f"{DEBUG_POLICY_OWNER}'s `[profile.dev]` block owns. Two "
"writers of one value diverge the day either is bumped; "
"delete this and let the profile decide."
)
return errors
def validate_toolchain_pin_sync(root: Path = ROOT) -> list[str]:
"""rust-toolchain.toml and the composite's default must name one version."""
try:
file_text = (root / "rust-toolchain.toml").read_text(encoding="utf-8")
except OSError:
return ["rust-toolchain.toml: missing (single source of truth for the CI toolchain)"]
channel_match = re.search(r'^channel = "(\d+\.\d+\.\d+)"$', file_text, re.MULTILINE)
if channel_match is None:
return ['rust-toolchain.toml: channel must be an exact stable version ("X.Y.Z")']
channel = channel_match.group(1)
try:
action_text = (root / SETUP_RUST_ACTION).read_text(encoding="utf-8")
except OSError:
return [f"{SETUP_RUST_ACTION}: missing"]
# Scoped to the `toolchain:` input's own entry, not the whole file: a
# `re.search` over the entire action text would resolve to whichever
# `default: "..."` happens to appear first, which is only the toolchain
# input's by accident of every other input's default being empty and
# sitting after it in the file today.
# `job_body` bounds a two-space `name:` block, which is exactly the
# shape of an action.yml `inputs:` entry — no second helper needed.
toolchain_input = job_body(action_text, "toolchain")
if toolchain_input is None:
return [f"{SETUP_RUST_ACTION}: no `toolchain:` input found"]
default_match = re.search(r'default:\s*"([^"]+)"', toolchain_input)
if default_match is None or default_match.group(1) != channel:
found = default_match.group(1) if default_match else "<none>"
return [
f"{SETUP_RUST_ACTION}: toolchain input default {found!r} != "
f"rust-toolchain.toml channel {channel!r}"
]
return []