bug(ci-standards): dev-lead.yml caller stub missing SonarCloud S7637 exemption — blocks ring-pinned consumers (bmad #334)

[don-petry]

Problem

The dev-lead caller-stub .github/workflows/dev-lead.yml, once channel-pinned to a ring tag (@dev-lead/ring0|ring1|next, per the canary-rings rollout #495/#500), trips SonarCloud rule githubactions:S7637 ("External GitHub Actions and workflows should be pinned to a commit hash") at HIGH severity. That drives new_security_rating → C, failing the SonarCloud Quality Gate ≥ A condition, so the required SonarCloud check goes red and the PR cannot merge.

This is a known false-positive class: the ref is a first-party @<agent>/<channel> tag we own and intentionally keep mutable (the basis of the ring model) — exactly the case the org already exempts for the agent (#871), for check_action_pinning, and in standards/ci-standards.md §SonarCloud Exemption: First-Party Reusable-Ref S7637. "Fixing" it the way S7637 wants (SHA-pin) would defeat the moving-channel design.

Live blocker (confirmation case)

petry-projects/bmad-bgreat-suite#334 (bmad → @dev-lead/ring1) is stuck on exactly this:

• Alert: githubactions:S7637 HIGH on .github/workflows/dev-lead.yml:51 — "Use full commit SHA hash for this dependency."
• Quality Gate: new_security_rating actual 3 (C) vs required 1 (A) → ERROR.

Root cause

The S7637 standard already exists (ci-standards.md §SonarCloud Exemption), and other stubs are exempted (e.g. google-app-scripts: pr-auto-review.yml, agent-shield.yml, auto-rebase.yml). But dev-lead.yml was never added to consumers' sonar-project.properties when it got channel-pinned, and the dev-lead caller-stub adoption guidance doesn't require the exemption — so every ring-pinned consumer (bmad/TalkTerm ring1, .github ring0, .github-private next, future adopters) hits this.

Fix

Per the existing standard — suppress only githubactions:S7637 only on the dev-lead.yml stub file (per-file sonar.issue.ignore.multicriteria keyed to **/dev-lead.yml; no blanket resourceKey — third-party actions must stay SHA-pinned):

1. Adoption guidance — make the dev-lead caller-stub adoption docs + ci-standards.md dev-lead section require the s7637_devlead exemption whenever dev-lead.yml is channel-pinned (mirror how the other stubs are handled), so future adoptions include it.
2. Confirm on the live PR — add the s7637_devlead exemption to bmad's sonar-project.properties (on the #334 branch — keep the @dev-lead/ring1 pin, the do-NOT-SHA-pin guard comment, and the dev-lead:hands-off label intact), and verify SonarCloud re-runs green (new_security_rating back to A, Quality Gate pass, required SonarCloud check ✅).
3. Propagate — apply the same s7637_devlead exemption to every other dev-lead + SonarCloud consumer that channel-pinned dev-lead.yml.

Acceptance criteria

• dev-lead stub adoption guidance / ci-standards.md require the per-file S7637 exemption for dev-lead.yml
• bmad sonar-project.properties exempts S7637 on **/dev-lead.yml (only); SonarCloud Quality Gate on [Fleet Monitor] petry-projects/.github — daily-org-status.yml #334 passes and #334 becomes mergeable
• All other ring-pinned dev-lead consumers carry the same exemption
• No blanket resourceKey; third-party actions remain SHA-pinned (S7637 still enforced elsewhere)

Refs: #495 #500 #871 · ci-standards.md §"SonarCloud Exemption: First-Party Reusable-Ref S7637" · blocks bmad-bgreat-suite#334

[don-petry]

Dev-Lead Implementation Plan

Issue: #546 — bug(ci-standards): dev-lead.yml caller stub missing SonarCloud S7637 exemption — blocks ring-pinned consumers (bmad #334)

Scope

Close the adoption-guidance gap (issue part 1) so every repo that channel-pins dev-lead.yml is told to carry the per-file s7637_devlead SonarCloud exemption. Parts 2–3 (bmad #334 and other consumer repos) live in other repositories and cannot be edited from petry-projects/.github.

Current state (already on main, no change needed)

• This repo's sonar-project.properties already carries s7637_devlead → **/dev-lead.yml (ring0 consumer is compliant).
• dev-lead.yml is already listed in ci-standards.md §"SonarCloud Exemption: First-Party Reusable-Ref S7637".
• check_sonar_s7637_exemption / classify_sonar_s7637_exemption in scripts/compliance-audit.sh are file-agnostic and already enforce/exempt per-file (tests green).

Implementation Checklist

• standards/ci-standards.md — add a required step to "Adopting the Dev-Lead Agent" instructing SonarCloud-gated adopters to add the s7637_devlead exemption (link to the S7637 standard); note it applies whenever dev-lead.yml is channel-pinned (incl. ring tags @dev-lead/ring0|ring1|next).
• standards/workflows/dev-lead.yml — add the SonarCloud S7637 exemption note to the ADOPTING THIS WORKFLOW header block (mirrors the other stubs).

Tests to Write

• None. Documentation/guidance-only change with no observable behavioral change — Phase 2 (TDD) exception per the dev-lead runbook. Existing sonar-s7637-exemption.bats already covers the classifier and the repo's own properties.

Out of repo (cannot be done here — flagged for follow-up)

• bmad-bgreat-suite #334 sonar-project.properties exemption + Quality-Gate confirmation.
• Propagation to other ring-pinned consumers (TalkTerm ring1, .github-private next).

Test Command

bash .dev-lead/scripts/run-bats.sh test/scripts/compliance-audit and bash .dev-lead/scripts/dev-lead-lint.sh

[don-petry]

Dev-Lead: Implementation Complete

Plan Execution

• Part 1 — adoption guidance (in-repo, the actual gap):
  • standards/ci-standards.md → "Adopting the Dev-Lead Agent" now has a required step 6: SonarCloud-gated adopters must add the per-file s7637_devlead exemption (resourceKey **/dev-lead.yml, never a blanket glob) whenever dev-lead.yml is channel-pinned (incl. ring tags @dev-lead/ring0|ring1|next). Links to the canonical S7637 block + notes the check_sonar_s7637_exemption audit finding.
  • standards/workflows/dev-lead.yml → the ADOPTING THIS WORKFLOW header gained the same requirement (step 5), so the stub's own adoption docs carry it.
• Verified existing repo state was already partially in place (no change needed): this repo's sonar-project.properties already carries s7637_devlead; the S7637 standard section already lists dev-lead.yml; classify_/check_sonar_s7637_exemption are file-agnostic and already enforce/exempt per-file.

Phase 2 (TDD) exception

Documentation/guidance-only change, no observable behavioral change → Phase 2 skipped per the runbook exception. The S7637 classifier + the repo's canonical properties are already covered by test/scripts/compliance-audit/sonar-s7637-exemption.bats (still green, see below).

Test Results

# bash .dev-lead/scripts/run-bats.sh test/scripts/compliance-audit  → EXIT 0 (87/87 ok)
ok 78 no issue-ignore config at all is missing
ok 79 an issue-ignore for an unrelated rule is missing (S7637 not covered)
ok 80 a narrow single-file S7637 exemption is present
ok 81 multiple narrow per-stub S7637 criteria are present
ok 82 a blanket workflows/*.yml resourceKey is too-broad
ok 83 a bare ** resourceKey is too-broad
ok 84 a bare *.yml resourceKey is too-broad
ok 85 one narrow + one blanket S7637 criterion is too-broad (blanket wins)
ok 86 whitespace around the ruleKey assignment is tolerated
ok 87 the repo's own canonical sonar-project.properties classifies as present

# bash .dev-lead/scripts/dev-lead-lint.sh  → EXIT 0
  [lint] shellcheck on 15 file(s)...
  [lint] validating .github/CODEOWNERS... OK
  [lint] all checks passed

Files Changed

• standards/ci-standards.md: added required SonarCloud s7637_devlead step to the dev-lead adoption section.
• standards/workflows/dev-lead.yml: added the same requirement to the stub's ADOPTING THIS WORKFLOW header.

Notes — acceptance criteria coverage

• dev-lead stub adoption guidance / ci-standards.md require the per-file S7637 exemption — done (this PR).
• No blanket resourceKey; third-party actions stay SHA-pinned — guidance explicitly forbids blanket globs; classifier still flags too-broad.
• bmad sonar-project.properties exemption + Quality-Gate confirmation on #334 — lives in petry-projects/bmad-bgreat-suite, cannot be edited from petry-projects/.github. Needs a follow-up commit on the #334 branch adding the s7637_devlead block (keep the @dev-lead/ring1 pin, the do-NOT-SHA-pin guard comment, and the dev-lead:hands-off label).
• Propagate to other ring-pinned consumers (TalkTerm ring1, .github-private next) — also out-of-repo follow-ups. .github itself (ring0) already carries the exemption.

The cross-repo items (parts 2 & 3) are outside this repository's tree; with the adoption guidance now requiring the exemption, the org compliance audit's sonar-s7637-exemption-missing warning will surface any consumer that still lacks it.