## Why `.github/workflows/scorecard.yml` (the "Scorecards supply-chain security" workflow) has `startup_failure`'d on **every** push to `main` — confirmed across the last several pushes through the latest commit (`e4c7d96`). It's a thin caller of `scorecard-reusable.yml@3f34549`, and the reusable **at that pinned SHA is itself valid** (I fetched it — identical to `main`'s copy minus the later `timeout-minutes` line). So this isn't a malformed-file bug; it's a redundant second scorecard run the standards repo doesn't need. ## Decision: retire, not repair `scorecard-enforcer.yml` (hardened in #371) is a **strict superset**: | Capability | `scorecard.yml` (reusable) | `scorecard-enforcer.yml` | |---|---|---| | Run OSSF Scorecard | ✅ | ✅ | | Upload SARIF | ✅ | ✅ | | **Publish to OSSF registry** | ❌ (reusable doesn't set `publish_results`) | ✅ `publish_results: true` | | **Score gate** (`MIN_SCORE`) | ❌ | ✅ | The thin-caller→reusable pattern is the estate convention for **downstream** repos. The standards repo is special — it *hosts* `scorecard-reusable.yml` and runs the *enforcer*, so it doesn't need the thin caller too. ## Safety - No other in-repo references to `scorecard.yml` (`grep` clean). - **Not a required status check** — pushes have been merging despite its red, so removing it cannot block merges. - **`scorecard-reusable.yml` is untouched** — downstream callers across the estate are unaffected. - Net: removes a perpetually-red check and a duplicate scorecard run, **zero functional loss** (publishing + SARIF + gate all remain via the enforcer). ## Alternative (rejected) Repairing the caller's `startup_failure` and keeping it would preserve the redundant double-run. If you'd rather keep the thin caller as the canonical pattern *in this repo too*, say so and I'll repair the startup_failure instead of deleting. ## Guardrail No `LICENSE` file or SPDX header touched. https://claude.ai/code/session_011xv3VLrqeXkpjXxUojKz82 --- _Generated by [Claude Code](https://claude.ai/code/session_011xv3VLrqeXkpjXxUojKz82)_ Co-authored-by: Claude <noreply@anthropic.com>