Skip to content

fix(ci): call the estate reusables by their real ref — these never parsed - #9

Merged
hyperpolymath merged 1 commit into
mainfrom
fix/reusable-workflow-refs
Sep 19, 2026
Merged

hyperpolymath merged 1 commit into
mainfrom
fix/reusable-workflow-refs

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

These workflows carried uses: ../….github/workflows/<x>-reusable.yml, which is not a ref form
GitHub Actions supports
— a reusable-workflow uses: may be ./… (same repo) or
<owner>/<repo>/….yml@<ref> (cross repo). A ../ path is rejected at parse time, so each of these
workflows is permanently dead: conclusion=failure, 0 jobs, and a run name equal to its path
rather than its declared name:. That triple is also the signature of callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

  1. the ref becomes the pinned cross-repo form,
    hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…;
  2. the caller grants the permissions the callee's job declares. A cross-repo callee cannot hold
    more than its caller grants it, so repairing only the ref would move the failure from parse time
    to run time — the same defect, one layer down. Permissions are keyed off the callee named in
    the ref, not the caller's filename: scorecard-enforcer.yml also calls scorecard-reusable.yml.

Refs hyperpolymath/standards#808. The reusables themselves are untouched — they were always fine;
this is the callers' ref form.

@coderabbitai

coderabbitai Bot commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor

Review Change StackReview Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 9ff0d79a-08e3-498a-92a5-596478d88f38

📥 Commits

Reviewing files that changed from the base of the PR and between 79ed653 and be13cd8.

📒 Files selected for processing (7)
  • .github/workflows/codeql.yml
  • .github/workflows/governance.yml
  • .github/workflows/hypatia-scan.yml
  • .github/workflows/mirror.yml
  • .github/workflows/scorecard-enforcer.yml
  • .github/workflows/scorecard.yml
  • .github/workflows/secret-scanner.yml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

📜 Recent review details
⏰ Context from checks skipped due to timeout. (9)
  • GitHub Check: scan / shell-secrets
  • GitHub Check: scan / rust-secrets
  • GitHub Check: scan / gitleaks
  • GitHub Check: analyze-js / analyze
  • GitHub Check: scan / Hypatia Neurosymbolic Analysis
  • GitHub Check: security
  • GitHub Check: build
  • GitHub Check: build
  • GitHub Check: security
🧰 Additional context used
🪛 zizmor (1.30.0)
.github/workflows/secret-scanner.yml

[warning] 20-20: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow

(secrets-inherit)

.github/workflows/codeql.yml

[warning] 22-22: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)

.github/workflows/governance.yml

[warning] 28-28: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)

.github/workflows/mirror.yml

[warning] 15-15: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)


[warning] 17-17: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow

(secrets-inherit)

.github/workflows/hypatia-scan.yml

[warning] 21-21: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)


[warning] 24-24: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow

(secrets-inherit)

.github/workflows/scorecard-enforcer.yml

[warning] 19-19: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)

.github/workflows/scorecard.yml

[warning] 25-25: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)


[warning] 26-26: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow

(secrets-inherit)

🔇 Additional comments (7)
.github/workflows/codeql.yml (1)

21-25: LGTM!

.github/workflows/governance.yml (1)

27-30: LGTM!

.github/workflows/hypatia-scan.yml (1)

20-24: LGTM!

.github/workflows/mirror.yml (1)

14-17: LGTM!

.github/workflows/scorecard-enforcer.yml (1)

17-20: LGTM!

.github/workflows/scorecard.yml (1)

23-26: LGTM!

.github/workflows/secret-scanner.yml (1)

20-20: LGTM!


📝 Summary

Summary by CodeRabbit

  • Chores
    • Updated automated security, governance, scanning, mirroring and scoring workflows to use pinned shared workflow versions.
    • Added explicit workflow permissions to support required checks while limiting access.
    • Improved consistency and reproducibility of automated repository maintenance tasks.

Walkthrough

Seven GitHub Actions workflows now call commit-pinned reusable workflows from hyperpolymath/standards. Several jobs now declare explicit permissions, including read access and security event write access where required.

Changes

Shared workflow migration

Layer / File(s) Summary
Pinned workflow references and job permissions
.github/workflows/codeql.yml, .github/workflows/governance.yml, .github/workflows/hypatia-scan.yml, .github/workflows/mirror.yml, .github/workflows/scorecard-enforcer.yml, .github/workflows/scorecard.yml, .github/workflows/secret-scanner.yml
All reusable workflow calls now use commit 4e6ffe5568d7864f540d99c7d4ea9b9250ed30f2 from hyperpolymath/standards. CodeQL, Hypatia, mirror, and Scorecard jobs declare explicit permissions. The Scorecard job replaces inherited actions: read with contents: read and security-events: write.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the main change: correcting reusable workflow references that failed to parse.
Description check ✅ Passed The description directly explains the invalid references, the pinned replacements, and the required permissions changes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

A rabbit reads each line,
The patch grows clear beneath the moon,
Small changes hop in place,
Tests guard the garden path,
Reviews bloom before the dawn.

Comment @coderabbitai help to get the list of available commands.

…d copies

`uses: ../….github/workflows/<x>-reusable.yml` is not a ref form GitHub Actions supports, so every
workflow carrying it fails at parse time: conclusion=failure, 0 jobs, and a run name equal to its
path rather than its declared `name:`.

This repairs them throughout the tree, not only in the root `.github/workflows/`, because the root
is where they are *live* but the nested copies are where they *propagate* — standards' format
templates, k9-ecosystem's dispatch templates and deed-core's action scaffolds are what new repos are
minted from, and each one carried an unparseable ref.

Each ref becomes the pinned cross-repo form
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`, and each calling job is
granted the permissions its callee declares — keyed off the callee named in the ref, since several
callers point at the same reusable. Without that step the repair only moves the failure from parse
time to run time.

Refs hyperpolymath/standards#808.
@hyperpolymath
hyperpolymath force-pushed the fix/reusable-workflow-refs branch from be13cd8 to 490f0f6 Compare September 19, 2026 19:41
@sonarqubecloud

Copy link
Copy Markdown

@hyperpolymath
hyperpolymath merged commit b41f557 into main Sep 19, 2026
8 of 11 checks passed
@hyperpolymath
hyperpolymath deleted the fix/reusable-workflow-refs branch September 19, 2026 19:42
@github-advanced-security

Copy link
Copy Markdown

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

  • The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
  • Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
  • You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
hyperpolymath added a commit that referenced this pull request Sep 19, 2026
…rsed (#9)

These workflows carried `uses: ../….github/workflows/<x>-reusable.yml`,
which is **not a ref form
GitHub Actions supports** — a reusable-workflow `uses:` may be `./…`
(same repo) or
`<owner>/<repo>/….yml@<ref>` (cross repo). A `../` path is rejected at
parse time, so each of these
workflows is permanently dead: `conclusion=failure`, **0 jobs**, and a
run name equal to its path
rather than its declared `name:`. That triple is also the signature of
callee-lockfile poisoning,
which is why these read as lockfile faults rather than as what they are.

Two changes per file:

1. the ref becomes the pinned cross-repo form,
`hyperpolymath/standards/.github/workflows/<x>-reusable.yml@4e6ffe55…`;
2. the caller grants the permissions the callee's job declares. A
cross-repo callee cannot hold
more than its caller grants it, so repairing only the ref would move the
failure from parse time
to run time — the same defect, one layer down. Permissions are keyed off
the **callee** named in
the ref, not the caller's filename: `scorecard-enforcer.yml` also calls
`scorecard-reusable.yml`.

Refs hyperpolymath/standards#808. The reusables themselves are untouched
— they were always fine;
this is the callers' ref form.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants