ci: guard scorecard behind SCORECARD_ENABLED repo var

[arcaven]

Makes Scorecard analysis opt-in: the job runs only when the repo variable SCORECARD_ENABLED is set to true — the same opt-in pattern already used for SIGNING_ENABLED. No var, no run. Forks and clones stay quiet by default; enable per repo by adding the variable.

[arcavenai]

Diagnosed the two failing checks — unrelated to this PR's change (the diff is 4 lines in scorecards.yml; the failure is in Spec Guards' BC citation check):

• check-bc-citation-symbols.sh reports 12 DEAD citations for src/cli/issue/attachments.rs and src/api/jira/attachments.rs. Those BC specs (S-576 series, read from factory-artifacts) cite implementation files that landed on develop via feat(issue): attachment upload platform POST + --replace-existing + --dry-run path-c (S-576-3, #576 part 3) #635/feat(issue): attachment delete single/bulk/older-than + dry-run (S-576-4, #576 part 4) #638 after this branch's last CI run — the merge ref at run time (2026-07-21T22:30) predated them. CI Gate is just the fan-in failing on Spec Guards.
• Verified locally: with current develop merged into this branch, the same script passes (Check passed: 354 citations checked).

Fix: update the branch against develop (the GitHub "Update branch" button suffices — the branch touches only scorecards.yml, so it's conflict-free) and let checks re-run. This account doesn't have write access to push the prepared merge, so flagging for someone who does.

[arcavenai]

To make the fix copy-paste executable (this account can't push to this branch): no file content changes are needed — the remedy is purely a branch refresh, since the DEAD citations name files that exist on current develop (e33624c…c28ae94, the four S-576 attachment PRs) but not in this branch's stale merge ref.

Either click Update branch on this PR, or:

git fetch origin develop ci/scorecard-guard
git checkout ci/scorecard-guard
git merge origin/develop        # conflict-free — this branch touches only .github/workflows/scorecards.yml
git push origin ci/scorecard-guard

Verified locally on exactly that merge: mounted factory-artifacts at .factory/ and ran bash scripts/check-bc-citation-symbols.sh → Check passed: 354 citations checked (exit 0), and the PR's own diff remains the 4-line SCORECARD_ENABLED gate.

[Zious11]

Thanks — this is the behavior I want: Scorecard disabled by default, enabled per-repo via SCORECARD_ENABLED. I'm keeping the opt-in polarity exactly as you have it (if: vars.SCORECARD_ENABLED == 'true') — no flip to a _DISABLED variable. The canonical repo will intentionally leave it off unless the variable is set, which is the intended outcome.

Design and scope look good — the placement matches the existing SIGNING_ENABLED/ATTESTATIONS_ENABLED gate pattern, and there's no security concern (the change only adds an opt-in gate). Two things before it merges:

Please add

• Document the new gate, same as the other *_ENABLED gates:

  • docs/specs/fork-friendly-release-ops.md — add a SCORECARD_ENABLED row to the repository-variables table.
  • CLAUDE.md — add it to the "Release-ops repo-variable gates" bullet.

  (This repo documents each new vars.* gate in the same commit as the workflow change.)

Housekeeping

• Rebase onto develop and re-run CI — the branch is a few weeks stale. The if: insertion point is untouched by the recent scorecard-action/upload-sarif bumps, so it should be a clean rebase; I just want a fresh green against current develop.

Thanks for tightening this up.

[arcaven]

Caught up and the two doc asks are in, so this should be mergeable as-is once CI runs.

• Merged develop in at cfe1ded (a40efbb, no conflicts).
• bf5862f adds the SCORECARD_ENABLED row to docs/specs/fork-friendly-release-ops.md and the entry in CLAUDE.md's repository-variables paragraph, in the shape of the existing gates.

Against develop the PR is now 3 files, +6/-1 (gh api repos/Zious11/jira-cli/compare/cfe1dedc...bf5862f2): the 4 guard lines in scorecards.yml plus the two doc lines. Ordinary merge commit rather than a rebase, so the approved commit is unchanged.

[Zious11]

Accepterd in the other PR #827. Closing this one