Symptom
governance / Workflow security linter fails on every PR with:
##[error]duplicate key(s): 'with' (line 143)
Cause
.github/workflows/build-gossamer-gui.yml has a single step carrying two with: blocks:
- name: Setup Rust (stable) with wasm32 target
uses: dtolnay/rust-toolchain@v1
with:
toolchain: master
with:
toolchain: stable
targets: wasm32-unknown-unknown
Introduced by #810 (chore(deps): bump the actions group with 7 updates, 2026-09-22). Dependabot rewrote the action ref from a branch to @v1 and added a with: block instead of editing the existing one, leaving the original toolchain: master in place.
Why it matters beyond the red check
This is a duplicate YAML mapping key, so the outcome is parser-dependent: most YAML loaders take the last occurrence (giving toolchain: stable + targets: wasm32-unknown-unknown, which is what was intended), but the value is not well-defined by the spec and a stricter loader may reject the document outright. A workflow whose inputs depend on which parser reads it is not a workflow anyone can reason about — and if a parser ever takes the first key, the job silently builds with toolchain: master and no wasm32 target.
Acceptance criteria
Scope note
Found while verifying PR #821 (#815, the src/abi duplicate deletion). It is not caused by that PR — build-gossamer-gui.yml is byte-identical between #821 and main, and #821's only workflow change is a single comment line inside a run: block in tests.yml, which cannot create a duplicate YAML key. Filed separately rather than folded in, per the standing rule that a new finding is an issue, not a merge blocker.
🤖 Generated with Claude Code
https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV
Symptom
governance / Workflow security linterfails on every PR with:Cause
.github/workflows/build-gossamer-gui.ymlhas a single step carrying twowith:blocks:Introduced by #810 (
chore(deps): bump the actions group with 7 updates, 2026-09-22). Dependabot rewrote the action ref from a branch to@v1and added awith:block instead of editing the existing one, leaving the originaltoolchain: masterin place.Why it matters beyond the red check
This is a duplicate YAML mapping key, so the outcome is parser-dependent: most YAML loaders take the last occurrence (giving
toolchain: stable+targets: wasm32-unknown-unknown, which is what was intended), but the value is not well-defined by the spec and a stricter loader may reject the document outright. A workflow whose inputs depend on which parser reads it is not a workflow anyone can reason about — and if a parser ever takes the first key, the job silently builds withtoolchain: masterand no wasm32 target.Acceptance criteria
.github/workflows/build-gossamer-gui.ymlhas exactly onewith:per step; the surviving block istoolchain: stable+targets: wasm32-unknown-unknown.dtolnay/rust-toolchainis conventionally used at@master(it has no version tags in the usual sense). Whatever is chosen, pin it to a commit SHA with the version in a trailing comment, per estate policy.governance / Workflow security linterreports success on a PR carrying the fix.with:block to any step and confirm the linter goes red again — a gate that passes after a fix proves nothing until it is shown it can still fail.with:shape, since the cause is mechanical and would repeat.Scope note
Found while verifying PR #821 (#815, the
src/abiduplicate deletion). It is not caused by that PR —build-gossamer-gui.ymlis byte-identical between #821 andmain, and #821's only workflow change is a single comment line inside arun:block intests.yml, which cannot create a duplicate YAML key. Filed separately rather than folded in, per the standing rule that a new finding is an issue, not a merge blocker.🤖 Generated with Claude Code
https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV