workflow-interface-registry.yml + 8 starter templates reference l9-ci-core@v1, which no longer exists

[cryptoxdog]

Summary

workflow-interface-registry.yml and 8 of the 9 files in workflow-templates/ pin Quantum-L9/l9-ci-core at @v1 and describe a 9-kernel workflow set (pr-pipeline.yml, release-publish.yml, nightly.yml, pre-commit-ci.yml, trio-governance.yml, security.yml, scorecard.yml, sbom.yml, l9-self-ci.yml). None of this exists in l9-ci-core anymore.

Verified facts

• l9-ci-core has exactly one git tag: v0.1.0. There is no v1 tag/ref of any kind (checked git tag + git api .../git/refs).
• l9-ci-core's main branch is on v2.0.0 (per its README.md), a "thin control plane" rewrite. Its current .github/workflows/ contains governance-ci.yml, normalize-semgrep-report.yml, profile-normalize-semgrep.yml, publish-analysis.yml, release-validation.yml, sdk-contract-check.yml, self-ci.yml — none of which match the 9 kernel files the registry describes.
• The registry's current_sha (2b330a5aab90cd7781bef08f14c5e7904b61bc56) is a real historical commit in l9-ci-core, and at that commit the 9 kernel files (pr-pipeline.yml etc.) did exist. So the registry was accurate once, but was never updated after the v2 rewrite retired that layout.
• Affected starter templates (all reference Quantum-L9/l9-ci-core/.github/workflows/<file>.yml@v1):
  • workflow-templates/l9-pr-pipeline.yml
  • workflow-templates/l9-release.yml
  • workflow-templates/l9-nightly.yml
  • workflow-templates/l9-pre-commit.yml
  • workflow-templates/l9-governance.yml
  • workflow-templates/l9-security.yml
  • workflow-templates/l9-scorecard.yml
  • workflow-templates/l9-sbom.yml
  • workflow-templates/l9-node-ts-monorepo.yml (its security/scorecard sub-jobs use the same broken refs)

Impact

Any repo that clicks "Set up this workflow" on one of these 9 starters today gets a workflow that fails immediately (workflow was not found) the first time it runs, because GitHub cannot resolve l9-ci-core/.github/workflows/<file>.yml@v1.

Why this wasn't caught

Quantum-L9/.github has no CI of its own (no .github/workflows/ in this repo), so ops/validate-starters.sh only runs when someone remembers to invoke it manually. Even then, it only validates structural things (matching .properties.json, required fields, no @main references) — it never actually resolves whether the pinned ref/file exists in the target repo. A drift like this (target repo rewritten, ref abandoned) is invisible to it by design.

Suggested fix

1. Decide the org's actual posture toward l9-ci-core v2:
   • If v2's phase-scoped model (profile-normalize-semgrep.yml, publish-analysis.yml, etc.) is the intended replacement, rewrite the affected starter templates to call the correct v2 workflow names/inputs, or retire the ones with no v2 equivalent (pr-pipeline, release-publish, nightly, pre-commit-ci, trio-governance, scorecard, sbom, l9-self-ci currently have no v2 counterpart at all per l9-ci-core's own docs/consumer-lint-test.md, which explicitly moved generic lint/test to a copy-in template pattern instead of a reusable workflow).
   • If l9-ci-core should still expose a v1-compatible surface, cut an actual v1 tag at (or forward-ported from) the last commit where the 9 kernels existed, and keep it alive alongside v2.
2. Update current_ref/current_sha and the kernels: list in workflow-interface-registry.yml to match whatever is decided.
3. Consider adding a scheduled CI check in Quantum-L9/.github (there is currently none) that resolves each starter's uses: target and fails if the file/ref doesn't exist in the target repo — ops/validate-starters.sh as it stands cannot catch this class of drift.

Related

Related to the org-defaults gap tracked in #6 (missing local LICENSE/ISSUE_TEMPLATE cascade) — same root cause of org-level config drifting without a feedback loop back from consumer repos.