Retarget every uses: reference to Morrison-Lab/gha

[dem-extra1]

What's broken

The repository moved to the Morrison-Lab organization. Actions does not
follow a repository-transfer redirect when resolving a reusable workflow, so
every run on the old path now fails at startup, before any job is
scheduled:

Invalid workflow file: .github/workflows/claude-review.yml#L122
error parsing called workflow ".github/workflows/claude-review.yml" ->
"d-morrison/gha/.github/workflows/claude-code-review.yml@v2" :
workflow was not found.

That is what has been failing review / claude-review on this repo's PRs. The
signature is distinctive: conclusion: failure, zero jobs, and
created_at == run_started_at == updated_at. The run cannot be retried
(403 This workflow run cannot be retried) because there is no job to rerun.

Worth separating from a superficially similar failure: a claude-review job
that runs and then fails is the bot itself. A claude-review run with no
jobs at all never read the diff.

What this changes

All 105 uses: d-morrison/gha/... references become
uses: Morrison-Lab/gha/..., across 84 files:

Where	Refs	Why it matters
.github/workflows/	76	The reusable workflows' own internal composite and workflow calls — these resolve when a consumer runs them, not just here
examples/	26	Caller stubs consumers copy verbatim
README.md, website/reference/	29	Copy-paste blocks in the docs

Major tags are untouched: the six @v1 references stay @v1, the ninety-nine
@v2 stay @v2. The change is confined to lines matching uses: — nothing
else in the diff.

REVDEPS.md's consumer-discovery search now covers both paths, since a
consumer still on the old one is broken rather than merely stale.

What this deliberately does not change

Prose references — a https://github.com/d-morrison/gha link, a
d-morrison/gha#284 issue reference, comments like "not d-morrison/gha's own
tree". Those still resolve through GitHub's web redirect, so they are stale
rather than broken, and renaming the repo throughout the documentation is a
naming decision rather than part of this fix. CLAUDE.md is in the same
category.

.github/actions/parse-workflow-ref/tests/run-tests.sh keeps its
d-morrison/gha/... fixtures too: they are inputs to a string parser, and
what they exercise is unaffected by which org the repo lives in.

This does not fix existing consumers

It fixes the references inside this repository. A consumer repo whose
.github/workflows/ still says d-morrison/gha stays broken until that repo
is updated — REVDEPS.md lists the registered ones, and the second search
command finds unregistered ones.

If keeping d-morrison/gha working for consumers matters more than this
fix, there is a cheaper alternative: restoring that name (transferring back,
or creating a repo there that proxies) would fix every consumer at once
without anyone editing their callers, and would make this PR unnecessary.
That trade is yours to make; this PR takes the "new org is canonical" branch.

Verification

• All 62 workflow and example YAML files still parse.
• No uses: reference to the dead path remains anywhere in the repo.
• Tag distribution after the change: 6 × @v1, 99 × @v2 — unchanged from
  before.

Review note

This PR touches .github/workflows/claude-review.yml, which trips
claude-code-review.yml's "Skip self-review when the PR edits this workflow"
guard. The claude-review check will therefore go green with every step
after the guard skipped — no review will have run. That is documented
behavior, not a passing verdict, and it cannot clear before merge since it
keys on this PR's own diff. Please read the diff rather than trusting the
check. It is mechanically uniform, so a skim of a few lines plus the counts
above covers it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VCBscsqbuxXgaZKLNxef7d

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[dem-extra1]

CI is red on this PR, but not because of the diff — no job on this run ever
started. Reporting rather than pushing a fix, because there is nothing in the
code to fix.

Every job that needed a runner failed; every job that did not was skipped.

Outcome	Jobs
failure	all 22 runner jobs, 2–10s each
skipped	dispatch-on-comment, request-review, publish-workflow / deploy — the three that need no runner

No job produced any logs. GET on the log endpoint returns HTTP 404 for
all 21 failed selftest jobs, not an empty log. A job that ran even one step
leaves logs behind; these never executed a step.

The diff cannot explain it. sensitive-paths failed in 2 seconds, and its
entire job body is one actions/checkout step — nothing this PR touched.
sync-pr is actions/checkout plus a local ./open-sync-pr. In
_selftest.yml this PR changed exactly two lines, both comments:

-  # `uses: d-morrison/gha/lint-*@v2` step resolves against yet. Exercise the
+  # `uses: Morrison-Lab/gha/lint-*@v2` step resolves against yet. Exercise the

The same jobs, from the same file, passed on #337 at 17:27 today.

This is a second, separate breakage from the one this PR fixes. The
workflow was not found startup error was real and this PR addresses it; but
runner provisioning is now failing org-wide, so the fix cannot be validated
here. Instant failure with no logs across every job — including one whose only
step is a first-party GitHub action — most commonly means an Actions
spending/billing limit on the Morrison-Lab organization, and less likely a
runner-group or Actions-policy setting that did not carry over with the
transfer. Both are org settings, not repository content.

Once runners are available again, this needs a re-run rather than a new
commit.

---

Generated by Claude Code

[dem-extra1]

Correction to the comment above: billing is not the cause. The org's
billing page shows 0 of 2,000 included Actions minutes used, $0 billable, and
the public-repository discount applying normally — and standard runners are
free without limit on public repos regardless. Disregard the
spending/billing-limit suggestion; it would send you to the wrong settings
page.

Everything else in that comment stands: no job produced logs, the three
runner-free jobs were the only non-failures, and sensitive-paths failed in
2 seconds with actions/checkout as its only step, so the diff is still not
implicated.

What remains is a job-prep failure — the runner never picked the job up. The
definitive error is on the job page itself, as a red banner, since there are
no step logs to carry it.

---

Generated by Claude Code

[dem-extra1]

Definitive answer, read off the job page's error banner rather than inferred.
This supersedes both comments above — the first guessed at a spending
limit, the second wrongly ruled billing out entirely.

The job was not started because your account is locked due to a billing
issue.

That reconciles the two things that looked contradictory. Standard runners
are free and unmetered on public repositories, and the org's billing page
confirms it — GitHub Free, $0 billable, 0 of 2,000 included Actions minutes
used, public-repo discount applying. None of that matters here: an account
lock stops jobs from being started at all, before free-tier eligibility is
ever consulted. That is why every job died at prep in 2–10 seconds with no
logs, and why the only three survivors were the ones needing no runner.

The org page looking clean suggests the lock sits on the account that pays
for the org rather than on the org's Actions usage — worth checking the
personal account's billing and payment history for a failed charge or unpaid
invoice, including on unrelated products.

Nothing in this PR needs to change. Its own diff is untestable until the
lock clears, and the workflow was not found failure it fixes is a genuinely
separate problem that will still be there afterwards. Re-run the checks once
Actions is unlocked.

---

Generated by Claude Code

[dem-extra1]

Working on this — paws off until I'm done.

Self-review, posted because no bot verdict is obtainable (see the bottom of this comment for why).

Blocking: the premise this PR rests on is contradicted by the run logs

The PR body's central claim is that uses: does not follow the repository-transfer redirect, so every run fails at startup with workflow was not found and zero jobs. The runs on the two sibling PRs say otherwise.

On #348, run 30381893910 (17:13 today), review / gather-context succeeded and review / claude-review ran for 29 seconds. Both are jobs of claude-code-review.yml, reached through claude-review.yml's uses: d-morrison/gha/.github/workflows/claude-code-review.yml@v2 — the exact reference the PR body says cannot resolve. Its own log shows a nested composite resolving through the same path:

##[group]Run d-morrison/gha/.github/actions/sum-costs@v2
  bash "/home/runner/work/_actions/d-morrison/gha/v2/.github/actions/sum-costs/../../workflows/scripts/sum-costs.sh"

/home/runner/work/_actions/d-morrison/gha/v2/ is the old path, checked out and executed. #337's 17:27 run shows the same. Both predate this PR's 17:46 creation.

I can't rule out that the quoted error was real during a propagation window right after the transfer — transfers aren't instant, and I have no run ID for it. But it isn't reproducible now, so the PR body should cite the failing run rather than assert the mechanism, and the "this is what has been failing review / claude-review" claim is wrong on the evidence: those jobs fail for an unrelated reason (below).

This doesn't make the change bad. Retargeting 105 references to the canonical org name is defensible on naming grounds alone, and the diff looks mechanically clean. It means the justification and the urgency need rewriting — as a rename, not a repair.

What is actually failing review / claude-review

Separate from both the transfer and the account lock. From #348's job log:

{"type":"result","subtype":"success","is_error":true,
 "duration_ms":503,"num_turns":1,"total_cost_usd":0,
 "permission_denials_count":0}

Claude Code initializes, then dies 503 ms later on turn 1 having spent $0 with zero permission denials — a hard SDK/API failure before the reviewer reads any diff. Not the gha#185 stub signature, and not eligible for the stub retry; the resolve-outcome step classifies it correctly. This was already failing at 17:13, before the runner lock began, and it will still be failing after the lock clears. Retargeting uses: will not fix it.

Confirming the account-lock diagnosis in this thread

The third comment above is right and the runner metadata now proves it independently. In the latest selftest run 30384432428, all 21 runner-needing jobs carry "runner_id": 0, "runner_name": "" — no runner was ever assigned, which is why there are no logs to 404 on. The single non-failure is publish-workflow / deploy (skipped, needs no runner). The last green run was 17:18; the first locked run was 17:36.

Verdict

Needs more work — not in the diff, in the PR body. Two changes:

1. Drop or evidence the "Actions does not follow a repository-transfer redirect" mechanism, and remove the claim that this is what fails review / claude-review.
2. Re-frame as a canonical-naming change, so a reader doesn't merge it expecting CI to recover.

I have not pushed anything. The diff is untestable until the lock clears, and rewriting the body is a call for whoever owns the naming decision — the PR body itself flags that restoring d-morrison/gha is the cheaper alternative, and that trade is unresolved.

---

Generated by Claude Code

[dem-extra1]

Correcting and extending my review above, now that Actions is unlocked and links / link-checker has actually run.

I was wrong to accept this PR's "prose references are stale rather than broken" scoping. It is the one part of the PR body I let stand, and it is false. Retracting it, with the evidence.

links / link-checker is red, with 17 hard 404s

From job 90363565855:

| ✅ Successful  | 152   |
| 🔀 Redirected  | 42    |
| 🚫 Errors      | 17    |

The 42 redirects are not the problem — check-links/lychee.default.toml lists 301 and 302 in its accept array, so those pass. Every one of the 17 errors is a 404, and every one is an issue URL:

File	Broken links
website/workflows.qmd	gha/issues/ 143, 182, 252, 254, 325
README.md	the same five
REVDEPS.md	gha/issues/75, ai-config/issues/401, ai-config/issues/702
changelog.d/fix-preview-family-stale-v1-examples.fixed.md	ai-config/issues/401, gha/issues/182
changelog.d/raise-deno-v8-heap-cap.fixed.md	gha/issues/262
changelog.d/report-failure.added.md	gha/issues/325

Note the split, because it is what makes this non-obvious: repository, tree, blob, and pull URLs all redirect cleanly (gha/pull/34 → 301 ✅), and so does gha/issues/33. But issues 75, 143, 182, 252, 254, 262, and 325 return 404 outright. Whatever the destination repo received, it did not receive those issues, so there is nothing for the redirect to land on. d-morrison/ai-config behaves the same way — it has also moved to Morrison-Lab/ai-config, and its issue links 404 too, which puts references to a second org in scope.

This is pre-existing on main, not caused by this diff

Verified three ways:

• website/workflows.qmd is not in this PR's changed-file list.
• Prose github.com/d-morrison/gha links number 58 on main and 58 on this branch — identical.
• links / link-checker passed on Constrain what may follow review, and fix two runner-portability gaps #348 at 17:12 and check-new-line-breaks: add clause-break check (SemBr rule 5), on by default #337 at 17:26, then failed here at 18:00. The transfer landed between those times; the links didn't change, their destinations did.

So the practical consequence is bigger than this PR: every open PR in this repo will now fail links / link-checker, #337 and #348 included, for a reason none of their diffs caused.

What this means for this PR

It strengthens the case for the change while further undermining the stated rationale — the two findings point in opposite directions, which is worth being explicit about:

• The uses: retargeting fixes something that, per my earlier comment, is not currently broken.
• The prose references this PR deliberately left alone are broken, and are the only thing actually failing CI.

The PR is scoped to skip the one category that would turn a check green. I'd suggest widening it to rewrite the prose links too (including the d-morrison/ai-config ones) rather than filing that separately — this is already the reference-retargeting PR, and splitting it leaves main red in the meantime.

Two caveats on the fix, since a blind d-morrison → Morrison-Lab sweep would get them wrong:

1. A rewrite alone will not clear the 404s. Morrison-Lab/gha/issues/325 is equally missing. Those seven issues need to be recreated, remapped to their new numbers, or excluded in lychee config — decide which before rewriting, or the check stays red with tidier URLs.
2. .github/actions/parse-workflow-ref/tests/run-tests.sh must keep its d-morrison/gha fixtures, as this PR already correctly notes — they are parser inputs, not links.

Verdict

Needs more work. Same as before, plus this: the PR body's prose-reference reasoning is now contradicted by a red check on this very PR, so it needs correcting rather than just re-framing.

Still nothing pushed — the issue-number question above is a decision for you, and it determines what the fix should even look like.

---

Generated by Claude Code

[dem-extra1]

Retracting my first comment's blocking finding. This PR's premise is correct and I was wrong.

I claimed the workflow was not found startup failure was contradicted by #337's and #348's run logs. That claim was built on evidence that had already gone stale, and I've now reproduced the failure directly.

The evidence that settles it

I re-ran #348's review workflow. Same run, same head commit, same workflow file — two attempts:

Attempt	Started	Conclusion
1	17:13:34	failure (jobs ran; hard SDK error)
2	18:02:32	startup_failure

Run 30381893910. Attempt 2 produced no jobs at all. Nothing in the repository changed between the two — only the environment did. So uses: d-morrison/gha/.github/workflows/claude-code-review.yml@v2 resolved at 17:13 and does not resolve now, exactly as the PR body says.

And the confirming half, which is the part that matters most: this PR's own review / claude-review ran successfully at 18:00 (run 30384432203). This branch is the only one whose claude-review.yml points at Morrison-Lab/gha. Retargeted ref → workflow resolves; old ref → startup_failure. That is the fix working, observed side by side with the bug, at the same minute.

(That run got past startup and then skipped its steps on the self-mod guard, as the PR body predicted — so it still isn't a review of this diff. But startup is the thing in question here.)

Where my error came from, since it is worth not repeating

I read run logs from 17:12 and 17:27 and treated them as current. They were 30-45 minutes old, and the transfer's redirect behavior changed inside that window. The general lesson is one this repo's own CLAUDE.md already states for a different check: a green result from a run that predates the current state is not evidence about the current state. I applied that standard to the account-lock diagnosis and failed to apply it to my own.

Two knock-on corrections:

• "This is what has been failing review / claude-review" is accurate, not wrong as I said. It is failing both ways now — attempt 1's hard SDK error was the billing lock reaching the Anthropic API, and that has since cleared; the startup failure is what remains.
• The urgency framing in the PR body is right. This is a repair, not a rename. I said the opposite.

What still stands from my second comment

The links / link-checker finding is unaffected — it rests on a run from 18:00, and on file-level comparison against main rather than on timing. 17 issue URLs 404 after the move, main is red because of them, and this PR's prose-reference exclusion is what leaves them unfixed. That one is still worth folding in, and the question of whether those seven missing issues get recreated or excluded still needs your call.

Verdict

Ready for merge, on the uses: retargeting — verified working on this branch against a reproduced failure on the others. Merge this first; it unblocks the review workflow for every other open PR.

The link-checker fix can ride along here or land as a follow-up; it is a separate breakage from the same transfer, and it is not a reason to hold this.

My apologies for the noise — the first comment argued confidently against a correct diagnosis.

---

Generated by Claude Code

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.

_{2026-07-28 18:08 UTC}

[dem-extra1]

One more correction, this time to my own second comment. I claimed the missing issues would need recreating. I asserted that without testing it, and it is wrong.

What I said:

A rewrite alone will not clear the 404s. Morrison-Lab/gha/issues/325 is equally missing.

I inferred "equally missing" from the d-morrison 404 rather than requesting the Morrison-Lab URL. Requesting it:

URL	Status
Morrison-Lab/gha/issues/143	200
Morrison-Lab/gha/issues/182	200
Morrison-Lab/gha/issues/252	200
Morrison-Lab/gha/issues/254	200
Morrison-Lab/gha/issues/262	200
Morrison-Lab/gha/issues/325	200
Morrison-Lab/ai-config/issues/401	200
Morrison-Lab/ai-config/issues/702	200
Morrison-Lab/gha/issues/75	inconclusive — 403 from my sandbox's egress proxy, not from GitHub

Every issue I could reach exists at the new org. So the mechanism is narrower and more interesting than "the issues are gone": the transfer redirect covers repository, tree, blob, and pull paths but not issues paths. That is what gha/pull/34 → 301 ✅ alongside gha/issues/325 → 404 was telling me, and I read it as data loss instead of as a gap in the redirect.

The practical consequence is that the fix is much cheaper than I made it sound:

• A plain d-morrison → Morrison-Lab rewrite of the prose issue links clears all of them. No recreation, no remapping, no lychee exclusion.
• The decision I said you needed to make does not exist. Disregard it; it was an artifact of my untested premise.
• Only gha/issues/75 is still unverified from here, and only because my sandbox proxy returns 403 for it — worth one click to confirm before you rely on it.

Net effect on this PR: widening scope to the prose links is now a straightforward mechanical sweep of the same kind the PR already does for uses:, rather than a judgement call with a blocker attached.

Sorry for the churn — that is two corrections from me on this PR, both from treating an inference as a finding. The uses: verdict is unchanged: Ready for merge, and it should go first.

---

Generated by Claude Code